얼마 전 저는 어떻게 컨텍스트(Context)를 관리할지에 대해 고민하고 있었습니다. 저는 KV 양자화(KV quantisation)에 대해 좋지 않은 경험이 있어서 더 이상 그것을 건드리고 싶지 않았습니다 (최신 llama.cpp의 rotation quants도 마찬가지입니다). 그래서 저는 제 작업들에 주어진 컨텍스트 길이(Context lengths)에 갇혀 있는 상태였습니다. LLM 설정: 64GB 통합 RAM을 탑재한 Jetson AGX Orin에서 각각 120k / 80k 컨텍스트를 가진 Qwen3.6 27B Q6 및 Gemma 4 31B Q5를 사용 중입니다. 작업들은 때때로 프로그래밍이지만, 주로 연구를 통한 개인적 보조, 도구 호출(Tool calling), 논리적 논증 합성, 개인 파일 검색 등을 수행합니다. 저는 opencode(및 기타 하네스)에서 자동 압축(auto-compations)에 의해 갑작스럽게 중단되는 것이 마음에 들지 않아 이를 비활성화했습니다. 하지만 저는 직관적으로 생각하며 제가 일하는 방식과 에이전트(Agent)가 일하는 방식을 비교해 보았습니다. 제가 하위 작업(Sub-task)을 마치면, 저는 즉시 작업 컨텍스트를 잊어버리고 결과/요약만을 기억합니다. 다른 모든 세부 사항은 외부 파일에 기록되지만, 제 뇌의 작업 기억(Working memory)은 슬림하게 유지됩니다. 저는 무언가를 기억해야 하는 것들로 인해 뇌가 압도되어 무언가를 잊기 시작할 때까지 "기다리지" 않습니다. 저는 그것을 선제적으로 수행합니다. 그래서 생각했습니다. LLM에게도 똑같이 하도록 가르칠 수는 없을까? 만약 LLM에게 큰 작업을 주고, 작업의 일부(예: 웹사이트 스크래핑)를 마칠 때마다 도구 호출(Tool calls)의 세부 사항을 컨텍스트에서 압축하고 가지치기(Prune)하여 선택적인 부분만 남기고 스스로 요약을 작성하게 한다면 어떨까? 이렇게 하면 LLM은 다시 쓰는 시점부터 컨텍스트를 다시 프리필(Pre-fill)하게 되겠지만, 그 외에는 다음 작업을 위해 LLM의 컨텍스트 크기가 줄어들 것입니다. 이것을 Dynamic Context Pruning이라고 부릅니다. 서브 에이전트(Subagents)와 무엇이 다르냐고 물으신다면? 주요 차이점은 서브 에이전트는 작업을 어디서 나눌지, 서브 에이전트에게 무엇을 말할지를 미리 결정해야 하는 오버헤드(Overhead)를 LLM에 발생시킨다는 점입니다. 에이전트-서브 에이전트 간의 통신은 항상 그들이 상호작용하는 텍스트에 의해 제한되지만, Dynamic Context Pruning을 사용하면 모든 의미론적 컨텍스트(Semantic context)와 뉘앙스를 포함한 잠재 공간(Latent space)의 의미가 보존됩니다.

저는 여전히 서브에이전트 (subagents)를 사용하지만, 컨텍스트 (context)가 가득 차는 것을 방지하기 위해 억지로 사용할 필요는 없습니다. 게다가 DCP를 사용하면 작업을 완료한 후, 얼마나 그리고 어떤 부분을 유지하고 싶은지 간단히 결정할 수 있다는 장점이 있습니다. 다음은 LLM이 작업 후에 컨텍스트를 가지치기 (prune)하기로 결정했을 때의 모습입니다:

▣ DCP | -92.1K removed, +10.3K summary │░░░░░░░░░░░░░░░░░░░░░░⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿█│ ▣ Compression #2 -38.3K removed, +10.3K summary → Topic: Hybrid search refactor & tests → Items: 40 messages and 37 tools compressed → Compression (~10.3K tokens): ## Refactoring Summary for hybrid_search.py ...

이번 압축 (compression) 사례(#2)는 38k를 10k로 줄였습니다. 이전 압축을 포함하면 총 92k가 10.3k로 줄어들었으므로, 제 LLM은 앞으로 슬림한 컨텍스트를 유지하게 됩니다. 현재 제 설정에서는 스킬 (skills) 로딩 등을 비롯한 특정 요소들도 보호됩니다. 특정 항목을 절대 가지치기하고 싶지 않다면 언제든지 설정할 수 있습니다. 현재 제 설정은 컨텍스트가 50%에 도달하면 LLM이 부드러운 압축 유도 (soft compression nudges)를 받고, 75%에 도달하면 강력한 유도 (strong nudges)를 받도록 되어 있습니다.

저는 얼마 전 OpenCode용 DCP 구현체를 설치했고, 약간의 튜닝과 실험을 거친 후 그것이 잘 작동하는 것을 보고 매우 기쁩니다. 이 글을 통해 단순히 저의 경험을 공유하고 싶었습니다. 채팅에서 "더 큰 컨텍스트 크기"를 가질 수 있다는 편안함과, 작업을 계속하기 위해 빈번하게 새로운 세션을 만들 필요가 없다는 점이 정말 만족스럽습니다. 처음에는 핸드오프 (handoff) 스킬 및 관련 스킬들을 생각했으나, 이제 DCP가 있으므로 필요하지 않다고 판단했습니다. 따라서 컨텍스트 관리, 컨텍스트 저하 (context degradation) 및 크기 문제로 어려움을 겪고 있다면 DCP를 시도해 보시기 바랍니다! DCP가 이곳 레딧 (reddit)에서 전혀 언급되지 않는 것 같아 가치 있는 정보라고 느껴 이 글을 작성하게 되었습니다. 다만, 길고 상세한 벤치마크 (benchmarks) 데이터는 가지고 있지 않습니다.

Dynamic Context Pruning for OpenCode: https://github.com/Opencode-DCP/opencode-dynamic-context-pruning
DCP for Pi (I didn't try any of them): * https://github.com/complexthings/pi-dynamic-context-pruning * https://github.com/PSU3D0/pi-dcp submitted by /u/ayake_ayake [link] [comments]