AI 개발

OpenAI DevDay 2026 예측: Structured Outputs, Function Calling, AI Agent는 어떻게 달라질까?

JSONSort 게시 2026-09-02 업데이트 2026-09-02 약 14분

OpenAI DevDay 2026은 샌프란시스코 Fort Mason에서 9월 29일 열립니다. 키노트는 라이브 스트리밍되고, 기술 세션은 API·Agent·프로덕션 패턴을 다룹니다. 제품명은 아직 엠바고이지만 계층은 분명합니다. Structured Outputs는 유효한 JSON을, Function Calling은 호출 의도를, AI Agent는 둘을 실행 가능한 워크플로로 엮습니다. 2025년 이후 공개 API를 기준으로 세 층의 예측과 지금 할 수 있는 JSON Schema 준비를 정리합니다.

읽기 전 요약

층	2026-09 현황	DevDay에서 갈 방향
Structured Outputs	`json_schema` + `strict`로 Schema 준수	더 넓은 Schema 부분집합, 증분 유효 스트림, handoff 기본 적용
Function Calling	`tools[]` / `tool_calls`. `arguments`는 여전히 문자열	네이티브 JSON 인자, 병렬+직렬 계획, MCP 1급 매핑
AI Agent	Responses API + Agents SDK. Assistants API는 8월 26일 종료	타입 있는 handoff, 관측 가능한 JSON, MCP / A2A 연동

공개 API 궤적에 따른 예측이며 공식 의제나 유출이 아닙니다. 9월 29일 키노트가 1차 출처입니다.

DevDay 2026은 언제이며 무엇을 예측하는가

날짜는 확정입니다. 2026년 9월 29일, 샌프란시스코 Fort Mason, 하루. 키노트는 무료 중계, 나머지 세션은 이후 openai.com에 올라갑니다. 현장 신청은 7월 10일 마감, 초대 티켓은 650달러. 올해 처음 본행사 뒤에 DevDay Exchanges가 이어집니다(벵갈루루 10/16, 도쿄 20, 서울 22, 베를린 26, 파리 28, 런던 11/3, 상파울루 6, 멕시코시티 11).

공개 페이지에는 API, Agent, 프로덕션 패턴, 안전이 적혀 있습니다. 제품명은 아직 엠바고입니다. 이 글은 반증 가능한 예측만 합니다. 각 항목은 현재 고통에 대응하고, 행사 후 채점할 수 있습니다. 모델 크기나 하드웨어 소문은 다루지 않고, 매일 쓰는 JSON만 봅니다.

2026년 9월 세 층 기준선

예측 전에 ‘이미 나온 것’을 맞춥니다. 작년 기능을 올해 발표로 착각하지 않기 위해서입니다.

Structured Outputs(2024년 8월~): JSON mode보다 엄격하며 출력은 JSON Schema에 맞아야 합니다. Responses API에서는 text.format, 도구에서는 strict: true입니다.
Function Calling: tools[]를 넣고 tool_calls를 받습니다. arguments는 여전히 문자열화된 JSON이라 호스트가 parse한 뒤 검증해야 합니다.
AI Agent: 프로덕션은 Responses API + Agents SDK로 수렴했습니다. 2025 DevDay의 AgentKit(Agent Builder, ChatKit, Connector Registry)이 상위 오케스트레이션입니다. Assistants API는 2026년 8월 26일 종료되었습니다.

생태계에는 두 층이 더 있습니다. 도구 공급은 MCP Tool Schema vs Function Calling, Agent 상호운용은 A2A Extensions. DevDay가 이 개방 프로토콜을 대체하기보다 OpenAI 호출 프레임에 연결할 가능성이 큽니다.

예측 1: Structured Outputs는 ‘쓸 수 있는 기능’에서 ‘기본 파이프’가 된다

Structured Outputs는 이미 ‘JSON처럼 보이지만 Schema에 안 맞는’ 사고를 막습니다. 남은 마찰은 좁은 Schema 부분집합, 중간에 깨지는 스트림, 불안정한 거부 형태입니다. DevDay에서 가장 가능성 높은 움직임은 Schema를 Agent 파이프라인의 기본 계약으로 만드는 것입니다.

티켓 추출 Schema 예:

