이 스레드의 호평과 달리, 기대에 비해 Pi는 다소 실망스러웠음. 사용자 정의 아이디어는 좋지만 사소한 불편이 많고, 최소형 프로그램치고 시작이 느리며 기본 C-p, C-n 키 바인딩도 작동하지 않음 XDG Base Directory Specification을 따르지 않고 $HOME을 어지럽히는 것도 문제임. 오픈소스이고 Rust·Go 같은 빠른 컴파일 언어로 작성되며, Lua 같은 단순한 스크립트 언어를 지원하고, XDG 요청을 WONTFIX로 닫지 않는 덜 독선적인 실행 도구가 나올 여지는 여전히 큼

Pi에게 요청하면 20초 만에 키 바인딩이나 $HOME 처리 등을 바꾸는 확장을 작성해 주고, 기존 확장을 포크해 손볼 수도 있어 초기 적응이 빠름
세션 탐색·검색, 읽기·쓰기·검색 결과 추론처럼 민감한 작업에 결정론적 코드를 실행하는 위임 확장, 일괄 모드에서 도구 호출을 정리해 GPT-5.x의 문맥 공간을 절약하는 확장, 자동 검색과 유사한 확장까지 원하는 작업 흐름을 거의 그대로 구현했음. Tmux 연동으로 별도 창이나 패널에 작업 트리도 띄울 수 있음
실행 도구는 사람이 생각하고 작성하는 과정이 병목이므로 성능 문제를 겪은 적은 없음

Pi를 아주 좋아하지만, 오랫동안 내세운 문구가 “실행 도구는 많지만 이것은 내 것”이었던 점이 가장 큰 약점임. 소유자가 문구를 MINE에서 YOURS로 바꿨지만, 표준에서 벗어난 동작이나 제안이 팀에 의해 WON'T FIX로 닫히는 모습을 보면 여전히 Mario의 도구에 가까움
독선적인 설계를 좋아하더라도 표준에는 존재 이유가 있음. 그럼에도 Pi를 주력으로 쓰며 공유 버스로 연동되는 플러그인 생태계까지 만들었을 만큼 훌륭한 실행 도구지만, 일부 설계 판단에는 동의하기 어려움
OpenAI API 명세만으로 모든 정보를 얻을 수는 없어도 모델 설정에 필요한 상당 부분은 확보할 수 있는데, Pi 배포본에는 여전히 특정 추론 제공자의 모델 설정이 포함됨. 기반 작업이 진행되는 만큼 언젠가는 이를 분리하길 기대함
기여하려는 사람이 많지만 팀은 직접 세심하게 만들고 싶어 하는 듯하며, 현재 방향 자체는 옳다고 봄

최소형 프로그램이 $HOME에 파일을 흩뿌리는 행태는 정말 화가 남. Ollama와 Claude Code도 비슷한 것으로 보이며, 2026년의 새 소프트웨어가 홈 디렉터리에 dotfile을 만드는 데는 변명의 여지가 없음

smol은 표준 라이브러리만 사용하는 약 20줄짜리 Go 프로그램이지만, MCP·agents.md·시스템 프롬프트를 쓰지 않는 등 상당히 독선적이라 모든 조건을 충족하지는 않을 수 있음
구현 전체가 문맥 창에 넉넉히 들어갈 만큼 작아 쉽게 수정할 수 있고, smol을 포함한 에이전트도 코드를 온전히 이해하며 작업하기 좋음 https://github.com/smol-env/smol

