OpenAI 공식 발표 기준 · 2026.03.29 작성
Assistants API 종료,
Chat Completions도 같이 끝날까요?
결론부터 말씀드리면, Chat Completions는 종료되지 않습니다. 하지만 Assistants API 의존 코드를 그대로 두면 2026년 8월 26일 이후 서비스가 즉시 장애납니다. 엔드포인트만 바꾸는 수준의 작업이 아닙니다.
Chat Completions는 종료 안 됩니다 — 많은 팀이 헷갈리는 지점
OpenAI Assistants API 종료 소식이 퍼지면서 “이제 OpenAI API 전체를 바꿔야 하나”라는 반응이 적지 않습니다. 실제로는 다릅니다. Chat Completions API는 계속 지원됩니다. OpenAI는 공식 마이그레이션 문서에서 “Responses API는 Chat Completions의 슈퍼셋이며, Chat Completions는 계속 지원된다”고 명시하고 있습니다. (출처: OpenAI 공식 마이그레이션 문서, platform.openai.com/docs/guides/migrate-to-responses)
종료 대상은 openai.beta.assistants, openai.beta.threads, openai.beta.threads.runs 엔드포인트에 한정됩니다. 2025년 8월 26일 deprecated 선언, 2026년 8월 26일 완전 차단입니다. (출처: OpenAI 공식 커뮤니티 발표, 2025.08.26)
💡 공식 발표 흐름과 실제 엔드포인트 목록을 같이 놓고 보니 이게 보였습니다. Chat Completions를 쓰는 기존 코드는 전혀 영향을 받지 않습니다. Assistants API의 /v1/assistants와 /v1/threads만 8월 26일부터 요청을 거부합니다.
다만 GPT-5.4부터 Chat Completions에서 reasoning: none 설정 시 tool calling이 차단됩니다. Responses API에는 이 제한이 없습니다. Chat Completions를 계속 쓰더라도, 추론 모델 기반 도구 호출이 필요한 워크플로라면 결국 Responses API가 필요해집니다. (출처: OpenAI 마이그레이션 문서 “Additional differences” 항목)
객체 4개가 통째로 바뀝니다 — Threads는 어디로 갔나
이번 전환에서 핵심 객체 4개가 전부 이름과 동작 방식이 달라집니다. 이름만 바뀐 게 아닙니다. 각 객체의 역할 경계 자체가 재설계됐습니다. 공식 마이그레이션 가이드에 나온 대응 관계를 확인했습니다. (출처: OpenAI 공식 마이그레이션 가이드, platform.openai.com/docs/assistants/migration)
| Assistants API (구) | Responses 스택 (신) | 달라진 핵심 |
|---|---|---|
| Assistant | Prompt | API로 생성 불가 → 대시보드에서만 생성, 버전 관리 가능 |
| Thread | Conversation | 메시지만 저장 → 메시지·툴 콜·출력 등 Items로 통합 |
| Run | Response | 비동기 폴링 → 동기 입출력, 툴 루프 직접 제어 |
| Run steps | Items | 메시지·툴 콜·출력 모두 Items 타입으로 통일 |
여기서 가장 놓치기 쉬운 지점은 Prompt(구 Assistant)를 이제 API로 생성할 수 없다는 점입니다. OpenAI 공식 커뮤니티에서도 여러 개발자가 “이게 feature parity가 아닌 구조적 변화”라고 지적했습니다. 코드에서 Assistant를 동적으로 생성하던 팀에게는 단순 리팩터링이 아닙니다. 대시보드에서 Prompt를 미리 만들고 ID를 소스코드에 명시하는 방식으로 전체 워크플로를 다시 설계해야 합니다.
Run의 비동기 폴링 구조가 사라지는 것도 체감 변화가 큽니다. 기존 Assistants API는 Run을 생성한 뒤 `queued → in_progress → completed` 상태를 반복 폴링했습니다. 생산 코드에서는 이 폴링 루프가 복잡하게 얽혀 있는 경우가 많습니다. Responses API는 단일 호출로 입출력을 처리하기 때문에, 폴링 로직 전체를 걷어내야 합니다.
Thread 히스토리, 자동으로 못 옮깁니다
“Thread에 쌓인 대화 기록은 자동으로 Conversations로 이전되겠지”라고 생각하기 쉬운데, 막상 해보면 다릅니다. OpenAI 공식 마이그레이션 가이드에는 이 문장이 그대로 나옵니다: “We will not provide an automated tool for migrating Threads to Conversations.” 직접 스크립트를 짜야 합니다. (출처: platform.openai.com/docs/assistants/migration)
⚠️ 보존이 필요한 Thread 히스토리가 있다면 지금 바로 내보내기를 시작해야 합니다.
8월 26일 이후에는 /v1/threads 자체가 차단되기 때문에 그때는 조회도 불가합니다.
공식 가이드가 제시한 백필 방법은 다음과 같습니다. Thread에서 메시지를 페이지 단위로 꺼내고(openai.beta.threads.messages.list), 각 메시지를 Responses API Items 형식으로 변환한 뒤, openai.conversations.create(items=items)로 새 Conversation에 주입합니다. Python 예제가 공식 문서에 포함돼 있습니다. (출처: platform.openai.com/docs/assistants/migration)
실제로 고객사 프로덕션에서 이 마이그레이션을 진행한 한 시니어 개발자 사례에서는, Thread 메시지 변환 시 이미지·멀티모달 콘텐츠 타입 처리가 텍스트와 다르게 작동해 별도 분기 로직이 필요했습니다. 텍스트만 쌓인 Thread와 파일이 첨부된 Thread는 Items 형식이 다릅니다. 단순 반복문으로 끝나지 않을 수 있습니다. (출처: Medium, From Deprecated to Optimized, 2025.09.02)
Responses API가 더 빠르고 싼 이유 — 숫자로 확인했습니다
“새 API니까 당연히 낫겠지”라고 넘기기 전에 숫자를 보면 실감이 달라집니다. OpenAI 내부 테스트 기준, Responses API의 캐시 활용률은 Chat Completions 대비 40%~80% 향상됩니다. (출처: OpenAI 공식 마이그레이션 문서, platform.openai.com/docs/guides/migrate-to-responses)
💡 캐시 활용률 수치와 OpenAI 과금 구조를 같이 놓고 보니 이게 보였습니다. 캐시된 입력 토큰은 표준 요금보다 훨씬 낮게 과금됩니다. 호출 빈도가 높은 에이전틱 워크플로에서는 캐시 적중 하나하나가 직접 비용 절감으로 연결됩니다.
SWE-bench 기준으로도 수치가 나옵니다. GPT-5 추론 모델을 Responses API로 사용하면 Chat Completions 동일 조건 대비 3% 성능 향상이 확인됐습니다. (출처: OpenAI 공식 마이그레이션 문서) 3%가 작아 보일 수 있지만, 코딩 자동화나 대규모 문서 처리처럼 반복 호출이 많은 워크플로에서는 누적 차이가 납니다.
구조 변화도 있습니다. Assistants API의 Run은 상태를 OpenAI 서버에 위임해 비동기로 처리했습니다. 그래서 “Run 생성 → 폴링 → 상태 확인 → 메시지 조회”라는 여러 번의 왕복 호출이 필요했습니다. Responses API는 단일 호출로 입출력을 처리합니다. 한 번 시에 실제 응답 지연을 측정한 팀에서 60% 응답 속도 개선을 보고한 사례가 있습니다. (출처: Medium, From Deprecated to Optimized, 2025.09.02)
마이그레이션 후 비용이 오르는 경우가 있습니다
“캐시 활용률이 올라가니 비용은 줄겠지”라고 계산하기 쉬운데, 한 방향만 보면 안 됩니다. Responses API에서 내장 도구를 쓰면 툴 콜 단위 추가 과금이 붙습니다. Assistants API에서는 별도로 청구되지 않던 항목입니다. (출처: OpenAI 공식 API 요금 페이지, openai.com/api/pricing)
| 도구 | 과금 항목 | 단가 (공식 기준) |
|---|---|---|
| File Search | 스토리지 (1GB 초과) | $0.10/GB/일 |
| File Search | 툴 콜 (Responses API 한정, 신규) | $2.50/1,000건 |
| Web Search | 툴 콜 | 약 $10/1,000건 + 검색 콘텐츠 토큰 |
| Code Interpreter | 컨테이너 세션 | $0.03/1GB 컨테이너 |
RAG 호출이 잦은 서비스라면 특히 체크해야 합니다. File Search 툴 콜은 Responses API에서만 별도로 $2.50/1,000건이 붙습니다. 하루 1만 건 RAG 호출이 있다면 월 File Search 툴 콜 비용만 약 $750이 추가로 발생합니다. 마이그레이션 전에 현재 월 RAG 호출 수를 먼저 뽑는 이유가 여기 있습니다.
반대로 내장 Web Search나 MCP처럼 Responses API 전용 기능을 쓰면 기존에 직접 구현하던 외부 API 연동 비용이 줄어들 수 있습니다. 도구별로 득실을 별도로 계산해야 합니다. 전체 비용이 줄어든다는 가정으로 마이그레이션에 착수하면 청구서를 받고 놀랄 수 있습니다.
상태 관리 전략 3가지 — 섞으면 사고납니다
Assistants API는 Threads 하나로 상태 관리를 고정했습니다. Responses API는 전략을 직접 골라야 합니다. 어떤 전략을 쓰느냐보다 “이 워크로드는 어떤 전략을 쓴다”는 것을 명시적으로 결정하고 문서화하는 게 먼저입니다. 섞어 쓰면 API 오류가 납니다.
Conversations API
Thread와 가장 유사한 방식입니다. openai.conversations.create()로 대화 객체를 만들고 Responses 호출 시 conversation: id로 연결합니다. Conversation items는 Response 객체의 기본 30일 TTL과 달리, 별도 만료 기한 없이 유지됩니다. (출처: OpenAI 커뮤니티 발표, 2025.08.26)
previous_response_id 체이닝
이전 Response의 ID를 다음 요청에 넘겨 컨텍스트를 이어갑니다. 상태를 앱에서 완전히 통제하고 싶을 때 적합합니다. 단, conversation 파라미터와 동시 사용 불가입니다. 두 방식을 한 요청에 같이 쓰면 API 오류가 납니다.
store: false + 암호화 추론
Zero Data Retention(ZDR) 요구사항이 있는 조직에 필요합니다. store: false로 서버 저장을 끄되, include에 reasoning.encrypted_content를 추가하면 암호화된 추론 토큰을 받아 다음 요청에 재활용할 수 있습니다. 서버에는 아무것도 기록되지 않습니다. (출처: OpenAI 마이그레이션 문서 “Decide when to use statefulness” 항목)
RAG 기반 서비스라면 ①이, 세션 단위 단기 대화라면 ②가, 금융·법률 같이 데이터 잔류 규제가 있는 환경이라면 ③이 맞습니다. 가장 피해야 할 패턴은 ①과 ②를 한 코드베이스에서 조건부로 섞어 쓰는 것입니다. 스테이징에서는 통과해도 실트래픽 패턴에서 터집니다.
지금부터 8월 26일까지 움직여야 할 순서
지금(2026년 3월 말) 기준으로 D-150 정도 남아 있습니다. 5개월처럼 보이지만, parity 검증·카나리 배포·롤백 드릴을 포함하면 여유가 없습니다. 공식 마이그레이션 플레이북을 참고해 한국 팀 규모에 맞게 정리했습니다. (참고: igor-ya.com, Assistants to Responses API Migration Playbook, 2026.03.03)
지금 ~ 4월 / 인벤토리 확인
코드베이스에서 openai.beta.assistants, openai.beta.threads, openai.beta.threads.runs를 전수 검색합니다. 상태 관리 전략(①②③)을 워크로드별로 결정하고 문서화합니다. 보존이 필요한 Thread 히스토리도 이 시점에 목록화합니다.
4월 ~ 5월 / 프로토타입 & parity 검증
대시보드에서 Prompt 생성, 핵심 워크플로 Responses API 포팅, 단일 턴 → 멀티 턴 → RAG 검색 품질을 수치로 비교합니다. File Search 툴 콜 월 예상 비용도 이 단계에서 뽑습니다.
5월 ~ 6월 / 카나리 배포
5% → 25% → 50% 순서로 트래픽을 전환합니다. 보존이 필요한 Thread 히스토리가 있다면 Conversations API 백필 스크립트를 이 단계에서 실행합니다.
7월 ~ 8/12 / 완전 전환 & 레거시 제거
Assistants API 엔드포인트 의존을 전부 제거합니다. 8월 26일 2주 전 완료를 목표로 잡아야 마지막 이슈를 처리할 버퍼가 생깁니다. 마감 당일 전환은 위험합니다.
💡 실제 마이그레이션을 진행한 팀들의 공통된 실패 패턴을 보니 이런 흐름이 보였습니다. 스트리밍 컨슈머를 가장 마지막에 교체하다 실트래픽에서 장애를 냈습니다. Responses API의 스트리밍은 SSE 기반이며, 이벤트 순서와 취소 로직이 Assistants API와 다릅니다. 백엔드 호출만 바꾸고 클라이언트 파서를 그대로 두면 부하 상황에서 스트림이 깨집니다.
당장 전환이 어렵다면 서드파티 호환 레이어(Ragwalla 등)를 단기 브리지로 쓸 수 있습니다. baseURL만 바꾸면 기존 코드가 계속 동작합니다. 단, Deep Research·MCP·Computer Use 같은 Responses API 전용 기능은 쓸 수 없습니다. 장기 해결책이 아닌 전환 기간 완충용으로만 고려해야 합니다. (출처: ragwalla.com, Assistants API Deprecation Migration Guide, 2026.01.28)
Q&A
마치며
솔직히 말하면, 이 마이그레이션에서 가장 위험한 태도는 “아직 동작하니까 나중에 하지”입니다. 지금 Assistants API가 동작한다는 사실과 8월 26일 이후 완전히 작동하지 않는다는 사실이 동시에 맞습니다. D-150에서 실제 전환 여유는 3~4개월이고, 카나리 배포·parity 검증·롤백 드릴을 포함하면 넉넉하지 않습니다.
한편으로는 이 전환이 기회이기도 합니다. 캐시 효율 개선, Deep Research·MCP·Computer Use 내장 도구 활용, 구조화된 Prompt 버전 관리를 한 번에 챙길 수 있습니다. 실제로 이미 마이그레이션을 완료한 팀에서는 응답 속도 60% 향상, 비용 40~60% 절감이 나왔습니다. (출처: Medium, From Deprecated to Optimized, 2025.09.02) 비용과 코드베이스가 동시에 개선됩니다.
지금 당장 할 수 있는 가장 현실적인 첫걸음은 코드베이스에서 openai.beta로 시작하는 호출을 전수 검색하는 것입니다. 규모를 파악하는 것만으로도 다음 단계 계획이 훨씬 구체적으로 잡힙니다.
📎 본 포스팅 참고 자료
- OpenAI 공식 Assistants → Responses 마이그레이션 가이드 — platform.openai.com/docs/assistants/migration
- OpenAI 공식 Chat Completions vs Responses API 비교 문서 — platform.openai.com/docs/guides/responses-vs-chat-completions
- OpenAI 커뮤니티 공식 deprecation 발표 (2025.08.26) — community.openai.com
- Medium, From Deprecated to Optimized — Production Migration (2025.09.02) — medium.com
- OpenAI 공식 API 요금 페이지 — openai.com/api/pricing
본 포스팅 작성 이후 OpenAI 서비스 정책·UI·기능이 변경될 수 있습니다. 수록된 API 요금·엔드포인트·종료 일정은 2026년 3월 29일 기준이며, 공식 플랫폼(platform.openai.com)에서 최신 정보를 확인하시기 바랍니다.
댓글 남기기