Pi: 자체 도구를 작성하는, 미니멀하고 자기 확장형인 코딩 에이전트
— 회 조회
Pi는 1,000 토큰 미만의 시스템 프롬프트와 네 가지 핵심 도구(Read, Write, Edit, Bash)를 중심으로 구축된 오픈소스 터미널 코딩 에이전트다. 내장 기능을 제공하는 대신, 필요할 때마다 자체 TypeScript 확장을 작성한다. MIT 라이선스, v0.78.1(2026년 6월 4일).
npm install -g --ignore-scripts @earendil-works/pi-coding-agentPi란 무엇인가
Pi는 2026년의 대다수 하네스와 정반대의 베팅을 하는 오픈소스 커맨드라인 코딩 에이전트다. 큰 시스템 프롬프트와 수십 개의 번들 도구 대신, 약 1,000 토큰 미만의 시스템 프롬프트와 단 네 가지 핵심 도구——Read, Write, Edit, Bash——만을 제공한다. 사이트의 홍보 문구는 직설적이다. “에이전트 하네스는 많지만, 이것은 당신의 것이다.”
이 프로젝트는 Mario Zechner의 작업으로 시작되었고 현재는 Earendil Inc. 산하에서 개발되고 있으며, Armin Ronacher(Flask와 Jinja2의 제작자)의 기여도 있다. 코드는 MIT 라이선스 아래 badlogic/pi-mono 모노레포에 있으며, @earendil-works/pi-coding-agent로 npm에 게시된다. 이 글을 쓰는 시점의 최신 릴리스는 v0.78.1로 2026년 6월 4일에 태그되었으며, 5월 내내 빠른 릴리스 주기(v0.75부터 v0.78까지)를 보였다.
차별화 요소: 스스로 역량을 구축한다
정의적 특징은 자기 확장이다. 어떤 역량이 존재하지 않으면, Pi에게 그것을 구축하도록 요청하면 되고, 그러면 Pi는 새로운 도구와 지침을 노출하는 TypeScript 확장 모듈을 작성한 뒤 이를 호출할 수 있다. 이는 기본 컨텍스트를 작게 유지하면서도 표면적을 프로젝트마다 키울 수 있게 한다. 이 저장소는 또한 재사용 가능한 조각들로 깔끔하게 분리된다. 공급자에 구애받지 않는 LLM 레이어(@earendil-works/pi-ai), 에이전트 런타임(@earendil-works/pi-agent-core), 터미널 UI 라이브러리(@earendil-works/pi-tui), 그리고 코딩 에이전트 CLI 자체다.
Pi는 네 가지 동작 모드——대화형, print/JSON, RPC, 그리고 SDK——와 더불어 트리 구조의 세션 히스토리 및 15개 이상의 공급자 통합을 내세운다. 최근 릴리스는 자동화 지향 도구로서의 실용적 면모를 보여준다. v0.77.0은 Claude Opus 4.8 지원, 도구를 선택적으로 비활성화하는 --exclude-tools, 그리고 헤드리스 로그인을 위한 디바이스 코드 인증을 추가했다. v0.78.0은 --name을 통한 이름 있는 시작 세션과 OSC 8 하이퍼링크를 통한 클릭 가능한 파일 경로를 추가했다. v0.78.1은 공급자 커버리지를 넓혔다.
비교
| 차원 | Pi | 전형적인 대형 하네스 |
|---|---|---|
| 시스템 프롬프트 | 약 1,000 토큰 미만 | 수천 토큰 |
| 내장 도구 | 4(Read/Write/Edit/Bash) | 다수, 고정 |
| 새 역량 | 에이전트가 자체 확장을 작성 | 릴리스를 기다림 |
| 표면적 | 프로젝트마다 성장 | 출시 시 고정 |
시작하기
npm으로 전역 설치하거나(--ignore-scripts 플래그가 문서화된 형식이다), 설치 스크립트를 사용한다.
npm install -g --ignore-scripts @earendil-works/pi-coding-agent
# or
curl -fsSL https://pi.dev/install.sh | sh그런 다음 저장소에서 pi를 실행하고, 빈틈을 만나면 플러그인 마켓플레이스에 손을 뻗는 대신 빠진 도구를 구축하도록 요청하면 된다.
실무자 노트
미니멀 프롬프트 접근은 토큰 예산과 재현성을 중시한다면 가장 매력적이다. 작은 기본 컨텍스트는 모델을 조종하는 숨겨진 지침이 더 적다는 뜻이며, 프로젝트별 확장은 diff를 떠서 커밋할 수 있는 검사 가능한 TypeScript다. 트레이드오프는 에이전트가 곧이어 실행할 코드를 작성하도록 신뢰한다는 점이다——--ignore-scripts 설치 플래그와 문서화된 컨테이너화 경로는 유지관리자들이 당신이 그것을 샌드박스화하기를 기대한다는 신호다. 생성된 확장은 다른 의존성과 똑같이 다루라. Bash 접근 권한으로 실행되기 전에 그것들을 검토하라.
충분히 고려되지 않은 관점
흥미로운 장기적 질문은 “에이전트가 자체 도구를 작성하는 것”이 내구성 있고 공유 가능한 역량을 만들어내는가, 아니면 프로젝트들에 걸쳐 거의 중복되는 일회성 확장의 난립을 낳는가이다. 각 저장소가 자체 도구 세트를 키우도록 허용하는 하네스는 플러그인 생태계의 큐레이션 문제를 파편화 문제와 맞바꾼다——다섯 개의 프로젝트가 저마다 약간씩 다른 “테스트를 실행하고 실패를 요약하는” 도구를 재발명할 수 있다. 이 모델에서 승리하는 팀은 아마도 에이전트가 작성한 확장을 일급 소스 코드로 다루는 이들일 것이다. 즉, 버전을 매기고, 검토하고, 매번 처음부터 재생성하기보다는 공유되는 내부 라이브러리로 승격시키는 것이다.