서버에서 Pi를 헤드리스 모드와 XMPP 클라이언트로 감싸 성공적으로 사용 중임. XMPP에 접속할 수 있는 어디서든 대화할 수 있고, 필요하면 에이전트끼리도 소통하며 공유 위키와 GitHub 이슈를 작업 목록으로 사용함
NixOS에서 이름이 지정된 여러 Pi 인스턴스를 각각 별도 사용자 계정으로 병렬 실행함. 에이전트가 임시 셸에 원하는 것을 설치할 수 있어 환경을 걱정할 필요가 없고, 요청하면 XMPP 에이전트를 새로 띄울 수도 있음
Pi 자체는 XMPP 래퍼와 익명 하위 에이전트용 pi-subagents 확장만 추가한 기본 구성에 가까움. 주로 Deepseek v4 Flash로 자리를 비우거나 이동하는 동안 코딩 및 서버 유지보수 작업을 조금씩 처리함
핵심은 NixOS임. 에이전트가 서버 설정 전체를 보고 변경한 뒤 실제 배포 전에 컴파일 검사를 실행할 수 있고, 잘못되더라도 언제든 되돌릴 수 있음

이메일과 Pi를 조합하면 응답을 이메일 패치로 받아 검토하고 여러 스레드를 유지하기 쉬울 듯함. 다만 메일을 설정하는 것보다 XMPP를 VPN에 연결하는 편이 조금 더 간단해 보임

같은 이유로 NixOS 기본 지원을 추가했음. 변경과 디버깅이 쉬워지고 고객 요청도 있었으며, 웜 풀에서 이를 지원하는 샌드박스 제공자는 아마 우리뿐일 것임

모든 에이전트가 개인용 컴퓨터 같은 공유 파일 시스템과 연산 환경을 쓴다면, Markdown 파일 폴더 대신 여전히 위키를 선택할지 궁금함. 공유 상태 저장소로 위키가 자주 선택되는 이유를 파악하고 싶음

Pi는 기본 상태에서 오히려 너무 최소형임. Emacs에 비유하면 파일은 불러올 수 있지만 저장하거나 파일 내부를 검색하려면 직접 확장해야 하는 수준임
모델이 코딩 작업을 끝낼 수 있게 하는 최소 기능은 별도 설정 없이 제공되어야 함. 같은 성향의 사용자를 위한 Oh-my-pi도 있음

내 사용 환경에서는 Pi가 Codex보다 문맥 압축과 토큰 사용을 훨씬 잘 처리했고, 이것이 전환한 주된 이유임
Codex와 동일한 압축 방식과 도구로 옮기면 결국 Codex와 같은 수준이 되는데, 그러면 Pi의 이점이 무엇인지 의문임. 터미널 UI를 바꾸고 기능을 얹을 수는 있어도 효율 향상은 사라짐

코딩 실행 도구를 위한 좋은 벤치마크가 있는지 궁금함. Pi는 토큰 소비와 로컬 모델 지원 면에서 훌륭하지만, 코딩 품질·작업 완료율·과도한 설계 등 최종 결과를 기준으로 각 도구의 장단점을 보여주는 자료가 필요함
제대로 비교할 방법이 없어 실행 도구를 계속 바꿔가며 고생 중임

개방형 작업을 제대로 비교하려면 시간과 노력이 많이 들고, 설정 변수도 지나치게 많음. 제공 환경, 모델, 하위 에이전트, 기본 또는 사용자 정의 시스템 프롬프트, agents.md 등을 모두 고려해야 함
실행 결과의 변동성이 크므로 여러 번 실행하고 추적 기록까지 살펴봐야 하며, 적은 표본만으로는 신뢰하기 어려움

철학적으로 pi.dev는 찾던 도구와 정확히 맞음. 최소형이고 명시적이며, 기본값인 YOLO 모드가 위험할 수 있다는 점도 분명히 알림
pi.dev 작성자가 지지하는 Rust 재작성판을 주력으로 쓰는 사람이 있는지 궁금함. 최소형이면서 npm이 붙지 않아 매력적인데, 샌드박스 설정이나 편의 기능 같은 실제 사용 정보가 필요함

