OpenAI GPT 2026: Function Calling, Structured Outputs, JSON Schema 변화

대조 기준일은 2026년 8월 18일이다. 필드와 동작은 OpenAI Function Calling 가이드, Structured Outputs 가이드를 따른다. 지연·가격·성공률은 지어내지 않는다. 공개 문서가 고정하지 않은 지점은 「실서비스 재생으로 확인해야 함」이라고 밝힌다.

OpenAI 호환 백엔드를 다른 모델로 옮길 때는 구조화 출력과 도구 루프를 따로 검수해야 한다. Base URL만 바꾸면 안 된다. 사이트 안의 OpenAI API를 Kimi K3로 옮길 때 검수표 2026과 맞춰 보면 된다.

결론부터: 세 층이 한꺼번에 바뀌었다

많은 저장소는 아직 2024년 머리로 돌아간다. 프롬프트에 「JSON으로 답하라」고 쓰고, 코드 펜스를 정규식으로 긁는다. 2026년 운영 경로에서는 스키마 위반, 필드 누락, enum 환각이 파서를 그대로 뚫는다.

바꿔야 하는 것은 세 층이지, 더 큰 모델 이름으로 갈아끼우는 일이 아니다.

납품 계약

사용자나 하류 서비스에 넘기는 최종 객체. Structured Outputs를 쓴다(Responses에서는 text.format, Chat Completions에서는 response_format.json_schema).

실행 계약

모델이 도구를 호출할 때 인자는 그 도구 자체의 JSON Schema에 맞아야 한다. 이것이 Function Calling이며, 밑단은 Structured Outputs와 같은 제약 디코딩이다.

호환 계약

옛 JSON Mode(json_object)는 「JSON처럼 보인다」만 보장하고, 필드·타입·enum이 Schema와 같다는 것은 보장하지 않는다. 공식은 Structured Outputs의 전신으로 두었고, 신규 프로젝트의 주경로로 쓰지 말라고 본다.

놓치기 쉬운 제품 쪽 변화도 있다. 새 코드는 Responses API로 간다. Chat Completions는 여전히 쓸 수 있지만 strict 기본값이 다르다. Responses는 Schema를 가능한 한 엄격 모드로 정규화하고, 실패할 때만 되돌린다. Chat Completions 기본값은 여전히 비엄격 최선을 다하기다.

모델과 API 주경로: gpt-5.6 + Responses

Structured Outputs는 GPT-4o 세대부터 쓸 수 있다. 공식이 신규 프로젝트에 권하는 것은 gpt-5.6이다. 더 오래된 gpt-4-turbo와 그 이전 스냅샷에서 문서는 여전히 JSON Mode를 가리키며, 완전한 json_schema 엄격 출력이 아니다.

선정할 때 진입점부터 나눈다

SDK 쪽에서 들일 습관은, additionalProperties를 빼먹기 쉬운 Schema를 손으로 쓰지 않는 것이다. 공식 helper로 타입에서 생성한다. Python은 client.responses.parse(..., text_format=YourModel), JavaScript는 zodTextFormat. 손으로 쓴 Schema가 strict: true 제약을 못 지키면 요청 자체가 거절된다. 「모델이 아무거나 내고 재시도」가 아니다.

Gemini 노선과 비교할 때 「OpenAI SDK 호환」을 Schema 동작까지 같다고 읽지 않는다. Google 쪽 능력 경로는 Gemini 3.5 Pro 신기능: 알아야 할 AI 능력 업그레이드 10가지를 본다. 같은 JSON Schema를 벤더 간에 복사하면 중첩 객체의 additionalProperties가 보통 첫 폭발 지점이다.

JSON Mode, Structured Outputs, Function Calling

운영 사고에서 가장 흔한 혼동은, 로그가 JSON이니 Structured Outputs가 이미 켜졌다고 믿는 것이다. 공식 의미로 나누면 아래와 같다.

Function Calling을 쓰지 말아야 할 때

모델이 시스템에 손댈 필요가 없으면—재고 조회도, 티켓 수정도, 스크립트 실행도 없이 답을 카드·단계·점수로만 쪼개면—Structured Outputs가 맞다. 반대로 출력이 「이 부작용을 실행해 달라」면 반드시 tools다. 함수 인자를 최종 답 Schema로 위장하지 않는다.

거절은 「깨진 JSON」이 아니다

안전 거절 때 모델은 Schema에 억지로 끼워 넣지 않는다. Responses / Chat Completions는 별도의 refusal 필드를 준다. 파싱 층은 거절을 일급으로 다룬다. 먼저 refusal, 그다음 output_parsed. 빈 객체를 성공으로 치지 않는다.

Strict JSON Schema의 하드 규칙

strict를 켜면 OpenAI가 받는 것은 JSON Schema의 부분집합이지, 임의의 Draft 2020-12 문서가 아니다. 요청 단위에서 가장 자주 벽에 부딪히는 세 가지는 다음과 같다.

1. properties에 나온 필드는 모두 required 배열에 있어야 한다.
2. 중첩을 포함한 모든 object에 additionalProperties: false가 필요하다.
3. 루트 객체는 anyOf가 될 수 없다. 선택은 「필수 + null 허용」으로 쓴다. 예: ["string", "null"].

즉 required에서 빼서 선택인 척하기는 strict에서 바로 400이다. 올바른 쓰기는 필드를 required로 두고 타입을 null 허용 유니온으로 하는 것이다. 애플리케이션 층에서 null을 「미제공」으로 본다.

