메인 컨텍스트를 절약하여 품질을 높이고 비용을 낮추는 방법: Context Drop 제작까지

상원정길(上原正吉, EarthLink Network Co., Ltd.)입니다. Claude Code를 개발의 주체로 삼아 20개가 넘는 제품을 혼자 동시에 개발하고 운영하고 있습니다. 이 글은 그 현장의 실측 기록입니다.

어느 시점부터인가, Claude Code가 '고장' 나기 시작했습니다.

정확히 말하자면, 고장 난 것은 Claude Code 자체가 아닙니다. 고장 난 것은 우리의 사용 방식이었습니다. 다수의 에이전트를 한 번에 구동하고, 거대한 로그나 스크린샷을 대화에 붙여 넣으며, 긴 세션을 /compact로 연결하면서 계속 돌리는 것—Claude Code의 'ultracode'를 켜고 무거운 팬아웃(fan-out)을 당연하게 사용하는 운영 방식입니다. 이를 지속하다 보면 어느 날 갑자기 tool 호출이 원본 텍스트로 대화에 새어 나오거나, 모델이 생각한 대로 한마디도 답하지 않는 현상이 발생합니다.

기록을 살펴보면, 이러한 오류들의 공통점은 **컨텍스트의 비대화(context の肥大化)**였습니다 (인과관계는 상관관계 수준이며, §2를 참조하십시오). 대화가 커질수록 매 턴 재전송 비용이 늘어나고, 손상 발생 조건에 가까워지며, 응답이 불안정해집니다.

Context Drop은 이 문제의 한 지점—'원본 컨텍스트(raw context)를 메인 대화에 직접 흘려 넣는' 습관—을 끊기 위해 만든 작은 데스크톱 도구입니다. 스크린샷이나 로그, JSON 등을 메인 대화가 아닌 격리된 서브 에이전트(메인과 별도의 대화 기록에서 작동하는 작업 담당 AI)에게 읽게 하고, 돌아오는 것은 요약(compact result)만 받습니다. 메인 컨텍스트는 가볍게 유지됩니다.

본고에서는 먼저 '왜 무거운 운영 방식에서 고장 나는지'와 'effort / model / ultracode를 어떻게 분배하여 사용할지'를 전제 지식으로 정리하고, 그 위에 Context Drop이 무엇인지, 어떻게 사용하며, 어떻게 설치하는지를 화면 캡처와 함께 설명합니다.

먼저 용어를 정의하겠습니다. 'ultracode'는 Claude Code 측의 opt-in 메커니즘입니다. 프롬프트에 ultracode라는 키워드를 포함하거나 세션 전체에서 on으로 설정하면 유효해집니다. 사내 설계 기록이 정한 상시 온 모드는 아닙니다.

on 상태일 때, 모델은 실질적인 작업마다 다수 에이전트의 워크플로우를 구성하여 지휘하며, 게다가 토큰 비용을 제약으로 간주하지 않습니다(토큰은 AI가 입력과 출력 양을 세는 단위이며, 요금도 이것으로 결정됩니다). 그래서 자연스럽게 거대한 팬아웃이 됩니다. 실제로 사내 기록에는 v0.256.0의 77 에이전트 적대 리뷰가 의무가 아닌 재량(ultracode)으로 구동되었다고 나와 있습니다. 규칙으로 의무화된 것이 아니라, ultracode를 붙였기 때문에 가능했던 규모였습니다.

강력한 것은 틀림없습니다. 다만, 그 이면에서 쌓이는 것이 컨텍스트와 토큰입니다. '똑똑한 모델에게, 대량의 컨텍스트를, 많은 에이전트로, 한 번에 처리하게 하는'—이 운영 방식이 축적하는 컨텍스트야말로 다음에 언급할 오류들의 공통점이었습니다.

가장 까다로웠던 것은 Opus 4.8 계열에서 발생하는 tool-call 손상입니다. 본래 구조화된 tool_use가 되어야 할 tool 호출이 생 텍스트로 대화에 새어 나옵니다. 내부의 제어 태그가 count / court / call 같은 실재하는 영어 단어로 변질되어 파서(parser)가 'tool call could not be parsed'라고 오류를 내뱉습니다.

이 발생 조건은 시사적입니다—Opus 4.8/4.7, 방대한 컨텍스트(1M 세션), /compact 직후, 일본어 등 비-ASCII 인자, 3개 이상의 MCP 서버, 긴 tool 인자, 다중 tool 동시 실행. 요컨대 '무겁고・길게・다국어로・채워 넣은' 상태일수록 발생하기 쉽습니다.

