Emacs 31: 현재 제가 매일 사용 중인 변화들

Meta Description: Emacs 31 출시가 임박했습니다. 업그레이드할 가치가 있는, 제가 매일 사용 중인 변화들을 소개합니다. 실제 테스트 결과, 솔직한 견해, 그리고 설정 팁이 포함되어 있습니다.

TL;DR: Emacs 31은 tree-sitter 통합, 네이티브 컴파일 (native compilation), 내장 패키지 매니저, 그리고 접근성 도구에 의미 있는 개선을 가져왔습니다. 저는 몇 달 동안 프리릴리스 (pre-release) 빌드를 실행해 왔으며, 몇몇 변화들은 제 일상적인 워크플로우를 진정으로 개선했습니다. 이 글은 무엇이 주의를 기울일 가치가 있는지, 그리고 무엇이 여전히 다듬어질 필요가 있는지 정확히 분석합니다.

Emacs 커뮤니티에 충분히 오래 머물렀다면, 릴리스 사이클이 그들만의 신중한 속도로 움직인다는 것을 알고 있을 것입니다. Emacs 30은 2024년 초에 출시되었으며, 2026년 중반 현재, 버전 31은 매우 가까워져서 우리 중 많은 이들이 몇 달 동안 개발 빌드를 기본 에디터로 사용해 왔습니다. 질문은 업그레이드할 것인가 _아닌가_가 아니라, 실제로 사용하게 되었을 때 _어떤 변화가 정말 중요한가_입니다.

저는 2026년 초부터 Emacs 31 프리릴리스 빌드를 매일 사용해 왔습니다. 무엇이 변했는지, 무엇이 잘 작동하는지, 그리고 전환하기 전에 무엇을 알아야 하는지에 대한 저의 솔직한 평가를 공유합니다.

[INTERNAL_LINK: Emacs 30 리뷰 및 업그레이드 가이드]

핵심 요약 (Key Takeaways)

• Tree-sitter 지원이 이제 진정으로 성숙해졌습니다 — Emacs 29의 초기 출시 당시 있었던 거친 부분들이 31에서는 대부분 매끄럽게 다듬어졌습니다.
• 네이티브 컴파일 (native-comp)의 기본 설정이 개선되었습니다 — 첫 설치 시 마찰이 줄어들고, 콜드 부트 (cold boot) 시 시작 속도가 빨라졌습니다.
• 내장 use-package 통합이 확장되었습니다 — 의존성 관리 (dependency management)가 더 응집력 있게 느껴집니다.
• 새로운 접근성 및 디스플레이 기능이 스크린 리더 사용자 및 HiDPI 설정을 위해 도입되었습니다.
• Org Mode가 의미 있는 업데이트와 함께 출시됩니다 — 다만 파워 유저들은 여전히 Org 리포지토리 (repo)를 직접 추적하기를 원할 것입니다.
• 일부 서드파티 패키지는 여전히 업데이트가 필요합니다 — 프로덕션 설정을 업그레이드하기 전에 호환성을 확인하세요.

Emacs 31에서 실제로 새로워진 점

매일 사용하는 경험에 대해 본격적으로 들어가기 전에, 구체적인 사항들을 바탕으로 논의를 고정해 보겠습니다. Emacs 31은 혁명적인 릴리스는 아닙니다. 대신 정교화(refinement) 릴리스이며, 이는 현재 이 프로젝트에 정확히 필요한 것입니다.

Tree-Sitter: 유망함에서 실용성으로

2023년 Emacs 29가 tree-sitter 지원을 출시했을 때, 커뮤니티의 반응은 조심스러운 낙관론이었습니다. 성능 향상은 실질적이었지만, 문법(grammar) 가용성은 불규칙했고, font-lock 통합은 일관성이 부족하게 느껴졌습니다. Emacs 30은 이를 점진적으로 개선했습니다.

Emacs 31은 tree-sitter가 비로소 완성된 느낌을 주기 시작하는 지점입니다.

개선된 사항:

• 문법 자동 설치 훅 (Grammar auto-installation hooks) — 이제 treesit-auto와 같은 서드파티 패키지 없이도, 인식된 모드에 대해 tree-sitter 문법을 자동으로 가져오고 컴파일하도록 Emacs 31을 설정할 수 있습니다.
• 더 일관된 font-lock 동등성 (font-lock parity) — tree-sitter 모드와 기존 레거시 모드 간의 시각적 격차가 눈에 띄게 줄어들었습니다.
• 들여쓰기 엔진 개선 — 특히 python-ts-mode는 Emacs 30에서보다 중첩된 구조를 훨씬 더 안정적으로 처리합니다.
• 구조적 탐색 키 바인딩 (Structural navigation keybindings) — C-M-f 및 관련 키들이 이제 ts-mode에서 더 직관적으로 작동합니다.

