구조화된 출력의 거짓말: JSON 스키마를 강제했는데, 왜 여전히 틀린 데이터가 나올까?

LLM의 구조화된 출력(Structured Output)이 유행입니다. JSON Schema를 정의하면 AI는 "반드시" 그 형식으로 응답한다고 했습니다. 데이터 파이프라인 문제의 완벽한 해결책처럼 들렸죠.
하지만 현실은 다릅니다.
형식은 맞는데 값이 틀렸다
스키마 검증은 통과합니다. 모든 필드가 정확한 타입입니다. 하지만 실제 데이터는 여전히 환각(hallucination)합니다. 고객 주소를 요청하면 올바른 JSON 구조로 존재하지 않는 주소를 돌려줍니다.
선택지 필드가 예상 밖의 값을 택한다
`"status": ["pending", "completed", "failed"]` 같은 enum을 정의했는데, 모델이 "processing" 같은 값을 끼워 넣습니다. 스키마 검증이 강제되면 에러가 나지만, 일부 모델은 이를 우회합니다.
중첩된 객체에서만 실패한다
최상위 필드는 완벽한데, 깊은 중첩 구조에선 타입 변환이 일어납니다. 배열이어야 할 것이 객체로, 숫자여야 할 것이 문자열로.
왜 일어나나?
Structured Output은 "형식"만 보장합니다. 의미(semantics)는 모델의 예측에 의존합니다. 스키마는 문법 검사기일 뿐, 사실성 검증기가 아닙니다.
해결책은?
스키마 강제 + 추가 검증 로직 | 프롬프트에서 예시(few-shot) 강화 | 신뢰도 낮은 필드는 별도 검증 루프 | 추론 모델(o1)로 한 번 더 검증
Structured Output은 유용하지만, "완벽한 자동화"는 아닙니다.