OpenAI ZDR 확장 발표: 한국 기업 AI의 데이터 보존 설계를 다시 묻다

OpenAI는 2026년 8월 19일 프런티어 모델에도 제로 데이터 보존(Zero Data Retention, ZDR)을 제공하고, 여러 상호작용의 위험 패턴을 원문 노출 없이 찾는 Private Safety Processing을 시험한다고 발표했습니다. 한국 기업이 바로 해야 할 일은 “ZDR이면 아무 데이터도 남지 않는다”고 홍보하는 것이 아니라, 실제 사용하는 엔드포인트와 도구별 보존 동작을 표로 만들고 사내 로그·벡터 저장소·상담 시스템까지 포함한 전체 데이터 흐름을 다시 확인하는 것입니다.

확인된 사실: OpenAI의 8월 19일 발표는 적격 API 고객의 프롬프트와 응답을 요청 처리 후 보존하지 않는 ZDR 방향을 설명합니다. Private Safety Processing은 고객 통제 인프라를 이용하는 초기 고객 시험으로 소개됐습니다. 고객 관리 키로 OpenAI 저장 데이터를 암호화하는 방식은 현재 제공 기능이 아니라 개발 중인 옵션이라고 별도로 밝혔습니다. 공식 데이터 제어 문서는 기본 악용 모니터링 로그가 최대 30일 보존될 수 있고 ZDR은 사전 승인과 제한 조건이 있으며, 일부 기능은 애플리케이션 상태를 보존할 수 있다고 안내합니다.

>

POEMORA의 해석: ZDR은 제품 전체에 붙는 단일 스위치가 아니라 워크로드별 검증 항목입니다. 계약 문구보다 실제 요청 경로와 주변 시스템의 저장 행위를 증명해야 합니다.

2026년 8월 19일 발표의 핵심 변화

OpenAI는 기존 ZDR 호환 안전 시스템이 개별 상호작용을 평가하는 데서 나아가, Private Safety Processing이 관련 상호작용 사이의 패턴을 자동으로 식별하도록 설계됐다고 밝혔습니다. 발표 당시 Private Safety Processing은 고객이 통제하는 인프라에 콘텐츠를 두는 방식으로 초기 고객과 시험 중이었습니다. OpenAI 인프라에 저장하되 고객이 키를 통제하는 암호화 방식은 현재 제공 기능이 아니라 개발 중인 옵션으로 별도 소개됐습니다. 위험이 식별되면 OpenAI에는 활동 유형을 나타내는 제한된 신호가 전달되며, 직원이 기본 원문 프롬프트나 응답에 접근하지 않는다는 것이 발표의 요지입니다.

Private Safety Processing은 발표 당시 초기 고객과 시험 중이었고, 고객 관리 키 저장 옵션은 별도로 개발 중인 상태였습니다. 일반 제공 범위, 세부 기술 조건, 국내 고객의 자격을 확정된 사실처럼 말해서는 안 됩니다. 도입 검토 문서에는 발표된 방향과 현재 계약상 제공되는 기능을 별도 칸으로 나눠야 합니다.

ZDR이 뜻하는 것과 뜻하지 않는 것

OpenAI의 공식 데이터 제어 문서는 API 데이터가 명시적 옵트인 없이는 모델 학습에 사용되지 않는다고 설명합니다. 동시에 기본 악용 모니터링 로그에는 프롬프트와 응답 등 고객 콘텐츠가 포함될 수 있고 최대 30일 보존될 수 있다고 안내합니다. 승인된 고객은 Modified Abuse Monitoring 또는 ZDR을 조직이나 프로젝트 단위로 선택할 수 있지만, 사전 승인과 추가 요구사항이 적용됩니다.

ZDR이 켜진 조직에서는 Responses API와 Chat Completions API의 store 값이 요청에서 true여도 false로 처리됩니다. 그러나 공식 문서는 ZDR 비적격 엔드포인트나 기능이 애플리케이션 상태를 보존할 수 있다고 경고합니다. 따라서 다음 세 문장은 서로 다릅니다.

한국 기업이 먼저 그릴 데이터 흐름

첫째, 사용자 입력이 브라우저나 앱에서 API로 직접 가는지, 사내 백엔드·게이트웨이·보안 프록시를 지나는지 표시합니다. 둘째, 프롬프트 템플릿, 첨부 파일, 검색 증강 생성(RAG) 문서, 도구 호출 결과, 최종 응답을 각각 다른 데이터 종류로 나눕니다. 셋째, 각 구간의 저장 위치, 암호화 키 소유자, 접근 역할, 삭제 주기, 백업 반영 시점을 적습니다.

