15.3.1. 테스트 데이터셋의 버전 제어 시스템(DVC, Git-LFS) 구축

15.3.1. 테스트 데이터셋의 버전 제어 시스템(DVC, Git-LFS) 구축

결정론적 오라클 검증 시스템을 구성하는 양대 축은 ’테스트 스위트(Test Suite) 코드’와 검증의 기준이 되는 ’골든 데이터셋(Golden Dataset)’이다. 전통적인 소프트웨어 공학에서는 코드가 핵심이었으나, AI 기반 소프트웨어에서는 데이터가 곧 로직의 유효성을 결정하는 중추적인 역할을 수행한다. 그러나 수 기가바이트(GB)에 달할 수 있는 대규모 텍스트, 정형 데이터베이스 결괏값, 혹은 이미지/오디오 정답지를 일반적인 형상 관리 시스템(Git)에 직접 커밋(Commit)하는 행위는 리포지토리(Repository)의 비대화와 CI/CD 병목을 유발하는 안티 패턴(Anti-pattern)이다.

따라서 소스 코드의 진화 궤적과 테스트 데이터셋의 진화 궤적을 논리적으로 동기화하면서도, 물리적으로는 분리하여 저장하는 전문적인 ‘분산 데이터 버전 제어 아키텍처(Distributed Data Version Control Architecture)’ 구축이 필수적으로 요구된다.

1. 데이터-코드 버전 비동기화의 위험성 (Risk of Desynchronization)

