클로드 코드 리뷰(Code Review) 정식 출시: 누가 쓸 수 있나, 개인은 /code-review와 말로 요청 비교

앤트로픽이 10월 15일 깃허브 풀 리퀘스트(PR)를 클로드가 자동으로 검토하는 코드 리뷰(Code Review)를 정식으로 내놓았습니다. 연구 미리보기 때보다 리뷰가 세 배쯤 빨라졌고, 저장소마다 검토 깊이를 고를 수 있습니다. 다만 팀(Team)·엔터프라이즈(Enterprise) 요금제 전용입니다. 프로·맥스 같은 개인 요금제는 클로드 코드에 들어 있는 /code-review 명령을 씁니다. 버그를 일부러 넣은 변경 하나를 /code-review와 그냥 말로 한 요청에 각각 맡겨, 무엇이 다른지 비교했습니다.

결과 8개 직접 열어 보기(각 회차의 답 원문과 찾은 문제 목록, 검토 대상 변경)

1. 무엇이 바뀌었나

코드 리뷰는 PR이 올라오면 여러 에이전트가 바뀐 코드와 주변 코드를 함께 읽고 버그를 찾는 서비스입니다. 찾은 것은 확인 단계에서 한 번 더 걸러 오탐을 줄이고, 심각한 순서대로 해당 줄에 댓글로 남깁니다(공식 문서). 이번 정식 출시에서 달라진 점은 세 가지입니다(앤트로픽 발표).

무엇이	내용
속도	대부분의 리뷰가 미리보기 때보다 약 3배 빨라졌습니다. 약 20분 걸리던 것이 6~10분
지적 방식	문제가 무엇인지, 어떤 상황에서 일어나는지, 어떻게 고치는지를 몇 문장으로 짧게
검토 깊이	관리자가 저장소마다 빠름(Quick)·보통(Standard, 기본)·깊게(Deep)를 고름. 깊을수록 오래 걸리고 비쌈

지적마다 붙는 표시는 세 가지입니다. 🔴 중요(합치기 전에 고칠 버그), 🟡 사소함(고치면 좋지만 막지는 않음), 🟣 원래 있던 것(이번 PR이 만든 것이 아닌 기존 버그)입니다. 리뷰는 PR을 승인하거나 막지 않습니다. 합칠지는 사람이 정합니다. 코드를 빌드하거나 실행하지 않고 읽어서 판단한다는 점도 문서에 적혀 있습니다.

2. 누가 쓸 수 있나, 요금은

	코드 리뷰 서비스	/code-review 명령
쓸 수 있는 요금제	팀·엔터프라이즈	모든 요금제(프로·맥스 포함)
어디서	깃허브 PR(앤트로픽 서버에서 돎)	내 클로드 코드 세션
언제 돌아가나	PR 열 때·푸시할 때마다·@claude review 댓글	내가 명령을 칠 때
요금	정액 없음. 토큰 사용량만큼 사용량 크레딧에서 요금제 기본 사용량과 따로 빠짐. 조직에 청구	내 요금제 사용량(또는 API 요금)에서 빠짐
켜는 사람	Claude 조직 관리자(Owner) + 깃허브 조직 관리자가 Claude 깃허브 앱 설치	설정 없음
지침 파일	REVIEW.md·CLAUDE.md	CLAUDE.md(REVIEW.md는 안 읽음)

요금은 리뷰 깊이, 바뀐 코드의 양, 주변 코드의 복잡도에 따라 달라집니다(비용 문서). 저장소를 새로 추가하면 기본값이 “푸시할 때마다”라서 리뷰가 가장 많이 돕니다. 처음에는 “PR 만들 때 한 번”이나 “수동”으로 시작하고, claude.ai 관리자 설정의 사용량 메뉴에서 월 한도를 걸어 두라고 문서가 권합니다. 자격이 되는 엔터프라이즈 조직은 2027년 1월 15일까지 최소 1만 달러어치 코드 리뷰 크레딧을 받을 수 있습니다(받은 뒤 30일 안에 써야 함).

3. 개인 요금제는 /code-review

/code-review는 클로드 코드에 처음부터 들어 있는 명령이라 따로 깔 것이 없습니다(/review도 같은 명령). 쓰는 법은 이렇습니다(공식 문서).

