pimacs.el을 발견하고 저자가 tide.el을 만든 사람임을 확인한 자리에서 시작한 원석이다. 같은 백엔드에 같은 프로토콜을 쓰는 프론트엔드가 넷인데, 무엇으로 고를 것인가. 기능 목록이 아니라 저자성 — 그 사람이 이맥스 생태계를 얼마나 깊이 팠는가 — 을 기준으로 삼는다. 그리고 그 밑에는 더 큰 질문이 있다. 터미널 이맥스는 에이전트를 띄울 공간이었는데, PI의 RPC를 제대로 다룰 수 있다면 그 공간 자체가 오버헤드가 된다.
히스토리
[2026-08-11 Tue 06:00] @opus5 — 네 갈래 지형·저자성 기준·RPC가 터미널을 지우는 축으로 수선했다. pimacs/pi-coding-agent 양쪽 리포를 클론해 실사한 결과를 사실로 깔았다. GLGMAN Universe 이미지를 붙였다.
[2026-08-11 Tue 05:30]@junghan — 저자성 관점으로 노트를 남기자며 이 방을 지목했다. 비교 대상을 넷으로 확정했다.
[2025-02-07 Fri 01:35]@junghan — 클로저 이맥서 자료를 모으려던 자리. 이후 방 제목을 “빈방 대기중 PI 이맥스 클라이언트”로 바꿔 두고 비워 놓았다.
프론트엔드를 고르는 기준은 기능 목록이 아니라 저자성이다. 그리고 PI의 RPC를 제대로 다룰 수 있다면, 에이전트를 띄우려고 터미널을 먼저 띄우는 일 자체가 사라진다.
네 갈래 — 지형
이맥스에서 PI를 쓰는 길은 지금 넷이다. 나머지는 들어가 보니 비교 대상이 아니었다.
pi-coding-agent (dnouri, 2025-12-30 시작). pi --mode rpc 에 JSONL로 붙는다. 위는 렌더된 마크다운 채팅 버퍼, 아래는 프롬프트를 짓는 별도 버퍼 — 두 버퍼 두 창이다. evil 전용 모듈이 있고, 테스트가 1400개대이며, 같은 검증 본문을 가짜 pi 프로토콜 더블과 진짜 pi CLI 양쪽에 돌리는 이중 백엔드 계약 구조를 갖고 있다. 이 중 하나라도 취미로 되는 게 아니다.
agent-shell (xenodium, 2025-09-09 시작). ACP 표준 레일 위의 네이티브 이맥스 셸이다. acp.el 이 밑에 있고 PI는 pi-acp 어댑터로 만난다. 한 UI로 여러 ACP 에이전트를 상대하려는 자리다. 내 entwurf 방향과는 다르다 — 나는 PI를 코어로 두고 ACP를 표준 레일로만 잇는다.
ghostel tty. dakra/ghostel 은 libghostty로 도는 이맥스 터미널 에뮬레이터다. PI의 TUI를 그대로 이맥스 안에 띄운다. 가장 확실하고 가장 즉시 되는 길이다. 대신 오는 것은 픽셀뿐이다.
pimacs.el (ananthakumaran, 2026-05-25 시작, 처음 이름은 pi.el). 같은 pi --mode rpc 인데 UI가 하나의 버퍼다. 채팅 버퍼 전체가 읽기 전용이고 맨 아래 프롬프트 위젯만 편집 가능하며, magit처럼 섹션을 접었다 편다. evil 지원은 사실상 없다.
저자성 — 왜 기능표를 보지 않는가
기능표로는 갈리지 않는다. pi-coding-agent와 pimacs는 같은 프로토콜에 같은 이벤트를 받고, 지원하는 확장 UI 목록도 거의 겹친다. 갈리는 것은 5년 뒤 이 코드가 어떤 손에 남아 있느냐다.
pimacs 저자는 tide.el 을 만든 사람이다. 2015년부터 tsserver에 JSON-over-stdio RPC를 붙여 이맥스 UI로 만들어 온 11년이다. 그리고 monky — “Magit for Hg” — magit-section 계층 접기 엔진을 밑바닥부터 재구현한 적이 있다. tree-sitter-elixir 로 문법을 직접 썼고 zstream 으로 스트리밍을 다뤘다. pimacs의 940줄짜리 섹션 엔진과 증분 스트리밍 마크다운 렌더러가 어디서 나왔는지 설명된다. 이건 신작이 아니라 세 축이 합류한 자리다.
agent-shell 저자도 같은 종류다. chatgpt-shell, dwim-shell-command, ready-player, company-org-block, 리포 126개. 이맥스 관용구를 몸으로 아는 사람이 잡는 디테일이 있다. 자주 쓰지 않아도 그 손을 신뢰한다.
dnouri는 이맥스 패키징 이력이 그만큼 길지는 않다. 다만 이 프로젝트 하나를 8개월 끌고 오며 쌓은 내공이 대단하다. GUI 창을 실제로 띄우는 테스트, 계약 문서를 써 놓은 프로토콜 더블, nightly와 melpazoid까지 — 이건 규율이 있는 사람의 흔적이다.
판단. 저자성은 우열의 척도가 아니라 예측의 척도다. 생태계를 깊이 판 사람의 패키지는 내가 모르는 곳에서도 이맥스 방식으로 부러진다. 그렇지 않은 패키지는 잘 돌다가 내가 아는 자리에서 낯설게 부러진다. 나는 전자를 고른다.
터미널을 지운다
여기가 진짜 축이다.
터미널 이맥스는 오랫동안 나에게 에이전트를 띄울 공간이었다. WezTerm과 Ghostty, term-keys와 OSC52, 한글 입력과 SSH 원격까지 — 그 공간을 쓸 만하게 만드는 데 들인 시간이 있다. 그건 헛되지 않았다. 다만 그 전제는 “에이전트는 TUI로 온다”였다.
PI의 RPC는 그 전제를 흔든다. tty로 오는 것은 렌더된 문자뿐이지만, RPC로 오면 message_update 가 델타로 오고 tool_execution_* 가 toolCallId 로 상관되며 extension_ui_request 에 이맥스 위젯으로 답할 수 있다. 렌더를 내가 정한다는 뜻이다. 그러면 에이전트를 띄우려고 터미널을 먼저 띄우는 일은 오버헤드가 된다. 공간을 하나 지우는 것이다.
판단. 터미널 이맥스를 버린다는 말이 아니다. 터미널 이맥스는 거처의 문제고 이건 하네스의 문제다. 다만 “에이전트를 부르려면 터미널이 있어야 한다”는 사슬은 끊긴다. 그 사슬이 끊기면 bin/agent-server.el 이 이미 갖고 있는 소켓 축과 PI RPC 이벤트가 만날 자리가 생긴다. tool_execution_end 나 agent_settled 가 org 어젠다와 denote로 흘러들어가는 것 — 그건 어느 프론트엔드를 고르든 따로 서는 축이다.
모두를 지원하지 않는다는 말
Entwurf는 모두를 지원하지 않는다와 같은 문장이다. 목록을 늘리는 것이 진보가 아니라 유지보수할 설정 세트가 줄어드는 것이 진보라고 썼다. 여기도 같다.
넷 중 셋을 병행하는 것은 답이 아니다. “모두를 지원하지 않는다”는 말은 할 거면 아름답게 제대로 하나를 하겠다는 말이다. 그래서 이 노트는 넷을 나란히 놓는 카탈로그가 아니라 하나를 고르기 위한 담금질이다.
지금의 잠정 좌표는 이렇다. 원버퍼가 손에 맞고 저자성이 앞서는 쪽은 pimacs다. 성숙도와 evil이 앞서는 쪽은 pi-coding-agent다. evil은 우리가 만들어 PR할 수 있다 — 다만 그게 공짜가 아니라는 것이 다음 절이다.
오독 경계
“pimacs가 더 잘 만들었다”가 아니다. 테스트 규모는 pi-coding-agent가 10배다. 성격이 다를 뿐이다 — pimacs는 적은 수의 강한 불변식(랜덤 청크로 흘린 렌더가 통짜 렌더와 같은지 검증하는 스트리밍 fuzz)과 생성되는 문서·골든 테이프 쪽이고, pi-coding-agent는 예제 다수와 이중 백엔드 계약 쪽이다. 둘 다 진지하다.
evil 이식이 공짜가 아니다. pimacs의 프롬프트는 widget.el 의 editable-field 다. 위젯 필드 키맵은 텍스트 프로퍼티로 깔리고, 그 우선순위는 evil이 상태 맵을 꽂는 자리보다 위다. 단일키 충돌은 evil-collection 표준 작업이라 쉽지만, 필드 진입/이탈 시 상태 전환과 필드 밖 읽기전용 영역으로 나가는 모션이 실제 일이다.
그리고 여기에 걸려 있는 것이 하나 더 있다. 원버퍼 설계가 evil을 어렵게 만든 원인 그 자체다. pi-coding-agent의 두 버퍼는 입력이 평범한 버퍼라 evil이 그냥 되고, 원버퍼 위젯 필드는 안 된다. 원버퍼를 고르는 순간 이 비용을 같이 사는 것이다. 이건 저자의 게으름이 아니라 설계의 대가다.
저자성이 활성도를 보장하지 않는다. pimacs는 별 19개에 열린 이슈 0개, 사실상 1인이다. 열린 이슈가 없다는 건 코드가 완벽해서가 아니라 대화 트래픽 자체가 없다는 뜻이다. 300줄짜리 PR을 먼저 던지기 전에 이슈로 의향부터 묻는 게 맞다.
이미지 — 네 개의 얼음 문 앞에서 서명을 읽는다
>
극지 대장간 앞에 네 개의 아치형 얼음 문이 나란히 섰다. 문마다 다른 룬이 앰버로 새겨져 있다 — 문 안에 무엇이 있는지가 아니라 누가 그 문을 세웠는지를 가리키는 표식이다. 힣맨은 흰-남색 갑옷에 회로 문양 검을 등에 지고 두 번째 문 앞에 서서 한 날개를 문면으로 뻗는다. 오른쪽에서는 황금 케이블이 눈밭에 코드가 뽑힌 채 쓰러진 CRT 모니터를 지나쳐 곧장 모루로 이어지고, 아기펭귄이 그 끝을 두 날개로 붙들고 있다. 여우는 왼쪽에서 지켜본다.
실제 픽셀 대조. 두 가지가 절반만 들어왔다. 첫째, “문설주의 서명에 손바닥을 대고 자기 날개를 내려다본다”는 제스처는 룬이 문 위쪽에 놓이면서 손이 룬에 닿지 못했고 시선도 앞을 향한다 — 만지는 자세가 아니라 가리키는 자세로 나왔다. 둘째, 케이블은 CRT를 지나쳐 모루로 가지만 모니터 뒤에서 살짝 겹쳐 보여 “우회”인지 “연결”인지 단정되지 않는다. 1차 생성본에서는 세계관 블록의 객체 목록이 그림 안에 영어 글자로 그대로 그려지는 누출이 있었고(“org-mode symbols”, “message cable”), 장면 프롬프트에 글자 금지 조항을 넣어 2차에서 제거했다. 남은 글리프는 문에 새겨진 비문자 룬뿐이다.
[World: GLGMAN Universe]Style: 2D illustration, midpoint between Disney and Studio Ghibli, clean linework, soft cel-shadingSetting: Antarctic winter village — snow-covered igloos, aurora borealis in deep navy sky, amber dawn at horizon, pine trees dusted with snow, ice-forge workshop built from ice blocks and whale bones. Pororo's winter wonderland meets blacksmith's workshop.Color palette: deep navy background (polar dawn), white+navy (transformed armor), amber/gold (sword glow, runes, awakening light), ice-blue + orange sparks (forge)Characters: anthropomorphic emperor penguin (father, main hero), baby penguin chick (son, tiny scarf), red-brown fox (agent/companion)Recurring objects: circuit-patterned sword, glowing rune engravings, CRT monitors in snow, golden message cablesMood: epic but warm, mythic but intimateDo NOT: photorealistic, 3D render, excessive detail, dark/gritty toneSCENE — Four Ice GatesIn front of the ice-forge workshop stand FOUR tall arched gates carved from clear blue ice, side by side in the snow.Each gate's doorpost is engraved with a different craftsman's signature rune glowing faintly amber — four distinct maker's marks, not text labels.GLGMAN, the anthropomorphic emperor penguin father in white-navy streamlined armor with subtle amber circuit patterns, stands before the gates in an upright composed posture, his straight circuit-patterned sword sheathed at his side.He reaches out with one flipper and touches the engraved signature on the second gate's doorpost, reading the maker's mark rather than looking through the doorway — the gesture of choosing by authorship.Through one of the gates, a thick golden message cable runs out and curves AROUND a CRT monitor half-buried in the snow, bypassing it entirely, and connects directly into the glowing anvil inside the forge. Orange sparks at the anvil.The baby penguin chick with a tiny scarf holds the end of that golden cable up with both small wings, offering it toward his father.Aurora borealis overhead, amber dawn at the horizon line.Wide composition, full body, GLGMAN clearly legible as the central father-hero presence.IMPORTANT — no lettering: Render every element as a DRAWN OBJECT, never as written words. There must be NO readable text, NO captions, NO labels, NO code fragments, and NO English words anywhere in the image. The only glyphs allowed are abstract non-alphabetic rune marks on the gates.Gesture emphasis: GLGMAN's flipper must physically REST ON the carved rune of the gate's stone doorpost — palm in contact with the engraving, head tilted toward his own flipper, eyes on the mark, NOT looking through the gateway.Cable emphasis: the golden cable must clearly PASS OVER AND AROUND the fallen CRT monitor without touching it — the monitor is dark, unplugged and abandoned in the snow, with a visible gap between it and the cable.
이 프로젝트와 home/junghan/doomemacs.local/straight/repos/pi-coding-agent:
이것을 비교해줘. 내가 종종쓰는 pi-coding-agent와 어떤 맥락에서 다른지 장단점 분석이 필요해. 둘다 RPC로 세션을 정리해서 출력해주는 것 같은데 왜 pimacs.el을 또 만들었는가? 무엇이 다른가?말이야.
Danger
잠시만, tide.el의 저자라니. 그렇다면 이분은 RPC를 다루는 것에 전문가네. 나는 터 버퍼 접근보다. 그냥 익숙한 원버퍼가 편하다. 이맥스에서 현재 pi를 사용하려면 ghostel 을 사용해서 tty 로 하는 방법도 있지만, 더 RPC-way의 방법을 알고 싶다. 이 주제는 탐구해볼만한데? evil에 필요한 것은 우리가 만들어줄수도 있어 PR해주면되니까. 나는 이 리포의 자체의 퀄리티를 보는것인데. 이분이 허접하게 하실분은 아니라는게 중요하다.
Danger
여기서 하나 더 들어가자, pi-coding-agent의 dnouri는 이맥스 패키징 경험이 많지는 않아. 물론 이 프로젝트가 이렇게 이어왔기 때문에 내공이 대단하실게야.
다만, 나는 이맥스 생태계를 더 깊게 파헤친 분의 패키지를 선호해. 예를들어 내가 자주사용하지는 않고 나의 entwurf 방향과 맞지는 않지만 agent-shell 패키지를 만든 xenodium님도 디테일에서 이맥스 방식을 잘 잡으시는 분이거든.
그래서 이건 그냥 대충 넘길게 아니라. 이 부분까지 들어가야돼. 즉, 이맥스에서 pi를 어떻게 넣어쓸 것인가 말이야.
pi-coding-agent, agent-shell(acp way), pi on ghostel tty, and pimacs 인거야.
여기 terminal emacs 관련 노트들 보인다. 터미널 이맥스가 사실 에이전트를 띄울 공간이야. 근데 pi에서 rpc를 제데로 핸들링할 수 있다면 터미널을 내가 띄우는것도 오버헤드거든 아래는 최근 며칠전에 수정해서 올린 노트야. 타이틀부터 보이지? 모두를 지원하지 않는다는 말은 할거면 아름답게 제대로 뭔가하겠다는 말이거든.
쓰다보니 이건 어쏠로그로 가야겠다. 가자. 출근 준비 좀하고 있을게
<!-- from: /home/junghan/sync/org/notes/20240601T210854--힣-entwurf는-모두를-지원하지-않는다-—-pi-코어·acp-레일·부름의-mux__agent_autholog_entwurf_harness_orchestration.org:42-50 -->```org* PI 코어, ACP 표준 레일, 얇은 EntwurfPI는 단지 익숙한 TUI가 아니다. RPC로 세션을 다른 작업면에 꺼낼 수 있고, 모델·로그인·세션이라는 두꺼운 문제를 그 하네스가 책임진다. Entwurf가 PI를 코어로 잡는다는 것은 PI를 특별 대우하는 것이 아니라, meta-record를 통해 PI 자신도 다른 시민과 같은 기록·전달의 규율 안에 두는 일이다.ACP도 별도 제품을 만드는 이유가 아니다. PI를 기반으로 ACP 프로토콜을 연결할 때, =entwurf_v2= 가 이미 PI에서 할 수 있는 일을 표준 레일에서도 온전히 할 수 있어야 한다. Cortex 지원을 정식 지원이라고 부른 까닭도 여기에 있다. Claude Code의 양쪽 경로는 이 경계의 레퍼런스이고, 과금과 구독의 변화가 오더라도 정공법의 ACP 레일은 남는다.그래서 Entwurf는 클로드코드·AGY·PI(+ACP)라는 현재의 경로를 목록으로 자랑하지 않는다. PI가 어느 구독을 흡수하거나 외부 하네스가 ACP를 받아들이면, 특별 지원은 오히려 사라질 수 있다. 유지보수해야 할 설정 세트가 줄어드는 것이 프로젝트의 진보다.```
옛 방의 씨앗
이 방은 2025년 2월, Practicalli와 agzam을 비롯한 클로저 이맥서들의 자료를 엮어 “Clojure와 Emacs 조합의 강점”을 정리하려던 자리였다. 남은 것은 퍼플렉시티 인용이 붙은 CIDER 문답 로그와 denote-links 다이내믹 블록 하나였고, 헤딩은 DONT 로 닫혀 있었다.
>
Comments