[OpenAI][Responses API] store=true와 자체 로그를 언제 나눠야 하나

IT 리서치 노트

[OpenAI][Responses API] store=true와 자체 로그를 언제 나눠야 하나

Responses API를 운영하다 보면 store=true를 켜는 순간과 자체 시스템에 메타 로그를 남기는 순간이 자꾸 한 덩어리처럼 섞인다. 하지만 2026년 6월 30일 기준 OpenAI 공식 문서를 다시 보면, platform persisted state, ZDR 강제 동작, background mode 임시 저장, MCP 호출 로그 권고는 서로 다른 층위다. 이 글은 store 플래그와 자체 운영 로그를 언제 같은 문제로 보고 언제 분리해야 하는지 실무 기준으로 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 store=true는 플랫폼에 응답 상태를 남겨 multi-turn continuation을 쉽게 만드는 설정이고, 자체 로그는 우리 팀이 감사, 문의 대응, MCP 호출 추적, 운영 검토를 위해 남기는 별도 체계다. 둘은 겹칠 수는 있어도 대체 관계가 아니다. 플랫폼이 30일 보존해 주는 persisted state가 있어도, 자체 시스템에 어떤 메타 정보와 검토 로그를 남길지는 별도로 설계해야 한다.

반대로 ZDR 조직이라면 store 파라미터가 true여도 false처럼 처리될 수 있으므로, 앱 코드에 남은 플래그만 보고 continuation이 된다고 믿으면 안 된다. 이럴 때는 continuation 경로와 감사 경로를 나눠 생각해야 한다. 장기 세션 판단은 previous_response_id와 stateless replay 글, compaction 기준 글과 같이 읽는 편이 맞다.

특히 ZDR 요구가 있는 라우트라면 오늘 발행한 background mode 10분 보관과 자체 감사 로그를 어디까지 나눠야 하는지 정리한 글을 같이 보는 편이 좋다. store 판단과 background polling 판단은 비슷해 보여도 보관 경계가 다르기 때문이다.

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

실무에서 가장 자주 생기는 혼동은 세 가지다. 첫째, store=true를 켰으니 조사나 문의 대응에 필요한 운영 로그도 자동으로 충분할 것이라고 생각한다. 둘째, 보안팀이 ZDR를 요구하는데 앱팀은 previous_response_id 기반 continuation을 그대로 유지할 수 있다고 본다. 셋째, MCP나 deep research 경로에서 외부 데이터와 툴 호출이 늘어났는데도, 플랫폼 persisted state만 있으면 출처 추적이 된다고 가정한다.

OpenAI data controls 문서를 보면 Responses API application state는 기본적으로 30일 남고, ZDR 조직에서는 store 파라미터가 false처럼 강제될 수 있다. 이 문장만 봐도 store는 '플랫폼이 상태를 들고 있는가'에 대한 설정이지 '우리 조직이 어떤 감사 기록을 갖고 있는가'에 대한 설정이 아니라는 점이 드러난다. 여기에 WebSocket mode 문서까지 보면, store=false일 때는 uncached previous_response_id에 persisted fallback이 없어 실패할 수 있다.

문제가 더 커지는 지점은 외부 도구다. MCP and Connectors 문서는 store=true일 때도 MCP로 보낸 데이터는 자체 시스템 로그를 별도로 남기고 검토하라고 권한다. deep research 문서도 MCP 서버와 web search가 섞이면 어떤 데이터가 어디로 흘렀는지 periodic review를 두는 편이 좋다고 말한다. 즉 툴 호출 경로가 늘어날수록 자체 로그는 선택이 아니라 운영 책임에 가까워진다.

• 증상: store=true를 켰는데도 운영 조사에 필요한 근거가 부족하다.
• 실패: platform persisted state와 조직 감사 로그를 같은 것으로 본다.
• 막힘: ZDR 요구가 생겼는데 continuation 경로가 어떻게 바뀌는지 정리하지 않는다.
• 누락: MCP, deep research, background mode가 들어간 호출을 별도 검토 로그 없이 둔다.

