이 글은 Claude Opus 5.5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Over the past few months, Claude Code has turned into a spaceship with 80% of functionality I have no use for.

Mario Zechner 가 2025년 11월 30일 블로그에 쓴 문장입니다. 지난 몇 달 사이 Claude Code 가 쓸 일 없는 기능이 80% 인 우주선이 됐다고요. 그는 Cursor 를 1년 반 쓰다가 2025년 4월 Claude Code 로 갔고 대부분의 일을 Claude Code 로 했는데, 릴리스마다 시스템 프롬프트와 도구가 바뀌어 작업 흐름이 깨지고 모델의 행동이 달라지는 게 싫었다고 했어요. 화면이 깜빡이는 것도요. 그래서 직접 만든 게 Pi 이고, 원칙은 한 줄이었습니다. “if I don’t need it, it won’t be built.”

저는 이 글을 쓰려고 Pi 1.4.0 을 처음 설치해 봤습니다. Claude Code 를 업무에 쓰고 Codex 도 써 본 사람으로서 가장 먼저 눈에 들어온 건 기능 목록보다 “넣지 않은 것” 목록이었어요. 이 편은 Pi 가 무엇을 넣고 무엇을 뺐는지, 그 선택의 이유와 대가를 봅니다.

누가 만들었고 지금 누구 것인가#

Zechner 는 Java 게임 프레임워크 libGDX 를 만든 사람입니다. 본인 말로 2009년 무렵부터 오픈소스를 해 왔고 libGDX 가 첫 성공작이었다고 해요. Pi 저장소의 첫 커밋은 2025년 8월 9일인데, 커밋 메시지를 보면 처음엔 코딩 에이전트가 아니라 GPU 서버(pod)를 관리하는 도구로 시작했습니다. 코딩 에이전트 패키지가 npm 에 처음 올라온 건 11월 12일이고, 11월 30일 블로그 글이 Pi 를 세상에 알렸어요. 이름을 일부러 검색이 안 되게 지었다고 농담했는데, 사용자가 없으면 이슈도 없을 테니까요.

2026년 4월 8일 Earendil 이 Pi 를 인수했습니다. Earendil 은 Flask 를 만든 Armin Ronacher 와 Colin Daymond Hanna 가 2025년에 세운 공익법인(Public Benefit Corporation)이고, 인수와 함께 Zechner 는 Earendil 의 주요 지분 보유자이자 팀원이 됐어요. 공지문은 Pi 를 “OpenClaw 안의 미니멀 에이전트” 라고 소개했고, 초기 투자자 명단에 OpenClaw 의 Peter Steinberger 와 Sentry 의 David Cramer 가 있습니다. Zechner 는 같은 날 글에서 “pi is MIT licensed. It will stay MIT licensed.” 라고 못 박으면서도, MIT 코어 위에 Fair Source 와 독점 라이선스 기능이 단계적으로 붙을 거라고 예고했어요. 5월 7일 npm 패키지 이름이 @mariozechner/pi-coding-agent 에서 @earendil-works/pi-coding-agent 로 바뀌었고, 2026년 10월 1일 1.0 이 나왔습니다. 제가 설치한 1.4.0 은 10월 21일 릴리스예요.

규모는 이렇습니다. 2026년 10월 23일 GitHub 기준 스타 11만 7천여 개, 기여자 300명 안팎, 10월 12일부터 18일까지 npm 주간 다운로드가 새 패키지 271만, 옛 이름 23만입니다. 다운로드는 CI 와 자동 업데이트가 섞인 숫자라 사용자 수와는 달라요. Earendil 은 1.0 공지에서 매주 수십만 명이 Pi 를 쓴다고 했고, 사용자들이 공유한 extension 이 5천 개를 넘는다고 했는데 둘 다 회사 발표라 확인할 방법은 없습니다.

프롬프트 한 장과 도구 네 개#

Pi 의 기본 시스템 프롬프트는 짧습니다. 설치한 1.4.0 의 소스에서 기본 설정(도구 네 개, 규칙 파일·skill 없음)으로 프롬프트를 직접 조립해 보니 2,843자, 371단어였어요. 토큰으로는 700개 안팎입니다. 첫 문장은 이렇습니다.

You are an expert coding assistant operating inside pi, a coding agent harness.

