이번엔 버전 관리 시스템과, 이러한 버전 관리 시스템을 사용하는 프로젝트를 지원하는 웹호스팅 서비스를 결정해보도록 하자. 각각 Git, SVN / GitHub, BitBucket같은 것을 예로 들 수 있다. 소스코드 형상관리 시스템이나 소스코드 관리 시스템 같은 명칭으로도 종종 불리는데, 나는 그냥 버전 관리 시스템이라고 부르는 게 더 편한 것 같다.

도입 이유

버전 관리 시스템

아무튼 이러한 버전 관리 시스템을 도입하려는 이유는 다음과 같다.

  • 백엔드 어플리케이션을 지금 당장은 혼자 개발하겠지만, 미래에 새로운 백엔드 엔지니어가 우리 팀에 들어와서 협업하게 될 수도 있다. 시스템의 도움을 받아 협업을 원활히 하는 것이 첫 번째 이유다. 소스 코드를 USB나 메일로 주고받는 건 엄청난 낭비니 말이다.

  • 변경을 쉽게 되돌릴 수 있다. 에디터 툴들이 일반적으로 지원하는 Ctrl+Z 커맨드와는 차원이 다른 수준의 기록 관리를 지원한다. 소스코드를 과거의 특정 시점으로 되돌리거나, 특정 시점의 변경 사항을 취소하거나, 두 버전의 소스 코드를 비교하는 등의 일이 가능하다.

잘 모르겠다면 생활코딩 git 강의의 '버전관리란?' 챕터 영상를 살펴보자.

버전 관리 웹호스팅 서비스

  • 협업하고 있는 코드를 저장할 서버가 필요하기 때문이다. 이게 없으면 작업을 서로 공유하기 어려우며 사실 이 이유 하나만으로도 도입 동기가 충분하다. 코드를 USB나 메일로 주고받을 수도 있겠지만, 인생을 그렇게 낭비하지 말자. 버전 관리 서버는 직접 운영할 수도 있으나 에어비앤비, 슬랙, 페이팔같은 큰 조직도 GitHub을 쓰는 마당에 특별한 이유가 없다면 이미 잘 만들어져 있는 서비스를 쓰도록 하자.

  • 버전 관리 시스템을 지원하는 웹호스팅 서비스의 hook 기능을 통해, push나 이슈 추가, pull request같은 이벤트에 반응하여 자동으로 무언가(테스트 실행, 배포 등)가 실행되게 만들 수 있다. 예를 들면, master 브랜치로 push가 이루어졌을 때 자동으로 테스트를 돌리고, 문제가 없다면 배포하는 식이다.

  • 이러한 서비스들은 'pull request'라는 기능을 지원한다. 작업물의 병합을 요청하는 것이다. 여기서 리뷰를 진행하거나, 커뮤니케이션할 수 있다. 개발 프로세스 정립의 자유도가 높아진다.

의사결정

버전 관리 시스템

사실 요즘은 게임 업계가 아닌 이상 무조건 git을 쓰고있는 것 같지만, 이것도 의사결정에 포함시켜 보자.

배경과 요구사항

  • 대부분의 개발자가 이미 익숙해져 있는 도구일 수록 좋다.

  • 브랜치 개념이 있어야 한다. 배포용 코드/작업용 코드 등으로 나누어 프로젝트를 원활히 진행하기 위해 꼭 필요하다.

  • 분산형 모델을 사용하는 것을 우선적으로 선택하겠다. 중앙집중식/분산형 버전 관리 시스템의 차이를 모르겠다면 Git SCM의 문서 버전 관리란?을 읽어보자.

선택지

  • git

  • svn

  • mercurial

의사결정

