Claude Fable 5는 ZDR에서 사용할 수 없다: 30일 보관 의무

조직에서 데이터 무보관(zero-data-retention, ZDR) 계약으로 Claude를 사용한다면, claude-fable-5에 보낸 첫 요청에서는 completion이 오지 않았을 것이다. 대신 400 invalid_request_error가 반환된다. 장애가 아니라 정책 때문이다. Fable 5는 30일간 데이터를 보관하지 않고는 사용할 수 없는 최초의 정식 출시 Claude 모델이다. 이 요건은 Claude API, AWS Bedrock, Google Vertex AI, Microsoft Foundry 등 모든 플랫폼에 동일하게 적용되며, 각 플랫폼에서 명시적으로 보관에 동의해야 사용할 수 있다.

“데이터를 보관하지 않는다”는 특성을 LLM 스택의 전제로 삼아 온 팀이라면 아키텍처 차원에서 대응해야 한다. 이 글에서는 정책의 내용과 30일이라는 기간이 필요한 이유, 각 클라우드의 구현 방식, 소비자 대상 제품과 민감 데이터를 다루는 업계에 미치는 영향을 살펴본다.

TL;DR

• Claude Fable 5를 사용하려면 prompt와 completion을 30일간 보관해야 한다. 이 요건은 Claude API, AWS Bedrock, Google Vertex AI, Microsoft Foundry에 모두 적용된다(정책 시행일 2026-06-09).
• 예외는 없다. 데이터 무보관 계약을 맺은 조직에서도 400 invalid_request_error가 발생하며, 기존 ZDR 조건은 그대로 적용되지 않는다.
• Bedrock에서 Fable 5를 사용하려면 data_retention_mode: provider_data_share가 필요하다. 설정하지 않으면 모델이 사용 불가로 표시된다.
• Usage Policy 위반으로 감지된 콘텐츠는 30일 보관 기간과 별개로 최대 2년간 보관될 수 있다.

정책 내용은 2026-06-12에 Anthropic, AWS, Google, Microsoft가 공개한 문서를 기준으로 확인했다. 정책은 변경될 수 있으므로 링크된 공식 자료와 각자의 계약을 다시 확인해야 한다. 이 글은 엔지니어링 관점의 개요이며 법률 자문이 아니다.

정책의 실제 내용

Anthropic은 Claude Fable 5와 Claude Mythos 5를 적용 대상 모델로 지정했다. API 데이터 보관 문서와 Mythos 계열 모델의 데이터 보관 방식에 따르면 2026-06-09부터 다음 정책이 적용된다.

• Prompt와 completion은 30일간 보관된 뒤 자동 삭제된다. 단, 진행 중인 안전 조사 대상으로 지정됐거나 법률상 보관 의무가 있는 경우는 예외다.
• 보관을 거부할 수 없다. 데이터 보관은 모델 사용 조건이다. 조직의 보관 설정이 요건을 충족하지 않으면 요청에 400 invalid_request_error가 반환된다.
• 데이터 접근은 의도적으로 엄격히 제한된다. 자동화된 안전 시스템이 데이터를 검사하며, 승인된 소수 인원만 감지된 대화를 검토할 수 있다. 이들은 데이터를 내보내거나 복사하거나 다운로드할 수 없고, 모든 접근 기록은 위변조 방지 로그에 남는다.
• 클라우드 플랫폼을 거치는 경우를 포함해 기존 ZDR 계약은 적용 대상 모델의 트래픽에 그대로 적용되지 않는다.

소비자용 요금제인 Claude Free/Pro/Max에는 영향이 없다. 이미 별도의 데이터 보관 조건에 따라 운영되기 때문이다. 이 정책의 대상은 상용 API다. 바로 “데이터를 절대 보관하지 않는다”는 약속이 주로 적용되던 영역이다.

30일간 보관하는 이유

