blog.ruahverce Vol · 2026 · Issue 013 — A field log of LLMs, RAG, and ML systems

Field Log · Entry

RAG Deletion·Retention·Privacy Governance: Embedding까지 삭제를 증명하는 법 (9/10)

검증된 삭제 요청이 serving deny·tombstone을 적용한 뒤 raw·chunk·embedding·index·cache·snapshot으로 전파되고 hold·retention과 deletion receipt로 검증되는 RAG 절차

오늘의 결론

  • RAG에서 “문서 삭제”는 vector DB row 하나를 지우는 API 호출이 아닙니다. 원천 사본, parser 출력, chunk, embedding, sparse·vector index, cache, prompt trace, evaluation export, snapshot과 backup에 퍼진 모든 파생물을 찾고 처리하는 workflow입니다.
  • 가장 먼저 serving을 차단합니다. 검증된 deletion tombstone과 deny overlay로 retrieval·citation·cache에서 즉시 숨기고, 물리 삭제는 storage별 retention과 legal hold를 따라 추적합니다.
  • 삭제 대상 identity를 먼저 정확히 확정합니다. 이름 검색이나 fuzzy match로 다른 사람·문서를 지우지 않고, stable resource ID와 subject link provenance를 사용합니다.
  • Legal hold와 retention은 삭제를 무시하는 예외 flag가 아닙니다. 요청 근거, hold authority, 범위, 승인과 해제 조건을 법무·privacy owner가 결정하고 시스템은 serving restriction과 보존 상태를 분리해 기록합니다.
  • 완료는 “job success”가 아니라 source·derived artifact·active index·cache·restore 경로와 third party를 검증한 deletion receipt로 증명합니다. Backup이 만료 전 남는다면 그 상태와 재노출 방지 통제를 명시합니다.

앞 글에서는 lineage로 input→artifact→index의 영향 범위를 계산했습니다. 삭제도 같은 lineage를 역으로 따라가야 누락된 vector와 오래된 cache를 찾을 수 있습니다.

중요: 이 글은 소프트웨어·데이터 엔지니어링 설계 자료이며 법률 자문이 아닙니다. 적용 법률, 삭제 근거, 예외, 보존 기간과 통지 의무는 관할권·계약·산업 규제에 따라 privacy·법무 담당자와 결정해야 합니다.

verified request and authoritative scope
  → immediate serving restriction
  → durable tombstone
  → lineage fan-out to every derived artifact
  → storage-specific purge or retained-under-hold state
  → restore-safe verification
  → minimal deletion receipt

검증된 삭제 요청이 serving deny와 tombstone을 거쳐 raw·parsed·chunk·embedding·index·cache·trace·snapshot으로 전파되고 legal hold·retention을 평가한 뒤 synthetic probe와 restore rehearsal로 검증되는 RAG deletion pipeline

먼저 답하기: embedding은 원문이 아니니 남겨도 되는가?

기술적으로 embedding은 원문과 다른 수치 표현입니다. 그러나 다음 질문에 답하기 전 “무조건 익명”이라고 단정하면 안 됩니다.

  • Stable document·subject ID와 연결되어 있는가?
  • Metadata나 vector payload로 원천 대상을 다시 찾을 수 있는가?
  • Model·attack 조건에서 membership·attribute inference 위험이 있는가?
  • 동일 vector가 query·cache·evaluation export에 복제됐는가?
  • 조직의 privacy inventory와 삭제 결정이 derived representation을 포함하는가?

엔지니어링 기본값은 삭제 scope에 포함된 content에서 파생된 embedding을 추적 가능한 artifact로 취급하고 함께 제거하는 것입니다. 최종 법적 분류와 의무는 담당자 판단을 따릅니다.

이 글의 대상과 학습 시간

  • 대상: 사내 RAG, 고객별 knowledge base, support Agent의 data lifecycle을 운영하는 초·중급 개발자
  • 선수 지식: stable ID, lineage, tombstone, snapshot·backup의 기본 개념
  • 빠르게 읽기: 약 13분
  • 삭제 state machine까지 이해하기: 약 40분
  • restore rehearsal 포함: 반나절 이상

