Sleep-time Compute: 에이전트가 쉬는 동안 기억을 정제하고 추론 비용을 5배 줄이는 방법
왜 이 문제가 중요한가
LLM 에이전트를 프로덕션에 올리면 두 가지 비용이 동시에 발생한다. 첫째는 응답 품질을 높이기 위한 추론 토큰이다. 복잡한 질문에 단계적으로 생각하게 할수록 정답률이 오르지만, 레이턴시와 비용이 함께 오른다. 둘째는 컨텍스트 처리 비용이다. 긴 대화 이력, 문서, 이전 결과물을 매 요청마다 다시 읽는 것은 비싸다.
test-time compute 스케일링은 요청이 들어오는 순간에 추론 예산을 늘리는 방식이다. 그런데 에이전트가 사용자와 상호작용하지 않는 유휴 시간도 있다. 이 시간을 활용할 수 없을까?
2026년 4월, Letta와 UC Berkeley의 연구팀이 이 질문에 답하는 논문을 공개했다. 논문 제목은 "Sleep-time Compute: Beyond Inference Scaling at Test-time" (arXiv:2504.13171)이다. 핵심 주장은 단순하다: 에이전트가 유휴 상태일 때 컨텍스트를 미리 처리해두면, 요청이 들어왔을 때 필요한 추론 토큰을 약 5배 줄이면서 동일한 정확도를 달성할 수 있다.
Sleep-time Compute란 무엇인가
Sleep-time compute는 에이전트가 사용자와 대화하지 않는 유휴 시간에, 기존 컨텍스트를 기반으로 미리 추론하고 기억을 정제해두는 패러다임이다.
인간이 수면 중에 단기 기억을 장기 기억으로 통합하듯, 에이전트는 유휴 시간 동안:
- 컨텍스트에서 예상 가능한 질문을 추론한다.
- 해당 질문에 유용한 형태로 컨텍스트를 재구성한다.
- 재구성된 정보를 메모리 블록에 저장한다.
- 이후 실제 요청이 들어오면 훨씬 적은 추론 예산으로 답한다.
test-time compute와의 가장 큰 차이는 레이턴시 경로 밖에서 실행된다는 것이다. Sleep-time 작업은 사용자가 기다리는 동안이 아니라, 에이전트가 쉬고 있는 동안 실행된다.
전체 이력 매번 재처리
복잡한 질문 = 높은 비용
예상 질문 미리 추론
rethink_memory() 반복 호출
추론 토큰 ~5× 절감
두 에이전트 아키텍처
Letta의 구현에서 sleep-time compute는 두 에이전트의 역할 분리로 실현된다.
Primary Agent (주 에이전트)
사용자 요청을 처리하는 에이전트다. 역할을 좁게 유지하도록 설계된다.
- 사용자와 대화하고 응답을 반환한다.
- 도구를 호출하고 외부 시스템과 상호작용한다.
- 메모리를 직접 수정하지 않는다. 메모리 블록을 읽고 참조할 뿐이다.
- 처리 경로가 가볍고 결정론적이어야 하므로, 불필요한 메모리 관리 작업을 하지 않는다.
Sleep-time Agent (수면 에이전트)
메모리를 정제하는 에이전트다. 유휴 시간에 백그라운드로 동작한다.
- 대화 이력, 외부 데이터 소스, 이전 추론 결과를 읽는다.
rethink_memory()함수를 반복적으로 호출해 메모리 블록을 업데이트한다.- 특화된 도구를 호출하고, 깊은 추론을 수행할 수 있다.
- 기존 MemGPT와 달리, 메모리 관리를 비동기로 처리해 응답 레이턴시에 영향을 주지 않는다.
두 에이전트는 공유 메모리 블록을 통해 연결된다. Primary agent가 메모리를 읽고, sleep-time agent가 메모리를 업데이트하는 단방향 구조다.
핵심 장점: 추론 비용의 분산
같은 컨텍스트에 대해 다른 사용자가 서로 다른 질문을 하더라도, 미리 정제된 메모리는 재사용된다. Sleep-time 추론 비용이 여러 쿼리에 걸쳐 분산된다는 점이 핵심이다.
예를 들어 긴 계약서를 컨텍스트로 가진 에이전트가 있다면, sleep-time agent가 미리 핵심 조항, 의무, 기한을 정리해둔다. 이후 "3.2조의 위약금 조건은?" 같은 질문이 들어오면, primary agent는 전체 계약서를 다시 읽지 않아도 된다.
실험 결과
연구팀은 두 가지 수학 추론 벤치마크를 상태 있는(stateful) 형태로 변환해 실험했다.
Stateful GSM-Symbolic
초등 수학 문제를 여러 단계에 걸친 상태 변화를 포함하는 문제로 확장한 것이다. 에이전트는 대화 이력 속 숫자 상태를 추적해야 한다.
| 방식 | 정확도 | 비고 |
|---|---|---|
| 기준선 (test-time 1×) | ~60% | 컨텍스트 단순 전달 |
| Sleep-time compute | ~73% | +13%p 향상 |
| Sleep-time + 더 많은 예산 | ~78% | 추가 추론 예산 투입 시 |
Stateful AIME
수학올림피아드 수준의 문제(AIME 2024, 2025)를 상태 있는 형태로 변환했다.
| 방식 | 성능 |
|---|---|
| 기준선 동일 예산 | 기준 |
| Sleep-time compute (5× 적은 test-time 예산) | 기준과 동일 |
| Sleep-time compute + 추가 예산 | +18%p |
핵심 수치: test-time 추론 예산을 5분의 1로 줄이면서 동일한 정확도를 달성한다.
모델별 특성
실험에는 o1, o3-mini, Claude Sonnet 3.7이 사용됐다.
- o3-mini, Claude Sonnet 3.7에서 유의미한 성능 향상이 관찰됐다.
- o1에서는 제한적인 향상을 보였다. Open question: o1의 내부 추론 메커니즘이 이미 일부 컨텍스트를 암묵적으로 처리하는 방식이 영향을 미쳤을 가능성이 있다.
MemGPT와의 차이
MemGPT는 메모리 관리, 대화, 도구 호출을 하나의 에이전트에서 처리했다. 메모리를 업데이트해야 할 때 응답 처리가 느려지거나, 대화 중에 업데이트가 적절한 시점을 놓치는 문제가 있었다.
Sleep-time compute 아키텍처는 이 문제를 역할 분리로 해결한다.
| 항목 | MemGPT (단일 에이전트) | Sleep-time (이중 에이전트) |
|---|---|---|
| 메모리 업데이트 타이밍 | 대화 중 동기적 | 유휴 시간 비동기 |
| 응답 레이턴시 | 메모리 작업 시 증가 | 사용자 요청과 분리 |
| 메모리 품질 | 점진적, 단편적 | 전체 이력 기반 재정제 |
| 확장성 | 에이전트 단일 병목 | 메모리 에이전트 독립 확장 |
프로덕션에서 적용할 수 있는 상황
Sleep-time compute가 효과적인 상황과 그렇지 않은 상황을 구분해야 한다.
효과적인 상황
- 대화 이력이 길고 반복 질의가 예상될 때: 고객 지원 에이전트, 법률 문서 분석 에이전트, 코드베이스 질의 에이전트
- 컨텍스트가 자주 바뀌지 않을 때: 분석 대상이 안정적인 데이터라면 메모리 재정제 주기를 늘릴 수 있다.
- 응답 레이턴시가 엄격할 때: Sleep-time 추론으로 test-time 예산을 줄이면 응답 속도를 개선할 수 있다.
효과가 제한적인 상황
- 컨텍스트가 실시간으로 빠르게 변할 때: 주식 가격, 실시간 센서 데이터처럼 지속적으로 바뀌는 컨텍스트는 미리 정제해도 금방 무효화된다.
- 단일 세션, 짧은 대화: 이력이 짧으면 sleep-time 정제의 이점이 줄어든다.
- 컨텍스트 독립적인 질문: 메모리와 무관한 일회성 질문에는 효과가 없다.
운영 체크리스트
Sleep-time compute 아키텍처를 도입할 때 고려해야 할 항목들이다.
메모리 관리 설계
- [ ] 메모리 블록의 구조와 스키마를 명확히 정의한다. 비정형 메모리는 재사용 효율이 낮다.
- [ ] Sleep-time agent가 얼마나 자주 실행될지 정책을 결정한다. 너무 잦으면 비용이 증가하고, 너무 드물면 메모리가 stale해진다.
- [ ]
rethink_memory()호출의 종료 조건을 설정한다. 무한 루프 방지.
비용 관리
- [ ] Sleep-time 추론 비용과 test-time 절감 비용의 균형을 측정한다.
- [ ] 메모리 업데이트가 자주 필요하지 않은 컨텍스트에만 sleep-time agent를 배치한다.
- [ ] 업데이트된 메모리가 여러 사용자 쿼리에 재사용되는지 추적한다.
정확도 검증
- [ ] Sleep-time 정제가 중요한 정보를 손실하지 않는지 검증한다. 특히 수치, 날짜, 고유명사.
- [ ] 컨텍스트 변경 이후 stale 메모리로 인한 오답을 탐지할 모니터링을 구성한다.
인프라
- [ ] Primary agent와 sleep-time agent가 동일한 메모리 블록에 동시 접근하는 경쟁 상태를 방지한다.
- [ ] Sleep-time agent를 독립 확장할 수 있도록 배포 구조를 설계한다.
마무리
Sleep-time compute는 에이전트 추론 비용을 줄이는 새로운 축이다. Test-time compute가 "요청 시점에 더 깊이 생각하는" 방향이라면, sleep-time compute는 "유휴 시간에 미리 생각해두는" 방향이다.
두 접근법은 경쟁 관계가 아니라 보완 관계다. 실제 프로덕션에서는 두 축을 모두 활용하는 것이 효과적이다: 반복적으로 참조되는 컨텍스트는 sleep-time으로 미리 정제하고, 실시간 판단이 필요한 부분은 test-time 예산으로 처리한다.
핵심 전제 조건은 상태 있는 메모리다. 에이전트가 세션 간에 지식을 유지하지 못하면 sleep-time compute의 효과는 없다. 이것이 stateful agent 아키텍처가 단순한 선택이 아니라 이 패러다임의 전제 조건인 이유다.
References
- Letta & UC Berkeley, "Sleep-time Compute: Beyond Inference Scaling at Test-time," arXiv:2504.13171, April 2026: https://arxiv.org/abs/2504.13171
- Letta, "Sleep-time Compute" (blog post): https://www.letta.com/blog/sleep-time-compute/
- Letta Docs, "Sleep-time Agents": https://docs.letta.com/guides/agents/architectures/sleeptime/
- GitHub, "letta-ai/sleep-time-compute" (accompanying code): https://github.com/letta-ai/sleep-time-compute
- Arize AI, "Sleep-time Compute: Beyond Inference Scaling at Test-time" (review): https://arize.com/blog/sleep-time-compute-beyond-inference-scaling-at-test-time/
- Ken Huang, "Why AI Agents Are Starting to Dream," Substack: https://kenhuangus.substack.com/p/why-ai-agents-are-starting-to-dream