Github, 코드 개발 기반 소셜 네트웍 (퍼온글)

지난 주 The Crunchies 2008 시상식에서 아주 눈에 띄는 분야와 수상작이 있었습니다. 바로 자수 성가형(Bootstrapped) 스타트업 분야에서 GitHub가 수상한 것이죠.

gitHub는 한마디로 ‘소셜 소스 코드 공유’를 모토로 한 분산형 협업 개발 호스팅 서비스 입니다. 생소한 개념 같지만 한마디로 ‘오픈 소스 개발 모델’에다가 요즘 한창 유행인 ‘소셜 네트웍’을 접목했다고 보시면 됩니다.

git는 2006년경 BitKeeper라는 리눅스 커널 개발에 쓰든 분산형 패치 도구에 대한 대안으로 리누스 토발즈가 직접 개발한 분산형 소스 콘트롤(Source Control Management)인데, gitHub가 하는 일은 이 git를 기반으로 한 프로젝트 호스팅입니다.

github이 기존 프로젝트 관리를 주목표로 하는 기존 포지(Forge) 계통의 SourceForge나 Google Code와 다른 점은 소스 코드 개발과 패치에 초첨을 맞추고 소셜 네트웍 기능을 접목해서 프로젝트의 개인별 코드 개발 상황을 바로 바로 알려주고 서로 연결해 주고 업데이트해 주는 기능을 편리하게 만들어 주는 것입니다.

분산형 SCM 모델의 장점
소스 코드 개발에 있어 프로젝트 보다 ‘개인이 주체가 되는’ 시스템인데 이때 왜 git 같은 분산형 SCM을 쓰게 되었나 간단하게 소개를 해야 될 것 같네요. 기존의 CVS나 SubVersion은 중앙의 소스 레포지터리를 두고 각 개발자가 복사(Checkout)해서 개별 작업 공간(Workspace)에서 개발한 코드를 중앙으로 올려 보내는(Check-in) 형태였습니다.

이에 반해 git, mercurial, bazaar 같은 SCM들은 개발 개발자들이 직접 레포지터리를 복제(Clone)해 운영하면서 각자 개발을 하고 필요한 부분을 중앙 레포지터리에 보내는(Push) 방식을 이용합니다.

이렇게 되면 대형 프로젝트에서 원격 개발자 혹은 개별 그룹이 좀 더 원활하게 개발을 할 수 있습니다. 대표적으로 git는 리눅스 커널, mercurial은 Mozilla 프로젝트, bazaar는 MySQL의 SCM으로 이용하고 있지요. 대형 오픈 소스 프로젝트의 경우, 코드 베이스가 크고 복잡하기 때문에 개별 개발자가 유지 관리하기에 속도도 느리고 오프라인 시 개발도 힘든 점이 있습니다. 그래서 분산형 SCM의 요구 사항이 생기게 되었습니다.

github, 투명한 소스 코드로 말하는 사회
그런데, gitHub는 소규모 프로젝트에서도 git를 써야할 이유를 만들어 주었습니다. 일반적으로 오픈 소스 프로젝트에서 코드를 분리해 따로 개발을 하는 이른바 포킹(forking)은 커뮤니티가 깨지는 경우가 아니면 잘 일어나지 않습니다. (포킹은 꽤 불명예스러운 일이기도 하죠.)

github는 포킹을 오히려 장려(?) 합니다. github의 대표적인 프로젝트가 Ruby on Rails, Prototype 그리고 Scriptaculous 인데요. 대략 RoR의 경우 400회 이상의 포킹(Forking)이 이루어졌으니 그만큼의 개발자들이 개발에 참여하고 있구요. 700여명의 개발자들이 활동 사항을 주목(Watch)하고 있는 중입니다.

포킹을 통해 개발자들이 각자 소소 레포지터리를 운영하면서 완성도 높은 코드를 중앙으로 밀어 줌으로서 소스 코드 개발을 기반한 인간 관계를 통한 사회적 활동으로 이용하고 있습니다. 이른바 “코드 개발로 말하는 소셜 네트웍”인 셈이죠. 특히 페이스북처럼 친구들의 개발 내역을 상세하게 볼 수 있고 코멘트도 해 줄 수 있습니다.