1. Privacy lifecycle은 수집 전에 시작한다

삭제를 잘하려면 무엇을 왜 보유하는지 먼저 알아야 합니다.

Data inventory

Data class예OwnerPurposeRetentionDerived outputs
Source document상담 기록 PDFSupport내부 검색정책별parse, chunk, vector
Metadataauthor, customer IDData ownerfilter·citation정책별index payload
Query log사용자 질문Product품질 개선짧게trace, evaluation
Feedbackrating, correctionProduct평가동의·정책별gold set
Answer cachecontext 포함 답변PlatformlatencyTTLcache replica
Audit receipt삭제 workflow 증거Privacycompliance별도 정책report

System schema에 legal conclusion을 하드코딩하지 않더라도, data class별 processing purpose와 policy reference를 연결합니다.

{
  "data_class": "support_transcript",
  "purpose_ids": ["internal_support_search"],
  "policy_ref": "privacy-policy-2026-04",
  "retention_rule_id": "ret-support-24m",
  "subject_link_method": "customer_account_id",
  "owner": "support-data-owner"
}

NIST Privacy Framework는 조직이 privacy risk를 식별하고 관리하도록 돕는 자발적 프레임워크입니다. 특정 법률 준수를 자동 보증하지는 않지만 data processing inventory, governance, control과 communication을 구조화하는 참고점이 됩니다.

2. 삭제 대상의 단위를 먼저 정의한다

“사용자 A를 삭제”에는 여러 scope가 있을 수 있습니다.

  • 특정 source document 한 개
  • Document 안 특정 subject span
  • Customer account와 연결된 모든 record
  • 특정 purpose에서만 processing 중단
  • Query·feedback history
  • Tenant 전체 offboarding
  • 잘못 수집된 field만 정정·제거

삭제 API는 scope를 명시해야 합니다.

{
  "request_id": "delreq-7712",
  "request_type": "erase",
  "subject_id": "subject-cust-884",
  "scope": {
    "data_classes": ["support_transcript", "query_feedback"],
    "purposes": ["internal_support_search"],
    "tenants": ["tenant-support-a"],
    "time_range": null
  },
  "received_at": "2026-07-16T05:00:00Z",
  "authority_ref": "privacy-case-2188"
}

Raw email이나 주민번호를 workflow key로 복제하지 않고 verified subject token이나 internal stable ID를 사용합니다.

3. Identity verification과 authorization을 분리한다

삭제 요청을 받았다고 바로 실행하지 않습니다.

Requester verification

  • 요청자가 누구인지
  • Subject 자신인지 authorized agent인지
  • Tenant·account scope가 맞는지
  • 요청 channel과 assurance level

Decision authorization

  • 어떤 data class가 scope인지
  • 삭제, 정정, processing restriction 중 무엇인지
  • 예외 또는 보존 의무가 있는지
  • Third-party processor 통지가 필요한지
  • 승인자가 누구인지

개발자가 ticket 문구만 보고 법적 근거를 추론하지 않습니다. Privacy workflow가 machine-readable decision을 발행하고 deletion engine은 이를 집행합니다.

4. GDPR Article 17을 engineering requirement로 단순화하지 않는다

EU GDPR Article 17은 특정 근거가 적용될 때 개인 데이터 삭제를 지체 없이 요구받을 권리와 controller의 삭제 의무를 규정하며, 같은 조항에는 적용 예외도 있습니다. Article 19는 일정한 경우 정정·삭제·처리 제한을 recipient에게 알리는 의무를 다룹니다.

이를 “모든 요청은 즉시 모든 backup bit 삭제” 같은 한 줄 규칙으로 번역하면 실제 법률·기술 맥락을 놓칩니다.

엔지니어가 제공할 것은 다음입니다.

  • Data location과 processor inventory
  • Stable targeting과 lineage
  • Immediate serving restriction
  • Storage별 purge capability·retention
  • Exception·hold state
  • Recipient notification task
  • Completion evidence와 residual risk

최종 결정은 관할권과 사실관계를 아는 담당자가 내립니다.

