[OpenAI][Conversations API] response는 30일인데 conversation item은 왜 TTL이 끝나지 않나

IT 리서치 노트

[OpenAI][Conversations API] response는 30일인데 conversation item은 왜 TTL이 끝나지 않나

Responses API를 다룰 때 '30일 저장' 문장만 보고 보존 규칙을 이해했다고 생각하면 Conversations API에서 크게 헷갈린다. 2026년 6월 30일 기준 OpenAI 공식 문서를 다시 보면 response object는 기본적으로 30일 저장되지만, conversation object와 item은 그 TTL 대상이 아니다. 이 글은 durable conversation을 붙였을 때 왜 보존 해석이 달라지는지, 그리고 store, ZDR, background mode와 어떻게 분리해서 봐야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 Responses response object의 30일 TTL과 Conversations item 보존은 같은 규칙이 아니다. response는 기본적으로 30일 저장되지만, conversation object와 그 안의 item은 그 TTL 대상이 아니므로 더 오래 남을 수 있다. 그래서 durable conversation을 쓰는 순간 store 플래그만 보는 설계에서 벗어나, 어떤 state surface를 쓰는지까지 같이 기록해야 한다.

이미 store=true와 자체 로그 글이 플랫폼 보존과 팀 로그를 나누는 기준을 다뤘다면, 이번 글은 그 위에 conversation durable state를 붙였을 때의 차이다. 또 previous_response_id와 stateless replay 글을 봤다면, 오늘은 '굳이 durable conversation까지 가야 하는가'를 판단하는 단계다.

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

실무에서 가장 흔한 오해는 'store=false면 다 지워진다' 또는 'response가 30일이면 conversation도 그쯤 끝난다'는 식의 단순화다. 하지만 OpenAI conversation state 문서는 response object와 conversation item의 보존 규칙을 분리해서 설명한다. response는 기본 30일 저장되지만, conversation object와 item은 그 TTL 대상이 아니라고 명시돼 있다.

이 차이를 놓치면 retention review에서 세 가지 문제가 생긴다. 첫째, 앱팀은 편하게 stateful conversation을 켰는데 보안팀은 30일 보존만 있다고 이해한다. 둘째, background mode가 polling을 위해 약 10분 저장한다는 문장을 별개로 보지 않아 ZDR와 충돌한다. 셋째, WebSocket mode처럼 메모리 캐시만 쓰는 경로와 durable conversation을 같은 continuation으로 취급해 설계를 섞는다.

결국 핵심은 '상태가 남는 위치'를 구분하지 않은 데 있다. Responses response, Conversations item, background polling state, WebSocket previous-response cache는 전부 다른 층위다. 특히 conversation item은 세션과 기기와 작업을 넘기는 durable object를 만들기 때문에, 단순한 previous_response_id 체인과는 운영 의미가 다르다.

• 증상: 30일 보존만 있다고 이해했는데 durable conversation이 계속 남는다.
• 실패: store 플래그만 보고 conversation item 보존을 따로 기록하지 않는다.
• 막힘: background mode와 ZDR 충돌을 response 30일 규칙과 섞어 본다.
• 누락: WebSocket 메모리 캐시와 durable conversation을 같은 continuation으로 처리한다.

상황	먼저 볼 곳	판단 기준
response retrieve와 logs만 필요하다	response object 30일 규칙	durable conversation이 없어도 되는지 본다
세션을 기기나 작업 사이에서 이어야 한다	conversation object와 item	TTL 비대상 보존을 감수할 이유가 있는지 본다
민감 데이터와 ZDR가 중요하다	store, background, websocket cache	durable conversation을 피할지 검토한다

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

실무에서는 다섯 단계로 나누면 정리가 쉽다. 먼저 이 경로가 기기와 세션을 넘는 durable state가 필요한지 본다. 두 번째로 민감 데이터와 ZDR 요구가 있는지 적는다. 세 번째로 background mode가 필요한지 확인한다. 네 번째로 WebSocket 메모리 캐시 또는 previous_response_id replay만으로 충분한지 검토한다. 마지막으로 durable conversation을 쓰는 경우 보존 책임과 삭제 책임을 운영 문서에 남긴다.

1. 기기와 작업을 넘는 durable state가 필요한지 먼저 적는다.
2. 민감 데이터와 ZDR 요구 여부를 별도 표로 남긴다.
3. background mode가 필요한지 본다.
4. conversation 대신 previous_response_id나 stateless replay로 충분한지 비교한다.
5. durable conversation이면 item 보존 책임과 자체 감사 로그 범위를 적는다.

이 순서를 따르면 '편해서 conversation을 쓴다'와 '정말 durable object가 필요하다'를 나눌 수 있다. 예를 들어 로그인된 사용자가 여러 기기에서 같은 작업을 이어야 한다면 conversation durable id가 맞을 수 있다. 반대로 짧은 세션, 민감 데이터, ZDR 요구가 강한 경로라면 WebSocket 캐시나 stateless replay가 더 안전하다.

선택 메모 예시

route=agent_followup
needs_cross_device_resume=true
use_conversation_object=true
contains_sensitive_data=false
background_mode=false
fallback=previous_response_id
review_owner=platform_ops

또 durable conversation을 쓴다고 해서 자체 운영 로그를 생략하면 안 된다. conversation item 보존과 팀 감사 로그는 다른 문제다. 이 점은 store=true 경로를 정리한 기존 글과 마찬가지다. 다만 durable conversation이 들어오면 그 로그 설계에 '어떤 conversation id가 어떤 경로에서 만들어졌는가'까지 추가로 남겨야 한다.

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

