AI 메모리 결과를 게시했습니다. 그러자 실제 검색(Retrieval)이 모든 것을 망가뜨렸습니다.

이 글은 GitHub Finish-Up-A-Thon Challenge를 위한 제출물입니다.

내가 만든 것

AI 메모리 결과를 게시했습니다. 그러자 실제 검색 (Retrieval) 기능을 추가했고, 모든 것이 망가졌습니다.

이것은 제가 다시 돌아가서 작업을 마무리한 후 만든 결과물입니다.

**AI 메모리 판단 데모 (AI Memory Judgment Demo)**는 AI 에이전트의 메모리가 행동을 올바르게 제어할 수 있는지 테스트하기 위한 공개 연구 프레임워크입니다.

질문은 단지 다음과 같은 것이 아닙니다:

시스템이 가장 유사한 메모리를 검색(Retrieve)했는가?

더 어려운 질문은 다음과 같습니다:

검색된 메모리가 행동을 결정할 권한(Authority)을 가졌는가?

이 데모는 메모리 시스템이 안전할 때는 답변하고, 불확실할 때는 검증하며, 필요할 때는 차단하는지를 테스트합니다.

저장소 (Repository):

https://github.com/keniel13-ui/ai-memory-judgment-demo

공개 저장소에는 다음이 포함되어 있습니다:

정책(Policy), 수정(Correction), 자격 증명(Credential), 컨텍스트(Context) 레이어를 갖춘 구조화된 메모리 저장소,
의미론적으로 유혹적인 방해 요소(Distractors)가 포함된 적대적 시나리오(Adversarial scenarios),
TF-IDF, BM25, 로컬 임베딩(Local embeddings), 역할 필터링(Role filtering), 범위 필터링(Scope filtering), 그리고 행동 유형 우선순위(Action-type precedence)를 위한 결정론적 평가기(Deterministic evaluators),
증거, 약점, 허용된 표현, 금지된 과잉 주장(Overclaims)과 함께 각 발견 사항을 추적하는 공개 주장 원장(Public claim ledger),
별도의 모델 인스턴스가 평가기 결과를 보기 전에 유용한 관할권 메타데이터(Jurisdiction metadata)를 작성할 수 있는지 확인하는 새로운 작성자(Fresh-author) governs 테스트.

이 프로젝트는 공개 저장소가 존재하기 전에는 비공개로 시작되었습니다.

파일 기반 타임라인은 다음과 같습니다:

4월 30일: 휴대 가능한 AI 메모리 전송 팩이 존재했습니다 (AI_MEMORY/README.md, AI_MEMORY/Identity.md).
5월 22일: 수정 메모리 (correction-memory) 아티팩트와 플레이북 (playbook) 파일들이 존재했습니다.
5월 24일: 첫 번째 비공개 리셋 평가 하네스 (reset-evaluation harness)가 존재했습니다 (run_ai_memory_reset_eval.py, AI_MEMORY_RESET_EVAL_SCENARIOS_2026-05-24.json, AI_MEMORY_RESET_EVAL_RESULTS_2026-05-24.md).
5월 25일: 블라인드 패킷 (blind packet) 및 v0.3 평가 아티팩트들이 존재했습니다.
5월 26일: 6개 파일로 구성된 데모가 공개적으로 검토 가능한 아티팩트로 나아가는 가교 역할을 했습니다.
5월 29-31일: 공개 저장소는 권한 중재 (authority-arbitration) 연구 아크 (arc)로 성장했습니다: CLAIM-08부터 CLAIM-14까지, 그리고 Article 09를 포함합니다.

따라서 진정한 "이전" 상태는 버려진 공개 저장소가 아니었습니다. 그것은 패키지화되지 않았고, 재현 불가능하며, 공개되지 않은 비공개 진단 작업이었습니다.

마무리 작업은 그 작업을 검토 가능한 공개 프레임워크로 전환하는 것이었습니다.

데모 (Demo)

메인 시나리오 로컬 평가기를 클론(Clone)하여 실행하세요:

git clone https://github.com/keniel13-ui/ai-memory-judgment-demo.git
cd ai-memory-judgment-demo
python3 run_memory_store_eval.py

결정론적 어휘 및 역할 필터 (role-filter) 실행에는 API 키가 필요하지 않습니다.

로컬 임베딩 (embedding) 전략은 사용 가능한 경우 Ollama를 사용합니다:

OLLAMA_EMBED_MODEL=nomic-embed-text:latest python3 run_memory_store_eval.py

