10.2.3 구조화된 출력(Structured Output) 데이터셋: JSON/XML 스키마 정합성(Schema Consistency) 검증용

엔터프라이즈 B2B 환경에서 최신 파운데이션 모델(Foundation Model) 기반의 AI 에이전트는 더 이상 단순하게 사람과 핑퐁 대화를 나누는 심심풀이 챗봇(Chatbot) 문학가가 아니다. 그들은 방대한 사내 백엔드(Backend) 분산 마이크로서비스(MSA) 시스템과 실시간으로 동기화(Sync)되며 명령을 수행하는 **‘자동화 데이터 파이프라인의 핵심 라우팅 노드(Routing Node)’**로 기능한다.

법인 카드 영수증 이미지 비전 모델에서 비정형 텍스트를 파싱하여 관계형 DB에 INSERT 하거나, 사용자의 자연어 일정 예약 질문을 사내 백엔드 API 호출 규격 구조에 완벽하게 맞춰 JSON 페이로드(Payload)로 파라미터화(Parameterization)하는 연산 과정에서는, 거대 언어 모델이 자랑하는 화려하고 유창한 문학적 생성 능력은 철저히 배제되어야 한다. 이 단계에서는 오직 기계 장치와 파서(Parser)가 에러 없이 단번에 읽어낼 수 있는 완벽한 이진 구문(Binary Syntax)과 문법적 무결성만이 유일한 지상 과제다.

’구조화된 출력(Structured Output)용 골든 데이터셋’은 예측 불가능한 AI가 생성한 JSON, XML, YAML 데이터 덩어리가 시스템이 요구하는 백엔드 스키마 제약(Schema Constraints)을 단 1바이트의 문법적 오차나 환각 없이 100% 충족하는지를 폭력적으로 판별해 내는 가장 비정하고 강도 높은 통합 테스트(Integration Test) 성격의 검증 잣대다.

1. 데이터셋 스키마 설계: 스키마 완전체 정의와 필드별 하드 검증(Hard Validation) 룰

이 특수 목적 데이터셋이 품고 있는 골든 트루스(Golden Truth)는 기존 자연어 평가의 느슨한 키워드 매칭(Keyword Matching)이나 의미론적 코사인 유사도 수준을 아득히 넘어선다.
데이터셋 메타데이터 구조 내부에는 AI가 반환해야 할 원시 정답 문자열뿐만이 아니라, **‘타겟 스키마(Target Schema)’ 그 자체의 구조적 정의서 기능(예: JSON Schema RFC, OpenAPI Spec)**과 각 필드(Field) 트리가 강제로 가져야 할 원시 타입(Primitive Type) 및 크기 제약 조건이 촘촘하게 하드코딩(Hard-coding) 명시되어야만 한다.

{
  "test_id": "SO-PARSER-042-CRITICAL",
  "category": "Receipt_Extraction_API",
  "input_context": "[Vision OCR Output] 스타벅스 강남점 아이스 아메리카노 4500원 법인카드 결제 완료. 날짜는 23년 10월 24일 오후.",
  "golden_truth": {
    "validation_type": "strict_json_schema",
    "target_schema_uri": "s3://schemas/receipt_v2.json",
    "expected_data_payload": {
      "merchant_name": "스타벅스",
      "total_amount": 4500,
      "currency_iso": "KRW",
      "iso8601_date": "2023-10-24"
    },
    "strict_mode_enabled": true
  }
}

여기서 strict_mode_enabled: true 메타 지시어는, AI가 요구하지도 않은 엉뚱한 추가 필드(예: "item_name": "아이스 아메리카노", "location": "강남점")를 환각적 친절함에 의해 임의로 생성하여 페이로드에 욱여넣었을 때, 결정론적 오라클이 코드 단에서 자비 없이 HTTP 400 Bad Request 처리와 유사한 테스트 REJECT를 던져야 함을 의미한다(additionalProperties: false 룰 검증 강제 수행).

2. Pydantic 오라클 연동 매핑: 구문(Syntax)과 내용(Semantics)의 이중 검증 파이프라인

구조화된 데이터셋을 평가하는 오라클 아키텍처는 단일 LLM 판사(LLM-as-a-Judge)에 의존하는 허술함을 버리고, C++ 컴파일러 레벨의 확정적(Deterministic) 2-Step 검증 깊이(Depth)를 가져야 한다.

1. Step 1. 구문 및 타입 검증 오라클 (Syntax & Type Oracle):
   파이프라인의 가장 낮고 물리적인 계층의 검증이다. 정규표현식으로 대괄호 껍데기만 살피는 느슨한 정적 분석 대신, Pydantic(파이썬 생태계)이나 Zod(타입스크립트 생태계)와 같은 가장 가혹한 애플리케이션 데이터 검증 라이브러리를 오라클 러너(Judge Runner)의 심장부로 직접 투입한다.
   AI의 출력 텍스트 스트림을 메모리로 파싱(json.loads())하여, 추출된 total_amount가 정말로 정수형(Integer) 자료형인지, iso8601_date가 글로벌 날짜 포맷 규격을 완벽히 따르는지 가장 먼저 원천적으로 기계 검사한다. 여기서 AI가 흔히 저지르는 실수인 JSON 마크다운 백틱 래퍼(json )가 깨져있거나, trailing 쉼표(,) 하나라도 문법에 어긋나게 누락되거나 붙어있다면, 로직은 뒤도 돌아보지 않고 즉시 파싱 에러 실패(Fail) 처리한다.
2. Step 2. 의미론적 데이터 체커 (Semantic Payload Checker):
   Step 1의 빡빡한 구문 파싱 레이어를 성공적으로 버텨냈다면, AI가 입력 컨텍스트에서 기계적으로 추출한 Value 값이 골든 데이터에 명시된 expected_data_payload와 논리적으로 ‘팩트 타격’ 일치하는지를 검증한다. (예: OCR 컨텍스트의 4500원이 정확히 Value로 들어갔는가?).
   이때 단순 무식한 산술 == 문자열 비교뿐만 아니라, 오라클 러너(Runner) 백그라운드 코드를 통해 모델이 출력한 “4,500” 문자열을 정수 4500으로, 인간이 쓴 “2023/10/24” 날짜를 “2023-10-24“로 코드 레벨에서 정규화(Normalization / Type Coercion) 한 뒤 안전하게 비교 채점하는 세련된 관용(Tolerance) 로직 계층이 추가로 필요할 수 있다.

이처럼 철두철미하게 이중 구조화된 데이터셋 아키텍처는, 엔지니어가 선의로 수정한 한 줄의 프롬프트 엔지니어링 변경이, 나비효과를 일으켜 사내 레거시 시스템 간 API 통신 포맷을 박살 내고 백엔드 DB 데이터 적재율(Data Loading Rate)을 0%로 떨어뜨리는 파괴적이고 끔찍한 프로덕션 회귀 영향(Regression Impact)을, 테스트 빌드 타임(Build Time) 초기 단계에서 완벽하게 차단하고 방어해 내는 가장 듬직하고 거대한 인프라 방패다.