--- title: "이맥스가 Git 대신 Bazaar를 붙잡았던 6년짜리 오픈소스 드라마" published: 2026-05-12T21:40:55.000Z canonical: https://jeff.news/article/2583 --- # 이맥스가 Git 대신 Bazaar를 붙잡았던 6년짜리 오픈소스 드라마 이맥스는 2008년 CVS에서 벗어나면서 Git 대신 GNU 프로젝트인 Bazaar를 선택했고, 이 결정은 성능 벤치마크와 개발자 반발을 압도한 정치적 판단에 가까웠다. Bazaar는 느리고 유지보수도 흔들렸지만, GNU 패키지는 GNU 도구를 써야 한다는 원칙 때문에 전환은 2014년까지 미뤄졌다. 결국 ELPA 브랜치 문제와 Bazaar 개발 중단, 변환 스크립트 준비 끝에 이맥스는 Git으로 옮겨갔다. - 이맥스(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 로그보다도 느리다”는 식으로 반응함 > [!IMPORTANT] > 이 논쟁의 핵심은 “Git이 조금 더 빠르다”가 아니었음. 기본 개발 작업에서 수백 배 차이가 나는 상황에서도 최종 선택은 기술 벤치마크가 아니라 GNU 내부 원칙 쪽으로 기울었음. - 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의 답은 짧았음. “여기엔 이맥스보다 더 많은 것이 걸려 있다.” ```mermaid 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의 유지보수 상태가 무너지면서 논쟁의 성격이 바뀌었어요. 느린 도구를 참고 쓰는 문제에서, 핵심 브랜치가 깨져도 고칠 사람이 부족한 인프라 리스크로 넘어간 거예요. - 그래서 이 사례는 오픈소스 프로젝트가 도구를 고를 때 “우리 철학에 맞는가”와 “기여자가 계속 올 수 있는가”를 같이 봐야 한다는 교훈을 줘요. 원칙은 중요하지만, 그 원칙을 운영할 유지보수 역량이 없으면 결국 프로젝트 속도를 갉아먹게 돼요. ## 핵심 포인트 - 2008년 이맥스 개발진은 Git과 Bazaar를 비교했지만, 성능 수치상 Bazaar는 실무에 쓰기 어려울 정도로 느렸다. - 리처드 스톨먼은 기술적 벤치마크보다 GNU 패키지끼리 서로를 지지해야 한다는 원칙을 우선했다. - 2012년 Canonical이 Bazaar 개발팀을 정리하면서 유지보수 리스크가 현실이 됐다. - ELPA 브랜치가 Bazaar에서 제대로 동작하지 않자 일부 저장소부터 Git으로 이동했고, 2014년 전체 이맥스 저장소가 Git으로 전환됐다. ## 인사이트 이 이야기는 도구 선택이 단순히 벤치마크 싸움이 아니라 생태계, 정체성, 유지보수 비용의 충돌이라는 걸 잘 보여준다. 다만 원칙이 현실의 개발 경험을 계속 밀어내면, 결국 그 비용은 기여자들이 매일 치르게 된다.