종료 일정과 지금 당장 확인해야 할 것

OpenAI는 2025년 8월 26일, Assistants API를 공식 deprecated 선언했습니다. 공식 커뮤니티 발표문에는 이렇게 적혀 있습니다. “It will sunset one year from now, August 26, 2026.” 정확히 1년 유예. 발표 당시 Responses API가 Assistants API와 기능 동등성(feature parity)을 달성했다고 이유를 밝혔습니다.

지금 서비스에서 Assistants API를 쓰고 있다면 확인할 게 있습니다. 코드 안에 openai.beta.threads 또는 openai.beta.assistants라는 패턴이 있다면 Assistants API를 쓰고 있는 겁니다. 이 코드는 2026년 8월 26일 이후 호출하면 에러가 납니다.

▲ 목차로 돌아가기

Responses API, 더 좋다는 말이 숫자로 맞는지 확인했습니다

OpenAI 공식 문서에는 Responses API의 성능 우위를 구체적인 수치로 명시하고 있습니다. 공식 비교 가이드에 따르면, 캐시 활용률이 Chat Completions 대비 40~80% 개선됐고, GPT-5 같은 추론 모델을 같은 프롬프트·설정으로 사용할 때 SWE-bench 벤치마크에서 3% 성능 향상이 확인됐습니다. (출처: OpenAI 공식 문서 Responses vs Chat Completions, 2026.03 기준)

캐시 효율 40~80%는 실제 청구 비용에 직접 영향을 줍니다. 같은 대화 맥락을 반복 처리하는 챗봇·에이전트 서비스라면 월 API 비용이 눈에 띄게 줄어듭니다.

(출처: OpenAI 공식 문서 — responses-vs-chat-completions, assistants/migration / 2026.03 기준)

▲ 목차로 돌아가기

전환하면 막히는 지점 3가지 — 공식 커뮤니티 실제 사례

OpenAI가 “feature parity 달성했다”고 선언했지만, 실제로 전환을 시도한 개발자들의 반응은 달랐습니다. 공식 커뮤니티 스레드(2025.08.26 발표 이후)에서 직접 확인한 내용입니다.

① Prompt는 API로 만들 수 없습니다

Assistants API에서 Assistant 객체는 API 호출로 동적으로 생성할 수 있었습니다. 반면 후속 개념인 Prompt는 OpenAI 대시보드 UI에서만 만들 수 있습니다. (출처: OpenAI 공식 마이그레이션 문서, 2026.03) 동적으로 수백 개의 Assistant를 생성해서 운영하던 서비스라면 아키텍처 자체를 바꿔야 합니다.

② Truncation 로직을 직접 짜야 합니다

Assistants API는 대화 길이를 자동으로 잘라주는 truncation 기능이 있었습니다. Responses API에는 이 기능이 없습니다. 긴 대화를 처리하는 서비스는 컨텍스트 윈도우 한도 관리 코드를 직접 작성해야 합니다. 커뮤니티에서 “이 부분만큼은 Assistants가 나았다”는 피드백이 가장 많이 나온 항목입니다.

③ ZDR(Zero Data Retention) 환경은 별도 대응 필요

데이터 보존 정책이 엄격한 기업(의료, 금융, 법률 등) 환경에서는 Responses API를 stateful하게 사용할 수 없습니다. store: false로 설정하고 reasoning.encrypted_content를 include에 추가하는 방식으로 암호화된 추론 상태를 전달해야 합니다. (출처: OpenAI 공식 문서 responses-vs-chat-completions, 2026.03)

▲ 목차로 돌아가기

Thread → Conversation 이전, 자동 도구가 없습니다

마이그레이션에서 가장 현실적인 부담은 기존 Thread 데이터를 옮기는 작업입니다. OpenAI 공식 마이그레이션 문서에는 이렇게 나옵니다. “We will not provide an automated tool for migrating Threads to Conversations.” 자동화 도구를 제공하지 않겠다는 뜻입니다. 직접 코드를 짜서 백필(backfill) 해야 합니다.

권장 방식은 신규 유저 대화는 Conversation으로 바로 받고, 기존 Thread는 필요한 것만 선별해서 수동으로 변환하는 겁니다. 아래가 공식 문서에 나온 Thread → Conversation 변환 코드 패턴입니다.

