구조화 출력은 왜 실패하나: 9개 LLM에서 본 Pydantic 스키마 실패 유형 분석

Why Does Structured Output Fail? An Empirical Study of Prompt-Enforced Pydantic Schemas Across Nine LLMs

Oct 24, 2026•Amit Verma•View PDF

TL;DR Highlight

실패율 하나로는 원인을 몰라, 실패를 유형별로 쪼갰더니 마크다운 펜스가 최다 원인이었다

Who Should Read

프롬프트에 Pydantic 스키마를 넣고 검증·재시도 루프를 돌리는데 실패 원인을 파악하지 못해 고민인 백엔드 개발자

Core Mechanics

유효율 하나로는 원인을 모른다
- 비슷한 실패율의 모델도 지배적인 실패 유형이 서로 달랐다.
- 수정할 곳이 파서인지 스키마인지 재시도 피드백인지 실패율로는 알 수 없다.
마크다운 펜스가 최다 실패 원인이다
- 실패 1,126건 중 markdown_wrap이 681건(60.5%)이었다.
- 펜스를 벗겨도 통과하는 건 48.0%뿐이었다.
펜스 밑에는 길이 위반이 숨어 있다
- 나머지 52.0%는 펜스 안에 다른 위반이 있었고 대부분 길이 제한 위반이었다.
- 파서 에러 메시지는 이 위반을 언급하지 않는다.
길이 제한을 풀면 길이 실패가 사라진다
- Sonnet 4.6은 글자 수 상한을 올리자 length_bound 실패가 18건에서 0건이 됐다.
- 대신 regex_pattern이 지배적 유형이 됐다.
정규식 하나에 두 원인이 섞인다
- ^[a-z][a-z0-9_]{2,30}$ 는 문자 종류와 길이 상한을 한 패턴에 담고 있다.
- 문자 종류만 풀면 앞자리 숫자 위반은 4건에서 0건이 됐지만 길이 초과는 남았다.
같은 모델도 도메인에 따라 실패 양상이 달랐다
- Sonnet 5는 두 도메인 실패율이 비슷했지만 HotpotQA에서는 펜스가 지배적이었다.
- FinanceBench에서는 한 유형이 뚜렷하게 지배하지 않았다.

Evidence

Haiku 4.5는 첫 시도가 전부 실패했다
- 첫 시도 475건이 모두 펜스로 감싸져 엄격 검증에서 떨어졌다.
- 시도 실패율은 66.1%였고 142/166 run만 완료됐다.
펜스 제거 후 재검증 결과
- 펜스 실패 681건 중 327건(48.0%)만 통과했다.
- 나머지는 length_bound 327, regex_pattern 26, missing_field 1건이었다.
Sonnet 4.6에서 상한 완화를 검증했다
- 저장된 medium 출력 178건을 medium_v2 스키마로 재검증하니 길이 실패 18건이 모두 통과했다.
- 유효 출력이 무효가 된 경우는 없었고 실패율은 15.7%에서 5.6%로 줄었다.
재시도 메시지의 32.2%가 숨은 위반을 말해주지 않았다
- 보낸 재시도 메시지 1,101건 중 354건이 파서 에러만 알렸다.
- 이 중 350건이 Haiku 4.5였고 재시도가 소진된 24개 run-node가 모두 길이 문제로 끝났다.

How to Apply

펜스 제거 후 재검증 로그 남기기
- 검증 실패 시 앞뒤 ```json 펜스를 벗기고 다시 model_validate_json을 돌려라.
- 통과하면 '포맷만 문제', 실패하면 남은 에러를 함께 기록해라.
정규식에서 길이 제한 분리하기
- {2,30} 같은 수량자로 길이를 막고 있다면 별도 min_length·max_length 필드로 옮겨라.
- 이렇게 하면 로그에서 길이 위반과 문자 종류 위반이 구분된다.
상한값은 실제 출력 길이로 정하기
- answer·notes 같은 자유 텍스트 필드의 실제 출력 길이를 먼저 재라.
- 상한이 실제 길이보다 낮으면 다운스트림 요구인지 확인하고 상한을 올리거나 프롬프트로 길이를 지시해라.
재시도 피드백을 펜스 제거본 검증 결과로 만들기
- 재시도 메시지를 만들기 전에 펜스를 벗긴 페이로드를 먼저 검증해라.
- 논문은 이 방식을 테스트하지 않았으니 재시도 횟수 변화를 직접 측정해라.
실패 평가는 구성별 유형 분포로 보고하기
- 전체 실패율 대신 모델·스키마별로 실패 유형 비율을 집계해라.
- 숨은 위반도 함께 세라.

Try It

복사해서 바로 해보기

# Python 셸에서 실행: 실패 응답이 펜스 문제인지 숨은 위반인지 구분하는 간이 진단 (논문 방법의 간이 버전)
# 설치: pip install pydantic

import re
from pydantic import BaseModel, Field, ValidationError

class Answer(BaseModel):
    answer: str = Field(min_length=20, max_length=400)

def strip_fence(raw):
    s = raw.strip()
    s = re.sub(r"^```[a-zA-Z]*\n?", "", s, count=1)
    return re.sub(r"\n?```\s*$", "", s, count=1)

