변경 작업을 끝냈는데 린터가 빨갛게 켜지고, 결국 늘 고치던 세 가지 유형의 문제를 또 diff 안에서 고치고 있습니다. /simplify는 이 반복을 줄여 줍니다. 보고서만 내는 대신, 파일을 직접 수정합니다.
/simplify가 diff에 하는 일
/simplify는 Claude Code에 번들로 포함된 구현 후 정리 및 리뷰 패스입니다. 현재 diff에 있는 파일만 읽고, 그 변경분 위에 병렬 리뷰 에이전트를 펼친 뒤, 주석으로 지적하는 대신 파일에 바로 수정 사항을 적용합니다 . 이 마지막 부분이 린트 보고서와의 핵심 차이입니다. 파일이 표시되는 것이 아니라 실제로 바뀝니다. 전체 코드베이스가 아니라 diff만 훑기 때문에 범위도 좁게 유지되고 토큰 비용도 낮습니다.
처음 출시됐을 때는 변경된 파일을 대상으로 세 개의 에이전트가 동시에 실행됐습니다 :
- Reuse — 중복된 로직을 찾고, 방금 작성한 새 코드를 대체할 수 있는 기존 유틸리티를 드러냅니다.
- Quality — 가독성, 구조, 불필요한 상태, 새는 추상화를 짚어냅니다.
- Efficiency — 불필요한 작업, 놓친 동시성, 핫패스의 비대를 잡아냅니다.
이 스킬은 계속 더 촘촘해지고 있습니다. v2.1.160(2026년 6월 2일)에서는 다섯 개의 정리 finder를 하나로 합쳐 호출당 토큰 사용량을 약 25% 줄였습니다 . 그래서 같은 리뷰를 출시 당시보다 더 저렴하게 실행할 수 있습니다. 모든 PR에 연결하기 전에 알아둘 만한 점입니다.
이 기능을 신기한 장난감이 아니라 모든 프로젝트의 습관으로 다룰 이유는 1차 출처의 발언에서 나옵니다. 2026년 2월 27~28일, Claude Code를 만든 Anthropic 기술 스태프 Boris Cherny는 Threads와 X에서 다음 버전에 /simplify와 /batch가 포함될 것이라고 알리며, 두 기능을 "매일 사용하고 있다"고 말했습니다 .
"Been using both [/simplify and /batch] daily." — Boris Cherny, member of technical staff at Anthropic (source: Threads)
이 스킬은 번들로 제공됩니다. 자동 설치되어 모든 코드베이스의 모든 세션에 존재하므로, 이 매일 쓰는 습관을 재현하는 데 저장소별 설정은 필요 없습니다 .
PR 루틴에 /simplify 넣기
Cherny의 습관을 그대로 재현하려면 pull request를 열기 직전 마지막 단계로 /simplify를 실행하세요. 변경 사항을 먼저 작성하고, 스킬을 호출한 뒤, 작업 트리에 적용된 편집을 검토하고 커밋하면 됩니다. 이 스킬은 번들이므로 만들 .claude/skills/ 폴더도, 설치 단계도 없습니다. Claude Code에 포함되어 있으며 모든 세션에서 사용할 수 있습니다 . 최소한의 복사-붙여넣기 절차는 다음과 같습니다.
Step 1 — 버전을 확인합니다. /simplify와 /batch 스킬은 Claude Code v2.1.63에서 번들 명령으로 들어왔습니다 . 현재 실행 중인 버전을 확인하세요:
claude --version
# or, inside a session:
/versionv2.1.63 이상이라면 스킬은 이미 있습니다. 추가로 설치할 것은 없습니다.
Step 2 — 먼저 작성하고, 그다음 simplify를 실행합니다. 기능이나 수정 작업을 다 쓴 뒤, 인자 없이 /simplify를 입력하세요. 이 스킬은 diff를 자동으로 찾아 변경한 파일만 살피므로 경로를 넘길 필요가 없습니다 . 해당 diff 위에 병렬 리뷰 에이전트를 펼치고, 보고만 하는 대신 수정 사항을 직접 적용합니다 .
Step 3 — 검토한 뒤 커밋합니다. 작업 트리에 적용된 편집을 확인하세요. 명확한 감사 기록을 남기고 싶다면 별도의 정리 커밋으로 stage하고, 아니면 push하기 전에 기능 커밋에 squash하면 됩니다.
Step 4 (선택) — rebase 후 다시 실행합니다. merge나 rebase로 새 diff 파일이 들어왔다면 /simplify를 다시 호출해 추가 변경 사항까지 정리 패스가 훑게 하세요.
범위를 좁히는 단축 방식. 패스를 한 가지 관심사로 좁히려면 전체 리뷰를 실행하는 대신 focus 절을 덧붙입니다:
/simplify focus on error handling
/simplify focus on memory efficiency이렇게 하면 에이전트가 단일 차원에만 집중합니다. 효율성만 중요한 핫패스나, 오류 처리가 위험 요소인 I/O 코드에서 유용합니다 .
이름 변경: /simplify는 이제 래퍼입니다
변경 로그를 따라가 보면 /simplify와 /code-review가 서로 다른 두 도구가 아니라, 같은 스킬이 발전해 온 결과라는 점을 알 수 있습니다. v2.1.147(2026년 5월 21일)에서 /simplify는 /code-review로 이름이 바뀌었습니다. 동작도 선택 가능한 노력 수준(예: /code-review high)에 맞춰 정확성 버그를 보고하는 쪽으로 이동했고, 기존의 자동 적용 정리 동작은 제거되었습니다 . 이 변화는 수정이 바로 적용되리라 기대하던 사용자들의 습관을 깨뜨렸고, 그래서 v2.1.152(2026년 5월 27일)에서 /simplify가 내부적으로 /code-review --fix를 호출하는 얇은 래퍼로 돌아왔습니다. 많은 사용자가 의존하던 작업 트리에 바로 적용하는 동작이 복원된 것입니다 . 이후 v2.1.160(2026년 6월 2일)에서는 다섯 개의 정리 탐지기가 하나로 합쳐졌고, 호출당 토큰 사용량이 약 25% 줄었습니다 .
오늘 기준으로 실무적인 구분은 이렇습니다. /simplify는 작업 트리에 편집을 적용합니다. /code-review만 실행하면 파일을 건드리지 않고 발견 사항만 보고합니다. /code-review --comment는 발견 사항을 GitHub PR의 인라인 주석으로 게시합니다 . 의도에 맞는 동사를 고르면 됩니다. 고칠 것인지, 보고할 것인지, 주석으로 남길 것인지입니다.
| 버전 | 날짜 | 동작 변경 | /simplify에 미친 영향 |
|---|---|---|---|
| v2.1.147 | 2026-05-21 | /code-review로 이름 변경. 노력 수준별 정확성 버그 보고. 자동 적용 제거 | 제자리 수정 사라짐 |
| v2.1.152 | 2026-05-27 | /simplify 복원. 내부적으로 /code-review --fix 호출 | 제자리 적용 복원 |
| v2.1.160 | 2026-06-02 | 다섯 개의 정리 탐지기를 하나로 병합 | 실행당 토큰 약 25% 감소 |
/simplify를 더 밀어붙이는 방법
기본 패스가 습관이 되었다면, 세 가지 조절 지점으로 더 날카롭게 만들 수 있습니다. 첫째, 한 가지 관점으로 범위를 좁혀 관련 에이전트만 실행되게 하세요. /simplify focus on memory efficiency나 /simplify focus on error handling처럼 쓰면 전체 재사용/품질/효율성 검사를 돌리는 대신 리뷰 범위를 좁힙니다 (source: howborisusesclaudecode.com).
둘째, 자동 적용 편집이 아니라 리뷰어가 볼 수 있는 메모를 원한다면 /code-review --comment를 사용하세요. --comment 플래그는 작업 트리를 건드리지 않고 발견 사항을 GitHub PR 인라인 주석으로 게시하며, v2.1.147 (2026-05-21)에서 추가되었습니다 (source: Claude Code changelog). 수정 여부 판단은 사람 리뷰어에게 남겨둡니다.
셋째, /batch로 이 습관을 대규모 작업에 적용하세요. 각 /batch 워커는 자체 git worktree에서 실행되고 커밋 전에 자신의 diff에 자동으로 /simplify를 실행하므로, 생성되는 모든 PR이 추가 호출 없이 정리 패스를 거치게 됩니다 (source: claudefa.st).
조합 패턴은 이렇게 이어집니다. 큰 리팩터링은 /batch로 분해한 뒤, 각 배치 PR에 /code-review --comment를 얹어 리뷰어가 바로 볼 수 있는 주석 패스를 추가합니다. 다음 변경에서는 focus 플래그로 좁게 시작하고, 같은 규율을 마이그레이션 전체로 확장하면 됩니다.
시청 / 출처
- Anthropic — Mastering Claude Code in 30 minutes
- Matt Pocock — 5 Claude Code skills I use every single day
- Greg Isenberg — Claude Code Clearly Explained (and how to use it)
자주 묻는 질문
Claude Code에서 /simplify와 /code-review는 같은 것인가요?
두 도구가 아니라 하나의 스킬이 발전해 온 것입니다. v2.1.152(2026년 5월 27일)부터 /simplify는 /code-review --fix를 호출하는 얇은 래퍼이며, 발견 사항을 작업 트리에 직접 적용합니다 . 제자리에서 편집을 자동 적용하려면 /simplify를 입력하고, 파일을 건드리지 않은 채 발견 사항만 보고하려면 /code-review만 입력하면 됩니다.
/simplify를 쓰기 전에 설정이나 구성이 필요한가요?
아니요. v2.1.63부터 Claude Code에 번들된(자동 설치되는) 스킬로 제공됩니다. 작성해야 할 .claude/skills/ 폴더도 없고 설치 단계도 없습니다 . 단일 저장소에 체크인되는 방식이 아니라 번들로 제공되기 때문에, 조건을 충족하는 버전이라면 모든 코드베이스의 모든 세션에서 사용할 수 있습니다.
/simplify는 린터가 놓치는 무엇을 잡아내나요?
단순한 스타일이 아니라 구조와 설계를 따져 봅니다. 처음 출시되었을 때는 diff 위에서 세 개의 병렬 에이전트가 펼쳐졌습니다. 중복 로직을 대체할 기존 유틸리티를 찾아내는 Reuse 에이전트, 새는 추상화와 중복 상태를 지적하는 Quality 에이전트, 놓친 동시성과 핫패스 비대화를 잡아내는 Efficiency 에이전트입니다 . 린터가 문법과 포매팅을 겨냥한다면, /simplify는 설계를 겨냥합니다.
전체 패스 대신 한 가지 관심사로 /simplify를 제한하려면 어떻게 하나요?
실행 범위를 좁히는 focus 문구를 붙이면 됩니다. 예를 들어 /simplify focus on memory efficiency 또는 /simplify focus on error handling처럼 사용합니다 . 이렇게 하면 정리 패스가 관련 차원으로 좁혀지고 나머지는 건너뛰므로, 표적 리뷰나 토큰 예산이 중요한 상황에 유용합니다.
/batch는 /simplify와 어떤 관계인가요?
각 /batch 워커는 커밋 전에 자신의 diff에 자동으로 /simplify를 실행합니다. /batch는 큰 작업을 대략 5~30개의 독립 단위로 나누고, 각 단위마다 격리된 git worktree에서 백그라운드 에이전트를 하나씩 띄운 뒤, 각각의 PR을 엽니다 . 결과적으로 생성된 모든 PR은 정리 패스가 이미 적용된 상태로 도착합니다.
