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

머신러닝 프로젝트에서 대용량 데이터와 모델 파일을 효과적으로 관리하는 DVC(Data Version Control)의 핵심 기능을 다룹니다. 설치부터 파이프라인 구축까지 실무에서 바로 활용할 수 있는 내용을 담았습니다.

---

목차

1. DVC_설치_및_초기화
2. Git_통합_설정하기
3. dvc_add_push_pull_사용법
4. Remote_Storage_설정
5. 파이프라인_정의
6. 의존성_그래프_시각화

---

1. DVC 설치 및 초기화

김개발 씨는 머신러닝 팀에 합류한 지 일주일 된 신입 개발자입니다. 첫 번째 업무로 기존 모델을 개선하라는 지시를 받았는데, 문제가 생겼습니다.

"이 학습 데이터, 어느 버전이 맞는 거예요?" 폴더에는 data_final.csv, data_final_v2.csv, data_진짜최종.csv가 뒤섞여 있었습니다.

**DVC(Data Version Control)**는 한마디로 대용량 파일을 위한 Git입니다. 마치 도서관 사서가 수만 권의 책 위치를 정확히 기억하는 것처럼, DVC는 거대한 데이터셋과 모델 파일의 모든 변경 이력을 추적합니다.

이것을 제대로 활용하면 "어떤 데이터로 학습했더라?" 하는 혼란에서 완전히 벗어날 수 있습니다.

다음 코드를 살펴봅시다.

# DVC 설치하기
pip install dvc

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

# DVC 초기화 (Git 저장소 내에서 실행)
dvc init

# 초기화 결과 확인
git status
# .dvc/ 디렉토리와 .dvcignore 파일이 생성됨

# 변경사항을 Git에 커밋
git add .dvc .dvcignore
git commit -m "Initialize DVC"

김개발 씨는 입사 첫 주부터 난관에 부딪혔습니다. 선배가 남긴 머신러닝 프로젝트를 인수받았는데, 학습 데이터가 여기저기 흩어져 있었습니다.

Git으로 코드는 잘 관리되어 있었지만, 정작 중요한 데이터 파일들은 혼란 그 자체였습니다. 팀 리더 박시니어 씨가 다가와 화면을 보더니 한숨을 쉬었습니다.

"우리도 예전엔 이랬어요. 근데 DVC를 도입하고 나서 세상이 달라졌죠." 그렇다면 DVC란 정확히 무엇일까요?

쉽게 비유하자면, DVC는 마치 대형 창고의 재고 관리 시스템과 같습니다. 일반 Git이 작은 사무용품을 관리하는 서랍장이라면, DVC는 수 톤짜리 화물도 언제 들어오고 나갔는지 정확히 추적하는 물류 시스템입니다.

파일 자체를 저장하는 게 아니라, 파일의 "위치표"를 관리하는 방식으로 작동합니다. DVC가 없던 시절에는 어땠을까요?

개발자들은 data_v1.csv, data_v2.csv처럼 파일명에 버전을 붙이는 원시적인 방법을 썼습니다. 프로젝트가 커지면 어떤 버전이 어떤 모델과 연결되는지 아무도 몰랐습니다.

더 큰 문제는 Git에 대용량 파일을 올릴 수 없다는 점이었습니다. GitHub는 100MB 이상 파일을 거부하는데, 학습 데이터는 수 GB가 기본이니까요.

바로 이런 문제를 해결하기 위해 DVC가 등장했습니다. DVC를 사용하면 Git처럼 버전 관리가 가능해집니다.

또한 대용량 파일을 원격 저장소에 안전하게 보관할 수 있습니다. 무엇보다 코드와 데이터의 동기화가 자동으로 이루어진다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 pip install dvc로 DVC를 설치합니다.

Python 패키지로 제공되어 설치가 간편합니다. 다음으로 dvc init 명령어가 핵심입니다.

이 명령은 .dvc 디렉토리를 생성하여 DVC 설정 파일들을 저장할 공간을 만듭니다. 마지막으로 이 변경사항을 Git에 커밋하면 초기화가 완료됩니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 이미지 분류 모델을 개발한다고 가정해봅시다.

