13.3.7 구조적 오류 발생 시 LLM 재요청(Retry)을 위한 에러 메시지 템플릿 설계

13.3.7 구조적 오류 발생 시 LLM 재요청(Retry)을 위한 에러 메시지 템플릿 설계

1단계 Pydantic 오라클이 강타입 검증을 통해 ValidationError 익셉션(Exception)을 격발 시키며 환각 데이터의 데이터베이스 삽입을 격추하는 것은, 전체 아키텍처 방어망의 절반을 완성한 것에 불과하다.
AI 주도 소프트웨어 공학에서 진정한 의미의 **‘비결정성의 완벽한 통제’**란, 이 에러가 발생한 직후 백엔드 파이프라인이 수동으로 멈춰버리는 것이 아니라, 시스템 스스로 LLM의 멱살을 잡고 “네가 방금 이 문법 규칙을 위반했으니, 로그를 읽고 문학적 변명 없이 코드를 고쳐서 다시 제출해라” 라고 기계적으로 명령하는 자동 자가 교정(Self-Correction) 피드백 루프를 아키텍처 레벨에 설계하는 데 있다.

대규모 언어 모델(LLM)은 단순히 *“오류가 발생했습니다. 다시 시도해 주세요”*라는 멍청하고 모호한 메시지보다, 파이썬 백엔드가 내뿜은 구체적인 스택 트레이스(Stack Trace)와 스키마 속성 위반 사항을 차가운 JSON 형태로 컨텍스트에 제공받았을 때 스스로 자신의 토큰을 디버깅하고 정답을 교정할 확률이 비약적으로 상승하는 특성을 지닌다.
따라서 우리는 1단계 오라클이 뱉어낸 에러 객체를 캡처하여, LLM 컴파일러가 소화할 수 있는 ’완벽한 압박용 프롬프트 템플릿(Retry Prompt Template)’으로 치환하여 재주입해야만 한다.

1. 에러 객체의 파싱 및 피드백 템플릿 구조화 로직

Pydantic의 ValidationError는 단순히 String 에러를 뱉는 것이 아니다. 내부의 e.errors() 메서드를 호출하면 에러가 발생한 정확한 트리 노드 위치(loc), 기대했던 타입과 어긋난 타입(type), 그리고 입력된 쓰레기 환각 텍스트(input)를 완벽하게 구조화된 딕셔너리(Dict) 리스트 형태로 반환한다. 오라클 설계자는 이를 파싱 하여 LLM의 논리를 굴복시킬 피드백 프롬프트로 역변환한다.

from pydantic import ValidationError
import json

def generate_oracle_retry_prompt(original_text: str, bad_llm_json_output: str, error: ValidationError) -> str:
    """ 
    1단계 구조적 오라클이 거부한 에러 로그를 해부하여, 
    LLM의 어텐션을 강제로 쥐어짜는 재요청(Retry) 시스템 프롬프트를 생성한다. 
    """
    
    error_details = []
    # Pydantic이 반환한 N개의 복합 에러 트리를 순회하며 원인 추출
    for err in error.errors():
        # 에러가 발생한 JSON 트리의 뎁스 경로 (예: items -> 0 -> unit_price)
        field_path = " -> ".join([str(loc) for loc in err['loc']])
        error_msg = err['msg']  # 오라클이 뱉은 차가운 거부 사유
        error_details.append(f"- 환각 발생 필드 경로: [{field_path}]\n  오라클 거부 사유: {error_msg}")
        
    formatted_errors = "\n".join(error_details)
    
    # LLM이 디버깅 컨텍스트(In-context)를 완벽히 이해하도록 압박하는 템플릿
    retry_prompt = f"""
[SYSTEM ORACLE WARNING: STRICT JSON SCHEMA VALIDATION FAILED]
당신이 직전에 생성한 데이터 추출 결과물이 백엔드의 엄격한 데이터베이스 스키마 검증망(Pydantic Oracle)을 통과하지 못하고 치명적 오류를 발생시켜 거부(Rejected)되었습니다. 

[발생한 구조적/타입 오류 상세 원인]
{formatted_errors}

[당신이 직전에 생성했던 실패한 출력 덤프]
{bad_llm_json_output}

[ORACLE INSTRUCTION]
위의 오라클 오류 로그를 정확히 분석하고 당신의 출력을 스스로 디버깅하여 교정하십시오. 
예를 들어 숫자(Float) 필드에 화폐 기호나 문자가 섞여 있거나, 필수 필드 배열(Array)이 비어있거나, 날짜가 ISO 8601 포맷이 아닌 경우 구조 역학이 붕괴된 것입니다. 이를 완벽히 수정해야 합니다.
어떠한 변명이나 사과, 부연 설명 텍스트도 덧붙이지 마십시오. 오직 교정된 올바른 타겟 JSON 객체만을 다시 반환하십시오.
    """
    return retry_prompt

2. LLM의 디버깅 메커니즘(In-context Learning)의 해킹 및 역이용

이 리트라이(Retry) 템플릿의 주입은 단순한 핑퐁 게임이나 에러 로깅이 결코 아니다. 이것은 트랜스포머 아키텍처의 본질을 해킹(Hacking)하는 고도의 인프라 튜닝이다.
LLM의 어텐션 메커니즘은 컨텍스트 윈도우(Context Window) 내에 ’자신이 과거에 저지른 실패 사례(bad_output)’와 ’시스템이 찍어준 매우 구체적인 실패 원인 타겟(error_details)’을 병렬로 함께 제공받았을 때, 어텐션 헤드(Attention Heads)가 오류 지점을 강력하게 집중 참조하게 되는 위대한 ‘문맥 내 학습(In-context Learning)’ 능력을 발휘하여 즉각적인 로직 수리를 수행하게 된다.

시스템이 while문을 통해 이 오라클 검문 및 피드백 구조를 최대 3회(Max Retries = 3) 반복하며 자가 교정 루프를 돌릴 때, 비정형 데이터 추출 파이프라인의 환각 없는 순수 데이터 무결성(Reliability)은 90%에서 99.99%로 극적으로 치솟는다. 이것이 단순한 “파이썬 문자열 파서(Parser)“가 엔터프라이즈의 거룩한 “오라클(Oracle)“로 진화하는 최종적인 공학적 메커니즘이다.

이제 인간의 입력을 엄격한 데이터베이스의 그릇에 담아내는 1단계 구조적(Syntactic) 방어막의 아키텍처 구축을 모두 완벽히 마쳤다. 다음 13.4절에서는 이를 통과한 정제된 규격의 숫자 값들이, 과연 트랜잭션의 ’비즈니스 수학 논리’에 단 1원도 어긋남 없이 부합하는지 덧셈과 곱셈으로 지독하게 검사하는 **‘2단계 의미적/논리적 오라클(Semantic Consistency Oracle)’**의 세계로 진입한다.