Assistants API 종료,
코드 그대로면 8월에 멈춥니다
Thread 자동 이전 없고, 동적 Assistant 생성도 Responses API에선 안 됩니다.
지금 당장 확인해야 할 것부터 정리했습니다.
대체: Responses API
공식 마이그레이션 가이드 확인
지금 쓰는 Assistants API가 정확히 언제 꺼지나요
결론부터 말씀드리면, 2026년 8월 26일 자정(UTC)에 모든 /v1/assistants, /v1/threads 엔드포인트가 응답을 멈춥니다. 그날 이후로 어떤 요청을 보내도 오류만 돌아옵니다. OpenAI는 2025년 8월 26일 공식 Deprecations 문서에 이 날짜를 고정했고, 이후 변경 공지가 없습니다.
오늘(2026년 3월 26일) 기준으로 남은 시간은 153일입니다. 길어 보여도 기존 Threads 데이터를 수동으로 옮기고, Runs 폴링 루프를 걷어내고, 프로덕션 트래픽을 단계적으로 전환하는 일정을 잡으면 빠듯합니다.
💡 공식 Deprecations 문서와 커뮤니티 공지를 함께 놓고 보니, 이 종료 일정이 2025년 8월 발표 이후 단 한 번도 수정된 적 없습니다. 마감일이 미뤄질 거라는 기대는 근거가 없습니다.
(출처: OpenAI Deprecations 공식 문서, developers.openai.com/api/docs/deprecations/)
Thread → Conversation 자동 이전이 없다는 게 실제로 무슨 의미인가요
많은 분들이 “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 Assistants Migration Guide, developers.openai.com/api/docs/assistants/migration/)
자동 이전 도구는 없습니다. 기존 Thread에 쌓인 대화 기록을 보존하려면 직접 Thread 메시지를 읽어서 Conversation 객체에 items 형태로 심어야 합니다.
Thread 히스토리를 잃지 않으려면 지금 해야 할 일
Assistants API가 살아있는 지금 Thread 메시지를 페이지 단위로 내려받아서 별도 저장소(DB 또는 S3)에 백업하는 것이 우선입니다. 8월 26일 이후로는 읽을 수도 없습니다. OpenAI가 공식 가이드에 제공한 백필(backfill) 코드 패턴을 그대로 가져다 쓸 수 있습니다. thread의 메시지를 순서대로 불러온 뒤, 역할(role)에 따라 input_text/output_text 타입으로 변환해 Conversation items에 넣는 방식입니다.
💡 대화 이력이 없어도 되는 단발성 챗봇이라면 이 단계를 건너뛸 수 있습니다. 반면 사용자별 맞춤 히스토리가 핵심인 서비스라면 데이터 이전 계획이 전환 작업의 절반 이상을 차지합니다.
동적으로 Assistant 만드는 코드, Responses API에선 그대로 못 씁니다
Assistants API를 쓰는 팀 중 상당수가 openai.beta.assistants.create()를 코드에서 직접 호출해 사용자별·태스크별 Assistant를 동적으로 생성합니다. 이 패턴이 Responses API에서는 작동하지 않습니다.
Assistants를 대체하는 개념이 Prompts인데, Prompts는 대시보드에서만 생성할 수 있습니다. API를 통한 프로그래매틱 생성 메서드가 없습니다. 공식 마이그레이션 가이드에도 이렇게 나옵니다: “Assistants were persistent API objects… Their replacement, prompts, can only be created in the dashboard.”
런타임에
assistants.create({ instructions: ... })를 호출해 사용자 요청마다 새 Assistant 객체를 만드는 구조는 마이그레이션 후 아키텍처를 통째로 바꿔야 합니다.
대안으로 쓸 수 있는 패턴 3가지
| 패턴 | 방식 | 적합한 경우 |
|---|---|---|
| A. 대시보드 Prompt 고정 | 미리 만든 Prompt ID를 환경변수로 참조 | 지시사항이 공통이거나 몇 가지로 고정된 경우 |
| B. instructions 런타임 주입 | responses.create({ instructions: ... })에 동적으로 지시문 전달 |
사용자별·세션별 지시사항이 달라야 하는 경우 |
| C. 클라이언트 관리 상태 | 서버 상태 없이 매 요청마다 컨텍스트 배열 직접 관리 | Thread 의존도 낮고 Zero Data Retention 필요한 경우 |
동적 지시사항이 필요한 경우 B 패턴이 사실상 유일한 선택지입니다. Prompt 객체 없이도 instructions 파라미터 하나로 세션 단위 행동을 제어할 수 있습니다.
Responses API로 전환하면 비용이 줄어드는 이유
“마이그레이션 비용이 더 들 것”이라는 우려가 많습니다. 막상 전환해보면 방향이 반대인 경우가 있습니다. OpenAI 내부 벤치마크 기준으로 Responses API는 Chat Completions 대비 캐시 활용률이 40~80% 개선됩니다.
💡 공식 migrate-to-responses 가이드와 내부 eval 수치를 같이 놓고 보면, 멀티턴 대화에서 캐시 히트율이 낮았던 Chat Completions와 달리 Responses는 추론 토큰과 컨텍스트를 턴 간 재사용합니다. 매 요청마다 전체 대화를 다시 보내는 방식이 아니라서 입력 토큰이 줄어드는 구조입니다.
(출처: OpenAI Migrate to Responses 가이드, platform.openai.com/docs/guides/migrate-to-responses)
추론 모델에서 차이가 더 납니다
GPT-5 기반 추론 모델을 Chat Completions로 쓰면 reasoning 토큰이 턴마다 재계산됩니다. Responses API는 store: true 상태에서 추론 토큰을 다음 턴에 그대로 이어받습니다. 공식 문서에는 동일한 프롬프트·세팅 기준으로 SWE-bench에서 3% 성능이 오른다고 나옵니다. 비용은 줄고 정확도는 오르는 셈입니다.
단, 이 이점은 멀티턴 대화에서 두드러집니다. 단발성 요청(stateless)이라면 비용 차이가 미미할 수 있습니다. 제로 데이터 리텐션(ZDR) 요건이 있는 조직도 store: false에 reasoning.encrypted_content를 조합하면 추론 토큰 재사용 혜택을 유지하면서 서버 저장을 막을 수 있습니다.
RAG 연동하고 있다면 파일 검색 비용 구조가 달라집니다
Assistants API의 Retrieval(파일 검색)을 쓰고 있다면, Responses API 전환 후 청구 항목이 달라집니다. 기존 Assistants API의 파일 검색은 별도 툴콜 비용 없이 모델 토큰에 합산됐습니다. Responses API에서는 두 가지가 추가됩니다.
| 항목 | Assistants API | Responses API |
|---|---|---|
| 파일 검색 툴콜 | 별도 청구 없음 | $2.50 / 1,000건 |
| 벡터 스토리지 | 1GB 무료 후 $0.10/GB/일 | 동일 구조 유지 |
| 웹 검색 툴콜 | 해당 없음 | 약 $10 / 1,000건 + 토큰 |
(출처: OpenAI Deprecation Migration 가이드 ragwalla.com, 2026.01.28 / OpenAI API Pricing 공식 페이지)
💡 툴콜 단가만 보면 파일 검색이 비싸 보이지만, 하루 1,000건 파일 검색 요청이라면 월 비용 증가는 $2.50 × 30 = $75 수준입니다. 이 금액이 모델 토큰 절감으로 상쇄될 수도 있으니 실제 사용량 기준으로 시뮬레이션해보는 것이 맞습니다.
벡터 스토어는 그대로 재사용 가능합니다
Assistants API에서 만든 Vector Store는 Responses API에서도 그대로 쓸 수 있습니다. file_search 툴에 vector_store_ids를 지정하는 방식으로 동일하게 연결됩니다. 파일을 다시 올리거나 재임베딩할 필요가 없습니다.
지금부터 8월 26일까지 단계별 행동 계획
솔직히 말하면, 지금 당장 전환을 시작하지 않아도 5월까지는 크게 문제없습니다. 다만 6월 이후부터 예상치 못한 파리티 갭(기능 차이)이나 성능 편차가 생길 수 있어서 버퍼 시간이 필요합니다.
현재 사용 중인 Assistants, Thread, Run Steps, 벡터 스토어 목록을 뽑습니다. 동적 Assistant 생성 코드가 있으면 B 패턴(instructions 런타임 주입)으로 대체 가능한지 확인하고, Responses API 프로토타입을 하나 만들어 end-to-end 흐름을 검증합니다.
중요 Assistants를 대시보드에서 Prompt로 만들고, 파일 검색과 웹 검색 툴콜 비용을 별도로 추적합니다. 프로덕션 트래픽 일부(예: 신규 사용자 세션)를 Responses API로 돌려서 섀도 비교를 시작합니다.
모든 Assistants 엔드포인트를 Responses로 교체하고, 보존이 필요한 Thread 대화 데이터를 전부 내려받습니다. 마감일(8월 26일) 전에 최소 3~4주 버퍼를 확보하는 것을 권장합니다.
이 날짜 이후 /v1/assistants, /v1/threads 요청은 전부 오류 응답을 받습니다. 잔여 의존성이 없는지 코드베이스를 grep으로 한 번 더 확인하는 것이 좋습니다.
자주 묻는 질문 (Q&A)
마치며
Assistants API 종료는 단순한 버전 교체가 아닙니다. Thread 자동 이전 없음, 동적 Assistant 생성 코드 무효화, 파일 검색 툴콜 비용 신규 발생 — 세 가지가 동시에 바뀝니다. 이 중 하나라도 현재 코드에 깊이 얽혀 있다면 전환 작업이 생각보다 길어질 수 있습니다.
개인적으로 가장 신경 쓰이는 부분은 Prompt가 대시보드 전용이라는 점입니다. 수십 개의 커스터마이징된 Assistant를 API로 관리하던 팀이라면, 지금 당장 대시보드에서 Prompt를 하나 만들어 보는 것만으로도 이 제약이 얼마나 영향을 미치는지 감이 옵니다.
Responses API가 더 단순하고 비용 효율도 좋다는 건 맞습니다. 다만 “전환하면 알아서 더 좋아진다”가 아니라, 설계를 다시 잡아야 비로소 그 이점이 나옵니다. 8월 26일이라는 마감은 고정돼 있습니다. 지금 시작하는 게 가장 여유 있습니다.
📚 본 포스팅 참고 자료
- OpenAI Deprecations 공식 문서 — developers.openai.com/api/docs/deprecations/
- OpenAI Assistants → Responses API Migration Guide — developers.openai.com/api/docs/assistants/migration/
- OpenAI Migrate to Responses 가이드 — platform.openai.com/docs/guides/migrate-to-responses
- Ragwalla Assistants API Deprecation Migration Guide — ragwalla.com (2026.01.28)
- OpenAI Community — Assistants API beta deprecation sunset thread — community.openai.com
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. OpenAI API는 업데이트 주기가 빠르므로 최신 정보는 공식 문서에서 직접 확인하시기 바랍니다. 본문 내 가격 정보(파일 검색 $2.50/1k건 등)는 2026년 3월 기준이며 변경될 수 있습니다.
댓글 남기기