아직도 Emacs를 쓰는 사람이 있을까?

최근 오렌지 사이트에서의 토론에서는 Emacs 31 Is Around the Corner: The Changes I’m Already Daily Driving 글을 계기로 사람들이 “아직도 Emacs를 쓰는 사람이 있을까?”라고 자문하며 각자의 관점을 내놓고 있었다.

나에게 답은 단호하게 그렇다… 하지만 흥미로운 부분은 내가 Emacs를 계속 쓰고 있는 것이 아니라, 사실 Emacs를 다시 쓰고 있다는 점이다. 그리고 그 첫 질문에 대한 내 답을 긴 토론 스레드 속에 묻어두는 대신, 지난 거의 30년에 걸친 Emacs와 함께한 시간, 그리고 Emacs 없이 지낸 시간을 설명해 보려 한다. 마지막에는 내가 초능력을 얻은 것처럼 느끼게 해 주고, 나를 계속 붙잡아 두는 바로 그 기능도 공개하겠다.

나는 1997년쯤 Caldera OpenLinux 1.1을 통해 Linux에 입문했다. 그전에는 어릴 때 Borland Turbo C++와 Visual Basic을 꽤 많이 만져 봤기 때문에 우리가 잃어버린 그 화려한 IDE들에 아주 익숙했다.

Linux에 발을 들이고 낯선 세계에 들어서자, 입문서를 두어 권 사야 했다. 그렇다, 책이다. 종이책 말이다. 예전에는 새로운 것을 그렇게 배워야 했으니까. 두 책 모두 Vim과 Emacs를 다루며 이를 고급 선택지로 소개했다. 내게는 이게 이상하게 느껴졌다. 전에 쓰던 IDE들이 더 완성도 있어 보였기 때문이다. 그래도 나는 무슨 이유에서인지 Windows를 등진 반항아였고, 그대로 밀고 나갔다. 나는 두 편집기의 기초를 익혔고, 서로 다른 시점에 각각의 튜토리얼도 따라 해 봤다.

그 시절 Linux를 배우는 데 썼던 오래된 두 권의 책. Vim과 Emacs 소개 부분이 보이도록 펼쳐 두었다.

그때부터 대략 2015년까지 나는 Vim과 Emacs 사이를 오락가락했다. 어떤 때는 하나를 쓰고, 어떤 때는 다른 하나를 썼다. 긴 코딩 세션에서는 Emacs를 선호했지만, pkgsrc 작업처럼 수십 개의 서로 다른 파일을 빠르게 연달아 편집해야 할 때는 Vim이 더 뛰어났다.

Vim과 Emacs는 내게 잘 맞았지만, 무언가가 부족했다. 언어 통합이 빈약했기 때문에 모두가 칭찬하던 더 현대적인 편집기들에 끌렸다. 특히 macOS로 옮기고 나서는 더 그랬다. 지금은 사라진 Atom이나 Brackets 같은 여러 편집기를 써 봤지만, 모두 불안정하고 부담스럽게 느껴졌다. 기능이 너무 많고, 설정도 너무 많았다.

그러다 2015년에 VSCode가 등장했다. 시험 삼아 써 보자마자 처음부터 “느낌이 맞았다”. 현대적으로 보였고, 비교적 가벼웠으며, 평범하고 단순한 설정 편집기—즉, 당시에는 설정 패널조차 없었기 때문에 그냥 JSON 파일이었다!—덕분에 내가 통제권을 쥐고 있다는 느낌을 받았다. 나는 이 현대적인 편집기를 이해할 수 있었고, 내 필요에 맞게 쉽게 조정할 수 있었다.

얼마 지나지 않아 나는 Go를 배우기 시작했고, 이어서 Rust도 익혔다. VSCode가 각 언어의 LSP와 제공하던 통합은 그 과정을 훨씬 쉽게 만들어 주었다. 코드 자동 완성과 실시간 오류 강조 덕분에 학습 속도가 크게 빨라졌다. 나는 이 언어들에서는 VSCode를 계속 썼고, 서서히 Emacs는 멀어졌다. 완전히 마음을 빼앗겼다.

그 시기 나는 Google에서 Bazel—Java 프로젝트—작업도 하고 있었고, 그에 대한 자연스러운 선택은 IntelliJ였다. 한때 Java 개발에 Emacs를 써 보려 했던 적도 있었지만, IntelliJ는 너무나도 훌륭해서 지금도 그렇지만 사실상 유일하게 현실적인 선택이었다.

Vim 플러그인을 붙인 VSCode 사용은 Microsoft에서 짧게 일하던 시기에도 계속됐다. 당시 나는 C++ 코드베이스를 다루고 있었고 원격 Windows 머신에 접속해야 했다. 대부분은 RDP로 원격 머신에서 “직접” 작업했지만, 나는 그 워크플로를 견딜 수 없었다. 내 데스크톱에서 VSCode를 실행하고 SSH로 원격 머신에 연결하는 방식을 훨씬 더 선호했는데, VSCode는 그 일을 아주 잘 해냈다.

그러다… 2022년에 Snowflake로 옮겼다. 그곳의 개발은 오래된 Linux VM 안에서 이뤄지곤 했고, 내 일상 업무는 셸 스크립트와 Bazel 빌드 파일을 작성하는 일이었다. 여기서는 VSCode도 IntelliJ도 나를 구해 주지 못했다. 그리고 앞서 말했듯, 나는 “원격” 그래픽 환경의 제약 안에서 일하는 느낌을 싫어한다. 그래서 본능적으로 다시 SSH로 돌아가 로컬 VM에 접속했다.

