JSONSchemaBench: 실제 스키마 복잡성으로 인한 LLM 구조적 출력 보장 실패

대부분의 팀은 제약 조건 기반 디코딩(constrained decoding)을 해결된 문제로 여깁니다. JSON 스키마를 추가하면 유효한 JSON을 얻을 수 있다고 믿기 때문입니다. JSONSchemaBench (arXiv:2501.10868)는 9,558개의 실제 스키마를 대상으로 이러한 가정을 테스트한 최초의 체계적인 시도이며, 그 결과는 마케팅 문구만큼 안심할 수준이 아닙니다.

논문 소개

Microsoft Research의 Saibo Geng, Hudson Cooper, Michał Moskal 및 동료들은 실제 운영 환경의 소스에서 추출한 9,558개의 스키마 벤치마크인 JSONSchemaBench를 소개합니다. 여기에는 GlaiveAI 함수 호출 시그니처, 사소한 수준부터 극도로 복잡한 수준까지 계층화된 GitHub 리포지토리, Kubernetes API 설정, Snowplow 이벤트 분석 스키마, JSONSchemaStore 컬렉션 등이 포함됩니다. 연구진은 세 가지 축인 커버리지(프레임워크가 처리할 수 있는 스키마의 비율), 효율성(제약 없는 생성 대비 초당 토큰 오버헤드), 품질(다운스트림 작업 정확도)을 기준으로 Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs, Gemini 등 6개의 제약 조건 기반 디코딩 프레임워크를 평가합니다. 평가 기준에는 준수하는 엔진이 지원해야 할 45개 기능 카테고리를 문서화한 공식 JSON 스키마 테스트 스위트도 포함되었습니다.

이 논문의 핵심 주장은 스키마 복잡성이 유능한 프레임워크와 취약한 프레임워크를 가르는 결정적인 변수이며, 세 가지 축 모두에서 압도적인 우위를 점하는 단일 프레임워크는 없다는 것입니다.

주요 개념

• 스키마 복잡성에 따른 커버리지 급감. 단순한 GlaiveAI 스키마에서는 모든 프레임워크가 86% 이상의 점수를 기록했습니다. 그러나 다단계 중첩, 재귀적 정의, 복잡한 패턴 제약이 포함된 GitHub-Hard 스키마에서는 Guidance가 41%, Llamacpp이 39%, XGrammar가 28%로 떨어졌으며, Outlines는 3%라는 처참한 수치를 기록했습니다. OpenAI는 GitHub-Hard에서 9%에 그쳤고, Gemini는 중간 난이도 이상의 스키마에서 유효한 출력을 전혀 생성하지 못했습니다.
• Kubernetes에서 드러난 XGrammar의 특정 약점. XGrammar는 속도에 대한 강점에도 불구하고 Kubernetes 스키마에서 단 7%의 커버리지만 달성했습니다. 이는 해당 스키마들이 문맥 의존적(context-dependent) 패턴에 의존하는 반면, XGrammar의 문맥 독립적(context-independent) 사전 계산 방식으로는 이를 처리할 수 없기 때문으로 보입니다. 프로덕션 에이전트에게 Kubernetes 설정을 포함한 벤치마크 커버리지는 선택이 아닌 필수입니다.
• 컴파일 실패보다 위험한 과소 제약(Under-constrained). XGrammar는 JSON 스키마 테스트 스위트에서 38개의 과소 제약 오류를 보였습니다. 즉, 선언된 스키마를 위반하는 JSON을 생성하면서도 성공했다고 보고하는 것입니다. Guidance는 이러한 오류가 단 1건뿐이었습니다. 쓰기 작업(write-back) 에이전트의 경우, 컴파일 오류는 설계 시점에 발견되지만, 과소 제약 오류는 아무런 신호 없이 런타임에 데이터를 오염시킵니다.
• Guidance의 패스트 포워딩(fast-forwarding)을 통한 실질적인 50% 속도 향상. 고정된 객체 구조의 필드 이름과 같이 긴 결정론적 시퀀스가 존재할 때, Guidance는 한 번의 디코딩 단계에서 여러 토큰을 전진시킬 수 있습니다. A100의 Llama-3.1-8B에서 Guidance는 출력 토큰당 69ms로 실행되는 반면, 제약 없는 생성은 1516ms가 소요됩니다. Outlines는 토큰당 3046ms로 제약 없는 생성보다 느린데, 이는 주로 스키마당 38초가 걸리는 사전 오토마톤 컴파일 때문입니다.
• 제약 조건 기반 디코딩의 추론 정확도 소폭 향상. GSM8K(수학)에서 Guidance는 정확도를 80.1%(제약 없음)에서 83.8%로 끌어올렸습니다. Last Letter 및 Shuffle Objects에서도 1~3포인트의 향상이 있었습니다. 이는 JSON 형식을 강제하면 답변 품질이 떨어진다는 널리 알려진 우려를 반박하는 결과입니다. 하지만 효과 크기가 작기 때문에 형식 선택이 프레임워크 선정의 주된 이유가 되어서는 안 됩니다.
• 45개 JSON 스키마 기능 카테고리를 모두 지원하는 프레임워크는 없음. Guidance는 13개, Llamacpp와 XGrammar는 각각 1개, Outlines는 0개를 지원합니다. 실질적인 의미는 if/then/else, unevaluatedProperties, 또는 재귀적 $ref 정의를 사용하는 모든 스키마가 어떤 엔진을 사용하느냐에 따라 예측 불가능하게 작동할 수 있다는 것입니다.

