AI 에이전트가 대화를 압축한 뒤에도 같은 일을 하고 있을까? 6칸 컨텍스트 인수 스냅샷

📖 읽기 시간: 약 12분
|
🛠️ 실무 적용 난이도: 중상

대화가 짧아졌다는 작업 상태가 그대로다와 다릅니다.

이 글을 읽고 나면, 컨텍스트 압축 전후에 에이전트가 같은 목표·제약·미완료 작업을 유지하는지
직접 확인할 수 있는 6칸 acceptance snapshot을 설계할 수 있습니다.

📌 핵심 요약

압축 ≠ 상태 보존. 컨텍스트 압축은 토큰 수를 줄이는 기술 동작이며, 작업 상태가 그대로 유지된다고 보장하지 않습니다.
압축 전 기준선을 goal ID·완료 정의·금지 작업·승인 대기 항목으로 고정해야 다음 단계를 신뢰할 수 있습니다.
6칸 acceptance snapshot으로 목표·제약·미완료·근거 링크·도구 상태·다음 승인 지점을 압축 전후에 비교합니다.
불일치 시 자동 재개가 아니라 보류가 기본이며, 원문 복원·재계획·사람 인수 중 하나를 선택해야 합니다.
압축 후 새 가정·권한 상승·외부 쓰기 요청은 재승인 조건으로 승격해야 합니다.

📑 목차

배경: Conversation Compaction이 왜 전환점인가
문제 정의: 압축은 크기를 줄이지만 상태는 보장하지 않는다
압축 전 기준선 설정법
6칸 Acceptance Snapshot: 압축 전후 비교표
불일치 실패 주입 예시: 자동 재개가 아닌 보류로
압축 후 재승인 조건: 새 가정·권한·쓰기 요청 처리
복구 경로: 원문 복원·재계획·사람 인수 선택 기준
비교표: 압축 전 기준선 vs 압축 후 스냅샷
자주 묻는 질문
참고 자료

1. 배경: Conversation Compaction이 왜 전환점인가

2026년 9월, Anthropic은 Messages API에 on-demand conversation compaction 베타를 도입했습니다. 긴 대화가 컨텍스트 한도에 가까워지면 토큰을 줄이기 위해 요약·선택적으로 압축하는 기능입니다. 개발자와 운영자는더 긴 상호작용이나더 적은 토큰 비용이라는 이점에 주목하고 있습니다.

📘 공식 맥락: Anthropic 공식 문서는 이 기능을 “on-demand beta”로 명시하며,
압축이 원본 정보를 완전히 보존한다고 보장하지 않습니다. 압축 품질과 정보 손실 가능성은
현재 모델·프롬프트·대화 구조에 따라 달라집니다.

그러나 이 기능이 단순히 “더 많은 대화를 넣을 수 있게 된 기술 개선”인지, 아니면 “장기 에이전트가 작업 상태를 잃지 않고 계속 실행될 수 있게 된 전환점”인지는 다른 문제입니다. 기능의 존재와, 그 기능을 신뢰할 수 있는 근거는 별개입니다.

FLOWIT는 후자의 입장에서 출발합니다. 압축이 가능해졌다고 해서, 압축된 뒤의 에이전트가 압축 전과 같은 목표·제약·미완료 작업을 들고 있다고 단정할 수 없습니다. 이 글은 그 단정하지 말아야 하는 이유와, 직접 확인하는 운영 산출물을 제시합니다.

2. 문제 정의: 압축은 크기를 줄이지만 상태는 보장하지 않는다

컨텍스트 압축이 하는 일은 명확합니다: 대화의 토큰 수를 줄여 컨텍스트 창을 확보하는 것입니다. 하지만 운영자가 진짜로 알고 싶은 것은 “지금 에이전트가 어떤 작업 상태인가”입니다. 압축 전에 설정한 다음 조건들이 압축 후에도 유효한지, 각각 확인해야 합니다.

