요약(TL;DR) — 제약된 디코딩(Constrained decoding)과 JSON 스키마 강제(JSON schema enforcement)는 모델의 출력이 파싱(parse)되는 것을 보장하지만, 그 값이 참인지, 안전한지, 또는 실제 시스템 상태에 근거(grounded)하고 있는지에 대해서는 아무것도 말해주지 않습니다. 구조화된 출력을 API 경계에 있는 신뢰할 수 없는 클라이언트를 대하듯 취급하십시오. 스키마 검증(schema validation)은 첫 번째 단계일 뿐, 작업의 전부가 아닙니다. 프로덕션 환경에 남아있는 위험한 버그들은 더 이상 잘못된 형식의 JSON이 아닙니다. 그것들은 형식이 잘 갖춰진 거짓말입니다.

구조화된 출력(Structured output)은 해결된 문제로 판매되었습니다. 디코더(decoder)를 문법(grammar)에 맞게 제약하고, 모델이 스키마에 따라 유효한 JSON을 생성하도록 강제하면, 초기 LLM 통합 과정에서 골칫거리였던 파싱 오류(parsing errors)가 사라집니다. 실제로 사라졌습니다. 하지만 그 과정 어딘가에서 팀들은 _스키마에 유효함(schema-valid)_을 _정확함(correct)_의 동의어로 취급하기 시작했고, 이러한 대체는 버그처럼 보이지 않는 새로운 유형의 프로덕션 버그를 조용히 일으키고 있습니다. 이 버그들은 마치 깔끔하고 타입이 잘 지정된(well-typed) 데이터처럼 보입니다.

이 점을 명확히 할 가치가 있는데, 왜냐하면 사람들이 함수 호출(function calling)과 구조화된 생성(structured generation)에 대해 이야기할 때 "타입(type)"이라는 단어가 과도하게 많은 역할을 수행하고 있기 때문입니다.

당신이 실제로 얻은 보장

문법 제약 디코딩(Grammar-constrained decoding)은 정확히 한 가지 보장만을 제공합니다: 출력이 특정 형태(shape)를 따를 것이라는 점입니다. 만약 당신의 스키마가 status가 세 가지 문자열로 구성된 열거형(enum)이라고 정의한다면, 모델은 그 세 가지 문자열 중 하나를 출력할 것입니다. 만약 amount가 숫자(number)라고 정의되어 있다면, 문장 파편이 아닌 숫자를 얻게 됩니다. 이것은 실제이며 가치 있는 일입니다. 이는 과거에 오염된 응답(malformed responses)으로부터 복구하기 위해 순수하게 존재했던 글루 코드(glue code)라는 범주 전체를 제거해 주었습니다.

하지만 컴파일러 관점에서의 타입 시스템(type system)은 단순히 형태(shape)를 확인하는 것 이상의 역할을 합니다. 타입 시스템은 특정 값이 프로그램의 나머지 부분을 건전하게(sound) 만드는 도메인(domain)에 속하는지 확인합니다. JSON 스키마(schema)는 user_id가 문자열(string)이라고 말할 수 있습니다. 하지만 user_id가 실제로 존재하는 사용자를 참조하는지는 말할 수 없습니다. refund_amount가 양수(positive number)라고 말할 수 있지만, 그 숫자가 계좌의 실제 잔액보다 작거나 같은지는 말할 수 없습니다. date가 ISO 형식을 따른다고 말할 수 있지만, 논리적으로 미래가 될 수 없는 필드에 대해 그 날짜가 미래가 아니라고 말할 수는 없습니다. 문법 제약(Grammar constraints)은 전적으로 값의 구문(syntax) 내부에서만 작동합니다. 이러한 제약은 도메인의 의미론(semantics)을 전혀 들여다볼 수 없습니다. 왜냐하면 그 의미론은 데이터베이스, 비즈니스 규칙(business rules), 그리고 세상의 현재 상태에 존재하며, 디코더(decoder)는 생성 시점(generation time)에 이 중 어느 것에도 접근할 수 없기 때문입니다.

잘 짜여진 거짓말 (Well-Formed Lies)

