10.6.3 도메인별/기능별 카테고리 태깅을 통한 부분 테스트(Partial Testing) 지원 구조

10.6.3 도메인별/기능별 카테고리 태깅을 통한 부분 테스트(Partial Testing) 지원 구조

풀 회귀 테스트(Full Regression Test) 스위트(Suite)가 전체 AI 런타임 시스템의 무결성(Integrity)과 안정을 보장하는 최후의 보루이긴 하지만, 매번 사소한 사이드 로직 변경 시에도 그 무거운 거대 언어 모델 시스템 파이프라인 전체를 가동하는 것은 극도의 컴퓨팅 자원 낭비와 시간 비효율(Inefficiency)을 초래한다. 예를 들어 백엔드 엔지니어링 파트에서 A 도메인(예: 결제 및 환불 모듈)의 프롬프트나 에이전트 라우팅(Agent Routing) 로직을 수정했는데, 구조적으로 전혀 상관없는 B 도메인(예: 일반 고객 응대 챗봇 컴포넌트)의 골든 데이터 수만 건까지 굳이 토큰(Token) 비용을 태워가며 채점할 공학적 이유는 전혀 존재하지 않는다.

따라서 골든 데이터셋(Golden Dataset)의 모든 레코드는 다이내믹하게 필터링(Dynamic Filtering)할 수 있도록 다차원적인 횡단 관심사 기반의 ‘태그(Tags)’ 인프라를 필수적으로 갖추어야 한다. 이를 통해 스크립트 기반의 CI 파이프라인은 전체(Full) 런(Run)도, 극최소 단위의 스모크(Smoke) 테스트도 아닌, **‘수정된 코드의 영향도 범위(Impact Radius)에 정확히 맞춘 타겟 부분 테스트(Targeted/Partial Testing)’**를 동적으로 조립하여 런타임(Runtime)에 실행할 수 있게 된다.

1. 다차원 태깅 스키마(Multidimensional Tagging Schema) 설계

골든 데이터 하나하나에 메타데이터(Metadata)로 부여되는 태그는 1차원적인 단순 카테고리가 아닌, 교집합(Intersection) 및 부분집합(Subset) 검색 쿼리가 가능한 배열(Array) 형태로 견고하게 형상 관리 및 설계되어야 한다.

{
  "test_id": "PAY-RFND-099",
  "tags": {
    "domain": ["Payment", "Refund"],
    "capability": ["Tool_Calling", "Math_Calculation"],
    "priority": "P1",
    "language": ["ko", "en"]
  }
}

이러한 정규화된 스키마(Normalized Schema)가 아키텍처 레벨에 서빙(Serving)되면, 개발 팀은 데이터베이스나 클라우드 기반의 테스트 러너(Test Runner)에게 다음과 같은 정교한 복합 쿼리(Compound Query)를 날려 거대한 테스트셋을 즉석에서 목적 테이블(Subset)로 안전하게 분할할 수 있다.

  • “결제(Payment) 도메인의 코드를 수정했으니, domain 배열 내에 Payment가 존재하면서 동시에 priority 속성이 P1 또는 P2인 고위험 데이터 레코드만 런타임에 인메모리(In-Memory)로 뽑아서 병렬 평가 루프를 돌려라.”

2. 모듈식(Modular) 테스트 스위트의 강력한 유연성

기능별 능력을 선언하는 태깅(capability)은 특히 프로덕션 환경에서 AI 기반 모델 자체를 전면 교체하는 마이그레이션(Migration) 작업에서 눈부신 공학적 진가를 발휘한다.

예를 들어, 백엔드의 기반 파운데이션 모델(Foundation Model)을 GPT-3.5에서 아키텍처가 완전히 다른 개방형 모델(예: LLaMA 3)이나 상위 버전(예: GPT-4o)으로 메이저 업그레이드(Major Upgrade)할 때, 엔지니어는 “과연 새로운 모델 아키텍처가 이전 파라미터 셋업만큼 외부 함수 호출(Function Calling)이나 엄격한 JSON 형식 포맷팅(Forced JSON Output)을 안정적이고 결정론적으로 수행할까?“라는 합리적인 의구심을 가지게 된다.

이때 무식하게 전체 회귀 테스트를 풀 가동할 필요가 없다. 단순히 메타데이터 필터망에서 capability: "Tool_Calling" 인 데이터셋 교집합만 500개 우선 추출하여 벤치마크 테스트(Benchmark Test)를 백그라운드에서 백테스팅(Backtesting) 해보면 (즉, A/B Testing 프레임워크 가동), 채 10분 만에 새 모델의 특정 컴퓨팅 능력에 대한 정밀점묘 수준의 수치화된 디버깅 리포트(Debugging Report)를 통계적으로 얻어낼 수 있다.

graph LR
    A[골든 데이터셋 Database] --> B{태그 쿼리 엔진 Tag Query Engine}
    B -->|domain_in=[Payment, Refund]| C[결제 모듈 회귀 테스트 Sub-suite]
    B -->|capability=Tool_Calling| D[모델 마이그레이션 능력 검증 Sub-suite]
    B -->|priority=P1 & language=en| E[글로벌 핵심 로직 Smoke Test]
    C --> F[CI/CD 결과 리포팅]
    D --> F
    E --> F
    
    style B fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px

결과적으로 골든 데이터셋의 분할 관리는 물리적인 개별 페이로드 파일(A.json, B.json)을 하드코딩(Hardcoding)으로 쪼개는 단순한 분류계가 전부가 아니다. 단일 파티셔닝된 거대 데이터베이스 뷰(또는 효율적으로 직렬화된 NoSQL 컬렉션) 내에 비트맵 인덱스(Bitmap Index)와 동일한 논리적인 다차원 태그 인덱스(Tag Index)를 촘촘히 구축하는 것, 그래서 검증 파이프라인 로직이 매 순간, 그 릴리즈에 가장 최적화되고 필요한 오라클 테스트셋만을 레고 블록 조립점퍼처럼 유연하고 가볍게 조립할 수 있도록 메타 아키텍처를 세우는 것이 현대적인 AI 테스트 엔지니어링(AI Test Engineering)의 핵심 정수다.