이 글을 통해 알 수 있는 것
- 같은 실수가 계속될 때, 수정하는 것을 거듭하는 것보다
/clear로 처음부터 다시 하는 것이 더 빠르다는 이유와 재시작 프롬프트 작성법 -
/clear
・/compact
・/btw
의 사용 구분 방법 - 요약으로 사라지게 하고 싶지 않은 정보를 CLAUDE.md에 기록하는 방법
Claude Code로 작업하면서 다음과 같은 경험을 해보신 적이 없으신가요?
"거기가 아니야, 고쳐줘" → "수정했습니다!" → "……아직도 같은 실수를 하고 있어" → "수정했습니다!"
2번, 3번과 같이 수정해 달라고 할수록 오히려 나빠집니다. 매달려 한 번만 더……라며 계속하다 보면 어느새 30분이 지나 있습니다. 이 글에서는 그 원인과 탈출 방법을 공식 문서를 바탕으로 정리합니다.
전제
- 대상: Claude Code (터미널 버전의 CLI)
- 사양은 2026년 10월 18일자 공식 문서를 확인했습니다. 작성 시점의 제 손안 버전은 2.1.299입니다.
- 본문 내의
/clear
・/compact
・/btw
입력 예시는 설명용 예시입니다. 실제 답변은 프로젝트나 대화 내용에 따라 달라집니다.
전체 개요
먼저, 왜 '청소'가 필요한지부터 짚고 넘어가겠습니다.
Claude Code의 공식 문서(Best practices)에는 대부분의 베스트 프랙티스의 기반이 되는 제약 사항이 적혀 있습니다.
Claude's context window fills up fast, and performance degrades as it fills.
(컨텍스트 윈도우는 금방 차고, 차면 성능이 저하됩니다.)
컨텍스트 윈도우(Claude가 그 시점에서 참조할 수 있는 정보의 범위)에는 대화 전체가 들어갑니다. 자신의 메시지, Claude의 답변, 불러온 파일, 실행한 명령어 출력 등입니다. 이것이 가득 차면, Claude는 앞쪽 지시를 '잊기' 시작하거나 실수가 늘어납니다.
즉, 대화는 길어질수록 성능이 떨어지는 자원입니다. 이번에 다룰 세 가지 명령어는 모두 이 자원을 정리하기 위한 도구입니다.
| 명령어 | 하는 일 | 사용하는 경우 |
|---|
/clear | 컨텍스트를 리셋하여 새로운 대화를 시작함 | 같은 실수가 계속될 때 / 관련 없는 작업으로 넘어갈 때 |
/compact | 대화를 요약하여 줄임 | 같은 작업을 하면서 대화가 길어졌을 때 |
/btw | 메인 대화 기록에 남기지 않고 질문함 | 현재 작업에 대해 잠깐 확인하고 싶을 때 |
절차와 사용 구분
/clear
- 두 번 고쳐도 안 되면 2번 수정 요청할 때마다 컨텍스트에는 다음과 같은 것들이 쌓이게 됩니다.
첫 번째 지시
✗ 실패① (잘못된 코드)
수정 지시
...
실패한 코드도, 그것에 대한 지적도 전부 대화의 일부로 남습니다. Claude는 다음 답변을 만들 때 이 모든 것을 읽습니다. 따라서, 실패했던 방식 자체가 '참고 자료'가 되어 버리는 것입니다.
공식 문서에도 명확하게 이렇게 쓰여 있습니다.
If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run
/clear
and start fresh with a more specific prompt that incorporates what you learned.
요약하자면 '같은 문제를 2번 이상 고쳤다면, 컨텍스트는 실패한 방식으로 어지럽혀져 있다. /clear로 하고, 배운 것을 담은 구체적인 프롬프트로 다시 시작하라'는 내용입니다. 이어서 '깨끗한 세션 + 좋은 프롬프트는, 수정을 쌓아 올린 긴 세션에 거의 반드시 승리한다'고도 쓰여 있습니다.
'자주 발생하는 실패 패턴(よくある失敗パターン)' 목록에도 **Correcting over and over (반복적으로 고치기)**가 실려 있습니다. 대책은 '2번 수정에 실패했다면 /clear로 하고, 배운 것을 담아 처음 프롬프트를 다시 작성하는 것'입니다.
2. 재시작할 때는 배운 내용을 짧고 구체적으로 추가하기
/clear만 했다고 해서 처음에 똑같은 지시를 내리면, 같은 실패를 또 할 가능성이 있습니다. 중요한 것은 2번의 실패로 알게 된 것을 프롬프트에 추가하는 것입니다.
예를 들어, Next.js에서 로그인 후 리다이렉트가 제대로 작동하지 않는 상황을 가정해 봅시다. Claude는 useEffect 안에서 router.push 하는 수정을 반복하고 있었습니다.
처음 지시사항은 다음과 같았습니다.
/clear
한 후, 다음처럼 다시 요청합니다.
로그인 리다이렉트를 고쳐줘.
- 목표: 로그인 후에는 /dashboard로 돌아가게 할 것
- 위치: 리다이렉트는 middleware.ts에서 수행할 것
...
추가하는 것은 다음 세 가지입니다.
| 추가 항목 | 예시 | 역할 |
|---|
| 목표 | 로그인 후에는 /dashboard로 돌아가게 할 것 | 무엇을 하면 완료인지 명확히 함 |
| ... | | |
| 같은 실수를 피하기 위해, 세 번째 '피하고 싶은 방식'도 작성합니다. 두 번의 실패는 낭비가 아니라 '이 방법은 안 되었다'라는 정보입니다. 이를 추가해 두면 새로운 대화에서도 같은 길을 피하기 쉬워집니다. | | |
공식 문서의 프롬프트 예시에서도 증상, 위치, 그리고 '고쳐진' 상태를 작성하는 것이 권장됩니다.
"users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it"
/clear
- 관련 없는 작업으로 전환할 때도 같은 실수가 계속되지 않더라도
/clear를 사용해야 할 타이밍이 있습니다. 현재 작업과 관계없는 작업으로 전환할 때입니다.
하나의 대화 안에서...
・로그인 수정
・(덤으로) 이 CSS, 왜 깨지는 거야?
...
이는 공식적으로 **The kitchen sink session (무엇이든 넣는 세션)**이라고 불리는 실패 패턴입니다. 하나의 작업으로 시작해서 관계없는 질문을 하고, 다시 원래 작업으로 돌아옵니다. 그러면 컨텍스트가 관계없는 정보로 가득 차게 됩니다.
대책은 '관계없는 작업을 할 때마다 /clear를 하는 것'입니다.
대화 ①: 로그인 수정
↓ /clear
대화 ②: CSS 질문
...
로그인 수정을 하고 있을 때, CSS나 API 설계 이야기는 필요하지 않습니다. 관계없는 정보가 섞일수록 Claude의 주의가 분산됩니다.
반면, 같은 기능에 대한 조사부터 구현, 테스트로 진행하는 관련 작업이라면, 그까지의 경위가 도움이 됩니다. 그 경우에는 /clear를 하지 않고 계속 진행하고, 길어졌을 때 다음 /compact를 사용합니다.
/compact
으로 줄이기
- 같은 작업을 계속할 경우 '같은 작업을 더 하고 싶지만, 대화가 길어져 왔다'는 상황도 있습니다. 지금까지의 경위를 버리기는 아까우므로, 그럴 때는
/compact를 사용합니다.
/compact는 대화 기록을 요약하여 줄이는 명령어입니다. 핵심은 무엇을 중심으로 남길지 지시할 수 있다는 것입니다.
/compact API 변경 사항을 중심으로 남겨줘
공식 문서의 예시는 /compact Focus on the API changes입니다. 아무것도 지정하지 않는 것보다, 현재 작업에서 중요한 것을 전달하는 것이 요약 후에도 작업을 계속하기 쉽습니다.
또한, 컨텍스트 상한선에 가까워지면 Claude Code는 자동으로 대화를 요약합니다 (auto compaction). 공식 설명에서는 이때 코드 패턴, 파일 상태, 중요한 결정 등을 우선하여 남긴다고 합니다.
/clear | /compact |
|---|
| 하는 것 | 컨텍스트를 리셋 |
| 지금까지의 경위 | 새로운 대화로 이어지지 않음 |
| 적합한 상황 | 실수가 계속되거나 / 관계없는 작업으로 전환할 때 |
/btw
- 간단한 확인은 작업 도중에 '어라, 아까 설정 파일 이름이 뭐였지?' 하고 궁금해질 때가 있습니다. 평소에 물어보면 그 질문과 답변도 메인 대화 기록에 남아 컨텍스트가 조금 늘어납니다.
그럴 때 사용할 수 있는 것이 /btw입니다.
공식 문서 설명을 정리하면, /btw에는 다음과 같은 특징이 있습니다.
- 질문과 답변은 메인 대화 기록에 남지 않습니다. 따라서 컨텍스트를 늘리지 않고 확인할 수 있습니다. 다만, 터미널 버전에서는 직전 20회 왕복까지의
/btw가 다음 /btw로 인계됩니다(<code>x</code> 키로 삭제 가능). - Claude가 작업 중에도 사용할 수 있습니다. 메인 작업이 멈추지 않습니다.
- 이미 대화에 있는 정보만으로 답변합니다. 파일을 읽거나, 명령을 실행하거나, 검색하는 등의 도구는 사용할 수 없습니다. - 질문 한 번에 답변도 한 번입니다. 계속 듣고 싶다면, 다시
/btw를 사용하세요.
사용 예시입니다.
- “아까 결정했던 방침이 뭐였지?”
- “아까 읽었던 함수의 인수가 뭐였지?”
- “아까의 에러 메시지를 한 번 더 보여줘”
6. 요약으로 사라지게 하고 싶지 않은 것은 CLAUDE.md에 작성하기
/compact나 자동 요약은 편리하지만, 요약인 이상 세부 정보가 누락될 수 있습니다. 반드시 남겨두고 싶은 것은 CLAUDE.md에 요약 규칙으로 작성할 수 있습니다. CLAUDE.md는 Claude Code가 매번 읽어들이는 지시 파일입니다.
공식 문서의 예시는 다음과 같습니다.
"When compacting, always preserve the full list of modified files and any test commands"
(요약할 때 변경한 파일의 전체 목록과 테스트 명령을 반드시 남길 것)
일본어로 작성한다면 예를 들어 다음 형태입니다.
# Commands
- 타입 체크: npm run typecheck
# Compact instructions
...
시리즈 전에는 'CLAUDE.md에는, 지우면 AI가 실수하는 줄만 적는다'는 내용이었습니다. 요약에서 무엇을 남길지는 바로 지우면 AI가 실수를 하는 정보이기 때문에, CLAUDE.md에 작성할 가치가 있습니다.
실제로 사용해 보기
제 경우, 같은 수정이 루프하기 시작하면 상황에 맞춰 다음 세 가지를 번갈아 사용합니다.
/rewind로 대화를 되감아 이전 시점부터 다시 시작하기
/compact의 인수에 “〇〇는 남겨줘”라고 지시하여 필요한 경위만 남기고 대화를 축소하기
/clear를 사용하여 문제를 부분별로 분해하고, 각각을 전용 세션으로 진행하기
세 번째는 이 글의 '관련 없는 태스크로 전환할 때는 /clear'의 응용입니다. 하나의 큰 문제를 하나의 대화에 담아두지 않고, 작은 문제별로 대화를 나누고 있습니다.
요약
- 같은 문제 수정 요청을 2번 해도 해결되지 않으면,
/clear를 하고 '목표・장소・피해야 할 방식'을 추가하여 다시 시도하기 - 관련 없는 태스크로 이동할 때는 /clear, 같은 작업으로 대화가 길어지면 /compact + 무엇을 남길지에 대한 지시 - 간단한 확인은 /btw, 요약에서 남기고 싶은 것은 CLAUDE.md에 작성하기
AI가 같은 실수를 반복하면, 무심코 '한 번만 더' 하고 싶어집니다. 하지만 대화에 쌓인 실패의 흔적이 실수의 원인이 되는 경우도 많습니다. 다음에 같은 문제 수정 요청을 2번 해도 해결되지 않으면, 세 번째를 요청하기 전에 /clear를 시도해 보세요.
Instagram @k_grid_blog에서는 Claude Code×AI 개발의 실전 노하우를 발신하고 있습니다.
참고
- Best practices for Claude Code (Course-correct early and often / Manage context aggressively / Avoid common failure patterns)
- Interactive mode - Side questions with /btw
- Manage sessions (/clear` 이후 세션 저장 및 재개)
※ 2026년 10월 18일자 공식 문서를 기반으로 합니다. 명령어 사양은 변경될 수 있으므로, 최신 정보는 공식 문서를 확인해 주세요.
Discussion