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

머신러닝 프로젝트에서 데이터와 모델 파일의 버전을 체계적으로 관리하는 DVC(Data Version Control)의 핵심 개념과 실무 활용법을 알아봅니다. Git으로는 관리하기 어려운 대용량 데이터 파일을 효율적으로 추적하고 협업하는 방법을 배웁니다.

1. DVC 초기화와 기본 개념

김개발 씨는 입사 후 첫 머신러닝 프로젝트에 투입되었습니다. 열심히 모델을 학습시키던 어느 날, 선배가 물었습니다.

"지난주에 학습시킨 모델이랑 데이터셋 어디 있어요? 그때 성능이 더 좋았는데." 김개발 씨는 당황했습니다.

데이터 파일을 덮어쓰기 해버렸기 때문입니다.

**DVC(Data Version Control)**는 한마디로 대용량 데이터 파일을 위한 Git입니다. 마치 도서관에서 책의 모든 개정판을 보관하듯이, DVC는 데이터셋과 모델 파일의 모든 버전을 체계적으로 관리합니다.

Git이 코드의 역사를 기록한다면, DVC는 데이터의 역사를 기록하는 것입니다.

다음 코드를 살펴봅시다.

# DVC 설치 및 초기화
pip install dvc

# Git 저장소에서 DVC 초기화
cd my-ml-project
dvc init

# 초기화 후 생성되는 파일 확인
ls -la .dvc/
# .dvc/config - DVC 설정 파일
# .dvc/cache - 데이터 캐시 디렉토리

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

김개발 씨는 입사 3개월 차 머신러닝 엔지니어입니다. 요즘 한창 이미지 분류 모델을 개발하고 있는데, 데이터셋만 해도 수십 기가바이트에 달합니다.

문제는 실험을 반복할 때마다 데이터가 조금씩 바뀐다는 것이었습니다. "이 데이터셋 Git에 올려도 되나요?" 김개발 씨가 선배 박시니어 씨에게 물었습니다.

박시니어 씨는 고개를 저었습니다. "Git은 대용량 파일에 적합하지 않아요.

저장소가 엄청나게 커지고, 클론 받는 데만 한 세월이 걸릴 거예요." 그렇다면 DVC란 정확히 무엇일까요? 쉽게 비유하자면, DVC는 마치 창고 관리인과 같습니다.

여러분이 귀중한 물건을 맡기면, 관리인은 그 물건에 고유한 번호표를 붙여서 창고에 보관합니다. 나중에 번호표만 있으면 언제든 그 물건을 찾아올 수 있습니다.

DVC도 마찬가지로, 대용량 데이터 파일을 별도의 저장소에 보관하고, Git에는 그 파일을 찾을 수 있는 작은 메타데이터 파일만 저장합니다. DVC가 없던 시절에는 어땠을까요?

개발자들은 데이터 파일을 직접 관리해야 했습니다. data_v1.csv, data_v2_final.csv, data_v2_final_진짜최종.csv 같은 파일명이 난무했습니다.

어떤 데이터로 어떤 모델을 학습시켰는지 추적하기가 거의 불가능했습니다. 협업은 더 큰 문제였습니다.

팀원끼리 대용량 파일을 공유하려면 USB나 외장하드를 주고받거나, 클라우드에 수동으로 업로드해야 했습니다. 바로 이런 문제를 해결하기 위해 DVC가 등장했습니다.

DVC를 사용하면 데이터 파일도 코드처럼 버전 관리가 가능해집니다. 특정 시점의 데이터셋으로 언제든 돌아갈 수 있습니다.

또한 팀원들과 데이터를 쉽게 공유할 수 있습니다. 무엇보다 실험의 재현성이 보장된다는 큰 이점이 있습니다.

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

그 다음 프로젝트 디렉토리에서 dvc init 명령을 실행하면 .dvc 폴더가 생성됩니다. 이 폴더 안에는 DVC의 설정 파일과 캐시 디렉토리가 들어있습니다.

마지막으로 이 설정 파일들을 Git에 커밋하면 초기화가 완료됩니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 추천 시스템을 개발한다고 가정해봅시다. 사용자 로그 데이터가 매일 수집되고, 주기적으로 모델을 재학습시켜야 합니다.

DVC를 활용하면 각 시점의 데이터와 모델을 정확히 기록해두고, 성능이 떨어졌을 때 이전 버전으로 쉽게 롤백할 수 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 DVC 초기화 전에 이미 Git 저장소가 있어야 한다는 것을 잊는 것입니다. DVC는 Git 위에서 동작하는 도구이므로, 반드시 git init을 먼저 실행해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 바로 DVC를 도입하기로 했습니다.

"이제 데이터 파일 잃어버릴 걱정은 없겠네요!"

실전 팁

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

.dvc 폴더와 .dvcignore 파일은 반드시 Git에 커밋하세요

2. 데이터 파일 추적하기

DVC를 초기화한 김개발 씨는 이제 실제로 데이터 파일을 추적해보고 싶었습니다. 프로젝트 폴더에는 학습용 이미지 데이터셋이 잔뜩 들어있었습니다.

"이 파일들을 어떻게 DVC에 등록하죠?" 박시니어 씨가 dvc add 명령어를 알려주었습니다.

dvc add 명령은 데이터 파일을 DVC의 추적 대상으로 등록합니다. 이 명령을 실행하면 원본 파일은 캐시로 이동하고, 파일의 메타정보를 담은 .dvc 파일이 생성됩니다.

이 .dvc 파일은 크기가 매우 작아서 Git으로 관리하기에 적합합니다.

다음 코드를 살펴봅시다.

# 데이터 파일을 DVC로 추적
dvc add data/train_images/
dvc add models/model.pkl

# 생성된 .dvc 파일 확인
cat data/train_images.dvc
# outs:
# - md5: a1b2c3d4e5f6...
#   size: 1073741824
#   path: train_images

# .gitignore에 자동으로 원본 파일이 추가됨
cat data/.gitignore
# /train_images

# .dvc 파일을 Git에 커밋
git add data/train_images.dvc data/.gitignore
git commit -m "Add training images dataset"

김개발 씨는 프로젝트 폴더를 열어보았습니다. data/train_images 폴더 안에는 10만 장이 넘는 이미지 파일이 들어있었습니다.

용량만 해도 5기가바이트가 넘었습니다. "이걸 전부 Git에 올리면 큰일나겠죠?" 김개발 씨가 물었습니다.

박시니어 씨는 고개를 끄덕였습니다. "맞아요.

대신 dvc add를 써보세요." dvc add란 정확히 무엇일까요? 쉽게 비유하자면, dvc add는 마치 물품 보관소에 짐을 맡기는 것과 같습니다.

귀중품을 맡기면 보관소에서는 물건을 안전하게 보관하고, 대신 작은 보관증을 발급해줍니다. 나중에 이 보관증만 있으면 언제든 물건을 찾을 수 있습니다.

DVC에서 .dvc 파일이 바로 이 보관증 역할을 합니다. dvc add를 실행하면 어떤 일이 일어날까요?

첫째, 원본 파일의 내용을 해시값으로 계산합니다. 이 해시값은 파일의 고유한 지문과 같습니다.

파일 내용이 조금이라도 바뀌면 해시값도 달라집니다. 둘째, 원본 파일을 .dvc/cache 폴더로 복사합니다.

셋째, 해시값과 파일 정보를 담은 .dvc 파일을 생성합니다. 여기서 중요한 포인트가 있습니다.

DVC는 자동으로 .gitignore 파일을 수정해서 원본 데이터 파일이 Git에 올라가지 않도록 막습니다. 덕분에 실수로 대용량 파일을 커밋하는 일을 방지할 수 있습니다.

대신 작은 .dvc 파일만 Git에 커밋하면 됩니다. 위의 코드를 자세히 살펴보겠습니다.

dvc add data/train_images/ 명령을 실행하면 train_images 폴더 전체가 DVC의 추적 대상이 됩니다. 그러면 data/train_images.dvc라는 파일이 생성됩니다.

이 파일을 열어보면 md5 해시값, 파일 크기, 경로 정보가 들어있습니다. 이 작은 텍스트 파일만 Git에 커밋하면 됩니다.

실제 현업에서는 어떻게 활용할까요? 자연어 처리 프로젝트를 진행한다고 가정해봅시다.

수집한 텍스트 코퍼스가 수 기가바이트에 달합니다. 전처리를 거칠 때마다 데이터가 조금씩 변합니다.

dvc add로 각 단계의 데이터를 추적하면, 나중에 어떤 버전의 데이터로 학습했는지 정확히 알 수 있습니다. 주의할 점도 있습니다.

한 번 dvc add로 추적을 시작한 파일은 직접 수정하면 안 됩니다. 파일을 수정하고 싶다면, 먼저 dvc unprotect로 파일을 수정 가능한 상태로 만들어야 합니다.

또한 .dvc 파일을 수동으로 편집하는 것도 피해야 합니다. 박시니어 씨의 설명을 들은 김개발 씨는 바로 실행에 옮겼습니다.

dvc add를 실행하자 .dvc 파일이 생성되었습니다. "생각보다 간단하네요!" 김개발 씨가 감탄했습니다.

실전 팁

💡 - 폴더 전체를 추적할 때는 경로 끝에 슬래시를 붙여도 되고 안 붙여도 됩니다

