AX LABS
← 블로그 에이전트 제품 설계

압축은 멈춤이 아니라 배치다

장기 실행 에이전트는 히스토리를 병렬로 줄인다

현장에서 장기 실행 에이전트를 붙이면 처음에는 답 품질이 문제가 아니다. 문제는 세션이 길어질수록 에이전트가 무엇을 했고, 왜 했고, 어떤 증거를 봤는지 스스로 감당하지 못하는 순간에 온다. 파일 읽기, 검색 결과, tool call, 중간 판단, 사용자 정정이 한 줄로 쌓인다. 어느 순간 압축이 필요해지고, 그 압축이 다시 새로운 장애 지점이 된다.

단일 compaction은 운영 병목이다

지금 많은 에이전트 런타임은 context가 차면 하나의 긴 히스토리를 하나의 요약 호출로 줄인다. Claude Code의 /compact와 자동 compaction, Anthropic의 context editing·memory tool, OpenAI Agents SDK의 session compaction 같은 흐름은 이미 제품 레벨에서 context 관리를 전제로 한다. 방향은 맞다. 그러나 운영 설계가 단일 요약 호출에 머물면 장기 실행 업무에는 부족하다.

단일 compaction은 세 가지 문제를 만든다.

  • 압축 중 agent loop가 멈춘다.
  • 요약 지시가 길어져도 어떤 정보가 남을지 예측하기 어렵다.
  • 손실이 생겨도 다음 turn에서야 발견된다.

2026년 5월 arXiv에 올라온 Parallel Context Compaction 논문도 이 지점을 정면으로 다룬다. 긴 히스토리의 LLM 요약은 lossy이고, blocking call은 agent inference를 멈춘다. CoMem 논문도 memory management를 agent reasoning과 분리해 비동기로 겹쳐 실행하는 구조를 제안한다. 결론은 같다. 압축은 모델에게 맡기는 문장 일이 아니라 런타임이 스케줄링해야 하는 작업이다.

장기 실행 에이전트에서 compaction은 요약 기능이 아니라 상태 관리 기능이다.

히스토리는 블록으로 나눠야 검증된다

Parallel context compaction scheduler의 기본 단위는 message가 아니라 block이다. block은 하나의 의미 있는 작업 구간이다. 예를 들면 “요구사항 확정”, “검색과 증거 수집”, “코드 수정”, “테스트 실패 분석”, “사용자 정정 반영” 같은 구간이다.

각 block은 append-only로 고정한다. 원문 transcript, tool 결과의 content hash, file path, 결정 사항, unresolved question을 함께 묶는다. 압축 worker는 block별로 병렬 실행한다. worker의 출력은 자유 요약문이 아니다. 운영에서는 schema가 필요하다.

구성요소 보존해야 할 것 버려도 되는 것
intent 현재 목표, acceptance criteria 반복된 재진술
evidence 출처 ID, file path, tool result hash 재조회 가능한 원문 전문
decision 선택지, 결정, 근거 장황한 사고 과정
risk 미해결 이슈, 반대 증거 해결된 임시 가설
handoff 다음 행동, 필요한 context 종료된 하위 작업 로그

이렇게 해야 merge 단계가 가능해진다. block summary가 서로 다른 언어로 쓰이면 병합은 다시 감에 의존한다. 반대로 같은 schema로 압축하면 “빠진 사실”, “충돌하는 결정”, “증거 없는 결론”을 기계적으로 찾을 수 있다.

merge verifier가 손실을 조기에 잡는다

병렬 압축은 빠르지만 위험하다. block마다 잘라 요약하면 block 사이의 의존성이 사라진다. 그래서 scheduler에는 merge verifier가 반드시 붙어야 한다.

merge verifier는 최종 요약을 예쁘게 고치는 역할이 아니다. 손실을 검출하는 gate다. 최소한 네 가지 검사를 둔다.

  1. coverage check: 각 block의 필수 field가 merged state에 남았는지 본다.
  2. contradiction check: 이전 결정과 이후 정정이 동시에 남아 충돌하는지 본다.
  3. evidence check: claim마다 source pointer나 tool result hash가 있는지 본다.
  4. replay check: 다음 turn에서 필요한 질문을 던져 원문 block과 merged state의 답이 기능적으로 같은지 본다.

Cloudflare의 Agent Memory 발표는 compaction 시점에 conversation을 ingestion하고 facts, events, instructions, tasks를 추출·검증·분류한다고 설명한다. 이 방향은 merge verifier 설계와 맞닿아 있다. 요약을 저장하는 것이 아니라 다음 행동에 필요한 상태를 검증해 저장해야 한다.

스케줄러는 agent harness의 일부다

이 설계는 모델 프롬프트 몇 줄로 끝나지 않는다. harness engineering 영역이다. scheduler는 context 사용량, block 나이, task boundary, tool result 재조회 가능성, latency budget을 보고 압축 작업을 큐에 넣는다. parent agent는 계속 진행하고, compaction worker는 뒤에서 block summary를 만든다. merge verifier가 통과한 상태만 active context나 external memory로 승격한다.

운영 기준은 단순하다.

  • 원문 block은 일정 기간 보관한다.
  • summary에는 evidence pointer를 강제한다.
  • verifier 실패 시 해당 block만 재압축한다.
  • 사용자 지시, acceptance criteria, 보안·권한 관련 내용은 별도 high-priority lane으로 둔다.

Claude Code 문서는 subagent가 별도 context window에서 작업하고 최종 요약만 parent로 돌아온다고 설명한다. PreCompact hook도 compaction 전 transcript archive 같은 로직을 넣는 지점으로 제시된다. 이런 hook과 subagent 패턴은 parallel compaction scheduler를 제품에 붙일 때 현실적인 연결점이다.

참고와 적용

핵심은 얕다. 긴 히스토리를 한 번에 요약하지 않는다. block으로 쪼개 병렬 압축한다. merge verifier로 손실을 먼저 잡고, 통과한 상태만 agent loop에 되돌린다.

참고한 최근 12개월 이내 자료는 아래와 같다.

AX LABS는 이런 compaction·memory·verifier를 개별 기능이 아니라 운영 가능한 agent harness로 설계한다. 장기 실행 에이전트를 PoC 밖으로 꺼내려면 먼저 context 운영을 설계해야 한다: AX Ops 방법론 →