만약 귀하의 조직이 제로 데이터 보관 (Zero-Data-Retention, ZDR) 계약 하에 Claude를 운영하고 있다면, claude-fable-5에 대한 첫 번째 요청은 완료(completion)를 반환하지 않았을 것입니다. 대신 400 invalid_request_error를 반환했을 것입니다. 이것은 서비스 장애가 아니라 정책 때문입니다. Fable 5는 30일 데이터 보관 (30-day data retention) 없이는 사용할 수 없는 최초의 일반 공개 Claude 모델이며, 이 요구 사항은 모든 플랫폼에 적용됩니다. 즉, Claude API, AWS Bedrock, Google Vertex AI, 그리고 Microsoft Foundry는 각각 명시적인 보관 옵트인 (opt-in)을 통해 이 모델의 사용을 제한합니다.

"우리는 귀하의 데이터를 보관하지 않는다"를 자신들의 LLM 스택의 확정된 속성으로 간주했던 팀들에게, 이는 아키텍처 측면의 중대한 사건입니다. 이 포스트에서는 해당 정책이 무엇을 말하는지, 왜 이러한 기간이 존재하는지, 각 클라우드가 이를 어떻게 구현하는지, 그리고 소비자 제품과 민감 데이터 산업에 어떤 변화를 가져오는지 다룹니다.

정책 세부 사항은 2026-06-12에 Anthropic, AWS, Google, Microsoft의 공개 문서를 바탕으로 확인되었습니다. 정책은 변경될 수 있으므로, 연결된 기본 소스 및 귀하의 계약 내용을 통해 확인하십시오. 본 내용은 엔지니어링 개요이며, 법률 자문이 아닙니다.

정책의 실제 내용

Anthropic은 Claude Fable 5와 Claude Mythos 5를 대상 모델 (Covered Models)로 지정합니다. API 데이터 보관 문서 (API data retention docs) 및 Mythos 클래스 보관 관행 문서 (Mythos-class retention practices article) (2026-06-09 발효)에 따르면:

• 프롬프트와 완성된 내용은 30일 동안 보관되며, 그 후 자동으로 삭제됩니다 — 활성 안전 조사 플래그가 지정되었거나 법적으로 요구되는 경우가 아니라면.
• 거부할 수 있는 옵션이 없습니다. 데이터 보존은 모델을 사용하는 조건입니다. 보존 구성이 요구 사항을 충족하지 못하는 조직의 요청은 400 invalid_request_error를 반환합니다.
• 접근은 설계상 제한적입니다. 자동화된 안전 시스템이 데이터를 검토하며; 승인된 소수의 인원만이 플래그가 지정된 대화를 검토할 수 있고, 이를 내보내거나(export), 복사하거나(copy), 다운로드할 수 없으며, 모든 접근 기록은 위변조 방지 로그에 남습니다.
• 기존 ZDR 계약은 Covered Model 트래픽으로 승계되지 않습니다 — 클라우드 플랫폼을 통한 경우를 포함하여.

개인 사용자 플랜(Claude Free/Pro/Max)에는 영향을 미치지 않으며 — 이들은 이미 자체적인 보존 약관에 따라 운영됩니다. 이 정책은 상업용 API 표면을 대상으로 하며, 바로

사람들을 놀라게 하는 기존의 한 가지 주의 사항은 다음과 같습니다. ZDR (Zero Data Retention) 하에서도 Anthropic은 안전 분류기 (safety classifier) 결과를 보유하며, 이용 정책 (Usage Policy) 위반으로 플래그가 지정된 콘텐츠는 최대 2년 동안 보관될 수 있습니다. 데이터 제로 보관 (Zero data retention)이 데이터가 전혀 없음을 의미하는 것은 아닙니다. 이는 일반적인 경로에서 플래그가 지정되지 않은 콘텐츠에 대해 보관을 하지 않는다는 것을 의미합니다.

동일한 요구 사항, 세 개의 클라우드, 세 가지 메커니즘

보관 정책은 모델이 실행되는 모든 곳에 적용되지만, 각 플랫폼은 옵트인 (opt-in) 방식을 다르게 연결합니다. 그리고 이러한 차이가 누가 귀하의 데이터를 처리하고 귀하의 제어 권한이 어디에 위치할지를 결정합니다.

