외부 메모리에 저장한 사실이 실제 답변에 쓰였는지 확인하는 법

그림. memory는 저장 성공·검색 성공·답변 반영 성공을 따로 확인해야 합니다.

reader_decision: 외부 memory를 쓸 때 저장 성공·검색 성공·답변 반영 성공을 세 개의 독립된 사건으로 기록하고, 어느 단계가 실패했는지 확인한 뒤 다음 작업을 진행합니다.

저장됐다는 로그는 답이 아닙니다
write가 성공했다는 메시지는 backend에 레코드가 실제로 남았다는 증명이 아닙니다. 검색 결과가 나왔다는 사실도 모델이 그 결과를 답변에 사용했다는 증명은 아닙니다. 세 단계를 분리해서 readback합니다.

4.3만 건인데 시간축은 거의 비어 있었습니다

영속 memory 상태를 점검했을 때 항목은 약 4.3만 건, embedding coverage는 100%로 보였습니다. 그런데 timeline 항목은 2개, time coverage와 link coverage는 0.0%였습니다. 내용 벡터가 채워져 있다는 것과 언제 어떤 사건이 이어졌는지를 검색할 수 있다는 것은 별개의 건강 지표였습니다.

보강 작업의 dry-run은 추가 이벤트를 화면에 보여 줬지만 저장 개수는 14에서 14로 그대로였습니다. 실제 전체 실행도 정상 종료했고 약 4.3만 건을 처리했다고 표시했지만 새 link는 0건이었습니다. 그 뒤에도 약 1.3만 건이 오래된 상태로 남았습니다. 처리한 건수와 새로 만든 산출물을 분리하지 않았다면 성공으로 읽기 쉬운 결과였습니다.

memory는 세 번 확인해야 합니다

단계	검증 질문	통과 증거
save	write가 실제 저장소에 레코드를 남겼나?	저장 전후 count·id·content readback
search	검색 질의가 그 레코드를 찾아왔나?	결과 id·내용·score·timestamp
answer use	답변이 검색 결과를 실제로 사용했나?	답변의 인용 id 또는 sentinel 일치

이 세 단계 중 하나라도 결과를 직접 읽어오지 않으면 “memory가 작동한다”는 문장을 닫을 수 없습니다. 특히 embedding coverage나 전체 item count는 저장소의 양을 보여 줄 뿐, 시간·링크·신선도·답변 사용을 보장하지 않습니다.

작은 sentinel fixture로 계약을 고정합니다

외부 backend에 바로 대규모 보강을 걸기 전에 작은 키와 고유한 값을 씁니다. 예를 들어 profile:demo에 MEMORY-SENTINEL-42를 저장한 뒤, 같은 키를 조회하고 답변에 그 값을 그대로 요구합니다. 검색 query mismatch, write no-op, 답변의 임의 생성은 서로 다른 실패입니다.

key = "profile:demo"
sentinel = "MEMORY-SENTINEL-42"

store[key] = sentinel
write_ok = store.get(key) == sentinel
retrieved = search(key)
search_ok = retrieved == sentinel
answer = answer_from(retrieved)
answer_ok = sentinel in answer

fixture	save readback	search readback	answer use	판정
pass	성공	성공	성공	PASS
write-drop	실패	실패	실패	저장 단계에서 중단
query-mismatch	성공	실패	실패	검색 조건 확인
answer-mismatch	성공	성공	실패	답변 조립 확인

검색 결과가 많아도 기억이 좋아지는 것은 아닙니다

또 다른 학습 로그에서는 일주일에 486개 항목이 쌓였고 약 80%가 잡음으로 평가되었습니다. 로그가 6,799줄까지 커진 뒤 3,218줄, 955줄로 줄였지만, 줄 수를 줄였다는 사실만으로 검색 품질이 좋아졌다고 말할 수는 없습니다. 오래된 threshold 0.8을 현재 기준 0.6 대신 답변에 사용한 사례처럼, 낡은 기억은 많이 주입할수록 더 그럴듯한 오류가 됩니다.

운영 규칙

• 한 번의 write 응답을 성공으로 카운트하지 말고 저장소 readback을 통과시킵니다.
• 검색 결과에는 id·내용·시점·원문 링크 같은 provenance를 붙입니다.
• 답변은 검색 결과의 id를 인용하거나 sentinel을 재현하게 해 실제 사용을 확인합니다.
• 오래된 memory와 최신 규칙이 충돌하면 최신 SSOT를 우선하고, memory를 자동으로 덮어쓰지 않습니다.
• dry-run의 예상 추가 수, 실제 저장 수, 검색 가능한 수, 답변에서 사용된 수를 각각 기록합니다.

결론

memory의 건강성은 저장량이나 embedding coverage 한 줄로 판단하지 않습니다. 저장 전후 count와 레코드, 검색 결과, 답변의 사용 흔적을 분리해서 확인해야 합니다. 4.3만 건이 있어도 timeline과 link가 비어 있을 수 있고, 화면에 추가 이벤트가 많아도 실제 저장은 0건일 수 있습니다. 작은 sentinel fixture를 먼저 통과시키면 대규모 보강을 성공으로 착각할 가능성이 크게 줄어듭니다.

참고한 자료

• DataCook, 완료 보고에서 증거를 분리하는 방법
• Anthropic, context engineering과 정보 선택