LLM 구조화된 출력의 한계와 복구 전략: outputguard 개발기

섹션별 상세

LLM은 학습 데이터의 영향으로 JSON을 마크다운 블록(```json)으로 감싸거나 파이썬 스타일의 True/False를 사용하는 등 명세를 미세하게 위반하는 경우가 빈번합니다. 이러한 '거의 맞음' 상태의 데이터는 정규식이나 단순 문자열 치환만으로는 완벽하게 처리하기 어렵고 오히려 다른 오류를 유발할 수 있습니다.

288회의 테스트 결과, 마크다운 펜스 사용이 가장 흔한 오류였으며 뒤를 이어 JSON에서 허용되지 않는 후행 쉼표(trailing comma)와 주석 삽입이 빈번하게 발생했습니다. 특히 문자열 내부의 따옴표 이스케이프 누락이나 토큰 제한으로 인한 객체 중단(truncation)은 단순 파서로는 해결할 수 없는 치명적인 오류로 분류됩니다.

근거

288회의 실제 모델 호출을 통해 주요 제공업체의 구조화된 출력 실패 모드를 분석했습니다. — So I Built a Test Suite 섹션

복구 전략의 적용 순서가 결과의 유효성을 결정짓는 핵심 요소임을 발견하고 인코딩 수정 후 구조적 수정을 진행하는 파이프라인을 설계했습니다. 예를 들어 쉼표를 먼저 수정하면 마크다운 펜스 내부의 데이터와 혼동될 수 있으므로, 반드시 펜스를 먼저 제거한 뒤 구조적 수정을 가해야 상호 간섭을 피할 수 있습니다.

근거

outputguard는 15가지 복구 전략과 2,001개의 테스트 케이스를 포함하고 있습니다. — What I Built 섹션 출처

OpenAI 등에서 제공하는 JSON Mode는 구문적 유효성은 보장하지만 스키마 일치 여부나 토큰 제한으로 인한 중단 문제까지는 해결하지 못합니다. 따라서 프로덕션 환경에서는 유효한 JSON이더라도 필수 필드가 누락되거나 타입이 틀린 경우를 대비한 별도의 검증 및 복구 레이어가 필수적입니다.

기술

Python
outputguard
JSON Schema
OpenRouter

활용 사례

LLM 응답을 DB에 직접 저장해야 하는 경우
RAG 시스템의 구조화된 검색 결과 처리
멀티 에이전트 간의 데이터 규격 준수 보장

언급된 리소스

GitHuboutputguard GitHub Repository