5. Deletion state machine을 명시한다

RECEIVED
  → IDENTITY_VERIFIED
  → SCOPE_APPROVED
  → SERVING_BLOCKED
  → PROPAGATING
  → VERIFYING
  → COMPLETED

alternative:
  ON_HOLD
  RESTRICTED_NOT_ERASED
  REJECTED_WITH_REASON
  PARTIALLY_COMPLETE_BACKUP_PENDING

각 전이는 actor, timestamp, decision revision과 evidence를 가집니다.

{
  "request_id": "delreq-7712",
  "from": "SCOPE_APPROVED",
  "to": "SERVING_BLOCKED",
  "at": "2026-07-16T05:04:12Z",
  "actor": "deletion-controller-v3",
  "decision_revision": "privacy-decision-18",
  "evidence": ["deny-overlay:do-991", "probe-run:pr-771"]
}

“실패” 하나로 끝내지 않고 retryable, held, manual review와 permanent policy conflict를 구분합니다.

6. Serving restriction을 물리 삭제보다 먼저 한다

삭제 job이 수시간 걸려도 RAG가 계속 answer를 만들면 안 됩니다.

Immediate deny overlay

deny subject-linked resource IDs
deny document/version/chunk IDs
invalidate retrieval and answer cache
deny citation fetch
exclude from evaluation export jobs

Tombstone

{
  "tombstone_id": "tomb-991",
  "scope_id": "subject-cust-884",
  "resource_ids": ["doc-19", "doc-87"],
  "source_sequence": "privacy-case-2188",
  "effective_at": "2026-07-16T05:04:00Z",
  "reason_code": "approved_erasure",
  "request_id": "delreq-7712",
  "status": "serving_blocked"
}

Tombstone에는 원문 personal data를 넣지 않고 stable opaque ID와 최소 evidence만 둡니다.

7. Tombstone은 재수집과 복원을 막는다

다음 사건이 문서를 부활시킬 수 있습니다.

  • 늦게 도착한 old CDC update
  • Periodic full crawl
  • Index rollback
  • Backup restore
  • Migration backfill
  • Evaluation dataset 재수입
  • 다른 source에서 같은 문서 재발견

모든 ingestion은 active tombstone registry를 확인합니다.

def ingest(event):
    tombstone = tombstones.match(
        resource_id=event.resource_id,
        subject_links=event.subject_links,
        source_locator=event.source_locator,
    )
    if tombstone and event.source_sequence <= tombstone.source_sequence:
        return quarantine("blocked_by_tombstone", tombstone.id)
    return process(event)

새로운 lawful source event가 tombstone을 해제할 수 있는지는 privacy decision workflow만 결정합니다. Worker가 timestamp가 새롭다는 이유로 자동 부활시키지 않습니다.

8. Lineage로 deletion graph를 만든다

subject_id
  → source resources
  → raw objects and versions
  → parsed blocks / OCR text / tables
  → canonical documents and metadata assertions
  → chunks and embeddings
  → sparse/vector index rows
  → retrieval / answer caches
  → traces / feedback / evaluation exports
  → snapshots / backups / third-party processors

각 edge에 discovery method와 confidence를 둡니다.

{
  "from": "subject-cust-884",
  "to": "doc-19",
  "relation": "data_subject_of",
  "method": "verified_customer_account_id",
  "confidence": 1.0,
  "assertion_revision": "link-291"
}

LLM entity extraction으로 subject link를 제안했다면 사람 검수·source span과 confidence가 필요합니다. False positive 삭제는 다른 사람의 기록을 훼손할 수 있습니다.

9. Exact deletion과 subject discovery를 분리한다

Exact artifact deletion

Stable resource·version·chunk ID가 이미 주어진 경우 결정적입니다.

Subject discovery

Subject와 관련된 artifact를 찾는 단계입니다.

  • Verified account ID join
  • Source system subject index
  • Structured metadata
  • Deterministic tokenized identifier
  • Reviewed entity link
  • Text search candidate

