Efrit: 왜 Emacs에서 멀티에이전트인가?
Steve Yegge가 Emacs로 멀티에이전트 시스템을 구축하려는 이유와 그의 전체 비전을 분석한 문서.
관련노트
- @샘스트라우스 #클로저 #이맥스 #유튜버 SammyEngineering
- Steve Yegge #분석 #바이브코딩 #인터뷰 정리
- Beads 용어집 완전판
- Beads 분석 및 Macro Memory System 설계
- @힣: 에이전트 생존 그리고 마이크로뷰 - 매크로뷰
- Beads Agent Mail 멀티에이전트 병렬작업 도입
- @스티브예기 steveyegge §beads §efrit §ampcode #바이브코딩
핵심 질문: 왜 Emacs인가?
Steve Yegge의 딜레마
Steve Yegge는 30년간 Emacs를 사용해온 베테랑이다. Vibe Coding 시대가 오면서 그는 고민했을 것이다:
“Emacs가 이제 필요없는가? CLI 에이전트(Claude Code, Codex)가 다 하는데?”
그의 답: Emacs는 “Self-Modifying” 환경
왜 Emacs가 특별한가?
1. VS Code: API 제한 → AI가 에디터 자체를 수정 불가
2. Vim: vimscript 한계 → 런타임 확장 어려움
3. Emacs: Elisp = 런타임에 자기 자신을 수정 가능
→ AI가 자신의 도구를 스스로 개선할 수 있는 유일한 환경Yegge의 블로그에서:
“Of course, I always need to switch over to Emacs to get real work done.”
Efrit의 핵심 원칙: Zero Client-Side Intelligence
❌ Efrit이 절대 하지 않는 것:
- 패턴 인식 (에러 메시지 파싱)
- 작업별 로직 (문법 수정 등)
- 의사결정 휴리스틱
- 코드 생성
✅ Efrit이 하는 것:
- 컨텍스트 수집 (버퍼 내용, 파일 목록)
- 도구 실행 (eval_sexp, shell_exec)
- 결과 전달
- 상태 유지 (세션 추적)
핵심: Efrit은 "순수 실행기", 모든 지능은 Claude에게이것이 “Self-Hosting” 철학:
- Emacs가 스스로를 정의하듯
- AI가 스스로의 도구를 정의
Steve Yegge의 전체 생태계
세 개의 프로젝트
┌─────────────────────────────────────────────────────────────┐
│ Agent Swarm Ecosystem │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌───────────────────┐ │
│ │ Efrit │ │ Beads │ │ MCP Agent Mail │ │
│ │ (Emacs AI) │ │ (이슈 추적) │ │ (에이전트 조정) │ │
│ │ │ │ │ │ │ │
│ │ "손" │ │ "기억" │ │ "소통" │ │
│ │ elisp 실행 │ │ 작업 추적 │ │ 메시지 교환 │ │
│ │ 버퍼 조작 │ │ 의존성 관리 │ │ 파일 예약 │ │
│ └──────────────┘ └──────────────┘ └───────────────────┘ │
│ │ │ │ │
│ └─────────────────┼─────────────────────┘ │
│ ↓ │
│ ┌───────────────┐ │
│ │ VC (VibeCoder) │
│ │ AI Supervisor │
│ │ 멀티에이전트 오케스트레이터 │
│ └───────────────┘ │
└─────────────────────────────────────────────────────────────┘각 프로젝트의 역할
| 프로젝트 | 역할 | 핵심 기술 | 상태 |
|---|---|---|---|
| Efrit | 에이전트의 “손” | Elisp 직접 실행 | v0.3.0 |
| Beads | 에이전트의 “기억” | Git+SQLite 분산 DB | v0.24+ |
| Agent Mail | 에이전트의 “소통” | MCP + PostgreSQL | Active |
| VC | 오케스트레이터 | AI Supervisor | Dogfooding |
진화 경로
| 시점 | 프로젝트 | 의미 |
|---|---|---|
| 2025-07 | Efrit | ”실행”에 집중 |
| 2025-10 | Beads | ”기억”으로 전환 |
| 2025-10 | VC | ”조율”로 확장 |
| 2025-11 | Agent Mail | ”소통” 레이어 추가 |
관찰: 실행 → 기억 → 조율 → 소통 순으로 진화
Efrit v0.3.0: 대규모 리팩토링
새로운 아키텍처
lisp/
├── core/ ← 핵심 인프라
│ ├── efrit-executor.el (506줄) ← efrit-async.el 대체
│ ├── efrit-session.el (548줄) ← 새 세션 관리
│ ├── efrit-common.el
│ ├── efrit-config.el
│ ├── efrit-progress.el ← 새 파일
│ └── efrit-tool-utils.el (556줄) ← 새 파일
├── interfaces/
│ ├── efrit-do.el
│ └── efrit-remote-queue.el
├── tools/ ← 새 도구들
│ ├── efrit-tool-project-files.el
│ ├── efrit-tool-search-content.el
│ ├── efrit-tool-vcs-*.el
│ └── ...
└── deprecated/ ← 구 파일들변경 이유 (Why)
- 복잡도 감소: 4개 모듈 → 2개 모듈 (1,523줄 → 1,012줄)
- 명확한 분리:
- Executor = “Claude 호출 방법”
- Session = “무엇을 기억할지”
- 도구 확장 준비: tools/ 디렉토리로 새 도구 쉽게 추가
- 커뮤니티 준비: 새 메인테이너가 이해하기 쉬운 구조
Efrit이 필요한 이유: Emacs의 특별한 위치
왜 CLI 에이전트만으로 부족한가?
CLI 에이전트 (Claude Code, Codex):
┌─────────────────────────────────┐
│ 터미널 │
│ ├── 파일 읽기/쓰기 │
│ ├── 쉘 명령 실행 │
│ └── Git 조작 │
└─────────────────────────────────┘
↑
└── 여기까지만 가능
Efrit (Emacs):
┌─────────────────────────────────┐
│ Emacs 런타임 │
│ ├── 버퍼 조작 │
│ ├── 모드/훅 수정 │
│ ├── 키바인딩 동적 변경 │
│ ├── 새 함수 정의 │
│ ├── 패키지 로드/언로드 │
│ └── UI 동적 생성 │
└─────────────────────────────────┘
↑
└── Elisp로 무한 확장 가능Emacs가 “AI 친화적”인 이유
- Introspection: 런타임에 모든 것을 검사 가능
- Self-Modification: 실행 중에 함수 재정의 가능
- Text-Centric: 모든 것이 버퍼 = 텍스트 기반 AI에 적합
- Programmable UI: AI가 UI를 동적으로 생성 가능
Efrit의 결정적 역할
시나리오: AI가 새로운 코딩 워크플로우를 만들고 싶다
CLI 에이전트:
1. 파일 수정
2. 쉘 스크립트 작성
3. 사용자에게 "이렇게 써주세요" 안내
→ 사람의 개입 필요
Efrit:
1. 새 minor-mode 정의
2. 키바인딩 설정
3. 훅 등록
4. 즉시 활성화
→ AI가 직접 도구를 만들고 배포매크로뷰와의 연결
힣의 Two Track System
| Track | 영역 | 도구 | 목표 |
|---|---|---|---|
| Micro | 리포별 작업 | bd (beads) | 구현해내기 |
| Macro | 삶 전체 | ? (설계 중) | 나를 아는 존재 |
Efrit의 위치
Macro (삶 전체)
│
├── ~/org/ (3000+ org files)
├── self-tracking-data (5년)
├── claude-memory/
│
↓
┌─────────────────────────────┐
│ Emacs = 통합 인터페이스 │
│ ├── org-mode (지식) │
│ ├── denote (연결) │
│ └── efrit (AI 실행) │
└─────────────────────────────┘
↓
Micro (프로젝트별)
│
└── .beads/ (작업 추적)Efrit이 필요한 이유:
- Emacs가 Macro-Micro를 연결하는 허브
- AI가 org-mode 파일을 직접 조작
- 지식베이스와 작업 추적을 실시간 연동
결론: Efrit의 미래 가치
현재 상태
- Efrit 자체는 “순수 실행기”로서 완성도 높음
- v0.3.0으로 아키텍처 정리 완료
- 새 도구들 (VCS, 프로젝트 탐색) 추가
잠재적 가치
-
Emacs-AI 통합의 유일한 해법:
- VS Code, Cursor 등은 API 한계
- Emacs만이 “AI가 자기 자신을 수정” 가능
-
Macro Memory System의 실행 레이어:
- org-mode + efrit = AI가 지식베이스 직접 조작
- denote 파일 자동 생성/연결
-
멀티에이전트 노드:
- Agent Mail + Efrit = Emacs가 에이전트 네트워크의 노드
- 다른 CLI 에이전트들과 협업
Steve Yegge의 비전 해석
“우리는 코드를 만드는 것이 아니라 경험을 만든다” — Steve Yegge, Vibe Coding 인터뷰
Emacs는 “경험을 만드는 도구의 도구”:
- IDE가 아니라 “운영체제”에 가까움
- AI가 이 운영체제를 직접 프로그래밍
- 사용자는 “팀 리드”로서 방향만 제시
다음 단계
단기 (ko 브랜치 작업)
- upstream 머지 (113 커밋)
- 새 아키텍처에 맞게 OpenRouter 재구현
- efrit-executor.el에 API 백엔드 선택 로직 추가
장기 (매크로뷰 통합)
- org-mcp-server + efrit 연동 검토
- claude-memory → efrit 통합 가능성
- Macro Memory System에서 efrit의 역할 정의
세션 정보
- 환경: ThinkPad P16s (Ubuntu)
- 디바이스: laptop (work)
- 시간: 2025-11-26 오전
- 분석 대상: efrit upstream 113 커밋, mcp_agent_mail
Comments