내 AI 메모리 시스템이 포착한 세 가지 실패 — 그리고 그 과정에서 드러난 시스템 자체의 결함

이것은 증거가 아닙니다. 제 개인적인 워크플로우에서 얻은 초기 단계의 무질서한 증거입니다: 세 가지 실패, 한 번의 작은 비교, 그리고 제가 놓쳤던 하나의 스키마 (schema) 버그입니다.

저는 일주일 동안 공개적으로 AI 메모리는 인프라 (infrastructure) 이전에 규율 (discipline)을 바탕으로 구축되어야 한다고 주장해 왔습니다: 수정 사항을 보존하고, 해결되지 않은 질문을 보존하며, 어떤 기록이 우선할지 결정하는 것입니다. 이 프레임워크는 세 가지 계층으로 구성됩니다: 연속성을 위한 요약 메모리 (summary memory), 반복되는 실수를 위한 수정 메모리 (correction memory), 그리고 아직 해결되지 않아야 할 질문들을 위한 미결 메모리 (unresolved memory)입니다.

좋은 이론입니다.

그러다 계획되지 않은 3일간의 실패가 제 허락도 없이 모든 주장을 시험했고, 이후 하나의 댓글이 저로 하여금 이를 더 주의 깊게 테스트하도록 강제했습니다.

무엇이 유지되었는지, 수치가 실제로 무엇을 말해주는지, 그리고 제가 예상치 못했던 결함은 무엇인지 소개합니다.

파트 1 — 우연한 스트레스 테스트 (stress test)

이것들은 극적인 이야기가 아닙니다. 장기간 실행되는 에이전트 (agent) 설정이 결국 맞닥뜨리게 되는 지루한 실패 모드 (failure modes)들입니다. 그것이 핵심입니다.

세션이 두 번 종료되었습니다. 빌드 도중, 기기가 이틀 사이에 두 번이나 다운되었습니다. 실시간의 문맥 이해 (in-context understanding)가 즉시 사라졌습니다: 그날의 결정, 현재 상태, 스레드 (thread) 등 말입니다. 하지만 아무것도 잃어버리지 않았습니다. 왜냐하면 그 어떤 것도 세션에만 존재하지 않았기 때문입니다. 그것들은 디스크 (disk)에 미러링되어 저장되어 있었습니다. 이 실패 모드는 보편적입니다 — 충돌 (crashes), 타임아웃 (timeouts), 그리고 컨텍스트 제한 (context limits)은 예외적인 상황이 아니라 보장된 상황입니다. 여기서 얻은 교훈은 시스템 전체가 기반하고 있는 원칙입니다: 메모리는 당신이 기록하는 정도만큼만 지속된다. 연결은 끊겼지만, 기록은 유지되었습니다.

에이전트가 자신 있게 틀린 답을 내놓았습니다. 충돌 이후, 제 에이전트 중 하나가 재시작되었는데, 이틀 전의 오래된 상태에 다시 고정(re-anchored)된 채로 그것을 현재 상태라고 보고했습니다 — 아주 확신에 차서 말이죠. 그것은 거짓말을 한 것이 아닙니다. 그것은 더 이상 존재하지 않는 세상에 대해 _확신_하고 있었을 뿐입니다. 이것은 망각보다 더 나쁜, 조용한 살인자입니다: 오래된 상태로 복구되어 그것을 확정된 사실로 서술하는 에이전트 말입니다. 이것이 포착될 수 있었던 이유는 실제 상태가 비교를 위해 기록되어 있었기 때문입니다. 진실이 디스크에 있었기에 드리프트 (drift) 현상이 눈에 보일 수 있었습니다.

잘못된 버전이 거의 배포될 뻔했습니다. 동일한 문서의 두 가지 "최종 (final)" 버전이 존재했고, 그중 더 약한 버전이 배포될 위기에 처했습니다. 증거가 주장과 일치하지 않았기에 발견될 수 있었습니다. 즉, 백업 파일이 더 컸고 "최종" 버전에서 누락된 섹션들을 포함하고 있었습니다. 두 파일 모두 _final_이라고 명시되어 있었지만, 오직 하나만이 이를 증명할 수 있었습니다. 여기서 얻은 교훈은 다음과 같습니다: 메모리는 에이전트가 알고 있다고 주장하는 것이 아니라, 기록이 여전히 증명할 수 있는 것입니다. 충돌이 발생한 후가 아니라, 충돌이 발생하기 _전_에 어떤 기록이 우선하는지에 대한 규칙이 필요합니다.

