ZDR 이후: ‘보지 않는 안전 점검’은 가능한가 — OpenAI Private Safety Processing 프리뷰

원문 링크: WordPress 원문

AI NOTES · KO KOREAN EDITION

KO · 한국어 / EN · English BILINGUAL PAIR

민감한 문서나 고객 상담 기록을 AI API에 보내려는 팀은 서로 충돌해 보이는 두 요구를 만납니다. 요청과 응답을 오래 남기지 않아야 하지만, 동시에 악용과 심각한 안전 문제를 발견할 통제도 필요합니다. 데이터 최소 보존만 강조하면 위험 신호를 놓칠 수 있고, 안전 점검을 이유로 모든 내용을 쌓으면 처음 세운 개인정보 원칙이 무너집니다.

OpenAI는 2026년 8월 19일 공식 RSS에서 적격 API 고객을 위한 Zero Data Retention, 즉 ZDR을 재확인하면서 Private Safety Processing이라는 프리뷰를 함께 알렸습니다. OpenAI는 ChatGPT와 API를 제공하는 AI 플랫폼 사업자이며, 이번 글에서 중요한 역할은 모델 성능 경쟁자가 아니라 데이터 보존 규칙과 안전 통제의 공급자입니다. 발표가 흥미로운 이유는 “저장하지 않는다”와 “안전을 점검한다”를 같은 문장에 놓았기 때문입니다.

다만 지금 확인된 공개 근거는 방향과 현재 데이터 통제 문서입니다. Private Safety Processing의 구체적 처리 구조, 정확도, 적용 범위, 비용, 정식 출시 일정은 공개된 RSS 설명만으로 검증할 수 없습니다. 따라서 이 글은 새 프리뷰의 성능을 평가하지 않습니다. 대신 ZDR이라는 짧은 이름 뒤에서 실제로 나눠 봐야 하는 데이터 종류와 운영 질문을 정리합니다.

ZDR은 모든 데이터를 지우는 하나의 스위치가 아닙니다

OpenAI의 Your data 공식 가이드 는 API에서 저장될 수 있는 정보를 크게 두 층으로 나눕니다. 하나는 정책 집행과 유해 사용 완화를 위한 abuse monitoring logs이고, 다른 하나는 일부 API 기능이 작업을 수행하기 위해 유지하는 application state입니다. 이 구분을 놓치면 “ZDR이 켜졌다”는 설정 하나를 전체 시스템의 무보존 보증처럼 읽기 쉽습니다.

기본 abuse monitoring logs에는 프롬프트와 응답 같은 고객 콘텐츠가 들어갈 수 있고, 분류기 출력처럼 고객 콘텐츠에서 파생된 메타데이터도 포함될 수 있습니다. 현재 가이드는 기본 보존 기간을 최대 30일로 설명하면서 법적 요구나 서비스와 제삼자 보호에 필요한 경우를 예외로 둡니다. 이 30일은 모든 데이터가 정확히 같은 방식으로 30일 동안 저장된다는 뜻이 아니라, 기본 모니터링 로그에 관한 공급자 문서의 상한 설명입니다.

ZDR은 적격 고객이 사전 승인을 받고 추가 요구사항을 수락한 뒤 조직이나 프로젝트에 적용하는 통제입니다. 누구나 API 키 하나로 즉시 켤 수 있는 일반 기능이 아닙니다. “OpenAI API는 모두 ZDR이다”라는 문장은 현재 문서와 맞지 않습니다. 더 정확한 질문은 어떤 조직과 프로젝트가 승인됐는지, 어떤 기능이 ZDR 대상인지, 그리고 ZDR이 바꾸지 않는 상태가 무엇인지입니다.

ZDR은 모든 데이터를 한꺼번에 지우는 스위치가 아니라, 남을 수 있는 로그와 기능 상태를 구분해 확인하는 통제다.

모니터링 로그와 기능 상태를 분리해야 합니다

현재 가이드에 따르면 ZDR은 고객 콘텐츠를 abuse monitoring logs에서 제외합니다. 또한 Responses API와 Chat Completions의 store 값은 요청에서 true 를 보내더라도 false 로 취급됩니다. 이 동작은 중요한 통제지만, 모든 엔드포인트와 기능의 application state까지 자동으로 사라진다는 뜻은 아닙니다.

