Claude Code 코드 리뷰 활용 — `/commit`도 `/pr`도 없더니 리뷰엔 내장 명령이 *셋*이다(`/code-review`·`/review`·`/security-review`), 좋은 리뷰의 축은 *분리*(방금 쓴 코드에 편향되지 않는 fresh context), effort가 정하는 발견의 폭, 결과의 세 출구(보고·`--fix`·`--comment`), 클라우드에서 검증까지 하는 `/code-review ultra`, 그리고 체크리스트를 못 박는 `REVIEW.md`

들어가며

39차시는 이렇게 끝났다 — 생성한 PR을 그대로 신뢰하지 말고, 리뷰한다. 37차시(안전 원칙)에서 38차시(커밋), 39차시(PR)로 이어진 섹션 8의 여정이 이번 차시에서 닫힌다. 변경을 분석하고, 커밋으로 쌓고, PR로 올렸으면, 이제 그 PR을 읽을 차례다.

에이전트가 코드를 쓰는 비중이 커질수록 리뷰의 위치가 달라진다. 사람이 다 쓰던 시절의 리뷰가 다른 사람의 관문이었다면, 에이전틱 코딩에서 리뷰는 워크플로우 안의 한 단계다 — 커밋과 PR 사이 어딘가에서, 혹은 PR이 열린 직후에, 기계적으로 돌아야 하는 단계. 그래서 이 차시는 세 가지를 다룬다. 리뷰를 부르는 도구(내장 명령들), 리뷰가 좋아지는 원리(분리), 그리고 리뷰 결과를 코드로 되먹이는 흐름(피드백 적용).

시작은 38·39차시와 정반대의 반전이다.

반전 — 이번엔 전용 명령이 있다, 셋이나

38차시에서 /commit이 없다는 걸 배웠고, 39차시에서 /pr이 없다는 걸 배웠다. 두 차시를 지나며 패턴이 잡혔을 것이다 — “Git 작업은 자연어로 부르고, Claude가 절차로 굴린다.” 그런데 리뷰에 오면 이 패턴이 뒤집힌다. 리뷰엔 전용 내장 명령이 셋이나 있다. 명령 레퍼런스가 “출시 전(Before you ship)” 단계의 도구를 이렇게 요약한다.

/diff shows what changed, /code-review checks the diff for correctness bugs and cleanups and can apply the findings with --fix, /review runs the same read-only review on a GitHub pull request, and /security-review gives a deeper read-only pass. /code-review ultra runs a multi-agent review in the cloud.

표로 정리하면 이렇다.

명령	대상	하는 일
`/code-review`	현재 diff(내 작업)	정확성 버그 + 재사용·단순화·효율 정리 거리를 찾는다. 번들 스킬
`/review [PR]`	GitHub PR(주로 남의 작업)	같은 리뷰 엔진으로 PR을 리뷰. 인자 없으면 열린 PR 목록에서 고른다
`/security-review`	현재 브랜치의 변경	보안 취약점만 깊게 — injection, 인증 문제, 데이터 노출
`/code-review ultra`	브랜치 또는 PR	클라우드에서 멀티 에이전트 리뷰(구 `/ultrareview`는 별칭)

커밋과 PR은 자연어였는데 왜 리뷰만 명령으로 굳었을까. 편의 때문만은 아니다. 이 차시의 중심 명제가 그 답이다.

좋은 리뷰의 축은 ‘분리’다

커밋 메시지와 PR 본문을 쓸 때, 작업하던 세션의 컨텍스트는 자산이었다. 그 세션이 변경의 이유를 알고 있으니, “무엇이 아니라 왜”(38차시)를 쓸 수 있었다.

리뷰에서는 정확히 같은 것이 부채가 된다. 베스트 프랙티스 문서가 한 문장으로 못 박는다.

A fresh context improves code review since Claude won’t be biased toward code it just wrote.

방금 코드를 쓴 컨텍스트는 그 코드를 리뷰하기에 나쁘다 — 자기가 쓴 코드에 편향되기 때문이다. “이 코드가 맞다”고 판단하며 썼던 그 추론이 컨텍스트에 그대로 남아 있으니, 같은 컨텍스트로 다시 보면 같은 결론이 나온다. 사람 리뷰에서 “본인 PR은 본인이 승인하지 않는다”는 규칙과 같은 원리다.

