AI가 다 해주는 시대, Emacs 고수의 손놀림은 여전히 무기일까?

들어가며

수십 년 동안 Emacs 사용자들은 빠른 편집 속도, 끝없는 맞춤화, LISP의 표현력을 자랑해 왔습니다. 그런데 이제는 직접 타이핑하지 않고 AI에게 "이렇게 해줘"라고 말하는 방식이 자리 잡고 있습니다. 그렇다면 Emacs 숙련도는 앞으로도 경쟁력이 될까요? GeekNews에 소개된 글 「마법의 시대에 Emacs는 어디로 가는가」는 이 질문을 실제 사례와 함께 다룹니다. 핵심 내용을 정리해 보겠습니다.

핵심 요약

AI에게 원하는 결과를 말하는 방식이 퍼지면서 Emacs 숙련도의 우위가 약해지고 있습니다.
excali-mode.el과 cooked.el은 과거라면 엄두도 못 냈을 대규모 재구현을 AI로 해낸 사례입니다.
나만을 위한 일회성 소프트웨어가 늘어나는 흐름은 **'소프트웨어의 Emacs화'**라고 부를 수 있습니다.
다만 여기에는 역설이 있습니다. 원하는 동작을 얻더라도 그것이 어떻게 작동하는지는 아무도 모를 수 있습니다.

결정론적 컴퓨팅에서 확률적 AI로

글쓴이는 2025년 9월부터 Claude Code를 써 왔습니다. 처음부터 코딩 과정 전반을 처리하는 능력이 놀라웠고, 1년쯤 지나자 체감상 10배 정도 더 강력해졌다고 말합니다.

변화는 코딩에서 그치지 않습니다. Scott Aaronson이 **'The Mathocalypse'**라고 부른 흐름 속에서, OpenAI의 최신 모델은 연구 문제 8,000개를 3시간 동안 공략해 해결 가능성이 있는 결과 372개를 내놓았습니다. 그중 일부는 사람이 풀었다면 경력의 대표 성과가 될 만한 문제였다고 합니다. 다만 372개 모두가 검증을 마친 해답은 아니라는 점은 짚어 둘 필요가 있습니다.

지금까지 우리가 컴퓨터를 믿었던 이유는 같은 입력에 늘 같은 출력이 나온다는 결정론적 특성 덕분이었습니다. 켜짐과 꺼짐을 명확히 나누는 이진 신호와 명령을 그대로 수행하는 방식이 컴퓨터에 일을 맡기는 기반이었죠. 확률적으로 답을 내는 AI는 이 전제를 흔들고 있습니다.

규칙 기반 AI와 LISP의 유산

AI는 처음부터 확률적이지 않았습니다. 초기 AI는 규칙을 쌓아 지능을 흉내 내는 방식이었습니다.

초기 전문가 시스템은 끝이 없는 현실의 행동을 규칙만으로 모두 담을 수 있느냐는 한계에 부딪혔습니다.
RMS(Richard Stallman)가 회고한 MIT CSAIL의 회로 분석기는 연립방정식을 푸는 대신, 사람이 하듯 차례로 진단을 적용하는 방식을 썼습니다.
펀치카드 시절을 지나 입력한 글자가 편집기 화면에 바로 보이게 되자, 세상을 충분히 규칙화하면 지능을 만들 수 있다는 기대가 커졌습니다.
인간 문법의 재귀 구조와 잘 맞는다는 이유로 언어 연구에서는 LISP/Scheme이 주로 쓰였고, Prolog도 일부 쓰였습니다.

LISP는 C보다 느렸지만 표현의 경제성으로 이를 메웠습니다. 다만 C의 creat나 strpbrk가 그나마 실제 단어에서 온 이름인 것과 달리, LISP의 car와 cdr는 비전문가가 뜻을 짐작하기 어렵다는 지적도 덧붙입니다.

Emacs 숙련도가 더는 같은 무기가 아닌 이유

이 변화는 커밋 과정만 비교해 봐도 바로 보입니다.

Magit에서 커밋하기

C-x g로 Magit 화면 열기
S로 모든 변경 사항 스테이징
c c로 커밋을 시작하고 메시지 작성
C-c C-c로 마무리

Claude Code에서 커밋하기

작업 한 덩어리가 끝나면 회색 commit 제안이 뜹니다.
사용자는 탭과 엔터만 누르면 됩니다.

손에 익은 단축키 조합이 키 두 번으로 바뀐 셈입니다. Git 이력에는 Anthropic의 공동 작성자 표시가 붙는데, 이를 보면 사람이 실제로 얼마나 기여했는가라는 물음도 자연스럽게 떠오릅니다.

사례 1: excali-mode.el, 캔버스 하나 때문에 스택 전체를 다시 만들다

excali-mode.el은 Emacs에 새로 생긴 캔버스 기능을 쓰기 위해 Excalidraw를 계층마다 재구현한 프로젝트입니다.

Excalidraw는 원래 React 컴포넌트라서 브라우저 환경이 있어야 돌아갑니다. xwidget-webkit으로 웹뷰를 띄우는 방법도 있지만, 그러면 새 캔버스 API를 쓸 수 없습니다. 그래서 이 프로젝트는 아래처럼 계층을 하나씩 바꿨습니다.

| 원래 계층 | 대체한 계층 | |---|---| | 브라우저 | Emacs | | TypeScript → JavaScript | Elisp | | rough.js, Excalidraw 렌더링 코드 | excali-rough.c, excali-render.c 등 C 모듈 | | Skia 기반 Canvas 2D API | Cairo | | 텍스트 처리 | Pango | | <canvas> 요소 | Emacs 32 캔버스 이미지 |