일부 기능은 작업 자체를 완료하기 위해 상태를 유지합니다. 배치 작업, 비동기 처리, 파일이나 이미지 입력, 도구 사용처럼 요청 하나가 즉시 끝나지 않는 기능은 저장 위치와 기간이 단순한 텍스트 응답과 다를 수 있습니다. OpenAI 문서도 ZDR 적격 표에서 No 로 표시된 엔드포인트와 기능은 ZDR이 켜져 있어도 application state를 저장할 수 있다고 밝힙니다.

따라서 운영팀은 “ZDR 사용 여부”를 한 칸으로 기록하기보다 요청 경로를 기능별로 나눠야 합니다. 텍스트 응답, 파일 입력, 이미지 입력, 배경 실행, 웹 검색, 배치 처리처럼 실제 사용하는 경로마다 abuse monitoring과 application state를 따로 확인해야 합니다. 같은 조직 안에서도 프로젝트 설정과 기능 선택에 따라 결과가 달라질 수 있습니다.

‘제로’에는 문서화된 예외와 조건이 있습니다

OpenAI 문서는 ZDR과 Modified Abuse Monitoring을 승인받은 고객에게도 안전과 법률상 책임이 남는다고 적습니다. 고객은 최종 사용자가 OpenAI 정책을 지키도록 관리하고, 적용되는 법률에 따른 moderation과 reporting 요구를 이행해야 합니다. 공급자의 로그 보존이 줄었다고 고객의 제품 통제 책임이 없어지는 것은 아닙니다.

현재 가이드에는 모델 적격성이 바뀌는 경우도 나옵니다. OpenAI는 특정 고객에게 사전 서면 통지한 뒤 일부 모델을 ZDR 또는 Modified Abuse Monitoring 비대상으로 만들 수 있다고 설명합니다. Eyes Off와 Safety Retention 항목은 보존과 사람 검토의 조건이 서로 다를 수 있음을 보여 줍니다. 특히 심각한 위험 활동을 조사하거나 예방할 필요가 있을 때는 문서에 적힌 범위에서 고객 콘텐츠가 보존되고 사람 검토 대상이 될 수 있습니다.

이미지와 파일에도 별도 경계가 있습니다. OpenAI는 제출된 이미지와 파일을 잠재적 아동 성착취물 탐지 대상으로 스캔하며, 분류기가 가능성을 감지하면 ZDR이 켜져 있어도 수동 검토를 위해 이미지를 보존할 수 있다고 적습니다. 이 예외는 ZDR이 무의미하다는 뜻이 아닙니다. 오히려 “무엇도 절대 남지 않는다”는 넓은 표현 대신 어떤 상황에서 어떤 자료가 남을 수 있는지 계약과 문서에서 확인해야 한다는 뜻입니다.

Private Safety Processing은 아직 답이 아니라 질문입니다

OpenAI의 공식 뉴스 RSS 는 Private Safety Processing을 데이터 프라이버시를 훼손하지 않으면서 고도화된 AI 안전을 다루기 위한 프리뷰로 소개합니다. 지금 공개적으로 확인 가능한 RSS 설명은 여기까지입니다. 특정 암호화 방식, 안전 신호의 종류, 사람 접근 통제 구조, 탐지 정확도, 오탐 처리 절차를 설명하지 않습니다.

그러므로 “OpenAI가 내용을 보지 않고 모든 위험을 탐지한다”거나 “프라이버시 문제가 해결됐다”고 쓰면 근거를 넘어섭니다. 프리뷰는 제품 방향을 보여 주지만 운영 보증은 아닙니다. 실제 도입 판단에는 기술 문서, 적용 가능한 모델과 엔드포인트, 데이터 흐름, 키와 접근 권한, 사고 대응 절차, 검증 결과가 필요합니다.

이 구분은 새 기술을 과소평가하려는 태도가 아닙니다. 발표 단계의 약속과 실제로 검증 가능한 통제를 나누면, 새 기능이 정식 문서로 공개될 때 무엇을 비교해야 하는지가 선명해집니다. 지금은 “가능하다”는 결론보다 어떤 증거가 나와야 가능하다고 판단할 수 있는지 정하는 편이 정확합니다.

안전 점검은 보존 정책을 대신하지 않습니다

OpenAI의 Safety best practices 는 moderation, 적대적 테스트, 고위험 업무의 사람 검토, 입력과 출력 범위 제한, 사용자 신고 경로, 한계 고지를 권합니다. 이 항목들은 Private Safety Processing이 자동으로 제공한다고 문서화된 기능이 아닙니다. 고객 애플리케이션이 별도로 설계해야 하는 기본 안전 통제입니다.

