#컨텍스트 압축에서 잃어서는 안 되는 것

압축은 채팅 기록을 짧게 쓰는 것이 아니라, 다음 턴에 모델이 올바른 동작을 할 수 있는지를 결정하는 일이다. 판단 기준은 한 문장의 총강이다 — 다음 단계의 행위, 권한, 안전, 결과 재검토에 영향을 주는 정보는 일반 요약으로 압축해서는 안 되고 반드시 구조화 보존해야 한다.

여기서 절대 잃어서는 안 되는 4종 정보가 전개된다: 사용자 목표와 금지 항목, 도구 결과의 핵심 필드, 실패 경로, 증거와 시효.

이는 3층 전략으로 구현된다(채팅 내용은 요약 가능 / 실행 상태는 구조화 / 안전 경계와 외부 ID는 원문 그대로 보존).

네 개의 트리거 워드가 체크리스트 하나를 구성한다: 행위 / 권한 / 안전 / 결과 재검토.

#표면은 압축, 실제는 상태 보존

컨텍스트에 들어오는 내용	성질
Prompt	서술
도구 결과	실행 상태
사용자 목표	하드 제약
시스템 상태	실행 상태
에러 기록	실행 상태
외부 데이터	외부 사실

압축의 정의가 다시 쓰인다: 채팅 기록을 짧게 쓰는 것이 아니라, 다음 턴에 모델이 올바른 동작을 할 수 있는지를 결정하는 것.

압축의 목표는 Token 절약이 아니라, 다음 턴의 Agent가 최소한이면서도 충분히 신뢰할 수 있는 상태를 받게 하는 것이다.

#잃어서는 안 되는 4종

• 사용자 목표와 금지 항목

  • 목표: 현재 무엇을 완성해야 하는가, 검수 기준은 무엇인가, 어떤 범위는 건드리면 안 되는가
  • 금지 항목: 삭제 불가, 발송 불가, 월권 불가, 수정 불가 — 네 가지 경계

  이탈의 진짜 원인: 요약이 틀려서가 아니라, 사용자가 나중에 바꾼 목표를 모호한 배경 한 줄로 요약해서 옛 계획이 계속 유효해지는 것

• 도구 결과의 핵심 필드

  • 처리 요구: 원문 그대로 보존(고쳐 쓰기 금지, 의역 금지, 요약화 금지)
  • 핵심 대조: 자연어 요약은 「결제 성공」이라 말해도 되지만, 실행 시스템은 payment_id와 상태, 시각이 필요하다
  • 기술적 뒷받침: OpenAI Structured Outputs의 가치가 바로 여기에 있다 — 핵심 상태를 구조화 형식으로 전달하게 하지, 모델이 한 단락의 말을 기억하는 데 의존하지 않게 한다

  업무 식별자	주문번호, 승인번호
  시스템 식별자	파일 경로, trace ID, DB 기본키
  재현 가능 동작	테스트 명령
  실패 식별자	에러 코드

• 실패 경로 (Agent가 같은 함정을 반복해 밟는 것을 방지)

  • 어떤 방안을 시도했는가
  • 왜 실패했는가
  • 어떤 테스트가 통과하지 못했는가
  • 어떤 권한이 거부되었는가

  성공 경로만 남김 → 다음 턴의 모델이 실패 원인을 못 봄 → 이미 안 된다고 증명된 방안을 다시 돌린다

  실제 프로젝트에서 실패 기록은 성공 결과와 똑같이 중요하다.

• 증거와 시효 (답이 신뢰받을 수 있는지를 결정)

  설명은 줄여도 되지만 출처와 시각은 지워서는 안 된다.

  때로는 옛 상태를 반드시 다시 검증해야 한다 — 요약이 아직 남아 있다고 세상이 안 변한 것은 아니다.

  RAG 인용 조각	증거 출처
  웹페이지 갱신 시각	시효
  외부 데이터 조회 시각	시효
  사용자 확인 시각	시효

