2025.09.22 기준 / GPT-5 Responses API

Responses API, 싸다고요?
이 구조 먼저 보세요

OpenAI가 새 API를 밀어붙이는 진짜 이유를 공식 문서와 독립 분석으로 확인했습니다.

⚡ 캐시 비용 절감 40~80%

📅 Assistants API 종료 2026.08.26

🔗 Chat Completions는 계속 지원

OpenAI Responses API가 Chat Completions보다 40~80% 비용 절감이 된다고 공식 문서에 나와 있습니다. 개발자들이 반색할 만한 수치입니다. 그런데 막상 이 숫자가 어떤 조건에서만 성립하는지 짚고 넘어간 글은 거의 없습니다. 결론부터 말씀드리면, 이 절감 효과는 GPT-5처럼 추론 트레이스(reasoning trace)를 내부에서 숨기는 모델에서만 의미 있게 발생합니다. 일반적인 텍스트 생성 작업에서 Responses API로 갈아탄다고 바로 40%가 줄어드는 게 아닙니다.

동시에 Assistants API는 2026년 8월 26일에 완전히 종료됩니다. (출처: OpenAI 공식 Deprecations 문서, 2025.08.20 발표) 지금 Assistants API로 서비스를 운영 중이라면 이건 선택이 아니라 필수 대응입니다. 이 두 가지 맥락을 같이 놓고 봐야 Responses API가 실제로 어떤 서비스에 필요한지 정확히 보입니다.

Chat Completions와 뭐가 다른 건가요?

기본 설계 철학이 달라졌습니다

Chat Completions는 stateless입니다. 매 요청마다 이전 대화 전체를 배열로 넘깁니다. Responses API는 다릅니다. previous_response_id 하나만 넘기면 OpenAI 서버가 이전 컨텍스트를 유지해줍니다. 개발자 입장에서는 분명 편합니다.

응답 구조가 바뀌었습니다

Chat Completions는 choices[0].message.content로 텍스트를 꺼냈습니다. Responses API는 output_text 헬퍼로 바로 꺼낼 수 있고, 응답 객체에 추론 단계(reasoning), 함수 호출(function_call), 메시지가 각각 독립 item으로 구분되어 들어옵니다. 디버깅이나 감사 로그(audit log) 만들기는 훨씬 쉬워집니다.

내장 도구가 생겼습니다

웹 검색, 파일 검색, 코드 인터프리터, 이미지 생성, 컴퓨터 사용, 원격 MCP 서버 — 이것들을 별도 오케스트레이션 없이 단일 API 호출 안에서 쓸 수 있습니다. Chat Completions에서 이 기능들을 구현하려면 외부 파이프라인을 직접 짜야 했습니다. (출처: OpenAI 공식 Responses vs Chat Completions 문서)

▲ 목차로 돌아가기

40~80% 절감, 이 조건일 때만 해당됩니다

💡 공식 발표문과 독립 개발자의 분석을 같이 놓고 보니, 이 수치가 성립하는 조건이 문서에 명시되어 있지 않다는 게 보였습니다.

OpenAI가 공개한 수치

OpenAI 공식 블로그(2025.09.22)는 내부 테스트 기준 캐시 활용률 40~80% 개선을 발표했습니다. 이게 그대로 비용 절감으로 이어진다고 설명합니다. 또한 GPT-5 기준 SWE-bench에서 Chat Completions 대비 3% 성능 향상이 확인됐다고 합니다. (출처: OpenAI Developers Blog, “Why we built the Responses API”, 2025.09.22)

이 수치가 성립하는 진짜 조건

소프트웨어 엔지니어 Sean Goedecke는 독립 기술 분석(2025.09.09)에서 이 구조를 다른 각도에서 설명합니다. 핵심은 이렇습니다. GPT-5처럼 추론 과정을 내부적으로 숨기는 모델은 Chat Completions로 쓰면 구조적으로 불리합니다. 대화 히스토리를 넘길 때 추론 트레이스(chain-of-thought)가 빠지기 때문입니다. Responses API가 server-side에서 이 추론 흔적을 유지해줘야 비로소 “모델이 이전에 뭘 생각했는지”가 다음 요청에 반영됩니다. 즉, 40~80% 캐시 절감은 추론 트레이스를 서버에서 관리하기 때문에 발생하는 효과입니다. 단순 텍스트 생성 작업에서는 이 격차가 훨씬 좁아집니다.

