11.3.3 오라클의 출력 정규화: JSON 포맷을 통한 검증 가능 데이터 구조 정의

11.3.3 오라클의 출력 정규화: JSON 포맷을 통한 검증 가능 데이터 구조 정의

기존 레거시 API가 뱉어내는 응답 페이로드는 종종 무거운 XML 형태이거나, 올드한 프론트엔드 화면 렌더링을 위해 HTML 태그가 섞여 있거나, 심지어 파싱하기 까다로운 파이프(|)나 쉼표 구분의 순수 텍스트(Plain Text) 형태일 때가 많다. 새롭게 이식할 오라클 시스템이 최신 AI 챗봇 파이프라인 및 CI/CD 검증기와 완벽하게 톱니바퀴처럼 맞물기 위해서는, 이 날것의(Raw) 레거시 출력 데이터를 LLM과 자동화 테스트 스크립트(Python, TS)가 가장 잘 이해하고 신뢰하는 데이터 구조인 **‘엄격한 JSON 포맷(Strict JSON Format)’**으로 강제 정규화(Normalization)해야 한다.

1. 문자열 파싱 탈피와 기본 타입(Type) 캐스팅 강제

오라클 출력의 정규화 아키텍처에서 가장 크리티컬한 원칙은 수학적 연산의 결과인 숫자나 논리적 분기인 불리언(Boolean) 값을 절대로 문자열(String) 포맷으로 얼버무려 반환하지 않는 것이다.
기존 레거시 시스템이 오랜 관행으로 인해 <final_price>1,234,000</final_price> 처럼 콤마(,)와 문자열이 섞인 낡은 포맷을 반환한다면, 오라클 래퍼(Wrapper) 계층 공간에서 이를 가차 없이 순수 정수형(Integer)인 1234000으로 런타임 타입 캐스팅(Type Casting)해 내야만 한다. 더불어 단위(‘원’, ‘달러’)나 화폐 기호는 비즈니스 계산과 독립적인 메타데이터 필드로 따로 분리해야 한다.

[지양해야 할 잘못된 오라클 출력 예시]

{
  "calculated_fee": "1,234,000원",
  "approval_status": "가입 불가 (나이 미달)"
}

위와 같이 인간 친화적이지만 문법적으로 모호한 문자열 출력 덩어리는, 이후 LLM 프롬프트에 주입되었을 때 언어 모델의 유연한 환각을 오히려 부추기는 지저분한 트리거가 되며, 파이프라인 마지막 단의 정규식 검증기(Regex Verifier) 작성 시 수백 가지의 복잡한 예외 처리 파싱 로직을 강제하게 만드는 기술 부채(Technical Debt)의 주범이 된다.

[엄격하게 정규화된 이상적인 오라클 출력 예시]

{
  "final_fee_amount": 1234000,
  "currency_code": "KRW",
  "is_approved": false,
  "rejection_reason_code": "AGE_UNDER_18_RESTRICTION"
}

2. 상태 코드(Status Code) 및 에러 플래그의 명시적 정의

출력 정규화 작업 시 JSON 스키마 내에 또 하나 반드시 포함되어야 할 필수 요소는, 계산의 성공 여부나 비즈니스 프로세스의 상태를 하드코딩 형태로 나타내는 명시적인 대문자 영문 ‘이유 코드(Reason Code)’ 혹은 ’상태 플래그(Status Flag)’다.

사실 최신 대형 언어 모델(LLM)은 한국어 자연어로 된 “고객님은 나이가 어려서 가입이 불가능합니다“라는 긴 문장을 컨텍스트로 읽을 때보다, {"is_approved": false, "rejection_reason_code": "AGE_UNDER_18_RESTRICTION"} 이라는 차갑고 명확한 JSON 구조를 시스템 프롬프트(System Prompt)의 변수로 제공받았을 때 압도적으로 높은 추론 능력을 발휘한다. 이 변수를 바탕으로 고객에게 전달할 위로의 거절 사유를 논리적으로 덧붙이거나, 다음 비즈니스 액션(예: “법정대리인의 동의서류를 스캔하여 업로드해 주시겠습니까?”)을 동적으로 트리거하는 과정에서 환각 발생률이 제로(0)에 가깝게 수렴하기 때문이다.

결국 오라클의 JSON 정규화란 단순히 포맷을 예쁘게 통일하는 미용 작업이 아니다. 그것은 **“감정이 없는 룰 엔진 기계가, 확률적이고 유창한 언어 모델 기계에게 보내는 가장 건조하고도 수학적으로 무결한 통신 규약(Protocol)”**을 제정하는 권위적인 행위다. 이 구조화된 JSON 데이터는 이후 챗봇 파이프라인에서 수백만 번 렌더링 컨텍스트로 주입되고, 수천 번 자동화 검증기의 assert(oracle_output.final_fee_amount == llm_extracted.final_fee_amount) 구문을 통해 채점되는 비즈니스 로직의 살아있는 척추 역할을 영속적으로 수행하게 될 것이다.