13.9.4 스키마 변경 및 문서 양식 변화에 대응하는 회귀 테스트 시나리오

엔터프라이즈의 거시적 비즈니스 환경은 결코 정지해 있지 않는다. 내년도 국가 세법이 개정되어 기존에 없던 ‘환급형 부가세(Refundable VAT)’ 필드가 모든 세금계산서에 의무적으로 추가되거나, 우리 회사의 가장 큰 물류 납품업체가 자신들의 ERP 시스템을 SAP로 교체하면서 하룻밤 사이에 인보이스 문서 양식을 완전히 뒤집어버리는 참사는 아주 일상적인 인시던트(Incident)다.
이때 MLOps 파이프라인 아키텍트는 필연적으로 시스템의 심장부인 Pydantic 스키마(거푸집)를 뜯어고치고 오라클의 2단계/3단계 밸리데이션 룰셋을 새롭게 변경해야만 한다.

하지만 이 외과 수술 과정에서 개발자들이 경험하는 가장 뼈아픈 재앙은, 새로 업데이트한 오라클 코드 한 줄 때문에 **‘과거에 멀쩡하게 잘 통과하던 수천 장의 기존 양식 문서들의 데이터 추출 파이프라인까지 연쇄적으로 붕괴해 버리는(Regression) 현상’**이다. 이를 원천 봉쇄하기 위해 가동되는 것이 바로 **‘테스트 주도 유지보수(Test-Driven Maintenance)’**의 마스터 시나리오다.

1. 하위 호환성(Backward Compatibility)을 보장하는 점진적 스키마 확장

세법 개정으로 refundable_vat라는 새로운 필수 필드를 Pydantic 스키마에 추가해야 한다고 가정해 보자. 우리가 보유한 수십만 건의 과거(Legacy) 영수증들에는 이 텍스트 필드 자체가 아예 존재하지 않는다.
초보 개발자처럼 생각 없이 단순히 스키마에 refundable_vat: float = Field(...) 값을 강제 필수 필드로 추가해 버리면 어떤 일이 벌어질까? 메인 비전 모델(LLM)은 종이 위에서 존재하지도 않는 필드를 어떻게든 찾아내려다 심각한 환각(Hallucination) 발작을 일으키고, 오라클은 값이 없다며 무자비하게 ValidationError를 뿜어내어 기존의 모든 트랜잭션을 마비시킨다 (하위 호환성 완전 붕괴).

진정한 아키텍트는 이를 점진적이고 방어적인 스키마 진화(Additive Schema Evolution) 패턴으로 제어한다.

from pydantic import BaseModel, Field, model_validator
from typing import Optional
from datetime import date

class InvoiceMasterOracleStageV2(InvoiceMasterOracleStageV1):
    # 과거 V1 레거시 데이터와의 하위 호환성을 완벽히 보장하기 위해 Optional 로 느슨하게 선언
    refundable_vat: Optional[float] = Field(
        default=0.0, 
        description="2024년 세법 개정 이후 발행된 문서에만 존재하는 환급형 부가세 필드. 문서에 명시되지 않았으면 절대 지어내지 말고 0.0을 반환하라."
    )

    @model_validator(mode='after')
    def validate_new_tax_logic_based_on_timeline(self):
        """ 
        시간 축(Timeline)을 기준으로 구형 문서와 신규 문서를 분기 처리하는 지능형 오라클 방어망 
        """
        # 1. 문서 발행일이 2024년 1월 1일 이후인 신규 트랜잭션의 경우에만 강력한 잣대 적용
        if self.invoice_date and self.invoice_date >= date(2024, 1, 1):
            if self.refundable_vat == 0.0:
                # 2024년 문서인데 해당 세금이 0.0으로 파싱되었다면, LLM이 포착을 놓쳤거나 위조된 서류일 확률 99%
                raise ValueError("[리걸 오라클 위반 (V2)] 2024년 신규 세법 스키마에 따른 환급형 부가세가 누락(0.0)되었습니다. 인간 거부 큐(HITL)로 라우팅합니다.")
        
        # 문서가 2023년 이전 것이라면 이 오라클은 조용히 바이패스(Bypass)하며 기존 파이프라인의 평화를 유지함
        return self

이러한 타임라인 기반 분기 처리 패턴은, 기존에 구축해 둔 ’V1 골든 데이터셋 1,000장’에 대한 자동 성능 테스트를 단 0.1%의 기각(Regression) 오차 없이 100% 무사 통과시키면서도, 신규 유입되는 V2 세법 데이터에 대한 오라클 방어망을 가장 안전하고 정교하게 시스템에 증축시킬 수 있게 해 주는 아키텍처의 철학이다.

2. CI/CD 파이프라인 상의 강력한 자동 회귀 방어선 (Automated Regression Testing)

데이터 엔지니어가 위와 같은 오라클 V2 코드를 로컬 브랜치(Branch)에서 짜고 엔터프라이즈 메인 리포지토리에 머지(Merge) 하려 할 때, 인간의 코드 리뷰나 인간의 수작업 테스트를 믿어서는 안 된다. 시스템 구조 상 GitHub Actions나 GitLab CI 환경 서버에서 무자비한 pytest 워크플로우가 자동으로 가동되어야만 한다.

자동화 테스트 스크립트는 13.9.3절에서 구축했던 3가지 거대한 계층의 **‘무결점 골든 데이터셋’**을 불러와, LLM 추론 캐싱(Caching)을 이용해 5분 만에 초고속으로 파이프라인을 전부 다시 돌려보며 다음 3가지 명제를 기계적으로 단언(Assert) 해야 한다.

[과거의 영광 수호]: 구형 스키마(V1)로 작성된 해피 패스 문서 300장이, 새로 짠 V2 코드 위에서도 여전히 한 장의 에러 없이 100% 모조리 통과하는가? (회귀 붕괴 현상 Zero 확증)
[신규 룰셋 작동 입증]: 신규 세법이 적용되어 ’환급형 부가세’가 적힌 V2 영수증 샘플 데이터들이 새로 증축된 오라클의 까다로운 산술 로직을 모두 무사히 통과하여 DB 텐서로 변환되는가?
[공격 및 함정 생존 입증]: 이 신규 부가세 필드값을 포토샵으로 고의로 뭉개버린 V2 맞춤형 네거티브 트랩 문서(사기 덤프 파일)를 주입했을 때, 시스템이 뚫리지 않고 정확하게 의도했던 ValueError를 뿜어내며 파이프라인의 숨통을 끊어내고 튕겨 내는가?

CI/CD 파이프라인의 가혹한 젠킨스(Jenkins) 콘솔 터미널에 이 3가지 완벽한 초록색 체크(✔) 사인이 떨어지지 않는다면, 그 어떠한 천재적인 아키텍트가 짠 오라클 리팩토링 코드라 할지라도 회사 메인 AI 파이프라인의 프로덕션 배포(Production Deploy) 버튼은 절대로, 영원히 활성화되지 않는다. 이것이 오라클이 지배하는 진정한 의미의 시스템 테스트 주도 유지보수(TDD) 생태계다.