Claude Code로 코드 리뷰하기: 프로덕션에 가기 전 버그 잡기

Claude Code Review란 무엇인가요?

Claude Code Review는 리포지토리 맥락에서 PR을 살피고 잠재적 버그, 보안 이슈, 회귀를 보고하는 멀티 에이전트 코드 리뷰 시스템입니다. GitHub Code Review는 GitHub PR에 대해 이러한 에이전트를 실행하며, 로컬 /code-review는 현재 변경(diff)에 대한 리뷰를 Claude Code에서 바로 제공합니다.

여기서 중요한 단어는 맥락입니다. 전통적인 diff 리뷰는 변경된 라인을 확인하도록 요청합니다. Claude의 리뷰 에이전트는 리포지토리 맥락 속에서 그 변경을 살펴봅니다. GitHub 워크플로에서는 여러 특화 에이전트가 병렬로 작업하고, 그 뒤에 검증, 중복 제거, 심각도 순위 지정이 이어집니다.

예를 들어 10줄짜리 pandas 변환 변경도 상류 dbt 모델이 만든 스키마, Snowflake 테이블의 그레인, 하류 대시보드에 내재된 가정에 의존할 수 있습니다.

Claude는 PR을 승인하거나 차단하지 않습니다. GitHub Code Review는 중립 체크 결론을 보고하므로, 체크 출력에 자체 CI 로직을 얹지 않는 한 기존 브랜치 보호 규칙은 그대로 유지됩니다.

세 가지 리뷰 인터페이스

현재 Claude Code로 코드를 리뷰하는 주요 방법은 세 가지입니다.

로컬 /code-review 명령은 브랜치의 커밋을 살핍니다. 특정 파일, 브랜치, PR 번호, Git ref 범위를 지정할 수도 있습니다.

GitHub Code Review는 PR 자체 중심으로 설계되었습니다. 리포 설정에 따라 PR 생성 후 1회, 매 푸시마다, 혹은 누군가 @claude review로 리뷰를 요청할 때만 실행되도록 구성할 수 있습니다.

/code-review ultra는 더 무거운 옵션입니다. Anthropic은 이 기능을 ultrareview라고 부르며, 계정에서 기능이 활성화되어 있다면 /ultrareview를 별칭으로 사용할 수 있습니다. 원격 샌드박스에서 다수의 리뷰어 에이전트를 실행하고, 보고된 버그는 각기 재현 및 검증된 뒤에야 결과에 포함됩니다. 현재 연구 프리뷰이며, 일반적으로 5~10분 정도가 소요됩니다.

Claude가 표시하는 항목과 건너뛰는 항목

Claude Code Review는 우선 정확성을 중시합니다. Anthropic 문서는 프로덕션에 영향을 주는 버그와 형식 선호, 테스트 커버리지 누락을 명확히 구분합니다.

발견사항은 3단계 심각도를 사용합니다:

이 구분은 유용합니다. 데이터 과학자들은 무엇을 리뷰 시간의 대상으로 삼을지 의견이 크게 갈리는 경우가 많기 때문입니다. revenue_df와 weekly_revenue 중 어떤 이름이 더 나은지 제안하는 일은, 어느 다대다 조인이 변환에 끼어들어 매출이 2배가 되는 문제와는 전혀 다른 범주입니다.

Claude Code에서 코드 리뷰를 어떻게 설정하나요?

Claude Code Review 설정은 로컬 리뷰인지 GitHub PR 코드 리뷰인지에 따라 단계가 다릅니다. 로컬 /code-review는 GitHub 앱이 필요 없으며 PR을 열기 전에도 실행할 수 있습니다. 

GitHub Code Review는 조직의 소유자(Owner/Primary Owner)가 Claude GitHub 앱을 설정하고 리포를 선택해야 합니다. PR 리뷰를 할 때는 REVIEW.md라는 전용 파일을 만들어 리뷰 전용 규칙을 넣는 것이 좋습니다.

CLAUDE.md vs. REVIEW.md

CLAUDE.md와 REVIEW.md는 목적이 다르며, 둘을 섞어 쓰면 소음 많은 리뷰가 되기 쉽습니다.

CLAUDE.md에는 Claude가 여러 작업에서 참고하는 일반적인 프로젝트 지침이 담깁니다. 코드 리뷰도 이 지침을 읽고, 새로 도입된 위반 사항을 nit로 보고합니다.  반면 REVIEW.md는 리뷰 동작에 특화되어, 팀이 무엇을 표시하고 건너뛰며 Important로 취급하길 원하는지 리뷰 에이전트에 알려줍니다.