자유 text name search는 candidate discovery로만 사용합니다. 동명이인, alias, OCR 오류와 다른 사람 언급이 있기 때문입니다.

discover candidates
  → evidence review / deterministic rule
  → approved resource set manifest
  → execute exact deletion

10. Deletion manifest를 immutable하게 고정한다

{
  "manifest_id": "delman-7712-v2",
  "request_id": "delreq-7712",
  "decision_revision": "privacy-decision-18",
  "created_at": "2026-07-16T05:03:00Z",
  "targets": {
    "source_resources": ["src-19", "src-87"],
    "raw_objects": ["raw-881", "raw-992"],
    "canonical_versions": ["ver-19-4", "ver-87-2"],
    "chunk_ids": ["chunk-set-ref:cs-771"],
    "index_generations": ["g1", "g2"],
    "cache_namespaces": ["retrieval", "answer"],
    "processor_tasks": ["proc-44"]
  },
  "holds": [],
  "scope_hash": "sha256:..."
}

대상이 조사 중 바뀌면 v3 manifest를 만들고 history를 보존합니다. 누가 어떤 scope를 승인했는지 설명할 수 있습니다.

11. Storage별 deletion adapter를 둔다

하나의 delete_everywhere() 함수 안에 vendor logic을 숨기지 않습니다.

class DeletionAdapter:
    def plan(self, manifest): ...
    def restrict(self, manifest): ...
    def execute(self, manifest): ...
    def verify(self, manifest): ...
    def evidence(self, manifest): ...

Adapter 예:

  • Source DMS
  • Object storage raw zone
  • Canonical table
  • Metadata assertion store
  • Vector database
  • Sparse search index
  • Redis/cache
  • Trace store
  • Evaluation warehouse
  • Backup catalog
  • External model/provider

각 adapter가 hard delete, tombstone, TTL expiry, legal hold와 unsupported 상태를 명시합니다.

12. Raw·parsed·chunk·embedding을 함께 처리한다

Raw object

  • Object version ID별 처리
  • Replication destination
  • Multipart·temporary object
  • Lifecycle rule
  • Object lock·retention 확인

Parsed representation

  • OCR text
  • Page image
  • Table JSON
  • Layout block
  • Parser cache

Canonical metadata

  • Subject assertion
  • Alias·entity link
  • Provenance span
  • Data quality sample

Chunks and embeddings

  • 모든 active·candidate generation
  • Old rollback index
  • Migration staging
  • Batch file·embedding response cache
  • Sparse and vector records

Document row만 지우고 chunk foreign key cascade를 기대하지 않습니다. 외부 vector store와 object storage는 별도 system입니다.

13. Index deletion은 active alias만 보면 안 된다

삭제 대상이 존재할 수 있는 generation:

  • Current active
  • Candidate migration
  • Rollback-retained old index
  • Shadow test index
  • Offline evaluation index
  • Disaster recovery replica

Generation registry에서 physical target을 찾습니다.

for generation in registry.generations_containing(resource_id):
  generation.delete(resource_id, chunk_ids)
  generation.refresh_or_wait_visibility()
  assert generation.search_exact(marker) == []

Vector 삭제 후 search visibility가 언제 바뀌는지 engine consistency를 확인합니다. API 200만으로 완료 처리하지 않습니다.

14. Cache와 answer artifact를 잊지 않는다

삭제 대상 content가 남는 곳:

  • Retrieval result cache
  • Rerank cache
  • Prompt/context cache
  • Generated answer cache
  • Citation preview cache
  • Browser/CDN cache
  • Session memory
  • Agent long-term memory
  • Feedback screenshot·export

Cache key가 context IDs와 generation을 포함하면 targeted invalidation이 쉽습니다. 그렇지 않으면 namespace flush와 TTL을 조합합니다.

삭제 후 과거 answer를 다시 보여 줄 수 있는 product history가 있다면 별도 processing purpose·retention을 검토합니다.

15. Trace·log·evaluation dataset도 data store다

Observability가 privacy blind spot이 되기 쉽습니다.

