AI 에이전트 메모리는 GDPR을 준수하는가? 개발자를 위한 가이드

짧은 답변을 드리자면, 이는 구현 방식에 따라 다릅니다. AI 에이전트 메모리 자체가 본질적으로 GDPR을 위반하는 것은 아니지만, 대부분의 기본 구현 방식은 세 가지 심각한 준수 리스크를 생성합니다. 즉, 특정 개인에 대한 모든 데이터를 찾을 수 없고, 삭제가 실제로 이루어졌음을 증명할 수 없으며, 임베딩 (embedding) 기반 저장 방식은 선택적 삭제를 기술적으로 불가능하게 만듭니다. 이 가이드는 GDPR 제17조가 AI 에이전트 메모리에 무엇을 요구하는지, 일반적인 메모리 프레임워크가 어디에서 부족한지, 그리고 방어 가능한 시스템을 어떻게 설계할 수 있는지 설명합니다.

GDPR 제17조가 실제로 요구하는 사항

GDPR 제17조 — "삭제권" 또는 "잊힐 권리" — 는 정보 주체에게 자신의 개인 데이터를 삭제하도록 요구할 권리를 부여하며, 데이터 컨트롤러(data controller)가 "부당한 지체 없이" 이를 준수할 것을 요구합니다. 사용자에 대해 무언가를 기억하는 AI 에이전트의 맥락에서, 이는 네 가지 구체적인 엔지니어링 의무를 생성합니다:

1. 식별 (Identification): 당신은 에이전트가 특정 정보 주체에 대해 보유한 모든 데이터를 찾아낼 수 있어야 합니다. 만약 에이전트가 50번의 세션에 걸쳐 사용자에 대한 사실을 학습하고 이를 벡터 임베딩 (vector embeddings)으로 저장했다면, 모든 관련 임베딩을 찾아내는 것은 다루기 어렵습니다.

2. 삭제 (Deletion): 당신은 해당 데이터를 완전히 제거할 수 있어야 합니다. "검색 인덱스 (retrieval index)에서 제거"하는 것만으로는 기준을 충족하지 못합니다. 근본적인 레코드가 저장소에서 삭제되어야 합니다.

3. 삭제 증명 (Proof of deletion): 실제로 규제 기관과 정보 주체는 삭제가 발생했다는 증거를 요청할 수 있습니다. 검증 가능한 감사 추적 (audit trail) 없이 "X 시점에 삭제됨"이라고 로그만 남기는 시스템은, 삭제 시 제거된 레코드의 차이(diff)를 생성하는 시스템보다 방어하기가 더 어렵습니다.

4. 하위 처리자 전파 (Sub-processor propagation): 메모리 저장을 위해 제3자 API(관리형 벡터 데이터베이스, SaaS 메모리 서비스 등)를 사용하는 경우, 당신은 해당 하위 처리자(sub-processor) 또한 데이터를 삭제하도록 보장할 책임이 있습니다. 이는 클라우드 기반 메모리 서비스에 구체적인 시사점을 가집니다.

일반적인 메모리 아키텍처가 실패하는 지점

임베딩 기반 저장소 (Embedding-based storage) (Mem0, 대부분의 RAG 시스템)

에이전트가 "Alice는 채식주의자이다"라는 사실을 학습하여 이를 벡터 임베딩 (vector embedding)으로 저장할 때, 해당 벡터는 수학적 공간 내에서 그 사실의 의미론적 의미를 인코딩합니다. 기록을 "삭제"할 때 검색 인덱스 (retrieval index)에서의 참조는 제거되지만, 벡터 값은 데이터베이스가 컴팩션 (compaction) 또는 진공 (vacuum) 작업을 수행하기 전까지 데이터베이스의 하부 저장소에 계속 남아 있습니다. 더 치명적인 점은, 임베딩을 생성한 모델이 해당 사실을 "보았다"는 것입니다. 모델에게 가르친 내용을 다시 되돌릴(un-teach) 수는 없습니다.

GDPR 관점에서 보면: 검색 인덱스에서의 삭제는 해당 사실을 검색할 수 있는 실질적인 능력은 제거하지만, 하부의 개인정보 (personal data) 자체를 말소 (erasure)하는 것으로 간주되지는 않습니다. Pinecone, Weaviate, Qdrant와 같은 벡터 데이터베이스 (vector databases)는 개별 벡터의 하드 삭제 (hard deletion)를 지원하므로 이 문제는 해결 가능합니다. 하지만 이는 Mem0와 같은 프레임워크의 기본 동작이 아니라 명시적인 구현이 필요한 사항입니다.