Python 데이터 리포의 경우 CLAUDE.md에는 리포 구조, pytest 실행 방법, 변환이 pandas인지 polars인지, SQL 모델의 위치 같은 내용을 담겠습니다. 

REVIEW.md에는 리뷰 규칙을 넣겠습니다. 예시 규칙은 다음과 같습니다:

• “새 변환마다 해당 테스트가 있는지 확인.”
• “자격 증명을 절대 로깅하지 말 것.”
• “생성된 파일은 건너뛸 것.”

작은 REVIEW.md는 다음과 같을 수 있습니다:

# Review instructions

## Important findings

Report as Important:
- Incorrect joins or filters that can change dataset grain
- Missing tenant or customer scoping
- Secrets or credentials written to logs
- Silent changes to revenue or customer metrics

## Do not report
- Formatting already enforced by Ruff
- Generated files
- *.lock files

## Always check
- New transformations have tests
- Joins use the intended keys
- Datetime operations specify timezone assumptions
- Missing values are handled explicitly

REVIEW.md는 간결하게 유지할 것을 권장합니다. 지침이 길어지면 중요한 규칙의 힘이 약해질 수 있습니다. 현재 구현은 파일을 평문 지침으로 읽기 때문에 @ 단축 표기 대신 규칙을 직접 적어야 합니다. 

참고로, 로컬 개발 시 /code-review는 REVIEW.md를 읽지 않습니다. CLAUDE.md를 따르며, GitHub Code Review 파이프라인은 리뷰 전용 지침으로 REVIEW.md를 사용합니다.

로컬과 GitHub에서 동일한 리뷰 규칙을 원한다면, 일반 규칙은 CLAUDE.md에 두고, 필요한 리뷰 전용 규칙은 REVIEW.md에도 반복해 두세요.

자세한 내용은 최적의 CLAUDE.md 작성 가이드를 참고하세요.

GitHub 앱과 트리거 모드

GitHub Code Review는 조직 소유자(Owner/Primary Owner)가 Claude의 관리자 설정을 통해 구성합니다. 관리자는 Claude GitHub 앱을 설치하고, 리포 접근 권한을 부여하며, 리뷰할 리포를 선택하고, 각 리포에 리뷰 동작을 지정해야 합니다.

트리거 모드는 3가지가 있습니다:

세 가지 모두에 공통 예외가 하나 있습니다. Claude는 포크에서 온 풀 리퀘스트를 자동으로 리뷰하지 않습니다. 반드시 @claude review 코멘트를 달아야 합니다.

2026년 7월 업데이트 기준, 수동 명령도 변경되었습니다: 

• @claude review는 단일 리뷰를 시작하며 이후 푸시에는 구독되지 않습니다. 

• @claude review always는 리뷰를 시작하고 PR을 구독해, 이후 푸시마다 리뷰가 실행됩니다.

• @claude review once는 기본 명령과 동일하게 동작합니다.

2026년 초에 Claude Code Review를 배우셨다면, 예전 튜토리얼에는 @claude review가 이후 리뷰에 구독된다고 적혀 있을 수 있으나, 해당 동작은 2026년 7월에 변경되었고 2026년 9월 현재도 같습니다.

조직의 GitHub Code Review 접근 권한이 없는 Pro/Max 사용자는 앱을 아예 건너뛰고 로컬 /code-review와 더 깊은 리뷰인 /code-review ultra를 사용할 수 있습니다.

로컬에서 /code-review로 diff를 어떻게 리뷰하나요?

로컬 /code-review 명령은 PR을 열기 전에 현재 브랜치를 리뷰합니다. 저는 항상 여기서 시작합니다. 작업 중에 문제를 잡아 CI 실패를 막을 수 있기 때문입니다.

리뷰할 사례

전자상거래 리포에 order_id, customer_id, order_date, status, revenue가 있는 주문 테이블이 있고, 주간 매출을 계산하는 weekly_revenue.py를 만든다고 가정해 봅시다:

orders = load_orders()
customers = load_customers()

# Derive the reporting week from the order date
orders["week"] = orders["order_date"].dt.to_period("W").dt.start_time

weekly_revenue = (
    orders
    .merge(customers, on="customer_id", how="inner")
    .groupby("week", as_index=False)["revenue"]
    .sum()
)

언뜻 보기엔 이상할 것이 없어 보입니다. merge()는 명시적이고, 그룹화도 읽기 쉽고, 조인 후 매출을 집계합니다.

