LLM 데이터 보존과 ZDR: 프롬프트를 읽을 수 있는 모든 주체

프롬프트가 곧바로 “AI 회사”에만 전달되는 것은 아니다. agent stack에서는 여러 주체를 거치며, 모두 프롬프트를 평문으로 처리한다. 어떤 주체를 거치는지는 stack 구성에 따라 달라진다. agent framework의 telemetry, tracing platform, memory store, analytics tool, AI gateway, 그리고 세 유형 중 하나에 해당하는 inference provider가 관여하며, 각자 retention policy, storage region, training clause가 다르다. 프롬프트를 가장 오래 보관하는 주체는 대개 API 반대편이 아니라 자체 시스템 쪽에 있다. 모델 vendor는 일반 로그를 약 30일 후 삭제하지만, 기본 설정의 tracing 또는 memory store는 직접 삭제할 때까지 보관한다. Zero data retention(ZDR)은 실질적이고 유용한 계약이지만, 세 가지 축 가운데 정확히 하나만, 이들 주체 가운데 정확히 하나에 대해 고정한다. 이 글에서는 전체 경로와 각 주체가 무엇을 얼마나 오래 보관하는지, ZDR이 어디까지 적용되고 어디부터 적용되지 않는지 정리한다.

TL;DR

• 평문이 지나는 모든 구간에서 수집이 가능하다. agent 측 tracing과 memory store는 어떤 model provider보다도 프롬프트를 훨씬 오래 보관한다.
• Provider의 보존 정책은 기능별로 다르다. Claude API에서 caching은 ZDR 적용 대상이고, batch job은 29일간 유지되며, Fable 5에는 30일 보존이 필요하다.
• 데이터 위치는 실제 server를 따른다. DeepSeek 공식 API는 데이터를 중국에 저장하며, 다른 선택지는 없다.
• Free endpoint가 가장 위험하다. 무료 용량의 대가는 대개 training 권한이다.
• ZDR은 법정에서도 효력을 유지했다. NYT 증거 보존 명령에서 예외로 인정된 대상은 zero-retention API 고객뿐이었다.

Agent stack에서 누가 프롬프트를 읽을 수 있는가?

경로에 있는 모든 주체다. 실제 경로는 대부분의 팀이 그린 구성도보다 길다.

왼쪽부터 살펴보자. agent layer는 자체 시스템이지만, 자체 구성 요소만 있는 경우는 드물다. framework에는 telemetry가 포함되고, tracing 및 observability platform은 원래 전체 프롬프트와 응답을 저장하기 위한 제품이다. memory 기능은 conversation content를 자동 만료되지 않는 vector store에 기록한다. web UI의 session replay analytics snippet은 backend에 도달하기도 전에 사용자가 입력하는 프롬프트를 캡처한다. gateway는 직접 운영하면 하나의 주체지만, SaaS를 쓰면 두 주체가 된다. SaaS gateway도 두 유형으로 나뉜다. 첫째는 multi-provider aggregator다. 하나의 API가 요청마다 여러 provider 중 하나로 routing하므로 데이터 처리 방식은 항상 gateway 자체 정책과 해당 요청이 도착한 host의 정책을 합친 결과다. 둘째는 security vendor가 제공하는 gateway다. data-loss-prevention(DLP)과 guardrail gateway의 핵심 기능은 payload 검사, redaction, policy enforcement다. 모든 프롬프트를 읽는 것 자체가 기능이며, flag된 프롬프트는 보통 의도적으로 security event로 보관된다.

Gateway 뒤에는 세 유형의 inference provider가 있다. model vendor의 자체 API, cloud tenancy 내부에서 모델을 hosting하는 cloud provider, 자체 logging policy에 따라 open weights를 제공하는 GPU host다. 우회 경로인 전용 tenant 또는 자체 GPU 기반 self-hosted inference만이 제3자에게 평문을 노출하지 않는다. 다만 이 방식에도 뒤에서 설명할 조건이 따른다.

나머지를 이해하는 핵심 원칙은 간단하다. 볼 수 있는 것과 보관하는 것은 별개의 문제다. 모든 구성 요소는 기술적으로 수집할 수 있다. 실제 수집 여부는 기본값, 설정, 계약으로 결정되며, 그 기본값은 경로마다 크게 다르다.

실제로 누가 프롬프트를 보관하는가?

대개 자체 도구가 누구보다 오래 보관한다. security questionnaire에서 집중적으로 다루는 provider의 보존 기간은 며칠 단위지만, 질문조차 받지 않는 agent 측 store의 보존 기간은 무제한이다.