플랫폼	옵트인 메커니즘	범위	옵트인 미설정 시
Claude API	개인정보 보호 제어 (Privacy controls) 내 30일 보관	조직 또는 워크스페이스	400 invalid_request_error
...
AWS Bedrock은 가장 명시적입니다. 데이터 보관은 설정 가능한 모드 (default / provider_data_share / none)이며, 프로젝트 → 계정 → 모델 기본값 순으로 결정됩니다. Fable 5는 allowed_modes: ["provider_data_share"]를 선언합니다. 즉, 프롬프트 (prompts)와 완성된 텍스트 (completions)가 Anthropic과 공유되며 최대 30일 동안 보관됩니다. 다른 모드에서는 다음과 같습니다:

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
...

Fable-5 이전 모델들에 대해서는 변경된 사항이 없으며, bedrock:DataRetentionMode 조건 키에 대한 SCP (Service Control Policy)를 통해 조직 전체에 귀하의 보안 태세를 강제할 수 있습니다. 즉, 아무도 새로운 모델을 테스트하기 위해 몰래 계정 설정을 변경할 수 없습니다. 참고: 교차 리전 추론 (cross-region inference)을 사용하는 경우, 보관된 복사본은 대상 (destination) 리전에 존재하며, 이는 데이터 거주성 (residency) 약속을 준수해야 하는 경우 중요하게 작용합니다.

Google Vertex AI는 Google의 Fable 5 문서에 따라, 프로젝트 수준의 Anthropic 데이터 공유 설정(dataSharingEnabledProvider: "anthropic"를 포함한 setPublisherModelConfig) 및 Model Garden에서의 약관 동의를 통해 모델에 대한 접근을 제어합니다. 일반적인 데이터 처리 방식은 Vertex AI의 데이터 거버넌스 정책을 따릅니다. 거주성 (residency)에 민감한 워크로드의 경우, Vertex의 리전 및 멀티 리전 엔드포인트(endpoints)가 추론 (inference)이 실행되는 위치를 제어하며, 여기에는 이제 보관된 복사본이 저장되는 위치도 포함됩니다.

Microsoft Foundry는 구조적으로 다릅니다. Microsoft의 데이터 및 개인정보 보호 문서는 Claude 모델이 제3자 마켓플레이스 서비스임을 명시하고 있습니다. 즉, 배포 시 Anthropic의 약관에 동의하게 되며, **Microsoft가 아닌 Anthropic이 데이터 처리자 (data processor)**가 됩니다. Azure OpenAI의 ZDR 및 수정된 남용 모니터링 (abuse-monitoring) 프로그램은 Claude 배포에는 적용되지 않습니다. 다른 곳에서 ZDR 태세를 유지하는 조직은 일반적으로 대상 모델 (Covered Model) 사용을 전용 구독 (subscription)으로 격리하며, 이를 통해 데이터 보관 경계를 절차적인 방식이 아닌 구조적인 방식으로 설정합니다.

세 곳 모두에서 나타나는 패턴은 다음과 같습니다: 보관 클래스 (retention class)가 계약서의 한 단락이 아니라, 모드 (mode), 플래그 (flag), 약관 게이트 (terms gate)와 같은 일급 객체이자 기계 판독 가능한 모델 속성 (model attribute)이 되었다는 점입니다. 이제 귀하의 인프라가 데이터 태세 (data posture)를 강제할 수 있으며, 마땅히 그렇게 해야 합니다.

기업 배포에 미치는 의미

ZDR 합의가 없는 경우, 기계적으로 변하는 것은 없습니다. 귀하는 이미 인지하지 못한 채 30일 스타일의 태세를 유지하고 있었을 것입니다. 해야 할 일은 이를 벤더 문서에 명시적 (explicit) 으로 만드는 것입니다.

ZDR 합의가 있는 경우, 세 가지 선택지가 있습니다:

