종료 타임라인 — 지금까지 정확히 무슨 일이 있었나

Assistants API는 2024년 12월 18일 기준으로 v1 베타 접근이 중단됐고 v2만 운영됐습니다. 이후 OpenAI가 2025년 8월 26일 공식 deprecated 선언을 하면서 1년간의 마이그레이션 기간이 시작됐습니다. 종료일은 2026년 8월 26일로, 이 날 이후에는 /v1/assistants와 /v1/threads 엔드포인트로 보내는 요청이 모두 실패합니다. (출처: OpenAI 공식 플랫폼 문서, platform.openai.com)

솔직히 말하면, 5개월이라는 기간이 길게 느껴질 수도 있습니다. 그런데 RAG 구조나 멀티턴 대화 이력이 복잡하게 얽힌 서비스라면 지금 당장 시작해도 촉박한 일정입니다. Ragwalla의 마이그레이션 가이드(2026.01.28 기준)는 4~5월을 프로덕션 트래픽 점진적 전환 구간으로 잡고 있고, 7월 이후는 최종 Thread 데이터 백필과 마무리 검증에 써야 한다고 권고합니다.

▲ 목차로 돌아가기

Responses API가 더 저렴하다는 숫자의 근거

많은 개발자가 Responses API로 전환하면 비용이 더 올라갈 것이라고 예상합니다. 그런데 공식 내부 테스트 결과는 반대입니다. OpenAI 공식 문서(platform.openai.com/docs/guides/responses-vs-chat-completions)에는 이런 문장이 그대로 들어 있습니다.

캐시 효율이 40~80% 개선됐다는 건, 같은 대화 맥락을 반복 참조하는 멀티턴 챗봇 서비스에서는 토큰 비용이 실질적으로 줄어든다는 뜻입니다. 단, 이 수치는 내부 테스트 기준이고 서비스 구조나 프롬프트 설계에 따라 달라질 수 있습니다. 추가로 Tool 비용 구조도 바뀌었습니다.

File search를 많이 쓰는 RAG 서비스는 전환 후 Tool 호출 비용이 새로 붙을 수 있으니, 전환 전에 월간 호출 횟수를 먼저 뽑아보는 게 좋습니다. 캐시 절감이 Tool 비용 추가분보다 클지 서비스 구조에 따라 달라집니다.

▲ 목차로 돌아가기

Thread가 자동으로 이전되지 않는다는 것이 실제로 의미하는 것

Assistants API에서 Responses API로 바꾸면 기존 Thread 대화 기록이 자동으로 넘어올 것이라고 생각하기 쉽습니다. 그런데 OpenAI 공식 마이그레이션 가이드에 이 문장이 있습니다.

Thread 기록이 수백만 건 쌓인 서비스라면 이 부분이 마이그레이션에서 가장 손이 많이 가는 구간입니다. 대화 이력을 유지해야 하는 고객서비스 봇이나 개인화 챗봇이라면 지금 당장 기존 Thread 메시지를 export하는 코드부터 만들어야 합니다.

Thread 기록을 살리는 방법 — 공식 문서 기준 3단계

OpenAI 공식 마이그레이션 가이드에 나온 Thread 백필 흐름은 다음과 같습니다. Assistants API가 살아있는 지금 이 코드를 실행해서 데이터를 먼저 뽑아두는 것이 핵심입니다.

# 1. 기존 Thread 메시지 추출 (Python 예시)
thread_id = "thread_EIpHrTAVe0OzoLQg3TXfvrkG"
messages = []
for page in openai.beta.threads.messages.list(thread_id=thread_id, order="asc").iter_pages():
messages += page.data
# 2. items 형식으로 변환
items = []
for m in messages:
item = {"role": m.role}
item_content = []
for content in m.content:
if content.type == "text":
item_content.append({
"type": "input_text" if m.role == "user" else "output_text",
"text": content.text.value
})
item["content"] = item_content
items.append(item)
# 3. Conversations API로 새 Conversation 생성
conversation = openai.conversations.create(items=items)

주의할 점은 이미지나 파일이 첨부된 메시지가 포함된 Thread는 변환 로직이 더 복잡해진다는 것입니다. 텍스트만 있는 Thread부터 먼저 처리하고 멀티모달 Thread는 별도로 검증하는 순서가 안전합니다.

▲ 목차로 돌아가기

Assistants와 Responses, 구조가 어떻게 달라졌나

Assistants API에서 Responses API로의 전환은 단순한 엔드포인트 교체가 아닙니다. OpenAI 커뮤니티 포럼(2026.01.06)에서 나온 말이 핵심을 짚습니다. “API 교체가 아니라 아키텍처 변화로 생각하라.” 실제로 네 가지 핵심 개념이 통째로 바뀌었습니다.

Runs 폴링이 없어지는 것이 왜 중요한가

기존 Assistants API에서는 Run을 만들고 `while run.status in (“queued”, “in_progress”)` 루프를 돌리며 상태를 폴링해야 했습니다. Responses API에서는 이 폴링 루프가 사라지고 동기 방식으로 응답이 옵니다. 코드 구조가 단순해지지만, 기존 Runs 폴링 로직을 쓰던 곳은 전부 걷어내야 합니다.

