Claude 코드 컨텍스트의 올바른 처리 방법: 세션이 길어지지 않도록하고 모델이 더욱 "멍청"해지지 않도록 조심하세요
원문 제목: Using Claude Code: Session Management & 1M Context
원문 저자: Thariq, Claude Code 팀 멤버
번역자: 보옥, AI 연구원
BlockBeats 주석: 현재 AI 프로그래밍 도구가 계속해서 "컨텍스트 확장"하는 가운데, 많은 사용자들이 컨텍스트가 클수록 경험이 자연스럽게 향상된다고 오해합니다. 그러나 Claude Code 연구원의 이 기고는 냉정한 답변을 제시하며, 생산 품질을 실제로 결정짓는 것은 창 크기 자체가 아니라 그것을 어떻게 관리하는가입니다.
/usage에서의 업데이트 출시부터 "계속하기, 되감기, 압축, 초기화, 서브 에이전트"와 같은 마이크로 작업에 대한 분해까지, 이 기사는 종종 간과되는 능력인 컨텍스트 스케줄링 능력을 드러냈습니다. 이는 공학적 문제일 뿐만 아니라 인지적 문제이기도 합니다: 언제 역사를 유지할지, 언제 의도적으로 잊을지, 언제 작업을 분해할지, 언제 새로운 게임을 시작할지. 이러한 선택은 AI가 "협력"하느냐 아니면 "짐"하느냐를 직접 결정합니다. 아래는 원문 내용입니다:
오늘, 우리는 /usage 명령어를 위한 새로운 업데이트를 출시했으며, 이는 Claude Code 내에서의 사용량을 더 명확히 이해하고자 합니다. 이 결정의 배경에는 최근 사용자들과의 다수의 심층적 대화가 있습니다.
이러한 대화 중, 우리는 세션을 관리할 때 사용자들의 습관에 대해 반복적으로 들었습니다. 특히 최근에 Claude Code가 컨텍스트 창을 100만으로 업그레이드한 이후에는 이러한 차이가 더욱 두드러졌습니다.
터미널에서 한 두 개의 세션만 유지하는 것에 익숙하신가요? 아니면 매번 입력 프롬프트마다 새 세션을 열으시나요? 언제 주로 압축, 되감기 또는 서브 에이전트를 사용하시나요? 어떤 이유로 압축이 실패하면서 좋지 못한 경험이 있었나요?
실은 이 모든 것에는 깊은 의미가 있습니다. 이런 사소한 디테일들은 여러분이 Claude Code를 사용하는 경험에 큰 영향을 미칩니다. 그리고 이 모든 것의 핵심은, 당신의 컨텍스트 창을 어떻게 관리하는가에 달려있습니다.
빠른 정보 제공: 컨텍스트, 컨텍스트 압축 및 컨텍스트 소멸
맥락 창문(Context Window)이란, 모델이 다음 응답을 생성할 때 한 번에 '볼 수 있는' 모든 정보를 의미합니다. 이는 시스템 프롬프트(System Prompt), 지금까지의 채팅 기록, 각 도구 호출(Tool Call) 및 해당 출력물, 심지어 읽은 각 파일까지 포함합니다. 이제 Claude Code는 최대 1백만 토큰(Token)(주석: 토큰은 대규모 모델이 텍스트를 처리하는 기본 단위로, 일반적으로 영어 단어 하나가 약 1개의 토큰이며, 한 문자는 1-2개의 토큰을 차지할 수 있습니다)의 대규모 맥락 창을 보유하고 있습니다.
그러나 유감스럽게도, 맥락을 사용하는 데에는 약간의 비용이 듭니다. 우리는 일반적으로 이를 맥락 쇠퇴(Context Rot)라고 합니다(주석: 대화 기록이 점점 길어짐에 따라 모델이 처리해야 할 정보가 너무 많아져 주의가 산만해지고, 초기 중요 정보를 잊거나 관련 없는 콘텐츠에 방해받는 현상을 가리킵니다). 맥락이 계속 길어짐에 따라 모델의 성능이 저하되는 경우가 많은데, 이는 주의가 더 많은 토큰으로 분산되기 때문입니다. 초기 레거시 내용 중 더 이상 관련이 없는 내용이 모델의 현재 작업에 방해가 되기 시작합니다.
맥락 창은 강제 용량 한도가 있습니다. 따라서 창이 거의 가득 찰 때, 당신은 수행 중인 작업을 간단한 설명으로 요약하고, 이 설명과 함께 새로운 맥락 창에서 작업을 계속해야 합니다.
이 과정을 맥락 압축(Compaction)이라고 합니다(주석: 메모리 공간을 확보하기 위해 초장기 기록을 간결한 요약으로 변환하는 프로세스). 물론, 언제든지 이 압축 프로세스를 수동으로 트리거할 수도 있습니다.
상상해보세요, 방금 Claude에게 일을 부탁했고, 그 일을 이미 완료했습니다. 이제 당신의 맥락에는 약간의 정보(예: 도구 호출, 도구 출력 결과, 지시한 내용)가 들어가 있습니다.
다음 단계는 무엇입니까? 놀랍게도 여러분은 다음과 같은 많은 선택지가 있다는 것을 발견할 수도 있습니다:
· 계속하기(Continue)—같은 세션에서 직접 다음 메시지를 보냅니다
· 되감기(/rewind 또는 Esc 키를 두 번 누르기)—타임 리와인드, 이전 메시지로 돌아가 다시 시도합니다
· 지우기(/clear)—새로운 세션을 시작하며, 일반적으로 방금 전 대화에서 추출한 간단한 요약을 함께 합니다
· 압축(Compact)—현재 대화를 요약하고, 이 요약을 기반으로 계속 작업합니다
· 서브 에이전트(Subagents)—다음 단계의 작업을 자체적인 클린 컨텍스트를 갖고 있는 또 다른 AI 에이전트에 위임하고, 최종 작업 결과만을 가져옵니다
직접 "계속"하는 것이 가장 자연스러운 반응이긴 하지만, 다른 네 가지 옵션의 설정은 당신이 컨텍스트를 더 잘 관리할 수 있도록 도와줍니다.
언제 새 세션을 열어아 할까요?
긴 여러 단계의 이전 세션을 유지해야 하는 때와 새로 시작해야 하는 때는 언제일까요? 우리의 경험 법칙은: 새 작업을 시작할 때 새 세션을 열어야 합니다.
100만 개의 컨텍스트 창은 이제 더 긴, 더 복잡한 작업을 매우 신뢰할 수 있게 수행할 수 있음을 의미합니다. 예를 들어, 클로드에게 무언가를 처음부터 전체적인 애플리케이션을 구축하도록 요청하는 것입니다.
그러나 때로는 관련된 작업을 수행할 때도 있습니다. 이 경우 이전 컨텍스트를 일부 유지해야 하지만 전부는 아닙니다. 예를 들어, 새 기능을 방금 작성했고, 이제 해당 기능에 대한 사용 설명서를 작성해야 할 때입니다. 당연히 새 세션을 시작할 수 있지만, 그러면 클로드는 방금 전에 쓴 모든 코드 파일을 다시 읽어야 합니다. 이는 속도가 느리고 비용이 더 많이 드는 일입니다.
「되감기」를 사용하여「수정」하기
만약 당신이 "우수한 컨텍스트 관리 능력"을 대표할 수 있는 좋은 습관을 선택해야 한다면, 그것은 분명히 "되감기(Rewind)"를 잘 활용하는 것입니다.
클로드 코드에서는 Esc 키를 두 번 누르거나 (/rewind 명령을 실행) 하면 이전 메시지 중 아무 것이나로 다시 이동하여 힌트를 다시 제공할 수 있습니다. 그 노드 이후의 모든 대화는 완전히 콘텍스트에서 제거됩니다.
AI의 오류를 수정할 때 "회상"이 종종 더 현명한 접근법입니다. 예를 들어, 클로드가 다섯 개의 파일을 읽고 한 가지 방법을 시도했지만 실패한 경우를 생각해보세요. 당신의 본능적인 반응은 대화 상자에 "이 방법은 작동하지 않아요. X 방법으로 바꿔 보세요."라고 쓰는 것입니다. 하지만 더 현명한 접근법은, 그 다섯 개의 파일을 읽은 직후로 회상한 다음 새로 배운 교훈을 가져와 "A 방법 대신 사용하지 마세요. foo 모듈은 그것을 전혀 지원하지 않습니다—바로 B 방법을 시도해 보세요."라고 말하는 것입니다.
"여기서 요약 시작(summarize from here)" 기능을 사용하여 클로드가 배운 교훈을 자체적으로 요약 정보로 만들도록 할 수도 있습니다. 이것은 방금 함정에 빠졌던 "미래 버전 클로드"가 과거 행동을 아직 시작하지 않은 본인에게 메모를 남긴 것처럼 느껴집니다.
콘텍스트 압축 vs 새로운 대화
대화가 점점 길어지면 그것을 "가볍게" 만들 수 있는 두 가지 방법이 있습니다: /compact(압축) 또는 /clear(초기화 및 처음부터 다시 시작). 이 두 작업은 비슷해 보이지만 실제로는 매우 다릅니다.
압축은 모델이 대화를 요약하고 이 요약을 사용하여 긴 기록을 대체하는 프로세스입니다. 이 프로세스는 "손실이 있는"데, 즉, "어떤 콘텐츠가 중요한지를 결정하는 권한을 클로드에게 넘깁니다."
이점은 무엇도 작성할 필요가 없으며, 클로드가 중요한 경험 또는 파일 기록을 보다 신중하게 보관할 수 있을 수도 있습니다. 또한 압축 방향을 제어하기 위해 지시를 내릴 수도 있습니다(예: /compact는 인증 모듈의 재구성에 중점을 둠으로써 테스트 디버그에 관한 내용을 제거합니다).
/clear 를 사용하면 자신 만의 핵심 포인트를 작성해야 합니다(예: "우리는 인증 미들웨어를 재구성 중이며, 현재 제한 조건은 X이며, 관련 중요 파일은 A와 B이며, 우리는 방법 Y를 제외했습니다"). 그런 다음 매우 깨끗한 상태로 다시 시작해야 합니다. 약간 귀찮을지라도 새로 생성된 새로운 컨텍스트는 당신이 진정으로 관련성이 있다고 생각하는 것의 백분의 백을 가져옵니다.
어떤 종류의 "압축"이 실패할까요?
귀하가 매우 긴 세션을 계속 유지하는 경우, "압축" 효과가 매우 나쁜 상황을 겪을 확률이 높습니다. 우리는 이러한 "실패"가 일반적으로 특정 시점에 발생하는 것을 발견했습니다: 즉, 대형 언어 모델(Large Language Model, LLM)이 다음 작업 방향을 예측하지 못할 때 발생합니다.
예를 들어, 긴 코드 디버깅 후 시스템이 자동으로 요약을 통해 이전 조사 과정을 보여준 후 바로 "이제 우리가 bar.ts에서 본 다른 경고도 수정합시다."라고 말했을 때입니다.
그러나 방금 발생한 세션의 중점이 이전 버그 디버깅에 전적으로 두었기 때문에 수정되지 않은 그 경고는 이미 무시되었을 가능성이 매우 높습니다.
이는 매우 까다로운 문제입니다. 컨텍스트 손실에 제한을 받기 때문에 모델은 압축을 수행하는 그 순간에 가장 똑똑하지 않을 때가 많습니다. 100만 개의 컨텍스트 용량 덕분에 이제는 "내가 다음에 무엇을 하려고하는지" 설명을 추가하여 직접 /compact를 실행할 수 있는 공간이 훨씬 넓어졌습니다.
서브 에이전트 및 완전히 새로운 컨텍스트 윈도우
서브 에이전트는 컨텍스트를 관리하는 데 탁월한 도구입니다. 특히, 특정 작업이 후속적으로 사용되지 않는 대량의 "즉시 삭제" 중간 결과를 생산할 것으로 사전에 알고 있을 때 특히 유용합니다.
클로드가 에이전트 도구를 통해 하위 에이전트를 파생시킬 때, 이 작은 친구는 완전히 새로운 컨텍스트 창을 제공받습니다. 여기서 자유롭게 작업하고 원하는 만큼의 작업을 수행할 수 있습니다. 모든 작업이 완료되면 그 결과를 요약하여 최종 보고서만 "상위" 클로드에게 제출합니다.
우리가 하위 에이전트를 사용해야 할지 여부를 결정하는 "영혼의 질문"은: 나중에 이 도구가 생성한 상세 출력을 다시 볼 필요가 있을까요, 아니면 최종 결론만 필요한가요?
Claude Code가 백그라운드에서 하위 스마트 에이전트를 자동으로 호출할 수 있지만 때때로 명시적으로 그것을 지시할 수도 있습니다。 예를 들어, 다음과 같이 말할 수 있습니다:
· "하위 스마트 에이전트를 보내서 아래 스펙 문서를 기반으로 방금 한 작업을 검증해 보세요."
· "하위 스마트 에이전트를 보내서 다른 코드 라이브러리를 전체적으로 읽고, 그들이 어떻게 인증 프로세스를 구현했는지 요약하고, 그것을 따라 여기에서도 구현해 보세요."
· "하위 스마트 에이전트를 보내서 내 Git 변경 내역을 기반으로이 새 기능에 대한 문서를 작성해 주세요."
요컨대, Claude가 한 번 응답을 완료하고 다음 메시지를 보낼 준비를 할 때, 당신은 의사 결정의 십자로에 서 있게 됩니다.
미래에는 Claude가 충분히 현명해져서 여러분을 위해 이 모든 것을 스스로 처리할 것으로 기대합니다. 그러나 현재로서는 이러한 결정들을 능숙하게 다루는 것이 바로 여러분이 Claude가 고품질 결과물을 만들도록 이끄는 길일 것입니다.
BlockBeats 공식 커뮤니티에 참여하세요:
Telegram 구독 그룹：https://t.me/theblockbeats
Telegram 토론 그룹：https://t.me/BlockBeats_App
Twitter 공식 계정：https://twitter.com/BlockBeatsAsia