그 뒤로 도구 네 개의 한 줄 설명, 열 줄 남짓한 규칙(파일 목록은 bash 로, 파일 내용은 read 로, 부분 수정은 edit 로, 새 파일만 write 로, 답은 간결하게), Pi 자기 문서의 위치, 현재 디렉터리가 붙습니다. 그게 전부예요. 2025년 11월 블로그에 실린 원래 프롬프트는 이보다 더 짧은 980자 남짓이었고, Zechner 는 당시 시스템 프롬프트와 도구 정의를 합쳐 1,000 토큰이 안 된다고 했습니다. 1년 사이 세 배쯤 늘었지만 여전히 한 화면에 들어옵니다. Simon Willison 이 코딩 에이전트의 시스템 프롬프트는 수백 줄이 될 수 있다며 2026년 3월 Codex 의 프롬프트를 예로 든 것과 비교하면 차이가 분명하죠.

기본 도구는 read·bash·edit·write 네 개입니다. grep·find·ls 도 들어 있지만 기본으로 꺼져 있고, --tools 로 켜야 해요. 파일 검색은 bash 로 rg 나 find 를 부르라는 게 기본 규칙입니다. 그리고 프로젝트의 AGENTS.md 나 CLAUDE.md 를 홈 디렉터리, 상위 디렉터리, 현재 디렉터리 순으로 찾아 프롬프트 끝에 붙입니다. Claude Code 를 쓰던 저장소에서 Pi 를 열어도 CLAUDE.md 가 그대로 읽힌다는 뜻이에요.

이렇게 작게 두는 이유를 Zechner 는 컨텍스트 엔지니어링으로 설명합니다. 1편에서 인용한 대로, 모델의 컨텍스트에 무엇이 들어가는지 정확히 통제해야 결과가 좋아지는데 기존 하네스는 화면에도 드러나지 않는 것들을 몰래 주입한다는 거죠. 프롬프트가 작으면 사용자가 붙이는 규칙과 도구가 그만큼 분명하게 보입니다.

일부러 넣지 않은 것#

pi.dev 에는 “What we didn’t build” 라는 절이 따로 있습니다. 다른 하네스에 다 있는 기능을 빼고, 그 자리를 무엇으로 채우라고 하는지 적어 둔 목록이에요.

빠진 기능Pi 의 대안2025년 블로그의 이유
sub-agenttmux 로 Pi 인스턴스를 여러 개 띄우거나 extension 으로 직접 만듦하위 에이전트가 무엇을 하는지 보이지 않는 “black box within a black box”
권한 팝업컨테이너에서 돌리거나 확인 흐름을 extension 으로 만듦다른 에이전트의 보안 장치는 대부분 “security theater”
plan mode계획을 파일에 쓰거나 extension 으로 만듦Claude Code 의 plan mode 는 계획 과정을 관찰할 수 없음
내장 to-doTODO.md 파일to-do 목록은 모델을 돕기보다 헷갈리게 하는 경우가 많음
백그라운드 bashtmux백그라운드 프로세스 관리는 복잡도를 늘림

권한 쪽 입장이 가장 과격합니다. Pi 는 기본으로 “full YOLO mode” 로 돕니다. 파일 시스템 전체에 접근하고 어떤 명령이든 확인 없이 실행해요. Zechner 의 논리는 에이전트가 코드를 쓰고 실행할 수 있게 되는 순간 사실상 끝이고, 데이터 유출을 막는 유일한 방법은 실행 환경의 네트워크를 끊는 것뿐이라는 겁니다. 그러니 불편한 사람은 컨테이너 안에서 돌리거나 다른 도구를 쓰라고요. 1.4.0 README 도 같은 말을 합니다. Pi 에는 파일 시스템·프로세스·네트워크·자격 증명 접근을 제한하는 내장 권한 시스템이 없고, 더 강한 경계가 필요하면 컨테이너나 샌드박스에 넣으라고.

MCP 는 이 목록에서 빠져나간 유일한 항목입니다. 2025년의 Zechner 는 “pi does not and will not support MCP.” 라고 썼어요. Playwright MCP 가 도구 21개로 13.7k 토큰, Chrome DevTools MCP 가 26개로 18k 토큰을 세션마다 컨텍스트에 쏟아붓는다는 게 이유였습니다. 그런데 1.0 에 MCP 가 내장됐고, Earendil 은 2026년 9월 29일 「You Said No MCP!」 라는 글로 이유를 설명했어요. MCP 를 넣는 데 필요한 변경이 다른 데도 쓸모가 있었고, Pi 에 필요한 것과 MCP 에 필요한 것이 결국 같았다는 겁니다. 인터프리터 형태의 샌드박스. 그래서 1.0 의 MCP 는 기본값이 Codemode 입니다. MCP 도구를 모델에게 하나하나 선언하지 않고, 모델이 JavaScript 샌드박스 안에서 코드를 짜서 도구를 엮어 부르게 하는 방식이에요. 컨텍스트 걱정을 피하면서 받아들인 셈이죠. 같은 글에 “We believe the best way to positively influence something is to embrace it.” 이라는 문장이 있습니다. 1.0 공지문은 새 기능을 받아들이는 기준을 이렇게 적었고요. 무언가가 스스로를 증명할 때까지 기다렸다가, 그 기능이 실제로 주는 것과 덧붙는 복잡도를 저울질한 뒤에야 채택을 고려한다고.

