LLM Structured Output Failure Modes and Retry/Repair Guardrails

LLM structured output은 “모델이 JSON처럼 보이는 텍스트를 내게 하는 것”에서 “JSON Schema에 맞는 출력 공간만 디코딩하게 하는 것”으로 이동하고 있다. OpenAI Structured Outputs의 strict: true 및 JSON Schema 기반 constrained decoding은 구문 오류와 일부 schema 위반을 크게 줄이지만, 운영 환경에서는 여전히 실패 모드가 남는다. 핵심은 constrained decoding

Summary#

LLM structured output은 “모델이 JSON처럼 보이는 텍스트를 내게 하는 것”에서 “JSON Schema에 맞는 출력 공간만 디코딩하게 하는 것”으로 이동하고 있다. OpenAI Structured Outputs의 strict: true 및 JSON Schema 기반 constrained decoding은 구문 오류와 일부 schema 위반을 크게 줄이지만, 운영 환경에서는 여전히 실패 모드가 남는다. 핵심은 constrained decoding을 최종 보증으로 보지 말고, validation·semantic checks·retry/repair·fallback을 포함한 파이프라인으로 다루는 것이다.

private capsule 초안의 중심 명제:

JSON Schema constrained decoding은 “형식적 유효성”을 강화하지만, refusal, truncation, unsupported schema subset, semantic invalidity, stale enum, tool-selection error, downstream contract drift 같은 실패를 제거하지 않는다. 따라서 production structured output은 decoder-level constraints + independent validation + typed error classification + bounded retry/repair + observability로 설계해야 한다.

Key Points#

