Claude Code Review 정식 출시, 리뷰 수준과 비용은 어떻게 달라졌나?

Anthropic이 직접 운영하는 PR 리뷰 서비스인 Claude Code의 Code Review가 연구 프리뷰를 마치고 2026년 10월 15일 Claude Team과 Enterprise 조직에 정식 출시됐다 ^[1]. 정식 버전에서는 대부분의 리뷰가 프리뷰 때보다 약 3배 빨라졌고, 지적 사항을 쓰는 방식이 더 간결해졌으며, 관리자가 저장소마다 Quick, Standard, Deep 중 리뷰 수준을 고를 수 있다 ^[1].

정식 출시로 무엇이 바뀌었나?

정식 출시에서 바뀐 점은 세 가지다. 속도, 지적 사항의 품질, 저장소별 리뷰 깊이다. Anthropic에 따르면 이제 대부분의 리뷰가 약 6~10분 안에 끝난다. 프리뷰 기간에는 약 20분이 걸렸다 ^[1]. 또 중요한 버그를 더 많이 찾아내고, 지적 사항마다 문제가 무엇인지, 어떤 조건에서 생기는지, 어떻게 고치는지를 몇 문장으로 짧게 적는다고 밝혔다.

자격을 갖춘 Claude Enterprise 조직은 2027년 1월 15일까지 최소 $10,000 상당의 Code Review 크레딧을 받을 수 있고, 크레딧은 받은 날부터 30일 뒤에 만료된다 ^[1]. 발표문은 별도 약관이 적용된다고만 하고 약관 내용은 밝히지 않는다.

Code Review는 어떻게 동작하나?

Code Review는 리뷰마다 Anthropic 인프라에서 찾기, 검증, 순위 매기기, 게시의 4단계를 거친다 ^[2]. 먼저 여러 에이전트가 변경분(diff)과 주변 코드를 병렬로 살핀다. 검증 단계에서는 후보 지적 사항을 실제 코드와 대조해 오탐(false positive)을 걸러 낸다. 남은 지적 사항은 중복을 없애고 심각도 순으로 정렬한 뒤 PR에 게시한다.

리뷰가 끝나면 문제가 된 줄에 인라인 댓글이 달리고, 리뷰 본문에 요약이 남으며, "Claude Code Review"라는 이름의 체크 런(check run)이 생긴다 ^[2]. 체크 런의 결과는 중립(neutral)이고, 푸시에서 바뀐 파일이 없으면 건너뜀(skipped)이 된다. 실패로 끝나는 일은 없으므로 리뷰가 끝나도 필수 체크가 실패하지 않는다 ^[6]. 리뷰는 PR을 승인하지도 막지도 않는다. 머지 여부는 여전히 팀이 정한다 ^[2].

기본 설정에서 Code Review가 찾는 대상은 프로덕션을 망가뜨릴 정확성 문제다. 코드 형식 취향이나 빠진 테스트 커버리지는 찾지 않는다 ^[2]. 리뷰 중에는 저장소를 읽기만 할 수 있고, 커밋을 푸시하지 않으며, 코드를 빌드하거나 실행하지 않고 읽어서만 판단한다. 사용할 Claude 모델도 Code Review가 직접 고른다. 관리자 설정에는 모델을 고르는 항목이 없으므로, 리뷰 깊이를 조절할 수단은 리뷰 수준 하나뿐이다.

심각도 단계

지적 사항에는 다음 세 가지 심각도 중 하나가 붙는다 ^[6].

• Important: 머지하기 전에 고쳐야 할 버그다.
• Nit: 사소한 문제다. 고칠 만하지만 머지를 막을 정도는 아니다.
• Pre-existing: 코드베이스에 원래 있던 버그로, 이번 PR이 만든 문제는 아니다.

리뷰 수준 Quick, Standard, Deep은 어떻게 다른가?