빈자리를 채우는 부품#

빠진 기능의 대안이 거의 다 “extension 으로 만들라” 입니다. Pi 의 extension 은 TypeScript 모듈이고 컴파일 없이 로드돼요. 도구를 등록하고, 슬래시 명령과 단축키를 만들고, 도구 호출 직전이나 프롬프트 조립 직전 같은 이벤트에 끼어들고, TUI 에 상태 표시줄이나 오버레이를 그릴 수 있습니다. 1.4.0 에 딸려 온 예제 하나를 그대로 옮기면 이렇습니다. .env 와 .git/ 과 node_modules/ 에 대한 쓰기와 수정을 막는 extension 이에요.

import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";

export default function (pi: ExtensionAPI) {
	const protectedPaths = [".env", ".git/", "node_modules/"];

	pi.on("tool_call", async (event, ctx) => {
		if (event.toolName !== "write" && event.toolName !== "edit") {
			return undefined;
		}

		const path = event.input.path as string;
		const isProtected = protectedPaths.some((p) => path.includes(p));

		if (isProtected) {
			if (ctx.hasUI) {
				ctx.ui.notify(`Blocked write to protected path: ${path}`, "warning");
			}
			return { block: true, reason: `Path "${path}" is protected` };
		}

		return undefined;
	});
}

모델이 write 나 edit 를 부르면 실행 직전에 경로를 보고, 막을 경로면 도구 호출 자체를 거부하고 이유를 모델에게 돌려줍니다. 프롬프트에 “.env 는 건드리지 마” 라고 쓰는 것과 다른 점은 모델이 그 지시를 잊어도 막힌다는 거예요. 그리고 이 코드를 직접 쓸 필요도 없다는 게 Pi 의 주장입니다. pi.dev 는 필요한 명령이나 도구나 UI 를 Pi 에게 만들어 달라고 하면 Pi 가 자기 자신을 고치고, /reload 하면 바로 쓸 수 있다고 소개해요. 시스템 프롬프트의 docs 절이 Pi 에게 자기 문서와 예제가 어디 있는지 알려 주는 게 그래서입니다.

다만 “만들면 된다” 의 무게는 기능마다 다릅니다. 예제 폴더에 plan mode 와 sub-agent extension 도 들어 있는데, plan mode 는 두 파일 합쳐 560줄, sub-agent 는 1,200줄이 넘어요. Claude Code 에서 단축키 하나로 들어가는 기능이 Pi 에서는 수백 줄짜리 코드이고, 그걸 남이 만든 패키지로 깔든 Pi 에게 시키든 결국 내가 고른 코드가 됩니다.

나머지 부품은 짧게 적겠습니다. skill 은 Anthropic 이 시작한 Agent Skills 형식을 그대로 쓰고, 시스템 프롬프트에는 이름·설명·경로만 넣었다가 필요할 때 전체를 읽게 합니다. 프롬프트 템플릿은 마크다운 파일을 두면 /이름 으로 펼쳐지고, extension·skill·템플릿·테마를 묶은 패키지는 pi install npm:... 이나 pi install git:... 으로 설치해요. 세션은 JSONL 파일 하나에 트리로 저장되고, /tree 로 이전 지점으로 돌아가 거기서 가지를 칠 수 있으며 가지들이 모두 같은 파일에 남습니다. 모델은 15개가 넘는 provider 에서 고르고 세션 중간에 /model 이나 Ctrl+L 로 바꿀 수 있어요. 대화형 TUI 말고도 pi -p 의 print 모드, JSON 이벤트 스트림, stdin·stdout 으로 주고받는 RPC 모드, 앱에 넣어 쓰는 SDK 가 있습니다. 세션 트리와 모델 전환은 4편에서 실제로 써 보겠습니다.