구조화된 출력(structured output)이 나오기 전에는, 좋지 않은 모델 응답이 대개 파서(parser)를 망가뜨렸습니다. 예외(exception)가 발생하거나, 재시도(retry)를 하거나, 눈에 보이는 실패가 나타났습니다. 그 실패는 짜증스러운 일이었지만 정직했습니다. 시스템이 무언가 잘못되었다고 알려주었기 때문입니다.

이제 실패 모드(failure mode)의 형태가 바뀌었습니다. 모델은 여전히 환각(hallucinate)을 일으키고, 여전히 문맥(context)을 잘못 읽으며, 여전히 불확실성 속에서 추측합니다. 하지만 모델은 이 모든 과정을 완벽하게 유효한 JSON 객체 내부에서 수행합니다. 열거형(enum) 값은 실제로 존재하지만, 단지 잘못된 값일 뿐입니다. 주문 ID(order ID)는 형식이 올바르지만, 존재하지 않을 뿐입니다. 함수 호출(function call)은 올바른 인자 타입(argument types)을 갖추고 있지만, 단지 잘못된 인자 값(argument values)을 가질 뿐입니다. 아무런 예외도 발생하지 않고, 아무런 에러 로그도 남지 않습니다. 2년 전의 잘못된 형식의 응답(malformed response)은 오늘날의 '잘 짜여진 거짓말(well-formed lie)'이 되었습니다. 그리고 잘 짜여진 거짓말은 훨씬 더 잡아내기 어렵습니다. 기존의 관측성(observability)은 의미론적 실패가 아니라 구문 분석 실패(parse failures)를 잡아내도록 구축되었기 때문입니다.

이는 15년 전 웹 개발자들이 클라이언트 측 양식 검증 (client-side form validation)에서 저질렀던 것과 동일한 실수입니다. 즉, "브라우저가 사용자로부터 쓰레기 데이터를 제출하지 못하게 막는다"는 것과 "서버가 수신한 데이터를 신뢰할 수 있다"는 것을 혼동한 것입니다. 우리는 이미 그 교훈을 혹독하게 배운 적이 있습니다. 구조화된 LLM 출력 (Structured LLM output)은 우리에게 이 교훈을 두 번째로 다시 배우라고 요구하고 있습니다. 다만 이번에는 "클라이언트"가 브라우저가 아닌 확률적 모델 (probabilistic model)인 영역이라는 점이 다릅니다. 이로 인해 신뢰할 수 없는 입력은 예측 가능해지는 것이 아니라 오히려 더 예측 불가능해집니다.

함수 호출 (Function Calling)은 당신이 작성하지 않은 RPC 클라이언트입니다

함수 호출 (Function calling)은 그 위험 부담이 더 크기 때문에 이 문제를 더욱 날카롭게 만듭니다. 잘못된 구조화된 객체는 데이터베이스 필드에 저장될 뿐이지만, 잘못된 함수 호출은 _실행_됩니다. 모델은 어떤 메서드를 호출할지, 어떤 인자 (arguments)를 사용할지를 결정하며, 당신이 제공한 도구 스키마 (tool schema)는 문서일 뿐 강제 가능한 의미에서의 계약 (contract)이 아닙니다. 스키마는 인자의 타입을 제한할 수는 있습니다. 하지만 환불 금액이 원래 결제 금액을 초과할 수 없다는 전제 조건 (precondition), 취소가 이미 배송된 주문을 대상으로 할 수 없다는 전제 조건, 또는 권한 범위가 지정된 작업이 호출자의 테넌트 (tenant) 외부 리소스에 대해 호출될 수 없다는 전제 조건 등을 인코딩할 수는 없습니다.

그러한 전제 조건들은 이미 당신의 코드베이스에 존재합니다. 그것들은 인간이든 프로그램이든 어떤 호출자에 대해서도 확인해야 하는 동일한 불변량 (invariants)입니다. 팀들이 저지르는 실수는 스키마 준수 (schema compliance)가 이미 검증을 수행했다는 이론 하에, 특히 LLM에서 유래한 호출에 대해서만 그 검증을 건너뛰는 것입니다. 하지만 그렇지 않습니다. LLM은 당신이 작성하지 않은 RPC 클라이언트, 당신이 검토하지 않은 코드를 실행하는 클라이언트, 그리고 당신이 명시적으로 비즈니스 규칙을 넣고 하류 (downstream)에서 다시 확인하지 않는 한 당신의 비즈니스 규칙에 대한 개념이 없는 프로세스에 의해 생성된 인자를 가지고 당신의 시스템을 호출하는 클라이언트로 모델링하는 것이 가장 적절합니다.