그렇게 하다 보니 긴 작업 세션을 위한 편집기가 필요했고, 오래되고 믿음직한 Emacs가 거기서 나를 기다리고 있었다. 하지만 이번에는 설정할 인내심이 없었다. 왜냐하면 수년 동안 init.el 파일에 수백 줄을 쌓아 놓았으면서도 그 내용 대부분을 제대로 이해하지 못했고, 나는 그걸 전부 버리고 처음부터 다시 시작하고 싶었기 때문이다… 하지만 그것조차 너무 큰 일처럼 느껴졌다. 어쩌면 운명이 적절한 순간에 Doom Emacs를 내 앞에 가져다준 것인지도 모른다.

프로젝트 웹사이트에 있는 기본 Doom Emacs 스크린샷.

Doom Emacs는 누군가가 Emacs를 바닥부터 설정하는 고통—혹은 즐거움일 수도 있다, 판단은 하지 않겠다—을 대신 겪어 놓은 Emacs “배포판”이다. 더 구체적으로 말하면, Doom Emacs는 합리적인 기본값, 미리 정의된 언어 통합, 그리고 예전 Vim 사용자도 반길 만한 경험을 제공한다. 스스로를 IDE라고 주장하지는 않지만… 내게는 그렇게 느껴진다.

설치를 마치고 나자 데자뷔를 느꼈다. 2015년의 VSCode가 그랬듯 Emacs가 딱 맞는 느낌을 주었다. 갑자기 많은 Emacs 기능이 스페이스 기반 단축키 뒤에 숨어 있는 대화형 팝업 메뉴를 통해 쉽게 발견 가능해졌고, 손목을 망가뜨리지도 않았다. 게다가 그것은 내가 이미 너무 익숙해진 Vim 스타일 키 바인딩과도 공존했다. 하지만 그보다 더 중요한 것은 설정 이 단순하고 이해하기 쉬웠다는 점이다. 설정은 고작 세 개의 사소한 파일에 나뉘어 있었다.

• config.el은 테마나 사용할 글꼴 같은 전역 설정을 지정한다.

• init.el은 어떤 Doom 전용 모듈을 활성화할지 선택한다.

• packages.el은 Doom에 포함되지 않은 패키지를 설치한다.

이 파일들의 기본값은 합리적이고, 조정하고 싶을 만한 몇 안 되는 세부 사항을 설정할 수 있도록 주석도 풍부하게 달려 있다.

이 새로운 구성 덕분에 나는 지금까지 가장 훌륭한 Emacs 경험을 하고 있다. LSP의 발전—이 점은 VSCode에 감사해야 한다—과 tree-sitter 같은 현대적 기능 덕분에, 이제 Emacs는 IDE처럼 느껴진다. 내가 다뤄야 하는 대부분의 언어에서 제대로 된 언어 통합을 누릴 수 있다.

그리고 내게 절대적인 킬러 기능은, 어떤 머신에서 일하든 정확히 똑같은 개발 환경 을 얻는다는 점이다. MacBook이든 Linux 노트북이든, Linux 클라우드 워크스테이션에 접속하든, 심지어 내 FreeBSD 서버에 접속하든 상관없다. 내게 필요한 것은 셸, tmux, 그리고 Emacs뿐이고, 어디서나 똑같이 생산적이다. 이것은 내게 정말 큰 가치가 있다. 나는 다양한 머신에서 작업하는 편이고, 이런 상황에서는 근육 기억이 큰 보상을 주기 때문이다.

온라인에서 Doom Emacs를 찾아보면 “너무 많은 일을 한다”고 “불평”하는 사람들을 발견할 것이다. 그리고 그 말은 사실이다. 실제로 많은 일을 한다. 그래서 내가 그렇게 유용하다고 느끼는 것이다. 하지만 언젠가는 Emacs에 대해 더 많이 배우고 싶기 때문에, 이걸 좀 덜어낼 수 있을지 종종 궁금하다. 특히 요즘은 많은 현대적 서드파티 모듈이 “졸업”해서 기본 패키지의 일부가 되는 모습을 보고 있으니 더 그렇다.

그런 이유로 최근에는 Bedrock이나 Emacs Solo 배포판을 써 보고 싶은 유혹을 느끼고 있다. 하지만… 전환에 필요한 시동 에너지가 꽤나 높다. 그리고 정말 그 길로 간다고 해도, 결국에는 왜 아예 “날것의” Emacs로 끝까지 가지 않는지 스스로에게 되묻게 될 것이다.

마무리하기 전에 관련된 생각을 하나 더 하자면, Emacs가 Elisp를 기반으로 해서 사람들에게 왜 그렇게 변혁적인 도구가 되는지는 아직 완전히 이해하지 못하겠다. 물론 Emacs 안에서 더 많은 로직과 워크플로를 구현할 수도 있겠지만, 나는 이미 셸에서 스크립트로 “모든 것”을 쉽게 하고 있다. 그리고 스크립트 쪽이 더 Unix답게 느껴진다. 왜냐하면 “Unix is my IDE”이기 때문이다. 나는 Org mode와 Magit가 독립 실행형 애플리케이션이 아니라 Emacs 뒤에 “묶여” 있다는 점도 사실 마음에 들지 않는다. 분명 내가 놓치고 있는 무언가가 있겠지만, 그게 정확히 무엇인지는 잘 모르겠다…

그러니 글의 첫 질문으로 돌아가 보자. 그렇다, 나는 여전히 Emacs를 쓴다. 그리고 서로 다른 원격 머신에서 늘 작업해야 하는 내 필요 때문에, 과거보다도 내게 더 중요한 도구가 되었다.

이제 여러분께 묻고 싶은 것은 이것이다. 여러분도 아직 Emacs를 “계속” 쓰고 있는가? 쓴다면 어떤 배포판을 쓰는가, 아니면 아무 배포판도 쓰지 않는가? Emacs는 여러분의 워크플로를 어떻게 바꿔 놓았는가?