Vim의 보스, Bram Moolenaar

 (neovim.io)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Bram Moolenaar는 Vim의 소스·문서·vim_dev에서 문제 해결 중심의 태도를 남겼고, Neovim은 Vim과 Bram의 유산을 잇는 프로젝트로 자신을 바라봄
  • 무례한 반응이나 개인적 판단보다 문제 이해를 진전시키는 방식이 Bram의 강점으로 드러났고, 조용하지만 깊은 가치를 만든 사람으로 기억됨
  • Vim 커밋 메시지의 Problem/Solution 원칙은 단순하지만 효과적이며, 우간다 지원에서도 자원을 추상화하지 않고 직접 관리하는 태도로 이어짐
  • Neovim은 Vim의 파생물로서 계속성과 분기를 동시에 받아들이며, 유지보수·문서화·확장성·임베딩을 이어갈 핵심 축으로 삼음
  • Neovim이 계승하려는 방향은 새로움 자체가 아니라, 목표를 잊지 않고 행동을 결과와 비교하는 실용주의에 가까움

Bram이 남긴 문제 해결 방식

  • Bram은 기술적 장인정신을 넘어 겸손한 태도와 현실에 닻을 둔 문제 해결 방식을 보여줌
  • vim_dev, Vim 소스, 문서에는 Bram의 말과 결정뿐 아니라 그가 하지 않은 선택도 남아 있음
    • 선정적인 표현이나 개인적 판단에 기대지 않음
    • 무례한 대우를 받아도 해결해야 할 문제를 더 잘 이해하는 방향으로 반응하는 경우가 많았음
  • Vim 커밋 메시지의 Problem/Solution 구호는 단순하지만 강력한 작업 원칙으로 작동함
  • Bram은 우간다 사람들을 돕는 일에서도 자원을 추상적으로 다루기보다 직접 관리하는 방식을 택함
  • 겸손은 시도를 “좁은 허리” 같은 자발적 제약으로 통과시키는 사고방식이며, 더 조합 가능하고 강력한 결과를 만들 수 있음
    • unimpaired 같은 플러그인은 이런 흐름을 변주한 사례임
  • Emacs와 Vim 같은 라이프스타일 소프트웨어의 효용은 이념보다 살아 있는 생태계와 스스로 지속되는 추진력에 있음

