Open Responses란 무엇인가?

Open Responses는 OpenAPI 3.1 문서로 게시된 공개 명세로, 여러 제공자에 걸쳐 언어 모델을 호출하기 위한 하나의 요청 및 응답 형태를 설명합니다. 이는 OpenAI Responses API를 기반으로 합니다. 즉, model, input 그리고 선택적 tools를 POST /v1/responses로 보내면, 제공자별 형식 대신 타입이 지정된 항목과 시맨틱 스트리밍 이벤트를 돌려받습니다. OpenAI는 2026-01-15에 Open Responses를 출시했으며, Apache 2.0 라이선스로 배포되고, 2026-10-22에 OpenAI는 이를 MCP도 호스팅하는 Linux Foundation 산하 기구인 Agentic AI Foundation(AAIF)에 기증했습니다.

마지막 단계가 바로 뉴스입니다. 이 명세는 이제 기술 헌장, 운영 위원회, 그리고 중립적인 소속처를 갖게 되었습니다. 이 글에서는 명세가 정의하는 내용, 누가 구현하는지, AAIF 이전이 무엇을 바꾸는지, 그리고 의존하는 엔드포인트가 명세를 준수하는지 확인하는 방법을 다룹니다. 기반 API가 처음이라면 OpenAI Responses API 사용 방법부터 시작하세요.

Open Responses가 정의하는 것

명세는 문제를 명확히 설명합니다. 제공자들은 동일한 구성 요소(메시지, 도구 호출, 스트리밍, 멀티모달 입력)로 수렴했지만, 각자 다르게 인코딩합니다. Open Responses는 하나의 인코딩을 골라 문서로 기록합니다.

현재 OpenAPI 문서는 버전 2026-04-24이며 작은 범위를 다룹니다.

오퍼레이션	수행하는 작업
`POST /responses` (`createResponse`)	스트리밍 여부와 관계없이 응답 생성
`/responses`의 WebSocket	지속 소켓을 통한 동일한 응답 모델(2026-04-24 추가)
`POST /responses/compact` (`compactResponse`)	긴 대화를 위한 압축된 입력 윈도 반환

요청 본문은 OpenAI API를 사용해 봤다면 예상할 수 있는 필드들을 받습니다. model, input, instructions, tools, tool_choice, stream, store, previous_response_id, reasoning, text, truncation, temperature, top_p, max_output_tokens, prompt_cache_key 그리고 몇 가지 더 있습니다. 응답 객체(ResponseResource)는 id, status, output, usage, error와 함께 보낸 설정을 그대로 되돌려줍니다. 문서는 총 108개의 스키마를 정의하며, 대부분 항목 및 스트리밍 이벤트 타입입니다.

설계를 이끄는 세 가지 개념이 있습니다.

항목은 컨텍스트의 단위

모델이 읽거나 생성하는 모든 것은 항목입니다. message, function_call, function_call_output, reasoning 항목 등입니다. 항목은 양방향이므로 한 턴의 출력을 다음 턴의 입력으로 바로 되돌려 보낼 수 있습니다. 각 항목 타입은 type 필드로 구분되며 고유한 스키마를 갖습니다.

항목은 또한 상태 머신입니다. 각 항목은 in_progress에서 completed 또는 incomplete(토큰 예산 소진)로 이동하며, incomplete 항목은 반드시 마지막으로 방출되어야 하고 전체 응답은 incomplete로 표시됩니다. 상태는 서버가 해당 항목을 저장했는지 여부를 말해주지 않습니다. 지속성은 별개의 문제입니다.

스트리밍은 원시 델타가 아닌 시맨틱 이벤트

stream: true를 설정하면 서버는 Content-Type: text/event-stream과 정의된 이벤트 시퀀스로 응답해야 합니다. 출력 항목은 response.output_item.added로 시작하고, 그 안의 텍스트는 response.content_part.added로 도착한 다음 반복되는 response.output_text.delta 이벤트, 그리고 response.output_text.done과 response.content_part.done으로 이어집니다. 항목은 response.output_item.done으로 닫힙니다. 스트림은 반드시 종료 이벤트로 끝나야 합니다. 즉, response.completed, response.failed 또는 response.incomplete입니다. 후행 [DONE]은 선택 사항이며, 클라이언트는 그것 없이 끝나는 스트림도 처리해야 합니다.