예를 들어 민감한 상담 요약 서비스를 운영한다면 모델 호출 전에 입력 범위를 줄이고, 결과를 실제 업무에 쓰기 전에 권한을 가진 사람이 원문과 대조하며, 문제가 생겼을 때 신고할 경로를 마련해야 합니다. ZDR이 승인됐더라도 잘못된 사람에게 결과가 노출되거나, 애플리케이션 로그가 원문을 따로 저장하거나, 분석 도구가 프롬프트를 수집한다면 전체 시스템의 최소 보존 목표는 달성되지 않습니다.

반대로 안전팀이 모든 요청을 자체 로그에 무기한 남기는 것도 자동으로 좋은 답이 아닙니다. 위험을 발견하는 데 필요한 신호와 사건 증거를 정의하고, 원문이 필요한 경우와 파생된 최소 신호로 충분한 경우를 나눠야 합니다. 저장 기간, 접근 권한, 삭제 절차, 감사 기록을 함께 설계해야 안전과 프라이버시가 같은 운영 계약 안에 들어옵니다.

운영팀은 요청 경로마다 보존 설정, 기능 상태, 문서화된 예외, 사람 검토 책임을 차례로 확인한다.

공급자 설정보다 전체 요청 경로가 더 중요합니다

한 번의 AI 요청은 모델 제공자만 거치지 않을 수 있습니다. 사용자의 브라우저, 애플리케이션 서버, 로드 밸런서, 관측 도구, 오류 추적 서비스, 데이터베이스, 백업, 지원 티켓, 분석 플랫폼이 같은 내용을 복사할 수 있습니다. OpenAI 측의 ZDR 설정은 이 가운데 OpenAI API 경로의 특정 보존 동작을 바꾸는 통제입니다.

운영팀은 요청이 생성되는 순간부터 결과가 폐기되거나 승인된 저장소에 남을 때까지 데이터 흐름을 그려야 합니다. 각 지점에서 원문, 해시, 분류기 출력, 오류 메시지, 사용자 식별자 중 무엇이 생성되는지 확인합니다. 필요한 데이터와 편의를 위해 남은 데이터를 구분하면, 공급자 설정은 강한 구성요소가 되지만 전체 프라이버시 보증으로 과장되지는 않습니다.

특히 디버깅 설정이 문제를 만들기 쉽습니다. 모델 제공자는 고객 콘텐츠를 모니터링 로그에서 제외해도, 개발팀이 실패한 요청 전체를 애플리케이션 로그에 기록할 수 있습니다. 운영 대시보드가 요청 본문을 수집하거나 지원 담당자가 화면 캡처를 티켓에 붙일 수도 있습니다. ZDR 도입 검토는 공급자 계약 확인과 동시에 내부 로깅 점검을 진행해야 완성됩니다.

기능별 표를 읽지 않으면 예상 밖의 저장이 생깁니다

OpenAI 데이터 가이드는 엔드포인트와 기능별로 ZDR 적격 여부와 application state 보존을 다르게 설명합니다. 제품 기획 단계에서 “API를 쓴다”는 한 문장만 남기면, 개발 과정에서 선택한 배경 모드나 파일 기능이 처음 세운 보존 가정과 어긋날 수 있습니다.

요청 경로를 확정할 때는 사용 모델과 엔드포인트, store 동작, 배경 실행 여부, 파일·이미지 입력, 웹 접근, 배치 처리, 캐시, 지역 설정을 한 묶음으로 검토해야 합니다. 공급자 문서가 바뀌면 이 묶음도 다시 읽어야 합니다. 모델 이름만 고정해 두고 데이터 동작은 예전 문서에 의존하면 시간이 지나면서 보존 정책과 구현이 갈라집니다.

민감한 업무라면 기능 추가를 독립된 변경으로 취급하는 편이 안전합니다. 예를 들어 텍스트 전용 요청에 파일 업로드를 붙이거나, 즉시 응답에 배경 모드를 추가하는 순간 데이터 흐름 검토를 다시 엽니다. “같은 API 공급자”라는 이유만으로 기존 ZDR 판단을 자동 승계하지 않습니다.

도입 전 검증은 설정 화면 캡처로 끝나지 않습니다

첫 단계는 승인과 범위를 확인하는 일입니다. 조직과 프로젝트가 실제로 어떤 retention control을 적용받는지, 사용하려는 모델과 기능이 대상인지, 변경 통지가 누구에게 전달되는지 확인합니다. 설정 화면은 출발점이지 전체 증거가 아닙니다.

