Browse Tag

레저큐 인턴기 3편 – EastskyKang 님이 leisureq/gajago에 push했습니다.

가자고는 매우 복잡하고 방대한 소프트웨어 시스템이다. 전체 소스코드가 500만 줄에 달하고 서브시스템(sub-system)이 5개가 넘는다. 아무리 뛰어나고 생산성이 높은 개발자라고 하더라도 이렇게 크고 복잡도가 높은 소프트웨어를 혼자서 개발할 수 없을 것이다.

가자고 팀에는 6명의 개발자가 있고, 이들이 협업하며 동시에 가자고 프로젝트를 개발한다. 그런데 여기서 잠깐 생각해보자. 도대체 어떻게 협업해서 소스코드를 작성하는걸까? 개발해야 하는 프로젝트는 하나인데 작업을 하고 있는 개발자는 여러명이다. 제일 먼저 상상할 수 있는 방법은 아마, 아래와 같은 모습일 것이다.

개발자 A와 B가 동시에 어떤 시스템을 개발하고 있는데 이들이 각자 다른 부분을 수정하고 있다. 이 프로젝트는 굉장히 잘 모듈화되어있고, 개발자들은 굉장히 전문화되어서 분업이 잘 이뤄지고 있다. 이들은 업무 시간 동안 열심히 코딩을 하고, 각자 수정한 부분을 퇴근하기 전에 합치는 작업을 수행한다. 야근이 잦지만 뭐, 아직까지는 양호하다.

쉽게 상상할 수 있는 그림이다. 그런데 문제가 생겼다.

어느날 개발자 A와 B가 실수로 동시에 같은 부분을 수정했다. 이때부터 문제가 생긴다. 아무리 비슷한 실력의 개발자더라도 생각하는 방식과 코딩 스타일이 크게 다르다. 이 둘은 서로 ‘충돌’이 난 부분을 모여서 같이 고치기 시작했고, 각자가 ‘같은 일’을 하도록 짠 코드가 완전히 다르게 작성되었다는 것을 깨달았다. 기억을 더듬어 일일히 수정한 코드를 한줄한줄 비교해봐도 어떻게 코드를 합치는 작업을 해야할지 결정하기가 쉽지 않다.

불쌍한 개발자 A와 B가 밤샘 작업을 통해서 수정하고 합치는 작업에 성공했다고 해보자. 그러나, 만약 개발자가 2명이 아니라 5명으로 늘어난다면 어떨까? 전체 시스템의 코드가 100만, 1000만 줄에 육박한다면 어떨까?

