시니어 코드 리뷰어 프롬프트 — 버그·성능·엣지케이스 발견
기본 AI 코드 리뷰는 스타일 지적의 산에 진짜 버그가 묻혀 쓸모가 없다. 이 프롬프트는 심각도 트리아지를 강제하고, 엄격한 테크리드 리뷰를 통과할 항목만 보고하게 하며, 정확한 행 번호를 인용해 각 지적을 초 단위로 검증할 수 있게 한다.
당신은 시니어 스태프 엔지니어로서 아래 diff를 리뷰합니다. 목표는 엄격한 테크리드 리뷰를 실제로 통과할 지적을 잡아내는 것입니다 — 린트 노이즈가 아닌. 리뷰 규칙: 1. 모든 지적을 BLOCKER / MAJOR / MINOR / NIT 중 하나로 분류하세요. 2. 기본적으로 BLOCKER와 MAJOR만 출력. 명시 요청이 없으면 MINOR와 NIT는 억제. 3. 각 지적은 정확한 파일 경로 + 행 번호 범위를 인용하고, (a) 무엇이 잘못됐는지, (b) 프로덕션의 실패 모드, (c) 권장 수정을 순서대로 설명. 4. 80% 미만의 확신도라면 [low-confidence] 표기 + 검증에 필요한 추가 컨텍스트 명시. 5. 마지막에 한 단락 총평: ship-it / ship-with-followups / do-not-ship. 다음은 지적하지 마세요: - 명명 선호 (실제 오독을 유발하지 않는 한). - 포매터가 있는 경우의 포맷·공백. - 측정된 핫패스에 연결할 수 없는 가설적 최적화. - 코드베이스 다른 곳에서 이미 사용 중인 패턴 (스타일 일관성이지 버그 아님). 리뷰 대상 diff: [여기에 unified diff 또는 파일 본문을 붙여넣으세요]
사용해야 할 시점
- 비자명 PR 머지 전 — diff를 본 프롬프트에 통과시켜 두 번째 시선으로 보고 싶은 항목을 드러낸다.
- 본인 코드 셀프 리뷰 — 인간 리뷰 요청 전에 통과시키면 부끄러운 단순 실수를 잡을 수 있다.
- 낯선 코드베이스 온보딩 — 함수 + 프롬프트를 붙여넣어 변경 전에 리스크를 파악.
모델별 팁
- claude
- Claude (Sonnet 4.6 또는 Opus 4.7)가 가장 신중한 트리아지를 반환. diff를 코드 블록으로 붙여넣으면 PR 전체도 처리.
- chatgpt
- GPT-5 / GPT-4o는 스타일 지적에 적극적. 위의 'MINOR/NIT 억제' 규칙으로 궤도 수정됨.
- cursor
- Cursor에서는 .cursorrules 항목으로 저장하거나 composer에 붙여넣기. @file 참조와 잘 어울림.
출력 예시
BLOCKER: src/auth/session.ts:42-58 - what: 세션 토큰 비교가 ===이며 상수 시간 비교가 아님. - failure mode: 원격 로그인에서 타이밍 공격에 노출 가능. - fix: crypto.timingSafeEqual()로 버퍼 쌍 비교로 변경. MAJOR: src/auth/session.ts:73 [low-confidence] - what: 리프레시 토큰이 localStorage에 기록됨. - failure mode: 비정제 사용자 콘텐츠가 페이지에 도달하면 XSS로 추출 위험. - fix: 클라이언트가 직접 읽지 않으면 httpOnly 쿠키로 이동. (low-confidence: 프론트가 이 토큰을 어떻게 사용하는지 보이지 않음.) Summary: ship-with-followups. 상수 시간 비교 수정은 머지 전 필수, 저장 위치 건은 본 PR과 별개로 follow-up issue 가치 있음.
작동 원리
왜 대부분의 AI 코드 리뷰는 쓸모없는가
기본적으로 언어 모델은 코드 리뷰 작업에서 '친절한 주니어' 페르소나로 흐른다. 명명에 너무 많이 코멘트하고, 멀쩡한 코드에 '클린 코드' 리라이트를 제안하고, 진짜 버그 하나를 무시해야 할 제안 더미에 묻어버린다. 신호 대 잡음비가 워크플로우를 죽인다 — 대부분의 팀이 일주일 안에 사용을 중단한다.
위 프롬프트는 세 가지를 뒤집는다: 심각도 트리아지로 사소한 문제를 명시적으로 억제, 행 번호를 요구해 각 지적을 초 단위로 검증 가능하게, 신뢰도 플래그로 전체 파일을 읽지 않고도 신뢰할 지적을 판단 가능하게.
CI와의 결합
PR 워크플로우의 '세컨드 오피니언' 단계로 사용 — 게이팅 체크가 아닌. 모델은 여전히 환각을 일으킨다, 특히 파일 간 불변 조건이나 붙여넣지 않은 프레임워크 관습에 의존하는 코드에서. 출력은 '기계적으로 수정할 항목 리스트'가 아닌 '검증할 항목 리스트'로 다룰 것.
CI에 넣고 싶다면 JSON 출력으로 변경 (프롬프트 수정: 'severity, path, lineStart, lineEnd, what, fix, confidence 필드를 가진 JSON 배열 반환'). BLOCKER/MAJOR만 묶어 PR에 단일 코멘트로 게시, 'AI 어시스트 — 행동 전 검증' 헤더 명시.
팀에 맞춘 조정
diff 위에 'Codebase context' 섹션 추가 — 스택, 테스트 관습, 비자명 불변 조건(예: '모든 DB 쓰기는 src/db/withTx 경유, raw client 금지')을 5-10줄로 기술. 그렇지 않으면 모델이 코드베이스 고유 관습을 놓친다.
팀 특유의 약점(특정 잡 러너의 레이스, 특정 서비스의 N+1 쿼리)이 있으면 'Watch especially for: …' 행 추가. 모델이 그 버그 클래스를 가중치 높게 보고 존재 시 더 잘 표시한다.
자주 묻는 질문
›비공개 소스 코드에 사용해도 되나요?
가능하지만 고용주 정책을 먼저 확인하세요. 프롬프트 자체는 무해하며, 핵심은 사용 모델에 코드를 붙여넣어도 되는지입니다. Claude와 ChatGPT 엔터프라이즈는 일반적으로 입력으로 학습하지 않으며, 컨슈머 플랜은 확인 필요.
›왜 MINOR와 NIT를 억제하나요?
실무에서 리뷰 피로를 만들기 때문입니다. '이 부분은 함수 추출 고려'를 세 번째 보면 더는 읽지 않게 됩니다. 억제하면 BLOCKER/MAJOR 신호가 날카롭게 유지됩니다. 깊이 보고 싶을 때만 'show all findings including MINOR and NIT'로 토글하세요.
›diff 길이는 어디까지?
Claude Sonnet/Opus와 GPT-5는 5만+ 토큰 diff를 무리 없이 처리합니다. 매우 큰 PR은 디렉터리 단위(src/auth → src/billing)로 분할하면 모델이 각 서브시스템을 독립 사고할 수 있어 정확도가 오릅니다.
›보안 전용 리뷰는?
본 프롬프트는 명백한 암호·저장·SSRF 계열 문제를 잡지만, 인증·결제 코드의 보안 리뷰 대체가 아닙니다. 그 경로에는 본 프롬프트 + 전용 보안 리뷰 프롬프트(별도 공개 예정)를 함께 사용하세요.
›여러 파일 교차 리뷰?
가능합니다 — 모든 파일을 포함한 diff를 한 번에 붙여넣으세요. 한 번의 붙여넣기 내 교차 불변 조건은 합리적으로 처리됩니다. 여러 PR을 가로지르는 문제(예: '다른 곳의 피처 플래그 게이팅과 일치하는가?')는 그 파일들의 대표 발췌를 함께 포함하세요.
›[low-confidence] 지적은 신뢰해도 되나요?
'행동 전 조사'로 다루세요. 저신뢰 지적의 절반은 진짜이지만 모델이 검증하지 못한 것이고, 나머지 절반은 오독입니다. 플래그는 정직한 신호이지 무시할 이유가 아닙니다.
›왜 실패 모드를 쓰게 하나요?
'여기 잘못됨'만으로는 'unicode 입력에서 크래시'를 알 수 없기 때문. 실패 모드 행이 우선순위를 알려줍니다 — 100만에 1번의 엣지케이스를 막는 수정과 매일의 프로덕션 사고를 막는 수정은 다릅니다.
›Cursor에서 어떻게 사용?
리포 루트의 .cursorrules에 저장하거나 composer에 붙여넣고 @file 참조와 결합. Cursor가 해당 프로젝트에 규칙을 지속 적용합니다.
관련 계산기
관련 프롬프트
최종 수정: