벡터 데이터베이스 개인정보 리스크: 삭제 요청은 어떻게 증명할까

벡터 데이터베이스는 문서와 사용자 데이터를 임베딩으로 변환해 의미 기반 검색을 제공한다. 숫자 배열만 보면 원문과 달라 보이지만, 임베딩은 원문에서 파생된 데이터이며 다른 메타데이터와 결합될 때 개인이나 민감 내용을 추론할 가능성이 있다. 따라서 “벡터니까 개인정보가 아니다”라고 단정하면 안 된다.

더 큰 운영 문제는 삭제다. 원문 문서를 지워도 청크, 벡터, 검색 색인, 결과 캐시, 평가 데이터, 백업에 파생 사본이 남으면 RAG 시스템이 삭제된 내용을 계속 반환할 수 있다. 삭제를 증명하려면 데이터 계보와 일관된 식별자가 필요하다.

데이터 흐름을 한 줄로 추적한다

각 데이터 단위에 다음 관계를 남긴다.

source_id -> document_version -> chunk_id -> embedding_model_version
          -> vector_id -> index_version -> cache_entry -> backup_generation

필수 메타데이터는 다음과 같다.

• 원본 시스템과 소유자
• 원본의 안정적인 식별자와 버전
• 데이터 등급과 접근 정책
• 청크 생성 규칙과 순서
• 임베딩 모델 이름·버전·파라미터
• 벡터 저장소·namespace·테넌트
• 색인 버전과 생성 시각
• 보존·삭제 기준과 법적 보존 상태

원문 해시만 저장하면 문서가 수정됐을 때 같은 대상을 찾기 어렵다. 업무 시스템의 안정적인 source_id와 버전을 함께 사용한다.

임베딩을 원문과 같은 위험 경계에서 본다

원문이 민감 또는 제한 데이터라면 벡터도 기본적으로 같은 등급을 상속한다. 특히 다음 데이터는 별도 검토가 필요하다.

• 고객지원 대화와 이메일
• 인사·평가·급여 문서
• 의료·재무·법률 기록
• 인증 비밀과 소스 코드
• 사용자 행동·검색 기록
• 여러 출처를 결합해 개인을 추론할 수 있는 프로필

모델 입력 전 불필요한 식별자를 제거하고, 검색 목적에 필요하지 않은 필드는 임베딩하지 않는다. 원문 전체를 청크 메타데이터에 복제하거나 디버그 로그에 저장하지 않는다.

접근 제어를 검색 전에 적용한다

검색 결과가 나온 뒤 애플리케이션에서만 필터링하면 권한 없는 문서가 랭킹·로그·캐시에 노출될 수 있다. 가능하면 검색 쿼리 단계에서 테넌트, 사용자 그룹, 문서 ACL, 데이터 등급을 필터링한다.

• 원본 ACL 변경을 벡터 메타데이터에 동기화한다.
• ACL이 없는 벡터는 기본 거부한다.
• 테넌트 간 namespace 또는 물리적 격리를 검토한다.
• 관리자 검색과 일반 사용자 검색을 분리한다.
• 검색 결과의 문서 ID와 적용된 권한 정책을 감사 로그에 남긴다.
• 권한 필터가 실패하면 전체 검색으로 폴백하지 않는다.

세부 설계는 RAG 접근 제어와 연결한다.

삭제 요청을 여섯 단계로 처리한다

1. 대상 확인

요청자의 신원과 권한을 확인하고 원본 시스템의 source_id, 관련 계정, 문서 범위를 식별한다. 법적 보존이나 분쟁 보존이 있는지 확인한다. 삭제 의무와 예외는 지역·계약에 따라 달라질 수 있으므로 개인정보·법률 담당자의 검토가 필요하다.

2. 즉시 검색 차단

삭제가 완료되기 전이라도 tombstone 또는 deny list를 적용해 해당 source_id와 파생 벡터가 검색 결과에 나오지 않게 한다. 이 조치는 가역적이며 조사와 승인 중 노출을 줄인다.

3. 운영 사본 삭제

원문, 청크 저장소, 벡터, 메타데이터, 결과 캐시, 프롬프트 기록, 평가 데이터에서 관련 ID를 삭제하거나 정책에 따라 비식별화한다. 일괄 재색인이 필요한 경우 작업 ID와 예상 완료 시각을 남긴다.

4. 색인 재구성 또는 정리

