실전 프롬프트·워크플로우 — 도구별 요청 패턴 모음

7장에서 작업 성격에 맞춰 도구를 조합하는 "최적 스택"을 짰다면, 이번 장은 그 도구를 실제로 어떻게 불러 쓰는가입니다. 같은 도구라도 요청을 어떻게 던지느냐에 따라 결과가 극과 극으로 갈립니다. 여기서는 유형별로 통하는 요청 패턴과 복붙해서 바로 쓸 수 있는 프롬프트를 정리합니다.

도구 유형에 따라 프롬프트가 달라진다

프롬프트를 잘 쓴다는 건 미사여구를 붙이는 게 아닙니다. 도구가 어떤 방식으로 동작하는지 알고, 그 방식이 먹기 좋게 정보를 떠먹여 주는 겁니다. 자동완성형·채팅편집형·에이전트형은 입력을 받아들이는 통로가 서로 다릅니다.

자동완성형 — 주석과 시그니처로 유도한다

GitHub Copilot의 인라인 완성이나 Tabnine 같은 자동완성형은 채팅창이 아니라 커서 주변의 코드를 읽고 다음 줄을 예측합니다. 그러니 프롬프트를 "말"로 던지지 말고 코드로 심어야 합니다. 함수 시그니처를 먼저 적고, 그 위에 한 줄 주석으로 의도를 박아 두면 제안 품질이 확 올라갑니다.

예를 들어 빈 함수 위에 이렇게 적어 둡니다.

// 이메일 문자열을 받아 형식이 유효하면 true, 아니면 false 반환. RFC 5322 간이 규칙. function isValidEmail(email: string): boolean {

주석에 반환 조건과 판정 기준을 못 박아 두면, 자동완성은 그 맥락을 그대로 물고 본문을 채웁니다. 반대로 주석 없이 빈 함수만 두면 이름만 보고 아무 구현이나 던집니다. 자동완성형에서는 원하는 결과를 코드 형태의 힌트로 미리 깔아 두는 것이 사실상의 프롬프트입니다.

채팅·편집형 — 맥락과 범위를 못 박는다

Cursor 같은 채팅편집형은 "이 함수 고쳐줘" 한마디로도 움직이지만, 그 한마디로는 어디까지 손댈지 도구가 알 수 없습니다. 핵심은 대상 파일·범위·건드리면 안 되는 것을 함께 주는 겁니다. 어떤 파일의 어느 함수인지, 무엇을 바꾸고 무엇은 유지할지 명시하면 엉뚱한 곳까지 수정되는 사고를 막습니다.

에이전트형 — 목표·제약·검증 기준을 함께 준다

Claude Code처럼 스스로 파일을 만들고 명령을 실행하는 에이전트형은 자율성이 높은 만큼, 방치하면 의도 밖으로 멀리 가 버립니다. 여기서 통하는 프롬프트는 세 덩어리를 갖춥니다. 목표(무엇을 완성해야 하는가), 제약(무엇은 건드리지 말고 어떤 규칙을 지켜라), 검증 기준(무엇이 통과 조건인가). 특히 검증 기준을 주면 에이전트가 스스로 테스트를 돌려 자기 결과를 점검합니다.

복붙해서 바로 쓰는 프롬프트 템플릿

아래 템플릿은 채팅편집형·에이전트형에 그대로 붙여 쓸 수 있습니다. 대괄호 부분만 본인 상황으로 바꾸면 됩니다.

리팩터링 요청

[파일 경로]의 [함수명]을 리팩터링해줘. 조건: (1) 외부에서 보이는 동작과 반환값은 기존과 완전히 동일하게 유지 (2) 중복 로직은 헬퍼로 추출 (3) 리팩터링 후 기존 동작을 검증하는 단위 테스트도 함께 추가 (4) 다른 파일은 건드리지 말 것.

"동작 유지"와 "테스트 추가"를 함께 거는 게 핵심입니다. 리팩터링은 겉보기 동작이 바뀌면 실패인데, 검증 테스트를 같이 요구하면 도구가 스스로 안전장치를 만듭니다.

버그 수정 요청

[증상: 무엇을 입력하면 무엇이 잘못 나오는지]. 기대 동작은 [원하는 결과]. 관련 파일은 [경로]로 추정돼. 먼저 원인을 진단해서 설명하고, 수정안을 제시한 뒤 내 확인을 받고 나서 코드를 바꿔줘.

버그는 "고쳐줘"보다 입력→실제 출력→기대 출력을 명시하는 게 압도적으로 효과적입니다. 원인 진단을 먼저 시키면 엉뚱한 곳을 성급히 고치는 걸 막을 수 있습니다.

신규 함수·기능 작성

[함수명] 함수를 작성해줘. 입력: [타입과 의미]. 처리: [핵심 규칙, 엣지 케이스 포함]. 출력: [타입과 형식]. 예외 상황([빈 값·범위 초과 등])일 때 동작도 정의해줘. 프로젝트 기존 코드 스타일을 따르고, 사용 예시 한 줄도 붙여줘.

