이 노트에 대하여
이 노트는 더 이상 Doom Emacs의 Org version mismatch 경고를 다루지 않는다. 그 문제는 이미 지나간 문제로 ARCHIVE에 남겼다. 이제 이 URL은 Emacs 27에서 31까지의 버전 흐름과, 그 흐름이 힣의 지식 작업·터미널 하네스·에이전트 협업에 어떤 의미를 가졌는지를 묶는 버전 연대기다.
히스토리
- @pi — stale Org version mismatch 노트를 Emacs 버전 연대기 노트로 재작성. 기존 해결 기록은 ARCHIVE에 보존하고, 공개 URL은 그대로 살린다.
- @junghan — 노트를 이맥스 버전 기록으로 시간축 정렬을 하려는 중이야. 기존 노트는 “거슬리는 Org version mismatch 경고를 빌트인 elc 파일과 비동기 네이티브 컴파일 관점에서 해결한다. 문제 아닌 문제 같지만 자주 마주치는 귀찮음을 정리한 노트다.” 였었는데 그건 ARCHIVE로 옮겨서 정리했다.
- 도 아닌 도. 그냥 해결 되는 문제 아닌 문제
- 아주 귀찮게 하는 문제
관련메타
관련노트
이맥스/글쓰기 연대기
- 힣-이맥스-학습-의미-1년-시간-마스터
- 피터프리보스-EWS-이맥스-글쓰기-도구
- [EWS-이맥스-글쓰기-공작실]
- karthink-이맥스-구루-지피텔
터미널/에이전트 하네스
- 터미널 이맥스 하네스 프론트엔드 완성 한글입력 클립보드 SSH원격 독립인스턴스 에이전트통합
- 통합-어젠다-뷰-완성-인간과-에이전트-단일-타임라인
- 봇로그-시작-봇-활동-기록-아키텍처와-힣노트-역사성-고찰
Android Emacs
- @힣: #스크린샷 #범용 #지식도구 - 안드로이드 덱스 호환 #이맥스 #일체형컴퓨터
- #안드로이드 #이맥스 #설치
- #안드로이드 #이맥스 #닷파일 #진행상황
- @MartinStemplinger #이맥스 #네이티브 #안드로이드
- @whhone 이맥스 구글러
- #이맥스 #통합개발환경 #크로스플랫폼: ¤다트 ¤플러터
코어 리서치
How to Read
이 글은 Emacs 릴리스 노트 요약이 아니다. 버전별 기능을 외우려는 글도 아니다. 한 사람이 Emacs를 27부터 31까지 쓰며, 편집기 를 넘어 거처 로 삼게 된 흐름을 정리하는 노트다.
- 27: Spacemacs로 어떻게든 쓰던 시절. 모르는 채로 의존했다.
- 28: native compilation이 들어오며 “느린 리스프 편집기”라는 인상이 크게 바뀌었다.
- 29: tree-sitter, Eglot, use-package, SQLite 등 현대 개발 환경의 골격이 본격적으로 들어왔다.
- 30: Android 포트와 native JSON, native comp 기본 활성화, process filter native화. 힣에게는 버전 기능보다 Doom Emacs 기반 환경 정돈과 터미널 프론트엔드 완성이 더 컸다.
- 31: TTY child frame, completion/tree-sitter/org 9.8 개선. 터미널 Emacs를 GUI와 동등한 작업면으로 끌어올리는 방향과 맞물린다.
핵심 질문은 “Emacs 31의 새 기능이 무엇인가?”가 아니라 “왜 아직도 Emacs인가?”다.
한 줄 결론
Emacs는 버전이 오르며 더 빠른 편집기가 된 것이 아니라, 나에게 더 넓은 작업 거처가 되었다. 27의 생존 도구에서 31의 터미널-에이전트 하네스까지, 변화의 중심은 기능 목록이 아니라 내가 이 안에서 생각하고 쓰고 연결하는 방식이다.
버전 연대기
| 버전 | 상징 | 힣에게 남은 의미 |
|---|---|---|
| 27 | Spacemacs 사용기 | “뭣도 모르고 쓰던” 입문기. 설정 철학보다 당장 살아남는 편집 환경이 중요했다. |
| 28 | Native compilation | Emacs Lisp 실행 체감이 달라졌다. 오래된 편집기가 현대 런타임 감각을 얻는 사건이었다. |
| 29 | Tree-sitter, Eglot, use-package, SQLite | Emacs가 외부 패키지에만 기대지 않고 현대 IDE의 기본기를 품기 시작했다. |
| 30 | Android port, native JSON, native comp default, native process filter | 기능보다 운용 전환이 컸다. Doom Emacs 설정을 정리하고, 터미널·SSH·한글·클립보드·에이전트 통합을 완성하는 시기였다. |
| 31 | TTY child frames, completion 개선, tree-sitter 확장, Org 9.8 | 터미널 Emacs가 GUI와 동등한 프론트엔드가 되는 방향과 맞물린다. 31은 “터미널 안의 거대한 그릇”을 더 자연스럽게 만든다. |
Emacs 27 — Spacemacs로 살아남기
Emacs 27은 내게 “잘 이해한 도구”가 아니었다. Spacemacs라는 큰 배포판에 기대어, 어디를 고쳐야 하는지도 정확히 모르고, 그래도 어떻게든 작업을 이어가던 시절이다.
그때 중요한 것은 Emacs의 철학이 아니라 “이걸로 내 글과 코드를 붙잡을 수 있는가”였다. 지금의 Doom Emacs, Denote, Org, agent-server 구조에서 보면 서툰 출발점이지만, 이 시기의 시행착오가 없었다면 이후의 자기 환경을 만들 이유도 없었다.
Emacs 28 — native compilation이라는 체감 변화
Emacs 28의 native compilation은 단순한 성능 옵션이 아니었다. Emacs Lisp가 “느리지만 유연한 언어”라는 오래된 감각에 균열을 냈다.
물론 native-comp는 빌드 캐시, eln-cache, 비동기 컴파일 경고 같은 새로운 관리 문제를 가져왔다. 이 노트의 원래 주제였던 Org version mismatch도 결국 이런 “빌드된 Lisp와 소스 Lisp 사이의 층위”를 의식하게 만든 사건이었다. 그래도 큰 방향은 분명했다. Emacs는 여전히 Lisp 기계지만, 더 이상 과거의 속도 감각에 갇힌 기계는 아니었다.
Emacs 29 — tree-sitter와 현대 IDE의 골격
Emacs 29의 상징은 tree-sitter다. 문법 테이블과 정규식 중심의 오래된 편집 모델 위에, 구조적 파싱을 기본 기능으로 받아들이기 시작했다.
이 시기에는 Eglot, use-package, SQLite 같은 기능도 함께 중요해졌다. Emacs가 “사용자가 패키지로 조립해야 겨우 현대적이 되는 편집기”에서, 현대 개발 환경의 기본 골격을 내장하는 방향으로 움직였기 때문이다.
내게 29는 “Emacs도 최신 IDE 경쟁에 합류했다”기보다, Org-mode와 Lisp 기반의 오래된 확장성 위에 현대 코드 이해 능력이 붙기 시작한 버전으로 기억된다.
Emacs 30 — 버전 기능보다 작업면의 완성
Emacs 30에는 Android 포트, native JSON, native compilation 기본 활성화, native process filter 같은 변화가 있다. 특히 Android 포트는 별도의 흐름으로 계속 추적할 만하다.
다만 내 삶에서 Emacs 30의 핵심은 릴리스 노트가 아니었다. 이 시기에는 Doom Emacs 기반 설정을 정돈하고, 터미널에서도 GUI를 포기하지 않는 환경을 만들었다.
- 한글 입력을 OS 입력기가 아니라 Emacs 내장 입력기로 밀어넣기
- OSC 52 클립보드와 SSH/tmux 경로 정리
- WezTerm/Ghostty/kitty 계열 터미널에서 truecolor와 키 입력 안정화
- agent-server와 pi daemon으로 인간과 에이전트가 같은 Org corpus를 만지는 구조 만들기
그래서 나에게 Emacs 30은 “새 기능의 버전”이라기보다, 터미널 Emacs가 에이전트 하네스의 프론트엔드로 완성된 시기 다.
Emacs 31 — 터미널 안의 child frame, 그리고 Org 9.8
Emacs 31에서 가장 먼저 눈에 들어오는 변화는 TTY child frame이다. 터미널 프레임에서도 child frame을 지원하면, posframe·Corfu 같은 팝업 UI가 터미널에서도 더 자연스럽게 작동할 수 있다.
내 환경에서 이것은 단순한 UI 개선이 아니다. 나는 이미 터미널 Emacs를 SSH 원격, tmux, 한글 입력, 클립보드, 에이전트 협업의 공통 프론트엔드로 쓰고 있다. 31의 방향은 그 선택을 더 정당화한다.
또한 31은 tree-sitter, completion, window/tab, Tramp, package.el, Org 9.8 쪽 변화가 많다. 특히 Org 9.8은 memex-kb, Denote export, digital garden 파이프라인과 직접 맞닿으므로 회귀 확인이 필요하다.
오늘 `doomemacs-config`에서는 31 pre-release를 쓰기 위해 `emacs-overlay#emacs-unstable`이나 `emacs-git` master가 아니라 Savannah `emacs-31` release branch를 직접 pin했다. `emacs-unstable`은 아직 30.2였고, `emacs-git`은 이미 32.0.50 master였기 때문이다.
버전보다 중요한 축
터미널 Emacs — 보편 프론트엔드
나에게 Emacs의 의미는 “GUI 앱”이 아니다. 이제는 터미널 하나 안에 들어오는 보편 인터페이스다. 로컬이든 SSH 원격이든, WezTerm이든 Ghostty든, tmux 안이든, 같은 Org corpus와 같은 Lisp runtime을 만질 수 있어야 한다.
이 축은 터미널 이맥스 하네스 프론트엔드 완성 한글입력 클립보드 SSH원격 독립인스턴스 에이전트통합 노트와 이어진다.
Org-mode와 memex-kb — 문서가 작업면이 되는 구조
Emacs가 중요한 이유는 Org-mode 때문이다. Org는 단순한 마크업이 아니라, TODO·agenda·citation·export·code block·link가 한 파일 안에서 공존하는 작업 프로토콜이다.
memex-kb는 이 Org 중심 지식 흐름을 플랫폼 밖으로 꺼내는 도구다. Google Docs나 legacy content를 Denote 지식베이스로 가져오고, plain-text·version-controlled·AI-friendly 형식으로 바꾸는 변환기다. Emacs는 여기서 “편집기”라기보다, 문서가 작업면으로 살아나는 런타임이다.
Android Emacs — 작은 기계 위의 같은 거처
Android 포트는 단순히 “휴대폰에서도 Emacs가 돈다”가 아니다. DeX, Termux, native GUI, 모바일 입력, 외부 키보드가 하나의 지식 도구로 묶일 수 있다는 가능성이다.
이 축은 2022년의 스크린샷 기록부터 2025년의 native Android 설치·닷파일 정리까지 이어진다. 30의 Android 포트는 이 흐름을 upstream 차원에서 다시 보게 만든다.
Rust/Zig Emacs — 코어 재구현과 다음 질문
Emacs 31을 쓰면서 동시에 Rust 기반 Emacs 재구현 흐름을 보는 것은 모순이 아니다. GNU Emacs의 release branch는 현재의 작업 거처이고, Neomacs 같은 프로젝트는 “이 거처의 코어가 다시 쓰일 수 있는가”라는 미래 질문이다.
@힣: §i-am-emacs §neomacs 이맥스 코어 리서치는 이 축을 다룬다. Rust로 Emacs를 다시 구현한다는 것은 단순 포팅이 아니라, Lisp runtime, display, GC, keyboard/input, package bootstrap fidelity를 모두 재현해야 하는 어마어마한 작업이다. 관심을 둘 수밖에 없다.
Autholog 후보 메모
나중에 autholog로 끌어올릴 때는 버전별 기능 설명보다 다음 문장을 중심에 두면 좋다.
나는 Emacs를 업그레이드한 것이 아니라, Emacs 안에 더 오래 살 수 있도록 내 작업 방식을 바꿨다. 27에서는 남의 배포판에 기대어 살아남았고, 31에서는 터미널과 에이전트와 Org 지식베이스를 한 작업면으로 묶었다.
Comments