[OpenAI][Responses API] ZDR 환경에서 background mode 10분 보관과 자체 감사 로그를 어디까지 나눠야 하나

IT 리서치 노트

[OpenAI][Responses API] ZDR 환경에서 background mode 10분 보관과 자체 감사 로그를 어디까지 나눠야 하나

Responses API를 운영하다 보면 긴 작업은 background mode로 넘기고 싶고, 동시에 ZDR 요구도 지키고 싶어진다. 하지만 2026년 7월 4일 기준 OpenAI 공식 문서를 다시 보면 background mode는 polling을 위해 약 10분 동안 response data를 저장하므로 ZDR과 호환되지 않는다. 이 글은 ZDR 환경에서 background mode 10분 보관과 자체 감사 로그를 어디까지 나눠야 하는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 ZDR이 필요한 경로에서는 background mode를 상태 보관 수단으로 쓰면 안 된다. OpenAI 문서는 ZDR 조직에서 store가 사실상 false처럼 처리되고, background mode는 polling을 위해 약 10분 상태를 남기므로 ZDR 보장을 깨뜨린다고 분명히 적고 있다. 따라서 ZDR-safe 경로는 store: false와 encrypted reasoning 쪽으로 보내고, 사내 감사 로그는 trace id, 모델명, summary 같은 최소 정보만 별도 저장하는 쪽이 맞다.

이미 Responses background mode와 webhook 글이 비동기 완료 확인 순서를 다뤘다면, 이번 글은 그 비동기 경로가 ZDR 요구와 충돌할 때 어디서 다시 갈라야 하는지에 가깝다. 또 store=true와 자체 로그를 나눈 글은 상태 보관 책임을 넓게 다뤘고, 오늘은 그중에서도 ZDR 예외 조건을 더 좁게 본다.

ZDR 분기까지 정리했다면, 그 다음 단계로는 reasoning summary를 장기 감사 로그에 남길 때 encrypted_content와 raw trace를 어디서 끊는지 다룬 후속 글을 같이 보는 편이 좋다. 지금 글이 background polling과 ZDR-safe continuation의 경계를 다뤘다면, 후속 글은 장기 감사 스키마의 경계를 더 좁힌다.

2. 어디서 실제로 막히는가

실무에서 가장 먼저 꼬이는 지점은 세 가지다. 첫째, background 요청이 성공적으로 접수됐다는 사실만 보고 ZDR도 지켜졌다고 착각한다. 둘째, store: true 플래그가 코드에 남아 있으니 continuation state도 살아 있다고 가정한다. 셋째, 사내 감사 로그에 원문 입력과 출력 전체를 붙여 두고 그것을 '필수 증빙'으로 포장한다.

OpenAI 데이터 제어 문서는 ZDR 조직에서 store가 항상 false처럼 처리된다고 설명하고, background 가이드는 polling을 위해 약 10분 response data를 저장하므로 ZDR과 호환되지 않는다고 적는다. 마이그레이션 문서는 ZDR 요구가 있는 경우 encrypted reasoning items로 stateless continuation을 설계하라고 별도 경로를 제시한다. 이 셋을 같이 읽으면, background polling과 ZDR-safe continuation은 같은 문제를 푸는 경로가 아니라는 점이 보인다.

또 감사 로그를 설계할 때도 OpenAI application state와 사내 저장소를 같은 층위로 두면 안 된다. product state는 모델 연속성을 위한 것이고, 사내 감사 로그는 운영 추적과 설명을 위한 것이다. 요청 본문 전체, 민감 출력 전체, 도구 호출 결과 전체를 모두 남기면 보안 경계가 불필요하게 넓어진다.

• 증상: background 작업은 잘 끝났는데 ZDR 검토에서 막힌다.
• 실패: 요청 성공 여부와 ZDR 충족 여부를 같은 체크로 본다.
• 막힘: store 플래그와 실제 상태 보관 경로를 구분하지 않는다.
• 누락: 감사 로그를 최소 범위가 아니라 원문 전체 저장으로 설계한다.

