아직도 Emacs를 쓰는 사람이 있나요?

• 1997년 Linux 입문 뒤 Vim과 Emacs를 오가던 경험은 2015년 VSCode와 IntelliJ로 옮겨갔다가, 2022년 Snowflake의 원격 Linux VM 환경에서 Doom Emacs로 다시 돌아오는 흐름으로 이어짐
• VSCode는 현대적인 UI, 작은 규모, JSON 기반 설정, Go·Rust의 LSP 통합으로 학습과 개발을 쉽게 만들었고, Java 개발에서는 IntelliJ가 더 현실적인 선택지였음
• Snowflake의 오래된 Linux VM에서는 shell script와 Bazel build file 작성이 중심이었고, 원격 그래픽 환경보다 SSH 기반 작업이 잘 맞아 Emacs가 다시 필요해짐
• Doom Emacs는 합리적인 기본값, 언어 통합, Vim 스타일 키 바인딩, space 기반 팝업 메뉴, 단순한 설정 파일 구조 덕분에 Emacs를 IDE처럼 느끼게 함
• MacBook, Linux laptop, Linux cloud workstation, FreeBSD server 어디서든 shell·tmux·Emacs만으로 동일한 개발 환경을 유지할 수 있다는 점이 Emacs를 계속 쓰게 만드는 핵심 이유임

DOS/Windows IDE에서 Linux 편집기로

• 1997년쯤 Caldera OpenLinux 1.1로 Linux에 입문함
• 그 전에는 Borland Turbo C++와 Visual Basic을 많이 사용해, 당시의 완성도 높은 IDE에 익숙했음
• Linux 입문서 두 권을 통해 Vim과 Emacs를 접했고, 두 편집기 모두 고급 선택지로 소개되어 있었음
• 이전에 쓰던 IDE가 더 완전해 보였지만, Vim과 Emacs의 기본 사용법과 튜토리얼을 각각 익힘
• 2015년 무렵까지 Vim과 Emacs를 번갈아 사용함
  • Emacs는 긴 코딩 세션에 더 잘 맞았음
  • Vim은 pkgsrc 작업처럼 여러 파일을 빠르게 오가며 수정할 때 강점이 있었음

VSCode와 IntelliJ로 옮겨간 이유

• Vim과 Emacs가 충분히 작동했지만, 언어 통합이 약해 더 현대적인 편집기에 관심이 생김
• macOS로 이동하면서 Atom과 Brackets도 시도했으나, 기능과 설정이 너무 많아 취약하고 부담스럽게 느껴짐
• 2015년에 등장한 VSCode는 처음부터 잘 맞는 도구처럼 느껴짐
  • 현대적으로 보였고 비교적 작았음
  • 당시 설정 편집기는 설정 패널 없이 JSON 파일 기반이라 제어하기 쉽다고 느꼈음
• Go와 Rust를 배우기 시작하면서 VSCode의 각 언어 LSP 통합이 큰 도움이 됨
  • 코드 자동완성
  • 실시간 오류 강조
  • 학습 속도 향상
• Google에서 Bazel이라는 Java 프로젝트를 다룰 때는 IntelliJ가 자연스러운 선택이었음
  • Emacs로 Java 개발을 시도한 적도 있었지만, IntelliJ가 매우 좋아 현실적인 선택지는 IntelliJ였음
• Microsoft에서 C++ 코드베이스와 원격 Windows 머신을 다룰 때도 VSCode와 Vim 플러그인을 계속 사용함
  • 많은 사람은 RDP로 원격 머신에서 직접 작업했음
  • 로컬 데스크톱에서 VSCode를 실행하고 SSH로 원격 머신에 접속하는 방식을 더 선호했음

Snowflake에서 Doom Emacs로 돌아온 계기