숫자를 직접 따라가 볼 수 있는 계산

멀티턴 대화에서 Chat Completions를 쓰면 매 요청마다 이전 전체 히스토리를 토큰으로 전송합니다. 10턴 대화라면 첫 턴 토큰이 10번 반복 전송되는 구조입니다. Responses API에서 previous_response_id를 쓰면 이 중복 전송이 사라집니다. 예를 들어 턴당 평균 1,000 토큰짜리 대화를 10턴 진행할 때, Chat Completions는 약 $$1{,}000 + 2{,}000 + 3{,}000 + \cdots + 10{,}000 = 55{,}000$$ 입력 토큰이 발생합니다. Responses API에서 캐시가 정상 작동하면 이론상 $$10{,}000$$ 토큰 수준으로 떨어집니다. 이는 약 82% 절감에 해당합니다. 단, 이 계산은 캐시 히트가 100%일 때의 이론값이고, 실제 환경에선 낮아집니다.

▲ 목차로 돌아가기

Assistants API 종료, 내 서비스는 괜찮을까요?

종료 일정이 확정됐습니다

OpenAI는 2025년 8월 26일, Assistants API의 공식 Deprecation을 선언했습니다. Shutdown 날짜는 2026년 8월 26일입니다. (출처: OpenAI 공식 Deprecations 문서, developers.openai.com/api/docs/deprecations/) 이날 이후에는 Assistants API 호출이 작동하지 않습니다. 약 5개월 남았습니다.

Chat Completions는 종료되지 않습니다

이게 중요한 포인트입니다. 많은 사람이 Responses API가 나오면 Chat Completions도 곧 없어지는 거 아니냐고 묻습니다. 공식 입장은 명확합니다. OpenAI 문서는 “Chat Completions는 계속 지원된다. Responses가 모든 새 프로젝트에 권장되지만, 기존 Chat Completions 코드를 당장 바꿀 의무는 없다“고 명시합니다. (출처: OpenAI 공식 Responses vs Chat Completions 문서) 즉 긴급한 건 Assistants API 사용 여부를 확인하는 것입니다.

마이그레이션 대상 확인 방법

코드 베이스에서 OpenAI-Beta: assistants=v2 헤더나 /v1/assistants, /v1/threads 엔드포인트를 사용 중이라면 마이그레이션 대상입니다. OpenAI 공식 마이그레이션 가이드(developers.openai.com/api/docs/assistants/migration)에 Assistants → Responses + Conversations API로의 전환 절차가 명시되어 있습니다.

▲ 목차로 돌아가기

statefulness가 편의성인지, 잠금장치인지

💡 “쓰기 편해졌다”는 말이 동시에 “갈아타기 어려워졌다”는 말이 될 수 있다는 걸, 오픈소스 진영의 반응을 통해 확인했습니다.

왜 개발자 일부는 걱정할까요?

기존 Chat Completions는 stateless여서 llama.cpp, ollama, vLLM 같은 오픈소스 추론 엔진이 완전히 호환됐습니다. Responses API의 statefulness는 데이터베이스와 영구 저장소가 필요한 구조이기 때문에, 로컬 추론 엔진에서 그대로 복제하기 어렵습니다. Reddit r/LocalLLaMA 커뮤니티(2025.03.18)에서는 이를 두고 “Open AI 생태계 안에 갇히는 구조”라는 우려가 나왔습니다. 개발자 커뮤니티에서 88%의 동의율(upvote ratio)을 얻은 글입니다.

Zero Data Retention 조직은 다르게 써야 합니다

보안 정책상 데이터를 OpenAI 서버에 저장할 수 없는 조직(ZDR, Zero Data Retention)은 store: false와 reasoning.encrypted_content를 조합해야 합니다. 이 경우 추론 컨텍스트가 암호화되어 클라이언트로 전달되고, 디스크에는 기록되지 않습니다. 편의성은 상당히 낮아지고 구현 복잡도는 올라갑니다. (출처: OpenAI 공식 Responses vs Chat Completions 문서)