엉클 밥의 원칙과 겹치는 곳#

『Clean Code』 의 Robert C. Martin 이 Pi 를 언급한 자료는 찾지 못했습니다. 그런데 2026년에 그가 공개적으로 설명해 온 에이전트 작업 방식은 Pi 의 설계와 겹치는 데가 많아요. 아래 정리는 그가 출연한 AI DevOps Podcast 419화를 Alex Rusin 이 8월에 요약한 글과 그의 GitHub 저장소에 기댄 것이고, Pi 와 겹친다는 건 제 해석입니다.

Rusin 의 요약에 따르면 엉클 밥은 처음에 TDD 와 클린 코드 규칙을 프롬프트로 설명했고 그 문서가 5~10쪽까지 늘었는데, 모델은 그걸 규칙이 아니라 가이드라인 정도로 취급했다고 합니다. 컨텍스트의 처음과 끝만 무게를 갖고 가운데는 흐려지는 “lost in the middle” 때문이라고 보고, 프롬프트를 최소한으로 줄인 뒤 규칙을 지키게 하는 일을 사후에 도는 결정론적 도구로 옮겼어요. 테스트 커버리지와 순환 복잡도를 합친 CRAP 점수, 연산자를 뒤집어 테스트가 실패하는지 보는 뮤테이션 테스트. 그리고 일 하나를 여러 좁은 에이전트에게 사슬처럼 넘깁니다. 명세를 쓰는 에이전트, 코드를 쓰는 에이전트, 정리하는 에이전트, 뮤테이션 테스트로 단련하는 에이전트, QA 에이전트. 컨텍스트를 작게 유지해야 맨 위의 규칙이 실제로 지켜진다는 이유입니다. 이 사슬이 그가 4월에 공개한 swarm-forge 의 역할 팩이고, swarm-forge 는 그 에이전트들을 tmux 세션과 git worktree 에서 돌립니다.

겹치는 곳을 차례로 짚어 보면, 먼저 프롬프트를 작게 둔다는 출발점이 같아요. 엉클 밥은 경험으로 긴 규칙 파일을 버렸고, Pi 는 처음부터 프롬프트를 한 장으로 두고 규칙 파일을 사용자 몫으로 남겼습니다. 여기서 주의할 게 있는데, Pi 가 AGENTS.md 를 자동으로 읽는다고 해서 거기에 규칙을 길게 쓰라는 뜻은 아닙니다. 엉클 밥의 교훈대로라면 오히려 짧게 써야 하죠.

다음은 규칙을 지키게 하는 자리입니다. 엉클 밥이 뮤테이션 테스트와 CRAP 점수로 옮긴 일을 Pi 에서는 위의 protected-paths 같은 extension 이 맡을 수 있어요. 모델이 잊어버려도 도구 호출 단계에서 걸리는 결정론적 검사니까요.

마지막이 가장 단단한 공통점인데, 기능을 하네스 안에 넣지 않고 하네스 여러 개를 바깥에서 엮는다는 발상입니다. Pi 가 sub-agent 대신 “Spawn Pi instances via tmux” 를 권하는 것과 swarm-forge 가 tmux 로 역할별 에이전트를 띄우는 건 같은 방향이에요. 다만 swarm-forge 가 지원하는 백엔드 목록에 Pi 는 없습니다. Claude·Codex·Grok·Copilot 이에요. 엉클 밥이 하네스는 남의 것을 쓰고 그 위의 조율만 직접 만든 반면, Pi 는 하네스 자체를 사용자 것으로 만들자는 쪽입니다. 그가 같은 저장소에서 Claude 세션 둘을 띄워 하나는 계획만, 하나는 코드 수정만 하게 한다는 이야기도 LinkedIn 에 소개됐는데(Chris Rickard), 계획을 파일로 따로 두라는 Pi 의 “No plan mode” 와 같은 감각입니다. 그가 “에이전트가 만든 코드를 더 이상 읽지 않는다” 고 했다는 이야기도 유튜브 영상 제목 등으로 퍼졌지만, 본인 글은 확인하지 못해 여기서는 그렇게 소개됐다는 정도로만 적어 둡니다.

약점과 비판#