문제는 고객 테이블에 일부 고객의 이력 레코드가 여러 개 존재한다는 점입니다. 레코드가 2개인 고객은 조인 후 2행이 생성되어 해당 고객의 매출이 두 배가 됩니다. 이는 테이블 그레인을 확인하지 않고 로컬에서 변환 코드를 훑을 때 놓치기 쉬운 정확히 그런 유형의 버그입니다.

diff 범위 지정

Claude Code 세션에서 /code-review를 실행하세요.

이 명령은 업스트림 브랜치 대비 현재 브랜치의 앞선 커밋과, 커밋되지 않은 변경을 함께 리뷰합니다. 특정 파일, 브랜치, PR, 혹은 main...feature/weekly-revenue 같은 범위를 지정할 수도 있습니다.

예를 들어:

/code-review weekly_revenue.py

또는:

/code-review main...feature/weekly-revenue

또한 /code-review high처럼 노력 수준(effort level)을 지정할 수 있습니다. low와 medium에서는 자신 있는 발견만 보고하고, high~max에서는 커버리지를 늘리는 대신 거짓 양성 가능성이 다소 높아집니다. 

플래그로 리뷰 방향 설정

워크플로에 익숙해지면 다음 두 플래그가 유용해집니다: 

• --fix는 리뷰 후 발견사항을 작업 트리에 적용합니다.

• --comment는 발견사항을 인라인 코멘트로 남깁니다.

Claude는 리뷰를 백그라운드 서브 에이전트로 실행하므로, 처리 중에도 계속 작업할 수 있습니다. 리뷰가 끝나면 결과가 세션으로 돌아옵니다.

리뷰는 대략 다음과 같이 보고할 수 있습니다:

🔴 Important
weekly_revenue.py:9

The merge on customer_id can duplicate order rows because
customers contains multiple records per customer. This can
inflate revenue when a customer has more than one matching
customer record.

Verify that customer_id is unique in customers or join against
the intended current-record subset before aggregating revenue.

리뷰는 구체적인 실패 모드를 찾아내고, Claude의 판단을 맹신하기보다 실제 스키마에 비춰 검증할 거리를 제공합니다.

발견사항 읽기

/code-review --fix를 실행하기 전에는 여전히 수동으로 한 번 훑어보겠습니다. 먼저 customers를 구성하는 코드를 찾고, 고유성 제약을 확인하고, weekly_revenue.py 주변 테스트를 살펴봅니다.

customers.customer_id가 실제로 고유하다면 Claude의 지적은 거짓 양성입니다. 테이블이 고객당 유효일(effective date)별 1행이라면 발견은 진짜이며 변환을 수정해야 합니다.

핵심은 Claude 리뷰어가 코드 동작을 보고 있다는 점이며, 데이터가 무엇을 표현하는지 아는 책임은 여전히 제게 있다는 것입니다.

리뷰 후 Claude에 조사를 요청할 수 있습니다:

Investigate the customer_id join finding.
Check how the customers table is built and determine whether
customer_id is unique at the point of this merge. Do not modify
the code yet.

이 두 번째 단계는 코멘트를 맹목적으로 고치게 하기보다 종종 더 유용합니다. 리뷰를 코드 생성이 아니라 짧은 조사로 바꿔 주기 때문입니다.

GitHub PR에서 Claude Code Review를 어떻게 실행하나요?

GitHub Code Review는 Claude의 발견사항을 PR에 직접 남기므로, 리뷰어가 변경된 코드 옆에서 문제를 확인할 수 있습니다. 

리뷰는 이미 존재하는 PR에 연결되므로 순서가 중요합니다:

1. git push로 weekly-revenue 브랜치를 GitHub에 푸시합니다.

2. 풀 리퀘스트를 엽니다. Claude는 열린 PR만 리뷰할 수 있으므로, 이 전에는 아무 일도 일어나지 않습니다.

3. 리포가 자동 트리거로 설정되어 있다면 리뷰가 자동 시작됩니다. 수동으로 설정되어 있다면 최상위 PR 코멘트로 @claude review를 남겨 시작하세요.

여기서 자주 걸리는 요구 사항이 세 가지 있습니다. 명령은 최상위 PR 코멘트여야 하며, 인라인 리뷰 코멘트에 대한 답글이 아니어야 합니다. 또한 리포에 대한 write/maintain/admin 권한이 필요합니다. 명령은 코멘트의 맨 앞에서 시작해야 하고, once 또는 always를 추가한다면 같은 줄에 있어야 합니다.