1. 검토할 저장소 폴더에서 claude를 켭니다. 기능 브랜치에 있으면 됩니다.
2. /code-review를 입력합니다. 대상을 안 적으면 지금 브랜치의 커밋과 아직 커밋 안 한 변경을 봅니다. 브랜치에 기준(upstream)이 없으면 main이나 직전 커밋과 비교합니다.
3. 터미널에서는 리뷰가 뒤에서(백그라운드) 돌아서 그동안 다른 일을 해도 됩니다. 끝나면 찾은 문제가 대화에 올라옵니다. 데스크톱 앱에서는 파일 위치·한 줄 요약·분류가 붙은 목록으로 보입니다.
4. “1번하고 3번 고쳐 줘”라고 하거나, 처음부터 /code-review --fix로 고치기까지 맡깁니다.

이렇게 치면	검토 대상
/code-review	지금 브랜치 + 커밋 안 한 변경
/code-review 1234	PR 1234번
/code-review main...my-feature	두 브랜치 차이
/code-review src/auth	그 폴더
/code-review high	생각 깊이를 높여서(low는 확신 높은 것만, medium~max로 갈수록 넓게)
/code-review --comment	찾은 것을 깃허브 PR에 줄 댓글로 올림

단계를 안 적으면 예전에 마지막으로 친 단계(low~max)를 다시 씁니다. 그래서 저는 /code-review medium처럼 단계를 같이 적어 씁니다. /code-review ultra는 클라우드에서 도는 더 깊은 리뷰(ultrareview)입니다. 프로·맥스는 계정당 한 번 무료 3회가 있고, 그 뒤로는 변경 크기에 따라 보통 한 번에 5~25달러가 사용량 크레딧에서 빠집니다.

4. 같은 변경을 /code-review와 말로 요청에 맡긴 결과

친구가 만든 동네 카페 포인트 코드에 “생일 2배 적립·하루 적립 한도 5,000·포인트 사용” 기능을 붙여 feature 브랜치에 올렸다고 가정했습니다. 이 변경에 아래를 일부러 넣었습니다.

넣은 것	실제로 돌려 보면
진짜 버그 ① 포인트를 쓸 때 만료된 적립분부터 깎음	1,000을 써도 쓸 수 있는 잔액이 1,000 그대로
진짜 버그 ② 생일에 적립률 자체를 2배로 바꿔 버림	생일 다음 날도 2배, 다음 해 생일엔 4배
진짜 버그 ③ 하루 한도를 “남은” 포인트로 계산	쓰고 나면 같은 날 다시 적립돼 하루 8,000
원래 있던 버그(이번 변경 아님) 365일째 되는 날 포인트가 사라짐	364일째 500, 365일째 0
버그 아님: 변수 이름 바꾸기, 설명 주석, 함수 하나 분리	동작 같음

채점 기준 9개는 실행 전에 공식 문서에서 뽑아 고정했습니다. 진짜 버그 3개를 찾았는지, 원래 있던 버그를 “이번 변경이 만든 게 아님”으로 구분했는지, 모양만 바꾼 것을 문제로 올리지 않았는지, 문제마다 줄 위치와 고치는 법이 있는지, 심각한 순서인지, 오탐이 없는지입니다. 말로 한 요청은 이 문장입니다.

친구가 카페 포인트 코드(points.py)에 기능을 추가해서 feature 브랜치에 올렸어. main에 합쳐도 되는지 검토해서 찾은 문제를 답에 정리해 줘.

말로 요청은 두 가지로 돌렸습니다. 하나는 클로드가 스스로 /code-review를 부르지 못하게 막은 것(스킬 막음)이고, 하나는 설정을 그대로 둔 것입니다.

조건	진짜 버그 3개	원래 있던 버그 구분	줄 위치(모든 항목)	점수(9점)	비용
말로 요청(스킬 막음) 1·2회	모두 찾음	둘 다 구분	없음 · 없음	8 · 7	0.34·0.36달러
말로 요청(그대로) 1·2회	모두 찾음	둘 다 구분	없음 · 없음	7 · 8	0.28·0.30달러
/code-review medium 1·2회	모두 찾음	둘 다 구분	있음 · 있음	8 · 8	0.39·0.38달러
/code-review high 1·2회	모두 찾음	1회만	있음 · 있음	8 · 8	0.38·0.37달러

여덟 번 모두 진짜 버그 3개를 찾았고, 제가 넣지 않은 실제 버그 하나(use(-1000)처럼 음수를 넣으면 포인트가 늘어남)까지 찾았습니다. 모양만 바꾼 세 곳을 문제로 올린 경우는 한 번도 없었고, 오탐도 없었습니다. 2월 29일생은 평년에 생일 적립을 못 받는다는 정책 문제도 여덟 번 모두 짚었습니다. 이 정도 크기의 변경이라면 점수 차이는 거의 없습니다. 차이는 정리 방식에서 났습니다.