증상	먼저 볼 곳	판단 기준
멀티턴 상태를 오래 이어야 한다	store 설정과 continuation 방식	platform persisted state가 필요한지 본다
민감 데이터나 ZDR 요구가 있다	store=false와 replay 구조	자체 로그는 최소 메타 정보 중심으로 줄인다
MCP와 deep research가 섞인다	툴 호출 경로와 periodic review	자체 감사 로그를 별도로 둔다

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

실무에서는 네 단계로 나누면 깔끔하다. 먼저 이 경로가 continuation 편의를 위해 platform persisted state를 필요로 하는지 결정한다. 두 번째로 보안팀 또는 계약상 요구 때문에 ZDR가 필요한지 확인한다. 세 번째로 MCP, deep research, background mode, 외부 파일 검색처럼 데이터 출처가 늘어나는지 본다. 마지막으로 플랫폼 보존과 별개로 어떤 메타 정보가 자체 시스템에 있어야 운영 조사가 가능한지 최소 범위를 정한다.

1. store=true가 필요한 멀티턴 경로인지 먼저 구분한다.
2. ZDR 또는 민감 데이터 요구가 있으면 store=false 강제 가능성을 같이 적는다.
3. MCP, deep research, background mode 사용 여부를 체크한다.
4. 자체 로그에는 요청 ID, 툴 종류, 검토 메모처럼 최소 메타 정보만 남길지 정한다.

중요한 점은 persisted state와 자체 감사 로그의 목표가 다르다는 것이다. persisted state는 응답을 이어 붙이는 데 유리하고, 자체 로그는 사고 후 조사와 정책 검토에 유리하다. 둘을 합치려 들면 store=false 경로에서는 조사성이 떨어지고, store=true 경로에서는 필요 이상으로 많은 데이터를 장기간 자체 보관하는 위험이 생긴다.

운영 메모 예시

route=deep_research_with_mcp
store=false
zdr_required=true
continuation_mode=stateless_replay
platform_state_persisted=false
own_log_fields=request_id, tool_type, review_status
background_mode_allowed=false

background mode는 특히 따로 본다. deep research 문서는 background mode가 polling을 위해 약 10분 정도 응답 데이터를 디스크에 둘 수 있으므로 ZDR와는 맞지 않을 수 있다고 설명한다. 그래서 background=true를 켰는지 여부는 단순 성능 옵션이 아니라 보존 정책 표에도 같이 들어가야 한다.

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

첫 화면은 OpenAI data controls 문서의 Responses API retention 구간이다. 이 문서에서 먼저 확인해야 하는 것은 store=true일 때 응답 상태가 기본적으로 얼마나 보존되는지다.

OpenAI data controls 문서는 Responses API application state가 기본적으로 30일 보존된다고 설명한다.

즉 store=true를 켠 순간 '로그를 안 남긴다'는 전제는 깨진다. 사람이 보기 위한 감사 로그를 별도로 만들지 않았더라도, 플랫폼 차원 보존과 자체 운영 로그는 서로 다른 층위라는 점을 먼저 분리해야 한다.

두 번째 자료는 같은 문서의 Zero Data Retention 구간이다. 여기서는 ZDR 조직에서 store 파라미터가 어떻게 강제되는지 확인해야 한다.

ZDR가 켜진 조직에서는 store 파라미터가 true여도 false처럼 처리된다는 점을 먼저 봐야 한다.

이 문단 덕분에 store=true를 앱 코드에 남겨 두는 것과 실제 persisted state가 살아 있는지는 별개라는 점이 드러난다. 이미 store:false와 encrypted reasoning 글을 봤다면, 오늘 글은 그 위에 retention 책임을 어디로 둘지의 문제다.

세 번째 자료는 WebSocket mode 문서의 previous_response_not_found 설명이다. 자체 로그를 나눠야 하는지 판단할 때는 persisted fallback이 아예 없는 경우를 같이 이해해야 한다.

OpenAI WebSocket mode 문서는 store=false일 때 uncached previous_response_id가 persisted fallback 없이 실패할 수 있다고 설명한다.

이 구간은 store=false가 단순히 비용 절감 옵션이 아니라 continuation 방식 자체를 바꾼다는 점을 보여 준다. 장기 세션에선 previous_response_id와 stateless replay 글이나 compaction item 기준 글과 함께 봐야 판단이 맞아진다.