리뷰 트리거

비용 측면에서 실제 선택지는 자동 여부가 아니라, 두 가지 수동 명령 중 무엇을 쓰느냐입니다.

@claude review는 1회 리뷰를 실행하고 PR 구독을 남기지 않습니다. @claude review always는 리뷰를 실행하고 PR을 구독해 이후 푸시마다 새 리뷰를 시작합니다.

이는 2026년 7월 이후, 2026년 9월 현재의 동작입니다. 그 전에는 기본 @claude review가 PR을 이후 리뷰에 구독시켰으니, 예전 튜토리얼을 따른다면 먼저 이 부분을 확인하세요.

리뷰는 보통 20분 내외가 걸리지만, Anthropic은 비용과 소요 시간이 PR의 크기와 복잡도에 따라 달린다고 말합니다. 각 리뷰는 Team/Enterprise 플랜의 포함 사용량과 별개로 사용 크레딧으로 개별 과금됩니다. 비용 구조에 대해 더 알고 싶다면 Claude Code 사용 한도 가이드를 권합니다.

인라인 코멘트와 체크 실행 결과 읽기

리뷰가 끝나면 Claude가 관련 라인에 인라인 코멘트를 남깁니다. GitHub 체크 실행에는 심각도 요약도 포함되어, weekly_revenue.py, SQL 모델, 테스트 파일 등 여러 파일에서 발견이 있을 때 유용합니다.

예시:

인라인 코멘트에서는 실제 문제를 조사하고, 체크 실행에서는 리뷰의 전체 윤곽을 파악합니다.

참고로 👍 또는 👎을 클릭해도 새 리뷰는 시작되지 않으며, 인라인 코멘트에 답글을 달아도 Claude가 응답하지 않습니다. 새 리뷰를 받으려면 코드를 고치고 푸시하거나, 새로운 최상위 PR 코멘트로 @claude review를 남기세요.

리뷰 자체도 병합을 차단하지 않습니다. 체크는 중립 결론을 제공하지만, 체크 출력에는 팀이 gh와 jq로 소비해 자체 머지 게이트를 구축할 수 있는 기계가독 심각도 정보가 포함됩니다.

Claude의 리뷰 코멘트를 어떻게 분류하나요?

리뷰 주기에서 사람이 루프 안에 머무르는 것이 핵심입니다. 즉, Claude의 모든 리뷰에 대해 각 발견이 실제 버그인지, 비차단 개선인지, 거짓 양성인지 판단해야 합니다. 리뷰어는 구현 동작을 점검할 수 있지만, 데이터셋이나 지표 뒤의 모든 비즈니스 가정을 알지는 못하기 때문입니다.

저는 단순한 3가지 결정을 사용합니다:

마지막 범주가 중요합니다. 30건을 보고하는 리뷰어가 5건을 보고하는 리뷰어보다 반드시 더 낫지는 않습니다. pandas 조인에 대한 거짓 양성 코멘트가 원래 변경보다 더 많은 시간을 들게 할 수 있습니다.

수정, 건너뛰기, 반박

고객 행 중복 버그가 실제라면, Claude에 상류 모델을 확인하게 한 뒤 다음 수정을 요청할 수 있습니다:

The customer_id finding is valid. Inspect the existing customer
model and update weekly_revenue.py to join only the current
customer record. Add a regression test for a customer with
multiple historical records, then run the relevant tests.

이후 Claude는 리포를 살피고 Python 코드를 수정하며, 테스트를 추가하고, 테스트 스위트를 실행할 수 있습니다.

GitHub 리뷰 코멘트를 중심으로 작업하려면 Claude Code가 GitHub CLI(gh)를 통해 리포와 상호작용할 수도 있습니다. 중요한 점은 전체 리뷰를 “전부 고쳐라”가 아니라 유효하다고 판단한 특정 수정만 선택해서 맡긴다는 것입니다.

이렇게 하면 개발자가 리뷰 루프 안에 머무릅니다:

1. Claude가 잠재적 문제를 찾습니다.
2. 제가 코드와 데이터 가정에 비춰 문제를 검증합니다.
3. Claude가 요청한 수정을 수행합니다.
4. 테스트 실행.
5. Claude가 결과 diff를 다시 리뷰합니다.

이는 첫 리뷰 출력을 자동 리팩터링 대기열처럼 취급하는 것보다 훨씬 안전합니다.

데이터 PR에 여전히 사람이 필요한 이유

