한눈에 보기
- 이 글에서 클로드 코드의 /simplify 를 “코드를 다듬는다는 게 뭔지”부터 명령 치기, 고친 것 보기·되돌리기, /code-review 와 다른 점, 규칙 적기, 내 스킬로 바꾸기, 막힐 때까지 공식 문서대로 옮겼어요.
- 결론 코드를 고친 뒤 /simplify 를 치면 에이전트 넷이 다시 쓸 곳·더 짧게 쓸 곳·느린 곳·자리가 어긋난 곳을 찾아 바로 반영해요. 버그는 찾지 않으니 버그는 /code-review 로 봐요.
- 준비물 클로드 코드와 바꾼 코드. 치기 전에 커밋해 두면 마음에 안 들 때 깃으로 바로 되돌릴 수 있어요.
- 주의 고친 것을 바로 적용하는 명령이에요. 하위 에이전트가 고친 것은 /rewind 로 안 돌아가는 경우가 있다고 문서에 적혀 있으니 깃을 믿고 써요.
- 읽는 법 “처음이라면” 세 절이면 첫 다듬기까지 가요. 규칙 적기와 내 스킬 만들기, 코덱스·제미나이 CLI 비교하기는 뒤쪽이에요.
이 글 순서
코드가 돌아가긴 하는데 길고 어수선할 때가 있어요. 같은 일을 하는 줄이 두 번 나오거나, 이미 있는 함수를 모르고 새로 짜 넣었거나, 쓸데없이 같은 일을 여러 번 도는 식이에요. 글로 치면 뜻은 통하는데 문장이 늘어지는 상태예요. 클로드 코드의 /simplify 는 이런 코드를 더 짧고 읽기 쉽게 다듬어 바로 반영하는 명령이에요.
이 글은 클로드 코드 공식 문서 “Commands”, “Code Review”, “Skills”, “Checkpointing”, “Subagents”와 변경 기록(changelog)을 2026년 10월 10일에 읽고 옮긴 거예요. 한국어 문서가 있는 곳은 한국어 문서도 같이 봤고, 명령 이름은 문서 그대로 영어로 두었어요. 비교하려고 OpenAI 코덱스 문서와 제미나이 CLI 명령 문서도 같은 날 읽었어요.

다듬기가 뭔가요
단어부터 풀게요. 클로드 코드는 Anthropic 이 만든 AI 코딩 도구로, 터미널(마우스 대신 글자로 컴퓨터에 일을 시키는 창)이나 데스크톱 앱에서 내 폴더의 파일을 읽고 고쳐요. 그 안에서 / 로 시작하는 말을 치면 정해진 일을 하는데, 이걸 명령(command)이라고 불러요.
“코드를 다듬는다”는 하는 일은 그대로 두고 쓰는 모양만 낫게 바꾸는 일이에요. 개발하는 사람들은 리팩터링(refactoring)이라고도 불러요. 결과가 달라지면 다듬기가 아니라 고장이에요. 아래는 값 목록의 합계를 내는 짧은 함수 하나로 든 예예요.

