최근 수정 시각 : 2024-11-14 04:03:35

버전 관리 시스템

버전 관리에서 넘어옴
1. 개요2. 버전 관리란?3. 종류
3.1. 로컬 VCS3.2. 중앙집중식 VCS3.3. 분산 버전 관리 시스템(VCS)
4. 목록5. 관련 문서

1. 개요

Version Control System(VCS)
문서나 설계도, 소스 코드 등의 변경 사항, 즉 버전을 관리해주는 소프트웨어.

2. 버전 관리란?

파일:졸업논문_최종_최종_final.jpg
버전 관리 없이 문서를 작성한 경우 유서 지못미

소프트웨어 등을 작성할 때 변경점을 관리하는 것은 말할 필요도 없이 아주 중요하다. 버전 관리를 함으로써 얻을 수 있는 것에는 다음과 같은 것이 있다.[1][2]
  • 변경점 관리: 어떤 내용을 누가 작성해서 어느 시점에 들어갔는지 확인할 수 있게 해준다.
  • 버전 관리: 특정 시점에 꼬리표(Tag)를 달아 버전을 표시해주고, 브랜치(Branch) 등으로 동시에 여러 버전을 개발할 수 있게 해준다.
  • 백업&복구: 무언가가 잘못되었을 때 다시 특정 시점으로 돌아가게 해주고, 사고로 내용이 날아간 경우에도 복구할 수 있게 해준다.
  • 협업: 같이 일하는 사람들에게 수정 사항을 쉽게 공유

버전 관리 프로그램만 따로 사용해 관리하는 경우도 있지만, 오늘날에는 비주얼 스튜디오, IntelliJ IDEA 등의 통합 개발 환경과 텍스트 에디터에서 이런 기능을 통합해줘서 에디터 내부에서 바로 사용할 수도 있다. 굳이 소프트웨어 개발에서만이 아니더라도, 구글 문서 도구, 원드라이브 등 클라우드 컴퓨팅에서도 버전 관리 기능을 제공한다.

3. 종류

3.1. 로컬 VCS

서버 없이 로컬 컴퓨터 내에서 버전을 관리한다. 간단한 데이터베이스만으로도 구현이 가능하므로 단순하고 개인적인 프로젝트에 적합하다.

단, 협업에서 쓰기에는 힘들고, 컴퓨터가 고장나는 등 내부 정보가 통째로 날아가버리면 복구할 방법이 없다.

3.2. 중앙집중식 VCS

서버에 최종본 한 벌이 있으며, 사용자들은 이 중 수정을 원하는 파일만 로컬에 받아 수정한 후 서버에 올리게 된다.

간단한 방법으로 협업이 가능하고 관리자가 누가 어떤 일을 하고 있는지 알기 쉬운 장점이 있다. 단, 중앙 서버가 다운될 경우 그동안은 업무가 마비되는 단점이 있다. 그리고 서버의 정보가 날아갈 경우 모든 히스토리가 날아가게 된다. 협업의 규모가 커지면 수정 충돌 문제 등이 발생할 수 있다.

비유하자면 나무위키의 문서 편집 시스템이 간단한 중앙집중식 버전 관리에 속한다. 대표적으로 Subversion이 있다.

3.3. 분산 버전 관리 시스템(VCS)

파일을 저장하는 서버가 있는 것은 위와 동일하지만 수정을 위해 프로젝트 전체를 로컬 컴퓨터에 다운 받은 뒤 수정한다.

중앙 서버가 다운되더라도 개별 사용자는 각자 작업이 가능하고 서버가 날아가도 다운 받은 내용은 남아있기 때문에 가장 안정적이다. 수정 시에도 현재 코드는 나 혼자 수정하고 있기 때문에 충돌의 염려 없이 수정할 수 있으며, 최종적으로 서버에 반영할 때에만 신경써서 머지(Merge)해주면 된다.

대표적으로 Git이 있다.

4. 목록

  • Git: 현재 버전 관리 시스템의 최고봉, 메이저, 대명사. 인텔리제이 같은 메이저 IDE에서도 개발 환경에 깃 배쉬를 연동하는 것이 관례이다.[3]
  • Subversion: 2000년에 CollabNet이 개발하고 이후 아파치 소프트웨어 재단 소유로 넘어왔다. 2000년대 중반까지 가장 널리 쓰였으나 2010년도 이후 Git에 맹렬하게 추격당해 시장의 지배권을 내주었다. 중앙집중형 구조를 취하기 때문에 Git에 비해 쓰기 쉽지만 규모가 커질수록 충돌을 해결하는 데 드는 노력이 증가하기 때문에 대형 프로젝트의 협업에는 불리하다.
  • Mercurial: Git과 같은 분산형 버전 관리 시스템. Git보다 직관적이고 쉽지만 덜 유연하다. Git 등장 전까지는 SVN(Subversion)에 이은 2위였다. Git이 Subversion을 잡아먹고 사실상 표준으로 자리잡는 동안 만년 3인자 자리에서 벗어나지 못하고 있다.
  • BitKeeper: 리누스 토르발스가 원래 사용하려고 했던 버전 관리 시스템. 그러나 리누스가 결국 버전 관리 시스템 Git을 직접 개발하는 바람에 점유율이 대폭 줄어들어 버렸다.
  • CVS: 90년대에 개발되어 널리 쓰였던 버전 관리 시스템. 위에 있는 시스템들보다 훨씬 고전적인 구조로, 소프트웨어 개발환경이 복잡해지면서 자연히 Subversion에 밀려 일찌감치 역사의 뒤안길로 사라졌다.
  • Fossil: SQLite의 개발자가 만들어 SQLite의 소스코드를 관리하는 데에 직접 사용하고 있는 버전 관리 시스템. SQLite의 제작자 답게, 디렉토리 트리 구조로 정보를 저장하는 다른 시스템들과 달리 Database 형식으로 정보를 저장하여 관리 정보가 단일 파일로 모두 압축된다는 특징을 가지고 있다. 이 때문에 포터블 프로그램으로도 제공된다.
  • Perforce Helix Core: 중앙집중형 VCS. 보통 풀네임으로 불리지 않고 그냥 줄여서 Perforce라고 부른다. 1995년 개발된 역사가 긴 VCS중 하나다. Git은 코드 이외의 순수 바이너리 형태의 파일을 관리하는데는 썩 적합하지 않고 (LFS가 도입된 것은 나중의 일이다) 사용 환경도 프로그래머의 입장에서나 편한 환경을 가진것에 비해 GUI기반의 관리 툴들과 커다란 바이너리 파일을 관리하는데 장점이 있어 이러한 데이터의 관리가 중요한 게임 회사나 반도체 설계 회사 등에서 주로 사용한다.
  • Visual SourceSafe: Microsoft의 단종된 VCS. 파일을 관리하고 수정사항을 병합하는데 파일이 깨지는 안정성 문제가 있어 얼마 가지 못하고 버려졌다.
  • Bazaar: 분산형 VCS. Python으로 작성.

5. 관련 문서


[1] 변경점 관리 및 백업&복구 기능은 가까운 예시를 이를테면 나무위키의 문서 역사 기능을 활용하면 경험해 볼 수 있다. [2] 협업 기능은 나무위키에서 문서를 기여(편집)할 때, 요약 필드에 텍스트를 입력하게 되면 해당 문서에 기여하고자 하는 다른 사람들에게 무엇이 변경되었는지 대략적으로 알려줄 수 있다. [3] MS는 마침내 GitHub를 인수했다.

분류