• 2022년 Snowflake로 옮긴 뒤 개발은 오래된 Linux VM 안에서 이뤄졌고, 일상 업무는 shell script와 Bazel build file 작성이었음
• 이 환경에서는 VSCode나 IntelliJ가 문제를 해결해주지 못했고, 원격 그래픽 환경의 제약도 싫어 SSH로 로컬 VM에 접속하는 방식으로 돌아감
• 긴 작업 세션용 편집기가 다시 필요해졌고, 선택지는 Emacs였음
• 예전 init.el에는 수년간 쌓인 수백 줄 설정이 있었지만 내용을 충분히 이해하지 못해 전부 버리고 새로 시작하고 싶었음
• 이 시점에 Doom Emacs를 접함
  • Doom Emacs는 Emacs를 처음부터 구성해 둔 “배포판”임
  • 합리적인 기본값을 제공함
  • 미리 정의된 언어 통합을 제공함
  • ex-Vim 사용자에게 친숙한 경험을 제공함
  • IDE라고 주장하지는 않지만, 실제 사용감은 IDE처럼 느껴짐

Doom Emacs가 바꾼 사용 경험

• Doom Emacs를 설정한 뒤 Emacs가 2015년 VSCode처럼 다시 “맞는 도구”로 느껴짐
• 많은 Emacs 기능이 space 기반 단축키 뒤의 인터랙티브 팝업 메뉴로 드러나 발견하기 쉬워짐
• Vim 스타일 키 바인딩과 공존하면서 손목에 부담을 덜 주는 단축키 흐름을 제공함
• 설정은 세 개의 간단한 파일로 나뉨
  • config.el: theme, font 같은 전역 설정 지정
  • init.el: 활성화할 Doom 전용 모듈 선택
  • packages.el: Doom에 포함되지 않은 패키지 설치
• 기본값은 합리적이고, 조정할 만한 세부 항목에는 주석이 충분히 달려 있음
• LSP의 발전과 tree-sitter 같은 현대 기능 덕분에 Emacs가 이제 IDE처럼 느껴짐
  • 다뤄야 하는 대부분의 언어에서 제대로 된 언어 통합을 얻음

어디서든 같은 개발 환경을 쓰는 가치

• 가장 강력한 기능은 어떤 머신에서 작업하든 동일한 개발 환경을 얻는 점임
• 작업 대상은 MacBook, Linux laptop, Linux cloud workstation, 개인 FreeBSD server까지 포함됨
• 필요한 것은 shell, tmux, Emacs뿐임
• 다양한 머신에서 일할 때 같은 환경과 근육 기억은 생산성에 직접적인 가치를 줌
• 이 필요 때문에 Emacs는 과거보다 더 중요한 도구가 됨

Doom Emacs가 너무 많은 일을 하는가

• Doom Emacs에는 “너무 많은 일을 한다”는 불만이 있지만, 실제로 많은 일을 해주기 때문에 유용함
• 언젠가는 Emacs 자체를 더 배우기 위해 구성을 줄일 수 있을지 고민하게 됨
• 여러 현대적인 서드파티 모듈이 기본 Emacs 패키지로 들어가는 흐름도 이런 고민을 키움
• 최근에는 Bedrock이나 Emacs Solo 배포판을 시도해보고 싶은 마음도 있음
• 다만 전환에 필요한 활성화 에너지가 높고, 그 길을 택하더라도 결국 “raw” Emacs까지 가지 않는 이유를 다시 묻게 됨

Elisp, Org mode, Magit에 대한 거리감

• Emacs가 Elisp 기반이라 사람들의 워크플로를 어떻게 크게 바꾸는지는 아직 완전히 이해하지 못함
• Emacs 안에서 더 많은 로직과 워크플로를 구현할 수는 있지만, 이미 shell script로 거의 모든 일을 쉽게 처리하고 있음
• script는 “Unix is my IDE”라는 관점에서 더 Unix답게 느껴짐
• Org mode와 Magit이 독립 애플리케이션이 아니라 Emacs 뒤에 묶여 있는 점은 마음에 들지 않음
• 서로 다른 원격 머신에서 계속 작업해야 하는 필요가 남아 있는 한, Emacs는 여전히 중요한 도구로 남음