2010년 대학교 졸업 후 취업 할 생각은 안하고 빈둥거리고 있을 때, 지인의 소개로 모 회사의 SI 프로젝트에 프리랜서 자격으로 참여 할 수 있었다.

프리랜서이지만 나름 첫 출근날, 상콤한 마음으로 프로젝트 장소에 도착하여 간략하게 개발업무에 대한 설명을 듣고, 개발환경을 구축하려는 그때부터 나는 멘붕에 빠져버렸다.

사실 대학교 막 졸업한 내가 제대로 할 줄 아는것이 무었이 있었겠는가? 그냥 다 할 줄 안다고 패기있게 참여한 프로젝트였지만 첫 시작부터 예상치 못한 친구인 “버전 관리 시스템”을 만나게 되었다. 당시 그 업체에서는 Visual Source Safe라는 툴을 사용하고 있었는데, 버전 관리 시스템이라것을 거기서 처음 들은 나는 Source Safe에서 소스 받아가라는 PL의 말을 알아듣지 못 할 수 밖에..

대학에서 친구 몇 명과 조그만 프로젝트를 개발 할 때는 한명이 프로젝트를 생성하여 큰 틀을 만들고, 각자 역할에 나누어 개발 후 한 사람 PC에 옹기종기 모여 각자 개발 한 모듈을 USB에 담아 취합하는 작업을 했었다.

시스템이 복잡하면 할 수록 점점 소스를 취합하는것이 힘들어 질 것이다. 그리고 특정 파일을 3일전의 상태로 돌리고 싶다면 어떨까? 매일매일 소스를 백업하여 아래같이 해둔다면 어찌 해 볼 수 있겠지만 그마저도 없다면 오롯이 내 머릿속의 기억에만 의존해야하는 최악의 사태가 벌어 질 수 있다.

  • 2015-06-01.zip
  • 2015-06-02.zip
  • 2015-06-03.zip

어떻게 이런 문제들을 해결 할 수 있을까?

버전 관리(Version Control)란?

개발자들은 자신의 머리가 그리 똑똑하지 못하는다는것을 오래전에 깨닫고 파일의 변화를 기록하는 시스템을 만들었으니 그게 버전관리 시스템이다.

아마 처음에는 자신의 컴퓨터에 있는 파일의 버전을 관리해주는 프로그램을 개발 했을 것이다.
내가 짠 소스코드의 변화를 시스템이 관리해주니 오늘 수정한 소스가 잘못된 것을 알았을 때 손쉽게 그 이전 버전이나, 특정 날짜에 작성한 버전으로 돌릴 수 있었을 것이다.

하지만, 소프트웨어는 여럿이 개발하는 경우가 많으므로, 내가 작성한 코드가 다른 사람에게도 보였으면 하는 생각이 들었을 것이고, 내 로컬에 변경사항을 기록하는 것이 아닌, 소스를 관리하는 서버에 변경사항을 기록하고, 각자 서버에서 소스를 받아서 사용할 수 있는 시스템을 만들었다. 그게 현재 사용하는 TFS, Source Safe, SVN, Subversion과 같은 프로그램이고 이것을 중앙 집중형 버전관리 시스템이라고 한다.

이 프로그램을 사용하면 다음과 같은 장점을 누릴 수 있다.

  • 여러명의 개발자가 하나의 프로젝트를 동시에 개발 할 수 있다.
  • USB등으로 파일을 copy할 필요 없이 다른 사람이 개발한 소스코드를 내 컴퓨터에 받아 올 수 있다.
  • 이 파일을 누가 언제 어떻게 수정했는지 이력을 볼 수 있다.
  • 문제가 생겨 이전 버전으로 돌아가야하는 일이 생겼을 때 손쉽게 돌아 갈 수 있다.
  • Branch를 이용하여, 좀 더 안전하게 새 기능을 추가하고 Merge하여 통합 할 수 있다.
  • 내가 A 기능을 개발하는 중에 급하게 Patch해야 할 버그가 생겼을 때도 잠시 A기능을 개발하지 전 상태로 돌려 버그를 수정하고, 다시 A기능을 개발하던 상태로 돌아 갈 수 있다.

이렇게 많은 기능을 제공하니, 개발자들은 좀 더 편리하게 개발 할 수 있게 된 것이다.

중앙집중형 버전관리 시스템
출처 : https://homes.cs.washington.edu/~mernst/advice/version-control.html

