35P by xguru 2달전 | favorite | 댓글 2개

Graphite 개발자 Greg Foster가 이에 관심을 가진 이유

  • 그는 페이스북 내부 도구에서 영감을 받아 Graphite 프로젝트를 시작
  • 페이스북 출신 동료들이 Mercurial과 "stacked diffs" 워크플로우에 대해 소개한 후, GitHub 개발자들을 위해 이를 도입하기로 결정하고, 결과적으로 Hg의 아이디어를 Git에 통합한 CLI를 만들었음
  • 왜 페이스북은 Git 대신 Mercurial을 채택하고 그 위에 커스텀 워크플로우를 구축했을까 ?
  • 구글도 Git을 사용하지 않지만, 그건 Google의 엔지니어링이 Git보다 5년 이상 앞서 있기 때문
  • 반면에 Facebook은 Git이 만들어진 시기와 비슷한 시기인 2004년에 설립되었으며, Facebook이 소스 제어 도구를 진지하게 검토할 무렵에는 Mercurial보다 Git이 더 인기가 있었음
  • 그런데 왜 Facebook은 Git을 사용하지 않을까?
  • 그의 생각에 Facebook이 Git을 도입하고 2010년대 초반에 기여했다면 엔지니어링 세계는 달라졌을 것
    • Git이 더 사용자 친화적이고, 네이티브하게 Stacked Changes를 지원하게 되었을 수도
    • 초기 페이스북 직원들이 만든 Uber와 Pinterest 같은 회사들도 Mercurial 대신 Git과 GitHub를 소스 컨트롤로 사용하여 지난 10년 동안 덜 파편화된 생태계를 만들었을 것
  • 하지만 Facebook은 (기본 모노리포지토리를 위해) Git을 고수하지 않았음. 대신 버전 관리를 위해 Mercurial을 채택하고 그 위에 사용자 지정 도구를 점진적으로 추가함
    • 페이스북에 올라온 Scaling Mercurial at Facebook 글을 발견
    • 10년전 글이고, 그 이후에 몇개의 유튜브를 통해서 "성능 때문이지" 라는 해답을 얻었음
    • 하지만, 더 깊게 들어가서 그 당시 결정권자들의 생각을 들어보고 싶었고, Mercurial 마이그레이션 프로젝트에 참여했던 두명의 엔지니어에게 물어봤음
    • 그들과의 비공식적인 얘기를 통해 이 내용을 정리함

페이스북이 Git을 버리고 Mercurial로 이주한 이유

  • 페이스북은 처음에 Git을 사용했으나, 2012년경 코드베이스 규모가 커지면서 성능 문제를 겪기 시작
  • Git의 파일 "stat-ing" 과정이 병목 현상을 일으키며, 기본 Git 명령어 실행 시간이 45분 이상 소요
  • Git 유지보수자들은 페이스북의 대규모 리포지토리 문제에 대해 협력적이지 않았고, 대신 리포지토리 분할을 권장

고려된 대안들

  • 2012년 당시 Git의 대안은 많지 않았으며, 페이스북은 Perforce와 같은 폐쇄 소스 솔루션을 고려했으나 기술적 문제가 있었음
  • Mercurial은 Git과 유사한 성능을 가졌으나, 더 깔끔한 아키텍처와 확장성을 가지고 있었음
  • 페이스북 팀은 Mercurial 해커톤에 참여하여 Mercurial의 확장성과 커뮤니티의 개방성에 감명받음

전체 엔지니어링 조직의 이주

  • 페이스북 팀은 나머지 회사를 설득하기 위해 Git과 Mercurial 간의 명령어 및 워크플로우를 매핑하고, 개발자들의 우려를 듣는 시간을 가짐
  • 이주 과정은 신중하게 진행되었으며, 결국 페이스북은 Mercurial로 전환함
  • 페이스북은 Mercurial의 성능을 향상시키고, "stacked diffs"를 통해 코드 리뷰 병렬화를 가능하게 하는 등의 기여를 함

마무리 생각

  • 이 이야기는 "많은 주요 기술적 결정은 기술이 주도하는 것이 아니라 사람이 주도한다"는 점을 상기시킴
  • 페이스북은 Mercurial이 Git보다 성능이 뛰어나서가 아니라, Mercurial 유지보수자들과의 협업이 더 개방적이었기 때문에 선택함
  • 전체 엔지니어링 조직을 설득하는 과정에서 한 기술이 다른 기술보다 더 우수해서가 아니라 "사려 깊은 커뮤니케이션"이 중요했음
  • "소통과 친절함"이 개발 도구 세계에서 중요한 가치임을 강조

리누스 토발즈가 리눅스 소스코드를 관리하려고 만든게 Git이다보니 어느 정도 타협할 수 없는 부분이 있었을거라 생각합니다.
마무리 생각의 요지가 마치 Git은 Facebook 자신들의 요구를 듣지 않아 소통과 친절함을 중요시하지 않았으므로 나쁘다는 것처럼 들리는데, 그냥 여러 측면에서 성향이 서로 달랐을 뿐이라고 저는 생각합니다.
역으로 생각하면 Facebook은 Git이 권장한 리포지토리 분할을 받아들이고 실행하는 방법도 남아있었습니다. 자신들이 원하지 않는 친절함이었을 뿐이죠.

지인 분이 말씀하신 "고객을 설득하기 위해선 효자손이 돼여한다"라는 말이 떠오르네요

너무날카로울 필요도, 너무 빠를 필요도, 너무 편할필요도, 너무 비쌀 필요도 없이 딱 원하는 곳을 긁어줄 수 만 있으면 그게 고객이 원하능 서비스라고 ㅋㅋ