종료 일정, 정확히 언제인가요?

Deprecated와 Shutdown, 두 날짜가 다릅니다

OpenAI가 공식 문서에 올린 내용을 그대로 옮기면 이렇습니다. “As of August 26th, 2025, we’re deprecating the Assistants API, with a sunset date of August 26, 2026.” (출처: OpenAI 마이그레이션 가이드, platform.openai.com/docs/guides/migrate-to-responses) 즉, 이미 2025년 8월 26일에 Deprecated(지원 중단 예고) 선언이 났고, 실제 서비스 종료일은 정확히 1년 후인 2026년 8월 26일입니다.

Deprecated 상태에서도 당분간 API 호출 자체는 됩니다. 하지만 신규 기능 추가는 없고, 이후 발생하는 성능 저하나 장애에 대한 SLA 보장도 달라집니다. 지금 이 시점(2026년 3월)은 종료까지 약 5개월이 남은 시점입니다. “아직 시간 있다”는 생각이 드는 게 당연하지만, Thread 데이터 이전이 수동이라는 점을 생각하면 지금 시작하는 게 늦지 않습니다.

Azure OpenAI를 쓰는 경우도 동일합니다. Microsoft 공식 문서도 “Assistants API는 더 이상 사용되지 않으며 2026년 8월 26일에 사용 중지됩니다”라고 명시하고 있습니다. (출처: Microsoft Learn — Azure OpenAI Assistants 개념 문서)

▲ 목차로 돌아가기

Assistants API가 사라지는 진짜 이유

편리함의 대가로 생긴 비용 폭탄

Assistants API의 핵심 아이디어는 간단했습니다. 대화 히스토리(Thread)를 서버 측에서 자동으로 관리해주니, 개발자가 직접 컨텍스트를 쌓지 않아도 됐습니다. 문제는 이 ‘편의 기능’이 토큰 비용을 기하급수적으로 키웠다는 점입니다.

구체적으로 보면, 사용자가 문서를 업로드하고 질문을 5번 한다고 했을 때 — Assistants API는 질문마다 해당 문서 전체를 다시 처리합니다. 20페이지 PDF라면 같은 문서를 5번 토큰으로 계산한다는 뜻입니다. 실제 개발자 커뮤니티에서는 “token usage scales out of control very quickly”라는 표현이 반복됩니다. 짧은 세션이나 첨부 파일이 없다면 괜찮지만, 조금만 복잡해지면 비용을 예측하기 어렵습니다.

OpenAI가 Responses API로 방향을 튼 이유

OpenAI는 공식 문서에서 교체 이유를 이렇게 적었습니다. “Based on developer feedback from the Assistants API beta, we’ve incorporated key improvements into the Responses API to make it more flexible, faster, and easier to use.” (출처: platform.openai.com/docs/guides/migrate-to-responses) 개발자 피드백이 직접 설계 변경으로 이어진 겁니다. 실제로 polling 방식(응답 완료 여부를 반복 확인하는 방식)을 버리고 스트리밍을 기본으로 전환한 것도 이 맥락입니다.

▲ 목차로 돌아가기

Responses API, 더 편해지는 게 맞긴 한데

개발자 작업이 줄어드는 부분과 늘어나는 부분이 동시에 있습니다

Responses API의 가장 큰 장점은 빌트인 툴입니다. 웹 검색, 파일 검색, 컴퓨터 사용, 코드 인터프리터, 원격 MCP 서버 연결까지 — 외부 함수 없이 API 한 번 호출에 모두 처리됩니다. (출처: platform.openai.com/docs/guides/migrate-to-responses) 기존 Chat Completions에서는 웹 검색 하나를 붙이려면 직접 함수를 짜야 했습니다.

반면, 대화 상태 관리는 다시 개발자 쪽으로 돌아옵니다. Assistants API가 Thread를 서버에서 자동으로 유지했다면, Responses API에서는 previous_response_id를 코드에서 직접 넘기거나, Conversations API를 별도로 써야 합니다. “상태 관리의 번거로움을 없애준다”는 게 Assistants API의 셀링포인트였는데, 그게 다시 돌아온 셈입니다.

구조적 변화 한눈에 보기

(출처: OpenAI Assistants API Migration Guide, platform.openai.com/platform/assistants/migration)

▲ 목차로 돌아가기

Thread 마이그레이션, 자동 도구가 없습니다

공식 가이드가 직접 말한 내용입니다

“Responses API로 넘어가면 기존 대화 데이터도 자동으로 옮겨주겠지”라는 기대가 자연스러운데, 공식 가이드에는 이렇게 나옵니다. “We will not provide an automated tool for migrating Threads to Conversations.” (출처: platform.openai.com/platform/assistants/migration) OpenAI가 Thread를 Conversations으로 자동 이전하는 도구를 제공하지 않겠다고 못 박은 겁니다.

대신 권고 사항은 “신규 유저 대화는 Conversations로 받고, 기존 Thread는 필요한 것만 수동으로 백필(backfill)하라”입니다. 공식 문서에 Python 예제 코드도 함께 나오는데, 기존 Thread에서 메시지를 순서대로 불러와 Items 형식으로 변환한 뒤 Conversations를 만드는 방식입니다. 규모가 큰 서비스라면 이 작업이 결코 간단하지 않습니다.