저는 매일 많은 양의 Python과 TypeScript를 작성합니다. Emacs 31에서 두 언어 모두 -ts-mode 변형으로 전환한 것은 실질적인 단점 없이 순수하게 긍정적인 효과를 가져왔습니다. 이는 6개월 전에는 결코 쓸 수 없었을 문장입니다.

솔직한 주의사항: 만약 Elixir, Zig, 또는 Nix와 같이 덜 흔한 언어를 주로 사용한다면, 문법 지원은 여전히 커뮤니티에 의해 유지 관리되며 품질이 다양할 수 있습니다. 본격적으로 사용하기 전에 항상 사용 중인 특정 언어를 테스트하십시오.

[INTERNAL_LINK: Emacs를 위한 Tree-sitter 설정 가이드]

네이티브 컴파일 (Native Compilation): 더 나아진 기본 설정

네이티브 컴파일 (native-comp)은 Emacs 28에서 도입되었으며 이후 점진적으로 개선되어 왔습니다. Emacs 31에서 가장 큰 변화는 기술 그 자체라기보다, 그와 관련된 기본 설정(defaults)과 사용자 경험(user experience)입니다.

변경된 사항:

• native-comp-async-report-warnings-errors의 기본값이 'silent로 변경되었습니다 — 패키지가 컴파일되는 동안 첫 실행 시 경고 메시지가 쏟아지는 현상이 더 이상 발생하지 않습니다. 이는 초보 사용자에게는 큰 혼란을, 숙련된 사용자에게는 번거로움을 주던 주요 원인이었습니다.
• 백그라운드에서 더 공격적으로 컴파일이 수행됩니다 — Emacs 31은 컴파일 작업을 스케줄링하는 시점을 더 똑똑하게 결정하며, 그 결과 설치 후 초기 몇 세션 내에 더 빠른 "웜 스타트업 (warm startup)"을 제공합니다.
• 컴파일 실패에 대한 더 나은 처리 — 패키지가 왜 느린지 알 수 없게 만들던 무음 실패(silent failures) 대신, Emacs 31은 이러한 상황을 더 유용하게 로그(log)로 기록합니다.

실제로 제 주력 기기(2023 MacBook Pro, M2 Pro)에서 콜드 부트(cold-boot) 스타트업 시간(emacs 명령 실행부터 사용 가능한 에디터 상태까지 측정)이 약 1.8초에서 약 1.1초로 단축되었습니다. 삶을 바꿀 정도의 변화는 아니지만, 체감할 수 있는 수준입니다.

팁: 본인의 스타트업 성능을 벤치마킹하려면 *scratch* 버퍼에서 (emacs-init-time)을 사용하세요. 네이티브 컴파일(native-comp) 비동기 작업이 단일 측정값을 왜곡할 수 있으므로, 3~4번의 새로운 시작을 통해 측정하고 평균값을 내는 것이 좋습니다.

use-package 및 패키지 관리 개선 사항

use-package는 버전 29에서 Emacs 코어의 일부가 되었습니다. Emacs 31은 추가적인 패키지 관리 레이어의 필요성을 줄이는 방식으로 이러한 통합을 확장합니다.

주요 추가 사항:

• :vc 키워드 개선 — 버전 관리 소스(GitHub, Sourcehut 등)에서 패키지를 직접 가져오는 기능이 더 안정화되었으며, 더 많은 포지(forges)를 지원합니다.
• 더 나은 package-vc 통합 — Emacs 29에서 데뷔한 내장 VC 기반 패키지 설치 기능이 더욱 견고해졌습니다. 제 테스트 과정에서는 설치 실패가 단 한 건도 없었습니다.
• 의존성 고정 (Dependency pinning) — 이제 최소 버전 제약 조건을 더 명확하게 지정할 수 있으며, 이는 여러 기기에 걸쳐 공유 설정을 유지 관리할 때 매우 중요합니다.

재현 가능한 패키지 관리 (reproducible package management)를 위해 straight.el에 의존해 온 사용자들에게, Emacs 31의 내장 기능 개선은 그 격차를 의미 있게 좁혀줍니다. 파워 유저들에게 내장 도구가 straight.el을 완전히 대체할 수 있다고 말하기에는 아직 이르지만, 새로운 설정을 구성하는 대부분의 사람들에게 이제 내장 방식은 진정으로 실행 가능한 선택지가 되었습니다.

[INTERNAL_LINK: Emacs 패키지 관리 비교: straight.el vs 내장 기능]