Diagram of the Open Responses streaming event order: output_item.added, content_part.added, output_text.delta repeated, output_text.done, content_part.done, output_item.done, then a terminal completed, failed or incomplete event

이것은 클라이언트 코드에서 가장 중요합니다. 두 제공자가 동일한 이벤트를 동일한 순서로 방출한다면 하나의 SSE 파서로 둘 다 처리할 수 있습니다. 저희 SSE 테스트 가이드는 이러한 스트림을 이벤트별로 검사하는 방법을 보여줍니다.

네임스페이스가 적용된 확장을 갖춘 안정적인 코어

제공자는 자체 항목 타입, 도구, 스트리밍 이벤트를 추가할 수 있지만, 제공자 슬러그를 접두사로 붙여야 합니다. 명세 자체의 예시는 openai:web_search_call입니다. 접두사가 붙은 타입을 인식하지 못하는 클라이언트는 문제없이 건너뛸 수 있습니다. 이렇게 해서 웹 검색이나 파일 검색 같은 호스팅 도구가 제공자 기능으로 남으면서도 명세는 이식성을 유지합니다.

계약의 나머지 부분

명세 위에 무언가를 구축하기 전에 알아둘 만한 몇 가지 규칙이 더 있습니다.

두 종류의 도구. 외부 호스팅 도구(함수, MCP 서버)는 제공자 외부에서 실행됩니다. 함수의 경우 모델이 function_call을 방출하면, 당신이 실행하고 일치하는 call_id와 함께 function_call_output을 돌려보냅니다. 내부 호스팅 도구(예: OpenAI의 파일 검색)는 제어권을 되돌려주지 않고 제공자 내부에서 실행됩니다.
tool_choice와 allowed_tools. tool_choice는 auto(기본값), required, none, 또는 하나의 함수를 지정하는 객체를 받습니다. allowed_tools는 모든 도구를 보여주면서도 모델이 호출할 수 있는 도구를 제한하므로, tools 배열을 수정해 캐시된 프롬프트를 무효화하지 않아도 됩니다. 서버는 이를 강제 한도로 적용해야 합니다.
previous_response_id. 서버는 새 요청을 previous_response.input + previous_response.output + input 순서로 처리해야 하므로 트랜스크립트를 다시 보내지 않아도 됩니다.
Reasoning 항목은 원시 content, 불투명한 encrypted_content 블롭, 사용자 안전 summary, 또는 이들의 조합을 담을 수 있습니다.
오류는 type(server_error, invalid_request, not_found, model_error, too_many_requests)과 함께 code, param, message를 담습니다. 스트림 중간에서는 오류 뒤에 response.failed가 옵니다.

2026-04-24 개정판(변경 로그)은 WebSocket 전송을 추가했습니다. 각 턴은 response.create 메시지로 시작하고, 하나의 연결은 한 번에 하나의 응답을 처리하며, 연결은 60분으로 제한됩니다(오류 코드 websocket_connection_limit_reached). 그리고 store: false 연속성은 연결 로컬 메모리에 유지되며, 그 상태가 사라지면 previous_response_not_found로 실패합니다. 같은 개정판은 /responses/compact, 어시스턴트 메시지의 선택적 phase 필드(commentary 또는 final_answer)를 추가하고 logprobs를 선택 사항으로 만들었습니다.

Open Responses vs Chat Completions

Chat Completions는 여전히 가장 널리 복제된 LLM 인터페이스입니다. 차이는 형태에 있습니다. Chat Completions는 메시지를 담은 choices를 반환하고 도구 호출은 그 안에 숨겨져 있는 반면, Responses 모델은 타입이 지정된 항목의 평평한 목록을 반환합니다. 추론 단계, 세 번의 도구 호출, 최종 메시지는 각자의 상태를 가진 별개의 순서 있는 객체가 되어 에이전트 루프에 더 적합합니다.

Side-by-side diagram: Chat Completions nests content and three tool_calls inside choices[0].message, while Open Responses returns a flat output list of reasoning, three function_call items and a message, each with a status

