15.5.4. 타입(Type) 엄격성 강화/완화에 따른 오라클 수정 가이드라인

JSON Schema 기반의 강제 구조화 출력(Structured Outputs) 환경에서, 특정 필드의 타입(Type) 캐스팅 정책을 어떻게 가져가느냐는 단순한 데이터 파싱의 문제를 넘어 오라클 시스템의 통과(Pass) 곡선을 결정짓는 핵심 파라미터다.

LLM은 본질적으로 숫자가 아닌 ’텍스트(String)를 생성하는 통계적 기계’이다. 따라서 백엔드가 요구하는 정수(Integer)나 열거형(Enum) 타입을 LLM이 온전히 이해하고 반환하길 기대하는 것은 위험한 발상이다. 프로젝트가 고도화됨에 따라 개발팀은 모델링 에러율을 줄이기 위해 어설픈 타입 제산을 완화(Relaxation)하거나, 반대로 극단적인 비즈니스 룰을 지키기 위해 엄격성(Strictness)을 강화해야 하는 상황에 직면한다. 본 절에서는 이러한 타입 정책 변경 시 오라클 코드를 어떻게 연동하고 마이그레이션해야 하는지에 대한 공학적 가이드를 제공한다.

1. 엄격성 완화 (Type Relaxation): Coercion과 유연성의 확보

LLM이 비즈니스 로직은 정확히 이해했으나, JSON 포맷팅 과정에서 미묘한 타입 캐스팅 에러(예: 123 대신 "123" 출력)를 발생시켜 테스트가 실패하는 현상을 ’형식적 오답(Formal False Negative)’이라 한다. 이런 부채를 해결하기 위해 스키마의 타입을 완화(Relaxation)할 때 오라클은 다음과 같이 수정되어야 한다.

Union Type의 허용: 기존 프롬프트 단의 스키마에서 type: integer를 type: [integer, string]과 같이 다형성 지표로 완화해라.
오라클 전처리(Preprocessor)의 주입: 스키마를 유연하게 열어두었으므로, 대신 오라클 파이프라인 안에서 강력한 데이터 정제(Coercion) 단계를 신설해야 한다.

graph TD
    A[LLM Output: `{"price": "100.50"}`] --> B(Pydantic Validator 모드: Coerce)
    B -->|문자열을 Float로 강제 형변환| C{Validator Action}
    
    C -->|성공: 타입 유연성 수용| D[Float 100.50 객체 반환]
    C -->|실패: e.g. "백달러"| E[ValidationError 발생]
    
    D --> F[Golden 정답지 Float(100.5)와 수학적 비교]
    F -->|오차 범위 이내| G[Oracle Pass]

오라클 시스템은 여기서 Validator(strict=False) 모드를 채택해야 한다. 이를 통해 LLM의 변덕스러운 형식 출력은 수용하되, 비즈니스 비교 평가 단계(오라클 패스 판명)는 완벽한 수학적 객체(Float)의 형태로 비교될 수 있다.

2. 엄격성 강화 (Strictness Enforcement): 환각 차단과 명시성

반대로 환자 처방 데이터나 금융 거래 송금액과 같이 극대화된 타입 강결합(Tight-Coupling)이 필요한 도메인이라면, LLM에게 ’추론의 자율성’을 박탈하는 **엄격성 강화(Strictness Enforcement)**가 필수적이다.

이 경우 오라클은 기존의 관용적인 비교를 폐기하고, 타입과 스키마를 무결하게 점검하는 검문소로 리팩토링되어야 한다.

Enum 제약 조건의 완전한 이식: LLM 출력물이 자유 형식의 문자열이 아니라 특정 카테고리("PENDING", "SUCCESS", "FAIL") 내에 안착해야 한다면, JSON Schema에 enum 제한을 명시하고 오라클 코드 내 어설션(Assertion)에서 대소문자나 후행 공백의 자비로운 수용을 즉각 중단해라. 오라클 코드는 assert actual == expected로 원복 되어야 한다.
Schema Strict Mode 활성화: Pydantic 등의 모델러에서 strict=True를 발동시켜, 오라클이 검증을 시작하기도 전에 타입이 어긋난 패킷들을 파싱 레이어에서 파단(Break)시키도록 조치해라.

3. 골든 데이터셋(Golden Dataset) 타입 일괄 변환(Migration)

스키마의 타입 정책이 바뀌면 오라클 평가 로직뿐 아니라, 검증의 기준이 되는 기존 골든 데이터셋의 타입 형상도 일괄 변경되어야 한다.

완화 시: 기존 데이터셋의 정답지가 Integer 형태였다 하더라도, 새로운 유연한 오라클은 이 값을 정상 수용할 것이므로 정답지 데이터를 수정할 필요가 없다. (백워드 호환).
강화 시: 과거에 "10"이라는 문자열 형태로 저장되어 있던 정답지를 전부 Integer 10으로 변환하는 강력한 DB 마이그레이션 스크립트를 작성하여 골든 데이터베이스를 갱신해야 한다. 그렇지 않으면 오라클 코드를 엄격하게 수정하자마자 과거의 모든 회귀 테스트가 폭포수처럼 터지는(Cascading Failure) 참사를 겪게 된다.

4. 소결

타입 엄격성의 조율은 LLM의 창의성(Creativity)과 소프트웨어의 결정성(Determinism) 사이의 밸런스를 맞추는 정밀 공학이다. 타입 제한을 느슨하게 풀어줄 때는 오라클 내부의 전처리 파이프라인을 견고하게 쌓아 올려야 하며, 타입을 엄격하게 조일 때는 과거의 방만한 정답 데이터들을 일괄 소각(Migration)하는 단호함이 필요하다. 이 양방향의 스키마 마이그레이션 가이드를 체득한 조직만이 폭주하는 LLM의 출력을 엔터프라이즈 레벨의 안정성망 안으로 포섭할 수 있다.