데이터 버전 관리 DVC 완벽 가이드

머신러닝 프로젝트에서 대용량 데이터와 모델 파일을 Git처럼 체계적으로 관리하는 DVC의 핵심 개념과 실전 활용법을 다룹니다. 초급 개발자도 쉽게 따라할 수 있도록 설치부터 파이프라인 구축까지 단계별로 안내합니다.

---

목차

1. DVC_설치_및_초기화
2. 데이터_추적하기
3. 원격_저장소_연결
4. 파이프라인_정의
5. 실험_재현성_확보
6. Git과_DVC_통합

---

1. DVC 설치 및 초기화

김개발 씨는 머신러닝 팀에 합류한 지 한 달이 되었습니다. 오늘 팀장님이 학습 데이터 파일을 전달해주셨는데, 무려 5GB가 넘는 대용량 파일이었습니다.

"이걸 어떻게 Git에 올리지?" 막막해하던 김개발 씨에게 선배가 다가와 말했습니다. "Git으로는 안 돼요.

DVC를 써야 해요."

**DVC(Data Version Control)**는 한마디로 대용량 데이터 파일을 위한 Git입니다. 마치 Git이 소스 코드의 변경 이력을 추적하듯, DVC는 데이터 파일과 모델 파일의 버전을 관리합니다.

이것을 제대로 이해하면 수십 GB의 학습 데이터도 체계적으로 관리할 수 있습니다.

다음 코드를 살펴봅시다.

# DVC 설치 (pip 사용)
pip install dvc

# 프로젝트 디렉토리로 이동
cd my-ml-project

# Git 저장소가 없다면 먼저 초기화
git init

# DVC 초기화 - .dvc 디렉토리가 생성됩니다
dvc init

# 생성된 DVC 설정 파일들을 Git에 커밋
git add .dvc .dvcignore
git commit -m "Initialize DVC"

김개발 씨는 입사 초기부터 한 가지 고민이 있었습니다. 머신러닝 프로젝트를 진행하다 보면 학습 데이터, 모델 가중치, 전처리된 데이터셋 등 대용량 파일이 계속 생겨났습니다.

이 파일들을 어떻게 관리해야 할지 막막했습니다. Git에 올리려고 했더니 "파일이 너무 큽니다"라는 오류가 떴습니다.

GitHub는 100MB 이상의 파일을 허용하지 않기 때문입니다. 그렇다고 이 파일들을 그냥 로컬에만 두자니, 팀원들과 공유하기도 어렵고 버전 관리도 되지 않았습니다.

박시니어 씨가 해결책을 알려주었습니다. "DVC를 사용하면 돼요.

Data Version Control의 약자인데, Git과 함께 쓰면 코드와 데이터를 모두 버전 관리할 수 있어요." DVC란 정확히 무엇일까요? 쉽게 비유하자면, DVC는 마치 도서관의 대출 시스템과 같습니다.

도서관에서 책을 빌릴 때 실제 책은 서고에 보관하고, 대출 카드에는 "누가, 언제, 어떤 책을 빌렸는지"만 기록합니다. DVC도 마찬가지입니다.

실제 대용량 파일은 별도의 저장소에 보관하고, Git에는 파일의 위치와 버전 정보만 가벼운 메타데이터로 저장합니다. DVC가 없던 시절에는 어땠을까요?

개발자들은 데이터 파일을 USB에 담아 전달하거나, 공유 드라이브에 "data_v1", "data_v2", "data_final", "data_진짜최종" 같은 폴더를 만들어 관리했습니다. 어느 버전이 최신인지, 어떤 코드와 어떤 데이터가 맞는지 알 수 없었습니다.

팀원 간의 혼란은 프로젝트가 커질수록 심해졌습니다. DVC 설치는 매우 간단합니다.

Python 패키지 관리자인 pip를 사용하면 됩니다. pip install dvc 명령 한 줄이면 설치가 완료됩니다.

만약 특정 원격 저장소를 사용할 계획이라면 **pip install dvc[s3]**처럼 추가 옵션을 붙일 수도 있습니다. 설치가 끝났다면 프로젝트 디렉토리에서 dvc init 명령을 실행합니다.