여기서 주민등록번호, 건강정보, 고객 상담, 미공개 계약서처럼 민감도가 높은 입력은 “모델로 전송 가능” 여부를 업무 규칙으로 따로 정해야 합니다. 공급자 설정이 안전하더라도 사내 관측 도구가 요청 본문을 그대로 수집하거나 오류 추적 서비스가 첨부 파일을 저장하면 전체 시스템은 ZDR이 아닙니다. 이것은 OpenAI 발표의 직접 문구가 아니라 POEMORA의 한국 실무 해석입니다.

AI 기능의 요청 경로와 보존 정책을 서비스 설계 단계에서 정리하려면 POEMORA 웹 서비스의 개발 범위를 참고할 수 있습니다.

구매·보안·개발팀 공동 점검표

1. 구매팀은 조직과 프로젝트에 승인된 보존 모드, 적용 모델, 예외, 변경 통지 절차를 계약과 관리자 화면에서 대조합니다.
2. 보안팀은 공급자뿐 아니라 API 게이트웨이, 웹 애플리케이션 방화벽, 로그 수집기, 분석 도구, 백업에서 요청 본문이 남는지 확인합니다.
3. 개발팀은 사용 중인 모든 엔드포인트와 호스팅 도구를 공식 적격 표에 매핑하고, store 설정만으로 판정을 끝내지 않습니다.
4. 개인정보 담당자는 처리 목적, 항목, 국외 이전, 보존 기간, 삭제와 정보주체 대응 절차를 실제 흐름에 맞춰 검토합니다.
5. 운영팀은 모델 또는 기능 변경 시 보존 정책 회귀 테스트를 배포 체크리스트에 넣습니다.

• [ ] 운영 프로젝트와 개발 프로젝트의 데이터 제어 설정을 각각 캡처해 승인 기록에 연결했다.
• [ ] 오류 로그에서 프롬프트와 응답 본문을 기본 마스킹했다.
• [ ] 파일·이미지·음성·도구 사용 시 별도 제한을 공식 표에서 확인했다.
• [ ] 삭제 요청이 원본 DB뿐 아니라 캐시와 백업 정책에도 반영되는지 시험했다.
• [ ] 공급자의 기능 변경일과 사내 마지막 검토일을 함께 기록했다.

프리뷰 기능을 도입할 때의 안전한 순서

Private Safety Processing은 2026년 8월 19일 발표 시점에 초기 고객과 시험 중이었습니다. 고객 관리 키로 OpenAI 저장 데이터를 암호화하는 옵션은 같은 발표에서 개발 중이라고 밝혔습니다. 따라서 실제 도입 전에는 두 기능의 이용 가능 여부를 각각 확인하고, 안전 신호의 종류와 이의 제기 절차도 공급자와 검토해야 합니다. 발표문에 나온 설계를 곧바로 모든 계정의 현재 동작으로 간주하면 안 됩니다.

권장 순서는 비민감 테스트 프로젝트에서 엔드포인트별 저장 행위를 확인하고, 사내 로그 마스킹을 먼저 적용한 뒤, 제한된 업무로 파일럿을 여는 것입니다. 테스트에는 정상 요청뿐 아니라 실패·재시도·도구 호출·파일 업로드·관리자 조회·삭제 요청을 포함해야 합니다. 결과는 “설정 완료”가 아니라 어떤 데이터가 어느 구간에서 얼마 동안 남았는지로 기록하십시오.

경영진에게 보고할 때 피해야 할 표현

“데이터가 절대 저장되지 않는다”, “직원 누구도 접근할 수 없다”, “개인정보 규제를 자동 충족한다”처럼 범위가 무제한인 문장은 피해야 합니다. 공식 문서가 말하는 적격 고객, 지원 엔드포인트, 제한 조건, 프리뷰 상태를 함께 써야 합니다. 또한 ZDR은 법률 자문이나 개인정보 영향평가를 대신하지 않습니다.

POEMORA의 결론은 ZDR을 찬반으로 판단하지 말자는 것입니다. 이번 발표는 강한 모델의 안전 모니터링과 고객 데이터 통제를 함께 설계하려는 중요한 방향입니다. 그러나 한국 기업이 신뢰를 얻는 지점은 공급자의 기능명보다 엔드포인트별 증거, 내부 시스템의 최소 수집, 정기적인 삭제·복구 시험에 있습니다.