규칙을 작성했다. .claude/rules에 구성 규칙을 정의하고 설계서의 출력 형식을 상세하게 지정했다. 그런데 세션이 길어지면 무시된다.

처음에는 지켜준다. 하지만 App Router 설계, Prisma 스키마, 컴포넌트 설계로 진행되다 보면 모든 내용이 파일 하나에 다 담긴다. "분할해줘"라고 말하면 고쳐진다. 하지만 다음 섹션에서 다시 하나의 파일로 돌아간다. "그러니까 분할하라고". 다시 고쳐진다. 그리고 또 돌아온다.

프롬프트(Prompt) 작성 방식이 잘못된 것인가 싶어 규칙의 입도(Granularity)를 바꿨다. 구체적인 예시를 추가했다. 기대되는 출력 샘플까지 붙였다. 효과가 없다.

세 번째 시도쯤에 깨달았다. 처음에는 지켜주고 있었다. 세션 초반에는 완벽하게 분할되어 있었다. 하지만 작업이 진행되고 수정 사항이 쌓일수록 규칙이 작동하지 않게 된다.

원인은 규칙이 아니었다. 컨텍스트(Context)가 오염되어 있었다.

Claude에는 한 번의 세션에서 볼 수 있는 범위가 있다. 컨텍스트 윈도우(Context Window)라고 불리며, 그 안에서 규칙이 차지하는 비중은 처음에 읽어 들인 수백 토큰(Token, 텍스트 처리 단위) 분량이다. 반면, 중간의 질문과 답변, 수정과 재수정은 수천 토큰을 차지한다. 당연히 묻힐 수밖에 없다. 규칙이 나쁜 것이 아니라, 규칙이 보이지 않게 된 것이다.

한 번의 질문이 남은 모든 턴에 영향을 미친다

컨텍스트 윈도우를 화이트보드에 비유하면 이해하기 쉽다. 적은 내용은 전부 남는다. 관계없는 질문도, 실패한 수정 지시도 사라지지 않는다.

세션 중에 무심코 던지는 질문이 쌓이면 컨텍스트의 상당 부분을 차지할 수 있다. "이게 무슨 뜻이야?", "이 방식이 맞아?" 정도의 가벼운 질문이라도 그렇다. 은근히 치명적이다. 단순히 공간을 낭비하는 것이 아니라, 컨텍스트 내의 모든 텍스트가 다음 출력에 영향을 미치기 때문에 노이즈(Noise)가 늘어날수록 정밀도가 떨어진다.

오염시키지 않는다, 오염되면 되돌린다, 넘치면 끊는다. 여기서부터는 그 실천에 관한 이야기다.

/btw: 작업을 멈추지 않고 방침을 확인하기

작업 중에 "지금 어떤 방침으로 진행하고 있어?"라고 확인하고 싶을 때가 있다. 하지만 그것을 메인 대화에 입력하면 질문과 답변이 컨텍스트에 남는다.

/btw는 이를 해결한다. 일시적인 별도 창을 사용하여 메인 컨텍스트에는 전혀 남지 않는다.

/btw 설계서 구성이 어떻게 되어 있어? 라우팅과 스키마는 분리되어 있어?

Claude가 작업 중이라도 중단되지 않는다. 답변이 인라인(Inline)으로 돌아오고 사라진다. 메인 세션의 컨텍스트는 무결한 상태를 유지한다.

나의 사용법은 다음과 같다:

• "개발자가 이해하기 쉬운 형태로 분할되어 있는가?"
• "구성을 먼저 결정한 뒤에 작성하고 있는가?"
• "규칙을 지키고 있는가?"

방침이 어긋나지 않았다면 그대로 진행한다. 어긋났다면 다음 차례인 /rewind가 등장할 차례다.

단, /btw는 확인 전용이다. 도구(Tool)를 전혀 사용할 수 없으므로 파일을 읽거나 명령을 실행할 수 없다. 현재 컨텍스트에 들어 있는 정보만으로 답변해 준다.