적용 대상 모델 문서는 이유를 구체적으로 설명한다. 이 모델들은 소프트웨어 엔지니어링, agentic workflow, 사이버 보안 영역의 성능이 크게 향상됐으며, “일부 오용 행위는 여러 요청을 종합해야만 감지할 수 있다.” 문서에서 예로 든 best-of-N jailbreaking과 국가 지원 첩보 활동은 개별 prompt만 보면 정상으로 보이고, 요청의 흐름을 봐야 공격임을 판단할 수 있는 패턴이다. 삭제한 요청으로는 이런 흐름을 감지할 수 없다.

이 보관 기간을 다음 두 가지와 혼동하면 안 된다.

• 학습 데이터가 아니다. Anthropic은 명시적인 허가 없이는 보관 데이터를 학습에 사용하지 않는다고 밝히고 있다. 목적은 오용 탐지뿐이다.
• 보관 방식 자체가 새로운 것은 아니다. 강제된다는 점이 새롭다. 약 30일간 오용 감지용 데이터를 보관하는 방식은 수년간 업계의 기본값이었다. OpenAI는 API 오용 로그를 최대 30일간 보관하며, 승인받은 경우에만 ZDR을 제공한다. Azure OpenAI는 수정된 오용 감지 프로그램을 승인받지 않은 경우 prompt를 최대 30일간 보관한다. 달라진 점은 특정 모델 계열에서 이 기간을 협상할 수 없게 됐다는 것이다. 이전에는 모든 provider가 데이터 무보관을 선택할 방법을 제공했다.

기존 ZDR에도 사람들이 자주 놓치는 예외가 있었다. Anthropic은 ZDR에서도 안전 classifier 결과를 보관하며, Usage Policy 위반으로 감지된 콘텐츠는 최대 2년간 보관할 수 있다. 데이터 무보관이 모든 데이터를 전혀 보관하지 않는다는 의미였던 적은 없다. 일반적인 처리 경로에서 감지되지 않은 콘텐츠를 보관하지 않는다는 의미다.

같은 요건, 세 클라우드, 서로 다른 세 가지 방식

모델을 어디서 실행하든 보관 요건은 동일하다. 다만 각 플랫폼의 동의 방식이 다르며, 이 차이에 따라 누가 데이터를 처리하고 어디서 통제할지가 결정된다.

AWS Bedrock의 방식이 가장 명확하다. 데이터 보관은 설정 가능한 mode이며, default / provider_data_share / none 중 하나를 사용한다. 설정은 project → account → model default 순으로 결정된다. Fable 5의 allowed_modes는 ["provider_data_share"]다. 이 mode에서는 prompt와 completion이 Anthropic에 공유되며 최대 30일간 보관된다. 다른 mode에서는 다음과 같이 표시된다.

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Fable 5 이전 모델에는 아무 변화가 없다. bedrock:DataRetentionMode condition key에 SCP를 적용하면 조직 전체에서 보관 정책을 강제할 수 있다. 누군가 새 모델을 시험하려고 계정 설정을 몰래 바꾸는 일을 막을 수 있다는 뜻이다. Cross-region inference를 사용할 때는 보관되는 사본이 destination region에 저장된다. 데이터 residency를 보장해야 한다면 반드시 확인해야 한다.

Google Vertex AI에서는 project 수준의 Anthropic 데이터 공유 설정인 setPublisherModelConfig와 dataSharingEnabledProvider: "anthropic"을 활성화하고 Model Garden 약관에 동의해야 한다. 자세한 내용은 Google의 Fable 5 문서에 나와 있다. 일반적인 데이터 처리는 Vertex AI 데이터 거버넌스 정책을 따른다. 데이터 residency가 중요한 workload에서는 Vertex의 regional 및 multi-region endpoint가 inference 실행 위치를 결정하며, 이제 보관되는 사본의 위치도 여기에 포함된다.

Microsoft Foundry는 구조부터 다르다. Microsoft의 데이터 및 개인정보 보호 문서는 Claude 모델을 서드파티 marketplace 서비스로 명시한다. 배포할 때 Anthropic 약관에 동의하며, 데이터 processor는 Microsoft가 아니라 Anthropic이다. Azure OpenAI의 ZDR 및 수정된 오용 감지 프로그램은 Claude deployment에 적용되지 않는다. 다른 영역에서 ZDR 정책을 운영하는 조직은 대개 적용 대상 모델을 별도 subscription에 격리한다. 절차가 아니라 구조로 보관 경계를 만드는 방식이다.

