Anthropic이 최상위 모델군에 강제 데이터 보관 정책을 도입했습니다. ZDR(Zero Data Retention) 계약을 맺은 기업 고객도 예외가 없어서, 조용히 받아들이기엔 파장이 꽤 큽니다.
구체적으로 보면, Claude Mythos 5와 Claude Fable 5를 포함한 "Mythos급 모델"에 제출된 프롬프트와 그 출력물은 신뢰·안전(trust and safety) 목적으로 30일간 보관됩니다. Fable 5는 Mythos 5와 동일한 기반 모델을 공유하되, 사이버·바이오 도메인에 추가 안전장치가 적용된 버전입니다. 두 모델 모두 이 정책의 적용을 받으며, 앞으로 Anthropic이 "covered models"로 지정하는 동급 이상의 신규 모델에도 동일하게 확장됩니다. 이 정책은 2026년 6월 9일부터 발효됩니다.
영향을 받는 대상은 기업 고객 중에서도 특정 조건을 만족하는 경우입니다.
- Claude Console에서 ZDR 워크스페이스를 설정한 조직
- Claude Enterprise 환경에서 ZDR로 Claude Code를 사용하는 조직
- AWS Bedrock·Google Cloud Agent Platform·Microsoft Foundry를 통해 ZDR 조건으로 Claude에 접근하는 조직
반대로 Claude Free·Pro·Max 같은 일반 소비자 플랜은 이미 입출력 데이터를 안전 목적으로 보관하고 있었기 때문에 이번 정책 변경에서 "unaffected"로 명시됩니다. 즉, 변화를 실감하는 쪽은 그동안 "우리 데이터는 저장 안 된다"는 전제 위에 워크플로를 설계해 온 기업들입니다.
Anthropic이 밝힌 이유는 단순합니다. 고성능 모델일수록 단일 요청만 봐서는 포착되지 않는 악용 패턴이 존재한다는 것입니다. 대표적인 예가 Best-of-N 재시도 공격(jailbreak 시도를 수백 가지 변형으로 반복 전송해 하나라도 통과시키는 방식)이고, 더 큰 규모로는 국가 지원 스파이 활동이나 데이터 탈취 캠페인처럼 여러 요청에 걸쳐 패턴이 드러나는 위협도 있습니다. 요청 하나하나를 독립적으로 분석해서는 이런 패턴을 잡을 수 없고, 일정 기간 데이터를 묶어서 봐야 가능하다는 논리입니다. 30일이라는 기간은 그 분석 창(window)의 상한선이 되는 셈입니다.
직접 해봤더니라기보다, 정책 문서를 읽으면서 처음엔 "ZDR 고객이 가장 타격을 받겠다"는 생각이 바로 들었습니다. ZDR은 말 그대로 데이터 무저장을 전제로 설계된 계약인데, 그 전제가 최상위 모델에서만큼은 더 이상 유효하지 않게 된 것이니까요. 단순한 보관 기간 문제가 아니라, 기업이 이 모델을 어떤 데이터에 적용할 수 있는지를 다시 검토해야 하는 상황이 됐습니다.
Anthropic이 공개한 정책 문서를 보면, 이 결정의 출발점이 꽤 구체적입니다. Mythos 5는 "capabilities의 substantial increase"라고 표현되어 있고, Fable 5는 "same underlying model as Mythos 5"라고 명시되어 있습니다. 즉 Fable은 Mythos에 사이버·바이오 도메인 세이프가드를 추가 적용한 버전인데, 기반 모델 자체가 같기 때문에 같은 보관 정책이 묶여서 적용됩니다. 안전장치의 층위가 달라도, 모델이 가진 원래 능력치가 동일한 이상 감시 수준을 따로 낮출 수 없다는 판단인 셈입니다.
타이밍에 대해서도 문서는 솔직합니다. Best-of-N jailbreaking이라는 공격 방식이 명시적으로 언급되는데, 이건 수백 개의 미세하게 변형된 프롬프트를 연속으로 보내면서 그중 하나가 가드레일을 통과하길 기다리는 방식입니다(마치 자물쇠를 무작위 열쇠로 계속 긁어보는 것에 가깝습니다). 단건 검사 시스템은 이 패턴을 원리적으로 감지할 수 없습니다. 요청 하나만 보면 그냥 평범한 질문처럼 보이거든요. 비슷한 이유로 국가 지원 스파이 활동이나 데이터 갈취 캠페인도 언급됩니다. 이런 공격은 단발성이 아니라 장기간 여러 계정에서 분산되어 들어오기 때문에, 분류기(classifier)가 "여러 요청을 동시에 펼쳐놓고" 봐야 패턴이 드러납니다.
결국 이전 모델들에 이 정책이 없었던 건 능력이 낮아서가 아니라, 그 모델들이 유발할 수 있는 실질적 위협의 임계값이 달랐기 때문입니다. Anthropic 입장에서 Mythos·Fable급은 처음으로 "단건 필터링만으로는 부족하다"는 판단이 내려진 모델 세대입니다. 저는 이 부분을 읽으면서, 사실 이 정책이 모델의 성능을 제한하는 게 아니라 그 성능을 배포 가능하게 만드는 조건이라는 느낌을 받았습니다. 달리 말하면, 30일 보관이 없었다면 이 모델은 아예 외부 API로 나오지 못했을 수도 있습니다.
💡 핵심: 30일 보관 정책은 모델 성능을 제한하는 조치가 아니라, 이 모델을 외부 API로 출시하기 위한 전제 조건일 수 있다. 정책이 없었다면 배포 자체가 불가능했을 가능성이 있다.
그렇다면 이 정책이 실제로 영향을 미치는 대상이 누구인지, 즉 어떤 계약 형태와 어떤 플랫폼에서 이 변화가 적용되는지를 구체적으로 확인해볼 필요가 있습니다.
ZDR, 즉 Zero Data Retention은 Anthropic과 계약할 때 "우리 데이터는 절대 저장하지 말아 달라"고 명시적으로 요청한 상태를 말합니다. 일반적으로 엔터프라이즈 고객이나 클라우드 플랫폼을 통해 API를 사용하는 조직들이 이 옵션을 선택합니다. 그런데 이번 정책이 정확히 이 ZDR 고객들을 겨냥하고 있습니다.
먼저 영향을 받지 않는 쪽을 명확히 하는 게 좋습니다. Claude Free, Pro, Max 같은 일반 소비자 플랜은 이번 정책과 무관합니다. 이유는 간단한데, 이미 보관 중이기 때문입니다. Claude.ai 웹, 데스크톱, 모바일 앱, 그리고 Claude Code 소비자 버전 모두 원래부터 입력과 출력을 안전 목적으로 보관하고 있었습니다. 원문에서도 이 부분을 명시적으로 짚습니다.
"Consumer plans (Claude Free, Pro, and Max) across our web, desktop, and mobile apps—including Claude.ai and Claude Code—are unaffected by this update, since we already retain inputs and outputs for safety purposes on these surfaces."
실제로 달라지는 건 세 가지 경로입니다.
- Claude Console에서 ZDR 워크스페이스를 설정한 조직
- Claude Enterprise에서 ZDR과 함께 Claude Code를 사용하는 조직
- AWS Bedrock, Google Cloud Agent Platform, Microsoft Foundry를 통해 Claude에 접근하면서 ZDR 계약을 맺은 조직
이 세 경로 외에는 변경 사항도, 설정할 것도 없습니다.
저는 이 구분이 생각보다 중요하다고 느꼈습니다. 국내에서 Claude API를 쓰는 팀들을 보면 상당수가 AWS Bedrock을 통해 접근합니다. 비용 구조나 기존 인프라 때문에 Bedrock을 선택한 곳들이 많은데, 거기서 ZDR 옵션을 켜놨다면 이번 정책의 직접 대상이 됩니다. "우리는 그냥 AWS에서 쓰는데요"라고 생각했던 팀들이 의외로 영향권 안에 있을 수 있다는 얘기입니다.
또 한 가지 눈에 띄는 점은 플랫폼 목록이 Bedrock, GCP, Microsoft Foundry로 구성됐다는 겁니다. 하이퍼스케일러 세 곳이 모두 포함됐고, 이 플랫폼들에서 ZDR을 선택했던 조직이라면 계약서에 명시된 데이터 처리 조건이 2026년 6월 9일부터 사실상 변경되는 셈입니다. 계약상의 ZDR 조항이 이번 Mythos급 모델에 한해서는 적용 범위에서 제외된다는 뜻이기도 합니다. 그 30일 동안 보관된 데이터를 Anthropic이 어떤 조건 아래에서 열람할 수 있는지는, 다음에 살펴볼 접근 통제 구조를 확인해야 온전히 판단할 수 있습니다.
30일이라는 숫자는 명확해 보이지만, 실제 문구를 들여다보면 예외 조항이 상당히 넓게 열려 있다.
Anthropic 공식 문서에는 삭제 조건이 이렇게 적혀 있다: "After 30 days, the data is deleted automatically, except in the rare cases where it's part of a safety investigation or we're legally required to keep it." 여기서 "rare cases"라는 표현이 핵심이다. '드문 경우'라고 못 박았지만, 어떤 요청이 안전 조사 대상으로 분류되는지에 대한 기준은 공개 문서 어디에도 구체적으로 나와 있지 않다. 분류 권한이 Anthropic 내부에 있다는 뜻이고, 외부에서 검증할 방법이 현재로선 없다.
접근 통제 구조 자체는 꽤 촘촘하게 설계되어 있다. 직원이 대화 내용을 열람하려면 "잠재적으로 심각한 피해로 플래그된 경우" 또는 "고객의 서면 요청이 있는 경우"에만 가능하고, 승인된 소수의 리뷰어만 접근할 수 있는 전용 툴링을 통해서만 조회가 된다 — 내보내기, 복사, 다운로드 기능은 차단되어 있다. 모든 접근 이력은 리뷰어가 수정하거나 숨길 수 없는 변조 방지 로그에 기록된다. 이 부분은 소스 원문에 명시된 내용이다. 구조적으로는 상당히 엄격한 편이다.
그럼에도 커뮤니티에서 지속적으로 문제를 제기하는 지점은 딱 두 가지다.
- 안전 조사 지정 기준이 불투명하다는 것. '드문 경우'라는 표현이 법적 구속력을 갖는 수치나 조건이 아니라, 사실상 재량 조항에 가깝다.
- 법적 보관 의무("legally required to keep it")가 발생하는 경우 — 예를 들어 수사 기관의 보존 명령이나 소송 관련 홀드(litigation hold)가 걸리면 — 30일 카운트가 멈추고 보관 기간이 사실상 무기한으로 늘어날 수 있다.
이 시나리오에서는 고객사에 별도 통지가 이루어지는지에 대한 내용도 현재 공개 문서에는 없다. 변조 방지 로그가 있다는 건 내부 통제를 위한 장치이지, 외부 고객사에 보관 연장 사실을 알려주는 메커니즘은 아니다.
선택 옵션으로 제공되는 고객 관리 암호화 키(customer-managed encryption keys)와 접근 투명성 감사 로그는 일부 조직에 한해 추가할 수 있다고 명시되어 있다. 다만 "eligible organizations"이라는 단서가 붙어 있어서, 모든 ZDR 고객이 자동으로 이 옵션을 사용할 수 있는 건 아니다. 어떤 조직이 자격 요건을 갖추는지는 Trust Center의 기술 백서에 더 상세히 기술되어 있다고 되어 있지만, 그 백서 자체는 일반에 공개된 문서가 아니다. 결국 30일이라는 타임라인은 기본값이지, 보장값이 아니다. 이 차이가 GDPR이나 HIPAA 같은 규제 환경에서 어떤 충돌을 일으키는지는, 실제 컴플라이언스 검토 단계에서 훨씬 더 날카롭게 드러난다.
⚠️ 주의: 30일은 기본값이지 보장값이 아니다. 안전 조사 지정 또는 법적 보관 의무 발생 시 보관 기간이 무기한으로 연장될 수 있으며, 이 경우 고객사에 별도 통지가 이루어지는지에 대한 내용은 현재 공개 문서에 없다.
GDPR 맥락에서 가장 먼저 걸리는 지점은 데이터 처리 주체(controller) 문제다. ZDR 계약을 맺은 조직은 지금까지 Anthropic을 데이터 프로세서(processor)로 분류해왔다. 조직이 목적과 수단을 결정하고, Anthropic은 단순히 그 지시에 따라 처리만 한다는 구조였다. 그런데 이번 정책이 시행되면 Anthropic이 독립적인 안전 목적으로 데이터를 보관하기 시작한다. 법률 언어로는 "목적과 수단을 독자적으로 결정"하는 순간인데, 이 순간부터 Anthropic은 컨트롤러(controller) 지위를 겸하게 된다. GDPR 제28조가 요구하는 Data Processing Agreement(DPA) 구조가 전면 재검토 대상이 된다는 뜻이다.
컨트롤러 전환이 왜 문제가 되냐면, 정보 주체(데이터를 입력한 실제 사람)에게 고지·동의 의무가 추가로 발생하기 때문이다. 조직이 직원이나 고객 데이터를 담은 프롬프트를 Claude에 넘겼다면, 그 정보 주체들은 Anthropic이 해당 데이터를 30일간 독립적으로 보관한다는 사실을 사전에 고지받아야 한다. 이미 배포한 내부 툴이나 고객 대면 서비스에서 이 고지가 빠져 있다면, 조직 자체가 GDPR 위반 상태에 놓인다. EU 거주자 데이터를 다루는 조직이라면, 개인정보 처리방침과 DPA를 6월 9일 전에 손봐야 하는 실질적인 기한이 생긴 셈이다.
HIPAA 쪽은 얼핏 더 안전해 보이지만, 실상은 조금 다르다. Anthropic은 Business Associate Agreement(BAA)를 제공한다. BAA가 있으면 HIPAA 규제 환경에서 Claude를 쓸 수 있는 법적 근거가 된다. 문제는 BAA가 "보호 건강 정보(PHI)를 처리할 수 있다"는 허가증이지, "PHI를 원래 서비스 목적 외로 무기한 보관해도 된다"는 면허가 아니라는 점이다. HIPAA의 최소 필요 원칙(Minimum Necessary Standard)은 PHI를 서비스 제공에 필요한 최소한의 범위에서만 사용·보관하도록 요구한다. Anthropic이 안전 조사 목적으로 PHI가 포함된 프롬프트를 30일 이상 보관하는 상황이 발생하면, 그 보관 행위가 BAA가 명시한 허용 목적 범위 안에 있는지를 따져야 한다. 의료 분야 고객사가 "BAA가 있으니까 괜찮다"고 단정 짓기 전에, 법무팀이 BAA 조항을 이번 정책 문언과 나란히 놓고 검토해볼 필요가 있다.
NDA는 더 조용하지만 더 널리 퍼진 지뢰다. 기업 간 계약에 딸린 기밀유지 조항, 거래 상대방과 서명한 NDA, 임직원 비밀유지 서약 — 이 모든 문서에는 보통 "기밀 정보를 제3자에게 제공하거나 제3자가 접근할 수 있는 시스템에 저장하지 않는다"는 문구가 들어 있다. 영업 담당자가 거래 조건을 요약해 달라고 Claude에 붙여 넣거나, 법무팀이 계약서 초안을 검토시키는 순간 — 그 내용이 30일간 Anthropic 서버에 남는다. Anthropic 직원이 심각한 위해 가능성이 감지될 때만 접근할 수 있다는 보호 장치가 있다고 해도, 상대방 NDA 입장에서는 "제3자 시스템에 저장된 사실" 자체가 위반으로 해석될 수 있다. 실제로 NDA 위반 분쟁은 정보가 외부로 흘러나갔는지가 아니라 "외부 접근이 가능한 상태에 놓였는지"만으로도 촉발된 사례가 있다.
세 규제 영역 모두 공통적으로 가리키는 것은 하나다. 조직 내부의 Claude 사용 정책이 "ZDR이 있으니 데이터가 안 나간다"는 전제 위에 설계되어 있었다면, 그 전제가 Fable·Mythos급 모델에서는 더 이상 성립하지 않는다. 어떤 규제 프레임워크를 적용받든, 이 변화가 실제 업무 흐름에서 어떤 시나리오로 나타나는지를 구체적으로 따져보는 것이 다음 단계다.
가장 현실적인 출발점은 "우리 팀이 Fable이나 Mythos를 어떤 경로로 쓰고 있나"를 먼저 확인하는 것이다. Bedrock이나 GCP를 통해 ZDR로 묶어둔 조직이라면 이번 정책 변경의 직접 대상이다. 세 가지 상황을 구체적으로 짚어보자.
시나리오 1 — B2B SaaS 팀이 Fable을 고객 대면 기능에 붙인 경우. 고객사가 자사 데이터를 SaaS 플랫폼에 입력하면, 그 데이터는 SaaS 팀이 Claude API로 넘기는 프롬프트 안에 들어간다. 지금까지는 ZDR 덕분에 "우리 서비스를 통해 들어간 데이터는 Anthropic 서버에 남지 않는다"고 고객에게 설명할 수 있었다. 이제 Fable·Mythos 모델을 쓰는 한 그 문장을 그대로 유지하기 어렵다. 제일 빠른 대응은 두 갈래다. 해당 기능에서 모델을 Haiku나 Sonnet 계열로 다운그레이드하거나, 고객 계약서의 데이터 처리 조항을 업데이트하고 DPA(Data Processing Agreement)에 Anthropic의 30일 보관 사실을 명시하는 것이다. 어느 쪽을 선택하든 고객사 보안팀에 먼저 알리는 편이 낫다. 나중에 알려지는 것보다 낫다는 건 경험상 분명하다.
시나리오 2 — 의료·법률 데이터를 파이프라인에 태우는 팀. 앞 섹션에서 짚었듯 BAA가 있어도 HIPAA 위반 소지가 생긴 상황이다. 여기서 추가로 따져봐야 할 게 있다. Anthropic의 공식 문서는 "소수의 승인된 검토자만 접근 가능하고, 전체 접근 로그가 변조 불가능한 형태로 기록된다"고 명시한다. 그런데 의료·법률 기관의 컴플라이언스 팀은 '접근이 제한된다'는 것과 '접근 자체가 없다'는 것을 같은 수준으로 보지 않는다 (이 둘의 차이가 감사 때 얼마나 크게 느껴지는지는 겪어본 사람만 안다). 실질적 대응 방향은 PHI나 법적 특권 정보(Privileged Information)가 담긴 프롬프트를 Fable·Mythos 모델로 보내는 파이프라인 자체를 분리하는 것이다. 해당 워크로드만 다른 모델로 라우팅하고, Fable·Mythos는 비민감 요약이나 내부 메모 작성 같은 용도에 한정하는 식으로 경계를 그을 수 있다.
시나리오 3 — Claude Code로 코드베이스를 통째로 넘기는 스타트업. 이쪽이 체감상 가장 많이 간과되는 케이스다. Claude Code를 ZDR Enterprise 환경에서 쓰는 팀은 이번 변경의 적용 대상이다. 코드베이스 전체를 컨텍스트로 넘기는 세션에는 API 키, 내부 아키텍처 설계, 미공개 알고리즘이 그대로 포함될 수 있다. 30일간 보관되는 건 그 컨텍스트 전부다. Anthropic이 명시한 접근 제한 조건 — 심각한 위해 가능성이 있다고 판단되거나 고객이 서면 요청을 한 경우에만 내부 검토 가능 — 이 실제로 얼마나 엄격하게 적용되는지는 외부에서 검증할 방법이 없다. 당장 취할 수 있는 조치는 .claudeignore 또는 컨텍스트 필터링 설정을 통해 민감한 파일 경로를 제외하는 것이고, 시크릿 관리 도구(HashiCorp Vault나 AWS Secrets Manager 등)를 이미 쓰고 있다면 해당 설정 파일이 Claude Code 세션에 노출되지 않도록 파이프라인을 점검해보면 좋다.
세 시나리오 모두를 관통하는 공통 과제가 하나 있다. 지금 팀 내에서 Fable·Mythos 모델을 쓰는 워크로드 목록을 만들고, 각각에 "여기에 들어가는 데이터가 30일간 외부 서버에 보관되어도 괜찮은가"를 한 줄씩 적어보는 것이다. 이 목록이 없으면 다음 감사 때 어디서 문제가 터질지 예측하기 어렵다. 그리고 솔직히, 이 과정을 거치다 보면 Fable·Mythos를 계속 쓸 워크로드가 얼마나 되는지, 아니면 대부분을 다른 모델로 넘겨야 하는지 윤곽이 잡힌다. Anthropic이 이 정책을 설계할 때 그런 선택을 유도하려 했을 가능성도 있다.
처음엔 저도 이 정책을 읽고 "결국 ZDR을 유명무실하게 만드는 건가" 싶었다. 돈 더 내고 계약까지 바꿔서 데이터가 안 남게 했는데, Fable·Mythos를 쓰는 순간 그 전제가 흔들리니까. 기분 좋게 받아들이기 어려운 건 사실이다.
그런데 한 발 물러서면 Anthropic 입장도 이해가 안 되는 건 아니다. 실제로 Mythos급 모델은 이전 세대와 능력 차이가 질적으로 다르다고 공개 문서에서 직접 밝히고 있고, Fable도 "same underlying model"이라는 표현을 쓴다. 그 모델이 만약 사이버·바이오 도메인에서 정말 위험한 방식으로 악용된다면, 피해는 그 조직 안에서만 끝나지 않는다. Anthropic이 "우리는 책임 있는 배포를 하고 있다"고 말할 수 있으려면, 최소한 30일치 패턴을 들여다볼 수 있어야 한다는 논리가 완전히 틀리지는 않다.
다만 불편한 건 그 선택의 비용을 고객이 일방적으로 부담한다는 구조다. Anthropic이 안전 감시 체계를 강화하는 건 기업 전략이기도 하고, 규제 선점이기도 하다. 그 과정에서 ZDR 고객이 계약 조건을 재검토하고, 법무팀을 다시 돌리고, 일부 워크로드를 다른 모델로 옮기는 비용은 고스란히 고객 몫이다. "우리가 안전하게 하겠다"는 명분 뒤에 "그러니까 당신 데이터를 30일간 보겠다"는 조건이 따라붙는 방식이다.
어쩌면 이게 의도된 필터일 수 있다. 30일 보관을 감당할 수 없는 워크로드는 Fable·Mythos를 쓰지 말라는, 일종의 암묵적 사용 제한. 가장 강력한 모델을 가장 민감한 데이터에 붙이는 조합 자체를 Anthropic이 원하지 않는다면, 정책으로 금지하는 것보다 이런 식의 구조적 마찰을 만드는 쪽이 훨씬 유연하다. 실제로 그렇게 읽히는 부분이 있다.
좋은 모델인데 못 쓰게 된 느낌이라면, 아마 그 느낌이 맞을 수도 있다. 단지 그 제한이 기술 스펙이 아니라 데이터 정책이라는 형태로 온 것뿐이다.
Q. ZDR 계약을 맺은 기업도 이 정책의 영향을 받나요?
A. 네, 받습니다. ZDR(Zero Data Retention) 워크스페이스를 설정한 조직도 Claude Fable 5·Mythos 5 같은 covered models를 사용하면 프롬프트와 출력물이 30일간 보관됩니다. AWS Bedrock, Google Cloud, Microsoft Foundry를 통해 ZDR 조건으로 접근하는 경우도 동일하게 적용됩니다.
Q. 왜 하필 Fable과 Mythos에만 이 정책이 적용되나요?
A. Anthropic은 Mythos 5가 이전 세대 대비 '능력의 질적 도약'을 이뤘다고 공개 문서에서 직접 밝히고 있습니다. Fable 5는 같은 기반 모델을 공유하기 때문에 동일한 보관 정책이 묶여 적용됩니다. Best-of-N 재시도 공격처럼 단일 요청으로는 포착되지 않는 악용 패턴을 잡으려면 일정 기간 데이터를 묶어 분석해야 한다는 게 Anthropic의 논리입니다.
Q. 이 정책은 언제부터 시행되고, 일반 사용자에게도 해당되나요?
A. 2026년 6월 9일부터 발효됩니다. Claude Free·Pro·Max 같은 일반 소비자 플랜은 이미 안전 목적으로 입출력 데이터를 보관하고 있었기 때문에 이번 변경에서 'unaffected'로 명시됩니다. 실질적인 변화를 체감하는 쪽은 데이터 무저장을 전제로 워크플로를 설계해 온 기업 고객들입니다.