이 명령은 반드시 Git 저장소 안에서 실행해야 합니다. DVC는 Git과 함께 동작하도록 설계되었기 때문입니다.

아직 Git 저장소가 아니라면 먼저 git init을 실행하세요. dvc init을 실행하면 .dvc 디렉토리가 생성됩니다.

이 안에는 DVC의 설정 파일들이 들어있습니다. 또한 .dvcignore 파일도 생성되는데, 이는 .gitignore와 비슷한 역할을 합니다.

DVC가 추적하지 않을 파일 패턴을 지정할 수 있습니다. 마지막으로 생성된 파일들을 Git에 커밋해야 합니다.

git add .dvc .dvcignore로 스테이징하고 커밋하면 초기 설정이 완료됩니다. 이제 김개발 씨의 프로젝트는 DVC를 사용할 준비가 되었습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 안내대로 DVC를 설치하고 초기화하니, 이제 대용량 데이터 파일도 체계적으로 관리할 수 있게 되었습니다.

"생각보다 간단하네요!"라며 김개발 씨는 안도의 한숨을 내쉬었습니다.

실전 팁

💡 - DVC는 반드시 Git 저장소 안에서 초기화해야 합니다

• 원격 저장소 유형에 따라 pip install dvc[s3], dvc[gdrive] 등 추가 패키지를 설치하세요
• 팀 프로젝트라면 .dvc 디렉토리를 꼭 Git에 커밋하여 설정을 공유하세요

---

2. 데이터 추적하기

DVC 초기화를 마친 김개발 씨는 이제 본격적으로 데이터를 관리하려고 합니다. 5GB짜리 학습 데이터 파일 training_data.csv가 앞에 놓여 있습니다.

"이제 이 파일을 DVC로 추적하면 되는 거죠?"라고 물었더니, 박시니어 씨가 고개를 끄덕였습니다. "맞아요.

dvc add 명령을 쓰면 돼요."

dvc add는 Git의 git add와 비슷하지만 동작 방식이 다릅니다. 이 명령은 지정한 파일을 DVC의 관리 대상으로 등록하고, 실제 파일 대신 가벼운 .dvc 파일을 생성합니다.

마치 무거운 짐을 창고에 맡기고 보관증만 들고 다니는 것과 같습니다.

다음 코드를 살펴봅시다.

# 대용량 데이터 파일을 DVC로 추적
dvc add data/training_data.csv

# 위 명령 실행 후 생성되는 파일들:
# - data/training_data.csv.dvc (메타데이터 파일)
# - data/.gitignore (원본 파일을 Git에서 제외)

# 생성된 .dvc 파일 내용 확인
cat data/training_data.csv.dvc
# outs:
# - md5: a1b2c3d4e5f6...
#   size: 5368709120
#   path: training_data.csv

# .dvc 파일과 .gitignore를 Git에 커밋
git add data/training_data.csv.dvc data/.gitignore
git commit -m "Add training data to DVC"

김개발 씨는 DVC 초기화를 마치고 드디어 데이터를 추적하려 합니다. data 폴더 안에 있는 training_data.csv 파일은 5GB가 넘는 대용량 파일입니다.

Git에 직접 올릴 수 없으니 DVC를 통해 관리해야 합니다. dvc add 명령의 동작 원리를 이해하려면 먼저 비유를 들어보겠습니다.

여러분이 귀중한 보석을 은행 금고에 맡긴다고 상상해보세요. 은행에서는 보석을 금고에 안전하게 보관하고, 여러분에게는 보관증을 줍니다.

나중에 보석이 필요하면 보관증을 가져가서 찾으면 됩니다. DVC도 똑같이 동작합니다.

dvc add data/training_data.csv 명령을 실행하면, DVC는 먼저 파일의 내용을 해시값으로 계산합니다. 이 해시값은 파일의 고유한 지문과 같습니다.

