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 작업은 사용자가 기다리는 동안이 아니라, 에이전트가 쉬고 있는 동안 실행된다.

Test-time Compute (기존 방식)

사용자 요청 수신

↓

긴 컨텍스트 읽기
전체 이력 매번 재처리

↓

추론 토큰 대량 소비
복잡한 질문 = 높은 비용

↓

응답 반환

유휴 시간: 아무것도 안 함

Sleep-time Compute (새로운 방식)

유휴 시간 (sleep-time agent 작동)

↓

컨텍스트 분석 & 재구성
예상 질문 미리 추론

↓

메모리 블록 업데이트
rethink_memory() 반복 호출

요청 처리 (primary agent)

사용자 요청 수신

↓

정제된 메모리로 빠른 추론
추론 토큰 ~5× 절감

↓

응답 반환

Sleep-time Compute: test-time compute vs sleep-time compute 비교

두 에이전트 아키텍처

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