GitHub와 소프트웨어 개발 문화

Git이나 Subversion과 같은 소프트웨어 버전 관리시스템은 소프트웨어 개발 문화와 상당히 밀접한 관계가 있습니다.

이러한 버전 관리 시스템의 스펙이나 사용방식 등은 이것들을 개발했을 당시에 추구된 소프트웨어 개발 문화를 그대로 담고 있습니다.

CVS와 Subversion

초기에는 파일을 여러벌 가지고 있지 않아도 되고, 최소한의 용량으로 파일의 버전을 관리할 수 있는 RCS(Revision Control System)이 나왔습니다. 이때는 그냥 파일의 버전을 관리하는 것만으로도 감지덕지였죠. 이걸 NFS 같은걸로 원격에 있는 저장공간을 마운트하여 여러 사용자가 작업을 했다고 합니다.

RCS를 NFS를 통하여 쓰자니 불편하게 짝이 없죠. 그래서 RCS를 네트워크상에서 좀더 편하게 사용할 수 있도록 만든 것이 CVS입니다.

이후 꽤 오랬동안 오픈소스 개발에는 CVS를 많이 사용해왔습니다. 하지만 CVS는 여러가지 단점들이 있었고, 이 단점들을 개선해보고자 Subversion이 만들어지게 됩니다. 하지만 이 때 까지도 CVS의 단점들만 개선했을 뿐 개발 방식이나 문화는 달라진 것이 없었습니다.

CVS는 파일 단위 개발에 국한 되어있고, Subversion도 파일 단위 개발 방식의 단점을 개선하였지만 디렉터리 경로 기반 방식에서 벗어나지 못했습니다.

따라서 브랜치도 기존 기반 위에서 덧붙인 형태로 개발될 수 밖에 없었습니다. CVS는 브랜치를 하면 RCS 파일 하나하나에 브랜치를 했다는 표시를 남깁니다. 그래서 파일이 많으면 브랜치 하는데만 엄청난 시간이 소요되었습니다.

Subversion은 이 시간을 단축시키고자 RCS 포맷을 버리고 Changeset과 Snapshot으로 파일과 디렉터리를 관리 했습니다. Subversion에서 브랜치는 단지 trunk의 특정 리비전을 branches 디렉터리 아래에 링크를 거는 것과 같았습니다. 브랜치 전환은 디렉터리 경로를 달리하여 소스를 받는 것입니다. 그렇기 때문에 Subversion을 디렉터리 경로 기반 방식이라고 한 것이죠.

CVS와 Subversion를 쓰는 개발 문화는 메인 소스를 네트워크상에서 여러명이 공유하여 작업한다는데 초점이 맞춰져 있습니다.

Git

리누스 토발즈는 리눅스를 개발하면서 BitKeeper라는 버전 관리 시스템을 사용했습니다. 하지만 몇가지 분쟁들로 인해 Git이라는 버전 관리 시스템을 직접 개발하기에 이릅니다.

리눅스가 처음 개발될 당시에는 이메일로 Patch(diff 포맷) 파일을 받아서, 전세계 개발자들의 구현물을 전달 받았습니다. 지금도 마찬가지이지만 Git으로 인해 좀더 편리해졌습니다.

Git의 기능을 살펴보면 리눅스 커널 개발에 특화되었다는 것을 알 수 있습니다. 먼저 분산형 저장소를 기본으로 하고 있는데, 각 개발자들의 자신만의 저장소를 가지고 실험적인 구현을 해보고 최종적인 결과물만 리누스 토발즈에게 제출하는 방식입니다. Git에는 format-patch라는 명령이 있어서 리눅스 메일링 리스트에 올리기 적합한 형태로 Patch 파일을 만들어줍니다. git send-email 명령으로 Patch 파일을 바로 메일링 리스트에 보낼 수도 있습니다. Patch 파일을 받는 사람도 git am 명령을 통해 이메일로 받은 Patch 파일을 바로 커밋 할 수 있습니다. 이때 패치를 작성한 사람(Author)과 커밋한 사람(Committer), 패치를 확인한 사람들의 이름과 이메일 주소가 모두 올라갑니다.