파일 내용이 조금이라도 바뀌면 해시값도 달라집니다. 그 다음 DVC는 원본 파일을 .dvc/cache 디렉토리로 이동시킵니다.

이곳이 바로 은행 금고에 해당합니다. 그리고 원래 위치에는 캐시를 가리키는 링크를 남겨둡니다.

사용자 입장에서는 파일이 그대로 있는 것처럼 보이지만, 실제로는 캐시에 저장된 파일을 참조하는 것입니다. 동시에 training_data.csv.dvc라는 작은 텍스트 파일이 생성됩니다.

이 파일이 바로 보관증입니다. 안에는 파일의 해시값, 크기, 경로 정보가 담겨 있습니다.

용량은 수십 바이트에 불과합니다. 이 가벼운 파일은 Git에 문제없이 커밋할 수 있습니다.

DVC는 한 가지 더 해줍니다. data 폴더에 .gitignore 파일을 자동으로 생성하거나 업데이트합니다.

이 파일에 training_data.csv가 추가되어, Git이 원본 대용량 파일을 무시하도록 합니다. 실수로 대용량 파일을 Git에 커밋하는 일을 방지해주는 것입니다.

이제 해야 할 일은 .dvc 파일과 .gitignore를 Git에 커밋하는 것입니다. git add data/training_data.csv.dvc data/.gitignore 명령으로 스테이징하고 커밋합니다.

이렇게 하면 Git에는 메타데이터만 저장되고, 실제 데이터는 DVC가 따로 관리합니다. 나중에 데이터 파일이 변경되면 어떻게 될까요?

다시 dvc add 명령을 실행하면 됩니다. DVC는 새로운 해시값을 계산하고, .dvc 파일을 업데이트합니다.

이 변경된 .dvc 파일을 Git에 커밋하면 데이터의 새 버전이 기록됩니다. 디렉토리 전체를 추적할 수도 있습니다.

dvc add data/ 명령을 사용하면 data 폴더 안의 모든 파일을 한꺼번에 DVC로 관리할 수 있습니다. 수백 개의 이미지 파일이나 여러 개의 데이터셋을 다룰 때 유용합니다.

김개발 씨는 고개를 끄덕였습니다. "아, 그러니까 무거운 짐은 DVC 창고에 맡기고, 보관증만 Git에 올리는 거군요!" 박시니어 씨가 미소를 지었습니다.

"정확해요. 이제 팀원들도 이 .dvc 파일만 있으면 데이터를 받아올 수 있어요."

실전 팁

💡 - dvc add 후에는 반드시 생성된 .dvc 파일을 Git에 커밋하세요

• 여러 파일을 한번에 추적하려면 디렉토리 단위로 dvc add를 실행하세요
• .dvc 파일을 삭제하면 추적이 해제되니 주의하세요

---

3. 원격 저장소 연결

김개발 씨가 데이터를 DVC로 추적하는 방법을 익혔습니다. 그런데 문득 의문이 들었습니다.

"이 데이터가 제 컴퓨터 캐시에만 있으면, 다른 팀원들은 어떻게 받아요?" 박시니어 씨가 답했습니다. "좋은 질문이에요.

원격 저장소를 설정해야 해요. Git에 GitHub가 있듯이, DVC에도 원격 저장소가 필요합니다."

DVC 원격 저장소는 데이터 파일을 팀원들과 공유하기 위한 중앙 저장소입니다. AWS S3, Google Cloud Storage, Azure Blob, Google Drive 등 다양한 스토리지 서비스를 지원합니다.

마치 Git의 GitHub/GitLab처럼, DVC 원격 저장소는 데이터의 중앙 허브 역할을 합니다.

다음 코드를 살펴봅시다.

# AWS S3를 원격 저장소로 설정
dvc remote add -d myremote s3://my-bucket/dvc-storage

# Google Drive를 원격 저장소로 설정 (폴더 ID 사용)
dvc remote add -d gdrive gdrive://1a2B3c4D5e6F7g8H9i

# 로컬 네트워크 경로도 가능
dvc remote add -dnas /mnt/shared/dvc-cache