git을 선택하겠다. 그 이유는,

  • SVN은 클라이언트-서버 모델을 사용한다. 이 때문에 저장소의 사본을 로컬에서 관리하는 git에 비해 매우 느리며(변경 로그 하나 보는 것도 인터넷을 경유해야 하므로) commit이 원격에 즉시 반영되기 때문에 부담이 크다. 게다가 SVN은 변화를 저장하는 방식으로 버전(변경 이력)을 관리하는데, 이것도 git과 비교했을 때 속도 문제를 일으킨다. git은 버전을 스냅샷으로 관리하기 때문이다.

  • 게다가 SVN에는 시스템적으로 브랜치 개념이 없어서, 작업마다 폴더를 만드는 식으로 우회하곤 한다. 스냅샷 기능이 없기 때문.

  • Mercurial과 Git은 분산 버전 관리 시스템이라는 점에서 꽤 유사하지만, 대부분의 개발자는 Git에 더 익숙하다. 우리 조직에 누군가가 들어왔을 때 불필요한 러닝커브가 생기지 않았으면 하는 바람이고, Git과 비교했을 때 Mercurial이 큰 메리트가 있는 것도 아니라는 판단이다.

준비

Git은 MacOS를 비롯한 대부분의 리눅스 환경에서 기본으로 제공한다. Windows를 사용하는 경우에만 Git for Windows를 설치하면 된다.

Git 웹호스팅 서비스

Git이 참조할 원격 저장소를 관리해줄 장소가 필요하다.

배경과 요구사항

  • 이것도 대부분의 개발자가 이미 익숙해져 있는 도구일 수록 좋다.

  • private 저장소를 무료로 만들 수 있게 해주는 서비스를 우선적으로 검토할 것이다. 나중에 조직이 커지면 돈을 쓰는 게 맞겠지만, 지금은 과금에 대한 부담이 적을수록 좋을 것이니 말이다.

  • 자체적으로 가지고 있는 이슈 트래커(작업 관리 도구)가 있으면 좋다.

선택지

의사결정

GitHub를 선택하겠다. 그 이유는,

  • BitBucket은 서버가 느리다. 이게 딱히 문제가 안 될 줄 알았는데 생각보다 굉장히 답답하며 자체적으로 제공하는 기능도 GitHub만큼 풍부하지 않다.

  • GitLab은 써본 사람이 얼마 없다. 이것도 딱히 문제가 안 될 줄 알았는데 예전에 GitLab 한 번 썼다가 어떤 기능이 어디에 있는 줄 몰라서 답답해 죽는줄 알았다. Mercurial을 쓰지 않았던 이유와 동일하게, 큰 메리트가 없으면서 굳이 익숙하지 않은 걸 썼다가 괜히 생산성만 조지는 수가 있다.

  • GitHub에 내장되어 있는 이슈 트래커(GitHub Issues)가 Projects 기능이나 ZenHub 플러그인과 함께 쓰면 생각보다 쓸만 하다. 조직이 웬만큼 커지기 전에는 이슈 트래커로 따로 돈 들어갈 일이 없다. 이슈 각각에 due를 설정하는 게 없는 것 빼고 꽤 만족스럽다.

  • GitHub은 free로 쓰던 돈을 내고 쓰던 거의 모든 면에 있어서 가장 풍부한 서비스라고 생각한다. 별의 별 기능이 다 있는데 그게 다 꼭 한 번씩은 필요한 기능들이었으며 기능 자체도 매우 잘 만들어져 *있었다. *특정 브랜치를 향한 pull request에 대해 n개 이상의 리뷰를 받아야 merge할 수 있게 만드는 것이나, Organization에서 팀을 만들어 사용자를 포함시키고, 팀 단위로 저장소 각각에 read/write/admin 권한을 부여하고, 서브 팀을 만들어 더 세부적인 위계를 나누는 등, 팀 관리 면에서도 매우 뛰어났던 것 같다.

  • 서비스 개발을 진행하는, 특히 백엔드 저장소를 public으로 두면 다른 의미로 많은 관심을 끌 수 있으므로 private로 두는 것이 좋다. 이 때문에 한가지 걸렸던 점은, GitHub에서 free 계정은 visibility를 public으로만 설정 가능하다는 것이었다. GitLab과 BitBucket이 무료 계정에게도 private 저장소를 제공하는 것과 대비된다. 이를 위해선 개인이 한 달에 7달러씩 지불하는 developer plan에 가입하거나, 팀 단위로 organization을 만들어서 유료 플랜을 구입해야만 했는데, 최근에 GitHub가 무료 플랜에게도 private 저장소를 만들 수 있도록 과금 정책을 변경하며 이러한 고민이 당장은 사라졌다. 물론 나중에 조직이 커져서 organization 단위로 프로젝트를 진행하게 되면 돈을 써야겠지만, 이건 다른 서비스들에게도 똑같이 적용되는 이야기다. 따라서 돈 때문에 GitHub를 포기할 이유가 없다. 나는 독자 여러분의 코드 참조를 위해 public으로 두겠다.

