컨텍스트 요약은 틀리지 않았는데 왜 실행할수록 이탈하는가
요약이 틀리지 않았다는 것이 제약이 남아 있다는 뜻은 아니다. Agent가 매 턴 컨텍스트를 압축할 때 작업 목표, 제약 조건, 이상 표기가 디테일보다 먼저 버려지고, 그래서 모델이 실행 후반부에 최초의 방향을 잊는다.
요약이 정확함 ≠ 제약이 보존됨
1층: 제약 계층화 (하드 제약 vs 소프트 제약)
시스템 지시를 두 종류로 쪼갠다. 하드 제약은 매 턴 반드시 써야 하며 요약에 맡겨 압축하면 안 된다.
| 하드 제약 (Hard Constraints) | 소프트 제약 (Soft Constraints) |
|---|
| 내용 | 권한(Permissions), 포맷(Format), 금지 조작(Ban List), 출력 규범(Output Spec) | 어조, 예시, 보조 설명 |
| 압축 전략 | 압축 엄금, 매 턴 반드시 휴대 | 압축 가능 |
2층: 목표 앵커
방안: 매 턴 요약 말미에 고정 포맷의 목표 앵커를 한 줄 추가한다.
역할: 그것은 한 번의 정답처럼 보이는 답변을 반복 가능하고 책임 추궁 가능한 프로세스로 바꾼다.
원칙: 차라리 검증을 한 단계 더 할지언정, 모델이 감으로 계속 실행하게 두지 말 것.
고위험 장면 관리 시 검증을 한 단계 강제할 것: 계약 · 자금 · 외부 발송 · 삭제 · 권한
3층·4층: 제약 검증과 롤백 감사
제약 검증 — 정상 경로가 안정적으로 돌아가게
롤백과 감사 — 이상 경로를 수습 가능하게
정리
제약 계층화, 목표 앵커, 제약 검증, 롤백 감사 4층: 먼저 하드 제약이 요약을 따라 감쇠하지 않도록 보장하고, 그다음 앵커와 검증으로 폴백 교정을 하며, 마지막으로 평가, 모니터링, 재생으로 안정성을 증명한다.
핵심 통찰
- 요약이 정확함 ≠ 제약이 보존됨 — 요약의 평가 지표는 「정보가 왜곡되었는가」인데, 공학이 진짜로 필요로 하는 것은 「제약이 살아남았는가」다. 이 두 지표는 압축 장면에서 거의 상관이 없으며, 전자로 후자를 검수하는 것이 이 문제의 근본적 오류다.
- 컨텍스트 압축의 폐기 순서는 반직관적이다 — 압축되는 것은 장황한 디테일이 아니라 작업 목표, 제약 조건, 이상 표기처럼 짧으면서 배경처럼 보이는 줄들이다. 중요할수록, 「한 번 말하고 다시는 반복되지 않을수록」 요약기는 그것을 이미 소화된 것으로 판정하기 쉽다.
- 짧고 정적이며 반복 등장하지 않는 정보가 긴 링크에서 가장 취약하다 — 하드 제약은 보통 0턴에서 한 번만 말해지고, 이후 모든 턴의 요약이 그것을 희석한다. 신뢰성은 재진술 빈도에서 오지 최초의 강조 강도에서 오지 않는다.
- 제약을 계층화해야 하는 이유는 압축 전략을 계층화해야 하기 때문이다 — 「권한/포맷/금지 조작/출력 규범」과 「어조/예시/보조 설명」을 하나의 system prompt에 섞는 것은, 요약기가 당신 대신 우선순위를 결정하게 하는 것과 같다. 계층화의 본질은 우선순위 결정권을 모델의 손에서 시스템으로 회수하는 것이다.
- 앵커는 망각에 대항하는 최소 메커니즘이다 — system prompt 전체를 다시 보낼 필요 없이 고정 포맷의 「현재 작업 + 이번 턴 금지 조작」 한 줄이면 되고, 이것은 압축에 참여하지 않는다. 대가는 매 턴 수십 토큰이고, 이득은 「정답처럼 보이는 답변」을 반복 가능하고 책임 추궁 가능한 프로세스로 바꾸는 것이다.
- 「정상 경로가 안정적으로 돌아가는 것」과 「이상 경로를 수습하는 것」은 서로 다른 두 메커니즘이다 — 전자는 제약 검증(사전/실행 중)에 의존하고 후자는 롤백 감사(사후)에 의존한다. 전자만 하는 시스템은 시연에서는 완벽하지만 상용에서 처음 경계를 넘는 순간 퇴로가 없다.
- 검증기가 대모델일 필요는 없다 — 「규칙이나 소형 모델로 제약 컴플라이언스 검사를 한 번 하라」고 명확히 말한다. 하드 제약은 대부분 판정 가능하므로(API 서명을 바꿨는지, 금지된 도구를 호출했는지), 규칙 판정이 저렴하고 확실하며 확률 모델에 다시 넘길 일이 아니다.
- 고위험 동작은 신뢰도가 아니라 카테고리별로 추가 검증을 발동해야 한다 — 계약, 자금, 외부 발송, 삭제, 권한 이 다섯 종류는 모델이 얼마나 확신하는지와 무관하게 일률적으로 검증을 한 단계 더 강제한다. 「감으로 계속 실행하기」를 제도적으로 꺼버리는 것이 모델의 판단력을 높이는 것보다 통제 가능하다.
엔지니어링 실전 Tips
- 하드 제약은 프롬프트 속 「반드시 준수해 주세요」 한 줄이 아니라 압축 함수의 화이트리스트로 만들 것: 압축 단계가 코드로 통제되기만 하면 하드 제약의 생존은 더 이상 모델의 자각에 의존하지 않는다.
- 앵커는 자연어가 아니라 고정 포맷으로:
【현재 작업】 / 【이번 턴 금지 조작】 같은 템플릿은 모델이 위치를 찾기 쉽고 검증기가 정규식으로 바로 추출·대조하기도 편하다.
- 검증기와 실행기는 같은 모델 인스턴스를 쓰지 말 것: 실행 링크에서 이미 제약을 잃은 컨텍스트로 자가 검사하게 하는 것은 결손된 기억으로 자기 답안을 채점하는 것과 같다. 검증은 원본 HARD 블록을 기준으로 독립적으로 수행해야 한다.
- 롤백에는 「앵커 재주입」을 동반할 것: 단순 재실행은 같은 압축 함정에 다시 빠진다. 동작은 「롤백 발동 + 앵커 재주입 후 실행」 두 단계이며 하나도 빠지면 안 된다.
- 외부 상태 변경 4종 세트: 권한 / 멱등 / 확인 / 감사. 멱등이 특히 중요하다 — 롤백 재시도 메커니즘이 있는 시스템에는 반드시 같은 동작이 두 번 실행되는 순간이 온다.
- 평가셋은 사고가 먹여 키운다: 모든 수정 건을 회귀 평가에 넣어야 경계 샘플셋이 상용 문제와 함께 자란다. 그렇지 않으면 부하 테스트 샘플이 영원히 상용 첫날의 상상력에 머문다.
- 답변 순서: 문제의 본질 → 아키텍처 설계 → 예외 처리(어떻게 멈추나 / 어떻게 조사하나 / 어떻게 보완하나) → 가점 요소(증거 / 권한·멱등·확인·감사 / 회귀 평가). 이 순서 자체가 상용 시스템을 다뤄봤음을 증명한다.