▲

Emacs용 Claude Code IDE 통합

 (github.com/manzaltu)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Claude Code IDE for Emacs는 Emacs 내에서 Claude Code CLI를 네이티브로 통합하여 강력한 AI 코딩 어시스턴트 환경을 제공함
  • Model Context Protocol(MCP) 기반 양방향 브리지를 통해 Claude가 Emacs의 LSP, 프로젝트 관리, Elisp 함수 등 다양한 기능을 활용할 수 있음
  • 자동 프로젝트 탐지, 다중 세션, 진단(에러/경고) 연동, 고급 diff, tab-bar 및 선택/버퍼 트래킹 등 Emacs 환경 최적화 기능 제공
  • Emacs 명령과 확장성을 바탕으로, MCP 서버를 통해 직접적인 명령 노출 및 맞춤형 워크플로우 연동이 가능함
  • Claude와 Emacs 전체 에코시스템 간 깊은 연결을 통해 클라우드 기반 AI 지원 개발 환경을 구축함

개요

Claude Code IDE for Emacs는 Claude Code CLI와의 연동을 통해 Emacs 환경 내에서 Claude AI의 기능을 극대화하는 오픈 소스 프로젝트임. 기존의 단순 터미널 래퍼와 달리, 이 패키지는 양방향 통신이 가능한 MCP(Model Context Protocol) 기반 브리지를 제공, Claude가 Emacs 내부 기능을 실제로 활용할 수 있도록 설계됨. LSP, 프로젝트 관리, Elisp 함수 등 Emacs의 강력한 생태계와 연결하여 Emacs 유저만의 생산적이고 지능적인 AI 개발 지원 환경을 구현함.

주요 특징

  • 자동 프로젝트 감지 및 세션 관리

    • Emacs 내장 project.el 활용, 자동으로 프로젝트 인식 및 세션 분리
    • 각 프로젝트별 독립 Claude Code 인스턴스 및 버퍼 제공

  • 터미널 통합 및 컬러 지원

    • vterm 또는 eat를 통한 컬러 플렌터미널 지원
    • Emacs 안에서 Claude와 대화 가능

  • MCP 프로토콜 통한 IDE 통합

    • 다양한 Emacs 명령(코드 탐색, 심볼 조회, AST 분석 등)을 MCP 서버로 노출
    • Claude가 Emacs 명령 및 사용자 정의 함수 실행 가능

  • 확장성 높은 MCP Tools 서버

    • 개인화된 MCP tool 추가/정의 가능 (예: 전체 프로젝트 내 검색, 전역 refactoring 등)

  • 코드 진단 및 diff

    • Flycheck, Flymake 연동 통한 코드 에러/경고 진단 정보 제공
    • ediff를 활용한 고급 diff 뷰 및 진단 정보 접근 지원

  • 상태/명령 전환 관리

    • tab-bar, 선택/버퍼 추적 등으로 Claude가 사용자의 현재 컨텍스트 이해 가능

Emacs Tool Integration

Claude Code IDE는 MCP tool 시스템으로 Emacs의 다양한 명령과 정보를 Claude에 직접 노출함

  • LSP 통합(xref)

    • Go-to-definition, 프로젝트 전역 심볼/참조 탐색 등 LSP 기반 지능형 탐색 지원

  • Tree-sitter 지원

    • 구문 트리 분석 및 AST(추상 구문 트리) 기반 코드 구조 이해 제공

  • Imenu, Project 통합

    • 심볼 목록, 프로젝트 파일 및 구조 정보 자동 제공

  • 사용자 지정 Elisp 함수

    • MCP tool로 직접 노출하여, 고유 워크플로우/도메인 특화 기능 활용 가능

이러한 통합으로 Claude는 Emacs 생태계의 문맥 정보를 활용하여, 코드 수준의 정밀한 AI 지원 제공 가능

사용법

기본 명령

  • M-x claude-code-ide-menu: 모든 명령을 시각적으로 제공하는 트랜지언트 메뉴 호출
  • 프로젝트 내 Claude Code 활성화, 프롬프트 전송, 이전 대화 이어받기, 다양한 상태/세션 관리 제공
  • 여러 프로젝트를 동시에 관리 가능하며, 각 프로젝트별 고유 Claude 세션 운용