대다수 조직이 초기에 범하는 실수는 골든 데이터셋을 AWS S3나 구글 드라이브와 같은 외부 스토리지에 단순 업로드하고, 코드베이스에서는 최신 메타 경로(예: s3://bucket/test_data_latest.json)만을 포인팅(Pointing)하는 방식이다. 이 구조는 치명적인 ‘시간 역행(Time Paradox)’ 결함을 지니고 있다.

  • 개발자 A가 신규 기능 출시에 맞춰 구조가 변경된(Type changed) 새로운 프롬프트와 오라클 파서 코드를 feature-branch에 커밋한다.
  • 동시에 S3의 test_data_latest.json을 새로운 구조에 맞게 덮어쓴다(Overwrite).
  • 이 순간, 과거 안정화 버전인 main 브랜치의 CI 파이프라인 트리거가 작동하면, 코드는 구형 오라클 로직을 가지고 있으나 S3에서 불러오는 데이터는 신규 포맷이므로 과거의 모든 안정 버전 빌드가 일제히 붕괴(Break)되는 현상이 발생한다.

수학적으로, 소스 코드의 특정 커밋 해시 C_k는 그 당시에 유효했던 데이터셋의 특정 해시 상태 D_k와 완전한 바이젝션(Bijection, 일대일 대응) 결합을 이루어야만 검증 오라클 체계가 성립한다.

2. Git-LFS와 DVC를 활용한 아키텍처 설계 비교

이러한 바이젝션 결합을 구현하기 위해 업계 표준으로 활용되는 도구는 대표적으로 Git Large File Storage(Git-LFS)와 Data Version Control(DVC)이 있다.

2.1 Git-LFS 기반의 투명한 포인터 격리

Git-LFS는 Git 내부 거버넌스를 그대로 활용하되, 대용량 파일의 실제 바이너리(Blob)는 별도의 원격 LFS 서버에 저장하고, Git 리포지토리 내부에는 해당 파일의 SHA-256 해시와 크기 정보를 담은 작은 텍스트 포인터(Pointer) 파일만을 커밋하는 기술이다. 개발자 입장에서는 일반적인 git pull 및 git checkout 명령어만으로도 소스 코드와 특정 시점의 테스트 데이터가 완벽하게 일치된 상태의 워크스페이스를 얻을 수 있다는 장점이 있으나, 오픈소스 프로젝트나 다수/대용량의 분산 오브젝트 스토리지 매핑에는 네트워크 비용 효율성이 떨어진다.

2.2 DVC 기반의 클라우드 네이티브 메타데이터 분리

반면 DVC는 데이터와 모델 가중치에 특화된 별도의 형상 관리 레이어를 Git 위에 덮어씌운다. DVC는 S3, GCS, Azure Blob 등 일반적인 클라우드 스토리지를 원격 캐시(Remote Cache)로 직접 사용하며, 프로젝트 디렉터리 내에 가벼운 .dvc 메타데이터 파일만을 남긴다.

DVC 기반의 테스트 파이프라인 아키텍처는 아래의 Mermaid 다이어그램으로 시각화할 수 있다.

graph TD
    A[소프트웨어 엔지니어] -->|소스 코드 커밋| B(Git Repository)
    A -->|골든 데이터 수정| C[DVC CLI: dvc add dataset.json]
    
    C --> D{메타데이터 파일 dataset.json.dvc 생성}
    C -->|데이터 해시값 전송| E[(AWS S3 / GCS Data Remote)]
    
    D --> |dvc 파일만 git에 커밋| B
    
    subgraph CI/CD 검증 환경
        F[클론 Git Commit Hash C_k] --> G[체크아웃: 과거 버전의 소스코드 및 당시의 .dvc 파일 위치 확인]
        G --> H[dvc pull 실행]
        H -->|메타데이터에 적힌 해시값 D_k 요청| E
        E -->|정확한 시점의 골든 데이터셋 다운로드| I[과거 버전의 코드 + 과거 버전의 골든 데이터 쌍 복원]
        I --> J[결정론적 회귀 테스트 Run Test]
    end
    
    J --> K[성공/실패 Report]

3. 구축 시 명심해야 할 파이프라인 무결성 원칙

효과적이고 지속 가능한 데이터셋 버전 제어 시스템을 유지하기 위해서는 기술적 툴킷의 도입을 넘어 다음과 같은 파이프라인 거버넌스를 확립해야 한다.

  1. 자동화된 오염 방지망 (Automated Taint Prevention): CI/CD 파이프라인의 극초반 로직에 dvc status 또는 git lfs status를 삽입하여, 소스 코드 커밋 내역과 실제 로컬 러너(Runner)에 풀링(Pulling)된 데이터 간의 해시 엇갈림이 없는지 선제적으로 검증해야 한다.
  2. 콜드 스토리지 아카이빙 (Cold Storage Archiving): AI 모델의 잦은 업데이트로 인해 골든 데이터의 버전 파편화(Fragmentation)가 발생하면 클라우드 스토리지 비용이 급증한다. DVC의 경우 dvc gc (Garbage Collection) 명령어를 통해 1년 이상 참조되지 않은 메타데이터 해시 트리를 주기적으로 클리닝하고 딥 아카이브(Glacier 등)로 이관하는 비용 절감 백그라운드 스크립트를 운용해라.
  3. 스키마 버전 제어 브랜치 분리: 단순 데이터의 변경이 아닌, JSON Schema와 같은 메타-구조의 변경이 수반되는 데이터셋 판올림(e.g., v1 -> v2)의 경우, 반드시 독립된 Git Branch 상에서 데이터 포인터 업데이트를 진행하고 테스트 스위트가 온전함을 증명한 뒤에만 Main으로 머지(Merge)하는 엄격한 코드-데이터 공동 리뷰 제도를 도입해야 한다.

4. 소결

골든 데이터셋을 코드베이스와 철저히 동기화된 궤적으로 관리하는 것은 결정론적 오라클의 가장 무거운 닻을 내리는 행위다. 위에서 논의한 DVC 및 Git-LFS 기반의 버전 제어 아키텍처를 도입함으로써, 엔지니어링 조직은 “내 로컬에서는 오라클 검증이 통과했는데 서버에서는 실패한다“는 오랜 난제를 논리적, 물리적으로 영구히 종결 지을 수 있다.