벡터 삭제가 즉시 색인 구조에서 제거되는지 제품 문서를 확인한다. 세그먼트 병합, compaction, 복제 지연 때문에 오래된 사본이 남을 수 있다. 필요하면 새 색인을 만들고 원자적으로 전환한다.

5. 백업·스냅샷 처리

불변 백업에서 개별 항목을 즉시 지우기 어렵다면 보존 만료 일정, 복원 시 재삭제 절차, 접근 제한을 문서화한다. 불변 백업 복구 훈련에서 삭제된 데이터가 복원 뒤 다시 서비스되지 않는지 시험한다.

6. 검증과 증거

삭제된 source_id로 직접 조회하고, 의미가 비슷한 질의로도 결과가 재등장하지 않는지 확인한다. 처리한 저장소, 시각, 작업 ID, 행·벡터 수, 검증 결과를 남기되 원문 개인정보를 증거에 다시 복제하지 않는다.

삭제 증명 레코드 예시

필드	내용
request_id	삭제 요청의 고유 ID
source_ids	대상 원본 식별자 목록
systems	원문·청크·벡터·캐시·백업 범위
tombstone_at	검색 차단 시각
deletion_jobs	각 시스템 작업 ID와 결과
index_version	삭제 후 활성 색인 버전
verification	직접·의미 검색 테스트 결과
backup_policy	남은 백업 세대와 재삭제 절차
reviewer	개인정보·시스템 소유자 승인

이 레코드는 법적 확인서의 형식을 자동으로 결정하지 않는다. 외부에 제공할 삭제 증명 내용은 개인정보·법률 담당자가 검토한다.

탐지 신호

• 원본 문서 수와 벡터의 고유 source_id 수가 맞지 않는다.
• 원본에서 삭제된 ID가 검색 결과에 나타난다.
• ACL이 없는 벡터 또는 테넌트 없는 레코드가 증가한다.
• 색인 버전 전환 뒤 오래된 replica가 계속 트래픽을 받는다.
• 삭제 작업은 성공했지만 compaction·재색인이 장기간 지연된다.
• 로그·평가 데이터에 원문이나 민감 메타데이터가 복제된다.
• 임베딩 모델 변경 뒤 전체 데이터가 승인 없이 재처리된다.
• 백업 복원 후 tombstone 목록이 적용되지 않는다.

실패 모드

실패	결과	교정
임베딩을 익명 데이터로 간주	보호·접근 정책 누락	원문 등급 상속과 위험 평가
원문만 삭제	벡터·캐시에서 계속 검색	파생 계보와 통합 삭제
검색 후 필터링	랭킹·로그에 권한 없는 결과 노출	검색 단계 ACL 필터
ID가 청크마다 임의 생성	삭제 대상 연결 불가	안정적인 source_id·버전
작업 성공만 확인	replica·색인에 잔여 데이터	직접·의미 검색 검증
백업 정책이 없음	복원 후 삭제 데이터 재등장	복원 시 재삭제 런북

운영 체크리스트

• 원문·청크·벡터·색인·캐시·백업 계보가 있다.
• 벡터가 원문의 데이터 등급과 보존 정책을 상속한다.
• 불필요한 식별자는 임베딩 전에 제거한다.
• 접근 제어가 검색 쿼리 단계에서 적용된다.
• ACL 없는 레코드는 기본 거부한다.
• 삭제 요청에 즉시 검색 차단 단계가 있다.
• 운영 저장소와 파생 사본을 함께 삭제한다.
• 재색인·replica·compaction 잔여 여부를 검증한다.
• 백업 복원 시 삭제 데이터의 재등장을 막는다.
• 삭제 증거에는 작업 ID·색인 버전·검증 결과가 남는다.

참고 기준

• NIST Privacy Framework
• NIST AI Risk Management Framework 1.0
• NIST AI 600-1: Generative AI Profile
• OWASP Top 10 for LLM Applications

결론

벡터 데이터베이스의 개인정보 보호는 벡터를 암호화하는 일만이 아니다. 원본에서 파생된 모든 사본을 식별하고, 접근 정책을 검색 전에 적용하며, 삭제 요청이 색인과 백업까지 어떻게 전달됐는지 검증하는 것이 핵심이다. 임베딩은 자동 익명화가 아니므로 원문과 같은 수준의 데이터 거버넌스가 필요하다.