“Chat Completions 써도 된다”는 착각 — 비용이 다릅니다

OpenAI Responses API를 처음 접하는 분들이 가장 많이 하는 오해는 “어차피 Chat Completions도 계속 지원된다고 하니 나중에 천천히 바꾸면 된다”는 생각입니다. 하지만 공식 문서에는 이미 숫자로 된 차이가 명시되어 있습니다. OpenAI가 자체 내부 테스트(internal evals)에서 측정한 결과, GPT-5 같은 추론 모델을 사용할 때 Responses API는 Chat Completions 대비 SWE-bench 점수가 3% 높게 나왔습니다. (출처: OpenAI 공식 문서 — platform.openai.com/docs/guides/responses-vs-chat-completions)

3%라는 숫자가 작아 보일 수 있지만, 이것이 의미하는 바는 단순한 정확도 수치 이상입니다. 코드 자동화·에이전트 파이프라인에서 3%의 성공률 차이는 수백 번 실행 시 수십 건의 실패 케이스로 쌓입니다. 운영 서비스에서 이 차이는 무시할 수 없는 신뢰성 격차입니다.

더 직접적인 수치는 캐시 효율에 있습니다. OpenAI 공식 발표에 따르면 Responses API는 Chat Completions 대비 캐시 활용률이 40%~80% 향상됩니다. o4-mini 기준으로 캐시된 입력 토큰은 비캐시 대비 75% 저렴합니다. (출처: OpenAI Cookbook — developers.openai.com/cookbook/examples/responses_api/reasoning_items) 이 숫자가 실무에서 의미하는 것은, 동일한 멀티턴 에이전트 워크플로를 돌릴 때 Responses API가 실질적으로 더 낮은 청구서를 만들어낸다는 뜻입니다.

▲ 목차로 돌아가기

Assistants API 종료 일정 — 이미 카운트다운이 시작됐습니다

지금 이 순간에도 Assistants API로 서비스를 운영하고 있다면 타임라인을 명확히 인지해야 합니다. OpenAI는 2025년 8월 26일에 Assistants API를 공식 deprecated(사용 중단 예정) 상태로 선언했으며, 2026년 8월 26일을 완전 종료(sunset) 날짜로 못 박았습니다. (출처: OpenAI 공식 마이그레이션 가이드 — platform.openai.com/docs/guides/assistants/migration)

오늘(2026년 3월 17일) 기준으로 D-162입니다. 약 5개월 남짓한 시간이 있습니다. 얼핏 넉넉해 보이지만, 실제 마이그레이션에는 기존 Thread → Conversation 변환 작업, 프롬프트 설계 재조정, 테스트 및 스테이징, QA, 운영 전환이 모두 포함됩니다. 그리고 OpenAI는 기존 Thread 데이터를 Conversation으로 자동 이전하는 도구를 제공하지 않겠다고 명시했습니다.

이것이 의미하는 바는, 현재 Assistants API를 쓰고 있는 서비스는 스스로 데이터를 역직렬화해서 Conversations API 구조에 맞게 변환하는 코드를 직접 짜야 한다는 뜻입니다. 위에서 크롤링한 공식 백필(backfill) 예시 코드를 보면, 기존 Thread의 메시지를 page 단위로 불러와 content 타입별로 분기 처리한 뒤 새로운 Conversation에 items로 주입해야 합니다. 규모가 큰 서비스일수록 이 작업의 공수는 선형이 아닌 지수적으로 증가합니다.

▲ 목차로 돌아가기

store: true 기본값의 함정 — “저렴하다”는 말이 반만 맞는 이유

Responses API 공식 문서에는 캐시 효율 40~80% 향상이라는 매력적인 수치가 적혀 있습니다. 그런데 거의 모든 한국어 포스팅이 이 수치만 강조하고, 바로 뒤에 딸린 중요한 조건을 언급하지 않습니다. 바로 store: true가 기본값이라는 점입니다. (출처: platform.openai.com/docs/guides/responses-vs-chat-completions)

store: true는 Responses API가 서버 측에 대화 상태를 유지한다는 의미입니다. 이 자체는 좋은 기능입니다. 문제는 멀티턴 대화를 이어갈 때 previous_response_id를 통해 이전 응답을 연결하면, 매 호출마다 해당 대화의 전체 context가 입력 토큰으로 계산된다는 점입니다. 1회 호출 비용이 줄어드는 것이 아니라, 대화가 길어질수록 누적 입력 토큰이 쌓이는 구조입니다.