윈도우 및 세션 관리

  • 새 세션이 이미 실행 중이면 창 토글/표시 기능만 수행
  • 표준 Emacs 명령(C-x 0)으로 창을 닫더라도 Claude 자체는 종료되지 않음

설정

  • Claude Code CLI, 터미널 백엔드, 진단 백엔드, 창 위치/크기, 디버그 옵션 등 세부적인 커스터마이징 지원
  • 플래그 추가, 시스템 프롬프트 지정, 버퍼 네이밍 함수 등 고급 옵션 제공
  • MCP 서버 활성화 및 사용 툴/포트 지정 가능

Terminal Backend 설정

  • 기본값은 vterm, 필요시 eat 백엔드로 전환 가능
  • eat는 순수 Elisp 기반 터미널로, vterm 빌드 문제 발생 시 유용
  • 전용 키바인딩 제공 (M-RET: 프롬프트에서 줄바꿈, C-<escape>: 종료/취소 등)

진단/디버깅 옵션

  • Flycheck, Flymake를 자동 감지/연동 또는 강제 지정 가능
  • 클로드 터미널 리플로우(재정렬) 버그(#1422) 회피용 임시 옵션 내장
  • Emacs 및 CLI 레벨에서의 상세 디버깅 로그 지원 (WebSocket, JSON-RPC 메시지 등 확인)

Advanced: 여러 Worktree, 세션 운영

  • git worktree 활용, 동일 프로젝트 내 분기별 여러 독립 세션 실행 가능
  • 각 작업군별 고유 버퍼 및 컨텍스트 유지로, 병렬 개발 워크플로우 지원

Emacs MCP Tools 상세

내장 MCP Tools 예시

  • xref-find-references: 프로젝트 내 특정 심볼 참조 전체 탐색
  • xref-find-apropos: 패턴-기반 심볼/코드 전체 검색
  • treesit-info: tree-sitter 기반 AST 분석 데이터 제공
  • imenu-list-symbols: 파일 내 모든 함수, 변수 목록 출력
  • project-info: 현재 프로젝트 메타/파일 정보 제공

사용자 정의 툴 추가

  • 사용자는 자신의 Emacs 함수도 MCP tool 포맷에 따라 추가 가능
  • 예시로, ripgrep 활용한 코드 검색 툴 또는 특정 도메인 전용 커맨드 정의 및 Claude에서 직접 호출 가능

라이선스 및 관련 프로젝트

  • GNU GPL v3.0 혹은 그 이상으로 제공
  • 관련 프로젝트로 VS Code, Neovim(claudecode.nvim) 통합 플러그인 등 소개

중요성 및 장점

Claude Code IDE for Emacs는 기존 LLM/AI 통합 툴과 달리, Emacs 내 고유 작업 맥락 및 생태계 정보를 적극 활용할 수 있는 강력한 AI IDE 환경을 제공함
비교적 초기 단계임에도 다양한 내장 기능 및 높은 커스터마이징 가능성, 멀티 프로젝트 지원을 갖추고 있어 Emacs 사용자 및 오픈 소스 개발자에게 매우 강력한 선택지임

▲
GN⁺ 1일전  [-]
Hacker News 의견
  • LSP와 tree-sitter처럼 Claude Code나 Aider 같은 AI 코딩 도구들은 Emacs나 Vim 같이 틈새 마켓 편집기들에게 매우 희소식임을 느낌, 예전처럼 고급 IDE 기능을 직접 구현하려 애쓰지 않아도 되고, 이런 도구들과 쉽게 연동해서 자신들만의 편집 관련 차별점에 집중할 수 있음, 실제로 이런 커스터마이즈와 유연한 연동이 이런 에디터들의 경쟁력을 훨씬 높여줌을 느낌
    • LSP처럼 agent형 코딩 도구들을 에디터에 쉽게 통합할 수 있는 표준이 있는지 궁금함
    • 항상 그랬다는 생각임, Emacs와 Vim은 예전부터 고급 IDE 기능이 있었음, LSP랑 tree-sitter 덕분에 이제 에디터와 언어를 아우르는 표준화가 더 쉬워짐
    • emacs와 vim이 틈새 편집기라는 말은 동의하지 않음, 이미 대표적인 편집기임
  • emacs는 AI 에이전트에게 최고의 편집기라는 생각을 늘 가졌음, 에이전트가 쉽게 에디터 상태를 모두 들여다보고 elisp로 동작까지 바꿀 수 있음, vim이나 emacs 수준의 커스터마이즈를 허용하는 편집기는 앞으로도 큰 장점을 가질 것 같음
    • vim이나 emacs는 사실상 항상 커다란 강점이 있었음을 느낌, 사람들마다 장점 판단이 다르지만, 개인적으로 VSCode나 IntelliJ의 폐쇄적 확장성은 큰 단점임, 폐쇄적이라는 것은 제한적인 플러그인 API, 샌드박스 실행환경, 기업의 승인 구조, 내부 로직의 불투명함 등을 의미함, 예전에는 새로운 기능들을 찾아 다른 IDE로 옮겨가려 노력했지만 지금은 Emacs를 배우는 것만으로 내 목적에 더 잘 다가갈 수 있음을 느낌, Emacs를 활용할 때 문제 해결 방식은 IDE를 사용할 때보다 훨씬 만족스러움
    • Emacs의 강점은 lisp 인터프리터 코어에 있음, AI 에이전트가 런타임에서 사용자가 쓰는 것과 동일한 평가 메커니즘으로 전체 편집기 상태를 직접 들여다보고 바꿀 수 있음, 대부분 에디터는 플러그인 API가 딱딱하게 고정되어 있음
  • claude-code.el 플러그인을 만족스럽게 사용 중임, 순수 터미널 래퍼지만 강력한 Transient 메뉴도 제공함, Emacs 내에서만 돌아가도 이미 워크플로우의 효율이 많이 올라감, 예전 iTerm 환경보다 훨씬 맞춤화된 흐름을 손쉽게 만들었음, 앞으로 새로 나온 패키지도 계속 주의 깊게 볼 예정임, eca-emacs도 기대됨, 생산성을 신뢰해야 하는 툴들은 도입 초기에 조심스럽게 접근하는 편임, 대개는 대형 프로젝트가 잔손질을 많이 필요로 하는 '빅뱅' 시기를 겪음
    • 잠깐 써보고 결국 그냥 터미널에서 claude code만 다시 쓰게 됐음, Emacs에서 약간 버벅이는 느낌이 있었고, 따로 터미널 창을 안 쓸 이유가 없음, mcp.el 패키지와 연동이 안 되는 것도 아쉬움, 실제로 claude code를 써봤을 때 내 업무에서는 쓸 만한 코드 퀄리티까지 아직 옴기지 못함, mcp.el도 참고할 만함
  • emacs가 LSP, tree-sitter, 그리고 Claude Code 같은 최신 툴을 통합하는 현상이 반갑지만, 동시에 이제 세팅의 난이도가 진짜 높아진 느낌임, 20년 된 emacs 유저지만 요즘은 환경 세팅이 쉽지 않음, Claude Code가 IDE 연동 이전에는 제일 쉬웠던 것 같음(그냥 돌아가고 자동 buffer 동기화로 신경 쓸 게 거의 없었음), 새 MacOS에서 typescript-ls는 겨우 돌렸지만 gopls는 아직 다운로드가 안 됨, 한두 시간 있으면 고칠 수 있겠지만 어디서 막히는지 찾는 게 번거로움, 요즘 emacs 유저들은 어떻게 하고 있는지 궁금해서 공유함, 요즘은 Zed를 쓰며 재밌게 코딩하고 있음, 20년의 emacs 적응력을 내려놓긴 쉽지 않음, emacs의 작은 설정파일 편집부터 대규모 프로젝트 지원, 그리고 극강의 커스터마이즈성은 여전히 각별함, 네오빔이 이쪽으로 더 나은지 궁금함, elisp 디버깅을 더 잘 배워서 내가 쓰는 명령어가 환경에 어떻게 작동하는지 좀더 이해해야 하는 건지 고민됨, 그간 emacs 키 바인딩(Dvorak까지!)에 익숙해져서 neovim 경험이 또 다를까 걱정도 있음
    • elisp 디버깅은 무조건 추천함, 몇십 년을 emacs 썼으면서도 built-in 프로파일러, edebug, apropos, 매크로 확장, advising system, 간접 버퍼 등도 모르는 사람이 많음, emacs를 자동차에 비유하면 주행 중에 부품을 조립해서 잠수정으로도 바꿀 수 있는 머신인데 당연히 기본적인 문제 해결과 예기치 않은 상황을 받아들이는 자세가 필요함, 문제 지점을 바로 찾고 gptel buffer에서 hook이나 advise 함수에 맞는 elisp를 직접 써서 바로 시험해볼 수 있는데, 그 해방감은 경험해봐야 함, 요즘은 '깔끔한' config 유지는 신경 안 씀, 모듈화만 잘해놓고 필요할 때마다 elisp 추가함, 대부분 타 패키지 업데이트 등 외부 문제로 깨져도 오히려 문제 찾고 대체 방법 마련하는게 몇 분이면 끝나고, 빈도도 적음
    • 환경 이슈 관리를 위해 emacs를 도커 환경에서 돌림, emacs-native-dockerfiles 참고하기 바람
    • 새로운 언어 생태계를 emacs에 통합하려면 패키지와 외부 툴(LSP 서버 등) 선택 자체가 꽤 번거로움, dabbling 수준의 프로젝트도 많아서 매번 고민해야 함, 실제 외부툴 다운/설치엔 Nix(devenv.sh), direnv 등을 써서 emacs가 직접 다운로드 안 하게 경로만 잡아줌, 관련 설정파일도 devenv로 저장해서 팀원들도 같은 환경을 쓸 수 있게 함
    • 8년 차 emacs 유저지만 두 달 전부터 nvim으로 완전히 갈아탔고 한 달간 emacs를 아예 안 켰음, lazy.vim 설치하고 AI 플러그인을 번갈아 쓰고 있음, nvim 쪽 생태계와 커뮤니티가 최근엔 오히려 더 활발함, ThePrimeagen 참고할 만함
    • 네오빔 경험도 많이 발전했음, barebone에서 풀 IDE 기능까지 다양하게 세팅 가능함, 이미 pre-configured된 배포판도 많아서 lazy.vim 같은 것 LazyVim 참고할 것, AI 플러그인도 awesome-neovim #ai 참고
  • org mode와 더 강력한 통합, 혹은 전반적인 노트 테이킹 관련 AI 기능이 더 절실함, github/copilot이 30일 지나면 대화 내용을 지워버려서 AI로 지식베이스 구축 시 지장이 크다는 걸 몸소 느낌, 구글의 notebookllm처럼 연구와 기록을 로컬에서 직접 관리할 수 있는 방식이 강하게 필요함
    • gptel-mode를 써보길 추천함, 대화가 org buffer에 저장되고 세션을 쉽게 저장하고 복원할 수 있음, mcp.el과도 잘 연동됨
    • ob-aider도 참고할 만함, ob-aider 링크
  • mcp 서버에 자유롭게 툴을 추가하는 기능 너무 만족함, Emacs답게 기대한 대로임, 몇 년째 쓰면서 elisp를 요즘 더 자주 직접 짜고 있는데, Claude가 elisp 짜는 지원도 꽤 좋아서 더 자주 쓰게 됨(가끔 괄호 정렬은 스스로 고쳐야 하지만 전체적으로 괜찮음), steve yegge의 efrit도 꼭 써볼 예정임, 에이전트가 임의의 elisp식을 쓰고 실행하는 기능이 Emacs의 한계를 한 단계 더 올려줌, efrit
    • 오랜 Yegge 팬이자 팔로워임, 아직 vibe code 허니문 단계라 생각하지만 emacs 역량은 그 누구보다 뛰어남, 1~2년 전부터 대형 LLM이 elisp에 기묘하게 강하다는 걸 깨달았고 이것이 하이퍼모던 프로젝트의 발단이었음, efrit도 아주 유망하다고 봄(완벽히 세팅하진 못했지만)
  • 동시에 5개 이상의 Emacs/Claude Code 연동 패키지가 등장하고 두세 개는 reddit 등에서 치열하게 경쟁하는 모습이 흥미로움, 하지만 진짜 뛰어난 플러그인은 조용히 존재하고 아무도 언급 안 하는 것 같음, yuya373/claude-code-emacs 패키지는 경쟁작들의 기능을 이미 거의 다 구현함
    • 얼마나 인기가 있는지는 모르겠지만 설치는 제일 쉬운 것 같음, melpa claude-code 참고
    • 그 패키지는 Claude-code-ide의 /ide 통합이 없는 것 같음
  • eca도 꼭 써보길 추천함, Emacs에서 AI 페어 프로그래밍 최고의 툴 만드는 데 집중하고 있음
  • 최근 Emacs 커뮤니티에서 이런 AI 통합 논의 자체를 비난하는 분위기가 있다는 걸 체감했지만, 이런 반응은 솔직히 득보다 해가 더 많다고 생각함, AI가 현 세대 방식과 다르게 발전하더라도 Emacs의 뿌리는 MIT AI Lab에 있다고 봄, 그런 AI working group에서 시작된 툴에 AI 통합을 꺼리는 분위기는 이상함
    • Emacs의 아름다움은 사용자 중심의 통제임, Elisp 레이어에서 원하는 모든 걸 바꿀 수 있기 때문에 이런 패키지들이 계속 등장함, 반면 VS Code는 구조적으로 분열을 유도함, 마이크로소프트가 자기네 독점 툴에는 전용 API를 쓰고, 외부엔 훨씬 제한적인 확장 API만을 내놓음, 그래서 수많은 vscode 포크가 생김, Emacs는 진짜 열정과 실력이 넘치는 Elisp 개발자 한 명이면 모든 걸 바꿀 수 있고 새 AI/LLM 연동 모듈도 얼마든지 등장할 수 있음, Emacs 커뮤니티의 비난은 좀 과장된 면도 많다고 느낌, 실제로 AI/LLM 관련 플러그인도 꾸준히 나와서 좋은 반응을 얻고 있음, 예시로 gptel 추천
    • 이런 분위기의 원인은 리차드 스톨만 때문임, 그는 자유소프트웨어 프로젝트가 준비되지 않은 상황에서 '비자유 소프트웨어' 대안의 통합은 경계해야 한다고 봄, 이런 접근이 GCC 확장, LLVM 디버거, tree-sitter, git/bzr, CI 빌드팜 등 여러 의사결정에서 채택 지연을 초래했고, 그 기간동안 Emacs와 같은 핵심프로젝트의 대체재 채택 속도만 늦어짐, 결국엔 항상 나중에 받아들이게 됨, 때로는 FSF의 입지를 지키려는 태도로 보이기도 했음
    • Emacs 커뮤니티는 매우 다양함, 어디서나 비난은 있지만 신경 안 써도 됨, 3rd party 모듈로 얼마든지 원하는 기능을 추가할 수 있고, 핵심 메인테이너가 막을 방법이 없음
    • MIT AI 랩이 현대 AI 붐과 연결되어 있다는 건 새롭게 알게 됨, 흥미로움
  • 이런 툴이 아주 기대됨, Emacs와 AI를 코딩 흐름에 접목하는 걸 좋아함, 그런데 무엇보다 원하는 건 이걸 $2000 이하 컴퓨터 하드웨어에서 자체 로컬로 실행하는 것임, 현재 또는 가까운 미래에 이게 가능한지, 혹시 로컬 모델로 코딩하는 에이전트를 직접 쓰고 있는 분 있는지 궁금함
    • 메모리 효율적인 추론 및 오픈 소스 코드 특화 모델 관련해서 엄청난 발전이 이루어지고 있음, 요즘은 Qwen3-Coder 모델군이 많이 주목받고 있음(Qwen3-Coder), 로컬 실행엔 Ollama, LM Studio 같은 툴이 있음, 모델 크기/양자화에 따라 다르지만 $2000 예산이면 굉장히 많은 모델을 돌릴 수 있음, M 시리즈 맥도 가성비 좋음, 로컬 LLM 활용 정보는 LocalLlamas 서브레딧에 많음, 대형 AI 연구실 수준과는 차이 있지만, 완전 로컬 세팅을 선호한다면 충분히 흥미롭고 해볼 만한 프로젝트임
    • gptel은 로컬 포함 다양한 모델 지원함
    • MacMini나 frame.work desktop, 혹은 Nvidia DGX Spark도 한 옵션임(최저가 3k)
답변달기