결론부터 말하면, “API 데이터는 학습에 사용하지 않는다”는 문구만으로 소스 코드나 고객 데이터를 보내면 안 됩니다. 일반적인 LLM API 보존 정책을 받아들일 수 있는 것은 공개 문서, 합성 데이터처럼 영향이 낮고 보존 기간과 사용 목적을 승인한 작업입니다. 비공개 저장소, 운영 로그, 고객 식별 정보, 미공개 취약점 정보처럼 유출 영향이 큰 입력에는 계약상 Zero Data Retention(ZDR)과 기술 설정을 모두 확인해야 합니다.
검토 단위도 회사 이름이 아니라 실제 요청 경로여야 합니다. 애플리케이션 → observability → gateway → upstream provider → endpoint/model → search·file·agent 같은 feature를 하나의 route로 기록합니다. 학습, 악용 방지 로그, provider 상태, feature 저장소, 하위 처리자, 우리 시스템의 로그라는 여섯 저장면 중 하나라도 unknown이면 민감한 traffic은 fail-closed, 즉 차단합니다.
배포 전 60초 판단
아래 세 줄로 첫 판단을 내릴 수 있습니다.
| 입력과 증거 상태 | 배포 판단 | 다음 행동 |
|---|---|---|
| 공개 정보 또는 합성 데이터이며 일반 보존을 위험 승인함 | 조건부 허용 | 보존 기간, 삭제 owner, 자체 로그를 evidence card에 남긴다. |
| 민감 데이터이며 정확한 route가 ZDR 대상이고 여섯 저장면이 모두 확인됨 | 보안·법무 승인 후 허용 | 비민감 canary를 실행하고 설정 증거와 재검토 날짜를 고정한다. |
| 민감 데이터인데 upstream, gateway, feature, 로그 중 하나라도 불명확함 | 차단 | 실제 데이터를 보내지 말고 계약·설정·route를 보완한다. |
여기서 완료 기준은 “문서를 읽었다”가 아닙니다. 실행 중인 organization/project/workspace, endpoint, model, feature, gateway와 log sink가 문서 및 계약의 범위와 일치하고, 그 증거를 코드 변경과 연결할 수 있어야 합니다. 이 조건을 충족하지 못하면 개발자가 store=false를 추가했더라도 배포를 허용하지 않습니다.
“학습 안 함”, “보존 제한”, “ZDR”은 서로 다른 주장이다
보안 검토에서 가장 자주 섞이는 문장은 다음 세 가지입니다.
- 학습에 사용하지 않음: 입력과 출력을 모델 개선에 쓰지 않는다는 뜻입니다. 악용 방지 로그나 application state가 남지 않는다는 뜻은 아닙니다.
- 기간을 정해 보존함: 예를 들어 abuse monitoring을 위해 일정 기간 저장한 뒤 삭제하는 정책입니다. 삭제 전에는 데이터가 존재합니다.
- Zero Data Retention: 계약과 제품 정의가 지정한 content를 응답 이후 저장하지 않는 통제입니다. 그렇더라도 법적·안전 예외, 비대상 feature, 하위 서비스, 고객이 만든 로그가 남을 수 있습니다.
따라서 ZDR은 하나의 boolean 옵션이 아닙니다. store=false 역시 특정 endpoint의 application state를 끌 수 있는 설정일 뿐, organization이 ZDR 승인을 받았는지, 도구가 데이터를 저장하는지, gateway가 prompt를 기록하는지까지 증명하지 못합니다.
2026-07-27에 확인한 OpenAI API 데이터 통제 문서는 기본 abuse-monitoring 로그가 고객 content를 포함할 수 있고 최대 30일 보존될 수 있다고 설명합니다. 적격 고객은 Modified Abuse Monitoring 또는 ZDR 승인을 요청할 수 있습니다. 같은 문서에서 ZDR이 적용된 /v1/responses와 /v1/chat/completions는 store=false로 처리되지만, Conversations, Files, vector stores, batch처럼 별도 상태가 필요한 항목은 범위가 다릅니다. 그래서 “OpenAI는 ZDR이다”가 아니라 “이 organization의 이 endpoint와 feature 조합이 ZDR 대상이다”라고 기록해야 합니다.
소스 코드와 취약점 데이터의 등급부터 고정한다
모든 코드가 같은 민감도를 갖지는 않습니다. README 예제와 공개 OSS 코드는 일반 보존 route에서도 처리할 수 있지만, 운영 secret이 섞인 configuration, 고객별 business rule, 내부 repository 전체, 아직 공개되지 않은 취약점 재현 정보는 유출 영향이 훨씬 큽니다.
배포 전 분류표는 최소한 다음처럼 동작해야 합니다.
| 데이터 등급 | 예시 | 기본 route | 승인 조건 |
|---|---|---|---|
| Public | 공개 저장소, 공개 API 문서, 이미 공개된 advisory | 일반 API 가능 | 자체 로그의 보존 기간과 삭제 절차 확인 |
| Internal | 사내 convention, 비공개 test code, 식별자를 제거한 운영 사례 | 제한 route | 최소 전송, 짧은 자체 보존, owner 승인 |
| Confidential | 독점 algorithm, 고객 입력, 운영 장애 dump, 내부 architecture | 검증된 ZDR 우선 | 여섯 저장면 pass, 계약과 설정 증거, 보안 승인 |
| Restricted | secret, credential, private key, 원본 개인정보, 규제상 별도 통제가 필요한 데이터 | 기본 차단 | 전송하지 않고 secret 제거·토큰화·로컬 처리부터 검토 |
ZDR은 Restricted 데이터를 자동으로 허용하는 면허가 아닙니다. API 호출 전에 secret scanner와 개인정보 탐지기를 실행하고, 필요한 줄이나 함수만 잘라 보내며, 실제 고객 값은 대체값이나 synthetic fixture로 바꾸는 것이 먼저입니다. 조직의 개인정보·금융·의료 규칙이 적용된다면 별도 법무 및 보안 검토가 필요합니다.
여섯 저장면: 하나라도 빠지면 ZDR 검토가 아니다
공급자 문구를 실제 architecture와 연결하려면 보존 위치를 여섯 면으로 나눠야 합니다.
| 저장면 | 확인 질문 | 필요한 증거 | 차단 조건 |
|---|---|---|---|
| 1. 모델 학습 | 입력·출력이 모델 개선에 쓰이는가 | API commercial terms, opt-out 또는 paid-service 조건 | training use가 허용되거나 불명확함 |
| 2. 악용·안전 로그 | content가 abuse review에 남는가, 기간은 얼마인가 | ZDR/modified monitoring 승인, admin 상태 | 기본 로그만 있고 민감도와 맞지 않음 |
| 3. Provider application state | API object, conversation, thread, response가 저장되는가 | endpoint별 retention 표, store 설정 | stateful endpoint가 ZDR 비대상 |
| 4. Feature 저장소 | file, cache, batch, agent, search, code execution이 별도 저장하는가 | 활성 feature inventory와 각 feature 문서 | feature 예외가 발견되거나 TTL이 정책 초과 |
| 5. 하위 처리자·도구 | gateway, upstream, MCP, web search, model host가 저장하는가 | 전체 route, subprocessor 목록, endpoint policy | upstream을 고를 수 없거나 정책 증거가 없음 |
| 6. 우리 로그·DB | APM, trace, Sentry, prompt analytics, retry queue에 content가 남는가 | log schema, redaction, TTL, 삭제 test | prompt/output이 무기한 또는 광범위하게 기록됨 |
이 프레임의 핵심은 provider-side 삭제와 customer-side 저장을 분리하는 것입니다. 공급자가 응답 뒤 content를 보존하지 않아도 우리 서버가 request body를 debug log에 남기면 전체 system은 ZDR이 아닙니다. 반대로 provider가 일반 보존을 하더라도 공개 데이터 작업에는 위험 승인 후 사용할 수 있습니다. 판단은 marketing label이 아니라 데이터 등급과 여섯 면의 조합입니다.
현재 provider route를 어떻게 읽어야 하나
아래는 2026-07-27 공식 문서를 route 검토용으로 정리한 것입니다. “어느 회사가 가장 안전한가” 순위가 아니며, 모델이나 feature가 바뀌면 다시 확인해야 합니다.
| Route | 현재 공식 문서에서 확인할 수 있는 것 | 놓치기 쉬운 경계 | Release evidence |
|---|---|---|---|
| OpenAI API | 적격 organization/project는 MAM 또는 ZDR 승인을 요청할 수 있고, 지원 endpoint는 ZDR에서 store=false로 처리 | Conversations, Files, vector stores, batch, background mode, MCP 등은 각자 저장 요건이 다름 | organization/project 승인 상태, endpoint와 feature 표, request config |
| Anthropic API | ZDR 계약에서 eligible Messages와 Token Counting의 prompt/response를 응답 후 at-rest 저장하지 않음 | Managed Agents, Files, batch, code execution, MCP connector 및 일부 모델은 비대상 | organization 계약, model/feature inventory, trust-and-safety 예외 |
| Gemini Developer API Paid Services | paid service content는 제품 개선에 쓰지 않으며, 승인된 project ZDR은 abuse log 전에 content와 식별 metadata를 제거 | Search/Maps grounding은 30일 저장. AI Studio logs/datasets는 Interactions 기본 store=true, Generate Content 기본 store=false와 request/project logging을 별도 설명하며, logs는 기본 55일(7/14/28/55일), dataset 저장 후 자동 만료되지 않음 | project 승인, 유효 store, project logging, dataset/export/share, feature별 TTL·삭제 |
| Azure Direct Models | 허가 없이 prompt/output을 foundation model 학습에 쓰지 않으며, 승인 resource는 modified abuse monitoring 상태를 확인 가능 | stateful feature는 고객 Azure resource에 저장될 수 있음 | resource ID, ContentLogging=false 증거, 저장 resource 목록 |
| Amazon Bedrock | AWS는 model provider가 Bedrock deployment account, prompt와 completion에 접근하지 못한다고 설명 | invocation logging, CloudTrail, agent, knowledge base, session은 고객 AWS 측 저장면 | account/region, log 설정, KMS·TTL·삭제 owner |
| Gateway/aggregator | gateway가 endpoint별 ZDR route나 no-training 정책을 제공할 수 있음 | gateway 자체 log, 실제 upstream, fallback, 하위 처리자, endpoint 분류가 모두 추가 경계 | gateway 계약과 설정, 고정 upstream, fallback 차단, upstream 증거 |
Anthropic의 API 데이터 보존 문서는 ZDR이 organization 단위 계약이며 지원 feature가 한정됨을 명시합니다. 특히 ZDR 비대상 feature가 항상 자동으로 막히는 것은 아니므로, 호출자가 inventory를 관리해야 합니다.
Gemini Developer API ZDR 문서는 approved project와 feature별 예외를 구분합니다. Search 또는 Maps grounding은 prompt, context, output을 30일 저장하며 끌 수 없습니다. Interactions의 실제 store, Generate Content logging, AI Studio project logging, log 보존 기간과 dataset 생성·export·공유·삭제는 abuse-monitoring ZDR과 별도 evidence로 남겨야 합니다. Live API session resumption, File API, explicit context cache도 독립된 저장 수명주기를 갖습니다.
Microsoft의 Azure Direct Models 데이터 문서와 Amazon Bedrock 데이터 보호 문서는 cloud route에서 “모델 공급자가 학습하지 않는다”와 “고객 cloud resource가 아무것도 저장하지 않는다”가 다른 주장임을 보여 줍니다. 이 route에서는 고객 계정의 logging, storage, identity와 삭제 owner까지 함께 심사해야 합니다.
Gateway도 예외가 아닙니다. 예를 들어 OpenRouter ZDR routing 문서는 endpoint 분류에 따라 ZDR route만 허용하는 정책을 설명하고 no-training과 no-retention을 분리합니다. 이는 해당 gateway의 분류와 계약이지, 모든 upstream의 독립 인증은 아닙니다. 공개 ZDR 조건, 정확한 upstream, fallback과 자체 logging을 검증하지 못한 gateway는 어느 브랜드든 ZDR 필수 workload에 추천해서는 안 됩니다.
Route Evidence Card를 만든다
승인 결과를 회의록에만 남기면 다음 model 변경 때 재사용할 수 없습니다. repository 안에 secret이 없는 evidence card를 두고, 실제 계약·admin screenshot은 접근 통제된 GRC나 ticket system의 ID로 연결합니다.
yamlretention_evidence: workload: source-review data_class: confidential owner: appsec-team route: application: code-review-service observability: redacted-traces gateway: none provider: exact-provider-name organization_or_project: grc-reference-only endpoint: exact-endpoint model: exact-model-version features: [text-only] fallback: disabled storage_planes: training: pass abuse_logs: pass application_state: pass feature_storage: pass subprocessors: pass customer_logs: pass evidence: contract_id: GRC-0000 admin_config_id: SEC-0000 official_scope_checked: "2026-07-27" deletion_test_id: TEST-0000 stop_rules: unknown_field: block route_drift: block new_feature: block recheck: owner: appsec-team due: "YYYY-MM-DD"
이 card에는 API key, customer content, prompt sample 또는 계약 원문을 넣지 않습니다. 증거 ID, 확인 날짜, 승인 owner와 결과만 기록합니다. pass는 추정값이 아니라 공식 scope 또는 계약, admin 설정, 우리 log 설정이라는 재현 가능한 근거가 있을 때만 사용합니다.
CI/CD를 fail-closed release gate로 바꾼다
문서 승인을 받은 다음 문제는 route drift입니다. 개발자가 web search를 켜거나, fallback provider를 추가하거나, store 기본값·project logging·log retention을 바꾸거나, dataset을 생성/export/share하거나, observability SDK가 request body capture를 시작하면 어제의 승인은 오늘의 배포를 보장하지 않습니다.
CI/CD gate는 최소한 다음 조건을 검사해야 합니다.
- 배포 manifest의 provider, organization/project, endpoint, model, feature와 fallback이 evidence card와 같은가.
- 민감 data class에서 여섯 저장면이 전부
pass인가. - 계약·공식 scope·admin config 증거가 만료되지 않았는가.
- 새 SDK, MCP server, search, file, cache, batch, agent, code execution 또는 tracing integration이 추가되지 않았는가.
- redaction test와 log deletion test가 성공했는가.
판단 로직은 단순해야 합니다.
textif data_class in ["confidential", "restricted"]: if any(storage_plane != "pass"): block_release() if deployed_route != approved_route: block_release() if evidence_expired or redaction_test_failed: block_release()
unknown을 경고로만 처리하면 gate가 아닙니다. 민감 workload에서는 차단하고, 공개·합성 fixture로만 canary를 실행합니다. 예외 승인이 필요하면 사람, 사유, 만료 날짜, 제한된 traffic scope를 기록하고 자동 만료시킵니다.
자체 로그가 provider ZDR을 무효화하지 않게 한다
실무에서 가장 가까운 저장소는 provider보다 우리 application일 때가 많습니다. HTTP middleware, reverse proxy, APM, Sentry, OpenTelemetry collector, prompt observability, job queue, dead-letter queue, support ticket가 prompt와 output을 복제할 수 있습니다.
점검은 실제 비민감 marker를 사용합니다. 예를 들어 RETENTION_CANARY_20260727을 합성 prompt에 넣고 request가 끝난 뒤 허용되지 않은 log index, trace attribute, error payload, queue, data warehouse에 marker가 검색되는지 확인합니다. 발견되면 다음을 고칩니다.
- request/response body capture를 기본 off로 두고 필요한 field만 allowlist한다.
- authorization, cookie, secret, 개인정보와 source fragment를 ingest 전에 redaction한다.
- debug sampling은 비민감 environment와 합성 payload로 제한한다.
- log, trace, cache, backup별 TTL과 삭제 owner를 따로 지정한다.
- retry와 dead-letter payload는 content가 아니라 reference ID만 보관한다.
- 삭제 test가 primary index뿐 아니라 replica, export와 support workflow까지 확인하게 한다.
Canary가 검색되지 않았다고 provider가 ZDR임을 증명하는 것은 아닙니다. 이 test는 여섯 번째 저장면인 customer-owned logging을 검증할 뿐이고, provider와 gateway는 계약 및 설정 증거로 별도 확인합니다.
보안 검토부터 작은 배포까지
민감 데이터를 보내기 전에 아래 순서로 진행합니다.
- workload를 Public, Internal, Confidential, Restricted로 분류하고 최소 input만 정의합니다.
- application부터 upstream까지 route를 그려 gateway, fallback, tool과 observability를 모두 적습니다.
- 여섯 저장면 각각의 source owner와 증거를 수집합니다.
- exact endpoint, model, feature가 ZDR 또는 승인된 보존 정책의 범위인지 확인합니다.
- secret과 개인정보 탐지, redaction, log TTL, 삭제 test를 실행합니다.
- evidence card를 승인받고 CI/CD gate를 활성화합니다.
- 합성 canary로 먼저 호출한 뒤, 승인된 data class만 작은 traffic slice로 엽니다.
- policy, contract, provider, model, endpoint, feature, gateway 또는 SDK가 바뀌면 자동으로 재심사합니다.
다음 중 하나라도 해당하면 배포를 중단합니다: upstream이 동적으로 바뀌는데 endpoint별 정책을 고정할 수 없음, ZDR scope가 계약과 admin 화면에서 확인되지 않음, stateful feature가 비대상임, 우리 log에서 content를 제거할 수 없음, 삭제 owner가 없음, 법무·보안 승인 범위를 넘어선 data class가 들어옴.
ZDR 확인 뒤에 비용을 비교한다
보안 조건을 통과하지 못한 저가 API는 후보가 아닙니다. 먼저 approved route set을 만든 뒤 그 안에서 latency, 품질, quota와 비용을 비교해야 합니다. 비용 검토가 다음 단계라면 한국어 LLM API 비용·품질·게이트웨이 리스크 비교로 이어갈 수 있습니다.
Google consumer/계정 기록 삭제가 주된 문제라면 API route ZDR과 다른 작업입니다. 그 경우 Google AI 데이터 삭제 경로에서 Gemini 활동, 계정 기록과 제품별 owner를 분리해 확인해야 합니다. MCP를 통해 사내 도구를 연결한다면 Claude MCP 내부 도구 API 통합 가이드의 tool boundary도 별도 심사합니다.
최종 판단
LLM API 데이터 보존과 ZDR의 차이는 “며칠 저장하는가” 하나가 아닙니다. 학습, 악용 방지, provider state, feature storage, subprocessor, customer log라는 여섯 면의 책임과 증거가 다릅니다.
소스 코드나 고객 데이터를 배포하려면 정확한 route evidence card를 만들고, 모든 critical field를 pass로 증명하고, 변경 시 CI/CD가 자동으로 차단하게 하십시오. 공식 문서나 계약에서 빠진 route를 추정으로 채우지 말고, store=false나 upstream ZDR badge 하나로 gateway와 자체 로그까지 안전하다고 확대 해석하지 마십시오. 민감 데이터 + 불명확한 저장면 = 배포 중단이 가장 작고 재현 가능한 규칙입니다.
