[논문 리뷰] Do Language Models Need Sleep? — 긴 컨텍스트를 잠자는 동안 정리하는 법
LLM이 긴 컨텍스트를 계속 들고 있는 대신, 오프라인 recurrent pass로 fast weights에 기억을 정리하면 온라인 추론 지연을 늘리지 않고 깊은 reasoning 성능을 높일 수 있다는 논문을 정리한다.
Series
논문 리뷰- 1AI 엔지니어 필독 논문 10개 — ① 기초 아키텍처 (Attention, VAE, GANs)
- 2AI 엔지니어 필독 논문 10개 — ② NLP 혁명과 멀티모달 (BERT, GPT, ViT, DDPM)
- 3AI 엔지니어 필독 논문 10개 — ③ 실무 적용과 학술의 속도 (RAG, LoRA, PEFT)
- 3AI 엔지니어 필독 논문 10개 — ③ 실무 적용과 학술의 속도 (RAG, LoRA, PEFT)
- 4거대 비전-언어 모델은 단 3개의 Attention Head로 충분하다
- 4[논문 리뷰] SEISMIC — Learned Sparse Retrieval을 마이크로초 단위로 끌어내리기
- 5[논문 리뷰] EnterpriseRAG-Bench: 사내 지식 RAG 벤치마크
- 6[논문 리뷰] A-RAG: Agentic RAG가 2026년의 기본기가 된 이유
- 7[논문 리뷰] Code as Agent Harness — LLM 에이전트의 계획·실행·검증 루프
- 8[논문 리뷰] Scaling Laws for Agent Harnesses — 피드백 계산으로 에이전트 성능 확장하기
- 8[논문 리뷰] DeepSeek-V4 — 1M Context에서 KV Cache 10% 수준으로 압축한 Hybrid Attention
- 9[논문 리뷰] HarnessX — 에이전트 하네스를 실행 트레이스로 진화시키기
- 9[논문 리뷰] HyperTool — 에이전트의 도구 호출 단위를 다시 설계하기
- 10[논문 리뷰] Consensus is Strategically Insufficient — 합의보다 중요한 것은 불일치의 구조다
- 11[논문 리뷰] Do Language Models Need Sleep? — 긴 컨텍스트를 잠자는 동안 정리하는 법
Do Language Models Need Sleep? Offline Recurrence for Improved Online Inference
Sangyun Lee, Sean McLeish, Tom Goldstein, Giulia Fanti (2026)- arXiv preprint
한 줄 요약
이 논문은 LLM에게도 일종의 “수면”이 필요하다고 주장한다. 여기서 수면은 비유가 아니라 꽤 구체적인 연산이다.
컨텍스트 윈도우가 꽉 찼을 때, 바로 KV cache를 버리지 말고, 모델이 오프라인으로 여러 번 recurrent pass를 돌면서 최근 컨텍스트를 fast weights에 정리한 뒤 cache를 비운다.
핵심은 추론 시점의 응답 지연은 늘리지 않으면서, 컨텍스트가 사라진 뒤에도 그 정보로 더 깊은 reasoning을 할 수 있게 만드는 것이다. 모델이 깨어 있을 때는 한 번의 forward pass로 답하고, 잠자는 동안에만 추가 계산을 쓴다.
내가 보기엔 이 논문은 “long context를 더 길게 만들자”보다 한 단계 더 중요한 질문을 던진다.
긴 컨텍스트를 저장하는 것과, 그 컨텍스트를 나중에 쓸 수 있는 형태로 정리하는 것은 같은 문제인가?
논문의 답은 “아니다”에 가깝다.
배경: 긴 컨텍스트의 병목은 저장만이 아니다
Transformer는 과거 토큰을 KV cache에 저장하고 attention으로 다시 꺼내 쓴다. 이 방식은 정확하지만 비용이 크다.
attention compute -> context length에 대해 대략 quadratic
KV cache memory -> context length에 대해 linear그래서 최근에는 full attention만 쓰는 대신 SSM, linear recurrent layer, hybrid attention-SSM 구조를 섞는 흐름이 많다. 이런 모델은 과거 정보를 고정 크기의 fast weight memory에 압축한다.
개념적으로는 이렇다.
Transformer attention:
과거 token들을 KV cache에 계속 보관한다.
SSM / linear recurrent memory:
과거 token들을 고정 크기 상태 또는 fast weights에 누적한다.이 접근은 memory와 throughput 측면에서 유리하다. 문제는 논문이 지적하듯, scalable memory가 곧 scalable reasoning은 아니라는 것이다.
어떤 정보를 저장하는 것과, 그 정보를 여러 단계 계산에 사용할 수 있게 정리하는 것은 다르다. 예를 들어 그래프의 edge들을 저장하는 것과, 나중에 16-hop traversal 질문에 답할 수 있게 내부 표현을 구성하는 것은 난이도가 다르다.
이 논문에서 중요한 구분은 memory capacity와 consolidation compute다. 모델이 정보를 담을 공간을 갖고 있어도, 그 정보를 쓸모 있는 상태로 변환할 계산 시간이 부족하면 깊은 reasoning에서 실패할 수 있다.
논문의 핵심 아이디어: cache eviction 전에 잠깐 잔다
논문이 제안하는 구조는 SSM-attention hybrid model 위에 올라간다. 모델은 일정 길이 L의 컨텍스트 윈도우를 갖고 있고, 윈도우가 가득 차면 attention cache를 비워야 한다.
일반적인 처리:
chunk 처리 -> fast weights 업데이트 -> KV cache eviction -> 다음 chunk논문이 제안하는 sleep 처리:
chunk 처리
-> N번 recurrent pass로 fast weights를 반복 업데이트
-> KV cache eviction
-> 다음 chunk여기서 N이 sleep duration이다. N = 1이면 사실상 일반 SSM-attention hybrid baseline에 가깝고, N > 1이면 cache를 비우기 전에 같은 chunk를 여러 번 돌면서 fast weights를 더 정교하게 만든다.
중요한 제약은 prediction phase다.
수면 중: 추가 recurrent computation 허용
깨어 있을 때: answer token은 single forward pass로 예측즉, 답변을 생성하는 순간에 chain-of-thought token을 더 만들거나, prediction-time loop를 돌리는 방식이 아니다. 추가 계산을 미리 써서 내부 메모리를 정리해두는 방식이다.
이 점이 꽤 실용적이다. 사용자-facing inference latency를 늘리는 대신, 컨텍스트 정리 구간에 계산을 몰아넣는다.
생물학적 비유가 생각보다 정확하다
제목만 보면 “LLM도 잠을 자야 한다”는 말이 약간 과장처럼 보인다. 그런데 논문이 쓰는 sleep analogy는 단순한 마케팅이 아니다.
동물의 수면에서는 hippocampal replay와 memory consolidation이 일어난다고 알려져 있다. 짧은 시간 동안 경험한 기억이 재활성화되고, 장기 기억에 가까운 형태로 정리된다.
논문이 하는 일도 유사하다.
wake phase:
외부 token을 읽고 short-term context에 담는다.
sleep phase:
외부 token 입력 없이, 이미 본 context를 반복적으로 처리한다.
after sleep:
KV cache는 비워지지만, fast weights는 업데이트되어 남는다.물론 생물학적 수면과 같다는 뜻은 아니다. 다만 “새 입력을 받지 않는 오프라인 재처리 단계가 이후 행동을 개선한다”는 구조적 유사성은 꽤 선명하다.
실험 1: Rule 110 cellular automaton
첫 번째 실험은 Rule 110 cellular automaton이다. 모델은 여러 개의 binary state를 읽고, 각 state를 t번 전개한 뒤 첫 bit를 맞혀야 한다.
여기서 t는 reasoning depth다.
t = 0 -> 사실상 첫 bit retrieval
t 증가 -> sequential simulation이 필요논문은 hard eviction constraint를 둔다. 모델은 한 번에 하나의 state만 attention으로 볼 수 있고, 다음 state로 넘어가기 전에 KV cache가 비워진다. 따라서 나중에 답하려면 state 정보를 fast weights에 정리해둬야 한다.
흥미로운 점은 baseline SSM-attention hybrid가 t가 커질수록 빠르게 무너진다는 것이다. 이때 sequence length와 저장해야 할 정보량은 고정되어 있다. 바뀌는 것은 필요한 sequential computation depth다.
즉, 실패 원인은 단순히 “메모리가 부족해서”가 아니다.
정보를 저장할 수는 있지만, 그 정보를 깊게 계산한 형태로 정리할 시간이 부족하다.
sleep을 넣으면 성능이 오른다. t = 32의 어려운 설정에서 baseline은 거의 random guessing에 가까운 약 10% exact accuracy에 머문다. 반면 offline loop를 추가하면 같은 token budget에서 다음처럼 좋아진다.
| 설정 | 결과 |
|---|---|
| no loop | 약 10% exact accuracy |
| 2 loops | 약 20% |
| 3-4 loops | 30% 이상 |
이 실험의 장점은 변인을 잘 통제했다는 점이다. context length, eviction rule, prediction-time computation은 고정되어 있고, 바뀌는 것은 consolidation-time compute다.
실험 2: Depo — multi-hop graph retrieval
두 번째 실험은 Depo라는 multi-hop retrieval task다. 모델은 shuffled directed cycle을 읽고, 나중에 “어떤 node에서 k번 outgoing edge를 따라가면 어디인가?” 같은 질문에 답해야 한다.
여기서도 k가 reasoning depth다.
1-hop -> 간단한 edge lookup
4-hop -> 여러 edge 조합
16-hop -> 훨씬 깊은 graph traversal설정은 더 어렵다.
- cycle은 최대 75 nodes
- context는 최대 300 tokens
- window size는
L = 75 - 따라서 graph가 4개의 cache window에 쪼개진다
- query는 나중에 나오므로, 모델은 query-agnostic한 graph 표현을 fast weights에 만들어야 한다
결과는 직관적이다. loop 수가 많을수록 특히 높은 hop count에서 학습이 잘 된다.
논문에 따르면:
- 1-loop 모델은 4-hop 이상에서 거의 진전이 작다.
- 2-loop 모델도 8-hop 이상에서 정체된다.
- 4-loop 모델만 가장 어려운 16-hop task에서 개선을 보이기 시작한다.
이건 long-context agent 시스템에도 꽤 직접적인 힌트를 준다. 문서를 저장해두는 것과, 그 문서들 사이의 관계를 나중에 여러 단계로 탐색할 수 있게 정리해두는 것은 다르다.
실험 3: GSM-Infinite — 긴 수학 문제에서의 검증
마지막으로 논문은 더 현실적인 자연어 reasoning task인 GSM-Infinite에서 실험한다. GSM-Infinite는 GSM8K 스타일의 synthetic math reasoning benchmark인데, distractor token을 추가해 긴 컨텍스트 처리와 multi-step reasoning을 동시에 요구한다.
설정은 다음과 같다.
- 문제 길이: 약 2,000-3,300 tokens
- 연산 수: 1-8 operations
- evaluation set: 1,600 held-out examples
- context-window size:
L = 2000 - Chain-of-Thought trace는 데이터에서 제외
- 모델은 final answer를 single forward pass로 예측해야 함
논문은 두 모델 계열을 본다.
| 모델 | 설명 |
|---|---|
| Jet-Nemotron 2B | Qwen 2.5 1.5B에서 일부 attention layer를 Jet layer로 바꾼 SSM-attention hybrid |
| Ouro 1.4B | depth-recurrent attention-only model에 Jet layer를 추가 |
쉬운 2-operation, 4-operation 문제에서는 loop 수와 무관하게 성능이 포화되는 경우가 많다. 하지만 6-operation, 8-operation처럼 깊은 reasoning이 필요해질수록 sleep loop의 효과가 커진다.
주요 수치는 이렇다.
| 모델 | 설정 | baseline | 더 긴 sleep | 변화 |
|---|---|---|---|---|
| Jet-Nemotron 2B | 6 operations | 0.742 | 0.812 | 개선 |
| Jet-Nemotron 2B | 8 operations | 0.351 | 0.388 | 개선 |
| Ouro 1.4B | 6 operations | 0.419 | 0.615 | 큰 개선 |
| Ouro 1.4B | 8 operations | 0.210 | 0.272 | 개선 |
특히 Ouro에서 6-operation 문제의 0.419 -> 0.615는 꽤 크다. 논문은 Ouro가 depth-recurrent pretraining을 갖고 있어 looped consolidation과 더 잘 맞을 수 있다고 해석한다.
Sliding-window에서도 효과가 있나
hard eviction은 실험적으로 깔끔하지만, 실제 long-context 모델은 sliding-window attention을 쓰는 경우가 많다. 논문도 이 설정을 따로 본다.
아이디어는 간단하다.
hard eviction:
window가 차면 KV cache를 통째로 비운다.
sliding-window eviction:
최근 `L - 1` tokens는 남기고, 오래된 token만 밀어낸다.이 경우 N = 1은 일반적인 SWA-SSM hybrid baseline이고, N > 1은 오래된 context가 attention 밖으로 나가기 전에 추가 consolidation을 수행하는 구조다.
Ouro 1.4B, L = 512 설정에서 loop를 늘리면 모든 operation count에서 accuracy가 올라간다. 특히 2-operation 문제에서도 0.596 -> 0.905로 크게 개선된다. 논문은 active attention window가 전체 sequence보다 몇 배 작을 때, 긴 sleep이 reasoning뿐 아니라 relevant context compression/retrieval에도 도움을 준다고 해석한다.
이 논문에서 제일 중요한 메시지
나는 이 논문의 핵심을 이렇게 읽었다.
Long context의 본질은 더 오래 기억하는 것이 아니라,
나중에 쓸 수 있는 형태로 기억을 재구성하는 것이다.지금까지 long-context 논의는 자주 “얼마나 많은 token을 attention window에 넣을 수 있는가”로 흘렀다. 128K, 1M token 같은 숫자는 직관적이고 마케팅하기 좋다.
하지만 실제 agent나 reasoning system에서는 다른 문제가 더 중요해진다.
- 많은 token 중 무엇이 중요한가?
- 현재 query와 관련된 정보는 무엇인가?
- 여러 조각의 정보를 어떤 중간 표현으로 엮어야 하는가?
- attention 밖으로 나간 정보를 나중에 multi-hop reasoning에 쓸 수 있는가?
이 논문은 그 문제를 모델 구조 차원에서 건드린다. 단순한 context compression이 아니라, recurrent computation을 통해 fast weights를 점진적으로 정리한다는 점이 포인트다.
에이전트 시스템 관점에서 읽기
이 논문은 LLM architecture 논문이지만, agent harness 설계에도 바로 연결된다.
장기 작업을 하는 에이전트는 계속 context를 쌓는다.
사용자 요청
-> 파일 탐색
-> 문서 읽기
-> 실행 로그 확인
-> 테스트 실패
-> 수정
-> 재테스트
-> PR 작성이 모든 trace를 모델 context에 계속 넣으면 금방 지저분해진다. 그래서 좋은 하네스는 중간중간 상태를 압축한다.
예를 들면:
raw trace:
터미널 로그, 파일 전문, 검색 결과, 실패한 시도들
consolidated state:
- 현재 목표
- 결정된 설계
- 남은 blocker
- 검증된 사실
- 위험한 가정이건 agent의 “수면”과 비슷하다. 외부 입력을 더 받는 게 아니라, 이미 본 정보를 다시 정리해 다음 행동에 쓸 수 있는 상태로 만든다.
차이는 구현 위치다.
| 관점 | 수면에 해당하는 것 |
|---|---|
| 이 논문 | 모델 내부 fast weights를 recurrent pass로 업데이트 |
| agent harness | transcript/log/file context를 요약·구조화해서 working memory로 재작성 |
| 프로젝트 운영 | 세션 기록을 ADR, task state, runbook으로 승격 |
Hermes나 BrainCrew 같은 multi-agent harness에서도 비슷한 문제가 있다. 단순히 모든 로그를 context에 남기는 것보다, 작업 경계마다 “consolidation step”을 두는 편이 안정적이다.
구현 아이디어: inference latency를 어디에 쓸 것인가
논문의 설계는 online inference latency를 보존하려고 한다. 답변 시점에는 single forward pass만 쓴다. 대신 cache eviction 직전에 compute를 쓴다.
시스템 설계 관점에서는 이 trade-off가 중요하다.
나쁜 방식:
사용자가 기다리는 동안 깊은 loop를 돈다.
좋은 방식:
사용자가 기다리지 않는 구간, 또는 context boundary에서 미리 consolidation한다.예를 들어 agent 시스템에서는 이런 식으로 응용할 수 있다.
1. 긴 문서 묶음을 읽는다.
2. 바로 다음 tool call로 넘어가지 않는다.
3. 문서 간 관계, 결정 사항, unresolved question을 구조화한다.
4. 이후 reasoning은 raw document가 아니라 structured memory를 중심으로 한다.즉, sleep은 꼭 모델 내부 weight update일 필요는 없다. 제품/하네스 레벨에서는 structured memory update, local index update, task state rewrite, episodic summary generation이 같은 역할을 할 수 있다.
한계와 주의점
논문도 한계를 분명히 말한다.
1. 공짜 성능 향상이 아니다
sleep loop가 늘어나면 훈련 비용은 대략 N에 비례해서 증가한다. 논문도 recurrent-depth cost가 거의 선형으로 증가한다고 보고한다.
즉, 이 방법은 latency를 없애는 게 아니라 어디에 latency를 배치할지 바꾸는 방법이다.
prediction-time latency는 유지
consolidation/training-time compute는 증가실서비스에서는 언제 sleep을 돌릴지, 얼마나 자주 돌릴지, 사용자 응답 흐름을 막지 않을지 설계가 필요하다.
2. 학습이 더 어렵다
여러 recurrent pass를 backpropagation해야 하므로 훈련이 느리고 불안정해질 수 있다. 논문은 implicit gradients, truncated BPTT, recurrent-depth training 안정화 기법이 필요할 수 있다고 언급한다.
3. 아직 modest-scale 실험이다
GSM-Infinite는 현실적인 자연어 reasoning benchmark에 가깝지만, 여전히 synthetic이다. 모델도 Jet-Nemotron 2B, Ouro 1.4B 수준이다. frontier-scale production LLM에 이 방식이 그대로 들어갈지는 별도 검증이 필요하다.
4. 모든 문제에 sleep이 필요한 것은 아니다
쉬운 문제에서는 loop 수를 늘려도 성능 차이가 작다. 논문에서도 2-operation, 4-operation GSM-Infinite 문제는 성능이 포화되는 경우가 많다.
따라서 sleep은 “항상 더 많이”가 아니라, 깊은 reasoning이나 강한 context eviction이 있는 상황에서 선택적으로 써야 한다.
내 생각: 긴 컨텍스트 경쟁의 다음 단계
이 논문이 마음에 드는 이유는 long-context 문제를 숫자 경쟁에서 구조 경쟁으로 옮기기 때문이다.
지금까지는 이런 질문이 많았다.
얼마나 긴 context window를 지원하는가?앞으로는 이 질문이 더 중요해질 것 같다.
context window 밖으로 나간 정보를 어떤 형태의 memory로 바꾸는가?
그 memory는 단순 retrieval뿐 아니라 reasoning에도 쓸 수 있는가?
그 변환에 필요한 compute를 언제, 어디서 쓸 것인가?agent 시스템도 마찬가지다. 장기 실행 agent의 성능은 “얼마나 많은 로그를 context에 넣었는가”보다 “어떤 순간에 무엇을 기억으로 승격했는가”에 더 크게 좌우된다.
그래서 나는 이 논문을 LLM architecture 논문이면서 동시에 agent memory 논문처럼 읽었다.
정리
Do Language Models Need Sleep?의 메시지는 단순하다.
- 긴 context를 그대로 들고 있는 것은 비싸다.
- SSM/fast weights는 효율적인 memory를 제공하지만, 저장만으로는 깊은 reasoning이 부족할 수 있다.
- cache eviction 전에 offline recurrent pass를 여러 번 수행하면, evicted context를 더 유용한 fast weights로 정리할 수 있다.
- 이 추가 계산은 prediction phase가 아니라 sleep phase에 배치되므로, wake-time inference latency를 유지할 수 있다.
- 효과는 쉬운 retrieval보다 깊은 sequential reasoning에서 더 뚜렷하다.
내가 가져갈 실무적 교훈은 이거다.
장기 기억은 저장소가 아니라 정리 과정이다.
LLM이든 agent harness든, 오래 일하게 만들고 싶다면 단순히 context를 늘리는 것만으로는 부족하다. 중간중간 멈춰서, 이미 본 것을 다시 계산하고, 다음 행동에 쓸 수 있는 상태로 바꾸는 “수면” 단계가 필요하다.