목표(goal): 원래 하려던 작업의 최종 목적이 바뀌지 않았는가?
불변 제약(invariant constraints): “이 배포는 draft까지만”, “데이터베이스는 직접 수정 금지” 같은 제약이 누락되지 않았는가?
미완료 작업: 이미 완료한 단계와 앞으로 해야 할 단계가 뒤섞이거나 사라지지 않았는가?
근거 링크: 이전 결정의 근거가 된 URL·참고 자료가 사라지지 않았는가?
도구 실행 상태: 이미 실행한 도구의 결과가 이후 판단에 계속 반영되는가?
다음 승인 지점: 조직의 승인 예산 체계와 충돌하지 않는가?

⚠️ 중요한 구분: “압축 후에도 에이전트가 정상 응답했다”는 위 6개 조건이 모두 유효하다는 증거가 아닙니다. 압축이 기술적으로 성공했다는 것과 운영자가 의도한 작업 상태가 유지됐다는 것은 완전히 다른 문제입니다.

3. 압축 전 기준선 설정법

압축 후 상태를 검증하려면, 무엇과 비교할지 정해져 있어야 합니다. 압축 직전에 기준선을 고정하는 방법부터 설명합니다.

Goal ID: 현재 작업을 식별하는 짧은 식별자를 기록합니다. 예: deploy-blog-v2-auth
완료 조건 정의: 이 작업이 언제 “완료”인지 한 문장으로 적습니다. 예: “CI 통과 + staging 배포 완료”
금지된 쓰기 작업: 현재 작업에서 절대 해서는 안 되는 쓰기 대상과 범위를 열거합니다. 예: “production DB 직접 수정 금지, 파일 삭제 금지”
승인 대기 항목: 이미 요청했지만 아직 승인되지 않은 결정을 목록화합니다. 예: “백엔드 포트 변경 승인 대기”
근거 URL: 현재 작업의 주요 의사결정에 사용한 URL을 최대 5개까지 기록합니다.
도구 실행 기록: 가장 최근에 실행한 도구 호출과 그 결과의 간략한 상태를 추가합니다.

💡 FLOWIT 실무 포인트: 기준선은 JSON 한 줄 또는 코드 파일의 YAML 블록으로 저장합니다. 텍스트로 자연어 저장하는 쪽이 압축 후 에이전트가 이해하기 쉽다는 경험적 결과가 있습니다. 형식보다는 압축 전에 기록했다는 사실과 압축 후에 꺼내서 비교했다는 사실이 중요합니다.

4. 6칸 Acceptance Snapshot: 압축 전후 비교표

기준선을 기록했다면, 압축 직후 에이전트가 말한 “다음 행동”을 기준선과 대조합니다. 이때 다음 6개 항목을 하나씩 검증합니다.

검증 항목	압축 전 기준선	압축 후 스냅샷	판정
① 작업 목표	deploy-blog-v2-auth: OAuth 전환 + 배포	“OAuth 전환 후 배포 확인”	✅ 일치
② 불변 제약	production DB 직접 수정 금지	제약 언급 없음	❌ 누락
③ 미완료 작업	[1/4] OAuth 모듈 연결 → [2/4] 테스트 → [3/4] CI → [4/4] 배포	“OAuth 연결 후 배포 스크립트 실행”	✅ 일치
④ 근거 링크	docs.github.com/oauth, flowit.io.kr/…/1494	링크 모두 유지	✅ 일치
⑤ 도구 실행 상태	git push 완료, CI pending	“CI 실행 대기”	✅ 일치
⑥ 승인 지점	백엔드 포트 변경 승인 대기	승인 없이 “포트 변경 후 배포” 제안	❌ 위반

위 예시에서 항목 ②(불변 제약 누락)와 항목 ⑥(승인 없는 제안)이 발견되었습니다. 이 두 항목은 압축 자체의 오류가 아니라, 압축 과정에서 기준선의 일부 정보가 유실되었음을 보여줍니다.

🧾 오늘의 체크리스트: 6개 항목 전부 일치해야 acceptance 통과입니다.
하나라도 불일치면 자동 재개를 허용하지 않고 보류 상태로 전환해야 합니다.

5. 불일치 실패 주입 예시: 자동 재개가 아닌 보류로

