Structured Output과 JSON mode는 무엇이 다른가

30초 답변

JSON mode는 모델이 문법적으로 유효한 JSON을 내도록 하지만 필요한 필드, 타입, enum, 중첩 구조까지 원하는 schema와 일치한다고 보장하지 않는다. Structured Output은 지원되는 모델·API에서 strict: true를 사용하고 refusal이 없으며 응답이 중도 종료되지 않았을 때 제공한 JSON Schema 일치를 보장해 파싱 실패와 임의 필드를 줄인다.

그러나 schema를 통과했다고 내용이 사실이거나 업무 규칙에 맞는 것은 아니다. 존재하지 않는 주문 ID, 허용 범위를 넘은 금액, 권한 없는 사용자 같은 의미 오류는 서버가 별도로 검증해야 한다.

이 글의 핵심

• JSON 유효성과 schema 일치는 다른 문제다.
• Structured Output은 구조를 안정화하지만 사실성과 권한을 보장하지 않는다.
• refusal, 중단, timeout, schema 버전도 처리해야 한다.

한눈에 보는 차이

OpenAI의 Structured Outputs 안내는 JSON mode가 유효한 JSON을 돕지만 특정 schema 준수를 보장하지 않는 점을 구분한다. 지원 모델·API·schema 제약은 제품 문서의 최신 내용을 확인해야 한다.

예시

주문 조회 결과에 다음 구조가 필요하다고 하자.

{
  "order_id": "string",
  "status": "pending | shipped | cancelled",
  "refundable": true
}

JSON mode에서도 다음처럼 유효하지만 계약과 다른 결과가 나올 수 있다.

{
  "id": 123,
  "state": "배송 중",
  "can_refund": "아마 가능"
}

Structured Output은 필드 이름, 타입, enum을 schema에 맞출 수 있다. 그래도 실제 주문 123이 존재하는지, 환불 가능한 상태인지, 현재 사용자가 볼 수 있는지는 Tool 결과와 업무 규칙으로 검증해야 한다.

Structured Output 이후에도 필요한 검증

의미 검증

• ID가 실제로 존재하는가
• 날짜와 금액 범위가 유효한가
• 필드끼리 모순되지 않는가

권한 검증

• 현재 사용자가 이 주문을 볼 수 있는가
• 이 금액의 환불을 승인할 수 있는가

실행 검증

• idempotency key가 있는가
• 외부 시스템의 현재 상태가 바뀌지 않았는가
• 고위험 작업에 승인이 있는가

예외 처리

• 모델의 안전 거절
• token 한도 또는 중간 종료
• timeout
• schema 버전 불일치
• provider fallback

언제 무엇을 쓸까

JSON이기만 하면 되는 로그·임시 데이터라도 downstream이 필드를 기대한다면 application validation이 필요하다. 시스템 간 계약, Tool 인자, 데이터 추출, UI 렌더링처럼 안정적인 구조가 필요한 경우 Structured Output이 더 적합하다.

자연어 답변까지 모두 JSON으로 만들 필요는 없다. 사람이 읽을 텍스트와 시스템이 처리할 구조화 결과를 분리할 수 있다.

자주 묻는 질문

Structured Output을 쓰면 hallucination이 없어지나?

아니다. 구조에 맞는 잘못된 값이 나올 수 있다. 원문 근거, Tool 결과, 업무 규칙으로 검증한다.

schema가 있으면 prompt는 필요 없나?

아니다. schema는 형식을 제한하고 prompt는 역할, 판단 기준, 근거 사용, 거절 조건을 설명한다.

Function Calling도 Structured Output인가?

Tool 인자에 strict schema 준수를 적용할 수 있지만 Function Calling은 모델이 어떤 기능을 호출할지 결정하는 메커니즘이고 Structured Output은 출력 구조 제약이다. 목적을 구분한다.

근거 자료

• OpenAI Introducing Structured Outputs
• OpenAI Function calling help