이맥스가 Git 대신 Bazaar를 붙잡았던 6년짜리 오픈소스 드라마

• 이맥스(Emacs)가 Git으로 오기까지는 그냥 “도구 바꿨다” 수준이 아니라, 거의 6년짜리 오픈소스 정치극에 가까웠음

  • 2008년 이맥스는 CVS에서 벗어나 더 현대적인 버전 관리 시스템으로 옮기려 했고, 후보는 Git과 Bazaar였음
  • Git은 리누스 토르발스가 리눅스 커널 개발을 위해 만든 도구였고, Bazaar는 Canonical이 관리하던 GNU 프로젝트였음
  • 여기서 이미 기술 선택과 GNU 정체성이 정면충돌할 판이 깔림

• 성능 비교는 꽤 잔인했음. 숫자만 보면 Git 압승이라 반박하기 어려운 수준

  • git log | head -1은 0.012초였는데, Bazaar의 같은 작업은 21.5초가 걸렸음
  • 단일 파일 변경 커밋도 Git은 0.08초, Bazaar는 17초였음
  • 한 핵심 개발자는 “bzr log가 시작하는 데만 1분 넘게 걸리는데, CVS 로그보다도 느리다”는 식으로 반응함

• Bazaar 쪽 개발자도 스레드에 들어와서 도와줬지만, 추천 워크플로 자체가 이미 웃픈 상태였음

  • 초기 체크아웃을 위해 wget으로 tarball을 받고, 압축을 풀고, 저장소를 초기화하고, 브랜치를 만들고, 다시 pull을 기억시키는 절차가 제안됨
  • 비교 대상은 그냥 git clone 한 줄이었음
  • “이 정도면 Bazaar가 지금 적합하지 않다는 걸 설득하려면 대체 뭐가 더 필요하냐”는 질문이 나올 만했음

• 그런데 리처드 스톨먼(Richard Stallman)의 결론은 명확했음. 이맥스는 GNU Bazaar를 써야 한다는 것

  • RMS는 “이건 현재 순간만을 위한 결정이 아니라 장기 결정”이라며 Bazaar 개발자들이 개선할 시간을 주는 게 낫다고 봄
  • 그리고 더 직접적으로는 “이 문제는 끝났고 결정됐다. GNU 패키지니까 GNU Bzr을 쓴다”고 말함
  • 누군가 “이건 기술적 논거를 전부 지워버리는 정치적 결정 아니냐”고 지적하자, GNU 패키지끼리 서로 지원해야 GNU 시스템 전체가 더 잘 굴러간다고 답함

• RMS의 논리 자체는 완전히 허무맹랑한 건 아니었음. 문제는 Bazaar가 그 원칙을 감당할 만큼 좋은 도구가 아니었다는 것

  • GNU의 대표 프로젝트가 GNU 도구를 안 쓰면 “우리 도구도 못 믿는다”는 신호를 줄 수 있음
  • 자유 소프트웨어 생태계를 자급자족 가능한 형태로 만들자는 철학에서는 일관된 주장임
  • 다만 개발자 입장에서는 매일 쓰는 도구가 느리고 불안정하면 철학보다 bzr diff 대기 시간이 먼저 체감됨

Bazaar에 묶인 시간

• 2008년 이후 바깥세상은 빠르게 Git으로 이동했음

  • GitHub가 2008년에 등장했고, 오픈소스 협업의 중심은 Git으로 폭발적으로 옮겨감
  • 반면 이맥스 기여자들은 패치를 보내려면 다른 데서는 거의 안 쓰는 Bazaar를 배워야 했음
  • “내 bzr 좀 풀어줘”, “이맥스 저장소를 bzr로 못 받겠다, 메모리 누수 같다” 같은 스레드가 반복됨

• 2012년에는 상황이 더 나빠짐. Canonical이 Bazaar 개발팀을 정리함

  • 도구가 느린 정도를 넘어서, 앞으로 유지보수가 제대로 될지 자체가 불확실해짐
  • 2013년 John Wiegley는 “Bazaar 개발이 사실상 멈췄고, 이맥스 개발에 영향을 주는 버그들이 몇 년째 방치돼 있다”며 Git 전환 논의를 다시 꺼냄
  • 특히 ELPA 저장소 관련 버그는 이맥스 개발에 직접적인 문제였음

• 2013년 논쟁에서도 RMS는 바로 포기하지 않았음

  • 그는 Bazaar 관리자가 버그를 고치고 있다고 들었고, 합리적인 시간을 주고 싶다고 말함
  • 그런데 그 버그는 이미 1.5년 된 문제였음
  • RMS는 “Bazaar가 효과적으로 유지보수되고 있는지 판단하려는 중이고, 가능하면 ‘그렇다’는 답을 얻고 싶다”고까지 말함

• 이 대목이 꽤 인간적이면서도 답답함. RMS는 자기 선호를 숨긴 게 아니라, 현실이 자기 원칙과 맞아떨어지길 바랐던 쪽에 가까움

  • 오래 Bazaar를 써온 기여자도 “커뮤니티는 친절하지만, 알려진 버그와 패치가 몇 년째 upstream에 안 들어간다”고 설명함
  • “Bzr 메일링 리스트를 읽으라”는 말은 현실적으로 “달에 갔다 오라”는 말과 비슷하다고도 함
  • 즉 도구를 쓰는 사람들의 고통은 이미 충분히 쌓여 있었음

