3.5.3.2 Git 기반의 데이터셋 형상 관리 전략(DVC 등 활용)

소프트웨어 시스템 공학(Software System Engineering)의 엄격한 세계에서, 애플리케이션의 비즈니스 로직을 담은 소스 코드의 형상(Configuration)과 변경 이력을 Git으로 철저하게 버전 관리(Version Control)하는 것은 숨 쉬는 것만큼이나 너무나 당연하고 양보할 수 없는 기본 상식이다. 그러나 놀랍게도 동시대의 수많은 AI 엔지니어링 랩이나 MLOps 초기 구축 환경에서, ‘코드 로직’ 그 이상으로 시스템의 지능 수준과 핵심 속성을 직접적으로 지배하는 가장 중요한 에셋(Asset)인 **‘정답지 데이터셋(Golden Dataset)’**은 종종 형상 관리의 궤도에서 이탈하여 S3 버킷(Bucket) 구석의 압축 파일이나, 심지어 특정 리서처 개인 노트북 로컬 폴더에 final_dataset_v3_really_final_fix2.json 같은 참담한 네이밍 컨벤션 형태로 방치되곤 한다.

이러한 무책임하고 주먹구구식인 데이터셋 버저닝(Versioning) 관리는 오라클(Oracle) 평가 파이프라인의 생명이자 근간인 **재현성(Reproducibility)**을 근본부터 물리적으로 파괴해 버린다. 프로덕션 환경에서 특정한 과거 시점(예: 지난주 릴리스된 v2.4 모델)의 응답 성능이 갑작스럽게 왜 하락했는지 논리적으로 추적(Auditing)하고 롤백(Rollback)하기 위해서는, 당시 서버에서 실행되었던 백엔드 코드의 해시(Commit Hash)뿐만 아니라, 그 당시의 모델 코드를 냉혹하게 채점하고 통과시켰던 정확한 정답지 데이터셋 스냅샷(Golden Dataset Snapshot) 상태가 비트(Bit) 단위로 정확히 동기화되어 온전히 필요하기 때문이다. 이를 완벽하게 결합하기 위해 정답지 데이터셋 역시 메인스트림 Git의 CI/CD 생태계 톱니바퀴 속으로 완전히 강제 통합되어야만 한다.

1. DVC(Data Version Control)를 활용한 대용량 정답지 관리 아키텍처

하지만 Git은 태생적으로 수십 기가바이트(GB)에 달하는 방대한 대용량 텍스트 코퍼스나 바이너리 덤프 파일(JSON Lines, Parquet, CSV 등)의 델타 버전을 추적하고 푸시하는 아키텍처로 최적화되어 있지 않다. 따라서 기가 단위의 무거운 골든 데이터셋 자체를 .git 메인 저장소(Repository) 공간에 LFS(Large File Storage) 없이 무식하게 직접 푸시(Push)하는 것은, 저장소의 Clone 속도를 처참하게 망가뜨리고 전체 빌드 성능 저하를 초래하는 안티 패턴(Anti-pattern)이다. 이 소프트웨어적 딜레마를 해결하고 코드와 데이터를 우아하게 결합하는 산업 포괄적 오픈소스 표준 시스템 도구가 바로 **DVC(Data Version Control)**이다.

DVC가 구축하는 형상 관리 메커니즘은 매우 정교하지만 직관적이다.

1. 메타데이터와 실물 페이로드 데이터의 논리적 분리 (Separation of Metadata and Payload): DVC는 수 GB의 무거운 실제 타겟 데이터 파일(예: golden_dataset_q3.jsonl) 자체는 AWS S3나 GCS(Google Cloud Storage), Azure Blob과 같은 싸고 튼튼한 원격 객체 저장소(Remote Object Storage) 공간으로 알아서 안전하게 파티셔닝하여 업로드시킨다. 그리고 로컬 워크스페이스에는 해당 무거운 파일의 MD5 해시값(Hash Value)과 원격 다운로드 위치 정보만을 담은 불과 몇 바이트짜리 아주 가벼운 메타데이터 포인터 파일(예: golden_dataset_q3.jsonl.dvc)만을 덩그러니 생성해 둔다.
2. Git 커밋과의 우아한 유착 결합 (Binding with Git): MLOps 개발자는 이제 무거운 실물 데이터가 아니라, 오직 이 깃털처럼 가벼운 .dvc 메타데이터 파일 정보만을 소스 코드의 변경 사항과 함께 git commit으로 묶어 버전 트리 체인에 기록하고 푸시(Push)한다.
3. 타임머신(Time-machine) 기능의 역동적 완성: 만약 치명적인 버그가 터져 누군가 git checkout v1.2.0 명령어를 터미널에서 실행하여 한 달 전 과거의 소스 코드로 워크스페이스를 되돌린다면, 소스 코드와 함께 커밋되었던 .dvc 메타데이터 파일 역시 정확히 그 한 달 전의 낡은 지점 해시를 가리키게끔 동기화되어 즉각 되돌아간다. 바로 이때 개발자가 dvc pull 명령어를 이어서 덧붙여 실행하면, DVC 데몬 엔진이 현재의 낡은 메타데이터 해시값을 읽어 들이고 물리적으로 정확히 v1.2.0 릴리스 시점에 오라클이 채점용으로 사용했던 그 옛날의 실물 정답지 데이터셋 버전을 S3 원격 저장소에서 즉시 다운로드하여 작업 디렉터리를 비트 퍼펙트(Bit-perfect)하게 복원해 낸다.

2. CI/CD 릴리스 파이프라인에서의 기계적 재현성 보장 및 록인(Lock-in)

Git 소스 구조와 DVC 데이터 생태계의 결합 아키텍처는, 우리의 AI 평가 오라클 시스템 파이프라인을 가장 까다로운 현대적인 CI/CD(Continuous Integration / Continuous Deployment) 파이프라인 철학과 한 치의 오차 없이 완벽하게 기계적으로 동기화시킨다.

새로운 프롬프트 최적화 코드가 담긴 풀 리퀘스트(Pull Request, PR)가 메인 브랜치로 상정되어 트리거가 발생하면, 통제권을 넘겨받은 젠킨스(Jenkins) 배포 서버나 GitHub Actions 러너(Runner) 파이프라인은 스크립트에 따라 git checkout과 dvc pull을 차례로 논리적으로 연계 실행한다. 이를 통해 러너 인스턴스는 한 치의 랜덤성(Randomness) 개입도 없이 **‘방금 푸시된 새로운 AI 비즈니스 소스 코드에 가장 역학적으로 동기화되고 정확하게 일치하는 버전의 정규 정답지 데이터셋’**만을 핀셋처럼 뽑아내어 메모리에 안전하게 로드한 뒤, 결정론적인 회귀 테스트(Regression Testing) 오라클을 구동할 수 있게 된다.

결과론적으로 평가해 보건대, AI 파이프라인 환경에서 정답지(Ground Truth)의 철저한 형상 관리(Configuration Management) 체계를 도입하는 행위는 단순한 파일 손실 대비용 ‘클라우드 백업’ 수준의 의미가 아니다. 그것은 지수함수적으로 요동치며 진화하고 퇴화하는 AI 언어 모델의 예측 불가능한 발전 역사(History of Probabilistic Evolution)를, 엔터프라이즈 소스 코드의 진화 역사(History of Deterministic Code)와 1바이트의 오차도 없이 일대일 매핑으로 단단하게 물리적으로 묶어버리는 그물망 같은 거대한 공간적, 시간적 동기화(Synchronization) 아키텍처의 완성형 메커니즘이다.