00:00:00100만 컨텍스트 윈도우가 엄청난 업그레이드처럼 들리지만, 실제로는 대부분의 사람들이 생각하는 것보다 훨씬 더 안 좋습니다.
00:00:05그리고 이것이 바로 Claude Code를 작업하는 엔지니어 Tarik이 그 글을 쓴 이유입니다.
00:00:09Claude Code가 100만 토큰에서야 성능이 떨어지기 시작한다고 생각하거나, 100만 토큰이면 걱정할 필요가 없을 정도로 충분하다고 생각한다면, 당신은 틀렸습니다.
00:00:17성능 저하는 사실 윈도우 절반까지 가기도 훨씬 전에 시작됩니다.
00:00:21그리고 대부분의 사람들이 해결책으로 찾는 '컴팩션(요약)'은 보통 상황을 더 악화시킵니다.
00:00:24이 영상이 끝날 때쯤이면, 여러분은 Anthropic 팀이 하는 방식과 똑같이 Claude Code의 성능 저하를 막는 방법을 정확히 알게 될 것입니다.
00:00:31모델 자체는 실제로 강력함에도 불구하고 Claude Code는 성능이 저하된 것처럼 느껴집니다.
00:00:35더 많이 환각을 일으키거나, 이전에 했던 지시사항을 계속해서 다시 상기시켜야 하거나, 장기적으로는 그런 지시사항을 잊어버리는 것을 눈치채셨을지도 모릅니다.
00:00:44저희도 더 긴 작업을 실행할 때 이를 알아챘고, Claude의 성능이 떨어진 것처럼 느껴졌습니다.
00:00:48하지만 그 뒤에는 분명한 이유가 있습니다.
00:00:50이제 Opus 4.5 이후 모델들은 모두 이전의 20만 대신 100만 컨텍스트 윈도우를 탑재하고 있습니다.
00:00:56이 업그레이드가 100만 컨텍스트 윈도우로 우리가 겪던 대부분의 문제를 해결해 줄 것처럼 들리지만, 이는 이론상으로만 좋을 뿐입니다.
00:01:03왜냐하면 이제 이전보다 컨텍스트 윈도우에 더 많은 정보를 넣고, Claude가 수행해야 할 작업에서 벗어나지 않도록 더 많은 문서와 정보로 기반을 다질 수 있게 되었기 때문입니다.
00:01:12100만 컨텍스트 윈도우는 또한 우리가 과거에 직면했던 컨텍스트 문제들을 크게 걱정하지 않고도 장기 실행 작업을 할 수 있는 길을 열어줍니다.
00:01:19하지만 문제는 이 모든 것이 완전히 해결된 것은 아니라는 점입니다.
00:01:22100만 컨텍스트 윈도우는 사실 양날의 검입니다.
00:01:26Claude가 더 길게 작업하고 한 번에 더 많은 정보를 보유할 수 있게 해주지만, 거기에는 대가가 따릅니다.
00:01:30그것은 바로 '컨텍스트 로트(Context Rot)'로 향하는 문을 여는 것입니다.
00:01:32컨텍스트 로트란 컨텍스트 윈도우에 정보가 많아질수록 모델의 성능이 저하되는 현상을 의미합니다. 왜냐하면 컨텍스트 윈도우가 비대해지면 모델이 신경 써야 할 대상이 너무 많아져 집중력을 유지할 수 없기 때문입니다.
00:01:42그리고 100만 컨텍스트 윈도우를 사용하면 컨텍스트가 훨씬 더 꽉 차게 되는데, 이는 Claude의 추론을 방해할 수 있는 정보가 20만 컨텍스트 윈도우 때보다 훨씬 더 많아졌다는 것을 의미합니다.
00:01:53컨텍스트 로트는 아주 비대해진 컨텍스트에서만 일어나는 현상도 아닙니다.
00:01:57Claude Code 제작자에 따르면, 컨텍스트 로트는 실제로는 100만의 훨씬 적은 수준인 약 30만~40만 토큰, 즉 40% 정도 사용량에서부터 발생하기 시작합니다.
00:02:07그러니 컨텍스트 윈도우 크기와 상관없이, 우리는 컨텍스트 로트를 방지하기 위한 조치를 취해야 합니다.
00:02:11그리고 이 사실을 아는 것만으로도 100만 컨텍스트 윈도우를 활용하는 방식이 바뀔 것입니다.
00:02:15먼저 간단히 복습해 보겠습니다.
00:02:16컨텍스트 윈도우는 모델이 한 번에 보는 모든 것으로, 지금까지의 대화, Claude.md 파일, 시스템 프롬프트, 세션으로 읽어 들인 파일, 그리고 모든 도구 호출 출력을 포함합니다.
00:02:26각 프롬프트는 컨텍스트를 더 추가하며, 윈도우가 가득 차면 더 신선한 윈도우로 계속 작업하기 위해 요약하는데, 이것이 바로 컴팩션입니다.
00:02:32컨텍스트를 제대로 관리하지 않으면 에이전트가 실패할 수 있는 4가지 방법이 있습니다.
00:02:37이는 장기 실행 에이전트에서 더욱 분명하고 문제가 됩니다.
00:02:40컨텍스트 오염이 첫 번째인데, 우리는 이미 이것이 무엇인지, 왜 발생하는지 논의했습니다.
00:02:45목표 이탈(Goal Drift)이 두 번째입니다.
00:02:46이것은 에이전트가 당장 집중해야 할 것이 너무 많아서 해야 할 일에서 벗어날 때, 또는 간단히 말해 작업해야 할 목표를 잊어버렸을 때 발생합니다.
00:02:55Claude Code로 작업할 때 이런 일이 자주 발생했을 수 있는데, UI가 특정 모양으로 보이기를 원해서 이미 지시했음에도 불구하고 이를 따르지 않아 실제 목표를 다시 상기시켜야 하는 경우입니다.
00:03:05메모리 손상(Memory Corruption)이 세 번째인데, 이는 실행 중에 에이전트의 내부 상태나 저장된 사실이 잘못되어, 그 잘못된 상태를 기반으로 계속 행동할 때 발생합니다.
00:03:14에이전트가 장기간 실행될 때는 실수 지점을 정확히 파악하기 어려워서 어디서 문제가 시작되었는지 불분명해지는 경우가 많습니다.
00:03:21예를 들어, 메모리 손상은 에이전트 자신이 어떤 방식으로 파일을 작성했는데, 현재 컨텍스트에 없는 하위 에이전트가 파일을 수정하는 상황처럼 보일 수 있습니다.
00:03:29에이전트는 자신의 구식 메모리를 다시 참조하며 파일이 여전히 처음 생성했을 때와 같은 형태로 존재한다고 가정하고 계속 작업합니다.
00:03:37의사결정 부정확성이 마지막입니다.
00:03:39이는 에이전트가 거의 동일한 상황에서 모순된 선택을 할 때 발생합니다. 예를 들어 한 곳에서는 특정 오류 처리 패턴을 사용하고 다른 곳에서는 다른 패턴을 사용하는 식입니다.
00:03:48이 모든 문제는 컨텍스트를 제대로 관리하지 않을 때 발생하며 에이전트의 장기적인 성능에 영향을 미칩니다.
00:03:53이것들이야말로 대부분의 에이전트 하네스가 최적화하려는 핵심 요소들입니다.
00:03:57Claude에게 작업을 요청하여 완료된 후, 다음 지시사항과 관련하여 실제로 5가지 선택지가 있습니다.
00:04:06각각은 여러분의 다음 프롬프트에 따라 달라집니다.
00:04:08각각을 제대로 활용하면 Claude와 작업하는 방식이 크게 개선될 수 있습니다.
00:04:12가장 자연스러운 선택은 계속 진행하는 것이지만, 다른 옵션들이 실제로 컨텍스트를 더 효과적으로 관리하는 데 도움을 줍니다.
00:04:18그러므로 같은 흐름으로 계속할지 아니면 새 세션을 시작할지 신중하게 결정해야 합니다.
00:04:24컨텍스트가 비대해지면 컨텍스트를 비워낼 두 가지 방법이 있는데, 첫 번째 선택지는 앞에서 설명한 기존 내용을 요약하는 방식인 컴팩션입니다.
00:04:32하지만 언제 요약할지 명확히 해야 합니다. 요약은 정보 손실이 발생하기 때문이며, 여러분에게는 중요해 보이지만 Claude에게는 중요하지 않아 보이는 세부 사항들이 삭제될 수 있습니다.
00:04:41결과적으로 중요한 컨텍스트가 더 이상 컨텍스트 윈도우에 존재하지 않게 될 수 있습니다.
00:04:44작업 도중에 자동으로 트리거되면 컴팩션이 더욱 엉망이 되기 때문에, 자동 컴팩션을 그대로 두기보다 직접 컴팩션을 제어하는 것이 좋습니다.
00:04:52Claude는 중요하다고 생각하는 것만 남기고 필요 없다고 생각되는 모든 것은 제거하는 경향이 있어서, 컴팩션 중에는 사실 Claude가 가장 신뢰할 수 없는 상태가 됩니다.
00:05:00그 시점에서 Claude의 초점은 순전히 요약에 맞춰져 있으며, 평소 Claude를 더 능력 있게 만드는 시스템 프롬프트 및 기타 요소 같은 지원 컨텍스트가 제거된 상태입니다.
00:05:08그러고 나면 Claude는 무엇이 중요한지에 대한 자신의 가정에 크게 의존하게 되는데, 이는 종종 잘못된 컴팩션 결정으로 이어질 수 있습니다.
00:05:14나쁜 컴팩션은 보통 모델이 작업의 방향을 명확하게 파악하지 못할 때 발생합니다.
00:05:19예를 들어 긴 디버깅 세션 중에 자동 컴팩션 후에 이전에 발생했던 경고가 있었다면, 그 특정 경고를 수정하라고 요청할 경우 Claude는 여러분이 말하는 경고가 무엇인지 모를 것입니다.
00:05:29이는 세션 전체가 디버깅에 초점이 맞춰져 있어서, 디버깅 활동에 대한 일반적인 요약만 유지되고 특정 경고는 노이즈로 취급되어 삭제되었기 때문입니다.
00:05:39최신 편향(Recency Bias)은 이를 더 악화시킵니다.
00:05:41컴팩션이 트리거되면, 프롬프트는 작업 중이던 최근 세부 사항을 보존하는 것을 우선시합니다.
00:05:46그래서 더 오래되었지만 여전히 중요한 정보는 무시되거나 제외될 수 있습니다.
00:05:50만약 이전에 무언가가 잘못 수행되었다면, 컴팩션 후에 모델은 더 이상 그 사실을 알지 못할 수 있습니다.
00:05:54컴팩션 중에는 도구 호출 기록이 완전히 보존되지 않기 때문에 모델은 프로젝트의 전체 상태가 아닌 트랜스크립트 수준의 요약에만 접근할 수 있습니다.
00:06:01자동 컴팩션이 발생하는 시점을 제어하는 플래그를 설정할 수 있지만, 이는 여러분이 더 자주 능동적으로 관리해야 할 부분입니다.
00:06:07컨텍스트 로트가 나타나기 시작하는 지점인 제작자가 언급한 30만~40만 토큰 범위에서 컴팩션을 트리거하고, 항상 직접 컴팩션 지시사항을 제공하세요. Claude는 명시적인 지시사항이 포함될 때 더 신중하게 반응하기 때문입니다.
00:06:22어떤 결정, 제약 사항, 발견된 문제를 가져갈지 알려주어 Claude가 무엇을 우선순위에 두어야 할지 알게 하세요.
00:06:27따라서 새로운 윈도우로 이전 작업 흐름의 컨텍스트를 가져가고 싶을 때 컴팩션을 실행해야 하며, 처음부터 완전히 새로 시작하고 싶을 때 실행해서는 안 됩니다.
00:06:34하지만 더 진행하기 전에 스폰서의 한 마디를 들어보겠습니다.
00:06:37아이디어를 실제 제품으로 전환하도록 돕는 AI 기반 플랫폼, Verdant입니다.
00:06:41빌드 작업 도중 집중력을 발휘하고 있는데, 크레딧이 다 떨어져 버립니다.
00:06:45AI가 멈춰버리고, 탄력도 사라집니다.
00:06:47모든 AI 코딩 도구가 여러분에게 이런 짓을 하지만, Verdant는 그렇지 않습니다.
00:06:50크레딧이 0이 되면, 한 푼 더 쓰지 않고도 AI가 계속 작동하도록 유지하는 제로 비용 모드인 '에코 모드'로 전환하세요.
00:06:56중단도, 충전도, 탄력 상실도 없습니다.
00:06:59그냥 계속 빌드하면 됩니다.
00:07:00그리고 크레딧이 있을 때도 Claude, GPT, Gemini 사이에서 고민할 필요가 없습니다.
00:07:04Verdant의 멀티 플랜 모드는 세 가지 모델을 결정 위원회처럼 함께 실행하여, 모델 선택에 대한 불안 없이 더 나은 계획을 제공합니다.
00:07:10더 많은 유연성을 원하시나요?
00:07:11BYOK를 사용하면 여러분의 API 키를 Verdant에 직접 연결할 수 있습니다.
00:07:15회사에서 사용하는 Claude나 GPT 크레딧을 사용하세요. 플랫폼 비용은 들지 않습니다.
00:07:18실제로 사용한 만큼만 지불하면 됩니다.
00:07:20100 크레딧과 7일간의 테스트 기간을 드립니다.
00:07:23고정 댓글의 링크를 클릭하고 Verdant를 무료로 체험해 보세요.
00:07:26두 번째 선택지는 모든 컨텍스트를 제거하고 빈 컨텍스트로 새 세션을 시작하는 'Clear' 명령어를 사용하는 것입니다.
00:07:32컴팩션과 달리 아무것도 다음으로 전달되지 않으며, 여러분이 다시 제공하는 내용만 컨텍스트 윈도우에 남습니다.
00:07:37컴팩션과 마찬가지로, 단순히 컨텍스트가 부족할 때만 Clear를 사용해서는 안 됩니다.
00:07:41관련 없는 작업으로 전환하는 경우, 이전 작업이 새 작업에 방해가 되지 않도록 세션을 비우고 새로 시작하는 것이 간단합니다.
00:07:49예를 들어, 에이전트에게 작업 중인 애플리케이션에 대한 테스트 케이스를 작성해 달라고 요청했다면, 그 테스트 케이스가 어떻게 생성되었는지에 대한 세부 사항은 유지하지 않는 편이 좋을 수 있습니다.
00:07:57같은 컨텍스트 내에서 계속 디버깅하는 대신, 새로운 세션을 시작할 수 있습니다.
00:08:01이렇게 하면 Claude는 이전에 테스트 케이스를 생성했던 방식에 영향을 받지 않고 더 효과적으로 애플리케이션 디버깅에 집중할 수 있습니다.
00:08:08Clear와 컴팩션을 결합하여 사용할 수 있는 또 다른 접근 방식도 있습니다.
00:08:12이를 통해 원하는 내용만 유지하고 나머지는 모두 버릴 수 있습니다.
00:08:16아이디어는 보존하고 싶은 정보를 캡처하는 구조화된 JSON 형식을 사용하는 것입니다.
00:08:21자주 재사용할 수 있도록 사용자 정의 명령어를 만들 수 있습니다.
00:08:24그 명령어에 전체 작업, 현재 상태, 제약 사항, 발견된 문제, 그리고 Claude가 유지하기를 원하는 기타 관련 세부 사항이 포함된 JSON 구조를 넣고, 이를 파일로 저장하라고 지시할 수 있습니다.
00:08:35이 접근 방식은 두 방법의 장점을 모두 얻을 수 있게 해줍니다.
00:08:38명령어를 실행하면 전체 대화와 애플리케이션의 현재 상태를 분석하여(일반적인 컴팩션이 안정적으로 보존하지 못하는 부분입니다), 지정된 파일로 모든 것을 저장합니다.
00:08:48스키마는 산문보다 훨씬 엄격하므로, Claude가 정의된 구조를 따를 때 중요한 내용을 더 일관되고 정확하게 표현할 수 있습니다.
00:08:56정보가 파일에 저장된 후, 컨텍스트 윈도우에서 모든 것을 제거하기 위해 Clear 명령어를 안전하게 사용할 수 있습니다.
00:09:02그런 다음 새 세션을 시작하고 Claude에게 컨텍스트를 수집하고 다음 작업을 구현하기 위해 해당 문서를 다시 참조하라고 지시할 수 있습니다.
00:09:14앞서 언급했듯이 컨텍스트가 커질수록 더 많은 정보가 주의를 끌기 위해 경쟁하기 때문에 에이전트의 초점이 흔들릴 수 있으며, 이는 100만 컨텍스트 윈도우에서 훨씬 더 두드러집니다.
00:09:23이 관행은 앞서 논의한 목표 이탈 문제와 의사결정 불일치 문제를 해결하는 데 도움이 됩니다.
00:09:29긴 실행 작업에서 계속 앞으로 나아가기보다, 주기적으로 멈춰서 에이전트에게 지금까지 무엇을 했는지 제약 사항 및 기타 중요한 요소와 함께 요약해 달라고 요청하는 것이 유용합니다.
00:09:39이렇게 하면 원래 목표가 강화되고 주요 세부 사항이 컨텍스트 윈도우의 이전 섹션에 묻히지 않고 더 최근 부분으로 다시 돌아오게 됩니다.
00:09:48이는 중요한 정보가 에이전트의 작업 컨텍스트에서 신선하게 유지되도록 하고 컴팩션 중에 손실되거나 시간이 지남에 따라 희석될 가능성을 줄여줍니다.
00:09:56따라서 에이전트는 수행해야 할 작업에 더 정렬된 상태를 유지하고 결정에 있어 더 나은 일관성을 유지합니다.
00:10:02또한, 저희 콘텐츠가 마음에 드신다면 '하이프(Hype) 버튼'을 누르는 것을 고려해 주세요. 저희가 이런 콘텐츠를 더 많이 만들고 더 많은 사람에게 도달하는 데 도움이 됩니다.
00:10:09하위 에이전트는 별것 아닌 것처럼 보일 수 있지만, 사실 컨텍스트를 관리하는 매우 중요한 방법입니다.
00:10:14각 하위 에이전트는 전용 컨텍스트 윈도우, 전체 도구 접근 권한, 작업을 완료하는 데 필요한 권한을 가진 독립적인 인스턴스입니다.
00:10:22그들은 부모 에이전트가 제공한 별도의 컨텍스트에서 할당된 작업을 실행한 다음, 최종 결과만 주 컨텍스트로 다시 반환합니다.
00:10:30따라서 도구 호출, 파일 읽기, 웹 검색, 중간 추론 등은 하위 에이전트의 컨텍스트 내에 머무르며 주 에이전트의 컨텍스트 윈도우를 오염시키지 않습니다.
00:10:40이것이 컨텍스트 로트를 줄이는 효과적인 방법입니다. 조사 작업이 가장 명확한 예입니다.
00:10:45에이전트가 여러 웹사이트, 페이지, 소스를 거치게 되는데, 이런 모든 원본 정보가 주 컨텍스트 윈도우에 계속 추가되는 것을 원하지 않을 것입니다.
00:10:53이런 경우, 하위 에이전트가 독립적으로 작업을 처리하고 최종 합성 결과만 반환할 수 있습니다.
00:10:58하위 에이전트를 사용하기 전에 스스로에게 물어봐야 할 핵심 질문은 중간 단계에 다시 접근해야 하는지, 아니면 최종 결과물만 중요한지 여부입니다.
00:11:07Claude Code도 하위 에이전트 오케스트레이션을 자체적으로 관리하며 작업을 자동으로 처리하기 위해 에이전트를 생성할 수 있습니다.
00:11:13하지만 가끔은 작업을 하위 에이전트에 위임하여 격리된 상태에서 처리되도록 프롬프트에 명시적으로 지정해야 할 때가 있습니다.
00:11:20그러니 조사 작업, 리팩토링 작업, 요약 또는 문서 생성 작업을 하는 경우, 주 에이전트 대신 하위 에이전트를 사용하여 분리하는 것을 고려하세요.
00:11:30마지막으로, 단순히 수정하는 것보다 'Rewind(되감기)'하는 것이 정말 중요합니다. 왜냐하면 올바른 상태만 유지하면서 컨텍스트 윈도우에서 관련 없는 부분이나 잘못된 부분을 제거하기 때문입니다.
00:11:40Claude가 실수에 부딪힐 때마다, 사람들은 종종 다른 접근 방식을 취하도록 다시 프롬프트하려 합니다.
00:11:44하지만 더 나은 옵션은 Rewind하고 새 프롬프트에서 올바른 방향을 제공하는 것입니다.
00:11:49Rewind 명령어를 사용하거나 Escape 키를 두 번 눌러서 이 작업을 할 수 있습니다.
00:11:53Rewind 후에는 그 지점부터 요약할 수도 있어, 해당 단계까지의 대화는 유용한 컨텍스트로 보존하면서 문제를 일으킨 부분은 제거할 수 있습니다.
00:12:01Rewind에는 여러 가지 이점이 있습니다.
00:12:03첫째, 문제가 발생한 부분을 제거하여 컨텍스트 윈도우를 깨끗하게 만들며, 결과적으로 올바른 구현만 보존하는 더 깨끗한 컴팩션 요약이 만들어집니다.
00:12:12중요한 정보를 고정하더라도 에이전트가 목표에서 벗어난 섹션을 가져가는 것을 방지하여 의사결정 불일치와 목표 이탈을 모두 줄이는 데 도움이 됩니다.
00:12:21하위 에이전트를 사용하는 경우, Rewind를 하면 작업이 넘겨질 때 더 깨끗하고 정확한 컨텍스트를 받게 되어 잘못된 접근 방식이 작업 상태에 포함되지 않습니다.
00:12:30마찬가지로, Handoff 명령어를 사용하면 손상되거나 오래된 상태 대신 애플리케이션의 올바른 상태를 캡처합니다.
00:12:37그러니 반복해서 앞으로 수정하려 하지 말고 Rewind하는 습관을 들여 에이전트가 전체 세션 동안 항상 깨끗하고 정확한 상태에서 작업하도록 하세요.
00:12:45이것으로 영상의 끝에 도달했습니다.
00:12:47채널을 지원하고 이런 영상을 계속 만드는 데 도움을 주고 싶다면, 아래의 'Super Thanks' 버튼을 사용하여 그렇게 할 수 있습니다.
00:12:54늘 그렇듯, 시청해 주셔서 감사하며 다음 영상에서 뵙겠습니다.