종료일 D-150일
OpenAI 공식 확정
OpenAI Assistants API 종료
5개월 안에 이걸 바꿔야 합니다
OpenAI가 Assistants API의 공식 종료일을 2026년 8월 26일로 확정했습니다. Responses API로 전환하는 건데, 막상 공식 마이그레이션 문서를 읽어보니 생각보다 복잡한 지점이 있었습니다. 특히 “Threads 데이터 자동 이전”은 처음부터 지원하지 않는다고 공식 문서에 나와 있습니다. 지금 Assistants API를 쓰고 있다면, 이 글이 바로 필요한 정보입니다.
종료 일정과 지금 당장 확인할 것
OpenAI는 2025년 8월 26일, Assistants API가 공식적으로 deprecated되었다는 공지를 발송했습니다. 그로부터 정확히 1년 뒤인 2026년 8월 26일에 완전 종료됩니다. 지금부터 5개월이 채 남지 않은 시점입니다.
OpenAI 공식 deprecations 문서에 이렇게 나옵니다:
“On August 26th, 2025, we notified developers using the Assistants API of its deprecation and removal from the API one year later, on August 26, 2026.”
(출처: OpenAI Platform Deprecations, platform.openai.com/docs/deprecations)
종료 이후에는 openai.beta.threads, openai.beta.assistants 등 beta 엔드포인트 전체가 응답을 중단합니다. 대체 API는 Responses API + Conversations API 조합입니다.
지금 가장 먼저 할 일은 코드베이스에서 openai.beta가 포함된 호출 위치를 전수 조사하는 것입니다. 규모가 클수록 마이그레이션 기간도 길어지므로, 지금 바로 파악해두는 게 맞습니다.
Responses API가 뭐가 다른가 — 구조부터 달라집니다
많은 개발자들이 Responses API를 “그냥 Assistants API의 이름 바꾼 버전”으로 생각합니다. 막상 공식 마이그레이션 문서를 읽어보면 그렇지 않습니다. 구조 자체가 바뀌었습니다.
OpenAI 공식 migration guide에 나온 변경 대응표입니다:
| 기존 (Assistants API) | 신규 (Responses API) | 변경 이유 |
|---|---|---|
| Assistants | Prompts | 버전 관리·롤백 가능 |
| Threads | Conversations | 메시지 외 도구 호출·출력도 저장 |
| Runs | Responses | 폴링 루프 없이 직접 output 반환 |
| Run steps | Items | 메시지·도구 호출·출력 통합 |
가장 체감이 큰 변화는 Run의 폴링 루프 제거입니다. 기존에는 run.status가 “completed”가 될 때까지 직접 루프를 돌려야 했는데, Responses API는 openai.responses.create() 한 번으로 output을 바로 돌려받습니다. 코드가 눈에 띄게 단순해집니다.
또한 Assistants에서는 대시보드 내에서 생성했던 Assistant 오브젝트가, Responses API에서는 Prompts라는 개념으로 바뀌고 대시보드에서만 생성 가능합니다. API로 동적으로 만들던 패턴이 있다면 그 부분을 먼저 확인해야 합니다.
속도가 빨라진다는데, 직접 측정하면 다른 이야기가 나옵니다
OpenAI 공식 migrate-to-responses 문서는 이렇게 씁니다: “캐시 활용률 40~80% 향상, SWE-bench에서 3% 성능 개선”. 그런데 실제 OpenAI 공식 커뮤니티에 올라온 측정 데이터를 보면 그렇지 않은 경우가 있습니다.
💡 공식 발표와 실측값을 같이 놓고 보면 조건이 붙습니다
개발자가 Azure OpenAI 환경에서 동일 프롬프트·동일 추론 레벨로 20회씩 반복 측정한 결과입니다:
| 조건 | Responses API (평균) | Chat Completions (평균) |
|---|---|---|
| store=true | 4.268s | 1.354s |
| store=false | 2.901s | 1.257s |
(출처: OpenAI Community Forum, Azure OpenAI 환경 실측, 2025.09)
store=true 상태에서 평균 지연이 3.15배 높게 나왔습니다. Chat Completions에서는 최대 지연이 2.4초였는데, Responses API는 최대 21.7초까지 튀었습니다.
OpenAI 엔지니어링팀도 커뮤니티에서 이 문제를 인정하며 이렇게 답했습니다: “previous_response_id를 사용할 때 데이터베이스 최적화 작업 중. 가장 빠른 응답 속도가 필요하면 store: false를 권장한다.” (출처: OpenAI Community, Steve Coffey, OpenAI API Eng팀, 2025.09.03)
정리하면, 공식 문서가 말하는 “속도 향상”은 캐시 히트율 기준이고, 실제 응답 지연은 설정 조건에 따라 오히려 더 길어질 수 있습니다. store 옵션을 어떻게 쓸지를 설계 단계에서 결정해야 합니다.
Thread 데이터 이전, 자동으로 안 됩니다
가장 많이 오해하는 부분입니다. “OpenAI가 Thread를 Conversation으로 알아서 옮겨주지 않을까”라고 생각하기 쉬운데, 공식 마이그레이션 문서에 이렇게 나옵니다:
“We will not provide an automated tool for migrating Threads to Conversations. Instead, we recommend migrating new user threads onto conversations and backfilling old ones as necessary.”
(출처: OpenAI Platform, Assistants Migration Guide, platform.openai.com/platform/assistants/migration)
자동화 도구는 없고, 직접 backfill 코드를 작성해야 합니다. OpenAI가 제공하는 예시 코드는 openai.beta.threads.messages.list()로 기존 Thread의 메시지를 순서대로 불러온 뒤, 형식을 변환해 새 Conversation에 담는 방식입니다.
대화 기록이 많은 서비스일수록 이 작업이 오래 걸립니다. Thread 내 메시지 수가 수천 개라면 API 레이트 리밋 안에서 분산 처리 로직도 필요합니다. “종료 직전에 처리하면 되겠지”라고 미뤘다가 데이터 손실이 생길 수 있는 구간입니다.
권장 순서는 이렇습니다. 먼저 신규 사용자 세션부터 Conversations API로 받기 시작하고, 그 이후 여유 있게 구 Thread 데이터를 backfill합니다. 8월 26일 이후에는 openai.beta.threads.messages.list() 자체가 호출 불가가 되므로, 그 전에 반드시 기존 Thread 데이터 추출을 완료해야 합니다.
단계별 전환 순서 — 공식 문서 기준 정리
OpenAI가 공식 가이드에서 제시하는 전환 단계를 실무 관점으로 재정리했습니다.
기존 Assistant를 Prompt로 전환
대시보드에서 기존 Assistant 오브젝트를 열고 “Create prompt” 버튼을 눌러 Prompt로 변환합니다. API로 동적 생성 중이었다면 대시보드 생성 방식으로 변경해야 합니다.
신규 대화를 Conversations API로 전환
openai.beta.threads.create()를 openai.conversations.create()로 교체합니다. 이후 Responses를 생성할 때 conversation ID를 넘기면 됩니다.
기존 Thread 데이터 backfill
메시지를 order="asc"로 순서대로 불러와 Items 형식으로 변환 후 openai.conversations.create(items=...)로 새 Conversation을 생성합니다. 8월 26일 이전에 완료 필수입니다.
Function calling 형식 업데이트
Responses API에서는 함수 정의 방식이 내부 태그 방식으로 바뀌고, 기본값이 strict: true입니다. Chat Completions에서는 strict가 기본 false였던 것과 다릅니다. 함수 정의 부분을 전수 확인해야 합니다.
Structured Outputs 형식 변경
response_format이 text.format으로 이동합니다. JSON Schema를 사용 중이라면 이 부분도 수정 대상입니다.
ZDR 조직이라면 한 가지 더 확인해야 합니다
Zero Data Retention(ZDR) 정책을 적용 중인 조직은 Responses API의 Stateful 기능 사용이 제한됩니다. ZDR 환경에서는 OpenAI가 store=false를 자동 강제합니다.
💡 공식 문서와 요금 정책을 교차해서 보면 보이는 지점
ZDR 환경에서도 추론 이점은 챙길 수 있습니다. store: false에 include: ["reasoning.encrypted_content"]를 함께 넣으면, 추론 토큰이 암호화된 상태로 반환됩니다. 이 암호화 결과물은 다음 요청에 그대로 넣으면 복호화 후 사용되고 즉시 폐기됩니다. 디스크에는 아무것도 저장되지 않습니다. ZDR 조건을 지키면서 다중 턴 추론의 일관성을 유지하는 유일한 방법입니다.
속도 측면에서도 ZDR 환경은 오히려 유리한 면이 있습니다. store=false로 강제되는 만큼, 앞서 본 “store=true 시 지연 3.15배” 문제를 처음부터 겪지 않습니다. 실측값 기준 Chat Completions와의 지연 차이가 store=false 상태에서는 평균 약 1.6배 수준으로 줄어듭니다.
ZDR가 아닌 일반 조직도 대화 기록을 서버에 저장할 필요가 없다면 store: false를 명시적으로 설정하는 것이 응답 속도에 도움이 됩니다. 기본값이 store: true이므로, 아무것도 안 하면 모든 대화가 OpenAI 서버에 저장됩니다.
Q&A
마치며
OpenAI Assistants API 종료는 단순한 “API 이름 변경”이 아닙니다. Threads 자동 이전 도구가 없고, 구조 자체가 바뀌며, 속도 특성도 설정에 따라 달라집니다. 5개월이 넉넉하게 느껴질 수 있지만, 대화 기록 backfill + 함수 정의 형식 변경 + ZDR 조건 확인까지 하다 보면 생각보다 빠듯합니다.
개인적으로 가장 먼저 챙겨야 할 것은 Thread 데이터 추출입니다. 8월 26일 이후에는 openai.beta.threads.messages.list()가 완전히 막히기 때문에, 그 전에 기존 대화 기록을 추출해두지 않으면 영구 손실입니다. 이 부분이 가장 되돌릴 수 없는 리스크입니다.
Responses API로 넘어오면 Code Interpreter, MCP 서버 연동, Deep Research 같은 새 도구들을 바로 붙일 수 있습니다. 전환 부담이 있는 만큼, 이 기회에 에이전트 아키텍처 자체를 한 번 다듬어 보는 것도 방법입니다.
📎 본 포스팅 참고 자료
- OpenAI Platform — Deprecation History (platform.openai.com/docs/deprecations)
- OpenAI — Assistants to Conversations Migration Guide (platform.openai.com/platform/assistants/migration)
- OpenAI — Migrate to Responses API Guide (platform.openai.com/docs/guides/migrate-to-responses)
- OpenAI Community — Stateful Responses API Much Slower Than Chat Completions (2025.08~09)
- OpenAI Community — Assistants API → Responses API: this is not a 1:1 migration (2026.01)
본 포스팅은 2026년 3월 29일 기준으로 작성되었습니다. OpenAI의 서비스 정책·API 사양·요금·종료 일정은 OpenAI의 내부 결정에 따라 변경될 수 있습니다. 최신 정보는 반드시 OpenAI 공식 문서에서 직접 확인하세요. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다.
댓글 남기기