공식 문서 명령표는 /simplify 를 “바뀐 코드에서 정리할 부분을 리뷰하고 수정 사항을 적용한다”고 적었어요. 리뷰(review)는 다른 눈으로 코드를 다시 읽는 일이에요. 그리고 네 개의 리뷰 에이전트가 나란히 돌며 네 가지를 본다고 했어요. 에이전트는 클로드가 일을 나눠 맡기는 작은 작업자예요.
- 다시 쓰기: 프로젝트에 이미 있는 헬퍼 함수를 쓰면 되는데 같은 일을 새로 짠 곳. 위 그림에서 sum 을 쓴 것과 같아요.
- 더 짧게(단순화): 같은 일을 더 단순하게 쓸 수 있는 곳.
- 효율: 같은 계산을 여러 번 하거나 쓸데없이 많이 도는 곳.
- 알맞은 자리: 문서 표현으로는 “변경이 적절한 추상화 수준에 있는지”예요. 쉽게 말해, 고친 코드가 맞는 층에 들어갔는지 봐요. 화면에 글자 띄우는 코드 안에 계산 규칙을 섞어 넣었다면, 계산은 계산하는 쪽으로 옮기는 게 맞는 자리예요.
![클로드 코드 한국어 문서 명령표 /simplify [target] 줄, 변경된 코드에서 정리할 부분을 리뷰하고 수정 사항 적용, 네 개의 리뷰 에이전트 병렬, 정확성 버그는 찾지 않음, 경로 또는 PR 참조](https://colaydle.com/wp-content/uploads/2026/10/colaydle-cc-simplify-command-1188.webp)
같은 줄에 “이 리뷰는 정확성 버그를 찾지 않는다, 버그를 찾으려면 /code-review 를 쓰라”는 말도 있어요. 정확성 버그는 돌리면 틀린 결과가 나오는 실수예요. /simplify 는 맞게 도는 코드를 더 보기 좋게 만드는 쪽이고, 틀린 곳을 찾는 건 다른 명령 몫이에요.
비개발자가 클로드 코드로 만든 엑셀 묶는 스크립트나 폴더 속 파일 이름 바꾸는 스크립트도 다듬을 거리가 있어요. 여러 번 “이것도 해 줘”를 덧붙이다 보면 같은 줄이 두세 번 들어가는 일이 흔하거든요. 초급 개발자라면 작은 기능을 하나 끝낸 뒤 커밋하기 전에 한 번 돌려 보기 좋아요.
한국에서, 무슨 요금제
| 질문 | 답 |
|---|---|
| 한국에서 되나 | 됨(Anthropic 지원 국가에 South Korea) |
| 따로 깔 것 | 없음(클로드 코드에 든 번들 스킬) |
| 값 | 따로 정한 값 안내 없음 |
| 지금 모습이 된 버전 | v2.1.154(5월 28일)부터 다듬기 전용 |
출처: 클로드 코드 문서 “Commands”·”Skills”·변경 기록, Anthropic 지원 국가 목록. 10월 10일 확인.
번들 스킬(bundled skill)은 클로드 코드에 처음부터 들어 있는 스킬이에요. 스킬은 클로드에게 할 일을 자세히 적어 준 지시 묶음이고, 문서는 번들 스킬이 “클로드에게 자세한 지시를 주고 클로드가 도구로 일을 꾸려 가게 하는” 방식이라고 적었어요. 따로 값이 붙는다는 안내는 없어요. 다만 에이전트 넷이 각자 코드를 읽으니, 제 생각에는 같은 크기의 보통 요청보다 사용량이 더 들 수 있다고 보고 쓰는 게 좋아요. 사용량 보는 법은 클로드 코드 사용량 확인하는 법에 있어요. 클로드 코드가 아직 없다면 클로드 코드 윈도우 설치부터 보세요.
처음이라면: 준비물
- 바꾼 코드: 문서는 “바뀐 코드”를 본다고 적었어요. 아무것도 고치지 않은 폴더에서는 다듬을 거리가 없어요. 무엇을 “바뀐 코드”로 보는지(커밋 안 한 수정인지, 가지 전체인지)는 문서에 따로 적혀 있지 않아요.
- 깃 저장소(권함): 깃(git)은 파일 수정 기록을 남기는 프로그램이고, 그 기록을 가진 폴더가 저장소예요. 커밋은 고친 내용을 기록에 한 번 저장하는 일이에요. /simplify 는 고친 것을 바로 적용하니, 치기 전에 커밋해 두면 마음에 안 들 때 그 시점으로 돌아갈 수 있어요. 처음이면 클로드 코드 깃 커밋·PR 맡기는 법에서 연습 폴더를 저장소로 만드는 것부터 보세요.
- 다 돌아가는 상태: 다듬기는 버그를 고쳐 주지 않아요. 지금 코드가 맞게 도는지 먼저 확인하고, 미덥지 않으면 /code-review 를 먼저 돌려요.
처음이라면: 명령 치기
폴더에서 클로드 코드를 켠 다음, 입력칸에 이 한 줄을 쳐요.
/simplify
“지금 바꾼 코드를 다듬어서 반영해 줘”라는 뜻이에요. 명령표의 형식은 /simplify [target] 이고, 대괄호 안은 넣어도 되고 안 넣어도 되는 자리예요. 특정 파일이나 폴더만 보고 싶으면 뒤에 경로를 적어요. 경로(path)는 폴더 안에서 파일이 있는 자리를 적은 글자예요.
/simplify src/report.py
“src 폴더의 report.py 만 다듬어 줘”라는 줄이에요(파일 이름은 예로 든 거예요). 문서는 경로 말고 PR 참조도 줄 수 있다고 적었어요. PR(풀 리퀘스트)은 내가 고친 브랜치를 원본에 병합해 달라는 요청이에요. PR 을 어떤 형식으로 적는지(번호인지 주소인지)는 /simplify 쪽에 예가 없어서, 처음엔 경로부터 써 보는 게 마음 편해요.
명령표에 실린 옵션은 이 대상 하나뿐이에요. /code-review 의 low~max 깊이나 --fix 같은 옵션은 /simplify 쪽 문서에 없으니 붙이지 마세요.
처음이라면: 보고 되돌리기
다듬기가 끝나면 무엇이 바뀌었는지 꼭 봐요. 클로드 코드 안에서는 /diff 를 쳐요. 명령표는 /diff 를 “작업 트리의 변경 사항을, 클로드가 지금까지 한 편집까지 포함해 리뷰한다”고 적었어요. 작업 트리는 지금 내 폴더에 있는 파일 상태예요. diff 는 두 버전을 비교해 달라진 줄만 뽑은 것이고요.
/diff
읽을 때는 빨간 줄(지운 것)과 초록 줄(넣은 것)을 짝지어 보고, “하는 일이 정말 같은가”만 따져요. 이름을 바꿨다면 다른 파일에서 그 이름을 호출하는 곳도 같이 바뀌었는지 봐요. 그다음 평소처럼 돌려 보거나 테스트를 돌려요. 결과가 달라지면 다듬기가 아니라 고장이니 되돌려요.
되돌리는 길은 깃이 가장 확실해요. 아래는 이 PC 의 연습 폴더에서 합계 함수를 손으로 다듬어 본 뒤, 깃으로 바뀐 것을 보고 되돌린 화면이에요. /simplify 를 돌린 화면이 아니라, 다듬은 뒤 보고 되돌리는 순서를 보여 주려고 깃만 돌렸어요.

git status --short: 바뀐 파일 목록이에요. M 은 고쳐졌다는 표시예요.git diff: 바뀐 줄을 보여 줘요. – 는 지운 줄, + 는 넣은 줄이에요.git restore total.py: 그 파일을 마지막 커밋 때로 되돌려요. 되돌린 수정은 다시 살릴 수 없으니 정말 버릴 때만 쳐요.
/rewind(대화와 코드를 앞 시점으로 되돌리는 명령)로도 되는지는 조심해서 봐야 해요. 문서는 하위 에이전트(서브에이전트, 따로 떨어진 대화 창을 가진 작은 작업자)가 고친 것은 클로드 코드가 보통 되돌릴 기록에 담지 않고, 앞에서 바로 도는 일부 경우 말고는 /rewind 가 복원하지 않으니 깃으로 되돌리라고 적었어요. /simplify 가 고친 것이 어느 쪽인지는 문서에 따로 적혀 있지 않아요. 그래서 “치기 전에 커밋, 끝나면 /diff, 아니면 깃으로” 순서를 권해요. /rewind 가 무엇을 되돌리는지는 compact·clear·rewind 차이, 하위 에이전트는 서브에이전트 사용법에 있어요.
클로드에게 말로 맡겨도 돼요. 커밋을 해 둔 상태라면 이렇게 요청하면 돼요.
방금 다듬은 것 가운데 report.py 쪽만 커밋한 때로 되돌려 줘. 다른 파일은 그대로 둬.
코드 리뷰와 다른 점
이름도 하는 일도 비슷해 보여서 가장 헷갈리는 짝이에요. 문서가 정한 일을 나눠 보면 이래요.
| 항목 | /simplify | /code-review |
|---|---|---|
| 찾는 것 | 다시 쓸 곳·짧게 쓸 곳·느린 곳·자리 | 틀리게 동작할 곳(버그) |
| 고치기 | 바로 적용 | 알려 주기, --fix 면 적용 |
| 옵션 | 대상(경로·PR) | 깊이·--fix·--comment 등 |
| 클라우드 깊은 리뷰 | 공식 안내 없음 | /code-review ultra |
출처: 클로드 코드 문서 “Commands”·”Code Review”, 10월 10일 확인.
문서는 /code-review 도 모델과 깊이(effort)에 따라 정리거리를 같이 본다고 적었어요. 그래도 /code-review 의 중심은 버그이고, /simplify 는 버그를 아예 보지 않는 다듬기 전용이에요. 제 생각에는 “/code-review 로 버그를 먼저 잡고, 맞게 도는 걸 확인한 뒤 /simplify 로 다듬는” 순서가 자연스러워요. 다듬다가 생긴 실수도 다시 /code-review 로 거를 수 있고요. /code-review 는 클로드 코드 /code-review 사용법, 보안 구멍만 보는 /security-review 는 /security-review 사용법에 있어요.
옛 설명과 다른 이유
다른 글에서 “/simplify 가 버그를 찾는다”거나 “/simplify 가 /code-review 로 바뀌었다”는 설명을 봤다면 틀린 게 아니라 옛날 얘기예요. 이 명령은 몇 달 사이 이름과 하는 일이 두 번 바뀌었어요.

변경 기록을 버전 번호 순서로 옮기면 이래요.
- v2.1.63(2월 28일): /simplify 가 번들 명령으로 처음 들어왔어요.
- v2.1.147(5월 21일): /simplify 이름이 /code-review 로 바뀌었어요. 버그를 깊이별로 보고하는 명령이 되고, 예전의 다듬고 고치는 동작은 빠졌어요.
- v2.1.152(5월 27일): /simplify 를 치면 /code-review --fix 가 돌게 됐어요.
- v2.1.154(5월 28일): /simplify 가 다시 다듬기 전용 리뷰(다시 쓰기·단순화·효율·자리)를 돌리고 고친 것을 적용하게 됐어요. 버그를 찾는 /code-review --fix 를 통째로 돌리던 것 대신이에요.

그래서 문서는 “버그 찾기를 위해 /simplify 를 스크립트에 넣어 두었다면 /code-review --fix 로 바꾸라”고 적었어요. 예전에 만들어 둔 자동 작업에 /simplify 가 들어 있다면 지금은 버그를 찾지 않는다는 걸 알고 써야 해요. 내 클로드 코드 버전은 터미널에서 claude --version 으로 봐요.
익숙해졌다면: 규칙 적기
다듬기는 사람마다 취향이 갈려요. 한 줄로 줄인 코드를 좋아하는 사람이 있고, 길어도 풀어 쓴 쪽이 읽기 쉽다는 사람도 있어요. 우리 프로젝트에서 지킬 다듬기 규칙이 있다면 CLAUDE.md 에 적어 두는 게 가장 쉬운 길이에요. CLAUDE.md 는 클로드가 세션을 시작할 때마다 읽는 규칙 메모 파일이에요(CLAUDE.md 쓰는 법).
## 코드 다듬을 때
- 공용 헬퍼 함수는 src/utils/ 에 있다. 새로 짜기 전에 먼저 찾아 쓴다.
- 한 줄로 줄이기보다 풀어 쓴 쪽을 고른다.
- 밖에서 호출하는 함수 이름과 인수는 바꾸지 않는다.
- 다듬을 때 결과가 달라지는 고침은 하지 않는다.
위는 예로 든 규칙이에요. 줄마다 “어디를 먼저 보라”, “무엇은 건드리지 말라”처럼 짧게 적는 게 좋아요.
이 규칙이 네 에이전트에게까지 적용되는지는 하위 에이전트 문서로 따져 볼 수 있어요. 문서는 내장 에이전트 가운데 Explore·Plan 만 CLAUDE.md 를 건너뛰고, 다른 내장·사용자 하위 에이전트는 CLAUDE.md 를 읽는다고 적었어요. 다만 /simplify 의 네 에이전트가 어떤 종류인지는 문서에 없어요. 또 문서는 메인 대화가 하위 에이전트의 결과를 읽을 때 CLAUDE.md 를 다 가지고 있으니 대부분의 규칙은 하위 에이전트까지 갈 필요가 없다고도 적었어요. 그러니 다듬은 결과가 규칙과 어긋나면 “CLAUDE.md 의 다듬기 규칙대로 다시 맞춰 줘”라고 한 번 더 요청하면 돼요.
더 깊이: 내 다듬기 스킬
CLAUDE.md 로 모자라면 다듬기 자체를 내 방식으로 바꿀 수 있어요. 스킬 문서의 이름 겹침 표는 내 스킬(개인 ~/.claude/skills/, 프로젝트 .claude/skills/ 등)과 번들 스킬의 이름이 같으면 “내 스킬이 번들 명령을 대신한다”고 적었어요. 즉 프로젝트에 simplify 라는 스킬을 만들면, /simplify 를 칠 때 번들 다듬기(에이전트 넷) 대신 내가 쓴 SKILL.md 가 돌아요. 스킬 파일 쓰는 법은 클로드 코드 스킬 만들기에 있어요.
이렇게 이름을 simplify 로 붙인 내 스킬에는 덤이 하나 있어요. 문서의 “각 커밋 전에 검사 실행” 절은, 세션이 시작될 때 verify 나 simplify 라는 이름의 스킬이 있으면 클로드가 커밋하기 바로 전에 그 스킬을 돌리라는 지시를 받는다고 적었어요(문서·테스트만 바꾼 커밋은 빼고).

조건은 셋이에요. 여기서 헷갈리기 쉬운 것을 문서대로 옮기면 이래요.
- 내가 만든 스킬만: 번들 /simplify 는 여기에 들지 않아요. 아무것도 안 만들면 커밋 전에 자동으로 다듬지 않아요. 플러그인 스킬과 claude.ai 계정에서 가져온 스킬도 빠져요.
- 클로드가 호출할 수 있어야: 스킬 프론트매터에
disable-model-invocation: true(클로드가 스스로 호출하지 못하게 하는 필드)를 넣으면 이 지시가 안 가요. - 깃 지시가 켜져 있어야: 설정
includeGitInstructions를 끄면 기본 커밋·PR 지시와 함께 이 지시도 빠져요. - 버전: Claude Code v2.1.286 이상이에요.
두 가지를 같이 기억해야 해요. 커밋 전에 자동으로 돌게 하려면 simplify 라는 내 스킬이 있어야 하고, 그 스킬이 있으면 /simplify 를 칠 때도 번들 다듬기가 아니라 내 스킬이 돌아요. 번들의 에이전트 넷짜리 다듬기를 커밋마다 그대로 쓰는 방법은 문서에 없어요. 클로드에게 커밋을 맡기는 흐름은 깃 커밋·PR 맡기는 법에 있어요.
더 깊이: 끄고 켜기
반대로 /simplify 를 내가 칠 때만 쓰거나 아예 숨기고 싶으면 설정 파일의 skillOverrides 를 써요. 문서는 번들 스킬도 이 설정으로 하나씩 숨길 수 있다고 적었어요.
{
"skillOverrides": {
"simplify": "user-invocable-only"
}
}
“simplify 는 클로드에게는 안 보이고, 내 / 목록에는 남겨 둬”라는 뜻이에요. 값은 넷이에요.
| 값 | 뜻 |
|---|---|
| “on” | 클로드에게 이름·설명, / 목록에도 보임(기본) |
| “name-only” | 클로드에게 이름만, / 목록에 보임 |
| “user-invocable-only” | 클로드에게 숨김, / 목록에 보임 |
| “off” | 둘 다 숨김 |
출처: 클로드 코드 문서 “Skills”, 10월 10일 확인.
내가 만든 스킬이라면 /skills 메뉴에서 고르고 Space 로 상태를 바꾼 뒤 Esc 로 저장해도 돼요(.claude/settings.local.json 에 적혀요). 다만 문서는 /skills 목록에 번들 스킬이 나오지 않는다고 적었어요(번들 스킬은 /context 에서 보여요). 그래서 번들 /simplify 는 위처럼 설정 파일에 직접 적어요. 번들 스킬을 전부 끄는 disableBundledSkills 설정도 있지만, /code-review 같은 다른 번들 스킬까지 같이 꺼지니 하나만 끄려면 skillOverrides 가 맞아요. 설정 파일 위치는 settings.json 쓰는 법에 있어요.
클로드가 내가 치지 않아도 /simplify 를 스스로 호출하는지는 문서에 /simplify 이름으로 적혀 있지 않아요. 스킬 문서는 “번들 스킬 가운데 일부는 클로드가 알맞을 때 스스로 호출하고, /verify 같은 것은 내가 칠 때만 돈다”고만 적었어요. 고친 것을 바로 적용하는 명령이라 마음이 쓰인다면 위의 “user-invocable-only”를 넣어 두면 돼요.
코덱스·제미나이 CLI 는
코덱스(OpenAI 의 AI 코딩 도구) CLI 명령 문서에는 다듬기만 따로 하는 명령이 없어요. 가장 가까운 것은 /review 로, 문서는 “작업 트리를 리뷰해 달라고 코덱스에 요청한다”고 적었어요. 터미널에서 바로 치는 codex review 는 커밋 안 한 수정, 기준 가지와의 차이, 커밋 하나, 직접 쓴 리뷰 지시를 리뷰할 수 있다고 적혀 있어요. 그러니 “다듬을 곳을 봐 줘”를 리뷰 지시로 쓸 수는 있어요. 다만 리뷰 뒤 바로 반영하는 옵션은 문서에서 못 찾았어요. 다듬기를 자주 한다면 스킬로 만들어 두는 길이 있어요(코덱스 CLI 스킬 만들기).
제미나이 CLI 명령 문서에도 내장 다듬기 명령은 없어요. 대신 .toml 파일로 내 명령을 만드는 사용자 명령(/commands)이 있고, 고친 것을 되돌리는 /restore(설정에서 되돌릴 기록을 켜야 씀)와 /rewind 가 있어요. 다만 구글 공지에 따르면 6월 18일부터 개인용 요금제는 제미나이 CLI 에서 구글 로그인으로 쓸 수 없고, 개인은 안티그래비티 CLI 로 옮기라고 안내해요(안티그래비티 CLI 스킬 만들기).
| 항목 | 클로드 코드 | 코덱스 | 제미나이 CLI |
|---|---|---|---|
| 다듬기 전용 명령 | /simplify(내장) | 공식 안내 없음 | 공식 안내 없음 |
| 가까운 리뷰 명령 | /code-review | /review, codex review | 공식 안내 없음(내장) |
| 직접 만들기 | 스킬(SKILL.md) | 스킬(SKILL.md) | .toml 사용자 명령 |
| 규칙 파일 | CLAUDE.md | AGENTS.md | GEMINI.md |
| 커밋 전 자동 실행 | simplify 이름의 내 스킬 | 공식 안내 없음 | 공식 안내 없음 |
출처: 클로드 코드 문서 “Commands”·”Skills”, OpenAI 코덱스 문서 “Slash commands”·”Developer commands”·”Build skills”·”AGENTS.md”, 제미나이 CLI 문서 “Commands”(/memory 줄의 GEMINI.md 포함), 구글 공지 “Gemini Code Assist consumer accounts”. 모두 10월 10일 확인. 제미나이 CLI 는 따로 까는 코드 리뷰 확장에 /code-review 가 있지만 다듬기가 아니라 리뷰 쪽이에요(/code-review 사용법의 비교하기 절).
세 CLI 를 다른 기능까지 비교한 표는 클로드 코드·코덱스·제미나이 CLI 비교에 있어요.
막힐 때
- 바뀐 게 없대요: 다듬을 “바뀐 코드”가 없을 수 있어요. 특정 파일을 보려면
/simplify 경로처럼 대상을 적어요. - 결과가 달라졌어요: 다듬기는 버그를 보지 않아요. 깃으로 되돌리고(
git restore 파일또는 커밋한 때로), 바뀐 줄을 /code-review 로 다시 보게 해요. - /rewind 로 안 돌아가요: 문서는 하위 에이전트가 고친 것은 보통 /rewind 로 복원하지 않는다고 적었어요. 깃으로 되돌려요. 다음부터는 치기 전에 커밋해요.
- 너무 많이 바꿔요: 대상을 파일 하나로 좁히고, CLAUDE.md 에 “밖에서 호출하는 이름은 바꾸지 않는다” 같은 규칙을 적어요.
- 버그를 안 짚어 줘요: v2.1.154 부터 원래 그래요. 버그는 /code-review 예요.
- /simplify 가 내 것과 달라요: 프로젝트나 개인 폴더에 simplify 라는 스킬이 있으면 그게 대신 돌아요. /skills 목록에서 그 스킬이 어디서 왔는지 봐요(번들 스킬은 이 목록에 안 나와요).
- /simplify 가 목록에 없어요: skillOverrides 에 “off”가 있거나 disableBundledSkills 가 켜져 있을 수 있어요. 아주 옛 버전이면
claude update로 올려요.
클로드 코드 자체가 안 켜지거나 로그인 오류가 나면 클로드 코드 오류 해결을 보세요.
누구에게 맞을까
여기서부터는 제 생각이에요. 클로드 코드로 작은 스크립트를 만드는 비개발자라면, 다 만든 뒤 커밋하고 /simplify 를 한 번 쳐 보는 정도가 알맞아요. /diff 로 바뀐 줄을 보고, 다시 돌려 봐서 결과가 같으면 커밋, 다르면 깃으로 되돌리면 끝이에요. 짧아진 코드는 나중에 “여기 고쳐 줘”라고 할 때도 클로드가 읽을 양이 줄어요.
혼자 개발하는 분이라면 기능 하나를 끝낼 때마다 /code-review 로 버그를 먼저 거르고 /simplify 로 다듬는 순서가 문서가 나눈 쓰임새와 맞아요. 팀 저장소라면 다듬기 취향을 CLAUDE.md 에 적어 두고, 커밋마다 같은 기준으로 다듬고 싶을 때 simplify 라는 프로젝트 스킬을 만들어 함께 쓰는 쪽을 권해요. 세 회사 요금제와 한도는 AI 비교 2026에 한 표로 모아 두었어요.
다시 확인할 날짜
- 11월 10일: 명령표의 /simplify 설명(에이전트 수·보는 네 가지·대상), 변경 기록에 /simplify 가 또 바뀌었는지.
- 11월 10일: “각 커밋 전에 검사 실행” 조건(버전·위치), 코덱스·제미나이 CLI 명령 문서에 다듬기 명령이 생겼는지.
이 글의 내용은 2026년 10월 10일 공식 문서 기준이에요. 명령과 옵션 이름은 자주 바뀌어요. 글과 다르게 보이면 공식 문서의 지금 내용을 먼저 보세요.
같이 보면 좋은 글: 클로드 코드 /code-review 사용법: 코드 리뷰 한 줄부터 --fix·클라우드 ultra 리뷰까지
같이 보면 좋은 글: 클로드 코드 /security-review 사용법: 보안 검토 한 줄부터 깃허브 PR 자동 검사까지
같이 보면 좋은 글: 클로드 코드 compact·clear·rewind 차이: 지워지는 것과 남는 것
같이 보면 좋은 글: 클로드 코드 CLAUDE.md 쓰는 법: /init 으로 만들고 어디에 두고 무엇을 적나
같이 보면 좋은 글: 클로드 코드 깃 커밋·PR 맡기는 법: 연습 폴더부터 /diff·push 막기·서명 줄까지
같이 보면 좋은 글: AI 비교 2026: 클로드·챗GPT·제미나이 요금제·한도·기능 표
같이 보면 좋은 글: 클로드 코드 /context 사용법: 대화 창 얼마나 찼나 보기부터 줄이는 순서·창 크기까지
같이 보면 좋은 글: 클로드 코드 /batch 사용법: 큰 수정을 5~30조각으로 나눠 동시에, 계획 확인부터 되돌리기까지
참고한 자료
2026년 10월 10일에 확인했어요.
- Commands (클로드 코드 한국어 문서, /simplify·/code-review·/diff·/rewind 줄)
- Commands (클로드 코드 공식 문서, /simplify [target])
- Code Review (클로드 코드 한국어 문서, /simplify 이름 변경 이력)
- Skills (클로드 코드 한국어 문서, 번들 스킬·각 커밋 전에 검사 실행·이름이 겹칠 때·skillOverrides)
- Changelog (클로드 코드 변경 기록, 2.1.63·2.1.147·2.1.152·2.1.154)
- Checkpointing (클로드 코드 한국어 문서, 하위 에이전트 편집이 복원되지 않음)
- Subagents (클로드 코드 공식 문서, 하위 에이전트가 읽는 CLAUDE.md)
- Supported countries and regions (Anthropic, South Korea)
- Slash commands (OpenAI 코덱스 공식 문서, /review)
- Developer commands (OpenAI 코덱스 공식 문서, codex review)
- Build skills (OpenAI 코덱스 공식 문서, SKILL.md)
- AGENTS.md (OpenAI 코덱스 공식 문서)
- Commands (제미나이 CLI 공식 문서, /commands·/memory GEMINI.md·/restore·/rewind)
- Gemini Code Assist consumer accounts (구글 공지, 6월 18일부터 개인용 요금제의 제미나이 CLI 구글 로그인 종료)
광고 · 쿠팡 추천 상품
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.


