JSON 출력 강제는 모델이 "정답"을 안다는 뜻이 아니라 "검증 가능한 형태로 답한다"는 뜻입니다. 구조 통과율과 값 정확도는 별개 지표이며, 프롬프트 지시·JSON mode·Structured Outputs는 보장 범위가 다릅니다. 2026년 기준으로 목표·제약·형식·평가를 분리해 설계해야 실사용 장애를 줄일 수 있습니다.
JSON 출력을 강제하면 모델이 정답을 더 잘 낼까?
아니요, 보장하지 않습니다. JSON 출력 강제는 구조(키·타입·enum)를 지키게 만드는 장치일 뿐, 값이 원문에 근거했는지는 따로 검증해야 합니다. OpenAI 자체 평가에서도 구조 준수율과 내용 정확도는 서로 다른 수치로 보고됩니다.
- 프롬프트 지시만으로는 파싱 가능한 JSON조차 항상 보장되지 않습니다.
- JSON mode는 "파싱 가능"까지만 보장하고, 필수 키·enum·자료형은 보장하지 않습니다.
- Structured Outputs(
strict: true)는 복잡한 스키마 준수 평가에서 100%를 기록했지만, 이는 구조 평가지 내용 정확도가 아닙니다. - 2026년 공개된 구조화 출력 벤치마크에서는 구조가 유효해도 텍스트 83.0%, 이미지 67.2%, 오디오 23.7%까지 값 정확도가 떨어질 수 있었습니다.
- 그래서 통과율과 정확도를 나눠 측정하는 평가 설계가 필요합니다.
실무에서 가장 흔한 함정은 "반드시 JSON만 출력하라"는 지시 한 줄을 넣고 끝내는 것입니다. json.loads()가 성공하면 기능이 완성됐다고 판단하는 팀을 자주 봅니다. 하지만 파싱 성공은 출력 계약의 가장 낮은 단계일 뿐, 필수 필드 누락이나 잘못된 enum 값, 원문에 없는 값을 지어내는 문제는 별도로 드러나지 않습니다. 이 글은 그 다음 단계—스키마 강제와 평가 분리—를 다룹니다.
프롬프트 지시만으로 JSON을 강제해도 괜찮을까?
작동은 하지만 보장 범위가 제한적입니다. OpenAI Structured Outputs 가이드는 일반 JSON mode가 "파싱 가능한 JSON"을 보장할 뿐 필수 키·자료형·enum까지 보장하지는 않는다고 설명합니다. 반면 Structured Outputs는 개발자가 제공한 JSON Schema 준수를 목표로 설계된 별도 기능입니다.
OpenAI가 공개한 복잡한 JSON Schema 준수 평가에서 gpt-4o-2024-08-06 + Structured Outputs는 100%를 기록했고, 같은 평가에서 gpt-4-0613은 40% 미만이었습니다. 다만 이는 OpenAI 자체 평가셋 기준이며 모델 버전·스키마·평가셋이 바뀌면 결과가 달라질 수 있습니다. 사용 방식은 response_format 또는 Responses API의 JSON Schema 형식에 strict: true를 지정하는 것이며, 공식 예시는 gpt-4o-mini, gpt-4o-mini-2024-07-18, gpt-4o-2024-08-06 및 이후 지원 모델을 대상으로 제시됩니다. 즉 "강제"의 수준이 프롬프트 지시 < JSON mode < Structured Outputs 순으로 올라가며, 어느 단계를 쓰든 그 단계가 보장하는 범위를 정확히 아는 것이 먼저입니다.
스키마를 설계할 때 무엇부터 고정해야 할까?
형식보다 목표를 먼저 한 문장으로 고정해야 합니다. 예를 들어 "상품명·가격·재고 여부를 원문에 근거해 추출한다"처럼 무엇을 추출·판정할지 정해두지 않으면, 모델이 JSON 형식은 맞췄지만 값의 근거성이나 완전성은 전혀 평가되지 않는 상황이 생깁니다.
목표 다음은 제약입니다. 허용값은 enum, 반드시 있어야 하는 값은 required, 숫자·문자열·배열은 자료형으로 제한합니다. OpenAI 구조화 출력 예제가 강조하는 Structured Outputs의 차이는 누락된 필수 키나 잘못된 enum 값을 구조 단계에서 제한할 수 있다는 점입니다. 형식 설계는 다음처럼 작게 유지하는 편이 유리합니다.
{
"items": [
{
"name": "string",
"price": 0,
"currency": "KRW",
"availability": "in_stock"
}
]
}
필드 수와 중첩을 불필요하게 늘리기보다, 애플리케이션이 실제로 소비하는 값만 남겨야 검증과 장애 추적이 쉬워집니다. 필드가 많아질수록 스키마 통과율은 떨어지고, 어떤 필드가 문제인지 역추적하는 비용도 커집니다.
통과율만 측정하면 무엇을 놓치게 될까?
"JSON 파싱 성공률" 하나만 보면 실제 품질 문제를 놓칩니다. 최소한 다음 다섯 가지를 분리해 측정해야 합니다.
- Schema pass rate: JSON Schema 검증 통과율
- Required-field recall: 필수 필드 누락률
- Type safety: 자료형 일치율
- Value accuracy: 정답 값 일치율
- Abstention accuracy: 원문에 정보가 없을 때
null·unknown등으로 올바르게 보류한 비율
이 다섯 지표를 나누지 않으면, 구조는 100% 통과했는데 값이 틀린 경우를 "성공"으로 잘못 집계하게 됩니다. 테스트셋도 정상 사례만 넣으면 안 됩니다. 필드 누락, enum 밖의 값, 숫자와 통화 혼동, 표 안의 합계 오류, 원문에 없는 값, 긴 문서 후반부의 정보, 저해상도 이미지 같은 사례를 포함해야 실사용 조건에 가까운 평가가 됩니다. 텍스트 입력에서 측정한 수치를 이미지나 음성 입력에 그대로 적용하는 것도 피해야 합니다.
구조가 맞으면 값도 맞다고 봐도 될까?
아니요, 둘은 별개로 측정해야 합니다. 2026년 공개된 구조화 출력 벤치마크는 모델들이 JSON 구조를 잘 지켜도 실제 값 정확도는 더 낮을 수 있다고 보고했습니다. 해당 벤치마크의 최고 Value Accuracy는 텍스트 83.0%, 이미지 67.2%, 오디오 23.7%였으며, 구조적으로 유효한 JSON을 만드는 능력이 원문 값 추출의 정확성을 보장하지 않는다는 점을 보여줍니다.
문서 OCR, 표 이미지, 음성 전사 후 JSON 변환은 텍스트 입력 평가 결과를 그대로 적용하면 안 됩니다. 같은 벤치마크가 텍스트·이미지·오디오 대화에서 구조 준수와 값 일치를 따로 측정한 이유도 여기에 있습니다. 또한 "100% JSON"이라는 수치를 제품 전체 정확도처럼 홍보하는 것도 피해야 합니다. OpenAI의 100% 수치는 gpt-4o-2024-08-06의 특정 복잡 스키마 준수 평가 결과일 뿐, 필드 값의 사실성·원문 누락·OCR 오류·비즈니스 규칙 위반까지 보장한다는 뜻은 아닙니다.
운영에 들어가면 무엇을 추가로 검증하고 기록해야 할까?
Structured Outputs가 스키마 형태를 제한하더라도 애플리케이션 규칙은 여전히 별도로 검사해야 합니다. 가격 범위, 날짜의 업무상 유효성, 합계 계산, 원문 근거 존재 여부는 구조 검증과 다른 레이어의 검사입니다.
검증 실패 시 무조건 같은 요청을 반복하지 말고 실패 유형을 기록하는 편이 좋습니다. missing_required, invalid_enum, wrong_type, unsupported_claim, value_mismatch처럼 분류하면 프롬프트 수정과 모델 교체 중 무엇이 효과가 있었는지 비교할 수 있습니다. 재현을 위해 모델명과 스냅샷, API 방식, JSON Schema, 평가셋, temperature 같은 조건도 함께 저장해야 합니다. 공식 문서의 지원 모델 목록과 API 설명은 계속 업데이트되므로, 내부 문서에는 "2025~2026년 공개 문서 기준이며 모델·API 버전에 따라 변경될 수 있음"을 명시해두는 편이 안전합니다. 비용을 비교할 때도 같은 입력 토큰 수, 출력 토큰 수, 재시도 횟수, 배치 여부, 캐시 사용 여부를 고정한 상태에서만 의미가 있습니다. 조건이 다른 비교는 숫자가 있어도 참고하기 어렵습니다.
핵심 정리
- JSON 출력 강제는 "정답을 안다"가 아니라 "검증 가능한 형태로 답한다"를 보장하는 기술입니다.
- 프롬프트 지시 < JSON mode < Structured Outputs 순으로 보장 범위가 넓어지며, 각 단계의 한계를 구분해야 합니다.
- OpenAI 자체 평가에서 Structured Outputs는 복잡한 스키마 준수 100%, 구버전 모델은 40% 미만을 기록했지만 이는 구조 평가지 내용 정확도가 아닙니다.
- 구조화 출력 벤치마크 기준 최고 Value Accuracy는 텍스트 83.0%, 이미지 67.2%, 오디오 23.7%로, 구조 통과와 값 정확도는 별개로 측정해야 합니다.
- 평가는 Schema pass rate, Required-field recall, Type safety, Value accuracy, Abstention accuracy를 나눠 기록하고, 실패 유형별로 재시도 전략을 설계해야 합니다.