10GB짜리 이미지 데이터셋을 DVC로 관리하면, 팀원 누구나 한 줄 명령어로 정확히 같은 데이터를 받을 수 있습니다. 실험마다 데이터가 조금씩 바뀌어도 히스토리가 남아 있어 언제든 되돌릴 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 Git 저장소가 아닌 곳에서 dvc init을 실행하는 것입니다.

DVC는 Git과 함께 작동하도록 설계되어 있어, 반드시 git init이 먼저 되어 있어야 합니다. 따라서 새 프로젝트라면 git init을 먼저 실행한 후 dvc init을 해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 안내에 따라 DVC를 설치하고 초기화한 김개발 씨는 희망을 보았습니다.

"이제 데이터도 Git처럼 관리할 수 있는 거군요!" DVC 초기화는 모든 데이터 버전 관리의 첫걸음입니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 가상환경에서 pip install dvc[all]을 사용하면 모든 원격 저장소 지원을 한 번에 설치할 수 있습니다

• .dvcignore 파일로 DVC가 추적하지 않을 파일 패턴을 지정할 수 있습니다

---

2. Git 통합 설정하기

김개발 씨가 DVC를 설치하고 나서 의문이 생겼습니다. "그런데 Git이랑 DVC가 어떻게 같이 작동하는 거예요?

둘이 충돌하지 않나요?" 박시니어 씨가 빙긋 웃으며 대답했습니다. "둘은 싸우는 게 아니라 환상의 콤비예요."

Git과 DVC의 통합은 마치 비행기 조종사와 부조종사의 협업과 같습니다. Git은 코드라는 항로를 책임지고, DVC는 데이터라는 화물을 책임집니다.

서로 역할이 명확히 분리되어 있지만, 같은 목적지를 향해 완벽하게 협력합니다. 이 통합을 이해하면 코드와 데이터가 항상 동기화된 상태를 유지할 수 있습니다.

다음 코드를 살펴봅시다.

# .dvc 파일의 구조 살펴보기
# data.csv를 DVC로 추적하면 data.csv.dvc 파일이 생성됨

# data.csv.dvc 파일 내용 예시
outs:
- md5: a8f5f167f44f4964e6c998dee827110c
  size: 1048576
  path: data.csv

# Git은 .dvc 파일만 추적
git add data.csv.dvc
git commit -m "Add training data"

# .gitignore에 자동으로 원본 파일이 추가됨
cat .gitignore
# /data.csv  <- DVC가 자동 추가

# 브랜치를 바꾸면 DVC도 따라감
git checkout feature-branch
dvc checkout  # 해당 브랜치의 데이터 버전으로 자동 전환

김개발 씨는 DVC를 설치한 후에도 여전히 궁금한 점이 많았습니다. Git과 DVC가 어떻게 함께 작동하는지 도무지 감이 오지 않았습니다.

둘 다 버전 관리 도구인데, 서로 방해하지 않을까요? 박시니어 씨가 화이트보드 앞으로 김개발 씨를 불렀습니다.

"자, 여기 그림을 보면서 설명해 줄게요." Git과 DVC의 관계는 마치 우체국 시스템과 같습니다. 일반 편지는 우체부가 직접 배달합니다.

이게 Git의 역할입니다. 하지만 대형 화물은 어떨까요?

우체부가 직접 들고 다닐 수 없으니, 화물 추적 번호가 적힌 스티커만 편지에 붙입니다. 실제 화물은 별도 창고에 보관되고요.

DVC가 바로 이 방식으로 작동합니다. DVC로 파일을 추적하면 .dvc 확장자를 가진 작은 파일이 생성됩니다.

이 파일은 수백 바이트에 불과합니다. 안에는 원본 파일의 해시값, 크기, 경로 정보만 담겨 있습니다.

Git은 이 가벼운 .dvc 파일만 관리하고, 실제 수 GB짜리 원본 파일은 DVC가 따로 관리합니다. 자동화의 마법도 있습니다.

