OpenAI Responses API, 비용 준다는 말이 전부가 아닙니다
“캐시 비용 40~80% 절감”이라는 공식 문서 수치, 실제로는 조건이 붙습니다. 그리고 OpenAI가 이 API를 밀어붙이는 진짜 이유도 따로 있습니다.
Responses API가 뭔지 한 줄로 정리하면
OpenAI가 2025년 3월 공개한 Responses API(/v1/responses)는 기존 Chat Completions API(/v1/chat/completions)의 후속 모델입니다. 단순한 업그레이드가 아니라, 에이전트형 AI 앱을 만들 때 필요한 기능들을 API 레벨에서 통합한 새로운 인터페이스입니다. (출처: OpenAI 공식 블로그 ‘Why we built the Responses API’, 2025.09.22)
Chat Completions는 “사용자가 메시지를 주면, 모델이 응답을 돌려준다”는 단순한 턴제 구조였습니다. Responses API는 여기에 상태 유지(stateful), 내장 툴(built-in tools), 추론 상태 보존을 얹었습니다. 덕분에 웹 검색·파일 탐색·코드 실행·이미지 생성·MCP 서버까지 API 한 번 호출로 연결됩니다.
공식 문서는 “모든 신규 프로젝트에 Responses API 사용을 권장한다”고 명시하고 있습니다. (출처: OpenAI Docs, Responses vs Chat Completions)
Chat Completions와 실제로 다른 점 3가지
① 응답 구조가 달라졌습니다
Chat Completions는 결과를 choices[0].message.content로 꺼내야 했습니다. Responses API는 response.output_text로 바로 접근합니다. 코드 한 줄 차이지만, 멀티스텝 에이전트에서 도구 호출 순서가 명확해지는 것이 실무에서 큰 차이입니다.
② 추론 상태가 회차 간에 살아있습니다
Chat Completions에서는 매 호출마다 추론을 처음부터 시작합니다. Responses는 이전 추론을 이어받으니 복잡한 멀티스텝 작업에서 결과가 달라집니다.
③ 호스팅 툴이 API 레벨에서 붙어 있습니다
웹 검색(web_search), 파일 탐색(file_search), 코드 해석기(code_interpreter), 이미지 생성(image_generation), 원격 MCP 서버 연결(mcp) 이렇게 5가지가 기본 내장입니다. Chat Completions에서는 이 기능들을 직접 구현해야 했습니다. (출처: OpenAI API Reference, 2025.08 기준)
| 항목 | Chat Completions | Responses API |
|---|---|---|
| 응답 접근 방식 | choices[0].message.content |
response.output_text |
| 추론 상태 유지 | ❌ 매 호출 초기화 | ✅ 서버 측 보존 |
| 웹 검색 내장 | ❌ 직접 구현 필요 | ✅ 기본 제공 |
| 코드 인터프리터 | ❌ 직접 구현 필요 | ✅ 기본 제공 |
| 상태 저장 방식 | 클라이언트 직접 관리 | 서버 자동 관리 |
| 오디오 지원 | ✅ | ⏳ 준비 중 |
“비용 40~80% 절감”이 조건부인 이유
OpenAI 공식 문서에는 이렇게 나와 있습니다. “Chat Completions 대비 캐시 활용률이 40~80% 개선됐다.” (출처: OpenAI Docs, Responses vs Chat Completions, 2025.08) 처음 보면 비용이 절반 이하로 떨어지는 것처럼 읽힙니다.
💡 공식 발표 수치와 실제 청구 내역을 같이 놓고 보니 이런 차이가 보였습니다
OpenAI 개발자 커뮤니티에서 실제 토큰 사용량을 비교한 결과, previous_response_id를 사용해도 입력 토큰 수는 Chat Completions와 거의 동일하다는 보고가 올라왔습니다. (출처: OpenAI Developer Community, ‘Responses API vs Completions: No Token Savings?’, 2025.06) 이유는 간단합니다. OpenAI 서버가 내부적으로 여전히 전체 컨텍스트를 처리하기 때문입니다.
정리하면, 40~80% 절감은 캐시 적중률(cache hit rate) 향상의 이야기입니다. 컨텍스트가 1,000토큰 이상이고, 동일한 프리픽스(prefix)가 반복될 때 자동으로 캐시가 걸립니다. 이 조건이 갖춰지지 않은 단순 QA 앱이나 매번 다른 시스템 프롬프트를 쓰는 구조에서는 절감이 거의 없습니다.
실제 비용 절감을 보려면 이렇게 따져봐야 합니다. 내 앱의 시스템 프롬프트가 매 요청마다 바뀌지 않고, 컨텍스트 길이가 1,000토큰을 넘으며, 같은 사용자가 연속 대화를 이어가는 구조여야 캐시가 의미 있게 작동합니다. 이 세 가지 중 하나라도 빠지면 청구서는 크게 다르지 않습니다.
OpenAI가 이 API를 강하게 미는 진짜 배경
솔직히 말하면, OpenAI가 Responses API를 이렇게까지 강하게 미는 데는 개발자 편의 외에 따로 이유가 있습니다. 소프트웨어 엔지니어 Sean Goedecke의 분석이 이 부분을 정확하게 짚었습니다. (출처: seangoedecke.com, 2025.09.09)
💡 공식 발표문과 실제 API 설계 흐름을 같이 놓고 보니 이런 차이가 보였습니다
CoT를 노출하지 않으면 Chat Completions에서 GPT-5는 매 호출마다 추론을 처음부터 시작합니다. 이러면 추론 모델의 성능이 OpenAI 자체 제품(ChatGPT)보다 API에서 낮게 나옵니다. Responses API는 CoT를 OpenAI 서버에서 암호화 보관했다가 자동 주입합니다. 즉, CoT를 숨기면서도 성능을 유지하려면 stateful API가 필요했던 겁니다. OpenAI가 공식 문서에서 별도 이유를 밝히지 않은 부분입니다.
이 사실은 실제 코드 작성에도 영향을 미칩니다. Anthropic의 Claude를 쓴다면 CoT를 직접 다음 요청에 넣을 수 있어서 Chat Completions 방식 API에서도 같은 효과를 낼 수 있습니다. GPT-5를 최대 성능으로 쓰려면 Responses API가 현재로선 유일한 방법입니다.
Assistants API 쓰고 있다면 마감일이 있습니다
OpenAI는 2025년 8월 26일 Assistants API를 공식 deprecated(사용 중단 예고) 처리했습니다. 실제 서비스 종료일은 2026년 8월 26일입니다. (출처: OpenAI 공식 마이그레이션 문서, platform.openai.com)
지금 기준으로 약 5개월 남았습니다. 마이그레이션 방향은 이렇습니다. Assistants → Prompts, Threads → Conversations, Runs → Responses, Run steps → Items로 각각 대응됩니다. 기존 Thread 객체를 Conversation으로 자동 이전해 주는 툴은 OpenAI가 제공하지 않습니다. 직접 코드로 백필해야 합니다.
마이그레이션에서 가장 달라지는 점은 Prompts 생성 방식입니다. 기존 Assistants는 API로 생성·수정이 가능했습니다. 새로운 Prompts는 대시보드에서만 만들 수 있습니다. 코드로 Prompt 객체를 직접 생성하는 게 막혀 있습니다. 자동화 파이프라인에서 Assistant를 동적으로 생성하던 구조라면 이 부분이 걸립니다.
⚠️ 체크리스트
- 현재
openai.beta.threads,openai.beta.assistants코드를 쓰고 있다면 대상입니다 - Thread → Conversation 자동 이전 도구 없음, 수동 백필 필요
- Prompt는 대시보드에서만 생성 가능, API 생성 불가
- 종료일: 2026년 8월 26일
ZDR 환경이라면 stateful하게 못 씁니다
Responses API의 핵심 기능은 상태 유지(stateful)입니다. 그런데 ZDR(Zero Data Retention, 무데이터 보존) 계약을 맺은 OpenAI 엔터프라이즈 고객은 이 기능을 그대로 쓸 수 없습니다. 데이터가 서버에 저장되지 않아야 한다는 조건과 충돌하기 때문입니다. (출처: OpenAI Docs, Responses vs Chat Completions, 2025.08)
이 경우 store: false로 설정하고, include 필드에 reasoning.encrypted_content를 추가하면 됩니다. OpenAI 서버가 암호화된 추론 토큰을 클라이언트에게 돌려주고, 클라이언트는 이를 다음 요청에 첨부합니다. 서버는 메모리에서만 복호화하고 디스크에 저장하지 않습니다. 추론 흔적이 클라이언트 측에 있지만, 암호화돼 있어 내용을 읽을 수 없습니다.
금융·의료·공공 분야처럼 데이터 보존 규정이 엄격한 환경에서는 이 옵션이 유일한 선택입니다. 다만 이 방식은 Gemini가 이미 기본 방식으로 제공하는 것과 동일한 구조입니다. OpenAI가 이것을 “예외 옵션”으로 두었는지 이유는 공식 발표에 나와 있지 않습니다.
결론 — 지금 당장 옮겨야 할 사람, 아닌 사람
Responses API가 무조건 좋은 건 아닙니다. 상황에 따라 Chat Completions가 더 맞는 경우가 있습니다. 오디오 입출력이 중심인 앱은 Responses API에서 아직 지원이 준비 중이고, 단순 단답형 API라면 추가 복잡도를 감수할 이유가 없습니다.
지금 바로 옮길 이유가 있는 경우
- Assistants API 사용 중 → 2026년 8월 26일 강제 종료 전에 마이그레이션 필요
- GPT-5 기반 에이전트 개발 → 추론 상태 보존으로 SWE-bench +3% 성능 확보 가능
- 웹 검색·코드 실행이 필요한 앱 → 내장 툴로 외부 구현 코드 제거 가능
- 멀티스텝 대화가 긴 서비스 → 캐시 활용으로 비용 절감 효과 가능
굳이 지금 안 옮겨도 되는 경우
- 단순 QA·요약 앱 → Chat Completions가 더 단순하고 충분
- 오디오 중심 앱 → Responses API 오디오 지원 준비 중 (2026년 기준)
- GPT-4.1 이하 모델 사용 → 추론 상태 보존의 이점이 제한적
Q&A 5가지
마치며
Responses API는 분명히 기술적으로 발전한 인터페이스입니다. 에이전트 개발에서 코드 복잡도를 줄이고, GPT-5 계열 모델의 추론 성능을 최대로 끌어내려면 이 쪽으로 가는 게 맞습니다. 그런데 “비용이 줄고 더 쉽다”는 마케팅 언어를 그대로 믿으면 막상 써보고 예상과 달라서 당황하게 됩니다.
핵심만 짚으면 이렇습니다. 비용 절감은 캐시 조건이 맞아야 보이고, 코드가 더 단순해지는 건 툴 빌드 부담이 있는 에이전트 앱에서만 해당합니다. Assistants API를 지금 쓰고 있다면 2026년 8월 26일이라는 실제 마감이 있습니다. 그리고 GPT-5 이상을 제대로 쓰려면 Responses API가 사실상 필수 경로입니다.
Chat Completions도 계속 지원되고 버리는 게 아니니, 전환 부담이 크다면 신규 기능부터 Responses API로 붙여가는 점진적 이전이 현실적입니다.
본 포스팅 참고 자료
- OpenAI 공식 블로그 — Why we built the Responses API (2025.09.22)
- OpenAI Docs — Responses vs Chat Completions (2025.08 기준)
- OpenAI Docs — Assistants API Migration Guide (2025.08 기준)
- Sean Goedecke — The whole point of OpenAI’s Responses API (2025.09.09)
- OpenAI Developer Community — Responses API vs Completions: No Token Savings? (2025.06)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. OpenAI Responses API는 지속적으로 업데이트되는 서비스이므로, 최신 정보는 OpenAI 공식 문서에서 직접 확인하시기 바랍니다. 본 포스팅의 수치와 기능 설명은 2026년 3월 29일 기준입니다.
댓글 남기기