📅 2026.03.23 기준 / OpenAI API 공식 문서 기준
OpenAI Assistants API 종료, 마이그레이션 전 확인할 것 3가지
공식 문서에 딱 이렇게 나옵니다. 종료일 2026년 8월 26일.
지금 쓰고 있다면, Responses API로 옮기기 전에 이 세 가지는 꼭 읽어보시길 권합니다.
🔁 대체: Responses API
💡 캐시 개선: 40~80%
Assistants API가 사라지는 이유 — 공식 발표 그대로
OpenAI는 2025년 8월 26일, 공식 커뮤니티 공지를 통해 Assistants API 베타의 종료를 선언했습니다.
종료 예정일은 공식 Deprecations 문서에 2026년 8월 26일로 명시돼 있습니다.
지금 기준으로 5개월이 남은 셈입니다.
(출처: OpenAI 공식 Deprecations 문서)
공식 발표문에는 이렇게 나와 있습니다. “Assistants were our early take on how agents could be built (before reasoning models).”
직역하면 “Assistants는 추론 모델 이전 시대에 에이전트를 만들던 초기 방식이었다”는 것입니다.
Responses API가 토큰 활동량에서 Chat Completions를 이미 넘어섰다는 사실도 OpenAI가 직접 공개했습니다.
추론 모델 시대에 맞춰 설계된 새 구조로 전면 교체하는 흐름입니다.
💡 공식 발표문과 실제 타임라인을 같이 놓고 보니 이런 맥락이 보였습니다.
OpenAI는 2025년 3월에 Responses API를 출시할 때 “Assistants의 기능 동등성이 달성되면 종료를 공식화하겠다”고 했고,
실제로 같은 해 8월에 종료 선언이 나왔습니다. 계획대로였지만, 기능 동등성 달성 여부에 대해서는 커뮤니티 반응이 엇갈립니다.
대체 경로는 Responses API + Conversations API 조합입니다.
기존 Assistants의 Assistant 객체는 Prompts로, Thread는 Conversations로, Run은 Responses로 각각 대응됩니다.
이름만 바뀐 게 아니라 작동 방식 자체가 다르기 때문에 코드 전체를 재검토해야 합니다.
Responses API가 무조건 더 싸다는 말의 함정
OpenAI Assistants API 종료를 다룬 글들이 빠지지 않고 쓰는 문장이 있습니다. “Responses API로 바꾸면 비용이 낮아진다.”
실제로 OpenAI 공식 문서에는 캐시 활용 개선으로 Chat Completions 대비 40~80% 비용이 낮아진다고 나옵니다.
(출처: OpenAI Responses vs Chat Completions 공식 가이드)
그런데 바로 그 문서 안에 이런 내용도 있습니다.
“Even with previous_response_id, prior inputs in the chain still contribute to billed input tokens.”
상태 체이닝(Chaining)을 쓸 경우, 이전 대화 전체가 매번 입력 토큰으로 청구됩니다.
Assistants API의 Thread 방식과 실질적으로 동일한 구조입니다. 비용이 낮아진다는 말은 캐시가 잘 맞아 떨어질 때의 이야기입니다.
💡 캐시 개선 수치와 File Search 추가 요금을 교차해 보면 다른 그림이 나옵니다.
File Search 도구를 쓸 경우 1,000 tool calls당 $2.50이 별도 부과됩니다. 저장 비용은 첫 1GB 무료, 이후 하루 $0.10/GB입니다.
Assistants API 시절에도 동일한 구조였지만, 당시에는 Tool call 별도 요금이 없었습니다.
캐시 절감이 Tool call 요금보다 크려면 특정 사용 패턴이 전제돼야 합니다.
| 항목 | Assistants API (종료) | Responses API (권장) |
|---|---|---|
| File Search | 툴 호출 별도 요금 없음 | $2.50 / 1K calls |
| File Storage | 첫 1GB 무료, 이후 $0.10/GB/일 | 첫 1GB 무료, 이후 $0.10/GB/일 |
| Code Interpreter | 세션당 $0.03 | 세션당 $0.03 (4GB $0.12) |
| 캐시 활용 개선 | 기준치 | Chat Completions 대비 40~80% ↓ |
| Web Search | 없음 | $25.00 / 1K calls |
(출처: OpenAI API 가격 공식 페이지, 2026.03.23 기준)
File Search를 하루 1,000번 이상 호출하는 서비스라면 월 75달러의 추가 요금이 생깁니다. 캐시 절감이 이를 상쇄하는지는 실측이 필요합니다.
기능 동등성? 실제로는 이 부분이 빠져 있습니다
OpenAI는 종료 선언 이유로 “Responses API가 기능 동등성(feature parity)에 도달했다”는 점을 들었습니다.
그런데 OpenAI 개발자 커뮤니티에서는 이 부분에 이의가 있었습니다.
Assistants API에서는 코드로 Assistant 객체를 동적으로 생성할 수 있었지만,
Responses API의 대응 개념인 Prompt는 대시보드에서만 만들 수 있고 API로 생성하는 방법이 없습니다.
공식 마이그레이션 가이드에 직접 이렇게 나와 있습니다.
“Their replacement, prompts, can only be created in the dashboard, where you can version them as you develop your product.”
(출처: OpenAI Assistants 마이그레이션 가이드)
이는 런타임에 동적으로 Assistant를 생성해 다수 고객에게 각각 다른 설정을 적용하던 방식에서는 직접 대응이 안 된다는 의미입니다.
💡 마이그레이션 가이드와 커뮤니티 피드백을 함께 보니 이런 간극이 보였습니다.
다수의 고객마다 다른 시스템 프롬프트·도구 구성을 API로 프로그래매틱하게 만들어야 하는 서비스라면,
Prompt 대시보드 방식이 실질적인 병목이 될 수 있습니다. 이 경우에는 인스트럭션을 요청 단위로 직접 전달하는
stateless 방식으로 아키텍처를 재설계해야 합니다.
또 한 가지. Assistants API에는 Truncation 전략이 있어 대화 길이를 예산 기준으로 제어할 수 있었습니다.
Responses API에서는 이에 대응하는 기능으로 Compaction이 있지만, 별도 API 호출(`/responses/compact`)이 필요합니다.
장기 대화 관리 로직을 직접 구현해야 하는 부담이 생깁니다.
마이그레이션 순서, 공식 문서 기준으로 정리
OpenAI Assistants API 종료에 대응하는 공식 마이그레이션 절차는 크게 4단계입니다.
OpenAI는 스레드(Thread)에 대한 자동 변환 도구는 제공하지 않는다고 명시했습니다.
기존 Thread의 메시지는 직접 백필(backfill) 작업을 해야 합니다.
Assistant → Prompt 변환
대시보드에서 기존 Assistant를 찾아 “Create Prompt” 버튼으로 변환합니다.
Prompt ID를 소스 코드에 저장해 안정적인 식별자로 참조하도록 설계합니다.
신규 대화부터 Conversations API 적용
새로 생성되는 사용자 대화는 Conversations API를 통해 처리합니다.
기존 Thread는 필요에 따라 메시지를 순서대로 백필하는 방식으로 이전합니다.
상태 유지 방식 결정
대화 지속성이 필요하다면 Conversations API를 씁니다.
단순 체이닝은 previous_response_id를 활용하되,
입력 토큰 비용이 누적된다는 점을 고려해 대화 길이를 관리해야 합니다.
기능 정의 방식 업데이트
Responses API에서는 함수 정의 방식이 달라졌습니다. externally-tagged 방식에서 internally-tagged 방식으로 바뀌었고,
기본 strict 설정도 변경됐습니다. 함수 스키마를 전부 검토해야 합니다.
Structured Outputs의 정의 방식도 바뀌었습니다. 기존에는 response_format을 썼지만,
Responses API에서는 text.format으로 이동했습니다. 단순한 필드명 변경이 아니라
스키마 정의 위치 자체가 달라진 것이어서 검토가 필요합니다.
기업 보안 정책에서 Responses API가 막히는 경우
Responses API가 Assistants API보다 낫다는 전제는 대부분 사실이지만,
기업 보안 정책 맥락에서는 예외가 있습니다.
Responses API의 Background mode(비동기 처리)는 Zero Data Retention(ZDR) 정책과 호환되지 않는다고
공식 문서에 직접 명시돼 있습니다.
(출처: OpenAI Background mode 공식 가이드)
ZDR 조직이란 계약 조건에 따라 입력 데이터를 OpenAI 서버에 저장하지 않도록 설정된 기업 고객입니다.
금융, 의료, 공공기관 등에서 흔히 요구되는 조건입니다.
Background mode는 폴링을 위해 약 10분간 응답 데이터를 저장하는 구조인데,
이것이 ZDR 정책과 충돌합니다. ZDR 조직에서는 store: false가 자동 적용됩니다.
⚠️ ZDR 계약이 있는 기업은 Background mode를 사용할 수 없습니다.
장기 실행 작업(Long-running task)을 비동기로 처리해야 한다면,
OpenAI 서버 측 폴링 대신 외부 큐(Queue) 시스템을 직접 구현해야 합니다.
이는 Assistants API의 Run 폴링 방식과 비교해 마이그레이션 작업량이 늘어나는 케이스입니다.
반면 ZDR 조건에서도 추론 모델의 장점을 유지하는 방법은 있습니다.
store: false로 상태 비저장 설정을 하고,
include: ["reasoning.encrypted_content"]를 함께 전달하면
OpenAI 서버가 추론 토큰을 암호화해 반환하고 디스크에 저장하지 않습니다.
이후 요청에 이 암호화된 토큰을 그대로 전달하면 추론 연속성을 유지할 수 있습니다.
비용 계산 — 직접 따라할 수 있는 방식으로
실제 비용을 추산해볼 수 있는 시나리오를 하나 만들어봤습니다.
하루 1,000번 파일 검색 요청을 처리하는 서비스를 기준으로,
Assistants API와 Responses API의 월간 비용 차이를 비교합니다.
📊 시나리오: 일 1,000회 File Search, 10GB 파일 저장, gpt-5 기준
Responses API File Search 요금:
ㆍTool calls: 1,000회/일 × 30일 = 30,000회 → $2.50 × 30 = $75.00/월
ㆍ저장 비용: 10GB × $0.10 × 30일 = $30.00/월 (첫 1GB 제외 9GB 기준 $27.00)
ㆍ소계: 약 $102.00/월 (도구 비용만, 토큰 비용 제외)
Assistants API File Search 요금 (종료 전 기준):
ㆍTool call 별도 요금: 없음
ㆍ저장 비용: 10GB × $0.10 × 30일 ≈ $27.00/월
→ File Search를 많이 쓰는 서비스는 Responses API 전환 후 월 약 $75 이상 추가 비용 발생 가능
(출처: OpenAI Platform 가격 문서, 2026.03.23 기준. 토큰 비용은 모델별로 별도 적용)
캐시 개선으로 입력 토큰 비용이 40~80% 줄어드는 효과가 있더라도,
File Search 호출이 많은 서비스에서는 Tool call 요금이 이를 상쇄하거나 초과할 수 있습니다.
이 계산식을 본인 서비스 수치에 대입해 먼저 추산해보는 것이 마이그레이션 전 필수 작업입니다.
반면 Web Search나 Computer Use를 새로 활용할 계획이 있다면 Responses API의 장점이 분명합니다.
Web Search는 Assistants API에 없던 기능이고, 1,000 calls당 $25.00으로 책정돼 있습니다.
Computer Use 역시 Responses API에서만 지원되는 네이티브 기능입니다.
새 기능을 활용하면서 도구 비용이 증가하는 구조인지, 아니면 기존 워크플로만 이전하는 것인지에 따라
마이그레이션 경제성이 달라집니다.
Q&A 5가지
마치며
OpenAI Assistants API 종료 자체는 예견된 수순이었습니다.
추론 모델 시대에 맞춰 설계된 Responses API가 실제로 더 강력하고, 더 많은 기능을 제공하는 것도 사실입니다.
그런데 “그냥 옮기면 된다”는 인식이 몇 가지 조건을 지우고 있습니다.
File Search를 많이 쓰는 서비스에서는 도구 요금이 새로 생깁니다.
동적으로 Assistant를 생성하던 구조는 대시보드 전용 Prompt 방식으로 바로 대응하기 어렵습니다.
ZDR 계약이 있는 기업에서는 Background mode를 쓸 수 없습니다.
이 세 가지는 공식 문서에 전부 나와 있는 내용이지만, 많은 글들이 지나쳐 버리는 부분입니다.
5개월이 남아 있습니다. 충분히 검토하고 이전할 시간이 있습니다.
서비스의 File Search 호출량과 ZDR 계약 여부부터 먼저 확인하고,
비용 추산을 마친 뒤에 마이그레이션 순서를 잡는 것이 순서에 맞습니다.
댓글 남기기