지금 대부분의 AI 애플리케이션은 Chat Completion API를 사용합니다. 하지만 이 API는 “사용자가 질문하면 AI가 답변하는” 턴제 대화를 위해 설계된 것이죠. 문제는 AI의 역할이 이미 바뀌었다는 겁니다. 이제 AI는 스스로 추론하고, 도구를 호출하고, 여러 단계를 거쳐 복잡한 작업을 완수하는 ‘에이전트’로 진화했습니다. 그런데 우리는 여전히 옛날 도구를 쓰고 있는 셈이에요.

Hugging Face가 OpenAI의 Responses API를 기반으로 한 오픈 표준 Open Responses를 발표했습니다. OpenAI가 시작하고 오픈소스 커뮤니티가 함께 만든 이 새로운 표준은 에이전트 시대에 맞는 API 설계를 제공하며, Hugging Face, OpenRouter, Ollama, vLLM, LM Studio 등 주요 파트너들이 참여하고 있습니다.

출처: Open Responses: What you need to know – Hugging Face Blog

Chat Completion의 시대는 끝났다

Chat Completion API는 훌륭한 도구였습니다. 하지만 단순 대화형 챗봇을 넘어 자율적으로 작동하는 에이전트를 만들려면 한계가 명확해요. 에이전트는 장시간에 걸쳐 추론하고, 계획을 세우고, 행동해야 하는데 턴제 대화 형식으로는 이런 워크플로우를 자연스럽게 표현하기 어렵습니다.

OpenAI는 2025년 3월 Responses API를 출시하며 이 문제를 해결하려 했습니다. Responses API는 텍스트, 이미지, 구조화된 JSON 출력을 일관되게 생성하고, 도구 호출을 자율적으로 실행하며 최종 결과를 반환하는 ‘에이전트 루프’를 제공자(provider) 측에서 처리할 수 있게 설계됐죠. 하지만 이건 OpenAI만의 폐쇄적 표준이었고, 생태계 전체가 여전히 Chat Completion에 의존하는 상황이 지속됐습니다.

Open Responses가 바꾸는 것들

Open Responses는 OpenAI의 Responses API를 오픈 표준으로 확장한 것입니다. 핵심은 단순히 API 형식을 통일하는 것을 넘어 에이전트 워크플로우에 필요한 기능들을 표준화했다는 점이에요.

추론 과정의 투명성

가장 눈에 띄는 변화는 모델의 추론 과정(reasoning trace)을 공개할 수 있다는 겁니다. 기존 OpenAI 모델들은 요약본(summary)이나 암호화된 내용(encrypted_content)만 제공했는데, Open Responses는 원본 추론 과정(content)을 노출할 수 있는 옵션을 표준에 포함했습니다. 오픈 웨이트 모델들은 이제 자신의 사고 과정을 그대로 스트리밍할 수 있죠.

// 오픈 웨이트 모델은 원본 추론을 스트리밍
event: response.reasoning.delta
data: { "delta": "User asked: 'Where should I eat...' Step 1: Parse location...", ... }

// 암호화된 추론을 사용하는 모델은 요약본 제공
event: response.reasoning_summary_text.delta
data: { "delta": "Determined user wants restaurant recommendations", ... }

sub-agent loops: 한 번의 요청으로 복잡한 작업 완수

에이전트의 핵심은 “추론 → 도구 호출 → 결과 확인 → 다시 추론”을 반복하는 루프입니다. Open Responses는 이 루프를 공식화해서, 제공자 측에서 자율적으로 여러 단계를 처리하고 최종 결과만 반환할 수 있게 했어요.

예를 들어 “Q3 매출 데이터를 찾아서 팀에게 요약 이메일을 보내줘”라는 요청을 생각해보세요. 기존 방식이라면 클라이언트가 직접 여러 번 API를 호출하며 단계를 관리해야 했습니다. Open Responses에서는 단일 요청으로 모델이 알아서 문서를 검색하고, 요약하고, 이메일을 작성하는 전체 과정을 완료할 수 있습니다. max_tool_calls로 반복 횟수를 제한하고, 중간 과정(도구 호출, 결과, 추론)이 모두 응답에 포함됩니다.

도구 통합의 표준화

Open Responses는 도구를 두 가지로 구분합니다. 외부 호스팅 도구(클라이언트 측 함수나 MCP 서버)와 내부 호스팅 도구(OpenAI의 파일 검색, Google Drive 통합 등)죠. 내부 도구는 제공자 인프라 내에서 모델이 직접 호출하고 실행하기 때문에 개발자 개입이 필요 없습니다.

벤더 종속성에서 벗어나기

Open Responses의 진짜 가치는 오픈 표준이라는 점입니다. OpenRouter, Hugging Face, vLLM, Ollama, LM Studio가 모두 참여하면서 사실상 모든 주요 모델과 서빙 도구를 일관된 방식으로 사용할 수 있게 됐어요. 클라이언트는 요청 시 제공자와 제공자별 옵션을 지정할 수 있고, 라우터는 이를 기반으로 여러 업스트림 제공자 간 요청을 조율합니다.

물론 이 표준화가 OpenAI에게 전략적으로 유리한 것도 사실입니다. 자사 API 형식이 산업 표준이 되면 Google, Anthropic, Meta 같은 경쟁사들은 OpenAI 방식에 맞춰야 하지만, 기존 OpenAI 고객들은 아무것도 바꿀 필요가 없으니까요. 하지만 개발자 입장에서는 매번 다른 API 형식 때문에 코드를 다시 작성하는 것보다 훨씬 낫습니다.

개발자 Simon Willison은 이런 벤더 중립적 표준을 “가장 원했던 것”이라고 평가하면서도, 한 가지 아쉬운 점을 지적했습니다. 서버 구현을 검증하는 compliance 테스트는 있지만, 클라이언트 라이브러리를 검증할 수 있는 표준 테스트 스위트가 없다는 거죠. 클라이언트 개발자 입장에서는 자신이 만든 라이브러리가 모든 세부사항을 올바르게 처리하는지 확인할 방법이 필요한데, 현재는 그런 도구가 부족합니다.

다음은?

Open Responses는 Responses API를 확장하고 개선해서 더 풍부한 콘텐츠 정의, 호환성, 배포 옵션을 제공합니다. Hugging Face Inference Providers를 통해 지금 바로 사용해볼 수 있고, Hugging Face Spaces에서 얼리 액세스 버전을 테스트할 수 있어요.

Chat Completion에서 Open Responses로의 전환은 단순한 API 업데이트가 아닙니다. AI가 단순히 “답변하는 도구”에서 “스스로 작업을 완수하는 에이전트”로 진화한 현실을 반영하는 거죠. 이제 남은 건 생태계 전체가 이 표준을 채택하고, 더 나은 클라이언트 도구를 만들어가는 일입니다.

참고자료:

• Open Responses – Simon Willison’s Weblog
• OpenAI wants its API format to become the industry standard – The Decoder