누가 활발하게 활동하고 있는지 단박에 알아볼 수 있는 열린 시스템을 가지고 있는 것이죠. 특정 프로젝트에 필요한 구현 내용을 정확히 파악하고 이를 뒷받침하는 개발 실력과 퍼포먼스 만이 이 세계에서 중요한 잣대가 됩니다.

예전에 제가 오픈 소스 프로젝트는 ‘요구 사항이 없는’ Exceptional Software Methodology을 따른다는 Robert Lefkowitz의 가설(?)을 소개해 드린 적이 있는데, github는 딱 그것처럼 버그 트래커가 없습니다. 일단 구현이 최고죠. 이게 있으면 좋겠다 싶은 걸 일단 구현하고 밀어 보내보고 받아주면 좋고 아니면 말고… 위키가 있는데 가끔 구현 했으면 좋겠다는 소망 목록(Wish list)정도를 관리하더군요.

웹 서비스 개발에 적합한 모델
제가 꽤 github가 멋지다고 생각하는 부분은 소셜 네트웍 아이디어 뿐만 아니라 개발 시 자주 있는 문제점을 도와줄 웹 기반 도구들 때문입니다. 특히 각 개발자가 보내준(Push) 코드를 웹으로 검토하고 처리하거나 코멘트를 해주는 기능이 그렇습니다. 따라서 github는 레포지터리에 잦은 커밋이 일반적으로 행해지는 웹 기반 서비스 개발의 문제점을 해결해 주는 방법이 될 것 같네요.

웹 개발 시에는 뷰(View)쪽 코드가 자주 변경되기 때문에 커밋이 잦은 편입니다. 따라서 SCM이 거의 개발 로그나 백업 정도를 벗어나지 못하는 경우가 많습니다. 이 방법을 해결하기 위해서는 브랜칭을 잘해서 코드 개발을 하고 이를 다시 머징하는 약간 복잡한 방식을 써야 하는데요. SE 전문가인 김성훈 박사도 브랜칭과 머징을 편리하게 해줄 도구가 필요하다고 인정하는 바였습니다.

그런데, 분산된 개발자 레포지터리에서 로컬로 개발과 테스트가 진행 된 후에 최종 단계에서 중앙 서버에 커밋을 하고 이를 코드 리뷰를 해 머징을 하는 형태는 형적인 웹 개발에 아주 적합한 방식이죠. 웹 서비스 개발에서 github 유료 호스팅을 시범적으 써보면 어떨까 싶은데, 유료 호스팅 모델도 가지고 있기 때문에 The Crunchies 2008 수상에 아주 큰 도움이 된 듯 합니다.

코드 리뷰와 패치 검토를 웹 기반에서 하는 것 또한 좋습니다. 이런 도구가 없어서 코드 리뷰를 빼먹고 넘어 가는 경우가 허다하니까요. 과거 구글에서는 메일로 코드 리뷰를 했다고 하더군요. 메일에 답장에 허가라고 하면 패치가 승인 됐다고. 하지만, 요즘에는 구글과 야후에서도 github 처럼 별도의 웹 기반 코드 리뷰 시스템을 가지고 있다고 합니다.

github는 앞으로도 개발자들이 참여할 만한 동기 유발(Motivation)이라는 중요한 미끼를 잘 던지고 있는 것 같습니다. 최근 RoR 뿐만 아니라 OSX 개발자들도 github에 많이 들어오고 있는데 대형 프로젝트 몇 개만 더 섭외(?)를 하면 소스포지(SouceForge)나 론치패드(LaunchPad)에서 진입 러시가 있지 않을까요?

p.s. 구글의 크리스 디보나가 “(소스포지에 대해) 하나의 기업이 그토록 큰 오픈소스 인프라를 가지고 있다는 것은 권력이라고 생각한다. 그래서 내가 ‘백업’ 역할을 해야겠다고 생각”해서 구글 코드를 만들었다고 했는데 또 하나의 백업이 생긴 셈이네요.

출처 : http://channy.creation.net/blog/626