• 목록 형식: /code-review는 문제마다 points.py:54 같은 위치와 분류(정확성·단순화·효율·테스트)를 붙였습니다. 말로 요청한 답은 큰 문제에는 줄 번호를 달았지만 사소한 항목에는 빠지거나 함수 이름만 적었습니다.
• 검증 여부를 스스로 밝힘: medium 두 번 모두 답 첫 줄에서 검증 단계를 거치지 않았다고 밝혔습니다(2회차: “이번 리뷰는 검증 단계 없이 진행해서 일부는 오탐일 수 있습니다”). high 두 번은 코드를 직접 돌려 재현한 뒤 답했습니다. 말로 요청한 네 번도 넷 다 파이썬으로 직접 돌려 확인했습니다.
• 버그 밖 항목: /code-review는 “적립률을 지갑에 저장할 필요 없음(단순화)”, “쓸 때마다 다시 정렬함(효율)” 같은 정리 제안을 따로 분류해 올렸습니다. 문서대로 모델·생각 깊이에 따라 단순화·효율 항목도 함께 봅니다.
• 고치는 법: 말로 요청한 답은 항목마다 “고치는 법” 줄이 있는 경우가 많았고, /code-review 목록은 만료분 차감 같은 항목에 일어나는 상황만 적고 고치는 법이 빠지기도 했습니다.

주의할 점이 두 가지 있었습니다. /code-review high 2회차는 답 전체가 영어였고, 1회차도 목록은 영어였습니다. 영어가 불편하면 프로젝트의 CLAUDE.md에 “답과 리뷰는 한국어로”라고 한 줄 적어 두면 됩니다(/code-review는 CLAUDE.md를 따릅니다). 또 문서에는 “리뷰해 줘”라고 말하면 클로드가 알아서 /code-review를 부를 수 있다고 되어 있지만, 설정을 그대로 둔 두 번 모두 부르지 않고 직접 검토했습니다.

제 결론은 이렇습니다. 작은 변경이면 말로 부탁해도 충분히 잡힙니다. /code-review의 값은 “늘 같은 형식으로, 위치가 붙은 목록”을 받는 데 있고, 데스크톱 앱에서는 이 목록을 보고 “고침·건너뜀”으로 표시해 가며 처리할 수 있습니다. 비용은 말로 요청보다 0.1달러쯤 더 들었습니다. 플러그인으로 코드 리뷰를 해 본 결과는 Engineering 플러그인 글(함정 9개 쇼핑몰 코드)에, 보안 쪽은 security-guidance 플러그인 글에 있습니다.

실습 재료 내려받기: 카페 포인트 git 저장소(main·feature 브랜치), 요청문, 채점 기준(정답 포함), 버그를 돌려 보는 verify.py가 들어 있습니다. 압축을 풀고 cafe-points 폴더에서 클로드 코드를 켜 /code-review를 치면 됩니다. 진짜 버그 3개와 원래 있던 버그 1개가 나오면 성공입니다.

실행 기록

# <작업 폴더>/cmd1 · macOS · 클로드 코드 2.1.299 · Opus 5.5
$ git log --oneline --all
bc14031 생일 2배·하루 한도·포인트 사용 추가
23344db 포인트 적립 첫 버전
$ git diff main --stat
 points.py | 40 ++++++++++++++++++++++++++++++++++++----
 1 file changed, 36 insertions(+), 4 deletions(-)

# 조건별 요청 (모두 같은 옵션)
$ claude -p "/code-review medium" --model claude-opus-5-5 --effort medium \
    --setting-sources project,local --permission-mode acceptEdits < /dev/null
$ claude -p "/code-review high" ...
$ claude -p "$(cat task.txt)" ...          # 말로 요청
# 스킬 막음 조건: 작업 폴더 .claude/settings.json
{"skillOverrides":{"code-review":"user-invocable-only"}}

# 숨은 검사(리뷰 대상에는 없음): 넣은 버그가 실제로 일어나는지
$ python3 verify.py points_v2.py
P1 365일째 잔액(정상 500): 0 | 364일째: 500
B1 사용 전 잔액: 1000 → 1000 쓴 뒤(정상 0): 1000
B2 생일 다음 날 10000원 적립(정상 500): 1000 | 다음 해 생일(정상 1000): 2000
B3 하루 적립 합계(정상 5000 이하): 8000