# 현재 설정된 원격 저장소 확인
dvc remote list

# 데이터를 원격 저장소로 업로드 (push)
dvc push

# 원격 저장소에서 데이터 다운로드 (pull)
dvc pull

# 설정을 Git에 커밋하여 팀과 공유
git add .dvc/config
git commit -m "Configure DVC remote storage"

김개발 씨의 컴퓨터에는 이제 DVC 캐시에 데이터가 저장되어 있습니다. 하지만 이 상태로는 혼자만 데이터를 사용할 수 있습니다.

팀원들과 협업하려면 데이터를 어딘가에 공유해야 합니다. 바로 이때 원격 저장소가 필요합니다.

Git을 사용할 때 GitHub나 GitLab에 코드를 푸시하는 것처럼, DVC도 원격 저장소에 데이터를 푸시합니다. 차이점은 DVC 원격 저장소가 대용량 파일을 저장하도록 설계된 스토리지 서비스라는 것입니다.

AWS S3, Google Cloud Storage, Azure Blob Storage 같은 클라우드 스토리지가 대표적입니다. 쉽게 비유하자면, 원격 저장소는 마치 클라우드 창고와 같습니다.

여러분의 로컬 캐시가 집 안의 작은 창고라면, 원격 저장소는 팀원 모두가 접근할 수 있는 거대한 공용 창고입니다. 누구든 필요할 때 이 창고에서 데이터를 가져갈 수 있습니다.

원격 저장소를 설정하는 명령은 dvc remote add입니다. -d 옵션은 이 저장소를 기본값으로 설정한다는 의미입니다.

그 뒤에 저장소 이름과 URL을 지정합니다. 예를 들어 AWS S3를 사용한다면 dvc remote add -d myremote s3://my-bucket/dvc-storage 형식입니다.

회사에서 Google Drive를 사용한다면 gdrive:// 프로토콜을 사용할 수 있습니다. 폴더 ID는 Google Drive 웹에서 해당 폴더를 열었을 때 URL에 표시되는 긴 문자열입니다.

팀 공용 폴더를 만들어 그 ID를 사용하면 됩니다. 로컬 네트워크 저장소도 지원합니다.

NAS나 공유 폴더가 있다면 /mnt/shared/dvc-cache 같은 경로를 지정할 수 있습니다. 클라우드 비용을 아끼고 싶거나 보안상 외부 저장소를 사용할 수 없는 환경에서 유용합니다.

원격 저장소 설정이 끝났다면 dvc push 명령으로 데이터를 업로드합니다. 이 명령은 로컬 캐시에 있는 모든 DVC 추적 파일을 원격 저장소로 전송합니다.

파일 크기에 따라 시간이 걸릴 수 있습니다. 팀원이 프로젝트를 클론한 후 데이터를 받으려면 dvc pull 명령을 실행합니다.

이 명령은 .dvc 파일들을 읽어서 해당 데이터를 원격 저장소에서 다운로드합니다. git pull로 코드를 받고, dvc pull로 데이터를 받는 것입니다.

중요한 점은 원격 저장소 설정을 Git에 커밋해야 한다는 것입니다. .dvc/config 파일에 원격 저장소 정보가 저장되어 있습니다.

이 파일을 커밋하면 팀원들도 같은 원격 저장소를 사용할 수 있습니다. 김개발 씨가 설정을 마치고 dvc push를 실행했습니다.

터미널에 업로드 진행률이 표시되었습니다. 잠시 후 "1 file pushed"라는 메시지가 떴습니다.

"이제 팀원들도 이 데이터를 받을 수 있겠군요!" 김개발 씨의 얼굴에 미소가 번졌습니다.

실전 팁

💡 - 민감한 데이터라면 S3나 GCS처럼 접근 권한을 세밀하게 제어할 수 있는 저장소를 사용하세요

• dvc push 전에 원격 저장소 접근 권한이 있는지 확인하세요 (AWS credentials 등)
• 여러 원격 저장소를 등록하고 상황에 따라 선택해서 사용할 수 있습니다

---