Claude가 다루지 못하는 실패 모드는 코드가 정상 동작하면서도 여전히 잘못된 일을 하는 경우입니다. 다음 세 가지 버전이 반복해서 나타납니다:

• diff 바깥에 존재하는 가정. Claude는 리포지토리를 읽지, 데이터 웨어하우스나 구성 서비스, 다른 팀이 가진 계약을 읽지 않습니다. 조인이 올바른 키를 사용하더라도 결과의 그레인은 상류 테이블의 행 수에 달려 있어, 눈앞의 코드가 아니라 상류의 속성입니다.

• 여러분 팀만 가진 정의. 매출을 주문/고객/주 단위 중 어디에서 계산할지는 비즈니스 결정입니다. Claude는 groupby()가 주어진 행을 기꺼이 합산한다고 말해줄 수 있지만, 재무팀이 공식적으로 인정하는 숫자가 무엇인지는 알 수 없습니다.

• 시간과 타입 가정. 2026-08-27이 UTC 날짜인지, 로컬 영업일인지, 상류 모델이 설정한 리포팅 날짜인지요? 객체/널 허용 정수/타임존 인식 datetime/문자열 간 연산은 그럴듯한 결과를 내면서도 비교 동작을 조용히 바꿔 놓을 수 있습니다.

데이터 누출은 첫 번째 범주의 가장 날카로운 예입니다. 피처 변환이 예측일 이후에만 존재하는 정보를 담은 테이블과 학습 세트를 조인할 수 있습니다. 조인은 유효하고, 행 수는 기대와 같지만, 모델은 오염됩니다.

그래서 저는 Claude를 구현 동작의 리뷰어로 대하되, 정의의 소유자는 사람으로 둡니다.

Code Review와 Ultrareview는 언제 써야 하나요?

빠른 로컬 피드백에는 /code-review를,d /code-review ultra는 더 깊은 사전 병합 검토에 사용하세요. 둘 다 코드를 리뷰하지만, /code-review는 반복 작업에, ultra 리뷰는 여러 원격 에이전트가 보고된 버그를 독립적으로 검증합니다.

Anthropic은 현재 ultra 리뷰를 연구 프리뷰로 설명합니다. Pro/Max 가입자는 갱신되지 않는 1회 한정 3회의 무료 실행을 제공받으며, 이후 리뷰 비용은 변경 크기에 따라 보통 $5~$25입니다. Team/Enterprise 사용자는 이 무료 실행을 받지 못하며, 해당 기능은 Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry, Zero Data Retention을 사용하는 조직에는 제공되지 않습니다.

중요한 차이는 검증입니다. /code-review ultra는 리포 상태를 원격 샌드박스로 보내 다수의 리뷰어 에이전트를 실행하고, 보고된 버그를 독립적으로 재현한 뒤에야 발견사항으로 반환합니다.

모든 커밋에 실행하진 않겠습니다. Python 노트북에서 변수명만 바꾸거나 dbt 모델의 형식만 조정한다면 로컬 /code-review면 충분합니다. 프로덕션 모델의 피처 생성 로직을 바꾸거나 매출 변환을 다시 쓰거나 고객 단위 집계를 수정한다면 추가 리뷰 패스가 더 합리적입니다.

또 하나 이름 관련으로 짚고 넘어갈 점이 있습니다. 문서화된 명령은 /code-review ultra이며, ultrareview가 계정에 제공될 때 /ultrareview 별칭이 동작합니다. 예전 튜토리얼은 종종 /ultrareview를 기본 명령으로 소개하지만, Anthropic 문서는 이제 심층 클라우드 리뷰를 /code-review 명령군의 일부로 다루며, /code-review ultra는 클라우드 기능이 없을 때 로컬 리뷰로 폴백합니다.

같은 PR에 ultra 리뷰 실행

리포에서 다음을 실행하세요:

/code-review ultra

GitHub PR을 직접 리뷰하려면:

/code-review ultra <pr#>

인자를 생략하면 /code-review ultra는 현재 브랜치를 기본 브랜치와 비교하고, 커밋되지 않은 변경과 스테이징된 변경을 포함합니다. 브랜치 리뷰는 기본적으로 변경 파일 약 500개, 변경 라인 8,000줄에 캡이 있으며, 이 숫자는 바뀔 수 있다고 Anthropic은 밝힙니다. diff가 너무 크면 브랜치를 푸시하고 PR로 리뷰하세요.

PR 번호를 지정하면 원격 환경이 GitHub에서 해당 PR을 클론하며, 로컬 머신에서는 아무 것도 업로드되지 않습니다.

