[논문 리뷰] Handover of In-Context Learning State — 세션 경계를 넘는 agent state 전달

한 줄 요약

이 논문은 long-running LLM 애플리케이션에서 세션이 끊길 때 무엇을 다음 세션으로 넘겨야 하는지를 task-relative in-context learning state의 전달 문제로 정식화한다. 흔한 “대화 요약을 잘 쓰자” 수준의 글이 아니다. 어떤 정보는 원문 그대로 보존해야 하고, 어떤 정보는 통계량으로 압축해도 되며, 어떤 정보는 다음 downstream query가 정해지기 전에는 버리면 안 된다는 점을 이론적으로 분리한다.

내 의견부터 말하면, agent runtime을 만드는 사람에게 꽤 중요한 주제다. 지금 많은 코딩 에이전트와 개인 비서는 context limit, 앱 재시작, subagent delegation을 만나면 대충 summary를 남기고 다음 세션을 시작한다. 그 방식은 편하지만, 작업의 제약·결정·증거·불확실성을 섞어버린다. 그래서 이어받은 agent가 “그럴듯하게 계속하는데 실제로는 다른 작업을 하는” 실패가 나온다.

왜 지금 중요한가

장기 실행 agent는 한 세션 안에서 끝나지 않는다.

• context window가 꽉 찬다.
• 앱이나 worker가 재시작된다.
• 큰 작업을 subagent에게 넘긴다.
• 사람이 중간에 개입하고, 나중에 다시 이어서 실행한다.
• 비용 때문에 긴 로그를 매번 통째로 넣을 수 없다.

이때 필요한 것은 “좋은 요약문”이 아니라 재개 가능한 상태 전달 프로토콜이다. 예를 들어 코딩 에이전트가 버그를 고치다 세션을 넘긴다고 해보자. 다음 agent에게 필요한 것은 단순히 “인증 버그를 고치는 중”이라는 문장이 아니다.

필요한 것은 더 구체적이다.

1. 이미 확인한 사실: 어떤 파일을 읽었고, 어떤 가설이 틀렸는가.
2. 결정된 제약: public API는 바꾸지 않는다, migration은 금지한다.
3. 반복 증거의 압축: 같은 테스트 실패가 여러 번 반복됐다는 사실.
4. 보존해야 할 원문 관찰: 에러 메시지, diff, 사용자 지시처럼 작은 표현 차이가 중요한 자료.
5. 아직 모르는 것: 다음 세션이 어떤 질문을 하게 될지 불확실한 영역.

논문은 이 문제를 “이전 context를 얼마나 비슷하게 복원하느냐”가 아니라 “다음 작업에서 같은 예측/판단 분포를 유지할 수 있느냐”로 본다. 이 관점이 좋다. handover의 목표는 로그 재현이 아니라 작업 지속성이다.

핵심 아이디어: handover는 summary가 아니라 sufficient state다

논문은 handover를 이전 세션에서 학습된 ICL state를 다음 세션으로 넘기는 문제로 본다. 여기서 중요한 표현은 task-relative다. 모든 정보를 보존할 필요는 없다. 하지만 다음 continuation task에 영향을 주는 정보는 보존해야 한다.

이를 agent 설계 언어로 바꾸면 이렇게 된다.

type HandoverState = {
  decisions: Decision[];
  constraints: Constraint[];
  evidenceStats: EvidenceStatistic[];
  preservedObservations: Observation[];
  unresolvedQuestions: Question[];
};

핵심은 summary: string 하나로 끝내지 않는 것이다. 요약은 사람이 읽기 좋지만 런타임이 검증하기 어렵다. 반면 결정, 제약, 증거, 원문 관찰, 미해결 질문을 분리하면 다음 세션이 무엇을 믿고 무엇을 다시 확인해야 하는지 훨씬 명확해진다.

논문은 특히 세 가지 record를 제안한다.

1. Decisions and constraints는 정확히 저장한다.
   사용자가 명시한 조건, 이미 확정한 선택, 금지된 행동은 손실 압축하면 안 된다.

2. Repeated evidence는 task-justified statistic으로 저장한다.
   반복 관찰 전체를 보관하는 대신, downstream 판단에 충분한 통계량으로 줄일 수 있다.

