45년을 버틴 에디터, GNU Emacs는 속을 어떻게 설계했을까

'에디터'가 아니라 '작은 운영체제'라는 농담

Emacs를 두고 개발자들이 반쯤 농담으로 하는 말이 있어요. "Emacs는 훌륭한 운영체제인데, 다만 쓸 만한 텍스트 에디터가 없다"는 거죠. 이게 왜 나온 말이냐면, Emacs 안에서 메일을 읽고, 웹을 보고, 심리상담 흉내(M-x doctor)까지 돌릴 수 있을 만큼 무한히 확장되기 때문이에요. 이번에 공개된 GNU Emacs 아키텍처 분석 문서는 바로 그 '끝없는 확장성'이 대체 어떤 구조에서 나오는지를 뜯어봐요. 1980년대에 설계된 프로그램이 아직도 현역인 비결이 여기 있거든요.

핵심은 '작은 C 심장 + 거대한 Lisp 몸통'

Emacs 구조의 핵심을 한마디로 하면, 아주 작은 C 언어 코어 위에 어마어마한 양의 Emacs Lisp가 올라가 있는 2층 구조예요. 이게 무슨 뜻이냐면요, 화면에 글자를 그리고, 키보드 입력을 받고, 파일을 읽는 것처럼 속도가 중요하고 저수준인 부분만 C로 딱딱하게 만들어 두고요. 그 위에서 '들여쓰기 규칙', '단축키 동작', '검색 기능' 같은 실제 기능들은 대부분 Emacs Lisp라는 내장 언어로 짜여 있어요. 그러니까 C 코어는 'Lisp를 실행하는 엔진'이고, 우리가 쓰는 기능 대부분은 그 엔진 위에서 도는 스크립트인 셈이에요.

왜 이렇게 만들었을까요? 바로 사용자가 프로그램을 실행 중에 뜯어고칠 수 있게 하려고요. 보통 프로그램은 기능을 바꾸려면 소스를 고치고 다시 컴파일해서 재실행해야 하잖아요. 그런데 Emacs는 지금 켜져 있는 상태 그대로, 함수 하나를 새로 정의하면 즉시 동작이 바뀌어요. 에디터 자기 자신이 자기를 수정하는 도구가 되는 거죠. 이 '살아있는 상태에서의 확장'이 Emacs 철학의 본질이에요.

버퍼, 재표시, 그리고 덤프(dump)

문서가 짚는 개념 몇 개만 쉽게 풀어볼게요. 먼저 '버퍼(buffer)'는 여러분이 편집 중인 텍스트가 담기는 메모리 공간이에요. Emacs는 화면에 보이는 파일뿐 아니라 내부 상태까지 전부 버퍼로 다뤄서, 텍스트를 다루는 모든 도구가 같은 방식으로 동작해요. '재표시(redisplay)'는 텍스트가 바뀌었을 때 화면 중 달라진 부분만 골라 다시 그리는 최적화 엔진이고요. 흥미로운 건 '덤프'인데요, Emacs는 시작할 때 방대한 Lisp 코드를 매번 다시 읽으면 느리니까, 기본 함수들을 한 번 메모리에 다 올린 상태를 통째로 저장해 두었다가 그걸 불러오는 방식으로 부팅을 빠르게 해요. 실행 중인 프로그램 상태를 그대로 얼려 저장한다는 발상이 꽤 독특하죠.

업계 맥락에서 보면

이런 '코어 + 스크립트 언어' 구조는 사실 지금도 곳곳에 살아있어요. VS Code가 성능 민감한 부분은 네이티브로 두고 확장(extension)은 자바스크립트로 짜게 한 것도, 게임 엔진이 C++ 위에 Lua 스크립트를 얹는 것도 결국 같은 아이디어예요. 다만 Emacs는 이 방향을 40년 넘게 극단까지 밀어붙였다는 점에서 원조 격이에요. '에디터를 확장 가능한 플랫폼으로 만든다'는 발상의 뿌리를 여기서 볼 수 있죠.

한국 개발자에게 주는 시사점

Emacs를 지금 당장 쓰라는 얘기는 아니에요. 다만 오래 살아남는 소프트웨어의 설계 원리를 배우기엔 최고의 교과서예요. 바뀌지 않을 핵심은 단단한 저수준 언어로, 자주 바뀔 기능은 유연한 스크립트 계층으로 분리한다 — 이 원칙은 플러그인 아키텍처나 확장 가능한 서비스를 설계할 때 그대로 적용돼요. 여러분이 만든 시스템 중에서 '핵심'과 '자주 바뀌는 부분'은 잘 나뉘어 있나요? 한번 들여다보면 재밌을 거예요.