1. 대상 모델 건너뛰기 (Skip Covered Models). ZDR(Zero Data Retention) 상태가 균일하게 유지되지만, 해당 모델을 포기해야 합니다. 워크로드에 해당 모델이 필요하지 않다면 실행 가능한 선택지입니다. 그 비용과 차이점에 대해서는 당사의 측정된 Fable 5 평가 (measured Fable 5 evaluation)를 참조하십시오.
2. 워크스페이스 또는 프로젝트별 분할. 모든 플랫폼은 범위가 지정된 옵트인 (scoped opt-in)을 지원합니다: 지정된 Claude API 워크스페이스 (Console → Settings → Workspaces → Privacy controls), provider_data_share가 설정된 Bedrock 프로젝트, 별도의 Vertex 프로젝트 또는 Azure 구독 등이 있습니다. 데이터 보관(retention)을 허용할 수 있는 워크로드만 그곳으로 라우팅하십시오.
3. 조직 전체에 보관 정책 수용. 운영 측면에서 가장 간단하지만, ZDR이 필요할 만큼 민감한 워크로드를 포함하여 모든 워크로드에 대한 보증 수준을 암묵적으로 낮추게 됩니다. 이는 단순한 설정 변경의 문제가 아니라, 귀사의 데이터 보호 책임자가 내려야 할 결정입니다.

제공업체와 관계없이: 귀사 자체의 로깅(logging)은 두 번째 보관 접점(retention surface)입니다. 만약 귀사의 게이트웨이(gateway)나 관측성 스택(observability stack)이 전체 프롬프트를 로깅한다면, 귀사는 제공업체보다 더 긴 보관 기간을 귀사 자체의 환경 내에서 운영하게 되는 것입니다. 제공업체의 보증은 그 앞단에 있는 레이어만큼만 의미가 있습니다. 캐시 주장 (cache claims)에 적용했던 것과 동일한 감사 로직이 여기에도 적용됩니다.

소비자 대상 제품에 미치는 영향

소비자에게 서비스를 제공하고 그들의 콘텐츠를 대상 모델(Covered Model)로 라우팅하는 경우, ZDR 합의 여부와 관계없이 이 변화는 귀사의 법적 책임 범위로 전파됩니다. 세 가지 구체적인 결과는 다음과 같습니다:

1. 개인정보 처리방침(privacy notice) 업데이트가 필요할 가능성이 높습니다. 대부분의 규제 체계는 단순히 수집뿐만 아니라 보관(retention)에 대한 공개를 요구합니다. GDPR 제13조 2항 (a)는 수집 시점에 저장 기간(또는 기준)을 요구하며, 캘리포니아의 CPRA는 수집 시 통지서에 개인정보 카테고리별 보관 기간을 명시하도록 요구합니다. 만약 귀사의 방침이 대화 데이터가 어디에도 보관되지 않는다고 명시하거나 암시하고 있다면, 30일간의 사본을 보유하는 처리자(processor)의 존재로 인해 해당 방침은 틀린 것이 됩니다. 개인정보 처리방침, 처리 기록(records of processing), 그리고 DPA(데이터 처리 합의서) 인벤토리를 업데이트하십시오.

2. 보유하지 않은 옵트아웃(opt-out)을 사용자에게 제공할 수는 없습니다. 해당 보관 정책에는 예외 메커니즘이 없으므로, 해당 모델을 계속 사용하면서 특정 사용자의 프롬프트만 제외하는 토글(toggle)을 구축할 수는 없습니다. 당신이 실제로 제어할 수 있는 수단은 **라우팅(routing)**입니다. 동의 여부를 인지하는 게이트웨이(gateway)를 통해, 데이터 공유를 거부한 사용자는 ZDR(Zero Data Retention)이 가능한 모델로 보내고, 나머지 사용자는 대상 모델(Covered Model)로 보내는 방식입니다. 이는 법적 제약 사항을 일반적인 라우팅 규칙으로 전환한 것입니다. 아무런 효과도 없는 선호도 체크박스를 만드는 것보다 훨씬 낫습니다.

3. 삭제 요청에는 정확한 배관(plumbing) 작업이 필요합니다. 삭제 의무(GDPR 제17조, CPRA 삭제권 및 그에 상응하는 규정들)는 처리자(processor)에게도 적용됩니다. 30일 이내에 자동 삭제되는 제한된 기간(bounded window)은 일반적으로 방어 가능한 처리자 입장(posture)이지만, 당신의 DSAR(데이터 주체 권리 요청) 플레이북에는 이를 명시해야지, 실행할 수 없는 즉각적인 하위 삭제(downstream deletion)를 약속해서는 안 됩니다.