#압축 품질의 검수 방법: 이어달리기 테스트

압축된 컨텍스트만 단독으로 Agent에게 주고 세 가지를 볼 것:

1. 다음 단계를 올바로 고를 수 있는가
2. 금지 항목을 지키는가
3. 핵심 증거를 재현할 수 있는가

판정 기준: 이어달릴 수 있어야 압축이 합격이다.

#핵심 통찰

1. 「중점을 남긴다」는 가짜 답이다. 「중점」은 사람의 가독성으로 정의되는데 Agent에게 필요한 것은 실행 가능성이기 때문이다 — 요약 품질의 전통적 평가(유창함, 요지 포착)는 Agent의 요구와 직교한다. 어떤 요약은 사람 눈에는 만점이면서 payment_id 하나를 잃어버려 다음 턴의 동작을 전부 틀리게 만들 수 있다. 압축의 좋고 나쁨을 판단하는 유일한 기준은 하류가 계속 올바르게 실행할 수 있는가이지, 읽었을 때 그럴듯한가가 아니다.
2. 압축의 본질은 상태 관리이지 텍스트 처리가 아니다 — 컨텍스트를 「채팅 기록」으로 보는 순간 압축은 요약 문제가 되고, 그것을 「Agent의 실행 상태」로 보면 압축은 상태 직렬화 + 손실 강등 전략 문제가 된다. 후자라야 공학적 해법이 있다.
3. 「행위 / 권한 / 안전 / 결과 재검토」는 바로 적용 가능한 4문 체크리스트다 — 어떤 정보든 이렇게 물어보라: 다음 단계 동작에 영향을 주는가? 할 수 있는지 여부에 영향을 주는가? 하는 것이 안전한지에 영향을 주는가? 사후에 재검토할 수 있는지에 영향을 주는가? 하나라도 예라면 요약 채널에 들어가면 안 된다. 이것은 모호한 판단을 확정적인 라우팅 규칙으로 바꾼다.
4. 정보는 시간의 신구가 아니라 타입에 따라 채널을 나눠야 한다 — 흔한 구현은 「최근 N턴 유지 + 그 이전은 요약」인데 이는 시간 차원의 재단이다. 3층 전략은 타입 차원의 라우팅이다. 시간 재단은 필연적으로 처음에 정해둔 금지 항목을 오폭하지만 타입 라우팅은 그러지 않는다.
5. 목표에는 버전 번호가 있어야 하며, 이것이 가장 과소평가된 항목이다 — 사용자가 중간에 요구를 바꾸면 옛 목표와 새 목표가 이력 안에 동시에 존재한다. 압축이 두 버전의 목표를 모호한 배경 한 줄로 뭉개면 Agent는 옛 계획대로 계속 달리고 오류의 귀인은 극도로 어려워진다. 목표에 버전을 붙이는 것은 「현재 유효한 제약」을 이력 속 한 문장이 아니라 덮어쓰기 가능한 단일 필드로 만드는 것과 같다.
6. 실패 경로의 가치는 성공 결과와 동등하지만, 거의 모든 소박한 압축이 그것을 버린다 — 요약은 태생적으로 「완료됨/성공함」류의 긍정적 결론을 선호하고, 부정적 기록(무엇을 시도했나, 왜 안 되나, 어떤 권한이 거부됐나)은 언어적으로는 노이즈처럼 보이지만 실행상으로는 하드 제약이다. 실패 기록을 버리면 직접적 결과는 무한 재시도 루프이며, 이것이 장시간 작업 Agent의 가장 전형적인 비용 소진 패턴이다.
7. 타임스탬프는 증거의 일부이며, 타임스탬프를 없앤 인용은 인용이 없는 것과 같다 — 「웹페이지 갱신 시각 / 외부 데이터 조회 시각 / 사용자 확인 시각」 세 항목이 전부 시간이라는 점은, 저자가 시효를 출처와 동등한 신뢰도 차원으로 본다는 뜻이다. 일시정지 후 재개하는 장시간 작업에서 요약의 존재 자체가 상태가 여전히 유효하다는 증명이 될 수 없다.
8. 이어달리기 테스트는 압축 전략의 유닛 테스트다 — 「압축된 컨텍스트를 단독으로 Agent에게 주고 이어 달리게 한다」는 것은 주관적인 「요약이 좋은가」 문제를 자동화 가능한 회귀 테스트로 바꾼다: 원본 궤적과 압축 결과가 주어졌을 때 다음 단계 선택, 금지 항목 준수, 증거 재현 세 항목을 검사한다. 이 문서에서 가장 바로 적용 가능한 항목이다.
9. 화이트리스트가 블랙리스트보다 낫다 — 「무엇을 압축하면 안 되는가」가 「무엇을 압축해야 하는가」보다 열거하기 쉽고 안전하다. 블랙리스트 하나를 놓치면 핵심 상태를 잃지만, 화이트리스트 하나를 놓치면 Token 몇 개를 더 남길 뿐이다. 안전 관련 취사선택에서 기본값은 보존 쪽으로 기울어야 한다.
10. Token 절약은 수단인데 목표로 오인된다 — 「압축의 목표는 Token 절약이 아니라 다음 턴의 Agent가 최소한이면서 충분히 신뢰할 수 있는 상태를 받게 하는 것」에서 「최소」와 「충분히 신뢰 가능」은 한 쌍의 제약이며, 신뢰 가능이 하드 제약이고 최소는 그 전제 하의 최적화 목표다. 순서를 뒤집으면 안 된다.