3. Statistic으로 보존되지 않는 original observation은 원문으로 남긴다.
   에러 메시지, 사용자 문구, 도구 출력의 작은 차이가 다음 판단에 영향을 준다면 요약하지 말아야 한다.

이 구분은 실무적으로도 꽤 쓸 만하다. agent memory를 만들 때 “무엇을 저장할까”보다 “무엇을 어떤 fidelity로 저장할까”가 더 중요하기 때문이다.

exact recovery와 predictive preservation은 다르다

논문에서 마음에 드는 구분은 exact recovery와 preservation of target distribution이다.

• exact recovery: 이전 세션의 자료를 최대한 그대로 복원한다.
• predictive preservation: 다음 continuation에서 필요한 판단 분포를 보존한다.

많은 agent memory 구현은 둘을 섞는다. 로그를 통째로 저장하면 안전해 보이지만 비용이 크고 retrieval이 어려워진다. 반대로 요약만 저장하면 싸지만 중요한 세부 사항을 잃는다.

실무에서는 둘 사이를 구분해야 한다.

블로그 운영 관점에서도 비슷하다. “이 글은 Handover 논문 리뷰를 쓰는 중”이라는 요약보다, 선택한 angle, frontmatter 규칙, 이미 확인한 source, 남은 검증 작업이 훨씬 유용하다.

writer와 continuation procedure를 분리해서 봐야 한다

논문은 handover 품질을 memory constraint만의 문제가 아니라 writer와 continuation procedure의 문제로도 본다. 이건 agent runtime에서 정말 자주 놓친다.

• Writer: 이전 세션 말미에 handover record를 작성하는 주체
• Memory constraint: 넘길 수 있는 정보량과 형식
• Continuation procedure: 다음 세션이 handover를 읽고 작업을 재개하는 방식

좋은 handover를 만들려면 세 요소가 맞아야 한다. 예를 들어 이전 agent가 아무리 잘 정리해도 다음 agent가 그것을 그냥 참고 문단으로만 읽고 tool state나 task plan에 반영하지 않으면 효과가 작다. 반대로 continuation procedure가 좋아도 writer가 모든 것을 “진행 중” 한 문장으로 뭉개면 복구할 수 없다.

그래서 나는 handover를 아래처럼 runtime primitive로 다루는 편이 맞다고 본다.

type ResumePacket = {
  taskGoal: string;
  invariants: string[];
  completedSteps: string[];
  failedHypotheses: string[];
  openQuestions: string[];
  requiredArtifacts: string[];
  nextRecommendedAction: string;
  citations: Array<{ label: string; source: string }>;
};

여기서 중요한 것은 nextRecommendedAction 하나만 믿지 않는 것이다. handover는 “다음에 뭘 해라”가 아니라 “왜 그 다음 행동이 합리적인지 검증할 수 있는 상태”를 넘겨야 한다.

downstream query를 모르는 상태에서 쓰는 비용

논문 초록에서 흥미로운 지점은 realized downstream query를 알기 전에 record를 작성하는 비용을 언급한다는 점이다. 실제 agent handover는 대부분 이 상황이다. 다음 세션이 정확히 어떤 질문을 할지 모른다.

예를 들어 코딩 에이전트가 다음 세션에서 할 수 있는 일은 여러 가지다.

• failing test를 다시 재현한다.
• 다른 파일을 탐색한다.
• 기존 patch를 되돌린다.
• 사용자에게 범위 확인을 요청한다.
• subagent에게 특정 모듈 분석을 위임한다.

다음 query가 정해져 있다면 필요한 정보만 압축하면 된다. 하지만 정해져 있지 않다면 handover는 더 보수적이어야 한다. 이때 실무적인 전략은 “모든 원문을 다 남긴다”가 아니라 불확실한 분기점의 evidence를 남긴다에 가깝다.

즉, 아래를 우선 보존한다.

1. 되돌릴 수 없는 결정의 근거
2. 여러 continuation path에 공통으로 필요한 제약
3. 실패한 가설과 그 증거
4. 요약하면 의미가 바뀌는 원문 관찰
5. 다음 작업자가 다시 비용을 크게 써야 얻을 수 있는 결과