또 Prompts(기존 Assistants 역할)는 API로 생성할 수 없고 반드시 대시보드에서만 만들어야 합니다. CI/CD 파이프라인에서 Assistant 객체를 프로그래밍 방식으로 생성하던 팀이라면 이 부분에서 작업 방식을 바꿔야 합니다.

▲ 목차로 돌아가기

지금 당장 해야 할 작업 vs 8월 전에 해야 할 작업

Ragwalla 마이그레이션 가이드(2026.01.28)는 현 시점 기준으로 남은 5개월을 4개 구간으로 나눕니다. 지금 이 가이드에서 제시한 타임라인과 오늘 날짜(2026.03.25)를 대조하면 현재 구간이 어디인지 파악할 수 있습니다.

지금 바로 Assistants 사용 현황부터 뽑아야 하는 이유

인벤토리 없이 마이그레이션을 시작하면 중간에 빠진 Assistant나 Thread를 발견하고 처음부터 다시 시작하는 경우가 생깁니다. 현재 프로젝트 내 모든 Assistant ID, Thread 수, 연결된 Vector Store, Tool 종류를 먼저 뽑아두는 것이 출발점입니다. OpenAI 대시보드 또는 `/v1/assistants` list API로 확인할 수 있습니다.

이 글에서 제안하는 실용적 접근: 신규 대화는 오늘부터 Conversations API로 받고, 기존 Thread는 월 단위로 배치 백필을 돌리는 방식이 가장 리스크가 적습니다. 이렇게 하면 8월 종료일이 와도 신규 트래픽은 이미 이전 완료 상태가 됩니다.

▲ 목차로 돌아가기

Thread 기록을 살리고 싶다면 지금 바로 해야 하는 이유

Responses API의 기본 Response 저장 보존 기간은 30일 TTL입니다. 반면 Conversations API로 생성한 Conversation은 이 30일 제한을 받지 않습니다. (출처: Ragwalla 마이그레이션 가이드, 2026.01.28) 대화 이력을 장기 보존해야 한다면 `store: true`로 Response를 저장하는 방식 대신 Conversations API를 써야 합니다. 이 두 가지가 같은 방식이라고 착각하면 나중에 기록이 사라진 것을 발견하게 됩니다.

한 가지 더 짚어둘 점은 previous_response_id와 conversation은 동시에 사용할 수 없다는 것입니다. OpenAI 공식 문서에 이 제한이 명시되어 있습니다. 어떤 방식으로 상태를 관리할지 설계 단계에서 결정해두지 않으면 나중에 코드를 이중으로 수정해야 합니다.

이 부분이 기존 블로그 대부분이 다루지 않은 지점입니다. “Responses API로 바꾸면 된다”는 말이 많지만, 어떤 상태 관리 방식을 선택하느냐가 실질적으로 아키텍처 전체를 바꾸는 결정입니다. 특히 RAG 서비스나 개인화 이력이 중요한 챗봇에서 이 선택이 나중에 빅이슈가 될 수 있습니다.

▲ 목차로 돌아가기

Q&A — 실제로 많이 나오는 질문 5가지

▲ 목차로 돌아가기

마치며

Assistants API 종료가 막연하게 알려진 것과 달리, 실제로 준비해야 할 작업이 꽤 구체적입니다. Thread 자동 이전 도구 없음, Prompt는 대시보드에서만 생성, Conversations와 previous_response_id 동시 사용 불가, 상태 관리 방식 3가지 중 하나를 먼저 결정해야 하는 것까지 — 이 중 하나라도 놓치면 8월 이후에 급하게 수습하는 상황이 됩니다.

개인적으로 가장 실질적인 첫 번째 액션은 지금 당장 /v1/assistants list API를 돌려서 프로젝트 내 Assistant 현황을 뽑아보는 것입니다. 몇 개인지, 어떤 Tool이 달려 있는지, Vector Store가 연결된 것은 몇 개인지 — 이것만 파악해도 마이그레이션 공수를 훨씬 정확하게 가늠할 수 있습니다.

Responses API는 단순히 Assistants API의 후속이 아니라, OpenAI가 에이전트 개발의 기본 단위로 삼겠다는 플랫폼 방향 전환입니다. 이 전환을 빨리 마치는 팀이 deep research, MCP, computer use 같은 신기능을 먼저 활용할 수 있습니다.

본 포스팅 참고 자료

1. OpenAI 공식 Responses vs Chat Completions 문서 — platform.openai.com/docs/guides/responses-vs-chat-completions
2. OpenAI 공식 Assistants Migration Guide — platform.openai.com/docs/guides/assistants/migration
3. Microsoft Learn — Azure OpenAI Assistants API 개념 문서 (2026.03.10) — learn.microsoft.com
4. Ragwalla — Assistants API Deprecation Migration Guide (2026.01.28) — ragwalla.com
5. OpenAI 에이전트 빌딩 새 도구 공식 발표 (2025.03.11) — openai.com