Claude `/code-review` — 무엇이 달라졌나

/simplify는 어디로 갔을까

얼마 전에 /simplify + 서브에이전트로 코드 리뷰를 한 번에 끝내는 글을 썼는데요, Claude Code 업데이트로 그 /simplify 커맨드가 /code-review로 개편됐습니다. 이름만 바뀐 게 아니라 동작 방식도 꽤 달라졌어요.

이전 글을 읽으셨다면 이 글로 따라잡으시면 되고, 안 읽으셨어도 괜찮습니다. 변경점만 따로 정리했으니까요.

한눈에 보는 변경점

무엇이 진짜 달라졌나

1. 정확성 결함(correctness bug) 검출이 명시적으로 들어왔어요. 기존 /simplify는 재사용성·품질·효율성 3개 관점이었는데, /code-review는 여기에 “이 코드가 의도한 대로 동작하는가”를 직접 확인합니다. 이름이 simplify에서 code-review로 바뀐 것도 이 방향성을 반영한 거예요. 단순 정리가 아니라 진짜 리뷰에 가까워졌습니다.

2. 강도를 고를 수 있게 됐어요. 이전에는 한 가지 모드만 있었지만, 이제는 low부터 ultra까지 5단계로 검토 깊이를 조절할 수 있습니다. 조용한 1차 점검부터 클라우드 멀티에이전트 심층 리뷰까지 한 커맨드로 커버해요.

3. 결과 처리가 분리됐어요. /simplify는 검토와 자동 수정이 한 묶음이었는데, /code-review는 둘이 갈라졌습니다. 검토만 하고 결과를 보거나(--comment), 바로 워킹 트리에 적용하거나(--fix)를 선택할 수 있어요.

4. 기존 사용자도 그대로 쓸 수 있어요. /simplify는 alias로 남아 있어서 그대로 호출하면 /code-review --fix와 동일하게 동작합니다. 이전 글의 워크플로우를 그대로 쓰셔도 됩니다.

effort level, 어떻게 고를까

기본값으로 시작하다가, 변경 범위가 클 때만 한두 단계 올리는 식으로 쓰시면 돼요.

플래그 두 개 — --fix vs --comment

/code-review의 결과를 어떻게 처리할지는 두 플래그로 정합니다.

• --fix — 검토 결과를 바로 워킹 트리에 반영합니다. 기존 /simplify의 동작이 여기로 옮겨왔어요. 커밋 전에 빠르게 정리할 때.
• --comment — 결과를 자동 수정 대신 GitHub PR에 인라인 코멘트로 게시합니다. 팀 리뷰어가 들어오기 전에 셀프 리뷰 흔적을 남기는 용도예요.

실전 예시는 이런 식이에요.

# 커밋 전 로컬 정리
/code-review --fix

# PR 올린 직후 셀프 리뷰 코멘트 남기기
/code-review high --comment

# 중요한 머지 직전 풀 리뷰
/code-review ultra --comment

이전 글의 워크플로우는 여전히 유효한가

이전 글에서 다룬 세 가지 통합 방법(커스텀 슬래시 커맨드, Hooks, CLAUDE.md 정책)은 그대로 유효합니다. 서브에이전트도, CLAUDE.md도 변한 게 없어요.

다만 그 안에서 /simplify를 호출하던 부분만 손보시면 됩니다. 예를 들어 이전 글의 “방법 1” 커스텀 커맨드 안에서 /simplify를 부르던 자리는 이렇게 바꿔주면 더 의도가 명확해져요.

## Step 1: /code-review 실행

최근 변경 코드에 대해 /code-review high --fix 를 실행합니다.
정확성 결함과 재사용성/단순화/효율성 이슈를 함께 확인합니다.

## Step 2: 서브에이전트 병렬 리뷰

...

이제는 같은 통합 커맨드 안에서 /code-review로 정확성까지 검토하고, 그다음 서브에이전트로 팀 컨벤션을 검토하는 식의 단계 조절이 가능해졌어요.

정리

이름만 바뀐 업데이트가 아니에요. 강도 조절과 결과 처리가 분리되면서 워크플로우 정밀도가 한 단계 올라갔습니다. /simplify로 한 번에 정리하던 흐름은 그대로 쓸 수 있고, 거기에 “PR마다 강도를 골라서 셀프 리뷰 코멘트를 남긴다”는 새로운 패턴이 추가된 셈이에요. 기존 워크플로우는 유지하면서, 중요한 PR에는 한 단계 더 깊이 볼 수 있는 손잡이가 생겼다고 보시면 됩니다.