Git의 브랜치는 논리적인 브랜치라 할 수 있는데, 이 브랜치를 저장소 끼리 주고 받을(Push, Pull) 수 있도록 되어 있습니다. 앞서 설명한 것 처럼 Subversion은 소스의 경로를 trunk 혹은 branches로 구분함으로써 브랜치를 관리했지만 Git은 소스트리가 한가지 밖에 없습니다. 브랜치를 전환(Checkout)하면 이 소스트리의 내용이 바뀌는 것이죠.

Git이 나왔을 당시만 해도 CVS나 Subversion에 비해 개념이 복잡하고 사용방법이 어려웠던 것이 사실입니다. 농담삼아 떠돌던 말이 Git을 사용하려면 IQ가 150이 넘어야 된다는 것이었습니다.

아래 설명할 GitHub가 나오기 전까지는 Git은 그저 리눅스 커널 개발자와 몇몇 개발자들만이 쓰던 마이너한 버전 관리 시스템이었습니다.

GitHub

2008년 Git을 무료로 호스팅해주는 GitHub라는 사이트가 만들어지게 됩니다. 오픈소스 개발공간을 호스팅해주는 사이트는 SourceForge를 비롯해 여러가지가 있었습니다.

하지만 GitHub가 오픈소스 개발문화를 180도 바꾸어 놓았습니다. 웹에서 클릭 만으로 오픈소스 저장소를 Fork(clone)할 수 있었고, Git의 브랜치 혹은 수정된 내용을 웹에서 쉽게 주고 받을 수 있도록 Pull Request 기능을 만든 것입니다.

저는 이 Pull Request 기능이 오픈소스 참여에 엄청난 기여를 했다고 생각합니다. 그 이전까지만 하더라도 오픈소스 프로젝트의 메인 저장소를 CVS나 Subversion으로 쓴다고 하더라도 해당 프로젝트에 참여하려면 Patch 파일을 보내는 수 밖에 없었습니다.(Patch 파일을 받는 개발자 입장에서도 상당히 귀찮았습니다. Patch 파일이라는 것이 라인 하나라도 맞지 않으면 Patch 파일 적용에 실패합니다. 그렇기 때문에 대규모 Patch 파일은 적용하고 테스트 해보기가 정말 까다롭습니다.)

Patch 파일을 보내지 않고 프로젝트의 저장소에 직접 소스를 커밋하려면 "커미터"라고 해서 저장소의 쓰기 권한을 얻어야 합니다. 이 커미터 권한을 얻기까지 진입장벽이 높기 때문에, 많은 사람들이 오픈소스에 기여하는 것을 포기하곤 했습니다.

하지만 GitHub가 생긴 이후로 관심있는 프로젝트를 Fork 한 뒤에 자신의 저장소에서 작업을 하고 Pull Request 하는 것만으로, 원하는 프로젝트에 기여하는 것이 쉬워졌습니다. 즉 Pull Request는 Patch 파일 제출과 이슈 등록을 한꺼번에 하는 것과 같습니다. 받아들이는 프로젝트 개발자 입장에서도 클릭 한번만으로 수정된 소스를 메인 저장소에 반영할 수 있으니 정말 편리해졌습니다.

그래서 요즘은 GitHub를 보더라도 커미터라는 개념이 희박해졌습니다. GitHub에 있는 오픈소스 프로젝트의 메인 개발자는 직접 개발해서 커밋하는 것 뿐만 아니라 다른 사람이 올린 Pull Request를 처리해주는 작업을 많이 합니다.

마치며

필요에 의해 만들어진 Git이라는 도구가 GitHub라는 사이트로 발전했고, GitHub는 개발 문화를 바꿨다는 점에서 경이로움을 느낍니다. 앞으로 어떤 획기적인 도구와 개념이 나올지 기대가 됩니다.