13.7.2 검증 실패 유형별 라우팅 전략 (자동 수정 vs 재시도 vs 사람 개입)

데이터 검증 파이프라인에서 뿜어져 나오는 모든 ValidationError 스택 트레이스(Stack Trace)가 동등한 공학적 무게(Weight)와 치명도(Severity)를 갖는 것은 결코 아니다.
어떤 때는 어이없는 “날짜 포맷 문자열 삐뚤어짐“이나 “불필요한 공백 혼재” 같은 아주 사소하고 원시적인 구문 오류가 발생할 수도 있고, 어떤 때는 3단계 오라클이 “해당 벤더는 국세청 API 조회 결과 2년 전 이미 폐업한 유령 사업자임“이라는 무시무시하고도 리걸(Legal)한 폭탄 에러를 런타임에 던질 수도 있다.

이처럼 차원이 다르게 생성된 두 가지 오류를 그저 똑같은 “시스템 검증 실패“라는 하나의 버킷으로 묶어서, 무지성으로 LLM API를 똑같이 재호출(Retry) 하고 토큰 요금을 소각하는 것은 공학의 치명적인 낭비이자 MLOps 설계의 직무유기다.
스마트한 EVCA 마스터 파이프라인은, 1/2/3단계 계층적 오라클들이 산발적으로 내뱉는 이 수많은 에러의 고유 코드와 원인을 날카롭게 패턴 매칭(Pattern Matching) 하여, 발생한 에러의 그 미묘한 ’질(Quality)’과 ’문맥 상황’에 따라 비동기 파이프라인의 물줄기(Routing)를 ‘자동 수정(Auto-Fix)’, ‘LLM 재시도(AI Retry)’, 혹은 즉각적인 격리 조치인 **‘인간 개입(Human-in-the-Loop, HITL)’**의 세 갈래로 가장 지능적이고 경제적으로 갈라쳐(Triage) 내야만 한다.

1. Type 1: 파이썬 기반의 결정론적 자동 수정 (Deterministic Auto-Fix)

이 유형의 실패는 데이터의 결함이 육안으로 명백하지만, 그 결함을 우회하고 치유할 해결(Fix) 수식마저 이미 프로그래밍 세계관에 정해져 있는 경우다. LLM의 파라미터 지능이 0.1%도 필요 없는, 그저 파이썬 내장 str 함수 한 줄로 완벽히 정화해 낼 수 있는 가장 수준 낮은 1차원적 에러를 뜻한다.
비싸고 느린 API 토큰을 소각하며 LLM에게 이 데이터를 다시 풀어보라 맡길 가치가 전혀 없다. 오라클이 정규식(Regex) 스크립트를 통해 스스로 즉시 객체를 정화하고 파이프라인의 다음 단계로 직행시킨다.

• 발생 조건 (Trigger): 대소문자의 지저분한 섞임, 날짜 포맷의 단순 변형(2023.01.01), $1,200.00처럼 통화 기호나 쉼표가 섞여서 Float 파싱이 안 되는 1단계 구문 오류.
• 라우팅 액션 (Routing Action): Pydantic의 @field_validator(mode="before") 레이어를 통해 파이썬의 .replace(), .upper(), .strptime() 알고리즘이 가동되어 오라클이 객체 값을 직접 변이(Mutation) 시키고 자체 교정(Auto-Fix)을 완료한다.
• 리소스 연소 (Cost): LLM 개입 없음. (추가 API 소모 비용 = $0, 지연 시간 = 1ms 미만)

2. Type 2: 오라클 피드백 기반 LLM 자가 수정 (Autonomous Self-Correction)

이 유형의 오류는 무언가 확실히 잘못되었고 파이썬 스크립트로는 도저히 런타임 추론이 불가능하지만, 원본 문서와 문맥을 다시 짚어보면 AI 모델 스스로 다른 노드를 검색하여 고칠 수 있는 ’고지능 영역의 메타 인지적 환각 오류’다. 오라클은 이 순간 정답 자체(Ground Truth)를 던져주지는 못하지만, *“네가 논리적으로 완전히 틀렸다”*는 따끔한 ’힌트 트리거’를 던져주어 LLM의 어텐션을 강제로 다른 곳으로 돌리게끔 유도할 수 있다.