저희는 Chat Completions vs Anthropic Messages vs Responses API에서 실제 요청과 함께 세 가지 지배적인 형식을 나란히 비교했습니다. OpenAI 자체의 표면 중에서 선택하고 있다면 Agents API vs Responses API vs Agents SDK 분석이 Responses의 위치를 다룹니다.

누가 구현하는가

지지자 목록에는 OpenAI와 함께 AWS Bedrock, Databricks, Hugging Face, LM Studio, Nvidia, Ollama, OpenRouter, Red Hat, Vercel, vLLM이 포함됩니다. Anthropic과 Google은 명시된 지지자에 없으며, 둘 다 여전히 자체 네이티브 형식을 제공합니다.

“지원”은 넓은 범위를 포괄하므로, 사용하는 런타임의 세부 사항을 확인하세요.

Ollama는 v0.13.3에서 POST /v1/responses를 추가했습니다. 호환성 문서는 “비상태 유지(non-stateful) 형태만 지원됩니다”라고 말합니다. 스트리밍, 함수 도구, 추론 요약은 작동하지만 previous_response_id, conversation, truncation은 작동하지 않습니다. 기록은 직접 다시 보내야 합니다.
LM Studio는 버전 0.3.39에서 http://localhost:1234/v1/responses 엔드포인트를 호환되게 만들었으며, previous_response_id, 비전 모델용 원격 이미지 URL, logprobs를 포함합니다. 설정은 저희 LM Studio 가이드를 참고하세요.

규모를 가늠하기 위해, API Evangelist가 9월 13일에 기준선을 측정했습니다. 읽을 수 있는 OpenAPI 문서를 게시하며 OpenAI 호환성을 주장하는 120개 제공자 중 26개가 POST /responses를 선언했고, POST /chat/completions를 선언한 곳은 105개였습니다. 이 기준선의 요점은 중립적 거버넌스가 그 숫자를 움직이는지 측정하는 것입니다.

Agentic AI Foundation 이전이 바꾸는 것

AAIF는 2026-10-22에 산호세에서 열린 AGNTCon + MCPCon North America에서 다른 세 가지 신규 프로젝트와 함께 Open Responses를 발표했습니다. 세 프로젝트는 Agent Skills(Anthropic 제공), OpenEnv(Hugging Face 제공), OpenSandbox(Alibaba 제공)입니다. 이로써 AAIF는 첫해에 MCP, Agent2Agent 프로토콜, AGENTS.md, goose, agentgateway, Agent Router에 이어 10개의 호스팅 프로젝트를 갖게 되었습니다. 이들이 어떻게 맞물리는지 정리 중이라면 저희 MCP vs A2A 해설이 좋은 출발점입니다.

바뀌는 것:

거버넌스. 이 프로젝트는 이제 “Open Responses a Series of LF Projects, LLC”이며, 2026-10-21에 기술 헌장을 채택했습니다. 초기에는 프로젝트 유지관리자로 구성된 기술 운영 위원회(Technical Steering Committee)가 기술 결정을 소유하며, 헌장을 따르는 누구나 참여할 수 있습니다.
다른 벤더에 대한 신뢰성. 한 회사가 소유한 명세는 제품입니다. 재단 아래의 명세는 경쟁사가 경쟁자를 따르는 것처럼 보이지 않고 채택하기 더 쉽습니다.

바뀌지 않는 것:

OpenAI 자체 API. api.openai.com의 Responses API는 자체 기능과 릴리스 일정을 유지합니다. Open Responses는 이식 가능한 코어를 설명하며, OpenAI 특정 도구는 openai: 접두사 뒤에 남습니다.
와이어 형식. 이전과 함께 새로운 명세 버전이 나오지 않았습니다. 최신 릴리스는 여전히 2026-04-24이며, 날짜가 붙은 릴리스는 불변입니다.
준수 여부. 지지자 목록에 있다고 해서 엔드포인트가 테스트를 통과하는 것은 아닙니다. 아직 통과/실패 지표를 게시하는 곳은 없으므로, 의존하는 엔드포인트는 직접 확인해야 합니다.

인수 테스트로 엔드포인트 확인하기

