결국 프롬프트가 가장 중요합니다
스킬, 서브 에이전트, 하네스, 플랜 모드 등.
코딩 에이전트 기능은 나날이 많아지고 있습니다.
하지만 실전에서 결과를 가르는 건 결국 프롬프트 자체의 품질입니다. 같은 도구를 써도 프롬프트를 어떻게 쓰느냐에 따라 결과물의 수준이 완전히 달라지거든요.
기존에는 구현 → 코드 리뷰라는 단순한 흐름이었습니다.
이를 좀 더 세분화하면 생산성을 극적으로 끌어올릴 수 있습니다.
프롬프트 작성 4단계 프로세스
1단계: 프롬프트 초안 작성
프롬프트는 그냥 작성하지 않습니다. 반드시 다음 네 가지 항목을 포함해주세요.
내용은 당연히 구체적일수록 좋습니다.
- Requirements: 개발 지식 없이도 작성 가능한 기능 요구사항. "비밀번호가 틀리면 에러 메시지를 표시한다" 같은 수준입니다.
- Implementation Detail: 개발자만 작성 가능한 구현 방식. "JWT 인증, 쿠키 저장"처럼 라이브러리·DB 설계 등 영향 범위가 큰 결정 사항을 명시합니다. AI의 임의 판단을 방지하는 게 핵심이에요.
- Constraints: 절대 해서는 안 되는 제약 조건.
- Acceptance Test: 작업 완료 시 통과해야 할 성공 조건. "올바른 아이디·비밀번호 입력 시 로그인 성공" 같은 것이죠.
비개발자인 경우 Implementation Detail은 생략해도 괜찮습니다.
2단계: 자체 점검
작성된 프롬프트를 다시 읽으며 AI가 오해할 수 있는 모호한 표현을 찾아냅니다.
"이 프롬프트를 입력했을 때, 내 의도대로 구현되지 않을 경우의 수는 무엇이 있을까?"를 고민해보는건데요, 예시를 보며 함께 찾아보겠습니다.
## Requirement
- `admin.vooster.ai` 주소로 배포할 것이다.
- dev 실행 시 `localhost:3004`에서 실행됨
- 로그인: 미리 정의한 관리자 id/pw로만 로그인
- 메인페이지: 계정이메일 + 조직slug를 입력하여 조회. 조회된 조직을 선택해 다음 action 수행 가능.
- subscription plan을 변경한다.
- 해당 계정이 organization에서 갖는 role을 바꾼다. ('OWNER', 'ADMIN', 'MEMBER')
- 해당 organization에 추가 크레딧을 부여한다.
## Implementation Detail
- tidy first
- `standalones/admin`에 필요한 기능들을 추가하라.
- trpc + tanstack query 사용.
- shadcn, tailwindcss 사용
- 인증유지를 위해서 Next.js middleware를 쓰지말고, useState로 로그인상태를 관리하라. (새로고침하면 풀린다.)
## Constraints
- `packages/prisma`외의 workspace package 사용은 불가하다. `standalones/admin`에서 직접 만들라.
---
## Acceptance Test
- `standalones/admin`의 build script가 성공한다.
- (수동) 미리 정의한 변수로 로그인이 성공한다.
- (수동) 유효한 이메일 + 조직slug로 계정/조직 조회가 성공한다.
위 프롬프트의 모호한 부분은 2개입니다.
먼저 "미리 정리한 관리자 계정"이라는 표현은 DB 계정 목록인지 단일 고정 계정인지 불분명합니다. (변수로 관리한다)라는 표현을 추가해서 명확하게 만들겠습니다.
또 tRPC·Tanstack Query처럼 셋업이 복잡한 기술 스택은 AI가 실수하기 쉬우므로 별도로 보강해야 합니다. (web search로 올바른 구현방식을 찾은 뒤 그대로 구현한다)라고 명시하겠습니다.
3단계: 피어 리뷰
동료 개발자와 프롬프트를 함께 리뷰합니다. "쿠키보다 세션이 적합하지 않은가?" 같은 구현 방향 수준의 피드백이 이루어집니다.
이렇게 프롬프트 사전 리뷰를 하게되면 여러가지 장점이 따라오는데요,
첫째로 완성된 코드가 아닌 의도와 접근 방식 수준에서 피드백하므로, 주니어가 시니어의 문제 해결 방식을 상시적으로 전수받게됩니다. 리뷰 시간이 짧아지고, 서로가 얻는 이득은 더 커지게 됩니다.
둘째는 피어 리뷰를 진행한 사람이 코드 리뷰도 담당하므로, 코드 리뷰 시 의도 파악 없이 구현 반영 여부만 확인하면 된다는 것입니다. 이미 아는 작업이니 빠르게 검토할 수 있습니다. 결과적으로 리뷰 속도가 크게 빨라집니다.
프롬프트 리뷰 문화가 잘 자리잡은 기업에서는 코드 리뷰 단계를 완전히 제거하기도 합니다. 구현 전에 미리 점검했으니, 구태여 한번 더 점검해 리소스 낭비와 병목을 만들 필요가 없는 것이죠.
체감 효용이 매우 큰 부분이니, 꼭 한번 도입해보셨으면 좋겠습니다.
4단계: 실행 및 사후 점검
마지막으로 작업자가 프롬프트를 실행한 후, 의도와 맞지 않거나 누락된 후속 요청 사항을 이슈 트래커에 기록합니다. 이는 팀 자산으로 관리되기 때문에 각자의 시행착오가 자동으로 문서로 남게되고, 결과적으로 팀 전체의 프롬프트 작성 능력이 계속 올라갑니다.
신규 입사자의 온보딩에도 큰 도움이 됩니다. 모든 프롬프트가 남아있고, 그 프롬프트에서 무엇을 보완해야했는지도 바로 볼 수 있으니까요. 사람이 붙어서 인수인계하는 것보다 훨씬 효율적입니다.
여기까지 프롬프트 작성 프로세스를 알아봤습니다.
총 소요 시간은 초안 30분, 피어 리뷰 30분, 실행·수정 포함 약 1시간입니다. 프롬프트에 시간을 오래 쓰긴 하지만, 같은 작업을 손으로 직접 개발하면 4~6시간이 걸리는만큼 큰 생산성 향상 효과를 볼 수 있습니다.
마무리
여기까지 개발팀을 위한 프롬프트 작성 템플릿과 협업 프로세스를 알아보았습니다.
많은 개발자들이 스킬/하네스 등 에이전트를 강화하기위한 장치는 열심히 공부하지만, 정작 팀원들이 작성하고 있는 프롬프트 자체의 퀄리티는 잘 관리되지 않는 경우가 많습니다.
AI 활용 능력의 핵심은 프롬프트입니다.
이 능력을 팀 차원에서 관리/전파하여 전사적인 생산성을 끌어올려보세요.
그것이 진정한 AI Native가 되기위한 첫번째 단계입니다.