3.3.2.2 JSON, XML, Plain Text 등 출력 형식이 내용 검증에 미치는 영향 배제

결정론적 오라클(Deterministic Oracle)이 검증해야 하는 것은 언어 모델이 생산한 ’순수한 데이터의 가치’이지, 그 데이터를 포장하고 있는 ’포장지의 재질’이 아니다. 즉, 동일한 의미적 데이터 셋을 반환했다면, 그것이 콤마로 구분된 텍스트(CSV)이든, 중괄호로 묶인 형태(JSON)이든, 태그로 감싸진 형태(XML)이든 오라클의 채점 결과는 변함없이 동일한 Pass를 가리켜야 한다.

1. 포맷 종속성(Format Dependency)이 유발하는 오동작

정답지(Ground Truth)를 설계할 때 개발자들이 가장 흔히 저지르는 실수는, 모델의 출력 형태 자체를 정답지의 비교 대상으로 삼아버리는 것이다.

• 안티 패턴 (문자열 일치 기반 검증):

  # 정답지에 JSON 문자열 그 자체를 하드코딩
  expected = '{"name": "Alice", "status": "active"}'
  assert llm_output == expected
  

- **발생하는 문제:** 거대 언어 모델은 확률적 특성상 띄어쓰기 한 칸, 줄바꿈(Newline)의 위치, JSON Key의 순서를 매달 다르게 생성할 수 있다. 심지어 프롬프트 업데이트를 통해 출력 형식을 XML로 변경하기라도 한다면, 기존에 구축해놓은 수만 개의 JSON 기반 정답지들은 데이터 내용의 변경(Data Drift)이 전혀 없이 오로지 '포맷' 때문에 전격 폐기되어야 하는 재앙에 직면한다.

## 2.  파서(Parser) 계층의 도입과 정답지의 추상화


포맷 불가지론(Format Agnosticism)을 구현하기 위해서는, LLM의 날것(Raw) 출력물과 결정론적 오라클 사이에 **'파서(Parser) 및 정규화(Normalization) 전처리 계층'**을 강제로 삽입해야 한다.

- **파서 계층의 역할:** LLM이 어떠한 형태(Plain Text, JSON, XML)로 답변을 뱉어내든, 파서는 이를 시스템이 이해할 수 있는 프로그래밍 언어 종속적인 객체(예: 파이썬의 `Dictionary`나 Java의 `HashMap`)로 역직렬화(Deserialization)해낸다. 이 과정에서 공백, 들여쓰기, 마크다운 코드 블록(```json)의 잔재와 같은 모든 형태적 잡음(Syntax Noise)이 완전히 소거된다.
- **추상화된 정답지:** 정답지 스키마는 특정한 문자열 포맷을 지양하고, 데이터를 검증할 논리적 트리 구조만을 보유한다. 오라클은 "출력물이 중괄호로 시작하는가?"를 묻는 것이 아니라, "역직렬화된 객체의 `status` 속성값이 `active`인가?"를 묻는다.

## 3. 포맷 제약(Format Constraint) 검증과의 분리

"그렇다면 LLM이 프롬프트에서 요구한 JSON 포맷을 어기고 Plain Text로 길게 서술한 것도 정답으로 인정해야 하는가?"라는 의문이 생길 수 있다. 

이 의문에 대한 공학적 해답은 **'내용 검증(Content Validation)'**과 **'포맷 검증(Format Validation)'**의 철저한 파이프라인 분리다. 
1. **포맷 검증 오라클:** JSON Schema 매칭이나 XML 검증기(Validator)를 통해 데이터의 규격을 1차적으로 통과시킨다. 이 오라클은 데이터의 참/거짓에는 관심이 없다.
2. **내용 검증 오라클 (결정론적 정답지):** 1단계를 통과하여 순수한 객체로 변환된 데이터만을 전달받아, 정답지와 비교하여 비즈니스 논리(Logic) 측면의 무결성을 최종 판단한다.

출력 형식의 배제 원칙은 정답지 생태계를 UI/UX나 시스템 아키텍처의 변경으로부터 독립시켜, AI 어플리케이션의 껍데기가 수백 번 바뀌더라도 뼈대인 골든 데이터셋(Golden Dataset)만큼은 영속적으로 보존되게 만드는 핵심 설계 사상이다.