더 나쁜 것은 한 번 고장 난 기록이 스스로 강화된다는 점입니다. 같은 세션에서 재시도해도 악화될 뿐 자가 복구되지 않습니다. 해결 방법은 '앞으로 나아가는 것(forward)'이 아니라 '되돌아가는 것(backward)'—/rewind → /compact → /clear여야 하며, --continue가 아닙니다.

참고로, '컨텍스트 비대화 → 손상'이라는 인과관계는 기록 상으로는 상관관계 수준의 뒷받침에 머뭅니다. 또한 hook(특정 타이밍에 자동 실행되는 처리)에서 /compact

자동으로 실행하는 것은 불가능하다. 그렇기 때문에, 비대해지지 않도록 하는 습관 자체가 효과를 발휘한다.

/compact

은 대화를 압축하여 가볍게 만드는 기능이다. 그런데 세션 시작 시에 19~32 KB의 다이제스트(digest)를 자동으로 재주입하는 메커니즘이 작동하고 있었기 때문에, compact 직후에 줄어든 부분이 상쇄되어 발화 조건이 다시 만들어지고 있었다.
"compact 했는데도 금방 비대해진다"── 그 기제가 기록으로 남아있다.

또 다른 측면은 장시간(marathon) 세션 후의 완전한 무음 상태다. Opus가 전혀 출력을 하지 않게 된다. 같은 요청을 새로운 세션에서 보내면 즉시 응답한다. ─ 쌓인 context가 가장 강력한 차이점이었다.

여기까지 읽으면, '어려우면 Claude Code를 가장 높은 설정으로 사용하면 되지 않을까'라고 생각할 수 있다. 모델을 크게 하고, effort를 높이고, ultracode로 에이전트를 늘리면 똑똑해진다면, 돈만 신경 쓰지 않는다면 처음부터 모든 것을 가장 현명한 설정으로 돌리면 된다──라는 사고방식이다.

우리도 실제로 그와 비슷한 운영을 했다. 그리고 문제는 거기서 발생했다. 위에 언급된 손상된 발화 조건을 재검토해야 한다. Opus의 최상위 모델, 1M의 방대한 컨텍스트, 다중 에이전트의 팬아웃(fan-out). 이 모든 것이 '최대 설정' 그 자체다. 최대 설정으로 돌릴수록 대화는 부풀어 오르고, 부푼 대화 속에서 tool 호출이 망가지며 응답이 멈췄다.

즉, 이것은 비용의 문제라기보다 품질의 문제였다. 인과관계는 상관관계 수준의 뒷받침에 그쳤지만, 우리는 돈을 들여 문맥을 쌓아 올린 것 자체가 품질을 떨어뜨리고 있다고 판단했다. 돈으로 품질을 사려고 했지만, 실제로는 돈을 써서 품질을 떨어뜨리고 있었던 셈이다. 그래서 답은 '더 높은 설정으로'가 아니라, '메인 대화에 무엇을 넣지 않을지'를 결정하는 것이었다.

손상만 있는 것은 아니다. 비용 관점에서도 context 비대는 효과적이다. Claude Code는 매 턴 '지금까지의 전체 대화 + 모든 tool 결과'를 입력으로 재전송 및 재과금한다. 기록에 남은 추산치로는, 20k 토큰의 로그를 한 번 읽을 때마다 나머지 30턴 동안 약 85k 토큰 상당을 계속 지불하게 된다. 200 토큰 다이제스트라면 약 0.9k── 약 100배의 차이다. 게다가 큰 로딩은 compaction의 도래를 앞당기고, 앞서 언급한 손상 위험에 가깝게 만든다.

극단적인 예로, 무거운 게이트(gate)를 전량 적용한 팬아웃으로 하나의 블로그 기사를 처리했을 때는, 서브 에이전트 포함하여 약 80만 토큰・부모 context 289k을 소비한 사례도 남아있다.

여기서 한 가지, 직관에 반하는 사실을 알아두고 싶다. '무거운 로딩은 서브 에이전트에게 전부 맡기면 싸진다'── 이것은 절반만 맞는 말이다.

서브 에이전트의 로딩도 과금된다. 격리는 부모 context를 지키지만, 그 작업을 공짜로 해주지는 않는다. 위임(delegation)은 과금을 이동시킬 뿐, 줄이는 것이 아니다.