다음 단계는 테스트용 비민감 데이터로 실제 요청 경로를 점검하는 일입니다. 애플리케이션 로그, 오류 추적, 백업, 지원 도구, 분석 플랫폼에 요청 본문이 남는지 확인합니다. ZDR이 모델 제공자 측의 보존을 줄여도 내부 복제본이 생긴다면 운영 결과는 달라집니다. 삭제 요청과 보존 만료가 실제 시스템에서 동작하는지도 확인해야 합니다.

마지막 단계는 예외가 발생했을 때의 책임을 문서화하는 일입니다. 특정 기능이 ZDR 비대상이 되거나 심각한 위험 조사로 Safety Retention이 적용될 때 누가 서비스를 중단하고, 누가 사용자와 내부 담당자에게 알리며, 어떤 대체 경로로 전환하는지 정합니다. 안전 관련 보존과 일반 분석용 보존을 같은 권한으로 다루지 않는 것도 중요합니다.

판단 기준은 ‘저장하나’보다 ‘무엇을 증명할 수 있나’입니다

ZDR은 민감한 API 사용에서 중요한 통제입니다. 기본 abuse monitoring logs에서 고객 콘텐츠를 제외하고 일부 저장 동작을 제한하는 기능은 실제 운영 가치를 가질 수 있습니다. 그러나 이름만으로 전체 시스템의 데이터 수명 주기를 설명할 수는 없습니다.

Private Safety Processing도 같은 기준으로 봐야 합니다. OpenAI가 프라이버시와 안전 점검을 함께 다루는 방향을 공개했다는 사실은 확인됩니다. 아직 공개된 근거만으로 구체적 처리 메커니즘이나 효과를 판정할 수는 없습니다. 기술 문서와 독립적인 검증이 나오기 전까지는 프리뷰라는 상태를 그대로 유지해야 합니다.

지금 팀이 내릴 수 있는 결정은 명확합니다. 기능별 데이터 흐름을 작성하고, ZDR 승인 범위와 예외를 확인하며, 내부 로그와 사람 검토 절차를 함께 점검할 수 있습니다. 새 프리뷰를 기다리는 동안에도 이 작업은 가능합니다. 오히려 기본 통제가 정리돼 있어야 새 기능이 공개됐을 때 기존 책임을 덮는 홍보 문구가 아니라 실제 개선인지 판단할 수 있습니다.

도입 판단은 ZDR 라벨보다 기능별 증거, 예외 처리, 검증 가능한 운영 계약을 기준으로 내린다.

아직 모르는 것을 남겨 두는 것이 안전한 결론입니다

Private Safety Processing이 어떤 신호를 처리하고, 어떤 정보에 사람이 접근할 수 없으며, 오탐과 이의 제기를 어떻게 다루는지는 현재 사용한 공개 근거만으로 답할 수 없습니다. 적용 가능한 고객과 모델, 정식 출시 시점, 비용, 지역별 동작도 이 글의 근거 범위 밖입니다.

따라서 답은 조건부입니다. 내용을 오래 남기지 않으면서 안전 신호를 다루는 방향은 필요하고, OpenAI는 그 방향의 프리뷰를 발표했습니다. 그러나 “보지 않는 안전 점검이 가능하다”는 운영 결론은 기능별 문서, 예외, 실제 데이터 흐름, 검증 결과가 함께 나올 때만 내릴 수 있습니다.

민감한 AI 도입에서 가장 유용한 질문은 “ZDR인가 아닌가”로 끝나지 않습니다. 어느 경로에서 무엇이 남고, 누가 접근하며, 어떤 예외가 작동하고, 그 사실을 어떻게 다시 확인할 수 있는지를 묻는 것이 더 정확합니다.

Sources

• OpenAI News RSS — Offering Zero Data Retention for frontier models

• OpenAI API — Your data

• OpenAI API — Safety best practices

Disclaimer

이 글은 2026년 8월 29일 확인한 OpenAI 공식 자료를 바탕으로 한 기술·운영 해설입니다. 법률, 개인정보보호, 보안 인증 또는 구매 자문이 아닙니다. 공급자 기능과 정책은 바뀔 수 있으므로 실제 도입 전 최신 계약, 데이터 처리 조건, 조직의 법률·보안 요구사항을 별도로 확인해야 합니다.