세 플랫폼의 공통점은 보관 등급이 machine-readable한 일급 모델 속성이 됐다는 것이다. 계약서의 한 문단이 아니라 mode, flag, 약관 동의 단계로 구현된다. 이제 infrastructure에서 데이터 정책을 강제할 수 있으며, 실제로 그렇게 해야 한다.

엔터프라이즈 배포에 미치는 영향

ZDR 계약이 없다면 기술적으로 달라지는 것은 없다. 인지하지 못했을 수 있지만 이미 30일 보관과 비슷한 조건으로 사용하고 있었기 때문이다. 필요한 작업은 vendor 문서에 이 조건을 명시하는 것이다.

ZDR 계약이 있다면 세 가지 중 하나를 선택해야 한다.

1. 적용 대상 모델을 사용하지 않는다. ZDR 정책을 일관되게 유지하는 대신 해당 모델을 포기한다. workload에 이 모델이 필요하지 않다면 현실적인 선택이다. 비용과 차이점은 Fable 5 실측 평가를 참고하라.
2. Workspace 또는 project를 분리한다. 모든 플랫폼에서 범위를 제한해 동의할 수 있다. Claude API에서는 지정된 workspace를 사용하고(Console → Settings → Workspaces → Privacy controls), Bedrock에서는 provider_data_share가 설정된 project를 사용한다. Vertex에서는 별도 project, Azure에서는 별도 subscription을 사용한다. 데이터 보관이 허용되는 workload만 이쪽으로 라우팅하면 된다.
3. 조직 전체에서 보관에 동의한다. 운영은 가장 단순하지만, 모든 workload의 보장 수준이 조용히 낮아진다. ZDR을 도입할 이유가 됐던 민감한 workload도 포함된다. 단순한 설정 변경이 아니라 데이터 보호 책임자가 내려야 할 결정이다.

Provider와 관계없이 자체 logging도 별도의 데이터 보관 지점이다. Gateway나 observability stack이 전체 prompt를 logging한다면 provider보다 더 오래 자체 환경에 보관하는 셈이다. Provider의 보장은 그 앞단의 계층이 제대로 관리될 때만 의미가 있다. Cache 관련 주장을 검증할 때 사용한 것과 같은 감사 방식이 여기에도 필요하다.

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

소비자가 입력한 콘텐츠를 적용 대상 모델로 보낸다면 ZDR 계약 여부와 관계없이 자체 법적 고지에도 변화가 생긴다. 구체적인 영향은 세 가지다.

1. 개인정보 처리방침을 수정해야 할 가능성이 높다. 대부분의 법률은 데이터 수집뿐 아니라 보관 기간도 공개하도록 요구한다. GDPR 제13조 제2항 (a)는 수집 시점에 보관 기간 또는 그 결정 기준을 고지하도록 요구한다. California CPRA도 개인정보 범주별 보관 기간을 수집 시 고지하도록 요구한다. 대화 데이터가 어디에도 보관되지 않는다고 명시하거나 그렇게 오해할 수 있게 써 놓았다면, processor가 30일간 사본을 보관하는 순간 사실과 달라진다. 개인정보 처리방침, 처리 활동 기록, DPA 목록을 수정해야 한다.

2. 직접 거부할 수 없는 보관을 사용자에게 거부할 수 있다고 제공해서는 안 된다. 보관 정책에는 예외가 없다. 해당 모델을 계속 사용하면서 특정 사용자의 prompt만 보관 대상에서 제외하는 toggle은 만들 수 없다. 실제로 제어할 수 있는 수단은 라우팅이다. 동의 여부를 인식하는 gateway에서 데이터 공유를 거부한 사용자는 ZDR 적용이 가능한 모델로 보내고, 나머지는 적용 대상 모델로 보낸다. 법적 제약을 일반적인 라우팅 규칙으로 바꾸는 것이다. 아무 효과도 없는 preference checkbox보다 훨씬 낫다.