실무적 격차 (Practical gap): Mem0의 기본 delete_all(user_id=...) API 호출은 관리되는 저장소에서 기록을 제거하지만, 만약 Qdrant 백엔드를 사용하는 셀프 호스팅(self-hosted) Mem0를 사용 중이라면, 삭제를 완료했다고 주장하기 전에 Qdrant가 삭제된 세그먼트 (segment)를 플러시 (flush)했는지 반드시 확인해야 합니다.

상태 유지 에이전트 메모리 (Stateful agent memory) (Letta / MemGPT)

Letta는 메모리를 에이전트가 직접 읽고 편집할 수 있는 페르소나 (persona), 휴먼 (human), 아카이브 (archival)와 같은 구조화된 "메모리 블록 (memory blocks)" 형태로 저장합니다. 삭제권 (Right-to-erasure)을 보장하려면 특정 개인에 대한 데이터를 포함하고 있는 블록이 무엇인지 식별하고, 이를 제로화(zeroing)하거나 제거해야 합니다. 단일 사용자 에이전트의 경우 이는 간단합니다. 하지만 하나의 에이전트 인스턴스가 여러 사용자를 서비스하는 멀티 유저 에이전트 배포 환경에서는 격리 모델 (isolation model)이 매우 중요해집니다. 즉, 사용자 A에 대한 데이터가 사용자 B의 상호작용이 닿을 수 있는 블록에 남아 있어서는 안 됩니다.

실무적 격차 (Practical gap): Letta의 메모리 블록은 사람이 읽을 수 있는 텍스트 파일 또는 데이터베이스 레코드이므로 임베딩보다 감사 (audit)하기는 쉽지만, 내장된 forget(user_id=...) API는 없습니다. 이를 직접 구축해야 합니다.

지식 그래프 메모리 (Knowledge graph memory) (Zep / Graphiti)

Zep은 메모리를 시계열 지식 그래프 (temporal knowledge graph) 형태로 저장합니다: 엔티티 (entities; 사람, 조직, 개념), 엣지 (edges; 관계), 그리고 타임스탬프 (timestamps; 사실이 학습된 시점)로 구성됩니다. 삭제권 (Right-to-erasure)을 준수하려면 특정 개인에 대한 개인 데이터를 인코딩하는 모든 노드 (nodes)와 엣지 (edges)를 삭제해야 합니다. Graphiti의 그래프 구조는 임베딩 검색 (embedding search)보다 이를 더 명시적으로 만들어 주지만, 동시에 더 복잡하게 만들기도 합니다. 즉, 특정 인물 엔티티를 삭제할 때 관련 노드들을 통한 연쇄 삭제 (cascading deletes)가 필요할 수 있습니다.

실무적 격차 (Practical gap): 그래프 삭제는 잘 정의되어 있지만, 고아 노드 (orphaned nodes; 삭제된 엔티티를 참조하는 엣지)는 주의 깊은 처리가 필요합니다.

오픈 포맷 메모리 (Open-Format Memory) 및 검증 가능한 삭제 (Verifiable Deletion)

대부분의 GDPR 준수 마찰이 발생하는 기술적 근본 원인은 **불투명한 저장 포맷 (opaque storage formats)**에 있습니다. 벡터 (vectors), 압축된 데이터베이스 페이지 (compressed database pages), 그리고 그래프 인덱스 (graph indices)는 모두 무엇이 삭제되었는지 확인하고 아무것도 남아 있지 않음을 증명하는 것을 어렵게 만듭니다.

기억된 정보의 각 조각이 파일 내의 일반 텍스트 레코드 (plain text record)로 저장되는 오픈 포맷 메모리는 삭제를 감사 가능 (auditable)하고 증명 가능 (provable)하게 만듭니다. 텍스트 파일에서 레코드를 삭제하고 해당 변경 사항을 버전 관리 (version control)에 커밋하면, 그 차이점 (diff)이 바로 삭제의 증거가 됩니다.

PLUR는 각 엔그램 (engram; 에이전트 메모리의 단위)을 로컬 YAML 파일 내의 구조화된 텍스트 레코드로 저장합니다. plur forget <id> 명령은 엔그램을 은퇴 (retire) 시킵니다. 즉, 해당 엔그램을 status: retired로 표시하고 향후 모든 회상 (recall) 과정에서 제외합니다. 저장소가 git으로 추적되는 플랫 파일 (flat file)이기 때문에, 은퇴 처리는 검증 가능한 diff를 생성합니다. 엔트리의 상태 필드가 active에서 retired로 변경되는 식입니다.

# ID를 통해 특정 엔그램을 은퇴시킴
plur forget ENG-2026-0618-042

...