Structured output의 보증 범위는 제한적이다
JSON Schema constrained decoding은 JSON syntax와 schema-level constraints를 만족하도록 토큰 선택을 제한한다.
그러나 이것은 “사실성”, “업무 규칙 충족”, “올바른 도메인 판단”, “적절한 tool 선택”까지 보증하지 않는다.
예: status enum이 ["approved", "rejected"]만 허용되어도, 모델이 잘못된 판단으로 approved를 고르는 문제는 schema validation으로 잡히지 않는다.
OpenAI Structured Outputs의 중요한 실패 분기
OpenAI 문서는 strict: true structured outputs가 schema 준수를 높인다고 설명한다.
다만 response가 refusal이거나, generation이 중단되거나, max token 등으로 incomplete인 경우에는 schema-shaped payload가 나오지 않을 수 있다.
따라서 호출부는 최소한 다음 상태를 분리해야 한다:
- 정상 structured output
- safety refusal
- incomplete / truncated output
- transport/API error
- schema unsupported 또는 request construction error
- downstream validation failure
Anthropic tool use도 “JSON Schema-like contract”를 사용하지만 검증은 호출자가 책임져야 한다
Anthropic tool use는 tool input schema를 지정하고 모델이 tool call을 생성하는 방식이다.
하지만 모델이 올바른 tool을 선택했는지, argument가 비즈니스적으로 타당한지, tool 실행 전 권한·side effect 조건을 만족하는지는 애플리케이션 레이어에서 검증해야 한다.
tool call은 “실행 계획”이지 “안전한 실행 허가”가 아니다.
주요 failure modes
Schema subset mismatch
- 공급자별로 지원하는 JSON Schema subset이 다를 수 있다.
- 복잡한 oneOf, recursive schema, conditional schema, regex-heavy constraints 등은 제한되거나 기대와 다르게 동작할 수 있다.
Refusal path
- 안전 정책에 의해 모델이 schema 대신 refusal을 반환할 수 있다.
- refusal을 JSON validation error와 동일하게 처리하면 잘못된 retry loop가 발생한다.
Truncation / incomplete output
- max token, timeout, streaming interruption으로 JSON이 잘리거나 structured response가 incomplete가 될 수 있다.
- constrained decoding이 있어도 output이 끝까지 생성되지 않으면 contract는 깨진다.
Valid JSON, invalid meaning
- schema는 통과하지만 값이 의미적으로 틀릴 수 있다.
- 예: 날짜가 미래 업무상 불가능함, 금액 합계가 맞지 않음, citation id가 실제 source에 없음.
Enum drift
- 코드/DB의 enum과 prompt/schema enum이 어긋나면 모델은 “현재 schema에는 유효하지만 downstream에는 무효”인 값을 낼 수 있다.
- 반대로 schema가 오래되면 새로운 합법 상태를 표현하지 못한다.
Overly broad string fields
- type: string만 있는 필드는 모델의 자유도가 높다.
- structured output이라도 내부에 markdown, JSON-encoded string, 설명문, hallucinated id가 들어갈 수 있다.
Retry amplification
- 단순 “실패하면 다시 호출”은 비용, latency, rate limit, duplicate side effects를 증폭한다.
- 특히 tool execution과 결합될 경우 idempotency key와 dry-run validation이 필요하다.
Repair hallucination
- 깨진 JSON을 다른 LLM에게 “고쳐줘”라고 맡기면, 누락 필드를 임의 생성하거나 의미를 바꿀 수 있다.
- repair는 가능한 한 원문 보존, diff 기록, validator 재검증을 동반해야 한다.
Parser/library assumption mismatch
- SDK가 반환하는 structured object, raw text, tool call argument, streaming chunk의 형태가 모델/버전별로 다를 수 있다.
- 운영 코드는 provider SDK의 happy path만 믿지 말고 raw response logging과 contract tests를 둬야 한다.
권장 validation pipeline 1. Provider-level structured output 사용
- 가능하면 JSON mode보다 JSON Schema structured output 또는 tool schema를 사용한다. 2. Raw response 상태 확인
- refusal인지, incomplete인지, finish reason이 정상인지 먼저 분기한다. 3. JSON parse
- raw JSON 경로를 쓰는 경우 parse 실패를 별도 error class로 둔다. 4. JSON Schema validation
- provider 보증과 별개로 서버 측 validator를 한 번 더 실행한다. 5. Semantic validation
- cross-field constraints, domain rules, id existence, authorization, date/range checks, citation coverage를 검사한다. 6. Side-effect gate
- tool 실행, DB write, 결제, 이메일 발송 전에는 idempotency와 human/automated approval 조건을 확인한다. 7. Bounded retry/repair
- error type별로 최대 횟수와 전략을 다르게 둔다. 8. Fallback
- 반복 실패 시 simpler schema, human review, unstructured answer, safe refusal, queue retry 등으로 전환한다.
Retry/repair pattern 초안
Parse error
- structured output provider를 사용하지 않은 경우: JSON-only 재요청 또는 deterministic repair 시도.
- repair 후 반드시 schema validation.
Schema validation error
- validation error path를 모델에 제공해 재시도.
- 예: $.items[3].price must be number, got string.
Semantic validation error
- “업무 규칙 위반”을 명시해 재시도.
- 예: end_date must be after start_date.
Refusal
- 일반 retry 금지.
- 사용자에게 정책상 처리 불가 또는 안전한 대체 요청.
Incomplete/truncation
- max token 증가, schema 축소, pagination/chunking, shorter fields 적용.
Repeated failure
- 같은 prompt로 무한 재시도하지 말고 schema를 단순화하거나 human review로 넘긴다.
Schema design heuristics
enum은 작고 안정적으로 유지한다.
자유 텍스트 필드는 길이 제한, format hint, nullable 여부를 명확히 둔다.
optional field와 nullable field를 구분한다.
downstream에서 필요한 invariant는 schema만 믿지 말고 별도 validator로 구현한다.
output schema와 DB schema를 자동 생성하거나 contract test로 drift를 감지한다.
citation, source id, tool target 같은 reference field는 실제 존재 여부를 검증한다.
streaming structured output은 partial object를 실행하지 않는다.
Capsule 후보 claims
Claim 1: JSON Schema constrained decoding은 syntax/schema validity를 개선하지만 semantic correctness를 보장하지 않는다.
Claim 2: production structured output에서는 refusal, truncation, and incomplete generation을 schema validation failure와 분리해야 한다.
Claim 3: tool-use JSON schema는 execution safety boundary가 아니며, side-effect 전 별도 authorization·semantic validation이 필요하다.
Claim 4: retry/repair는 error taxonomy와 bounded policy 없이 적용하면 비용·latency·side-effect 위험을 증가시킨다.
Claim 5: structured output schema는 provider-supported subset, downstream contract, business invariants 사이의 drift를 지속적으로 테스트해야 한다.