agent layer는 의도적으로 데이터를 보관한다. tracing platform은 프롬프트와 output을 저장하는 database가 핵심 제품이므로, 이곳의 보존 기간은 우연히 생긴 policy가 아니라 project setting이다. 기본값은 tool마다 다르므로 확인해야 한다. GitHub Copilot의 OpenTelemetry integration은 content capture를 명시적으로 활성화하지 않는 한 span 구조, timing, token count만 export하고 프롬프트 내용은 보내지 않는다. 더 많은 agent tooling이 따라야 할 privacy 보수형 설계다. Cursor의 privacy mode가 별도로 존재하는 이유는 기본 mode에서 code data를 공유하기 때문이다. model provider가 30일 후 데이터를 삭제해도 trace store에는 300일째까지 남아 있다.

gateway는 보관하기로 선택한 데이터를 보관한다. billing에는 요청별 token count, model, timestamp가 필요하므로 gateway는 usage record를 남길 수밖에 없다. 반면 payload는 전혀 저장하지 않아도 된다. 프롬프트와 response body를 memory에서만 통과시키고 저장소에는 기록하지 않을 수 있다. 하지만 널리 쓰이는 gateway 기능 두 가지가 이 경계를 조용히 넘는다. request inspection 또는 observability console은 정의상 payload storage이며, 앞 구간의 tracing SaaS와 정확히 같다. gateway 측 caching도 gateway 구간에 프롬프트 내용을 저장한다. semantic cache는 프롬프트의 embedding과 전체 cached response를 보관하고, response cache는 요청과 응답 양쪽을 gateway가 실행되는 disk에 그대로 저장한다. SaaS든 self-hosted든 gateway를 평가할 때는 같은 질문을 세 부분으로 나눠 확인해야 한다. request record에 무엇이 들어가는가, observability view가 무엇을 보존하는가, cache가 무엇을 기록하는가?

provider의 보존 정책은 회사가 아니라 기능별로 정해진다. 유용한 기준은 기능별 적용 여부를 공개한 Anthropic의 API 데이터 보존 문서에서 확인할 수 있다. prompt caching은 cache state를 memory에만 유지하므로 ZDR 적용 대상이다. batch processing은 async job에 storage가 필요하므로 job을 29일간 저장한다. code execution container는 최대 30일간 유지되며, 업로드한 파일은 사용자가 삭제할 때까지 남는다. 이 문서의 솔직한 설명은 그대로 인용할 만하다. stateful feature를 사용하는 것은 해당 데이터에 한해 “ZDR 계약 범위를 벗어나기로 선택하는 것”이다. OpenAI의 data controls 문서는 ZDR을 적용할 수 있는 endpoint를 나열하고, abuse monitoring log를 기본적으로 최대 30일간 보관한다고 설명한다. cached prompt는 암호화된 key-value tensor 형태로 GPU-local storage에 저장되며 TTL 상한이 있다. Claude API의 일반 상용 데이터는 30일 이내에 삭제된다.

데이터는 물리적으로 어디에 저장되는가?

실제 serving infrastructure가 있는 곳에 저장된다. provider 유형에 따라 답이 달라진다. cloud-hosted model은 가장 명확하다. Amazon Bedrock에서는 cloud provider가 data processor이며 inference는 선택한 region 안에서 처리된다. 규제 대상 구매자가 이 방식을 먼저 선택하는 이유다. model vendor의 자체 API는 vendor가 운영하는 위치에서 실행된다. OpenAI는 대부분의 endpoint에 미국과 EU regional processing을 제공하지만, 규모가 작은 vendor는 위치 정보를 공개하지 않는 경우가 많다. 가장 명확한 극단은 DeepSeek다. privacy policy에 따르면 personal data는 중화인민공화국에서 수집, 처리, 저장되며 공식 API에는 미국이나 EU 선택지가 없다. 같은 open weights를 미국 GPU host에서 제공하면 이러한 지역 조건이 적용되지 않는다. 즉, 모델의 데이터가 어디로 가는지는 모델이 아니라 누가 serving하느냐에 따라 결정된다.

Primary copy 외에도 두 가지가 더 남는다. cache와 batch file은 각각의 수명 동안 serving region에 존재하며 request log와 별도로 관리된다. 또한 모든 provider는 subprocessor, 즉 자체 downstream vendor와 backup을 사용한다. deletion commitment는 일반적으로 active system에서 삭제한다는 식으로 표현되며, backup에는 별도의 propagation window가 적용된다. data flow diagram이 API vendor 로고에서 끝난다면 적어도 이 두 구성 요소가 빠져 있다.

누가 데이터 보존을 요구하며, 누가 프롬프트로 training하는가?

기본 기간보다 오래 데이터를 유지시키는 요인은 세 가지다. 그중 provider의 marketing에 등장하는 것은 하나뿐이다.

