OpenAI 공식 발표 기준 · 2026.03.26 작성
OpenAI Assistants API 종료,
8월 전에 봐야 할 것들
결론부터 말씀드리면, 2026년 8월 26일 이후 /v1/assistants와 /v1/threads 엔드포인트는 완전히 차단됩니다. 대체 경로는 Responses API + Conversations API입니다. 엔드포인트만 바꾸는 수준의 작업이 아닙니다. 상태 관리 구조, 스트리밍 컨슈머, RAG 배선 전체가 달라집니다.
종료 확정까지 타임라인 — 놓치면 안 되는 날짜들
OpenAI가 Assistants API 종료를 공식 발표한 것은 2025년 8월 26일입니다. “Responses API가 기능 동등성에 도달한 이후 Assistants API를 종료하겠다”는 3월의 예고가 실제 날짜와 함께 구체화된 시점입니다. 종료일은 발표일로부터 정확히 1년 뒤인 2026년 8월 26일입니다. (출처: OpenAI 공식 커뮤니티 발표, 2025.08.26)
| 날짜 | 내용 |
|---|---|
| 2024.12.18 | Assistants API v1 베타 접근 종료 (v2만 유지) |
| 2025.03.11 | Responses API 출시 — 에이전틱 워크플로 표준으로 채택 |
| 2025.08.20 | Conversations API 출시 — 장기 대화 상태 관리용 |
| 2025.08.26 | Assistants API 공식 deprecated 선언 |
| 2026.01.28 기준 | API는 아직 동작 중이지만 end-of-life 취급 |
| 2026.08.26 | ⛔ Assistants API 완전 차단 — 모든 요청 불가 |
지금(2026년 3월 기준)은 D-153입니다. 5개월 남은 것처럼 보이지만, 프로덕션 마이그레이션에는 parity 검증·카나리 배포·롤백 훈련이 각각 2~4주씩 필요합니다. 여유가 없습니다.
객체 구조가 통째로 바뀝니다 — Threads는 어디로 갔나
이번 전환에서 핵심 객체 4개가 전부 이름과 동작 방식이 달라집니다. 이름만 바뀐 게 아닙니다. 각 객체의 역할 경계 자체가 재설계됐습니다. 공식 마이그레이션 가이드에 나온 대응 관계는 아래와 같습니다. (출처: OpenAI 공식 마이그레이션 가이드, platform.openai.com)
| Assistants API (구) | Responses 스택 (신) | 달라진 점 |
|---|---|---|
| Assistant | Prompt | API로 생성 불가 → 대시보드에서만 생성, 버전 관리 가능 |
| Thread | Conversation | 메시지만 저장 → 메시지·툴 콜·출력 등 Items로 통합 |
| Run | Response | 비동기 폴링 → 동기 입출력, 툴 루프를 직접 제어 |
| Run steps | Items | 메시지·툴 콜·출력 모두 Items 타입으로 통일 |
💡 공식 발표문과 실제 코드 예시를 같이 놓고 보니 이런 차이가 보였습니다. Prompt(구 Assistant)는 이제 API로 생성할 수 없습니다. 코드로 Assistant를 동적으로 생성하던 팀에게는 단순 리팩터링이 아닙니다. 대시보드에서 Prompt를 만들고 ID를 소스코드에 박는 방식으로 워크플로 전체를 재설계해야 합니다. 공식 커뮤니티에서도 “feature parity가 아닌 구조적 변화”라는 개발자 지적이 나온 지점입니다.
단순 엔드포인트 교체가 아닌 이유
많은 팀이 이 마이그레이션을 “엔드포인트 URL 하나 바꾸는 작업” 정도로 봅니다. 막상 해보면 다릅니다. 실제로 실패 패턴은 세 군데에서 집중적으로 터집니다.
Responses API가 실제로 더 빠른 이유가 있습니다
“새 API니까 당연히 낫겠지”라고 생각하기 쉬운데, 실제 공식 데이터로 보면 숫자가 나옵니다. OpenAI 내부 테스트 기준, Responses API는 Chat Completions 대비 캐시 활용률이 40%~80% 향상됩니다. 그만큼 토큰 비용이 직접 내려갑니다. (출처: OpenAI 공식 마이그레이션 문서, platform.openai.com/docs/guides/migrate-to-responses)
💡 공식 성능 수치와 실제 과금 구조를 같이 보니 이게 보였습니다. 캐시 활용률 향상은 단순 속도 개선이 아닙니다. 캐시된 입력 토큰은 표준 요금의 일부만 과금됩니다. 호출 빈도가 높은 에이전틱 워크플로에서는 월 비용이 체감할 수 있는 수준으로 달라집니다. 반면 GPT-5를 Reasoning 모드로 사용할 경우, 도구 호출이 비활성화되는 시점이 GPT-5.4부터 존재합니다 — Chat Completions에서 reasoning: none을 쓰면 툴 콜이 막힙니다. Responses API는 이 제한이 없습니다. (출처: OpenAI 공식 마이그레이션 문서 “Additional differences” 항목)
또한 Responses API에서만 쓸 수 있는 내장 도구들이 있습니다. Deep Research, MCP(원격 모델 컨텍스트 프로토콜), Computer Use가 대표적입니다. Chat Completions나 Assistants API에서는 동일 기능을 직접 구현해야 했던 것들입니다. 전환 비용을 감내할 이유가 있는 셈입니다.
상태 관리 전략 3가지 — 뭘 고르든 문서화가 먼저입니다
Responses API에서 상태 관리는 선택지가 세 가지입니다. Assistants API가 Threads로 상태를 고정 구조화했던 것과 달리, 이제는 팀이 직접 전략을 골라야 합니다. 고르는 것 자체보다 “이 워크로드는 어떤 전략을 쓴다”를 명시적으로 문서화하는 게 중요합니다. 섞어 쓰면 사고가 납니다.
① Conversations API — 서버 측 영속 상태
Thread와 가장 유사한 방식입니다. openai.conversations.create()로 대화 객체를 만들고 Responses 호출 시 conversation: id로 연결합니다. 장기 지원 워크플로에 적합합니다. 단, Conversation items의 보존 기한은 30일 TTL 적용 없이 유지됩니다 — Response 객체의 기본 30일 TTL과 다릅니다. (출처: OpenAI 공식 커뮤니티 발표, 2025.08.26)
② previous_response_id 체이닝 — 클라이언트 관리
이전 Response의 ID를 다음 요청에 넘겨 컨텍스트를 이어갑니다. 앱 레벨에서 상태를 완전히 통제할 수 있습니다. 단순 흐름에는 빠르지만, conversation과 동시 사용 불가입니다. 두 방식을 같이 쓰면 API 오류가 납니다.
③ 클라이언트 완전 관리 — 서버 저장 없음
store: false로 서버 측 저장을 끕니다. Zero Data Retention(ZDR) 요구사항이 있는 조직에 적합합니다. 이때도 encrypted_content를 include에 추가하면 암호화된 추론 토큰을 받아 다음 요청에 재활용할 수 있습니다. 서버에는 아무것도 쓰이지 않습니다. (출처: OpenAI 마이그레이션 가이드 “Decide when to use statefulness” 항목)
RAG·도구 비용, 마이그레이션 후 올라갈 수 있습니다
“캐시 활용률이 올라가니 비용이 줄겠지”라고 생각하기 쉬운데, 한 가지 반대 방향이 있습니다. Responses API에서 내장 도구를 쓰면 별도 과금이 붙습니다. Assistants API에서 file search를 쓸 때와 구조가 다릅니다.
| 도구 | 과금 항목 | 단가 (공식 기준) |
|---|---|---|
| File Search | 스토리지 (1GB 초과분) | $0.10/GB/일 |
| File Search | 툴 콜 (Responses API 한정) | $2.50/1,000건 |
| Web Search | 툴 콜 | 약 $10/1,000건 + 검색 콘텐츠 토큰 |
| Code Interpreter | 컨테이너 세션 | $0.03/1GB 컨테이너 |
(출처: OpenAI 공식 API 요금 페이지, openai.com/ko-KR/api/pricing/)
File Search 툴 콜은 Responses API에서만 별도 과금됩니다. Assistants API에서는 이 항목이 따로 청구되지 않았습니다. RAG 호출 빈도가 높은 서비스라면 전환 후 File Search 툴 콜 비용이 새로 생깁니다. 마이그레이션 전에 월 예상 호출 수를 먼저 뽑아 두는 이유가 여기 있습니다.
8월 전까지 움직여야 할 순서
공식 마이그레이션 플레이북(igor-ya.com, 2026.03.03)이 제시한 T-day 역산 스케줄을 한국 팀 규모에 맞게 정리했습니다. 지금(3월 말) 기준으로 실행 가능한 순서입니다.
인벤토리 확인: 현재 코드베이스에서 openai.beta.assistants, openai.beta.threads, openai.beta.threads.runs를 전수 검색합니다. 상태 전략을 워크로드별로 결정하고 문서화합니다.
프로토타입 & parity 검증: 대시보드에서 Prompt 생성, 핵심 워크플로 Responses API 포팅, 단일 턴 → 멀티 턴 → RAG 검색 품질을 수치로 비교합니다. 이 시점에 File Search 툴 콜 비용 추정치도 뽑습니다.
카나리 배포: 5% → 25% → 50% 순서로 트래픽을 전환합니다. 기존 Threads 히스토리가 필요한 경우, Conversations API에 메시지를 백필하는 스크립트를 이 단계에서 실행합니다.
완전 전환 & 레거시 제거: Assistants API 엔드포인트 의존을 전부 제거합니다. 8월 26일 2주 전까지 완료를 목표로 잡아야 마지막 이슈를 처리할 버퍼가 생깁니다.
⚠️ Thread 히스토리 자동 마이그레이션 도구는 제공되지 않습니다. OpenAI 공식 마이그레이션 가이드에 “We will not provide an automated tool for migrating Threads to Conversations”라고 명시돼 있습니다. 보존해야 할 Thread 메시지가 있다면 직접 스크립트를 짜서 내보내야 합니다. (출처: platform.openai.com/docs/assistants/migration)
Q&A
마치며
솔직히 말하면, 이 마이그레이션에서 가장 위험한 태도는 “아직 동작하니까 나중에 하지”입니다. 지금 Assistants API가 동작한다는 사실과 8월 26일 이후 작동하지 않는다는 사실이 동시에 맞습니다. D-153에서 실제 전환 여유는 3~4개월입니다. 카나리 배포·parity 검증·롤백 드릴을 포함하면 넉넉하지 않습니다.
반면 이 시점에 제대로 전환하면 캐시 효율 개선, 내장 도구 활용, 구조화된 Prompt 버전 관리를 한 번에 챙길 수 있습니다. 비용도 줄고, 코드베이스도 단순해집니다. 지금 인벤토리부터 뽑아 두는 것이 가장 현실적인 첫걸음입니다.
본 포스팅 참고 자료
- OpenAI 공식 Assistants → Responses 마이그레이션 가이드 — platform.openai.com/docs/assistants/migration
- OpenAI 공식 Chat Completions → Responses 마이그레이션 가이드 — platform.openai.com/docs/guides/migrate-to-responses
- OpenAI 커뮤니티 공식 deprecation 발표 (2025.08.26) — community.openai.com
- Ragwalla, Assistants API Deprecation Migration Guide (2026.01.28) — ragwalla.com
- igor-ya.com, Assistants to Responses API Migration Playbook (2026.03.03) — igor-ya.com
본 포스팅 작성 이후 OpenAI 서비스 정책·UI·기능이 변경될 수 있습니다. 수록된 API 요금·엔드포인트·종료 일정은 2026년 3월 26일 기준이며, 공식 플랫폼에서 최신 정보를 확인하시기 바랍니다.
댓글 남기기