그래서 /code-review는 현재 세션이 아니라 fresh subagent(깨끗한 컨텍스트의 서브에이전트, 27차시)에서 돈다. 문서의 표현이 정확하다.

a reviewer running in a fresh subagent context sees only the diff and the criteria you give it, not the reasoning that produced the change, so it evaluates the result on its own terms.

리뷰어는 diff와 판단 기준만 본다. 그 코드를 낳은 추론 과정은 보지 않는다. 그래서 결과물을 결과물 그 자체로 평가한다. 이게 리뷰가 자연어(“방금 코드 리뷰해줘”)가 아니라 명령으로 굳은 이유다 — 같은 세션에 대고 리뷰를 부탁하면 분리가 일어나지 않지만, /code-review는 분리를 구조적으로 보장한다.

이 분리에는 단계가 있다. 멀어질수록 리뷰가 독립적이 된다.

단계	방법	분리되는 것
0	같은 세션에서 “리뷰해줘”	없음 — 코드를 쓴 추론이 그대로 남아 있다
1	`/code-review`	컨텍스트 — fresh subagent가 diff와 기준만 본다
2	Writer/Reviewer 2세션	세션 — 리뷰어 세션은 구현 세션의 존재조차 모른다
3	`/code-review ultra`	머신 — 클라우드 fleet가 발견을 독립 재현·검증한다
4	관리형 Code Review	워크플로우 — 사람이 부르지 않아도 PR마다 저장소에서 돈다

이 차시의 나머지는 이 사다리를 아래에서부터 오른다.

`/code-review` 해부 — 스코프, effort, 타깃

문법부터. 명령 레퍼런스의 시그니처는 이렇다.

/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [target]

무엇을 찾나. 두 축이다 — 정확성 버그(correctness bugs)와 정리 거리(재사용·단순화·효율 cleanups). 스타일 취향이 아니라 “동작이 틀린 곳”과 “이미 있는 걸 다시 만든 곳”을 본다.

무엇을 보나(기본 스코프). 문서의 정의가 흥미롭다.

By default the local review covers your branch’s commits ahead of its upstream plus any uncommitted changes in the working tree.

“업스트림보다 앞선 브랜치 커밋들 + 작업 트리의 미커밋 변경.” 눈치챘겠지만 이건 38차시와 39차시의 단위를 합친 것이다 — 커밋의 단위(working tree의 미커밋 변경)와 PR의 단위(브랜치가 쌓은 커밋들)를 더하면, 정확히 “지금 PR로 나가게 될 모든 것”이 된다. 39차시의 제1 규칙(“최신 커밋 하나가 아니라 브랜치 전체”)이 리뷰에도 그대로 적용되는 셈이다.

다른 걸 보고 싶으면 타깃을 넘긴다. 파일 경로, PR 번호, 브랜치명, 그리고 39차시에서 배운 3-dot ref range가 재등장한다.

/code-review src/auth/session.ts     # 특정 파일만
/code-review 123                     # GitHub PR #123
/code-review main...my-feature       # my-feature → main PR이 담을 커밋된 diff

The ref range form reviews the committed diff a pull request from my-feature into main would contain, regardless of how the branch’s upstream is configured.

effort가 발견의 폭을 정한다. 인자 없이 부르면 세션의 현재 effort(/effort로 조절)를 따르고, 명시하면 그 수준으로 돈다.

Lower effort levels return fewer, higher-confidence findings, while high through max give broader coverage and may include uncertain findings.

즉 low/medium은 적지만 확실한 발견, high~max는 넓지만 불확실한 것도 포함하는 발견이다. 커밋 직전의 빠른 점검이면 낮게, 머지 직전의 마지막 점검이면 높게 — 리뷰의 감도를 상황에 맞게 돌리는 다이얼이다.

/simplify와 헷갈리지 말 것. 이력이 좀 얽혀 있다. 이 명령은 v2.1.147 전까지 /simplify라는 이름이었고 기본으로 수정까지 적용했다. 지금은 갈라졌다 — v2.1.154부터 /simplify는 정리 전용이다. 재사용·단순화·효율·추상화 수준을 보는 4개 에이전트가 병렬로 돌아 수정까지 적용하지만, 버그는 찾지 않는다. 문서가 직접 정리해 준다.