나는 그동안 TFS(Team Foundation Server)를 이용하여 버전관리를 했는데 IDE인 Visual Studio와의 통합도 훌륭하기 때문에 큰 불편함 없이 사용해왔다.

하지만 TFS(중앙 집중형 버전관리 시스템)의 경우 모든 소스를 서버가 관리하기 때문에 다음과 같은 단점이 존재한다.

  • 네트워크에 연결되어 있어야만 작업이 가능하다.(소스파일의 checkin, checkout시 서버에 접솝해야 한다.)
  • 서버에 문제가 생기면 작업을 할 수 없다.
  • 서버와의 통신이 지속적으로 이루어지기 때문에 네트워크가 느린경우 작업에도 영향을 미친다.
  • Branch하면 전체 소스를 다른 폴더에 받아오기 때문에 Branch가 많이 부담스러운 작업이다.

분산 버전 관리 시스템을 사용하면 앞서 말한 문제점을 해결 할 수 있다.

분산 버전 관리 시스템

중앙집중형 버전관리 시스템의 저장소(repository)가 server에만 있는것과 달리 분산 버전 관리 시스템에서 저장소는 모든 client가 저장소가 될 수 있다. 이게 무슨 말일까?

예를들어 TFS에서 get latest version을 통해 저장소에서 project를 가져온가고 생각해 보자. 그럼 저장소에서 사용자의 컴퓨터에 최신의 코드를 받아오게 된다. 분산 버전 관리 시스템의 경우 어떻까? server에서 저장소자체를 통채로 받아오게 된다. 이 말은 소스코드는 물론 그동안의 변경 이력까지 모든 정보를 가져와 로컬 컴퓨터 또한 완전한 저장소가 된다는 뜻이다.

이렇게 됨으로써 한번 저장소를 받아온 이후에 개발작업에서는 서버와는 별개로 자신의 로컬에서 진행하게 되고, 로컬이니 당연히 빠른 속도로 변경 할 수 있는 것이다. 만약 main.cs 파일의 지난 히스토리와 diff 하고 싶을 경우 TFS는 서버와의 통신을 통해 diff하는 반면 분산 버전 관리 시스템은 로컬에 있는 저장소에서 변경 이력을 찾아 diff해 준다.

이런 분산 버전 관리 시스템의 개념을 구현한 것이 git, Mercurial등이 있고, 나는 이제는 대새(?)로 자리잡은 git에 대해 설명 하려고한다. git은 리누즈 토발즈가 리눅스 커널의 버전관리를 위해 만들었다고 알려져 있다.

왜 git으로 바꿔야하나?

git은 어렵다. git을 만든 리누즈 토발즈도 한 인터뷰에서 이렇게 쓰기 어려운걸 누가 쓰리라곤 생각도 못했다.고 말했라고 한다. 특히나 CLI보다 GUI가 익숙한 닷넷 개발자는(닷넷개발자가 다 그렇다는 것이 아니다) 인터넷에 있는 git에 대한 사용법을 담은 자료를 보고, 버전 관리하는데 머가 이렇게 어려워?라는 생각을 가질 만하다.

우리 회사에서는 올해 초부터 시작해서 6개월동안 git을 사용하기 시작했는데, 내가 생각하는 장점은 다음과 같다.

  • 저장소 서버가 느려서 스트레스 받는 일이 줄었다.(우리는 Visual Studio Online 서비스를 이용하고 있는데 서버가 미국에 있다.)
  • Branch를 마음껏 할 수 있어, Backlog나 Bug 단위로 Branch를 만들어 개발하고 프로덕트를 release하는 Branch(master)는 clean하게 유지할 수 있다.(git workflow) -> 나는 이것이 git을 사용하는 가장 큰 benefit이라고 생각한다.

이 외에도 만약 이런 상태라면 git을 쓰자.

  • 버전관리 시스템을 써본적이 없다. 하지만 이제부터 쓸 예정이다.
  • github 서비스를 remote 저장소로 사용 할 예정이다.
  • 머릿속에 프로젝트에 대한 새로운 아이디어가 넘치는데 중앙의 source 이력을 망가뜨리지 않고 마구 실험해 보고 싶다.
  • 오픈소스의 컨트리뷰터가 되고 싶을 때(많은 오픈소스가 git으로 진행되거나 전환하고 있다)
  • git이 대세라는데 그 이유가 궁금하다.(써보면 안다)