기본 원칙

  • Query·chunk 원문을 default log에 넣지 않음
  • Principal은 scoped pseudonymous ID
  • Protected trace와 운영 metric 분리
  • Short retention
  • Access audit
  • Deletion subject link 또는 lookup token

Evaluation export

Production query·answer를 offline gold set으로 복제했다면 lineage edge를 남깁니다. Export가 notebook, analyst local file, BI extract로 이동하면 processor inventory와 삭제 automation 범위를 넓혀야 합니다.

16. Third-party processor task를 추적한다

Embedding·LLM provider, managed search, annotation vendor와 support SaaS가 데이터를 받았을 수 있습니다.

{
  "processor_task_id": "proc-44",
  "processor": "managed-model-provider",
  "data_scope": "embedding_requests_for_doc-19",
  "contract_ref": "dpa-2026-11",
  "request_sent_at": "2026-07-16T05:10:00Z",
  "acknowledged_at": null,
  "status": "pending",
  "evidence_ref": null
}

Provider가 input을 보관하지 않는 계약이라면 그 설정·contract revision을 receipt에 연결합니다. “API라서 저장하지 않는다”고 가정하지 않습니다.

17. Retention schedule은 data class별이다

retention:
  raw_source_copy:
    rule: source_policy
  parsed_artifact:
    rule: source_plus_7_days
  answer_cache:
    rule: ttl_24_hours
  protected_trace:
    rule: ttl_14_days
  deletion_receipt:
    rule: compliance_record_policy
  backup:
    rule: rolling_35_days

모두 예시입니다. “RAG 데이터 1년” 같은 global 기간은 목적과 위험이 다른 data를 섞습니다.

Retention expiry는 정기 job과 verification report를 가져야 합니다. Policy가 있어도 lifecycle rule이 잘못 설정되면 실제 삭제되지 않습니다.

Legal hold는 특정 artifact를 보존해야 하는 decision일 수 있습니다. AWS S3 Object Lock 문서처럼 storage 기능은 retention period와 legal hold를 별도 개념으로 제공하며, legal hold는 명시적으로 제거될 때까지 특정 object version을 보호할 수 있습니다.

RAG workflow에서 확인할 것:

  • Hold authority와 case ID
  • 적용 대상 object version·data class
  • 시작·review·release 조건
  • 보존 중 serving 허용 여부
  • Access restriction
  • Hold 해제 후 pending deletion 재개
ON_HOLD does not imply searchable

physical object retained under approved hold
  + retrieval/citation denied
  + access restricted to authorized case workflow

Hold 대상과 deletion manifest가 충돌하면 automation이 임의 선택하지 않고 privacy·legal owner에게 escalation합니다.

19. Snapshot과 time travel은 삭제 지연을 만든다

Apache Iceberg는 write마다 table snapshot을 만들고 time-travel·rollback에 사용할 수 있습니다. Maintenance 문서는 snapshot이 expire operation 전까지 누적되며, snapshot expiry가 더 이상 필요 없는 data file 삭제와 metadata 관리에 필요하다고 설명합니다.

현재 row에서 삭제해도 이전 snapshot이 file을 참조할 수 있습니다.

따라서 receipt에 다음을 둡니다.

serving_current_state: deleted
historical_snapshot_state: pending_expiration
earliest_physical_expiration_at: ...
hold_state: none / active
restore_control: tombstone replay required

Snapshot retention을 줄이면 rollback·audit 요구와 충돌할 수 있습니다. Data class별 policy를 적용하고 privacy owner와 platform owner가 합의합니다.

20. Backup은 “나중에 자연 삭제”만으로 끝내지 않는다

Backup 전략에서 답할 질문:

  • Backup set의 retention과 immutable 기간
  • Selective delete 지원 여부
  • 암호화 key granularity
  • Restore 권한과 승인
  • Restore 후 tombstone 재적용 순서
  • Backup catalog에서 대상 존재 추적 가능성
  • Disaster recovery rehearsal

Restore-safe sequence

restore into isolated environment
  → apply latest tombstone registry
  → apply retention and hold decisions
  → run deletion probes
  → only then allow serving or replication