the review does not look for correctness bugs. Use /code-review to find bugs.

버그 사냥은 /code-review, 품질 정리는 /simplify. 예전 스크립트에서 /simplify를 버그 찾기로 썼다면 /code-review --fix로 바꾸면 된다(동작이 그대로다).

결과의 세 출구 — 보고, `--fix`, `--comment`

리뷰가 끝나면 발견(findings)이 나간다. 출구는 셋이다.

① 세션 보고(기본). 발견이 대화로 돌아온다. 읽고, 물어보고, 고칠 것만 고르는 인터랙티브 모드다. 37차시의 안전 원칙이 여기서도 유지된다 — 리뷰 명령은 기본이 read-only다. 코드를 바꾸지 않는다.

② --fix — 작업 트리에 적용. 리뷰 후에 발견을 실제 코드에 반영한다. read-only 기본에서 코드를 바꾸는 유일한 명시적 옵트인이다.

/code-review high --fix

③ --comment — GitHub PR 인라인 코멘트. 발견을 세션이 아니라 PR의 해당 라인에 코멘트로 게시한다. 39차시에서 만든 PR 위에 리뷰를 남기는 출구다 — 내 리뷰 결과를 팀이 PR 페이지에서 그대로 보게 된다.

/code-review 123 --comment

`/review <PR>` — 남의 PR을 읽는다

/code-review가 주로 내 작업을 향한다면, /review는 GitHub PR — 주로 남의 작업을 향한다.

Review a GitHub pull request by number, using the same review engine as /code-review. With no arguments, lists open PRs to pick from.

엔진은 같다(비교표 기준으로 medium 수준의 /code-review 엔진). 다른 건 입구다 — PR 번호를 주면 그 PR을, 인자가 없으면 열린 PR 목록을 띄워 고르게 한다. 공식 비교표가 말하는 용도는 명확하다 — “reviewing a teammate’s PR before approving”, 팀원의 PR을 승인하기 전에 한 번 훑는 자리다.

/review 123

물론 “이 PR 리뷰해줘”라는 자연어도 통한다(Claude가 gh로 PR을 읽는다). 하지만 /review는 리뷰 절차를 굳혀 놓은 쪽이라, 매번 같은 기준으로 도는 게 장점이다.

`/security-review`와 커스텀 리뷰어

세 번째 내장은 렌즈가 좁고 깊다.

Analyze pending changes on the current branch for security vulnerabilities. Reviews the git diff and identifies risks like injection, auth issues, and data exposure

/security-review는 현재 브랜치의 변경을 보안 관점으로만 훑는다 — injection, 인증·인가 문제, 데이터 노출. 이것도 read-only다.

더 좁은 기준이 필요하면 커스텀 리뷰어를 직접 만든다. 베스트 프랙티스 문서의 예제가 정확히 이 자리다 — .claude/agents/security-reviewer.md(27차시의 커스텀 서브에이전트).

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

읽기 도구만 주고(read-only 리뷰어), 시스템 프롬프트에 체크리스트를 박아 넣었다. 이렇게 만들어 두면 “Use a subagent to review this code for security issues”라고 부를 때마다 같은 기준으로 돈다. 리뷰 기준을 사람 머릿속이 아니라 파일로 관리하는 방법이다.

리뷰 체크리스트 — 도구에 매핑하고, 구멍은 프롬프트로 메운다

커리큘럼이 제시하는 리뷰 체크리스트는 다섯 항목이다. 지금까지 본 도구에 매핑해 보자.

체크리스트 항목	담당 도구
코드 품질·가독성	`/code-review`의 정리 축(재사용·단순화), `/simplify`
잠재적 버그	`/code-review`의 정확성 축, ultra의 독립 검증
성능 이슈	`/code-review`·`/simplify`의 효율(efficiency) 축
보안 취약점	`/security-review`, 커스텀 security-reviewer
테스트 누락	기본 리뷰가 안 본다 — 커스텀 영역

네 항목은 내장이 커버하는데, 마지막 줄이 눈에 띈다. 공식 문서가 기본 리뷰의 범위를 이렇게 선언하기 때문이다.

By default, Code Review focuses on correctness: bugs that would break production, not formatting preferences or missing test coverage.

