Responses API가 등장한 진짜 이유

OpenAI는 2025년 3월, /v1/responses 엔드포인트를 공개했습니다. 표면적 이유는 “더 강력한 에이전트 개발 환경”이지만, 공식 개발자 블로그를 직접 읽으면 다른 맥락이 보입니다. Chat Completions 엔드포인트는 단순 채팅 인터페이스 시절에 설계됐고, 추론 모델과 멀티모달 입력이 일상화된 지금 구조적으로 버겁습니다. (출처: OpenAI Developers Blog, 2025.09.22)

Assistants API는 이 공백을 메우려 했지만, 비동기 Runs 구조가 복잡해 현장 채택률이 낮았습니다. 결국 OpenAI 스스로 “Chat Completions만큼 접근하기 쉬우면서 Assistants만큼 강력한” 것이 필요하다고 판단했고, 그 결과물이 Responses API입니다.

핵심 차이는 한 가지입니다. Chat Completions가 “메시지를 주고받는 채팅 루프”라면, Responses API는 “추론하고 도구를 쓰고 결과를 돌려주는 에이전트 루프”입니다. 추론 상태가 호출 간에 유지되고, 도구 실행이 서버 쪽에서 처리됩니다.

▲ 목차로 돌아가기

Chat Completions와 뭐가 다른지, 코드로 직접 비교

가장 눈에 띄는 차이는 응답 구조입니다. Chat Completions는 choices[0].message.content처럼 중첩된 배열에서 값을 꺼내야 합니다. Responses API는 response.output_text로 바로 꺼냅니다. 작은 차이처럼 보이지만, 멀티턴 + 툴콜 환경에서는 코드 복잡도가 현격히 줄어듭니다.

completion = client.chat.completions.create(
model="gpt-5",
messages=[{"role": "user", "content": "질문"}]
)
print(completion.choices[0].message.content)  # 중첩 구조

response = client.responses.create(
model="gpt-5",
input="질문"
)
print(response.output_text)  # 바로 꺼냄

구조적 변화: Messages에서 Items으로

Chat Completions는 모든 것을 Message 하나에 욱여넣습니다. 툴 호출이 먼저인지, 메시지가 먼저인지 순서가 섞입니다. Responses API는 모든 행동을 “Items”라는 다형적 객체로 분리합니다. message, function_call, function_call_output이 각각 독립된 타입으로 명확히 구분되어 감사 로그나 디버깅이 훨씬 수월합니다. (출처: OpenAI platform.openai.com/docs/guides/responses-vs-chat-completions)

Structured Outputs도 달라집니다. Chat Completions의 response_format 파라미터가 Responses API에서는 text.format으로 이동했습니다. 함수 정의 방식도 내부 태깅 방식으로 바뀌고, strict 모드가 기본값으로 켜집니다. 마이그레이션 시 가장 많이 놓치는 부분입니다.

▲ 목차로 돌아가기

빠르다는 말이 맞는 조건과 아닌 조건

OpenAI 커뮤니티에서 개발자가 직접 20회 반복 측정한 결과가 있습니다. Store=True(상태 저장 켜짐) 조건에서 Responses API 평균 응답 시간은 4.268초였고, Chat Completions는 1.354초였습니다. 3.15배 차이입니다. (출처: OpenAI Community Forum, 2025.09.06)

※ 측정 환경: Azure OpenAI, gpt-5, minimal reasoning, low verbosity, 20회 반복 / 출처: OpenAI Community Forum (2025.09.06)

Store를 끄면 Responses API도 빨라지지만, 여전히 Chat Completions보다 2.31배 느립니다. OpenAI 엔지니어링 팀은 “데이터베이스 최적화 작업 중”이라고 커뮤니티에 직접 답변했습니다. 2026년 3월 현재까지 공식 성능 개선 공지는 없습니다.

그렇다면 어디에서 쓰는 게 맞나

웹 검색, 코드 인터프리터, MCP 같은 내장 도구를 쓰는 에이전트 워크플로우라면 Responses API가 실질적으로 유리합니다. 도구 실행이 서버 쪽에서 일어나서 개발자 서버와의 왕복 횟수가 줄어들기 때문입니다. 반면 단순 텍스트 생성이나 짧은 멀티턴 채팅이라면 지금 당장은 Chat Completions가 지연 시간 면에서 낫습니다.

▲ 목차로 돌아가기

비용 구조: 캐시 절감이 실제로 가능한 상황

Responses API의 캐시 이점은 조건이 맞아야 작동합니다. 공식 내부 테스트에서 40~80% 캐시 비용 절감이 가능하다고 했는데, 이는 긴 시스템 프롬프트나 반복적인 컨텍스트가 있는 환경에서의 수치입니다. (출처: platform.openai.com/docs/guides/responses-vs-chat-completions) 짧은 단발성 요청에서는 캐시 히트 자체가 일어나지 않아 절감 효과가 없습니다.

출처: platform.openai.com/docs/pricing#built-in-tools (2026.03.24 기준)

