TL;DR
동일한 프롬프트와 단일 JSON Schema를 여러 LLM 공급자에 보내면 출력의 형식적 유효성은 유지되더라도 스키마 계약(필드·타입·배열 구조) 준수는 공급자마다 달랐다. 실험은 다섯 공급자와 동일한 입력을 사용해 150번의 로컬 워크플로우를 돌려 각 응답을 스키마에 대조한 결과를 보여준다. 결과는 공급자별로 스키마 패스, 누락 필드, 잘못된 JSON 등으로 분류되었고(이미지 기준: Schema pass 99, Missing fields 35, Invalid JSON 16, Provider/API 1), 이로 인해 유효한 JSON이더라도 기대하는 계약을 따르지 않으면 다운스트림 파서가 실패한다고 확인됐다. 즉, 모델 간 작은 출력 차이도 프로덕션 파이프라인에서 치명적이다. 따라서 실제 서비스에서는 단순한 포맷 검사뿐 아니라 스키마 검증 단계와 공급자별 예외 처리 또는 파서 견고화가 필요하다. 작성자는 전체 방법론·스키마·샘플 출력·결과를 링크에 문서화해 경험 공유를 요청하고 있다.
섹션별 상세
이미지 분석

이미지는 실험 파이프라인(스키마 → 여러 공급자 → 결과 카테고리)을 도식화하고 각 카테고리별 실행 수치를 제시한다. 이 수치는 '유효한 JSON'과 '계약(스키마) 충족'이 항상 일치하지 않음을 수치로 뒷받침하며, 소규모 차이가 프로덕션 파서에서 문제를 일으킬 수 있음을 시각적으로 강조한다.
다섯 LLM 공급자에 동일 JSON Schema를 적용한 실험 요약 인포그래픽(총 150 실행, Schema pass 99, Missing fields 35, Invalid JSON 16, Provider/API 1).
실무 Takeaway
- 동일한 JSON Schema를 여러 LLM에 사용하면 일부 공급자는 스키마를 더 일관되게 따르고 일부는 필드 누락 또는 무효 JSON을 반환해 파싱 오류를 유발한다 — 따라서 프로덕션에서는 출력 검증이 필요하다
- 유효한 JSON 포맷이 곧 스키마 계약 준수를 보장하지 않으므로 타입·필드 존재 여부를 별도로 검사하는 schema validation 단계를 배치해야 한다
- 공급자별 작은 출력 차이가 downstream parser를 쉽게 깨뜨리므로 공급자 이동성(portability)을 유지하려면 파서 견고화나 공급자 특화 워크어라운드를 도입해야 한다
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.