이 기준은 context compaction이나 memory pruning에도 그대로 적용할 수 있다.

실무 적용: agent resume packet 체크리스트

long-running agent를 운영한다면 handover를 아래 체크리스트로 점검하는 게 좋다.

1. 결정과 관찰을 섞지 말기

“인증 미들웨어가 문제인 듯함”은 관찰인지 가설인지 결정인지 애매하다. 다음처럼 분리하는 편이 낫다.

decisions:
  - "public API response shape은 바꾸지 않는다"
observations:
  - "GET /session test가 401 대신 500을 반환했다"
hypotheses:
  - "session middleware가 null user를 처리하지 못할 가능성"
rejected_hypotheses:
  - "database migration 누락은 아님: local test DB schema 확인 완료"

2. 원문 보존이 필요한 데이터를 표시하기

모든 도구 출력을 저장할 수는 없다. 하지만 원문성이 중요한 출력은 표시해야 한다.

• stack trace
• failing assertion
• user-provided constraint
• external API response sample
• diff hunk
• config snippet

이런 것은 요약보다 citation이 낫다. 파일 경로, line range, command output id 같은 근거 링크가 있어야 한다.

3. 다음 행동보다 resume condition을 적기

“다음에는 test를 돌려라”보다 “test를 돌리기 전에 X 파일의 patch가 적용돼 있어야 한다”가 더 중요할 때가 많다. handover는 action list가 아니라 state transition 문서여야 한다.

4. subagent handoff에는 권한 경계를 같이 넘기기

subagent에게 넘길 때는 task만 넘기면 안 된다.

• 읽을 수 있는 파일 범위
• 수정 가능한 파일 범위
• 실행 가능한 command
• 외부 네트워크 사용 가능 여부
• 완료 artifact 형식

이 경계가 없으면 handover는 delegation이 아니라 권한 누수다.

한계와 읽을 때 주의할 점

이 논문은 이론적 정식화의 비중이 크다. 초록 기준으로 Gaussian linear regression과 nonparametric regression을 통해 finite-dimensional handover, finite-bit perturbation bound, memory와 squared prediction error의 관계를 다룬다. 따라서 바로 “이 알고리즘을 붙이면 agent memory가 좋아진다”는 식으로 읽으면 안 된다.

내가 보기에는 실무 적용의 핵심은 특정 수식보다 아래 세 가지다.

1. handover를 summary generation이 아니라 sufficient state construction으로 본다.
2. exact record와 compressed statistic, original observation을 분리한다.
3. 다음 continuation task가 불확실할 때 보수적으로 남겨야 할 정보를 정의한다.

아직 확인해야 할 부분도 있다. 실제 production agent trace에서 이 record가 얼마나 작아지는지, writer가 자동으로 안정적인 handover를 만들 수 있는지, 사람이 리뷰 가능한 schema로 떨어지는지는 논문 본문과 후속 구현을 더 봐야 한다. 초안 단계에서는 이 부분을 확정 사실처럼 쓰지 않는 게 맞다.

내 생각

agent handover는 앞으로 꽤 중요한 runtime primitive가 될 가능성이 높다. context window가 커져도 이 문제는 사라지지 않는다. 긴 context는 “많이 넣을 수 있음”을 해결할 뿐, “무엇이 task state인가”를 자동으로 해결하지 않는다.

특히 코딩 에이전트에서는 handover 품질이 곧 안전성과 비용이다. 잘못된 handover는 같은 파일을 반복 탐색하게 만들고, 이미 기각한 가설을 되살리며, 사용자 제약을 희미하게 만든다. 더 나쁘게는 subagent가 원래 의도와 다른 patch를 만들어도 그럴듯해 보이게 한다.

그래서 좋은 agent runtime은 대화 끝에 자연어 요약을 남기는 수준을 넘어야 한다. session boundary가 생길 때마다 구조화된 resume packet을 만들고, 다음 세션은 그 packet을 plan, tool policy, memory retrieval에 명시적으로 반영해야 한다. 이 논문은 그 방향을 이론적으로 정리해주는 좋은 출발점이다.

참고 자료

• arXiv: Handover of In-Context Learning State Across Session Boundaries
• PDF: arXiv 2608.14528v1