작은 실험을 위해 애플리케이션 스택을 통째로 옮기는 일은 예전이라면 상상하기 어려웠습니다. 하지만 AI와 함께라면 이런 무모한 시도도 토큰 비용만 내면 해볼 수 있는 일이 됩니다.

참고로 원문에 나오는 고등학생과 Qwen의 대화 장면은 개발 과정을 상상해 본 것이고, 실제 대화 기록은 아닙니다.

사례 2: cooked.el, 텍스트 버퍼를 위해 터미널까지 만들다

한 달쯤 전 r/emacs에서는 comint의 편리함을 유지하는 터미널 모드에 대한 논의가 있었습니다. 터미널을 최대한 일반 텍스트 버퍼처럼 보이고 동작하게 하자는 것이 핵심이었고, 한 숙련자가 이런 출력을 "cooked"라고 불렀습니다.

며칠 뒤 한 고등학생이 cooked.el을 공개했습니다.

AI를 쓴 점에 대해 사과하면서도, 설계에는 자신이 적극적으로 참여했다고 밝혔습니다.
코드는 Claude가 작성했습니다.
가장 눈에 띄는 점은 Rust로 독립형 터미널 에뮬레이터를 직접 구현했다는 것입니다.

예전 같으면 기존 구현을 가져다 썼을 무거운 작업을 짧은 시간에 새로 만든 것입니다. 작은 기능 하나를 원했는데 거대한 기반 시스템까지 새로 생기는 AI 개발의 특징을 잘 보여 줍니다.

Emacs의 오래된 숙제, 이제는 의지의 문제

글쓴이는 전체 재구현이 의미 있을 만한 Emacs의 오래된 과제도 꼽습니다.

Elisp를 Guile Scheme으로 바꾸기
선점형 LISP 스레드 도입

관심 있는 Emacs 개발자라면 100달러 요금제와 긴 주말 하나로 쓸 만한 초안을 만들 수도 있다는 것이 글쓴이의 생각입니다. 물론 실제로 해 보거나 검증한 결과가 아니라 개인적인 판단입니다.

그런데도 아직 아무도 하지 않은 이유로, 기술적으로 어려워서라기보다 구현보다 논의에 더 관심이 많았기 때문이라는 비판을 소개합니다. 몇 년 전 YouTube에서 주목받은 Emacs 부흥 계획도 실제 코드 없이 관심만 모으다 잊혔습니다. '있으면 좋은 기능'을 '당연히 있어야 할 기능'처럼 말하는 불평은 직접 일하지 않고도 관심을 얻는 방법이 될 수 있다는 날카로운 지적도 나옵니다.

소프트웨어의 Emacs화: 나만을 위한 일회성 소프트웨어

코드 품질에 크게 신경 쓰지 않는 대다수 사용자 사이에서는 나에게 딱 맞춘 일회성 소프트웨어가 계속 늘어날 것으로 보입니다.

Hacker News의 "The Emacsification of Software" 토론에는 AI로 자기 취향에 정확히 맞춘 Markdown 뷰어를 만든 사례가 나옵니다.
디스어셈블할 수 있다면 폐쇄형 소프트웨어까지 포함해 모든 앱이 이렇게 개인화될 수 있습니다.
r/emacs의 분위기는 **"0% Product Hunt, 100% Show and Tell"**로 요약됩니다.

배포판 전체가 통일성을 갖추는 대신, 사람마다 자기만의 임시방편 코드를 모은 환경을 갖게 될 수도 있습니다. 사실 이것은 까다로운 취향에 맞춰 설정을 고쳐 온 Emacs 사용자들이 이미 익숙한 방식입니다.

만들고 버리기 쉬워질 때 생기는 자유의 역설

excali-mode.el이나 cooked.el처럼 만들고 버리는 일이 스위치를 켜고 끄듯 쉬워지면, '낭비'라는 전통적인 기준도 의미를 잃습니다.

더 나아가 AI가 Dario Amodei가 말한 "machines of loving grace"가 된다면, 언젠가는 고수준 언어를 거치지 않고 하드웨어에 직접 기계어를 쓰는 일까지 맡기게 될 수도 있습니다. 글쓴이는 이를 ACGT 염기 조합에서 생명이 만들어지는 과정에 비유할 만큼 큰 도약이라고 봅니다.

여기서 역설이 생깁니다.

Stallman이 말한 소프트웨어 자유는 코드를 읽고, 이해하고, 고칠 수 있는 자유였습니다.
AI는 상상하는 대로 컴퓨터를 움직이는 실질적인 자유를 줍니다.
하지만 그 대가로 사용자도, 다른 누구도 그것이 어떻게 작동하는지 모르게 될 수 있습니다.

마치며

이 글은 Emacs 이야기처럼 보이지만, 결국 AI 시대에 개발자의 숙련도와 소프트웨어 자유가 어떤 의미를 갖는지를 묻고 있습니다. 단축키를 손에 익히던 시간은 원하는 것을 정확히 설명하는 능력으로 옮겨 가고 있고, 누구나 자기만의 도구를 만들 수 있게 되었습니다. 그렇다면 이제 중요한 질문은 '무엇을 만들 수 있는가'보다 **'내가 만든 것을 이해하고 있는가'**일지도 모릅니다.

원문: GeekNews - 마법의 시대에 Emacs는 어디로 가는가

원문: https://news.hada.io/topic?id=37038&utm_source=geeknews&utm_medium=rss&utm_campaign=news