Emacs, 단순 편집기를 넘어선 C 기반 Lisp 런타임의 세계
Emacs는 단순한 텍스트 편집기가 아닌, C로 구현된 Lisp 런타임(Lisp Runtime)을 내장한 강력한 시스템임
Emacs Lisp를 통해 사용자 정의 및 확장이 가능하며, 40년 이상 사용되는 이유를 설명함
VSCode, Neovim 등 다른 편집기와의 비교를 통해 Emacs의 아키텍처(Architecture)와 성능을 분석함
Greenspun's Tenth Rule을 통해 복잡한 소프트웨어의 DSL(Domain Specific Language) 진화 패턴을 설명함
Emacs의 Lisp 런타임 구현
Emacs는 C로 구현된 Lisp 인터프리터(Interpreter)를 핵심으로 사용하며, 이는 Emacs의 강력한 확장성의 근간이다. 특히, Emacs Lisp를 통해 사용자는 편집기 자체를 프로그래밍하여 기능을 확장할 수 있다. 이러한 아키텍처는 1970년대 TECO 매크로 언어에서 시작되어 Lisp의 장점을 활용, 런타임(Runtime) 환경에서 편집기를 커스터마이징(Customizing)할 수 있도록 진화했다.
Emacs vs Neovim: 아키텍처 비교
Emacs와 Neovim은 모두 런타임을 내장한 편집기이지만, 아키텍처(Architecture)에서 차이를 보인다. Emacs는 모놀리식(Monolithic) C 코어에 Elisp 인터프리터를 내장한 반면, Neovim은 C 코어에 LuaJIT와 Msgpack RPC를 활용한다. 이러한 차이는 동시성(Concurrency) 처리 방식과 플러그인(Plugin) 아키텍처에 영향을 미치며, Neovim이 더 현대적인 기술을 활용하여 성능 우위를 보이는 경우도 있다.
Greenspun's Tenth Rule과 소프트웨어 진화
Greenspun's Tenth Rule은 충분히 복잡한 C 또는 Fortran 프로그램은 결국 Lisp의 절반을 구현한다는 법칙이다. Emacs, Vim, VSCode 등 다양한 편집기에서 DSL(Domain Specific Language)과 가상 머신(Virtual Machine)이 등장하는 현상은 이 법칙을 따른다. 이는 소프트웨어의 복잡성이 증가함에 따라 특정 도메인에 특화된 언어와 런타임이 필요해지는 자연스러운 결과이다.
편집기의 성능과 사용자 경험
VSCode는 Electron 기반으로, JavaScript와 V8 엔진을 사용하며, JIT, SIMD, 비동기 IPC를 통해 사용자 인터페이스(UI)의 응답성을 유지한다. Emacs는 Lisp 인터프리터의 성능 문제로 인해 Neovim에 비해 느리다는 인식이 존재하지만, Emacs의 편집 표면은 여전히 강력한 장점으로 평가받는다. 사용자들은 편집기의 성능뿐만 아니라, 자신에게 맞는 사용성(Usability)을 중요하게 생각한다.