DVC는 원본 파일을 .gitignore에 자동 추가합니다. 실수로 대용량 파일을 Git에 커밋하는 일을 원천 차단하는 것입니다.

똑똑하지 않나요? 위의 코드에서 핵심은 git checkout과 dvc checkout의 조합입니다.

Git으로 브랜치를 전환하면 .dvc 파일도 해당 브랜치 버전으로 바뀝니다. 그 상태에서 dvc checkout을 실행하면, .dvc 파일에 기록된 해시값을 보고 해당 버전의 데이터 파일을 가져옵니다.

코드와 데이터가 항상 한 쌍으로 움직이는 것입니다. 실무에서 이 통합이 빛을 발하는 순간이 있습니다.

예를 들어 A/B 테스트를 위해 두 가지 데이터셋으로 실험한다고 합시다. experiment-A 브랜치와 experiment-B 브랜치를 만들고, 각각 다른 데이터를 연결해 둡니다.

나중에 어떤 실험 결과든 브랜치만 체크아웃하면 그때의 코드와 데이터가 완벽하게 복원됩니다. 주의할 점이 하나 있습니다.

git checkout 후에 dvc checkout을 잊으면 안 됩니다. Git만 실행하면 .dvc 파일은 바뀌지만 실제 데이터 파일은 그대로입니다.

이 상태로 작업하면 코드와 데이터가 어긋나는 문제가 생깁니다. Git hooks를 설정해서 자동화하는 것을 권장합니다.

김개발 씨가 눈을 빛내며 말했습니다. "아, 그러니까 Git은 지도를 관리하고 DVC는 실제 보물을 관리하는 거네요!" 박시니어 씨가 고개를 끄덕였습니다.

"정확해요. 그 지도만 있으면 언제든 보물을 찾을 수 있죠."

실전 팁

💡 - git config로 post-checkout 훅을 설정하면 dvc checkout이 자동 실행되게 할 수 있습니다

• dvc install 명령어로 Git hooks를 한 번에 설정할 수 있습니다

---

3. dvc add push pull 사용법

김개발 씨가 드디어 첫 번째 학습 데이터를 DVC로 관리해 보기로 했습니다. "Git에서 add, commit, push 하듯이 비슷한 명령어가 있나요?" 박시니어 씨가 고개를 끄덕였습니다.

"거의 똑같아요. 그래서 배우기 쉽죠."

DVC의 add, push, pull 명령어는 Git의 그것과 거의 동일한 워크플로우를 따릅니다. 마치 택배를 보내고 받는 과정과 같습니다.

add는 택배 상자에 물건을 담는 것이고, push는 택배를 발송하는 것이며, pull은 배송된 택배를 수령하는 것입니다. 이 세 가지만 익히면 데이터 버전 관리의 80%는 마스터한 것입니다.

다음 코드를 살펴봅시다.

# 1. 데이터 파일을 DVC 추적에 추가
dvc add data/training_dataset.csv
# data/training_dataset.csv.dvc 파일 생성
# data/.gitignore에 training_dataset.csv 추가됨

# 2. 변경사항을 Git에 커밋
git add data/training_dataset.csv.dvc data/.gitignore
git commit -m "Add training dataset v1"

# 3. 데이터를 원격 저장소로 푸시
dvc push
# 실제 데이터 파일이 remote storage로 업로드됨

# 4. 다른 환경에서 데이터 가져오기
git clone <repository-url>
dvc pull
# .dvc 파일을 읽어서 해당 버전의 데이터 다운로드

# 5. 데이터 업데이트 후 재추적
dvc add data/training_dataset.csv  # 변경된 파일 재추적
git add data/training_dataset.csv.dvc
git commit -m "Update training dataset v2"
dvc push

김개발 씨의 책상 위에는 방금 전처리를 마친 학습 데이터 파일이 있었습니다. 500MB짜리 CSV 파일입니다.

이제 이걸 팀원들과 공유해야 하는데, 어떻게 해야 할까요? 박시니어 씨가 터미널 앞에 앉았습니다.