4. 파이프라인 정의

김개발 씨의 프로젝트가 점점 복잡해지고 있습니다. 데이터 전처리, 피처 추출, 모델 학습, 평가까지 여러 단계가 연결되어 있습니다.

어느 날 데이터가 업데이트되어 전처리부터 다시 실행해야 했는데, 어떤 순서로 어떤 스크립트를 실행해야 하는지 헷갈렸습니다. "이런 작업 순서를 자동으로 관리할 수 없을까요?"

DVC 파이프라인은 데이터 처리 단계들을 연결하여 자동화하는 기능입니다. dvc.yaml 파일에 각 단계의 의존성과 출력물을 정의하면, DVC가 변경된 부분만 자동으로 다시 실행합니다.

마치 레시피처럼 "이 재료가 바뀌면 이 요리를 다시 만들어라"라고 지정하는 것과 같습니다.

다음 코드를 살펴봅시다.

# dvc.yaml - 파이프라인 정의 파일
stages:
  prepare:
    cmd: python src/prepare.py
    deps:
      - src/prepare.py
      - data/raw/
    outs:
      - data/prepared/

  train:
    cmd: python src/train.py
    deps:
      - src/train.py
      - data/prepared/
    outs:
      - models/model.pkl
    metrics:
      - metrics/scores.json:
          cache: false

  evaluate:
    cmd: python src/evaluate.py
    deps:
      - src/evaluate.py
      - models/model.pkl
    plots:
      - metrics/plots.csv

# 파이프라인 실행
# dvc repro

머신러닝 프로젝트는 보통 여러 단계로 이루어집니다. 원본 데이터를 정제하고, 피처를 추출하고, 모델을 학습시키고, 성능을 평가합니다.

각 단계는 이전 단계의 결과물에 의존합니다. 이런 일련의 과정을 파이프라인이라고 부릅니다.

김개발 씨가 겪은 문제는 많은 ML 엔지니어들이 공감할 것입니다. 데이터가 바뀌면 어디서부터 다시 실행해야 할까요?

전처리 코드를 수정하면? 하이퍼파라미터를 바꾸면?

매번 수동으로 판단하고 실행하기는 번거롭고 실수하기 쉽습니다. DVC 파이프라인은 이 문제를 해결합니다.

비유하자면, DVC 파이프라인은 마치 요리 레시피와 같습니다. "양파를 볶아서 베이스를 만들고, 그 베이스에 토마토를 넣어 소스를 만들고, 그 소스에 파스타를 버무린다." 각 단계가 무엇에 의존하고 무엇을 만들어내는지 명확합니다.

양파가 바뀌면 베이스부터 다시 만들어야 하고, 파스타만 바뀌면 마지막 단계만 다시 하면 됩니다. 파이프라인은 dvc.yaml 파일에 정의합니다.

이 파일은 프로젝트 루트에 위치합니다. 각 단계(stage)마다 실행할 명령어(cmd), 의존성(deps), 출력물(outs)을 지정합니다.

deps는 해당 단계가 의존하는 파일이나 디렉토리입니다. 스크립트 파일 자체도 의존성에 포함합니다.

코드가 바뀌면 다시 실행해야 하기 때문입니다. 데이터 파일이나 이전 단계의 출력물도 의존성으로 지정합니다.

outs는 해당 단계가 생성하는 출력물입니다. 모델 파일, 전처리된 데이터, 중간 결과물 등이 여기에 해당합니다.

DVC는 이 출력물들을 자동으로 추적합니다. metrics는 모델 성능 지표를 담은 파일입니다.

정확도, F1 스코어 같은 숫자들을 JSON 형식으로 저장하면 DVC가 버전별로 비교해줍니다. cache: false 옵션은 이 파일을 캐시에 저장하지 않고 Git에 직접 커밋한다는 의미입니다.

작은 텍스트 파일이니까요. 파이프라인을 실행하려면 dvc repro 명령을 사용합니다.

이 명령은 의존성을 분석하여 변경된 부분만 다시 실행합니다. 아무것도 바뀌지 않았다면 "Stage is cached" 메시지와 함께 건너뜁니다.