5. 클로드 코드 팀은 리뷰를 어떻게 하나

같은 날 클로드 코드 팀이 자기들의 리뷰 방식을 공개했습니다(팀 블로그). 클로드가 클로드 코드 코드의 약 90%를 쓰는 상황에서, 6월부터 9월까지 합친 PR은 두 배 넘게 늘고 되돌린 비율은 40% 넘게 줄었다고 합니다. 개인이나 작은 팀이 가져다 쓸 만한 것만 추리면 이렇습니다.

• PR을 올리기 전에 클로드에게 테스트·빌드처럼 돌려 볼 수 있는 것을 주고, “다 됐다” 대신 실행 결과를 보여 달라고 합니다.
• PR 양식에 “어떻게 테스트했나·위험·되돌리는 법” 칸을 둡니다.
• 리뷰를 몇 번 돌려도 계속 새 지적이 나오면 끝이 없으니, 횟수를 정해 둡니다. 팀은 3번 뒤에는 접근 자체를 다시 생각하라고 하고, 몇 번 뒤부터는 바뀐 부분만 다시 봅니다. 이렇게 바꾼 뒤 한 번에 통과하는 PR이 65%에서 78%로 늘었다고 합니다.
• 리뷰가 놓친 것이 있으면 “모델 앞에 무엇이 없었나”를 묻고, 그 내용을 CLAUDE.md나 스킬, 새 검사로 남깁니다.

이런 사람에게

• ✅ 팀·엔터프라이즈에서 깃허브를 쓰는 개발팀: 관리자에게 코드 리뷰를 켜 달라고 하고, 저장소 하나에 “PR 만들 때 한 번”으로 시작해 평균 비용을 봅니다.
• ✅ 프로·맥스로 혼자 개발하는 사람: 커밋 전에 /code-review medium을 습관으로. CLAUDE.md에 한국어로 답하라고 적어 둡니다.
• ✅ 코드를 잘 못 읽지만 클로드 코드로 만드는 사람: 말로 “합쳐도 되는지 검토해 줘”라고만 해도 큰 버그는 잡힙니다. 목록으로 정리해 받고 싶을 때 명령을 씁니다.
• ❌ 깃랩만 쓰는 팀: 자동 리뷰 서비스는 깃허브 기준입니다. 대신 /code-review --comment(glab 필요)로 MR에 결과를 남기거나, 깃랩 CI/CD에 클로드를 붙여(API 키나 클라우드 자격 증명 필요) 머지 요청마다 돌립니다.

이번 달 클로드 코드의 다른 변화는 클로드 코드 10월 업데이트 글에 정리했습니다.

자주 묻는 질문

프로 요금제로 깃허브 PR 자동 리뷰를 켤 수 있나요?

아니요. 자동 리뷰 서비스는 팀·엔터프라이즈 조직 전용입니다. 프로·맥스는 /code-review를 직접 치거나, /code-review --comment로 PR에 결과를 올리는 방법을 씁니다.

/code-review도 돈이 따로 드나요?

아니요. 평소 클로드 코드를 쓰는 사용량에서 빠지고, 이번 실험에서는 한 번에 0.4달러 안쪽(API 요금 환산)이었습니다.

리뷰가 PR을 막아 버리나요?

코드 리뷰 서비스는 승인도 차단도 하지 않습니다. 줄 댓글과 “Claude Code Review” 검사 결과를 남기고, 이 검사는 실패로 끝나지 않습니다. 막고 싶으면 팀이 브랜치 규칙을 따로 정해야 합니다.

리뷰에서 무엇을 볼지 정할 수 있나요?

저장소 맨 위에 REVIEW.md를 두면 무엇을 어떤 심각도로 볼지, 어떤 파일은 건너뛸지 적을 수 있습니다(설정 문서). 이 파일은 PR 안의 수정이 아니라 기본 브랜치에 합쳐진 것만 읽습니다.

출처

앤트로픽 발표: Code Review is now generally available(2026-10-15), 클로드 코드 문서: Code Review, 문서: /code-review로 내 컴퓨터에서 리뷰, 문서: 코드 리뷰 켜기, 문서: 비용과 사용량, 문서: PR에서 리뷰 읽기, 문서: 리뷰 설정, 문서: ultrareview 요금, 클로드 코드 팀 블로그: How the Claude Code team does code review(2026-10-15) (2026-10-17 확인)