AI 도구가 개발 워크플로를 재편하는 가운데 Emacs와 Vim이 직면한 위험과 기회, 그리고 에디터의 역할 변화와 윤리적 쟁점을 살펴본다.
미래를 예측하기는 어렵다. 특히 미래에 대해서는.
– Yogi Berra
나는 20년 넘게 Emacs 열성 팬이었다. 가장 인기 있는 Emacs 패키지들 가운데 일부를 만들고 유지보수했으며, Emacs 자체에도 기여했고, 설정을 다듬는 데에 수없이 많은 시간을 쏟았다. Emacs는 내게 단순한 에디터가 아니다. 내 열정이자, 내가 가장 편안함을 느끼는 공간이다.
지난 1년 동안은 Vim과 Neovim에도 많은 시간을 썼다. 처음부터 다시 배우며, 두 커뮤니티가 비슷한 문제를 어떻게 다르게 접근하는지 대비해 보는 재미에 푹 빠졌다. 즐겁고 신선한 경험이었다.1
그리고 요즘은, 우리 업계의 다른 사람들과 마찬가지로, AI 도구들을 만지작거리고 있다. 특히 Claude Code 말이다. AI가 더 넓은 프로그래밍 지형에 어떤 영향을 주는지 지켜보고, 이것이 프로그래밍의 미래에 무엇을 의미하는지 곱씹어 본다. 당연히 나는 같은 질문으로 계속 돌아오게 된다. 이 용감한 신세계에서 내가 사랑하는 Emacs와 그 “숙적” Vim은 어떻게 되는 걸까?
내 생각에 답은 “둘 다 망한다”나 “아무것도 변하지 않는다” 중 하나로 깔끔하게 떨어지지 않는다. 미래를 예측하는 일은 분명 어렵지만, 그걸 두고 상상해 보는 건 정말 재미있다.
내 논리는 이렇다. 거대한 산업 변화는 그 안에 있는 사람들에게 항상 많은 위험과 기회를 동시에 가져온다. 그래서 Emacs와 Vim에 어떤 위험과 기회가 있는지 조금 시간을 들여 곱씹어 보고 싶다.
VS Code는 이미 압도적인 격차로 지배적인 에디터가 되었고, 앞으로 주요 AI 도구들과 모두 1급 통합을 받게 될 것이다. Copilot(당연히), Codex, Claude, Gemini 등등, 무엇이든 말이다. Microsoft는 VS Code를 AI 보조 개발을 위한 최고의 호스트로 만들 충분한 유인이 있고, 그걸 해낼 자원도 갖고 있다.
거기에 더해 Cursor, Windsurf 같은 목적형 AI 에디터들과 그 밖의 여러 도구들이 막대한 투자와 인재를 끌어모으고 있다. 이들은 기존 에디터에 AI를 ‘덤’처럼 덧붙이는 게 아니라, AI 워크플로를 중심으로 전체 경험을 설계한다. 통합된 컨텍스트 관리, 인라인 diff, 멀티 파일 편집, 그리고 억지로 붙인 느낌이 아니라 자연스럽게 녹아든 에이전트 루프를 제공한다.
이런 도구로 옮겨가는 개발자 한 명 한 명은 Emacs나 Vim 키바인딩을 배우지 않는 개발자이고, Elisp를 쓰지 않는 개발자이며, 우리 생태계에 기여하지 않는 개발자다. 중력 우물은 واقعی로 존재한다.
나는 Cursor와 Windsurf를 한 번도 써 보지 않았는데, 본질적으로 VS Code의 포크라고 할 수 있고 나는 VS Code를 도저히 못 견디기 때문이다. 여러 해에 걸쳐 몇 번이나 시도해 봤지만, 여러 이유로 그 안에서는 생산적이라고 느껴본 적이 없다.
Emacs와 Vim의 강점 중 하나는 언제나 코드를 쓰고 편집하는 속도를 올려준다는 점이었다. 키바인딩, 매크로, 확장성—모두가 인간이 코딩이라는 기계적 행위를 더 효율적으로 하도록 돕기 위한 것이다.
하지만 AI가 코드의 대부분을 작성하게 된다면, 기계적 편집 속도가 얼마나 중요할까? 문자 하나하나를 타이핑하는 대신 AI가 생성한 diff를 검토하고 방향을 잡는 일이 된다면, 병목은 “얼마나 빨리 편집할 수 있나”에서 “의도를 얼마나 잘 명세하고 결과물을 얼마나 잘 평가하나”로 옮겨간다. 이는 근본적으로 다른 능력이며, Emacs나 Vim이 여기서 본질적인 우위를 가진다고 말하기도 애매하다.
학습 곡선에 대한 논리도 설득력이 약해진다. “Emacs를 6개월 배우면 10배 빨라진다”는 말은 Cursor를 쓰는 주니어 개발자가 하루 오후 만에 애플리케이션 전체의 뼈대를 세울 수 있는 시대에는 팔기 어려운 주장이다.2
VS Code 뒤에는 Microsoft가 있다. Cursor 뒤에는 벤처 자본이 있다. Emacs 뒤에는… 소수의 자원봉사자들과 FSF가 있다. Vim에는 Bram이 있었고, 지금은 유지보수 커뮤니티가 있다. Neovim에는 작지만 헌신적인 코어 팀이 있다.
물론 이런 구도는 원래도 그랬지만, AI는 그 격차를 더 키운다. 깊은 AI 통합을 만들려면 빠르게 변하는 API, 모델, 패러다임을 계속 따라가야 한다. 자금이 풍부한 팀은 전담 엔지니어를 풀타임으로 붙일 수 있다. 자원봉사 기반 프로젝트는 사람들의 여가 시간과 열정의 속도로 움직일 수밖에 없다.
끝까지 가 보자. 향후 10년 안에 우리가 아는 형태의 프로그래밍이 완전히 자동화된다면 어떨까? AI 에이전트가 명세를 받아 인간 개입 없이도 동작하고, 테스트되고, 배포되는 소프트웨어를 만들어낸다면, 우리는 코딩 에디터 자체가 필요 없게 된다. Emacs도, Vim도, VS Code도, Cursor도. 카테고리 전체가 무의미해진다.
나는 단기적으로 그럴 가능성이 크다고 보진 않지만, 가능성으로서 인정할 가치는 있다. AI 역량의 궤적은 낙관론자들조차 놀라게 했다(나도 처음엔 AI 회의론자였지만, 지난 1년의 급격한 발전이 결국 내 생각을 바꿨다).
거의 아무도 이야기하지 않는 점이 하나 있다. Emacs와 Vim은 언제나 확장 언어의 난해함 때문에 고생해 왔다. Emacs Lisp는 1980년대의 Lisp 방언으로, 대부분의 프로그래머가 한 번도 본 적이 없다. VimScript는… VimScript다. Neovim이 더 접근하기 쉽다는 이유로 채택한 Lua조차도, 대부분의 개발자가 한 줄도 써 본 적 없는 정도로는 충분히 니치하다.
이것이 두 생태계 모두에서 가장 큰 병목이었다. 에디터 자체는 엄청나게 강력하지만, 커스터마이징하려면 낯선 언어를 배워야 하고, 대부분의 사람은 블로그 글이나 README에서 조각을 복사해 붙이는 단계에서 더 나아가지 못한다.
나도 처음 Emacs와 Vim을 배울 때 Elisp와 VimScript가 너무 부담스럽게 느껴졌고, 나만 그랬던 건 아닐 거라고 생각한다. Emacs에서 정말 생산적이라고 느끼게 된 건 Elisp를 제대로 배우는 데 꽤 많은 시간을 투자한 뒤였다. (VimScript는 같은 일을 할 생각조차 안 했고, 솔직히 Lua도 마스터하고 싶은 마음이 크진 않다.)
AI는 이것을 하룻밤 사이에 바꾼다. 이제는 평범한 영어로 원하는 것을 설명하면 동작하는 Elisp, VimScript, Lua 코드를 얻을 수 있다. “현재 문단을 72컬럼으로 재포맷하고 접두사를 추가하는 Emacs 함수를 써 줘”—끝. “lazy.nvim을 설정해서 LSP를 이 키바인딩으로 구성해 줘”—끝. 수십 년 동안 채택을 가로막아 온 확장 언어 장벽이 갑자기 훨씬 낮아진다.
Emacs 커뮤니티에서 20년 넘게 지내다 보니, 의미 있는 진전의 대부분을 비교적 소수—아마 50명에서 100명 정도—가 이끈다는 느낌을 자주 받는다. MELPA에서도, 메일링 리스트에서도, 버그 리포트에서도 같은 이름들이 반복해서 등장한다. 이것은 그 사람들에 대한 비판이 아니다(나도 그들 중 하나라는 사실이 자랑스럽다). 하지만 구조적 약점이긴 하다. 소수의 기여자에게 의존하는 커뮤니티는 취약하다.
그리고 문제는 Elisp와 VimScript만이 아니다. Emacs와 Vim(그리고 Neovim의 C 코어)의 C 내부 구현은 더 작은 그룹이 유지하고 있다. 수십 년 된 C 코드베이스를 기꺼이, 그리고 능숙하게 해킹할 사람을 찾는 일은 진짜 어렵고, C 자체를 배우는 개발자가 줄어들수록 더 어려워지고 있다.
AI 도구는 여기서 두 가지 방식으로 도움이 된다. 첫째, 신규 기여자의 진입 장벽을 낮춘다. 만들고 싶은 것이 무엇인지 _개념_을 이해하는 사람이라면, 낯선 언어로 _구현_하는 데 AI의 도움을 받을 수 있다. 둘째, 기존 유지보수자가 더 빠르게 움직이도록 돕는다. 개인적으로 나는 AI가 테스트 스캐폴딩 생성, 문서 작성, 그리고 모든 것을 느리게 만드는 패키지 유지보수의 지루한 부분을 처리하는 데 탁월하다는 걸 체감했다.
Emacs와 Neovim 커뮤니티는 가만히 있지 않다. 이미 인상적인 AI 통합이 존재한다:
Emacs:
Neovim:
그리고 이것은 일부 사례에 불과하다. 이런 통합을 만드는 일이 생각만큼 어렵지 않다. API는 단순하고, 두 에디터의 확장성 덕분에 AI 도구를 ‘네이티브처럼’ 느껴지도록 엮을 수 있다. AI의 도움까지 받는다면, 새로운 통합을 만드는 일은 더 쉬워진다. 플러그인 개발 속도가 크게 가속될지도 모른다고 해도 놀랍지 않다.
더 주목받아야 할 아이러니가 하나 있다. 가장 강력한 AI 코딩 도구들 가운데 상당수는 터미널 네이티브다. Claude Code, Aider, 그리고 여러 Copilot CLI 도구들은 모두 터미널에서 실행된다. 그리고 터미널에 무엇이 있나? Emacs와 Vim이다.3
Emacs의 vterm 버퍼나 Neovim의 터미널 스플릿에서 Claude Code를 실행하는 워크플로는 아주 자연스럽다. 한쪽 창에는 AI 에이전트가, 다른 쪽 창에는 에디터가 있고, 익숙한 키바인딩과 도구를 그대로 유지한다. 다른 애플리케이션으로 컨텍스트를 전환할 필요가 없다—모든 것이 같은 환경 안에 있다.
이는 사실 GUI 기반 AI 에디터에 비해 장점이기도 하다. GUI 에디터에서는 AI 통합이 에디터 자체 인터페이스에 강하게 결합돼 있다. 터미널 네이티브 도구에서는 자신이 원하는 에디터와 자신이 원하는 AI 도구를 각각 선택할 수 있고, 둘은 자연스럽게 조합된다.
Emacs의 “운영체제로서의 에디터(editor as operating system)” 철학은 AI 통합에 유난히 잘 맞는다. Emacs는 단지 코드 에디터가 아니다. 메일 클라이언트(Gnus, mu4e)이기도 하고, 노트 작성 시스템(Org mode)이기도 하며, Git 인터페이스(Magit)이기도 하고, 터미널 에뮬레이터이자, 파일 매니저이자, RSS 리더이기도 하며, 그 외에도 훨씬 더 많은 것들이다.
AI는 이 모든 레이어에 통합될 수 있다. org-mode의 아젠다를 읽고, mu4e에서 이메일 답장을 초안 작성하며, Magit에서 커밋 메시지를 도와주고, 소스 버퍼에서 코드를 리팩터링하는 AI 어시스턴트를 상상해 보라—모두 동일한 환경 안에서, 컨텍스트를 공유하면서 말이다. Emacs만큼 이런 깊이의 범분야 통합을 자연스럽게 해내는 에디터 아키텍처는 없다.
물론 나는 오래전에 Emacs를 내 OS처럼 쓰는 것을 그만뒀고, 요즘은 주로 프로그래밍과 블로깅에만 사용한다. (markdown-mode의 도움을 받아 이 글도 Emacs에서 쓰고 있다.) 그래도 나는 Emacs 사용자 중 한 명일 뿐이고, 많은 사람들은 더 전체적인 방식으로 Emacs를 쓰고 있을 것이다.
Emacs와 Vim 사용자에게 AI가 주는 가장 과소평가된 이점 중 하나는 지극히 현실적인 것, 즉 트러블슈팅이다. 두 에디터는 악명 높을 정도로 학습 곡선이 가파르고 오류 메시지도 불투명하다. “Wrong type argument: stringp, nil”은 어떤 경쟁자보다도 더 많은 사람을 Emacs에서 떠나게 만들었다.
AI 도구는 난해한 오류 메시지를 설명하고, 설정 문제를 진단하고, 해결책을 제안하는 데 놀랄 만큼 능숙하다. init 파일을 읽고 문제를 찾아낼 수 있다. Elisp 코드 조각이 무슨 일을 하는지 설명할 수 있다. 왜 키바인딩이 동작하지 않는지 이해하도록 도울 수 있다. 이는 에디터를 더 단순하게 만들어서가 아니라, 모든 사용자에게 인내심 많고 지식 있는 안내자를 제공함으로써 학습 곡선을 크게 완만하게 만든다.
나는 내 Emacs 설정을 트러블슈팅하는 데 AI 도움이 별로 필요하진 않지만, 상대적으로 지식이 얕은 Neovim 쪽에서는 가끔 유용했다.
Claude Code 덕분에 설정 문제를 고치는 일이 고통스럽지 않게 되면서, 몇 년 만에 Emacs로 돌아온 사람이 있었다는 문서화된 사례가 최소 하나는 있다. 그 사람은 설정 부담이 너무 성가셔서 IntelliJ로 떠났다가, AI가 그 장벽을 없애자 다시 돌아왔다. 그 표현을 그대로 옮기면 “Happy f*cking days I’m home again”이라고 했다. AI가 이탈한 Emacs 사용자를 다시 데려올 수 있다면, 내 기준으로는 좋은 일이다.
종말 시나리오로 돌아가 보자. 프로그래밍이 완전히 자동화되어 더 이상 아무도 코드를 쓰지 않는다고 하자. 그럼 Emacs는 죽을까?
꼭 그렇지는 않다. Emacs는 이미 프로그래밍 외의 훨씬 더 많은 용도로 쓰인다. 사람들은 Org mode로 할 일, 노트, 캘린더, 일지, 시간 추적, 심지어 학술 논문까지—삶 전체를 관리한다. Emacs는 뛰어난 LaTeX, Markdown, AsciiDoc, plain text 지원을 갖춘 훌륭한 글쓰기 환경이기도 하다. 이메일을 읽고, 웹을 둘러보고, 파일을 관리하고, 그렇다—테트리스도 할 수 있다.
Vim도 마찬가지로, 하나의 프로그램이라기보다 텍스트 편집 패러다임에 가깝다. Vim 키바인딩은 컴퓨팅 세계의 모든 텍스트 입력 영역을 식민지화했다—VS Code, IntelliJ, 브라우저, 셸, 심지어 Emacs(Evil mode를 통해)까지. Vim _프로그램_이 사라지더라도, Vim _아이디어_는 불멸이다.4
그리고 누가 알겠는가—언젠가 장인 정신으로 손수 만든 소프트웨어를 찾는 시장이 생길지도. “지역에서 조달한, 방목한 코드, Emacs에서 인간이 작성.” 그런 티셔츠라면 난 살 거다. 그리고 그런 장인 프로그래머들이 VS Code를 쓰고 있지는 않을 거라는 점은 꽤 확신한다.
그러니 가장 극단적인 시나리오에서도, 두 에디터 모두 코드 너머의 삶이 있다. 어쩌면 축소된 삶일지 모르지만, 그래도 삶은 있다.
실제로 벌어지고 있는 일은 “에디터가 죽는다” 혹은 “에디터는 멀쩡하다”보다 더 흥미롭다고 생각한다. 에디터의 역할이 바뀌고 있다.
수십 년 동안 에디터는 코드를 _작성_하는 곳이었다. 이제 점점 더, AI가 작성한 코드를 검토하고, 방향을 제시하고, 다듬는 곳이 되고 있다. 중요한 기술도 타이핑 속도와 편집 체조에서, 명세의 명확성, 코드 읽기, 그리고 아키텍처 판단으로 이동하고 있다.
이 세계에서 이기는 에디터는 최고의 코드 완성 기능을 가진 에디터가 아니다. 워크플로를 가장 잘 통제할 수 있게 해주는 에디터다. 그리고 그것은 언제나 Emacs와 Vim의 핵심 가치 제안이었다.
문제는 커뮤니티가 충분히 빠르게 적응할 수 있느냐이다. 도구는 있다. 아키텍처도 있다. 철학도 맞다. 필요한 것은 사람이다—더 많은 기여자, 더 많은 플러그인 작성자, 더 많은 문서 작성자, 더 많은 대화의 목소리. AI는 그 간극을 메우는 데 도움을 줄 수 있지만, 진짜 커뮤니티 참여를 대체할 수는 없다.
Emacs와 Vim 커뮤니티의 모두가 AI에 열광하는 것은 아니며, 반대 이유는 단순한 기술 공포증을 넘어선다. 오랫동안 논쟁될 정당한 윤리적 우려가 있다:
에너지 소비. 대규모 언어 모델을 학습시키고 실행하는 데는 막대한 연산과 전기가 든다. 오랫동안 효율성과 미니멀리즘을 중시해 온 커뮤니티—40년 된 에디터를 돌리는 것을 자랑하는 Emacs 사용자, 1초도 안 되는 시작 시간을 뽐내는 Vim 사용자—에게 AI의 환경 비용은 무시하기 어렵다.
저작권과 학습 데이터. LLM은 방대한 코드와 텍스트 코퍼스에서 학습하며, 그 학습의 합법성과 윤리성은 여전히 논쟁적이다. 일부 개발자는 명시적 동의 없이 저작권 있는 코드에서 학습했을 수 있는 도구를 쓰는 데 불편함을 느낀다. 라이선스를 깊이 중시하는 오픈소스 커뮤니티에는 특히 민감한 문제다.
일자리 대체. AI가 개발자의 생산성을 크게 끌어올린다면, 더 적은 개발자만 필요할 수도 있다. 이는 어떤 프로그래밍 커뮤니티에게나 불편한 생각이며, 인간 프로그래머를 강화하는 데 정체성이 있는 에디터 커뮤니티에게는 특히 날카롭게 다가온다.
이런 우려는 이미 구체적 행동을 낳고 있다. Vim 커뮤니티에서는 최근 EVi가 만들어졌다. 이는 Vim의 포크로, 존재 이유 전체가 AI 보조(생성?) 코드 기여로부터 자유로운 텍스트 에디터를 제공하는 데 있다.5 전제에 동의하든 아니든, 이런 이유로 기존 에디터를 포크하는 사람이 있다는 사실만으로도 일부 커뮤니티 구성원이 얼마나 강하게 느끼는지 알 수 있다.
나는 이런 우려가 AI 도구를 탐색하는 것을 멈추게 해서는 안 된다고 생각하지만, 우려 자체는 واقعی이며 진지하게 받아들일 가치가 있다. 앞으로 몇 년 동안 emacs-devel과 Neovim 이슈 트래커에서 이에 대한 활발한 논쟁을 꽤 보게 될 거라고 예상한다.
미래는 예전 같지 않다.
– Yogi Berra
걱정하지 않는 척하진 않겠다. AI의 파도는 빠르게 움직이고, 기존 강자는 자금과 인지도에서 막대한 이점을 갖고 있으며, 프로그래밍의 본질 자체가 우리 발밑에서 바뀌고 있다. Emacs와 Vim이 점차 니치한 무명으로 사라져, 변화에 적응하기를 거부하는 소수의 완고한 사람들만 쓰게 될 가능성도 충분히 있다.
하지만 나는 20년 동안 “Emacs는 죽어간다”는 말을 들어왔고, Emacs는 아직 여기 있다. 커뮤니티는 작지만 열정적이고, 에디터는 그 어느 때보다 유능하며, 아키텍처는 AI 시대에 진심으로 잘 맞는다. Vim도 상황은 비슷하다—핵심 아이디어가 너무 강력해서 계속해서 새로운 형태로 표현된다(Neovim이 가장 최근이자 가장 활력 있는 화신이다).
살아남는 에디터는 가장 화려한 AI 기능을 가진 에디터가 아닐 것이다. 사용자들이 충분히 신경 써서 계속 만들고, 적응하고, 공유하는 에디터일 것이다. 그것이 언제나 오픈소스 소프트웨어의 진짜 엔진이었고, AI가 아무리 발전해도 그 사실은 바뀌지 않는다.
그러니 Emacs 또는 Vim 사용자라면: 당황하지 말되, 안주하지도 말자. (원칙적으로 반대하는 게 아니라면) 새로운 AI 도구들을 배워라. 설정을 멋지게 꾸미고 최고로 만들어라. 자신의 워크플로를 글로 써라. 새로 온 사람을 도와라. AI 시대에도 에디터가 살아남게 하는 가장 좋은 방법은, 그 시대 안에서 번성하게 만드는 것이다.
미래가 예전 같지 않을지도 모른다—하지만 그게 꼭 나쁜 것만은 아니다.
오늘은 여기까지다. 계속 해킹하자!
Vim 모험담이 궁금하다면, Learning Vim in 3 Steps에 써 두었다.↩︎
게다가 아마 Emacs에 몇 년은 더 투자해야, 기존에 쓰던 에디터/IDE보다 실제로 더 생산적이 될 것이다.↩︎
적어도 어느 정도는 그렇다. 솔직히 나는 보통 Emacs는 GUI 모드로 쓰지만, (Neo)vim은 언제나 터미널에서 쓴다.↩︎
Claude Code에도 vim mode가 있다.↩︎