Backup에 대상이 남아도 production으로 다시 노출되지 않게 하는 compensating control입니다. 그 상태가 법적 요구에 충분한지는 담당자 판단이 필요합니다.

21. Cryptographic erasure를 사용할 때의 조건

Data가 unique envelope key로 암호화돼 있고 key를 안전하게 제거하면 복호화 불가능하게 만드는 방법을 고려할 수 있습니다.

하지만 다음을 확인해야 합니다.

  • Key가 삭제 scope별로 충분히 세분화됐는가?
  • Plaintext·derived copy가 다른 곳에 없는가?
  • Key backup과 escrow도 처리되는가?
  • Provider가 key destruction evidence를 주는가?
  • Metadata만으로도 민감 정보가 남지 않는가?
  • 적용 규정과 조직 정책이 이를 인정하는가?

Tenant 전체 key 하나로 여러 subject를 묶으면 한 subject만 지우기 어렵습니다. Crypto erasure를 만능 해법으로 두지 않습니다.

22. Deletion receipt는 최소 정보로 증명한다

Receipt에 삭제한 personal data 원문을 다시 복제하면 안 됩니다.

{
  "receipt_id": "delrec-7712",
  "request_id": "delreq-7712",
  "scope_hash": "sha256:...",
  "decision_revision": "privacy-decision-18",
  "serving_blocked_at": "2026-07-16T05:04:12Z",
  "systems": [
    {"name": "vector-g2", "status": "verified_absent", "at": "2026-07-16T05:12:00Z"},
    {"name": "answer-cache", "status": "invalidated", "at": "2026-07-16T05:05:00Z"},
    {"name": "backup-rolling", "status": "pending_expiry", "deadline": "2026-08-20"}
  ],
  "holds": [],
  "verification_run_ids": ["verify-118"],
  "completed_state": "PARTIALLY_COMPLETE_BACKUP_PENDING",
  "signed_by": "deletion-controller-v3"
}

Receipt 접근 자체를 통제하고 retention을 별도로 정합니다.

23. Verification은 negative probe와 restore rehearsal로 한다

Store-level

  • Exact resource ID absent
  • Chunk ID set absent
  • Vector payload absent
  • Cache keys absent
  • Source/object versions 상태

Serving-level

  • Lexical marker query 0
  • Dense paraphrase query 0
  • Metadata filter 0
  • Citation fetch deny
  • Agent memory lookup 0
  • Old answer cache miss

Security

  • Cross-generation search 0
  • Shadow index 0
  • Admin preview policy대로 deny
  • Evaluation export status

Restore

  • Isolated backup restore
  • Tombstone replay
  • Target remains unsearchable

API response code가 아니라 사용자가 접근할 수 없는 상태를 확인합니다.

24. Deletion SLO를 단계별로 둔다

SLI의미예시 목표
Decision latency요청→scope 승인정책별
Serving block latency승인→retrieval 0p99 60초
Active store purge latency승인→active system 삭제p99 24시간
Processor acknowledgement통지→확인계약별
Backup expiry completion승인→잔존 backup 만료retention별
Resurrection violations삭제 후 재노출0

숫자는 예시입니다. Legal deadline과 조직 risk는 privacy·legal owner가 정합니다.

25. Failure와 retry를 idempotent하게 만든다

동일 request가 재실행돼도 안전해야 합니다.

def delete_target(target, request_id):
    current = ledger.status(request_id, target)
    if current == "verified_absent":
        return current

    adapter = adapters[target.system]
    adapter.restrict(target)
    adapter.execute(target)
    result = adapter.verify(target)
    ledger.record(request_id, target, result)
    return result

Partial failure는 system별 ledger에 남기고 exponential backoff, manual queue와 deadline alert를 둡니다. Unknown 상태를 complete로 취급하지 않습니다.

26. 삭제 테스트용 synthetic subject를 둔다

Production personal data로 rehearsal하지 않습니다.

subject: SYNTH_PRIVACY_7Q2
source document marker: DEL_CANARY_DOC_91K
chunk marker: DEL_CANARY_CHUNK_31P
query marker: DEL_CANARY_QUERY_82M