# Thread의 메시지를 읽어서 Conversation으로 변환
for page in openai.beta.threads.messages.list(
thread_id=thread_id, order="asc"
).iter_pages():
messages += page.data
items = []
for m in messages:
item = {"role": m.role}
item_content = []
for content in m.content:
if content.type == "text":
item_content_type = (
"input_text" if m.role == "user" else "output_text"
)
item_content += [{"type": item_content_type,
"text": content.text.value}]
item |= {"content": item_content}
items.append(item)
# Conversation 생성
conversation = openai.conversations.create(items=items)

(출처: OpenAI 공식 마이그레이션 가이드 — platform.openai.com/docs/assistants/migration, 2026.03)

▲ 목차로 돌아가기

Responses API가 Chat Completions보다 나은 이유

Assistants API를 쓰던 서비스라면 Responses API로 가야 하지만, Chat Completions를 쓰던 서비스라면 어떻게 해야 할까요? OpenAI는 “새 프로젝트는 Responses API를 쓰라”고 권고하고 있습니다. Chat Completions는 계속 지원하지만, 신기능은 Responses API에만 들어옵니다.

공식 문서에서 확인한 가장 실질적인 차이는 멀티턴 대화 처리 방식입니다. Chat Completions는 매 요청마다 전체 대화 히스토리를 수동으로 붙여서 보내야 합니다. Responses API는 store: true로 설정하면 서버가 컨텍스트를 유지해줍니다. 대화가 길어질수록 Chat Completions 방식은 매 요청마다 페이로드가 커집니다. Responses는 그렇지 않습니다.

또한 GPT-5.4 이상에서 tool calling을 쓰려면 Responses API가 사실상 필수입니다. 공식 문서에 “GPT-5.4부터 Chat Completions에서 reasoning:none 설정 시 tool calling이 지원되지 않는다”고 나와 있습니다. (출처: OpenAI 공식 문서, 2026.03) 최신 추론 모델과 툴을 함께 쓸 계획이라면 전환은 선택이 아닙니다.

▲ 목차로 돌아가기

실제 전환 팀의 결과 — 60% 빠르고 40~60% 저렴해졌습니다

2025년 9월에 공개된 실사용 마이그레이션 사례(Salesforce 개발자 팀)를 보면 Assistants API에서 Chat Completions(이후 Responses API)로 전환한 뒤 응답 속도 60% 개선, API 비용 40~60% 절감을 달성했습니다. (출처: Medium — “From Deprecated to Optimized”, 2025.09.02) 이 수치가 모든 서비스에 그대로 적용되지는 않겠지만, 전환의 방향성은 분명합니다.

이 팀이 비용을 줄인 핵심은 “쿼리 복잡도에 따라 다른 모델을 쓰는” 동적 모델 선택이었습니다. 간단한 FAQ 응답에는 가벼운 모델을, 복잡한 분석에만 프리미엄 모델을 붙인 겁니다. Assistants API의 고정된 Assistant 설정으로는 이렇게 하기 어렵습니다. Responses API는 요청마다 모델을 바꿀 수 있어서 이 전략이 자연스럽게 가능합니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

솔직히 말하면, Assistants API는 처음 나왔을 때 꽤 편리했습니다. Thread 관리, Run 실행, 파일 업로드까지 한 번에 묶어놨으니까요. 그런데 써보면 금방 한계가 보였습니다. 폴링 방식의 느린 응답, 불투명한 상태 관리, 그리고 생각보다 올라가는 비용.

Responses API로의 전환이 불편한 건 맞습니다. 특히 Thread를 수백 개 이상 운영하던 서비스라면 데이터 이전 작업만 해도 적지 않은 시간이 필요합니다. 하지만 남은 5개월을 “언젠가 해야지”로 흘려보내는 건 더 위험합니다.

지금 당장 코드베이스에서 openai.beta를 검색해보세요. 몇 줄이나 나오는지 확인하는 것부터가 시작입니다.

📚 본 포스팅 참고 자료

1. OpenAI 공식 문서 — Responses vs Chat Completions: platform.openai.com/docs/guides/responses-vs-chat-completions
2. OpenAI 공식 마이그레이션 가이드: platform.openai.com/docs/assistants/migration
3. OpenAI 커뮤니티 공식 발표 — Assistants API beta deprecation August 26, 2026 sunset: community.openai.com
4. 실사용 마이그레이션 사례 — From Deprecated to Optimized (Medium, 2025.09.02): medium.com/@gjasula