OpenAI DevDay 2026 개발자 가이드: Responses API, Structured Outputs, Tool Calling과 MCP에서 바뀔 수 있는 것

이 가이드 쓰는 법: 예측문과의 분업

예측문은 「무대에서 무엇을 말할 수 있는가」에 답한다. 이 가이드는 「이번 주 저장소에 어떤 JSON을 넣을 것인가」에 답한다. 둘은 같은 2026 궤적을 따르되 다음에 할 일이 다르다. 전자는 주제 연설 대조, 후자는 schemas/ 트리를 고정하는 데 쓴다. 예측 때문에 제품을 다시 쓰지 마라. DevDay는 API를 처음부터 발명하는 일이 드물다. 미리보기, Beta, 기업 화이트리스트를 기본 제품으로 접는다.

「이미 사실」과 「발표될 수 있는 것」을 먼저 가른다. 이미 사실인 것: Responses는 Agent 능력의 주 경로다. Structured Outputs는 text.format.json_schema + strict로 최종 객체를 잠근다. 함수 도구와 원격 MCP는 같은 responses.create에 걸릴 수 있다. MCP는 기본으로 승인을 먼저 요구한다(mcp_approval_request). require_approval / allowed_tools로 좁힐 수 있다. 이것은 예측이 아니다. 발표될 수 있는 것은 종료일, GA 표시, 직접 켜는 스위치, 「두 Schema가 같은 원본임을 선언하는 공식 방법」이다.

유용한 읽기는 「GPT-5.7이 나오나」가 아니다. 어느 요청 면이 유일한 권장 경로가 되는가. 어느 JSON Schema가 모델 힌트에서 플랫폼 강제로 바뀌는가. 어느 세션 상태가 당신 데이터베이스에서 공식 Conversations로 옮기는가. 대조는 아래와 같다.

Responses API: 하나로 접힐 수 있는 요청 면

Assistants는 이미 죽었다. Chat Completions는 살아 있으나 2026년 새 능력은 거의 그리로 가지 않는다. 원격 MCP, Tool Search, Computer Use, Skills, hosted shell, WebSocket Responses, phase(commentary / final_answer)는 모두 Responses에 걸린다. 재사용 Prompt는 Chat Completions에 들어간 적이 없다. 취향이 아니라 플랫폼이 Agent 가능한 면을 하나로 접는 중이다. Assistant / Thread / Run에서 객체를 옮기는 법은 Assistants → Responses 이전을 보라.

DevDay가 가장 손대기 쉬운 것은 「Responses 파라미터 하나 더」가 아니다. 셋 중 몇 가지다. Chat Completions에 명시적 동결 또는 종료일을 준다. Conversations를 텍스트 Responses와 Realtime을 잇는 통일 세션 원어로 접는다. 이미지, 전사, 비디오를 내장 tool로 같은 output item 타임라인에 더 많이 쓴다. 당신에게는 새 래퍼가 input / output item, tools[], text.format, previous_response_id 또는 conversation만 본다는 뜻이다. tools[] 모양을 두 벌 유지하지 마라.

요청 메타데이터도 접힌다. Fast는 이미 Priority를 대체했고 Ultrafast는 아직 제한 미리보기다. service_tier, prompt_cache_retention, safety_identifier는 지금 명시 필드로 쓰고 SDK 기본값에 묻지 마라. 주제 연설 뒤에 청구서, 캐시 적중, 안전 차단을 맞추는 것은 이 키이지 모델 이름이 아니다. 아래 골격은 오늘 합법이고 DevDay 뒤에도 합법일 확률이 크다. 함수 도구, 원격 MCP, Structured Output이 같은 responses.create를 탄다.

{
  "model": "gpt-5.6-sol",
  "input": "Extract the paid invoice and call billing tools",
  "tools": [
    {
      "type": "function",
      "name": "searchInvoices",
      "strict": true,
      "parameters": {
        "type": "object",
        "properties": {
          "invoiceId": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["draft", "sent", "paid", "void"]
          }
        },
        "required": ["invoiceId", "status"],
        "additionalProperties": false
      }
    },
    {
      "type": "mcp",
      "server_label": "billing",
      "server_url": "https://mcp.example.com",
      "allowed_tools": ["searchInvoices", "createCreditNote"],
      "require_approval": "never"
    }
  ],
  "text": {
    "format": {
      "type": "json_schema",
      "name": "invoice_result",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "invoiceId": { "type": "string" },
          "total": { "type": "number" },
          "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] },
          "status": { "type": "string", "enum": ["paid", "open"] }
        },
        "required": ["invoiceId", "total", "currency", "status"],
        "additionalProperties": false
      }
    }
  },
  "service_tier": "fast",
  "safety_identifier": "billing-user-42"
}

Structured Outputs: 모양, 스트리밍, 같은 원본 Schema

