Hacker News는 Bozhidar Batsov의 Emacs and Vim in the Age of AI를 계기로 더 큰 질문을 던졌다. 코드 작성의 중심이 직접 타이핑에서 AI를 지시하고 검토하는 방향으로 이동할 때, programmable editor의 가치는 무엇으로 재정의되는가 하는 문제다. 이 HN 제출은 2026년 3월 10일 올라온 뒤 score 117과 comment 60개를 기록했다. 이번 주 HN에서 AI가 developer tool의 우선순위를 어떻게 다시 정렬하는지 가장 선명하게 보여준 토론 중 하나라고 볼 수 있다.

Batsov가 정리한 위험 요인은 꽤 현실적이다. VS Code는 이미 배포력과 기업 지원을 갖고 있고, Cursor나 Windsurf 같은 AI-first editor는 agent loop, inline diff, context management, multi-file editing을 중심에 두고 설계되고 있다. 이런 환경에서는 Emacs와 Vim이 오랫동안 내세워온 “인간이 코드를 더 빨리 편집하게 해준다”는 가치가 덜 결정적으로 보일 수 있다. AI가 초안을 대부분 만들어준다면 병목은 typing speed가 아니라 intent를 얼마나 명확히 설명하고, 결과를 얼마나 잘 평가하며, 구조적 판단을 얼마나 정확히 내리느냐로 옮겨가기 때문이다. Batsov는 또한 Microsoft나 VC-backed startup과 달리 Emacs, Vim, Neovim 생태계는 주로 volunteer에 의존한다는 funding gap도 지적했다.

하지만 이 글은 비관론으로 끝나지 않는다. 가장 흥미로운 반론은 AI가 오히려 두 생태계의 오래된 약점을 줄일 수 있다는 점이다. 사용자가 원하는 동작을 자연어로 설명하고 Elisp, VimScript, Lua 코드를 초안으로 얻을 수 있다면 customization과 plugin development의 진입장벽은 크게 낮아진다. 실제로 Batsov는 gptel, ellama, aider.el, agent-shell, avante.nvim, codecompanion.nvim 같은 통합이 이미 존재한다고 짚었다. Claude Code나 Aider처럼 terminal-native한 도구는 오히려 전통적인 editor workflow와 잘 맞을 수 있다는 관점도 흥미롭다.

이 글이 HN에서 의미 있었던 이유는 “legacy editor는 끝났다” 혹은 “아무것도 안 바뀐다” 같은 단순한 결론을 피했기 때문이다. 더 설득력 있는 해석은 editor가 점점 review, orchestration, refinement를 위한 control surface로 바뀌고 있다는 것이다. 이 변화는 typing speed만을 내세우는 도구에는 불리할 수 있지만, composable하고 inspectable하며 deeply scriptable한 도구에는 오히려 기회가 될 수 있다. Emacs와 Vim의 미래는 Cursor를 그대로 복제하는 데 있지 않고, 기존의 유연성을 더 나은 AI workflow로 바꾸는 데 있을 가능성이 크다. 원문은 batsov.com/articles/2026/03/09/emacs-and-vim-in-the-age-of-ai에서 읽을 수 있다.

#vim

Hacker News, AI 시대에도 Emacs와 Vim이 경쟁력을 유지할지 토론