.dvc 파일은 반드시 Git에 커밋해야 버전 관리가 됩니다

3. 원격 저장소 설정

김개발 씨는 혼자서는 잘 사용하고 있었지만, 팀원들과 데이터를 공유하는 방법이 궁금했습니다. "저만 이 데이터를 쓸 수 있으면 협업이 안 되잖아요?" 박시니어 씨가 말했습니다.

"DVC에도 원격 저장소 개념이 있어요. Git의 GitHub처럼요."

DVC Remote는 데이터 파일을 저장하는 원격 저장소입니다. AWS S3, Google Cloud Storage, Azure Blob 같은 클라우드 스토리지나, SSH로 접근 가능한 서버, 심지어 로컬 디렉토리도 사용할 수 있습니다.

팀원들은 이 원격 저장소를 통해 대용량 데이터를 공유합니다.

다음 코드를 살펴봅시다.

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

# 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

# 설정 파일 확인
cat .dvc/config
# [core]
#     remote = myremote
# ['remote "myremote"']
#     url = s3://my-bucket/dvc-storage

# Git에 설정 커밋
git add .dvc/config
git commit -m "Configure DVC remote storage"

김개발 씨의 팀에는 세 명의 개발자가 있었습니다. 각자 자신의 컴퓨터에서 작업하고 있었는데, 데이터를 공유하는 것이 가장 큰 골칫거리였습니다.

"예전에는 어떻게 했어요?" 김개발 씨가 물었습니다. 박시니어 씨가 한숨을 쉬었습니다.

"USB로 주고받거나, 구글 드라이브에 올려놓고 링크 공유하거나... 정말 비효율적이었죠." DVC Remote란 정확히 무엇일까요?

쉽게 비유하자면, DVC Remote는 마치 회사의 공용 창고와 같습니다. 각 직원이 개인 사물함만 쓰면 물건을 공유할 수 없지만, 공용 창고가 있으면 누구나 물건을 보관하고 가져갈 수 있습니다.

DVC Remote도 마찬가지로, 팀 전체가 접근할 수 있는 중앙 데이터 저장소 역할을 합니다. DVC는 다양한 종류의 원격 저장소를 지원합니다.

가장 많이 사용하는 것은 AWS S3입니다. 저렴하고 안정적이며, 용량 제한이 없습니다.

Google Cloud를 사용하는 팀이라면 GCS를 선택할 수 있습니다. Azure를 사용한다면 Azure Blob Storage도 가능합니다.

심지어 SSH로 접근 가능한 일반 서버도 원격 저장소로 설정할 수 있습니다. 위의 코드를 자세히 살펴보겠습니다.

dvc remote add 명령에서 -d 옵션은 default의 약자입니다. 이 저장소를 기본 원격 저장소로 설정한다는 의미입니다.

myremote는 이 원격 저장소의 이름입니다. 원하는 대로 지을 수 있습니다.

그 뒤에 오는 URL이 실제 저장소의 위치입니다. 설정이 완료되면 .dvc/config 파일에 정보가 저장됩니다.

이 설정 파일도 Git에 커밋해야 합니다. 그래야 팀원들이 저장소를 클론받았을 때 같은 원격 저장소 설정을 사용할 수 있습니다.

물론 인증 정보는 각자 별도로 설정해야 합니다. 실제 현업에서는 어떻게 활용할까요?

대부분의 회사에서는 이미 클라우드 인프라를 사용하고 있습니다. AWS를 쓰는 회사라면 S3 버킷을 하나 만들어서 DVC 전용으로 사용합니다.

비용도 저렴하고, IAM으로 접근 권한을 세밀하게 관리할 수 있습니다. 주의할 점도 있습니다.

원격 저장소의 접근 권한 설정을 신중하게 해야 합니다. 민감한 데이터가 포함되어 있다면 팀원 외에는 접근하지 못하도록 해야 합니다.

또한 저장소 비용도 고려해야 합니다. 데이터가 쌓일수록 저장 비용이 증가합니다.

김개발 씨는 팀의 AWS 계정에 S3 버킷을 생성하고 DVC Remote로 설정했습니다. "이제 팀원들과 데이터를 쉽게 공유할 수 있겠네요!"

실전 팁

💡 - 테스트할 때는 로컬 디렉토리를 원격 저장소로 설정하면 편리합니다

클라우드 저장소 사용 시 비용을 주기적으로 모니터링하세요

4. 데이터 푸시와 풀

원격 저장소를 설정한 김개발 씨는 이제 데이터를 업로드하고 싶었습니다. Git에서 push와 pull을 하듯이, DVC에서도 비슷한 명령어가 있을 것 같았습니다.

박시니어 씨가 말했습니다. "맞아요, dvc push와 dvc pull이 있어요."

dvc push는 로컬 캐시에 있는 데이터를 원격 저장소로 업로드합니다. dvc pull은 반대로 원격 저장소에서 데이터를 다운로드합니다.

Git의 push/pull과 개념이 동일하지만, 데이터 파일을 대상으로 한다는 점이 다릅니다.

다음 코드를 살펴봅시다.

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

# 특정 파일만 푸시
dvc push data/train_images.dvc

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

# 특정 파일만 풀
dvc pull data/train_images.dvc

# 다른 팀원이 저장소를 클론받은 후
git clone https://github.com/team/ml-project.git
cd ml-project
dvc pull  # 데이터 다운로드

# 업로드/다운로드 상태 확인
dvc status --cloud

김개발 씨는 열심히 데이터를 정제하고 dvc add로 추적을 시작했습니다. 이제 이 데이터를 팀원들과 공유할 차례입니다.

"Git push처럼 하면 되나요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 끄덕였습니다.

"거의 같아요. 대신 dvc push를 사용하면 돼요." dvc push와 dvc pull은 정확히 무엇일까요?

쉽게 비유하자면, push는 택배를 보내는 것이고 pull은 택배를 받는 것입니다. 내가 정성껏 포장한 물건을 택배로 보내면, 상대방은 그 택배를 받아볼 수 있습니다.

DVC에서도 마찬가지로, push로 데이터를 보내고 pull로 데이터를 받습니다. 일반적인 협업 흐름을 살펴봅시다.

먼저 개발자 A가 데이터를 준비하고 dvc add로 추적합니다. 그 다음 dvc push로 원격 저장소에 업로드합니다.

동시에 .dvc 파일을 Git에 커밋하고 푸시합니다. 이제 개발자 B가 저장소를 클론받습니다.

git clone만 하면 코드와 .dvc 파일만 받아집니다. 실제 데이터는 dvc pull을 실행해야 받을 수 있습니다.

위의 코드를 자세히 살펴보겠습니다. dvc push 명령은 매우 단순합니다.

별다른 옵션 없이 실행하면 모든 추적 중인 데이터를 업로드합니다. 특정 파일만 업로드하고 싶다면 .dvc 파일 경로를 지정하면 됩니다.

dvc pull도 마찬가지 방식으로 동작합니다. dvc status --cloud 명령은 유용한 확인 도구입니다.

이 명령을 실행하면 로컬과 원격 저장소 간의 동기화 상태를 확인할 수 있습니다. 아직 업로드하지 않은 파일이 있는지, 다운로드받아야 할 파일이 있는지 한눈에 알 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 신입 개발자가 팀에 합류했다고 가정해봅시다.

예전에는 데이터를 받기 위해 며칠을 기다려야 했습니다. 누군가 외장하드를 복사해주거나, 클라우드에서 수동으로 다운로드해야 했으니까요.

DVC를 사용하면 git clone과 dvc pull 두 명령만으로 모든 코드와 데이터를 받을 수 있습니다. 주의할 점도 있습니다.

dvc push를 하기 전에 반드시 .dvc 파일을 Git에 커밋해야 합니다. 그래야 다른 팀원이 해당 버전의 데이터를 pull할 수 있습니다.

순서가 중요합니다. dvc add, git add, git commit, git push, dvc push 순서로 진행하세요.

김개발 씨는 dvc push를 실행했습니다. 프로그레스 바가 올라가면서 데이터가 S3에 업로드되었습니다.

팀원 이주니어 씨가 dvc pull을 실행하자 데이터가 바로 다운로드되었습니다. "와, 정말 편하네요!"

실전 팁

💡 - push 전에 반드시 .dvc 파일을 Git에 커밋하세요

네트워크 상태가 좋지 않으면 dvc push -j 옵션으로 병렬 업로드 수를 조절할 수 있습니다

5. 데이터 버전 전환

어느 날 김개발 씨에게 급한 요청이 들어왔습니다. "지난달에 학습시킨 모델로 다시 테스트해봐야 해요.

그때 데이터도 필요해요." Git에서 이전 커밋으로 체크아웃하는 것처럼, DVC에서도 이전 버전의 데이터로 돌아갈 수 있을까요?

dvc checkout은 Git의 체크아웃과 연동되어 해당 버전의 데이터 파일을 작업 디렉토리에 복원합니다. Git에서 특정 커밋으로 이동하면, dvc checkout을 통해 그 시점의 데이터도 함께 복원할 수 있습니다.

이것이 DVC의 가장 강력한 기능 중 하나입니다.

다음 코드를 살펴봅시다.

# 현재 상태 확인
git log --oneline
# abc1234 Update dataset v2
# def5678 Initial dataset v1

# 이전 버전으로 이동
git checkout def5678

# 해당 버전의 데이터로 복원
dvc checkout