시작 전, Claude는 리뷰 범위, 남은 무료 실행, 예상 비용을 보여줍니다. 확인 후 리뷰는 백그라운드에서 실행되므로, 원격 에이전트가 작업하는 동안 Claude Code를 계속 사용할 수 있습니다.

우리의 weekly_revenue.py 예시에서는, 더 깊은 리뷰가 무조건 맞다고 가정하지 말고 결과를 비교하겠습니다.

만약 /code-review가 고객 조인을 표시하고 ultra 리뷰가 동일한 매출 중복을 독립적으로 재현한다면, 그 발견에 대한 신뢰도가 높아집니다. ultra 리뷰가 상류 테이블이 고유성을 보장한다고 해서 이를 무시한다면, 두 리뷰의 근거와 실제 모델 정의를 확인한 뒤 코드를 바꾸겠습니다.

복수 리뷰어의 유용한 특성은 불일치가 조사 거리를 제공한다는 점입니다.

비용도 고려해야 합니다. GitHub Code Review는 현재 리뷰당 평균 $15~$25인 반면, ultra 리뷰는 Pro/Max 무료 실행 이후 보통 $5~$25가 듭니다. GitHub Code Review 비용은 포함된 플랜 사용량과는 별개이며, Anthropic은 조직을 위한 지출 제어를 제공합니다.

혼자 작업한다면 로컬 /code-review에 가끔 /code-review ultra를 더하는 것이 합리적 시작점입니다. Team/Enterprise 플랜에서 모든 PR에 자동 리뷰를 붙이고 싶다면 GitHub Code Review가 더 적합합니다.

실전 Claude Code Review 워크플로

유용한 워크플로는 “병합 전마다 Claude 실행”이 아닙니다. 각 리뷰가 개발의 서로 다른 지점에서 일어나 비용이 다르고 잡아내는 문제 유형도 다르기 때문입니다.

프로덕션 변경에 제가 사용할 프로세스는 다음과 같습니다:

Write code
	   ↓
Run tests and data checks
	   ↓
/code-review
	   ↓
Fix verified findings
	   ↓
Open GitHub PR
	   ↓
GitHub Code Review
	   ↓
Human triage
	   ↓
/code-review ultra for higher-risk changes
	   ↓
Final tests
	   ↓
Human merge

로컬 리뷰는 고치기 쉬울 때 문제를 잡습니다. GitHub 리뷰는 팀 전체가 공유하는 발견 기록을 제공하고, ultra 리뷰는 중대한 병합 전에 더 높은 노력의 세컨드 오피니언을 제공합니다.

데이터 과학자를 위한 추가 점검

데이터 작업에서는 모델이 전체 리뷰를 수행하기를 기대하기보다 Claude 주변에 다음 4가지를 추가하겠습니다:

• 중요한 조인 전후로 행 수와 데이터셋 그레인 확인
• 변환과 피처 로직에 대한 단위/통합 테스트 실행
• 머신러닝 피처를 만들 때 누출 여부 점검
• 비즈니스 지표를 신뢰 가능한 쿼리나 대시보드와 대조 검증

Claude는 이 네 활동 모두에 참여할 수 있지만, 기대 결과는 Claude의 설명이 아니라 코드, 테스트, 데이터에서 나와야 합니다.

마무리

저는 Claude Code Review를 자동 승인 도장이 아니라 리뷰 스레드의 또 다른 엔지니어로 대할 때 가장 효과적이라고 봅니다.

로컬 /code-review 명령은 PR이 생기기 전에 빠르게 리뷰합니다. GitHub Code Review는 Team/Enterprise 조직의 PR에 멀티 에이전트 발견을 가져오며, /code-review ultra는 변화가 한 번 더 점검받을 가치가 있을 때 더 깊은 원격 리뷰를 제공합니다.

작게 시작하세요. 평소 브랜치 워크플로에 /code-review를 넣고, GitHub 리뷰를 위해 짧은 REVIEW.md를 작성하며, 잘못 병합 시 실제 비용이 드는 변경에는 /code-review ultra를 시도해 보세요.

기저 모델 개념은 Introduction to Claude Models 코스에서 더 넓은 맥락을 제공하며, GitHub Foundations와 Intermediate GitHub Concepts는 Code Review가 기반하는 Git과 GitHub 워크플로를 다룹니다. Claude로 GitHub 리포를 분류하는 영감을 더 얻으려면 Claude Code 커넥터 튜토리얼도 추천합니다.