OpenAI Responses API
Assistants API 종료 D-158
Responses API, store 기본값이
비용을 바꿉니다
결론부터 말씀드리면, Assistants API는 2026년 8월 26일 완전 종료됩니다. 공식 문서에 종료 일정이 확정됐고, 이미 deprecated 상태입니다. 새로 시작하는 프로젝트라면 지금 바로 Responses API로 출발해야 하고, 기존 Assistants API 코드가 있다면 이 글에서 짚는 세 가지를 먼저 읽으세요.
Assistants API가 종료되는 진짜 이유
OpenAI는 2025년 8월 26일 Assistants API 공식 deprecated를 선언했고, 종료일은 2026년 8월 26일로 못 박았습니다. (출처: OpenAI 공식 문서)
왜 없애는 걸까요? 공식 발표문에 이유가 담겨 있습니다. 핵심은 Thread 구조의 비용 구조적 결함입니다. Assistants API에서 메시지를 보낼 때마다 스레드 전체, 파일 포함, 를 매번 재처리했습니다. 사용자가 20페이지짜리 PDF를 업로드하고 질문을 5번 던지면, 그 PDF는 5번 통째로 토큰 계산에 들어갑니다. 실제로 개발자 커뮤니티에서는 “세션이 길어질수록 비용이 기하급수적으로 불어난다”는 피드백이 쏟아졌고, 이게 OpenAI가 Responses API를 설계한 출발점입니다.
또 하나는 polling 의존성입니다. Assistants API는 응답이 완성될 때까지 반복 요청을 보내야 했는데, 스트리밍이 안 됐습니다. 타이핑 효과 하나 구현하려고 별도 래퍼를 짜야 했던 셈이죠. 써보셨으면 이 불편함이 뭔지 바로 아실 겁니다.
💡 공식 발표문과 개발자 피드백을 같이 놓고 보니 이런 흐름이 보였습니다. OpenAI가 Responses API를 만든 건 기능 추가가 아니라 비용 구조 자체를 고친 것입니다.
Responses API가 Chat Completions와 다른 점
Chat Completions API는 2023년 GPT-3 시절부터 쓰인 방식입니다. 메시지 배열 전체를 매 요청마다 붙여서 보내는 구조죠. 대화가 길어질수록 input 토큰이 선형으로 증가합니다. Responses API는 이 구조를 바꿨습니다.
OpenAI 공식 비교 문서에 이런 수치가 있습니다. 캐시 효율이 Chat Completions 대비 40~80% 개선됩니다. (출처: OpenAI Responses vs Chat Completions 공식 문서) 같은 대화 맥락을 서버 측에서 유지하기 때문에 매 요청마다 전체 히스토리를 재전송하지 않아도 됩니다. 대화가 길어질수록 이 차이는 더 커집니다.
구조 변화를 표로 정리했습니다.
| 항목 | Chat Completions | Responses API |
|---|---|---|
| 대화 히스토리 | 매 요청마다 전체 전송 | previous_response_id로 체이닝 |
| 툴 지원 | 외부 구현 필요 | 웹검색·파일검색·컴퓨터사용 기본 내장 |
| 상태 저장 | 기본 비저장 | store:true 기본 |
| 추론 모델 성능 | 기준 | SWE-bench +3%p (공식 내부 이밸) |
| MCP 지원 | 없음 | 원격 MCP 서버 연동 가능 |
Chat Completions는 당분간 계속 지원됩니다. 새 프로젝트라면 Responses API를 권장하지만, 이미 Chat Completions로 잘 돌아가는 코드를 억지로 바꿀 이유는 없습니다.
store:true 기본값, 비용에서 뭐가 달라지나
여기서 많은 분이 놓치는 부분이 있습니다. Responses API는 store:true가 기본값입니다. 요청할 때 따로 끄지 않으면 응답이 OpenAI 서버에 저장됩니다. (출처: OpenAI 공식 문서)
이게 왜 중요하냐면, 저장된 응답은 tracing과 evaluation 기능의 기반이 되는 동시에 데이터 보관 정책 검토 대상이 됩니다. 기업 환경에서 개인정보가 포함된 대화를 다룰 때 이걸 모르고 쓰면 컴플라이언스 이슈가 생길 수 있습니다. 비용 측면에서는 저장된 토큰이 캐시 입력 단가로 재사용되기 때문에 오히려 절감 효과가 생기는 구조이기도 합니다.
실제 수치를 보면, gpt-5.4 기준 일반 입력 토큰은 $2.50/1M이고, 캐시된 입력은 $0.25/1M으로 10분의 1 수준입니다. (출처: OpenAI 공식 가격 페이지, 2026.03.21 기준) 자주 반복되는 프롬프트가 있다면 캐시 히트율이 높아질수록 실제 청구 금액이 줄어듭니다.
💡 공식 가격표와 store 동작 방식을 같이 놓고 보면 이런 구조가 나옵니다. store:true를 켜두면 캐시 효율이 올라가고 비용이 내려가지만, 데이터 저장 문제는 별도로 판단해야 합니다. 끄려면 store:false를 명시하면 됩니다.
비용을 직접 계산해볼 수 있는 구조입니다. 예를 들어 1만 번의 요청에서 평균 input 토큰이 2,000개이고, 그중 60%가 캐시 히트라면, 청구 계산은 이렇습니다.
캐시 미적용: 10,000 × 2,000 토큰 × $2.50/1M = $50.00
캐시 60% 적용: (4,000 × 2,000 × $2.50/1M) + (6,000 × 2,000 × $0.25/1M) = $20.00 + $3.00 = $23.00
→ 캐시 효율 60%에서 비용 약 54% 절감
이 계산식은 직접 따라해볼 수 있습니다. 캐시 히트율 추정치는 “약”으로 표기했고, 실제 히트율은 프롬프트 반복 패턴에 따라 달라집니다.
툴 사용 요금, 생각보다 빨리 쌓입니다
Responses API의 매력 중 하나가 웹검색·파일검색·코드 인터프리터 등 내장 툴입니다. 그런데 이 툴들은 토큰 요금과는 별도로 툴 호출당 요금이 붙습니다.
2026년 3월 기준 공식 가격표에 따르면, 웹검색은 gpt-4o·gpt-4.1 모델 기준 $10.00/1,000회 호출이고, gpt-5 같은 추론 모델은 $25.00/1,000회로 올라갑니다. 파일검색은 스토리지 $0.10/GB/일(첫 1GB 무료)에 툴 호출 $2.50/1,000회가 별도로 더해집니다. (출처: OpenAI 공식 가격 페이지, 2026.03.21 기준)
하루 웹검색을 1,000번 쓰면 한 달이면 약 $300, 추론 모델 기준이면 $750입니다. 에이전트가 한 작업에서 웹검색을 여러 번 호출하도록 설계되어 있다면 이 비용이 예상보다 빨리 올라갑니다.
💡 이게 실제 운영에서 어떤 의미인지 따져보니, 에이전트 설계 시 툴 호출 횟수 제어 로직이 없으면 비용이 선형이 아니라 작업 단위로 곱해지는 구조입니다. max_tool_calls 파라미터로 제한을 걸어두는 게 낫습니다.
또 한 가지, 컨테이너 기반의 코드 인터프리터는 2026년 3월 31일부터 가격 체계가 바뀝니다. 현재는 컨테이너 크기별로 단순 요금이지만, 3월 31일 이후에는 “20분 세션당” 요금으로 바뀝니다. 짧은 작업을 여러 번 실행하는 구조라면 세션이 자주 새로 생겨 비용이 더 올라갈 수 있으니 이 날짜 전에 사용 패턴을 확인해두는 게 좋습니다.
ZDR 환경이라면 stateful 전환이 안 됩니다
Responses API의 핵심 기능 중 하나가 서버 측 상태 저장, 즉 stateful 대화입니다. 그런데 이 기능이 ZDR(Zero Data Retention) 조건에서는 자동으로 비활성화됩니다. ZDR은 OpenAI Enterprise 계약에서 데이터를 서버에 저장하지 않겠다는 조건인데, 이 환경에서는 store가 자동으로 false로 강제됩니다.
이건 OpenAI 공식 문서에 이렇게 나옵니다. “For ZDR organizations, OpenAI enforces store=false automatically.” 즉 대화 체이닝, 캐시 히트 향상, tracing 같은 Responses API의 장점 대부분이 ZDR 환경에서는 그대로 적용되지 않습니다. (출처: OpenAI 공식 문서)
이 경우를 위한 우회 방법이 있기는 합니다. 암호화된 추론 아이템(encrypted reasoning items)을 쓰면 서버에 저장하지 않으면서도 멀티턴 추론 맥락을 유지할 수 있습니다. store:false로 설정하고 include 필드에 ["reasoning.encrypted_content"]를 추가하면 됩니다. 이 경우 암호화된 추론 토큰은 메모리에서만 처리되고 디스크에는 저장되지 않습니다.
💡 “Responses API로 전환하면 비용과 성능 모두 개선된다”고 쉽게 말하는 글이 많습니다. ZDR 조직이라면 이 조건이 붙습니다. stateful 기능을 전제로 설계한 경우 ZDR 여부를 먼저 확인해야 합니다.
Assistants → Responses 실제 마이그레이션 흐름
OpenAI는 Thread → Conversation 자동 마이그레이션 툴을 제공하지 않겠다고 못 박았습니다. “We will not provide an automated tool for migrating Threads to Conversations”라고 공식 마이그레이션 문서에 직접 나옵니다. 수동으로 처리해야 한다는 뜻이고, 작업량이 적지 않습니다.
단계별 흐름은 이렇습니다. 첫째, 기존 Assistant 객체를 대시보드에서 Prompt로 변환합니다. “Create prompt” 버튼 하나로 가능하지만, 이때 생성된 Prompt는 대시보드에서만 만들 수 있고 코드에서 직접 생성되지 않는다는 점이 기존과 다릅니다. 둘째, 기존 Thread의 메시지를 Conversation의 Item으로 변환합니다. 공식 예제 코드가 있고, 메시지 타입에 따라 input_text와 output_text를 분리해야 합니다. 셋째, Run 루프를 Responses 요청으로 교체합니다. polling 대신 한 번의 요청으로 처리되거나 스트리밍을 붙일 수 있습니다.
함수 정의 방식도 달라졌습니다. Chat Completions에서는 type: "function" 아래 function: {...}으로 중첩됐지만, Responses API에서는 직접 type: "function", name: "..."으로 평탄화됐습니다. strict 기본값도 Chat Completions는 false, Responses API는 true가 기본이라 기존 스키마가 strict 조건을 만족하지 못하면 오류가 납니다. 마이그레이션 전에 함수 파라미터 스키마를 미리 점검해야 합니다.
💡 마이그레이션 난이도는 Thread 수와 함수 복잡도에 비례합니다. 새 사용자 트래픽은 Responses API로, 기존 데이터는 점진적으로 백필하는 분리 전략이 위험 부담을 줄입니다.
Structured Outputs 방식도 바뀌었습니다. Chat Completions의 response_format 대신 Responses에서는 text.format으로 JSON 스키마를 지정합니다. 구조적으로는 비슷하지만 필드 위치가 달라졌기 때문에 파서 코드를 그대로 복사하면 동작하지 않습니다.
Q&A 5가지
Q
Assistants API를 지금 당장 Responses API로 바꿔야 하나요?
2026년 8월 26일 이전이면 기존 코드가 그대로 돌아갑니다. 하지만 새 기능 개발은 Responses API로 시작하는 게 낫고, 기존 앱은 종료 전에 마이그레이션 계획을 세워두는 걸 권장합니다. 마이그레이션 자동화 툴이 없기 때문에 Thread 수가 많다면 준비 기간이 필요합니다.
Q
Chat Completions API도 같이 없어지나요?
없어지지 않습니다. OpenAI 공식 문서는 “Chat Completions remains our most widely adopted API, and we’re fully committed to supporting it”라고 명시했습니다. 폐기 일정이 현재 발표되지 않았습니다. 다만 새 프로젝트는 Responses API를 권장합니다.
Q
store:true면 OpenAI가 내 대화를 학습에 씁니까?
OpenAI는 “비즈니스 데이터로 모델을 기본 학습하지 않는다”고 공식 선언했습니다. 다만 학습 데이터 공유 옵션을 선택하면 fine-tuning 비용 할인이 적용됩니다. 학습에 사용되길 원하지 않는다면 Enterprise Privacy 설정을 확인하면 됩니다.
Q
Responses API에서 Claude나 Gemini 모델도 쓸 수 있나요?
OpenAI Responses API 자체는 OpenAI 모델 전용입니다. 다만 Bifrost 같은 LLM 게이트웨이가 Responses API 포맷을 Anthropic·Google 등의 포맷으로 투명하게 변환해줍니다. 멀티 프로바이더 환경이라면 게이트웨이 레이어를 두는 방식이 현실적입니다.
Q
코드 인터프리터 요금이 3월 31일부터 왜 달라지나요?
현재는 컨테이너 크기별 단순 요금이지만, 3월 31일부터 20분 세션 단위로 바뀝니다. 1 GB 컨테이너 기준 한 세션 $0.03입니다. OpenAI가 별도 이유를 공식 발표하지 않은 상태입니다. 짧은 작업을 자주 실행하는 패턴이라면 세션 수 기준으로 비용을 다시 계산해보는 게 좋습니다.
마치며
Responses API가 Assistants API보다 낫다는 건 분명합니다. 비용 구조가 개선됐고, 툴이 내장됐고, 스트리밍도 됩니다. 그런데 막연하게 “좋아졌다”고 넘어가면 store:true 기본값, ZDR 제약, 툴 호출 요금, 코드 인터프리터 세션 요금 변경 같은 부분에서 예상 밖의 청구가 올 수 있습니다.
제가 이 글에서 강조하고 싶었던 건 딱 두 가지입니다. 하나는 Assistants API 종료는 확정이고 D-158입니다. 마이그레이션 자동화가 없으니 Thread 규모에 따라 지금 준비를 시작해야 합니다. 다른 하나는 캐시 개선 효과와 툴 요금은 같이 봐야 한다는 겁니다. 캐시로 토큰 비용을 아껴도 툴 호출 횟수가 늘면 순비용은 충분히 오를 수 있습니다.
새 프로젝트라면 지금 Responses API로 시작하는 게 맞습니다. 기존 앱이라면 8월 이전 어느 시점에 마이그레이션 일정을 잡아두세요.
본 포스팅 참고 자료
⚠️ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. OpenAI API 요금·기능 사양은 공식 문서(platform.openai.com/docs/pricing)에서 항상 최신 버전을 확인하세요. 본 포스팅은 특정 서비스 이용 계약의 법적 판단 근거가 아닙니다.
댓글 남기기