3. 삭제 요청 처리 절차가 실제 동작과 일치해야 한다. 삭제 의무는 GDPR 제17조, CPRA의 삭제권 및 그에 준하는 규정에 따라 processor에도 적용된다. 30일 안에 자동 삭제되는 제한된 보관 기간은 일반적으로 방어 가능한 processor 운영 방식이다. 하지만 DSAR 절차에는 그 사실을 정확히 기재해야 한다. 실제로 수행할 수 없는 즉각적인 downstream 삭제를 약속하면 안 된다.

같은 고지 및 processor 관련 원칙은 전 세계적으로 적용된다. UK GDPR과 브라질 LGPD는 물론, 계속 늘어나는 미국 주별 개인정보 보호법에도 유사한 요건이 있다. 중국 사용자의 경우 PIPL은 두 가지를 더 엄격하게 규정한다. 개인정보를 다른 processor에게 제공하려면 일반적으로 별도 동의가 필요하다. 중국 사용자의 콘텐츠를 해외 LLM endpoint로 라우팅하는 행위는 국외 이전에 해당하므로 보안 평가, 표준 계약, 인증 중 인정되는 절차가 필요하다. 누가 어떤 데이터를 어디에서 얼마나 오래 보관하는지를 바꾸는 모델 업그레이드는 바로 이런 법적 문서를 다시 정비해야 하는 변경이다.

민감 데이터 업계: 30일이 가장 큰 문제가 되는 곳

대부분의 제품에서 provider의 보관 기간은 문서화 문제다. 하지만 데이터 자체가 규제 대상인 업계에서는 아키텍처 문제다. Vendor가 보관하는 사본도 규제 대상인 저장 데이터이며, 업종별 규정이 이를 직접 통제하기 때문이다.

의료(HIPAA)

HIPAA는 데이터 무보관을 요구하지 않는다. 보호 대상 의료 정보(PHI)를 보관하는 vendor가 적절한 보호 조치를 갖추고 **Business Associate Agreement(BAA)**에 따라 처리하도록 요구한다. Prompt를 30일간 보관한 사본은 business associate가 저장한 PHI다. 핵심은 BAA가 이 사본까지 포함하는지다. 주요 API vendor 두 곳은 이를 서로 다르게 구성하며, 이제 그 차이가 중요해졌다. Anthropic의 HIPAA 지원 API access는 ZDR을 요구하지 않는다고 명시한다. 암호화, 접근 제어, 감사 logging, 기능 제한 강제 등 보호 조치를 적용한 보관을 기반으로 하기 때문이다. OpenAI API BAA는 데이터 무보관 적용이 가능한 endpoint를 대상으로 한다. ZDR endpoint만 포함하는 BAA는 보관을 의무화한 모델을 구조적으로 포함할 수 없다.

이제 모델의 보관 등급에 따라 BAA 적용 여부가 달라진다. PHI를 보내기 전에 BAA가 해당 모델을 포함하는지 서면으로 확인해야 한다. 클라우드를 사용하면 계약 관계도 달라진다. Bedrock에서는 플랫폼이 business associate이고, Foundry에서는 Anthropic이 데이터를 직접 처리한다. 특히 구조화된 출력의 JSON schema 정의에는 PHI를 절대 넣으면 안 된다. Cache된 schema에는 message 콘텐츠와 동일한 보호 조치가 적용되지 않는다.

아동 대상 제품(COPPA)

시기상 대응하기 까다롭다. FTC의 개정 COPPA Rule은 2025년 6월 23일에 발효됐으며, 대부분의 조항은 2026년 4월 22일부터 준수해야 했다. 운영 조직이 새 보관 의무 구현을 막 마친 시점에 provider 측 보관을 의무화한 첫 모델이 나온 것이다. 이 가운데 두 가지 요건이 30일 보관과 직접 관련된다. 이제 §312.10에 따라 어떤 아동 데이터를 왜 수집하고 언제 삭제하는지 명시한 공개 서면 데이터 보관 정책이 필수다. 또한 무기한 보관은 금지되며, 수집 목적에 합리적으로 필요한 기간만 보관할 수 있다.

