[Git, SVN] SVN vs Git : 2020년에 당신에게 적합한 것은? 번역 및 요약본

얼마 전 지인과의 대화해서 회사에서 SVN을 사용하고 있으면서 Git으로 전환할 것을 검토하고 있다는 이야기를 들었습니다. 막연히 이해하는 바로는 Git으로 전환하는 게 좋을 것 같다고 이야기했었는데 상황을 들어보니 마냥 전환하기는 쉽지 않은 여건도 보였습니다.

 

생각난 김에 SVN과 Git의 장단점을 정리하고 선택할 때 도움이 될 만한 글을 검색하니 2020년 3월에 작성된 글이 있어서 정리해 봤습니다.

---

0. 원문

https://www.tabnine.com/blog/svn-vs-git/

---

1. Git과 SVN

SVN과 Git은 소프트웨어 개발에서 워크플로우와 프로젝트 관리를 가능하게 하는 대표적인 VCS(Version Control System: 버전 제어 시스템)입니다. 

 

작업하는 모든 프로젝트에 적합한 VCS를 선택하는 것은 각 프로그래머(또는 개발 팀 리더)의 몫입니다. 믿거나 말거나, 잘못된 결정으로 인해 개발자는 많은 시간과 땀, 눈물을 흘리게 될 수 있습니다.

 

2. Git과 SVN의 차이점

Git vs Subversion 동작 방식

 

두 VCS의 큰 차이점은 핵심 아키텍처에 있습니다. SVN은 중앙 집중식으로 동작하고, Git의 버전 제어는 분산하여 동작합니다. 그러나  이는 빙산의 일각에 불과합니다. 둘 중 하나를 효과적으로 사용하려면, 접근 방식과 기능의 서로 다른 변형을 이해하는 것이 중요합니다. 

 

	Git	SVN
Server architecture 서버 아키텍처	분산 로컬에 설치되며 서버와 클라이언트 역할을 모두 수행.	중앙 집중 서버와 사용자 클라이언트가 필요
Revisioning	Git은 SCM(source code management)소스 코드 관리) 도구입니다. 따라서 전체 개정 번호(global revision number) 기능이 없습니다.	SVN은 개정 제어 시스템(revision control system)입니다. 따라서 전체 개정 번호(global revision number)가 표시됩니다.
Repository cloning 저장소 복제	가능	불가능
Storage format 저장 형식	메타데이터	파일
Storage requirements	대용량 바이너리 파일을 처리할 수 있는 용량이 제한되어 있음	코드 외에 대용량 바이너리 파일을 처리할 수 있음
Branching	브랜치는 특정 커밋에 대한 참조. 다른 커밋에 영향을 주지 않고 언제든지 생성, 삭제, 변경할 수 있다.	브랜치는 repository 내부의 디렉터리로 생성된다.  브랜치가 준비되면 trunk에 다시 커밋 된다.
Access contorl & permissions 접근 제어 및 권한	모든 기여자가 전체 코드베이스에 대해 동일한 권한을 가지고 있다고 가정함.	파일 수준 및 디렉터리 수준별로 읽기, 쓰기 및 접근 제어를 통해 세분화된 권한을 적용할 수 있음
Ease of use 사용 편이성	보다 어려움	보다 쉬움
Cryptographic hashing	네트워크 문제 또는 디스크 오류로 인한 repository 손상을 방지하기 위해 Git은 함호화된 hashed contents를 지원함.	n/a
License	GNU	Open srouce under the Apache License
Change tracking 변경 추적	Repository Level	File Level
Original developer	Linus Torvalds  (Linux 커널 코드 제어용으로 개발)	CollabNet, Inc

 

2.1 Git과 비교한 SVN의 장점

일반적으로 웹에서는 프로젝트의 버전 제어를 위한 solution으로 Git을 선호하는 경향이 있습니다. 그러나 몇몇 주목할만한 오픈 소스 프로젝트 가운데 24% 정도는 SVN을 사용한 OpenHub를 Git대신에 사용하고 있습니다. 이것이 Git에 비해 SVN의 장점에 먼저 초점을 맞추기로 한 이유입니다.

▶ 보다 우수한 아키텍처 (Superior architecture performance)

SVN과 같은 중앙 집중식 버전 제어 아키텍처를 선호하는 한 가지는 네트워크 트래픽을 처리하고 팀과 개발자 간의 동기화를 보장하는 데 효율적이라는 점입니다.

 

SVN으로 작업할 때 로컬에 있는 것과 서버에 있는 최신 것 간의 차이점만 동기화하면 됩니다. 이는 Git보다 훨씬 빠릅니다. Git은 분산되어 있기 때문에, 변경 사항으로 브랜치에서 삭제된 쓸모없는 자산이 기가바이트만큼 추가되더라도, 모든 변경 사항을 다운로드해야 합니다.

 

특히 혼잡한(속도가 느린) 네트워크에서 작업하, 저장소가 동기화되는 동안 낮잠을 자고 싶지 않은 경우 이는 낭비입니다. 깨어나서 체크아웃한 브랜치가 다른 사람의 손도 닿지 않은 기가바이트의 저장소를 다운로드했다는 사실을 알게 된다면 더욱 그렇습니다. 