• Karl Fogel의 비판은 이 논쟁에서 특히 날카로웠음

  • 그는 RMS가 Bazaar의 유지보수 상태를 제대로 평가할 시간과 정신적 여유가 없다면, 이맥스 유지보수자들에게 위임해야 한다고 지적함
  • 한 명에게 한 버그를 물어보는 건 프로젝트 건강도를 판단하는 방법이 아니라고 봄
  • RMS의 답은 짧았음. “여기엔 이맥스보다 더 많은 것이 걸려 있다.”

sequenceDiagram
    participant 기여자
    participant 이맥스유지보수자
    participant RMS
    participant Bazaar유지보수
    participant Git
    기여자->>이맥스유지보수자: Bazaar 성능과 버그 문제 제기
    이맥스유지보수자->>RMS: Git 전환 논의 요청
    RMS->>Bazaar유지보수: 유지보수 가능성 확인
    Bazaar유지보수-->>RMS: 일부 버그 수정 의사
    RMS-->>이맥스유지보수자: 더 기다리자는 판단
    이맥스유지보수자->>Git: ELPA 브랜치부터 이동
    Git-->>기여자: 2014년 전체 저장소 전환

결국 Git으로

• 2013년 ELPA 브랜치가 Bazaar에서 깨진 게 결정적인 현실 압박이 됨

  • 체크아웃이 크래시 나는 버그가 있었고, 고칠 사람이 사실상 없었음
  • Stefan Monnier는 ELPA 브랜치를 Git으로 옮기면서도 “trunk까지 Git으로 옮기자는 논의는 아니다”라고 선을 그음
  • 하지만 모두가 속으로 “ELPA가 Git이면 trunk도 Git이면 되는 거 아님?”이라고 생각했을 상황임

• 2014년에는 Eric S. Raymond가 변환 스크립트를 준비해 둔 상태였음

  • 그는 “힘든 일은 다 끝났고, 버튼을 누르기 8시간 전 통지만 있으면 된다”고 말함
  • 실제 마이그레이션은 2014년 11월에 이뤄짐
  • 전환 후 올라온 메시지는 딱 일곱 단어였음. “Commits are open. Have at it.”

• 아이러니하게도 Git으로 옮긴 직후에는 이맥스 핵심 기여자들 사이에서 Git 초보 질문이 쏟아짐

  • “git pull이 merge conflict로 실패한다. 이게 어떻게 가능하냐” 같은 질문이 나옴
  • “나머지 사람들을 위한 간단한 Git 워크플로”, “Git 좋은 책 추천”, “git pull의 이상한 경고 메시지” 같은 스레드도 이어짐
  • 세계에서 가장 중요한 텍스트 에디터 중 하나를 오래 개발해온 사람들이, Bazaar에 묶여 있느라 Git 시대를 늦게 맞은 셈임

• 이 사건의 씁쓸한 포인트는 “정치가 기술을 이겼다”에서 끝나지 않음

  • RMS의 GNU 원칙은 생태계를 지키려는 논리였고, 단기 편의만 좇는 판단은 아니었음
  • 하지만 도구의 품질과 유지보수 상태가 원칙을 따라오지 못하면, 그 비용은 추상적인 생태계가 아니라 실제 기여자 시간이 대신 냄
  • Leo Liu가 말한 것처럼 자원봉사자의 20% 시간이 Bazaar와 싸우는 데 쓰이면, 그건 GNU 전체에도 손해임

기술 맥락

• 이 사건에서 선택지는 단순히 Git이냐 Bazaar냐가 아니었어요. 이맥스라는 GNU 대표 프로젝트가 GNU 도구를 써야 하느냐, 아니면 당시 개발자들이 실제로 가장 효율적으로 쓸 수 있는 도구를 골라야 하느냐의 충돌이었거든요.

• Bazaar를 고른 이유는 성능이나 사용성보다 생태계 신호에 가까웠어요. GNU 프로젝트가 GNU 패키지를 외면하면 다른 GNU 도구의 신뢰도까지 흔들릴 수 있다는 판단이 있었고, RMS는 이 지점을 이맥스 하나보다 큰 문제로 봤어요.

• 반대로 Git 전환을 주장한 쪽은 매일의 개발 비용을 봤어요. 로그 조회가 0.012초와 21.5초로 갈리고, 커밋이 0.08초와 17초로 갈리면 이건 취향 문제가 아니라 기여 흐름을 막는 병목이 되거든요.

• 결정적으로 Bazaar의 유지보수 상태가 무너지면서 논쟁의 성격이 바뀌었어요. 느린 도구를 참고 쓰는 문제에서, 핵심 브랜치가 깨져도 고칠 사람이 부족한 인프라 리스크로 넘어간 거예요.

• 그래서 이 사례는 오픈소스 프로젝트가 도구를 고를 때 “우리 철학에 맞는가”와 “기여자가 계속 올 수 있는가”를 같이 봐야 한다는 교훈을 줘요. 원칙은 중요하지만, 그 원칙을 운영할 유지보수 역량이 없으면 결국 프로젝트 속도를 갉아먹게 돼요.