기본 리뷰는 프로덕션을 깨뜨릴 버그에 집중하고, 포맷 취향과 테스트 커버리지 누락은 보지 않는다. 테스트 누락까지 잡고 싶으면 기준을 직접 넘겨야 한다. 방법은 커스텀 리뷰 프롬프트다 — 베스트 프랙티스의 예제가 좋은 본보기다.

서브에이전트로 rate limiter diff를 PLAN.md와 대조해서 리뷰해줘.
모든 요구사항이 구현됐는지, 명시된 엣지 케이스마다 테스트가 있는지,
태스크 범위 밖의 변경이 없는지 확인해줘.
스타일 취향 말고, 빠진 것(gaps)만 보고해줘.

원문의 마지막 문장이 리뷰 프롬프트의 정수다 — “Report gaps, not style preferences.” 계획 대비 빠진 것을 찾되, 취향을 논하지 말라. 좋은 리뷰 요청은 무엇을 기준으로(PLAN.md), 무엇을 발견으로 칠지(빠진 요구사항, 테스트 없는 엣지 케이스, 범위 밖 변경)까지 명시한다.

그리고 반대 방향의 경고도 문서에 있다. 리뷰어는 찾으라면 찾는다.

A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. Chasing every finding leads to over-engineering

멀쩡한 코드에서도 발견은 나온다 — 그게 리뷰어가 받은 임무니까. 모든 발견을 다 고치려 들면 불필요한 추상화 계층, 방어 코드, 일어날 수 없는 케이스의 테스트가 쌓인다(과잉 설계). 문서의 처방은 명확하다 — 정확성이나 명시된 요구사항에 영향을 주는 발견만 반영하고, 나머지는 선택지로 취급한다.

분리의 끝 — `/code-review ultra`

사다리의 3단, 리뷰가 아예 다른 머신으로 떠난다. /code-review ultra(v2.1.86+, 리서치 프리뷰. /ultrareview는 별칭으로 남아 있다)는 Claude Code on the web 인프라의 원격 샌드박스에 리뷰어 에이전트 fleet를 띄운다. 로컬 리뷰 대비 세 가지가 다르다.

신호가 높다 — “every reported finding is independently reproduced and verified”. 보고되는 모든 발견이 독립적으로 재현·검증된다. 스타일 제안이 아니라 진짜 버그에 수렴한다.
커버리지가 넓다 — 더 큰 fleet가 병렬로 탐색해, medium 수준 로컬 리뷰가 놓치는 문제를 잡는다.
로컬 자원을 안 쓴다 — 리뷰가 도는 동안 터미널은 자유다.

스코프와 실행. 인자 없이 부르면 현재 브랜치 vs 기본 브랜치 diff에 미커밋·스테이징 변경까지 얹어 저장소 상태를 번들로 업로드한다. PR 번호를 주면(/code-review ultra 1234) 샌드박스가 호스트에서 PR을 직접 클론한다(저장소가 너무 커서 번들이 안 되면 PR 모드를 권한다). 실행 전에 확인 다이얼로그가 뜬다 — 리뷰 범위(파일·라인 수), 남은 무료 횟수, 예상 비용. 그리고 중요한 한 줄.

The command runs only when you invoke it with /code-review ultra; Claude does not start an ultrareview on its own.

명시적으로 불러야만 돈다. Claude가 알아서 유료 리뷰를 시작하는 일은 없다 — 37차시 안전 원칙(외부로 나가는 것은 요청해야만)의 리뷰 판이다.

진행과 결과. 보통 5~10분 걸리고 백그라운드 태스크로 돌아, 그동안 계속 작업할 수 있다(/tasks로 확인·중단). 단, 중단하면 부분 결과도 없다 — 클라우드 세션이 아카이브될 뿐이다. 완료되면 검증된 발견이 세션 알림으로 도착하고, 발견마다 파일 위치와 설명이 붙어 있어 바로 “고쳐줘”로 이을 수 있다. --fix를 함께 주면(/code-review ultra --fix) 발견이 도착하는 대로 작업 트리에 적용까지 된다.

비용. Pro/Max 구독자는 무료 3회 — 계정당 1회성 제공이고 갱신되지 않으며, 조기 중단·실패도 1회로 친다. 그 후에는 회당 대략 $5~20이 usage credits로 청구된다(Team/Enterprise는 무료분 없음). Claude.ai 계정 인증이 전제라 API 키 단독 로그인이면 /login이 먼저고, Bedrock·Vertex·Foundry 경유나 Zero Data Retention 조직에서는 쓸 수 없다.

