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

- ;

Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)

여러분의 생각 (17개)

  1. kkung 댓글:

    앞으로 어찌될지는 모르겠습니다만, :) 본문에 언급하신 웹 서비스 개발에서 github를 이용하는 국내 케이스로 미투데이가 있습니다. 미투데이는 github와 더불어 lighthouse 무척 즐겁고 편리하게! 이용하고 있습니다.^^

  2. codian's me2DAY 댓글:

    꽃띠앙의 생각…

    github가 그런 것이군화~…

  3. wkpark's me2DAY 댓글:

    영구의 생각…

    차니님의 블로그를 오랫만에 가보니 Github, 코드 개발 기반 소셜 네트웍가 떴다. 그냥 sourceforge류겠구나 생각을 했었는데.. Ohloh는 개발자를 위한 social network였다면 Github는 sf.net의 강화된 social network판이랄까…

  4. wafe's me2DAY 댓글:

    wafe의 생각…

    Github, 코드 개발 기반 소셜 네트웍 :: Channy’s Blog. 개발하기 더 편리하게 해주는 개발….

  5. kss 댓글:

    깔끔한 정리 감사합니다. http://dev.naver.com/projects/nforge 에 git도 지원할 수 있게 하려고 하는데 좋은 참고가 되겠네요~

  6. JNine 댓글:

    재미있는 내용이군요. 이제 네트워킹은 시대의 대세인가 보군요.

  7. Graffiti Paper # 02 – 2009.01.13…

    EDITOR’S COMMENT 무슨 날씨가 이리 추운지 모르겠습니다. 아침에 거의 동태가 된 상태에서 점심이 지나서야 겨우 몸이 해동이 되는 것 같습니다. 원래 추위를 잘 안타는 체질이고 더위에 기를 못펴는 스타일인데 갑자기 추워지니 정신이 오락가락 한가 봅니다. 그건 그렇고 벌써 그래피티 페이퍼가 2호를 발행했습니다. 네네~~ 돈 한푼 안들어가니 부도날 걱정은 없다만 이틀 연속으로 발행을 하다니…처음엔 다 의욕적인 법이죠….풉… 이 …

  8. LieBe 댓글:

    글 잘 읽었습니다.
    제 포스트에 담고서 트랙백 보냅니다.
    관련글은 아니지만 인용한 흔적을 남겨드리려고…^^

  9. allting 댓글:

    최근 구글 호스팅을 보니 리뷰 신청기능이 생겼더군요…다만 svn이어서 그런지 커밋이 아닌것으로 기억됩니다…ㅎ

  10. Zefyr 댓글:

    github에 대한 좋은 소개 잘 읽었습니다.
    감사합니다.!

  11. Google App Engine 시작하기 2/2…

  12. mz2guild의 생각…

    Github, 코드 개발 기반 소셜 네트웍 :: Channy’s Blog…

  13. […] 중요한 게 아니라 생활 속에서 필요한 코드를 짜서 공개하는 연습을 하고 github 같은 커뮤니티에 참여하는 것도 중요 합니다. Kestrel 같은 코드는 1500줄 밖에 안되는 포팅 […]

  14. 몽상동자의 생각…

    분산된 개발자 레포지터리에서 로컬로 개발과 테스트가 진행 된 후에 최종 단계에서 중앙 서버에 커밋을 하고 이를 코드 리뷰를 해 머징을 하는 형태…

  15. 김성준 댓글:

    git 와 github 를 개인 프로젝트를 개발하는 개발자 입장에서 사용한 사용기를 작성했는데, 관심있으신 분은 참고해보세요. (windows 환경에서 GUI 를 사용하는 것을 위주로 작성했습니다. 저도 써본지 얼마 안되서 잘 모르고 잘못 쓴 부분도 있을 수 있음을 주의해주세요)

    http://dev.azki.org/entry/Git-%EC%82%AC%EC%9A%A9%EA%B8%B0-windows-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-GIT-GUI-%EC%99%80-githubcom-%EC%9D%84-%EC%A4%91%EC%A0%90%EC%9C%BC%EB%A1%9C

  16. 괴짜시인의 생각…

    Github, 코드 개발 기반 소셜 네트웍…

  17. […] Git이라는 분산형 소스콘트롤이 나오고 나서 좀 변화가 시작되었다. 특히 소셜 기반 코딩 서비스, Github을 통해 그 변화는 엄청난 속도이다. 우리 회사에서도 Git을 기반으로 하는 […]