내 AI 메모리 시스템이 포착한 세 가지 실패 — 그리고 그 자체가 드러낸 결함
Source: Dev.to
이것은 증명이 아닙니다. 제 작업 흐름에서 얻은 초기의, 다소 엉성한 증거이며, 세 번의 실패, 작은 비교 하나, 그리고 제가 놓친 스키마 버그 하나를 포함합니다.
저는 일주일 동안 공개적으로 AI 메모리는 인프라보다 규율에 기반해야 한다고 주장했습니다: 수정 사항을 보존하고, 해결되지 않은 질문을 보존하며, 어떤 기록이 우선할지 결정한다. 이 프레임워크는 세 층으로 구성됩니다:
- Summary memory – 연속성을 위해
- Correction memory – 반복되는 실수를 위해
- Unresolved memory – 아직 해결되지 않아야 할 질문을 위해
좋은 이론이었습니다.
그런데 계획에 없던 3일간의 실패가 제 허가 없이 모든 주장을 시험했으며, 한 댓글이 저에게 더 신중히 테스트해 보라고 강요했습니다.
아래는 실제로 유지된 내용, 숫자가 실제로 보여준 것, 그리고 제가 미처 예상하지 못한 결함입니다.
Source: …
Part 1 — 우연한 스트레스 테스트
이것들은 드라마틱한 이야기가 아니다. 장기간 운영되는 에이전트 설정이 결국 마주하게 되는 지루한 실패 모드들이다. 그것이 요점이다.
1. 세션이 죽었다. 두 번.
빌드 도중, 머신이 다운되었다 — 이틀 안에 두 번. 모든 실시간, 컨텍스트 내 이해가 즉시 사라졌다: 그날의 결정, 현재 상태, 스레드. 이 중 어느 것도 세션에만 존재했기 때문에 사라진 것이 아니다. 디스크에 저장돼 있었고, 복제돼 있었다.
이 실패 모드는 보편적이다 — 충돌, 타임아웃, 컨텍스트 제한은 예외 상황이 아니라 보장된 상황이다. 여기서 얻는 교훈은 전체 시스템이 의존하는 핵심이다:
메모리는 당신이 적어 놓은 정도만큼만 지속된다.
전선은 끊어졌지만, 기록은 남았다.
2. 에이전트가 자신 있게 틀린 답을 반환했다.
충돌 이후, 한 에이전트가 재시작하면서 약 이틀 전의 상태에 다시 고정됐고, 이를 현재라고 보고했다 — 완전한 자신감과 함께. 거짓말을 한 것이 아니다. 존재하지 않는 세계에 대해 확신하고 있었을 뿐이다.
이것이 조용히 치명적인 문제이며, 잊어버리는 것보다 더 위험하다: 에이전트가 오래된 상태로 복구된 뒤 이를 확정된 사실로 서술하는 경우다. 실제 상태가 디스크에 기록돼 비교할 수 있었기 때문에 발견되었다. 드리프트가 눈에 보인 이유는 진실이 디스크에 있었기 때문이다.
3. 잘못된 버전이 거의 배포될 뻔했다.
같은 문서의 두 “최종” 버전이 존재했으며, 약한 쪽이 곧 배포될 상황이었다. 증거가 주장과 일치하지 않아 잡혔다 — 백업 파일이 더 크고 “최종” 파일에 없는 섹션을 포함하고 있었다.
두 파일 모두 final이라고 표시했지만, 증명할 수 있는 것은 하나뿐이었다. 교훈은 다음과 같다:
메모리는 에이전트가 주장하는 지식이 아니라, 기록이 아직 증명할 수 있는 것이다.
충돌이 발생하기 전에 어떤 기록이 우선할지 규칙을 정해야 한다, 충돌 후가 아니라.
세 가지 실패, 세 층의 시스템이 이를 포착했다. 실제 사례이지만, 어떤 종류의 증명인지 솔직히 말하자면, 이는 빌더가 직접 겪은 것이다. 시스템이 복구를 도와줬다는 것을 보여주지만, 그것이 측정된 것은 아니다.
전환
독자가 다음과 같은 한 가지 질문을 남겼습니다. 이 질문이 바로 이런 작업을 바꾸는 질문입니다:
비교할 기준이 있나요?
그것이 바로 올바른 질문이며, 저는 실제 답을 가지고 있지 않았습니다. 현장 이야기는 생존을 보여줄 뿐, 그 분야가 명백한 대안—모두를 단순히 요약하는 것—보다 뛰어나다는 것을 보여주지는 못합니다. 그래서 저는 테스트를 만들었습니다.
Part 2 — 의도적 테스트
작은 A/B 비교를 설정했습니다:
| 시스템 | 메모리 구성 |
|---|---|
| A – 요약‑전용 | 정리된 프로젝트 요약, 최근 결정, 선호도, 현재 방향. 수정 이력, 불확실성, 진실‑소스 규칙 없음. |
| B – 계층형 메모리 | 요약 플러스 수정 메모리, 미해결 질문, 진실‑소스 규칙, 검증 트리거, 그리고 인식론적 상태. |
측정 지표는 의도적으로 좁게 잡았습니다: 컨텍스트 리셋 후의 확신‑오류.
확신‑오류란 기록에 오래되었거나, 논쟁 중이거나, 미해결, 검증되지 않았거나, 실시간 확인에 의존한다는 내용이 있음에도 에이전트가 이를 확정된 것으로 취급하는 경우를 말합니다.
방법 개요
- 6개의 리셋/복구 시나리오
- 로컬 모델:
llama3.2:latest - 두 시스템 모두 동일한 작업 프롬프트 사용, 메모리 패킷만 다름
- 사전 정의된 기대 행동에 대해 수동 채점
- 작업 성공, 인식론적 처리, 확신‑오류를 기준으로 점수 부여
- 아직 벤치마크 수준이 아니며 외부 블라인드 채점도 진행되지 않음
첫 번째 버전 테스트에서는 매력적인 수치를 얻었습니다. 그러나 방법을 감사하면서 두 가지 문제를 발견했습니다:
- 몇몇 요약 기준이 너무 쉽게 실패하도록 설정돼 있었습니다.
- 블라인드 패킷이 구조적 정보를 과도하게 누출했습니다.
기준을 수정하고 패킷을 재생성한 뒤 로컬 모델을 다시 실행했으며, 점수를 작업 성공, 인식론적 처리, 확신‑오류 세 부분으로 나누었습니다.
수정된 1차 결과
| 지표 | 요약‑전용 | 계층형 메모리 |
|---|---|---|
| 작업 성공 | 1 / 6 | 6 / 6 |
| 인식론적 처리 | 4 / 12 | 12 / 12 |
| 확신‑오류 | 2 | 0 |
이 숫자는 의심스러울 정도로 깔끔합니다. 시나리오가 내가 직접 겪은 워크플로우의 알려진 실패 사례에서 나왔기 때문인데, 바로 그 환경을 다루기 위해 프레임워크가 만들어졌습니다. 보다 공정한 테스트라면 다른 사람이 작성한 시나리오, 여러 모델, 다중 실행, 외부 블라인드 채점을 포함해야 합니다.
이제 정직하게 말하자면, 보통 이런 부분에서 부정행위가 일어나기 때문입니다:
이것은 첫 번째, 작은 로컬‑모델 A/B 테스트 — 초기 신호일 뿐, 벤치마크가 아닙니다.
여섯 개 시나리오. 하나의 로컬 모델. 한 번의 실행. 내부 채점. 시나리오는 내 워크플로우에서 가져왔습니다. 이것을 입증된 결과라고 부를 수 없습니다. 올바른 프레이밍은: 초기 신호가 방향성을 뒷받침하고, 이제 더 정직하게 검증할 방법이 있다는 것입니다.
점수 형태의 간략 예시
| 시나리오 | 기대 행동 | 요약‑전용 행동 | 계층형 행동 |
|---|---|---|---|
| 잘못된 “최종” 버전 | 현재 전송 파일을 사용하고, 단지 보여지는 정규 파일을 사용하지 않음 | 일반적인 패키징 프로세스를 만들어 현재 파일을 식별하지 못함 | 현재 전송 버전을 식별하고 복사‑편집 전용 경계를 유지함 |
| 리셋 후 에이전트 상태 | … | … | … |
(표는 나머지 시나리오에 대해서도 계속됩니다.)
Part 3 — 예상치 못한 부분
테스트는 프레임워크를 단순히 지원한 것이 아니라 수정했습니다.
계층형 시스템의 첫 번째 버전은 아직 한 시나리오에서 실패했습니다. 하나의 글이 준비 완료 상태로 표시된 것을 알았고, 또 다른 다른 글이 다음에 작성될 것이라는 것도 알았습니다. 그런데 잘못 선택했는데— “ready”라는 단어에 과도하게 가중치를 두고 준비 상태를 우선순위처럼 취급했기 때문입니다.
이는 모델이 아니라 제 스키마에 실제 결함이 있음을 드러냈습니다: 준비 상태는 상태이고, 다음 행동은 우선순위— 그리고 메모리 시스템은 이를 별도의 필드에 보관해야 합니다.
- “Ready”(준비) 은 ‘완료됐나요?’ 라는 질문에 답합니다.
- “Next”(다음) 은 ‘지금 무엇을 해야 하나요?’ 라는 질문에 답합니다.
이 둘을 합치면, 심지어 규율 있는 메모리조차도 자신 있게 잘못된 행동을 하게 됩니다. 그래서 이제 스키마는 다음 필드를 구분합니다:
status
priority
confidence
epistemic_status
verification_required이 수정은 점수보다 저에게 더 중요합니다. *“잘못했던 곳을 보존한다”*는 전체 논지를 가진 메모리 프레임워크가 테스트 중에 스스로 잘못됐음을 발견하고 더 정밀해졌기 때문입니다. 자신만을 확인할 수 있는 시스템은 아무것도 증명하지 못합니다. 압박 속에서 스스로를 수정할 수 있는 시스템이라면 최소한 계속 테스트해볼 가치가 있습니다.
그 밑에 깔린 규칙
그 의견은 논쟁이 되지 않았습니다. 대신 테스트 시나리오가 되었고, 스키마 수정이 되었으며, 이 글이 되었습니다. 이제는 진지한 비판이 메모리 입력 유형—수정, 해결되지 않은 질문, 테스트, 혹은 미래의 조각—이 된다는 규칙이 자리 잡았습니다. 시스템이 어디에 저장해야 할지 알 때, 스마트한 비판은 내구성 있는 메모리가 됩니다.
마무리
제가 설계했기 때문에 이 메모리 시스템을 신뢰하지는 않습니다. 하지만 세 번이나 실패를 겪고도 기록 덕분에 복구하고, 비교하고, 수정할 수 있었으며, 최종 측정 시 테스트가 프레임워크가 아직 작업이 필요함을 보여줬기 때문에 더 신뢰하게 되었습니다.
제가 중요하게 여기는 기준은: 좋은 날에 메모리 시스템이 얼마나 많이 기억하느냐가 아니라, 나쁜 날에도 여전히 실제를 증명할 수 있는가—그리고 어디서 틀릴 수 있는지를 알려줄 수 있는가 입니다.
다음 버전의 테스트는 저만이 만들면 안 됩니다. 더 많은 시나리오, 여러 모델, 반복 실행, 그리고 최소 하나의 외부 블라인드 채점자를 포함해야 합니다. 프레임워크가 오직 제 자신의 실패에만 작동한다면, 그것도 알아야 할 유용한 정보입니다. 다른 사람의 시나리오에서도 여전히 유효하다면, 증거는 더욱 흥미로워집니다.
이 글은 AI 메모리를 판단 인프라로 다루는 짧은 시리즈의 일부입니다:
- 제로‑예산 기반
- 왜 수정 메모리 가 복합적인가
- 그리고 시스템이 해결되지 않은 것을 보존 해야 하는 이유, 조기 종료를 강요하지 않기 위해.