오늘의 Structured Outputs는 최종 객체를 잠글 수 있다. Responses에서는 text.format에 두고, 규칙은 Chat Completions의 response_format과 같으며 껍데기 필드명만 다르다. 공식 포인트는 타입 안전, 감지 가능한 거부, 「반드시 JSON을 내라」는 프롬프트에 덜 기대는 것이다. 의미는 팔지 않는다. 모양을 잠그는 것은 업무 의미를 잠그는 것이 아니다. 잘린 스트림 문자열, 조용히 버려지는 $ref, 과대 Schema, 동적 열거는 여전히 2026년 연동의 흔한 상처다. 사이트 Structured Output 튜토리얼과 AI 생성 JSON 오류 가이드는 같은 말을 했다. 플랫폼은 괄호 일치를 보장하지, 청구서 합계가 맞음을 보장하지 않는다.

DevDay가 「말할 법한」 개발자 고통은 이 셋이다. ① 스트리밍 Structured Output. 증분은 합법 부분 객체 또는 JSON Patch이지 깨진 문자열이 아니다. ② Tool Schema와 Output Schema를 같은 원본으로 선언할 수 있어 거의 같은 파일 두 벌을 손으로 유지하지 않는다. ③ 더 덜 잃는 JSON Schema 부분집합. oneOf / $ref의 silent drop이 줄어든다. 확률은 「Completions 수렴」보다 낮지만, 발표되면 스트림 파서와 Schema 디렉터리가 바로 지목된다.

지금 할 수 있는 일은 무대와 무관하다. schemas/output/와 schemas/tools/를 가른다. 각 출력 Schema는 Draft 2020-12, strict + additionalProperties: false, required를 전부 쓴다. 같은 파일을 플랫폼과 로컬 검증기에 넣는다. 플랫폼 오류와 로컬 오류가 어긋나면 모델을 의심하기 전에 두 Schema를 Diff한다. 사용자나 하류 시스템에 주는 최종 답은 checkpoint와도 MCP arguments와도 파일을 공유하지 마라—AI Agent State를 보라.

Tool Calling: 프로그래밍 호출과 다중 Agent

2026년 도구 호출은 더 이상 「모델이 함수 하나를 고르고, 당신이 한 번 돌리고, 문자열을 도로 넣는」것이 아니다. 7월 9일 GPT-5.6는 Programmatic Tool Calling, 명시적 Prompt Cache, persisted reasoning, Multi-agent orchestration(Beta)를 Responses에 넣었다. 모델은 프로그램 구조로 도구를 연속 호출하고 자식 Agent를 일등 객체로 다룰 수 있다. Beta의 전형적 운명은 DevDay에서 면책 문구를 떼고 SLA와 한도를 붙이는 것이다.

GA로 가면 오케스트레이터는 경계를 다시 긋는다. 어느 hop을 플랫폼 편성에 맡기고 어느 hop을 자체 루프에 남길 것인가. JSON이 한 가족 늘어난다—자식 Agent의 중간 artifact. 최종 Structured Output, MCP arguments와 같은 schema 파일에 넣지 마라. 각 도구 로그에 지금부터 correlationId / runId / callId를 찍어라. GA 뒤에 대사가 맞는다. 함수 도구 arguments는 여전히 JSON 문자열인 경우가 많다. 실행 전에 반드시 JSON.parse + Schema. MCP tools/call과 같은 부류의 문제다.

Tool Search, Skills, hosted shell은 이미 Responses에만 걸린다. DevDay가 「먼저 도구를 찾고 다음에 호출」을 기본으로 접으면, 함수 80개를 한 번에 tools[]에 넣은 것을 후회한다. 먼저 도메인으로 도구 묶음을 가르고, 함수 도구 쪽에도 allowed_tools식 화이트리스트를 먼저 쓴다. 파라미터 Schema는 작게, 열거는 짧게, additionalProperties는 금지. 세부는 MCP와 JSON Schema를 보라.

MCP: 원격 도구, 승인, Connector

GPT-5.5부터 Responses는 원격 MCP를 걸 수 있다. 모델은 먼저 mcp_list_tools를 내고 어느 것을 부를지 정한다. 콘솔에는 OpenAI가 유지하는 Connector가 있다. 5월 19일 Secure MCP Tunnel은 ChatGPT, Codex, Responses, AgentKit이 고객 측 tunnel-client를 통해 사내에 닿게 하나, 지금은 기업 개통에 가깝다. 기본 동작을 기억하라. 플랫폼은 데이터를 원격에 넘기기 전에 승인을 요구하고, 출력에 mcp_approval_request가 나온다. 신뢰한 뒤에는 require_approval을 일부 도구 또는 never로 둘 수 있다. 도구가 많으면 allowed_tools를 쓴다. 아니면 list만으로 컨텍스트를 태운다.

