"내 코드를 리뷰해줘."라고 함수를 붙여넣으면, AI는 다음과 같이 깔끔한 한 단락으로 답변합니다. "이 코드는 좋아 보입니다! 에러 처리 (error handling)를 추가하고 변수 이름을 개선하는 것을 고려해 보세요." 감사합니다. 당신도 이미 알고 있던 내용입니다. 당신이 원했던 것은 루프의 오프 바이 원 (off-by-one) 오류와 14번 라인의 처리되지 않은 null (unhandled null)을 찾아내는 것이었습니다.

문제는 모델이 아닙니다. 바로 프롬프트 (prompt)입니다. "내 코드를 리뷰해줘"라는 말은 AI에게 역할 (role), 우선순위 (priorities), 그리고 출력 형식 (output format)을 지정해주지 않기 때문에, AI는 모호한 칭찬을 기본값으로 내놓게 됩니다. 해결책은 시니어 엔지니어가 리뷰어에게 브리핑하는 방식대로 프롬프트를 작성하는 것입니다. 즉, 당신이 누구인지, 무엇을 찾아야 하는지, 무엇을 무시해야 하는지, 그리고 어떻게 보고해야 하는지를 알려주는 것입니다.

아래는 그 원칙들과 제가 실제로 사용하는 몇 가지 정확한 프롬프트들입니다. 이것들을 복사해서 당신의 코드로 교체해 보세요. 피드백의 품질이 변하는 것을 확인할 수 있을 것입니다.

왜 구조가 길이보다 중요한가

좋은 리뷰 프롬프트는 네 가지 부분으로 구성됩니다:

1. 역할 + 맥락 (Role + context) — "당신은 시니어 백엔드 리뷰어입니다. 이 코드는 결제를 처리하며 프로덕션 (production) 환경에서 실행됩니다."
2. 체크할 항목 (What to check) — 우선순위에 따른 구체적인 목록.
3. 제약 사항 (Constraints) — 하지 말아야 할 것. 모든 사람이 건너뛰는 부분이지만, 불필요한 미사여구를 제거하는 핵심적인 부분입니다.
4. 출력 형식 (Output format) — 에세이가 아닌, 우선순위가 분류된 리스트를 받을 수 있도록 합니다.

"특정 라인을 지목할 수 없는 개선 사항은 제안하지 마세요"라는 제약 사항 하나만으로도 일반적인 노이즈의 약 절반을 제거할 수 있습니다. 모델은 더 이상 "에러 처리 (error handling) 개선을 고려해 보세요"라고 말할 수 없습니다. 대신 에러 처리가 실제로 누락된 라인을 찾아내거나, 아니면 침묵해야 합니다.

프롬프트 1: 우선순위 분류 리뷰 (The triaged review)

이것은 저의 기본 설정입니다. 우선순위 지정과 "차단 요소 우선 (blocking first)" 규칙 덕분에 중요한 사항이 사소한 지적 사항 (nitpicks) 아래에 묻히지 않습니다.

당신은 프로덕션 코드를 위한 diff를 리뷰하는 시니어 엔지니어입니다.

제공된 코드를 리뷰하세요. 다음 순서로 확인하십시오:
...

프롬프트 2: 적대적 "코드 깨뜨리기" 리뷰 (The adversarial "break it" review)

때로는 예의 바른 리뷰가 아니라, AI가 당신의 코드를 적극적으로 망가뜨리려고 시도하기를 원할 때가 있습니다. 이는 일반적인 리뷰가 그냥 지나치기 쉬운 엣지 케이스 (edge cases)를 잡아냅니다.

당신은 적대적인 QA 엔지니어입니다. 당신의 목표는 이 함수가 잘못 작동하거나, 충돌하거나, 잘못된 출력을 생성하게 만드는 입력값과 조건을 찾는 것입니다.

...

"그것을 재현할 수 있는 테스트를 제공해줘"라는 문구는 이 프롬프트의 가치를 증명하는 핵심입니다. 단순히 버그에 대해 듣는 것에 그치지 않고, 이를 확인할 수 있는 실패하는 테스트(failing test)를 직접 얻을 수 있기 때문입니다.

프롬프트 3: 보안 전용 패스 (The security-only pass)

