검색(Retrieval)은 해결되었습니다. 왜 에이전트 메모리는 여전히 안전하지 않을까요?

이 글은 Self-Correcting Systems 연구 시리즈의 일부입니다. 처음 오셨다면 다음을 참고하세요: start-here-my-ai-memory-research-so-far-26hd. 공개 하네스(public harness)는 github.com/keniel13-ui/ai-memory-judgment-demo에서 확인하실 수 있습니다.

AI 메모리 생태계는 지난 3년 동안 어려운 문제를 해결하는 데 매진해 왔습니다.

에이전트(Agent)는 어떻게 세션(Session) 전반에 걸쳐 상태(State)를 유지할까요? 어떻게 컨텍스트 창(Window)을 과부하시키지 않고 적절한 컨텍스트(Context)를 검색할까요? 어떻게 긴 히스토리(History)를 관리하고 적절한 순간에 적절한 메모리를 표면화할까요?

LangChain, LlamaIndex, MemGPT/Letta, 그리고 Zep은 모두 이 문제를 해결하기 위해 실질적인 것들을 구축해 왔습니다. 벡터 저장소(Vector stores), 하이브리드 검색(Hybrid search), 의미론적 유사성(Semantic similarity), 컨텍스트 압축(Context compression) 등 도구들은 성숙해졌으며 연구 또한 진지하게 진행되고 있습니다.

저는 이 중 어느 것과도 논쟁하려는 것이 아닙니다.

저는 검색(Retrieval) 작업이 다루지 못하는, 다른 문제를 지목하고자 합니다.

검색은 한 가지 질문에 답합니다. 권한 부여(Authorization)는 또 다른 질문입니다.

에이전트가 메모리를 검색하고 그에 따라 행동할 때, 두 가지 조건이 충족되어야 합니다.

첫째: 메모리가 쿼리(Query)와 관련이 있어야 합니다.

둘째: 메모리가 해당 행동을 제어할 권한(Authorized)을 가지고 있어야 합니다.

생태계는 압도적으로 첫 번째 질문을 중심으로 구축되어 있습니다. 두 번째 질문, 즉 검색된 메모리가 다음에 일어날 일을 제어할 권한이 있는지 여부는 아직 미발달된 계층입니다. 그리고 우리의 연구에서 이 두 목표는 적극적으로 갈라집니다.

그것이 저를 얼어붙게 만든 첫 번째 발견이었습니다.

더 정확하게 적절한 메모리를 찾아내는 검색 전략이, 검색 정확도가 낮은 전략보다 더 많은 불안전한 행동을 유발할 수 있습니다. 관련성(Relevance)과 권한(Authority)은 서로 다른 목표입니다. 적대적 조건(Adversarial conditions) 하에서 이들은 서로 다른 방향으로 끌어당깁니다.

이것이 CLAIM-01입니다. 이는 12개의 시나리오, 두 가지 검색 모드, 그리고 다수의 외부 패킷(External packets)을 통해 입증되었습니다.

우리가 명명한 것과 우리가 구축한 것

이 연구는 검색 실험으로 시작되었습니다. 하지만 검색이 테스트하지 못하는 무언가를 테스트하기 위한 프레임워크로 발전했습니다.

다음은 이를 쉬운 언어로 설명한 흐름입니다.

1단계 — 관련성(Relevance)과 권한(Authority)의 분리. 적절한 메모리를 찾는 것이 곧 그 메모리에 기반하여 행동할 권한이 있음을 의미하지는 않습니다. 우리는 주석이 달린 시나리오와 새로 작성된 적대적 시나리오(Adversarial scenarios) 전반에 걸쳐 이 현상을 기록했습니다. (CLAIM-01, CLAIM-08)

2단계 — 권한(Authority)을 수학적으로 명시화하려는 시도. 거버넌스(Governance)가 조정된 점수 산정 공식: 관련성(Relevance) + 권한 가중치(Authority weight) + 범위 일치(Scope match) + 구체성(Specificity) + 작업 유형(Action type) + 상태 유효성(Status validity) - 충돌 위험(Conflict risk). 이 공식은 진단적입니다. 이는 아키텍처가 얼마나 취약한 메타데이터(Metadata)에 의존하고 있는지를 드러냅니다. 홀드아웃 패킷(Held-out packet) 테스트 결과, 단순한 BM25가 전체 스코어러(Scorer)보다 더 나은 성능을 보였습니다. 우리는 이 반증(Falsification)을 주요 연구 결과로 발표했습니다. (CLAIM-15, CLAIM-15B)