이 수치가 의미하는 것은, “Responses API가 무조건 싸다”는 단정이 잘못됐다는 점입니다. 단발성 요청이 많은 서비스라면 store: false로 명시적으로 상태 저장을 끄는 편이 비용 측면에서 유리할 수 있습니다. 반면, 장기 멀티턴 에이전트나 추론 토큰 재사용이 빈번한 워크플로에서는 캐시 절감 효과가 실제로 극대화됩니다. 본인의 워크로드 패턴을 먼저 파악하는 것이 출발점입니다.

▲ 목차로 돌아가기

ZDR 조직이라면 Responses API를 그냥 쓰면 안 됩니다

이 섹션은 국내 어떤 한국어 포스팅에서도 다루지 않은 내용입니다. OpenAI Responses API는 store: true가 기본값이라고 앞서 설명했습니다. 그런데 금융·의료·공공기관처럼 Zero Data Retention(ZDR) 정책을 적용 받는 조직은 이 설정을 그냥 쓸 수 없습니다. OpenAI는 ZDR 조직에 대해 자동으로 store: false를 강제한다고 공식 문서에서 명시했습니다. (출처: platform.openai.com/docs/guides/migrate-to-responses)

문제는 여기서 끝나지 않습니다. store: false로 설정하면 추론 모델(reasoning model)의 추론 토큰이 유지되지 않아 성능 저하가 발생할 수 있습니다. OpenAI는 이를 보완하기 위해 Encrypted Reasoning 기능을 제공합니다. 사용 방법은 다음과 같습니다.

response = openai.responses.create(
model="gpt-5",
input=[{"role": "user", "content": "..."}],
store=False,                           # ZDR 조직 필수
include=["reasoning.encrypted_content"] # 추론 암호화 포함
)
# 다음 턴에 encrypted_content를 다시 전달
next_response = openai.responses.create(
model="gpt-5",
input=[
*previous_items,
{"type": "reasoning",
"content": response.output[0].encrypted_content}  # 암호화된 추론 전달
],
store=False,
include=["reasoning.encrypted_content"]
)

이 구조가 의미하는 바는 ZDR 조직 개발자라면 마이그레이션 체크리스트에 반드시 Encrypted Reasoning 처리를 포함해야 한다는 것입니다. 이를 놓치면 store: false만 설정해 놓고 추론 컨텍스트가 매 턴 초기화되는 상황이 발생합니다. 서비스 응답 품질이 조용히, 그리고 눈에 띄지 않게 떨어지는 가장 위험한 유형의 버그입니다.

▲ 목차로 돌아가기

Assistants → Responses 구조 변환 7단계 실전 가이드

OpenAI 공식 마이그레이션 가이드(platform.openai.com/docs/guides/migrate-to-responses)에서 정리된 7단계를 실무적 관점으로 재해석합니다. 단계별로 막히는 지점과 주의 사항을 함께 정리했습니다.

5단계에서 특히 주의가 필요한 부분은 함수 스키마의 strict 기본값 변경입니다. Chat Completions에서는 함수 파라미터 유효성 검사가 느슨(non-strict)하게 기본 설정되어 있었습니다. Responses API에서는 반대로 strict가 기본값입니다. 이 말은 기존에 느슨하게 정의했던 파라미터 스키마에 additionalProperties: false와 required 배열이 완벽히 선언되지 않았다면 API 호출이 실패한다는 뜻입니다. 마이그레이션 시 함수 정의 파일을 전수 검토하지 않으면 테스트 환경에서 발견하지 못하고 운영 배포 후 조용히 실패하는 케이스가 생깁니다.

▲ 목차로 돌아가기

함수 호출·구조화 출력·멀티턴 — 코드 한 줄 바꾸면 터지는 차이 3가지

① 함수 호출 형식 — type 위치가 달라집니다

Chat Completions에서는 함수를 {"type": "function", "function": {"name": ..., "parameters": ...}} 형식으로 감쌌습니다. Responses API에서는 이 외부 래핑이 사라지고 {"type": "function", "name": ..., "parameters": ...}로 평탄화됩니다. 구조 자체는 동일하지만 JSON 경로가 달라지므로, 기존 함수 정의를 동적으로 생성하는 코드가 있다면 해당 로직을 반드시 수정해야 합니다.

② 구조화 출력 — response_format에서 text.format으로

JSON Schema를 강제하는 Structured Outputs 기능은 Chat Completions에서 response_format: { type: "json_schema", json_schema: {...} }로 지정했습니다. Responses API에서는 text: { format: { type: "json_schema", ... } }로 키 경로가 바뀝니다. 스키마 내용은 동일하므로, 키 경로만 수정하면 동일하게 동작합니다.