중요한 점은, /btw로 방침 변경을 전달해도 메인 Claude에게는 전달되지 않는다는 것이다. 메인 세션은 질문이 있었다는 사실조차 모른다. 방침 변경은 전달되지 않는다.

바꾸고 싶다면 메인에 직접 개입하거나, /rewind로 다시 시작해야 한다.

/rewind: 실수를 "없었던 일"로 만들기

"아니야, 그게 아니라"를 반복하면 어떤 일이 벌어질까?

틀린 출력 + 수정 지시 + 수정된 출력. 이 세 가지가 모두 컨텍스트에 남는다. 수정을 두 번 반복하면 정답 출력 1개에 대해 쓰레기 데이터가 5개 남는다. 컨텍스트의 대부분이 "이렇게 하지 마"라는 기록으로 채워진다.

/rewind는 실수가 발생한 체크포인트(Checkpoint)까지 되돌린다. 실수와 수정 지시가 모두 사라진다. 깨끗한 상태에서 이번에는 더 명확한 지시로 다시 시작할 수 있다.

/rewind
# 또는 Esc를 두 번 누름

먼저 과거의 체크포인트 목록이 나온다. 되돌리고 싶은 지점을 선택하면 다음 선택지가 나타난다:

• Restore code and conversation: 코드와 대화를 해당 지점으로 되돌림
• Restore conversation: 대화만 되돌림 (코드는 현재 상태 유지)
• Restore code: 코드만 되돌림 (대화는 현재 상태 유지)
• Summarize up to here: 선택한 지점 이전의 대화를 요약으로 압축. 최근 작업 내용은 유지됨
• Summarize from here: 선택한 지점 이후의 대화를 요약으로 압축. 초반의 지시 사항은 유지됨

설계 단계가 페이즈 1에서 2로 전환될 때, 페이즈 1의 세세한 상호작용을 「Summarize up to here」로 압축하여 가져가는 것이 편리합니다.

「수정」보다 「되돌리기」가 정확도가 높은 이유

컨텍스트 (Context)에 오류가 남아 있으면, 모델은 그것까지 참조하여 다음 출력을 생성합니다. "이렇게 하지 마"와 같은 부정형 지시는 긍정형 지시보다 효과가 떨어집니다. 오류를 지우고 올바른 지시만 남은 상태가 확실히 더 높은 정확도를 보여줍니다.

초반의 설계서가 바로 그런 사례입니다. "나눠서 해줘"를 세 번 반복하는 것보다, 되돌리기를 통해 "라우팅, 스키마, 컴포넌트의 3개 파일로 나눠줘"라고 한 번 다시 말했더니 단번에 통했습니다.

/btw → /rewind 루프

이 두 가지를 조합하면 안정적입니다.

• 태스크를 시작한다
• /btw로 방침을 확인한다 - 어긋나지 않았다면 방치, 어긋났다면 /rewind 실행
• 되돌린 지점부터 더 명확한 지시로 재개
• 다시 /btw로 확인

핵심은 컨텍스트에 오류를 축적시키지 않는 것입니다. 도중에 "아니야"를 쌓아가는 것이 아니라, 발견하면 되돌려서 올바른 길만 남기는 것입니다.

/clear: 화제를 완전히 전환하기

태스크가 끝나고 다음 작업으로 넘어갈 때입니다. 이전 태스크의 컨텍스트는 전부 방해가 됩니다.

/clear는 대화 이력을 통째로 지웁니다. 단:

• 코드 변경 사항은 그대로 남음
• CLAUDE.md나 메모리도 남음
• 프로젝트 지식은 유지됨

"되돌리기"가 /rewind라면, "다른 일"은 /clear입니다.

리팩터링 (Refactoring)이 끝나고 다음으로 테스트를 작성하는 상황과 같습니다. 이전 리팩터링의 시행착오가 컨텍스트에 남아 있으면 테스트 생성 품질에 영향을 줍니다. /clear를 하고 "테스트를 작성해줘"라고 시작하는 편이 좋습니다.

/branch와 claude -w: 병행 작업을 한다면