그렇다면 위임의 가치는 무엇일까 ── 부모 대화를 오염시키지 않는 것이다. 원본의 방대한 데이터를 부모에게 남기지 않고 격리하면, 부모 context는 가볍게 유지되고, 손상된 발화 조건에서 멀어지며, 이후 턴의 재전송 비용도 늘어나지 않는다. 이 '격리하여 부모를 보호한다'라는 생각이 그대로 Context Drop의 설계 사상이 되었다.

비대와 비용에 대한 대책은 두 가지 레버로 정리할 수 있다. context 다이어트(너무 많이 읽지 않기/너무 많이 붙이지 않기)와, 모델 티어(model tier) 분배다. Context Drop은 전자에 필요한 도구이지만, 후자── 그리고 '한 번에 얼마나 생각하게 할 것인지', '몇 명으로 분담시킬 것인지'──도 알아두면 운영이 안정되므로 여기서 정리해 둔다.

effort는 '한 사람이 얼마나 깊게 생각하는지', **ultracode는 '몇 명으로 분담/검증할지'**이다. 이 두 가지는 별개로 조정할 수 있다.

effort | 생각 방식 | 적합한 작업
|---|---|
| low | 거의 즉답이며, 추론은 최소화 | 문구 수정, grep 결과 정리, 기계적 치환
| ... |
effort를 높일수록 느려지고 토큰도 많이 사용한다. 정확도가 높아지는 것은 '생각하면 알 수 있는 문제'에 한정된다. 정보가 부족한 것이 원인이라면 effort를 높여도 해결되지 않는다. 그 경우 효과적인 것은 조사 범위를 넓히는 것이다.

모델을 선택하는 것에는 사내 운영 규칙이 있다. 요약하자면:

• 리스크로 결정 (하한): 과금・인증・운영 환경(본격 배포)・비가역적인 작업이 관련되면 top + 사람의 확인.
• 크기로 결정: 작고 기계적이면 light, 여러 파일이나 신규 설계라면 top으로 큰 틀을 정한다.
• 작업 유형으로 결정: 구현・버그 수정・테스트는 mid, 리뷰・적대 검증・설계는 top.
• 헷갈리면 상위로: 품질 사고의 손실은 토큰 절약을 능가한다.

model은 '지능의 상한선', effort는 '그 지성으로 얼마나 깊이 생각하는지', ultracode는 '몇 명이 참여하는지'이다. tier 판단 기준으로 model을 정하고, 위 A~E에서 effort와 ultracode를 결정하는 순서로 생각하면 헷갈리지 않는다.

effort

• 시작 시:
  claude --effort high
  ( claude --help에서 확인 가능. 설명은 '현재 세션의 Effort level', 값은 low/medium/high/xhigh/max )
• 대화 도중:
  /effort
  이 프로젝트에서 실제로 /effort를 사용해 본 결과, Set effort level to medium (saved as your default for new sessions)라고 표시되었다. 즉, 대화 중에 변경한 값은 이후의 새로운 세션의 기본값으로도 저장된다.