상황	먼저 볼 곳	판단 기준
긴 작업을 polling으로 본다	background mode 사용 여부	ZDR 요구가 있으면 같은 경로를 쓰지 않는다
stateful continuation이 필요하다	store와 encrypted reasoning	ZDR-safe면 stateless continuation으로 분기한다
감사 로그를 남겨야 한다	로그 필드 설계	trace id, 요약, 모델명처럼 최소 증빙만 남긴다

3. 실무에서 적용하는 순서

운영 순서는 다섯 단계로 잡는 편이 가장 짧다. 먼저 프로젝트나 라우트가 ZDR 요구인지 확인한다. 두 번째로 ZDR-required 라우트에서는 background=true를 금지한다. 세 번째로 연속 reasoning이 필요하면 store: false와 reasoning.encrypted_content 경로를 만든다. 네 번째로 사내 감사 로그에는 trace id, summary, usage, retention class만 남긴다. 마지막으로 background가 허용되는 비-ZDR 경로는 polling 또는 webhook 처리 로그를 감사 로그와 분리해서 저장한다.

1. ZDR-required 라우트인지 먼저 분류한다.
2. ZDR-required 라우트에서는 background=true를 차단한다.
3. 필요한 연속성은 encrypted reasoning 기반 stateless 경로로 옮긴다.
4. 감사 로그는 summary와 usage 중심의 최소 증빙으로 줄인다.
5. background polling 로그와 application audit 로그를 서로 다른 저장 규칙으로 둔다.

핵심은 '모델이 다음 요청을 이어 가기 위한 상태'와 '운영팀이 나중에 설명하기 위한 증빙'을 같은 저장소에 두지 않는 것이다. 전자는 OpenAI product behavior와 직결되고, 후자는 내부 규정과 보안 설계의 문제다. 이 경계를 먼저 자르면 background를 허용할 라우트와 금지할 라우트가 명확해진다.

감사 로그 예시

trace_id=resp_123
route_class=zdr_safe
background=false
store=false
reasoning_summary=Compared two retry branches before choosing stateless replay
usage.output_tokens=812
retention_class=minimal_audit_only

이 정도만 남겨도 작업 경로와 보관 책임을 설명하는 데는 충분한 경우가 많다. 반대로 원문 전체를 감사 목적으로 복사하면 ZDR-safe 애플리케이션 경로를 내부 로그가 다시 넓혀 버릴 수 있다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 OpenAI의 데이터 제어 문서다. 여기서는 Responses API의 기본 application state 보관과 ZDR 조직에서 store가 어떻게 강제되는지를 한 화면에서 같이 확인할 수 있다.

OpenAI 데이터 제어 문서는 ZDR에서 <code>store</code>가 <code>false</code>처럼 처리되고 background mode는 약 10분 보관을 쓴다고 설명한다.

즉 ZDR 조직에서 앱 코드에 store: true를 남겨 두는 것만으로 상태 보관이 살아난다고 보면 안 된다. 특히 background polling을 붙인 작업은 자체 감사 로그 설계와 분리해서 봐야 한다.

두 번째 자료는 background mode 가이드의 ZDR 경고 구간이다. OpenAI는 background mode가 polling을 위해 약 10분 저장을 쓰므로 ZDR과 호환되지 않는다고 직접 적고 있다.

background mode 가이드는 ZDR 프로젝트에서도 <code>background=true</code>가 접수되지만 ZDR 보장은 깨진다고 경고한다.

이 문장이 중요한 이유는, 단순히 요청이 성공했다는 사실과 ZDR 요구사항을 만족했다는 사실이 다르기 때문이다. 운영팀은 성공 응답만 기록할 게 아니라 어떤 상태 보관 경로를 탔는지도 로그에 남겨야 한다.

세 번째 자료는 Responses 마이그레이션 문서의 encrypted reasoning items 구간이다. ZDR 요구 때문에 stateful continuation을 못 쓰는 조직을 위해 store: false와 reasoning.encrypted_content 조합이 별도 경로로 안내된다.

OpenAI 문서는 ZDR 요구가 있으면 <code>store: false</code>와 <code>reasoning.encrypted_content</code>로 stateless continuation을 설계하라고 안내한다.

