Responses API 기준
⚠️ D-147 종료
Assistants API 종료, 마이그레이션 전에 볼 조건
결론부터 말씀드리면, 2026년 8월 26일에 Assistants API가 완전히 꺼집니다. 지금 /v1/assistants와 /v1/threads를 프로덕션에서 쓰고 있다면, 오늘 당장 마이그레이션 계획이 필요합니다. 그런데 “그냥 API 교체하면 되지”라고 생각했다면, 공식 문서를 다시 봐야 합니다.
종료 일정과 지금까지 온 타임라인
OpenAI가 Assistants API 종료를 공식 발표한 건 2025년 8월 26일이었습니다. 그로부터 정확히 1년 뒤인 2026년 8월 26일이 셧다운 날짜입니다. 공식 마이그레이션 문서에 딱 이렇게 나옵니다. “As of August 26th, 2025, we’re deprecating the Assistants API, with a sunset date of August 26, 2026.” (출처: OpenAI 공식 마이그레이션 가이드, developers.openai.com)
주요 타임라인을 짚으면, 2024년 12월 18일에 Assistants API v1 베타 접근이 끊겼고 v2만 남았습니다. 2025년 8월에 공식 deprecation 공지가 나왔고, 2026년 4월 현재 API는 여전히 작동하지만 end-of-life 상태입니다. 지금 시점에서 마이그레이션을 시작하지 않으면 8월 26일 이후 /v1/assistants 호출은 전부 실패합니다.
Assistants API → Responses API, 단순 교체가 아닙니다
“API 엔드포인트만 바꾸면 되는 거 아닌가?”라고 생각하기 쉽습니다. 그런데 OpenAI 커뮤니티에서도 이 지점을 명확히 짚고 있습니다. “It’s a bigger shift than that — think less ‘API replacement’ and more ‘architecture change.’” (출처: OpenAI Developer Community, 2026.01.06) 핵심 개념 자체가 바뀝니다.
| 기존 (Assistants API) | 새로운 (Responses 플랫폼) | 달라지는 점 |
|---|---|---|
| Assistants | Prompts | API 대신 대시보드에서 생성·버전 관리 |
| Threads | Conversations | 메시지 외에 tool call·output도 item으로 저장 |
| Runs (polling) | Responses | 폴링 루프 없이 input→output 직접 반환 |
| Run steps | Items | 메시지·도구 호출·결과가 하나의 타입으로 통합 |
특히 Prompts는 API로 만들 수 없고, 대시보드에서만 생성됩니다. 기존에 코드로 Assistant 객체를 동적으로 생성·관리했다면 이 부분이 가장 먼저 막히는 지점입니다. 소스 컨트롤에 Prompt ID를 넣어서 관리하는 방식으로 전환해야 합니다.
Thread 이전에 자동화 도구가 없습니다
이게 이번 마이그레이션에서 가장 번거로운 부분입니다. OpenAI 공식 문서에 다음 문장이 그대로 있습니다. “We will not provide an automated tool for migrating Threads to Conversations.” (출처: OpenAI Assistants Migration Guide, developers.openai.com) 직접 해야 한다는 뜻입니다.
권장하는 방식은 신규 사용자 대화는 Conversations API로 새로 생성하고, 기존 Thread 기록은 필요한 것만 골라서 backfill하는 방식입니다. 공식 문서에 Python 코드 예제도 나와 있는데, Thread 메시지를 읽어서 item 형식으로 변환한 뒤 Conversation을 새로 만드는 흐름입니다. Thread 수가 많다면 이 과정에 상당한 시간이 걸릴 수 있습니다.
Thread 히스토리 보존 3가지 방법
마이그레이션 이후 대화 상태를 유지하는 방법은 공식적으로 세 가지입니다. 어떤 걸 고를지는 서비스 성격에 따라 다릅니다.
- Conversations API — Thread와 가장 비슷한 서버사이드 상태 유지. 대화가 길고 사용자별 히스토리가 필요한 서비스에 적합합니다.
- previous_response_id 체이닝 — 직전 응답 ID를 다음 요청에 넘기는 방식. 간단하지만 Conversations와 동시에 쓸 수 없습니다 (아래 섹션에서 자세히).
- 클라이언트 관리 히스토리 — 서버에 상태를 저장하지 않고 앱이 직접 관리. 가장 자유롭지만 구현 부담이 가장 큽니다.
파일 검색 비용 구조가 바뀝니다
Responses API로 넘어오면서 파일 검색(File Search / RAG) 비용 체계가 달라집니다. Assistants API에서는 Vector Store 저장 비용만 냈지만, Responses API에서는 도구 호출 횟수당 추가 비용이 붙습니다.
| 항목 | Assistants API | Responses API |
|---|---|---|
| Vector Store 저장 | 1GB 무료 후 $0.10/GB/일 | 동일 |
| File Search 호출 | 별도 과금 없음 | $2.50 / 1k 호출 추가 |
| Web Search 호출 | 별도 없음 | 약 $10 / 1k 호출 추가 |
| 캐시 비용 | 기준값 | 40~80% 절감 (내부 테스트) |
(출처: OpenAI 공식 pricing 문서, Ragwalla 마이그레이션 가이드 2026.01.28)
RAG 기반 서비스에서 파일 검색을 자주 호출한다면, 마이그레이션 이후 예상 비용을 미리 계산해봐야 합니다. 하루에 File Search를 10만 번 호출하면 단순 계산으로 월 약 $7,500의 추가 비용이 발생합니다.
previous_response_id와 Conversation, 동시에 못 씁니다
Responses API로 넘어오면서 대화 상태를 이어가는 방법이 두 가지가 생겼는데, 이 둘을 같이 쓸 수 없습니다. 공식 FAQ에 명시되어 있습니다. “Can I use both conversation and previous_response_id? No — the Responses API docs note you can’t use previous_response_id while using a conversation.” (출처: Ragwalla 마이그레이션 가이드, 2026.01.28)
처음 마이그레이션할 때 두 방식을 혼합해 구현하려다 막히는 경우가 생기는 지점입니다. 서비스 초반에 previous_response_id로 빠르게 구현하다가 나중에 Conversations API로 전환하려면 상태 관리 로직을 새로 짜야 합니다. 처음 설계할 때 어느 방향으로 갈지를 먼저 결정하는 게 맞습니다.
또 한 가지. Conversations에 저장된 item은 30일 TTL 적용 없이 유지되지만, store: true로 생성한 Response 객체는 기본 30일 후 삭제됩니다. 사용자별 히스토리를 길게 보관해야 한다면 Conversations API를 써야 합니다.
지금 당장 해야 할 3가지
Ragwalla가 정리한 타임라인 기준으로, 4월 현재 시점에 해야 할 작업을 정리하면 다음과 같습니다. (출처: Ragwalla Assistants API Deprecation Guide, 2026.01.28)
Assistant 수, Thread 수, 연결된 Vector Store, 사용 중인 tool 종류를 목록으로 만들어야 합니다. 이 인벤토리가 없으면 마이그레이션 범위를 가늠할 수 없습니다.
8월 26일 이전에 export하지 않으면 데이터 접근이 불가능해집니다. 공식 Python 예제를 참고해 Thread 메시지를 item 형식으로 변환·저장하는 스크립트를 먼저 만들어두는 게 좋습니다.
문서만 읽는 것과 실제로 돌려보는 것은 다릅니다. 기존 서비스의 핵심 기능 하나를 Responses API + Conversations API로 구현해보면, 막히는 지점이 어디인지 파악할 수 있습니다. 5월 이전에 해두는 게 안전합니다.
자주 묻는 질문
마치며
솔직히 말하면, Responses API로의 전환은 “더 나은 API로 바꾸는 것”이 아니라 “에이전트 아키텍처를 새로 짜는 것”에 가깝습니다. Thread 자동 이전 도구도 없고, Prompt는 대시보드에서만 만들어야 하고, 비용 구조도 달라집니다. 8월 26일이라는 데드라인은 생각보다 빠릅니다.
좋은 소식은, 캐시 비용이 크게 줄어들고 MCP·computer use 같은 최신 기능을 바로 붙일 수 있다는 점입니다. 마이그레이션을 짐으로 보는 것보다, 에이전트 설계를 처음부터 다시 해볼 기회로 보는 게 현실적으로 낫습니다. 지금 당장은 Thread 백업부터 시작하는 게 가장 급합니다.
본 포스팅 참고 자료
본 포스팅은 2026년 4월 1일 기준으로 작성되었습니다. OpenAI Responses API 및 Assistants API 관련 정책·UI·기능·요금은 업데이트로 변경될 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으므로, 최신 내용은 OpenAI 공식 문서에서 직접 확인하시기 바랍니다.
댓글 남기기