Neovim 사용자가 Doom Emacs로 옮기며 경험한 설정과 작업 방식

이 전환의 핵심은 Neovim이 부족해서가 아니라, 편집기 바깥의 일까지 한 환경에서 다루고 싶다는 데 있습니다. 기사 속 작성자는 Neovim으로 개발하는 데 불편이 없었지만, 웹 탐색·이메일·달력·IRC마다 별도 프로그램과 규칙을 익히는 부담을 느꼈습니다. 그래서 Emacs 선택은 기능 비교라기보다 작업의 중심을 어디에 둘 것인가에 대한 판단에 가깝습니다.

Doom Emacs가 전환을 쉽게 했다는 경험은 의미 있지만, 이것이 학습 비용을 없앴다는 뜻은 아닙니다. Vim 키 바인딩과 안내 팝업은 진입 장벽을 낮추고, 패키지 생태계와 문서 탐색은 새 기능을 발견하는 데 도움을 줍니다. 다만 Emacs의 힘은 결국 설정과 개념을 자기 방식으로 연결할 때 커질 가능성이 큽니다. 초기에 편리한 구성이 나중에는 내부 동작을 이해하는 일을 미루게 할 수도 있습니다.

기사에서 패키지 설치, LSP 설정, 문서화가 장점으로 언급된 점은 특히 설득력 있습니다. 편집기는 기능이 많기만 해서는 부족하고, 기능을 찾고 문제를 해결하는 경로가 분명해야 합니다. 스페이스 키를 누른 뒤 가능한 명령을 팝업으로 보여주는 방식은 키 조합을 암기하는 대신 탐색하며 익히게 합니다. 이런 설계는 초보자뿐 아니라 오랜 사용자에게도 도구의 기억 부담을 줄이는 경험이 될 수 있습니다.

그러나 모든 작업을 한 프로그램에 모으는 일이 모두에게 효율적이라고 단정할 수는 없습니다. 통합은 프로그램 간 전환을 줄이는 대신, 하나의 환경에 익숙해지고 설정을 유지하는 비용을 늘릴 수 있습니다. 또한 기사도 지적하듯 현대 웹은 텍스트 기반 브라우저와 잘 맞지 않는 경우가 있습니다. Emacs가 여러 프로그램을 대체한다기보다, 작성·정리·개발처럼 텍스트 중심인 작업을 묶는 허브로 자리 잡을 가능성이 더 현실적입니다.

Mu4e, org-mode, Magit을 차례로 익히려는 계획은 이 전환의 성패를 가를 겁니다. 각각을 한꺼번에 도입하기보다 실제로 반복하는 작업 하나를 옮겨 보고, 기존 도구보다 나아지는지 확인하는 편이 안전해 보입니다. 그렇게 해야 통합이 목적이 아니라 실제로 마찰을 줄이는 수단인지 판단할 수 있습니다.

결국 이 글이 보여주는 것은 Neovim과 Emacs 중 어느 쪽이 우월한지가 아닙니다. 이미 만족스러운 편집기를 쓰더라도, 도구들이 흩어져 있다는 불편이 더 커지면 다른 생태계로 옮길 이유가 생긴다는 점입니다. Doom Emacs는 그 실험을 시작하기 좋은 발판일 수 있지만, 장기적으로 편리함을 결정하는 것은 설정의 양이 아니라 사용자가 자기 작업 흐름을 얼마나 명확히 구성하느냐일 겁니다.