최근 작성글:

In This Memory Test, Relevance Wasn't Authority

재기 스토리 (The Comeback Story)

첫 번째 비공개 결과는 고무적이었습니다.

5월 24일에 리셋 평가 하네스 (reset-evaluation harness)는 요약 전용 메모리 (summary-only memory) 베이스라인을 계층형 메모리 (layered memory)와 비교했습니다. 6개의 리셋/복구 시나리오에서 요약 전용 메모리는 3/12점을 기록한 반면, 계층형 메모리는 9/12점을 기록했습니다.

그것은 유용했지만, 충분하지는 않았습니다.

초기 하네스는 주로 리셋 후에 메모리가 더 안전한 행동 경계 (action boundaries)를 보존할 수 있는지 여부를 테스트했습니다. 아직 더 어려운 검색 (retrieval) 문제를 테스트하지는 않았습니다:

에이전트가 메모리를 직접 전달받는 대신, 스스로 적절한 메모리를 찾아야 할 때는 어떤 일이 벌어지는가?

검색 (Retrieval)이 루프에 진입하자, 작업의 성격이 변했습니다.

관련된 메모리들이 더 엄격한 메모리들을 압도하기 시작했습니다. 구체적인 운영상의 방해 요소 (distractors)들이 추상적인 안전 정책 (safety policies)을 이겼습니다. 때로는 시스템이 잘못된 메모리로부터 올바른 행동을 생성하기도 했는데, 이는 행동의 정확성 (action correctness)만으로는 잘못된 검색 (retrieval)을 숨길 수 있음을 의미했습니다.

첫 번째 큰 교훈은 다음과 같습니다:

검색 정확도 (Retrieval accuracy)와 행동 정확도 (action correctness)는 서로 어긋날 수 있다.

그 후 더 어려운 결과가 나타났습니다:

관련성 (Relevance)이 권위 (authority)를 의미하지는 않는다.

새로 작성된 시나리오 로컬 저장소 (scenario-local stores)를 대상으로 어휘 검색 (lexical retrieval)과 로컬 임베딩 검색 (local embedding retrieval)을 테스트했습니다. 하나의 임베딩 모델 (embedding model)도 이러한 실패 유형들을 해결하지 못했습니다. 두 가지 사례에서는 성능이 오히려 퇴보했는데, 이는 의미론적으로 가까운 (semantically close) 메모리가 표면적인 질문에는 답했지만, 정작 해당 행동을 제어할 권한이 있는 메모리는 따로 있었기 때문입니다.

이로 인해 아키텍처 변경이 이루어졌습니다.

검색 (retrieval)이 모든 것을 해결하도록 요구하는 대신, 문제를 분리했습니다:

관련성 (relevance): 어떤 메모리가 쿼리 (query)와 가까운가?
권위 (authority): 어떤 메모리가 해당 행동을 제어하도록 허용되었는가?

첫 번째 역할 필터 (role-filter) 전략은 활성 정책 (active policy), 자격 증명 (credential), 그리고 수정 (correction) 메모리를 위한 권위 차선 (authority lane)을 생성했습니다. 5개의 시나리오로 구성된 적대적 패킷 (adversarial packet) 테스트에서 다음과 같은 결과에 도달했습니다:

이전의 모든 전략은 동일한 시나리오에서 여전히 함정 메모리 (trap memories)를 선택했습니다.

전략	대상 선택	행동 정확	함정 실패
`bm25_metadata_text`	3/5	4/5	2
...

그 후 프로젝트는 더 정직해져야 했습니다.

메타데이터 노이즈 (Metadata-noise) 테스트 결과, 광범위하거나 상충하는 정책들이 권위 차선 (authority lane)을 오염시킬 때 역할 필터가 과도하게 차단 (overblock)할 수 있음을 보여주었습니다. 범위 인식 (Scope-aware) governs 메타데이터가 이러한 통제된 과잉 차단을 해결했지만, 이는 범위 (scope) 메타데이터가 양호할 때만 가능했습니다.

그래서 저는 새로 작성된 범위 (scope) 메타데이터를 테스트했습니다.

세 번의 별도 신규 모델 패스 (model passes) 모두 첫 번째 패킷에서는 깨끗한 결과를 유지했습니다. 그러나 더 까다로운 혼란 패킷 (clutter packet)에서 두 가지 새로운 실패가 드러났습니다:

