작성자 주: 실전에서 검증된 25개의 Claude Code 코드 리뷰 프롬프트를 모았습니다. 보안 검토, 성능 분석, 아키텍처 리뷰, 버그 탐지, PR 리뷰 등 7가지 핵심 시나리오를 다루며, 프롬프트 작성 공식도 함께 제공합니다.
Claude Code는 자체적으로 /security-review 명령어와 코드 리뷰 멀티 에이전트 시스템을 갖추고 있지만, 기본 리뷰 결과는 종종 너무 장황하거나 사소한 것까지 모두 지적하곤 합니다. 좋은 리뷰 프롬프트는 테스트 케이스처럼 정확해야 합니다. 즉, 범위를 정의하고, 우선순위를 설정하며, 구체적인 행 번호와 수정 제안을 요구해야 합니다. 이 글에서는 보안 검토부터 아키텍처 리뷰까지 7가지 시나리오를 아우르는 25개의 코드 리뷰 프롬프트를 정리했으니, 바로 복사해서 사용해 보세요.
핵심 가치: 코드 리뷰에서 가장 빈번하게 발생하는 시나리오를 다루는 25개의 프롬프트와 함께, 프롬프트 작성 공식 및 좋은 예시와 나쁜 예시를 비교해 드립니다.
Review 프롬프트 작성 공식
훌륭한 Review 프롬프트는 마치 테스트 케이스처럼 정밀합니다. 반면, 좋지 않은 프롬프트는 모호한 Slack 메시지와 같죠.
5요소 공식
[역할] {언어/분야} 시니어 엔지니어의 관점에서
[범위] {파일/디렉토리/PR}의 {변경 내용}을 검토해줘
[중점] {보안/성능/로직/아키텍처}에 집중해서
[형식] 출력 형식: {번호 매긴 목록/표/인라인 주석}
[레벨] 심각도 표시: {Critical/High/Medium/Low}
| 요소 | 나쁜 예시 | 좋은 예시 |
|---|---|---|
| 역할 | (설정 없음) | "백엔드 시니어 엔지니어의 관점에서" |
| 범위 | "이 코드 좀 봐줘" | "src/auth/의 최근 git diff를 검토해줘" |
| 중점 | "피드백 좀 줘" | "SQL 인젝션과 인증 우회에 집중해서" |
| 형식 | (아무렇게나 출력) | "번호 매긴 목록, 각 항목에 [파일:라인 번호], 문제 설명, 수정 제안 포함" |
| 레벨 | (요구 사항 없음) | "Critical/High/Medium/Low로 심각도 표시" |
시나리오 1: 보안 검토 (프롬프트 4종)
보안 검토는 Code Review에서 우선순위가 가장 높은 작업입니다. Claude Code는 기본적으로 /security-review 명령어를 제공하지만, 커스텀 프롬프트를 사용하면 훨씬 더 깊이 있는 분석이 가능합니다.
프롬프트 #1: OWASP Top 10 종합 스캔
보안 감사 엔지니어의 관점에서 src/ 디렉토리 내 최근 수정된 모든 파일을 검토해줘.
OWASP Top 10 항목에 따라 다음을 체크해:
1. 인젝션 (SQL/NoSQL/명령어 인젝션)
2. 인증 취약점
3. 민감 데이터 노출
4. XXE
5. 접근 제어 취약점
6. 보안 설정 오류
7. XSS
8. 역직렬화
9. 취약한 컴포넌트 사용
10. 불충분한 로깅 및 모니터링
출력 형식: 번호 매긴 목록, 각 항목에 [파일:라인 번호] [심각도] [문제 설명] [수정 제안]을 포함해줘.
실제로 존재하는 문제만 보고하고, 이론적인 위험은 제외해줘.
프롬프트 #2: API 엔드포인트 보안 검토
모든 API 라우트 파일(routes/, controllers/)을 검토하고 다음 사항에 집중해줘:
- 인증 미들웨어가 누락된 엔드포인트가 있는지
- 파라미터에 대한 입력값 검증 및 살균(Sanitization)이 이루어졌는지
- 대량 할당(Mass Assignment) 위험이 있는지
- 속도 제한(Rate Limiting)이 설정되어 있는지
- 에러 응답이 내부 정보를 노출하고 있지는 않은지
출력 형식: [엔드포인트 경로 | 문제 | 심각도 | 수정 방안] 표로 정리해줘.
프롬프트 #3: 민감 정보 노출 탐지
프로젝트 전체를 스캔하여 다음 민감 정보가 하드코딩되어 있거나 실수로 노출되었는지 확인해줘:
- API 키, Secret, 토큰
- 데이터베이스 연결 문자열
- 개인 키 및 인증서
- 내부 IP 및 도메인
- 주석 내 비밀번호나 자격 증명
검사 범위: 소스 코드, 설정 파일, .env.example, docker-compose.yml, README
발견된 모든 항목의 파일 경로와 라인 번호를 표시해줘.
프롬프트 #4: 인증 및 인가 로직 검토
보안 전문가의 관점에서 인증 및 인가 관련 코드를 검토해줘:
1. JWT 토큰 검증 로직이 완전한지 (만료, 서명, 변조 여부)
2. 비밀번호 저장 시 안전한 해시(bcrypt/argon2)를 사용했는지
3. 세션 관리에 고정 세션 공격 위험이 있는지
4. CORS 설정이 너무 허용적인지
5. OAuth 콜백에서 state 파라미터를 검증하는지
Critical 및 High 등급의 문제만 보고하고, 수정 코드 예시를 포함해줘.
시나리오 2: 버그 탐지 (프롬프트 4개)
프롬프트 #5: 널 포인터 및 경계 조건
최근 수정된 파일을 검토하여 다음과 같은 잠재적 버그를 찾으세요:
- null/undefined 체크 없이 속성에 접근하는 곳
- 배열 인덱스 범위를 벗어난 접근
- 0으로 나누기 오류
- 빈 문자열 처리 미흡
- parseInt/parseFloat에서 NaN 처리 미흡
각 발견 사항에 대해 트리거 조건(어떤 입력이 충돌을 유발하는지)과 수정 코드를 제시하세요.
프롬프트 #6: 비동기 및 동시성 문제
프로젝트의 모든 비동기 코드(async/await, Promise, 콜백)를 검토하여 다음을 확인하세요:
- catch 오류 처리가 없는 Promise가 있는지
- 경쟁 상태(race condition)가 있는지
- 루프 내에서 await를 사용하여 직렬로 실행되는 부분(Promise.all을 사용해야 함)
- 리팩토링이 필요한 콜백 지옥(callback hell)이 있는지
- 트랜잭션이 롤백 처리를 올바르게 수행하는지
[파일:행 번호] [문제] [영향] [수정 방안] 형식으로 표시하세요.
프롬프트 #7: 논리 오류 탐색기
다음 함수의 비즈니스 로직을 주의 깊게 읽고 다음을 찾으세요:
- if/else 분기가 모든 경우를 커버하는지
- 루프 종료 조건이 올바른지
- 비교 연산자가 정확한지 (== vs ===, > vs >=)
- 변수 스코프가 올바른지
- 모든 경로에서 반환값이 정의되어 있는지
코드 스타일은 무시하고, 오직 논리적 정확성에만 집중하세요.
프롬프트 #8: 오류 처리 검토
프로젝트의 오류 처리 메커니즘을 검토하세요:
1. try/catch 블록이 일반적인 Error가 아닌 구체적인 예외를 포착하는지
2. catch 블록이 오류를 단순히 삼켜버리는지(빈 catch)
3. 오류가 상위 계층으로 올바르게 전파되는지
4. 사용자에게 노출되는 오류 메시지가 친절한지(내부 정보 노출 방지)
5. 주요 작업(결제, 데이터 변경)에 실패 시 롤백 메커니즘이 있는지
심각도 순으로 정렬하여 출력하세요.
시나리오 3: 성능 분석 (프롬프트 3개)
프롬프트 #9: 데이터베이스 쿼리 성능
모든 데이터베이스 쿼리 코드(models/, repositories/, ORM 호출)를 검토하여 다음을 확인하세요:
- N+1 쿼리 문제(루프 내 쿼리 실행)
- 인덱스가 누락된 쿼리 필드
- SELECT *를 구체적인 필드로 대체해야 하는지
- 대량 데이터 쿼리에 페이징 처리가 되어 있는지
- 캐시로 최적화할 수 있는 중복 쿼리가 있는지
각 문제의 성능 영향도를 추정(낮음/중간/높음)하고, 최적화된 코드를 제시하세요.
프롬프트 #10: 메모리 및 리소스 누수
프로젝트 내 발생 가능한 메모리 및 리소스 누수를 검토하세요:
- 컴포넌트 언마운트 시 이벤트 리스너가 제거되는지
- 타이머(setInterval/setTimeout)가 정리되는지
- 데이터베이스 연결이 올바르게 닫히는지
- 파일 핸들이 finally 블록에서 해제되는지
- 대형 배열/객체 사용 후 참조가 해제되는지
React 컴포넌트의 useEffect 정리 및 Node.js의 스트림 처리에 집중하세요.
프롬프트 #11: 알고리즘 복잡도 검토
최근 수정된 함수를 검토하여 시간 및 공간 복잡도를 분석하세요:
- O(n²) 이상의 복잡도를 최적화할 수 있는지
- 선형 검색을 해시 테이블로 대체할 수 있는 곳이 있는지
- 불필요한 깊은 복사(deep copy)가 있는지
- 문자열 연결 시 StringBuilder/join을 사용해야 하는지
- 정렬 시 적절한 알고리즘을 사용했는지
현재 복잡도 → 최적화 가능 복잡도 → 구체적인 최적화 방안 순으로 표시하세요.
시나리오 4: 아키텍처 리뷰 (프롬프트 4개)
프롬프트 #12: 의존성 및 결합도 분석
src/ 디렉토리의 모듈 의존 관계를 분석해 주세요:
1. 모듈 간 의존성 그래프를 그려주세요 (어떤 모듈이 어떤 모듈을 import 하는지)
2. 순환 의존성을 찾아주세요
3. 결합도가 가장 높은 모듈(다른 모듈에서 가장 많이 참조하는 모듈)을 찾아주세요
4. 인터페이스나 추상화를 통해 결합을 해제해야 할 의존 관계를 제안해 주세요
출력: 의존 관계 표 + 순환 의존성 목록 + 결합 해제 제안
프롬프트 #13: 계층형 아키텍처 준수 여부 확인
코드가 계층형 아키텍처 원칙을 따르고 있는지 확인해 주세요:
- Controller 계층에 비즈니스 로직이 포함되어 있나요? (라우팅과 파라미터 검증만 수행해야 함)
- Service 계층이 데이터베이스를 직접 조작하나요? (Repository를 통해야 함)
- Model/Entity 계층에 HTTP 관련 로직이 포함되어 있나요?
- 계층을 건너뛰는 호출이 있나요? (Controller가 Repository를 직접 호출하는 경우 등)
계층 원칙을 위반한 파일과 구체적인 코드 위치를 나열해 주세요.
프롬프트 #14: API 설계 리뷰
RESTful API 설계 모범 사례를 기준으로 모든 API 엔드포인트를 검토해 주세요:
- URL 명명 규칙이 REST 관례를 따르고 있나요? (복수 명사, 계층 관계)
- HTTP 메서드 사용이 올바른가요? (GET은 읽기 전용, POST는 생성, PUT은 업데이트, DELETE는 삭제)
- 응답 형식이 일관적인가요? (에러 코드, 페이징 형식, 시간 형식)
- API 버전 관리가 적절한가요?
- 통합 가능한 중복 엔드포인트가 있나요?
출력: 개선 제안 표 (현재 → 제안 → 이유)
프롬프트 #15: 기술 부채 평가
프로젝트의 기술 부채를 종합적으로 평가해 주세요:
1. 오래된 의존성 패키지 및 프레임워크 버전
2. 더 이상 사용되지 않는(deprecated) API 호출
3. 하드코딩된 설정 값 (환경 변수로 대체해야 함)
4. 복사-붙여넣기 된 중복 코드 블록
5. 단위 테스트가 누락된 핵심 모듈
6. 너무 복잡한 함수 (순환 복잡도 > 15)
수정 시급성에 따라 정렬해 주세요: 차단(즉시 수정 필요) > 높음 > 중간 > 낮음
시나리오 5: PR 리뷰 (프롬프트 4개)
프롬프트 #16: PR Diff 신속 검토
현재 브랜치와 main 브랜치의 diff를 검토하고, 시니어 엔지니어의 관점에서 평가해 주세요:
1. 이 PR의 목적은 무엇인가요? (diff를 통해 추론)
2. 변경 사항이 완전한가요? (누락된 파일이나 로직이 있는지)
3. 새로운 버그나 회귀(regression)가 발생했나요?
4. 테스트 커버리지가 충분한가요?
5. 불필요한 변경 사항이 있나요? (디버깅 코드, 포맷팅 노이즈 등)
High 및 Critical 수준의 문제만 보고해 주세요. 사소한 코드 스타일(nit-pick)은 지적하지 마세요.
프롬프트 #17: 하위 호환성 확인
현재 PR의 모든 변경 사항을 검토하여 하위 호환성을 해치는 변경이 있는지 확인해 주세요:
- 공개 API 인터페이스의 시그니처나 반환값이 변경되었나요?
- 데이터베이스 스키마에 파괴적인 변경(breaking change)이 있나요?
- 설정 파일 형식이 변경되었나요?
- 다른 모듈에서 사용 중인 함수가 삭제되었나요?
- 환경 변수의 이름이나 형식이 변경되었나요?
각 비호환 항목에 대해 영향 범위와 마이그레이션 방안을 평가해 주세요.
프롬프트 #18: 테스트 충분성 검토
현재 PR의 코드 변경 사항과 테스트 변경 사항을 비교해 주세요:
1. 새로 추가된 함수에 적절한 단위 테스트가 포함되었나요?
2. 수정된 로직에 맞춰 기존 테스트가 업데이트되었나요?
3. 경계 조건과 예외 경로에 대한 테스트 커버리지가 있나요?
4. 통합 테스트가 새로운 API 엔드포인트를 커버하나요?
5. 테스트 데이터가 합리적인가요? (무작위 123, abc 등이 아닌지)
누락된 테스트 케이스 제안: 함수명 | 누락된 테스트 시나리오 | 우선순위
프롬프트 #19: 커밋 품질 검토
현재 PR의 커밋 히스토리를 검토해 주세요:
1. 커밋 메시지가 변경 내용을 명확하게 설명하고 있나요?
2. 각 커밋이 원자적(atomic)인가요? (하나의 커밋은 하나의 목적만 수행)
3. squash(합치기)가 필요한 사소한 커밋이 있나요?
4. "fix typo", "wip" 등 정리해야 할 임시 커밋이 있나요?
5. 커밋 순서가 논리적인가요? (인프라 설정 후 비즈니스 로직 순서 등)
정리가 필요한 커밋과 최종적인 커밋 구조를 제안해 주세요.
시나리오 6: 가독성 (프롬프트 3개)
프롬프트 #20: 명명 규칙 검토
최근 수정된 파일의 모든 변수, 함수, 클래스 이름을 검토하세요:
- 의미가 모호한 이름이 있는가 (data, info, temp, res, obj 등)
- 과도하게 줄여 쓴 이름이 있는가 (usr → user, btn → button 등)
- 불리언(boolean) 변수명이 is/has/should로 시작하지 않는가
- 함수명이 동사로 시작하여 동작을 정확히 설명하는가
- 클래스명이 명사로 시작하여 역할을 정확히 설명하는가
잘못된 명명 규칙이 발견되면, 더 나은 대체 이름을 제안하세요.
프롬프트 #21: 주석 품질 검토
코드 내 주석의 품질을 검토하세요:
- "무엇(what)"을 설명하는 주석을 "왜(why)"를 설명하는 주석으로 바꿔야 하는가
- 코드와 일치하지 않는 오래된 주석이 있는가
- 함수 이름으로 추출해야 할 만큼 설명적인 주석이 있는가
- 복잡한 비즈니스 로직에 대한 설명 주석이 부족하지 않은가
- 공개 API에 JSDoc/docstring이 포함되어 있는가
너무 당연한 주석(예: "// 카운터 증가")은 추가하지 않도록 하세요.
프롬프트 #22: 함수 분리 제안
30줄이 넘는 모든 함수를 검토하여 분리할 필요가 있는지 평가하세요:
- 함수가 여러 가지 책임을 지고 있는가 (관련 없는 여러 작업을 수행하는가)
- 중첩 단계가 3단계 이상인가
- 매개변수가 4개 이상인가
- 추출 가능한 중복 로직이 있는가
구체적인 분리 방안을 제시하세요: 원본 함수 → 분리된 함수 목록 → 각 함수의 책임.
시나리오 7: 리팩토링 제안 (프롬프트 3개)
프롬프트 #23: DRY(중복 제거) 원칙 위반 탐지
프로젝트 내 중복 코드를 스캔하세요:
- 3줄 이상 반복되는 코드 블록을 찾으세요
- 로직은 비슷하지만 작성 방식이 다른 코드를 찾으세요
- 유틸리티 함수로 추출할 수 있는 공통 패턴을 찾으세요
각 중복 코드 그룹에 대해, 공통 함수로 추출할 수 있는 구체적인 구현 코드를 제시하세요.
프롬프트 #24: 디자인 패턴 최적화
디자인 패턴 전문가의 관점에서 코드를 검토하세요:
- 다수의 if/else나 switch 문을 전략 패턴으로 대체할 수 있는가
- 복잡한 객체 생성을 팩토리/빌더 패턴으로 개선할 수 있는가
- 반복되는 템플릿 코드를 템플릿 메서드 패턴으로 바꿀 수 있는가
- 다중 중첩 콜백을 책임 연쇄 패턴으로 바꿀 수 있는가
- 전역 상태 관리를 옵저버 패턴으로 관리할 수 있는가
패턴 도입으로 복잡성이 확실히 줄어들 때만 제안하세요. 과도한 설계는 지양합니다.
프롬프트 #25: 레거시 코드 현대화
프로젝트 내 레거시 코드를 검토하여 현대적인 문법으로 다시 작성할 부분을 찾으세요:
- var → const/let
- 콜백 함수 → async/await
- for 루프 → map/filter/reduce
- 문자열 연결 → 템플릿 리터럴
- require → import
- Class → 함수형 컴포넌트 + Hooks (React)
리팩토링 전후의 코드를 비교하고, 리팩토링 위험도(낮음/중간/높음)를 평가하세요.
🎯 사용 팁: 자주 사용하는 리뷰 프롬프트는
CLAUDE.md나.claude/skills/에 저장하여 팀 표준으로 활용하세요./loop명령어를 사용하면 보안 검토와 PR 리뷰를 자동화할 수 있습니다.
자동화된 리뷰 시스템을 API로 구축한다면, APIYI(apiyi.com)를 통해 Claude Opus 4.6을 20% 할인된 가격으로 연동해 보세요.
자주 묻는 질문(FAQ)
Q1: 기본 /code-review가 너무 장황해요. 어떻게 하죠?
프로젝트 루트 디렉토리에 REVIEW.md를 생성하거나 CLAUDE.md에 Review 규칙을 추가하여 Claude에게 무엇에 집중하고 무엇을 무시할지 명확히 지시하세요. 예를 들어: "Critical 및 High 레벨 문제만 보고할 것. 코드 스타일이나 명명 규칙에 대한 사소한 지적은 하지 말 것. 주석 추가를 제안하지 말 것." Claude Code는 매번 Review를 수행할 때마다 이 파일을 자동으로 읽습니다.
Q2: 프롬프트를 재사용 가능한 Skill로 저장하려면 어떻게 하나요?
.claude/skills/security-review/SKILL.md에 보안 검토 프롬프트를 저장하고 user-invocable: true로 설정하면 /security-review 슬래시 명령어로 등록됩니다. 이후에는 /security-review만 입력하면 바로 실행할 수 있어 매번 복사해서 붙여넣을 필요가 없습니다. 여러 프롬프트를 각각의 Skill로 저장할 수 있습니다.
Q3: PR Review를 GitHub 댓글로 자동 전송할 수 있나요?
네, 가능합니다. 두 가지 방법이 있습니다: 1) PR 댓글에 @claude review를 입력하면 Claude가 자동으로 diff를 분석하여 인라인 댓글 형태로 발견된 내용을 게시합니다. 2) /code-review --comment 명령어를 사용하면 Claude가 Review 결과를 PR 댓글로 게시합니다. Anthropic은 2026년 3월에 전문적인 Code Review 멀티 에이전트 시스템을 출시하여, 보안, 로직, 테스트 등 여러 관점에서 PR을 검토하도록 에이전트 그룹을 조정할 수 있습니다.
Q4: Review 프롬프트는 토큰을 얼마나 소모하나요?
검토 범위에 따라 다릅니다. 단일 파일 검토는 약 2,0005,000 토큰, 전체 프로젝트 보안 스캔은 10,00030,000 토큰 정도 소모됩니다. "모든 파일 스캔"으로 인한 토큰 낭비를 방지하기 위해 구체적인 파일/디렉토리 범위로 검토 대상을 제한하는 것이 좋습니다. APIYI(apiyi.com)를 통해 Claude Opus 4.6을 20% 할인된 가격으로 연동하면 Review 비용을 크게 절감할 수 있습니다.
요약
Claude Code Code Review 프롬프트의 핵심 포인트:
- 25가지 프롬프트로 7가지 시나리오 커버: 보안 검토(4), 버그 탐지(4), 성능 분석(3), 아키텍처 리뷰(4), PR Review(4), 가독성(3), 리팩토링 제안(3) — 바로 복사해서 사용하세요.
- 좋은 프롬프트를 위한 5요소 공식: 역할 + 범위 + 핵심 포인트 + 형식 + 심각도. Slack 메시지처럼 모호하게 작성하지 말고, 테스트 케이스처럼 정밀하게 작성하세요.
- 3단계 Review 체계: 내장 명령어(/security-review) → 커스텀 프롬프트(본문의 25가지) → /loop 자동화 지속 Review.
APIYI(apiyi.com)를 통해 Claude Opus 4.6 API를 20% 할인된 가격으로 연동하여 자동화된 Code Review 시스템을 구축하는 것을 추천합니다.
📚 참고 자료
-
Claude Code 코드 리뷰 공식 문서: 내장된 Review 기능에 대한 상세 설명
- 링크:
code.claude.com/docs/en/code-review - 설명: PR 리뷰, 멀티 에이전트 시스템 및 사용자 정의 방법 포함
- 링크:
-
Claude Code 보안 리뷰: Anthropic 공식 보안 검토 솔루션
- 링크:
github.com/anthropics/claude-code-security-review - 설명: /security-review 명령어의 전체 구현 내용 포함
- 링크:
-
Claude PR 리뷰 프롬프트 7가지: 커뮤니티에서 검증된 리뷰 프롬프트
- 링크:
rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026 - 설명: PR 검토를 위한 구조화된 프롬프트 템플릿 포함
- 링크:
-
APIYI 문서 센터: Claude Opus 4.6 API 20% 할인 연동
- 링크:
docs.apiyi.com - 설명: 자동화된 리뷰 시스템 구축을 위한 최적의 API 솔루션
- 링크:
저자: APIYI 기술팀
기술 교류: 댓글로 자유롭게 의견을 나눠주세요. 더 많은 자료는 APIYI docs.apiyi.com 문서 센터에서 확인하실 수 있습니다.