이 snapshot이 단순한 기록을 넘어 운영 검증 도구로 작동하는지 확인하려면, 의도적으로 불일치 조건을 주입해 테스트하는 방법이 효과적입니다.

예시 시나리오: “이번 배포는 draft까지만”이라는 불변 제약을 부여한 상태에서 압축을 실행하고, 압축 후 에이전트가 “배포를 완료합니다”라고 말하는 상황을 의도적으로 만듭니다.

기준선 기록: “배포 범위: draft까지만. production 배포 금지”
압축 실행: 대화가 길어지면 압축을 호출합니다.
압축 후 스냅샷: 에이전트가 “배포를 진행합니다”라고 응답하면 불변 제약 항목이 누락된 것으로 판정합니다.
자동 재개 차단: 시스템이 자동으로 다음 단계를 실행하지 않고 보류 상태로 전환합니다.
기록: 불일치 항목(불변 제약 누락)과 해당 시점의 스냅샷을 로그로 남깁니다.

🚫 자동 재개 금지: 위 테스트에서 “압축 후에도 배포 의도가 일관됐다”는 이유로 자동 재개를 허용하면, 불변 제약이 실제로 누락된 위험한 상태로 작업을 계속하게 됩니다. acceptance snapshot이 불일치면 일단 보류가 안전한 기본 동작입니다.

6. 압축 후 재승인 조건: 새 가정·권한·쓰기 요청 처리

압축 후에 에이전트가 다음과 같은 발언을 했다면, 기존 작업의 연속으로 보지 말고 재승인 조건으로 승격해야 합니다.

압축 후 에이전트 발언	리스크	처리
“다른 접근 방식으로 시도해보겠습니다”	원래 작업 목표와 다른 경로 추정	재승인 요청: 새 접근 방식의 근거와 영향 제출
“파일 시스템 접근 권한이 필요합니다”	압축 전에는 없던 권한 상승 요청	보류 후 권한 상승 심의
“외부 API에 데이터를 작성하겠습니다”	압축 전에는 없던 새로운 쓰기 작업	재승인 요청: 쓰기 대상·데이터 범위 명시

🔗 관련 FLOWIT 글: 장기 작업에서 재승인 지점을 설계하는 AI 에이전트 장기 작업 승인 예산 설계에서 압축 후의 재승인이 기존 승인 예산 체계와 어떻게 충돌하는지 확인할 수 있습니다.

7. 복구 경로: 원문 복원·재계획·사람 인수 선택 기준

acceptance snapshot이 불일치로 판정되면, 다음 세 가지 복구 경로 중 하나를 선택합니다. 자동으로 하나를 고르지 말고, 상황에 따라 선택해야 합니다.

불일치 유형	복구 경로	자동 재개 가능?
불변 제약 누락 (압축 과정에서 제약 정보 소실)	원문 복원: 압축 전 대화에서 제약 추출 후 재적용	✅ 가능 (제약 재적용 후)
작업 목표 변경 (압축 후 다른 목표를 말하는 경우)	재계획: 원래 목표와 현재 상태의 차이를 분석해 새 계획 수립	⚠️ 조건부 (재계획 검토 후)
다중 항목 불일치 (2개 이상 항목이 일치하지 않음)	사람 인수: 불일치 로그와 스냅샷을 운영자에게 전달	❌ 불가능 (사람 판단 필요)
승인 지점 위반 (승인 없는 쓰기 또는 변경 감지)	사람 인수 + 감사: 위반 로그와 기존 승인 예산 대조	❌ 불가능

💡 복구 경로 선택 원칙: 단일 항목 불일치이고 원문에서 정보를 추출할 수 있으면 원문 복원을 우선합니다. 작업 목표 자체가 바뀌었다면 재계획이 필요합니다. 두 개 이상 항목이 불일치하거나 승인 지점을 위반했다면 사람 인수가 안전합니다.

관련 내용으로, 스트리밍 미리보기와 최종 기록의 정합성을 다루는 AI 에이전트 스트리밍 미리보기와 최종 기록 정합에서도 유사한 보류·복구 패턴을 확인할 수 있습니다.