입력·처리·출력을 나눠 적는 것만으로 결과물의 정확도가 크게 올라갑니다. 엣지 케이스를 미리 나열해 주면 나중에 터질 버그를 앞에서 막습니다.

에이전트에게 맡기는 다단계 작업

목표: [완성해야 할 기능]. 제약: 기존 공개 API 시그니처 변경 금지, [설정 파일·마이그레이션 등]은 건드리지 말 것, 커밋 메시지는 한국어로. 검증: 작업 후 [테스트 명령]을 실행해 모두 통과해야 하고, 실패하면 스스로 고쳐서 다시 돌려줘. 작업 시작 전에 계획부터 보여주고 내 승인을 받아.

에이전트형에서 가장 중요한 한 줄은 마지막 문장, **"계획부터 보여주고 승인을 받아"**입니다. 이 한마디가 뒤에서 설명할 안전 워크플로우의 출발점입니다.

에이전트형 안전 워크플로우

자율 에이전트는 강력한 만큼 통제 장치 없이 돌리면 위험합니다. 세 가지 습관만 지켜도 대부분의 사고를 예방할 수 있습니다.

계획을 먼저 확인한다

에이전트가 바로 코드를 쓰게 두지 말고, 무엇을 어떤 순서로 바꿀지 계획을 먼저 뽑게 하십시오. Claude Code의 Plan Mode처럼 계획 단계를 분리하는 기능이 있으면 적극 씁니다. 계획을 읽어 방향이 어긋났다면 이 시점에 바로잡는 게, 파일 수십 개가 바뀐 뒤에 되돌리는 것보다 훨씬 쌉니다.

Git 커밋을 자주 찍는다

에이전트에게 작업을 맡기기 전에 반드시 커밋해 깨끗한 상태를 만들어 두십시오. 그래야 결과가 마음에 안 들 때 git reset이나 git checkout 한 번으로 원점 복귀가 됩니다. 커밋되지 않은 작업물 위에 에이전트를 풀어 놓으면, 내 손으로 쓴 코드와 AI가 바꾼 코드가 뒤섞여 되돌리기가 지옥이 됩니다.

변경 diff를 반드시 리뷰한다

에이전트가 "완료했습니다"라고 해도 그대로 믿지 말고 git diff로 실제 변경을 한 줄씩 훑으십시오. 자동완성이 채운 몇 줄과 달리, 에이전트는 한 번에 수백 줄을 건드립니다. 통과한 테스트도 테스트가 허술하면 의미가 없으니, 사람이 눈으로 확인하는 이 마지막 관문을 건너뛰면 안 됩니다.

흔한 실수와 교정법

맥락 없이 "고쳐줘"만 던진다

가장 흔하고 가장 손해 보는 패턴입니다. 무엇이 어떻게 잘못됐는지, 기대 동작은 무엇인지 없이 "안 돼요, 고쳐주세요"만 던지면 도구는 추측으로 아무 데나 손댑니다. 최소한 입력·실제 결과·기대 결과 세 가지는 항상 붙이십시오.

범위를 안 정하고 자율에 맡긴다

"이 프로젝트 전체를 개선해줘" 같은 백지위임은 에이전트가 멀쩡한 코드까지 갈아엎게 만듭니다. 범위를 좁히고("이 한 파일만"), 건드리면 안 되는 경계를 명시하는("설정과 마이그레이션은 제외") 것만으로 사고 확률이 뚝 떨어집니다.

검증 없이 결과를 그대로 믿는다

AI가 짠 코드는 그럴싸해 보여도 미묘하게 틀릴 때가 많습니다. 테스트 실행, diff 리뷰, 실제 동작 확인 중 하나도 안 거치고 커밋하면 결국 나중에 더 큰 비용으로 돌아옵니다. "생성"보다 "검증"에 시간을 쓰는 쪽이 길게 보면 빠릅니다.

시리즈를 마치며

지금까지 여덟 장에 걸쳐 도구 지형도부터 개별 해부, 상황별 조합, 실전 프롬프트까지 훑었습니다. 한 가지만 남긴다면 이겁니다. 이 판은 반년마다 뒤집힙니다. Windsurf가 Devin Desktop으로 사라지고 Amazon Q가 단종 수순에 들어간 것처럼, 오늘의 1등이 내년에도 1등이라는 보장은 없습니다. 그러니 특정 도구 이름을 외우기보다 자동완성·채팅편집·에이전트라는 유형, 자동완성 품질·자율성·대형 코드베이스 이해·생태계라는 판단 축, 그리고 작업 성격에 맞춰 도구를 조합하는 감각을 손에 쥐십시오. 도구는 계속 바뀌어도 이 세 가지는 남습니다. 새 도구가 나와도 "이건 어떤 유형이고, 내 어떤 작업에 끼워 넣을까"만 물으면 됩니다. 더 많은 조합 아이디어는 AI 꿀조합에서, 다른 주제는 시리즈 목록에서 이어 가시길 바랍니다.