Neovim이 이어받은 것과 갈라지는 것

  • Neovim은 처음부터 Vim의 파생물로 자리 잡았고, Vim을 계속 잇는 동시에 Vim과 달라지는 성격도 함께 가짐
  • fork는 에너지를 파괴하기보다 만든다는 관점에서, Bram 없이 Vim 자체를 전달할 수는 없어도 일부 본질적인 요소는 계속 이어갈 수 있음

  • 유지보수와 문서화

    • Maintenance: 실험은 필요하고 창조적 파괴와 장난스러운 실패도 가치가 있지만, Neovim은 새것을 향한 욕망인 “neomania”를 대표하지 않음
    • Documentation: Vim 문서화의 습관은 분명하며, Nvim이 Vim 위에 구축되며 얻은 큰 이점 중 하나임

  • 확장성과 임베딩

    • Extensibility: Bram의 Agide 프로젝트도 Neovim과 비슷한 확장성을 지향했고, 단일 애플리케이션이 아니라 별도 도구를 꽂아 쓰는 방식을 내세움
    • Embedding: Vim의 :help design-not은 Vim을 셸이나 운영체제로 만들기보다, 셸이나 IDE에서 컴포넌트로 사용하는 방향을 말함
    • Bram은 자신을 지나치게 심각하게 여기지 않았고, 자신만의 유머 감각도 지녔음
    • Neovim은 Vim과 Bram에 대한 기념비로 남되, 독단보다 실용성을 택하고 목표와 결과를 기준으로 행동을 되돌아봐야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Bram에게 감사함
    30년 넘게 Vim을 써 왔고, 최근에는 가끔 Neovim도 쓰며, 학교에서는 여러 BSD 시스템에서 vi를 썼음. 커리어 내내 거의 매 근무일마다 썼지만 Vim 메일링 리스트에 들어간 적도, 질문한 적도, 버그 리포트를 낸 적도 없음
    그럴 필요가 없었기 때문임. 버그를 만나지 않았고, 궁금한 점은 늘 내장 문서로 해결됐음. 훌륭한 사람이 이끈 훌륭한 소프트웨어 프로젝트였고, 큰 영감이 됨

    • 25년 전 가을, 대학 IT 부서에 취직했을 때 상사가 Perl과 vi O'Reilly 책을 줘서 Unix 서버에서 프로그래밍을 시작했음. 그 뒤로 vi와 Vim을 커리어 내내 매일 써 왔음
    • 복잡한 제어 시스템을 다뤄 봤는데, 문서가 워낙 좋아서 필요한 정보를 언제나 쉽게 찾을 수 있었음
      반대로 비교적 단순한 시스템도 문서가 없거나, 한 번은 끔찍한 문서 때문에 훨씬 더 캐묻고 파헤쳐야 했던 적이 있음

  • Vim에는 영혼이 있음. 할아버지에게 물려받은 끌처럼 계속 쓰게 되는 도구임
    새 제품처럼 부드러운 고무 손잡이는 없어도 손에 잘 맞고 편안함. 자기만의 역사를 가진 도구임
    여기 댓글들을 보면 해커 정신이 아직 살아 있는 것 같음. 새로 뜬 수십억 달러짜리 젊은 회사는 10~20년 뒤 다른 것으로 대체되겠지만, Vim은 계속 살아남을 것임. 언젠가 나만의 Vim 같은 것을 만들고 싶음

    • 다만 차이가 조금 있음. 초보자가 할아버지의 끌을 집어 든다고 해서, 그 끌이 손에 달라붙고 세 마디 마법 주문을 구글링해야만 떨어지는 건 아님
    • Galadriel의 병처럼, 다른 모든 빛이 꺼졌을 때 어두운 곳에서 밝혀 주는 빛 같음

  • Bram이 세상을 떠난 뒤 내 Vim 여정을 돌아봤음. 지난 10년간 대학 프로젝트부터 FAANG, 모든 게 불타는 스타트업까지 유일하게 변하지 않은 직업적 동반자였음
    자랑스러운 작업, 부끄러운 작업, 승진으로 이어진 작업, 수백만 달러 규모의 장애로 이어진 작업까지 모두 Vim에서 했음. 운영체제, 데이터베이스, 프로그래밍 언어, 회사, 동료는 오고 가지만 Vim은 늘 남아 있었음
    Bram에게 감사함

  • 링크된 글 [0]에 Bram의 GitHub 활동 스크린샷과 이런 문구가 있음
    “Bram이 세상을 떠났다는 소식을 읽었을 때 왜 이렇게 마음에 와닿았는지, 아마 이 모든 것이 쌓였기 때문일 것이다. 가족의 메시지에는 Bram이 아팠다는 점이 분명히 적혀 있었다. ‘지난 몇 주 사이 빠르게 진행된 의학적 상태’였다고 한다. 대부분은 이를 몰랐고, 그래서 소식은 더 놀라웠다.”
    “그리고 누군가 Bram의 최근 GitHub 활동을 짚어 줬을 때 더 슬퍼졌다.”
    https://github.com/brammool
    [0] https://j11g.com/2023/08/07/the-legacy-of-bram-moolenaar/
    덧붙여, Wikipedia의 BDFL 목록을 보면 Bram이 † 표시가 붙은 첫 인물처럼 보임
    https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

  • 오늘 네덜란드 Utrecht 기차역에서 특별한 걸 봤음. 안내판에 hjkl 글자가 역순으로 적혀 있었음
    이 글자들은 승강장에서 어느 구역으로 들어가면 되는지 표시함. 승강장 길이와 열차 출입문 위치에 따라 글자가 표시됨
    https://postimg.cc/mcCWhMXw
    엄청난 우연이거나, 네덜란드 철도 회사 NS에 Vim 팬이 있어서 Bram에게 이런 식으로 헌정한 것 같았음

    • 생각해 보니 이 글자들은 알파벳에서 이어져 있긴 함. 다만 H와 J 사이의 I가 빠져 있는데, 아마 소문자 l과 헷갈릴 수 있어서 의도적으로 뺐을 수도 있음
      결국 우연일 수도 있지만 그래도 내게는 특별했음. 기차역에서 이런 걸 본 적이 없었는데 Bram이 세상을 떠난 바로 다음 주에 갑자기 보였기 때문임
    • 우연도 헌정도 아님. 영국에서도 수년 전부터 같은 식이었음. 글자 i는 숫자 1이나 글자 l과 쉽게 헷갈려서 이런 용도에는 보통 쓰지 않음
    • Vim을 쓰긴 하지만, 이 글자들은 Vim보다 터치 타이핑의 홈 로우가 먼저 떠오름
    • 이 표지는 열차가 승강장 어디에 멈출지 보여 주는 위치 표시임
      네덜란드어 영상: https://www.youtube.com/watch?v=JPvh9SaQbUY

  • 예전에 인턴 후보자를 면접했는데, 메일링 리스트에서 가능한 취약점을 두고 Bram과 논쟁했다며 자랑했음. Bram은 중요하지 않다고 했고, 이 젊은 친구는 중요하다고 우겼음
    우리는 그를 채용하지 않았음. Bram 추모 글들을 보니, 사람들이 말하는 Bram은 좋은 의미에서 그 친구와 정반대였던 것 같음

    • 그 논쟁이 자동 파일 암호화/복호화 기능과, Bram이 암호학적으로 안전한 알고리즘을 쓰려 하지 않았던 일에 관한 것이었는지 궁금함. 길고 길게 이어졌고 꽤 달아오른 스레드였음
      그래도 나는 Bram 쪽이었음. 그 기능은 애초에 암호학적 의미의 보안을 목표로 한 게 아니었음

  • https://en.wikipedia.org/wiki/Benevolent_dictator_for_life에는 BDFL 목록이 있음. Bram은 그 목록에서 세상을 떠난 첫 BDFL임
    앞으로 10년, 혹은 그 이후에 세대교체가 올 것임. 준비하는 게 맞고, 그것이 유산과 커뮤니티를 보존하는 방법임
    Bram의 가족과 친구들이 그의 유산과 Vim의 미래를 존중하며 이 일을 처리하는 방식이 인상적이었음

    • 이 글을 쓴 뒤 John Gruber가 Markdown의 BDFL로 추가됐음. 창시자인 건 맞지만, BDFL이라고 하기는 좀 과한 듯함

  • 링크된 글 중에는 Jan van den Berg가 쓴 이 글이 더 좋았음
    https://j11g.com/2023/08/07/the-legacy-of-bram-moolenaar/
    인상적인 문장 하나는 “Vim은 걸작이며, 현대의 많은 것이 깎여 나온 빛나고 정밀한 공작 도구다”였음
    그리고 이 링크도 있음
    https://m.youtube.com/watch?v=eX9m3g5J-XA
    “7 Habits for Effective Text Editing 2.0”
    1시간 20분짜리라 누가 녹취나 요약을 갖고 있으면 좋겠음. 첫 댓글은 웃겼음: “7시간 자는 동안 자동 재생을 켜 뒀더니 Billie Eilish에서 이 영상까지 왔다”
    삶은 이상하지만 그래서 좋음
    참고로 나는 (Neo)vim도 Emacs도 쓰지 않음. “프로그래밍 가능”이라는 말을 읽는 순간 멀어짐. 취향에 맞는 고정 기능 편집기를 몇 분 설정하고 바로 쓰는 쪽을 선호함. 그냥 내 취향일 뿐임
    그래도 좋은 도구는 목적을 잘 수행함. 좋은 도구와 그 도구를 만든 사람들이 있는 세상은 더 나은 세상임. 때로는 그 유산, 철학, 작업 방식이 남겨진 코드나 커뮤니티 안에서 계속 살아감. Bram에게 찬사를 보냄

    • 추모문을 두고 경쟁할 필요가 있는지는 모르겠지만, 올려 준 글도 감동적이었음. Bram의 GitHub 기여 그래프 사진은 잊히지 않음
    • “프로그래밍 가능”이라는 말이 싫고 취향에 맞는 고정 기능 편집기를 원한다면 Helix가 맞을 수도 있음
      Kakoune 키 바인딩을 쓰는데 Vim이나 Emacs보다 훨씬 납득이 잘 감. 이미 기본 설정이 잘 되어 있고 유용한 기능도 많음. 매일 쓰고 있는데 빠르고 괜찮음
      PATH에 LSP가 있으면 자동으로 사용하므로 설정이 아주 적게 필요함. 내 설정은 테마와 약간의 스타일 변경뿐이고, 원하면 여기서 볼 수 있음: https://github.com/RGBCube/NixOSConfiguration/blob/master/ma...
    • Vim은 set nocompatible, set ruler, 백스페이스, 들여쓰기, 기본 색상표 중 하나 정도를 고르는 것 외에는 “프로그래밍”할 필요가 거의 없음
      Neovim에서는 lightline, pathogen, monokai 색상표와 뭔가 하나 더 설치했는데, 아마 조금 더 특이한 언어의 구문 강조였던 것 같음
      핵심은 Vim이 이것저것 잔뜩 매달기 전까지는 고정 기능 편집기라는 점임
    • “7 Habits for Effective Text Editing 2.0”의 자료는 여기 있음: https://moolenaar.net/habits_2007.pdf
      tlamponi [1] 덕분임: https://news.ycombinator.com/item?id=37013315

  • Vim은 내 삶에 실제로 영향을 줬음. 지난 15년 동안 써 왔고, 새 호스트를 받으면 set -o vi나 psql/ipython의 비슷한 설정을 거의 즉시 rc 파일에 넣음
    셸 안에서 보낸 수많은 시간이 Bram의 작업 덕분에 훨씬 즐거워졌음
    이 글을 올려 줘서 고맙고, 편히 쉬길 바람

    • Vim 명령을 배운 건 내가 아는 것 중 투자 대비 효과가 가장 큰 일 중 하나였음. 수년간 귀중했고, 컴퓨터와 상호작용하는 시간을 수백 시간은 아껴 줬을 것임
      오래전에 근육 기억이 되었고, 텍스트 편집과 화면에서 커서 이동은 이제 전혀 힘이 들지 않음
      새 프로그래머들에게 늘 추천하는 것 중 하나임. Vim 학습 곡선이 가파르다고 할 수는 있지만, 프로그래머가 늘 하는 텍스트와의 상호작용을 더 효율적으로 바라보게 해 줌
      셸과 Readline을 쓰는 모든 곳, Emacs에서는 evil-mode로 기본값을 바꾸는 등 지원되는 곳마다 Vi(m) 모드를 켜 둠
      모드 기반 인터페이스와 조합 가능한 기억술적 명령은 Emacs식 키 조합 UI보다 훨씬 뛰어나고 직관적임. Vim을 사랑함. 20년 넘게 전 이 여정을 시작하게 해 준 도구이고, 지금도 빠른 편집에는 매일 씀. 다만 IDE로는 더 확장 가능한 환경인 Emacs를 선호함. evil-mode 덕분에 둘의 장점을 모두 얻음
      Bram은 수많은 사람의 삶을 개선했고, 우리 업계의 위대한 인물들 사이에서 인정받아야 함. RIP

  • 덧없는 소프트웨어의 세계에서 Vim은 시대를 초월한 걸작임
    Bram이 내 삶과 커리어에 준 영향을 직접 감사할 기회가 있었으면 좋았겠음. Vim이 없었다면 여기까지 오지 못했을 것 같음

    • 이것이 Vim의 중요한 점 중 하나라고 봄. 오래 존재할수록 더 오래 살아남을 가능성이 커짐. 수많은 현대 텍스트 편집기보다 오래 버텼음
      내가 살아 있는 동안, 그리고 그 이후에도 계속 살아 있기를 바람
답변달기