즉 background mode를 못 쓰는 환경에서도 reasoning 연속성 자체를 포기하라는 뜻은 아니다. 상태 보관은 끄고, 필요한 reasoning item만 암호화된 형태로 넘겨받는 설계가 대안이 된다.

실무에서는 ZDR-safe 요청과 background 요청을 코드 레벨에서 분기해 두는 편이 낫다. 그래야 어떤 요청이 10분 polling 보관을 쓰고, 어떤 요청이 stateless continuation을 타는지 재현이 쉽다.

ZDR-safe stateless 요청과 background 요청을 분리해 두는 예시다.

이 분기를 남겨 두면 감사 때도 background=true가 남아 있던 이유를 설명하기 쉽다. 이미 store:false와 encrypted reasoning 글을 읽었다면, 이번 글은 그 위에 background 보관과 감사 로그 책임을 얹는 단계다.

어떤 경로에서 무엇을 남길지 표로 고정해 두면 판단이 빨라진다. 특히 product state, 자체 감사 로그, 사용자 요청 재현 로그를 한 덩어리로 두면 나중에 경계가 무너진다.

ZDR-safe stateless 경로, background polling 경로, 자체 감사 로그를 나눠 읽는 비교표다.

이 표를 쓰면 background=true를 장기 감사 저장처럼 오해하는 실수를 줄일 수 있다. 또 store=true와 자체 로그를 나눈 글과 연결하면 OpenAI 상태 보관과 사내 로그 보관의 경계가 더 선명해진다.

마지막 자료는 운영 체크리스트다. background polling, webhook, 사내 감사 로그, ZDR-safe continuation을 한 흐름으로 적어 두면 어느 팀이 어떤 저장 책임을 지는지 빨리 보인다.

ZDR 환경에서 Responses background와 자체 감사 로그를 분리해 점검하는 체크리스트다.

이 메모가 있으면 '요청은 성공했는데 왜 규정 위반이냐'는 식의 혼선을 줄일 수 있다. 기존의 background mode와 webhook 글이 비동기 처리 순서를 다뤘다면, 이번 글은 그 처리 방식을 ZDR 기준으로 다시 나눠 본다.

5. 주의사항과 리스크

첫 번째 리스크는 background 요청이 허용되었다는 사실을 정책 준수로 오해하는 것이다. 두 번째 리스크는 사내 감사 로그에 민감 원문을 과하게 저장해 내부 보안 범위를 넓히는 것이다. 세 번째 리스크는 encrypted reasoning 대안을 설계하지 않은 채 긴 작업은 전부 background로만 보내는 것이다.

운영 전에 확인할 때는 최소한 route class, background 사용 여부, store 설정, summary 저장 범위, usage 저장 범위를 표로 남기는 편이 좋다. 이 다섯 항목만 있어도 다음 보안 검토 때 설명이 훨씬 짧아진다.

• background 성공과 ZDR 충족은 별개다.
• 감사 로그는 최소 범위 증빙만 남긴다.
• 긴 작업이 필요해도 ZDR-safe 라우트는 stateless continuation으로 분기한다.

6. 결론

Responses API에서 ZDR을 지켜야 한다면 background mode 10분 보관을 continuation 수단으로 보면 안 된다. ZDR-safe 경로는 store: false와 encrypted reasoning으로 분기하고, 사내 감사 로그는 trace id와 summary 중심의 최소 정보만 따로 남겨야 경계가 무너지지 않는다.

만약 여기서 한 단계 더 내려가 reasoning item을 trace에 얼마나 오래 남길지 헷갈린다면, 새로 정리한 reasoning item trace 저장 범위 글처럼 replay 창구와 operator trace와 장기 감사 로그를 따로 나누어 보는 편이 더 안전하다.

• ZDR-required 라우트에서는 background를 끈다.
• continuation은 encrypted reasoning 쪽으로 설계한다.
• 감사 로그는 application state와 분리한다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/your-data
2. https://developers.openai.com/api/docs/guides/background
3. https://developers.openai.com/api/docs/guides/migrate-to-responses
4. https://developers.openai.com/api/docs/guides/deep-research