• 발생 조건 (Trigger): “명세의 단가가 10이고 수량이 2라면서 네가 뽑은 라인 합계는 30이다” 거나, “발주일이 청구일보다 미래에 위치한다“라는 2단계 수학/논리적 모순 (Semantic Error).
• 라우팅 액션 (Routing Action): 발생한 에러 메시지(예: LineTotalMismatchException의 구체적 이유)를 텍스트로 직렬화하여, 원본 이미지와 묶어 *“너의 산술 연산이 틀렸으니 에러 코드를 읽고 다시 어텐션을 살펴 재추론하라”*는 꾸짖음 프롬프트와 함께 LLM 엔진 큐(Queue)로 재발송(Retry) 한다. (상세 구현은 13.7.3절 참조).
• 리소스 연소 (Cost): 지수 백오프 기반 최대 Max_Retry=3회 한도까지만 재호출 비용을 지불하고 메타 인지의 회복력에 베팅한다. 만약 3번을 넘어설 경우, 이 데이터는 구제불능이라 간주하여 즉각 Type 3 상태로 비참하게 강등(Demotion) 된다.

3. Type 3: 파이프라인 영구 격리 및 인간 통제관 이관 (HITL Queue Routing)

가장 치명적이고 절망적인 에러로, LLM의 추론 지능이 멍청하거나 부족해서가 아니라, 입력으로 들어온 데이터나 벤더 비즈니스 본연이 지닌 차가운 “독성(Toxicity)과 위법성(Illegality)” 때문에 발생한다. 이 경우는 아무리 구글이나 앤스로픽에 돈(Token)을 쏟아부어 백 번 천 번을 재추론 시켜도 파이프라인의 에러가 뚫리지 않는 근원적인 재앙 사태다.

• 발생 조건 (Trigger): “해당 PO 번호가 사내 ERP 마스터 DB에 없다”(고아/사기 레코드), “국세청 조회 결과 해당 벤더는 이미 3년 전 파산 신고된 기업이다”(치명적 법적 리스크), 13.6.3절에서 강제했던 ’정직한 모름’인 "null" 토큰 반환, 또는 앞선 Type 2 재시도 루프 한도(3/3) 완전 소진.
• 라우팅 액션 (Routing Action): 튜링 머신 기계의 권한으로는 해결 불가 선언. 마스터 파이프라인은 모든 해당 트랜잭션 연산을 즉각 하드 스톱(Hard Stop) 시키고, 스택 트레이스 전면에 붉은색 [HITL_REQUIRED_AUDIT] 메타데이터 태그를 강제로 매핑한다. 그리고 RabbitMQ나 Kafka에 물려 있는 ’인간 검토 보류 전문가 큐(Review Queue)’로 트랜잭션 덩어리를 냅다 던져버리고 파이프라인을 비운다.
• 인간 개입 (Final Judgment): 인간 재무 디버거가 HITL 대시보드 UI를 열어 원본을 대조해 보고, 오라클의 오판이라 판단되면 수동(Manual) 전표 강제 승인(Approve)을 누르거나, 악의적 공급자의 사문서 위조 사기로 간주하여 영구 거절(Reject) 처리를 때려 파이프라인을 종결시킨다.

이토록 거대하고 유려하게 흐르는 동적 라우팅 트리(Dynamic Routing Tree) 구조는, 기업의 심장부 거대 인프라 위에서 발생할 수 있는 클라우드 API 추론 비용과 응답 시간(Latency), 그리고 데이터 생명 주기의 치명도를 가장 완벽하게 저울질하며, 가장 경제적이고 영리한 길로 비정형 트랜잭션을 안내하는 마스터 나침반이 된다.