"자, 실습으로 보여줄게요." 첫 번째 단계는 dvc add 입니다. 이 명령어는 "이 파일을 DVC로 관리하겠다"고 선언하는 것입니다.

실행하면 두 가지 일이 일어납니다. 원본 파일 옆에 .dvc 파일이 생성되고, .gitignore에 원본 파일이 추가됩니다.

DVC는 원본 파일을 .dvc/cache 디렉토리에 복사해 둡니다. 왜 캐시에 복사할까요?

나중에 파일이 바뀌어도 이전 버전으로 돌아갈 수 있게 하기 위해서입니다. 마치 게임의 세이브 파일을 저장해 두는 것과 같습니다.

실수로 데이터를 망쳐도 언제든 복구할 수 있습니다. 두 번째 단계는 Git 커밋입니다.

.dvc 파일과 .gitignore 변경사항을 Git에 커밋합니다. 이 순간 "이 코드 버전에는 이 데이터 버전이 연결되어 있다"는 기록이 남습니다.

나중에 이 커밋으로 돌아오면 정확히 그때의 데이터를 복원할 수 있습니다. 세 번째 단계가 바로 dvc push 입니다.

로컬 캐시에 있는 데이터를 원격 저장소로 업로드합니다. S3, GCS, Azure 등 다양한 클라우드 저장소를 지원합니다.

팀원들이 접근할 수 있는 공용 저장소로 데이터를 보내는 것입니다. 반대로 dvc pull은 데이터를 가져옵니다.

새로운 팀원이 프로젝트를 clone하면 코드만 받아집니다. 대용량 데이터는 아직 없는 상태입니다.

dvc pull을 실행하면 .dvc 파일을 읽어서 원격 저장소에서 해당 데이터를 다운로드합니다. 실무에서 이 워크플로우는 반복됩니다.

데이터를 수정할 때마다 dvc add, git commit, dvc push 세 단계를 거칩니다. 마치 Git으로 코드를 관리할 때 add, commit, push 하는 것과 똑같습니다.

이미 Git에 익숙하다면 DVC 학습 곡선은 매우 완만합니다. 흔히 하는 실수가 있습니다.

dvc add만 하고 git commit을 잊어버리는 경우입니다. 이러면 .dvc 파일이 Git에 기록되지 않아서, 나중에 이 버전으로 돌아올 수 없습니다.

반드시 DVC 명령어 다음에는 Git 커밋이 따라와야 합니다. 김개발 씨가 직접 따라해 보았습니다.

dvc add, git commit, dvc push. "생각보다 간단하네요!" 박시니어 씨가 웃으며 말했습니다.

"Git을 알면 DVC도 아는 거예요."

실전 팁

💡 - dvc add 대신 dvc add -R directory/로 디렉토리 전체를 한 번에 추적할 수 있습니다

• dvc status로 로컬과 원격의 동기화 상태를 확인할 수 있습니다

---

4. Remote Storage 설정

김개발 씨가 dvc push를 실행했더니 에러가 났습니다. "ERROR: failed to push - remote storage가 설정되지 않았습니다." 박시니어 씨가 설명했습니다.

"아, 데이터를 보낼 목적지를 아직 안 정했구나. 창고 주소를 먼저 등록해야지."

Remote Storage는 DVC 데이터의 실제 저장 장소입니다. 마치 이사할 때 짐을 맡기는 창고 서비스와 같습니다.

로컬에서 작업한 데이터를 안전하게 보관하고, 팀원 누구나 접근할 수 있는 중앙 저장소 역할을 합니다. AWS S3, Google Cloud Storage, Azure Blob 등 주요 클라우드 서비스를 모두 지원합니다.

다음 코드를 살펴봅시다.

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

# Google Cloud Storage 설정
dvc remote add -d myremote gs://my-bucket/dvc-storage

# 로컬 디렉토리를 원격으로 설정 (테스트용)
dvc remote add -d myremote /path/to/local/storage

# 설정된 원격 저장소 확인
dvc remote list
# myremote s3://my-bucket/dvc-storage