어휘가 중복되는 인접한 정책들,
읽기 전용 쿼리 (read-only queries)가 실수로 쓰기/실행 (write/execute) 정책을 트리거하는 경우.

이는 다음 아키텍처 계층인 구체성 우선순위 (specificity precedence) 및 작업 유형 필터링 (action-type filtering)으로 이어졌습니다.

혼란 패킷 (clutter packet)에 대해 두 번의 별도 작업 유형 패스 (action-type passes)를 수행한 결과, 모두 다음과 같은 결과에 도달했습니다:

전략	대상 선택	작업 정확도	함정 실패	과도한 차단
`scope_precedence_role_filter_bm25_metadata_text`	5/5	5/5	0	0

핵심은 이것이 AI 메모리 문제를 해결한다는 것이 아닙니다.

해결하지 못합니다.

남아 있는 가장 강력한 위협은 혼란 패킷 (clutter packet) 제품군에 대한 아키텍처 과적합 (architecture-overfitting)입니다. 다음으로 의미 있는 테스트는 관찰된 실패 사례나 그 결과로 도출된 아키텍처에 대한 지식 없이 작성된, 진정으로 새로운 홀드아웃 (held-out) 혼란 패킷을 사용하는 것입니다.

하지만 이 프로젝트는 이제 공개되었고, 재현 가능하며, 자체적인 한계에 대해 솔직합니다.

패키징되지 않았거나 공개되지 않은 비공개 메모리/리셋 실험, 기사 초안, 그리고 로컬 평가 하네스 (eval harness).

이후:

결정론적 평가기 (deterministic evaluators), 적대적 저장소 (adversarial stores), 신규 작성 테스트, 주장 원장 (claim ledger), 감사 프로토콜 (audit protocols), 그리고 9개의 기사로 구성된 연구 아크 (research arc)를 갖춘 공개 리포지토리 (public repo).

이것이 마무리 단계입니다.

GitHub Copilot 사용 경험

이 프로젝트의 개발 파트너는 Claude Code와 Codex였습니다. 이들은 메모리 동작 자체가 연구의 대상이었던 AI 에이전트들입니다. GitHub Copilot은 빌드 과정에 포함되지 않았습니다.

GitHub가 제공한 것은 제가 처음에는 필요하다고 깨닫지 못했던 부분인 책임성 (accountability)이었습니다.

GitHub는 작업을 검사 가능한 상태로 만들었습니다:

모든 결과는 파일에 연결되어 있고,
모든 주장은 커밋 (commit)에 연결되어 있으며,
모든 과도한 주장 (overclaim)은 CLAIM_LEDGER.md에 기록되어 있고,
모든 평가기 (evaluator)는 다시 실행될 수 있으며,
모든 공개 기사는 그것을 생성한 산출물 (artifacts)을 다시 가리킵니다.

그것이 프로젝트를 변화시켰습니다.

GitHub가 없었다면, 이 프로젝트는 비공개 메모와 확신에 찬 주장들의 모음으로 남아 있었을 것입니다.

GitHub와 함께함으로써, 이 프로젝트는 다른 사람들이 검사하고, 다시 실행하고, 비판하며, 그 위에 구축할 수 있는 무언가가 되었습니다.

그것이 바로 이 저장소(repo)에 불편한 파일들이 포함된 이유이기도 합니다: 유효성 위협(validity threats), 금지된 어구(forbidden wording), 회의적인 감사 프롬프트(skeptical audit prompts), 그리고 실패한 중간 전략들(failed intermediate strategies) 말입니다. 목적은 깔끔해 보이는 것이 아니었습니다. 목적은 연구가 속기 어렵게 만드는 것이었습니다.

무엇이 변했는가

저는 하나의 질문으로 시작했습니다:

AI 메모리는 리셋(reset) 후에도 생존할 수 있는가?

저는 더 어려운 질문으로 끝을 맺었습니다:

AI 시스템은 질의(query)에 답하는 메모리와 행동을 제어하도록 허용된 메모리를 구분할 수 있는가?

그 두 번째 질문이야말로 이 프로젝트를 끝까지 완수할 가치가 있게 만든 지점이었습니다.

이것은 벤치마크급 검증(benchmark-grade validation)은 아닙니다. 이것은 실패, 교정, 그리고 아키텍처(architecture)에 관한 공개적이고 검사 가능한 연구 노트입니다.

그것이 제가 완성한 결과물입니다.

Tags: devchallenge, githubchallenge, ai, machinelearning