2.9.3. 버전 관리 시스템 내에서의 테스트 케이스 및 오라클 이력 관리

2.9.2절을 통해 오라클의 평가 기준이 단일한 고정점(Fixed Point)이 아니라 매일마다 살아 움직이는 동적인 개체(Dynamic Entity)로 진화했음을 확인했다. 하지만 기준(Rule)이 수시로 변한다는 것은 소프트웨어 공학 측면에서 지독한 악몽이다. “어제 릴리즈된 모델은 도대체 어떤 정답지 기준을 통과해서 배포된 것인가?”, “새로운 오라클 정책이 도입된 이후로 오히려 기존 시스템이 붕괴했는데, 즉각적으로 과거 오라클 상태로 롤백(Rollback)할 수 있는가?”

이러한 치명적인 추적 불가능성(Untraceability)에 대한 유일한 물리적 해답은 오라클과 테스트 케이스를 애플리케이션 소스 코드(Source Code)와 동일한 위상으로 취급하여, 엄격한 코드 기반 형상/이력 관리 체계(Version Control System, VCS) 내부로 종속시키는 것이다.

1. 프롬프트로서의 코드 (Prompt-as-Code)와 오라클-as-Code의 결합

전통적인 DevOps에서 ’인프라스트럭처를 코드로 관리(IaC)’하여 멱등성(Idempotency)을 달성했듯, LLMOps에서는 오라클의 기준, 프롬프트, 제약 스키마(JSON Schema), 그리고 평가용 골든 데이터셋 전체를 단순한 DB의 행(Row) 정보가 아니라 Git과 같은 형상 관리 시스템 내의 리포지토리(Repository)에 영구 박제(Snapshot)해야 한다.

오라클 버전과 모델 배포 버전을 1:1 강제 동기화(Hash Mapping): App_Version_v1.5가 배포될 때는, 어설프게 가장 최신 정답지를 가져와 비교해선 안 된다. v1.5 릴리즈 당시에 승인(Commit)된 Oracle_Ruleset_v1.5_hashX 시점의 코드로 강제 매핑시켜 회귀 테스트를 고정해야 한다.

2. 오라클의 롤백 체계 및 다중 브랜치(Multi-Branch) 운영 전략

비즈니스 요구사항이나 규제 준수(Compliance) 정책은 때로 후퇴하거나 과거로 회귀해야 할 때가 있다. 예를 들어 환불 기간을 30일에서 14일로 바꿨다가 다시 30일 정책(Legacy)으로 롤백해 달라는 임원진의 폭력적 요구가 내려오는 경우, 파이프라인 구조가 분리되어 있지 않으면 대참사가 발생한다.

gitGraph
    commit id: "Initial Oracle (v1)"
    branch experimental
    checkout experimental
    commit id: "Add Dynamic Rubrics"
    commit id: "Tweak LLM Judge Prompts"
    checkout main
    merge experimental id: "Deploy Model v2 (with Oracle v1.5)"
    branch compliance_patch
    checkout compliance_patch
    commit id: "Strict PII Hard-rule Oracle added"
    checkout main
    merge compliance_patch id: "Deploy Model v3"
    commit id: "Detect False Positives - Revert PII Oracle!" type: REVERSE

위의 Git 그래프 아키텍처는 놀랍도록 보편적이다. 오라클 검증 로직 자체를 Git 브랜치 전략(GitFlow) 내부로 밀어 넣음으로써, 새로운 평가 기준이 치명적 파이프라인 병목(False Positive)을 양산할 때 즉각 명령어 한 줄(git revert)로 인프라를 이전의 느슨한 평가 체계로 되돌릴 수 있는 구조적 멱등성을 확보한다.

3. 대용량 데이터 버전 관리 도구(DVC)와의 융합

오라클의 구성 요소 중 메타 프롬프트와 JSON 스키마는 단순 텍스트 파일(Git-friendly)이지만, 수십만 개의 오라클 평가 베이스라인(Reference Embeddings, Vector Data)을 포함하는 골든 데이터셋은 Git으로 관리하기에 용량이 비대하다.
이러한 데이터 편차를 매니징하기 위해 MLOps 생태계는 **DVC(Data Version Control)**와 커밋(Commit) 트리를 융합한다. 소스 레벨에서는 오라클 동작 알고리즘의 뼈대를 Git으로 추적하고, 내부적으로 바인딩된 지식 소스와 거대 정답지 포인터는 DVC 해시값을 통해 S3, Blob Storage 등 오브젝트 저장소로 분리 보관하면서도 논리적 버전은 완벽히 결속(Coupling)시킨다.

4. 소결: 통제 불투명성을 극복하는 영속성의 앵커(Anchor)

버전 관리 시스템(VCS) 내 통제 구조 편입은 AI 파이프라인의 불투명성이라는 악명을 철저한 코드 단위의 증명 가능성(Provability)으로 씻어내는 행위다. 누가 언제 오라클 프롬프트를 수정하여 합격선(Threshold)을 야금야금 낮춰버렸고 이로 인해 끔찍한 환각 응답이 릴리즈 체인을 뚫고 나갔는지, 모든 블레임(Blaming)과 타임라인 적발이 소스 관점에서 투명하게 지휘된다.

오라클의 이력을 완벽히 제어하는 무기를 손에 넣었다면, 이제 남은 것은 이 심판관에게 실제 시스템의 멱살을 잡고 실행을 중단시킬 무소불위의 권력을 인프라 상에서 쥐어주는 일이다. 이어지는 2.9.4절에서는 오라클이 CI/CD 배포 파이프라인 깊숙한 계층에 자리 잡아 배포의 숨통을 기계적이고 자비 없이 끊어버리는 오라클 자동화 배포 및 차단(Blocking) 전략을 총체적으로 구성한다.