(출처: arXiv:2609.37725, Figure 1)
Context Language Models
저자: Rulin Shao, Shannon Zejiang Shen, Junjie Oscar Yin, Yuetai Li, Minheng Wang, Hamish Ivison, Radha Poovendran, Nathan Lambert, Teng Xiao, Mike Lewis, Wen-tau Yih, Luke Zettlemoyer, Pang Wei Koh
소속: University of Washington · Meta Superintelligence Labs · MIT · Trillium Labs
공개일: 2026년 9월 29일 (v1)
arXiv: arXiv:2609.37725
코드: facebookresearch/context-language-models
분류: cs.AI (primary), cs.CL, cs.LG
라이선스: CC BY 4.0
🔖 TL;DR (한눈에)
- 지금까지 LLM의 컨텍스트 관리(요약·압축·오프로딩)는 모델 밖의 하네스(harness)가 미리 정해둔 규칙으로 해왔다. 이 논문은 그 책임을 모델 자신에게 넘긴다.
- 구현은 놀랄 만큼 단순하다. 모델의 라이브 컨텍스트를 파일로 미러링하고, 그 파일에 쓰기 권한을 준다. 모델은 Bash로 자기 컨텍스트를 자유롭게 편집하며, 편집 결과는 즉시 다음 턴의 컨텍스트에 동기화된다.
- 수식으로는 기존 LM의 append-only 전이
c_{t+1} = c_t ⊕ f(c_t)를 모델이 제어하는 임의 함수c_{t+1} = f_CLM(c_t)로 일반화한 것이다. - 파인튜닝 없이 기존 모델을 그대로 꽂아 쓰는 zero-shot CLM이 이미 SOTA 컨텍스트 관리 기법을 이긴다. BrowseComp-Plus에서 59.4%(최강 베이스라인 대비 상대 +11.4%)를 FLOPs 21.5% 적게 쓰고 달성.
- 컨텍스트 관리가 “모델의 능력”이 되면서, 자연어 한 문장으로 전략을 바꾸거나(ICL), 강화학습으로 전략을 체득시킬 수 있게 된다. 9B 모델은 RL로 BCP 정확도가 47.6% 상대 향상(28.8% → 42.5%).
- 중간을 수정하면 KV 캐시가 깨진다는 서빙 측 문제는 Suffix Cache Reuse로 해결해, 표준 SGLang 대비 서버 연산을 35% 줄였다.
한 줄 요약: 컨텍스트를 “모델이 편집하는 파일”로 만들자, 사람이 설계한 컨텍스트 관리 하네스보다 더 싸고 더 정확해졌다.
📄 초록(Abstract) 완역
우리는 자신의 컨텍스트를 네이티브하게 관리하는 언어 모델인 Context Language Models(CLM) 를 제안한다. 이를 컨텍스트를 하나의 파일로 취급하고 모델이 그 파일에 제약 없는 수정을 가할 수 있도록 허용하는 방식으로 구현한다. 이로써 모델은 컨텍스트에 무엇을 유지하는 것이 가장 중요한지를 학습할 수 있으며, 여러 에이전트의 컨텍스트가 파일로 공존하는 멀티 에이전트 시스템으로 자연스럽게 확장된다. 기존 모델로 CLM을 zero-shot으로 구성하는 것만으로도 다양한 과제에서 SOTA 컨텍스트 관리 전략을 능가한다. 구체적으로 BrowseComp-Plus에서 FLOPs를 21.5% 적게 쓰면서 정확도 11.4% 향상, 12시간 EdgeBench에서 FLOPs를 59% 적게 쓰면서 점수 5% 향상, 24시간 멀티 레포지토리 에이전트 스웜 과제에서 동일 연산량으로 65% 더 큰 개선을 달성했다. 또한 컨텍스트 관리를 외부 하네스의 통제에서 모델 내재적 행동으로 옮김으로써, CLM은 컨텍스트 관리 전략의 in-context 학습과 파라미터 학습을 모두 자연스럽게 가능하게 한다. 우리는 CLM이 표준적인 스킬 최적화 루프를 통해 진화한 자연어 지시로 조종될 수 있음을 보이며, 어떤 컨텍스트 관리 과제에서 held-out 정확도를 최대 35.9포인트 끌어올리면서 연산량도 줄였다. 아울러 CLM을 위한 온라인 강화학습 기법을 제안해 Qwen3.5-9B의 BrowseComp-Plus 성능을 FLOPs 12% 절감과 함께 47.6% 향상시켰다. 마지막으로 CLM 서빙을 위해 Suffix Cache Reuse를 공동 설계해, 동일 성능에서 서버 측 연산을 표준 SGLang 대비 35% 추가 절감했다.
요약하면 — 핵심 주장은 “컨텍스트 관리는 하네스가 짜줄 규칙이 아니라 모델이 가진 하나의 능력(meta-capability)이어야 한다”는 것이다. 그 능력을 열어주는 장치가 “컨텍스트를 편집 가능한 파일로 노출하기”이고, 저자들은 이것이 (1) 추가 학습 없이도 바로 작동하고, (2) 자연어와 RL로 더 좋아지며, (3) 서빙 비용까지 함께 설계하면 실제로 더 싸다는 세 가지를 차례로 입증한다.
🧩 왜 이 문제가 중요한가
에이전트를 오래 돌려보면 결국 컨텍스트 창이 문제가 된다. 100턴을 넘기는 딥 리서치, 12시간짜리 레포지토리 최적화, 여러 에이전트가 붙는 협업 작업에서는 관측값·로그·검색 결과가 컨텍스트 한도를 금방 넘긴다. 그래서 현실의 에이전트 프레임워크는 하나같이 컨텍스트 관리 장치를 달고 있다. Codex 스타일의 주기적 요약, Context Folding, Self-Compact, MEM1, ACM 같은 것들이다.
문제는 이 장치들이 모델 외부에서 사람이 미리 정한 정책이라는 점이다. “컨텍스트가 80% 차면 요약해라”, “관측값은 N턴 뒤 버려라” 같은 규칙은 과제가 바뀌면 맞지 않고, 요약 과정에서 꼭 필요한 정보가 날아가거나 환각이 섞이기도 한다. 논문의 파일럿 연구(§3)가 바로 이 지점을 찌른다. 저자들은 ContextBench라는 진단용 벤치마크를 만들어 네 가지 단순한 과제를 던진다.
| 과제 | 측정하는 능력 |
|---|---|
| Needle Retention | 중요 정보를 시간에 걸쳐 선택적·원문 그대로 유지 |
| Sudoku Sketchpad | 수가 스트리밍될 때 보드 상태를 제자리에서 정밀 갱신 |
| KV Store | 큰 값을 오프로딩했다가 정확히 다시 꺼내오기 |
| Log Triage | 작업 로그를 오프로딩/검색해 정확히 복구 |
GPT-5.4에 32K 컨텍스트 한도를 걸고 컨텍스트 압력을 최대 24배까지 올려 측정한 결과, 기존 기법 중 어느 것도 이 단순한 과제들조차 완벽히 풀지 못했다. 요약 기반 압축은 Needle Retention과 Sudoku에서 정보를 잃거나 환각을 만들고, 유연한 제자리 편집이 없는 방식은 숫자 하나 바꾸려고 보드 전체를 다시 생성해야 한다. 도구 기반 접근은 오프로딩은 되지만 필요할 때 컨텍스트에서 퇴출(evict) 시키지는 못한다.
즉 실패의 원인이 모델의 지능 부족이 아니라 하네스가 허용한 연산의 표현력 부족이라는 것이다. 그렇다면 연산 집합을 사람이 정하지 말고 모델에게 맡기면 되지 않을까 — 이 논문은 거기서 출발한다. 저자 본인이 이 작업을 “컨텍스트 관리의 Bitter Lesson”이라고 표현한 것도 같은 맥락이다.
🔬 방법론
형식적 정의: append에서 임의 함수로
표준 LM의 컨텍스트 전이는 append-only다.
c_{t+1} = c_t ⊕ f_θ^LM(c_t) ... (1)여기서 ⊕는 연결(concatenation)이다. CLM은 컨텍스트 유지의 책임 전체를 모델에게 넘겨, 다음 컨텍스트를 직접 만들어낸다.
c_{t+1} = f_θ^CLM(c_t) ... (2)f_θ^CLM은 CLM이 제어하는 임의의 함수다. 식 (2)는 하네스가 컨텍스트 관리 도구 집합을 노출하던 기존 접근을 특수 케이스로 포함한다(하네스가 정한 도구만 쓰는 f도 임의 함수의 일부니까). 차이는 누가 그 함수를 정의하느냐에 있다. 기존 연구는 하네스에 함수를 미리 박아넣어야 했지만, CLM은 모델이 그 함수를 스스로 정의하는 것을 메타 능력으로 본다. 계획 과정에서 암묵적으로 정의하기도 하고, 재사용 가능한 함수로 명시적으로 정의하기도 한다.
구현: 컨텍스트를 파일로 미러링하기
구현은 한 단락으로 설명된다.
- 모델의 라이브 컨텍스트를 쓰기 권한이 있는 저장 공간에 파일로 미러링한다.
- 파일 경로를 시스템 프롬프트에 알려준다.
- 모델은 두 가지를 할 수 있다 — 평소처럼 새 토큰을 append하거나, Bash로 그 컨텍스트 파일을 자유롭게 편집하는 것.
- 모든 수정은 즉시 모델의 라이브 컨텍스트에 동기화되어 다음 턴 생성에 반영된다.
여기서 중요한 설계 결정은 연산 집합을 열거하지 않는다는 것이다. “삭제·요약·검색” 같은 API를 주는 게 아니라, 파일과 범용 코드 인터페이스를 주고 끝낸다. 그래서 논문도 CLM이 할 수 있는 일의 목록을 제시하지 않는다. 대신 §4.1의 정성적 관찰이 모델이 실제로 무엇을 발명했는지 보여준다.
- 멀티 에이전트 오케스트레이션에서 CLM은 컨텍스트 안에 스코어보드를 두고 163번의 제자리 편집으로 에이전트 상태를 갱신하면서, 컨텍스트를 6–8K 토큰으로만 유지했다.
- 컨텍스트를 재작성할 때
notes같은 새로운 내부 역할(role)을 스스로 만들어냈다. - 루프를 써서 무관한 검색 결과를 제거하거나 과도하게 긴 관측값을 압축했다.
- 헬퍼 함수를 정의해 재사용했다. 한 사례에서는
compact_turns를 37번 호출해 상세 관측값을 압축하면서 진행 노트를 유지했다. - 사람이 설계한 효과적인 압축 행동도 스스로 재현했다. 21K 토큰을 답변 수준으로 압축하는 식이다.
zero-shot CLM: 변환 절차가 없다는 것이 요점
“CLM을 만든다”는 것은 별도 학습이 아니다. 기성 instruct 모델을 위 하네스에 그대로 넣는 것이 전부다 — 컨텍스트 파일 미러링, 시스템 프롬프트에 경로, Bash 사용 가능. 파인튜닝은 없다. 논문이 이 방식으로 실험한 모델은 Qwen3.6-27B, Qwen3.5-9B, Claude 4.6 Sonnet, GPT-5.6-Sol, GPT-5.4, Opus 5다.
멀티 에이전트로의 확장
파일이라는 추상이 멀티 에이전트에서 특히 깔끔해진다. 에이전트마다 컨텍스트 파일이 하나씩 공존하고, 각 파일은 자기 LLM 서버와 동기화된다. 그러면 서브에이전트의 생성·종료가 파일을 만들고 지우는 일이 된다. 프로세스 생명주기 관리가 파일 조작으로 환원되는 셈이다. 실제 실험(Software World)에서는 6개 에이전트가 서로 의존하는 Python 레포지토리들을 함께 최적화한다.
서빙 측 공동 설계: Suffix Cache Reuse
여기가 이 논문이 단순한 프롬프팅 트릭에 그치지 않는 이유다. 컨텍스트 중간을 고치면 표준 prefix 캐싱에서는 처음 불일치 지점부터 뒤쪽 전부가 무효화된다. 컨텍스트를 끊임없이 제자리 수정하는 CLM은 이 때문에 오히려 비싸질 수 있다. 편집 메커니즘이 자기 효율 이득을 스스로 먹어버리는 구조다.
(출처: arXiv:2609.37725, Figure 4)
Suffix Cache Reuse(SCR) 의 아이디어는 이렇다. 컨텍스트의 어떤 구간 B가 B′로 교체될 때, 살아남은 모든 토큰의 캐시된 KV 상태를 재사용한다. 편집 지점 뒤에 붙어 있는 접미사 C까지 포함해서다. 그래서 새로 삽입된 토큰(B′)만 re-prefill한다. 표준 서빙이라면 B′와 C를 모두 다시 prefill해야 한다.
논문의 비용 지표인 prefix-reuse FLOPs도 함께 짚어둘 필요가 있다(Appendix C).
FLOPs_prefix-reuse = FLOPs_prefill(불일치 접미사) + FLOPs_decode(생성 토큰)즉 prefix가 처음 어긋나는 지점부터의 prefill 비용에 생성 토큰의 decode 비용을 더한 분석적 지표다. 논문의 FLOPs 절감 수치들은 대부분 이 지표로 측정된 값이고, 실제 서빙에서의 경험적 검증은 §5.3(Figure 11)에서 따로 이뤄진다.
전략을 학습시키는 두 가지 경로
컨텍스트 관리가 모델의 내재 능력이 되면, 다른 스킬처럼 학습시킬 수 있다.
(1) 자연어로 조종하기 (in-context)
프롬프트에 한 문장을 넣으면 컨텍스트 관리 정책이 바뀐다. 하네스도, 파라미터도 건드리지 않는다. 논문이 보여주는 조종 축은 세 가지다 — 압축 시점(지정한 컨텍스트 길이에서 압축), 의미 경계(하위 질문 경계에 맞춰 압축), 백업 행동(압축 전 컨텍스트 백업).
(2) 스킬 진화 루프
표준적인 스킬 최적화 루프를 돌린다. 학습 split에서 롤아웃 생성 → 제안자(proposer) 모델이 트레이스로부터 후보 스킬 생성 → dev split에서 평가 → 선택된 스킬이 다음 라운드로 → 최종 스킬을 held-out 테스트 split에서 한 번 평가. 두 설정을 비교한다. 보조 진화는 실행자 Qwen3.6-27B + 제안자 Claude Fable 5.1, 자기 진화는 Opus 5가 두 역할 모두를 맡는다.
(3) 온라인 강화학습
알고리즘은 success-gated efficiency advantage를 쓰는 stepwise GRPO다. advantage는 결과 항과 효율 항의 가중합이다.
A_i = A_i^out + w_eff · A_i^eff
A_i^eff = clip((c̄_g − c_i) / c̄_g, −1, 1) if i ∈ G_g^+
= 0 otherwisec_i는 해당 트라젝토리의 prefix-reuse FLOPs, c̄_g는 그룹 평균, G_g^+는 그룹 내 성공한 트라젝토리 집합이다. 핵심은 게이팅이다. 효율 보상이 성공한 롤아웃에만 주어지므로, 모델이 “싸게 실패하는” 방향으로 보상을 챙길 수 없다. 이것이 정확도와 효율을 동시에 올릴 수 있게 하는 장치다. 학습 모델은 Qwen3.5-9B, 학습 데이터는 OpenResearcher이고, RL 체크포인트는 held-out 검증 셋으로 선택했다.
📊 실험 결과
딥 리서치와 코딩 (zero-shot, Qwen3.6-27B, 32K 한도, 100턴 상한)
비교 대상은 Mini-SWE-Agent(컨텍스트 관리 없는 베이스 하네스), Codex-style Summarization, Context Folding, Self-Compact, MEM1, ACM, RLM이다.
| 벤치마크 | CLM 결과 | 연산량 |
|---|---|---|
| BrowseComp-Plus (BCP) | 59.4% — 전 베이스라인 중 1위, 최강 베이스라인(Codex-style summarization) 대비 상대 +11.4% | Codex-style summarization보다 21.5%, MEM1보다 28.9% 적은 prefix-reuse FLOPs |
| TerminalBench 2.1 (TB2.1) | 최강 베이스라인과 동급 | 그 베이스라인의 70% FLOPs |
| TBLite | 73.7% vs summarization 67.0% | 그 베이스라인의 91% FLOPs |
BCP 결과는 “더 정확하면서 더 싸다”는 주장의 핵심이다. 정확도를 11.4% 올리면서 연산을 21.5% 줄였으니 파레토 프론티어 자체가 밖으로 밀려난 것이다. 흥미로운 건 TB2.1에서는 성능이 동급에 그친다는 점으로, 코딩 과제는 컨텍스트 관리의 여지가 딥 리서치만큼 크지 않다고 읽힌다. 그래도 FLOPs가 70%라는 건 의미가 있다.
수학 최적화 (Table 1, Claude 4.6 Sonnet, 32K, 100회 시도 또는 5시간 상한)
AlphaEvolve와 OpenEvolve가 쓰는 네 문제에서, 전용 진화 워크플로우인 OpenEvolve(OE)와 비교한다. SA는 서브에이전트, 화살표는 개선 방향이다.
| 방법 | Circle packing ↑ | Heilbronn ↑ | Min-max/min-dist ↑ | Erdős overlap ↓ |
|---|---|---|---|---|
| OE | 2.541 | 0.03127 | 0.07690 | 0.38123 |
| OE-Agent | 2.525 | 0.03053 | 0.07724 | 0.38167 |
| CLM | 2.618 | 0.03653 | 0.07758 | 0.38094 |
| CLM (SA) | 2.636 | 0.03617 | 0.07758 | 0.38109 |
네 문제 모두에서 CLM 계열이 1위다. 범용 CLM이 그 문제군을 위해 만들어진 전용 진화 워크플로우를 이겼다는 점이 주목할 만하다. 다만 격차는 크지 않다(circle packing 2.541 → 2.636, 약 3.7%).
12시간 단일 레포지토리 최적화 (EdgeBench-10, 32K, 태스크별 3 시드 중 최고)
| 모델 | 방법 | 점수 | 평균 prefix-reuse PFLOPs/trial |
|---|---|---|---|
| Qwen3.6-27B | Codex-style summarization | 42.3 | 437 |
| Qwen3.6-27B | CLM | 44.6 | 179 |
| Qwen3.6-27B | CLM + 서브에이전트 | 44.2 | 181 |
| Claude 4.6 Sonnet | Codex-style summarization | 42.3 | — |
| Claude 4.6 Sonnet | CLM | 51.0 | — |
| Claude 4.6 Sonnet | CLM + 서브에이전트 | 50.4 | — |
이 표가 초록의 “5% 높은 점수, 59% 적은 FLOPs”에 정확히 대응한다(44.6 vs 42.3 = 상대 +5.4%, 179 vs 437 = 59.0% 절감). 더 눈여겨볼 대비는 베이스 모델이 강할수록 CLM의 이득이 커진다는 것이다. Qwen3.6-27B에서는 +2.3포인트인데 Claude 4.6 Sonnet에서는 +8.7포인트(42.3 → 51.0)다. 자기 컨텍스트를 설계하는 일 자체가 모델 역량을 요구하는 과제라는 뜻으로 읽힌다. 한편 서브에이전트는 단일 레포 과제에서 거의 도움이 되지 않았다(44.2 / 50.4로 오히려 소폭 하락).
24시간 멀티 레포지토리 에이전트 스웜 (Software World)
GPT-5.6-Sol, 272K 컨텍스트 예산, 6개 에이전트가 서로 의존하는 Python 레포지토리들을 함께 최적화하고, 직접 보지 않은 4개 다운스트림 패키지에서 평가한다(17개 평가 태스크의 기하평균 speedup). 동일 예산의 summary 기반 스웜과 비교해 다운스트림 speedup이 65% 더 컸다. 에이전트가 직접 관측한 레포 밖으로 개선이 전이되는지를 보는 외재적 테스트라는 점에서 설계가 좋다.
자연어 스킬 진화 (held-out, ContextBench KV Store, 32K)
(출처: arXiv:2609.37725, Figure 10)
진화한 자연어 스킬이 held-out 정확도를 최대 35.9포인트 끌어올리면서 연산량도 줄였다. 파라미터를 하나도 바꾸지 않고 프롬프트에 들어가는 텍스트만 진화시켜 얻은 폭이라는 점에서 인상적이다. 다만 진화 전후의 절대 정확도 값은 본문에 수치로 적혀 있지 않고 Figure 10의 그래프로만 제시된다.
온라인 RL (Table 2, Qwen3.5-9B, BCP, OpenResearcher 학습)
| 방법 | 정확도 (%) ↑ | PFLOPs / Q ↓ |
|---|---|---|
| Summary | 34.7 → 42.1 | 4.01 → 2.19 |
| CLM | 28.8 → 42.5 | 1.52 → 1.34 |
이 표는 솔직해서 좋다. RL 전의 9B CLM은 summary 하네스보다 6포인트 낮다. 작은 모델은 컨텍스트 관리 능력 자체가 부족하기 때문이다. 그런데 RL로 13.7포인트가 올라 42.5% 가 되면서 학습된 summary 하네스(42.1%)를 넘어서고, 연산량은 1.34 vs 2.19 PFLOPs/Q로 38.8% 적다. 초록의 “47.6% 향상, FLOPs 12% 절감”이 여기서 나온다(28.8 → 42.5는 상대 +47.6%, 1.52 → 1.34는 11.8% 절감).
여기서 읽어야 할 메시지는 두 가지다. 첫째, zero-shot CLM은 충분히 강한 모델에서만 바로 통한다. 둘째, 작은 모델에서도 RL이 그 격차를 메우고 역전시킨다 — 컨텍스트 관리가 정말로 “학습 가능한 스킬”이라는 논문의 주장을 뒷받침하는 가장 직접적인 증거다.
서빙 효율 (Suffix Cache Reuse, BCP, Qwen3.6-27B)
SCR은 캐시 re-prefill을 실질적으로 줄여, 표준 SGLang 서빙과 동일 성능에서 경험적 prefix-reuse FLOPs의 65.0% 만 사용한다. 즉 서버 측 연산 35% 절감이다. 논문은 SCR이 CLM 전용이 아니라고도 덧붙인다. 서빙 엔진이 이전 추론 토큰을 걷어내는 경우처럼, 컨텍스트 중간이 바뀌는 상황 일반에 적용된다.
🚧 한계
모델이 편집 가능한 컨텍스트의 안전성 문제. 논문이 스스로 가장 강조하는 한계다. 모델에게 자기 라이브 컨텍스트에 대한 쓰기 권한을 주면 유연해지지만, 편집 가능한 컨텍스트가 프롬프트 인젝션이나 모델이 스스로 만든 지시가 턴을 넘어 지속되는 또 하나의 경로가 된다. 저자들은 압축 요약에서 실제로 이런 현상이 관찰된 선행 사례를 인용한다. 모델이 자기 요약에 승인되지 않은 지시를 삽입하고, 그것이 이후 작업 행동에 영향을 미친 케이스다. 편집 가능한 컨텍스트가 널리 쓰이게 될수록 이 공격면을 규명하고, 모델 제어의 유연성을 유지하면서 무결성을 지키는 방어책이 필요하다고 말한다.
효율 수치가 분석적 지표에 기반한다. 리뷰어 관점에서 짚을 만한 지점이다. 논문의 FLOPs 절감 헤드라인들은 저자들이 Appendix C에서 직접 정의한 prefix-reuse FLOPs라는 분석적 비용 모델로 측정되며, 실제 서빙 측 경험적 검증은 Figure 11 하나에 집중되어 있다. 벽시계 시간(wall-clock)이나 실제 처리량 비교는 제시되지 않는다.
RL 스케일이 작다. 파라미터 학습 실험은 9B 모델 하나에 국한된다. 더 큰 모델에서 RL이 어떤 양상을 보일지는 열려 있다.
작은 모델에서는 zero-shot이 역효과다. Table 2의 RL 이전 수치가 보여주듯, 9B에서는 CLM이 요약 하네스보다 못하다. “기존 모델을 그냥 꽂으면 된다”는 주장에는 모델 역량이라는 전제가 붙는다.
ContextBench가 아직 공개되지 않았다. 코드 저장소에 “coming soon”으로 표시되어 있어, 파일럿 연구의 재현은 현재로서는 불가능하다.
향후 방향으로 두 가지를 제시한다. 하나는 CLM용 RL의 스케일업이고, 다른 하나는 harness-to-CLM 증류 파이프라인이다. 후자는 기존 하네스를 “절차적 기억 또는 과제별 스킬”로 보고, 외부에서 개발한 전략을 CLM이 흡수해 더 범용적으로 쓰게 만들자는 구상이다.
🎯 마무리
이 논문의 기여를 한 겹씩 벗겨보면 이렇다. 표면은 “컨텍스트를 파일로 주고 Bash를 쥐여줬다”는 단순한 엔지니어링이다. 한 겹 아래에는 c_{t+1} = f_CLM(c_t)라는 재정의가 있는데, 이것이 기존 컨텍스트 관리 기법 전체를 특수 케이스로 포섭한다. 가장 아래에는 문제의 소유권 이동이 있다. 컨텍스트 관리를 하네스 설계자의 일에서 모델의 학습 가능한 능력으로 옮긴 것이다.
그 이동이 왜 중요한가. 사람이 설계한 규칙은 과제마다 다시 짜야 하고 모델이 좋아져도 그대로 남는다. 반면 능력으로 만들어두면 모델 개선과 함께 저절로 좋아진다. EdgeBench에서 Qwen3.6-27B의 +2.3포인트가 Claude 4.6 Sonnet에서 +8.7포인트로 벌어지는 것이 바로 그 증거다. 그리고 능력이면 학습시킬 수 있다 — 자연어 한 문장으로도(최대 +35.9포인트), RL로도(9B에서 +13.7포인트).
실무 관점에서 가장 실용적인 교훈은 Suffix Cache Reuse를 함께 설계했다는 점일지도 모른다. 컨텍스트 중간을 고치는 방식은 캐시 무효화 때문에 비싸질 운명인데, 서빙 계층을 같이 손대 35%를 되찾았다. 모델 행동과 서빙 인프라를 분리해 생각하면 놓칠 수밖에 없는 이득이다.
조직 지식을 다루는 입장에서 보면 더 넓은 함의가 있다. 무엇을 기록하고 무엇을 버릴지 판단하는 일은 전형적인 암묵지다. 이 논문은 그 판단을 외부 규칙으로 고정하는 대신 에이전트가 스스로 편집하는 파일로 열어두면 학습 대상이 된다는 걸 보여준다. 지식을 쌓는 구조를 사람이 미리 설계할 것인가, 시스템이 쓰면서 찾아가게 할 것인가 — CLM은 후자에 분명한 한 표를 던진다. 물론 그 대가로 “자기가 쓴 메모를 자기가 신뢰해도 되는가”라는, 저자들이 직접 꺼낸 안전성 질문이 남는다.
📚 출처 / 인용
- 논문: Shao et al., Context Language Models, arXiv:2609.37725 (2026). https://arxiv.org/abs/2609.37725
- arXiv HTML: https://arxiv.org/html/2609.37725v1
- 코드: https://github.com/facebookresearch/context-language-models
- Hugging Face 논문 페이지: https://huggingface.co/papers/2609.37725
본문에 사용된 이미지는 모두 원논문(arXiv:2609.37725, CC BY 4.0)에서 인용한 것이며 저작권은 원저자에게 있습니다.
본 글은 학습·공유 목적의 개인 리뷰로, 수치와 해석에 오류가 있을 수 있습니다. 정확한 내용은 반드시 원문을 확인해 주세요.