유효한 점과 그렇지 않은 점

이 벤치마크의 가장 큰 공헌은 스키마 소싱에 있습니다. 이전의 평가는 조잡한 스키마나 단일 소스 컬렉션을 사용했습니다. 함수 호출 시그니처와 함께 Kubernetes 설정을 포함한 것은 적절한 수준의 적대적 다양성을 제공합니다. 또한 복잡성 계층화(trivial부터 ultra까지)는 실무자들에게 보정 곡선을 제공합니다. 여러분의 스키마가 GlaiveAI 함수 호출과 비슷하다면 XGrammar나 Guidance 모두 괜찮지만, Kubernetes 매니페스트와 비슷하다면 선택지는 급격히 좁아집니다.

주요 약점은 단일 샘플 그리디(greedy) 평가 방식입니다. 스키마당 한 번의 생성으로 커버리지를 측정하는 것은 실제 성능을 과소평가할 수 있습니다. 프레임워크가 20%의 확률로 실패하더라도 재시도 시 성공할 수 있기 때문입니다. 논문에서도 이를 인정하지만, 실패 시 재시도하는 프로덕션 시스템에서 중요한 온도 샘플링 기반의 pass@k 수치는 보고하지 않았습니다.

또한 비교 대상에 서로 다른 모델이 섞여 있습니다. 오픈 소스 프레임워크(Guidance, Outlines, Llamacpp, XGrammar)는 Llama-3.2-1B에서 테스트된 반면, OpenAI와 Gemini는 자체 비공개 모델을 사용했습니다. OpenAI의 GitHub-Hard 커버리지 9%는 제약 조건 기반 디코딩 아키텍처만큼이나 모델 자체의 성능을 반영할 가능성이 큽니다. 공정한 비교를 위해서는 통제된 모델 접근이 필요하지만, 저자들이 상용 제공업체에 이를 강제할 수는 없었을 것입니다.

금융 AI(Finance AI)에 중요한 이유

모든 Beancount 라이트백(write-back) 에이전트는 구조적 출력을 생성합니다. 에이전트가 Beancount 지시어를 .beancount 구문으로 변환하기 전에 JSON으로 생성하거나, JSON 스키마를 통해 도구를 호출한다면, JSON 생성의 신뢰성은 단순한 세부 사항이 아니라 시스템의 핵심입니다. FinTrace 논문은 프론티어 모델들이 도구 출력에 대한 추론에 실패한다는 것을 보여주었습니다. JSONSchemaBench는 또 다른 문제를 드러냅니다. 추론 이전 단계인 포매팅 레이어에서조차 규격을 준수하지 않는 출력을 조용히 내보낼 수 있다는 점입니다.

특히 Kubernetes 결과는 Beancount에 시사하는 바가 큽니다. 장부(Ledger) 스키마는 단순한 키-값 쌍의 나열이 아닙니다. 계정 계층 구조, 트랜잭션 메타데이터, 태그 구조는 Kubernetes API 객체와 유사하게 중첩된 재귀 패턴을 생성합니다. Kubernetes에서 7%의 점수를 받은 프레임워크는 토큰당 오버헤드가 아무리 빠르더라도 복잡한 장부 스키마를 처리할 준비가 되지 않은 것입니다.

가장 우려되는 부분은 과소 제약(under-constrained) 실패 모드입니다. XGrammar를 사용하는 Beancount 에이전트는 프레임워크의 내부 유효성 검사는 통과하지만 실제 스키마는 위반하는 트랜잭션을 생성할 수 있으며, 이 경우 에이전트는 재시도할 이유를 찾지 못합니다. 소리 없는 데이터 오염은 눈에 보이는 실패보다 훨씬 위험합니다.

더 읽어보기

• XGrammar (arXiv:2411.15100, Dong et al.) — 테스트된 가장 빠른 프레임워크 중 하나의 기술 논문으로, 문맥 독립/의존 토큰 분할과 Kubernetes 스키마가 왜 이를 압박하는지 설명합니다.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — 제약 조건 기반 디코딩의 토큰 마스킹이 모델의 확률 분포를 왜곡할 수 있음을 보여주고 수정된 샘플링 알고리즘을 제안합니다. 이 벤치마크가 간접적으로만 측정한 품질 문제에 대한 이론적 근거를 제공합니다.
• XGrammar-2 (arXiv:2601.04426) — 멀티턴 세션 중에 스키마 자체가 변하는 에이전트 환경의 동적 스키마로 XGrammar를 확장한 후속 연구로, 활성화된 계정 유형에 따라 출력 형식을 조정하는 Beancount 에이전트와 직접적인 관련이 있습니다.