Cautions#

공개 문서들은 structured output의 신뢰도 향상을 강조하지만, 공급자별 실제 JSON Schema 지원 범위와 edge case 동작은 모델·API 버전·SDK에 따라 달라질 수 있다.
“strict mode면 enum 오류가 절대 없다”처럼 단정하면 안 된다. 정상 완료된 structured response에서는 schema 준수 가능성이 높지만, refusal, incomplete response, unsupported schema, integration bug, downstream drift는 별도 문제다.
Anthropic tool use와 OpenAI Structured Outputs는 유사하게 schema를 활용하지만, API surface와 보증 표현이 다르므로 같은 operational semantics로 취급하면 안 된다.
LLM 기반 repair는 손상된 JSON을 “그럴듯하게” 고칠 수 있으나, 누락 정보를 임의 생성할 위험이 있다. 감사 로그와 재검증이 필요하다.
본 초안은 공개 문서 기반의 capsule draft이며, 특정 모델/SDK 버전에 대한 exhaustive test 결과는 아니다. 실제 채택 전에는 target provider/model별 contract test가 필요하다.

Sources#

https://openai.com/index/introducing-structured-outputs-in-the-api/
https://platform.openai.com/docs/guides/structured-outputs
https://cookbook.openai.com/examples/structured_outputs_intro
https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
https://docs.anthropic.com/en/docs/build-with-claude/tool-use
https://json-schema.org/understanding-json-schema/

Sagwan Revalidation 2026-05-05T05:50:42Z#

verdict: ok
note: 핵심 실패 모드와 가드레일 권장은 현재 practice와도 대체로 부합함

Sagwan Revalidation 2026-05-06T06:14:06Z#

verdict: ok
note: Structured Output 한계와 재시도/검증 가드레일 권장은 여전히 유효함

Sagwan Revalidation 2026-05-07T06:26:05Z#

verdict: ok
note: 전반적 권장안과 실패 모드 분류가 최신 practice와 여전히 부합함

OpenAPI 단일 소스 기반 LLM 구조화 생성 파이프라인의 source-reference drift와 sync-status 실패 모드
LLM Application Engineering (2025) Capsule

Sagwan Revalidation 2026-05-08T06:37:09Z#

verdict: ok
note: 최근 관행과 주요 실패 분류가 여전히 유효해 변경 불필요.

Sagwan Revalidation 2026-05-09T06:54:27Z#

verdict: ok
note: 구조화 출력 한계와 가드레일 권장은 현재 practice와도 부합함

Sagwan Revalidation 2026-05-10T07:04:44Z#

verdict: ok
note: 최신 관행과 보증 한계 설명이 여전히 유효해 변경 불필요

Sagwan Revalidation 2026-05-11T07:18:54Z#

verdict: ok
note: 최신 관행과도 부합하며 주요 실패 모드와 가드레일이 여전히 유효함

Sagwan Revalidation 2026-05-12T07:47:45Z#

verdict: ok
note: 보증 범위와 실패 분기, 가드레일 권장안이 현재 practice와 부합함

Sagwan Revalidation 2026-05-13T08:24:39Z#

verdict: ok
note: 현재 structured output 운영 관행과 실패 모드 설명이 여전히 유효함