▶ 바이너리 파일 처리 개선 (Better handling of binary files)

SVN이 Git에 비해 갖는 가장 확실한 이점은 아마도 바이너리 파일을 처리하는 방식에 있을 것입니다. Subversion이 Git보다 우수한 이유는 Lock-Modify-Unlock모델을 지원하기 때문입니다. 이는 SVN은 lock command(svn:needs-lock property)를 사용하여 구연되었고, Git는 분산을 지원하는 특성 때문에 exclusive file locking을 전혀 지원하지 않기 때문입니다.

 

엔터프라이즈 프로젝트에서  다수의 non-mergeable binary assets를 코드베이스로 하는 경우에는, 이것이 큰 문제이며 SVN을 고수하게 되는 이유가 됩니다. 

▶ 유용성 및 사용 용이성 (Usability and ease of use)

논쟁의 여지는 있을 수 있지만 많은 개발자들이 SVN이 Git보다 배우고 사용하기 더 쉽다고 주장합니다. 더 나은 추상화 기능을 제공하여 기능을 더 빠르게 추가하고 구문이 훨씬 더 깔끔해졌습니다.

▶ 접근 제어 (Access control)

Git 아키텍처는 이를 사용하는 모든 사람이 동일한 권한을 가지고 있다고 가정합니다. 자체 브랜치의 전체 코드베이스에 대한 읽기 및 쓰기 접근 권한을 얻는 것은 큰 문제입니다. 실제로 자체 사용자 권한 지정이 없습니다. 오픈 소스 세계에서는 완전히 수용 가능하지만 이 접근 방식은 기업 환경에는 위험할 수 있습니다. 많은 경우 잘못된 접근 제어로 인해 코드의 일부를 작업하는 타사 계약자에게 기밀 및 독점 정보가 공개될 수 있습니다.

 

SVN은 그렇지 않습니다. 세밀한 경로 기반 사용자 권한이 시스템에 내장되어 더 엄격한 코드 보안과 제어가 가능합니다. 

2.2 SVN과 비교한 Git의 장점

Git이 많은 개발자의 기본 선택이 된 주된 이유는 실제로 GitHub이고 이 GitHub의 코드 공유의 용이성 때문이라고 주장하는 사람들도 있습니다. 이 자체가 SVN 대신 Git을 선택하는 이유는 아니지만, 왜 그렇게 많은 사람들이 Git을 선택하는지 밝혀줄 수 있습니다.

▶ Git 인기 (Git Popularity)

Git의 인기에 관해서는 닭과 달걀의 딜레마가 연상됩니다. 정말 더 나은지?, 아니면 단순히 GitHub와 오픈 소스 운동 덕분에 더 나은 PR을 얻은 것인지? 어느 쪽이든 cool kids는 모두 그렇게 하고 있는 것 같습니다. 심지어 non-cool kids도 따라잡고 있습니다.

▶ 더 쉬워진 병합 (Easier merging)

어떤 버전 관리 아키텍처를 사용하든 repository 병합은 결코 쉽지 않습니다. 즉, Git은 repository 병합에 더 나은 아키텍처입니다. 이는 여러 기여자의 코드를 병합하는 기능이 Git의 주요 초점이고 커뮤니티 협업이 가능하도록 아키텍처가 구축되었기 때문입니다.

▶ 오프라인 지원 (Offline support)

여행 중인데 심각한 버그를 수정해야 한다고 상상해 봅니다. repository를 동기화하고, 비행 중이나 회의 중에 수정 사항을 코딩하고, 신속하게 push & commit 합니다. 지금까지는 괜찮았지만 오프라인 상태가 되면 어떻게 될까요? Git의 분산 특성으로 인해 코드를 기본 저장소와 독립적으로 로컬로 push & commit 할 수 있습니다. 이를 통해 Git 버전 관리가 네트워크 트래픽을 더 가볍게 할 뿐만 아니라 중앙집중식 서버로부터의 독립성을 보장합니다. 서버가 당장 필요할 때 crash 되었을지도 모르기 때문입니다.

3. 버전 관리 추세에 대한 커밋 및 제출
   (Committing and submitting to versioning trends)

소프트웨어 버전 관리가 중요하다는 점은 반론의 여지가 없으며, 주요 논쟁은 어떤 아키텍처와 접근 방식이 언제 가장 좋은지에 대한 것입니다.

 

Git이 오픈 소스 개발을 목표로 하는 분산형 solution 역할을 하고 SVN이 여전히 기업에서 선호되는 상황에서 논쟁은 앞으로도 수년간 계속될 것 같습니다. 아마도 Mercurial, Bazaar, 기존 플레이어(CVS)및 신규 플레이어(Microsoft Azure DevOps)와 같은 시스템 대표자들의 목소리가 더욱 커질 것입니다.

 

추가로 읽어보면 좋은 글 : 2016년 8월 작성

https://svnvsgit.com/

 

 

 

 

참고문헌 (원문)

https://www.tabnine.com/blog/svn-vs-git/