첫 화면은 conversation state 문서의 응답 보존 규칙이다. 여기서 먼저 확인해야 하는 것은 일반 Responses response object가 기본적으로 얼마나 남는지다.

OpenAI conversation state 문서는 response object가 기본적으로 30일 저장된다고 설명한다.

이 문장만 보면 많은 팀이 Responses 상태는 전부 30일 뒤 사라진다고 이해한다. 하지만 바로 아래에 붙는 conversation item 규칙을 같이 읽지 않으면 retention 판단이 완전히 달라질 수 있다.

두 번째 자료는 Conversations API가 실제로 무엇을 보관하는지 보여 주는 구간이다. durable object가 단순 텍스트 기록이 아니라 messages, tool calls, tool outputs까지 item으로 쌓는다는 점을 먼저 봐야 한다.

Conversations API는 messages, tool calls, tool outputs 같은 item을 durable object 안에 저장한다.

이 item들이 같은 문서에서 30일 TTL 비대상으로 설명되기 때문에, conversation durable id를 붙이는 순간 store=true와 store=false를 나누는 문제 위에 또 하나의 보존 층위가 생긴다. 이미 store=true와 자체 로그 글을 읽었다면 이번 글은 그다음 단계인 durable conversation 보존 범위다.

세 번째 화면은 background mode 문서다. conversation item 보존만 따로 보면 안 되는 이유는 background mode도 짧은 저장을 전제로 움직이기 때문이다.

Background mode는 polling을 위해 응답 데이터를 대략 10분 저장하므로 ZDR와 호환되지 않는다.

여기서 중요한 점은 보존이 하나만 있는 것이 아니라는 사실이다. response 30일, conversation item durable 보존, background polling 10분 저장이 서로 다른 규칙으로 섞인다. 장기 세션을 설계할 때는 이 셋을 한 표에서 같이 봐야 한다.

네 번째 자료는 WebSocket mode 문서다. 같은 continuation이라도 어떤 경로는 디스크에 쓰지 않고 메모리 캐시만 쓴다는 점을 함께 봐야 한다.

WebSocket mode의 직전 previous-response 상태는 메모리에만 남고 디스크에는 쓰지 않는다고 문서가 설명한다.

이 경로는 store=false와 ZDR 쪽에 더 가깝다. 그래서 durable conversation이 필요한지, 메모리 캐시와 stateless replay면 되는지, 또는 previous_response_id와 stateless replay 글처럼 별도 재전달 구조를 둘지를 먼저 갈라야 한다.

이 표는 Responses response, conversation item, background mode, WebSocket 메모리 캐시를 같은 표에서 비교하기 위한 것이다. 보존 범위와 사용 목적을 같이 놓으면 무엇을 꺼야 하는지 훨씬 빨리 보인다.

OpenAI 상태 보존 표면을 response, conversation, background, WebSocket 캐시로 나눈 비교표다.

실무에서는 store 플래그만 체크하면 끝이라고 생각하기 쉽지만, 실제로는 어떤 state surface를 쓰는지가 더 중요하다. 이 표를 배포 설계 메모에 넣어 두면 민감 데이터 경로를 분리하기 쉬워진다.

마지막 자료는 durable conversation을 붙일지 판단할 때 남기는 최소 메모다. 보존, ZDR, continuation 방식을 같은 체크리스트에 넣어야 나중에 헷갈리지 않는다.

Conversation durable state를 켜기 전에 남겨야 할 체크리스트 예시다.

이 메모를 남겨 두면 conversation을 실수로 켠 경로와 꼭 필요한 경로를 구분하기 쉽다. 특히 store:false와 encrypted reasoning 글처럼 ZDR 쪽으로 설계한 흐름과 섞지 않게 된다.

5. 주의사항과 리스크

첫 번째 리스크는 response 30일 문장만 보고 conversation item도 비슷할 것이라고 추정하는 것이다. 두 번째 리스크는 background mode가 polling을 위해 따로 저장하는 사실을 ZDR 검토에서 빼먹는 것이다. 세 번째 리스크는 메모리 캐시와 durable conversation을 같은 continuation으로 취급해 민감 경로까지 conversation으로 밀어 넣는 것이다.

운영 문서에는 최소한 durable conversation 사용 여부, 민감 데이터 포함 여부, background mode 여부, continuation fallback 방식을 남겨 두는 편이 좋다. 그래야 다음에 '왜 이 세션은 오래 남는가', '왜 이 경로는 ZDR가 아닌가', '왜 이 흐름은 previous_response_id로 충분하지 않았는가'에 답할 수 있다.

• response TTL과 conversation item 보존은 같은 규칙이 아니다.
• background mode는 짧은 저장이라도 ZDR 검토에서 별도로 본다.
• durable conversation은 정말 필요한 경로에만 제한한다.

6. 결론

OpenAI Conversations API를 붙이면 response object의 30일 TTL만으로 보존 해석이 끝나지 않는다. conversation object와 item은 그 TTL 대상이 아니고, background mode와 WebSocket cache도 각자 다른 저장 규칙을 가진다. durable conversation을 쓰는 이유와 민감도와 fallback 경로를 같이 적어 두면 retention 오해를 크게 줄일 수 있다.

• response, conversation, background, cache를 각각 다른 표면으로 본다.
• durable conversation은 cross-device resume처럼 명확한 이유가 있을 때만 쓴다.
• 민감 경로는 ZDR와 fallback 방식을 같이 적는다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/conversation-state
2. https://developers.openai.com/api/docs/guides/your-data
3. https://developers.openai.com/api/docs/guides/background
4. https://developers.openai.com/api/docs/guides/websocket-mode