Responses API 공식 문서 직접 확인
Assistants API 2026.08.26 종료
OpenAI Responses API, 싸진다는 말이 조건이 있습니다
OpenAI 공식 문서는 Responses API가 Chat Completions보다 캐시 비용을 40~80% 절감한다고 명시합니다. 그런데 같은 문서 아래쪽에는 이 혜택이 작동하지 않는 조건이 나란히 적혀 있습니다. 마이그레이션 전에 이 부분부터 확인하는 게 순서입니다.
Responses API가 뭔지부터 짚고 가겠습니다
Chat Completions의 후속 API입니다
OpenAI Responses API는 기존 /v1/chat/completions 엔드포인트를 대체하는 새로운 API 레이어입니다. OpenAI 공식 문서는 “모든 새 프로젝트에 Responses API를 권장한다”고 직접 명시합니다. Chat Completions는 계속 지원하지만, 신규 기능은 Responses API에만 추가됩니다. (출처: OpenAI 공식 Responses vs Chat Completions 가이드)
Assistants API와는 별개의 맥락입니다
Assistants API는 2026년 8월 26일 완전 종료됩니다. Responses API는 이 Assistants API의 대체 역할도 겸합니다. 즉, 지금 프로젝트에 Assistants API를 쓰고 있다면 Responses API로 이전해야 하고, Chat Completions를 쓰고 있다면 전환 여부를 별도로 판단해야 합니다. 두 상황이 다릅니다.
기본 구조가 어떻게 달라졌나
Chat Completions는 매 요청마다 전체 대화 기록을 배열로 전송합니다. Responses API는 previous_response_id만 넘기면 OpenAI 서버가 이전 맥락을 유지해줍니다. 상태 관리를 클라이언트가 아니라 서버가 담당하는 구조로 전환된 것입니다. 이 차이가 비용과 데이터 정책 모두에 영향을 줍니다.
비용 절감 40~80%의 실제 조건
공식 수치는 “내부 테스트” 기준입니다
OpenAI 공식 가이드에는 “Chat Completions 대비 캐시 활용률이 40~80% 향상되었다”는 수치가 명시됩니다. (출처: OpenAI 공식 Responses vs Chat Completions 가이드, 2025.08 업데이트 기준) 수치가 인상적이지만, 뒤에 붙는 단서가 있습니다. “internal tests” 즉 OpenAI 내부 테스트 기준입니다. 실제 워크로드에 따라 달라집니다.
💡 공식 발표 수치와 실제 사용 조건을 같이 놓고 보니 이런 차이가 보였습니다.
캐시 절감이 일어나는 핵심 조건은 “동일하거나 유사한 입력이 반복될 때”입니다. 매번 다른 사용자가 전혀 다른 입력을 보내는 서비스라면, 40~80% 절감은 사실상 기대하기 어렵습니다. 반복적인 시스템 프롬프트가 긴 에이전트 워크플로에서 효과가 두드러집니다.
Extended Prompt Caching은 ZDR과 충돌합니다
확장 프롬프트 캐싱(Extended Prompt Caching)은 GPU 로컬 스토리지에 KV 텐서를 저장합니다. OpenAI 공식 데이터 정책 문서에 따르면, 이 기능을 사용하는 요청은 Zero Data Retention(ZDR)과 호환되지 않습니다. (출처: OpenAI Data Controls 공식 문서, 2026.03 기준) 의료·금융 등 ZDR이 필요한 조직은 캐시 절감 혜택과 데이터 정책 중 하나를 포기해야 합니다.
| 조건 | Chat Completions | Responses API |
|---|---|---|
| 캐시 활용률 향상 | 기준치 | +40~80% (내부 테스트) |
| ZDR 호환 | ✅ (일부 제한) | ✅ (store:false 시) |
| Extended 캐싱 + ZDR 동시 사용 | ❌ | ❌ |
| 기본 데이터 보관 | 없음(신규 계정은 30일) | 30일 (store:true 기본) |
| 웹 검색·이미지 생성 등 내장 툴 | ❌ | ✅ |
“더 단순하다”는 말, 공식 문서엔 다르게 나옵니다
단순함보다 정확한 단어는 “상태를 위임”입니다
OpenAI는 Responses API가 Chat Completions보다 “더 단순하다(simpler)”고 강조합니다. 코드 줄 수는 줄어드는 게 맞습니다. 대화 기록을 매번 배열로 쌓지 않아도 되니까요. 그런데 그 단순함의 대가로, 상태 관리 책임이 개발자 코드에서 OpenAI 서버로 이동합니다. 복잡성이 사라진 게 아니라 위치가 바뀐 것입니다.
💡 Responses API가 Reasoning API를 위한 우회책이기도 하다는 사실은, 마케팅 문구에서 빠져 있습니다.
GPT-5.4 이후부터는 tool calling이 제한됩니다
공식 문서에는 이런 내용이 있습니다. “GPT-5.4부터 Chat Completions에서 reasoning: none 설정 시 tool calling이 지원되지 않는다.” (출처: OpenAI Responses vs Chat Completions 가이드, 2025.08 업데이트 기준) 단순 Q&A 앱이 아니라 툴을 쓰는 에이전트를 Chat Completions로 유지하려 했다면, 최신 모델 업그레이드 시점에 강제로 마이그레이션 압박을 받게 됩니다.
store:true 기본값이 만드는 데이터 보관 함정
기본값을 바꾸지 않으면 30일 보관이 적용됩니다
Responses API는 기본적으로 store: true로 동작합니다. OpenAI 공식 데이터 정책 문서에는 “Responses API는 기본적으로 혹은 store 파라미터가 true로 설정될 때 30일간 Application State를 보관한다”고 명시합니다. (출처: OpenAI Data Controls 공식 문서, 2026.03 기준) 30일 동안 내 사용자의 대화가 OpenAI 서버에 남는다는 뜻입니다.
ZDR 설정 시 상태 저장 기능 자체가 꺼집니다
Zero Data Retention이 활성화된 조직에서는 store 파라미터가 자동으로 false로 강제됩니다. Responses API의 핵심인 상태 기반 대화 관리를 사용할 수 없게 됩니다. 대신 OpenAI는 “암호화된 추론 항목(encrypted reasoning items)”을 클라이언트에 전달하는 방식을 제공합니다. Gemini가 이미 이 방식으로 운영 중입니다.
Conversations API는 ZDR과 아예 호환되지 않습니다
/v1/conversations 엔드포인트는 데이터가 삭제 전까지 무기한 보관됩니다. ZDR 호환 자체가 불가합니다. HIPAA나 금융 규제 대응이 필요한 서비스에서 Conversations API를 대화 히스토리 저장소로 쓰는 건 정책상 불가입니다. (출처: OpenAI Data Controls 공식 문서, 2026.03 기준) 이 부분을 마이그레이션 설계 전에 확인해야 합니다.
Assistants API 마이그레이션, 어떻게 다른가
Thread를 Conversation으로 자동 이전해주지 않습니다
OpenAI 공식 마이그레이션 가이드에 직접 나와 있습니다. “Thread를 Conversation으로 자동 이전하는 도구는 제공하지 않는다.” (출처: OpenAI Assistants API 마이그레이션 가이드, 2025.08 기준) 기존 사용자 대화 내역을 직접 코드로 변환해야 합니다. 사용자가 많을수록 이 작업량이 커집니다.
💡 Assistant 객체와 Prompt 객체의 가장 큰 구조적 차이는 생성 방법입니다.
기존 Assistant는 API로 생성하고 관리했습니다. 반면 새로운 Prompt는 대시보드에서만 생성 가능합니다. 코드로 Prompt를 동적으로 생성하는 패턴은 지원되지 않습니다. CI/CD 파이프라인에서 Assistant를 자동 생성하던 팀은 운영 방식을 바꿔야 합니다.
Run → Response 전환에서 폴링 패턴이 사라집니다
Assistants API의 Run은 비동기였습니다. 상태를 주기적으로 조회(polling)해야 했습니다. Responses API는 동기 방식으로 바로 결과를 반환합니다. 코드가 짧아지는 건 맞지만, 기존에 폴링 로직으로 짜여 있던 코드 전체를 재설계해야 합니다. 단순 텍스트 교체로 끝나는 마이그레이션이 아닙니다.
지금 당장 바꿔야 할 상황 vs 기다려도 되는 상황
지금 바꿔야 하는 경우
Assistants API를 쓰고 있다면 2026년 8월 26일까지 반드시 이전해야 합니다. 그 이후에는 엔드포인트 자체가 닫힙니다. GPT-5 이상 추론 모델을 써야 하는데 tool calling이 필요하다면, Chat Completions에서 Responses API로의 전환 없이는 최신 모델의 성능을 제대로 쓸 수 없습니다.
기다려도 되는 경우
Chat Completions로 단순 텍스트 생성만 하고 있고, ZDR이 필요한 규제 환경이라면 오히려 Responses API 전환이 복잡해집니다. store:false로 설정하면 상태 관리 이점이 사라지고, Chat Completions와 기능적 차이가 줄어듭니다. OpenAI도 Chat Completions는 계속 지원하겠다고 명시했습니다.
단계적 전환이 공식 권장 방식입니다
OpenAI 공식 문서는 “추론 모델을 쓰는 플로우부터 Responses API로 옮기고, 나머지는 준비될 때 전환하라”고 직접 안내합니다. (출처: OpenAI Responses vs Chat Completions 가이드) 전체 서비스를 한 번에 전환할 필요 없이, 워크플로 단위로 나눠서 진행할 수 있습니다.
자주 묻는 질문 5가지
Q1. Chat Completions API는 언제 종료되나요?
Q2. Responses API 사용 시 추가 요금이 있나요?
Q3. 기존 Assistants API Thread는 자동으로 Conversation으로 이전되나요?
Q4. store:false로 설정하면 캐시 절감 혜택도 사라지나요?
Q5. Responses API의 structured output 설정이 Chat Completions와 다른가요?
response_format으로 설정했지만, Responses API에서는 text.format으로 위치가 바뀌었습니다. Function calling의 정의 방식도 달라졌습니다. Chat Completions는 외부 태그 방식, Responses API는 내부 태그 방식을 씁니다. 또한 Responses API에서는 함수가 기본적으로 strict 모드로 동작합니다.
마치며
Responses API는 분명히 방향이 맞습니다. 에이전트 구조에 최적화되어 있고, 추론 모델과의 조합에서 Chat Completions보다 유리한 점이 많습니다. 공식 내부 테스트에서 40~80% 캐시 비용 절감이 나온 것도 사실입니다.
다만 그 혜택이 모든 상황에서 동일하게 적용되지는 않습니다. ZDR이 필요한 환경, 반복 입력이 없는 서비스, API로 Prompt를 동적 생성해야 하는 구조에서는 오히려 Responses API가 제약 조건이 됩니다. “단순하고 싸다”는 문구만 보고 바로 전환 계획을 세우기 전에, 공식 데이터 정책 문서와 마이그레이션 가이드를 같이 읽는 게 필요합니다.
Assistants API를 쓰고 있다면 데드라인(2026년 8월 26일)이 있으니 지금 설계를 시작하는 게 맞습니다. Chat Completions를 쓰고 있다면, 추론 모델이 필요한 플로우부터 단계적으로 검토하는 순서가 현실적입니다.
📚 본 포스팅 참고 자료
본 포스팅은 2026년 03월 25일 기준으로 작성되었습니다. 본 포스팅 작성 이후 OpenAI의 서비스 정책·UI·기능·가격이 변경될 수 있습니다. 최신 정보는 OpenAI 공식 문서에서 확인하시기 바랍니다.
댓글 남기기