--reason 플래그는 엔그램의 근거 (rationale) 필드에 법적 근거 또는 요청 참조를 기록하여, 파일의 git 히스토리 내에 가벼운 감사 로그 (audit log)를 생성합니다.

이를 통해 얻을 수 있는 것: 데이터 주체 (data subject)가 삭제권 (right to erasure)을 행사할 때, 해당 식별자를 검색하여 일치하는 엔그램 (engram)을 은퇴 (retire)시키고, 커밋 (commit)하여 어떤 항목이 언제 은퇴되었는지 보여주는 디프 (diff)를 생성할 수 있습니다. 은퇴된 항목은 YAML 파일에 남아 있지만, 검색 (retrieval) 대상에서는 영구적으로 제외됩니다. 엄격한 GDPR 삭제 (물리적 제거)를 위해서는 YAML에서 은퇴된 항목을 수동으로 삭제하고 해당 변경 사항을 커밋할 수 있으며, 이 경우 git diff를 통해 완전한 제거를 확인할 수 있습니다. 이는 공식적인 데이터 처리 로그 (data processing log)를 대체하는 것은 아니지만, 귀하의 컴플라이언스 태세 (compliance posture)를 뒷받침하는 검증 가능한 기술적 산출물 (technical artifact)을 제공합니다.

잊힐 권리 구현하기: 실무 체크리스트

어떤 메모리 프레임워크를 사용하든, GDPR 방어 가능한 구현을 위해서는 다음이 필요합니다:

1. 모든 메모리 단위를 데이터 주체에 귀속시키기

메모리를 저장할 때, 해당 메모리와 관련된 사용자 식별자 (user identifier)를 태그로 지정하십시오. PLUR에서는 이것이 엔그램 (engram)의 scope 필드입니다. 커스텀 시스템의 경우, 각 레코드의 user_id 필드가 됩니다.

# 특정 사용자에게 귀속된 사실을 학습
plur learn "Alice prefers dark mode" --scope "user:alice@example.com"

2. 주체별 검색 기능 구축하기

특정 인물에 관한 모든 메모리를 효율적으로 찾아낼 수 있어야 합니다. 프로덕션 (production) 환경에 적용하기 전에 이를 테스트하십시오. 규제 기관의 조사 (regulatory inquiry) 시점에 검색 결과에서 레코드가 누락되어 있다는 사실을 뒤늦게 발견해서는 안 됩니다.

# 사용자에 대한 모든 활성 엔그램 찾기
plur recall --scope "user:alice@example.com" --limit 1000

3. 주체별 전체 삭제 구현하기

이를 프레임워크의 삭제 프리미티브 (deletion primitives)에 매핑하십시오. PLUR의 경우 다음과 같습니다:

# 사용자 스코프 내의 모든 엔그램을 은퇴시키는 한 줄 명령어
plur forget --search "alice@example.com" --reason "GDPR Article 17 request 2026-07-15"

임베딩 기반 (embedding-based) 시스템의 경우, 이는 일반적으로 다음을 의미합니다: (a) user_id = X인 모든 레코드를 쿼리 (query), (b) 각 레코드에 대해 하드 삭제 (hard-delete) API 호출, (c) 삭제된 세그먼트를 비우기 위한 스토리지 컴팩션 (storage compaction) 트리거, (d) 레코드 ID 및 확인 응답을 로그 (log)에 기록.

4. 하위 프로세서 (sub-processors)로 전파하기

만약 귀하의 에이전트가 외부 메모리 API (external memory APIs), 클라우드 벡터 데이터베이스 (cloud vector databases) 또는 제3자 서비스 (third-party services)를 사용한다면, 각 하위 프로세서 (sub-processor)와의 데이터 처리 합의서 (DPA, Data Processing Agreement)가 삭제 (deletion) 항목을 포함하고 있는지 확인하고, 삭제 요청이 제대로 전파 (propagate)되는지 테스트하십시오.

5. 감사 추적 (audit trail) 생성하기

모든 삭제 이벤트를 다음 항목과 함께 로그 (log)에 기록하십시오: 요청 참조 (request reference), 정보 주체 식별자 (subject identifier), 삭제된 레코드 ID (record IDs) 목록, 타임스탬프 (timestamp), 그리고 실행자 (executor). 오픈 포맷 시스템 (open-format systems)의 경우 커밋 디프 (commit diff)가 이에 해당하며, 데이터베이스 시스템 (database systems)의 경우 이를 추가 전용 감사 로그 (append-only audit log)에 기록하십시오.

6. 필요하기 전에 삭제 테스트 수행하기

