# 가장 Emacs다운 Bzr 사가

> Clean Markdown view of GeekNews topic #29481. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29481](https://news.hada.io/topic?id=29481)
- GeekNews Markdown: [https://news.hada.io/topic/29481.md](https://news.hada.io/topic/29481.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-14T09:30:54+09:00
- Updated: 2026-05-14T09:30:54+09:00
- Original source: [thanosapollo.org](https://thanosapollo.org/posts/bzr-saga/)
- Points: 2
- Comments: 1

## Topic Body

- 2008년 Emacs는 CVS 이후 후보로 **Git**과 **Bazaar**를 검토했고, 벤치마크에서는 Git이 압도적으로 빨랐음
- Richard Stallman은 Bazaar가 **GNU 패키지**라는 이유로 선택을 확정했고, 기술적 논의는 결정을 바꾸지 못함
- 2008~2012년 GitHub가 성장하는 동안 Emacs 기여자들은 **Bazaar**를 배워야 했고, Canonical은 2012년 개발팀을 해고함
- 2013년 Bazaar 유지보수 정체와 **ELPA 브랜치** 버그가 재논의를 촉발했고, ELPA는 결국 Git으로 옮겨짐
- 2014년 Eric S. Raymond의 전환 작업 뒤 Emacs는 **Git**으로 이전했지만, 직후 핵심 기여자들의 Git 학습 문제가 드러남

---

### 2008년: Git이 빨랐지만 Bazaar가 선택됨
- 2008년 3월 Emacs는 **CVS**에서 더 현대적인 버전 관리 도구로 옮기려 했고, 후보는 **Git**과 **Bazaar**로 좁혀짐
  - Git은 Linus Torvalds가 Linux 커널을 위해 만든 도구였음
  - Bazaar는 Canonical이 유지보수하던 GNU 프로젝트였음
- emacs-devel에서는 **236개 메시지**짜리 논의가 이어졌고, 여러 개발자가 두 도구를 벤치마크함
  - [Andreas Schwab](https://yhetil.org/emacs-devel/jeprtyalxt.fsf@sykes.suse.de/)은 `bzr log`가 시작하는 데 1분 이상 걸려 “완전히 사용할 수 없을 정도로 느리다”고 평가함
  - David Kastrup은 `git log`가 거의 즉시 실행되는 반면, Bazaar는 파일 복사·이동·이름 변경 정보를 명시적으로 받기 때문에 더 빨라야 할 것처럼 보인다고 봄
- 실제 수치에서도 **Git 우세**가 뚜렷했음
  - `git log | head -1`은 **0.012초**, 같은 작업의 Bazaar 실행은 **21.5초**였음
  - 단일 파일 변경 커밋은 Git이 **0.08초**, Bazaar가 **17초**였음
- 당시 수석 유지보수자였던 [Stefan Monnier](https://yhetil.org/emacs-devel/jwvod9cq7av.fsf-monnier+emacs@gnu.org/)는 Bazaar가 Git보다 빠른지 느린지는 핵심이 아니지만, Emacs가 전환하려면 “충분히 빨라야” 하며 적어도 `bzr diff`가 몇 초 이상 걸리면 안 된다고 봄
- Canonical의 Bazaar 개발자 [Jonathan Lange](https://yhetil.org/emacs-devel/d06a5cd30803122130h4dedcfbdx2cf5dda7ebd507ee@mail.gmail.com/)는 초기 체크아웃을 위해 `wget`, `tar`, `bzr init-repo`, `bzr branch`, `bzr pull --remember`를 조합한 절차를 제안함
  - 이 절차는 `git clone`과 대비될 만큼 길고 수동적이었음

### GNU 도구를 써야 한다는 결정
- 누군가 Emacs 유지보수자와 의사결정자에게 “현재 시점에서 bzr이 적절한 도구가 아니라고 설득하려면 어떤 정보가 더 필요하냐”고 물음
- Richard Stallman은 이 선택이 현재 순간의 결정이 아니라 **장기 결정**이며, 되돌리기 어려운 임시 결정보다 Bazaar 개발자들이 개선할 때까지 몇 달 기다리는 편이 낫다고 답함
- Stallman은 [별도 메시지](https://yhetil.org/emacs-devel/E1JbhT2-0003HR-PP@fencepost.gnu.org/)에서 “이 질문은 끝났고 결정됐다. GNU Bzr를 사용할 것이다. 그것이 GNU 패키지이기 때문이다”라고 못박음
- 기술적 논거가 정치적 결정으로 지워진다는 문제 제기에 대해, Stallman은 [GNU 패키지끼리 서로 지원하는 규칙](https://yhetil.org/emacs-devel/E1JfqPy-00030x-I0@fencepost.gnu.org/)이 GNU 시스템 전체를 더 잘 작동하게 한다고 답함
- “Git을 GNU 시스템의 일부로 만들면 안 되냐”는 질문에는 Git을 GNU 시스템에 포함할 수는 있지만, Git 개발자들이 Git을 GNU 패키지로 만들고 싶어 할 가능성은 낮다고 봄
- 2008년의 벤치마크, 236개 메시지, Canonical 직원의 우회 절차에도 결과는 바뀌지 않았고, Emacs는 **GNU 패키지**라는 이유로 Bazaar를 택함

### 2008~2012년: Git 확산과 Bazaar 사용 부담
- 2008년 GitHub가 출범하고 빠르게 성장하는 동안, Emacs 기여자들은 패치를 제출하기 위해 다른 곳에서는 쓰지 않는 **Bazaar**를 배워야 했음
- emacs-devel에는 Bazaar 문제를 다루는 스레드가 반복적으로 등장함
  - “Help me unstick my bzr, please”
  - “Can NOT bzr the emacs repos (may be bzr has a memory leak)”
- 2012년 Canonical은 **Bazaar 개발팀을 해고**함
- 이후 Bazaar의 유지보수 상태는 Emacs 개발 과정에서 더 큰 부담이 됨

### 2013년: 유지보수 정체와 Git 재논의
- 2013년 3월, Bazaar 개발이 사실상 멈춘 지 1년 뒤 [John Wiegley](https://yhetil.org/emacs-devel/m2620euf2l.fsf@newartisans.com/T/#u)는 Emacs가 Git으로 전환할 수 있는지 다시 물음
  - Bazaar 개발은 사실상 정체된 상태였음
  - ELPA 저장소처럼 Emacs 개발에 영향을 주는 주요 버그가 수년 동안 버그 트래커에 남아 있고 해결되지 않았음
- 이 논의에서도 약 **200개 메시지**가 이어짐
- Stallman의 첫 반응은 Bazaar 유지보수자가 일부 버그를 고치고 있으며, 자신도 바로 전날 ELPA 브랜치 버그 수정을 요청했으니 합리적인 시간을 주고 싶다는 것이었음
- [Dmitry Gutov](https://yhetil.org/emacs-devel/87hajxqlly.fsf@yandex.ru/)는 해당 버그가 **1.5년 된 버그**인데 너무 늦은 것 아니냐고 물음
- Stallman은 [Bazaar가 효과적으로 유지보수되고 있는지 판단하려 한다](https://yhetil.org/emacs-devel/E1UKtwC-0006bM-Dd@fencepost.gnu.org/)며, “Yes”라는 답을 얻고 싶다고 밝힘
- [Joakim Verona](https://yhetil.org/emacs-devel/m3txnwj6zm.fsf@chopper.vpn.verona.se/)는 Bazaar 커뮤니티가 매우 도움이 되지만, 잘 알려진 버그와 패치가 많고 일부는 Emacs 개발자가 제공했는데도 수년 동안 upstream에 들어가지 않았다고 봄
- Stallman은 [Bazaar 메일링 리스트를 읽을 시간이 없다](https://yhetil.org/emacs-devel/E1UL4KW-0002zx-Jj@fencepost.gnu.org/)며, 자신이 읽는 개발 메일링 리스트는 emacs-devel뿐이라고 답함
- Bazaar 사용자가 Bazaar의 유지보수 충분성 판단에 발언권을 가져야 하냐는 질문에는, 관련 정보는 참고하지만 사용자에게 “발언권”을 주는 것은 부적절하다고 봄

### Karl Fogel의 비판과 위임 문제
- [Producing Open Source Software](https://producingoss.com/)의 저자이자 초기 Subversion 개발자 중 한 명인 Karl Fogel은 Stallman의 판단 방식과 위임 부재를 비판함
- Fogel은 Stallman이 Bazaar 개발 상황을 면밀히 볼 시간이 없다면, Bazaar가 여전히 Emacs에 좋은 선택인지도 역량 있게 판단하기 어렵다고 봄
- 그는 이런 평가를 할 시간과 정신적 여력이 없다면 **Emacs 유지보수자에게 위임**해야 한다고 주장함
- Fogel은 한 사람에게 한 버그를 물어보는 방식이 프로젝트 건강성의 대리 지표가 될 수 없고, 스레드의 다른 사람들이 이미 더 철저한 조사를 했다고 봄
- Stallman은 “Emacs보다 더 많은 것이 걸려 있기 때문”이라고 답함
  - GNU 대표 프로젝트가 GNU 도구를 버리면 다른 GNU 패키지에 어떤 신호를 보내는지가 핵심 쟁점이었음
- Fogel은 Stallman이 Bazaar 유지보수 상태를 신뢰할 만큼 평가할 시간을 쓰거나, 그렇게 할 수 있는 사람에게 위임해야 한다고 다시 요구함
- Stallman은 이미 계획이 있고 실행 중이라고만 답했으며, 구체적인 내용이나 일정, 위임은 제시하지 않음

### ELPA가 먼저 Git으로 이동함
- 2013년 논의에서 Stefan Monnier는 Bazaar를 계속 쓰든 Git, Monotone, Darcs, Mercurial, OpenCM, Fossil 등으로 바꾸든 큰 관심은 없다고 밝힘
- Stefan에게 당장 중요한 일은 **ELPA 브랜치**를 Bazaar에서 벗어나게 하는 것이었음
  - Bazaar가 ELPA 브랜치를 제대로 다루지 못했기 때문임
- Leo Liu는 대부분의 GNU 프로젝트가 Bazaar를 쓰지 않는다고 지적함
- 그는 Bazaar 버그를 고치는 일이 Bazaar에는 이익일 수 있지만, GNU 전체에는 손실일 수 있다고 봄
  - 자원봉사자의 여가 시간 중 20%가 Bazaar와 씨름하는 데 쓰이면 GNU 프로젝트 참여를 꺼리게 만들 만큼 비용이 커진다는 논리였음
- 그해 말 Stefan Monnier는 Bazaar에서 깨져 있던 **ELPA 브랜치**를 Git으로 옮김
  - ELPA 브랜치는 체크아웃 중 충돌하는 버그가 있었고, 이를 고칠 사람이 남아 있지 않았음
  - Stefan은 Git for ELPA, Bzr for trunk라는 두 도구 체제가 마음에 들지는 않지만 다른 출구가 없다고 봄
  - 그는 이 변경을 Git과 Bazaar의 장단점 논쟁이나 `trunk`의 Git 이전 논의로 확대하지 말라고 선을 그음
- ELPA가 Git으로 옮겨지면서, “ELPA에 Git이 충분하다면 trunk에도 충분하지 않느냐”는 다음 논의의 발판이 생김

### 2014년: Eric S. Raymond의 전환 작업과 실제 이전
- 2014년 8월 Eric S. Raymond는 Emacs 저장소 전환 스크립트를 준비해 둔 상태였음
- 그는 [어려운 작업은 모두 끝났고](https://yhetil.org/emacs-devel/20140810205631.GA17907@thyrsus.com/), 버튼을 누르기 전 약 8시간의 통지만 필요하다고 밝힘
- 실제 이전은 **2014년 11월**에 이뤄짐
- 11월 13일 ESR은 [“Commits are open. Have at it.”](https://yhetil.org/emacs-devel/20141113031255.GA21938@thyrsus.com/)이라는 여섯 단어 메시지를 보냄
- 이 전환은 일부에게 [heroic](https://yhetil.org/emacs-devel/8761ej6ql7.fsf@ktab.red-bean.com/)으로 묘사됨
- 2008년의 236개 메시지, 2013년의 200개 메시지, Stefan의 유지보수, 반복된 Bazaar 문제, 죽은 버전 관리 시스템을 거친 끝에 Emacs는 Git으로 넘어감

### 이전 이후: 핵심 기여자들도 Git을 새로 배워야 했음
- 전환 직후 며칠 동안 핵심 기여자 상당수가 Git을 써 본 적이 없다는 점이 드러남
- emacs-devel에는 Git 사용법을 묻는 스레드가 이어짐
  - “[This Is The Git Help Mailing List](https://yhetil.org/emacs-devel/m3sihnf5jy.fsf@stories.gnus.org/)”
  - “git pull fails with merge conflicts. How can this possibly happen?”
  - “A simple git workflow for the rest of us”
  - “need help adjusting workflow to git”
  - “Good book on Git”
  - “Obscure error/warning/information message from git pull”은 **124개 메시지**로 이어짐
- 중요한 텍스트 에디터를 오래 개발해 온 사람들이 기본적인 Git 질문을 하게 된 배경에는, 다른 세계가 Git으로 이동하는 동안 Emacs가 Bazaar에 머물러 있었던 시간이 있었음

## Comments



### Comment 57430

- Author: neo
- Created: 2026-05-14T09:30:55+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/jgmrz0/most_emacs_bzr_saga) 
- rms가 이끄는 프로젝트에서 일하면 정말 **정신이 나갈 것 같음**
  - 아, 이제 **why-cooperation-with-rms-is-impossible.au** 플래시백이 떠오름

- 정말 굉장한 역사임. 오래전에 어느 대학에서 Mark Shuttleworth가 원래의 **Bazaar**를 설명하던 발표를 봤는데, 분산 버전 관리 시스템이라는 아이디어가 정말 흥미로웠음  
  그 뒤 bzr 재작성판이 나왔고 완전히 빠져들었음. Git보다 훨씬 말이 된다고 느꼈고, 몇 년을 프로젝트에 쏟아부으며 메일링 리스트에서 활동하고 플러그인을 만들고, 코드 차이 비교 알고리즘을 C로 다시 작성해 더 빠르게 만들려고도 했음  
  결국 **Git이 승자**라는 게 분명해졌지만, 받아들이는 데는 꽤 오래 걸렸음

- 이 요약에 따르면 Richard Stallman은 2013년까지도 Emacs 프로젝트가 **Git으로 이전**하는 걸 금지했다고 함. 이후 2013년 말과 2014년 말에 Emacs가 두 단계로 Git으로 옮겼다고 나오지만, 2013년 초 이후 Stallman은 언급되지 않음  
  수년 동안 Bazaar를 지지해 왔는데, 그 뒤 메일링 리스트 스레드에서는 정말 반대 글을 올리지 않았던 걸까? 아니면 그 사이 Emacs 프로젝트에 대한 권한을 잃은 걸까?  
  글에 링크된 2014년 스레드에서는 그의 이름이 들어간 이메일을 못 봤지만, 링크되지 않은 다른 스레드가 있었을 수도 있음. 논란 때문에 Stallman이 뭔가에서 사임한 시기였나 싶었지만 아니었고, 내가 다른 일을 떠올린 것이었음. [Wikipedia](https://en.wikipedia.org/wiki/Richard_Stallman)에 따르면 Stallman은 2019년에 Free Software Foundation을 떠났고, GNU Project를 떠난 것도 아니었음

- 어떤 프로젝트가 공식 **GNU 프로젝트**가 되는지 정확히 모르겠음. 라이선스 때문인가? Git과 Linux는 둘 다 GPLv2-only이고 Bazaar는 GPLv2+임. 저작권 양도 때문인가? 저장소, 이슈 추적기, 메일링 리스트 등의 호스팅 때문인가? 지지처럼 작동하는 “GNU” 접두사 이름 때문인가?  
  어딘가 중요한 구분이 있는 건 분명해 보이지만, 그게 무엇이고 왜 중요한지는 잘 모르겠음  
  그리고 반복되는 **하나 차이 오류**도 있음:  
  > On November 13th, ESR posted a seven-word message:  
  >  
  >> Commits are open. Have at it.  
  >  
  > [...]  
  >  
  > Six years of debate, [...] and it ended with seven words.  
  아, 대칭을 맞출 절호의 기회를 놓쳤음
  - GNU 산하에 명시적으로 들어간 소프트웨어를 말함. 여기 목록이 있음: https://www.gnu.org/software/software.html#allgnupkgs
  - “bazaar”에는 글자 **a**가 몇 번 나오나? :)

- 2014년쯤 mysql에 뭔가 하려고 했는데, 저장소를 복제하고 릴리스 브랜치를 체크아웃하는 데만 하루 종일 실패하다 포기했던 일이 이제 훨씬 덜 부끄러워짐  
  그 전까지 CVS, Subversion, Mercurial을 몇 년씩 써 왔기 때문에 네트워크나 내 컴퓨터 문제라고 생각했음. 이 글을 읽기 전까지는 bzr의 실제 벤치마크가 그렇게 끔찍했는지, Canonical이 bzr을 그렇게 많이 쓰면서도 이미 **bzr 팀을 해고**했는지 몰랐음  
  몇 년 뒤 mysql에 다른 일을 하러 갔을 때는 Git으로 옮겨져 있었고, 시작도 하기 전에 막히지 않은 덕분에 흥미로운 작업을 해낼 수 있었음  
  > Since I had no interesting books to read today, nor interesting films to watch, I decided to scavenge for the most intriguing content one can find online. I ended up reading the Linux kernel mailing lists, but those discussions seemed to be 18+, so I settled for the comparatively civil emacs-devel.  
  지금까지 본 것 중 가장 훌륭한 “아니요, 이 글은 AI로 쓰지 않았습니다” **면책 문구**임

- 멋진 글임. 이런 **메일링 리스트 드라마**가 어떻게 흘러갔는지 늘 보고 싶었지만 직접 뛰어들 용기는 없었음. 이야기 구성과 발췌가 정말 좋음

- 혼란스러운 역사를 재미있게 정리했음. 다만 제목은 “The Most Emacs Bzr Saga”보다 “**The Most Bzr Emacs Saga**”가 맞지 않나 싶음  
  “Emacs”를 형용사처럼 쓰는 일이 전혀 없진 않겠지만 그래도 좀 어색함

- Bazaar가 내가 처음 써 본 **버전 관리 시스템**이었음. 당시 Ubuntu로 Linux에 입문하던 중이었고, Canonical은 소스 코드를 호스팅할 수 있는 Launchpad를 쓰고 있었음  
  그 전까지는 코드를 어디에도 올리지 않았는데, Launchpad와 Bazaar를 쓰니 꽤 멋져 보였음. 물론 내 프로젝트들은 너무 작아서 성능 문제를 전혀 느끼지 못했음