코드가 인증 (auth), 결제 (payments), 또는 사용자 입력 (user input)을 다룰 때는, 일반적인 리뷰에 의존하여 보안 문제를 잡아내려 하기보다 보안 전용 패스를 실행하세요.

당신은 보안 감사관 (security auditor)입니다. 오직 보안 문제에 대해서만 이 코드를 리뷰하세요.
각 발견 사항을 다음 카테고리에 매핑하세요: 인젝션 (injection), 인증/인가 오류 (broken auth/authz), 민감한 데이터 노출 (sensitive data exposure), SSRF, 안전하지 않은 역직렬화 (insecure deserialization), 또는 입력 검증 누락 (missing input validation).
...

보안을 별도의 패스로 실행하는 것이 일반적인 리뷰에 통합하는 것보다 효과적입니다. 집중된 프롬프트는 모델이 명명 규칙 (naming), 구조 (structure), 보안 (security) 모두에 주의력을 분산시키지 않고 하나의 모드에 집중할 수 있게 해주기 때문입니다.

무엇이든 재사용할 수 있는 패턴

앞서 본 세 가지 프롬프트의 공통점을 살펴보세요: 역할 (role), 우선순위가 지정된 체크리스트 (prioritized checklist), 불필요한 내용을 배제하는 엄격한 제약 (constraint against fluff), 그리고 **고정된 출력 형식 (fixed output format)**입니다. 이와 동일한 골격은 디버깅 ("당신은 디버거입니다, 이론을 제시하기 전에 재현부터 하세요"), 리팩터링 ("동작을 보존하고, 한 번에 하나씩 변경하세요"), 테스트 작성 ("해피 패스 (happy path)가 아닌 엣지 케이스 (edge cases)를 목표로 하세요"), 그리고 SQL 리뷰 ("N+1 문제, 누락된 인덱스, 풀 스캔 (full scans)을 확인하세요")에도 적용할 수 있습니다.

이 골격을 내재화하고 나면, 영원히 "내 코드를 리뷰해줘"라고 타이핑하는 일은 사라질 것입니다. 대신 AI에게 정확히 어떤 작업을 수행하고 있는지 알려주는 프롬프트를 작성하게 될 것이며, AI는 더 이상 추측하지 않게 됩니다.

작은 숙제

위에서 다룬 분류된 리뷰 (triaged-review) 프롬프트를 가져와 이번 주에 작성한 함수에 실행해 보세요. 그다음 동일한 함수에 대해 단순하게 "내 코드를 리뷰해줘"라고 실행해 보세요. 그 차이를 확인하는 것이 이 포스트의 핵심이며, 지금 바로 무료로 시도해 볼 수 있습니다.

이 프롬프트들을 실제 워크플로에 연결하고 싶으신가요?

프롬프트는 단순히 채팅창에 떠 있는 상태가 아니라, 이름이 지정되고 반복 가능한 단계로 내장될 때 훨씬 더 강력해집니다. 제가 **Claude Code Agent OS**를 통해 구축한 것이 바로 이것입니다. 이 도구는 리뷰어(reviewer), 디버거(debugger), 테스트 작성자(test-writer), 보안 감사관(security-auditor) 등을 하나의 명령어로 호출할 수 있는 집중된 서브 에이전트(subagents)로 변환합니다. 각 에이전트는 위에서 소개한 프롬프트와 동일한 5단계의 불필요한 내용 제거 구조(역할, 체크리스트, 출력 형식, 제약 사항)를 따르며, 12개의 슬래시 명령어(/ commands)와 즉시 편집 가능한 CLAUDE.md 템플릿을 제공합니다. 현재 Claude Code와 함께 사용할 수 있으며, 프롬프트 자체는 ChatGPT, Cursor 또는 Copilot에도 바로 적용할 수 있습니다.

하지만 이 포스트에 소개된 세 가지 프롬프트는 여러분이 자유롭게 사용할 수 있으며, 오늘 바로 리뷰의 질을 높여줄 것입니다. 이 프롬프트들을 가져가서 여러분의 기술 스택(stack)에 맞게 조정하고, 더 나은 코드를 배포하세요.

어떤 리뷰 제약 사항(review constraint)이 여러분에게 가장 큰 차이를 만들어 주었나요? 저는 AI의 불필요한 미사여구(fluff)를 제거하는 문구들을 항상 수집하고 있습니다. 여러분의 노하우를 아래에 공유해 주세요.