컨텍스트 창 절단 때문에 사실이 빠졌는지 확인하는 법

그림. 화면에 보이는 기록과 실제 모델 입력에 남은 사실은 다를 수 있습니다.

reader_decision: 에이전트가 기억하지 못한 원인을 답변의 말투로 추측하지 않고, 실제 모델 입력에 sentinel이 있었는지·잘렸는지·요약에서 보존됐는지를 먼저 확인합니다.

핵심 구분
화면의 대화 기록, 세션에 남은 파일, 실제 모델 호출에 들어간 context는 서로 다를 수 있습니다. “스크롤하면 보인다”는 사실만으로 모델이 그 내용을 현재 입력에서 보고 있다고 결론내리지 않습니다.

방금 말한 파일을 다시 물어본 이유

긴 에이전트 작업에서 금지한 파일 규칙이 화면 기록에는 남아 있는데, 모델이 나중에 그 파일을 수정하는 장면을 본 적이 있습니다. 또 대화가 약 30턴을 넘긴 뒤에는 파일명이 여전히 채팅 화면에 보이는데도 모델이 다시 파일명을 물었습니다. 이때 “기억력이 나빠졌다”고 말하면 원인을 놓칩니다. 오래된 대화가 잘려 나갔는지, 요약 과정에서 규칙이 빠졌는지, 새 호출에 핵심 파일이 다시 붙지 않았는지를 나눠 봐야 합니다.

컨텍스트 창은 기억이 아니라 작업대입니다

컨텍스트에는 현재 작업에 필요한 자료를 올릴 수 있지만 무한히 유지할 수는 없습니다. 모든 로그와 문서를 넣으면 관련 없는 정보가 같은 무게를 갖고, 정작 금지 범위·완료 조건·현재 상태가 흐려집니다. Anthropic의 context engineering 안내도 에이전트가 사용할 정보를 작업에 맞게 구성하고, 필요한 정보만 단계적으로 제공하는 관점을 설명합니다.

sentinel을 넣어 입력 손실을 분리합니다

실제 모델의 품질을 주장하기 전에, 입력 구성 단계부터 작은 재현 fixture를 둡니다. 여덟 개 기록 중 세 번째에만 SENTINEL-ALPHA를 넣고, 전체 입력·뒤에서 다섯 개만 남긴 입력·짝수 위치 기록만 보존한 압축 입력을 비교합니다. 이 fixture의 목적은 “모델이 똑똑한가”가 아니라 sentinel이 현재 입력에 존재하는지를 확인하는 것입니다.

records = [
  {id: "r01", text: "ordinary"},
  {id: "r02", text: "ordinary"},
  {id: "r03", text: "SENTINEL-ALPHA"},
  {id: "r04", text: "ordinary"},
  {id: "r05", text: "ordinary"},
  {id: "r06", text: "ordinary"},
  {id: "r07", text: "ordinary"},
  {id: "r08", text: "ordinary"}
]

full = records
tail_truncated = records[-5:]
compressed = records[0::2]
contains = lambda xs: any(r["text"] == "SENTINEL-ALPHA" for r in xs)

입력 구성	입력 기록 수	sentinel 존재	읽을 수 있는 결론
전체	8	예	입력 구성 단계에서는 보존
뒤에서 5개만	5	아니오	잘린 입력에는 원문이 없음
짝수 위치만 압축	4	예	이 압축 규칙에서는 보존
모델 답변만 확인	-	알 수 없음	답변만으로 입력 존재를 증명할 수 없음

이 결과에서 tail truncated가 틀린 이유는 모델의 추론 실패가 아니라 입력에 sentinel이 없기 때문입니다. 반대로 compressed에서는 sentinel이 남아 있으므로, 답변이 틀렸다면 그 다음으로 프롬프트 구성·해석·생성 변동성을 조사할 수 있습니다. 원인 후보의 순서를 바꾸는 것만으로도 디버깅 시간이 줄어듭니다.

무엇을 context 밖에 고정할까

• 금지 규칙과 완료 조건은 대화에만 두지 말고 짧은 SSOT·runbook·manifest에 둡니다.
• 현재 상태는 “새 글 10개, 제외 1개, 남은 90개”처럼 짧은 snapshot으로 다시 제공합니다.
• 새 모델 호출마다 목표·금지 범위·산출물·검증 명령을 작은 계약으로 붙입니다.
• context를 압축할 때 원문을 모두 보존한다고 가정하지 말고, 핵심 사실의 sentinel과 checksum을 별도 검사합니다.
• 외부 memory에 저장한 사실은 Q08의 save→search→answer 검증과 분리합니다. context에 들어갔다는 것과 영속 저장됐다는 것은 다른 사건입니다.

실패를 세 종류로 이름 붙입니다

관측	가능한 원인	확인 방법
sentinel이 입력에 없음	truncation 또는 잘못된 window	실제 model request payload를 readback
sentinel은 입력에 있음, 답변에 없음	프롬프트 해석·주의력·생성 변동성	동일 입력 반복과 직접 추출 질문
요약에만 없음	compression 규칙이 중요 사실을 삭제	요약 전후 핵심 사실 비교
화면에는 있음	UI 기록과 실제 호출이 다름	request log와 provider payload 비교

결론

컨텍스트 창을 기억으로 착각하면 모든 실패를 “AI가 잊었다”로 뭉뚱그리게 됩니다. 먼저 실제 입력에 sentinel이 있었는지 확인하고, 그 뒤에 truncation·compression·해석·생성 변동성을 순서대로 나눕니다. 오래가는 작업은 대화의 양으로 버티지 말고, 안정적인 규칙은 문서에 고정하고 현재 상태는 짧은 snapshot으로 다시 넣는 편이 안전합니다.

참고한 자료

• Anthropic, Effective context engineering for AI agents
• DataCook, 완료라고 했을 때 확인하는 증거