#엔지니어링 실전 Tips

• 실행 상태는 필드화하고 문장화하지 말 것: 「결제 성공」은 문장이고 payment_id + status + timestamp는 필드다. 전자는 모델이 복창할 수 있을 뿐이고, 후자라야 프로그램이 소비할 수 있다. OpenAI Structured Outputs를 짚은 이유가 바로 이것이다.
• 원문 그대로 보존 = 문자 단위로 동일: ID, 경로, 명령, 에러 코드 같은 문자열은 「하는 김에 정규화」하는 것이 치명적일 수 있다. 압축 파이프라인에서 화이트리스트 항목은 우회 경로를 타서 모델을 거치지 않게 해야 한다.
• 금지 항목은 별도 테이블로 독립시키고 매 턴 주입할 것: 「공개 API를 바꾸지 말 것」 같은 제약이 이력의 어느 한 턴에만 나타나면, 시간 창 기반의 어떤 재단이든 그것을 밀어내 버린다. 금지 항목을 이력에서 추출해 상주 필드로 만들 것.
• 재시도 전에 먼저 실패 테이블을 조회할 것: Agent가 어떤 방안을 실행하기로 결정하기 전에 실패 경로 기록과 대조해 명중하면 바로 스킵한다. 이것이 모델이 「실패했던 것을 기억하기」를 기대하는 것보다 훨씬 신뢰할 수 있다.
• 외부 사실에 「수집 시각 + 유효 기간」을 붙일 것: 일주일 일시정지 후 재개하는 작업은 기한을 넘긴 외부 상태에 대해 재검증을 강제해야지 요약을 그대로 쓰면 안 된다. 요약이 남아 있다고 세상이 안 변한 것은 아니다.
• 이어달리기 테스트는 「단독으로」 제공해야 한다: 테스트 시 반드시 압축된 컨텍스트만 주어야 하며, 원본 궤적을 동시에 남겨두면 무엇을 잃었는지 측정할 수 없다.
• 「이탈」의 두 가지 귀인을 구분할 것: 요약이 틀림(내용 오류)과 요약이 하드 제약을 배경으로 강등시킴(구조 오류). 후자가 주요 원인이므로 트러블슈팅 시 구조를 먼저 보고 내용을 나중에 볼 것.