글로벌 차원의 복잡성이 이를 가중시킵니다. 동일한 공개 및 처리자 논리가 UK GDPR, 브라질의 LGPD, 그리고 확산되고 있는 미국의 주별 개인정보 보호법들에서 나타납니다. 중국 사용자의 경우, PIPL(개인정보보호법)은 두 가지 더 날카로운 측면을 추가합니다. 일반적으로 다른 처리자에게 개인정보를 제공하려면 별도의 동의가 필요하며, 중국 사용자의 콘텐츠를 해외 LLM 엔드포인트로 라우팅하는 것은 공인된 메커니즘(보안 평가, 표준 계약 또는 인증)이 필요한 국외 이전(cross-border transfer)에 해당합니다. 누가, 무엇을, 어디서, 얼마나 오래 보관하는지를 변경하는 모델 업그레이드는 바로 이러한 프레임워크들이 당신에게 서류 작업을 다시 하도록 요구하는 변화 그 자체입니다.

민감 데이터 산업: 30일 정책이 가장 뼈아프게 다가오는 곳

대부분의 제품에서 제공자의 보관 기간은 문서화의 문제입니다. 하지만 데이터 자체가 규제 대상인 산업의 경우, 이는 아키텍처(architecture)의 문제입니다. 보관된 복사본은 벤더(vendor) 내에 저장된 규제 대상 데이터(data at rest)이며, 해당 산업의 규칙이 바로 그 부분을 규제하기 때문입니다.

의료 (HIPAA)

HIPAA는 데이터 보관을 전혀 하지 않을 것(zero retention)을 요구하는 것이 아닙니다. 대신 보호 대상 건강 정보(Protected Health Information, PHI)를 보유하는 모든 벤더가 적절한 보호 조치를 포함한 비즈니스 파트너 계약 (Business Associate Agreement, BAA) 하에 정보를 보유할 것을 요구합니다. 귀하의 프롬프트가 30일 동안 복사되어 저장되는 것은 비즈니스 파트너(business associate) 측에 저장된 PHI(data at rest)이며, 문제는 귀하의 BAA가 이를 커버하는지 여부입니다. 두 주요 API 벤더는 이를 다르게 구성하고 있으며, 이제 그 차이가 중요해졌습니다: Anthropic의 HIPAA 대응 API 액세스는 명시적으로 제로 데이터 보관 (ZDR)을 요구하지 않습니다. 대신 보호 조치(암호화, 액세스 제어, 감사 로깅, 강제된 기능 제한)를 동반한 보관 (retention-with-safeguards) 방식을 기반으로 구축되었습니다. 반면 OpenAI의 API BAA는 ZDR이 가능한 엔드포인트를 커버합니다. ZDR 엔드포인트로 범위가 한정된 BAA는 구조적으로 데이터 보관을 의무화하는 모델을 커버할 수 없습니다.

이제 모델의 보관 클래스(retention class)는 BAA 적격성 문제와 직결됩니다. PHI를 모델로 전송하기 전에 귀하의 BAA가 해당 특정 모델을 커버하는지 서면으로 확인하십시오. 또한 클라우드 환경에 따라 책임 체인이 변경된다는 점을 기억해야 합니다. Bedrock에서는 플랫폼이 귀하의 비즈니스 파트너가 되지만, Foundry에서는 Anthropic이 데이터를 직접 처리합니다. 주의해야 할 날카로운 지점(sharp edge) 하나는, 구조화된 출력 (structured outputs)을 위한 JSON 스키마 정의에는 절대로 PHI가 나타나서는 안 된다는 것입니다. 캐시된 스키마는 메시지 내용과 동일한 수준의 보호를 받지 못합니다.

아동용 제품 (COPPA)

시기적으로 매우 난처한 상황입니다. FTC의 개정된 COPPA 규칙 (amended COPPA Rule)은 2025년 6월 23일에 발효되었으며, 대부분의 조항에 대한 준수 기한은 2026년 4월 22일까지입니다. 즉, 제공자 측의 의무적 데이터 보관 (retention)을 요구하는 첫 번째 모델이 등장한 시점이 운영사들이 새로운 보관 의무 이행을 막 마친 때와 맞물린 것입니다. 이 중 두 가지 사항이 30일 보관 기간과 직접적으로 상호작용합니다. 첫째, 이제 **서면으로 된 공개 데이터 보관 정책 (written, public data retention policy)**이 의무화되었습니다 (§312.10). 여기에는 어떤 아동 데이터를 수집하는지, 왜 수집하는지, 그리고 언제 삭제하는지가 포함됩니다. 둘째, 무기한 보관 (indefinite retention)은 금지되며, 보관은 수집된 목적을 위해 합리적으로 필요한 범위 내로 제한됩니다.