접근성 및 디스플레이 개선 사항

이 분야는 매니아층 언론에서 충분히 다뤄지지 않지만, 매우 중요한 부분입니다.

HiDPI 및 혼합 DPI (mixed-DPI) 개선:

• Emacs 31은 GTK4를 사용하는 Linux 환경에서 혼합 DPI 설정(예: HiDPI 노트북 화면과 표준 외부 모니터의 조합)을 훨씬 더 잘 처리합니다.
• Wayland에서의 폰트 렌더링 (font rendering)이 개선되었습니다. 특히 합자 (ligature) 렌더링이 더욱 일관성 있게 작동합니다.

스크린 리더 (screen reader) 지원:

• Linux의 AT-SPI2와의 통합이 개선되어, Orca 및 유사한 도구와 함께 Emacs를 더 원활하게 사용할 수 있습니다.
• Emacs가 버퍼 내용 (buffer content)을 노출하는 방식에 대한 일부 저수준 (lower-level) 변경 덕분에 emacspeak 생태계가 혜택을 입습니다.

접근성이 귀하나 귀하의 팀에게 중요한 고려 사항이라면, Emacs 31은 의미 있는 진전입니다.

Org Mode: 코어에 포함된 기능

Emacs는 코어에 Org Mode 버전을 포함하여 배포하며, 이는 항상 Org 프로젝트 자체의 릴리스 주기보다 약간 뒤처져 있습니다. Emacs 31에 번들로 포함된 버전에는 다음이 포함됩니다:

• 대규모 문서에 대한 LaTeX 내보내기 (export) 성능 개선
• 연도가 바뀌는 시점에서 아젠다 뷰 (agenda views) 내 SCHEDULED 및 DEADLINE 타임스탬프 처리 개선
• 깊게 중첩된 헤딩 (headings)에 대한 org-indent-mode의 더 일관된 동작

솔직한 조언: 만약 Org Mode가 귀하의 워크플로의 중심이라면—많은 Emacs 사용자들에게 그러하듯—여전히 ELPA나 Org 리포지토리에서 직접 Org를 설치하는 것이 좋습니다. 번들된 버전은 가벼운 사용에는 괜찮지만, 업스트림 (upstream) 프로젝트의 발전 속도가 더 빠릅니다.

저는 Doom Emacs를 설정 프레임워크 (configuration framework)로 사용하며, 이는 Org 버전을 자동으로 관리해 줍니다. 만약 커스텀 설정을 직접 구축하고 있다면, use-package 설정에 다음을 추가하세요:

(use-package org
  :ensure t
  :pin gnu)

[INTERNAL_LINK: 2026년을 위한 Org Mode 생산성 설정]

제가 실제로 매일 사용하는 것: 저의 Emacs 31 설정

이제 실질적인 부분입니다. 몇 달간 매일 사용해 본 결과, 단순히 개별적으로 테스트해 본 것이 아니라 저의 실제 워크플로 (workflow)에 통합한 Emacs 31 기능들은 다음과 같습니다.

스택 (The Stack)

구성 요소	도구	비고
설정 프레임워크 (Config framework)	Doom Emacs	여전히 생산적인 설정을 위한 가장 빠른 경로
...

Eglot: 이제 내 기본값이 된 내장 LSP 클라이언트

이것이 엄밀히 말해 Emacs 31에서 새로 나온 것은 아니지만, 이번 릴리스에서의 Eglot 개선 사항은 강조할 가치가 있습니다. Eglot는 Emacs 29부터 코어 (core)에 포함되어 있었지만, 항상 lsp-mode를 따라잡으려 애쓰는 느낌이었습니다.

Emacs 31에서 Eglot는 멀티 서버 설정을 더 매끄럽게 처리하며, (저의 주요 고충이었던) 대규모 TypeScript 프로젝트에서의 성능이 눈에 띄게 향상되었습니다. 저는 몇 달 동안 typescript-language-server 및 pyright를 대상으로 문제없이 실행해 왔습니다.

만약 Eglot의 기능이 부족하다고 느껴서 lsp-mode로 전환했었다면, Emacs 31에서 다시 평가해 볼 가치가 있습니다.

여전히 개선이 필요한 부분

정직한 평가를 위해서는 미흡한 점도 인정해야 합니다. 제가 여전히 우회하며 사용 중인 부분들은 다음과 같습니다:

서드파티 패키지 호환성 (Third-party package compatibility): font-lock 또는 들여쓰기 (indentation) 시스템에 깊게 관여하는 일부 패키지들이 Emacs 31의 tree-sitter 변경 사항에 맞춰 업데이트되지 않았습니다. 업그레이드하기 전에 설정을 점검하고, 중요한 패키지들의 이슈 트래커 (issue trackers)를 확인하세요.