# AWS 자격 증명 설정 (필요한 경우)
dvc remote modify myremote access_key_id 'YOUR_ACCESS_KEY'
dvc remote modify myremote secret_access_key 'YOUR_SECRET_KEY'

# 설정 파일 확인 및 Git 커밋
cat .dvc/config
git add .dvc/config
git commit -m "Configure S3 as DVC remote storage"

김개발 씨는 당황했습니다. push가 안 되다니요.

데이터는 준비됐는데 보낼 곳이 없다니 말이 됩니까? 박시니어 씨가 차근차근 설명을 시작했습니다.

"Git으로 치면 GitHub 같은 원격 저장소가 필요한 거야. DVC도 마찬가지로 데이터를 저장할 곳이 필요해." Remote Storage는 데이터의 집입니다.

비유하자면 이사할 때 쓰는 창고 서비스와 같습니다. 내 방에 있는 짐을 창고에 맡겨두면, 나중에 언제든 가져올 수 있습니다.

친구도 같은 창고에 접근 권한이 있으면 물건을 가져갈 수 있고요. DVC의 remote storage가 바로 이 역할을 합니다.

어떤 저장소를 선택해야 할까요? 회사에서 AWS를 주로 쓴다면 S3가 자연스러운 선택입니다.

Google Cloud 환경이라면 GCS가 좋습니다. 비용이 걱정된다면 로컬 서버나 NAS를 remote로 설정할 수도 있습니다.

DVC는 이 모든 것을 동일한 인터페이스로 지원합니다. 설정 방법을 살펴봅시다.

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

여러 개의 remote를 등록해 두고 상황에 따라 다른 곳에 push할 수도 있습니다. 하지만 대부분의 경우 하나의 기본 remote면 충분합니다.

클라우드 자격 증명은 어떻게 처리할까요? 두 가지 방법이 있습니다.

dvc remote modify로 직접 설정하거나, 환경 변수를 사용할 수 있습니다. AWS의 경우 ~/.aws/credentials 파일이 있으면 자동으로 인식합니다.

보안을 위해 자격 증명은 .dvc/config에 직접 쓰지 않는 것이 좋습니다. 가장 중요한 포인트가 있습니다. .dvc/config 파일을 Git에 커밋해야 합니다.

이 파일에 remote 주소가 저장되어 있어서, 팀원들이 clone하면 같은 저장소를 바라보게 됩니다. 각자 다른 저장소를 쓰면 데이터 공유가 안 되니까요.

실무에서 자주 쓰는 패턴이 있습니다. 개발 환경용 remote와 프로덕션 remote를 분리하는 것입니다.

실험 데이터는 저렴한 저장소에, 실제 서비스용 데이터는 안정적인 저장소에 보관합니다. dvc push -r production처럼 특정 remote를 지정해서 push할 수 있습니다.

김개발 씨가 S3 버킷 주소를 입력하고 다시 push를 시도했습니다. 이번에는 성공입니다.

"이제 팀원들도 이 데이터를 받을 수 있는 거죠?" 박시니어 씨가 확인해 주었습니다. "맞아요.

dvc pull 한 줄이면 돼요."

실전 팁

💡 - 로컬 디렉토리를 remote로 설정하면 네트워크 없이 DVC를 테스트해 볼 수 있습니다

• dvc remote modify로 region, endpoint 등 세부 설정을 조정할 수 있습니다

---

5. 파이프라인 정의

김개발 씨가 모델 학습 스크립트를 열심히 돌리고 있었습니다. 데이터 전처리, 피처 추출, 모델 학습, 평가까지.

매번 순서대로 실행하려니 귀찮고 실수도 잦았습니다. "이거 자동화할 방법 없나요?" 박시니어 씨가 귀가 솔깃해졌습니다.

"DVC 파이프라인을 써봐."

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.json:
          cache: false

  evaluate:
    cmd: python src/evaluate.py
    deps:
      - src/evaluate.py
      - models/model.pkl
      - data/prepared/
    plots:
      - results/plots/