아래는 운영에서 흔한 「티켓 추출」 객체다. 중첩 object에도 additionalProperties를 쓴 점에 주목한다.

from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()

class Ticket(BaseModel):
    title: str
    priority: str
    assignee: str | None
    tags: list[str]

response = client.responses.parse(
    model="gpt-5.6",
    input=[
        {"role": "system", "content": "사용자 설명에서 티켓 필드를 추출한다."},
        {"role": "user", "content": "로그인 페이지 500, Noah에게 배정, 우선순위 높음, 태그 auth와 api."},
    ],
    text_format=Ticket,
)
ticket = response.output_parsed
print(ticket.title, ticket.priority, ticket.assignee)

디버깅 중 요청이 거절되면 먼저 오류 메시지에 빠진 제약을 본다. 모델을 내리는 것은 그다음이다. Playground가 만든 Schema는 기본이 이미 strict이므로, 저장소에 그대로 복사하는 편이 「옛 json_object 프롬프트를 고치는」 것보다 보통 빠르다.

벤더를 넘길 때 한 번 더 맞춘다. 「모든 object에 false」인 같은 Schema가 일부 호환 게이트웨이·다른 모델에서는 HTTP 400이 될 수 있다. 그때는 업무 Schema를 세 벌 두지 말고 공급자별 변환을 둔다.

Function Calling 2026: strict, tool_search, custom tools

공식은 이제 Function Calling과 tool calling을 같은 일로 본다. JSON Schema로 호출 가능한 함수를 적고, 앱 쪽 실행기로 부작용을 돌린다. 2026년 문서에서 추가되거나 강조된 항목은 Agent 루프를 바로 바꾼다.

strict 기본값은 추측하지 않는다

• 항상 strict: true를 명시한다.
• Responses: strict를 생략하면 서버가 Schema 정규화를 시도한다. 실패하면 비엄격으로 돌아가고, 응답의 tool은 strict: false로 보인다.
• Chat Completions: 생략 시 기본은 비엄격이다.
• 미세조정 모델이 한 턴에 여러 함수를 부르면, 문서는 그 턴에서 strict가 꺼질 수 있다고 적는다.

도구 정의는 컨텍스트에 들어가고 입력 토큰으로 과금된다. 설명이 너무 길거나 한 번에 40개를 걸면 청구와 도구 선택 정확도가 같이 나빠진다. 도구가 많으면 tool_search로 저빈도 도구를 지연 로드한다. gpt-5.4 이상만. 루프에서는 tool_search_call / tool_search_output이 먼저 나온 뒤 실제 function_call로 들어갈 수 있다.

custom tools: DSL을 JSON 객체에 구겨 넣지 않는다

function tools는 구조화 인자에 맞다. custom tools는 자유 텍스트 입출력에 맞고, 문맥 자유 문법(CFG)을 붙일 수 있다. SQL 조각, 내부 질의 언어, 종결 기호가 서로 배타여야 하는 형식은 「string 필드에 프롬프트를 쌓는」 것보다 CFG가 안정적이다. CFG가 unexpected tokens를 내면 먼저 종결자의 겹침을 보고, 모델을 탓하지 않는다.

tools = [{
    "type": "function",
    "name": "get_order",
    "description": "주문 번호로 상태를 조회한다. 사용자가 명확한 주문 번호를 준 경우에만 호출한다.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {"type": "string"},
            "locale": {"type": ["string", "null"]},
        },
        "required": ["order_id", "locale"],
        "additionalProperties": False,
    },
}]

실행 루프 자체는 같다. finish_reason / item type이 도구 호출이면 로컬 함수를 돌리고, 결과를 tool 역할로 돌려 다시 요청한다. 바뀐 점은 인자를 json.loads로 운에 맡기지 않아도 된다는 것이다. assistant 메시지 전체(tool_calls 포함)는 반드시 저장한다. 빼면 다음 턴에서 호출 ID가 사라진다.

기존 프로젝트 이관 검수표

「돌아간다」와 「납품할 수 있다」를 나눠 검수한다. 옛 백엔드 스위치는 남겨 두고, 독립 환경에서 실제 트래픽을 재생한다.

1. 모델: 새 경로는 gpt-5.6(또는 계정에서 열린 동급)을 지정한다. 게이트웨이가 조용히 옛 스냅샷으로 매핑하지 못하게 한다.
2. 출력: json_object를 json_schema + strict: true, 또는 Responses의 text.format으로 바꾼다.
3. 도구: 각 function에 required와 중첩 additionalProperties: false를 채운다. 선택 필드는 null 허용 유니온으로 바꾼다.
4. 파싱: parse()와 refusal 분기를 넣는다. 스트리밍에서는 증분 JSON과 최종 parsed 객체가 같은지 확인한다.
5. 도구 면: 열몇 개를 넘으면 tool_search를 검토한다. 먼저 description을 줄이고, 그다음 지연 로드를 본다.
6. 대조: 같은 고정 작업으로 옛 JSON Mode와 새 Schema 경로의 재시도율, 필드 누락률, 수작업 재작업을 비교한다.

통과 기준은 「200이 돌아온다」가 아니다. 파서에 정규식 우회가 없고, 도구 인자 타입이 안정적이고, 거절이 관측 가능하고, 롤백 스위치를 연습했다는 것이다. SDK·재생 스크립트·브라우저 세션을 오래 켜 둘 때 노트북 절전은 대조 실험을 끊는다. 바로 뒤에서 클라우드 Mac mini가 들어가는 지점이다.

FAQ