리뷰 수준은 꼼꼼함과 시간·비용을 맞바꾸는 설정이다. Quick은 가장 가볍고 저렴한 단계이고, Standard는 깊이와 속도, 비용 사이에서 균형을 잡은 기본값이며, Deep은 가장 꼼꼼하지만 시간도 비용도 가장 많이 드는 단계다 ^[3]. 조직 소유자(Owner)는 조직 전체의 기본값을 하나 정하고, 특정 저장소에만 다른 수준을 줄 수 있다. 예를 들어 일상적인 코드베이스에는 Quick을, 중요한 코드베이스에는 Deep을 쓰는 식이다 ^[2]. 수준을 바꾸면 바꾼 뒤에 시작하는 리뷰부터 적용된다 ^[3].

문서에는 수준별 가격이 나와 있지 않다. Code Review에는 리뷰 한 건당 고정 가격이 없다. 토큰 사용량에 따라 사용 크레딧(usage credits)으로 청구되고, 요금제에 포함된 사용량과는 따로 계산되며, PR을 열었거나 리뷰를 요청한 개발자가 아니라 조직 앞으로 청구된다 ^[4]. 리뷰마다 비용은 리뷰 수준, 변경 규모, 주변 코드의 복잡도, 검증해야 할 후보 문제의 수에 따라 늘어난다.

비용을 좌우하는 또 하나의 요소는 리뷰를 얼마나 자주 돌리느냐다. 저장소마다 "Review runs" 설정이 있고, 선택지는 세 가지다 ^[3].

관리자 페이지에서 추가한 저장소는 "After every push"로 시작하는데, 세 설정 가운데 리뷰를 가장 많이 돌리는 설정이다 ^[4]. 자동 리뷰는 어느 설정에서든 초안(draft) PR과 포크에서 온 PR을 건너뛴다 ^[3].

Code Review는 어떻게 설정하고 시범 운영하나?

Claude 조직의 소유자(Owner)가 Claude Code 관리자 설정에서 Code Review를 켜고, Claude GitHub App을 설치한 뒤 리뷰할 저장소를 고른다. 설정을 마치면 저장소에 워크플로 파일을 두지 않아도 새 PR마다 리뷰가 돌아간다 ^[1][3]. 앱을 설치하려면 GitHub 조직의 소유자가 있어야 하고, 저장소를 추가하려면 연결된 GitHub 계정에 해당 저장소의 쓰기 권한이 있어야 한다 ^[3].

비용 문서는 넓게 도입하기 전에 작은 규모로 먼저 시범 운영해 보라고 권한다 ^[4].

1. Claude Code Review 서비스에 월 지출 한도를 정한다.
2. 대표성 있는 저장소 몇 개에서 Code Review를 켜고, "Review runs"를 "Once after PR creation"이나 "Manual (@claude review)"로 둔다.
3. 리뷰가 몇 번 쌓이면 관리자 설정의 Repositories 표에서 저장소별 "Average cost" 열을 확인한다.
4. 이 평균에 월간 PR 수를 곱한다. "After every push"라면 PR당 일반적인 푸시 횟수도 곱한다.

Code Review 지출 한도나 조직 지출 한도, 사용 크레딧 잔액이 바닥나거나, 남은 금액이 리뷰 한 건의 예상 비용보다 적으면 Code Review는 리뷰를 건너뛴다. 이때 개발자는 PR에서 원인을 밝힌 댓글을 보게 된다 ^[4]. GitHub 조직 전체를 한 번에 리뷰 대상으로 삼으려면 github.com 조직이어야 하고, 월 지출 한도도 정해 두어야 한다 ^[3].

PR에서 리뷰 요청하기

저장소에 쓰기(write), 유지 관리(maintain), 관리자(admin) 권한 중 하나가 있는 사람은 누구나 @claude review로 시작하는 최상위 댓글을 남겨 리뷰를 시작할 수 있다 ^[6]. @claude review always를 남기면 이후 푸시마다 리뷰가 돌도록 PR이 구독된다. 봇이 남긴 댓글로는 리뷰가 시작되지 않는다. 2026년 7월 업데이트 전에는 @claude review만으로도 PR이 구독됐다. 이 동작에 기대던 팀은 이제 always를 붙여야 한다.