# 파이프라인 실행
dvc repro
# 변경된 스테이지만 자동 재실행

김개발 씨의 하루 일과는 비슷했습니다. 출근하면 데이터 전처리 스크립트를 돌리고, 끝나면 학습 스크립트를 실행하고, 또 끝나면 평가 스크립트를 실행합니다.

이 과정에서 실수로 순서를 건너뛰어 엉뚱한 결과가 나온 적도 있습니다. 박시니어 씨가 새로운 파일을 하나 열었습니다.

dvc.yaml이라는 이름이었습니다. 파이프라인이란 무엇일까요?

공장의 조립 라인을 떠올려 보세요. 자동차를 만들 때 철판이 들어오면, 프레스, 용접, 도장, 조립 순서로 작업이 진행됩니다.

각 단계는 이전 단계의 결과물을 받아서 자기 작업을 수행합니다. DVC 파이프라인도 똑같습니다.

데이터가 들어오면 정의된 순서대로 처리됩니다. dvc.yaml 파일의 구조를 살펴봅시다.

stages 아래에 각 단계를 정의합니다. 각 단계에는 cmd(실행할 명령어), deps(의존성 파일), outs(출력 파일)가 있습니다.

DVC는 이 정보를 보고 어떤 순서로 실행해야 하는지 자동으로 파악합니다. 위 예제에서 세 개의 단계가 있습니다.

prepare 단계는 원시 데이터를 가공합니다. train 단계는 가공된 데이터로 모델을 학습합니다.

evaluate 단계는 학습된 모델을 평가합니다. train이 prepare의 출력을 의존성으로 가지고 있으므로, DVC는 prepare가 먼저 실행되어야 함을 압니다.

가장 강력한 기능은 incremental build입니다. 소스 코드나 데이터가 변경되지 않으면 해당 단계는 건너뜁니다.

만약 학습 스크립트만 수정했다면, prepare는 스킵하고 train과 evaluate만 다시 실행됩니다. 시간이 오래 걸리는 전처리를 매번 반복할 필요가 없습니다.

metrics와 plots 옵션도 눈여겨볼 만합니다. metrics.json처럼 평가 지표를 별도로 관리하면 dvc metrics show로 모델 성능을 한눈에 비교할 수 있습니다.

실험마다 정확도, 손실값 등을 체계적으로 기록하고 비교하는 것이 쉬워집니다. 실행은 단 한 줄입니다.

dvc repro 명령어가 전체 파이프라인을 실행합니다. reproduce의 줄임말로, 재현 가능한 실험이라는 DVC의 철학이 담겨 있습니다.

언제 어디서 실행해도 같은 결과가 나와야 한다는 것입니다. 김개발 씨가 dvc repro를 실행했습니다.

세 단계가 순서대로 실행되고, 마지막에 모델 평가 결과가 출력되었습니다. "이제 스크립트 실행 순서를 외울 필요가 없겠네요!" 박시니어 씨가 덧붙였습니다.

"실수할 일도 없어지죠."

실전 팁

💡 - dvc repro -s train처럼 특정 단계만 실행할 수 있습니다

• params.yaml 파일로 하이퍼파라미터를 관리하면 실험 추적이 더 쉬워집니다

---

6. 의존성 그래프 시각화

김개발 씨가 만든 파이프라인이 점점 복잡해졌습니다. 단계가 10개가 넘어가니 머릿속으로 흐름을 따라가기 어려웠습니다.

"이 단계가 저 단계보다 먼저인지 나중인지 헷갈려요." 박시니어 씨가 묘안을 알려주었습니다. "그래프로 보면 한눈에 들어와."

의존성 그래프는 파이프라인의 구조를 시각적으로 보여주는 지도입니다. 마치 지하철 노선도처럼, 각 역(단계)이 어떻게 연결되어 있는지 한눈에 파악할 수 있습니다.

복잡한 머신러닝 프로젝트에서 전체 흐름을 이해하고 병목 구간을 찾는 데 필수적인 도구입니다.

다음 코드를 살펴봅시다.