def diagnose(raw):
    try:
        Answer.model_validate_json(raw)
        return "valid"
    except ValidationError:
        pass
    if raw.lstrip().startswith("```"):
        try:
            Answer.model_validate_json(strip_fence(raw))
            return "pure_formatting"
        except ValidationError as e:
            return "compound: " + e.errors()[0]["type"]
    return "other"

long_text = "x" * 500
print(diagnose('```json\n{"answer": "' + long_text + '"}\n```'))

# 이어서 해 볼 것: 자신의 로그 응답 {{raw_output}}을 diagnose에 넣어 유형별로 집계해 보기

Terminology

Pydantic파이썬 데이터 검증 라이브러리다. 스키마 클래스를 정의해 두면 들어온 JSON이 규칙에 맞는지 검사해 준다.

markdown_wrap모델이 JSON을 ```json 코드 펜스로 감싸 반환해 엄격 파싱에 실패하는 유형이다. 택배 상자째로 받아 내용물을 못 꺼내는 것과 비슷하다.

constrained decoding생성 중 문법에 맞는 토큰만 허용하도록 막는 방식이다. 이 논문은 다루지 않고 프롬프트+검증 방식만 다룬다.

compound failure펜스 제거 후에도 길이나 패턴 위반이 남은 실패다. 겉 포장을 뜯어도 속 물건에 또 하자가 있는 경우와 같다.

question-clustered bootstrap같은 질문에서 나온 시도를 묶어 재표본해 신뢰구간을 구하는 방법이다. 재시도처럼 서로 독립이 아닌 데이터에 쓴다.

Related Resources

Original Abstract (Expand)

Pipelines that require structured outputs from hosted language models often specify a Pydantic schema in the prompt, validate the response, and retry when validation fails. Although native structured-output modes provide an alternative, application-side validation remains important for enforcing custom constraints. Yet pipeline reliability is often summarized by a single validity rate, which obscures why outputs fail and which interventions may help. We introduce a fine-grained taxonomy of schema-conformance failures and a deterministic classifier that assigns failure categories from model responses and Pydantic validation errors. We apply this framework to 3,997 generation attempts across nine OpenAI and Anthropic model/API configurations, using questions from HotpotQA and FinanceBench. Our results show that similar validity rates can mask different failure patterns, and that dominant failure categories vary with schema constraints and task. Markdown-fenced JSON is the most common failure: among 681 fenced failures, only 48.0% pass validation after fence removal, while the remainder conceal additional violations, predominantly field-length violations. In an exploratory prompt ablation, variants that suppress fences appear to shift failures toward length violations, but the shift is consistent with exposing violations that were already present, illustrating how aggregate validity rates can obscure changes in failure composition. We derive four engineering practices for validator, schema, retry and evaluation design, three supported by our data and one, on retry feedback, proposed but not tested, and release the classifier, completions, and annotations.

구조화 출력은 왜 실패하나: 9개 LLM에서 본 Pydantic 스키마 실패 유형 분석

Why Does Structured Output Fail? An Empirical Study of Prompt-Enforced Pydantic Schemas Across Nine LLMs

Oct 24, 2026•Amit Verma•View PDF

TL;DR Highlight

실패율 하나로는 원인을 몰라, 실패를 유형별로 쪼갰더니 마크다운 펜스가 최다 원인이었다

Who Should Read

프롬프트에 Pydantic 스키마를 넣고 검증·재시도 루프를 돌리는데 실패 원인을 파악하지 못해 고민인 백엔드 개발자

Core Mechanics

유효율 하나로는 원인을 모른다
- 비슷한 실패율의 모델도 지배적인 실패 유형이 서로 달랐다.
- 수정할 곳이 파서인지 스키마인지 재시도 피드백인지 실패율로는 알 수 없다.
마크다운 펜스가 최다 실패 원인이다
- 실패 1,126건 중 markdown_wrap이 681건(60.5%)이었다.
- 펜스를 벗겨도 통과하는 건 48.0%뿐이었다.
펜스 밑에는 길이 위반이 숨어 있다
- 나머지 52.0%는 펜스 안에 다른 위반이 있었고 대부분 길이 제한 위반이었다.
- 파서 에러 메시지는 이 위반을 언급하지 않는다.
길이 제한을 풀면 길이 실패가 사라진다
- Sonnet 4.6은 글자 수 상한을 올리자 length_bound 실패가 18건에서 0건이 됐다.
- 대신 regex_pattern이 지배적 유형이 됐다.
정규식 하나에 두 원인이 섞인다
- ^[a-z][a-z0-9_]{2,30}$ 는 문자 종류와 길이 상한을 한 패턴에 담고 있다.
- 문자 종류만 풀면 앞자리 숫자 위반은 4건에서 0건이 됐지만 길이 초과는 남았다.
같은 모델도 도메인에 따라 실패 양상이 달랐다
- Sonnet 5는 두 도메인 실패율이 비슷했지만 HotpotQA에서는 펜스가 지배적이었다.
- FinanceBench에서는 한 유형이 뚜렷하게 지배하지 않았다.

Evidence

Haiku 4.5는 첫 시도가 전부 실패했다
- 첫 시도 475건이 모두 펜스로 감싸져 엄격 검증에서 떨어졌다.
- 시도 실패율은 66.1%였고 142/166 run만 완료됐다.
펜스 제거 후 재검증 결과
- 펜스 실패 681건 중 327건(48.0%)만 통과했다.
- 나머지는 length_bound 327, regex_pattern 26, missing_field 1건이었다.
Sonnet 4.6에서 상한 완화를 검증했다
- 저장된 medium 출력 178건을 medium_v2 스키마로 재검증하니 길이 실패 18건이 모두 통과했다.
- 유효 출력이 무효가 된 경우는 없었고 실패율은 15.7%에서 5.6%로 줄었다.
재시도 메시지의 32.2%가 숨은 위반을 말해주지 않았다
- 보낸 재시도 메시지 1,101건 중 354건이 파서 에러만 알렸다.
- 이 중 350건이 Haiku 4.5였고 재시도가 소진된 24개 run-node가 모두 길이 문제로 끝났다.

How to Apply

펜스 제거 후 재검증 로그 남기기
- 검증 실패 시 앞뒤 ```json 펜스를 벗기고 다시 model_validate_json을 돌려라.
- 통과하면 '포맷만 문제', 실패하면 남은 에러를 함께 기록해라.
정규식에서 길이 제한 분리하기
- {2,30} 같은 수량자로 길이를 막고 있다면 별도 min_length·max_length 필드로 옮겨라.
- 이렇게 하면 로그에서 길이 위반과 문자 종류 위반이 구분된다.
상한값은 실제 출력 길이로 정하기
- answer·notes 같은 자유 텍스트 필드의 실제 출력 길이를 먼저 재라.
- 상한이 실제 길이보다 낮으면 다운스트림 요구인지 확인하고 상한을 올리거나 프롬프트로 길이를 지시해라.
재시도 피드백을 펜스 제거본 검증 결과로 만들기
- 재시도 메시지를 만들기 전에 펜스를 벗긴 페이로드를 먼저 검증해라.
- 논문은 이 방식을 테스트하지 않았으니 재시도 횟수 변화를 직접 측정해라.
실패 평가는 구성별 유형 분포로 보고하기
- 전체 실패율 대신 모델·스키마별로 실패 유형 비율을 집계해라.
- 숨은 위반도 함께 세라.