데이터가 바뀌었다면 그에 영향받는 모든 후속 단계가 순서대로 실행됩니다. 파이프라인의 또 다른 장점은 실행 이력이 기록된다는 것입니다.

dvc.lock 파일에 각 단계의 입출력 해시값이 저장됩니다. 이 파일을 Git에 커밋하면 "이 코드와 이 데이터로 이 결과물을 만들었다"라는 기록이 남습니다.

김개발 씨는 dvc.yaml을 작성하고 dvc repro를 실행했습니다. 터미널에 각 단계가 순서대로 실행되는 모습이 표시되었습니다.

"와, 이제 뭘 실행해야 하는지 고민 안 해도 되겠네요!" 박시니어 씨가 덧붙였습니다. "데이터가 바뀌면 dvc repro만 치면 돼요.

DVC가 알아서 필요한 것만 다시 실행해줍니다."

실전 팁

💡 - 의존성(deps)에 스크립트 파일도 반드시 포함하세요. 코드 변경도 재실행 트리거가 됩니다

• 큰 출력물은 outs에, 작은 지표 파일은 metrics에 지정하세요
• dvc dag 명령으로 파이프라인 구조를 시각적으로 확인할 수 있습니다

---

5. 실험 재현성 확보

김개발 씨가 드디어 좋은 성능의 모델을 만들었습니다. 정확도 95%!

팀장님께 보고하려는데, 팀장님이 물었습니다. "그 결과를 다시 만들어볼 수 있어요?" 김개발 씨는 멈칫했습니다.

어떤 데이터, 어떤 하이퍼파라미터, 어떤 코드 버전으로 그 결과를 얻었는지 정확히 기억나지 않았습니다. "재현이요?

그게..."

재현성은 같은 조건에서 같은 결과를 다시 얻을 수 있는 능력입니다. DVC는 코드, 데이터, 파라미터, 환경을 모두 버전 관리하여 언제든 과거 실험을 정확히 재현할 수 있게 합니다.

마치 타임머신처럼 과거의 특정 시점으로 돌아가 그때와 똑같은 실험을 다시 실행할 수 있습니다.

다음 코드를 살펴봅시다.

# params.yaml - 하이퍼파라미터 정의
prepare:
  split_ratio: 0.2
  random_seed: 42

train:
  learning_rate: 0.001
  epochs: 100
  batch_size: 32

# dvc.yaml에서 params 참조
stages:
  train:
    cmd: python src/train.py
    deps:
      - src/train.py
      - data/prepared/
    params:
      - train.learning_rate
      - train.epochs
    outs:
      - models/model.pkl

# 특정 Git 커밋으로 체크아웃 후 데이터도 함께 복원
git checkout v1.0
dvc checkout

# 또는 한 번에 실행
dvc repro --rev v1.0

머신러닝에서 재현성은 매우 중요합니다. 좋은 결과를 얻었다면 그 결과를 다시 만들 수 있어야 합니다.

그래야 검증도 할 수 있고, 더 나은 모델로 발전시킬 수도 있습니다. 하지만 실제로 재현성을 확보하기는 쉽지 않습니다.

김개발 씨처럼 많은 개발자들이 비슷한 경험을 합니다. "지난주에 정확도 95% 찍었는데, 지금 다시 돌리면 92%밖에 안 나와요." 왜 이런 일이 생길까요?

그 사이에 데이터가 조금 바뀌었거나, 코드를 수정했거나, 하이퍼파라미터를 다르게 설정했기 때문입니다. 재현성을 확보하려면 네 가지를 모두 기록해야 합니다.

코드, 데이터, 파라미터, 그리고 환경입니다. Git은 코드를 관리하고, DVC는 데이터를 관리합니다.

파라미터는 어떻게 할까요? DVC는 params.yaml 파일을 통해 하이퍼파라미터를 관리합니다.

학습률, 에폭 수, 배치 크기 같은 설정값을 이 파일에 정의합니다. 이 파일은 일반 텍스트이므로 Git에 커밋됩니다.