# DAG(방향성 비순환 그래프) 출력
dvc dag
# prepare -> train -> evaluate 형태로 출력

# 상세한 의존성 정보 포함
dvc dag --md
# 마크다운 형식으로 출력

# Graphviz DOT 형식으로 출력
dvc dag --dot > pipeline.dot

# DOT 파일을 이미지로 변환 (Graphviz 설치 필요)
dot -Tpng pipeline.dot -o pipeline.png

# 특정 타겟까지의 그래프만 보기
dvc dag --target train
# train 단계까지의 의존성만 표시

# 출력 파일 포함한 상세 그래프
dvc dag --outs
# 각 단계의 입출력 파일까지 표시

김개발 씨의 프로젝트가 성장했습니다. 처음에는 세 단계뿐이던 파이프라인이 이제 열두 단계가 되었습니다.

데이터 수집, 정제, 증강, 피처 엔지니어링, 여러 모델 학습, 앙상블, 평가까지. 복잡해진 만큼 실수도 늘어났습니다.

"어제 피처 엔지니어링 코드 수정했는데, 왜 앙상블까지 다시 돌아가는 거야?" 김개발 씨가 투덜거렸습니다. 박시니어 씨가 다가왔습니다.

"전체 흐름을 그림으로 보면 바로 이해될 거야." DAG라는 개념부터 알아야 합니다. DAG는 Directed Acyclic Graph, 즉 방향성 비순환 그래프입니다.

쉽게 말해 한 방향으로만 흐르고 절대 원점으로 돌아오지 않는 흐름도입니다. 지하철 노선도를 떠올려 보세요.

1호선을 타고 가다가 다시 출발역으로 돌아오는 일은 없습니다. 파이프라인도 마찬가지입니다.

dvc dag 명령어가 이 그래프를 보여줍니다. 터미널에서 실행하면 ASCII 아트로 파이프라인 구조가 출력됩니다.

어떤 단계가 어떤 단계에 의존하는지, 병렬로 실행 가능한 단계는 무엇인지 한눈에 보입니다. 더 예쁜 그림이 필요하다면 DOT 형식을 활용합니다.

dvc dag --dot으로 Graphviz 형식 파일을 생성하고, dot 명령어로 PNG 이미지로 변환합니다. 이 이미지를 문서에 첨부하거나 팀 회의에서 공유하면 프로젝트 구조를 설명하기 훨씬 쉬워집니다.

김개발 씨의 질문에 답이 나왔습니다. 그래프를 보니 피처 엔지니어링 단계의 출력이 여러 모델 학습 단계의 입력으로 연결되어 있었습니다.

그리고 그 모델들이 다시 앙상블 단계로 모였습니다. 피처 코드를 수정하면 그 이후의 모든 단계가 영향을 받는 것이 당연했습니다.

--outs 옵션도 유용합니다. 기본 dvc dag는 단계 이름만 보여주지만, --outs를 추가하면 각 단계의 입출력 파일까지 상세하게 표시됩니다.

"이 모델 파일은 어디서 생성되지?" 하는 의문이 바로 풀립니다. 실무에서 이 시각화가 빛나는 순간이 있습니다.

새로운 팀원이 합류했을 때입니다. 복잡한 파이프라인을 말로 설명하면 한참 걸리지만, 그래프 이미지 하나면 5분 만에 이해시킬 수 있습니다.

온보딩 문서에 파이프라인 그래프를 포함시키는 팀이 많습니다. 김개발 씨가 생성한 이미지를 팀 위키에 업로드했습니다.

"이제 누가 물어봐도 이 그림 보여주면 되겠네요." 박시니어 씨가 칭찬했습니다. "프로젝트 규모가 커질수록 이 습관이 빛을 발할 거야."

실전 팁

💡 - CI/CD 파이프라인에서 dvc dag --md를 자동 실행하여 문서를 최신 상태로 유지할 수 있습니다

• VS Code 확장 프로그램 중에 DVC 그래프를 실시간으로 보여주는 것도 있습니다

---

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