Linux에서의 GTK4는 여전히 까다롭습니다: GTK4 빌드를 사용할 수 있고 일반적으로 작동하지만, 특정 테마에서 렌더링 글리치 (rendering glitches)를 겪었습니다. Linux에서의 일상적인 사용에는 GTK3 빌드가 여전히 더 안정적입니다.

문서화 지연 (Documentation lag): Emacs 매뉴얼과 많은 커뮤니티 리소스들은 여전히 Emacs 29/30 패턴을 참조하고 있습니다. 무언가가 예상대로 작동하지 않을 때, 여러분은 종종 NEWS 파일이나 CHANGELOG를 직접 파헤쳐 봐야 할 것입니다.

Emacs 31로 업그레이드해야 할까요?

저의 솔직한 추천 매트릭스는 다음과 같습니다:

상황	추천
Emacs가 처음이며, 새로 설정하는 경우	안정 버전을 기다리세요 — 마찰이 적습니다
...

설정을 망가뜨리지 않고 Emacs 31을 테스트하는 방법

현재 설정을 위험에 빠뜨리지 않고 Emacs 31을 테스트하고 싶다면:

1. 별도의 --init-directory 사용 — Emacs 29+ 버전은 emacs --init-directory ~/.emacs-test/를 지원하여 완전히 분리된 설정으로 실행할 수 있습니다.
2. 패키지 관리자의 테스트 채널을 통해 설치 — macOS에서는 brew install --HEAD emacs-plus를 통해 최신 빌드를 얻을 수 있으며, Linux에서는 대부분의 배포판에 emacs-snapshot 또는 emacs-git 패키지가 있습니다.
3. 롤백 계획 유지 — 현재 사용 중인 Emacs 버전을 파악하고 바이너리를 보관해 두세요.

도구 추천: Chemacs2는 여러 설정을 매우 쉽게 실행할 수 있게 해주는 Emacs용 프로필 스위처입니다. 현재 설정과 함께 Emacs 31을 평가하고 있다면, 이것이 가장 깔끔한 접근 방식입니다.

자주 묻는 질문 (FAQ)

Q: Emacs 31은 언제 공식 출시되나요?

2026년 6월 현재, 공식 출시일은 발표되지 않았습니다. 프로젝트의 과거 패턴과 현재 프리테스트 (pretest) 빌드 상태를 바탕으로 볼 때, 2026년 말 출시가 가능해 보이지만, Emacs 프로젝트는 정해진 일정에 따르는 것이 아니라 준비가 되었을 때 출시됩니다. 가장 정확한 신호를 확인하려면 emacs-devel 메일링 리스트를 팔로우하세요.

Q: 기존 Emacs 설정이 Emacs 31에서 작동할까요?

대부분의 설정은 최소한의 변경만으로 작동할 것입니다. 업데이트가 가장 필요할 가능성이 높은 영역은 font-lock (폰트 락), 들여쓰기 (indentation), 또는 tree-sitter (트리-시터)와 깊게 통합된 패키지들입니다. M-x package-check-builtin을 실행하여 해당 시스템을 건드리는 패키지들을 점검하세요. Emacs 31 소스 트리 내의 NEWS 파일이 가장 좋은 참고 자료가 될 것입니다.

Q: Emacs 31이 Emacs 30보다 더 빠른가요?

제 테스트 결과로는, 네—완만하게 그렇습니다. native-comp (네이티브 컴파일) 개선 사항과 tree-sitter (트리-시터) 정교화가 특히 대용량 파일에서 더 나은 응답성 (responsiveness)에 기여합니다. 만약 Emacs 30에서 성능이 문제가 되지 않았다면 극적인 속도 향상을 기대하지는 마세요. 하지만 개선 사항은 실질적이며 측정 가능합니다.

Q: Emacs 31에서 lsp-mode 대신 Eglot로 전환해야 할까요?

만약 lsp-mode에 만족하고 있다면, 전환해야 할 긴급한 이유는 없습니다. 하지만 고민 중이었다면, Emacs 31의 Eglot 개선 사항 덕분에 대부분의 워크플로 (workflow)에서 강력한 기본 선택지가 될 것입니다. 저는 Emacs 30에서 전환했으며 다시 돌아보지 않았습니다. 가장 크게 잃게 되는 것은 lsp-mode 패키지들이 제공하는 몇몇 UI의 부가 기능 (bells and whistles)들이지만, 순수한 편집 성능 면에서 Eglot는 경쟁력이 있습니다.

Q: Emacs 31은 Windows에서 잘 작동하나요?