OpenAI Responses API
Assistants API 폐지 D-158
OpenAI Responses API, 전환하면 비용 아낀다고요?
OpenAI가 공식 블로그에 “캐시 효율 40~80% 향상”을 써놨습니다. 근데 실제로 전환한 개발자 중 일부는 캐시율이 0%가 됐다고 포럼에 올렸습니다. 2026년 8월 26일, Assistants API 종료가 5개월 앞으로 다가온 지금, 전환 전에 반드시 알아야 할 세 가지 조건을 공식 문서 기준으로 짚어봤습니다.
Responses API가 뭔지, 한 줄로 정리하면
Chat Completions와 Assistants, 두 API를 한 곳으로 합친 것
OpenAI는 2025년 3월 /v1/responses 엔드포인트를 공식 출시했습니다. Chat Completions API는 2023년에 만들어진 텍스트 기반 단순 응답 구조였고, Assistants API는 2023년 말 출시된 에이전틱 인터페이스였는데, 둘 다 쓰다 보니 개발자들 사이에서 불만이 쌓였습니다. Chat Completions는 툴 루프를 직접 짜야 했고, Assistants는 설계가 복잡하고 마이그레이션이 어려워 대중화에 실패했습니다.
Responses API는 이 둘을 합쳐 “채팅처럼 쉽고 에이전트처럼 강력하게” 만든 API입니다. 한 번의 API 호출에서 웹 검색, 파일 검색, 코드 실행, 컴퓨터 조작, 원격 MCP 서버 연동까지 처리할 수 있습니다. (출처: OpenAI 공식 문서 responses-vs-chat-completions, 2026.03 기준)
결론부터 말하면, OpenAI가 앞으로 기능 개발을 집중할 API는 Responses API입니다. Chat Completions은 유지되지만 새 기능은 여기에 붙지 않습니다.
Chat Completions과 정확히 무엇이 다른가
응답 구조, 상태 저장 방식, 추론 메모리가 모두 바뀌었습니다
Chat Completions는 응답 결과를 choices[0].message.content로 꺼냈습니다. Responses API에서는 response.output_text로 바뀌었고, 응답 객체 자체가 메시지 외에 툴 호출, 중간 추론 단계, 함수 출력 등을 모두 포함하는 “아이템 배열” 형태입니다. 아이템마다 타입이 명확해서 무엇이 먼저 실행됐는지 순서대로 추적할 수 있습니다.
가장 중요한 차이는 추론 상태(Reasoning State)의 연속성입니다. Chat Completions는 매 요청마다 추론 상태가 초기화됩니다. OpenAI 공식 블로그의 표현을 빌리면, “매번 방을 나갈 때 단서를 잊어버리는 탐정”과 같습니다. Responses API는 previous_response_id를 전달하거나 store: true를 쓰면 이 추론 상태가 다음 호출로 이어집니다. GPT-5 기준으로 추론이 이어지면 TAUBench에서 5% 향상이 실측됐습니다. (출처: OpenAI 개발자 블로그 responses-api, 2025.09.22)
| 항목 | Chat Completions | Responses API |
|---|---|---|
| 응답 추출 | choices[0].message.content |
response.output_text |
| 추론 상태 유지 | ❌ 매 요청마다 리셋 | ✅ previous_response_id로 연속 |
| 데이터 기본 저장 | 신규 계정 기준 저장 | 30일 저장 (기본값) |
| 내장 툴 | ❌ 직접 구현 | ✅ 웹검색·파일검색·코드실행·MCP 내장 |
| 함수 Strict 기본값 | non-strict (기본) | strict (기본값 변경) |
| Structured Outputs 파라미터 | response_format |
text.format |
비용이 줄어든다는 말, 이 조건에서만 맞습니다
캐시 향상 40~80%는 프롬프트 구조가 일정할 때의 이야기입니다
💡 공식 발표 수치와 실제 포럼 사례를 나란히 놓고 보니 캐시 효율이 어떤 조건에서 무너지는지가 보였습니다.
OpenAI 공식 쿡북 문서에는 이렇게 적혀 있습니다. “Chat Completions API에서 Responses API로 전환하면 캐시 활용률이 40%에서 80%로 높아졌다.” (출처: OpenAI Cookbook — Better performance from reasoning models using the Responses API, 2025.05.11) 비용이 줄어드는 원리가 여기 있습니다. 캐시가 되면 입력 토큰 비용이 내려가고, 추론 상태가 이어지니 같은 컨텍스트를 매번 다시 넣는 비용도 줍니다.
막상 해보면 다릅니다. 2026년 1월 OpenAI 개발자 포럼에 이런 글이 올라왔습니다. Responses API로 전환 후 캐시율이 40%에서 0%로 떨어졌다는 내용입니다. 원인은 프롬프트 안에 오늘 날짜와 시각을 삽입했기 때문이었습니다. 매 요청마다 시각이 바뀌니 캐시 키가 완전히 달라진 것입니다. (출처: OpenAI Community Forum — Caching rate drop after switching to Responses API, 2026.01.03~11) 요점은 단순합니다. 프롬프트 앞부분에 동적인 값(시각, 난수 등)이 들어가는 순간 캐시는 무력화됩니다.
⚠️ 캐시 효율 떨어지는 패턴 체크리스트
- 시스템 프롬프트에 현재 시각(hh:mm:ss)을 직접 삽입하는 경우
- 요청마다 랜덤 ID, UUID를 프롬프트 앞에 붙이는 경우
- 사용자 ID나 세션 토큰을 시스템 메시지 첫 줄에 넣는 경우
- 매 요청마다 날짜 포맷이 달라지는 경우 (“2026년 3월 21일” vs “2026-03-21”)
캐시가 작동하려면 입력 토큰의 앞부분 1,024 토큰 이상이 동일해야 합니다. 프롬프트 구조를 고정하고 동적 값은 뒷부분에 배치하거나, 날짜는 “2026년 3월 21일 오후”처럼 시간 단위를 낮춰서 변동폭을 줄이는 방식으로 캐시를 살릴 수 있습니다.
ZDR 조직이라면 store:true가 통하지 않습니다
데이터 저장 기본값이 바뀐 것, 기업 고객에겐 함정이 됩니다
💡 OpenAI 데이터 관리 정책 문서와 Responses API 스펙 문서를 나란히 보니, 기업용 플랜 사용자가 간과하기 쉬운 조건이 여기에 있었습니다.
Responses API의 기본값은 store: true입니다. 요청 결과가 OpenAI 서버에 최소 30일 저장된다는 뜻입니다. Chat Completions API는 명시적으로 저장 요청을 해야 했는데, Responses API는 반대입니다. 저장하지 않으려면 store: false를 직접 명시해야 합니다. (출처: OpenAI Data controls in the OpenAI platform — /v1/responses 항목, 2026.03 기준)
더 중요한 건 Zero Data Retention(ZDR) 조직에서 일어나는 일입니다. ZDR이 활성화된 조직에서는 요청에 store: true를 명시하더라도 OpenAI가 강제로 store: false로 처리합니다. 공식 문서에 딱 이렇게 나옵니다. “When Zero Data Retention is enabled for an organization, the store parameter will always be treated as false, even if the request attempts to set the value to true.” 이 말은 ZDR 조직에서 Responses API의 멀티턴 추론 연속성이 작동하지 않을 수 있다는 뜻입니다.
ZDR 조직이면서도 추론 연속성이 필요하다면, 공식 문서에 우회책이 있습니다. store: false와 함께 include: ["reasoning.encrypted_content"]를 설정하면 추론 토큰이 암호화된 채로 반환됩니다. 이걸 다음 요청에 다시 넘기면 OpenAI가 메모리에서만 복호화해 처리하고 디스크에는 저장하지 않습니다. 데이터를 보관하지 않으면서도 추론 흐름을 이어갈 수 있습니다. 단, Background 모드는 ZDR과 호환되지 않습니다.
📋 ZDR 환경에서 쓸 수 없는 Responses API 기능
- Background 모드 — 폴링용 응답 데이터를 10분간 임시 저장하므로 ZDR 비호환 (출처: OpenAI Data controls 문서)
- OpenAI-hosted Shell Container — 데이터 저장이 필요한 구조여서 ZDR 환경에서 사용 불가
- Extended Prompt Caching — GPU 로컬 스토리지에 K/V 텐서를 저장해야 하므로 ZDR 비호환
Assistants API → Responses API 마이그레이션 실전 순서
Thread를 Conversation으로 자동 이전하는 도구는 없습니다
OpenAI 공식 마이그레이션 가이드에는 이렇게 적혀 있습니다. “We will not provide an automated tool for migrating Threads to Conversations.” (출처: OpenAI 공식 Assistants Migration 가이드, 2026.03 기준) 기존 Thread를 Conversation으로 일괄 변환해주는 도구가 없다는 뜻입니다. 예전 대화 기록은 수동으로 또는 직접 스크립트를 짜서 백필해야 합니다.
개념 매핑도 바뀌었습니다. 기존 Assistants API의 Assistants는 Prompts로, Threads는 Conversations로, Runs는 Responses로, Run steps는 Items로 대응됩니다. 특히 Prompts는 API로는 생성할 수 없고 대시보드에서만 만들 수 있습니다. 코드로 어시스턴트를 프로비저닝하던 로직이 있다면 이 부분을 수작업으로 바꿔야 합니다.
대시보드에서 기존 Assistant를 Prompt로 전환 — 각 Assistant 페이지에서 ‘Create prompt’ 버튼 클릭. instructions + tool 묶음을 버전 관리 가능한 Prompt 객체로 분리합니다.
신규 사용자 대화는 Conversations API로 전환 — 새 세션부터 openai.conversations.create()를 사용하고, 기존 Thread는 백필 스크립트로 처리합니다.
폴링 루프 로직 제거 — Assistants API는 Run이 queued → in_progress → completed를 돌면서 폴링이 필요했습니다. Responses API는 동기 방식이 기본이므로 이 루프를 제거합니다.
함수 정의 형식 수정 — Chat Completions 형식은 externally-tagged polymorphism이었고 strict가 기본 off였습니다. Responses API는 internally-tagged이고 strict가 기본 on입니다. 함수 스키마에 additionalProperties: false와 required 배열이 완전해야 합니다.
Structured Outputs 파라미터 변경 — response_format 대신 text.format으로 바꿉니다. 스키마 구조는 동일합니다.
마감 기한은 2026년 8월 26일입니다. 2025년 8월 26일에 deprecated 선언이 났으니, 정확히 1년 뒤에 종료됩니다. 오늘(2026.03.21) 기준으로 약 5개월이 남아 있습니다.
Chat Completions는 사라지지 않습니다 — 마이그레이션이 ‘선택’인 이유
Assistants API 폐지와 Chat Completions 유지는 완전히 다른 이야기입니다
💡 “Assistants API 폐지”와 “Chat Completions 폐지”를 같은 맥락으로 읽는 개발자가 많습니다. 공식 문서를 보면 이 둘은 완전히 다른 이야기입니다.
OpenAI 공식 문서에는 이 문장이 있습니다. “While Chat Completions remains supported, Responses is recommended for all new projects.” Chat Completions는 계속 지원됩니다. Responses API가 Chat Completions의 상위 집합(superset)이라는 표현도 쓰면서, 두 API를 병행 운용하는 것도 선택지로 제시합니다. 에이전트 기능이 필요한 플로우만 Responses로 옮기고, 나머지는 Chat Completions를 유지해도 됩니다. (출처: OpenAI responses-vs-chat-completions 공식 문서, 2026.03 기준)
반면 Assistants API는 2026년 8월 26일 종료 후 API 자체가 닫힙니다. 이미 deprecated 상태이며 새 모델 연결은 기한 전까지만 유지됩니다. 둘을 혼동해 “ChatGPT API 자체가 없어진다”고 오해하는 사례가 있는데, 그렇지 않습니다. 없어지는 건 beta.assistants·beta.threads·beta.runs 경로뿐입니다.
2026년 2월 10일 VentureBeat가 보도한 Responses API 업데이트에서는 Server-side Compaction, Hosted Shell Container, Skills 표준 지원이 추가됐습니다. 에이전트가 5백만 토큰 넘는 세션을 정확도 저하 없이 처리한 사례가 나왔고(e-커머스 Triple Whale의 ‘Moby’ 에이전트 기준), 엔터프라이즈 AI 검색 스타트업 Glean은 Skills 프레임워크 적용 후 툴 정확도가 73%에서 85%로 올랐다고 밝혔습니다. (출처: VentureBeat, 2026.02.10) 단순 텍스트 생성이 아닌 장시간 자율 에이전트가 목적이라면 Responses API가 유리한 쪽은 맞습니다.
자주 나오는 질문 5가지
마치며
Responses API는 분명히 잘 만들어진 API입니다. 추론 상태 유지, 내장 툴, 간결한 응답 구조, 캐시 효율까지 공식 수치를 보면 Chat Completions 대비 여러 면에서 앞서 있습니다. 하지만 “전환하면 비용이 줄어든다”는 말은 전제 조건이 붙습니다. 프롬프트 구조가 고정되어 있어야 하고, ZDR 조직이 아니어야 하며, store: true의 의미(데이터 30일 저장)를 인식하고 있어야 합니다.
Assistants API 사용 중이라면 2026년 8월 26일 종료 전에 마이그레이션해야 하고, Chat Completions만 쓰고 있다면 급히 전환할 이유는 없습니다. 에이전트 기능이 필요한 프로젝트를 새로 시작한다면 처음부터 Responses API로 짜는 게 맞습니다. 기존 코드가 있다면 점진적 전환이 안전하고, Thread 이전 자동화 도구가 없다는 점을 감안해 일정을 넉넉히 잡는 게 현실적입니다.
개인적으로는 캐시 드롭 이슈가 생각보다 자주 언급된다는 점이 인상적이었습니다. “전환만 하면 자동으로 비용이 내려간다”는 기대와 “프롬프트 구조를 손대야 캐시가 산다”는 현실 사이에서, 첫 번째로 해야 할 일은 현재 프롬프트에 동적 값이 어디에 얼마나 섞여 있는지 확인하는 것입니다.
본 포스팅 참고 자료
- OpenAI 공식 문서 — Responses vs Chat Completions
- OpenAI 개발자 블로그 — Why we built the Responses API (2025.09.22)
- OpenAI 공식 문서 — Data controls in the OpenAI platform
- OpenAI 공식 문서 — Assistants to Responses API Migration Guide
- OpenAI Cookbook — Better performance from reasoning models using the Responses API (2025.05.11)
- OpenAI Developer Community — Caching rate drop after switching to Responses API (2026.01)
- VentureBeat — OpenAI upgrades its Responses API (2026.02.10)
본 포스팅은 2026년 3월 21일 기준으로 작성된 정보를 담고 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. OpenAI Responses API, Assistants API 관련 최신 내용은 platform.openai.com/docs에서 직접 확인하시기 바랍니다.
댓글 남기기