하나의 계층이 아닌, 두 개의 검증 계층

해결책은 매력적이지 않으며, 신뢰할 수 없는 입력에 대해 항상 존재해 왔던 것과 동일한 해결책입니다. 검증을 하나의 단계로 통합하는 대신, 계층화 (layering)하십시오.

• 경계에서의 스키마 검증 (Schema validation) — 형태(shape), 타입(type), 필수 필드(required fields). 이것은 제약된 디코딩 (constrained decoding)과 JSON 스키마 (JSON schema)가 이미 무료로 제공하는 기능입니다. 이를 유지하되, 여기에 과도하게 투자하지 마십시오.
• 파싱 후, 부수 효과 (side effect) 발생 전의 의미론적 검증 (Semantic validation). 이 ID가 실제 접근 가능한 엔티티로 해결됩니까? 이 값이 단순히 구문론적 범위가 아니라, 도메인의 실제 허용 범위 내에 있습니까? 이 필드들의 조합이 시스템이 실제로 가질 수 있는 상태를 나타냅니까? 이 계층은 모델의 문법이 볼 수 없는 지식을 인코딩하기 때문에 반드시 수동으로 작성(hand-written)되어야 합니다.

두 계층 중 어느 것도 다른 하나를 대체하지 않습니다. 첫 번째 계층만 실행하는 팀은 자신의 요청 검증기(request validator)가 데이터베이스 일관성 검사(database consistency check) 역할까지 수행할 것이라고 믿는 API를 출시하는 것과 같습니다. 두 계층을 모두 실행하는 팀은 LLM 출력을 자신이 완전히 제어할 수 없는 시스템으로부터 오는 모든 입력과 동일한 방식으로 취급합니다. LLM의 실체를 고려할 때, 이것이 바로 정확한 신뢰 수준입니다.

격차 측정하기 (Measuring the Gap)

만약 구조화된 출력 (structured-output) 또는 도구 호출 (tool-calling) 파이프라인을 스키마 준수율 (schema compliance rate)로만 평가한다면, 여러분은 이미 구조적으로 보장된 계층만을 측정하고 있는 것입니다. 이는 결과가 매우 좋게 보일 것이며, 실제 운영 리스크에 대해서는 거의 아무것도 알려주지 않을 것입니다. 중요한 지표는 스키마가 유효한 것과 의미론적으로 유효한 것 사이의 격차입니다. 즉, 잘 형성된 응답이 깔끔하게 파싱된 후 얼마나 자주 도메인 검사를 통과하지 못하는가 하는 점입니다. 그 수치가 바로 구조화된 작업에 대한 실제 환각률 (hallucination rate)이며, 이는 일반적으로 그 어떤 종합 정확도 점수보다 훨씬 더 많은 정보를 제공합니다. 왜냐하면 구문 보장 (syntax guarantees)이 포착하도록 설계되지 않았던 바로 그 실패 모드 (failure mode)를 정확히 분리해내기 때문입니다.

구조화된 출력 (Structured output)이 LLM 통합 (LLM integrations)을 안전하게 만든 것은 아닙니다. 그것은 통합 과정을 읽기 쉽게 (legible) 만들었을 뿐입니다. 가독성 (Legibility)은 진정으로 유용합니다. 파싱 (parse)할 수 없는 것은 검증 (validate)할 수 없기 때문입니다. 하지만 이는 신뢰 경계 (trust boundary)의 끝이 아니라 시작일 뿐입니다. 스키마 (schema)를 증명 (proof)이 아닌 캐스트 (cast, 틀)로 취급하고, 다른 신뢰할 수 없는 호출자 (untrusted caller)를 위해 구축했을 법한 의미론적 검사 (semantic checks)를 구축하십시오. 모델은 완벽하게 유효한 JSON 내부에서도 계속해서 자신만만하게 틀린 답을 내놓을 것입니다. 당신의 검증 레이어 (validation layer)만이 그 자신감과 당신의 프로덕션 데이터 (production data) 사이를 가로막고 있는 유일한 방어선입니다.