# 또는 한 번에 실행
git checkout def5678
dvc checkout

# 작업 후 다시 최신 버전으로
git checkout main
dvc checkout

# 특정 파일만 이전 버전으로
git checkout def5678 -- data/train_images.dvc
dvc checkout data/train_images.dvc

김개발 씨는 난감했습니다. 지난달의 모델과 데이터가 필요한데, 그동안 데이터가 여러 번 업데이트되었기 때문입니다.

"예전 같았으면 불가능했을 거예요." 박시니어 씨가 말했습니다. "하지만 DVC를 쓰고 있으니까 걱정 없어요." dvc checkout이란 정확히 무엇일까요?

쉽게 비유하자면, dvc checkout은 마치 타임머신과 같습니다. Git이 코드의 타임머신이라면, DVC는 데이터의 타임머신입니다.

특정 시점으로 돌아가면 그때의 코드뿐만 아니라 그때의 데이터까지 함께 복원됩니다. 실험의 완벽한 재현이 가능해지는 것입니다.

작동 원리를 살펴봅시다. Git 커밋에는 .dvc 파일이 포함되어 있습니다.

이 .dvc 파일에는 해당 시점 데이터의 해시값이 기록되어 있습니다. git checkout으로 이전 커밋으로 이동하면 .dvc 파일도 그때 버전으로 바뀝니다.

이 상태에서 dvc checkout을 실행하면 DVC가 해시값을 읽어서 캐시에서 해당 데이터를 복원합니다. 위의 코드를 자세히 살펴보겠습니다.

먼저 git log로 커밋 히스토리를 확인합니다. 돌아가고 싶은 커밋을 찾아서 git checkout을 실행합니다.

이 시점에서는 코드만 이전 버전이고, 데이터는 아직 현재 버전입니다. dvc checkout을 실행하면 데이터도 이전 버전으로 바뀝니다.

만약 캐시에 해당 버전의 데이터가 없다면 어떻게 될까요? 그런 경우에는 dvc pull을 먼저 실행해야 합니다.

원격 저장소에서 해당 버전의 데이터를 다운로드받은 후에 dvc checkout이 정상적으로 동작합니다. 실제 현업에서는 어떻게 활용할까요?

머신러닝 실험에서 모델 성능이 갑자기 떨어졌다고 가정해봅시다. 원인을 찾기 위해 이전에 잘 동작하던 버전으로 돌아가야 합니다.

DVC 덕분에 코드와 데이터를 모두 그 시점으로 복원할 수 있습니다. A/B 테스트를 위해 다른 버전의 모델을 비교할 때도 유용합니다.

주의할 점도 있습니다. dvc checkout은 로컬 캐시에 데이터가 있어야 동작합니다.

원격 저장소에만 있는 경우에는 먼저 dvc pull을 해야 합니다. 또한 현재 작업 중인 변경사항이 있다면 먼저 커밋하거나 스태시해두는 것이 좋습니다.

김개발 씨는 git checkout으로 지난달 커밋으로 이동한 후 dvc checkout을 실행했습니다. 순식간에 그때의 데이터가 복원되었습니다.

"마치 타임머신 같아요!" 김개발 씨가 감탄했습니다.

실전 팁

💡 - git checkout과 dvc checkout은 항상 쌍으로 실행하세요

캐시에 데이터가 없으면 dvc pull을 먼저 실행해야 합니다

6. DVC 파이프라인 구축

김개발 씨의 프로젝트가 점점 복잡해졌습니다. 데이터 전처리, 피처 추출, 모델 학습, 평가까지 여러 단계를 거쳐야 했습니다.

매번 수동으로 각 단계를 실행하는 것이 번거로웠습니다. 박시니어 씨가 말했습니다.

"DVC 파이프라인을 써보세요. 전체 워크플로우를 자동화할 수 있어요."

DVC Pipeline은 데이터 처리 워크플로우를 정의하고 자동화하는 기능입니다. dvc.yaml 파일에 각 단계의 의존성과 출력을 정의하면, DVC가 변경된 부분만 자동으로 재실행합니다.

마치 Makefile처럼 의존성 기반으로 동작하지만, 데이터 과학에 특화되어 있습니다.

다음 코드를 살펴봅시다.

# dvc.yaml 파일 생성
stages:
  preprocess:
    cmd: python src/preprocess.py
    deps:
      - src/preprocess.py
      - data/raw/
    outs:
      - data/processed/

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

  evaluate:
    cmd: python src/evaluate.py
    deps:
      - src/evaluate.py
      - models/model.pkl
    metrics:
      - evaluation.json:
          cache: false

# 파이프라인 실행
dvc repro

# 특정 단계만 실행
dvc repro train

김개발 씨는 매일 같은 작업을 반복하고 있었습니다. 먼저 전처리 스크립트를 실행하고, 그 다음 학습 스크립트를 실행하고, 마지막으로 평가 스크립트를 실행합니다.

실수로 순서를 빼먹거나, 이미 실행한 단계를 다시 실행하는 일도 잦았습니다. "이거 자동화할 수 없나요?" 김개발 씨가 한숨을 쉬며 물었습니다.

박시니어 씨가 눈을 빛냈습니다. "DVC 파이프라인이 딱이에요." DVC Pipeline이란 정확히 무엇일까요?

쉽게 비유하자면, 파이프라인은 마치 공장의 조립 라인과 같습니다. 자동차 공장에서는 부품이 순서대로 조립되어 완성차가 됩니다.

엔진이 장착되어야 변속기를 연결할 수 있고, 차체가 완성되어야 도색을 할 수 있습니다. DVC 파이프라인도 마찬가지로, 각 단계의 의존성을 정의하고 순서대로 실행합니다.

파이프라인의 핵심 개념을 알아봅시다. 첫째, **deps(dependencies)**는 해당 단계가 의존하는 파일들입니다.

이 파일들이 변경되면 해당 단계를 다시 실행해야 합니다. 둘째, **outs(outputs)**는 해당 단계에서 생성되는 파일들입니다.

이 파일들은 자동으로 DVC 추적 대상이 됩니다. 셋째, cmd는 실행할 명령어입니다.

위의 코드를 자세히 살펴보겠습니다. dvc.yaml 파일에는 세 개의 단계가 정의되어 있습니다.

preprocess 단계는 원본 데이터를 전처리하여 processed 폴더에 저장합니다. train 단계는 전처리된 데이터를 사용하여 모델을 학습시킵니다.

evaluate 단계는 학습된 모델을 평가합니다. dvc repro는 정말 똑똑합니다.

이 명령을 실행하면 DVC가 의존성 그래프를 분석합니다. 변경된 파일이 있는 단계만 재실행합니다.

예를 들어 train.py만 수정했다면 preprocess는 건너뛰고 train과 evaluate만 실행합니다. 이렇게 하면 시간과 컴퓨팅 리소스를 절약할 수 있습니다.

metrics는 특별한 출력입니다. 모델의 성능 지표를 기록하는 JSON 파일을 metrics로 지정하면, dvc metrics show 명령으로 쉽게 확인할 수 있습니다.

여러 실험의 성능을 비교하는 데 유용합니다. 실제 현업에서는 어떻게 활용할까요?

추천 시스템 프로젝트를 예로 들어봅시다. 사용자 로그 수집, 데이터 정제, 피처 엔지니어링, 모델 학습, 오프라인 평가, 온라인 배포까지 여러 단계가 있습니다.

각 단계를 파이프라인으로 정의해두면, 새로운 데이터가 들어올 때마다 dvc repro 한 번으로 전체 과정을 자동화할 수 있습니다. 김개발 씨는 dvc.yaml 파일을 작성하고 dvc repro를 실행했습니다.

모든 단계가 순서대로 자동 실행되었습니다. "이제 실수할 일이 없겠네요!" 김개발 씨가 기뻐했습니다.

실전 팁

💡 - 파이프라인 의존성은 최대한 구체적으로 지정하세요

metrics는 cache: false로 설정하면 Git에서 직접 확인할 수 있습니다

7. 실험 추적과 비교

김개발 씨는 여러 가지 하이퍼파라미터로 실험을 진행하고 있었습니다. 학습률 0.01, 0.001, 0.0001로 각각 실험했는데, 어떤 설정이 가장 좋았는지 헷갈리기 시작했습니다.

"실험 결과를 체계적으로 비교할 방법이 없을까요?" 박시니어 씨가 dvc exp를 소개해주었습니다.

DVC Experiments는 머신러닝 실험을 체계적으로 추적하고 비교하는 기능입니다. 각 실험의 파라미터, 메트릭, 결과물을 자동으로 기록하고, 여러 실험을 테이블 형태로 비교할 수 있습니다.

Git 브랜치를 만들지 않고도 수십, 수백 개의 실험을 관리할 수 있습니다.

다음 코드를 살펴봅시다.

# params.yaml 파일 생성
train:
  learning_rate: 0.001
  epochs: 100
  batch_size: 32

# 기본 실험 실행
dvc exp run

# 파라미터를 변경하면서 실험
dvc exp run -S train.learning_rate=0.01
dvc exp run -S train.learning_rate=0.0001
dvc exp run -S train.epochs=200