/branch는 대화 이력을 분기시킵니다. 과거의 체크포인트로부터 다른 대화를 파생할 수 있습니다.

솔직히 아직은 사용처를 잘 모르겠습니다.

이유는 간단합니다. 대화만 분기되고 파일 시스템은 공유되기 때문입니다. 양쪽 브랜치에서 같은 파일을 건드리면 사고가 발생합니다. "어느 쪽의 변경이 맞는가?"가 모호해집니다.

코드까지 분리하고 싶다면 claude -w가 더 안전하다고 생각합니다.

claude -w feature-auth

이것은 git의 worktree (독립된 작업 디렉토리)를 만들어 물리적으로 별도의 디렉토리에서 작업합니다. 파일이 충돌할 가능성이 제로입니다.

• /branch: 대화는 분기, 파일은 공유 → 같은 파일을 건드리면 위험함
• claude -w: 대화도 파일도 완전 분리 → 안전하지만 셋업이 한 단계 더 필요함

병행하여 "API 설계"와 "컴포넌트 설계"를 진행하고 싶을 때, claude -w로 두 작업을 완전히 나누는 것이 확실합니다. 끝나면 git으로 머지 (Merge)하면 됩니다.

사용법 요약표

여담: 내부에서 무슨 일이 일어나고 있는가

여기서부터는 관심 있는 분들을 위한 내용입니다. /btw가 가벼운 이유를 구조적으로 설명하겠습니다.

Claude API는 스테이트리스 (Stateless)입니다. 서버는 이전 대화를 기억하지 않습니다.

“어, 하지만 세션 중에는 이전 대화를 잘 기억하고 있잖아”라고 생각할지도 모른다. 그것은 Claude Code(로컬 앱)가 대화 전체를 로컬에 저장하고 있으며, 매 턴(Turn) 그 전체 내용을 서버로 다시 보내고 있기 때문이다. 서버는 매번 “처음 뵙겠습니다”인 상태이지만, 전체 내용이 전달되기 때문에 문맥을 파악할 수 있는 것뿐이다.

따라서 대화가 길어지면 송신량도 늘어나고, 불필요한 정보(Garbage)가 섞여 있다면 매번 그 불필요한 정보까지 통째로 다시 보내게 된다. 컨텍스트 관리 (Context Management)가 정확도와 직결되는 이유가 바로 여기에 있다.

“어, 비효율적이지 않아?”라고 생각할 수 있지만, 여기서 프롬프트 캐시 (Prompt Cache)가 효과를 발휘한다.

Claude Code가 백그라운드에서 캐시 포인트 (Cache Point)를 설정하여, “여기까지는 지난번과 동일하다”라고 판단할 수 있는 부분의 GPU 처리를 스킵한다. 캐시가 적용된 부분의 처리 비용은 통상의 1/10 수준이다. 송신은 이루어지지만 처리는 재사용되는 방식이다.

/btw 에이전트는 메인 세션의 캐시를 그대로 빌려온다. 따라서 대화 전체를 처음부터 다시 처리할 필요가 없으며, 비용이 거의 들지 않는다.

더 나아가 대화가 너무 길어지면 자동 압축 (Compaction)도 실행된다. 컨텍스트 (Context)가 한계에 가까워지면 오래된 대화 내용을 요약본으로 압축해 준다. 완전히 방치해도 시스템이 무너지지는 않지만, 그 정도로 비대해지기 전에 스스로 /rewind나 /clear를 사용하여 관리하는 편이 정확도가 더 높다.

이 메커니즘을 이해하면 왜 컨텍스트 관리가 효과적인지 납득할 수 있을 것이다.

컨텍스트는 저절로 오염된다

/btw로 확인해도 컨텍스트는 오염되지 않는다. /rewind로 되돌리면 규칙이 적용되는 상태로 돌아간다. /clear로 전환하면 다음 태스크는 깨끗하게 시작된다.

돌이켜보면, 정확도가 떨어졌을 때는 모두 컨텍스트의 상태가 원인이었다.