분기별로 삭제 훈련 (deletion drill)을 실시하십시오. 테스트 레코드를 생성하고, 삭제권 (right-to-erasure) 흐름을 실행하며, 삭제된 레코드가 이후의 회상 (recall) 과정에서 나타나지 않는지 확인하고 그 결과를 문서화하십시오.

EU AI Act 고려 사항

EU AI Act (2026년 8월부터 전면 적용)는 부속서 III (Annex III)에 따라 고위험 (high-risk)으로 분류된 AI 시스템에 대해 추가적인 의무를 도입합니다. 여기에는 고용, 교육, 신용 및 법 집행 맥락에서 개인과 상호작용하는 시스템이 포함됩니다. 만약 귀하의 에이전트가 고위험 범주에 속한다면, 메모리와 상호작용하는 로깅 (logging) 및 추적 가능성 (traceability) 요구 사항이 발생합니다. 즉, 에이전트가 중대한 결정을 내렸을 때 무엇을 알고 있었는지 재구성할 수 있어야 합니다.

이는 GDPR의 삭제권 (right-to-erasure)과 긴장 관계를 형성합니다. 채용 추천의 근거가 된 메모리를 삭제하면, 해당 추천을 감사 (audit)할 수 있는 능력을 상실할 수 있기 때문입니다. 이러한 긴장 관계에 대한 법적 가이드는 여전히 발전 중입니다. 실무적인 해결책은 삭제 대상이 되는 라이브 메모리 저장소 (live memory store)와 별개로, 중대한 결정에 대해 정보 주체를 익명화한 별도의 감사 로그 (audit log)를 유지하는 것입니다.

요약 표

FAQ

AI 에이전트의 메모리를 저장하는 것이 GDPR 하에서 "개인정보 (personal data)"에 해당합니까?

만약 메모리가 식별되었거나 식별 가능한 자연인(natural person) — 즉, 그들의 선호도, 행동, 진술 또는 그들에 관한 기타 정보 —와 관련이 있다면, 네, GDPR 제4조(1)항에 따라 개인정보 (personal data)에 해당합니다.

사용자의 기기에서 에이전트를 로컬로 실행하는 경우에도 GDPR이 적용됩니까?

데이터를 오직 로컬에서만 처리하고 서버로 전송하지 않는다면, 일부 GDPR 의무(특히 하위 처리자 (sub-processors) 관련 의무)는 적용되지 않습니다. 하지만 귀하는 여전히 데이터 컨트롤러 (data controller)이며, 사용자가 요청할 경우 삭제 권리 (right to erasure)는 여전히 적용됩니다.

삭제 요청 이후에 익명화된 메모리를 보관할 수 있습니까?

만약 메모리가 가명화 (pseudonymized)된 것이 아니라 진정으로 익명화 (anonymized)되어 — 즉, 완전히 비식별화되어 — GDPR의 범위 밖에 있다면 삭제할 필요가 없습니다. 익명화의 기준은 매우 높습니다. 단일 개인과 연결된 행동 패턴을 유지하면서 이름만 제거하는 것은 익명화가 아니라 가명화 (pseudonymization)입니다.

잊힐 권리 (right to be forgotten)가 파인튜닝 (fine-tuned)된 모델에도 적용됩니까?

엄밀히 말하면 그렇습니다. 만약 파인튜닝에 개인정보가 사용되었다면, 정보 주체 (data subject)는 삭제를 요청할 수 있습니다. 실제로는 파인튜닝된 모델에서 진정한 의미의 삭제를 대규모로 수행하는 것은 아직 기술적으로 불가능합니다 (머신 언러닝 (machine unlearning)은 현재 활발히 연구 중인 분야입니다). 규제 기관들은 이에 대한 가이드를 여전히 개발 중입니다. 사실을 모델 가중치 (weights)에 직접 주입하는 대신 개별 레코드로 저장하는 에이전트 메모리 시스템의 경우, 삭제가 실행 가능합니다.

에이전트 메모리에 적용되는 보유 기간은 얼마입니까?

GDPR은 데이터가 "개인정보가 처리되는 목적을 위해 필요한 기간보다 더 오래 보관되어서는 안 된다"고 규정합니다 (제5조(1)(e)항). 귀하는 세션 전용, 90일 롤링(rolling), 또는 연례 검토를 동반한 무기한 보관 등 정의된 보유 정책 (retention policy)과 이를 집행할 메커니즘을 갖추어야 합니다.

검토일: 2026-07-18. 이 기사는 기술적 가이드를 제공하며, 법적 조언이 아닙니다. 귀하의 구체적인 사용 사례에 대해서는 자격을 갖춘 데이터 보호 전문가와 상담하십시오.