CI에서도 부른다. 비대화형 서브커맨드가 따로 있다.

claude ultrareview            # 현재 브랜치 vs 기본 브랜치
claude ultrareview 1234       # PR 리뷰
claude ultrareview --json --timeout 20

완료까지 블록하고 발견을 stdout에 출력한다(--json이면 raw bugs.json). 성공 시 exit 0, 실패·타임아웃 시 1 — 파이프라인 게이트로 쓸 수 있는 형태다. 이 흐름은 41차시(CI/CD)에서 다시 만난다.

셋을 언제 쓰나. 공식 비교표를 요약하면 이렇다.

	`/code-review`	`/review <pr>`	`/code-review ultra`
대상	내 작업 diff	GitHub PR	작업 diff 또는 PR
실행 위치	로컬 세션	로컬 세션	클라우드 샌드박스
깊이	effort에 비례	medium 엔진	fleet + 독립 검증
시간	초~수 분	수 분	5~10분
비용	일반 사용량	일반 사용량	무료 3회 후 대략 $5~20
적합한 때	작업 중 빠른 피드백	팀원 PR 승인 전	큰 변경의 머지 전 확신

피드백 적용 — 리뷰는 읽고 끝이 아니다

리뷰의 가치는 발견이 아니라 되먹임에서 나온다. 방향은 셋이다.

① Claude의 발견 → 코드. 가장 짧은 길은 --fix다. 인터랙티브하게 가려면 발견을 보고받은 뒤 고를 것만 고른다 — “1번과 3번 발견만 고쳐줘. 2번은 의도된 동작이야.” ultra의 발견도 같다 — 위치·설명이 붙어 오니 그대로 수정을 지시하면 된다.

② 리뷰어 세션 → Writer 세션. 사다리 2단의 Writer/Reviewer 패턴은 피드백 루프까지가 한 세트다. 베스트 프랙티스의 시나리오를 옮기면 이렇다.

세션 A (Writer)	세션 B (Reviewer)
“API 엔드포인트용 rate limiter를 구현해줘"
	"@src/middleware/rateLimiter.ts 의 rate limiter 구현을 리뷰해줘. 엣지 케이스, 레이스 컨디션, 기존 미들웨어 패턴과의 일관성을 봐줘"
"리뷰 피드백이야 — [세션 B 출력]. 이 이슈들을 해결해줘”

리뷰어 세션의 출력을 Writer 세션에 그대로 붙여 넣는 마지막 행이 루프를 닫는다. 같은 원리로 테스트를 뒤집을 수도 있다 — 한 Claude가 테스트를 쓰고, 다른 Claude가 그 테스트를 통과하는 코드를 쓴다.

③ 사람 리뷰어의 코멘트 → 코드. 내가 올린 PR에 팀원이 리뷰를 남겼다면, 그 피드백을 읽어 오는 것도 Claude의 일이다. 39차시에서 봤듯 전용 명령(/pr-comments)은 v2.1.91에서 제거됐고, 이제 자연어로 부탁하면 Claude가 gh로 가져온다.

PR 123에 달린 리뷰 코멘트를 정리하고, 하나씩 어떻게 반영할지 제안해줘

내부에서 도는 건 이런 gh 호출이다 — PR의 인라인 리뷰 코멘트를 가져오는 GitHub API다.

gh api repos/owner/repo/pulls/123/comments

그리고 이 흐름의 진짜 지름길은 39차시가 깔아 놨다 — claude --from-pr 123. PR을 만든 세션이 PR에 링크돼 있으니, 리뷰 코멘트가 달리면 그 작업 맥락 그대로 돌아와서 피드백을 반영하고, 38차시의 커밋 절차로 수정 커밋을 쌓아 푸시하면 된다. 생성(39차시)과 리뷰 반영(40차시)이 하나의 세션 히스토리로 이어진다.

저장소에 상주하는 리뷰 — 관리형 Code Review

