AX LABS
← 블로그 AX Ops 방법론

압축 손실은 재연으로 잡는다

요약이 아니라 결정 품질을 검증한다

긴 에이전트 세션을 운영하면 비슷한 장면이 반복된다. 초반에 합의한 제약, 반려한 선택지, 사용자가 강조한 예외가 어느 순간 사라진다. 모델이 갑자기 멍청해진 것이 아니다. 압축된 히스토리가 다음 판단에 필요한 의미를 보존하지 못한 것이다.

Anthropic의 Claude API 문서는 compaction을 입력 토큰이 임계점에 가까워질 때 이전 대화를 요약 블록으로 바꿔 이어가는 기능으로 설명한다. Claude Code 문서도 PreCompact hook을 통해 compaction 전에 사용자 로직을 실행하고, 필요하면 전체 transcript를 보관하라고 안내한다. 운영 관점의 핵심은 명확하다. compaction은 기능이 아니라 손실이 발생하는 운영 이벤트다.

손실은 요약 품질이 아니라 재현 실패로 드러난다

많은 팀이 compact summary를 읽고 “괜찮아 보인다”고 판단한다. 이 방식은 틀렸다. 요약문은 늘 그럴듯하다. 문제는 요약문만 들고 같은 결정을 다시 내릴 수 있느냐다.

AX Ops의 context compaction loss test는 두 가지 질문으로 시작한다.

테스트 묻는 질문 실패 신호
Reconstruction probe 압축본만 보고 핵심 사실·제약·결정 근거를 복원하는가 누락, 왜곡, 출처 혼동
Decision replay 같은 업무 지점에서 같은 결정을 재현하는가 반려안 재채택, 승인 조건 누락, 도구 호출 변경

reconstruction probe는 기억력 시험이다. decision replay는 판단력 시험이다. 둘은 같이 봐야 한다. 사실을 일부 잃어도 결정이 유지되는 경우가 있고, 사실을 많이 맞혀도 중요한 예외 하나를 놓쳐 잘못된 결정을 내리는 경우가 있다.

compaction loss의 단위는 토큰이 아니다. 다시 실행했을 때 바뀐 결정이다.

Probe는 압축 직전의 원장을 기준으로 만든다

테스트의 기준선은 사람이 사후에 만든 정답지가 아니다. compaction 직전의 full history다. Claude Code의 PreCompact hook처럼 압축 직전 transcript를 외부에 저장할 수 있는 지점이 있다면 그 순간을 잡는다. 없으면 에이전트 런타임에서 message log, tool call, tool result, 사용자 승인 이벤트를 별도로 남긴다.

원장에서 probe item을 뽑을 때는 세 종류만 남긴다.

  1. 결정 사실: 무엇을 하기로 했고 무엇을 하지 않기로 했는가.
  2. 제약 조건: 보안, 비용, 일정, 승인, 데이터 접근 조건은 무엇인가.
  3. 근거 연결: 어떤 관찰이나 tool result 때문에 그 결정을 했는가.

좋은 probe는 단답형 지식 문제가 아니다. “왜 이 API를 쓰지 않기로 했는가”, “다음 단계에서 어떤 파일을 건드리면 안 되는가”, “사용자 승인이 필요한 조건은 무엇인가”처럼 다음 행동을 제한하는 질문이어야 한다.

Decision replay는 같은 분기점에 다시 세운다

decision replay는 압축 전후의 에이전트를 같은 분기점에 세우는 절차다. full history 조건에서는 원래 결정을 재현한다. compact history 조건에서는 압축본만 주고 같은 사용자 요청, 같은 도구 결과, 같은 시스템 지침으로 다시 실행한다.

여기서 비교 대상은 문장 유사도가 아니다. 운영에서는 다음 네 가지를 본다.

  • 선택한 action이 같은가.
  • 사용한 tool과 인자가 같은 의미를 갖는가.
  • 승인·검토·중단 조건을 유지하는가.
  • 이미 반려된 선택지를 다시 꺼내지 않는가.

OpenAI가 사내 data agent 글에서 runtime context와 memory를 별도 레이어로 두고 Evals API로 응답 품질을 보호한다고 설명한 이유도 같은 맥락이다. 장기 실행 agent의 품질은 모델 호출 하나의 정답률이 아니라, 누적된 맥락이 다음 실행에서 의사결정을 얼마나 보존하느냐로 결정된다.

AX Ops는 compaction을 배포 게이트로 다룬다

Context compaction loss test는 연구용 벤치마크가 아니다. 운영 배포 게이트다. AX Ops에서는 에이전트 업무별로 “잃으면 안 되는 의미”를 먼저 정의하고, compaction 이벤트마다 probe와 replay를 자동 실행한다.

실행 순서는 단순하다.

  1. compaction 직전 원장 저장
  2. probe item 자동 생성 후 사람 검수
  3. compact history로 reconstruction 실행
  4. 동일 분기점에서 decision replay 실행
  5. 실패 유형을 compaction instruction, memory schema, tool log 보존 정책에 반영

이 절차를 넣으면 compaction을 두려워할 필요가 없다. 압축을 금지하는 조직은 긴 세션을 운영하지 못한다. 압축을 측정하지 않는 조직은 긴 세션을 믿지 못한다. 둘 다 운영 설계 실패다.

Context compaction loss test의 목표는 요약을 예쁘게 만드는 것이 아니다. 압축 이후에도 같은 업무 판단이 유지되는 agent harness를 만드는 것이다. AX 도입 이후 운영 정착 단계에서 이 검증 루프를 설계해야 한다. 더 구체적인 적용 절차는 AX Ops 방법론 →에서 이어진다.

참고