중앙집중식 vs 분산형 버전 관리

SVN 같은 CVCS와 Git 같은 DVCS의 아키텍처 차이를 이해하고, 분산형이 왜 현대 개발에서 압도적으로 선택받는지 살펴본다.

· 6 min read · PALDYN Team

지난 글에서 버전 관리 시스템이 왜 필요한지 살펴봤다. 이번에는 VCS의 두 가지 아키텍처인 중앙집중식(CVCS)과 분산형(DVCS)의 차이를 구체적으로 비교한다. 이 차이를 이해하면 Git의 설계 철학이 왜 그렇게 강력한지 자연스럽게 납득하게 된다.

중앙집중식 VCS: 단일 진실 공급원

SVN(Subversion), CVS, Perforce 같은 중앙집중식 VCS는 단순한 모델을 따른다. 모든 버전 이력은 중앙 서버 하나에만 존재한다. 개발자는 최신 파일을 서버에서 받아 편집하고, 변경 사항을 서버로 전송한다.

# SVN 워크플로 예시
svn checkout http://server/repo/project  # 서버에서 받기
# ... 파일 편집 ...
svn commit -m "기능 추가"               # 서버로 전송 (네트워크 필수)
svn update                               # 다른 사람 변경 사항 받기

장점이 없는 건 아니다. 모델이 단순해서 이해하기 쉽고, 관리자가 누가 무엇에 접근하는지 세밀하게 제어할 수 있다. 대용량 바이너리 파일 관리에도 강점이 있다.

하지만 구조적 약점이 치명적이다.

중앙집중식 vs 분산형 아키텍처

단일 장애점(Single Point of Failure): 서버가 다운되면 모든 개발자가 커밋, 히스토리 조회, 브랜치 생성 등 모든 버전 관리 작업을 멈춰야 한다. 서버 데이터가 손상되면 백업이 없는 한 전체 이력을 잃는다.

오프라인 불가: 인터넷이 안 되는 환경(비행기, 지하철, 오지 출장)에서는 커밋을 할 수 없다. 작업은 할 수 있지만 버전 관리는 불가능하다.

느린 브랜치: CVCS에서 브랜치는 실제로 파일을 복사하는 작업이다. 수백 MB 규모의 프로젝트에서 브랜치 생성은 느리고, 병합은 더 느리다.

분산형 VCS: 각자가 완전한 복제본

Git, Mercurial 같은 분산형 VCS는 근본적으로 다른 전제를 따른다. git clone을 실행하면 파일만 받는 게 아니라 저장소 전체를 복제한다. 최초 커밋부터 현재까지 모든 이력, 브랜치, 태그가 로컬에 존재한다.

# Git 워크플로: 네트워크 없이도 완전한 버전 관리
git clone https://github.com/user/repo  # 전체 이력 복제

# 이후 네트워크 없이 가능한 작업들:
git log --oneline                        # 전체 이력 조회
git checkout -b feature/login            # 브랜치 생성 (즉시)
git commit -m "로그인 구현"              # 로컬 커밋
git diff HEAD~3                          # 3커밋 전과 비교
git revert abc1234                       # 특정 커밋 되돌리기

# 준비됐을 때만 원격과 동기화:
git push origin feature/login           # 원격으로 전송
git fetch origin                        # 원격 변경 확인

로컬 저장소가 완전한 백업 역할을 한다. GitHub 서버가 장애 나도 모든 개발자의 컴퓨터에 완전한 이력이 있으니 복구가 가능하다.

Git 분산 워크플로

성능 차이가 극적인 이유

Git이 거의 모든 작업에서 SVN보다 빠른 이유는 단순하다. 네트워크 I/O가 없기 때문이다.

작업SVN (CVCS)Git (DVCS)
커밋서버 왕복 필요로컬 즉시 (~1ms)
브랜치 생성서버 복사 작업로컬 파일 하나 (~1ms)
이력 조회서버 쿼리로컬 즉시
병합네트워크 필요로컬에서 처리

Git의 브랜치는 40바이트짜리 SHA-1 해시를 저장한 텍스트 파일 하나에 불과하다. 100만 줄짜리 프로젝트든 100줄짜리 프로젝트든 브랜치 생성에 걸리는 시간은 똑같다.

어떤 경우에 CVCS를 선택하나

그럼에도 CVCS가 선택받는 경우가 있다.

대용량 바이너리: 게임 개발에서 수십 GB의 에셋 파일을 다루는 경우, 전체 이력을 클론하는 DVCS 방식이 부담이 된다. Perforce가 게임 업계에서 여전히 쓰이는 이유다 (Git은 LFS로 이를 보완한다).

접근 제어: CVCS는 파일 단위, 디렉토리 단위 접근 권한 설정이 세밀하다. 내부 도구나 레거시 엔터프라이즈 환경에서 요구되는 경우가 있다.

그러나 일반적인 소프트웨어 개발에서는 분산형의 이점이 훨씬 크다. 오프라인 작업, 빠른 브랜치, 자동 백업, 유연한 워크플로 — 이 모든 것이 DVCS를 현대 개발의 표준으로 만든 이유다.


지난 글: 버전 관리란 무엇인가

다음 글: Git의 탄생과 역사


읽어주셔서 감사합니다. 😊