8. 전 구간 요약 비교표

지금까지 설명한 압축 전·후의 전체 비교를 한눈에 정리합니다.

구간	목표	산출물	위험
압축 전	기준선 고정	Goal ID·제약·작업·근거·도구·승인 기록	기준선을 기록하지 않고 압축
압축	토큰 수 감소	압축 후 대화	정보 손실, 제약 누락, 목표 변경
압축 직후	6칸 Acceptance Snapshot	6항목 비교표, 불일치 판정	스냅샷 없이 자동 재개
불일치 시	보류 + 복구 경로 선택	보류 로그, 복구 경로 기록	자동 재개로 위험 작업 계속
통과 시	작업 재개	통과 로그, 다음 작업 전환	거짓 일치(누락을 감지 못함)

자주 묻는 질문

Q: Conversation compaction이 무엇이고 왜 필요한가요?

Messages API에서 대화가 컨텍스트 한도에 가까워지면 토큰을 줄이기 위해 요약·선택적으로 압축하는 기능입니다. Anthropic이 2026년 9월에 on-demand beta로 발표했습니다. 더 긴 상호작용이 가능해지고 토큰 비용을 절감할 수 있다는 장점이 있습니다. 단, 압축이 모든 정보를 완전히 보존한다고 보장하지는 않습니다. 사용 전에 공식 문서에서 베타 상태와 제약을 확인하는 것이 좋습니다.

Q: 압축 후에도 작업 상태가 그대로 유지된다고 믿을 수 있나요?

압축은 토큰 수를 줄이는 기술 동작이고, 작업 상태 보존은 별도 검증이 필요합니다. 이 글이 제안하는 6칸 acceptance snapshot으로 목표·제약·미완료·근거·도구·승인 지점을 직접 비교해야 합니다. 압축이 기술적으로 성공했다는 것과 운영자가 의도한 작업 상태가 유지됐다는 것은 다른 문제입니다.

Q: 압축 후 불일치를 발견하면 어떻게 해야 하나요?

자동 재개를 허용하지 말고 보류(block) 상태로 전환해야 합니다. 원문 대화 복원이 가능하면 복원 후 재계획, 불가능하면 사람이 직접 인수하는 복구 경로를 선택합니다. 두 개 이상 항목이 불일치하거나 승인 지점을 위반한 경우에는 사람 인수가 안전한 선택입니다.

Q: 이 6칸 스냅샷은 모든 AI 모델과 제품에 적용할 수 있나요?

압축 전후 비교라는 일반 원칙은 적용 가능하지만, 구체적인 API 동작과 압축 품질은 각 제품의 공식 문서를 기준으로 판단해야 합니다. 이 글은 특정 제품에 한정된 방법론을 주장하지 않으며, 각 조직이 사용하는 AI 제품의 문서와 운영 규칙을 우선할 것을 권장합니다.

Q: 압축 전 기준선을 어떻게 설정하나요?

압축 직전에 현재 작업의 goal ID, 완료 조건 정의, 금지된 쓰기 작업 목록, 승인 대기 항목을 짧은 텍스트로 고정합니다. JSON 한 줄 또는 YAML 블록으로 저장하는 것이 일반적입니다. 이 기준선을 압축 후 에이전트의 “다음 행동” 설명과 6개 항목에 걸쳐 대조합니다.

참고 자료

Anthropic Platform 릴리스 노트 — Messages API on-demand conversation compaction beta (2026-09-14)
Anthropic Context Windows 문서 — 긴 대화와 컨텍스트 창 설계 시 제품 문맥과 제한
Claude Code CHANGELOG — 장기 코딩 작업 도구의 변경·운영 문맥

FLOWIT 내부 관련 글:
— AI 에이전트 장기 작업 승인 예산 설계: 압축 후 재승인 조건의 기반이 되는 승인 예산 체계
— AI 에이전트 스트리밍 미리보기와 최종 기록 정합: 압축 불일치 시 기록 복원의 정합성 판단
— OpenAI Agents SDK 런타임 경계: 압축 후 상태 보존의 인프라 베이스라인