오픈소스 대안이 이미 나왔습니다

Reddit 댓글 중 Open Responses라는 자체 호스팅 대안이 소개됐습니다. npx -y open-responses init 한 줄로 설치할 수 있으며 Agents SDK와 호환됩니다. 어떤 LLM 모델·프로바이더와도 연결할 수 있다고 설명합니다. (출처: r/LocalLLaMA, julep.ai docs) 완전 검증된 프로덕션 수준인지는 확인 필요입니다.

▲ 목차로 돌아가기

실제로 어떻게 바뀌나요? 코드 변경 범위

엔드포인트 변경은 한 줄입니다

단순 텍스트 생성이라면 POST /v1/chat/completions를 POST /v1/responses로 바꾸는 게 전부입니다. 메시지 배열도 그대로 input에 넣으면 됩니다. OpenAI 공식 문서는 “Responses API는 Chat Completions의 상위 집합(superset)”이라고 명시합니다. 즉 기존 메시지 포맷도 그대로 수용됩니다.

함수 호출 정의가 달라집니다

Chat Completions에서 function 정의는 externally-tagged 방식이었습니다. Responses API에서는 internally-tagged로 바뀌었고, 기본값이 non-strict에서 strict으로 변경됐습니다. 기존에 strict: false를 명시하지 않았다면 함수 스펙을 다시 검토해야 합니다. 이 부분에서 마이그레이션 중 버그가 가장 많이 발생합니다.

Structured Outputs 위치가 이동했습니다

Chat Completions에서 response_format에 넣던 JSON 스키마가 Responses API에서는 text.format으로 이동했습니다. 마이그레이션 시 이 위치 변경을 놓치면 Structured Output이 무시됩니다. 실제 서비스에서 자주 발생하는 조용한 버그입니다.

항목	Chat Completions	Responses API
엔드포인트	/v1/chat/completions	/v1/responses
응답 텍스트 꺼내기	choices[0].message.content	output_text
함수 정의 방식	externally-tagged, non-strict 기본	internally-tagged, strict 기본
구조화 출력	response_format	text.format
컨텍스트 관리	직접 히스토리 전송	previous_response_id 또는 Conversations API

출처: OpenAI 공식 Responses vs Chat Completions 마이그레이션 가이드

▲ 목차로 돌아가기

어떤 서비스에 Responses API가 맞을까요?

Responses API가 분명히 유리한 경우

GPT-5 등 추론 모델을 멀티턴 에이전트 워크플로에 쓰는 경우가 핵심입니다. TAUBench 기준 Chat Completions 대비 5% 성능 향상이 확인됐습니다. (출처: OpenAI Developers Blog, 2025.09.22) 내장 웹 검색, 파일 검색, 코드 인터프리터를 별도 파이프라인 없이 써야 하는 경우, 또는 여러 단계에 걸친 도구 호출 흐름을 한 API 요청 안에서 처리해야 할 때도 Responses API가 맞습니다.

Chat Completions가 여전히 나은 경우

단순 텍스트 생성, 분류, 요약처럼 단일 턴이거나 컨텍스트 유지가 불필요한 작업은 Chat Completions로 충분합니다. LangChain, LlamaIndex처럼 다양한 모델 프로바이더를 교체할 가능성이 있는 프로젝트라면 Chat Completions가 훨씬 이식성이 높습니다. Portkey 분석(2026.02.23)에서도 “범용 텍스트 생성 작업에는 Chat Completions가 여전히 표준”이라고 명시합니다.

Anthropic Claude를 같이 쓰는 환경에서는

Claude의 Messages API는 추론 트레이스를 그대로 노출합니다. Portkey처럼 여러 API 포맷을 중간에서 변환해주는 게이트웨이를 쓴다면, Responses API 포맷으로 요청을 보내면서 Claude 모델을 백엔드로 쓰는 것도 가능합니다. (출처: Portkey.ai, 2026.02.23) 이런 멀티프로바이더 전략을 처음부터 고려한다면 직접 Responses API SDK에 종속되는 것보다 이식성 확보가 더 중요할 수 있습니다.

▲ 목차로 돌아가기

Q&A

Q. Chat Completions를 쓰던 코드를 지금 당장 Responses API로 바꿔야 하나요?