3단계 — 잘못 라벨링된 메모리의 정확한 검색은 메모리를 놓치는 것보다 더 위험합니다. 민감한 메모리가 권한 신호나 거버넌스 필드 없이 일반적인 컨텍스트(Context)로 저장될 때, 검색 시스템은 이를 깔끔하게 찾아내어 매우 높은 확신을 가지고 답변합니다. 이는 '거짓 확신(False-certainty)' 오류입니다. 우리는 자격 증명 패킷, 개인정보(PII) 패킷, 산업 안전 패킷을 통해 이를 테스트했습니다. (CLAIM-17, CLAIM-18)

4단계 — 메모리의 자기 기술(Self-description)을 신뢰하지 마십시오. 명백한 해결책은 더 나은 메타데이터를 사용하는 것입니다. 문제는 메타데이터가 메모리를 저장하는 동일한 시스템에 의해 작성된다는 점입니다. 잘못 라벨링된 메모리는 자신의 주장만을 읽는 모든 검사를 통과할 것입니다. 우리는 검증 관문(Gate)을 운영 컨텍스트(Operation context)로 옮겼습니다: 에이전트가 실제로 무엇을 하려고 하는가? (CLAIM-22)

5단계 — 쿼리(Query) 또한 신뢰하지 마십시오. 쿼리는 작업을 모호하게 설명할 수 있습니다. "파트너 설정을 처리해줘"라는 말은 일상적인 것처럼 들립니다. 하지만 그 이면의 도구 호출(Tool call) — send_secret, target_resource: prod_api_key, recipient: external_partner —은 그렇지 않습니다. 우리는 검증 관문을 실제 도구 호출 파라미터(Tool-call parameters)로 옮기고, 이를 외부 권한 테이블(External grant table)과 대조했습니다. 결과는 7/7, 거짓 확신 오류가 0건이었습니다. (CLAIM-23)

쓰기 시점(Write-time)의 질문은 여전히 남아 있습니다. 애초에 누가 권한을 담은 메모리를 저장할 수 있는가? 이것이 쓰기(Write) → 검색(Retrieval) → 실행(Execution)으로 이어지는 전체 사이클을 완성합니다.

주요 프레임워크의 작동 방식

과장된 주장은 우리가 피하고자 하는 신뢰성 문제 그 자체이기 때문에, 이 지점에서 정확하게 말씀드리고 싶습니다.

LangChain, LlamaIndex, MemGPT/Letta, 그리고 Zep은 실제 메모리(Memory), 검색(Retrieval), 상태(State), 그리고 컨텍스트(Context) 문제를 해결합니다. 이 중 여러 프레임워크는 접근 제어(Access Controls)를 노출합니다: 인간 승인 워크플로우(Human approval workflows), 역할 기반 접근 제어(RBAC), 읽기/쓰기 경계(Read/write boundaries), 또는 미들웨어 훅(Middleware hooks) 등이 그것입니다. 이 생태계 중 여러 곳에 포함된 조건부 라우팅(Conditional routing) 프레임워크와 도구 호출 가드레일(Tool-calling guardrails)은 인접한 실패 모드(Failure modes)를 다룹니다. 이것들은 정당하며 유용합니다.

제가 발견하지 못한 것 — 그리고 테스트 하네스(Harness)가 구체적으로 테스트하고자 하는 것 — 은 검색된 메모리가 뒤따르는 동작을 제어할 권한이 있는지 묻는, 공개적이고 스트레스 테스트(Stress-tested)를 거친 프레임워크입니다. 시스템 경계에서의 접근 권한이 아닙니다. 쓰기 시점의 역할 기반 권한도 아닙니다. 더 좁은 질문입니다: 이 검색된 메모리가 *이 작업(This operation)*을 제어할 권한이 있는가?

만약 이 프레임워크 중 어느 하나라도 이를 위한 공개적인 하네스를 가지고 있다면, 저는 그것을 보고 싶습니다. 하네스는 외부의 압력을 받도록 설계되었습니다. ANP2는 제가 그것을 완전히 명명하기 전에 자기 기술 격차(Self-description gap)에 의문을 제기했습니다. Felix는 작업을 철학에서 증거의 영역으로 밀어붙였습니다. 그것들은 연구가 받은 가장 유용한 입력값이었습니다.

제가 솔직하게 할 수 있는 비교는 공개적인 증거 계층(Public evidence layer)에 관한 것입니다:

프레임워크	메모리 / 검색 (Memory / Retrieval)	접근 / 승인 제어 (Access / Approval Controls)	메모리-권한 스트레스 테스트 (Memory-Authority Stress Tests)	작업 경계 부여 평가 (Operation-Bound Grant Eval)	공개 주장 원장 (Public Claim Ledger)
LangChain	예	부분적	찾을 수 없음	찾을 수 없음	아니요
...