Rehearsal:

  1. Synthetic subject를 source→index→cache→trace까지 의도적으로 흘립니다.
  2. Approved deletion request를 생성합니다.
  3. Serving block 시간을 측정합니다.
  4. 모든 adapter와 third-party mock을 확인합니다.
  5. Old index·candidate·cache·evaluation export를 probe합니다.
  6. Backup restore 후 tombstone을 재적용합니다.
  7. Receipt completeness를 검증합니다.

27. 가상 반도체 지원 RAG 예시

다음은 설명을 위한 가상 예시입니다.

상황

외부 vendor engineer의 이름·연락처가 maintenance report, OCR 표, incident chat와 query feedback에 들어 있습니다. 계약 종료 후 승인된 삭제·처리 제한 decision이 도착했습니다.

위험한 구현

  • DMS PDF만 삭제
  • Vector index old rollback generation에 embedding 잔존
  • Citation preview cache에서 이름 노출
  • Evaluation notebook export에 query feedback 잔존
  • 다음 full crawl이 backup PDF를 다시 수집

개선 workflow

  1. Verified vendor subject ID와 source account link로 candidate를 찾습니다.
  2. Privacy reviewer가 다른 작업자 언급과 동명이인을 제외한 manifest를 승인합니다.
  3. Resource·subject deny overlay로 retrieval·citation을 차단합니다.
  4. Active·candidate·rollback index와 cache를 함께 처리합니다.
  5. OCR·chunk·embedding·feedback export lineage를 따라갑니다.
  6. Hold 대상 incident record는 physical retained·serving denied로 기록합니다.
  7. Backup expiry deadline과 restore tombstone을 receipt에 둡니다.
  8. Name, employee code paraphrase와 citation ID로 negative probe를 실행합니다.

이 예시는 실제 법적 판단이 아니라 system coverage를 설명하기 위한 가상 시나리오입니다.

28. 구현 순서

1단계. Inventory와 retention map

Source, derived artifact, cache, telemetry, export, snapshot, backup과 processor를 data class별로 목록화합니다.

2단계. Privacy decision contract

Verified subject, request type, scope, authority, exception·hold와 deadline을 machine-readable하게 받습니다.

3단계. Stable identity와 lineage

Subject→resource→derived artifact 관계를 provenance와 함께 구축합니다.

4단계. Serving deny와 tombstone

승인 직후 retrieval·citation·cache를 막고 resurrection을 방지합니다.

5단계. Storage adapters

각 system의 restrict·delete·verify·evidence와 unsupported state를 구현합니다.

6단계. Snapshot·backup·processor workflow

Expiry, hold, notification, acknowledgement와 restore control을 추적합니다.

7단계. Verification과 receipt

Exact lookup, semantic probe, citation, old generation과 restore rehearsal 결과를 최소 receipt에 서명합니다.

8단계. Periodic synthetic rehearsal

누락된 새 store와 broken adapter를 production incident 전에 찾습니다.

실전 체크리스트

  • Data inventory에 raw, derived, cache, telemetry, export, snapshot과 backup이 있다.
  • Data class마다 purpose, owner, retention과 processor가 있다.
  • 이 글의 구현이 법률 자문을 대체하지 않음을 명확히 한다.
  • Requester verification과 deletion decision authorization이 분리돼 있다.
  • 삭제·정정·processing restriction·tenant offboarding scope를 구분한다.
  • Raw identifier 대신 verified stable subject ID를 workflow key로 쓴다.
  • State machine에 serving blocked, hold, backup pending과 complete가 있다.
  • 승인 직후 physical purge보다 serving restriction이 먼저 실행된다.
  • Durable tombstone이 old event·crawl·restore·backfill resurrection을 막는다.
  • Subject discovery와 exact artifact deletion이 분리돼 있다.
  • Fuzzy name·LLM entity match만으로 삭제하지 않는다.
  • Immutable deletion manifest와 scope hash가 있다.
  • Source·raw·parsed·metadata·chunk·embedding을 모두 추적한다.
  • Active·candidate·rollback·shadow index를 모두 처리한다.
  • Retrieval·rerank·answer·citation cache가 invalidation된다.
  • Trace·log·feedback·evaluation export가 privacy inventory에 있다.
  • Third-party processor task와 acknowledgement를 추적한다.
  • Legal hold authority·scope·release가 deletion과 별도 상태다.
  • Hold 중에도 serving deny를 독립 적용할 수 있다.
  • Snapshot expiry와 physical file deletion 차이를 이해한다.
  • Backup restore 전 tombstone replay와 probe가 강제된다.
  • Crypto erasure의 key granularity와 copy coverage를 검증한다.
  • Receipt가 원문을 복제하지 않고 최소 evidence만 가진다.
  • Exact·lexical·dense·citation·old generation negative probe가 있다.
  • Partial failure는 unknown으로 남고 retry·deadline alert가 있다.
  • Synthetic subject로 정기 end-to-end rehearsal한다.