{
  "name": "ticket_extract",
  "strict": true,
  "schema": {
    "type": "object",
    "properties": {
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "assignee": { "type": "string" },
      "summary": { "type": "string" },
      "labels": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["priority", "summary"],
    "additionalProperties": false
  }
}

가능성 높은 순:

더 넓은 JSON Schema 부분집합. oneOf, $ref, 제한 재귀는 지금도 자주 깨집니다. 환불 | 교환 | 상담 같은 배타 분기는 납작한 enum이 아니라 oneOf가 필요합니다.
스트림도 증분 유효. 토큰이 오는 대로 표를 그리는 UI는 덜 닫힌 JSON에서 죽습니다. 닫힌 필드는 즉시 검증 가능한 계약이 맞습니다.
거부와 오류도 Schema 위. 안전 거부는 객체 형태를 자주 벗어납니다. 프로덕션은 자유 텍스트가 아니라 유효 JSON refusal이 필요합니다.
한 Schema를 모델 패밀리에서 재사용. 팀은 이미 GPT-5 스냅샷을 오갑니다. ‘한 schema, 여러 스냅샷’이면 어댑터가 줄어듭니다.

JSONSort 포맷으로 괄호를 확인하고, JSON Schema 튜토리얼에서 required / additionalProperties를 대조하세요. 사용자 데이터가 든 모델 출력을 공개 JSON 사이트에 올리지 마세요.

예측 2: Function Calling은 한 번의 호출이 아니라 ‘계획’이 된다

Function Calling은 단일 함수에서 병렬 tool_calls까지 왔습니다. 2026년 병목은 ‘부를까’가 아니라 대규모 오선택, 이중 인코딩, 타입 없는 결과, 손으로 쓴 MCP 매핑입니다. DevDay가 낼 것은 tools 별명이 아니라 호출 계획과 타입 있는 왕복일 가능성이 큽니다.

현재 도구 정의는 여전히 이렇게 생겼습니다:

{
  "type": "function",
  "function": {
    "name": "create_ticket",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "title": { "type": "string" },
        "priority": { "type": "string", "enum": ["low", "medium", "high"] }
      },
      "required": ["title", "priority"],
      "additionalProperties": false
    }
  }
}

핵심 예측:

arguments가 네이티브 JSON 객체(또는 객체+문자열). 두 번째 JSON.parse는 프로덕션 단골 버그입니다. Responses API는 이미 조일 여지가 있습니다.
병렬 + 직렬 계획이 1급. 병렬은 있지만 ‘주문 조회 후 환불’은 프롬프트나 자체 상태기계입니다. depends_on 같은 필드가 있으면 오케스트레이션 한 층이 줄어듭니다.
MCP 도구가 tools[]에 바로 등장. 호스트가 inputSchema → parameters를 손으로 바꾸지 않습니다. MCP가 공급하고 API 층이 의도를 표현한다는 이전 글과 같습니다.
도구 결과도 Structured Outputs. role: tool은 지금 대부분 자유 문자열입니다. 다운스트림 Agent가 받을 수 있는 것은 Schema에 맞는 결과입니다.
도구 50개를 한 번에 넣는 대신 검색. 큰 Schema는 비싸고 오호출을 늘립니다. 짧은 목록을 검색한 뒤 모델에 주는 API가 더 자연스럽습니다.
strict: true가 기본값. 새 연동이 플래그를 외우지 않아도 됩니다.

예측 3: AI Agent는 JSON 계약을 설정이 아니라 런타임으로 쓴다

2025–2026 본선은 Assistants를 떠나 Agents SDK에서 agent·tool·handoff·guardrail을 코드로 쓰는 것입니다. AgentKit은 캔버스, 채팅 UI, 커넥터를 제공합니다. 시각 Agent Builder가 11월 30일 이후 내보내기를 멈출 수 있다는 보도가 있습니다. 공식 안내로 확인하세요. 방향은 분명합니다. 버전 관리되는 코드 오케스트레이션이 내보낼 수 없는 캔버스를 이깁니다.

DevDay가 강조할 것은 ‘또 하나의 챗봇’이 아니라 타입 있는 handoff입니다:

{
  "handoff": {
    "from": "triage",
    "to": "billing_agent",
    "output": {
      "intent": "refund",
      "order_id": "A-1042",
      "confidence": 0.91
    }
  }
}

이 JSON이 SDK 1급 객체가 되면 라우팅은 본문의 “billing”에 의존하지 않습니다. 부가 예측:

Handoff는 output_type 필수. 분류 Agent가 객체를 내고 하류로 넘깁니다. 바로 Structured Outputs입니다.
Trace / Eval은 JSON. 점수, 단계 추적, 회귀 세트는 스크린샷이 아니라 diff 가능한 파일이 됩니다.
MCP와 A2A가 같은 파이프라인에 탑니다. MCP Server가 도구를 주고, A2A가 확장 헤더로 작업을 나눕니다. OpenAI 쪽은 세 번째 상호운용 프로토콜보다 커넥터 레지스트리를 깊게 만들 가능성이 큽니다.
긴 작업은 구조화 체크포인트에서 재개. 컴퓨터 사용과 야간 배치는 대화 이력만이 아니라 복구 가능한 JSON 상태가 필요합니다.

세 층이 하나의 JSON 파이프가 되려면

예측을 쌓으면 2026년 말의 안전한 형태는 삼자택일이 아니라 층입니다:

