Claude Code 문맥을 올바르게 처리하는 방법: 세션이 너무 길어지지 않도록하고 모델이 지나치게 '어리석지' 않도록하십시오.

이 글을 읽으려면 19 분

압축, 백트래킹, 하위 에이전트로 이어지는 이러한 기술을 숙지하여, Claude Code가 긴 대화 중에 항상 높은 수준의 출력을 유지하도록하세요.

원문 제목: Claude Code 사용하기: 세션 관리 및 1M 컨텍스트
원문 작성자: Thariq, Claude Code 팀원
원문 번역: 보옥, AI 연구원

BlockBeats 주석: 현재 AI 프로그래밍 도구의 지속적인 "윈도우 확장"에서, 많은 사용자들이 컨텍스트가 클수록 경험이 자연스럽게 향상된다고 잘못 이해하고 있습니다. 그러나 Claude Code 연구원의 이 현장 복기는 더 차분한 답을 제시합니다: 결과물 품질을 실제로 결정하는 것은 창 크기 자체가 아니라, 당신이 그것을 어떻게 관리하는지입니다.

/usage에서의 업데이트 발표부터 "계속하기, 되감기, 압축, 지우기, 서브에이전트" 등의 작은 작업들의 분해에 이르기까지, 이 기사는 종종 무시되는 능력인 컨텍스트 스케줄링 능력을 밝혔습니다. 이는 엔지니어링 문제이기도 하지만 인지적 문제이기도 합니다: 언제 기록을 유지해야 하며, 언제 의도적으로 잊어야 하는지, 언제 작업을 분리해야 하는지, 언제 새로 시작해야 하는지 등. 이러한 선택은 AI가 "협업"하는지 "지장"하는지를 직접적으로 결정합니다. 아래는 원문 내용입니다:

오늘, 우리는 /usage 명령어를 위한 새로운 업데이트를 발표했습니다. 이 업데이트는 Claude Code 내에서 자신의 사용 상황을 더 명확하게 이해할 수 있도록 돕기 위한 것입니다. 이 결정의 배후에는 최근에 사용자들과의 여러 차례 심층 대화가 있었습니다.

이러한 대화에서 우리는 반복해서 하나의 현상을 들었습니다: 사람들의 세션 관리 습관이 매우 다양하다는 것입니다. 특히 최근 Claude Code가 컨텍스트 창을 100만으로 업그레이드했을 때, 이러한 차이가 더욱 두드러졌습니다.

터미널에서 한 번에 두 개 이상의 세션만 유지하는 것이 익숙한가요? 아니면 매번 입력 프롬프트 단어마다 새 세션을 시작하시나요? 보통 압축(Compact), 되감기(Rewind), 또는 서브에이전트(Subagents)를 언제 사용하시나요? 어떤 이유로 인해 나쁜 압축이 발생했나요?

이 안에는 실은 많은 것이 있습니다. 이런 사소한 세부사항들이 여러분이 Claude Code를 사용하는 경험에 큰 영향을 미칩니다. 이 모든 것의 핵심은 하나에 집약되어 있습니다: 여러분의 컨텍스트 창을 어떻게 관리하는가에 대한 것입니다.

빠른 지식 소개: 컨텍스트, 컨텍스트 압축 및 컨텍스트 소멸

맥락 창이라는 것은 모델이 다음 응답을 생성할 때 현재 볼 수있는 모든 정보를 나타냅니다. 시스템 프롬프트, 지금까지의 채팅 기록, 각 도구 호출 및 출력 결과, 심지어 읽은 각 파일까지 포함됩니다. 지금, Claude Code는 최대 1,000,000 토큰의 대형 맥락 창을 보유하고 있습니다.

그러나 맥락을 사용하는 것에는 약간의 비용이 들기 마련입니다. 우리는 일반적으로 이것을 맥락 감쇠라고 부릅니다. 맥락이 점점 길어지면 모델의 성능이 저하되는 현상이 발생할 수 있습니다. 이는 주의가 더 많은 토큰에 분산되기 때문입니다. 초기에 중요했던 내용이나 관련이 없게 된 이른바 잔여 컨텐츠가 모델의 현재 작업을 방해하기 시작할 수도 있습니다.

맥락 창에는 하드 제한 용량이 있습니다. 그러므로 창이 거의 가득 차면 당신이 하고 있는 작업을 간단한 설명으로 요약하고 이 설명을 가지고 새로운 맥락 창에서 계속 작업해야 합니다.

이 과정을 압축이라고 합니다. 물론, 언제든지 이 압축 과정을 수동으로 시작할 수도 있습니다.

상상해보세요, 방금 Claude에게 일을 부탁했고 이를 이미 완료했습니다. 이제 일부 정보(예: 도구 호출, 도구 결과, 지시 사항)가 맥락에 채워졌습니다.

다음 단계는 무엇인가요? 놀랍게도 여러분은 다양한 선택지가 있다는 것을 발견할지도 모릅니다:

· 계속 (Continue)— 동일한 세션에서 직접 다음 메시지를 보냄

· 되감기 (/rewind 또는 Esc 키를 두 번 누름) — 시간을 되감아 이전 메시지로 돌아가 해당 지점부터 다시 시도

· 지우기 (/clear)— 새로운 세션을 시작하며, 일반적으로 직전 대화에서 요약한 간결한 내용을 함께 기록

· 압축 (Compact) — 현재 대화를 요약한 후 이를 기반으로 계속 작업

· 하위 에이전트 (Subagents) — 다음 작업 단계를 자체적인 클린 컨텍스트를 갖춘 또 다른 AI 에이전트에 위임하고 최종 작업 결과만 다시 가져오는

직접 "계속"하는 것이 가장 자연스러운 반응이긴 하지만, 다른 네 가지 옵션은 당신의 컨텍스트를 더 잘 관리할 수 있도록 설정되어 있습니다.