빈틈은 분명하다. 일반 프로젝트는 여전히 사설 MCP를 원클릭으로 걸 수 없고, Connector 목록도 자체 도구를 충분히 덮지 않는다. 예측문은 「Hosted MCP / Connector 셀프서브, Tunnel을 프로젝트 스위치로 내림」을 고확률로 적었다. 이 가이드가 요구하는 것은 확률과 무관한 한 가지다. MCP Tool.inputSchema와 모델 tools[].parameters는 한 원본을 공유. 껍데기 필드명은 달라도 된다. 속성, 필수, 열거는 같은 원본 파일에서 생성해야 한다. 플랫폼은 Server의 실행기 검증을 대신하지 않는다. 검증 사슬은 여전히 parse → Schema → 업무 규칙. 원격 MCP 자체는 무상태 JSON-RPC다. 업무 기위는 Server에 있지 않다—Stateless MCP를 보라.

A2A와 섞지 마라. MCP는 모델이 도구를 부르는 것이다. A2A는 Agent 가로 위임이고, 작업은 자체 수명 주기와 artifacts를 가진다. OpenAI는 이미 모델 층에서 MCP를 먹는다. 가로 위임은 여전히 빈칸이다. DevDay가 AAIF / A2A를 한 줄 짚어도 상호운용일 뿐, Agent Card와 inputSchema를 한 객체로 쓰라는 뜻이 아니다. 대조는 A2A vs MCP. 사설 도구 arguments와 MCP params.arguments가 어긋나면 Diff로 보는 것은 생성 사슬이지 모델 「발작」이 아니다.

지금 고정할 JSON Schema 6개

거대한 JSON 하나로 끝내지 마라. 소비자로 파일을 가른다. 모델은 출력 모양, 런타임은 도구 인자, MCP Server는 inputSchema, 오케스트레이터는 세션 item과 자식 Agent 산물, 장부는 사용량을 본다. 여섯 파일이면 DevDay가 가장 건드릴 면을 덮는다. 원본은 Draft 2020-12. OpenAI 껍데기(text.format / parameters)를 생성할 때는 포장만 더하고 속성은 바꾸지 마라.

저장소에 인덱스를 두고, 어느 두 파일이 같은 원본인지, 어느 파일이 포장만인지 선언하라. 인덱스 자체도 평범한 JSON이라 리뷰와 Diff가 쉽다.

{
  "schemaVersion": "1.0",
  "pack": "devday-2026-prep",
  "files": [
    {
      "id": "so.invoice_result",
      "path": "schemas/output/invoice_result.json"
    },
    {
      "id": "fn.searchInvoices.parameters",
      "path": "schemas/tools/searchInvoices.json"
    },
    {
      "id": "mcp.searchInvoices.inputSchema",
      "path": "schemas/mcp/searchInvoices.json",
      "sameOriginAs": "fn.searchInvoices.parameters"
    },
    {
      "id": "conv.item",
      "path": "schemas/session/conversation-item.json"
    },
    {
      "id": "agent.artifact",
      "path": "schemas/agent/child-artifact.json"
    },
    {
      "id": "obs.usage",
      "path": "schemas/obs/usage-record.json"
    }
  ]
}

연동 순서는 언제나 세 단계다. 모델이 DevDay에서 「더 똑똑해지는지」와 무관하다. parse → Schema → 업무 규칙. 잘린 JSON, Schema 오류, MCP arguments 드리프트마다 실제 실패 샘플을 하나씩 남긴다. 연설 당일에는 새 행동을 그 샘플에 대조한다. SNS 요약으로 필드를 짐작하지 마라.

브라우저에서 끝낼 수 있다. JSON 포맷터로 parse를 보고, JSON Schema 검증으로 output과 tools를 보고, JSON Diff로 모델 arguments와 MCP params.arguments를 비교한다. 데이터는 기기를 떠나지 않는다.

더 읽기: DevDay 예측 10개, Assistants → Responses 이전, Structured Output, MCP와 JSON Schema, Stateless MCP, A2A vs MCP.

자주 묻는 질문

요약과 다음 단계

DevDay 2026에서 개발자에게 진짜 중요한 것은 모델 이름을 하나 더 외우는 일이 아니다. 플랫폼이 Responses, Structured Outputs, Tool Calling, MCP를 기본 스택으로 접을 것인가이다. 네 줄은 같은 말을 한다. 평행 API는 줄고, 반드시 지켜야 할 JSON 계약은 늘어난다.

9월 29일 전에 Completions 새 코드를 멈추고, Schema 여섯을 가르고, 실패 샘플을 남겨라. 연설 당일에는 changelog를 대조하고 요약 글을 대조하지 마라. 응답 모양을 확인해야 하면 JSONVue를 열면 된다.