세 가지 실패, 그리고 이를 잡아낸 시스템의 세 가지 계층. 이는 실제 상황이었지만, 그것이 어떤 종류의 증거인지에 대해서는 솔직해질 필요가 있습니다. 이는 개발자가 직접 겪으며 얻은 경험적 증거입니다. 시스템이 저의 복구를 도왔다는 것을 보여줄 뿐, 무언가를 측정 (measure) 하는 것은 아닙니다.

전환점 (The turn)

한 독자가 이러한 종류의 작업을 실제로 변화시키는 단 하나의 질문을 담은 댓글을 남겼습니다:

비교할 수 있는 기준점 (baseline)이 있습니까?

그것은 올바른 질문이었고, 저에게는 제대로 된 답변이 없었습니다. 현장의 이야기는 생존을 보여줄 뿐, 이 방식이 모든 것을 단순히 요약하는 명백한 대안보다 낫다는 것을 보여주지는 않습니다. 그래서 저는 테스트를 구축했습니다.

파트 2 — 의도적인 테스트

저는 작은 A/B 비교를 설정했습니다:

• 시스템 A — 요약 전용 메모리 (summary-only memory): 깔끔한 프로젝트 요약, 최근 결정 사항, 선호도, 현재 방향성. 수정 이력, 불확실성, 진실의 근거 (source-of-truth) 규칙 없음.
• 시스템 B — 계층형 메모리 (layered memory): 요약 플러스 수정 메모리, 미결 질문, 진실의 근거 (source-of-truth) 규칙, 검증 트리거 (verification triggers), 그리고 인식론적 상태 (epistemic status).

측정 지표는 의도적으로 좁게 설정했습니다: 컨텍스트 리셋 (context reset) 이후의 거짓 확신 오류 (false-certainty errors). 거짓 확신 오류란, 기록상으로는 오래되었거나 (stale), 논쟁 중이거나 (contested), 미결 상태이거나 (unresolved), 검증되지 않았거나 (unverified), 또는 실시간 확인이 필요한 상태임에도 불구하고 에이전트가 이를 확정된 것으로 취급할 때 발생합니다.

이것은 "텍스트가 더 많을수록 더 나은가"를 테스트하는 것이 아니었습니다. 인식론적 상태(epistemic status) — 오래됨 (stale), 미결 (unresolved), 검증됨 (verified), 논쟁 중 (contested), 우선순위 (priority), 상태 (status) — 를 보존하는 메모리가 리셋 이후의 거짓 확신을 줄여주는지를 테스트하는 것이었습니다.

방법론 스냅샷:

• 6개의 리셋/복구 (reset/recovery) 시나리오
• 1개의 로컬 모델 (local model): llama3.2:latest
• 두 시스템 모두에 동일한 작업 프롬프트 (task prompt) 사용
• 메모리 패킷 (memory packets)만 다르게 구성
• 미리 정의된 기대 동작 (expected behavior)에 따라 수동 채점
• 작업 성공 (task success), 인식론적 처리 (epistemic handling), 거짓 확신 오류 (false-certainty errors)를 기준으로 채점
• 벤치마크 수준은 아니며, 아직 외부 블라인드 채점 (blind-scored)을 거치지 않음

테스트의 첫 번째 버전은 유혹적인 수치를 보여주었습니다. 하지만 방법론을 감사(audit)한 결과 두 가지 문제를 발견했습니다. 몇몇 요약 베이스라인 (summary baselines)은 실패하기에 너무 쉬웠고, 블라인드 패킷 (blind packet)이 구조적 정보를 너무 많이 유출하고 있었습니다. 그래서 베이스라인을 수정하고, 패킷을 재생성하고, 로컬 모델을 다시 실행한 뒤, 점수를 작업 성공 (task success), 인식론적 처리 (epistemic handling), 거짓 확신 (false certainty)의 세 부분으로 나누었습니다.

수정된 1차 통과 결과는 다음과 같습니다:

• 작업 성공 (Task success): 요약 전용 (summary-only) 1/6, 계층형 메모리 (layered memory) 6/6
• 인식론적 처리 (Epistemic handling): 요약 전용 (summary-only) 4/12, 계층형 메모리 (layered memory) 12/12
• 거짓 확신 오류 (False-certainty errors): 요약 전용 (summary-only) 2, 계층형 메모리 (layered memory) 0