③ 멀티턴 대화 — 수동 배열 관리에서 ID 체이닝으로

Chat Completions에서는 대화 히스토리를 개발자가 직접 배열에 쌓아 매 호출마다 통째로 전송했습니다. Responses API에서는 previous_response_id 파라미터에 이전 응답의 ID를 넘기면 서버가 컨텍스트를 이어받습니다. 코드가 단순해지는 것은 장점이지만, 앞서 설명한 누적 토큰 비용 구조를 이해하지 못한 채 쓰면 예상보다 높은 청구서를 받게 됩니다.

▲ 목차로 돌아가기

Chat Completions는 언제까지 유효한가 — 공식 로드맵 해석

OpenAI 공식 문서는 이렇게 씁니다. “While Chat Completions remains supported, Responses is recommended for all new projects.” 그리고 한발 더 나아가 “The Responses API is a superset of the Chat Completions API”라고 명시합니다. (출처: platform.openai.com/docs/guides/responses-vs-chat-completions)

이 문장들을 교차 분석하면 중요한 신호가 읽힙니다. 소셜 미디어에서 떠도는 “2026년 말 Chat Completions도 종료된다”는 주장은 공식 문서 어디에도 날짜가 명시되어 있지 않습니다. 현재(2026년 3월 기준)까지 OpenAI가 공식적으로 종료 일정을 발표한 것은 Assistants API(2026년 8월 26일)뿐입니다. Chat Completions의 종료 여부와 시점은 아직 공식 미확인 상태입니다.

현실적인 전략은 이렇습니다. 기존 Chat Completions 기반의 단순 텍스트 생성 엔드포인트는 당장 바꾸지 않아도 서비스 중단 위험이 없습니다. 그러나 Assistants API를 쓰고 있다면 2026년 8월 26일이라는 확정된 데드라인이 있으므로 지금 당장 마이그레이션 계획을 수립해야 합니다. 그리고 새로 개발하는 에이전트·추론·멀티툴 워크플로라면 처음부터 Responses API로 설계하는 것이 미래 비용과 성능 모두를 위한 선택입니다.

▲ 목차로 돌아가기

Q&A — 실무에서 가장 많이 묻는 5가지

▲ 목차로 돌아가기

마치며 — 총평

OpenAI Responses API는 단순한 API 버전 업그레이드가 아닙니다. Assistants→Prompts, Threads→Conversations, Runs→Responses로 이어지는 구조 변환은 OpenAI가 에이전트 구축의 설계 철학 자체를 바꾼 신호입니다. “비동기 Run 폴링” 모델에서 “동기적 입출력 아이템 처리” 모델로의 전환은 코드 복잡도를 낮추는 방향이지만, 그 과정에서 함수 스키마 strict 기본값 변경, store 기본값, ZDR 처리라는 3개의 숨겨진 함정이 기다리고 있습니다.

솔직하게 말하면, 마이그레이션 자체는 어렵지 않습니다. 7단계 절차 중 4단계까지는 코드 변경량이 크지 않습니다. 위험한 것은 “어차피 8월이니까 나중에 하면 된다”는 미루기입니다. Thread 데이터 백필, 함수 스키마 전수 검토, ZDR 정책 확인이라는 세 가지 과제는 모두 일정 공수가 필요하며, 종료 1~2주 전에 시작하면 절대로 완료할 수 없습니다.

지금 당장 할 수 있는 첫 번째 행동은 단 하나입니다. 현재 운영 중인 서비스에서 /v1/assistants 또는 /v1/threads 엔드포인트 호출이 존재하는지 코드 베이스를 검색하는 것입니다. 그 결과가 0건이면 안심하고, 1건이라도 있다면 오늘 마이그레이션 티켓을 만들어야 합니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. OpenAI 공식 — Responses API vs Chat Completions
   https://platform.openai.com/docs/guides/responses-vs-chat-completions
2. OpenAI 공식 — Assistants API Migration Guide
   https://platform.openai.com/docs/guides/assistants/migration
3. OpenAI 공식 — Migrate to Responses API
   https://platform.openai.com/docs/guides/migrate-to-responses
4. OpenAI 공식 — New Tools for Building Agents (한국어)
   https://openai.com/ko-KR/index/new-tools-for-building-agents/
5. OpenAI Cookbook — Reasoning Items in Responses API
   https://developers.openai.com/cookbook/examples/responses_api/reasoning_items/
6. OpenAI 공식 Deprecations 페이지
   https://platform.openai.com/docs/deprecations