30일이라는 제한된 기간과 자동 삭제 방식 자체는 양립 가능한 형태다. 하지만 provider는 운영자가 아동 데이터를 수집한 목적이 아니라 자체적인 신뢰 및 안전 목적으로 보관한다. 개인정보 처리방침에 processor 관계를 정확하게 설명해야 한다. 데이터 흔적을 최소화하려고 ZDR을 도입한 아동 대상 제품이라면 라우팅 원칙을 더 엄격하게 적용해야 한다. 아동 트래픽은 ZDR 적용이 가능한 모델에만 보내거나, 적용 대상 모델의 보관 기간을 먼저 §312.10 정책에 반영해야 한다.

같은 구조가 적용되는 다른 업종

규제 대상 데이터, vendor가 보관하는 사본, 데이터 보관을 통제하는 업종별 규정이라는 구조는 다른 분야에서도 반복된다.

• 생체정보(Illinois BIPA): 운영자는 생체정보에 대한 보관 일정과 폐기 지침을 작성해 공개해야 한다. 생체 식별자가 포함된 prompt의 provider 측 30일 사본도 이 일정에 포함해야 한다.
• 결제(PCI DSS / GLBA): PCI DSS는 승인 후 민감 인증 데이터를 어디에도 저장하지 못하게 한다. Prompt에 붙여 넣은 카드 데이터는 provider에 30일간 보관되는 카드 데이터가 된다. 올바른 해결책은 downstream 문서 작업이 아니라 upstream redaction이다.
• 교육(FERPA): 학교 관계자 예외에 따라 학생 기록을 처리하는 vendor는 학교의 직접적인 통제를 받아야 한다. 학교가 접근하거나 조기에 삭제할 수 없는 안전 목적의 보관 사본은 이 기준과 충돌할 여지가 있다. EdTech 트래픽을 적용 대상 모델로 보내기 전에 법률 검토가 필요하다.
• 금융 서비스의 반대 사례(SEC/FINRA): Broker-dealer는 장부 및 기록 규정에 따라 업무상 통신을 보관해야 한다. 이들에게 문제는 provider의 보관 기간이 아니라 자체적인 규정 준수용 사본을 확보하는 것이다. 같은 보관 문제지만 방향은 반대다.

공통점은 업종별 규정이 데이터 보관을 양방향으로 통제한다는 것이다. 직접 제어할 수 없는 provider 측 보관 기간을 해당 업종이 요구하는 방향에 맞춰 반영해야 한다.

의사결정 체크리스트

• ✅ 트래픽이 실제로 사용하는 모델을 모두 파악한다. 이제 보관 등급은 provider가 아니라 모델별 속성이다.
• ✅ ZDR을 사용한다면 명시적으로 결정한다. 적용 대상 모델을 제외하거나, workspace/project/subscription을 분리하거나, 조직 전체에서 보관에 동의해야 한다. 암묵적으로 적용되게 두면 안 된다.
• ✅ 정책은 infrastructure에서 강제한다. Wiki 문서가 아니라 Bedrock SCP, workspace privacy controls, 별도 cloud project를 사용한다.
• ✅ B2C라면 개인정보 처리방침과 DSAR 절차를 수정한다. 동의하지 않은 사용자는 작동하지 않는 opt-out 기능을 제공하는 대신 ZDR 적용이 가능한 모델로 라우팅한다.
• ✅ 규제 대상 데이터는 모델별 적용 범위를 서면으로 확인한다. PHI의 BAA, 아동 데이터의 §312.10 정책, 생체정보의 보관 일정 등을 확인한 뒤 보관 의무가 있는 모델로 데이터를 보내야 한다.
• ✅ 자체 logging을 감사한다. Gateway가 prompt를 무기한 logging한다면 provider의 30일 보관 기간은 의미가 없다.

결론

Fable 5에 적용되는 30일 보관은 데이터를 무분별하게 수집하려는 정책이 아니다. 목적과 기간이 제한된 오용 감지 조치이며, 업계 대부분이 이미 기본적으로 운영해 온 방식과 비슷하다. 여러 요청을 종합해야 하는 오용은 삭제된 데이터로 감지할 수 없기 때문에 특정 모델 계열에만 의무화한 것이다. 대부분의 팀은 엔지니어링 측면에서 바꿀 것이 없고, 거버넌스 측면에서는 vendor 검토 문서에 한 문단을 추가하면 된다.