JSON Schema가 단일 진실. 저장소에 schemas/tools/*.json과 schemas/handoffs/*.json을 둡니다.
Structured Outputs는 사용자 또는 하류 Agent에게 가는 최종 객체를 제약합니다.
Function Calling은 외부 시스템 호출 의도를 제약합니다. 파라미터 Schema는 같은 파일에서 내보냅니다.
Agent 런타임은 handoff JSON으로 경로를 정하고, tool JSON으로 실행하고, trace JSON으로 회고합니다.
MCP / A2A는 호스트 간 공급과 Agent 간 협상을 맡고, 위 세 층을 대체하지 않습니다.

버전이 어긋나면 JSON Diff로 ‘지난주 돌아간 Schema’와 ‘오늘 거부된 Schema’를 비교하세요. ‘모델이 멍청해졌다’의 상당수는 required가 하나 늘어난 것입니다.

지금 준비할 일 (9월 29일을 기다리지 말 것)

도구 인자, handoff 객체, 평가 픽스처를 프롬프트 산문이 아니라 JSON Schema로 쓴다.
새 코드는 Responses API / Agents SDK만 쓴다. Assistants 스레드를 열지 않는다.
도구마다 strict: true를 켜고 CI에서 ajv 등으로 예시 payload를 검증한다.
도구가 열 개를 넘으면 라우팅이나 검색을 넣는다. 카탈로그 전체를 한 요청에 넣지 않는다.
arguments를 문자열 또는 객체로 받아, DevDay 이후 타입 변경에 사이트 전체가 죽지 않게 한다.
비밀·사용자 데이터가 든 tool 응답은 로컬에서만: 포맷, Diff, 업로드 없음.

흔한 오해

예측을 릴리스 노트로 읽기. 9월 29일 전까지 ‘공식 X 출시’ 이차 게시물은 할인하세요. 이 글의 각 항은 무대에서 틀릴 수 있습니다.
Structured Outputs와 Function Calling을 한 스위치로 보기. 전자는 사용자/하류에 말할 형태, 후자는 호출 대상입니다. Agent에서는 둘을 같이 켜는 경우가 많습니다.
DevDay에서 MCP가 공식 프로토콜로 교체된다고 가정. 새 inputSchema보다 커넥터 심화가 더 그럴듯합니다.
내보낼 수 없는 캔버스 워크플로. 시각 Builder를 쓴다면 노드·프롬프트·Schema를 먼저 Git으로 내보내세요.
이중 인코딩된 arguments를 무시. 네이티브 객체가 오기 전까지 이것이 1번 장애입니다.

FAQ

공식 의제인가요?

아닙니다. 일시·장소·주제는 공개 이벤트 페이지, 제품 상세는 현행 API 고통에 따른 예측입니다. 1차 출처는 라이브 키노트입니다.

Structured Outputs가 Function Calling을 대체하나요?

아닙니다. 전자는 최종 객체, 후자는 도구 호출입니다. 2026년 패턴은 겹치기입니다. 같은 Schema가 파라미터와 handoff를 덮습니다.

Assistants가 끝났습니다. 옛 스레드는?

프로덕션은 Responses API + Agents SDK로 옮기세요. 스레드 상태, 도구 정의, 출력 Schema를 먼저 내보낸 뒤 SDK에서 오케스트레이션을 다시 쓰세요. 캔버스 자동 번역을 기다리지 마세요.

티켓이 없습니다. 어떻게 따라가나요?

키노트는 무료, 세션은 이후에 공개됩니다. Exchange 도시 신청은 9월 17일까지입니다. 대부분의 팀에는 행사 후 문서가 복도 질문보다 유용합니다.

도구와 handoff JSON을 어떻게 디버그하나요?

JSONSort로 브라우저 로컬에서 포맷·검증·Diff 하세요. 비밀이 든 tool 응답을 공개 JSON 사이트에 붙이지 마세요.

결론

DevDay 2026이 ‘JSON처럼 보이는 새 형식’을 발명할 가능성은 낮습니다. 더 그럴듯한 결과는 Structured Outputs가 기본 계약이 되고, Function Calling이 의존성 있는 계획이 되며, Agent 런타임이 diff 가능한 JSON 상태기계가 되는 것, 그리고 MCP·A2A에 더 깊게 연결되는 것입니다. 행사 전 레버리지가 큰 일은 제품명 맞히기가 아니라 Schema를 저장소의 단일 진실로 모으는 것입니다. 9월 29일 키노트를 채점하고, 맞는 것은 남기고 틀린 것은 버리세요. JSON 층 준비는 낭비되지 않습니다.

더 읽기

OpenAI Structured Outputs 현행 json_schema와 strict
OpenAI Function Calling tools / tool_calls 메시지 형태
MCP Tool Schema vs Function Calling 도구 JSON의 프로토콜 경계
A2A Extensions와 JSON 프로토콜 멀티 Agent 상호운용의 세 번째 층
JSONSort 로컬 도구함 포맷, 검증, Diff
모든 글 JSON과 AI 개발 노트

변경 기록: 2026-09-02 초고 (DevDay 전 예측)