특히 코드 인터프리터는 2026년 3월 31일부터 과금 방식이 바뀝니다. 지금까지는 컨테이너 용량 기준이었는데, 3월 31일 이후엔 “20분 세션당”으로 전환됩니다. 코드 실행이 자주 필요한 에이전트라면 비용 시뮬레이션을 다시 해야 합니다.

▲ 목차로 돌아가기

Assistants API 종료, 지금 당장 확인해야 할 것

2025년 8월 26일, OpenAI는 공식 커뮤니티를 통해 Assistants API 베타의 종료를 발표했습니다. 종료일은 2026년 8월 26일입니다. (출처: OpenAI Community Forum, 2025.08.26) 지금 이 글을 읽는 시점에서 약 5개월이 남았습니다.

마이그레이션에서 가장 복잡한 부분

개념 자체가 바뀝니다. Assistants → Prompts, Threads → Conversations, Runs → Responses, Run Steps → Items. 이름만 바뀐 게 아니라 동작 방식도 달라집니다. Runs는 비동기 폴링 방식이었지만, Responses는 입력을 주면 출력 Items를 돌려받는 단순한 구조입니다.

OpenAI는 기존 Thread를 Conversation으로 자동 변환하는 도구를 제공하지 않겠다고 밝혔습니다. 대신 새 사용자 대화는 Conversations으로 받고, 기존 Thread는 수동으로 백필하는 전략을 권장합니다. 프로덕션에서 Threads가 수만 개 쌓인 팀이라면 마이그레이션 공수를 과소평가하면 안 됩니다.

Prompts는 대시보드에서만 생성할 수 있습니다. 기존에 코드로 Assistant 객체를 생성하던 방식은 없어집니다. CI/CD 파이프라인에 `openai.beta.assistants.create()` 호출이 들어 있다면 지금 확인이 필요합니다.

▲ 목차로 돌아가기

ZDR 환경에서 상태 저장을 포기하지 않는 방법

Encrypted Reasoning Items 기능을 사용하면 됩니다. store: false로 설정하면서 include: ["reasoning.encrypted_content"]를 함께 넘기면, OpenAI 서버는 추론 토큰을 디스크에 저장하지 않고 암호화된 형태로 응답에 포함시킵니다. 이 암호화된 토큰을 다음 요청에 그대로 넘기면 추론 연속성을 유지할 수 있습니다. (출처: platform.openai.com/docs/guides/responses-vs-chat-completions, 2026.03.24 기준)

작동 방식을 구체적으로 보면, OpenAI 서버는 encrypted_content를 받을 때 메모리 내에서만 복호화하고 새 추론 토큰이 생기면 즉시 다시 암호화해서 돌려줍니다. 중간 상태는 디스크에 기록되지 않습니다. 이 방식은 의료·금융처럼 데이터 보존 정책이 엄격한 환경에서 유일하게 쓸 수 있는 선택지입니다.

단, 이 방법을 쓰면 응답마다 암호화된 토큰 덩어리가 추가되므로 요청 페이로드가 커집니다. 네트워크 비용과 직렬화 오버헤드가 생긴다는 점은 감안해야 합니다. 공식적으로 추가 과금은 없지만, 이유는 아직 공개되지 않았습니다.

▲ 목차로 돌아가기

자주 나오는 질문 5가지

▲ 목차로 돌아가기

마치며 — 지금 어떻게 움직여야 하나

솔직히 말하면, Responses API는 아직 “이게 더 낫다”고 단정 짓기 어렵습니다. 비용 캐시 효율은 분명히 낫고, 에이전트 구조도 더 깔끔합니다. 그런데 응답 속도가 공식 권장 설정에서 Chat Completions보다 3배 느린 건 현실입니다. OpenAI가 직접 인정하고 개선 중이라고 했으니, 시간이 해결해 줄 문제일 가능성이 높습니다.

당장 행동이 필요한 건 Assistants API 사용팀입니다. 2026년 8월 26일까지 5개월 남았고, OpenAI는 자동 변환 도구를 주지 않겠다고 했습니다. Threads 수가 많을수록 백필 작업이 길어집니다. 지금 당장 어떤 Assistant 객체를 쓰는지, Thread가 몇 개나 쌓였는지 파악하는 것부터 시작하면 됩니다.

신규 프로젝트라면 Responses API로 시작하는 게 맞습니다. 지연 시간이 아쉬워도, 6개월 뒤에 다시 마이그레이션하는 공수보다 지금 올바른 방향을 잡는 게 낫습니다. 내장 도구 없이 단순 텍스트 생성만 할 거라면 Chat Completions가 당분간 여전히 현실적인 선택입니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. OpenAI 공식 – Responses vs Chat Completions (platform.openai.com)
2. OpenAI Developers Blog – Why we built the Responses API (2025.09.22)
3. OpenAI 공식 – 응답 API의 새로운 도구 및 기능 (2025.05.21)
4. OpenAI 공식 가격표 – 내장 도구 요금 (platform.openai.com)
5. OpenAI Community – Assistants API 종료 공지 (2025.08.26)
6. OpenAI Community – Stateful Responses API 속도 측정 (2025.08.26)