코드와 함께 파라미터 변경 이력도 추적되는 것입니다. dvc.yaml에서 params 섹션을 추가하면 특정 파라미터가 바뀌었을 때 해당 단계를 다시 실행합니다.

학습률이 바뀌면 학습 단계를 다시 실행해야 하니까요. 이렇게 하면 "이 파라미터로 이 결과를 얻었다"라는 기록이 자동으로 남습니다.

과거 실험을 재현하려면 어떻게 할까요? 먼저 Git으로 그 시점의 코드를 체크아웃합니다.

git checkout v1.0 같은 명령이죠. 하지만 이것만으로는 부족합니다.

그 시점의 데이터도 필요합니다. 여기서 dvc checkout 명령이 등장합니다.

이 명령은 현재 .dvc 파일들을 읽어서 해당 버전의 데이터를 복원합니다. Git checkout 후에 dvc checkout을 실행하면 코드와 데이터 모두 과거 버전으로 돌아갑니다.

더 편리한 방법도 있습니다. dvc repro --rev v1.0 명령을 사용하면 특정 Git 커밋 시점의 파이프라인을 한 번에 재현합니다.

코드, 데이터, 파라미터를 모두 그 시점으로 맞추고 파이프라인을 실행합니다. 환경 관리도 중요합니다.

Python 버전이나 라이브러리 버전이 다르면 같은 코드도 다른 결과를 낼 수 있습니다. requirements.txt나 environment.yaml 파일을 Git에 커밋하여 환경 정보도 함께 기록하세요.

김개발 씨는 이제 모든 실험을 params.yaml과 함께 커밋하기 시작했습니다. 일주일 후 팀장님이 다시 물었습니다.

"지난번 그 좋은 결과, 다시 보여줄 수 있어요?" 이번에는 자신있게 대답했습니다. "물론이죠.

git checkout하고 dvc checkout하면 바로 재현할 수 있습니다!"

실전 팁

💡 - 랜덤 시드를 params.yaml에 명시하여 무작위성도 제어하세요

• 실험이 성공하면 바로 Git 태그를 달아두세요 (예: git tag exp-v1-95acc)
• requirements.txt도 함께 커밋하여 Python 환경까지 재현 가능하게 하세요

---

6. Git과 DVC 통합

김개발 씨는 이제 DVC의 기본 기능을 모두 익혔습니다. 하지만 한 가지 의문이 남았습니다.

"Git과 DVC를 따로따로 쓰는 게 번거로운데, 더 자연스럽게 통합할 수 없을까요?" 박시니어 씨가 웃으며 대답했습니다. "좋은 포인트예요.

사실 둘은 아주 자연스럽게 함께 동작하도록 설계되었어요. 그 흐름을 알려드릴게요."

Git과 DVC는 마치 한 팀처럼 동작합니다. Git이 코드와 메타데이터를 관리하고, DVC가 대용량 데이터를 관리합니다.

이 둘을 함께 사용하는 워크플로우를 익히면 코드와 데이터를 일관성 있게 버전 관리할 수 있습니다. 마치 듀엣을 이루는 두 악기처럼, 각자의 역할을 하면서도 하나의 음악을 만들어냅니다.

다음 코드를 살펴봅시다.

# 전체 워크플로우 예시

# 1. 데이터 업데이트 후 DVC로 추적
dvc add data/new_dataset.csv

# 2. 파이프라인 실행하여 모델 재학습
dvc repro

# 3. 변경사항 모두 Git에 커밋
git add data/new_dataset.csv.dvc dvc.lock params.yaml
git commit -m "Update dataset and retrain model"

# 4. 원격 저장소에 데이터 푸시
dvc push

# 5. Git 원격 저장소에 코드 푸시
git push

# 팀원이 프로젝트를 받을 때
git clone https://github.com/team/ml-project.git
cd ml-project
dvc pull  # 데이터 다운로드

# 특정 버전으로 전환
git checkout v2.0
dvc checkout

