Responses API 기준
⚠️ 2026.08.26 종료
OpenAI Assistants API 종료,
3가지 비용 함정 확인했습니다
결론부터 말씀드리면, Responses API로 옮겨야 하는 건 맞습니다. 그런데 공식 마이그레이션 가이드에 나오지 않는 비용 구조 변화가 있어서, 그냥 API 엔드포인트만 바꿨다가 청구서 받고 놀라는 경우가 생깁니다. 공식 문서와 실제 사용 후기를 교차 확인한 내용을 정리했습니다.
Assistants API가 정확히 언제, 어떻게 꺼지나요?
OpenAI가 Assistants API의 deprecated 공지를 낸 건 2025년 8월 26일입니다. 그로부터 정확히 1년 후인 2026년 8월 26일에 서비스가 종료됩니다. (출처: OpenAI 공식 Deprecations 페이지)
종료 이후에는 /v1/assistants, /v1/threads, /v1/runs 엔드포인트 전체에 대한 호출이 막힙니다. Chat Completions API(/v1/chat/completions)는 계속 지원되므로, 혼동하지 않도록 주의해야 합니다.
현재 기준(2026.03.18)으로 종료까지 약 161일이 남았습니다. 프로덕션 시스템을 운영 중이라면 지금 당장 마이그레이션 일정을 잡아두는 게 맞습니다.
Responses API로 뭐가 달라지는 건가요?
Assistants API는 Assistant → Thread → Run 세 개의 객체를 오가는 구조였습니다. 이게 꽤 번거로웠는데, Responses API는 이를 단일 호출로 단순화했습니다. 입력 아이템을 넣으면 출력 아이템이 나오는 방식입니다.
| Assistants API (구) | Responses API (신) | 변경 이유 |
|---|---|---|
Assistants |
Prompts |
버전 관리·스냅샷 지원 |
Threads |
Conversations |
메시지만 아닌 tool call 등 모든 아이템 저장 |
Runs |
Responses |
폴링 없이 단일 호출로 결과 반환 |
Run steps |
Items |
메시지·tool call·출력 결과를 동일한 타입으로 통일 |
Responses API는 deep research, remote MCP, computer use 같은 신규 기능이 계속 추가되고 있고, 내부 테스트 기준 캐시 활용률이 Chat Completions 대비 40~80% 개선된다고 OpenAI가 공식 문서에 명시하고 있습니다. 단순히 “오래된 걸 끄는 게 아니라” 에이전트 방향성을 Responses로 통일하는 과정입니다. (출처: OpenAI 공식 마이그레이션 가이드)
여기서 돈이 빠져나갑니다 — file_search 과금 구조
솔직히 이게 가장 중요한 내용입니다. OpenAI 공식 요금 페이지를 보면 이런 항목이 있습니다.
💡 공식 요금표와 실제 청구서를 같이 놓고 보니 이런 차이가 보였습니다
Assistants API의 file_search(구 retrieval)는 도구 호출 건당 별도 과금이 없었습니다. 그런데 Responses API에서는 file_search 도구 호출 1,000건당 $2.50가 추가됩니다. 공식 요금 페이지에 “(Responses API only)”라고 명시돼 있습니다. (출처: OpenAI API Pricing 페이지)
이게 얼마나 큰 차이인지 실제로 계산해보면 더 명확해집니다. RAG 기반 챗 서비스에서 gpt-4o-mini를 쓰고 질문당 입력 토큰을 약 30,000개 사용한다고 가정하면, 질의 1,000건 기준 토큰 비용은 $0.15/백만 토큰 × 30M = 약 $4.50입니다. 여기에 file_search 도구 호출 비용 $2.50이 더해지면 총 $7.00이 됩니다. Assistants API 기준($4.50)과 비교하면 실효 비용이 약 56% 증가하는 셈입니다.
이 수치는 실제로 RAG 앱을 운영하다가 Responses API로 전환한 개발자가 OpenAI 커뮤니티에 공개한 분석과 일치합니다. 해당 개발자는 “sneaky way of increasing the effective price by 50%”라고 표현했고, OpenAI 측에서는 별도 공지 없이 요금 페이지에만 표기해둔 상태입니다. (출처: OpenAI Developer Community, 2025.03)
주의: file_search를 쓰지 않는 단순 대화형 앱이라면 이 추가 비용은 발생하지 않습니다. RAG나 파일 검색 기능을 사용하는 앱에서만 해당합니다. 앱 아키텍처를 먼저 확인하는 게 순서입니다.
비용을 통제하려면 tool_choice 파라미터로 file_search 호출을 필요한 경우에만 제한하거나, 벡터 스토어 쿼리 횟수 자체를 줄이는 구조 개선이 필요합니다. “그냥 이전하면 된다”는 생각으로 접근하면 막상 청구서에서 처음 보는 항목을 만나게 됩니다.
Thread 이전, OpenAI가 대신 해줄 거라고요?
마이그레이션 공지를 보면서 많은 개발자들이 “Thread를 Conversation으로 자동으로 옮겨주는 도구가 있겠지”라고 기대하는 경우가 많습니다. 막상 공식 문서를 열어보면 이런 문장이 있습니다.
💡 공식 발표문과 실제 작업 범위를 같이 놓고 보니 이런 차이가 보였습니다
“We will not provide an automated tool for migrating Threads to Conversations. Instead, we recommend migrating new user threads onto conversations and backfilling old ones as necessary.”
(출처: OpenAI 공식 마이그레이션 문서)
즉, Thread → Conversation 이전은 전적으로 개발자 몫입니다. OpenAI가 제공하는 건 코드 샘플뿐이며, 실제로 기존 대화 히스토리를 Thread에서 꺼내 Conversation 형식으로 재구성하는 작업을 직접 구현해야 합니다.
이게 실제로 어느 정도의 작업인지 공식 문서의 예시 코드를 보면 감이 옵니다. Thread 메시지를 순서대로 꺼내, 각 role에 맞게 input_text와 output_text로 변환해 Conversation을 재생성하는 로직이 필요합니다. Thread 수가 수만 건이 넘는 앱이라면 백필 작업만으로도 상당한 공수가 들 수 있습니다.
하나의 현실적인 접근은, 기존 Thread는 2026년 8월 26일 이전에는 그대로 두고 새로 생성되는 대화 흐름만 Conversations API로 전환한 다음, 필요한 과거 Thread는 점진적으로 백필하는 방식입니다. 이것도 OpenAI가 권고하는 방법이기도 합니다.
Prompt 객체, API로 못 만듭니다
Assistants API에서 Assistant 객체는 API로 생성·수정이 자유로웠습니다. 배포 파이프라인에서 프로그래밍으로 Assistant를 만들고 교체하는 구조를 많이 사용했습니다. Responses API의 대응 개념은 Prompt인데, 여기서 막히는 지점이 있습니다.
💡 Assistants 문서와 Prompts 문서를 나란히 놓고 보니 이런 차이가 나왔습니다
공식 문서에 이런 표현이 있습니다: “Assistants were persistent API objects that bundled model choice, instructions, and tool declarations—created and managed entirely through the API. Their replacement, prompts, can only be created in the dashboard.” (출처: OpenAI 마이그레이션 문서)
Prompt 객체는 대시보드에서만 생성 가능합니다. API로는 기존 Prompt ID를 참조해서 사용하는 건 되지만, 새로 만들거나 programmatically 수정하는 건 안 됩니다. 이 의미는 기존에 CI/CD 파이프라인 안에서 Assistant를 자동 생성·교체하는 구조를 썼던 팀이라면 배포 방식을 다시 설계해야 한다는 뜻입니다.
OpenAI는 이를 “portability and versioning” 이점으로 설명하고 있습니다. 대시보드에서 스냅샷을 찍고 버전을 관리하는 방식이 더 안전하다는 논리입니다. 다만 완전 자동화 배포가 필요한 B2B 서비스 운영자 입장에서는 이 부분이 추가 작업으로 이어지는 건 사실입니다.
실제 마이그레이션 흐름 — 단계별 확인 사항
이론은 충분히 봤고, 실제로 어떤 순서로 진행하면 되는지 확인해봤습니다. OpenAI 공식 마이그레이션 가이드를 기반으로, 실제 사용자 경험에서 나온 주의 사항을 더했습니다.
기존 Assistant 객체를 Prompt로 전환
OpenAI 대시보드에서 기존 Assistant를 찾아 “Create prompt” 버튼을 누릅니다. 여기서 생성된 Prompt ID를 소스 코드에 저장해두면 됩니다. API가 아닌 대시보드 작업이므로 자동화 불가입니다.
신규 대화 흐름을 Conversations API로 전환
새로 생성되는 사용자 대화는 openai.conversations.create()로 시작하도록 코드를 바꿉니다. previous_response_id를 쓰는 방식도 가능하지만, 장기 대화에서는 Conversations API가 더 안정적입니다.
file_search 사용 여부 점검
RAG 기능 사용 중이라면 반드시 현재 file_search 호출 건수를 추산하고, 전환 후 추가 비용($2.50/1k건)을 사전에 계산해야 합니다. 앱 아키텍처에 따라 tool_choice로 호출을 제한하는 방안을 검토합니다.
함수 정의 형식 변경 주의
Responses API에서는 함수 정의가 외부 태그 방식에서 내부 태그 방식으로 바뀌었고, strict 옵션이 기본 활성화됩니다. 기존 함수 스키마를 그대로 복붙하면 예상치 못한 오류가 날 수 있어 검토가 필요합니다.
ZDR(Zero Data Retention) 요건 확인
데이터 보존 정책이 있는 엔터프라이즈 환경이라면 Responses API의 stateful 기능(Background mode 포함)을 사용할 수 없는 경우가 있습니다. store: false와 암호화된 reasoning 조합으로 stateless 운영이 가능하지만 추가 구성이 필요합니다.
실제로 Responses API로 전환을 완료한 개발자들의 후기를 보면, 코드 전환 자체는 2~4시간 수준으로 빠르게 끝나는 경우가 많습니다. 다만 file_search 비용 재계산, Thread 백필, Prompt 대시보드 작업이 ‘숨어있는 작업량’으로 나타납니다. 이 부분의 공수 추정이 빠지면 일정이 쫓기게 됩니다.
자주 묻는 질문
마치며
Responses API 자체는 잘 만든 API입니다. 구조가 단순하고 에이전트 기능이 강화됐습니다. 이전 방향은 맞습니다. 다만 “빨리 해야 하니까 엔드포인트만 바꾸자”는 식으로 접근하면 예상 밖의 항목이 생깁니다.
핵심 세 가지를 다시 정리하면, 첫째 file_search를 쓰는 RAG 앱은 Responses API 전환 후 도구 호출 비용이 추가됩니다. 규모에 따라 실효 비용이 50% 이상 오를 수 있습니다. 둘째 Thread → Conversation 자동 이전 도구는 없으며 수동 구현이 필요합니다. 셋째 Prompt 객체는 대시보드에서만 생성되므로 CI/CD 자동화 구조를 재검토해야 합니다.
161일이라는 시간이 길어 보일 수 있지만, 프로덕션 서비스 이전은 항상 예상보다 오래 걸립니다. 지금 일정을 잡아두는 것을 권합니다.
📚 본 포스팅 참고 자료
본 포스팅은 2026년 3월 18일 기준으로 작성되었습니다. OpenAI Assistants API 및 Responses API의 정책·요금·기능은 업데이트로 언제든지 변경될 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으므로, 중요한 의사결정 전 반드시 공식 문서를 직접 확인하시기 바랍니다.
댓글 남기기