Try It

복사해서 바로 해보기

# Python 셸에서 실행: 실패 응답이 펜스 문제인지 숨은 위반인지 구분하는 간이 진단 (논문 방법의 간이 버전)
# 설치: pip install pydantic

import re
from pydantic import BaseModel, Field, ValidationError

class Answer(BaseModel):
    answer: str = Field(min_length=20, max_length=400)

def strip_fence(raw):
    s = raw.strip()
    s = re.sub(r"^```[a-zA-Z]*\n?", "", s, count=1)
    return re.sub(r"\n?```\s*$", "", s, count=1)

def diagnose(raw):
    try:
        Answer.model_validate_json(raw)
        return "valid"
    except ValidationError:
        pass
    if raw.lstrip().startswith("```"):
        try:
            Answer.model_validate_json(strip_fence(raw))
            return "pure_formatting"
        except ValidationError as e:
            return "compound: " + e.errors()[0]["type"]
    return "other"

long_text = "x" * 500
print(diagnose('```json\n{"answer": "' + long_text + '"}\n```'))

# 이어서 해 볼 것: 자신의 로그 응답 {{raw_output}}을 diagnose에 넣어 유형별로 집계해 보기

Terminology

Pydantic파이썬 데이터 검증 라이브러리다. 스키마 클래스를 정의해 두면 들어온 JSON이 규칙에 맞는지 검사해 준다.

markdown_wrap모델이 JSON을 ```json 코드 펜스로 감싸 반환해 엄격 파싱에 실패하는 유형이다. 택배 상자째로 받아 내용물을 못 꺼내는 것과 비슷하다.

constrained decoding생성 중 문법에 맞는 토큰만 허용하도록 막는 방식이다. 이 논문은 다루지 않고 프롬프트+검증 방식만 다룬다.

compound failure펜스 제거 후에도 길이나 패턴 위반이 남은 실패다. 겉 포장을 뜯어도 속 물건에 또 하자가 있는 경우와 같다.

question-clustered bootstrap같은 질문에서 나온 시도를 묶어 재표본해 신뢰구간을 구하는 방법이다. 재시도처럼 서로 독립이 아닌 데이터에 쓴다.

Original Abstract (Expand)

구조화 출력은 왜 실패하나: 9개 LLM에서 본 Pydantic 스키마 실패 유형 분석

TL;DR Highlight

Who Should Read

Core Mechanics

Evidence

How to Apply

Try It

Terminology

관련 논문

Related Resources

구조화 출력은 왜 실패하나: 9개 LLM에서 본 Pydantic 스키마 실패 유형 분석

TL;DR Highlight

Who Should Read

Core Mechanics

Evidence

How to Apply

Try It

Terminology

관련 논문

Related Resources