사다리의 마지막 단은 리뷰가 저장소 자체에 상주하는 형태다. 관리형 Code Review(Team/Enterprise 구독의 리서치 프리뷰, GitHub App 설치)는 PR이 열리거나 푸시될 때마다 Anthropic 인프라에서 특화 에이전트 fleet가 돌아, 전체 코드베이스 맥락에서 로직 오류·보안 취약점·깨진 엣지 케이스·미묘한 회귀를 찾고, 검증 스텝이 실제 코드 동작과 대조해 오탐을 걸러낸 뒤, 문제의 라인에 인라인 코멘트로 게시한다.

수동으로 부르는 명령은 PR 코멘트다 — @claude review(리뷰 시작 + 이후 푸시마다 구독) 또는 @claude review once(1회만). 발견에는 심각도가 태깅된다.

마커	심각도	의미
🔴	Important	머지 전에 고쳐야 할 버그
🟡	Nit	사소한 문제 — 고치면 좋지만 블로킹은 아님
🟣	Pre-existing	이 PR이 만든 게 아닌, 원래 있던 버그

중요한 설계가 하나 있다 — 승인도 차단도 하지 않는다. 체크런은 항상 neutral로 끝나, 기존 리뷰 워크플로우(사람의 승인)를 건드리지 않는다. 발견 수로 머지를 게이트하고 싶으면 체크런 출력의 기계 판독용 심각도 JSON을 CI에서 직접 파싱한다(gh api ... check-runs/... --jq ... 형태로 {"normal": 2, "nit": 1, ...}을 얻는다).

그리고 체크리스트를 못 박는 자리가 여기 있다. 두 파일이 리뷰 기준을 조정한다.

CLAUDE.md(21차시) — 프로젝트 규칙의 새로 생긴 위반이 Nit 발견으로 잡힌다. 양방향이라, PR이 CLAUDE.md의 서술을 낡게 만들면 문서를 고치라고도 지적한다.
REVIEW.md — 저장소 루트의 리뷰 전용 지침. 리뷰 파이프라인의 모든 에이전트에 최우선 순위로 주입된다. 심각도 재정의(“이 저장소에서 Important란…”), Nit 개수 상한, 스킵 규칙(생성 파일·lockfile), 저장소 전용 체크(“새 API 라우트엔 통합 테스트 필수” — 앞의 테스트 누락 구멍이 여기서 메워진다), 발견의 증거 기준(“동작 주장엔 file:line 인용 필수”) 등을 적는다. 단, 원문 그대로 붙는 파일이라 @ import는 확장되지 않는다 — 규칙을 파일 안에 직접 쓴다.

비용은 리뷰당 평균 $15~25(usage credits 별도 청구, 평균 20분), 코멘트에 미리 달려 있는 👍/👎로 발견을 평가하면 머지 후 수집돼 리뷰어 튜닝에 쓰인다. 주의할 것 하나 — 인라인 코멘트에 답글을 달아도 Claude는 반응하지 않는다. 발견을 반영하려면 코드를 고쳐 푸시하거나(푸시 구독 시 다음 리뷰가 스레드를 자동 해소) @claude review once로 새 리뷰를 부른다.

여기까지 오면 리뷰는 더 이상 사람이 부르는 것이 아니라 저장소에서 일어나는 것이다 — 그리고 그게 정확히 다음 차시의 주제다.

흔한 함정

리뷰도 자연어로만 한다. 커밋·PR과 달리 리뷰엔 내장이 셋 있다 — /code-review(내 diff), /review(GitHub PR), /security-review(보안). 특히 같은 세션에 “리뷰해줘”는 분리가 없다.
방금 코드를 쓴 세션에서 리뷰한다. 그 컨텍스트는 자기 코드에 편향된다(“won’t be biased toward code it just wrote”의 반대면). fresh subagent(/code-review)나 별도 세션으로.
effort를 모른 채 발견 개수에 놀란다. low/medium은 적고 확실, high~max는 넓고 불확실 포함. 인자가 없으면 세션의 현재 effort를 따른다.
/simplify로 버그를 찾으려 한다. v2.1.154부터 /simplify는 정리 전용이다 — 버그는 /code-review(스크립트라면 /code-review --fix로 교체).
발견을 전부 고친다. 리뷰어는 찾으라면 멀쩡한 코드에서도 찾는다. 다 반영하면 과잉 설계 — 정확성·요구사항에 영향 있는 것만.
테스트 누락을 기본 리뷰가 잡아줄 거라 기대한다. 기본은 정확성 집중 — 테스트 커버리지는 안 본다. 커스텀 프롬프트(“엣지 케이스마다 테스트가 있는지”)나 REVIEW.md(“새 API 라우트엔 통합 테스트”)로 명시한다.
ultra가 알아서 돌 거라 기대하거나, 무료 3회가 매달 갱신된다고 생각한다. ultra는 명시 호출로만 돌고, 무료 3회는 계정당 1회성이다 — 중단·실패도 1회로 소모된다.
ultra를 중간에 멈추면 부분 결과라도 남을 거라 생각한다. 없다. 세션이 아카이브될 뿐이다 — 멈출 거면 시작 전에 스코프를 줄인다.
(관리형) 인라인 코멘트에 답글로 대화를 시도한다. 반응하지 않는다. 고쳐서 푸시하거나 @claude review once. GitHub Checks 탭의 Re-run 버튼도 재트리거가 안 된다.
--fix가 기본인 줄 안다. 리뷰 명령은 기본이 read-only다(37차시 원칙). 코드를 바꾸는 건 --fix라는 명시적 옵트인뿐이다.