# 실험 결과 비교
dvc exp show
# ┏━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━━━┓
# ┃ Experiment    ┃ accuracy┃ learning_rate  ┃
# ┡━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━━━━┩
# │ exp-abc12     │ 0.92    │ 0.001          │
# │ exp-def34     │ 0.89    │ 0.01           │
# │ exp-ghi56     │ 0.94    │ 0.0001         │
# └───────────────┴─────────┴────────────────┘

# 최고 성능 실험을 브랜치로 저장
dvc exp branch exp-ghi56 best-model

김개발 씨는 노트에 실험 결과를 적고 있었습니다. "학습률 0.01, 정확도 89%...

아, 이거 아까 기록한 건가?" 기록이 점점 엉망이 되어가고 있었습니다. "엑셀로 정리해볼까 했는데, 너무 번거로워요." 김개발 씨가 투덜거렸습니다.

박시니어 씨가 말했습니다. "DVC Experiments를 쓰면 자동으로 정리해줘요." DVC Experiments란 정확히 무엇일까요?

쉽게 비유하자면, 실험 노트를 자동으로 작성해주는 비서와 같습니다. 과학자가 실험할 때마다 비서가 실험 조건, 결과, 시간을 꼼꼼히 기록해줍니다.

나중에 "가장 성능이 좋았던 실험이 뭐였지?"라고 물으면 바로 찾아줍니다. DVC Experiments가 바로 그런 역할을 합니다.

params.yaml 파일이 핵심입니다. 이 파일에 실험의 하이퍼파라미터를 정의합니다.

학습률, 에포크 수, 배치 크기 같은 값들을 여기에 적어둡니다. 파이프라인의 스크립트에서 이 파일을 읽어서 사용하면, DVC가 자동으로 파라미터 변화를 추적합니다.

위의 코드를 자세히 살펴보겠습니다. dvc exp run은 파이프라인을 실행하면서 실험을 기록합니다.

-S 옵션을 사용하면 params.yaml의 값을 임시로 변경해서 실험할 수 있습니다. 파일을 직접 수정할 필요가 없어서 편리합니다.

여러 번 실행하면 각각 별도의 실험으로 기록됩니다. dvc exp show는 강력한 비교 도구입니다.

모든 실험을 테이블 형태로 보여줍니다. 파라미터 값과 메트릭을 한눈에 비교할 수 있습니다.

어떤 설정이 가장 좋은 성능을 냈는지 쉽게 파악할 수 있습니다. 마음에 드는 실험을 찾았다면 어떻게 할까요?

dvc exp branch 명령으로 해당 실험을 Git 브랜치로 저장할 수 있습니다. 그러면 해당 실험의 코드, 파라미터, 데이터가 모두 보존됩니다.

나중에 프로덕션에 배포하거나 추가 실험을 진행할 때 사용할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

딥러닝 모델 튜닝을 예로 들어봅시다. 학습률, 옵티마이저, 네트워크 구조 등 수십 가지 조합을 실험해야 합니다.

DVC Experiments를 사용하면 각 실험을 체계적으로 기록하고, 최적의 조합을 쉽게 찾을 수 있습니다. 논문 작성이나 결과 보고 시에도 실험 기록이 명확해서 재현성을 보장할 수 있습니다.

김개발 씨는 dvc exp show로 실험 결과를 확인했습니다. 학습률 0.0001일 때 가장 좋은 성능을 보였습니다.

"이제 어떤 실험이 최고였는지 바로 알 수 있네요!"

실전 팁

💡 - params.yaml에는 자주 바꾸는 하이퍼파라미터만 넣으세요

dvc exp show --sort-by 옵션으로 특정 메트릭 기준으로 정렬할 수 있습니다

8. Git 연동 워크플로우

김개발 씨는 이제 DVC의 기본 기능을 익혔습니다. 하지만 실제 협업에서 Git과 DVC를 어떻게 함께 사용해야 하는지 아직 감이 잡히지 않았습니다.

"브랜치 작업하면서 데이터도 관리해야 하는데, 어떤 순서로 해야 하죠?" 박시니어 씨가 실무 워크플로우를 알려주었습니다.

DVC는 Git과 함께 사용하도록 설계되었습니다. 코드 변경은 Git으로, 데이터 변경은 DVC로 관리하되, 두 시스템이 동기화되어야 합니다.

브랜치 생성, 머지, 태그 등 Git의 모든 기능과 DVC를 조화롭게 사용하는 방법을 알아야 실무에서 원활한 협업이 가능합니다.

다음 코드를 살펴봅시다.

# 새로운 피처 브랜치에서 작업 시작
git checkout -b feature/new-dataset
dvc checkout

# 데이터 작업 후 추적
dvc add data/new_dataset.csv
git add data/new_dataset.csv.dvc data/.gitignore

# 코드와 데이터 변경 커밋
git commit -m "Add new dataset for feature X"

# 원격 저장소에 푸시
git push -u origin feature/new-dataset
dvc push

# 코드 리뷰 후 머지
git checkout main
git merge feature/new-dataset
dvc checkout
dvc pull  # 다른 팀원의 데이터 변경 사항 받기

# 릴리스 태그 생성
git tag -a v1.0 -m "Release version 1.0"
git push origin v1.0
dvc push  # 해당 버전의 데이터도 함께 보존

김개발 씨는 새로운 기능을 개발하기 위해 브랜치를 만들었습니다. 그런데 브랜치를 전환할 때마다 데이터가 꼬이는 문제가 발생했습니다.

"main 브랜치에는 옛날 데이터가 있어야 하는데, 새 데이터가 그대로 남아있어요." 김개발 씨가 당황했습니다. 박시니어 씨가 설명했습니다.

"Git만 체크아웃하면 그래요. DVC도 함께 체크아웃해야 해요." Git과 DVC의 관계를 이해해봅시다.

쉽게 비유하자면, Git은 도서관의 목록 카드이고 DVC는 실제 책을 보관하는 서고입니다. 목록 카드를 보면 어떤 책이 어디에 있는지 알 수 있습니다.

하지만 카드만 바꾸면 책이 저절로 바뀌지는 않습니다. 서고에서 직접 책을 가져와야 합니다.

마찬가지로 git checkout만 하면 .dvc 파일만 바뀌고, 실제 데이터는 dvc checkout을 해야 바뀝니다. 실무 워크플로우의 핵심을 알아봅시다.

첫째, 브랜치 전환 시 항상 dvc checkout을 실행합니다. 이것을 습관화해야 합니다.

둘째, 커밋 전에 dvc add로 데이터 변경을 추적합니다. 셋째, 푸시는 git과 dvc 둘 다 해야 합니다.

넷째, 풀도 git과 dvc 둘 다 해야 합니다. 위의 코드를 자세히 살펴보겠습니다.

새 브랜치를 만들 때 git checkout -b로 브랜치를 생성하고 바로 dvc checkout을 실행합니다. 작업이 끝나면 dvc add, git add, git commit 순서로 진행합니다.

원격 저장소에는 git push와 dvc push를 둘 다 실행합니다. 태그를 활용하면 릴리스 관리가 편해집니다.

중요한 버전에 태그를 붙여두면 나중에 해당 버전으로 쉽게 돌아갈 수 있습니다. git tag로 태그를 만들고, 해당 시점의 데이터도 dvc push로 원격에 보관해둡니다.

프로덕션에 문제가 생겼을 때 특정 버전으로 롤백하기가 수월해집니다. 실제 현업에서는 어떻게 활용할까요?

여러 명이 동시에 다른 피처를 개발한다고 가정해봅시다. 각자 브랜치에서 작업하면서 데이터도 함께 변경합니다.

main에 머지할 때 코드 충돌처럼 데이터 충돌도 발생할 수 있습니다. 이런 경우 .dvc 파일을 기준으로 어떤 버전을 사용할지 결정하고, dvc checkout으로 해당 데이터를 가져옵니다.

주의할 점도 있습니다. git pull만 하고 dvc pull을 잊으면 데이터가 맞지 않는 상황이 발생합니다.

팀 전체가 이 워크플로우를 숙지하고 있어야 혼란을 피할 수 있습니다. Git hooks를 설정해서 checkout 후 자동으로 dvc checkout이 실행되도록 하는 것도 좋은 방법입니다.

김개발 씨는 워크플로우를 정리해서 팀 위키에 올렸습니다. "이제 팀 전체가 같은 방식으로 작업할 수 있겠네요!" 협업이 한결 수월해졌습니다.

실전 팁

💡 - post-checkout Git hook을 설정하면 자동으로 dvc checkout이 실행됩니다

머지 충돌 시 .dvc 파일은 원하는 버전을 선택한 후 dvc checkout하세요

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

#DVC#DataVersionControl#MLOps#DataPipeline#ModelManagement#Data Science

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