새 세션을 시작해아할 때?

긴 기존 세션을 유지해야 하는 때와 새로운 세션을 시작해아할 때는 언제일까요? 저희의 경험 규칙은 다음과 같습니다: 새로운 작업을 시작할 때 새 세션도 시작해야 합니다.

100만 개의 컨텍스트 창은 이제 더 긴, 더 복잡한 작업을 매우 신속하게 처리할 수 있다는 것을 의미합니다. 예를 들어, Claude에게 제로베이스부터 풀스택 애플리케이션을 구축하도록 요청하십시오.

그러나 때로는 연관된 작업을 수행 할 수도 있습니다. 이 경우 이전 컨텍스트 일부를 유지해야하지만 전부는 아닙니다. 예를 들어 새 기능을 작성한 후 해당 기능에 대한 사용 설명서를 작성해야하는 경우 새 세션을 시작할 수 있지만, 이는 Claude가 방금 작성한 모든 코드 파일을 다시 읽어야한다는 것을 의미합니다. 이는 더 느리고 더 비용 부담이 큽니다.

"변형" 대신 "되감기" 사용하기

만약 저에게 "우수한 컨텍스트 관리 능력"을 대표할 수 있는 좋은 습관을 선택하라고 요청한다면, 그것은 분명히 "되감기(Rewind)"를 적재적소에 사용하는 것입니다.

Claude Code에서는 Esc 키를 두 번 클릭하거나(/rewind 명령을 실행)하여 이전 메시지 중 어느 것이든 다시 돌아갈 수 있으며 거기서 다시 힌트를 제공할 수 있습니다. 이후에 발생한 모든 대화는 완전히 문맥에서 제거됩니다.

AI의 오류를 수정할 때 "되돌아가기"가 더 현명한 접근일 때가 많습니다. 예를 들어, Claude가 다섯 개의 파일을 읽고 한 가지 방법을 시도했지만 실패한 경우를 생각해보십시오. 대화 상자에 "이 방법은 효과가 없어, X 방법으로 바꿔봐." 라고 적는 것이 직감적인 반응일 수 있습니다. 그러나 더 현명한 접근은 다섯 개의 파일을 읽은 직후부터 되돌아가서 방금 배운 교훈을 가져와 "A 방법 대신 써봐라, foo 모듈이 그걸 지원하지 않아—바로 B 방법으로 가봐" 라고 다시 말하는 것입니다.

심지어 "여기서 요약하기(summarize from here)" 기능을 사용하여 Claude가 배운 교훈을 자체적으로 요약 정보로 만들도록 할 수도 있습니다. 이는 방금 함정에 빠진 "미래의 Claude"가 과거의 스스로에게 메모를 남기는 것과 같은 느낌입니다.

컨텍스트 압축 vs 새로운 대화

대화가 점점 길어지면, 그것을 "가볍게 하는" 두 가지 방법이 있습니다: /compact(압축)을 사용하거나 /clear(지우고 처음부터 다시 시작)을 사용합니다. 이 두 작업은 비슷해 보이지만 실제로는 매우 다릅니다.

압축(Compact)은 현재까지의 대화를 모델이 요약하고 이 요약을 사용해 긴 이력을 대체하는 것입니다. 이 프로세스는 "손실이 있는" 것으로, Claude에게 "어떤 내용이 중요한지"를 결정하는 권한을 부여합니다.

이점은 무엇인가를 작성할 필요가 없으며, Claude가 중요한 경험 또는 파일 기록을 유지하는 데 당신보다 더 세심할 수도 있습니다. 또한 지시를 내려 압축 방향을 제어할 수도 있습니다(예: /compact를 사용하여 인증 모듈 재구성에 중점을 두고, 테스트 디버그 내용을 삭제).

/clear를 사용하는 경우에는 핵심 포인트를 직접 작성해야 합니다(예: "우리는 인증 미들웨어를 재구성 중이며, 현재 제한 조건은 X이며, 관련 중요 파일은 A와 B이고, 우리는 방법 Y를 배제했습니다"), 그리고 매우 깨끗한 상태로 다시 시작해야 합니다. 약간 수고가 들지만, 여기에서 얻는 새로운 컨텍스트는 모두가 실제로 관련이 있다고 생각하는 것입니다.

어떤 종류의 "압축"이 실패할까요?

극장 같은 매우 긴 세션에 자주 종속되어 있었다면, "압축" 효과가 매우 나쁜 상황을 경험한 적이 있을 것입니다. 우리는 이러한 "실패"가 전형적으로 특정 시점에서 발생한다는 것을 발견했습니다: 즉, 대형 언어 모델(LLM)이 다음 작업 방향을 예측하지 못할 때입니다.

예를 들어, 긴 코드 디버깅 세션 후 시스템이 자동으로 압축을 시작하고 이전의 조사 과정을 요약했습니다. 그러자 당신은 "이제, 바로 전에 bar.ts에서 본 다른 경고도 고쳐주세요."라는 말을 바로 합니다.

그러나 방금 집중했던 세션이 이전 버그 디버깅에 완전히 집중했기 때문에 고치지 못한 경고는 이미 중요하지 않은 정보로 여겨져 요약할 때 직접 삭제되었을 가능성이 매우 높습니다.

이것은 상당히 어려운 문제입니다. 컨텍스트 감소로 인해, 모델은 압축을 수행할 때 그것이 "지능"이 가장 부족한 시점인 경우가 많습니다. 다행히, 1,000,000의 컨텍스트 크기로, 이제는 "다음에 무엇을 하려고 하는지"를 명시적으로 적어서 /compact를 미리 실행할 수 있는 공간이 훨씬 더 넓어졌습니다.