panic
다 망해버려라! (이미지 출처: http://www.itworld.com)

개발자의 영원한 친구 Git과 GitHub

다행히도 세상에는 버전 컨트롤 시스템(Version Control System)이라는 훌륭한 것이 존재한다. 이름에서 유추할 수 있듯이, 개발자가 작성한 소스코드의 버전을 관리하고 협업을 가능하게 해주는 시스템이다. Git이나 Subversion, Mercurial 등이 여기에 속한다.

가자고는 근래의 많은 개발 프로젝트들이 그렇듯이, Git이라고 불리는 VCS를 사용하고 있다. 참고로 Git은 Linux의 아버지, Linus Torvalds가 발명한 것이다. 리눅스 커널(리눅스 OS의 핵심부)을 개발할 때 전 세계 수많은 개발자들의 협업과 배포 버전 관리를 할 수 있는 방법이 필요했는데 적당한 방법을 찾지 못해 짜증이 난 Torvalds가 무려 2주만에 Git을 개발했다고 한다.

linus_torvalds_nvidia_fxxk_you
현존하는 가장 위대한 프로그래머, 오픈소스계의 영원한 아이돌, Linus Torvalds. (Linus Torvalds를 구글에 검색하면 제일 위에 이런 사진이 뜨는데 어떤 상황이었는지는 이 글을 참조…)

마이크로소프트 (악의 제국…) 페이스북, 트위터, 모질라 등 굵직굵직한 기업과 단체에서 Git을 사용하고 있다. 뿐만 아니라 전 세계의 수많은 개발자들, 학생들도 Git을 이용해서 소스코드를 관리한다.

Git의 방식은 프로그래머가 소스코드를 수정하고나서 ‘커밋'(commit)을 하면, 그 때까지의 수정 기록들을 커밋 단위로 모두 저장하는 것이다. 따라서 열심히 수정한 소스코드가 날아가버릴까봐 걱정할 필요도 없고, 지금 작업한 것을 버리고 예전 버전의 소스코드로 되돌리는 것도 자유롭게 할 수 있다. 뿐만 아니라, 버전을 분기시켜서 별도로 관리할 수도 있다. 커밋을 줄줄이 이어놓은 것을 하나의 ‘브랜치'(branch)라고 하는데 이 branch를 새로 분기시켜서 새로운 버전의 소스코드를 작성하는 것이다.

git_branch
Git branch. Git에 대해서 더 자세히 알고싶다면 여기 혹은 여기을 참조하시길… (이미지 출처: git-간편안내서)

여전히 풀리지 않는 의문이 하나 있다. Git을 써서 소스코드의 버전을 관리하기 좋다는 것은 알겠는데 어떻게 여러명의 개발자들이 Git으로 협업을 할 수 있는 걸까? 이런 의문에 대한 답이 Git 원격저장소(Git remote)라고 불리는 기능이다. 쉽게 말하면 서버나 클라우드 어딘가에 Git 저장소를 만들어놓고 여러명의 개발자들이 접근 할 수 있도록 하겠다는 것이다. 이런 Git 원격저장소를 호스팅하는 서비스가 여러군데 있는데 이 중에서 제일 유명한 것은 당연 자유소프트웨어의 성지(?)라고 불리는 GitHub이다.

github_logo
깃허브의 로고. (문어고양이…?) 깃허브는 social coding을 표방한다. 개발자들이 사진이나 글 대신에 소스코드를 공유하고 같이 협업하는, 즉 개발자들의 SNS이다.

GitHub는 개발자들이 무료로 git 저장소를 만들고 접근할 수 있도록 해준다. 다만 전제조건이 있는데, 무료 저장소는 모든 유저들이 볼 수 있도록 공개로 해놓아야한다. 이런 특성 때문에 많은 오픈소스 프로젝트들이 GitHub를 이용해서 git 저장소를 호스팅한다. 참고로 2016년 기준으로 가장 인기 있는 github 오픈소스 저장소는 트위터에서 만든 웹 UI 프레임워크 bootstrap, 구글의 angular.js, 페이스북의 react 등이다.

가자고도 GitHub를 이용하는데 우리의 소중한 소스코드를 누구에게나 공개할 수는 없기 때문에 GitHub의 기업용 유료계정을 통해 Git 저장소를 비공개로 관리하고 있다. 각 개발자들은 GitHub에 올라가 있는 Git 저장소를 자신의 개발머신에 ‘복제'(clone) 하고 자신의 커밋을 GitHub 저장소로 ‘푸쉬'(push) 하는 식으로 공동작업 한다. 이 과정에서 ‘풀 리퀘스트'(pull request)라는 기능을 사용하기도 하는데, 간단히 말하면 개발자가 자신이 개발하려는 기능을 아예 새로운 브랜치 에 만들어놓고 코드 리뷰를 요청하는 것이다. 이 브랜치는 프로젝트의 ‘마스터 브랜치'(master branch: 프로젝트의 기본 브랜치. 보통 실 서버에서 운영하고 있는 어플리케이션의 코드에 해당)와는 별도로 운영되기 때문에 코드 리뷰를 한 사람이 머지하기 전까지는 서비스에 아무런 영향을 끼치지 않는다.

github_gajago_repository
GitHub에 올라가 있는 가자고 저장소. 얼마전에 1주년을 맞이했다.

EastskyKang pushed to master at leisureq/gajago

나도 Git와 GitHub를 꽤 오래 전부터 써오고 있었다. 다만 지금까지 협업을 할 만큼 복잡한 시스템을 개발해 본 적이 없었기 때문에 늘 Git 저장소를 혼자서 썼을 뿐이다. 앞에서 얘기했듯이 혼자서 쓰더라도 Git과 GitHub는 굉장히 훌륭하다. 적어도 아래 그림과 같은 상황은 생기지 않는 것이다.

version_management_failured
최종…최종…최종… 버전관리 실패의 예 (이미지출처 : http://slowalk.tistory.com/)

하지만 역시 Git과 Github의 진가는 여럿이서 동시에 개발을 할 때 발휘된다. 특히 Git을 효과적으로 쓸 수 있게 해주는 몇가지 툴을 함께 사용한다면 여러명이서 동시에 개발하면서 발생할 수 있는 비효율(위에서 우리의 개발자 A와 개발자 B가 겪었던…)을 거의 느끼지 않고 협업을 할 수 있다. 심지어 각자가 고친 소스코드를 리뷰하고 함께 고민하는 과정에서 자연스러운 성장을 경험하기도 하고, 이전에는 찾을 수 없었던 문제들을 발견해내어 고치기도 한다. 1+1 = 1.5 였던 것이 1+1 = 3 정도가 되었다고나 할까…

나의 첫 커밋은 회사에 입사한지 정확하게 4일 뒤에 이루어졌다. 수정한 코드 라인은 정확하게 1줄… 고작 이 한줄을 고쳤을 뿐인데도 혹시나 내가 수정한 코드 때문에 서비스에 장애가 날지도 모른다는 걱정에 덜덜 떨면서 커밋을 했던 기억이 난다. (물론 모바일 앱의 개발에 필요한 플러그인을 추가해준게 다라서 뭔가 문제가 있었더라도 아무일도 일어나지 않았을 것이다 ^^;)

first_commit
가자고 저장소에 등록된 나의 첫 커밋. 수정한 줄수는 정확히 한줄.

6개월이 지난 지금, GitHub에 기록된 EastskyKang의 커밋은 총 197번. 대략 20000 줄의 코드를 추가하거나 수정했고, 수정의 범위도 예전에 비해서 훨씬 넓어졌다. 참으로 장족의 발전이 아닐 수 없다 🙂

이제는 매일같이 브랜치를 새로 만들고, 코드를 수정해서 풀 리퀘스트를 만들고 이슈와 코멘트를 남기고 브랜치들을 머지하고 있다. 때로는 고급 Git 기능들을 이용하기도 한다. 하지만 이 기간동안 내가 배운 것은 단순히 프로젝트를 이해하고 Git을 쓰는 법을 배운 것 뿐이 아니었다. 이 과정에서 자연스럽게 여러명의 개발자들과 협업하고 같이 프로젝트를 발전시켜가는 방법을 배울 수 있었다.

협업은 혼자서는 절대 할 수 없었던 일들을 가능하게 해준다. 특히 개발 프로젝트에서의 협업은 때로 1+1 > 3 의 기적을 만들어내기도 한다. 개발자들은 항상 어떻게 해서 협업의 효율성을 높이고 협업의 생산성을 높일지 늘 고민한다. Git과 GitHub도 그런 개발자들의 문화와 오랜 고민에서 탄생한 결과물이라고 할 수 있을 것이다.

협업의 중요성과 더 나은 협업에 대한 고민, 내가 가자고 팀에서 인턴을 하면서 얻을 수 있었던 가장 소중한 배움이다.

by EastskyKang