3.3.4.2 정규 표현식 및 스키마 매칭을 고려한 정답 데이터 구조화

기계 가독성(Machine-Readability)을 극대화하기 위해 정답지(Ground Truth)를 컴파일 가능한 코드 구조(Code Structure)로 선언했다 하더라도, 오라클(Oracle)의 최종 평가 연산 방식이 단순한 일대일 완전 문자열 비교(Exact String Equality, ==)에 머무른다면 해당 통합 테스트(Integration Test)는 여전히 아주 작은 노이즈(Noise)에도 쉽게 깨지는 취약성(Fragility)을 띠게 된다. 본질적으로 자연어(Natural Language)를 생성하고 처리하는 AI 파이프라인(AI Pipeline)에서는 값(Value)의 핵심적인 의미(Semantics)는 완전히 동일하지만 표면적인 문법 형태(Syntax)나 포맷(Format)이 미세하게 달라지는 현상이 필연적으로 발생한다. 이를 기계적으로 오차 없이 포용할 수 있는 패턴 매칭(Pattern Matching) 기술의 도입이 필수적이다.

이러한 유연성을 확보하기 위해, 결정론적 정답지(Deterministic Ground Truth)는 **정규 표현식(Regular Expression, Regex)**과 JSON 스키마(JSON Schema) 형식을 테스트 러너(Test Runner) 아키텍처 레벨에서 적극적으로 네이티브(Native)하게 파싱(Parsing)하고 활용할 수 있도록 그 구조 자체가 다형성(Polymorphism)을 띠게 설계되어야 한다.

1. 정규 표현식(Regex)을 내재화한 정답지 객체 패턴

프로덕션 레벨의 정답지는 특정한 고정 문자열(Hardcoded String) 스트림이 아닌, **‘비즈니스적으로 허용 가능한 문자열의 정규 패턴 집합(Set of Allowed Pattern Strings)’**을 온전히 담아내는 그릇(Container)이어야 한다.

예를 들어, 프롬프트 엔지니어링을 통해 AI가 OCR(광학 문자 인식)된 영수증 텍스트 뭉치에서 날짜(Date) 엔티티를 추출하는 태스크를 수행한다고 가정하자. 이때 테스트 엔지니어가 데이터셋의 정답지에 "2023-10-25"라고 단일 문자열로 하드코딩해 두면, 초거대 언어 모델(LLM)이 문맥을 추론하여 "2023.10.25"나 영국식 표기인 "25/10/2023", 혹은 년도를 축약한 "23/10/25"를 올바르게 출력했을 때 테스트는 AssertionError를 뱉으며 무참히 실패(FAIL)한다. 이런 위양성(False Positive)을 원천 차단하기 위해, 정답지 객체의 데이터 타입 속성(Type Attribute) 자체가 컴파일된 정규식을 지원하도록 시스템을 구조화해야 한다.

Regex 매퍼(Mapper)를 포함한 다형성 정답지 예시:

{
  "test_suite_id": "OCR-DATE-EXTRACT",
  "field": "receipt_date",
  "expected_pattern": "^(?:20)?23[-./]10[-./]25$",
  "match_type": "regex_match"
}


테스트 오라클 시스템은 런타임에 직렬화(Serialization)된 `match_type` 헤더가 `regex_match`인 것을 확인(Condition Check)하면, 바보 같은 `==` 단순 일치 연산 대신 정규식 파서 엔진(Regex Parser Engine) 모듈을 트리거(Trigger)하여 AI의 출력을 더욱 유연하면서도 견고하게(Robust) 검증해낸다.

## 2.  JSON Schema를 이용한 정형 데이터 구조 단언(Structural Assertion)


데이터 엔티티 객체의 무결성(Data Integrity)을 검증할 때는 리프 노드(Leaf Node)에 위치한 개별 필드의 원시 값(Primitive Value)을 대조하는 것을 넘어서, 응답으로 반환된 딕셔너리(Dictionary)나 객체 전반의 **자료형(Data Type), 필수 포함 요소(Required Fields Array), 그리고 중첩(Nested) 깊이가 사전 정의된 API 프로토콜(Protocol) 명세서를 정확히 엄수하는지**를 검증해야 한다. 이때 가장 강력하고 표준화된 공학적 무기가 바로 JSON Schema이다.

정답지 데이터셋 환경은 개별 테스트 레코드(Test Record)와 함께, 해당 레코드 그룹 전체가 상속받아 따라야 할 전역 스키마(Global JSON Schema) 메타데이터 정보를 의존성 주입(Dependency Injection) 형태로 포함해야 한다.

```mermaid
graph TD
    A[LLM 응답 JSON Payload] --> B{오라클 검증 파이프라인}
    B --> C[1단계: JSON Schema Validation]
    B --> D[2단계: Regex / Exact Value Matching]
    
    C -->|Schema 준수| D
    C -->|Schema 위반: Type Error / Missing Key| E[즉시 FAIL 처리 및 Report]
    
    D -->|Pattern Match| F[PASS: 최종 통과]
    D -->|Pattern Mismatch| E
    
    style C fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
    style D fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px

Schema 기반 오라클 정답지 예시:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "user_id": {
      "type": "integer",
      "minimum": 1
    },
    "email": {
      "type": "string",
      "format": "email"
    }
  },
  "required": ["user_id", "email"],
  "additionalProperties": false
}


이러한 스키마 주도형(Schema-Driven) 정답지는 파이썬(Python)의 `jsonschema` 패키지나 타입스크립트(TypeScript)의 `Ajv`와 같은 검증된 산업 표준 라이브러리를 호출함으로써, 단 한 줄의 세련된 코드로 강력하게 유효성 검증(Validation) 및 예외 처리(Exception Handling)가 완결될 수 있다.

결과적으로, 정규 표현식의 유연함과 JSON 스키마 매칭의 엄격함을 기본 스펙 인터페이스(Specification Interface)로 품어낸 정답지는, 텍스트의 단순 비교를 훌쩍 뛰어넘어 **'데이터의 형상(Shape)과 런타임 문법(Runtime Grammar)'을 동시에 채점해 내는 강력한 비즈니스 룰 자동화 엔진(Business Rule Automation Engine)**으로 진화하게 된다. 이는 AI가 내뱉는 수만 가지 변형 텍스트의 폭풍우 속에서도, 엔터프라이즈 시스템이 절대 놓지 말아야 할 굳건한 닻(Solid Anchor)의 역할을 가장 충실히 수행한다.