준비

GitHub에 계정이 없다면 만들고, 원격 저장소 하나를 만들어 두자. 원래는 팀 단위로 organization을 만들어서 저장소를 만드는 것이 일반적이지만, 같이 프로젝트를 하는 친구들은 사실 가상인물이므로 개인 계정에서 진행하자. GitHub Help의 Create a repo를 참고하면 될 것 같다. 위에서도 말했듯 나는 저장소를 public으로 만들텐데, 실제로 프로젝트를 하는 중이라면 private로 만드는 것이 맞다.

Git GUI

이건 조직 내가 아니라 개인적으로 결정해야 할 일이지만, 이미 CLI로 고통받고 있거나, CLI 때문에 git을 어려워하는 독자가 있을 수도 있기에 포함시켰다. CLI를 쓰겠다면 존중하겠지만 나는 그 많은 git 명령어를 자유자재로 외울 자신이 없기에 GUI를 사용하겠다. git 명령어가 익숙치 않은 독자가 git을 조금 더 쉽게 시작할 수 있게 하기 위한 목적도 있다.

배경과 요구사항

  • GUI 단에서 Git이 가지고 있는 대부분의 기능을 모두 사용할 수 있어야 한다.

  • UX가 후지지 않아야 한다.

  • GUI 툴 쓰다가 답답해서 콘솔 여는 경우가 없어야 한다.

선택지

의사결정

조직 단위의 결정이 아니기에 매우 개인적인 관점에서 GitKraken를 선택하겠다. 그 이유는,

  • GitHub Desktop은 가볍고 깔끔하지만 Git의 모든 기능을 지원하지 않는다. 예전에 신규 기능을 개발하다가 버그 핫픽스 작업이 갑작스레 생겨서 git stash 명령을 찾아보려 했는데, GitHub Desktop은 이걸 지원하지 않아서 CLI의 도움을 받았던 적이 있다.

  • 일할 땐 웬만하면 SourceTree를 쓰고, 나름 만족스럽지만 이번에 GitKraken을 찾아보니 UI도 예쁘고 좋아 보였다. 맨날 쓰던 것만 쓰면 꼰대가 되지 않을까 싶어서 이번에 GitKraken을 새로 써보려고 한다. GUI 툴은 쉽게 바꿀 수 있으니 써 보다가 아니다 싶으면 SourceTree로 바꾸려는 생각이다.

준비

다운로드를 받아 설치해 두자. 그리고 처음 실행하면 'Sign in with GitHub' 버튼을 통해 본인의 GitHub 계정을 연동할 수 있다. 물론 내가 GitKraken을 쓰기로 결정했다고 해서 꼭 이걸 써야 되는 건 아니다. 말했듯이 조직 단위의 결정이 아니기 때문이다.

그리고 Git GUI를 쓰던 bash를 쓰던 접근하기 편한 장소에 위에서 만들어 뒀던 레포를 clone해 두자. 나도 내 개인 계정에 Sampleapp-for-blog라는 이름의 저장소를 만들고, GitKraken을 통해 clone받았다.

지금까지

  • 버전 관리 시스템으로 Git을 사용하기 시작했다.
  • Git 웹호스팅 서비스로 GitHub를 사용하기 시작했다.