Policy requirement. 일부 모델은 안전 조건으로 데이터 보존을 의무화한다. Claude Fable 5와 Mythos 5는 ZDR 고객에게도 30일 보존을 요구한다. 이 조건은 명시적으로 실패하는 방식으로 적용된다. 조직의 보존 설정이 요구사항을 충족하지 못하면 요청을 조용히 받아들이는 대신 400으로 거부한다. abuse escalation도 별도의 policy 기간을 만든다. usage policy 위반으로 flag된 content는 완전히 다른 기준으로 보관된다. Anthropic의 consumer policy는 flag된 input과 output을 최대 2년, classifier score를 최대 7년 보관한다고 명시한다.

Legal hold. NYT 대 OpenAI 소송은 데이터 보존 약속을 검증한 가장 명확한 실제 사례였다. 2025년 5월 증거 보존 명령에 따라 OpenAI는 원래 삭제했어야 할 output log를 consumer tier 전반에서 보존해야 했다. 사용자가 삭제한 chat도 포함됐다. 명령 범위는 그해 9월 축소됐고, 이후 법원은 discovery 과정에서 chat log 2천만 건을 제출하라고 명령했다. API 구매자에게 중요한 세부 사항은 enterprise와 zero-data-retention 고객이 예외로 분리됐다는 점이다. 보존할 데이터 자체가 없었기 때문이다. deletion policy는 litigation hold에 따라 바뀔 수 있지만, 애초에 데이터를 저장하지 않는 architecture는 그렇지 않다.

데이터를 수집하는 중간 사업자. 경로 중간에서 평문을 수익화하다 적발되는 사례도 있다. 문서로 확인된 가장 큰 사례는 사용자와 가장 가까운 위치에서 발생했다. 2025년 12월, security researcher들은 수백만 회 설치된 “privacy” VPN browser extension이 AI chat page에 script를 주입했다고 밝혔다. 이 extension은 ChatGPT, Claude, Gemini와 그 밖의 assistant 5개에서 모든 프롬프트와 응답을 가로채 data broker 계열사로 전송했다. 수집은 VPN이 켜져 있는지와 관계없이 이뤄졌으며, 해당 publisher의 extension 제품군을 사용하는 약 800만 명이 영향을 받았다. 이 사건의 주체는 API gateway가 아니라 client-side interceptor였지만, 교훈은 구성도의 모든 요소에 동일하게 적용된다. 평문을 처리하는 모든 intermediary는 수집 지점이 될 수 있고, monetization이라는 동기가 있으며, 양쪽 endpoint에서는 interception을 확인할 수 없다. 중간 사업자를 신뢰한다는 것은 feature list가 아니라 business model을 신뢰한다는 뜻이다.

Training clause. 주요 vendor의 business API는 기본적으로 고객 데이터로 training하지 않는다. 반면 consumer product는 opt-out하지 않으면 training에 사용하는 경우가 늘고 있다. agent traffic에 consumer account가 아닌 API key를 써야 하는 또 하나의 이유다. 사용자가 직접 찾아야 하는 toggle로 training 여부를 설정하는 product도 늘고 있다. consumer plan은 training이 기본으로 켜져 있고 settings 깊숙한 곳에서 opt-out해야 한다. developer tool에서는 telemetry나 code sharing 설정이 training 동의로도 쓰인다. vendor program은 data sharing opt-in을 할인이나 free quota와 교환한다. aggregator dashboard에는 paid tier와 free tier의 training switch가 별도로 존재한다. 각 toggle은 account 단위이며 때로는 workspace 단위다. 기본값은 terms update와 함께 바뀔 수 있으므로 “한 번 확인했다”로는 부족하다. 이러한 switch 점검도 key rotation과 같은 정기 checklist에 포함해야 한다.

Free model을 별도로 강조하는 이유. 앞의 모든 위험이 한곳에 집중된다. 바로 free tier다. 무료 모델 출시에 필요한 비용은 대개 traffic에서 이익을 얻는 주체, 주로 모델 자체의 vendor가 부담한다. 따라서 free variant로 보낸 프롬프트는 해당 주체의 policy에 따라 전달되며, 흔히 training 권한도 거래 조건에 포함된다. 처리 위치도 그 주체의 운영 지역을 따른다. 중국 vendor라면 중국이다. aggregator gateway가 endpoint별 data policy와 training provider 제외 switch를 제공하는 이유도 free route에 이러한 조항이 집중되기 때문이다. 원칙은 단순하다. free endpoint를 API call이 아니라 data submission으로 취급해야 한다. 무료 inference 비용은 어떤 방식으로든 지불되며, 그 대가는 대개 사용자의 프롬프트다.

ZDR은 실제로 무엇을 의미하는가?

ZDR은 chain의 한 주체에 대해, 대상 기능에 한해, 세 축 중 하나를 고정한다. 이는 단점이 아니라 정의다. 경계를 정확히 알아야 제대로 활용할 수 있다.

