OpenAI 공식 발표 기준
OpenAI Assistants API 폐지,
마이그레이션 전에 봐야 할 것
Assistants API가 2026년 8월 26일부로 완전히 종료됩니다. “Responses API로 바꾸면 끝”이라고 생각하셨다면, 실제로 바꿔본 개발자들이 발견한 비용 함정과 Thread 데이터 이전 문제를 먼저 보세요.
종료 일정과 현재 상황 정확히 보기
OpenAI는 2025년 8월 26일, Assistants API의 공식 Deprecation을 선언했습니다. 정확한 종료일은 2026년 8월 26일입니다. (출처: OpenAI 공식 플랫폼 문서, 2025.08.26) 지금으로부터 약 155일 남은 시점이고, 이 날 이후로는 API 호출 자체가 불가능해집니다.
정확히 말하면 이 발표는 두 단계로 나뉩니다. 먼저 2025년 8월 26일에 Deprecation(더 이상 권장하지 않음)이 시작됐고, 실제 서비스가 완전히 꺼지는 Sunset은 정확히 1년 뒤인 2026년 8월 26일입니다. 기존 코드는 그때까지는 동작하지만, 새 프로젝트에 Assistants API를 쓰는 건 지금 당장 멈춰야 합니다.
Assistants API는 원래 “에이전트를 쉽게 만들기 위한 첫 시도”였습니다. OpenAI 공식 커뮤니티 발표문(2025.08.26)에는 “추론 모델이 나오기 전에 에이전트를 구성하는 초기 방식이었다”고 직접 설명되어 있습니다. 즉, 처음부터 영구 솔루션으로 기획된 게 아니었다는 뜻이고, 베타 딱지가 처음부터 붙어 있던 이유도 그것입니다.
Responses API가 실제로 뭐가 달라졌나
용어 구조부터 바뀌었습니다. Assistants API에서 쓰던 Assistant → Thread → Run → Run Steps 구조가 Responses API에서는 Prompt → Conversation → Response → Items로 전면 교체됩니다. (출처: OpenAI Assistants Migration Guide) 이름만 바꾼 게 아니라, 각 객체의 역할과 관리 방식이 근본적으로 달라졌습니다.
| Assistants API (기존) | Responses API (신규) | 변경 이유 |
|---|---|---|
| Assistant | Prompt | 버전 관리 가능, 대시보드에서 diff·롤백 지원 |
| Thread | Conversation | 메시지뿐 아니라 tool call, output 등 Items 저장 |
| Run | Response | 비동기 폴링 제거, input→output 단순화 |
| Run Steps | Items | 메시지·tool call·output을 단일 타입으로 통합 |
(출처: OpenAI Assistants Migration Guide, platform.openai.com)
Responses API의 가장 큰 변화는 “에이전트를 기본값으로 만들었다”는 겁니다. 이전 Assistants API에서는 Run을 생성한 뒤 상태가 queued → in_progress → completed로 바뀔 때까지 폴링해야 했습니다. Responses API에서는 input을 넣으면 output이 나오는 단일 호출 구조로 바뀌어서 코드가 훨씬 단순해집니다.
web search, file search, code interpreter, computer use, remote MCP 등 도구들이 기본으로 내장됐고, 단일 API 호출 안에서 여러 도구를 순서대로 실행할 수 있습니다. GPT-5 기준으로 추론 토큰이 대화 간 유지된다는 점도 눈에 띄는 변화입니다.
빠르다고 했는데, 조건이 있었습니다
💡 공식 발표문과 실제 사용 흐름을 함께 놓고 보니 이런 차이가 보였습니다
공식 문서는 Responses API가 “더 빠르다”고 명시합니다. 실제로는 file_search 도구를 사용하는 순간 이 이점이 사라집니다.
Predictable Dialogs의 벤치마크(2025.07.22 기준)에서는 도구 미사용 순수 텍스트 생성 기준으로 Responses API가 약 50ms, Assistants API가 2~3초를 기록했습니다. 숫자만 보면 엄청난 차이입니다.
그런데 실제 프로덕션 환경에서 RAG 기반 챗봇을 운영하며 마이그레이션을 직접 수행한 개발자는 공식 커뮤니티(2025.03.22)에 이렇게 남겼습니다. “file_search를 사용하면 속도 변화가 없었다. 같은 도구, 같은 모델을 쓰기 때문에 당연한 결과였다.” 이 개발자의 시스템은 수만 명의 유저를 가진 프로덕션 환경으로, Assistants API 때 응답 시간이 5~20초였는데 Responses API로 전환 후에도 거의 동일했다고 보고했습니다.
50ms는 도구 없이 단순 텍스트만 주고받을 때의 수치입니다. 실제 에이전트 워크플로에서는 file_search·code interpreter 등 도구를 거치는 순간 이 속도 우위는 사라집니다. 속도 개선을 기대하고 전환을 서두를 필요는 없습니다.
반면 공식 문서가 밝힌 캐시 활용 개선은 실제로 의미 있는 수치입니다. OpenAI 내부 테스트에서 Chat Completions API 대비 캐시 활용률이 40~80% 향상됐다고 밝혔습니다. (출처: OpenAI, “Migrate to Responses API”, platform.openai.com) 이는 반복 요청이 많은 고트래픽 서비스에서 토큰 비용을 직접적으로 줄여주는 요소입니다.
file_search 비용이 조용히 바뀌었습니다
💡 마이그레이션 발표문 어디에도 이 내용이 없습니다
OpenAI 가격 페이지를 직접 확인한 개발자들만 발견한 항목입니다.
솔직히 말하면, 이 부분이 마이그레이션에서 가장 주의가 필요한 지점입니다. Responses API에서는 file_search 도구를 호출할 때마다 1,000회당 $2.50의 추가 요금이 부과됩니다. Assistants API에서는 이 비용이 없었습니다. (출처: OpenAI Pricing Page, platform.openai.com)
실제로 프로덕션에서 마이그레이션을 완료한 개발자는 이 사실을 나중에 가격 페이지에서 우연히 발견했고, 공식 커뮤니티(2025.03.23)에 다음과 같이 계산했습니다. gpt-4o-mini 기준 입력 토큰 20,000~40,000개당 약 $5/1,000건인데, file_search 호출 비용 $2.50을 더하면 실질 비용이 50% 증가하는 셈이라는 지적입니다.
// 비용 비교 계산 (gpt-4o-mini 기준)
Assistants API 1,000건 처리:
입력 토큰 비용 ≈ $5.00 (30k 토큰 × $0.15/1M × 1,000)
Responses API 1,000건 처리 (file_search 포함):
입력 토큰 비용 ≈ $5.00 + file_search $2.50 = $7.50
※ 실제 토큰 수와 모델에 따라 다르며, 위 수치는 커뮤니티 발표 기반 추정입니다. 공식 가격은 platform.openai.com/pricing에서 확인하세요.
RAG 기반 서비스처럼 거의 모든 요청에서 file_search를 사용하는 구조라면, 마이그레이션 후 비용 청구서를 보고 당황할 수 있습니다. 전환 전에 현재 파일 검색 호출량을 먼저 파악하는 게 순서입니다.
반대로 file_search를 거의 쓰지 않는 단순 텍스트 생성 워크플로라면, Responses API의 캐시 개선 효과(40~80%)가 오히려 비용을 줄여줄 수 있습니다. 서비스 특성에 따라 판단해야 합니다.
Thread 데이터, 자동으로 옮겨지지 않습니다
OpenAI 공식 마이그레이션 가이드에는 이 문장이 명확하게 적혀 있습니다. “Thread에서 Conversation으로의 자동 이전 도구는 제공하지 않습니다.” (출처: OpenAI Assistants Migration Guide, platform.openai.com) 기존 대화 히스토리를 보존해야 하는 서비스라면, 이 작업을 직접 코딩해야 합니다.
공식 가이드에서 제시하는 방법은 기존 Thread의 메시지를 API로 순서대로 읽어온 뒤, Conversation 객체에 Items 형식으로 다시 넣는 backfill 방식입니다. 메시지 타입에 따라 input_text, output_text, input_image 등으로 타입을 분류해 변환해야 합니다.
따라서 권장 전환 전략은 이렇습니다. 신규 사용자의 새 대화는 즉시 Responses API + Conversations로 전환하고, 기존 사용자의 과거 Thread는 필요에 따라 순차적으로 backfill 처리하는 방식입니다. 수만 개의 Thread가 있는 대규모 서비스라면 이 작업 자체가 상당한 엔지니어링 리소스를 요구합니다.
⚠️ 주의
Response 객체는 기본적으로 30일 후 자동 삭제됩니다. Conversation에 연결된 Response는 TTL이 적용되지 않지만, 독립 Response는 30일 내 저장이 필요합니다. (출처: OpenAI 커뮤니티 공식 답변, 2025.08.26)
Prompt 객체는 API로 만들 수 없습니다
💡 “피처 동일” 발표 직후 커뮤니티에서 가장 많이 나온 지적입니다
동적으로 Assistant를 생성하던 서비스에는 대체 방법이 없습니다.
OpenAI 공식 마이그레이션 가이드에는 이런 문장이 있습니다. “Prompt는 대시보드에서만 생성할 수 있습니다.” (출처: OpenAI Assistants Migration Guide) Assistants API에서는 코드에서 openai.beta.assistants.create()로 Assistant를 동적으로 생성할 수 있었습니다. Responses API의 Prompt는 그 방법이 없습니다.
이 제한이 실제로 문제가 되는 케이스는 명확합니다. 고객마다 다른 instruction을 가진 Assistant를 코드에서 동적으로 생성하는 멀티테넌트 서비스, 또는 사용자 입력에 따라 실시간으로 Agent 설정이 바뀌는 워크플로입니다. Deprecation 발표 직후 커뮤니티에서 가장 많이 제기된 이슈가 바로 이 부분이었습니다. 공식 답변은 아직 명확히 나오지 않은 상태입니다.
현실적인 우회 방법은 Prompt를 사용하지 않고, Responses API의 instructions 파라미터로 매 호출마다 시스템 지시를 직접 넘기는 방식입니다. Prompt의 버전 관리 이점은 포기해야 하지만, 동적 생성이라는 유연성은 유지할 수 있습니다.
실제 마이그레이션 순서 정리
앞서 나온 내용을 바탕으로 실제 작업 순서를 정리하면 이렇게 됩니다.
file_search 사용량 먼저 확인
대시보드 Usage 탭에서 지난 30일간 file_search 호출 횟수를 확인하세요. 1,000회당 $2.50 추가 비용을 곱해 예상 비용 변동폭을 먼저 파악해야 합니다.
대시보드에서 기존 Assistant를 Prompt로 전환
OpenAI 대시보드 → Assistants 목록 → 해당 Assistant → “Create prompt” 버튼. Prompt ID를 코드에 저장하세요. API로는 생성 불가합니다.
신규 대화는 Conversations API로 즉시 전환
openai.beta.threads.create() 호출을 openai.conversations.create()로 교체합니다. Thread 자동 이전이 없으므로 신규/구형을 분기 처리하는 로직이 필요합니다.
Run 폴링 코드 제거
Assistants API에서 status in ("queued", "in_progress")를 체크하던 while 루프를 모두 제거합니다. Responses API는 단일 호출로 완료됩니다.
함수 정의 스키마 업데이트
Responses API에서 함수 스키마는 내부 태그 방식(internally-tagged)이며, strict 모드가 기본값입니다. Chat Completions/Assistants API의 외부 태그 방식과 다릅니다. 반드시 확인하세요.
기존 Thread backfill (필요 시)
과거 대화 이력이 필요한 경우에만 수행합니다. 공식 가이드에 Python 코드 예제가 있으며, 이미지 타입별로 변환 로직을 작성해야 합니다.
Q&A
Q. 2026년 8월 26일 이후에도 기존 Assistants API 코드가 작동하나요?
작동하지 않습니다. Sunset 날짜인 2026년 8월 26일 이후에는 /v1/assistants, /v1/threads 등 Assistants API 엔드포인트가 완전히 비활성화됩니다. (출처: OpenAI 플랫폼 공식 문서) 해당 날짜까지 마이그레이션을 완료하지 않으면 서비스 장애로 이어집니다.
Q. Chat Completions API도 함께 폐지되나요?
이번 발표에서는 Chat Completions API 폐지 계획은 없습니다. OpenAI 공식 문서(platform.openai.com)에는 “Chat Completions는 계속 지원되며, 신규 프로젝트에는 Responses API를 권장한다”고 명시되어 있습니다. 다만, 일부 개발자들은 Chat Completions도 결국 단계적으로 전환될 것이라 예측하고 있습니다. OpenAI가 공식 발표를 내놓지 않은 부분입니다.
Q. Azure OpenAI Service에서 Assistants API도 똑같이 폐지되나요?
Azure OpenAI의 Assistants API는 별도 일정을 따릅니다. Microsoft Learn 공식 페이지(2025.10 기준)에는 Azure OpenAI Assistants API가 OpenAI의 2026년 8월 26일 일정과 동일하게 적용되는지에 대한 공식 답변이 아직 명확히 나오지 않은 상태입니다. Azure를 사용 중이라면 Azure OpenAI 서비스 공지를 별도로 확인해야 합니다.
Q. ZDR(Zero Data Retention) 정책 적용 기업은 Responses API를 쓸 수 없나요?
쓸 수 있습니다. OpenAI 공식 문서에는 ZDR 조직을 위해 store: false와 reasoning.encrypted_content를 조합한 Stateless 모드가 지원된다고 나와 있습니다. 추론 토큰은 암호화된 상태로만 반환되며, 서버에 저장되지 않습니다. ZDR 환경에서는 store=false가 자동 강제 적용됩니다.
Q. vector store는 그대로 사용 가능한가요?
네, vector store 객체는 그대로 유지되고 Responses API에서도 동일하게 사용됩니다. 실제로 마이그레이션을 수행한 개발자들은 “벡터 스토어 부분은 전혀 바꿀 필요가 없었다”고 보고했습니다. (출처: OpenAI 커뮤니티, 2025.03.22) 다만 vector store 파일 수 상한(10,000개)은 그대로 유지되므로, 대규모 서비스에서는 여전히 제약 사항으로 남습니다.
마치며
Responses API 자체는 잘 만들어진 API입니다. 폴링 제거, 도구 내장, 캐시 개선처럼 실제로 코드를 단순하게 만들어주는 변화들입니다. 마이그레이션 자체도 Assistants API를 잘 구조화해뒀다면 몇 시간 안에 완료했다는 보고가 있습니다.
다만 file_search 비용 변화, Thread 수동 이전, Prompt 동적 생성 불가 — 이 세 가지는 마이그레이션 발표문 어디에도 굵직하게 강조되지 않았습니다. 막상 전환하고 나서 발견하면 비용 계획이나 아키텍처 설계를 처음부터 다시 해야 할 수 있습니다.
남은 기간은 약 155일입니다. 지금 당장 전환하지 않더라도, 적어도 현재 서비스의 file_search 사용량과 Thread 규모를 파악해두는 것부터 시작하면 됩니다.
본 포스팅 참고 자료
댓글 남기기