• 상용 기본값:
  ~/.claude/settings.json의 `

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

/code-review high

와 같은 것은 **리뷰 범위의 넓이(지적하는 방식)**를 나타내는 레벨이다. effort(세션에서 생각하는 깊이)와 이름은 비슷하지만 별개의 것이다. 또한 /code-review ultra는 클라우드에서 여러 에이전트가 작동하는 유료 리뷰이며 (사용자가 명시적으로 시작), ultracode와도 다른 메커니즘이다.

기본값은 **A(medium / off)**로 두고, 다음과 같이 전환하는 것이 좋다.

• 어려운 1점을 생각하게 하고 싶을 때 → effort만 올린다 (B)
• 누락된 부분이 있으면 곤란할 때 → ultracode를 붙인다 (C)
• merge 전이나 본상 장애 등 절대 빠뜨릴 수 없을 때 → 둘 다 올린다 (D)

이 '설정을 작업에 맞추는' 습관과, 'context를 가볍게 유지하는' 습관. 이 두 가지가 갖춰져야 무거운 운영에서도 고장 나지 않는다. Context Drop은 후자(context를 가볍게 유지하는 것)를 툴과 절차 측면에서 메커니즘으로 만들어준다.

Context Drop은 로컬 전용 데스크톱 메뉴바 앱이다. 텔레메트리 기능이 없고, Context Drop 자체가 네트워크로 무언가를 보내지도 않는다. 할 일은 단 하나— 원본 컨텍스트를 메인 대화에 넣지 않고, 격리된 서브 에이전트로 빼내는 것이다.

핵심 플로우는 다음과 같다:

원본 컨텍스트(raw) → Context Drop packet → 격리 subagent → 요약(compact) → main Claude

그리고, 의도적으로 하지 않는 플로우가 이것이다:

원본 컨텍스트(raw) → main Claude → subagent ← 이것은 금지

차이점은 '원본 데이터가 한 번이라도 메인 대화를 거치는지 여부'다. 전자는 메인을 전혀 오염시키지 않는다. 후자는 메인에 원본 데이터가 새겨져, 이후 턴에서 계속 재과금되고, 손상 위험을 높인다. Context Drop은 메인에는 파일의 위치 정보 같은 것만 전달하고, 내용을 읽는 작업은 플러그인의 지시에 따라 서브 에이전트로 돌림으로써 이 선을 긋는다.

설계상의 또 다른 기둥은 **'capture first, route later(먼저 모으고, 나중에 경로를 정하기)'**이다. 소재를 모으는 단계에서는 목적지를 정하지 않는다. 보내고 싶은 Claude Code 세션(탭)에서 /context-drop:pull

(단축형 /cd)
을 치는 순간, 그 세션이 '가져간다'. 그래서 '어떤 프로젝트의 어떤 세션에 전달할지'로 망설이지 않는다.

기본은 3단계다.

• 모으기: 앱에서 Start Capture(글로벌 단축키 Cmd+Shift+9)를 누르면, 누른 후에 복사한 소재만 packet에 쌓여간다. 파일은 언제든지 창으로 드래그 & 드롭할 수 있다. Stop으로 일시 정지(쌓인 항목은 남아 있음), Clear로 비우기.
• 가져오기: 전달하고 싶은 Claude Code 탭에서 /context-drop:pull <지시>
  을 친다 (옵션 단축형 /cd를 넣었다면 /cd <지시>도 좋다. §6 참조). 지시문에서 ANALYZE(조사만) / FIX(수정까지) / REVIEW(리뷰) 중 하나를 선택한다.
• 받기: 격리 서브 에이전트가 packet 안의 내용물(스크린샷・로그・JSON・파일)을 자신의 컨텍스트로 읽고, 돌아오는 것은 요약뿐이다.

이것이 얼마나 효과적인지 실측으로 보여준다. 이 프로젝트에서, PNG 스크린샷 2장 (163,772 바이트와 173,585 바이트)과 짧은 텍스트 3개 (184 / 487 / 87 바이트), 총 5개의 item packet을 /cd

그렇게 가져왔습니다. 격리 서브 에이전트(Isolated Sub-Agent)는 19,365 토큰을 사용하여 그것들을 읽었습니다. 반면, 메인 대화에 들어간 것은 간결한 목록(수백 토큰 규모)뿐이었고, 원본 바이트 배열은 메인 컨텍스트에 한 번도 들어가 있지 않았습니다. 만약 이 두 장의 스크린샷을 그대로 메인에 붙였다면, 그 무게가 메인 컨텍스트에 각인되어 이후 턴(turn)에서 계속 재전송되었을 것입니다. 그 무게를 일회용 서브 에이전트에게 대신 맡기고, 메인은 가볍게 유지하는 것── 이것이 Context Drop의 모든 가치입니다. (다만 '위임 ≠ 절약'이라는 점에 유의하여, 이 19,365 토큰 역시 과금이 됩니다. 절약할 수 있는 것은 메인 컨텍스트와 이후 매 턴의 재전송분입니다.)

여기서는 자세히 설명하겠습니다. Context Drop은 Tauri(Rust와 Web 프런트엔드로 데스크톱 앱을 만드는 프레임워크)로 제작되었으며, macOS와 Windows 양쪽 모두를 대상으로 설계되었습니다. 다만, 빌드된 배포물(.dmg)을 준비하고 있는 것은 현재 macOS의 Apple Silicon(arm64) 버전만입니다. 아래는 해당 Apple Silicon 버전에서의 절차입니다. Intel Mac과 Windows의 경우, Step 1 이후에 있는 '소스에서 빌드하기'를 참고해 주십시오.

GitHub의 Releases 페이지(https://github.com/EarthLinkNetwork/context-drop/releases)를 열고, **가장 최신 버전(Latest로 표시된 버전)**의 .dmg를 클릭하여 다운로드합니다. 이 기사 화면과 절차는 v0.1.3(Context-Drop-v0.1.3-macos-arm64.dmg, 약 6.3 MB)을 기준으로 확인했습니다. 2026년 10월 4일자 최신 버전은 v0.1.5이며, 읽는 시점에 따라 더 새로운 버전이 나왔을 수 있으니 반드시 최신 버전을 받으셔야 합니다. 아래 파일명이나 버전 번호도 해당 버전에 맞춰 변경해 주십시오. 이 .dmg는 Apple의 Developer ID 인증서로 서명되었으며, **Apple의 notarization(공증) 및 staple(스태플링)**이 완료되어 Gatekeeper에 의해 차단되지 않습니다 (최초 1회 macOS에서 '인터넷에서 다운로드된 앱' 확인 메시지가 뜨면 '열기'를 선택하세요).

Context Drop은 OSS(MIT 라이선스)로 소스 코드가 공개되어 있으므로, 빌드된 배포물이 없는 환경에서는 소스에서 직접 빌드할 수 있습니다. 필요한 것은 다음 3가지입니다.

• Rust (stable 버전. rustup으로 설치)
• Node.js와 pnpm
• 해당 OS의 WebView (Windows의 경우 Microsoft Edge WebView2 Runtime)

빌드 명령어는 다음과 같습니다.

git clone https://github.com/EarthLinkNetwork/context-drop.git
cd context-drop
pnpm install
...

완성된 인스톨러나 앱은 apps/desktop/src-tauri/target/release/bundle/ 아래에 출력됩니다 (데스크톱 앱이 독립적인 Cargo workspace이기 때문에, 리포지토리 직하단의 target/가 아닙니다). Windows에서의 컴파일 및 링크는 CI(GitHub Actions의 windows-latest)에서 매번 확인하고 있습니다. 다만 솔직히 말씀드리자면, 완성된 Windows 버전을 실제 기기에서 실행하여 사용하는 것은 저희 손으로는 아직 확인하지 못했습니다. 만약 문제가 발생하면 GitHub의 issue나 pull request로 알려주시면 감사하겠습니다.

다운로드한 .dmg(예: Context-Drop-v0.1.3-macos-arm64.dmg)를 더블 클릭하여 열면, Context Drop.app과 Applications 폴더로 가는 바로가기가 나열됩니다. 앱을 Applications로 드래그하여 복사합니다.

Applications에서 Context Drop을 실행한다. 이것은 메뉴바 상주 앱이므로, 화면 상단 메뉴바의 아이콘에서 창을 열 수 있다. 아직 Claude Code 연동이 완료되지 않았기 때문에, 상단에 'Finish setup' 배너('Open Setup' 버튼 포함)가 표시된다. 참고로, 앱을 실행하는 시점에 동봉된 context-drop CLI가 지정된 위치에 배치(업데이트)된다.

※ 이 첫 실행 화면과 이후 Context Drop 앱 화면(총 4장)은 v0.1.3의 실제 앱 UI(프론트엔드) 상태를 재현하여 그린 것이며, 실기 네이티브 창 스크린샷이 아니다.

배너의 'Open Setup' 또는 창 상단의 Settings 탭에서 'Claude Code Setup' 섹션을 연다. 여기에 앱 내의 'Step 1'(플러그인을 활성화하는 두 개의 명령어)과 'Step 2'(capture & route)가 나열되어 있으며, 복사 가능한 /plugin … 명령어가 있다. 복사 버튼으로 그대로 복사할 수 있다.

여기부터는 Claude Code 측의 작업이다(여기는 스크린샷이 아니라, 명령과 실제 출력을 텍스트로 보여준다). Claude Code 세션에서 다음을 입력한다. 이것은 공개 마켓플레이스 방식으로, 리포지토리 이름을 직접 지정할 수 있다:

/plugin marketplace add EarthLinkNetwork/context-drop

성공하면 다음과 같은 줄이 표시된다(글쓴이의 환경에서 동일한 계통의 명령을 실행했을 때 나온 줄):

Successfully added marketplace: context-drop

계속하여 설치한다:

/plugin install context-drop@context-drop

출력(체크 표시 포함):

Installed context-drop. Run /reload-plugins to apply.

메시지대로 반영한다:

/reload-plugins

Reloaded:로 시작하는 줄이 표시되면 완료다.

중요: 설치하기 전부터 열려 있던 Claude Code 세션은, /reload-plugins를 실행하거나 새 세션을 열 때까지, /context-drop:pull을 인식하지 못한다(/cd는 더욱 Step 6a의 단축형 설치가 필요하다). 실제로 오래 열어둔 세션에서 /cd ...를 입력했을 때, 명령이 아니라 단순한 텍스트로 처리되었다. '/cd가 작동하지 않는다'고 생각되면, 먼저 이것을 의심해 보길 바란다.

오프라인(인터넷 없음)으로 넣고 싶은 경우: Settings의 'Claude Code Setup → Optional / offline install → Install locally'에서 마켓플레이스를 로컬에 배치하고, 표시된 로컬 경로를 /plugin marketplace add <경로>에 전달한다. 공개 루트든 로컬이든, capture와 context-drop CLI 배치는 데스크톱 앱이 담당하므로, 앱은 켜져 있어야 한다(앱 실행 시 CLI가 지정된 위치에 배치된다).

플러그인 본체가 제공하는 것은 /context-drop:pull이고, 짧은 /cd는 다른 alias이다. 사용하고 싶다면 Settings → Claude Code Setup → Optional / offline install에서 Install /cd short alias를 클릭한다. 넣지 않는 경우, 본문에서 /cd라고 적힌 부분을 모두 /context-drop:pull로 바꿔주길 바란다.

Settings로 돌아가면, 'Finish setup' 배너 대신 'Plugin installed in Claude Code' 배지가 나타난다. 이것은 앱이 Claude Code 측의 도입 기록(installed_plugins.json)을 읽고 감지한 것이다. 여기까지 오면 준비 완료다.

Capture 탭에서 Start Capture를 누르거나(Cmd+Shift+9도 가능), 자료를 복사해 나간다. 파일은 창에 드래그 앤 드롭해도 좋다. Current Packet에 항목이 쌓이며, 텍스트는 상단 미리보기, 이미지는 썸네일로 목록 표시된다. 클릭하면 내용 확인이 가능하고(텍스트는 시작 1 MiB까지 표시), 휴지통 아이콘으로 하나씩 제거할 수 있다. 마지막으로 가져간 시각은 Last Dispatch에 나타난다.

원하는 탭에서 /context-drop:pull <명령어>를 입력한다(플러그인 도입 후에는 항상 사용 가능). Step 6a에서 단축형을 넣었다면 /cd <명령어>도 같다. 예를 들면:

/context-drop:pull 이 UI 문제점을 조사해서 고쳐줘
/cd 이 UI 문제점을 조사해서 고쳐줘

여기서도 스크린샷이 아니라 실제로 일어난 일을 텍스트로 작성한다. §5의 실측(위 예시의 명령어와는 다른 실행)에서는, 스크린샷 2장(163,772 바이트・173,585 바이트)과 짧은 텍스트 3개의 총 5개 항목을 /cd로 가져오자, 격리된 서브 에이전트가 19,365 토큰을 사용하여 이를 읽었고, 메인 대화에 들어간 것은 간결한 목록(수백 토큰 규모)뿐이었다. 메인 대화에는 스크쇼의 원시 바이트는 전혀 들어가지 않는다.

Context Drop이 하는 일은 기술적으로 매우 단순하다. 즉, 원본 컨텍스트를 메인 대화에 넣지 않고, 격리된 서브 에이전트에게 읽게 한 후 요약만 반환하는 것이다.

하지만 이 단순한 경계가 ultracode에서 무거운 팬아웃을 돌릴 때 우리를 괴롭혔던 세 가지 문제에 효과적이다. 손상 (대용량 컨텍스트 + post-compact가 발화 조건이라면, 메인 대화를 비대하게 만들지 않음), 비대 (매 턴 재전송되는 원시 데이터를 근본적으로 끊음), 비용 (무거운 읽기 작업을 일회용 서브 에이전트 안에 가둠. 다만 위임이 절약은 아니므로, 읽게 할 양 자체도 줄여야 함).

모델을 똑똑하게 하거나, 노력을 높이거나, 에이전트를 늘리는 것이 아니다. 메인 컨텍스트를 가볍게 유지하는 — 그 한 지점을 도구와 절차 측면에서 시스템화한다. 무거운 운영을 할수록 이 한 지점의 가치는 커진다.