정리

핵심 요점

리뷰엔 전용 내장 명령이 있다 — 셋이나. /commit(38차시)도 /pr(39차시)도 없던 자리에, /code-review(현재 diff의 버그+정리), /review <PR>(같은 엔진으로 GitHub PR), /security-review(injection·인증·데이터 노출)가 있다.
좋은 리뷰의 축은 분리다. 방금 쓴 코드의 컨텍스트는 그 코드에 편향된다. 그래서 /code-review는 fresh subagent에서 돈다 — 리뷰어는 diff와 기준만 보고, 코드를 낳은 추론은 보지 않는다. 사다리: 서브에이전트 → 2세션 → 클라우드 → 저장소 상주.
/code-review의 기본 스코프 = 업스트림보다 앞선 커밋 + 미커밋 변경. 38차시(working tree)와 39차시(브랜치) 단위의 합집합 — “지금 PR로 나갈 모든 것”. 타깃으로 파일·PR 번호·브랜치·main...my-feature(3-dot)를 받는다.
effort가 발견의 폭, 출구는 셋. low=적고 확실 ↔ max=넓고 불확실 포함. 결과는 세션 보고(기본), --fix(작업 트리 적용), --comment(PR 인라인 코멘트)로 나간다. /simplify는 v2.1.154부터 정리 전용 — 버그는 /code-review.
체크리스트는 도구에 매핑하고, 구멍은 명시한다. 품질·버그·성능은 /code-review, 보안은 /security-review(또는 커스텀 security-reviewer). 테스트 누락은 기본 리뷰 밖 — “Report gaps, not style preferences”식 커스텀 프롬프트나 REVIEW.md로. 발견을 다 고치면 과잉 설계다.
/code-review ultra = 분리의 끝. 클라우드 fleet가 발견을 독립 재현·검증한다. 5~~10분 백그라운드(/tasks), Pro/Max 무료 3회(1회성) 후 대략 $5~~20, 명시 호출로만. CI에선 claude ultrareview.
리뷰는 되먹여야 끝난다. Claude의 발견은 --fix나 선별 수정으로, 2세션 패턴은 리뷰 출력을 Writer에 붙여넣어, 사람 코멘트는 자연어+gh(gh api repos/owner/repo/pulls/123/comments)로 읽고 claude --from-pr로 그 세션에서 고친다. 관리형 Code Review는 @claude review, 🔴🟡🟣 심각도, 승인·차단 없음.

다음 단계

섹션 8이 끝났다 — 변경 확인(37), 커밋(38), PR(39), 리뷰(40)까지, Git 워크플로우의 한 사이클을 Claude와 함께 도는 법을 모두 봤다. 그런데 이 차시의 끝에서 리뷰는 이미 사람이 부르지 않아도 도는 형태(관리형 Code Review, claude ultrareview)로 넘어가고 있었다. **41차시(CI/CD 개념과 연동)**가 정확히 그 방향이다 — GitHub Actions에 Claude를 태우고, 헤드리스(claude -p)로 파이프라인에 끼워 넣고, 커밋·PR·리뷰의 사이클 전체를 자동화한다. 사람의 터미널에서 팀의 파이프라인으로, 무대가 옮겨간다.