• 세 가지 축. Training use, retention duration, human access는 서로 독립적이다. business API는 이미 고객 데이터로 training하지 않는다. ZDR은 payload의 보존 기간을 0으로 만든다. human access는 별도의 abuse process에 따라 관리된다. 이를 한데 묶으면 ZDR의 범위를 과장하게 된다.
• ZDR에서도 남는 데이터. usage metadata와 billing record, safety classifier output, 사용자가 opt-in한 stateful feature다. 두 주요 vendor는 이제 abuse monitoring 예외를 우회하는 대신 그 요건에 맞춰 설계한다. 한쪽은 payload가 없는 safety signal을, 다른 쪽은 classifier result만 보관한다.
• ZDR이 적용되지 않는 범위. provider 왼쪽의 모든 요소다. tracing store, gateway log, vector memory가 여기에 포함된다. model vendor와 ZDR을 계약해 놓고 tracing SaaS에 모든 프롬프트를 무기한 보관하는 구성이 가장 흔하며, 동시에 가장 앞뒤가 맞지 않는다.
• Self-hosting의 조건. 자체 GPU에서 open weights를 실행하면 모든 제3자를 제거할 수 있다. 대신 inference server request logging, access log, trace file 문제가 모두 자체 infrastructure로 넘어온다. self-hosting은 retention surface의 위치를 옮길 뿐이다. 이를 줄이려면 의도적으로 log hygiene을 적용해야 한다.

Synthorai의 처리 방식

gateway 구간은 Synthorai가 담당하므로 명확하게 약속할 수 있다. zero-retention mode에서는 request와 response body를 memory에서만 통과시키며 저장소에 기록하지 않는다. 유지되는 정보는 billing에 필요한 usage record뿐이다. timestamp, model, token count, 그리고 발언 내용을 저장하지 않고도 분쟁 시 request를 대조할 수 있는 content hash다. Upstream provider는 routing 전에 걸러진다. Synthorai는 자사 traffic에 zero data retention을 약속한 provider만 onboarding한다. 문서화된 유일한 예외는 Claude Fable 5다. 30일 보존이 model vendor의 의무 조건이어서 계약으로 없앨 수 없다. provider 선택은 곧 보존 정책 선택이다. gateway의 역할은 이 속성을 policy PDF에 숨기지 않고 route별로 명확히 표시하는 것이다. Fable 5 route에는 예기치 않은 조건이 아니라 문서화된 metadata로 보존 요구사항이 포함된다.

FAQ

LLM provider는 기본적으로 API 데이터로 training하는가?

아니다. 주요 vendor의 business API는 기본적으로 고객 데이터로 training하지 않으며, 이 약속은 각 provider의 data controls 문서에 명시돼 있다. 예외는 주로 그 밖의 영역에 몰려 있다. opt-in이 아니라 opt-out 방식인 consumer product, open weights를 제공하는 일부 GPU host, training 권한이 비용에 포함된 free-tier endpoint가 해당한다.

ZDR이면 provider가 아무것도 저장하지 않는다는 뜻인가?

아니다. ZDR은 대상 기능에서 프롬프트와 응답 payload를 보관하지 않는다는 의미다. usage metadata, billing record, safety classifier output은 남는다. batch job이나 file upload 같은 stateful feature는 특성상 데이터를 저장하므로 ZDR 범위 밖에 있다. headline이 아니라 feature eligibility table을 확인해야 한다.

Free model에 production data를 보내도 안전한가?

free endpoint를 API call이 아니라 data submission으로 취급해야 한다. 무료 용량은 traffic에서 이익을 얻는 주체가 비용을 부담한다. training 권한이 거래 조건에 포함되는 경우가 많으며, 데이터는 그 주체가 운영하는 지역에서 처리된다. 일회성 실험에는 괜찮은 선택일 수 있다. customer data, code, credential이 포함된다면 적절한 경우가 드물다.

Self-hosting이 항상 privacy 측면에서 가장 좋은 선택인가?

평문 경로에서 모든 제3자를 제거한다는 실질적인 장점이 있다. 하지만 데이터 보존까지 없어지지는 않는다. inference server, reverse proxy, tracing은 모두 기본적으로 log를 남긴다. 따라서 기본 logging 설정을 그대로 쓴 self-hosted stack이 ZDR API 구성보다 더 많은 프롬프트 데이터를 보관할 수도 있다. privacy는 hosting model이 아니라 logging configuration을 따른다.

출처 확인일 2026-08-29: 위의 모든 provider 관련 주장은 vendor 자체 문서 또는 법원의 primary record에 연결되어 있다. 이 분야의 policy는 게시 전 한 달 동안 두 차례 변경됐으므로 link된 문서를 현재 기준의 source of truth로 봐야 한다. 이는 engineering 관점의 해석이며 legal advice가 아니다.

관련 글: Fable 5의 30일 보존 요구사항, prompt caching의 작동 방식, provider cache 비교.

← 블로그로 돌아가기