이 프로젝트는 자체 인수 테스트를 제공합니다. 준수 페이지는 브라우저에서 모든 베이스 URL, 모델, 키에 대해 10개의 테스트를 실행합니다. 기본 텍스트 응답, 스트리밍, 시스템 프롬프트, 도구 호출, 이미지 입력, 멀티턴 기록, 어시스턴트 phase 레이블, 압축 엔드포인트, 그리고 model이 빠진 compact 요청에 대한 부정 테스트입니다. WebSocket 테스트 7개(순차 턴, store: false 연속성, 재연결 복구, 실패한 연속성 이후 캐시 제거)는 CLI에서만 실행됩니다.

git clone https://github.com/openresponses/openresponses
cd openresponses && bun install
bun run test:compliance --base-url http://localhost:11434/v1 --api-key ollama

각 HTTP 요청과 각 WebSocket 턴에는 30초의 기한이 주어지며, 타임아웃은 해당 테스트만 실패시킵니다. Ollama 같은 비상태 유지 런타임은 설계상 연속성 테스트에서 실패할 것으로 예상하세요.

Apidog CLI로 코딩 에이전트가 테스트하게 하기

인수 테스트는 서버가 오늘 명세를 따르는지 알려줍니다. 앱이 배포할 때마다, Ollama를 업그레이드할 때마다, 제공자를 전환할 때마다 호출하는 엔드포인트를 감시하지는 않습니다. 이를 위해 명세를 Apidog 프로젝트로 가져오고, 코딩 에이전트가 Apidog CLI로 회귀 테스트를 작성하고 실행하게 하세요.

CLI와 에이전트 스킬을 한 번 설치하세요.

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

그런 다음 Claude Code, Codex 또는 Cursor에 프롬프트 하나를 주세요.

Download https://www.openresponses.org/openapi/openapi.json and import it into
Apidog project <id>. Create an environment "local-ollama" with base URL
http://localhost:11434/v1. Add test cases for POST /responses: one that expects 200,
status "completed" and an output item of type "message"; one with stream: true that
expects text/event-stream ending in response.completed; one without "model" that
expects a 4xx error with an error.type field. Run them and summarize any failures.

에이전트는 스키마를 읽고, 작성하기 전에 페이로드를 검증하며, 케이스를 실행합니다.

curl -sLO https://www.openresponses.org/openapi/openapi.json
apidog import --project <id> --format openapi --file ./openapi.json
apidog environment create local-ollama --project <id> --base-url http://localhost:11434/v1
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json

명세의 servers 항목은 https://api.openai.com/v1을 가리키므로, 제공자마다 환경을 하나씩 추가하고 같은 케이스를 각각에 대해 실행하세요. 그것이 이식성 주장을 테스트하는 방법입니다. apidog run ... -r junit 라인을 파이프라인에 넣어 필드를 누락시키는 런타임 업그레이드가 빌드를 실패시키도록 하세요(CI/CD 가이드). Claude Code에서의 Apidog CLI는 에이전트 설정을 자세히 다룹니다.

FAQ

Open Responses는 OpenAI Responses API와 같은 것인가요? 아닙니다. Open Responses는 그것에서 파생된 명세입니다. OpenAI의 Responses API는 OpenAI 전용 기능이 추가된 하나의 구현이며, Ollama, LM Studio, vLLM은 또 다른 구현입니다.

이제 Open Responses를 누가 소유하나요? 2026-10-22부터 Linux Foundation 산하 Agentic AI Foundation 프로젝트이며, 기술 운영 위원회와 함께 LF Projects 시리즈로 운영됩니다. Apache 2.0 라이선스입니다.

Anthropic이 Open Responses를 지원하나요? Anthropic은 명시된 지지자에 없습니다. 같은 날 AAIF에 Agent Skills를 기증했지만, Claude의 네이티브 인터페이스는 여전히 Messages API입니다.

명세 파일은 어디에 있나요? https://www.openresponses.org/openapi/openapi.json에 있으며, 날짜가 붙은 릴리스는 GitHub 저장소에 있습니다.

다음 단계

제품이 가장 많이 호출하는 엔드포인트 하나를 골라 브라우저 인수 테스트를 실행하고, 명세를 Apidog로 가져와 에이전트가 모든 배포마다 그 검사를 계속 실행하도록 하세요. 시작하려면 Apidog를 다운로드하세요.