# DVC로 데이터 버전 관리 완벽 가이드 머신러닝 프로젝트에서 데이터와 모델 파일의 버전을 체계적으로 관리하는 DVC(Data Version Control)의 핵심 개념과 실무 활용법을 알아봅니다. Git으로는 관리하기 어려운 대용량 데이터 파일을 효율적으로 추적하고 협업하는 방법을 배웁니다. --- ## 목차 1. [DVC_초기화와_기본_개념](#dvc-초기화와-기본-개념) 2. [데이터_파일_추적하기](#데이터-파일-추적하기) 3. [원격_저장소_설정](#원격-저장소-설정) 4. [데이터_푸시와_풀](#데이터-푸시와-풀) 5. [데이터_버전_전환](#데이터-버전-전환) 6. [DVC_파이프라인_구축](#dvc-파이프라인-구축) 7. [실험_추적과_비교](#실험-추적과-비교) 8. [Git_연동_워크플로우](#git-연동-워크플로우) --- ## 1. DVC_초기화와_기본_개념 김개발 씨는 입사 후 첫 머신러닝 프로젝트에 투입되었습니다. 열심히 모델을 학습시키던 어느 날, 선배가 물었습니다. "지난주에 학습시킨 모델이랑 데이터셋 어디 있어요? 그때 성능이 더 좋았는데." 김개발 씨는 당황했습니다. 데이터 파일을 덮어쓰기 해버렸기 때문입니다. **DVC(Data Version Control)**는 한마디로 대용량 데이터 파일을 위한 Git입니다. 마치 도서관에서 책의 모든 개정판을 보관하듯이, DVC는 데이터셋과 모델 파일의 모든 버전을 체계적으로 관리합니다. Git이 코드의 역사를 기록한다면, DVC는 데이터의 역사를 기록하는 것입니다. 다음 코드를 살펴봅시다. ```python # DVC 설치 및 초기화 pip install dvc # Git 저장소에서 DVC 초기화 cd my-ml-project dvc init # 초기화 후 생성되는 파일 확인 ls -la .dvc/ # .dvc/config - DVC 설정 파일 # .dvc/cache - 데이터 캐시 디렉토리 # Git에 DVC 설정 파일 커밋 git add .dvc .dvcignore git commit -m "Initialize DVC" ``` 김개발 씨는 입사 3개월 차 머신러닝 엔지니어입니다. 요즘 한창 이미지 분류 모델을 개발하고 있는데, 데이터셋만 해도 수십 기가바이트에 달합니다. 문제는 실험을 반복할 때마다 데이터가 조금씩 바뀐다는 것이었습니다. "이 데이터셋 Git에 올려도 되나요?" 김개발 씨가 선배 박시니어 씨에게 물었습니다. 박시니어 씨는 고개를 저었습니다. "Git은 대용량 파일에 적합하지 않아요. 저장소가 엄청나게 커지고, 클론 받는 데만 한 세월이 걸릴 거예요." 그렇다면 **DVC**란 정확히 무엇일까요? 쉽게 비유하자면, DVC는 마치 창고 관리인과 같습니다. 여러분이 귀중한 물건을 맡기면, 관리인은 그 물건에 고유한 번호표를 붙여서 창고에 보관합니다. 나중에 번호표만 있으면 언제든 그 물건을 찾아올 수 있습니다. DVC도 마찬가지로, 대용량 데이터 파일을 별도의 저장소에 보관하고, Git에는 그 파일을 찾을 수 있는 작은 메타데이터 파일만 저장합니다. DVC가 없던 시절에는 어땠을까요? 개발자들은 데이터 파일을 직접 관리해야 했습니다. data_v1.csv, data_v2_final.csv, data_v2_final_진짜최종.csv 같은 파일명이 난무했습니다. 어떤 데이터로 어떤 모델을 학습시켰는지 추적하기가 거의 불가능했습니다. 협업은 더 큰 문제였습니다. 팀원끼리 대용량 파일을 공유하려면 USB나 외장하드를 주고받거나, 클라우드에 수동으로 업로드해야 했습니다. 바로 이런 문제를 해결하기 위해 DVC가 등장했습니다. DVC를 사용하면 데이터 파일도 코드처럼 버전 관리가 가능해집니다. 특정 시점의 데이터셋으로 언제든 돌아갈 수 있습니다. 또한 팀원들과 데이터를 쉽게 공유할 수 있습니다. 무엇보다 실험의 **재현성**이 보장된다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 pip install dvc로 DVC를 설치합니다. 그 다음 프로젝트 디렉토리에서 dvc init 명령을 실행하면 .dvc 폴더가 생성됩니다. 이 폴더 안에는 DVC의 설정 파일과 캐시 디렉토리가 들어있습니다. 마지막으로 이 설정 파일들을 Git에 커밋하면 초기화가 완료됩니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 추천 시스템을 개발한다고 가정해봅시다. 사용자 로그 데이터가 매일 수집되고, 주기적으로 모델을 재학습시켜야 합니다. DVC를 활용하면 각 시점의 데이터와 모델을 정확히 기록해두고, 성능이 떨어졌을 때 이전 버전으로 쉽게 롤백할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 DVC 초기화 전에 이미 Git 저장소가 있어야 한다는 것을 잊는 것입니다. DVC는 Git 위에서 동작하는 도구이므로, 반드시 git init을 먼저 실행해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 바로 DVC를 도입하기로 했습니다. "이제 데이터 파일 잃어버릴 걱정은 없겠네요!" **실전 팁** 💡 - DVC는 반드시 Git 저장소 안에서 초기화해야 합니다 - .dvc 폴더와 .dvcignore 파일은 반드시 Git에 커밋하세요 --- ## 2. 데이터_파일_추적하기 DVC를 초기화한 김개발 씨는 이제 실제로 데이터 파일을 추적해보고 싶었습니다. 프로젝트 폴더에는 학습용 이미지 데이터셋이 잔뜩 들어있었습니다. "이 파일들을 어떻게 DVC에 등록하죠?" 박시니어 씨가 dvc add 명령어를 알려주었습니다. **dvc add** 명령은 데이터 파일을 DVC의 추적 대상으로 등록합니다. 이 명령을 실행하면 원본 파일은 캐시로 이동하고, 파일의 메타정보를 담은 .dvc 파일이 생성됩니다. 이 .dvc 파일은 크기가 매우 작아서 Git으로 관리하기에 적합합니다. 다음 코드를 살펴봅시다. ```python # 데이터 파일을 DVC로 추적 dvc add data/train_images/ dvc add models/model.pkl # 생성된 .dvc 파일 확인 cat data/train_images.dvc # outs: # - md5: a1b2c3d4e5f6... # size: 1073741824 # path: train_images # .gitignore에 자동으로 원본 파일이 추가됨 cat data/.gitignore # /train_images # .dvc 파일을 Git에 커밋 git add data/train_images.dvc data/.gitignore git commit -m "Add training images dataset" ``` 김개발 씨는 프로젝트 폴더를 열어보았습니다. data/train_images 폴더 안에는 10만 장이 넘는 이미지 파일이 들어있었습니다. 용량만 해도 5기가바이트가 넘었습니다. "이걸 전부 Git에 올리면 큰일나겠죠?" 김개발 씨가 물었습니다. 박시니어 씨는 고개를 끄덕였습니다. "맞아요. 대신 dvc add를 써보세요." **dvc add**란 정확히 무엇일까요? 쉽게 비유하자면, dvc add는 마치 물품 보관소에 짐을 맡기는 것과 같습니다. 귀중품을 맡기면 보관소에서는 물건을 안전하게 보관하고, 대신 작은 보관증을 발급해줍니다. 나중에 이 보관증만 있으면 언제든 물건을 찾을 수 있습니다. DVC에서 .dvc 파일이 바로 이 보관증 역할을 합니다. dvc add를 실행하면 어떤 일이 일어날까요? 첫째, 원본 파일의 내용을 해시값으로 계산합니다. 이 해시값은 파일의 고유한 지문과 같습니다. 파일 내용이 조금이라도 바뀌면 해시값도 달라집니다. 둘째, 원본 파일을 .dvc/cache 폴더로 복사합니다. 셋째, 해시값과 파일 정보를 담은 .dvc 파일을 생성합니다. 여기서 중요한 포인트가 있습니다. DVC는 자동으로 .gitignore 파일을 수정해서 원본 데이터 파일이 Git에 올라가지 않도록 막습니다. 덕분에 실수로 대용량 파일을 커밋하는 일을 방지할 수 있습니다. 대신 작은 .dvc 파일만 Git에 커밋하면 됩니다. 위의 코드를 자세히 살펴보겠습니다. dvc add data/train_images/ 명령을 실행하면 train_images 폴더 전체가 DVC의 추적 대상이 됩니다. 그러면 data/train_images.dvc라는 파일이 생성됩니다. 이 파일을 열어보면 md5 해시값, 파일 크기, 경로 정보가 들어있습니다. 이 작은 텍스트 파일만 Git에 커밋하면 됩니다. 실제 현업에서는 어떻게 활용할까요? 자연어 처리 프로젝트를 진행한다고 가정해봅시다. 수집한 텍스트 코퍼스가 수 기가바이트에 달합니다. 전처리를 거칠 때마다 데이터가 조금씩 변합니다. dvc add로 각 단계의 데이터를 추적하면, 나중에 어떤 버전의 데이터로 학습했는지 정확히 알 수 있습니다. 주의할 점도 있습니다. 한 번 dvc add로 추적을 시작한 파일은 직접 수정하면 안 됩니다. 파일을 수정하고 싶다면, 먼저 dvc unprotect로 파일을 수정 가능한 상태로 만들어야 합니다. 또한 .dvc 파일을 수동으로 편집하는 것도 피해야 합니다. 박시니어 씨의 설명을 들은 김개발 씨는 바로 실행에 옮겼습니다. dvc add를 실행하자 .dvc 파일이 생성되었습니다. "생각보다 간단하네요!" 김개발 씨가 감탄했습니다. **실전 팁** 💡 - 폴더 전체를 추적할 때는 경로 끝에 슬래시를 붙여도 되고 안 붙여도 됩니다 - .dvc 파일은 반드시 Git에 커밋해야 버전 관리가 됩니다 --- ## 3. 원격_저장소_설정 김개발 씨는 혼자서는 잘 사용하고 있었지만, 팀원들과 데이터를 공유하는 방법이 궁금했습니다. "저만 이 데이터를 쓸 수 있으면 협업이 안 되잖아요?" 박시니어 씨가 말했습니다. "DVC에도 원격 저장소 개념이 있어요. Git의 GitHub처럼요." **DVC Remote**는 데이터 파일을 저장하는 원격 저장소입니다. AWS S3, Google Cloud Storage, Azure Blob 같은 클라우드 스토리지나, SSH로 접근 가능한 서버, 심지어 로컬 디렉토리도 사용할 수 있습니다. 팀원들은 이 원격 저장소를 통해 대용량 데이터를 공유합니다. 다음 코드를 살펴봅시다. ```python # AWS S3를 원격 저장소로 설정 dvc remote add -d myremote s3://my-bucket/dvc-storage # 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 # 설정 파일 확인 cat .dvc/config # [core] # remote = myremote # ['remote "myremote"'] # url = s3://my-bucket/dvc-storage # Git에 설정 커밋 git add .dvc/config git commit -m "Configure DVC remote storage" ``` 김개발 씨의 팀에는 세 명의 개발자가 있었습니다. 각자 자신의 컴퓨터에서 작업하고 있었는데, 데이터를 공유하는 것이 가장 큰 골칫거리였습니다. "예전에는 어떻게 했어요?" 김개발 씨가 물었습니다. 박시니어 씨가 한숨을 쉬었습니다. "USB로 주고받거나, 구글 드라이브에 올려놓고 링크 공유하거나... 정말 비효율적이었죠." **DVC Remote**란 정확히 무엇일까요? 쉽게 비유하자면, DVC Remote는 마치 회사의 공용 창고와 같습니다. 각 직원이 개인 사물함만 쓰면 물건을 공유할 수 없지만, 공용 창고가 있으면 누구나 물건을 보관하고 가져갈 수 있습니다. DVC Remote도 마찬가지로, 팀 전체가 접근할 수 있는 중앙 데이터 저장소 역할을 합니다. DVC는 다양한 종류의 원격 저장소를 지원합니다. 가장 많이 사용하는 것은 **AWS S3**입니다. 저렴하고 안정적이며, 용량 제한이 없습니다. Google Cloud를 사용하는 팀이라면 **GCS**를 선택할 수 있습니다. Azure를 사용한다면 **Azure Blob Storage**도 가능합니다. 심지어 SSH로 접근 가능한 일반 서버도 원격 저장소로 설정할 수 있습니다. 위의 코드를 자세히 살펴보겠습니다. dvc remote add 명령에서 -d 옵션은 default의 약자입니다. 이 저장소를 기본 원격 저장소로 설정한다는 의미입니다. myremote는 이 원격 저장소의 이름입니다. 원하는 대로 지을 수 있습니다. 그 뒤에 오는 URL이 실제 저장소의 위치입니다. 설정이 완료되면 .dvc/config 파일에 정보가 저장됩니다. 이 설정 파일도 Git에 커밋해야 합니다. 그래야 팀원들이 저장소를 클론받았을 때 같은 원격 저장소 설정을 사용할 수 있습니다. 물론 인증 정보는 각자 별도로 설정해야 합니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 회사에서는 이미 클라우드 인프라를 사용하고 있습니다. AWS를 쓰는 회사라면 S3 버킷을 하나 만들어서 DVC 전용으로 사용합니다. 비용도 저렴하고, IAM으로 접근 권한을 세밀하게 관리할 수 있습니다. 주의할 점도 있습니다. 원격 저장소의 접근 권한 설정을 신중하게 해야 합니다. 민감한 데이터가 포함되어 있다면 팀원 외에는 접근하지 못하도록 해야 합니다. 또한 저장소 비용도 고려해야 합니다. 데이터가 쌓일수록 저장 비용이 증가합니다. 김개발 씨는 팀의 AWS 계정에 S3 버킷을 생성하고 DVC Remote로 설정했습니다. "이제 팀원들과 데이터를 쉽게 공유할 수 있겠네요!" **실전 팁** 💡 - 테스트할 때는 로컬 디렉토리를 원격 저장소로 설정하면 편리합니다 - 클라우드 저장소 사용 시 비용을 주기적으로 모니터링하세요 --- ## 4. 데이터_푸시와_풀 원격 저장소를 설정한 김개발 씨는 이제 데이터를 업로드하고 싶었습니다. Git에서 push와 pull을 하듯이, DVC에서도 비슷한 명령어가 있을 것 같았습니다. 박시니어 씨가 말했습니다. "맞아요, dvc push와 dvc pull이 있어요." **dvc push**는 로컬 캐시에 있는 데이터를 원격 저장소로 업로드합니다. **dvc pull**은 반대로 원격 저장소에서 데이터를 다운로드합니다. Git의 push/pull과 개념이 동일하지만, 데이터 파일을 대상으로 한다는 점이 다릅니다. 다음 코드를 살펴봅시다. ```python # 데이터를 원격 저장소로 업로드 dvc push # 특정 파일만 푸시 dvc push data/train_images.dvc # 원격 저장소에서 데이터 다운로드 dvc pull # 특정 파일만 풀 dvc pull data/train_images.dvc # 다른 팀원이 저장소를 클론받은 후 git clone https://github.com/team/ml-project.git cd ml-project dvc pull # 데이터 다운로드 # 업로드/다운로드 상태 확인 dvc status --cloud ``` 김개발 씨는 열심히 데이터를 정제하고 dvc add로 추적을 시작했습니다. 이제 이 데이터를 팀원들과 공유할 차례입니다. "Git push처럼 하면 되나요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 끄덕였습니다. "거의 같아요. 대신 dvc push를 사용하면 돼요." **dvc push**와 **dvc pull**은 정확히 무엇일까요? 쉽게 비유하자면, push는 택배를 보내는 것이고 pull은 택배를 받는 것입니다. 내가 정성껏 포장한 물건을 택배로 보내면, 상대방은 그 택배를 받아볼 수 있습니다. DVC에서도 마찬가지로, push로 데이터를 보내고 pull로 데이터를 받습니다. 일반적인 협업 흐름을 살펴봅시다. 먼저 개발자 A가 데이터를 준비하고 dvc add로 추적합니다. 그 다음 dvc push로 원격 저장소에 업로드합니다. 동시에 .dvc 파일을 Git에 커밋하고 푸시합니다. 이제 개발자 B가 저장소를 클론받습니다. git clone만 하면 코드와 .dvc 파일만 받아집니다. 실제 데이터는 dvc pull을 실행해야 받을 수 있습니다. 위의 코드를 자세히 살펴보겠습니다. dvc push 명령은 매우 단순합니다. 별다른 옵션 없이 실행하면 모든 추적 중인 데이터를 업로드합니다. 특정 파일만 업로드하고 싶다면 .dvc 파일 경로를 지정하면 됩니다. dvc pull도 마찬가지 방식으로 동작합니다. dvc status --cloud 명령은 유용한 확인 도구입니다. 이 명령을 실행하면 로컬과 원격 저장소 간의 동기화 상태를 확인할 수 있습니다. 아직 업로드하지 않은 파일이 있는지, 다운로드받아야 할 파일이 있는지 한눈에 알 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 신입 개발자가 팀에 합류했다고 가정해봅시다. 예전에는 데이터를 받기 위해 며칠을 기다려야 했습니다. 누군가 외장하드를 복사해주거나, 클라우드에서 수동으로 다운로드해야 했으니까요. DVC를 사용하면 git clone과 dvc pull 두 명령만으로 모든 코드와 데이터를 받을 수 있습니다. 주의할 점도 있습니다. dvc push를 하기 전에 반드시 .dvc 파일을 Git에 커밋해야 합니다. 그래야 다른 팀원이 해당 버전의 데이터를 pull할 수 있습니다. 순서가 중요합니다. dvc add, git add, git commit, git push, dvc push 순서로 진행하세요. 김개발 씨는 dvc push를 실행했습니다. 프로그레스 바가 올라가면서 데이터가 S3에 업로드되었습니다. 팀원 이주니어 씨가 dvc pull을 실행하자 데이터가 바로 다운로드되었습니다. "와, 정말 편하네요!" **실전 팁** 💡 - push 전에 반드시 .dvc 파일을 Git에 커밋하세요 - 네트워크 상태가 좋지 않으면 dvc push -j 옵션으로 병렬 업로드 수를 조절할 수 있습니다 --- ## 5. 데이터_버전_전환 어느 날 김개발 씨에게 급한 요청이 들어왔습니다. "지난달에 학습시킨 모델로 다시 테스트해봐야 해요. 그때 데이터도 필요해요." Git에서 이전 커밋으로 체크아웃하는 것처럼, DVC에서도 이전 버전의 데이터로 돌아갈 수 있을까요? **dvc checkout**은 Git의 체크아웃과 연동되어 해당 버전의 데이터 파일을 작업 디렉토리에 복원합니다. Git에서 특정 커밋으로 이동하면, dvc checkout을 통해 그 시점의 데이터도 함께 복원할 수 있습니다. 이것이 DVC의 가장 강력한 기능 중 하나입니다. 다음 코드를 살펴봅시다. ```python # 현재 상태 확인 git log --oneline # abc1234 Update dataset v2 # def5678 Initial dataset v1 # 이전 버전으로 이동 git checkout def5678 # 해당 버전의 데이터로 복원 dvc checkout # 또는 한 번에 실행 git checkout def5678 dvc checkout # 작업 후 다시 최신 버전으로 git checkout main dvc checkout # 특정 파일만 이전 버전으로 git checkout def5678 -- data/train_images.dvc dvc checkout data/train_images.dvc ``` 김개발 씨는 난감했습니다. 지난달의 모델과 데이터가 필요한데, 그동안 데이터가 여러 번 업데이트되었기 때문입니다. "예전 같았으면 불가능했을 거예요." 박시니어 씨가 말했습니다. "하지만 DVC를 쓰고 있으니까 걱정 없어요." **dvc checkout**이란 정확히 무엇일까요? 쉽게 비유하자면, dvc checkout은 마치 타임머신과 같습니다. Git이 코드의 타임머신이라면, DVC는 데이터의 타임머신입니다. 특정 시점으로 돌아가면 그때의 코드뿐만 아니라 그때의 데이터까지 함께 복원됩니다. 실험의 완벽한 재현이 가능해지는 것입니다. 작동 원리를 살펴봅시다. Git 커밋에는 .dvc 파일이 포함되어 있습니다. 이 .dvc 파일에는 해당 시점 데이터의 해시값이 기록되어 있습니다. git checkout으로 이전 커밋으로 이동하면 .dvc 파일도 그때 버전으로 바뀝니다. 이 상태에서 dvc checkout을 실행하면 DVC가 해시값을 읽어서 캐시에서 해당 데이터를 복원합니다. 위의 코드를 자세히 살펴보겠습니다. 먼저 git log로 커밋 히스토리를 확인합니다. 돌아가고 싶은 커밋을 찾아서 git checkout을 실행합니다. 이 시점에서는 코드만 이전 버전이고, 데이터는 아직 현재 버전입니다. dvc checkout을 실행하면 데이터도 이전 버전으로 바뀝니다. 만약 캐시에 해당 버전의 데이터가 없다면 어떻게 될까요? 그런 경우에는 dvc pull을 먼저 실행해야 합니다. 원격 저장소에서 해당 버전의 데이터를 다운로드받은 후에 dvc checkout이 정상적으로 동작합니다. 실제 현업에서는 어떻게 활용할까요? 머신러닝 실험에서 모델 성능이 갑자기 떨어졌다고 가정해봅시다. 원인을 찾기 위해 이전에 잘 동작하던 버전으로 돌아가야 합니다. DVC 덕분에 코드와 데이터를 모두 그 시점으로 복원할 수 있습니다. A/B 테스트를 위해 다른 버전의 모델을 비교할 때도 유용합니다. 주의할 점도 있습니다. dvc checkout은 로컬 캐시에 데이터가 있어야 동작합니다. 원격 저장소에만 있는 경우에는 먼저 dvc pull을 해야 합니다. 또한 현재 작업 중인 변경사항이 있다면 먼저 커밋하거나 스태시해두는 것이 좋습니다. 김개발 씨는 git checkout으로 지난달 커밋으로 이동한 후 dvc checkout을 실행했습니다. 순식간에 그때의 데이터가 복원되었습니다. "마치 타임머신 같아요!" 김개발 씨가 감탄했습니다. **실전 팁** 💡 - git checkout과 dvc checkout은 항상 쌍으로 실행하세요 - 캐시에 데이터가 없으면 dvc pull을 먼저 실행해야 합니다 --- ## 6. DVC_파이프라인_구축 김개발 씨의 프로젝트가 점점 복잡해졌습니다. 데이터 전처리, 피처 추출, 모델 학습, 평가까지 여러 단계를 거쳐야 했습니다. 매번 수동으로 각 단계를 실행하는 것이 번거로웠습니다. 박시니어 씨가 말했습니다. "DVC 파이프라인을 써보세요. 전체 워크플로우를 자동화할 수 있어요." **DVC Pipeline**은 데이터 처리 워크플로우를 정의하고 자동화하는 기능입니다. dvc.yaml 파일에 각 단계의 의존성과 출력을 정의하면, DVC가 변경된 부분만 자동으로 재실행합니다. 마치 Makefile처럼 의존성 기반으로 동작하지만, 데이터 과학에 특화되어 있습니다. 다음 코드를 살펴봅시다. ```python # dvc.yaml 파일 생성 stages: preprocess: cmd: python src/preprocess.py deps: - src/preprocess.py - data/raw/ outs: - data/processed/ train: cmd: python src/train.py deps: - src/train.py - data/processed/ outs: - models/model.pkl metrics: - metrics.json: cache: false evaluate: cmd: python src/evaluate.py deps: - src/evaluate.py - models/model.pkl metrics: - evaluation.json: cache: false # 파이프라인 실행 dvc repro # 특정 단계만 실행 dvc repro train ``` 김개발 씨는 매일 같은 작업을 반복하고 있었습니다. 먼저 전처리 스크립트를 실행하고, 그 다음 학습 스크립트를 실행하고, 마지막으로 평가 스크립트를 실행합니다. 실수로 순서를 빼먹거나, 이미 실행한 단계를 다시 실행하는 일도 잦았습니다. "이거 자동화할 수 없나요?" 김개발 씨가 한숨을 쉬며 물었습니다. 박시니어 씨가 눈을 빛냈습니다. "DVC 파이프라인이 딱이에요." **DVC Pipeline**이란 정확히 무엇일까요? 쉽게 비유하자면, 파이프라인은 마치 공장의 조립 라인과 같습니다. 자동차 공장에서는 부품이 순서대로 조립되어 완성차가 됩니다. 엔진이 장착되어야 변속기를 연결할 수 있고, 차체가 완성되어야 도색을 할 수 있습니다. DVC 파이프라인도 마찬가지로, 각 단계의 의존성을 정의하고 순서대로 실행합니다. 파이프라인의 핵심 개념을 알아봅시다. 첫째, **deps(dependencies)**는 해당 단계가 의존하는 파일들입니다. 이 파일들이 변경되면 해당 단계를 다시 실행해야 합니다. 둘째, **outs(outputs)**는 해당 단계에서 생성되는 파일들입니다. 이 파일들은 자동으로 DVC 추적 대상이 됩니다. 셋째, **cmd**는 실행할 명령어입니다. 위의 코드를 자세히 살펴보겠습니다. dvc.yaml 파일에는 세 개의 단계가 정의되어 있습니다. preprocess 단계는 원본 데이터를 전처리하여 processed 폴더에 저장합니다. train 단계는 전처리된 데이터를 사용하여 모델을 학습시킵니다. evaluate 단계는 학습된 모델을 평가합니다. **dvc repro**는 정말 똑똑합니다. 이 명령을 실행하면 DVC가 의존성 그래프를 분석합니다. 변경된 파일이 있는 단계만 재실행합니다. 예를 들어 train.py만 수정했다면 preprocess는 건너뛰고 train과 evaluate만 실행합니다. 이렇게 하면 시간과 컴퓨팅 리소스를 절약할 수 있습니다. **metrics**는 특별한 출력입니다. 모델의 성능 지표를 기록하는 JSON 파일을 metrics로 지정하면, dvc metrics show 명령으로 쉽게 확인할 수 있습니다. 여러 실험의 성능을 비교하는 데 유용합니다. 실제 현업에서는 어떻게 활용할까요? 추천 시스템 프로젝트를 예로 들어봅시다. 사용자 로그 수집, 데이터 정제, 피처 엔지니어링, 모델 학습, 오프라인 평가, 온라인 배포까지 여러 단계가 있습니다. 각 단계를 파이프라인으로 정의해두면, 새로운 데이터가 들어올 때마다 dvc repro 한 번으로 전체 과정을 자동화할 수 있습니다. 김개발 씨는 dvc.yaml 파일을 작성하고 dvc repro를 실행했습니다. 모든 단계가 순서대로 자동 실행되었습니다. "이제 실수할 일이 없겠네요!" 김개발 씨가 기뻐했습니다. **실전 팁** 💡 - 파이프라인 의존성은 최대한 구체적으로 지정하세요 - metrics는 cache: false로 설정하면 Git에서 직접 확인할 수 있습니다 --- ## 7. 실험_추적과_비교 김개발 씨는 여러 가지 하이퍼파라미터로 실험을 진행하고 있었습니다. 학습률 0.01, 0.001, 0.0001로 각각 실험했는데, 어떤 설정이 가장 좋았는지 헷갈리기 시작했습니다. "실험 결과를 체계적으로 비교할 방법이 없을까요?" 박시니어 씨가 dvc exp를 소개해주었습니다. **DVC Experiments**는 머신러닝 실험을 체계적으로 추적하고 비교하는 기능입니다. 각 실험의 파라미터, 메트릭, 결과물을 자동으로 기록하고, 여러 실험을 테이블 형태로 비교할 수 있습니다. Git 브랜치를 만들지 않고도 수십, 수백 개의 실험을 관리할 수 있습니다. 다음 코드를 살펴봅시다. ```python # params.yaml 파일 생성 train: learning_rate: 0.001 epochs: 100 batch_size: 32 # 기본 실험 실행 dvc exp run # 파라미터를 변경하면서 실험 dvc exp run -S train.learning_rate=0.01 dvc exp run -S train.learning_rate=0.0001 dvc exp run -S train.epochs=200 # 실험 결과 비교 dvc exp show # ┏━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━━━┓ # ┃ Experiment ┃ accuracy┃ learning_rate ┃ # ┡━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━━━━┩ # │ exp-abc12 │ 0.92 │ 0.001 │ # │ exp-def34 │ 0.89 │ 0.01 │ # │ exp-ghi56 │ 0.94 │ 0.0001 │ # └───────────────┴─────────┴────────────────┘ # 최고 성능 실험을 브랜치로 저장 dvc exp branch exp-ghi56 best-model ``` 김개발 씨는 노트에 실험 결과를 적고 있었습니다. "학습률 0.01, 정확도 89%... 아, 이거 아까 기록한 건가?" 기록이 점점 엉망이 되어가고 있었습니다. "엑셀로 정리해볼까 했는데, 너무 번거로워요." 김개발 씨가 투덜거렸습니다. 박시니어 씨가 말했습니다. "DVC Experiments를 쓰면 자동으로 정리해줘요." **DVC Experiments**란 정확히 무엇일까요? 쉽게 비유하자면, 실험 노트를 자동으로 작성해주는 비서와 같습니다. 과학자가 실험할 때마다 비서가 실험 조건, 결과, 시간을 꼼꼼히 기록해줍니다. 나중에 "가장 성능이 좋았던 실험이 뭐였지?"라고 물으면 바로 찾아줍니다. DVC Experiments가 바로 그런 역할을 합니다. params.yaml 파일이 핵심입니다. 이 파일에 실험의 하이퍼파라미터를 정의합니다. 학습률, 에포크 수, 배치 크기 같은 값들을 여기에 적어둡니다. 파이프라인의 스크립트에서 이 파일을 읽어서 사용하면, DVC가 자동으로 파라미터 변화를 추적합니다. 위의 코드를 자세히 살펴보겠습니다. dvc exp run은 파이프라인을 실행하면서 실험을 기록합니다. -S 옵션을 사용하면 params.yaml의 값을 임시로 변경해서 실험할 수 있습니다. 파일을 직접 수정할 필요가 없어서 편리합니다. 여러 번 실행하면 각각 별도의 실험으로 기록됩니다. **dvc exp show**는 강력한 비교 도구입니다. 모든 실험을 테이블 형태로 보여줍니다. 파라미터 값과 메트릭을 한눈에 비교할 수 있습니다. 어떤 설정이 가장 좋은 성능을 냈는지 쉽게 파악할 수 있습니다. 마음에 드는 실험을 찾았다면 어떻게 할까요? dvc exp branch 명령으로 해당 실험을 Git 브랜치로 저장할 수 있습니다. 그러면 해당 실험의 코드, 파라미터, 데이터가 모두 보존됩니다. 나중에 프로덕션에 배포하거나 추가 실험을 진행할 때 사용할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 딥러닝 모델 튜닝을 예로 들어봅시다. 학습률, 옵티마이저, 네트워크 구조 등 수십 가지 조합을 실험해야 합니다. DVC Experiments를 사용하면 각 실험을 체계적으로 기록하고, 최적의 조합을 쉽게 찾을 수 있습니다. 논문 작성이나 결과 보고 시에도 실험 기록이 명확해서 재현성을 보장할 수 있습니다. 김개발 씨는 dvc exp show로 실험 결과를 확인했습니다. 학습률 0.0001일 때 가장 좋은 성능을 보였습니다. "이제 어떤 실험이 최고였는지 바로 알 수 있네요!" **실전 팁** 💡 - params.yaml에는 자주 바꾸는 하이퍼파라미터만 넣으세요 - dvc exp show --sort-by 옵션으로 특정 메트릭 기준으로 정렬할 수 있습니다 --- ## 8. Git_연동_워크플로우 김개발 씨는 이제 DVC의 기본 기능을 익혔습니다. 하지만 실제 협업에서 Git과 DVC를 어떻게 함께 사용해야 하는지 아직 감이 잡히지 않았습니다. "브랜치 작업하면서 데이터도 관리해야 하는데, 어떤 순서로 해야 하죠?" 박시니어 씨가 실무 워크플로우를 알려주었습니다. DVC는 Git과 함께 사용하도록 설계되었습니다. 코드 변경은 Git으로, 데이터 변경은 DVC로 관리하되, 두 시스템이 **동기화**되어야 합니다. 브랜치 생성, 머지, 태그 등 Git의 모든 기능과 DVC를 조화롭게 사용하는 방법을 알아야 실무에서 원활한 협업이 가능합니다. 다음 코드를 살펴봅시다. ```python # 새로운 피처 브랜치에서 작업 시작 git checkout -b feature/new-dataset dvc checkout # 데이터 작업 후 추적 dvc add data/new_dataset.csv git add data/new_dataset.csv.dvc data/.gitignore # 코드와 데이터 변경 커밋 git commit -m "Add new dataset for feature X" # 원격 저장소에 푸시 git push -u origin feature/new-dataset dvc push # 코드 리뷰 후 머지 git checkout main git merge feature/new-dataset dvc checkout dvc pull # 다른 팀원의 데이터 변경 사항 받기 # 릴리스 태그 생성 git tag -a v1.0 -m "Release version 1.0" git push origin v1.0 dvc push # 해당 버전의 데이터도 함께 보존 ``` 김개발 씨는 새로운 기능을 개발하기 위해 브랜치를 만들었습니다. 그런데 브랜치를 전환할 때마다 데이터가 꼬이는 문제가 발생했습니다. "main 브랜치에는 옛날 데이터가 있어야 하는데, 새 데이터가 그대로 남아있어요." 김개발 씨가 당황했습니다. 박시니어 씨가 설명했습니다. "Git만 체크아웃하면 그래요. DVC도 함께 체크아웃해야 해요." **Git과 DVC의 관계**를 이해해봅시다. 쉽게 비유하자면, Git은 도서관의 목록 카드이고 DVC는 실제 책을 보관하는 서고입니다. 목록 카드를 보면 어떤 책이 어디에 있는지 알 수 있습니다. 하지만 카드만 바꾸면 책이 저절로 바뀌지는 않습니다. 서고에서 직접 책을 가져와야 합니다. 마찬가지로 git checkout만 하면 .dvc 파일만 바뀌고, 실제 데이터는 dvc checkout을 해야 바뀝니다. 실무 워크플로우의 핵심을 알아봅시다. 첫째, **브랜치 전환 시 항상 dvc checkout**을 실행합니다. 이것을 습관화해야 합니다. 둘째, **커밋 전에 dvc add**로 데이터 변경을 추적합니다. 셋째, **푸시는 git과 dvc 둘 다** 해야 합니다. 넷째, **풀도 git과 dvc 둘 다** 해야 합니다. 위의 코드를 자세히 살펴보겠습니다. 새 브랜치를 만들 때 git checkout -b로 브랜치를 생성하고 바로 dvc checkout을 실행합니다. 작업이 끝나면 dvc add, git add, git commit 순서로 진행합니다. 원격 저장소에는 git push와 dvc push를 둘 다 실행합니다. **태그**를 활용하면 릴리스 관리가 편해집니다. 중요한 버전에 태그를 붙여두면 나중에 해당 버전으로 쉽게 돌아갈 수 있습니다. git tag로 태그를 만들고, 해당 시점의 데이터도 dvc push로 원격에 보관해둡니다. 프로덕션에 문제가 생겼을 때 특정 버전으로 롤백하기가 수월해집니다. 실제 현업에서는 어떻게 활용할까요? 여러 명이 동시에 다른 피처를 개발한다고 가정해봅시다. 각자 브랜치에서 작업하면서 데이터도 함께 변경합니다. main에 머지할 때 코드 충돌처럼 데이터 충돌도 발생할 수 있습니다. 이런 경우 .dvc 파일을 기준으로 어떤 버전을 사용할지 결정하고, dvc checkout으로 해당 데이터를 가져옵니다. 주의할 점도 있습니다. git pull만 하고 dvc pull을 잊으면 데이터가 맞지 않는 상황이 발생합니다. 팀 전체가 이 워크플로우를 숙지하고 있어야 혼란을 피할 수 있습니다. Git hooks를 설정해서 checkout 후 자동으로 dvc checkout이 실행되도록 하는 것도 좋은 방법입니다. 김개발 씨는 워크플로우를 정리해서 팀 위키에 올렸습니다. "이제 팀 전체가 같은 방식으로 작업할 수 있겠네요!" 협업이 한결 수월해졌습니다. **실전 팁** 💡 - post-checkout Git hook을 설정하면 자동으로 dvc checkout이 실행됩니다 - 머지 충돌 시 .dvc 파일은 원하는 버전을 선택한 후 dvc checkout하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Data Science

언어: Python

태그: DVC, DataVersionControl, MLOps, DataPipeline, ModelManagement, Data Science

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

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

목차

1. DVC 초기화와 기본 개념

2. 데이터 파일 추적하기

3. 원격 저장소 설정

4. 데이터 푸시와 풀

5. 데이터 버전 전환

6. DVC 파이프라인 구축

7. 실험 추적과 비교

8. Git 연동 워크플로우

이 카드뉴스가 포함된 코스

MLOps 파이프라인 구축 완전 정복

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드