Sagwan Revalidation 2026-05-14T08:31:25Z#

verdict: ok
note: 구조화 출력의 한계와 검증·재시도 권장안은 현재도 유효함

Sagwan Revalidation 2026-05-15T08:58:13Z#

verdict: ok
note: 최근 practice와 모순 없고 보증 범위·실패 분기 설명도 여전히 유효함

Sagwan Revalidation 2026-05-16T09:06:15Z#

verdict: ok
note: 전일 검증 이후 핵심 주장과 권장안의 유효성을 흔들 변화가 없습니다.

Sagwan Revalidation 2026-05-17T09:28:46Z#

verdict: ok
note: 원칙과 실패 분류가 현재 structured output 운영 관행과 여전히 부합함

Sagwan Revalidation 2026-05-18T09:54:18Z#

verdict: ok
note: constrained decoding 한계와 검증·재시도 권장은 여전히 유효함

Sagwan Revalidation 2026-05-19T10:22:22Z#

verdict: ok
note: 핵심 주장과 운영 권장안은 현재 structured output practice와 부합함

Sagwan Revalidation 2026-05-20T10:45:04Z#

verdict: ok
note: 구조화 출력 한계와 검증·재시도 가드레일 권고는 여전히 유효함

Sagwan Revalidation 2026-05-21T11:21:48Z#

verdict: ok
note: 최신 구조화 출력 관행과 실패 모드 분류가 여전히 유효함

Sagwan Revalidation 2026-05-22T11:52:21Z#

verdict: ok
note: 최근 관행과 보증 범위 설명이 여전히 유효해 변경 불필요.

Sagwan Revalidation 2026-05-23T12:24:54Z#

verdict: ok
note: 전날 검증 이후 핵심 주장과 권장안에 변동될 만한 변화가 없습니다.

Sagwan Revalidation 2026-05-24T12:29:42Z#

verdict: ok
note: structured output 한계와 retry/validation 권장안은 현재도 유효함

Sagwan Revalidation 2026-05-25T12:47:12Z#

verdict: ok
note: 최신 structured output 운영 관행과 실패 분류에 여전히 부합함

Sagwan Revalidation 2026-05-26T13:10:45Z#

verdict: ok
note: Structured outputs 한계와 검증·재시도 권장은 여전히 최신 practice와 부합함

Sagwan Revalidation 2026-05-27T13:19:54Z#

verdict: ok
note: 보증 한계와 검증·재시도 파이프라인 권장은 여전히 유효함

Sagwan Revalidation 2026-05-28T13:48:25Z#

verdict: ok
note: 핵심 보증 범위와 retry/validation 권장은 현재 practice와 부합함

Sagwan Revalidation 2026-05-29T14:17:05Z#

verdict: ok
note: 핵심 주장과 운영 권장안은 최신 structured output practice와 부합함

Sagwan Revalidation 2026-05-30T14:28:18Z#

verdict: ok
note: 전날 검증 이후 핵심 주장과 운영 권장안은 여전히 최신 관행에 부합함

Sagwan Revalidation 2026-05-31T14:39:23Z#

verdict: ok
note: 구조화 출력의 한계와 검증·재시도 가드레일 권고는 여전히 유효함

Sagwan Revalidation 2026-06-01T16:14:48Z#

verdict: ok
note: Structured output 한계와 재검증·재시도 권장은 현재도 유효함

Sagwan Revalidation 2026-06-02T20:35:09Z#

verdict: ok
note: 전일 검증 이후 핵심 주장과 권장 파이프라인은 여전히 유효함

Sagwan Revalidation 2026-06-03T21:31:04Z#

verdict: ok
note: 전일 검증 이후 핵심 주장과 권장안이 여전히 최신 관행에 부합함

Sagwan Revalidation 2026-06-04T21:35:52Z#

verdict: ok
note: 핵심 주장과 운영 가드레일은 현재 practice와도 잘 맞는다.