종료일: 2026.08.26
OpenAI 공식 문서 기준
Assistants API 종료, 엔드포인트만 바꾸면 될까요?
2026년 8월 26일 이후 /v1/assistants와 /v1/threads는 완전히 차단됩니다. 많은 팀이 “엔드포인트 교체 작업”으로 보고 있는데, 공식 마이그레이션 문서에는 그렇게 간단하지 않다는 내용이 직접 적혀 있습니다.
종료 타임라인 — 달력보다 실무 일정이 촉박합니다
종료일이 2026년 8월 26일이니 5개월 남은 것처럼 보입니다. 막상 따져보면 다릅니다. 공식 마이그레이션 플레이북(igor-ya.com, 2026.03.03)은 parity 검증·카나리 배포·롤백 드릴을 각각 2~4주씩 잡아야 한다고 명시합니다. 실질적인 작업 버퍼는 3~4개월입니다. 지금(4월 초)이 사실상 마지막으로 여유 있게 시작할 수 있는 시점입니다.
| 날짜 | 내용 |
|---|---|
| 2025.03.11 | Responses API 출시 — 에이전틱 워크플로 표준으로 채택 |
| 2025.08.20 | Conversations API 출시 — 장기 대화 상태 관리용 |
| 2025.08.26 | Assistants API 공식 deprecated 선언 |
| 2026.04.02 현재 | 동작 중이지만 end-of-life 취급, D-146 |
| 2026.08.26 ⛔ | Assistants API 완전 차단 — 모든 요청 불가 |
(출처: OpenAI 커뮤니티 공식 deprecation 발표, 2025.08.26)
객체 4개가 통째로 바뀝니다 — Threads는 어디로 갔나
💡 공식 발표문과 실제 마이그레이션 코드를 나란히 놓고 보니 이런 차이가 눈에 띄었습니다 — Prompt(구 Assistant)는 이제 API로 생성이 안 됩니다. 이름이 바뀐 게 아니라, 생성 경로 자체가 달라진 겁니다.
공식 마이그레이션 가이드(platform.openai.com)에 나온 객체 대응 관계는 아래 표와 같습니다. 이름만 달라진 것처럼 보이지만, 실제 동작 방식과 생성·관리 경로가 전부 재설계됐습니다.
| Assistants API (구) | Responses 스택 (신) | 핵심 변화 |
|---|---|---|
Assistant |
Prompt |
API 생성 불가 → 대시보드에서만 생성 |
Thread |
Conversation |
메시지만 저장 → 메시지·툴 콜·출력 Items로 통합 |
Run |
Response |
비동기 폴링 루프 → 동기 입출력, 툴 루프 직접 제어 |
Run steps |
Items |
메시지·툴 콜·출력 모두 Items 타입으로 통일 |
특히 Prompt(구 Assistant)를 API로 동적 생성하던 팀에게는 이게 단순 리팩터링이 아닙니다. 코드에서 Assistant를 만들던 로직을 전부 걷어내고, 대시보드에서 수동으로 Prompt를 만든 뒤 ID를 소스코드에 박는 방식으로 워크플로를 재설계해야 합니다. 공식 커뮤니티에서도 개발자들이 “기능 동등성이 아닌 구조적 변화”라고 지적한 지점이 바로 여기입니다.
(출처: OpenAI 공식 마이그레이션 가이드, platform.openai.com/docs/assistants/migration)
단순 교체가 막히는 3가지 이유가 있습니다
실제 마이그레이션 실패 사례를 보면, 문제가 터지는 곳이 3군데로 집중됩니다. 공식 마이그레이션 플레이북(igor-ya.com, 2026.03.03)이 P0 수준 위험으로 분류한 항목들입니다.
막히는 지점 1 — 상태 연속성
Threads는 메시지만 서버 측에 저장했습니다. Conversations는 메시지·툴 콜·출력까지 Items로 통합 저장합니다. 기존 코드가 암묵적으로 가정하던 상태 경계가 달라져서, 후속 턴에서 컨텍스트가 초기화되는 현상이 발생합니다. 스테이징에서는 통과하고 실트래픽에서 터지는 패턴입니다.
막히는 지점 2 — RAG 품질 저하
Assistants API의 file search는 assistant 레벨·thread 레벨 벡터 스토어를 자동으로 쿼리했습니다. Responses API에서는 vector_store_ids를 명시적으로 전달해야 합니다. 전환 후 검색 범위가 조용히 달라지면서 RAG 답변 품질이 떨어집니다. 수치로 비교하지 않으면 배포 후에야 인지합니다.
막히는 지점 3 — 스트리밍 컨슈머
Responses API의 스트리밍은 SSE 기반입니다. 이벤트 순서·끊김 처리·취소 로직이 달라집니다. 백엔드 호출만 바꾸고 클라이언트 이벤트 파서를 그대로 두면 실트래픽 패턴에서 스트림이 깨집니다.
세 가지 공통점이 있습니다. 전부 스테이징에서는 잘 작동하다가 실제 트래픽에서 터집니다. 엔드포인트 호환성이 동작 동등성을 보장하지 않는다는 뜻입니다.
Responses API가 빠른 건 사실인데, 비용은 다릅니다
💡 “캐시 효율이 좋아진다”는 말만 보고 비용이 무조건 줄 거라 예상하기 쉬운데, 공식 요금 페이지와 마이그레이션 문서를 같이 보니 반대 방향이 하나 있었습니다.
Responses API는 캐시 활용률이 Chat Completions 대비 40~80% 향상됩니다. 캐시된 입력 토큰은 표준 요금의 일부만 과금되므로, 호출 빈도가 높은 에이전틱 워크플로에서는 토큰 비용이 실제로 내려갑니다. (출처: OpenAI 공식 마이그레이션 문서, platform.openai.com/docs/guides/migrate-to-responses)
그런데 내장 도구를 쓰면 별도 과금이 붙습니다. 특히 File Search 툴 콜은 Responses API에서만 별도 청구됩니다. Assistants API에서는 이 항목이 따로 청구되지 않았습니다.
| 도구 | 과금 항목 | 단가 (공식 기준) | 비고 |
|---|---|---|---|
| File Search | 스토리지 (1GB 초과분) | $0.10/GB/일 | 두 API 동일 |
| File Search | 툴 콜 | $2.50/1,000건 | Responses API에서만 청구 |
| Web Search | 툴 콜 | 약 $10/1,000건 + 검색 콘텐츠 토큰 | Responses API 전용 |
| Code Interpreter | 컨테이너 세션 | $0.03/1GB 컨테이너 | Responses API 전용 |
(출처: OpenAI 공식 요금 페이지, openai.com/ko-KR/api/pricing/ / Azure OpenAI 요금 페이지)
RAG 호출 빈도가 높은 서비스라면, 마이그레이션 전에 월 예상 File Search 툴 콜 수를 먼저 뽑아 두는 게 좋습니다. 예를 들어 월 10만 건 File Search 호출이라면 Responses API 전환 후 툴 콜 비용만 $250이 새로 붙습니다. 캐시 절감분과 상쇄되는지 미리 계산해야 합니다.
상태 관리 전략 3가지 — 선택 기준이 다릅니다
Assistants API가 Threads로 상태를 고정 구조화했다면, Responses API에서는 팀이 직접 전략을 골라야 합니다. 세 가지 선택지가 있고, 각각 적합한 워크로드가 다릅니다. 섞어 쓰면 문제가 생깁니다 — conversation과 previous_response_id를 동시에 넘기면 API 오류가 납니다.
Conversations API
Thread와 가장 유사한 방식입니다. openai.conversations.create()로 대화 객체를 만들고 Responses 호출 시 conversation: id로 연결합니다.
적합 워크로드: 장기 지원·상담 워크플로
previous_response_id 체이닝
이전 Response ID를 다음 요청에 넘겨 컨텍스트를 이어갑니다. 앱 레벨에서 상태를 완전히 통제할 수 있습니다.
적합 워크로드: 단순 멀티턴, 결정론적 재현 필요
store: false
서버 측 저장을 끕니다. ZDR(Zero Data Retention) 요구사항이 있는 조직에 적합합니다. encrypted_content를 include에 추가하면 암호화된 추론 토큰을 다음 요청에 재활용 가능합니다.
적합 워크로드: 금융·의료 등 ZDR 필수 환경
💡 Conversations 항목의 보존 기한과 Response 객체의 보존 기한이 다릅니다 — Response 객체는 기본 30일 TTL이 적용되지만, Conversation에 연결된 items는 30일 TTL 없이 유지됩니다. (출처: OpenAI 커뮤니티 공식 FAQ, 2025.08.26) 두 개념을 혼동하면 이력이 갑자기 사라지는 것처럼 보이는 현상이 생깁니다.
지금부터 8월까지 움직이는 순서
공식 마이그레이션 플레이북(igor-ya.com, 2026.03.03)의 T-day 역산 스케줄을 바탕으로 정리했습니다. 한 가지만 주의하면 됩니다 — Thread 히스토리 자동 마이그레이션 도구는 제공되지 않습니다. OpenAI 공식 마이그레이션 가이드에 “We will not provide an automated tool for migrating Threads to Conversations”라고 직접 쓰여 있습니다. (출처: platform.openai.com/docs/assistants/migration)
인벤토리 확인
코드베이스에서 openai.beta.assistants, openai.beta.threads, openai.beta.threads.runs를 전수 검색합니다. 상태 전략을 워크로드별로 결정하고 문서화합니다.
프로토타입 & parity 검증
대시보드에서 Prompt 생성 후 핵심 워크플로를 Responses API로 포팅합니다. 단일 턴 → 멀티 턴 → RAG 검색 품질을 수치로 비교합니다. 이 단계에서 File Search 툴 콜 예상 비용도 뽑아둡니다.
카나리 배포
5% → 25% → 50% 순서로 트래픽을 전환합니다. 보존이 필요한 Thread 히스토리가 있다면 이 단계에서 Conversations API로 백필 스크립트를 실행합니다.
완전 전환 & 레거시 제거
Assistants API 엔드포인트 의존을 전부 제거합니다. 8월 26일 2주 전까지 완료를 목표로 잡아야 마지막 이슈 처리 버퍼가 생깁니다.
⚠️ Azure OpenAI를 쓰는 팀은 별도 일정입니다. Microsoft는 현재(2026.04 기준) Azure OpenAI에 별도 종료 일정을 요구하지 않는다고 밝혔습니다. 단, 이후 정책이 달라질 수 있으므로 Azure 공식 문서를 주기적으로 확인해야 합니다.
Q&A
Q1. 8월 26일 이후에도 그냥 기존 코드 두면 어떻게 되나요?
2026년 8월 26일 이후 /v1/assistants, /v1/threads 관련 모든 API 호출이 완전히 차단됩니다. 해당 엔드포인트에 의존하는 서비스는 즉시 장애가 납니다.
지금은 deprecated 상태라 동작하지만, 종료일 이후에는 요청 자체를 받지 않습니다. (출처: OpenAI 커뮤니티 공식 발표, 2025.08.26)
Q2. Responses API로 가면 Chat Completions API는 못 쓰게 되나요?
Chat Completions API는 계속 지원됩니다. OpenAI는 “Responses API는 Chat Completions의 슈퍼셋”이라고 설명하며, 두 API를 병행 운영하는 것도 가능합니다.
단, GPT-5.4부터 Chat Completions에서 reasoning: none 설정 시 tool calling이 지원되지 않는 제한이 추가됩니다. Responses API는 이 제한이 없습니다. (출처: OpenAI 마이그레이션 문서 “Additional differences” 항목)
Q3. 기존 Thread 대화 기록은 자동으로 옮겨지나요?
자동화 도구는 없습니다. 공식 가이드에 직접 명시돼 있습니다. Thread에서 메시지를 페이지 단위로 내보낸 뒤, Conversations API로 새 Conversation을 만들고 Items 형태로 백필하는 스크립트를 직접 작성해야 합니다.
공식 문서에 Python 예제가 포함돼 있습니다. (출처: platform.openai.com/docs/assistants/migration)
Q4. 전환이 어려운데 단기 대안은 없나요?
Ragwalla 같은 서드파티 서비스가 Assistants API 호환 엔드포인트를 제공합니다. 기존 코드에서 baseURL만 바꾸면 계속 동작합니다. 단기 브리지 전략으로는 쓸 수 있습니다.
단, Deep Research·MCP·Computer Use 같은 Responses API 전용 기능은 쓸 수 없습니다. 장기 해결책이 아닌 전환 기간 완충용으로만 고려해야 합니다.
Q5. Responses API 전환 후 정말 비용이 줄어드나요, 아니면 오르나요?
워크로드에 따라 다릅니다. 캐시 활용률 향상으로 토큰 비용은 내려갈 수 있습니다. 반면 File Search를 자주 호출하는 RAG 서비스라면 $2.50/1,000건의 툴 콜 비용이 새로 추가됩니다.
월 File Search 호출이 10만 건이라면 툴 콜 비용만 $250이 신규 발생합니다. 캐시 절감분과 상쇄 여부를 먼저 계산하는 게 순서입니다. (출처: OpenAI 공식 요금 페이지, openai.com/ko-KR/api/pricing/)
마치며
솔직히 말하면, 이 마이그레이션에서 가장 위험한 판단은 “아직 동작하니까 나중에 하면 된다”입니다. 지금 Assistants API가 멀쩡히 동작한다는 사실과 8월 26일 이후에는 작동하지 않는다는 사실이 동시에 맞습니다.
D-146에서 실제 전환 여유는 3~4개월입니다. 카나리 배포·parity 검증·롤백 드릴까지 챙기면 넉넉하지 않습니다. 특히 Thread 히스토리 자동 이전 도구가 없다는 점, Prompt가 API로 생성이 안 된다는 점은 공식 문서에 이미 명시돼 있는데 많은 팀이 사전에 인지하지 못합니다.
반대로 지금 제대로 전환하면 캐시 효율 개선, MCP·Computer Use·Deep Research 내장 도구 활용, 구조화된 Prompt 버전 관리를 한 번에 챙길 수 있습니다. 가장 현실적인 첫걸음은 코드베이스에서 openai.beta가 들어간 라인을 전수 검색하는 것입니다.
본 포스팅 참고 자료
- OpenAI 공식 Assistants → Responses 마이그레이션 가이드 — platform.openai.com/docs/assistants/migration
- OpenAI 커뮤니티 공식 deprecation 발표 (2025.08.26) — community.openai.com
- OpenAI 에이전트 빌딩 툴 발표 (2025.03.11) — openai.com
- OpenAI 공식 요금 페이지 — openai.com/ko-KR/api/pricing/
- Assistants to Responses API Migration Playbook, igor-ya.com (2026.03.03) — igor-ya.com
본 포스팅 작성 이후 OpenAI 서비스 정책·UI·기능이 변경될 수 있습니다. 수록된 API 요금·엔드포인트·종료 일정은 2026년 4월 2일 기준이며, 최신 정보는 platform.openai.com에서 확인하시기 바랍니다.
댓글 남기기