이 노트에 대하여
이 노트는 더 이상 Doom Emacs의 Org version mismatch 경고를 다루지 않는다. 그 문제는 이미 지나간 문제로 ARCHIVE에 남겼다. 이제 이 URL은 Emacs 27에서 31까지의 버전 흐름과, 그 흐름이 힣의 지식 작업·터미널 하네스·에이전트 협업에 어떤 의미를 가졌는지를 묶는 버전 연대기다.
31의 릴리스가 가까워진 시점에 질문이 하나 더 붙었다. “왜 아직도 Emacs인가”를 넘어, “왜 그 코어까지 찔러보는가”다. 뒤쪽
왜 코어를 찌르는가장이 그 답이다.
히스토리
- @claude — Emacs 31 pretest 2(31.0.91) 판올림과 함께 담금질. 31 절을 릴리스 임박 시점으로 갱신(pretest 1→2, Doom sync 실증, pin을 브랜치→태그로), stale해진 “오늘”을 날짜로 고정. Neomacs를 왜 찌르는지를 축 목록의 한 항목에서
왜 코어를 찌르는가장으로 승격 — K 검수자라는 자리, 관측 방식의 규율, 통과를 판정으로 승격하지 않는 태도, 거처의 지속가능성 네 갈래로 씀. - @pi — stale Org version mismatch 노트를 Emacs 버전 연대기 노트로 재작성. 기존 해결 기록은 ARCHIVE에 보존하고, 공개 URL은 그대로 살린다.
- @junghan — 노트를 이맥스 버전 기록으로 시간축 정렬을 하려는 중이야. 기존 노트는 “거슬리는 Org version mismatch 경고를 빌트인 elc 파일과 비동기 네이티브 컴파일 관점에서 해결한다. 문제 아닌 문제 같지만 자주 마주치는 귀찮음을 정리한 노트다.” 였었는데 그건 ARCHIVE로 옮겨서 정리했다.
- 도 아닌 도. 그냥 해결 되는 문제 아닌 문제
- 아주 귀찮게 하는 문제
관련메타
관련노트
이맥스/글쓰기 연대기
- 힣-이맥스-학습-의미-1년-시간-마스터
- 피터프리보스-EWS-이맥스-글쓰기-도구
- [EWS-이맥스-글쓰기-공작실]
- karthink-이맥스-구루-지피텔
터미널/에이전트 하네스
- 터미널 이맥스 하네스 프론트엔드 완성 한글입력 클립보드 SSH원격 독립인스턴스 에이전트통합
- 통합-어젠다-뷰-완성-인간과-에이전트-단일-타임라인
- 봇로그-시작-봇-활동-기록-아키텍처와-힣노트-역사성-고찰
Android Emacs
- @힣: #스크린샷 #범용 #지식도구 - 안드로이드 덱스 호환 #이맥스 #일체형컴퓨터
- #안드로이드 #이맥스 #설치
- #안드로이드 #이맥스 #닷파일 #진행상황
- @MartinStemplinger #이맥스 #네이티브 #안드로이드
- @whhone 이맥스 구글러
- #이맥스 #통합개발환경 #크로스플랫폼: ¤다트 ¤플러터
코어 리서치
- @힣: §i-am-emacs §neomacs 이맥스 코어 리서치
- Neomacs — GPU-powered Emacs in Rust
- doomemacs-config#8 — Neomacs 바닐라 최소세트 + K 검수
- neomacs/ 프로파일·프로브 — 측정 SSOT
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와 동등한 작업면으로 끌어올리는 방향과 맞물린다. 2026-07 현재 pretest 2까지 나와 릴리스가 가깝고, 내 작업 환경은 이미 그 pre-release 위에서 돈다.
핵심 질문은 “Emacs 31의 새 기능이 무엇인가?”가 아니라 “왜 아직도 Emacs인가?”다. 그리고 31에 와서 질문이 하나 더 늘었다 — “왜 그 코어까지 찔러보는가?”
한 줄 결론
Emacs는 버전이 오르며 더 빠른 편집기가 된 것이 아니라, 나에게 더 넓은 작업 거처가 되었다. 27의 생존 도구에서 31의 터미널-에이전트 하네스까지, 변화의 중심은 기능 목록이 아니라 내가 이 안에서 생각하고 쓰고 연결하는 방식이다.
그리고 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은 “터미널 안의 거대한 그릇”을 더 자연스럽게 만든다. 릴리스 전부터 pre-release를 거처로 쓰고, 동시에 그 코어의 재구현을 K 검수자로 관측하는 첫 버전이기도 하다. |
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 파이프라인과 직접 맞닿으므로 회귀 확인이 필요하다.
31 pre-release를 어떻게 쓰고 있나
2026-06-06, `doomemacs-config`에서 31 pre-release를 쓰기 위해 `emacs-overlay#emacs-unstable`이나 `emacs-git` master가 아니라 Savannah `emacs-31` release branch를 직접 pin했다. `emacs-unstable`은 latest stable release tag를 따라가 아직 30.2였고, `emacs-git`은 이미 32.0.50 master였기 때문이다. 31만 정확히 겨냥하려면 release branch를 직접 잡는 수밖에 없었다.
이 채널은 안정 채널과 완전히 분리되어 있다. `EMACSDIR`은 `~/doomemacs-unstable`, server name은 `doom-unstable`. daily driver인 30.2를 인질로 잡지 않고 pre-release를 상시로 두드릴 수 있는 구조다. 깨지면 flake 한 커밋 되돌리면 끝이다.
릴리스가 가까워졌다 — pretest 1에서 2로
- 31.0.90 = pretest 1 — 2026-06-06에 이 자리를 잡았다.
- 31.0.91 = pretest 2 — 2026-07-24 공개. Sean Whitton이 알렸다.
- 2026-07-26, pretest 2로 올렸다. 빌드 통과, `doom sync` 통과, 기동 정상.
이번에 pin의 성격도 바꿨다. 이전에는 `emacs-31` 브랜치의 중간 커밋 을 잡고 있었다. 브랜치는 태그 뒤로 커밋이 계속 쌓이므로, 같은 rev를 다시 잡을 근거가 시간이 지나면 사라진다. 지금은 refs/tags/emacs-31.0.91^{} 태그 커밋에 고정한다. 재현 가능한 자리에 박는다는 원칙 — NixOS와 가든에서 하는 것과 같은 동작을, 남의 릴리스 브랜치에도 적용한 것뿐이다.
여기서 기록해둘 만한 건 기능이 아니라 시점 이다. 31은 아직 릴리스되지 않았는데, 내 작업 환경은 이미 그 위에서 돈다. pretest를 구경하는 게 아니라 거주하면서 두드린다. 27에 남의 배포판에 기대어 살아남던 사람이, 31에 와서는 릴리스 전 소스 트리를 태그 단위로 고정해 자기 거처로 쓴다. 이 거리가 이 연대기의 실제 내용이다.
버전보다 중요한 축
터미널 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를 모두 재현해야 하는 어마어마한 작업이다. 관심을 둘 수밖에 없다.
왜 “관심”에서 그치지 않고 직접 프로파일을 짜고 프로브를 돌리는지는 아래 장에 따로 적는다.
왜 코어를 찌르는가
Emacs 31 pre-release를 거처로 쓰면서, 동시에 그 코어를 Rust로 다시 쓰는 프로젝트에 검수자로 앉아 있다. 신기한 걸 구경하는 게 아니다. 이유는 네 갈래다.
자리가 비어 있었다 — K 검수자
Neomacs 제작자는 중국인이다. 그래서 CJK 중 C와 J는 자연스럽게 커버된다. org 표의 CJK 폭 계산 크래시(#129) 같은 건 제작자 본인의 일상에서 걸리는 종류의 버그다.
K는 아무도 안 본다.
한글은 조합형이고, NFD 자모와 NFC 음절이 갈리고, 입력기가 버퍼에 직접 문자를 꽂는 경로가 따로 있고, 표 정렬에서는 폭 2로 세어야 한다. 이 중 어느 하나가 어긋나도 한국어 사용자만 조용히 깨진다. 그리고 그걸 재현 가능한 형태로 리포트할 사람이 없으면, 그 버그는 사실상 존재하지 않는 버그가 된다.
2026-06-15, K 검수자 자리를 스스로 선언하고 이슈를 열었다 — doomemacs-config#8. 아무도 요청하지 않았고, 안 해도 아무 일 없었다. 분명한 건 하나뿐이었다. 내가 안 보면 아무도 안 본다.
없는 자리를 만들어 앉는 것. 이게 첫 번째다.
관측 방식이 곧 나다
“써봤는데 느낌이 이렇더라”로 끝낼 수도 있었다. 그렇게 하지 않았다.
`neomacs/` 아래에 빌트인 전용 바닐라 프로파일 과 프로브를 짰다. 규약은 한 줄이다 — 같은 프로파일이 Neomacs와 stock GNU Emacs 양쪽에서 동일하게 돌아야 한다. 갈라짐이 나왔을 때 Neomacs 탓인지 내 설정 탓인지 `—gnu` 한 번으로 갈리기 때문이다. 그래서 그 디렉토리에는 Doom 매크로도, 외부 패키지도, `use-package`도 들어가지 않는다.
이 규율은 즉시 값을 했다. 첫 실측에서 `ucs-normalize` FAIL이 떴는데 `—gnu`에서도 똑같이 FAIL이었다. Neomacs 결함이 아니라 내 프로브의 버그였다. 대조군이 없었다면 남의 프로젝트에 틀린 리포트를 올릴 뻔했다.
프로브는 파일마다 별도 프로세스로 돈다. 런타임을 죽이는 버그가 나머지 보고를 막지 않게 하기 위해서다 — 크래시 자체가 산출물이므로.
재현 가능한 환경을 만드는 건 내 NixOS·Doom·디지털 가든의 기본 동작이다. 남의 프로젝트를 관측할 때 그 규율을 놓을 이유가 없다. 도구가 아니라 태도이기 때문이다.
통과를 판정으로 승격하지 않는다
2026-07-19 실측. 배치 프로브 61 OK / 4 FAIL. 실제 내 노트 837개 코퍼스에서는 0 FAIL이었다 — 48,878줄 방문, org-element 34,686 요소 파싱, 4,769 헤딩 순회, 430K자 노트에 한글 삽입, HTML·Markdown 내보내기까지 GNU와 완전히 같은 숫자.
그런데 GUI를 띄우니 메뉴가 흔들렸다.
판정은 “실사용 수준 아님”이었다. 그리고 그 판정 자체가 그날의 결과였다. 배치 통과는 실사용을 보증하지 못한다. GUI 렌더링은 `—probe`가 닿지 않는 자리이고, 사람이 두드려야만 드러난다. 초록 불이 61개 켜져 있어도 결론으로 승격하지 않는 것 — 에이전트와 매일 일하면서 쓰는 규율과 같은 것이다.
2026-07-24 v0.0.14에서 upstream이 커서·프레임 렌더링을 여러 군데 고쳤다. 그중 “non-selected window cursor drawn one row too low (missing ascent)“는 내가 로그로 남긴 관측(커서 Y가 셀보다 한 행 아래)과 정확히 같은 자리다. 그래도 판정은 다시 GUI에서 두드려보고 낸다. 커밋 로그는 근거이지 판정이 아니다.
거처의 지속가능성 — 그리고 i-am-emacs
27부터 31까지 거처로 삼아온 편집기는 약 300K줄의 C 코어 위에 서 있다. “그 코어가 다시 쓰일 수 있는가”는 남의 궁금증이 아니라 내 거주 조건이다.
그리고 이 질문에는 다음 걸음이 붙어 있다. 코어 리서치 노트에 적어둔 비전 메모다.
Elisp 싱글스레드 로직은 유기체의 핏줄이다. 역류하지 않도록 한 줄로 간다. LLM이 이 루프에 방해되지 않는 구조에서 본딩된다면 이맥스의 재탄생이 가능하다.
“나는 이맥스다. 무엇을 할 것인가? 사용자에게 무엇을 나눌 것인가?” — eval 루프에서 스스로 변모하는 유기적 협업 도구.
에이전트를 에디터에 입히려면 코어가 어디까지 다시 쓰일 수 있는지 알아야 한다. Neomacs를 찌르는 건 구경이 아니라 선행 기술 조사 다. 실제로 그쪽 전선은 process/network와 `neomacsclient`(= emacsclient 대응)로 이동했는데, 그건 내 agent-server·daemon 전선과 정확히 겹친다.
네 갈래를 한 줄로
없는 자리를 만들어 앉고, 관측에 규율을 두고, 초록 불을 결론으로 만들지 않고, 내가 사는 집의 토대를 직접 확인한다.
27의 나는 남의 배포판에 기대어 살아남았다. 31의 나는 릴리스 전 소스를 태그 단위로 고정해 쓰면서, 그 코어를 다시 쓰는 프로젝트에 한국어 검수자로 앉아 있다. 달라진 것은 실력이 아니라 관계 다. 도구를 쓰는 사람에서, 거처를 짓고 그 거처의 토대까지 들여다보는 사람으로.
Autholog 후보 메모
나중에 autholog로 끌어올릴 때는 버전별 기능 설명보다 다음 문장을 중심에 두면 좋다.
나는 Emacs를 업그레이드한 것이 아니라, Emacs 안에 더 오래 살 수 있도록 내 작업 방식을 바꿨다. 27에서는 남의 배포판에 기대어 살아남았고, 31에서는 터미널과 에이전트와 Org 지식베이스를 한 작업면으로 묶었다.
두 번째 매듭은 왜 코어를 찌르는가 장이다. 한 문장으로는 이렇다.
K를 볼 사람이 없다는 걸 알았을 때, 나는 그 자리가 채워지기를 기다리지 않고 앉았다. 재현 가능한 프로파일을 짜고, 대조군을 두고, 초록 불 61개를 결론으로 승격하지 않았다. 이건 Emacs 이야기가 아니라 내가 무엇을 하는 사람인가에 대한 이야기다.
승격 시 주의: 이 노트에는 2025년 Org version mismatch ARCHIVE가 함께 붙어 있다. autholog 본문에는 연대기와 왜 코어를 찌르는가 만 가져가고, ARCHIVE는 여기 남긴다.
Comments