Prompt 객체는 대시보드에서만 만들 수 있습니다

또 하나 주목할 변화가 있습니다. Assistants API에서는 Assistant 객체를 코드로 직접 생성할 수 있었는데, Responses API의 대응 개념인 Prompt 객체는 OpenAI 대시보드에서만 만들 수 있습니다. 이 말은 코드 저장소에서 Prompt 설정을 버전 관리하려면 대시보드에서 Export한 스펙을 소스 컨트롤에 따로 저장해야 한다는 뜻입니다. CI/CD 파이프라인에서 Assistant를 자동 생성하던 팀이라면 워크플로우를 처음부터 다시 설계해야 합니다.

▲ 목차로 돌아가기

비용 구조가 바뀝니다 — 줄어드는 것과 늘어나는 것

캐시 활용이 40~80% 개선된다는 수치의 의미

OpenAI가 공식 마이그레이션 가이드에 올린 수치가 있습니다. “Lower costs: Results in lower costs due to improved cache utilization (40% to 80% improvement when compared to Chat Completions in internal tests).” (출처: platform.openai.com/docs/guides/migrate-to-responses) 같은 프롬프트를 반복 호출할 때 캐시 히트율이 Chat Completions 대비 40~80% 높아진다는 내부 테스트 결과입니다. 멀티턴 대화처럼 앞부분 컨텍스트가 반복되는 구조에서 실질적 절약이 생깁니다.

반면 File Search 스토리지 비용은 그대로입니다. GB당 하루 $0.10, 처음 1GB는 무료입니다. (출처: OpenAI API Pricing, openai.com/api/pricing/) Code Interpreter도 세션당 $0.03로 동일하게 유지됩니다. 결국 캐시 개선 효과는 토큰 레벨에서 나고, 툴 사용 비용은 크게 달라지지 않습니다.

(출처: OpenAI 공식 마이그레이션 가이드 및 API Pricing 페이지, 2026.03.28 기준)

오디오 지원이 “Coming soon” 상태라는 점도 체크해둘 필요가 있습니다. 현재 Responses API 공식 기능 비교표에 오디오 컬럼은 있지만 “Coming soon”으로 표기되어 있습니다. (출처: platform.openai.com/docs/guides/migrate-to-responses) 음성 기반 기능을 Assistants API에서 쓰던 팀이라면, 전환 시점을 조율해야 할 수 있습니다.

▲ 목차로 돌아가기

마이그레이션 순서, 공식 가이드 요약

7단계를 굳이 한 번에 안 해도 됩니다

OpenAI 공식 마이그레이션 가이드에는 7단계가 나옵니다. 핵심만 짚으면, 단계 1은 엔드포인트를 /v1/chat/completions에서 /v1/responses로 교체하는 작업입니다. 함수 호출이나 멀티모달 입력을 안 쓴다면 이것만으로 거의 끝납니다.

단계가 복잡해지는 지점은 구조화 출력(Structured Outputs)과 함수 정의입니다. Structured Outputs의 경우 response_format 파라미터가 text.format으로 바뀌고, 함수 스키마 구조도 외부 태깅 방식에서 내부 태깅 방식으로 달라집니다. 또 Responses API에서는 함수가 기본적으로 strict 모드여서, 기존에 느슨하게 작성된 파라미터 정의가 오류를 낼 수 있습니다.

가이드는 단계별로 점진적 전환이 가능하다고 설명합니다. Responses API가 Chat Completions API의 상위 집합(superset)이기 때문에, 일부 사용자 흐름만 먼저 Responses로 올리고 나머지는 준비되는 대로 이전하는 방식이 가능합니다. 8월까지 전부 한 번에 바꾸려다 장애를 낼 필요가 없습니다.

▲ 목차로 돌아가기

자주 나오는 질문 5가지

▲ 목차로 돌아가기

마치며

솔직히 말하면, Responses API 전환이 “그냥 API 이름만 바뀌는 것”이라고 가볍게 봤다면 조금 다시 생각해볼 필요가 있습니다. 빌트인 툴과 스트리밍 지원은 분명히 좋아졌는데, Thread 수동 이전이라는 숙제가 남아 있고, Prompt 객체를 코드가 아닌 대시보드에서만 만들 수 있다는 제약도 파이프라인 설계에 영향을 줍니다.

캐시 개선으로 실질적인 비용 절감 효과(40~80% 내부 테스트 기준)가 있다는 건 마이그레이션의 확실한 이유가 됩니다. 다만 이 수치가 모든 워크로드에 동일하게 적용되지는 않으므로, 실제 호출 패턴을 보고 판단하는 게 맞습니다.

종료까지 5개월 정도 남았습니다. Thread 데이터 정리, Prompt 재설계, 함수 스키마 수정 — 작업 목록을 지금 만들어두는 것과 7월에 급하게 시작하는 것은 결과가 다릅니다.

본 포스팅 참고 자료

1. OpenAI Assistants API Migration Guide — platform.openai.com/platform/assistants/migration
2. OpenAI — Migrate to Responses API 공식 가이드 — platform.openai.com/docs/guides/migrate-to-responses
3. OpenAI API Pricing 공식 페이지 — openai.com/api/pricing
4. Microsoft Learn — Azure OpenAI Assistants 개념 (Deprecated 공지 포함) — learn.microsoft.com