스스로 확인하기

Q1. Source 문서를 지우면 downstream은 다음 sync 때 자동 삭제되지 않는가?

Connector가 delete를 명시적으로 전달하고 모든 downstream이 tombstone을 처리한다는 보장이 있어야 합니다. Cache, old index와 offline export는 별도 경로일 수 있어 검증이 필요합니다.

Q2. 개인정보 문자열이 없는 embedding도 항상 삭제해야 하는가?

법적 결론은 상황에 따라 다릅니다. 엔지니어링 관점에서는 source와 연결된 derived artifact로 inventory하고 privacy decision scope에 따라 처리하는 것이 안전합니다. 자동 익명으로 가정하지 않습니다.

Q3. Backup에서 즉시 selective delete가 불가능하면 완료할 수 없는가?

Retention 만료, 접근 격리, restore-time tombstone과 crypto erasure 같은 통제를 문서화할 수 있지만, 법적 충분성은 담당자가 판단해야 합니다. Receipt는 backup pending과 deadline을 숨기지 않아야 합니다.

아닙니다. 물리 보존과 serving access는 다른 정책입니다. Hold 대상은 승인된 case workflow에만 제한하고 일반 retrieval·citation에서는 차단할 수 있습니다.

Q5. Deletion receipt에 삭제 대상 email을 넣으면 추적하기 쉽지 않은가?

Receipt가 새로운 personal data copy가 됩니다. Opaque request·subject ID, scope hash와 protected case reference를 사용합니다.

Q6. Tombstone은 언제 삭제하는가?

Source 재수집, old backup·index와 replay 가능 기간을 고려해야 합니다. 너무 일찍 제거하면 resurrection을 막지 못합니다. Tombstone 자체의 최소 정보·retention은 privacy와 platform owner가 정합니다.

마무리

RAG deletion의 성공 기준은 삭제 API 호출 횟수가 아니라 사용자가 어떤 query·citation·restore 경로에서도 대상 정보를 다시 받지 못하고, 남은 보존 상태와 근거를 설명할 수 있는 것입니다.

verified scope and stable identity
  + immediate serving restriction
  + durable anti-resurrection tombstone
  + lineage-driven derived artifact purge
  + hold and retention-aware storage handling
  + negative probes, restore tests and minimal receipt
  = auditable RAG data deletion

다음 글 Production Knowledge Base Release Runbook에서는 이번 시리즈의 lifecycle·parser·identity·metadata·ACL·freshness·migration·quality·deletion을 하나의 build, validate, canary, activate, rollback 운영 절차로 묶습니다.

참고문헌

검증 메모 — 법령·공식 문서는 2026년 7월 16일 확인했습니다. 이 글은 법률 자문이 아니며 GDPR 적용 여부, Article 17의 근거·예외, recipient 통지, legal hold와 backup 처리의 충분성을 판단하지 않습니다. 본문의 subject, retention, SLO와 system은 가상 예시입니다. 실제 구현은 privacy·법무·security·data owner가 승인한 decision contract를 사용하고, 격리된 synthetic subject로 source, active·old index, cache, telemetry, processor, snapshot·backup restore와 resurrection path를 반복 검증해야 합니다.