최근 Claude Code 사용자들과의 대화에서 한 가지 주제가 계속해서 등장합니다: 100만 토큰 컨텍스트 윈도우는 양날의 검이라는 점입니다.
Claude Code가 더 오랫동안 자율적으로 작동하고 작업을 더 안정적으로 처리할 수 있게 해주지만, 세션을 신중하게 관리하지 않으면 컨텍스트 오염의 가능성도 열어줍니다.
세션 관리가 그 어느 때보다 중요해졌으며, 이에 대한 질문도 많은 것 같습니다. 터미널에서 하나의 세션을 계속 열어두시나요, 아니면 두 개를 사용하시나요? 매 프롬프트마다 새로 시작하시나요? compact, rewind, 또는 subagent는 언제 사용해야 할까요? 잘못된 compact의 원인은 무엇일까요?
여기에는 Claude Code 사용 경험을 크게 좌우할 수 있는 놀라운 양의 세부 사항이 있으며, 거의 모든 것이 컨텍스트 윈도우 관리에서 비롯됩니다.
컨텍스트, 압축 및 컨텍스트 부패에 대한 간단한 입문서
컨텍스트 윈도우는 모델이 다음 응답을 생성할 때 한 번에 "볼" 수 있는 모든 것입니다. 여기에는 시스템 프롬프트, 지금까지의 대화, 모든 도구 호출과 그 출력, 그리고 읽은 모든 파일이 포함됩니다. Claude Code는 100만 토큰의 컨텍스트 윈도우를 가지고 있습니다.
안타깝게도 컨텍스트를 사용하면 약간의 비용이 발생하며, 이를 종종 컨텍스트 부패라고 합니다. 컨텍스트 부패는 컨텍스트가 커짐에 따라 모델 성능이 저하되는 현상입니다. 그 이유는 어텐션이 더 많은 토큰에 분산되고, 오래되고 관련 없는 콘텐츠가 현재 작업을 방해하기 시작하기 때문입니다. 100만 컨텍스트 모델의 경우 약 30~40만 토큰 부근에서 어느 정도의 컨텍스트 부패가 발생하는 것을 볼 수 있지만, 이는 작업에 따라 크게 달라지며 절대적인 규칙은 아닙니다.
컨텍스트 윈도우는 하드 컷오프이므로, 컨텍스트 윈도우의 끝에 가까워지면 작업 중인 내용을 더 작은 설명으로 요약하고 새 컨텍스트 윈도우에서 작업을 계속해야 합니다. 이를 압축이라고 합니다. 직접 압축을 트리거할 수도 있습니다.
모든 턴은 분기점입니다
Claude에게 어떤 작업을 요청하고 완료되었다고 가정해 보겠습니다. 이제 컨텍스트에 몇 가지 정보(도구 호출, 도구 출력, 사용자의 지침)가 있고, 다음에 수행할 수 있는 옵션이 놀라울 정도로 많습니다:
- 계속하기 — 같은 세션에서 다른 메시지 보내기
- /rewind (esc esc) — 이전 메시지로 돌아가서 거기서부터 다시 시도하기
- /clear — 일반적으로 방금 배운 내용에서 추출한 브리프를 사용하여 새 세션 시작하기
- Compact — 지금까지의 세션을 요약하고 요약 위에서 계속 진행하기
- Subagent — 다음 작업 덩어리를 자체 깨끗한 컨텍스트를 가진 에이전트에 위임하고 결과만 다시 가져오기
가장 자연스러운 것은 계속 진행하는 것이지만, 다른 네 가지 옵션은 컨텍스트를 관리하는 데 도움이 되도록 존재합니다.
새 세션을 시작해야 하는 경우
새로운 100만 컨텍스트 윈도우는 더 긴 작업을 더 안정적으로 수행할 수 있음을 의미합니다. 예를 들어 처음부터 풀스택 앱을 빌드하도록 하는 경우입니다. 하지만 모델의 컨텍스트가 부족하지 않다고 해서 새 세션을 시작하지 말아야 한다는 의미는 아닙니다.
일반적인 경험 법칙은 새 작업을 시작할 때 새 세션도 시작해야 한다는 것입니다.
애매한 영역은 컨텍스트의 일부는 여전히 필요하지만 전부는 아닌 관련 작업을 수행하려는 경우입니다.
예를 들어, 방금 구현한 기능에 대한 문서를 작성하는 경우입니다. 새 세션을 시작할 수 있지만, Claude는 방금 구현한 파일을 다시 읽어야 하므로 더 느리고 비용이 많이 듭니다. 문서화가 지능에 크게 의존하는 작업이 아닐 수 있으므로, 관련 파일을 다시 읽지 않아도 되는 효율성 향상을 위해 추가 컨텍스트를 사용하는 것이 가치 있을 수 있습니다.
수정 대신 되감기
좋은 컨텍스트 관리를 나타내는 하나의 습관을 꼽자면, 그것은 되감기입니다.
Claude Code에서 Esc를 두 번 누르거나 /rewind를 실행하면 이전 메시지로 돌아가서 거기서부터 다시 프롬프트를 입력할 수 있습니다. 그 시점 이후의 메시지는 컨텍스트에서 삭제됩니다.
되감기는 종종 수정보다 더 나은 접근 방식입니다. 예를 들어, Claude가 다섯 개의 파일을 읽고 접근 방식을 시도했지만 작동하지 않는 경우입니다. "그건 안 됐어, 대신 X를 시도해 봐"라고 입력하는 것이 본능일 수 있지만, 더 나은 방법은 파일을 읽은 직후로 되감고 배운 내용을 바탕으로 다시 프롬프트를 입력하는 것입니다. "접근 방식 A를 사용하지 마. foo 모듈이 그것을 노출하지 않아. 바로 B로 가."
또한 "여기서부터 요약"을 사용하여 Claude가 학습 내용을 요약하고 핸드오프 메시지를 만들도록 할 수 있습니다. 마치 무언가를 시도했지만 작동하지 않은 미래의 자신이 이전 버전의 Claude에게 보내는 메시지와 같습니다.
압축 vs. 새 세션
세션이 길어지면 무게를 줄이는 두 가지 방법이 있습니다: /compact 또는 /clear(그리고 새로 시작)입니다. 비슷해 보이지만 매우 다르게 동작합니다.
Compact는 모델에게 지금까지의 대화를 요약하도록 요청한 다음, 기록을 해당 요약으로 대체합니다. 손실이 있으며, Claude가 무엇이 중요한지 결정하도록 신뢰하는 것이지만, 직접 아무것도 작성할 필요가 없으며 Claude가 중요한 학습 내용이나 파일을 더 철저히 포함할 수 있습니다. 또한 지침을 전달하여 방향을 제시할 수 있습니다(/compact는 auth 리팩터링에 집중하고, 테스트 디버깅은 제외).
/clear를 사용하면 *사용자가* 중요한 내용을 기록하고("auth 미들웨어를 리팩터링 중이고, 제약 조건은 X이며, 중요한 파일은 A와 B이고, 접근 방식 Y는 배제했습니다") 깨끗하게 시작합니다. 더 많은 작업이 필요하지만, 결과 컨텍스트는 사용자가 관련 있다고 결정한 내용입니다.
잘못된 압축의 원인은 무엇인가요?
장기 실행 세션을 많이 실행하는 경우 압축이 특히 나쁠 수 있는 때를 발견했을 수도 있습니다. 이 경우 잘못된 압축은 모델이 작업 진행 방향을 예측할 수 없을 때 발생할 수 있다는 것을 종종 발견했습니다.
예를 들어, 자동 압축은 긴 디버깅 세션 후에 실행되어 조사를 요약하고, 다음 메시지는 "이제 bar.ts에서 본 다른 경고를 수정해"입니다.
하지만 세션이 디버깅에 집중되어 있었기 때문에 다른 경고는 요약에서 누락되었을 수 있습니다.
컨텍스트 부패로 인해 모델이 압축 시점에 가장 지능이 낮은 상태이기 때문에 이는 특히 어렵습니다. 100만 컨텍스트를 사용하면 수행하려는 작업에 대한 설명과 함께 사전에 /compact를 실행할 수 있는 더 많은 시간을 확보할 수 있습니다.
Subagent 및 새 컨텍스트 윈도우
Subagent는 컨텍스트 관리의 한 형태로, 작업 덩어리가 다시 필요하지 않을 많은 중간 출력을 생성할 것임을 미리 알고 있을 때 유용합니다.
Claude가 Agent 도구를 통해 subagent를 생성하면 해당 subagent는 자체 새 컨텍스트 윈도우를 얻습니다. 필요한 만큼 작업을 수행한 다음 결과를 종합하여 최종 보고서만 부모에게 다시 전달합니다.
우리가 사용하는 정신적 테스트는 다음과 같습니다: 이 도구 출력을 다시 필요로 할까, 아니면 결론만 필요로 할까?
Claude Code가 자동으로 subagent를 호출하지만, 명시적으로 그렇게 하도록 지시할 수도 있습니다. 예를 들어 다음과 같이 지시할 수 있습니다:
- "다음 스펙 파일을 기반으로 이 작업의 결과를 확인하기 위해 subagent를 실행해"
- "다른 코드베이스를 읽고 인증 흐름을 어떻게 구현했는지 요약한 다음, 같은 방식으로 직접 구현하기 위해 subagent를 분기해"
- "내 git 변경 사항을 기반으로 이 기능에 대한 문서를 작성하기 위해 subagent를 분기해"
요약
요약하자면, Claude가 턴을 종료하고 새 메시지를 보내려고 할 때 결정해야 할 지점이 있습니다.
시간이 지남에 따라 Claude가 이를 자체적으로 처리하도록 도울 것으로 예상되지만, 현재로서는 이것이 Claude의 출력을 안내할 수 있는 방법 중 하나입니다.
