# 아직도 Emacs를 쓰는 사람이 있나요? > Clean Markdown view of GeekNews topic #30682. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30682](https://news.hada.io/topic?id=30682) - GeekNews Markdown: [https://news.hada.io/topic/30682.md](https://news.hada.io/topic/30682.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-21T10:02:47+09:00 - Updated: 2026-06-21T10:02:47+09:00 - Original source: [jmmv.dev](https://jmmv.dev/2026/06/is-anyone-still-using-emacs.html) - Points: 1 - Comments: 1 ## Topic Body - 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](https://github.com/doomemacs/)를 접함 - 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](https://github.com/ashton314/emacs-bedrock)이나 [Emacs Solo](https://github.com/LionyxML/emacs-solo) 배포판을 시도해보고 싶은 마음도 있음 - 다만 전환에 필요한 **활성화 에너지**가 높고, 그 길을 택하더라도 결국 “raw” Emacs까지 가지 않는 이유를 다시 묻게 됨 ### Elisp, Org mode, Magit에 대한 거리감 - Emacs가 **Elisp** 기반이라 사람들의 워크플로를 어떻게 크게 바꾸는지는 아직 완전히 이해하지 못함 - Emacs 안에서 더 많은 로직과 워크플로를 구현할 수는 있지만, 이미 shell script로 거의 모든 일을 쉽게 처리하고 있음 - script는 “Unix is my IDE”라는 관점에서 더 Unix답게 느껴짐 - [Org mode](https://orgmode.org/)와 [Magit](https://magit.vc/)이 독립 애플리케이션이 아니라 Emacs 뒤에 묶여 있는 점은 마음에 들지 않음 - 서로 다른 원격 머신에서 계속 작업해야 하는 필요가 남아 있는 한, Emacs는 여전히 중요한 도구로 남음 ## Comments ### Comment 60052 - Author: neo - Created: 2026-06-21T10:02:49+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/s1ep1w/is_anyone_still_using_emacs) - 이 글은 주제가 **너무 웃겨서** 썼음 특정 질문 때문이 아니라, 회사의 높은 직급 사람들이 CLI 기반 코딩 에이전트를 쓰느라 **명령줄 도구**를 “발견”하고, 그 새 발견이 얼마나 유용한지 보여주려는 모습을 보고 있기 때문임 지금까지는 tmux가 대표 사례이고, 곧 Vim과 Emacs도 있다는 걸 깨닫기를 기다리는 중 이런 도구들은 오랫동안 곁에 있었고, 회사의 “고급 10x 개발자”에게 물어보면 아마 쓰고 있다고 할 것임 그런데도 흔히 “하하, 그거 고대 유물이지. 웹으로 가자!!11” 취급을 받았음. 어쩌면 그 개발자들이 이 도구들을 계속 쓰는 데는 이유가 있었을지도 모름 ;P - “저품질 생성물 거품”의 한 가지 좋은 점은, **일반 텍스트**가 다시 유효하고 중요한 매체가 되고 있다는 점임 CLI가 더 흔해지고, 구전되던 지식이 많이 문서화되는 것도 포함됨. 물론 사람이 만든 지식이라는 전제가 필요함 지금의 곤란한 시기를 지나도 이런 좋은 부분은 남았으면 함 - Emacs 사용자의 대부분은 아마 **GUI**로 쓰고 있을 것 같음. 숫자는 없지만, 압도적 다수일 거라고 봄 - 나도 이제 막 배우기 시작한 쪽에 포함됨 몇 년 전 **Doom Emacs**를 써봤지만 지연이 거슬릴 정도로 느껴져서 튕겨 나왔음. 네이티브 컴파일 덕분에 이제는 과거 일이 됐는지는 모르겠고, 아직 아무 설정 없는 기본 Emacs라 체감하기 어려움. Nixpkgs의 30.2를 쓰고 있는데, 기본으로 네이티브 컴파일이 켜져 있는 것 같음 Emacs에서 이메일을 쓰는 기능 같은 건 크게 관심 없고, 내가 원하는 대로 빚을 수 있는 편집기가 필요함. 나중에 Lisp를 배우고 싶을 때도 쓸 수 있으면 좋겠고, 아마 Janet이 될 듯함. Helix는 아직 플러그인이 없어서 Lisp 쪽은 선택지가 거의 없음. “모든 것은 텍스트”라는 철학도 마음에 드는데, 실제로 잘 맞을지는 두고 봐야 함 2026년에 배우기에는 부담스러운 점도 있음. 수십 년간 쌓인 **암묵지** 때문에 글을 읽으면 패키지 이름, 명령 이름 등이 마구 나오고, 단지 `$THING`을 하고 싶을 뿐인데 압도됨. 그래서 안내된 학습 경로로 [Mastering Emacs](https://www.masteringemacs.org/)를 집어 들었음 기본 키 바인딩도 꽤 이상함. 전부 다시 묶을 수 있다는 건 알지만 일이 늘어남. 게다가 분리형 인체공학 키보드를 직접 만들고, 수정 키를 핵심 흐름으로 쓰지 않는 Vim/Helix식 작업 방식에 맞춰 펌웨어도 조정해둔 상태임 MacBook Pro, PC, 커스텀 키보드까지 세 종류를 오가므로 머리가 녹지 않는 일관된 키 바인딩을 찾아야 함. `hjkl`은 모든 키보드에서 같은 위치지만 `Ctrl` 같은 키는 그렇지 않음 - 키 바인딩이 어렵고 Vim 쪽에 더 익숙하다면 [evil](https://github.com/emacs-evil/evil)을 봐볼 만함 evil은 “Emacs의 참된 복음”을 배우기 싫은 Vim 피난민용이라는 훈계를 들을 수도 있지만, **Emacs의 참된 복음®** 은 자신에게 가장 잘 맞는 방식으로 쓰는 것임 1998년부터 Emacs를 썼고 Vim 애호가는 전혀 아니었음. 2011년쯤 손목 반복사용손상 문제가 조금 생겨 이를 줄여줄 패키지들을 시도했고, 몇 년간 [god mode](https://github.com/emacsorphanage/god-mode)를 많이 썼지만 여전히 어색했음 그러다 “안 될 걸 증명하려고” 평생 Vim을 써본 적도 없던 상태에서 evil을 써봤는데, 일주일 만에 god mode만큼 능숙해졌고 한 달 뒤에는 공식 Emacs 키 바인딩을 쓸 때보다 더 빨라졌음 그렇다고 기본 키 바인딩이 틀렸다는 뜻은 아님. 내 손목이 좋지 않아서 경험이 다를 수 있음. [boon](https://github.com/jyp/boon)이나 [meow](https://github.com/meow-edit/meow)도 잘 맞을 수 있음 다만 evil이 잘 맞는다면 죄책감은 전혀 가질 필요 없음. Emacs가 사용자를 바꾸기도 하지만, 그보다 훨씬 크게 Emacs가 사용자를 위해 바뀌어줌 - Doom은 어떻게 설정하느냐에 따라 정말 달라짐. 그 부분도 시간이 지나며 계속 나아지고 있음 가장 좋은 건 직접 구성하는 것이지만 일이 많고, Doom 같은 프로젝트는 **신규 사용자 진입**을 확실히 쉽게 만들어줌 - 기본 키 바인딩이 이상하다는 점이 오히려 Doom Emacs에서 마음에 들었음 예전에는 기본 Emacs 키 바인딩을 꽤 알고 있었지만 자연스럽다고 느낀 적은 없고, 특히 발견 가능성이 낮았음 Doom Emacs는 거의 모든 작업에 **SPC 접두키**를 쓰고, 잠깐 멈추면 가능한 완성을 설명하는 일시 메뉴가 떠서 꽤 좋음. 몰랐던 기능을 찾아낼 수 있고 Vim 모달 모드와도 충돌하지 않음 그래서 텍스트 편집은 Vim 모드, Emacs 작업은 SPC 조합으로 하는 구성이 좋은 균형처럼 느껴짐 Emacs 기본 키 바인딩의 장점도 있음. 기본 텍스트 조작 키들이 readline, 심지어 macOS와도 공유됨. macOS의 Emacs식 텍스트 관리 키가 VSCode에도 전파되고 표준 클립보드 키와 충돌하지 않아서 macOS의 VSCode는 꽤 좋았음 Windows와 Linux로 옮긴 뒤에는 Vim 플러그인 없는 VSCode를 도저히 견디기 어려웠음 - Helix에서 왔다면 [meow](https://github.com/meow-edit/meow)를 봐도 좋음 Kakoune과 Helix 비슷한 기능을 기본 제공한다고 들었고, 방해를 덜 하려는 쪽임. 둘 다 직접 써본 건 아니라 들은 바에 근거한 말임 추천받은 evil 패키지는 키 바인딩을 너무 많이 장악하고 외부 패키지들과 잘 어울리지 않아 “어댑터” 패키지가 많이 필요하다는 문제가 있다고 봄 meow는 한 번 설정한 뒤에는 꽤 손이 덜 가는 편이었음 - **33년**째 쓰고 있는데, 편집기나 IDE에 필요한 건 전부 해줌 - Doom과 (n)vim 사이를 왔다 갔다 하다가 최근에는 대부분 **Neovim**에 정착했음 Emacs를 쓰며 겪은 핵심 문제는, 웃기게도 유지보수가 고통스럽다는 점이었음. Doom을 업그레이드하면 패키지 동기화가 어긋나서 완전히 재설치하는 핵폭탄 선택지만 남는 일이 잦았음 물론 더 “초보스럽지 않게” 고칠 수도 있었겠지만, 어느 순간부터는 그냥 도구가 동작하기만 바라게 됨. 해야 할 일이 있는데 설정이 깨지고 편집기에 과하게 의존하는 상황은 감당하기 어려움 그래도 org-mode와 Emacs의 전반적인 탐색 방식은 그리움 VSCode, CLion 같은 “현대적” 해법을 시도할 때마다 같은 문제를 더 많이 겪음. 제대로 된 접근성 기능이 없어서 순수 키보드 탐색 대신 어색하게 클릭해야 하고, “Vim” 동작도 진짜에 비하면 불완전함 요즘 Neovim을 쓰는 이유는 그냥 잘 동작하기 때문임. 사실 코딩 에이전트에게 설정을 고쳐달라고 2분만 시켰다면 지금의 Emacs도 똑같이 말할 수 있었을 듯함 (: - Doom의 `update` 기능을 몇 번 시도했지만 항상 문제가 생겼음 요즘은 업그레이드하고 싶거나 Emacs 업그레이드 때문에 필요할 때마다 `rm -rf ~/.emacs.d/`로 지우고 Doom을 처음부터 설정함. `~/.doom.d/`는 버전 관리에 넣어둠 이 흐름에서는 문제가 없었음 - 개발, 글쓰기, 이메일까지 **Emacs**로 하는 별난 사람이고, 그렇게 한 지 15년쯤 됐지만 elisp를 배울 시간이나 여유는 끝내 못 찾았음 설정 파일을 만질 때도 사실 뭘 하고 있는지 잘 모름. 그런데도 여전히 가장 생산적인 환경이라는 건 이 편집기가 얼마나 대단한지 보여줌 :-) [Mastering Emacs](https://www.masteringemacs.org/)를 제대로 읽는 일은 인정하기 부끄러울 만큼 오래 할 일 목록에 남아 있음 - 나도 거의 같은 배임. 설정을 고치고 편집하다 보니 삼투압처럼 elisp를 조금 알게 됐지만, 실제로 아는 양이 너무 적어서 좀 민망함 - `M-x high-five` 내 경우도 패키지를 아주 조금만 쓰고 원래 키 바인딩을 씀. 실제로 high-five 함수는 없지만, 이참에 드디어 elisp를 파볼지도 모르겠음 - Vim 렌더링이 마음에 안 들고 Electron/VSCode류에도 질려서 약 2년 전에 Emacs로 옮겼음 **avy**와 몇몇 점프 플러그인에 꽂혔지만, 계속 붙잡아두고 지금도 코드 변경의 주력 도구로 쓰게 만든 건 **magit**임 - 업무에서 상대하는 고객사는 사업 전체가 아주 큰 CSV 파일 활용에 달려 있는데, 그쪽에서는 **1GB 파일**의 데이터를 열거나 검토하는 법을 아는 사람이 없어 보임 CSV 헤더를 달라고 할 때 쓸 `head` 명령도 모름 - 수년간 X/GUI로 쓰다가 방금 `-nw`로 전환했음 발표할 때만 **Pgtk 버전**을 사용함