그렇지 않습니다. OpenAI 공식 문서는 Chat Completions를 계속 지원한다고 명시합니다. 다만 GPT-5처럼 추론 모델을 멀티턴 에이전트에 쓰는 경우에는 Responses API로 가는 게 성능상 유리합니다. 지금 당장 급한 건 Assistants API 사용 여부 확인입니다.

Q. Assistants API 종료 후에도 Thread나 Assistant 객체 데이터가 남아 있나요?

2026년 8월 26일 이후 API 호출 자체가 중단됩니다. Thread, Message, Run 같은 객체 데이터의 보존 여부는 OpenAI 공식 마이그레이션 가이드에서 최신 내용을 직접 확인하는 것이 안전합니다. 현재 공식 문서상으로는 사전 데이터 이전 계획을 세우도록 권고합니다.

Q. store: false로 설정하면 비용이 줄어드나요?

store: false를 쓰면 서버에 응답이 저장되지 않습니다. 다만 이 경우 previous_response_id를 통한 컨텍스트 연결이 불가능해 멀티턴 캐시 절감 효과도 사라집니다. ZDR(Zero Data Retention) 환경에서는 encrypted_content를 함께 써서 추론 컨텍스트를 암호화 형태로 유지해야 하는데, 구현 복잡도가 높아집니다.

Q. Responses API는 OpenAI 모델에서만 되나요?

네이티브로는 OpenAI 모델에서만 동작합니다. Portkey 같은 API 게이트웨이를 쓰면 Responses API 포맷으로 요청하면서 Claude, Gemini 등 다른 모델을 백엔드로 연결하는 것이 가능합니다. 오픈소스 대안으로는 open-responses(julep.ai)가 있으나 프로덕션 수준 검증은 직접 확인이 필요합니다.

Q. 멀티턴 대화에서 비용이 실제로 얼마나 달라지나요?

이론적으로 10턴 대화 기준 Chat Completions 대비 최대 82% 입력 토큰 절감이 가능합니다(각 턴 1,000토큰 기준, 캐시 히트 100% 가정). 실제로는 캐시 히트율에 따라 절감폭이 달라지고, 단순 텍스트 생성 작업에서는 추론 트레이스가 없으므로 효과가 제한적입니다. OpenAI 내부 테스트 기준 40~80%라는 수치는 추론 모델 기반 복잡한 워크플로에서 나온 값입니다.

▲ 목차로 돌아가기

마치며

솔직히 말하면, Responses API 자체는 잘 만들어진 API입니다. 에이전트 워크플로를 위한 구조가 Chat Completions보다 훨씬 정돈돼 있고, 내장 도구도 실용적입니다. 그런데 “더 싸다”는 마케팅 언어에 끌려서 전환을 결정하면, 막상 일반 텍스트 생성 작업에서 기대한 만큼의 비용 차이를 못 보고 실망하게 됩니다.

기억해야 할 건 두 가지입니다. 첫째, Assistants API를 쓰고 있다면 2026년 8월 26일 이전에 반드시 마이그레이션해야 합니다. Chat Completions를 쓰고 있다면 급하지 않습니다. 둘째, Responses API의 비용 절감은 GPT-5 같은 추론 모델 기반 멀티턴 에이전트에서 가장 크게 납니다. 이 조건에 맞는 서비스를 운영하고 있다면 전환을 적극적으로 검토할 만합니다.

기대했던 것과 다를 수 있는 게 하나 더 있습니다. statefulness가 편해 보이지만, 동시에 OpenAI 이외 프로바이더로 갈아타기 어려워지는 구조이기도 합니다. 이 트레이드오프를 알고 선택하는 것과 모르고 선택하는 것은 나중에 꽤 다른 결과를 만듭니다.

▲ 목차로 돌아가기

📚 본 포스팅 참고 자료

※ 본 포스팅은 2026년 3월 19일 기준 공개된 OpenAI 공식 문서를 바탕으로 작성됐습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. API 종료 일정, 가격, 기능 스펙은 반드시 OpenAI 공식 문서에서 최신 내용을 직접 확인하시기 바랍니다.

Responses API, 싸다고요? 이 구조 먼저 보세요

Responses API, 싸다고요?
이 구조 먼저 보세요