GPT-5.4 / Responses API GA
IT / AI
Responses API, “싸다”는 말이 절반만 맞는 이유
OpenAI 공식 문서는 Responses API가 Chat Completions보다 캐시 활용도가 40~80% 향상됐다고 밝힙니다. 많은 글이 이 수치를 “비용 40~80% 절감”으로 옮기는데, 공식 표현과는 다릅니다. 실제로 previous_response_id를 쓰면 입력 토큰이 줄어드는지 커뮤니티 실측 데이터까지 교차 확인했습니다. 그리고 2026.08.26이라는 Assistants API 종료 데드라인도 챙겨야 합니다.
Responses API가 뭔지 먼저 짚고 갑니다
OpenAI API의 계보는 크게 세 단계로 정리됩니다. 단순 텍스트 생성을 위한 Completions API, 대화 형식을 지원하는 Chat Completions API, 그리고 지금 얘기할 Responses API입니다. 공식 마이그레이션 가이드는 이렇게 선언합니다. “Chat Completions는 계속 지원되지만, 새로운 프로젝트에는 Responses API를 권장합니다.” (출처: OpenAI 공식 마이그레이션 가이드)
Responses API가 기존 Chat Completions API와 다른 핵심은 세 가지입니다. 첫째, 빌트인 도구(웹 검색, 파일 검색, Computer Use, 코드 인터프리터, 원격 MCP 등)를 별도 구현 없이 바로 쓸 수 있습니다. 둘째, 멀티턴 대화에서 이전 응답 ID만 넘기면 상태가 유지됩니다. 셋째, 에이전트 루프를 하나의 API 요청 안에서 처리할 수 있습니다.
코드 구조도 간결해졌습니다. Chat Completions에서는 completion.choices[0].message.content처럼 중첩 접근이 필요했는데, Responses API에서는 response.output_text로 바로 꺼낼 수 있습니다. 공식 문서 표현 그대로 “Items”라는 단위로 응답 구조가 재설계됐습니다.
💡 공식 발표문(2026.03.11)과 마이그레이션 가이드를 함께 놓고 보면 한 가지 패턴이 보입니다. OpenAI는 Responses API를 단순히 “편의성 개선”이 아니라, 추론 모델과 에이전트 루프에 최적화된 새로운 실행 층으로 설계했습니다. Chat Completions는 대화 인터페이스였고, Responses API는 프로그래머블 시스템 인터페이스입니다.
“저렴하다”는 수치의 실제 조건
공식 마이그레이션 가이드의 원문은 이렇습니다. “내부 테스트에서 Chat Completions 대비 캐시 활용도가 40~80% 향상됐습니다.” 많은 한국어 블로그가 이 문장을 “비용 40~80% 절감”으로 소개하는데, 공식 문서에는 그런 표현이 없습니다. 캐시 활용도(cache utilization) 개선과 비용 절감은 다른 이야기입니다. 캐시 히트율이 높아지면 반복 요청에서 비용이 줄어들 수 있지만, 그게 곧 40~80% 비용 절감은 아닙니다.
실제로 비용 절감이 발생하는 조건은 이렇습니다. 동일한 컨텍스트를 반복 사용하는 에이전트 워크플로, 즉 같은 시스템 프롬프트·스킬 파일·파일 검색 인덱스 등을 재사용하는 상황에서 캐시 히트가 발생하면 입력 토큰 비용이 줄어듭니다. 단순 일회성 챗봇이나 매번 다른 컨텍스트를 쓰는 경우라면 이 효과를 기대하기 어렵습니다.
| 항목 | Chat Completions API | Responses API |
|---|---|---|
| 캐시 활용도 | 기준치 | 40~80% 향상 (내부 테스트) |
| SWE-bench 성능 | 기준치 | +3% 향상 (추론 모델 기준) |
| 빌트인 도구 | 없음 (직접 구현 필요) | 웹 검색·파일 검색·Computer Use·코드 인터프리터·MCP |
| 대화 상태 관리 | 클라이언트가 직접 관리 | previous_response_id 또는 Conversations API |
| Audio 지원 | 지원 | Coming soon (2026.03 기준) |
출처: OpenAI 공식 마이그레이션 가이드 (developers.openai.com/api/docs/guides/migrate-to-responses, 2026.03 기준)
previous_response_id의 숨겨진 진실
Responses API의 가장 편리한 기능 중 하나는 previous_response_id입니다. 이전 응답의 ID만 넘기면 전체 대화 기록을 다시 붙여 넣지 않아도 됩니다. 그런데 이 편리함이 “입력 토큰이 줄어든다”는 오해를 낳습니다.
⚠️ 실측 확인된 내용
OpenAI 공식 커뮤니티에서 개발자들이 직접 비교 측정한 결과, previous_response_id를 써도 실제 입력 토큰 수는 Chat Completions에서 전체 히스토리를 직접 넘기는 것과 거의 동일합니다. API가 내부적으로 해당 응답의 전체 컨텍스트를 다시 처리하기 때문입니다. 편의성은 올라가지만 토큰 비용 자체는 줄지 않습니다. (출처: OpenAI 커뮤니티 포럼, “Responses API vs Completions: No Token Savings?”, 2025.06)
그럼 비용 절감은 어디서 오냐는 질문이 생깁니다. 1,000토큰 이상의 컨텍스트라면 자동 캐싱이 작동해 캐시 히트 시 입력 비용이 줄어들 수 있습니다. 공식 문서는 이 캐싱이 “Chat Completions든 Responses API든 자동으로 적용된다”고 밝힙니다. 즉, 캐시 이점은 Responses API만의 것이 아닙니다. Responses API의 실질적인 비용 이점은 캐시 히트율이 구조적으로 더 높게 설계됐다는 점이고, 그 차이가 내부 테스트에서 40~80%로 나타난 것입니다.
💡 공식 문서와 커뮤니티 실측을 함께 보면 이런 그림이 나옵니다. 동일 시스템 프롬프트를 반복하는 에이전트일수록 이 차이가 벌어지고, 매번 새 컨텍스트를 쓰는 단순 챗봇이라면 체감 차이가 거의 없습니다.
Computer Use가 강력한 만큼 위험한 이유
2026년 3월 11일, OpenAI는 Responses API에 컴퓨터 환경을 직접 탑재했다고 공식 발표했습니다. 쉘 도구(shell tool), 호스팅된 컨테이너 워크스페이스, 에이전트 스킬(skills)이 Responses API 안으로 들어온 것입니다. GPT-5.4부터 이 구조를 기반으로 훈련됐습니다. (출처: “From model to agent: Equipping the Responses API with a computer environment”, OpenAI Engineering Blog, 2026.03.11)
쉘 도구는 기존 코드 인터프리터(Python만 실행)와 달리, grep, curl, awk 같은 유닉스 유틸리티부터 Go, Java, Node.js 실행까지 가능합니다. 모델이 스크린샷을 보고 클릭, 입력, 스크롤 같은 UI 액션을 제안하면 하네스가 실행하는 구조입니다. 실용적으로 강력하지만 그만큼 실수하면 되돌리기 어려운 상황도 발생합니다.
공식 가이드에서 명시하는 “반드시 사람이 직접 개입해야 하는” 상황
- 비밀번호 변경의 마지막 단계
- 브라우저 보안 경고(HTTPS 경고, 페이월 장벽) 우회
- 금융 거래 확인
- OS 보안 설정, VPN 변경
- CAPTCHA 풀기
출처: OpenAI 공식 Computer Use 가이드 (developers.openai.com/api/docs/guides/tools-computer-use, 2026.03 기준)
공식 가이드가 특히 강조하는 건 프롬프트 인젝션 위협입니다. 화면에 표시되는 텍스트(웹사이트 내용, PDF, 이메일, 채팅)는 모두 신뢰할 수 없는 입력으로 취급해야 합니다. 화면에서 발견된 “지금 당장 실행하세요” 같은 지시는 사용자 명령이 아닙니다. 이 구분을 시스템 프롬프트에 명시적으로 박아두지 않으면, 화면에 숨겨진 악의적인 지시에 에이전트가 그대로 따라갈 수 있습니다.
ZDR 환경에서의 함정
Responses API의 기본 동작은 store: true입니다. 요청 내용이 OpenAI 서버에 저장됩니다. 공식 문서는 이것을 아무렇지 않게 “기본값”으로 설명하는데, ZDR(Zero Data Retention) 정책을 쓰는 기업이나 개인에게는 기본 설정 그대로 쓰면 안 된다는 뜻입니다.
ZDR 조건에서도 추론(reasoning) 기능을 쓰고 싶다면 방법이 있습니다. store: false로 저장을 끄고, include 필드에 ["reasoning.encrypted_content"]를 추가하면 됩니다. 이렇게 하면 추론 토큰이 암호화된 형태로 반환되고, 다음 요청에서 일반 reasoning 항목처럼 넘길 수 있습니다. 복호화는 메모리에서만 이루어지고 디스크에 쓰이지 않습니다. (출처: OpenAI 공식 마이그레이션 가이드, 2026.03 기준)
💡 대부분의 블로그가 store: false를 단순히 “저장 끄기”로만 소개하는데, ZDR 조직에서는 이 설정이 없으면 OpenAI가 자동으로 강제 적용합니다. 즉, ZDR 조직이라면 별도 설정을 하든 안 하든 저장은 안 되지만, 그 상태에서 암호화 추론 없이는 멀티턴 reasoning을 이어가기 어렵습니다. 설정 조합을 알고 있어야 합니다.
2026.08.26 마이그레이션 데드라인, 어떻게 대비할까
OpenAI는 2025년 8월 26일 Assistants API 지원 중단을 공식 발표하면서 종료일을 2026년 8월 26일로 확정했습니다. Responses API 공식 문서에는 “Assistants API는 2026년 8월 26일에 sunset됩니다”라고 명시돼 있습니다. (출처: OpenAI Migrate to Responses API 공식 가이드, developers.openai.com) Assistants API를 쓰는 프로덕션 코드가 있다면 지금이 이전 시점입니다.
마이그레이션은 단계적으로 가능합니다. 공식 가이드는 Responses API가 Chat Completions API의 상위 집합(superset)이라고 표현합니다. 즉, 전체를 한 번에 바꾸지 않아도 추론 모델이나 에이전트 플로우가 이득을 볼 부분부터 먼저 옮기고, 나머지는 Chat Completions에 그대로 둘 수 있습니다.
함수 정의 방식도 달라집니다. Chat Completions에서는 외부 태그 방식(type: “function” + function: {…})으로 중첩이 한 단계 더 있었는데, Responses API는 내부 태그 방식으로 간결해졌습니다. 또한 Chat Completions에서 함수는 기본적으로 non-strict였지만 Responses API에서는 strict가 기본입니다. 스키마 검증 없이 넘기던 코드가 있다면 이 부분에서 오류가 날 수 있습니다.
마이그레이션 전 체크리스트 (공식 가이드 7단계 요약)
- 엔드포인트 변경:
POST /v1/chat/completions→POST /v1/responses - Item 정의 업데이트 (messages → items)
- 멀티턴 대화 컨텍스트 로직 수정 (
previous_response_id) - ZDR 정책 여부 확인 및
store필드 설정 - 함수 정의 구조 변경 (내부 태그 방식, strict 기본값 확인)
- Structured Outputs:
response_format→text.format - 빌트인 도구로 전환 가능한 커스텀 함수 검토
Q&A
마치며
Responses API는 “Chat Completions보다 좋다”는 말이 맞긴 한데, 어떤 맥락에서 좋은지를 짚지 않으면 기대와 다른 결과가 나옵니다. previous_response_id는 편의성이지 토큰 절약이 아니고, 40~80% 향상은 비용 절감이 아니라 캐시 활용도 수치입니다. 공식 문서를 원문으로 읽지 않으면 이 차이가 흐려집니다.
2026년 3월 11일 발표된 쉘 도구+컨테이너 환경은 에이전트 구축의 진입 장벽을 실질적으로 낮춘 변화입니다. 다만 Computer Use는 “편리하니까 쓴다”가 아니라, 프롬프트 인젝션 방어와 민감 데이터 처리 정책을 설계에 함께 박아두는 방식으로 접근해야 합니다. 편의 기능이 늘어날수록 그 뒤에 붙어 있는 책임도 커집니다.
Assistants API를 쓰고 있다면 2026.08.26까지 6개월도 안 남았습니다. 마이그레이션을 미루기 좋은 시기가 있는 건 아닌데, 공식 가이드가 잘 정리돼 있으니 지금 훑어두는 걸 권합니다.
📚 본 포스팅 참고 자료
- OpenAI 공식 마이그레이션 가이드 — developers.openai.com/api/docs/guides/migrate-to-responses
- OpenAI Computer Use 공식 가이드 — developers.openai.com/api/docs/guides/tools-computer-use
- OpenAI Engineering Blog: “From model to agent: Equipping the Responses API with a computer environment” (2026.03.11) — openai.com/index/equip-responses-api-computer-environment
- OpenAI 커뮤니티 포럼: “Responses API vs Completions: No Token Savings?” — community.openai.com
- Microsoft Learn: “Assistants API will be deprecated in August 2026” — learn.microsoft.com
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 본문의 모든 수치와 기능 설명은 2026년 3월 22일 기준 공식 문서를 바탕으로 작성됐습니다. OpenAI는 업데이트 주기가 빠르므로 최신 내용은 공식 문서에서 직접 확인하시기 바랍니다.
댓글 남기기