하지만 ZDR 범위로 제한된 BAA, 아무 데이터도 남지 않는다고 적힌 개인정보 처리방침, 데이터 최소화를 전제로 설계한 아동용 제품처럼 데이터 무보관을 compliance의 전제로 삼은 조직에는 상황이 다르다. Fable 5가 등장하면서 이 전제를 모든 모델에 동일하게 적용할 수 없게 됐다. 해결책은 모델을 무조건 피하는 것이 아니다. 가격과 컨텍스트 윈도우를 기준으로 라우팅하듯, 보관 등급도 모델별 라우팅 결정의 명시적인 입력값으로 사용해야 한다.

FAQ

데이터 무보관 계약으로 Claude Fable 5를 사용할 수 있는가? 아니다. Fable 5와 Mythos 5는 30일 보관이 필요한 적용 대상 모델이다. ZDR 조직에서 사용하려면 workspace에 30일 보관을 활성화하고 Fable 5 트래픽을 해당 workspace로 라우팅해야 한다. 그렇지 않으면 400 invalid_request_error가 발생한다.

AWS Bedrock, Vertex AI, Microsoft Foundry를 통하면 이 요건을 피할 수 있는가? 아니다. 각 플랫폼은 별도의 보관 동의 절차를 거쳐야 모델을 사용할 수 있게 한다. Bedrock은 provider_data_share, Vertex는 Anthropic 데이터 공유와 Model Garden 약관 동의, Foundry는 배포 시 Anthropic 약관 동의가 필요하다. Foundry에서는 Microsoft가 아니라 Anthropic이 데이터 processor다. 어느 플랫폼에서도 기존 ZDR 조건이 그대로 적용되지 않는다.

최종 사용자가 데이터 보관을 거부할 수 있는가? 아니다. 보관을 거부하는 기능은 없다. 직접 제어할 수 있는 수단은 라우팅이다. 데이터 공유를 거부한 사용자는 ZDR 적용이 가능한 모델로 보내야 한다. 아무것도 바꾸지 않는 preference toggle을 출시하면 안 된다.

보관된 데이터를 모델 학습에 사용하는가? Anthropic은 명시적인 허가 없이는 보관 데이터를 학습에 사용하지 않는다고 밝히고 있다. 목적은 신뢰 및 안전 검토다. 자동 검사 후 감지된 대화만 승인된 인원이 검토할 수 있으며, 해당 인원은 데이터를 내보낼 수 없다. 모든 접근은 위변조 방지 로그에 기록된다.

30일 보관으로 prompt caching 방식이 달라지는가? 아니다. Cache entry에는 별도의 짧은 TTL인 5분 또는 1시간이 적용되며, Fable 5의 caching 계약도 바뀌지 않았다. 자세한 내용은 실측 평가를 참고하라. 30일 보관은 안전 검토를 위한 별도의 병렬적인 데이터 보관이다.

관련 글: Prompt caching 완벽 가이드에서는 데이터 보관 정책과 관련된 cache 동작을 설명하며, 플랫폼 가격에서는 각 모델의 provider 정가를 확인할 수 있다.

출처

• Anthropic — API 및 데이터 보관
• Anthropic — 적용 대상 모델
• Anthropic — Mythos 계열 모델의 데이터 보관 방식
• AWS — Amazon Bedrock 데이터 보관
• Google Cloud — Claude Fable 5(파트너 모델)
• Google Cloud — Vertex AI 데이터 거버넌스
• Microsoft — Foundry의 Claude: 데이터, 개인정보 보호 및 보안
• OpenAI — 엔터프라이즈 개인정보 보호
• OpenAI — API 서비스용 BAA
• FTC — COPPA Rule 개정 보도자료
• Federal Register — 아동 온라인 개인정보 보호 규칙

모든 내용은 2026-06-12에 확인했다. 정책은 변경될 수 있으므로 최신 문서와 각자의 계약을 확인해야 한다. 법률 자문이 아니다.

← 블로그로 돌아가기