Pi의 장점은 좋은 문서와 쉬운 사용자 정의를 갖춘 최소형 도구라는 데 있음. 덕분에 작성자가 상상하지 못한 용도가 생기며, Pi 생태계가 유기적으로 성장하는 과정도 흥미로움
지금까지 가장 좋아하는 코딩 에이전트 중 하나로, 개인 용도를 넘어 큰 환경까지 확장 가능함. 단순한 코딩 에이전트보다 강력한 확장성을 갖춘 코딩 에이전트 플랫폼에 가까움

최소한의 시스템 프롬프트 외에 Pi가 다른 에이전트보다 문맥을 더 잘 처리하는 방식이 무엇인지 궁금함. 매 요청마다 AGENTS.md, 기능 정의, 전체 대화와 함께 시스템 프롬프트를 보내야 하는 것은 동일하지 않나 싶음

/tree는 놀라운 문맥 관리 기능인데 다른 실행 도구가 아직 도입하지 않은 점이 의외임. 이전 메시지로 돌아가 대화를 분기하고, 에이전트의 발언을 파고드는 곁가지 작업을 현재 문맥에서 제거할 수 있음
기존 대화 기록을 별도 스레드에 유지하고 서로 오갈 수도 있어 단순한 되감기 기능보다 강력함

Pi의 시스템 프롬프트는 OpenCode보다 훨씬 작고, agents.md가 바뀌어도 다시 삽입하지 않아 캐시를 보존함. 도구도 네 개뿐이며 각 도구 설명이 추론 부담을 만들기 때문에 적을수록 유리함
Pi, OpenCode, smol이 같은 작업을 새 세션에서 각각 아홉 번 수행한 추적 기록을 볼 수 있음 https://smolenv.com/t/nested-template-includes-60636/
시스템 프롬프트와 도구가 에이전트의 행동을 어떻게 유도하는지 단계별로 확인 가능함. GPT 5.6 Sol은 시스템 프롬프트 없이 sh 도구 하나만으로도 작동함

많은 실행 도구가 문맥이 커지면 압축하지만 Pi는 기본적으로 그러지 않는다고 생각했으나, 이는 잘못 알고 있던 내용임. 기본 도구가 적어 에이전트가 인지해야 할 외부 도구 호출 설명으로 문맥이 오염되지 않는 장점도 있음
문맥을 특별히 더 잘 처리한다기보다 거의 손대지 않으며, 오히려 이것이 비용 효율에 유리할 수 있음

핵심은 최소한의 프롬프트와 내장 기능이며, 사용자 정의 구성을 연결하면 거의 완전한 제어도 가능해 보이지만 직접 해보지는 않았음

여러 코딩 실행 도구를 써본 결과 Pi는 Emacs를 쓰는 느낌과 정확히 같음. 원하는 기능은 에이전트에게 만들어 달라고 할 수 있고 기존 설정 코드도 많지만, 코드 절반은 버그가 있고 UI 요소가 겹치며 가끔 충돌함
학습 곡선을 넘고 문제를 감수할 의지가 있다면 훌륭한 도구가 될 수 있음 https://i.sstatic.net/7Cu9Z.jpg

적어도 코딩 실행 도구에서는 이런 철학을 이해하기 어려움. 다른 도구가 기본 제공하는 기능을 위해 두 시간 동안 프롬프트를 작성하고 설정하고 고치고 싶지 않으며, 표준 기능을 재구현하는 데 토큰을 낭비하고 싶지도 않음
가상 머신, 서버, 노트북 등 사용하는 모든 장비에서 같은 과정을 반복하는 것도 원치 않음

Emacs는 배우지 않았지만 Neovim 사용자이며, 동료들에게도 비슷하게 비유했음. Codex와 Claude Code가 VS Code·JetBrains라면 Pi는 Neovim임

Claude 5 모델용으로 Claude Code 시스템 프롬프트의 약 80% 를 제거했으므로, 실행 도구의 작업당 비용 벤치마크는 이미 낡았을 수 있음