권한 시스템이 없다는 건 철학이지만 위험이기도 합니다. Pi 의 보안 문서는 스스로 이렇게 씁니다. 대화 기록을 지켜보는 것도, 프로젝트 신뢰(project trust) 설정도, 변경을 검토하는 것도 보안 경계를 만들지 않는다고. extension 은 Pi 프로세스와 같은 OS 권한으로 돌고, AGENTS.md·CLAUDE.md 같은 규칙 파일은 프로젝트를 신뢰하지 않겠다고 해도 읽힙니다. 남의 저장소를 열 때는 그 안의 지시문을 신뢰할 수 없는 입력으로 다루라고 문서가 직접 경고해요. 2026년 6월 8일에는 보안 권고 네 건이 한꺼번에 공개됐습니다. 공유 리눅스 호스트에서 예측 가능한 임시 설치 경로로 권한 상승이 가능했던 것(high), 프로젝트 안의 extension 을 승인 없이 로드했던 것(medium), auth.json 쓰기 경쟁 상태와 HTML 내보내기의 XSS(low). 지금은 고쳐졌지만, 하네스를 사용자 것으로 만든다는 건 이런 경계를 사용자가 직접 챙긴다는 뜻이기도 합니다.

Hacker News 의 반응도 갈립니다. Zechner 글을 다룬 2026년 2월 스레드에서 한 사용자는 Codex 는 OS 가 제공하는 샌드박스 안에서 명령을 돌리고 그게 에이전트를 쓸모없게 만들지 않는다며 “보안 연극” 이라는 주장을 반박했어요. Terminal-Bench 리더보드에서 Pi 가 더 이상 보이지 않는다는 지적도 있었습니다. 1편의 2025년 12월 표에서 Pi 는 Claude Opus 4.5 로 49.8%, 7위였는데, 지금 4.0 리더보드는 대부분 각 모델의 자사 하네스 결과라 비교할 줄이 없어요.

운영 쪽에서 알아 둘 것도 있습니다. README 에 따르면 새 기여자의 이슈와 PR 은 자동으로 닫힙니다. 설치 텔레메트리는 기본으로 켜져 있고(PI_TELEMETRY 로 끌 수 있습니다), Earendil 의 게이트웨이 Radius 로 로그인해 두면 /share 의 기본 저장소가 GitHub gist 에서 Radius 로 바뀝니다. 그리고 앞으로 Fair Source 와 독점 기능이 붙을 예정이에요. MIT 코어가 그대로라 해도, 회사가 소유한 오픈소스라는 사실은 지켜볼 대목입니다.

마지막으로 Claude Code 사용자에게 가장 현실적인 약점이 하나 있는데, 그건 기술이 아니라 요금 문제입니다. 2편에서 본 대로 2026년 4월부터 서드파티 하네스에 Claude 구독 계정으로 직접 로그인하면 구독 한도가 아니라 별도 과금이 붙어요. Pi 1.4.0 도 그렇게 로그인하면 그 사실을 경고로 띄웁니다. Claude Code 를 거쳐 Claude 를 부르는 우회로는 아직 구독 한도를 쓰지만, Anthropic 이 한 번 바꾸려다 보류해 둔 자리예요. 이게 실제로 어떤 선택지를 남기는지, 그리고 그 비용을 치를 만한 이득이 무엇인지가 Part 4 의 주제입니다.

자료에 대해#

Pi 의 기원과 설계 이유는 Zechner 의 2025년 11월·2026년 4월 블로그와 Earendil 의 공지문에 기댔고, 둘 다 당사자의 글입니다. 시스템 프롬프트 길이는 제가 설치한 1.4.0 의 소스로 기본 설정의 프롬프트를 조립해 센 것이라 도구 JSON 스키마는 빠져 있고, 토큰 수는 4자당 1토큰으로 어림한 값이에요. 사용자 수와 extension 수는 회사 발표이고, 다운로드 수는 사용자 수가 아닙니다. 첫 공개 시점은 npm 첫 배포(2025-11-12)와 CHANGELOG 의 “Initial public release”(0.10.0, 2025-11-25)가 갈려 npm 쪽을 따랐습니다. 엉클 밥에 관한 서술은 팟캐스트 요약(Alex Rusin), LinkedIn 글(Chris Rickard), swarm-forge 저장소처럼 제3자 정리와 저장소에 기댄 것이고, 그와 Pi 를 잇는 부분은 제 해석입니다. 보안 권고는 GitHub 의 저장소 권고 목록으로 확인했습니다.

편주제
Part 1하네스란 무엇인가
Part 2하네스 이전과 지금
Part 3 (이 글)Pi 라는 하네스
Part 4Pi 를 옆에 두기

References#

최신 자료 (2026)

비교·배경 자료 (2025)