지금까지 배운 내용을 종합해보겠습니다. Git과 DVC는 각자의 영역이 있습니다.

Git은 소스 코드, 설정 파일, 그리고 DVC가 생성하는 메타데이터 파일(.dvc 파일, dvc.lock, dvc.yaml)을 관리합니다. DVC는 대용량 데이터 파일과 모델 파일을 관리합니다.

비유하자면, Git과 DVC의 관계는 마치 건물의 설계도와 건축 자재의 관계와 같습니다. 설계도(코드)는 가볍고 쉽게 공유할 수 있습니다.

건축 자재(데이터)는 무겁고 별도의 창고가 필요합니다. 하지만 설계도에는 "이 창고의 이 자재를 사용하라"라는 참조가 적혀 있습니다.

둘을 함께 보면 완전한 건물을 지을 수 있습니다. 실제 워크플로우를 살펴보겠습니다.

새로운 데이터가 들어왔다고 가정합니다. 먼저 dvc add로 데이터를 추적합니다.

그 다음 dvc repro로 파이프라인을 실행하여 모델을 재학습시킵니다. 여기까지가 DVC 영역입니다.

이제 Git 영역입니다. 변경된 .dvc 파일과 dvc.lock 파일을 커밋합니다.

이 파일들에는 새 데이터의 해시값과 파이프라인 실행 결과가 기록되어 있습니다. 커밋 메시지에 어떤 변경이 있었는지 적으면 좋습니다.

다음으로 dvc push를 실행하여 새 데이터를 원격 저장소에 업로드합니다. 그리고 git push로 코드와 메타데이터를 GitHub에 푸시합니다.

순서가 중요합니다. dvc push를 먼저 하는 것이 좋습니다.

그래야 팀원이 코드를 받았을 때 데이터도 바로 받을 수 있습니다. 팀원 입장에서 보겠습니다.

새 팀원이 프로젝트에 합류했습니다. 먼저 git clone으로 저장소를 복제합니다.

이 시점에는 코드와 .dvc 파일만 있고 실제 데이터는 없습니다. dvc pull을 실행하면 .dvc 파일을 읽어 원격 저장소에서 데이터를 다운로드합니다.

이제 팀원도 완전한 프로젝트를 가지게 되었습니다. 브랜치 작업도 자연스럽게 됩니다.

새 기능을 개발하기 위해 브랜치를 만들고, 데이터를 수정하고, 실험을 진행합니다. 브랜치마다 다른 버전의 데이터를 사용할 수 있습니다.

메인 브랜치로 병합할 때 .dvc 파일도 함께 병합됩니다. 특정 버전으로 전환하는 것도 간단합니다.

git checkout v2.0으로 코드를 과거 버전으로 돌리고, dvc checkout으로 데이터도 그 시점으로 맞춥니다. 두 명령을 연달아 실행하면 프로젝트 전체가 과거 상태로 복원됩니다.

주의할 점이 있습니다. .dvc 파일을 커밋하지 않으면 데이터 변경 이력이 끊어집니다.

파이프라인을 실행한 후에는 dvc.lock 파일도 함께 커밋해야 합니다. 이 파일이 없으면 재현성이 보장되지 않습니다.

김개발 씨는 이제 Git과 DVC를 자유자재로 사용합니다. 코드를 수정하고, 데이터를 업데이트하고, 실험을 기록하고, 팀원들과 공유합니다.

모든 것이 버전 관리되고, 언제든 과거로 돌아갈 수 있습니다. "이제야 제대로 된 ML 프로젝트 관리가 뭔지 알겠어요!" 박시니어 씨가 흐뭇하게 웃었습니다.

"축하해요. 이제 당신도 DVC 마스터입니다."

실전 팁

💡 - 커밋할 때 .dvc 파일과 dvc.lock을 빠뜨리지 마세요. 체크리스트를 만들어두면 좋습니다

• CI/CD 파이프라인에 dvc pull을 추가하면 자동 배포 시에도 데이터를 사용할 수 있습니다
• git push 전에 항상 dvc push를 먼저 실행하는 습관을 들이세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!