Bruce Schneier가 소개한 CIMemories(arXiv 2511.14937) 실측: 프론티어 모델 최대 69% 속성 위반, 태스크 1→40에서 GPT-5 위반률 0.1%→9.6%, 같은 프롬프트 5회 실행 시 25.1%. 프라이버시 프롬프팅은 과일반화로 실패.
핵심 요약
- CIMemories는 LLM의 지속 메모리(persistent memory)가 맥락에 따라 민감 정보를 부적절하게 노출하는지 평가하는 벤치마크입니다. 사용자당 100개 이상의 속성을 가진 합성 프로필과, 각 속성이 필요한/부적절한 다양한 태스크 컨텍스트로 구성됩니다 (Schneier on Security).
- 실측 결과는 충격적입니다. 프론티어 모델이 최대 69%의 속성 수준 위반을 보였습니다. LLM이 기억하는 정보를 맥락과 무관하게 새는 것입니다.
- 위반은 사용량에 따라 누적됩니다. 태스크 수가 1개에서 40개로 늘면 GPT-5의 위반률이 0.1%에서 9.6%로 상승했고, **같은 프롬프트를 5번 실행하면 25.1%**에 달했습니다. 같은 입력인데 매번 다른 정보를 누출하는 불안정한 행동입니다 (CIMemories).
- 프라이버시 프롬프팅은 해결책이 아닙니다. 모델은 맥락에 따라 미묘하게 판단하는 대신 전부 공유하거나 전부 거부하는 과일반화를 보입니다.
- Bruce Schneier가 이 논문을 소개하며 "AI와 무결성(integrity)에 대해 많이 생각하고 있다"고 밝혔습니다. 맥락 무결성은 단순 프롬프트 문제가 아니라 맥락 인식 추론 능력의 문제입니다 (Schneier on Security).
기억하는 AI는 정보를 어떻게 누출하는가
CIMemories는 LLM의 지속 메모리가 맥락에 맞게 정보를 통제하는지 평가하는 벤치마크입니다. LLM이 과거 대화를 기억해 맞춤형 응답을 하는 시대가 왔지만, 이 메모리는 민감 정보가 부적절한 맥락에서 노출되는 위험을 만듭니다. 예를 들어 사용자의 건강 상태를 기억하는 에이전트가, 그 정보가 필요 없는 동료 협업 세션에서 그 사실을 그대로 언급하는 상황이 그것입니다.
예를 들어 봅니다. 사용자 프로필에 "당뇨병 있음", "아이 둘", "연봉 수준", "주소" 같은 속성이 저장되어 있다고 합시다. 어떤 태스크에서는 이 정보가 쓰여야 합니다. 건강식 추천에는 당뇨병 정보가 쓰이고, 배송에는 주소가 쓰입니다. 하지만 같은 정보가 전혀 다른 맥락 — 예를 들어 동료와의 협업 세션이나 낯선 사용자와의 대화 — 에서 노출되면 안 됩니다.
맥락 무결성(Contextual Integrity) 은 정보가 흐르는 맥락이 정보의 성격과 맞아야 한다는 개념입니다. 헬렌 니센바움(Helen Nissenbaum)이 제안한 프라이버시 이론으로, "정보는 그 정보가 수집된 맥락에 맞게만 흘러야 한다"는 원칙입니다. CIMemories는 이 개념을 LLM 지속 메모리에 적용한 벤치마크입니다 (Schneier on Security).
CIMemories가 측정한 것
CIMemories는 사용자당 100개 이상의 속성을 가진 합성 프로필을 만들고, 각 속성이 특정 태스크에서는 필수이지만 다른 태스크에서는 부적절한 다양한 컨텍스트를 구성합니다. LLM이 메모리에서 정보를 꺼내 쓸 때, 맥락에 맞는 정보만 흘려보내는지를 측정합니다 (CIMemories).
실측 결과는 세 가지로 요약됩니다.
첫째, 위반률이 높습니다. 프론티어 모델들이 최대 69%의 속성 수준 위반을 보였습니다. 즉 저장된 민감 정보가 부적절한 맥락에서 새어나간 것입니다.
둘째, 위반이 누적됩니다. 태스크 수가 1개에서 40개로 늘어나면 GPT-5의 위반률이 0.1%에서 9.6%로 상승했습니다. 대화가 길어질수록 메모리에서 새는 정보가 많아지는 것입니다.
셋째, 행동이 비결정적입니다. 같은 프롬프트를 5번 실행하면 위반률이 25.1%에 달했습니다. 같은 입력인데 모델이 매번 다른 속성을 누출하는 불안정한 행동을 보인다는 뜻입니다.
프라이버시 프롬프팅의 실패
가장 중요한 발견은 프라이버시를 주의시키는 프롬프트가 해결책이 아니라는 것입니다. 모델은 "민감 정보를 조심하라"는 지시를 받으면 맥락에 따라 미묘하게 판단하는 대신 과일반화합니다 — 모든 정보를 공유하거나, 모든 정보를 거부하는 극단적인 행동을 보입니다.
이건 프롬프트 엔지니어링의 한계를 보여줍니다. 맥락 무결성은 "이 정보가 지금 이 맥락에서 적절한가"라는 맥락 인식 추론(context-aware reasoning) 이 필요한 문제입니다. 단순히 "조심해"라고 지시하는 것으로는 해결되지 않고, 모델이 각 정보의 민감도와 각 맥락의 특성을 함께 고려하는 능력이 필요합니다.
왜 지금 이 문제인가
이 논문이 중요한 이유는 에이전트의 메모리가 점점 더 커지고 있기 때문입니다. 앞서 다룬 것처럼 에이전트는 SOUL.md 같은 파일에 정체성을 저장하고, 대화를 기억하고, 사용자 모델을 쌓아갑니다. 메모리가 커질수록, 그리고 에이전트가 더 많은 맥락에서 활동할수록 맥락 무결성 위반의 표면은 넓어집니다.
특히 주목할 점은 "비결정적 누출" 입니다. 같은 프롬프트인데 25.1%의 확률로 다른 정보가 새는 것은, 테스트 시점에 따라 결과가 달라진다는 뜻입니다. 보안 관점에서 이것은 최악의 특성입니다 — 결정적으로 예측할 수 없기 때문입니다.
대안: 맥락 무결성을 구조로 해결하는 방법
CIMemories가 실측한 세 가지 실패(69% 위반, 누적 누출, 비결정성)는 각각 다른 대안으로 대응할 수 있습니다. 프롬프트에 의존하지 않는 구조적 접근입니다.
첫째, 69% 위반 — 속성 민감도 태깅과 맥락 허용 매트릭스. 메모리에 저장되는 각 속성에 민감도 등급(공개/내부/민감)을 붙이고, 맥락 유형(개인 세션/협업/공개)별 허용 여부를 매트릭스로 정의합니다. LLM이 "판단"하는 대신, 외부 필터가 속성 등급과 맥락 등급을 대조해 차단합니다. 예를 들어 '민감' 속성은 협업 세션에서 필터가 자동으로 제외합니다. 이는 모델의 맥락 추론을 믿는 대신, 결정을 명시적 규칙으로 옮기는 것입니다.
둘째, 누적 누출 — 메모리 접근 범위 축소와 세션 분리. 태스크가 길어질수록 위반이 쌓이는 것은 전체 메모리가 모든 태스크에 노출되기 때문입니다. 대안은 메모리를 태스크 스코프로 분리하는 것입니다. 각 태스크에 필요한 속성만 그 태스크의 컨텍스트에 주입하고, 나머지는 격리합니다. nanobot의 config/workspace 분리처럼, 에이전트 워크스페이스와 프로젝트 워크스페이스를 나누는 설계가 실제 사례입니다. 긴 세션에서는 태스크 전환 시 메모리 컨텍스트를 리셋하는 것이 필요합니다.
셋째, 비결정성 — 결정적 게이트와 자동 검증. 같은 프롬프트가 25.1% 확률로 다른 정보를 누출하는 것은 테스트 시점에 따라 결과가 달라진다는 뜻입니다. 대안은 민감 정보가 포함될 수 있는 응답에 결정적 필터를 붙이는 것입니다. 응답 생성 후, '민감 속성 + 현재 맥락' 대조 규칙을 통과하지 못하면 응답을 보류하거나 속성을 제거합니다. 확률적 모델의 출력을 결정적 규칙으로 검증하는 이중화입니다.
넷째, 인간 확인 게이트. 위반의 영향이 큰 속성(건강, 재정, 위치)은 자동 노출을 아예 금지하고, 노출이 필요한 경우 인간 확인을 요구합니다. 이는 Vercel Foreman이 머지를 사람에게 남기는 것과 같은 원리 — 결정적 영향이 있는 행동은 자동화 밖에 둡니다.
이 네 가지는 프롬프트를 바꾸지 않고 구조를 바꿉니다. CIMemories의 결론("맥락 인식 추론 능력이 필요하다")에 동의하지만, 그 능력을 모델 안에서 키우는 대신 모델 밖의 규칙과 필터로 보완하는 것이 현재로선 가장 현실적인 대안입니다.
판단과 실용 체크리스트
CIMemories의 실측은 LLM 메모리의 맥락 무결성이 현재 해결되지 않은 근본적 한계임을 보여줍니다. 표본 한계는 분명합니다. 합성 프로필 기반이고, 특정 모델 버전 기준이며, 벤치마크의 태스크 구성이 실제 사용과 다를 수 있습니다. 하지만 69% 위반률과 비결정적 누출은 프롬프트로 해결될 문제가 아닙니다.
메모리를 쓰는 에이전트를 운영한다면 아래 체크리스트를 참고하시기 바랍니다.
- 1단계 — 메모리에 무엇이 저장되는지 감사합니다. 프로필에 민감 속성(건강, 재정, 위치)이 포함되는지 확인하고, 최소한만 저장합니다.
- 2단계 — 맥락 경계를 설계합니다. 낯선 사용자, 협업 세션, 공개 채널에서는 메모리 접근을 분리합니다. 맥락이 바뀌면 메모리도 분리되어야 합니다.
- 3단계 — 속성에 민감도 등급을 태깅합니다. 공개/내부/민감 3단계로 분류하고, 맥락 유형별 허용 매트릭스를 정의합니다. LLM의 판단을 믿는 대신 필터가 차단합니다.
- 4단계 — 결정적 필터를 붙입니다. 응답 생성 후 '민감 속성 × 현재 맥락' 대조 규칙을 통과하지 못하면 보류하거나 속성을 제거합니다. 비결정성은 규칙으로 검증합니다.
- 5단계 — 누출 사고에 대비합니다. 맥락 무결성 위반은 언제든 일어날 수 있으므로, 로그와 롤백 메커니즘을 준비합니다.
결론은 이렇습니다. LLM의 지속 메모리는 편리함과 위험이 함께 옵니다. CIMemories가 실측한 69% 위반률과 비결정적 누출은, 맥락 무결성이 프롬프트가 아니라 구조로 해결해야 할 문제임을 보여줍니다. 구체적인 대안은 명확합니다 — 속성 민감도 태깅과 맥락 허용 매트릭스, 태스크 스코프 메모리 분리, 결정적 필터, 인간 확인 게이트. 프롬프트를 개선하는 대신 모델 밖에 규칙과 필터를 두는 것, 이것이 현재로선 가장 현실적인 선택입니다. 메모리를 쓰는 에이전트가 늘어나는 지금, 이 문제는 더 중요해질 것입니다.
