Claude Code 리뷰는 실제로 어떻게 작동할까: 디프, 훅, 그리고 에이전트가 잡아내는 것들
복잡하게 생각할 필요 없이, 디프만 보고도 시니어 엔지니어급 에이전틱 리뷰를 그대로 실행하세요.
Claude Code Review: 에이전틱 PR 리뷰를 위한 실전 가이드
Claude Code는 숙련된 시니어 엔지니어가 하는 방식으로 pull request나 로컬 diff를 리뷰할 수 있습니다 — 변경된 파일을 읽고, 호출 지점을 추적하고, 테스트를 확인하고, 심각도별로 정리된 결과와 수정 제안을 반환합니다. 이 가이드는 구체적으로 Claude Code(Anthropic의 에이전틱 CLI 도구)를 코드 리뷰에 활용하는 방법을 다룹니다: 어떻게 실행하는지, 어떻게 프롬프트를 잘 작성하는지, 모든 커밋이나 PR마다 자동화하는 방법, 그리고 팀 파이프라인에 연결하는 방법까지.
"Claude Code 리뷰"가 실제로 의미하는 것
사람들이 "Claude 코드 리뷰"라고 부르는 것에는 매우 다른 두 가지가 있습니다. 첫 번째는 채팅 인터페이스에서 Claude에게 붙여넣은 코드 스니펫을 봐달라고 요청하는 것입니다. 두 번째는 — 이 가이드의 주제입니다 — 실제 리포지토리 안에서 실제 diff나 pull request에 대해 Anthropic의 에이전틱 CLI인 Claude Code를 실행하는 것입니다.
이 차이는 매우 중요합니다. Claude Code가 diff를 리뷰할 때, 붙여넣은 발췌문에 대해 단독으로 추론하는 것이 아닙니다. 이는 파일을 열고, import를 따라가고, CLAUDE.md 프로젝트 지침을 읽고, 인접한 테스트를 확인하며, 단 하나의 결과라도 내놓기 전에 변경 사항의 전체 맥락을 이해할 수 있는 자율 에이전트입니다. 이러한 파일 간 인지 능력이 결과물을 일반적인 수준이 아니라 진짜로 유용하게 만드는 요소입니다.
Claude Code는 로컬에 설치하는 CLI(npm install -g @anthropic-ai/claude-code)로, 또는 클라우드 샌드박스에서 실행되는 에이전트로 사용할 수 있습니다 — 두 방식 모두 뒤에서 더 자세히 다룹니다. Anthropic의 공식 문서에서 설치와 초기 설정을 확인할 수 있습니다.
/review 워크플로우 단계별 설명
Claude Code에는 바로 이 작업을 위해 설계된 /review 슬래시 커맨드가 내장되어 있습니다. 다음은 diff부터 실행 가능한 결과물까지 전체 워크플로우입니다.
1단계 — Claude Code에게 diff를 알려주기
리뷰하고 싶은 변경 사항을 전달하는 방법은 여러 가지가 있습니다.
스테이징된 변경 사항 (/review 커맨드):
/reviewClaude Code 세션 안에서 /review 슬래시 커맨드는 변경 사항에 대한 리뷰를 시작합니다. 이는 가장 흔한 로컬 워크플로우입니다: 작업을 스테이징하고, /review를 실행하고, 커밋하기 전에 결과를 확인합니다. (정확한 커맨드 동작은 계속 발전하므로 최신 문법은 Anthropic의 Claude Code 문서를 확인하세요.)
특정 git 범위:
에이전트에게 자연어로 요청할 수도 있습니다 — 예를 들어 "main과 이 브랜치 사이의 diff를 리뷰하고 버그나 회귀가 있으면 알려줘." Claude Code는 직접 git 명령을 실행할 수 있으므로, 지정한 범위의 diff를 생성해 리뷰합니다. 이는 PR을 열기 전에 피처 브랜치를 리뷰할 때 유용하며, 정확한 플래그 문법에 의존하지 않아도 됩니다.
GitHub pull request URL:
프로젝트에 GitHub CLI가 설정되어 있다면, Claude Code는 PR diff를 직접 가져올 수 있습니다. 프롬프트에 PR URL이나 번호를 제공하면, 에이전트는 gh를 사용해 diff와 PR 설명을 함께 가져오는데, 이는 코드와 함께 의도 맥락까지 제공해줍니다.
2단계 — 컨텍스트 로딩
결과를 내놓기 전에, Claude Code는 diff를 제대로 평가하기 위해 필요한 컨텍스트를 읽습니다:
CLAUDE.md— 프로젝트의 지침 파일로, 리뷰 시 집중할 영역, 금지된 패턴, 아키텍처 규칙, 팀 컨벤션 등을 정의할 수 있습니다. 이는 에이전트가 무엇에 주의를 기울일지 커스터마이징하는 가장 강력한 수단입니다.- 임포트된 모듈과 호출자 — 변경된 함수가 열 군데에서 호출된다면, 에이전트는 해당 호출 지점들을 읽어 변경 사항이 하위 호환되는지 확인합니다.
- 기존 테스트 — 변경된 코드의 의도된 계약을 이해하고, 새로운 로직에 커버리지가 부족한 경우를 알아채기 위해 테스트 파일을 읽습니다.
- 설정 파일 —
eslint,tsconfig,pyproject.toml등의 파일은 에이전트가 CI에서 이미 강제되고 있는 린팅 규칙을 이해하도록 도와, 이미 여러분의 툴링이 잡아내는 사항을 중복해서 지적하지 않게 합니다.
3단계 — 분석
Claude Code의 분석은 여러 차원을 동시에 다룹니다:
- 정확성 — 로직 버그, off-by-one 오류, null 역참조, 잘못된 알고리즘 가정
- 보안 — 인젝션 위험, 노출된 credential, 안전하지 않은 역직렬화, 누락된 인가 검사
- 신뢰성 — 누락된 에러 처리, 처리되지 않은 promise rejection, 잡아내지 못한 엣지 케이스
- 유지보수성 — 중복된 로직, 불명확한 네이밍, 비직관적인 동작에 대한 문서 누락
- 테스트 커버리지 — 대응하는 테스트 없이 추가된 코드 경로
에이전트는 단순히 라인을 지적하는 데 그치지 않고, 그 결과가 왜 중요한지, 그리고 그대로 배포될 경우 어떤 영향이 있을지를 설명합니다.
4단계 — 구조화된 결과
출력은 각각 다음을 포함하는 결과 목록입니다:
- 심각도 라벨 (일반적으로: critical / warning / suggestion)
- 파일 및 라인 참조
- 문제에 대한 평이한 언어로 된 설명
- 제안된 수정안 — 종종 바로 적용 가능한 코드 스니펫
기본적으로 결과는 터미널에 출력됩니다. 팀 사용을 위해서는 이를 리다이렉트할 수 있습니다: 파일로 파이프하거나, gh pr comment를 통해 PR 댓글로 게시하거나, 훅을 사용해 공유 리뷰 로그에 기록할 수 있습니다.
Claude Code 리뷰는 구조화된 파이프라인을 따릅니다 — diff 입력부터 컨텍스트 로딩과 분석을 거쳐, 순위가 매겨진 결과와 수정 제안까지, 훅을 통해 완전한 자동화가 가능합니다.
실전 예제: 실제 diff, 실제 리뷰
이를 구체적으로 보여주기 위해, 최소한의 Python diff와 Claude Code 리뷰가 드러내는 내용을 살펴보겠습니다.
diff:
# Before
def get_user(user_id):
result = db.query(f"SELECT * FROM users WHERE id = {user_id}")
return result[0]
# After (in PR)
def get_user(user_id):
result = db.query(f"SELECT * FROM users WHERE id = {user_id}")
if result:
return result[0]
return NonePR 작성자가 고쳤다고 생각한 것: 사용자를 찾지 못했을 때 발생하는 KeyError.
Claude Code가 리뷰에서 드러낸 것:
-
Critical — SQL Injection (2번째 줄): f-string이
user_id를 쿼리에 직접 보간합니다.1; DROP TABLE users;--와 같은 값이 실행될 수 있습니다. 수정: 파라미터화된 쿼리를 사용하세요 —db.query("SELECT * FROM users WHERE id = ?", (user_id,)). -
Warning — 암묵적인
None반환 전파:None을 확인하지 않는get_user의 호출자들은 이제 멀리 떨어진 곳에서 실패하게 됩니다. 사용자 객체가 항상 반환된다고 가정하는 세 곳의 호출 지점(파일별로 나열됨)을 검토하세요. -
Suggestion — 타입 어노테이션 누락: IDE와 타입 체커가
None케이스를 호출 지점에서 자동으로 잡아낼 수 있도록 반환 타입은Optional[User]이어야 합니다. -
Suggestion — 테스트가 추가되었지만 불완전함: 새로 추가된 테스트
test_get_user_not_found는None이 반환되는지만 확인하며,user_id가0이거나 정수가 아닌 경우의 동작은 검증하지 않습니다.
원래 작성자는 KeyError를 고쳤지만 조용한 None 전파 위험을 새로 도입했고, 기존에 있던 SQL 인젝션은 알아차리지 못했습니다. Claude Code는 둘 다 잡아냈습니다 — diff만이 아니라 호출 지점을 읽었기 때문에 가능했습니다.
더 나은 리뷰를 위해 Claude Code에게 프롬프트하기
리뷰의 품질은 에이전트에게 제공하는 컨텍스트의 품질에 정비례합니다. 다음의 프롬프트와 기법들은 지속적으로 더 나은 결과를 만들어냅니다.
CLAUDE.md를 사용해 상시 지침 설정하기
가장 큰 지렛대는 프로젝트의 CLAUDE.md 파일에 있습니다. ## Review Guidelines 섹션을 추가하세요:
## Review Guidelines
- We use parameterized queries everywhere. Flag any string interpolation in SQL.
- All public functions must have return-type annotations (Python) or JSDoc (JS).
- Security findings should always be severity: critical, not warning.
- We prefer explicit error returns over exceptions in the data layer.
- Do not flag import ordering — Black handles that automatically.이는 에이전트에게 한 번 지시하는 것으로, 프로젝트 내의 모든 리뷰가 다시 프롬프트할 필요 없이 이 규칙들을 상속받게 합니다.
프롬프트에 의도 제공하기
대화형으로 리뷰를 요청할 때, 에이전트에게 해당 PR이 무엇을 달성하려는지 알려주세요:
/review This PR migrates our auth flow from JWT to session cookies. Focus on
session fixation, secure cookie attributes, and any places we might be leaking
the old JWT validation logic.의도 맥락을 제공하면 Claude Code는 모든 차원에 걸친 균일한 체크리스트를 생성하는 대신 관련성 높은 결과의 우선순위를 정할 수 있습니다.
먼저 심각도만 확인하는 패스 요청하기
큰 diff의 경우, 두 단계 접근 방식이 효율적입니다:
/review Pass 1: list only critical and warning severity findings with file+line.
No suggestions yet.그런 다음, critical 목록을 확보한 후 특정 결과에 대한 수정 세부사항을 요청하세요. 이렇게 하면 200줄짜리 리뷰 결과에서 중요한 버그가 스타일 제안 사이에 묻히는 문제를 피할 수 있습니다.
이해 여부 확인 요청하기
복잡한 변경의 경우:
Before reviewing, summarize what this diff is trying to do in two sentences,
then proceed with the review.요약이 잘못되었다면, 에이전트가 diff를 잘못 이해했다는 것을 알 수 있으므로 잘못된 결과에 시간을 낭비하기 전에 바로잡을 수 있습니다.
훅을 이용한 리뷰 자동화
/review를 수동으로 실행하는 것도 유용하지만, 진짜 생산성 향상은 리뷰를 자동으로 만드는 데 있습니다 — 사람이 기억하지 않아도 모든 커밋이나 열린 PR마다 리뷰가 트리거되도록 하는 것입니다. Claude Code의 훅 시스템이 이를 가능하게 합니다. (훅 시스템은 Claude Code 훅 가이드에서 심도 있게 다루므로 — 이 섹션은 리뷰 사용 사례에만 초점을 맞춥니다.)
모든 커밋마다 자동 리뷰
프로젝트의 .claude/settings.json에 Stop 훅을 추가하세요:
{
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "claude -p 'Review the diff from the last commit (git diff HEAD~1 HEAD) and list any bugs, security issues, or regressions.'"
}
]
}
]
}
}이렇게 설정하면 Claude Code가 작업을 완료할 때마다(커밋으로 끝나는 코딩 작업 포함) 훅이 실행되어 결과 diff를 리뷰합니다. 커밋이 완료된 직후 터미널에 결과가 나타납니다.
PR이 열릴 때 자동 리뷰
CI 통합을 위해서는, GitHub Actions job 안에서 Claude Code를 headless 모드(claude -p "<prompt>")로 실행하고 결과를 PR 댓글로 게시하세요. 아래 패턴은 예시용입니다 — Anthropic은 공식 Claude Code GitHub Action도 배포하고 있으므로, 플래그를 그대로 베끼기보다는 Claude Code 문서에서 현재 권장되는 CI 설정을 확인하세요:
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install Claude Code
run: npm install -g @anthropic-ai/claude-code
- name: Run review
run: |
claude -p "Review the diff between origin/${{ github.base_ref }} and HEAD. \
List bugs, security issues, and regressions, ranked by severity." > review.md
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
- name: Post review as PR comment
run: gh pr comment ${{ github.event.number }} --body-file review.md
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}이는 모든 push마다 Claude Code의 결과를 PR 댓글로 자동 게시합니다. 이후 사람 리뷰어들은 에이전트가 이미 찾아낸 사항에 시간을 쓰는 대신, Claude Code가 잡아내지 못하는 판단이 필요한 사항에 집중할 수 있습니다.
Claude Code 리뷰가 잡아내는 것 — 그리고 놓치는 것
역량의 범위를 명확히 인식하는 것이 중요합니다. AI 리뷰는 특정 유형의 결과에 대해서는 진짜로 강력하지만, 다른 유형에 대해서는 확실히 부족합니다.
Claude Code는 기계적인 정확성, 보안 패턴, 일관성 부분에 뛰어난 반면 — 제품에 대한 판단, 새로운 위협, 규정 준수 승인은 여전히 사람의 책임으로 남아 있습니다.
Claude Code가 확실하게 잡아내는 것:
- diff와 그 즉각적인 맥락에서 보이는 off-by-one 오류, null/undefined 역참조, 타입 불일치
- 알려진 보안 패턴: SQL 인젝션, XSS, CSRF 결함, 안전하지 않은 직접 객체 참조, 입력 검증 누락, 코드 내 secret
CLAUDE.md와 설정 파일에 정의된 규칙을 위반하는 스타일 및 컨벤션 위반- 중복 로직 — 에이전트의 파일 간 인지 능력 덕분에, 방금 추가한 함수가 두 디렉토리 떨어진 유틸리티 모듈에 이미 존재한다는 것을 알아챕니다
- 누락된 에러 처리 — 처리되지 않은 promise rejection, 텅 빈
except절, 호출자가 예상하지 못한 상태에서None이나undefined를 반환할 수 있는 함수 - diff에 추가된 특정 코드 경로에 대한 테스트 커버리지 부족
Claude Code가 사람의 판단을 대체하지 못하는 것:
- 제품 및 요구사항 결정. 기능이 존재해야 하는지, UX가 타당한지, API 계약이 올바른 추상화인지 — 이는 어떤 에이전트도 갖지 못한 비즈니스 맥락을 필요로 합니다.
- 새로운 보안 위협. 에이전트는 알려진 취약점 클래스는 알고 있지만, 여러분 애플리케이션의 배포 환경이나 비즈니스 로직에 특화된 위협 모델을 만들어내지는 못합니다.
- 대규모 성능. 정적 분석은 프로파일러 출력, 부하 테스트 결과, 실제 트래픽 패턴에 대한 이해를 대체할 수 없습니다.
- 규제 준수. GDPR, HIPAA, PCI-DSS 및 이와 유사한 것들은 사람의 승인과 종종 법률 검토를 필요로 합니다. AI 리뷰는 이를 대체할 수 없습니다.
- 팀 역학과 아키텍처 거버넌스. "이것이 이 모듈에 속하는가?" 혹은 "이 의존성을 받아들여야 하는가?" 같은 질문은 조직적 맥락을 필요로 합니다.
건전한 프레이밍은 이렇습니다: Claude Code 리뷰는 코드 리뷰의 지루한 부분 — 기계적인 오류를 잡고, 컨벤션을 강제하고, 알려진 나쁜 패턴을 지적하는 것 — 을 제거해줌으로써, 여러분의 사람 리뷰어들이 실제로 사람의 판단이 필요한 영역에 한정된 시간을 쓸 수 있게 합니다.
Claude Code 리뷰를 팀 파이프라인에 통합하기
팀이 에이전틱 리뷰를 지속적으로 실제로 사용하게 만들려면, 이를 선택적인 추가 요소가 아니라 워크플로우의 필수 부분으로 다뤄야 합니다.
3단계 모델
잘 작동하는 팀 파이프라인은 세 개의 레이어로 구성됩니다:
- 로컬 pre-commit — 개발자가 push하기 전에
/review를 실행합니다. 위에서 설명한 훅 설정이 이를 자동화합니다. 이 레이어의 결과는 수정하기 가장 저렴합니다. - CI 게이트 — GitHub Actions 워크플로우가 사람 리뷰어가 배정되기 전에 Claude Code의 결과를 PR 댓글로 게시합니다. 사람 리뷰어는 CI 리뷰를 통과한(critical 결과가 없는) 이후에만 배정됩니다.
- 사람 리뷰의 집중 — 사람 리뷰어들은 Claude Code의 댓글을 트리아지 가이드로 활용합니다. 그들의 역할은 판단이 필요한 항목 — 아키텍처 적합성, 제품 정확성, 성능 트레이드오프 — 를 평가하는 것이지, 오타를 찾기 위해 모든 줄을 다시 읽는 것이 아닙니다.
CLAUDE.md 컨벤션 공유하기
여러분의 CLAUDE.md는 에이전트의 리뷰 동작을 위한 설정 레이어입니다. 이를 코드처럼 다루세요: 커밋하고, 버전 관리하고, PR에서 변경 사항을 리뷰하세요. 팀이 특정 패턴(린터가 있기 때문에)에 대해 Claude Code가 더 이상 지적하지 않기로 합의하면, CLAUDE.md를 업데이트하고 그 변경 사항은 앞으로의 모든 리뷰에 적용됩니다.
심각도 임계값 조정하기
팀들은 초기에 기본 심각도 조정이 너무 시끄럽다고 느끼는 경우가 많습니다. CLAUDE.md에 명시적인 지침을 추가해 이를 제어하세요:
## Review Severity Rules
- Only flag console.log as a warning if it is in a non-test, non-debug file.
- Import ordering is never a finding; Prettier handles it.
- Treat any hardcoded credential as critical regardless of context.
- Performance suggestions are informational only unless they affect O(n²) loops.몇 주간 사용한 후, 대부분의 팀은 에이전트의 주의가 자신들의 코드베이스에서 실제로 중요한 패턴에 맞춰지면서 노이즈 수준이 크게 줄어드는 것을 발견합니다.
거짓 양성(False Positive) 처리하기
Claude Code는 가끔 무언가를 잘못 지적할 수 있습니다. 올바른 대응은 리뷰 전체를 무시하는 것이 아니라, 해당 패턴을 처리하는 프로젝트별 지침을 CLAUDE.md에 추가하는 것입니다. 시간이 지나면서 이는 여러분 팀의 실제 기준을 반영하는, 점점 더 정확하고 프로젝트에 특화된 리뷰 설정을 만들어냅니다.
로컬 설치 없이 Claude Code 리뷰 실행하기
지금까지 설명한 모든 내용은 Claude Code가 터미널에 설치되어 실행 중이라는 것을 전제로 합니다. 많은 팀에게 — 특히 잠긴 회사 컴퓨터, WSL이 없는 Windows 환경, 또는 브라우저 탭에서 리뷰하고 싶은 개발자들에게 — 로컬 설치는 마찰 지점입니다.
Happycapy는 브라우저 안에서 직접 안전한 클라우드 샌드박스에서 Claude Code를 실행합니다. 아무것도 설치하지 않고도 파일 간 컨텍스트 로딩, CLAUDE.md 지원, /review 커맨드를 포함한 완전한 에이전틱 리뷰 기능을 사용할 수 있습니다. 이는 특히 다음과 같은 경우에 유용합니다:
- 브랜치를 로컬로 pull하지 않고 브라우저에서 pull request에 대한 코드 리뷰하기
- 로컬 설치를 배포하기 전에 공유되고 일관된 환경을 원하는 Claude Code 리뷰에 온보딩하는 팀들
- 전역 npm 패키지 설치에 IT 승인이 필요한 잠긴 컴퓨터
- 전체 리포지토리를 클론하지 않고도 에이전트의 컨텍스트 로딩을 활용하고 싶은 낯선 리포지토리 리뷰하기
Claude Code가 에이전틱 역량 측면에서 대안들과 어떻게 비교되는지 궁금하다면 Claude Code vs. GitHub Copilot과 Claude Code vs. Cursor를 참고하세요. 그리고 Happycapy가 브라우저 환경에서 Claude Code를 어떻게 실행하는지 이해하고 싶다면 Claude Code on the web에서 아키텍처를 다룹니다.
자주 묻는 질문
Q: Claude Code 리뷰는 모든 언어에서 작동하나요?
네. Claude Code는 언어에 국한되지 않습니다 — 텍스트 기반 diff라면 무엇이든 읽고 해당 코드에 대한 추론을 적용합니다. Python, TypeScript, JavaScript, Go, Rust(학습 데이터에서 비중이 큰 언어들)에서 가장 정밀한 경향이 있지만, Ruby, Java, C# 및 대부분의 주류 언어에서도 유용한 결과를 만들어냅니다. 도메인 특화 언어나 특이한 프레임워크의 경우, CLAUDE.md에 컨텍스트를 추가하면 결과가 상당히 개선됩니다.
Q: /review는 채팅에서 Claude에게 diff를 봐달라고 요청하는 것과 어떻게 다른가요?
핵심 차이는 에이전틱 도구 사용과 리포지토리 컨텍스트입니다. 채팅에서 Claude는 여러분이 붙여넣은 것만 볼 수 있습니다. Claude Code의 /review 커맨드는 에이전트가 파일을 열고, import를 따라가고, 테스트를 확인하고, 프로젝트 컨벤션을 읽을 수 있게 해줍니다 — 발췌문이 아니라 실제 코드베이스에 근거한 결과를 만들어냅니다. 크거나 서로 연결된 변경 사항의 경우, 이 차이는 상당합니다.
Q: Claude Code 리뷰는 보안 취약점을 잡아내나요?
잘 알려진 취약점 클래스는 확실하게 잡아냅니다: SQL 인젝션, XSS, CSRF 결함, 안전하지 않은 직접 객체 참조, 하드코딩된 secret, 누락된 입력 살균 처리. 새로운, 애플리케이션 특화된 공격 벡터나 배포 환경에 대한 이해가 필요한 취약점에는 덜 신뢰할 수 있습니다. 침투 테스트가 아니라 철저한 첫 번째 단계 보안 스캔으로 취급하세요.
Q: 린터가 이미 처리하는 항목들을 리뷰가 지적하지 않게 하려면 어떻게 하나요?
CLAUDE.md에 명시적인 제외 규칙을 추가하세요: "Do not flag import ordering — isort handles this." 또는 "Do not flag trailing whitespace — Prettier enforces it." 대부분의 팀은 2~3주 정도 사용하면서 이 목록을 구축하고, 신호 대 잡음 비율이 극적으로 개선되는 것을 발견합니다.
Q: 여러 언어를 사용하는 모노레포에서 Claude Code 리뷰를 사용할 수 있나요?
네. 경로 인자나 변경한 하위 디렉토리만 다루는 git diff 범위로 리뷰의 범위를 지정할 수 있습니다. 또한 에이전트가 컨텍스트 로딩의 일부로 읽는 CLAUDE.md에 언어별 리뷰 섹션을 유지할 수도 있습니다.
Q: diff가 매우 클 경우 — 예를 들어 3,000줄짜리 PR이라면 어떻게 되나요?
매우 큰 diff의 경우, 두 단계 접근 방식을 고려하세요: 먼저 critical과 warning 결과만(제안은 제외하고) 요청하고, 이를 트리아지한 다음, 특정 파일이나 서브시스템에 대한 전체 분석을 요청하세요. 극도로 큰 리팩터의 경우, PR을 분할하는 것이 더 나은 해결책입니다 — 사람과 AI 리뷰어 모두에게 그렇습니다.
Q: 리뷰 결과는 결정론적인가요? 두 번 실행해도 같은 결과를 얻나요?
아니요 — 모든 대규모 언어 모델 출력과 마찬가지로, 실행 간에 변동이 있습니다. 리스크가 높은 리뷰의 경우, 커맨드를 두 번 실행하고 결과를 비교하는 것이 합리적인 관행입니다. 대부분의 critical 결과는 일관되게 나타나며, 사소한 제안은 더 많이 변합니다. (워크플로우에서 설정 가능하다면) 낮은 temperature를 사용하거나 더 명시적인 프롬프트를 사용하면 변동을 줄일 수 있습니다.
Q: Claude Code 리뷰는 기존 린터 및 정적 분석 도구와 어떻게 상호작용하나요?
이를 대체하는 것이 아니라 보완합니다. 여러분의 린터는 강제된 스타일 규칙을 기계적으로 빠르게 잡아냅니다. Claude Code는 의미론적 이해를 더합니다 — 함수가 올바른 일을 하는지 평가할 수 있는데, 이는 어떤 린터도 할 수 없는 일입니다. 이상적인 파이프라인은 둘 다 실행합니다: pre-commit 훅에서 린터(빠르고 결정론적), CI에서 Claude Code 리뷰(느리고 의미론적). /review 커맨드는 린터 설정을 인지하고 있어 여러분의 도구가 이미 만들어내는 결과를 중복하지 않습니다.
Q: Slack이나 티켓에 게시하기 위해 리뷰 결과의 형식을 커스터마이징할 수 있나요?
네. 결과를 특정 형식 — JSON, markdown, 혹은 팀의 PR 댓글 스타일에 맞는 템플릿 — 으로 출력하도록 에이전트에게 프롬프트할 수 있습니다. 이를 훅 시스템과 작은 셸 스크립트와 결합하면, 팀이 결과를 추적하는 어디로든 구조화된 결과를 게시하는 완전히 자동화된 리뷰 파이프라인을 갖게 됩니다.
관련 글: Claude Code 훅 심화 가이드 — 리뷰를 넘어 pre-commit 검사, 린팅, 커스텀 워크플로우를 자동화하세요.