CI에서 리뷰 결과에 따라 머지를 막고 싶다면 체크 런 상세 텍스트의 마지막 줄을 쓰면 된다. 이 줄에는 기계가 읽을 수 있는 형식으로 심각도별 개수가 들어 있고, normal 키의 값이 Important 지적 사항의 수다 ^[6].

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

문서는 이 줄이 없다고 해서 지적 사항이 없다는 뜻은 아니며, 판정 자체가 없다는 뜻이라고 경고한다. 실패했거나, 시간이 초과됐거나, 취소됐거나, 새 리뷰로 대체된 리뷰는 이 줄을 남기지 않기 때문이다.

REVIEW.md와 CLAUDE.md는 지적 대상을 어떻게 바꾸나?

저장소 안의 두 파일이 리뷰 방향을 정한다. CLAUDE.md에는 Code Review가 맥락으로 읽는 프로젝트 지침을 두고, REVIEW.md에는 무엇을 지적할지, 어떤 심각도로 볼지, 무엇을 건너뛸지처럼 리뷰에만 쓰는 지침을 둔다 ^[5]. 짧은 REVIEW.md는 다음과 같다.

# Review instructions

## Cap the nits
Report at most five Nits per review.

## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/`

Code Review는 REVIEW.md를 PR 자체의 변경분이 아니라 기준(base) 브랜치나 기본 브랜치에서 읽는다 ^[5]. 심각도를 낮추거나, 경로를 제외하거나, Nit 개수에 상한을 두는 식으로 리뷰를 완화하는 지침은 루트 파일이 보호된 기본 브랜치에서 왔을 때만 반영된다. 로컬 /code-review 명령은 CLAUDE.md는 읽지만 REVIEW.md는 읽지 않는다. 두 툴이 모두 따라야 할 지침은 CLAUDE.md에 두어야 한다.

AI 에이전트를 쓰는 팀에는 어떤 의미가 있나?

코딩 에이전트가 사람과 나란히 PR을 여는 팀이라면, Code Review는 모든 변경을 읽지만 머지는 할 수 없는 에이전트 무리를 하나 더 두는 셈이다. 설계상 결정권은 사람에게 남는다. 리뷰는 읽기 전용이고, 승인도 차단도 하지 않으며, 체크 런은 실패하지 않는다 ^[2][6]. 머지 결정을 누가 내리는지는 바꾸지 않고 리뷰어를 한 명 더 들일 수 있다는 뜻이다.

정식 출시에서 실무에 가장 와닿는 변화는 저장소별 리뷰 수준이다. 사내 툴에는 Quick, 대부분의 서비스에는 Standard, 결제나 인증 코드에는 Deep을 쓰고, PR이 많은 저장소는 "Once after PR creation"으로 두면 지출을 예측하기 쉬워진다 ^[3][4].

한계와 남은 질문은?

Code Review는 GitHub 저장소에서만 동작한다. GitHub Enterprise Server와 데이터 레지던시를 쓰는 GitHub Enterprise Cloud도 대상에 들어간다 ^[2]. 제로 데이터 보존(ZDR)이나 HIPAA 구성을 쓰는 조직은 쓸 수 없고, Anthropic의 비즈니스 어소시에이트 계약(BAA) 적용 대상도 아니며, 고객이 관리하는 암호화 키와 함께 쓸 수도 아직 없다. Amazon Bedrock, Google Cloud의 Agent Platform, Microsoft Foundry로 Claude Code를 쓰는 팀도 Team이나 Enterprise 요금제의 Claude 조직이 있어야 하고, 리뷰 비용은 Anthropic 청구서에 올라간다 ^[2][4].

2026년 10월 17일 기준으로 풀리지 않은 질문도 있다. 발표문은 "중요한 버그를 더 많이 찾는다"는 주장의 근거가 되는 벤치마크를 내놓지 않았다. 문서는 수준별로 어떤 모델을 쓰는지 밝히지 않고, 수준별 가격도 공개하지 않는다. 결국 믿을 만한 비용 수치는 직접 해 본 시범 운영 결과뿐이다. 문서는 지적 사항이 없는 리뷰라고 해서 코드에 오류가 없거나 안전하다는 뜻은 아니라는 점도 짚는다 ^[2].