이 수치들은 의심스러울 정도로 깔끔합니다. 이 수치들이 깔끔한 이유는 시나리오들이 제 작업 흐름 (workflow)에서 발생한 알려진 실패 사례들, 즉 이 프레임워크가 처리하도록 설계된 바로 그 환경에서 가져온 것이기 때문입니다. 더 공정한 테스트라면 다른 사람이 작성한 시나리오, 여러 모델, 여러 번의 실행, 그리고 외부 블라인드 채점 (external blind scoring)을 사용해야 할 것입니다.

이제 솔직해지겠습니다. 이런 종류의 작업들이 보통 속임수를 쓰는 지점이 바로 여기이기 때문입니다: 이것은 최초의, 작고, 로컬 모델을 사용한 A/B 테스트입니다. 즉, 벤치마크가 아니라 초기 신호 (early signal)입니다. 6개의 시나리오. 하나의 로컬 모델. 한 번의 실행. 내부 채점. 시나리오는 제 자신의 작업 흐름에서 가져왔습니다. 저는 이것을 검증되었다고 말하지 않을 것입니다. 올바른 프레임워크는 다음과 같습니다: 초기 신호가 방향성을 뒷받침하며, 이제 이를 더 정직하게 테스트할 수 있는 방법이 마련되었다는 것입니다.

채점 형태의 압축된 예시는 다음과 같습니다:

시나리오	기대되는 동작 (Expected behavior)	요약 전용 동작 (Summary-only behavior)	계층형 동작 (Layered behavior)
잘못된 "최종" 버전	이전의 정식 버전처럼 보이는 파일이 아닌, 현재의 전송 파일을 사용해야 함	일반적인 패키징 프로세스를 임의로 만들어냈으며 현재 파일을 식별하지 못함	현재 전송 버전을 식별하고 교정(copyedit) 전용 경계를 보존함
...

파트 3 — 예상치 못했던 부분

테스트는 단순히 프레임워크를 뒷받침하는 데 그치지 않았습니다. 그것은 프레임워크를 교정했습니다.

계층형 시스템(layered system)의 첫 번째 버전은 여전히 한 가지 시나리오에서 실패했습니다. 시스템은 한 기사가 준비됨(ready) 상태로 표시되었다는 것을 알고 있었습니다. 또한 다른 기사가 다음에 작성되어야 할 대상이라는 것도 알고 있었습니다. 하지만 시스템은 잘못된 선택을 했습니다.

저는 제가 직접 설계했기 때문에 이 메모리 시스템을 신뢰하지 않습니다. 오히려 저는 이 시스템을 더 신뢰합니다. 왜냐하면 세 번의 실패가 닥쳤음에도 불구하고 기록(record)이 저로 하여금 복구하고, 비교하고, 수정할 수 있게 해주었기 때문입니다. 그리고 마침내 측정을 수행했을 때, 테스트 결과는 프레임워크(framework)가 여전히 개선이 필요한 지점이 어디인지를 명확히 보여주었습니다.

그것이 제가 중요하게 생각하는 기준입니다. 메모리 시스템이 컨디션이 좋을 때 얼마나 많이 기억하느냐가 아닙니다. 상황이 좋지 않을 때도 무엇이 실제인지 여전히 증명할 수 있는지, 그리고 어디가 틀렸을 수 있는지 여전히 알려줄 수 있는지의 여부입니다.

다음 버전의 테스트는 저 혼자만의 힘으로 이루어져서는 안 됩니다. 더 많은 시나리오, 다수의 모델, 반복된 실행, 그리고 최소한 하나 이상의 외부 블라인드 스코어러(blind scorer)를 활용해야 합니다. 만약 이 프레임워크가 오직 저의 실패에서만 작동한다면, 그것 또한 알아두어야 할 유용한 사실입니다. 하지만 만약 타인의 시나리오에서도 여전히 유효하다면, 그 증거는 더욱 흥미로워질 것입니다.

이 글은 AI 메모리를 판단 인프라(judgment infrastructure)로 다루는 짧은 시리즈의 일부입니다: 제로 예산 기반의 토대, 왜 수정 메모리 (correction memory)가 복리로 작용하는지, 그리고 왜 시스템이 성급한 종결을 강요하는 대신 미결 상태인 것을 보존 (preserve what's unresolved)해야 하는지에 대해 다룹니다.