네 번째 화면은 MCP and Connectors 문서다. 여기서는 플랫폼 저장과 별개로 어떤 데이터는 자체 시스템에도 다시 남기는 편이 좋은지 기준을 잡아 준다.

OpenAI MCP 문서는 store=true일 때도 MCP로 보낸 데이터는 자체 시스템 로그를 별도로 검토하라고 권한다.

이 한 줄이 중요하다. 플랫폼에 30일 남는다고 해서 우리 팀의 감사 기록, 사용자 문의 대응 로그, 보안 검토 로그가 자동으로 해결되지는 않는다. 특히 외부 MCP 호출 경로는 입력과 출력의 출처가 더 복잡해지므로 자체 운영 로그의 범위를 따로 설계해야 한다.

이 표는 store=true, store=false, 자체 운영 로그를 언제 나누는지 빠르게 판단하기 위한 비교표다. 같은 Responses 호출이어도 continuation 요구와 감사 요구가 다르면 결론이 달라진다.

Responses persisted state와 자체 운영 로그를 분리해서 판단하는 비교표다.

표로 묶어 두면 보안팀은 보존 기간을, 앱팀은 continuation 실패 시점을, 운영팀은 조사 가능 범위를 같은 문서에서 볼 수 있다. 이 구조가 없으면 store 플래그 하나에 너무 많은 의미를 실어 버리게 된다.

마지막 자료는 운영자가 실제로 남겨야 할 최소 메모다. retention 책임을 분리하려면 기술 설정만이 아니라 확인 절차도 같이 남겨야 한다.

store=true와 자체 로그 범위를 나눌 때 확인하는 체크리스트다.

이 체크리스트를 배포 메모에 붙여 두면 다음번에 ZDR, MCP, background mode가 섞여도 같은 기준으로 다시 판단할 수 있다. 특히 deep research처럼 배경 실행이 길어지는 경로에서는 background retention과 자체 감사 로그가 같은 문제가 아니라는 점이 더 중요해진다.

5. 주의사항과 리스크

첫 번째 리스크는 store=true를 보안 로그나 감사 로그의 대체물처럼 보는 것이다. 두 번째 리스크는 ZDR가 필요한데도 앱 코드에 남은 store 플래그만 믿고 continuation 전략을 바꾸지 않는 것이다. 세 번째 리스크는 MCP, deep research, background mode가 들어간 요청에 대해 periodic review 없이 운영하는 것이다.

운영 문서에는 최소한 네 가지가 남아야 한다. 실제 store 값, continuation 경로, 자체 로그 범위, 툴 호출 검토 책임자다. 이 네 가지가 없으면 나중에 '왜 이전 응답을 못 이어 받았는가', '왜 이 MCP 호출은 남았는가', '왜 이 경로는 background mode를 껐는가' 같은 질문에 답하기 어렵다.

• store는 플랫폼 상태 보존 설정이지 자체 감사 로그의 대체물이 아니다.
• ZDR 경로는 previous_response_id fallback 기대를 따로 버릴 준비가 필요하다.
• MCP와 deep research는 자체 검토 로그를 더 엄격하게 두는 편이 안전하다.

6. 결론

Responses API에서 store=true와 자체 운영 로그는 같은 버튼이 아니다. persisted state가 필요한 멀티턴 경로인지, ZDR와 민감 데이터가 있는지, MCP나 deep research처럼 출처가 늘어나는지에 따라 둘을 분리해서 설계해야 한다. 이 구분을 먼저 해 두면 continuation 실패와 감사 공백을 동시에 줄일 수 있다.

• store는 continuation 편의 기준으로 본다.
• 자체 로그는 감사와 검토 책임 기준으로 별도 설계한다.
• background mode와 MCP 호출은 별도 표로 같이 관리한다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/your-data
2. https://developers.openai.com/api/docs/guides/conversation-state
3. https://developers.openai.com/api/docs/guides/websocket-mode
4. https://developers.openai.com/api/docs/guides/tools-connectors-mcp
5. https://developers.openai.com/api/docs/guides/deep-research