"찾을 수 없음(Not found)"은 제가 검색해 보았으나 이 계층을 테스트하는 공개적인 하네스를 찾지 못했다는 의미입니다. 만약 제가 무언가를 놓쳤다면 말씀해 주십시오. 표를 업데이트하겠습니다.

증거 표준 (The Evidence Standard)

마지막 열에 대해 한마디 하고 싶은데, 왜냐하면 그것이 저에게 가장 중요한 부분이기 때문입니다.

AI 연구 분야에는 신뢰성 문제(Confidence problem)가 있습니다.

프레임워크들은 메모리의 진보를 주장합니다. 논문들은 검색의 개선을 주장합니다. 제품들은 더 안전한 에이전트를 주장합니다. 이러한 주장들 대부분은 사전 등록(Pre-registration), 허위 판별 조건(Falsification conditions), 또는 누구나 이의를 제기할 수 있는 공개적인 하네스 없이 이루어집니다.

우리는 실험을 실행하기 전에 모든 주장(claim)을 사전 등록(pre-register)합니다. 실험 결과가 예측과 모순될 경우, 다음 기사가 나오기 전에 해당 허위 판별(falsification) 결과를 공개합니다. 묻어두지도, 재구성하지도 않습니다. 실패한 예측이 헤드라인이 됩니다.

이것은 여전히 흔치 않은 일입니다.

표준은 낮습니다. 벤치마크를 직접 선택하고, 평가(eval) 방식을 작성하며, 발표 시점을 결정할 수 있다면 "우리의 접근 방식이 결과를 개선했다"라고 주장하기는 쉽습니다.

이 하네스(harness)는 적대적 압박(adversarial pressure)을 받도록 설계되었습니다. ANP2는 외부 패킷을 작성했습니다. Felix는 결과가 실제인지 아니면 AI가 생성한 것인지 물었습니다. 두 사람 모두 연구가 더 강력한 증거를 향하도록 밀어붙였습니다. 그것이 바로 공개 장부(public ledger)의 용도입니다.

23개의 주장. 사전 등록됨. 허위 판별 결과 공개됨. 누구나 복제하거나 이의를 제기할 수 있습니다: github.com/keniel13-ui/ai-memory-judgment-demo.

복제할 수 없는 단 한 가지

연구의 궤적은 복제될 수 있습니다. 하네스는 공개되어 있습니다.

복제할 수 없는 것은 외부의 압박 속에서 공개적으로 구축된 증거의 흔적이며, 각 기사가 발표되기 전 허위 판별 결과가 기록으로 남겨진 과정입니다.

우리가 원하는 결과가 나올 때까지 실험을 반복하는 비공개 기간은 존재하지 않습니다. 주장 장부(claim ledger)는 순차적입니다. 타임스탬프는 실제입니다. 홀드아웃 테스트(held-out test)가 공식을 깨뜨렸을 때, 첫 번째 기사는 그 사실을 헤드라인으로 다루었습니다.

현재 우리의 위치

세 가지 신뢰 경계(trust boundaries)를 통과했습니다.

첫째, 메모리는 자신의 권한(authority)을 스스로 설명하는 것을 신뢰할 수 없었습니다.

그다음, 쿼리(query)는 동작을 설명하는 것을 신뢰할 수 없었습니다.

이제 게이트(gate)가 도구 호출(tool call)을 읽고 외부 승인(external grant)을 확인합니다.

하지만 이것이 전체 시스템은 아닙니다. 쓰기 시점 권한 부여(Write-time authorization) — 즉, 애초에 권한을 지닌 메모리를 저장할 수 있는 사람이 누구인지 — 는 여전히 해결되지 않은 문제입니다. 2026년 3분기(Q3 2026)를 목표로 합니다.

memory-authority-auditor-web-992750435781.us-central1.run.app의 Memory Authority Auditor는 제품 수준의 속도로 실행되는 프레임워크입니다. 6개의 에이전트(agents)와 라이브 웹 인터페이스(live web interface)로 구성되어 있으며, 어떤 메모리 파일이든 입력받아 권한 감사 보고서(authority audit report)를 반환합니다.

만약 여러분이 에이전트 메모리(agent memory)를 연구하고 있으며, 제가 여기서 설명하지 않은 방식으로 권한 부여 계층(authorization layer)을 밀어붙였다면, 저는 그 내용을 읽어보고 싶습니다. 그것이 바로 이 하네스(harness)의 용도입니다.

시리즈의 이전 기사들: