Pi 1.0: 내 방식대로 조립하는 코딩 에이전트 하네스

코딩 에이전트를 쓰다 보면 기능이 많아서 편한 순간도 있지만 답답할 때도 있습니다. 계획 모드의 동작이 마음에 안 들 수 있어요. 권한 확인 창이 작업 흐름을 자꾸 끊거나 꼭 필요한 모델을 지원하지 않기도 하죠. 제품이 정해둔 방식에 내 작업을 끼워 맞추는 기분이 듭니다.

이런 불편을 직접 고쳐 쓰고 싶을 때 눈에 들어오는 도구가 Pi입니다. Pi는 스스로를 최소형 에이전트 하네스(minimal agent harness)라고 소개해요. 필요한 기능을 전부 내장하지 않고 작고 단단한 코어(core) 위에 확장(extension)과 스킬(skill)을 얹도록 설계됐습니다. 프롬프트 템플릿(prompt template)과 테마(theme)도 마음대로 바꿀 수 있고요.

처음 실행하면 다른 터미널 코딩 에이전트와 크게 달라 보이지 않습니다. 파일을 읽고 고치며 셸 명령을 실행하죠. 하지만 조금만 들여다보면 방향이 꽤 과감합니다. 내장 계획 모드(plan mode)도, 하위 에이전트(sub-agent)도, 권한 확인 창(permission prompt)도 없어요. 필요하면 직접 만들거나 패키지로 설치하라는 겁니다.

그런 Pi가 2026년 10월 1일 첫 안정 버전인 1.0을 내놓았습니다. 개발사 Earendil은 매주 수십만 명이 Pi를 쓴다고 밝혔는데요. 1.0에서 가장 눈에 띄는 변화는 그동안 거리를 두던 MCP를 코드모드(Codemode)라는 자기만의 방식으로 받아들였다는 점입니다.

기능을 일부러 뺀 도구가 왜 매력적일까요? 이번 글에서는 Pi 1.0을 기준으로 철학과 기본 사용법을 알아봅니다. 대화 이력 트리와 확장 시스템, 새로 내장된 MCP를 써보고 어디서 주의해야 하는지도 짚어볼게요.

Pi는 무엇인가

Pi를 이해하려면 먼저 코딩 에이전트의 작동 원리에서 말하는 언어 모델과 하네스를 분리해서 봐야 합니다. 언어 모델이 다음 행동을 판단하는 두뇌라면 하네스는 모델에 파일 도구와 셸을 연결하는 실행 환경입니다. 대화 이력과 컨텍스트(context)도 하네스가 관리하죠.

Claude Code나 Codex 같은 제품은 모델과 하네스뿐 아니라 계획부터 권한과 작업 관리 방식까지 하나의 완성된 경험으로 제공합니다. 빠르게 시작하기 좋지만 제품이 선택한 작업 흐름(workflow)에 영향을 많이 받습니다.

Pi는 다른 길을 택했어요. 기본 코어에는 파일 읽기와 쓰기, 부분 수정, 셸 실행이라는 네 가지 도구를 제공합니다. 여기에 모델 호출과 대화형 터미널 사용자 인터페이스(terminal user interface, TUI)를 붙였습니다. 세션(session)이나 대화 이력 관리처럼 에이전트 실행에 꼭 필요한 토대만 두고 나머지는 사용자가 조립합니다.

이런 설계는 Harness Engineering의 개인용 구현체에 가깝습니다. 좋은 에이전트를 고르는 데서 끝나지 않고 에이전트가 일하는 환경 자체를 코드와 설정으로 다루는 거죠. Pi의 구호인 “작업 흐름을 Pi에 맞추지 말고, Pi를 작업 흐름에 맞추라”가 방향을 잘 보여줍니다.

설치와 첫 대화

Pi는 npm 패키지로 배포되며 Node.js 22.19 이상이 필요합니다. Bun을 쓴다면 다음 명령으로 전역 설치(global install)할 수 있어요. --ignore-scripts는 의존성의 생명주기 스크립트(lifecycle script) 실행을 막는 옵션입니다. Pi는 일반적인 설치 과정에서 이 스크립트를 필요로 하지 않습니다.

$ bun add -g --ignore-scripts @earendil-works/pi-coding-agent

macOS나 Linux에서는 공식 설치 스크립트도 쓸 수 있습니다.

$ curl -fsSL https://pi.dev/install.sh | sh

Windows라면 PowerShell용 설치 스크립트가 따로 있습니다.

powershell -c "irm https://pi.dev/install.ps1 | iex"

설치가 끝나면 작업할 프로젝트로 이동해 pi를 실행합니다.

$ cd my-project
$ pi

1.0부터 Pi는 터미널 화면 전체를 쓰는 전체 화면 모드(fullscreen mode)로 열립니다. 마우스로 대화를 스크롤하고 선택한 텍스트를 바로 복사할 수 있죠. 터미널의 원래 스크롤 기록(scrollback)에 대화를 남기는 예전 방식이 익숙하다면 ~/.pi/agent/settings.json에서 tuiMode를 "regular"로 바꾸거나 실행할 때 --tui-mode regular를 넘기면 됩니다.

{
  "tuiMode": "regular"
}

처음에는 모델 제공자(provider)를 연결해야 하는데요. 대화창에서 /login을 입력하면 ChatGPT Plus나 Pro, Claude Pro나 Max, GitHub Copilot 같은 구독 계정으로 로그인할 수 있습니다. SSH로 접속한 서버처럼 브라우저가 다른 컴퓨터에 있을 때는 브라우저에 표시된 코드나 리디렉션된 주소를 Pi에 붙여 넣으면 됩니다. 다만 Claude 구독을 Pi 같은 서드파티 도구에서 쓸 때의 과금 정책은 올해 여러 번 바뀌었어요. 글을 고친 시점 기준으로 Anthropic은 서드파티 앱 사용량도 플랜 한도에서 차감한다고 안내합니다. 하지만 사용량 크레딧(usage credits)에서 차감할 권리를 남겨두고 있으니 쓰기 전에 Anthropic 도움말을 확인해 보세요.

API 키를 쓰고 싶다면 /login에서 입력하거나 환경 변수(environment variable)로 넘겨도 됩니다.

$ export ANTHROPIC_API_KEY="sk-ant-..."
$ pi

Pi의 장점은 특정 모델 회사에 묶이지 않는다는 데 있습니다. Anthropic과 OpenAI, Google을 비롯해 15개가 넘는 API와 클라우드 제공자를 지원해요. 로컬 모델(local model)도 쓸 수 있는데요. llama.cpp 라우터는 /llama 명령으로 바로 관리하고, Ollama나 LM Studio 같은 호환 서버는 ~/.pi/agent/models.json에 등록하면 됩니다. 대화 중 /model을 실행하거나 Ctrl+L을 누르면 모델을 바꿀 수 있어 모델마다 잘하는 일이 달라도 세션을 새로 열 필요가 없습니다.

기본 사용법

프로젝트에서 Pi를 실행한 뒤 평소 말하듯 요청하면 됩니다.

이 저장소의 구조를 요약하고 변경 후 실행해야 하는 검사를 알려줘.

Pi는 현재 디렉터리를 기준으로 파일을 읽습니다. 필요하면 코드를 고친 뒤 셸 명령까지 실행하죠. @를 입력하면 프로젝트 파일을 퍼지 검색(fuzzy search)해서 대화에 첨부할 수도 있어요.

$ pi @README.md "이 프로젝트의 개발 환경을 설명해줘"

에이전트가 일하는 도중에도 메시지를 보낼 수 있습니다. Enter로 보낸 메시지는 지금 진행 중인 응답과 도구 호출이 끝나면 바로 다음 응답의 방향을 바꾸는 조향(steering) 메시지가 됩니다. 반면 Alt+Enter로 보낸 후속 메시지(follow-up)는 현재 작업이 완전히 끝날 때까지 기다렸다가 전달돼요. 엉뚱한 파일을 고치기 시작했다면 Enter로 바로잡고, 끝나고 나서 시킬 일은 Alt+Enter로 쌓아두면 됩니다.

대화형 모드(interactive mode)에서 !로 시작하는 명령은 직접 실행되고 출력도 모델에 전달됩니다. 반면 !!는 명령만 실행하고 결과를 모델의 컨텍스트에는 넣지 않습니다. 빌드 출력이 너무 길거나 에이전트가 볼 필요가 없는 명령에 유용해요.

!bun run typecheck
!!git status --short

프로젝트 규칙은 AGENTS.md나 CLAUDE.md에 적어두면 됩니다. Pi는 사용자 홈의 ~/.pi/agent/AGENTS.md부터 현재 디렉터리와 상위 디렉터리의 컨텍스트 파일을 찾아 합칩니다. 테스트 명령과 코딩 규칙처럼 매번 설명하기 귀찮은 내용을 넣어두세요. 건드리면 안 되는 파일도 적어두면 좋고요.

# Project Instructions

- 코드 변경 후 `bun run typecheck`를 실행합니다.
- 프로덕션 마이그레이션은 로컬에서 실행하지 않습니다.
- 새 의존성을 추가하기 전에 이유를 설명합니다.

기본 시스템 프롬프트(system prompt) 자체가 마음에 들지 않으면 .pi/SYSTEM.md로 통째로 바꾸거나 .pi/APPEND_SYSTEM.md로 지시를 덧붙일 수 있습니다. 파일을 고친 뒤에는 /reload로 규칙과 확장 자원을 다시 불러오면 됩니다.

세션 트리

긴 코딩 작업에서 대화 이력은 단순한 채팅 로그가 아닙니다. 잘못된 접근을 버리고 이전 결정 지점으로 돌아갈 수 있어야 하죠. 두 해결책을 나란히 시험하고 싶을 때도 있습니다.

Pi는 세션을 트리 구조(tree structure)로 저장합니다. /tree를 실행하면 이전 메시지로 이동해 거기서 새 분기를 만들 수 있어요. 기존에 진행한 분기도 같은 줄 단위 JSON(JSON Lines, JSONL) 파일에 남기 때문에 한쪽을 선택했다고 다른 시도가 사라지지 않습니다.

예를 들어 인증 버그를 고치다가 쿠키 방식과 토큰 방식 두 가지가 모두 가능하다는 걸 알게 됐다고 해볼까요? 첫 번째 방식으로 진행한 뒤 /tree로 설계 결정을 내리기 전 메시지로 돌아가 두 번째 방식도 시험할 수 있습니다. 결과를 비교한 뒤 더 나은 분기를 이어가면 돼요.

아예 다른 세션 파일로 떼어내고 싶을 때는 /fork와 /clone을 씁니다. /fork는 이전 사용자 메시지 시점에서 새 세션을 만들고, /clone은 지금 보고 있는 분기를 통째로 새 세션에 복사합니다.

세션은 작업 디렉터리별로 ~/.pi/agent/sessions/에 자동 저장됩니다. 최근 작업을 바로 잇거나 이전 세션 목록에서 고를 수도 있습니다.

$ pi -c # 가장 최근 세션 계속하기
$ pi -r # 이전 세션 찾아서 열기

/session을 실행하면 현재 세션의 토큰 사용량과 비용을 모델별로 보여줍니다. 대화를 남기거나 공유하고 싶을 때는 /export로 HTML이나 JSONL 파일을 만들고, /share로 뷰어 링크를 받을 수 있어요.

대화가 모델의 컨텍스트 한도에 가까워지면 Pi가 오래된 내용을 자동으로 압축(compaction)합니다. 최근 작업은 남기고 앞부분을 구조화된 요약으로 바꾸는 방식이에요. 필요하면 /compact로 직접 실행할 수 있고, 확장을 통해 요약 방식 자체도 바꿀 수 있습니다.

빠진 기능으로 보는 Pi의 철학

Pi가 특별한 이유는 무엇을 넣었는가보다 무엇을 넣지 않았는가에서 선명해집니다. 공식 사이트는 내장하지 않은 기능을 꽤 솔직하게 밝히고 있어요.

여기에는 분명한 취향이 있습니다. 여러 해법이 가능한 기능을 코어에서 하나로 못 박지 않겠다는 거예요. 처음부터 모든 기능이 있어야 마음이 놓이는 사용자에게는 불친절하게 느껴질 수 있습니다. 반대로 내 도구와 보안 정책, 팀 규칙에 맞춰 하네스를 설계하고 싶다면 이런 빈 공간이 자유가 됩니다.

원래 이 표에는 MCP도 있었습니다. Pi는 잘 만든 CLI와 사용법을 담은 스킬이면 충분한 경우가 많다며 MCP를 코어에 넣지 않았거든요. 서버마다 도구 정의를 전부 컨텍스트에 밀어 넣고 결과를 긴 텍스트로 돌려주는 방식이 작은 하네스와 맞지 않는다고 봤습니다. 그런데 1.0에서는 이 칸이 사라졌습니다. 무작정 넣은 건 아니고, Earendil이 쓴 “You Said No MCP!”에 따르면 도구를 필요할 때만 불러오는 구조를 먼저 갖춘 뒤에야 받아들였다고 해요. 기능을 넣는 기준이 “유용한가”가 아니라 “늘어나는 복잡도만큼 값어치가 있는가”라는 점이 Pi답습니다.

MCP와 코드모드

1.0의 Pi는 표준 입출력(stdio)과 스트리머블 HTTP(streamable HTTP) 방식의 MCP 서버를 기본으로 지원합니다. 서버는 pi mcp add로 추가하고 pi mcp list로 연결 상태를 확인해요.

$ pi mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem .
$ pi mcp add docs --url https://example.com/mcp --bearer-token-env-var DOCS_TOKEN
$ pi mcp list

설정은 사용자 단위의 ~/.pi/agent/mcp.json과 프로젝트 단위의 .pi/mcp.json에 저장되며, 형식은 Claude Code나 Cursor의 mcpServers와 같습니다. 다른 클라이언트에서 쓰던 항목을 그대로 복사해 와도 돼요. Sentry처럼 OAuth를 쓰는 원격 서버는 /mcp에서 로그인하면 Pi가 토큰을 저장하고 갱신까지 맡습니다.

흥미로운 부분은 MCP 도구를 모델에 보여주는 방식인데요. 다른 에이전트처럼 모든 도구 정의를 시스템 프롬프트에 펼쳐 놓지 않습니다. 기본값은 코드모드로, 모델이 MCP 도구를 직접 호출하는 대신 그 도구들을 부르는 JavaScript 스크립트를 작성합니다. 스크립트는 QuickJS 격리 환경에서 실행되고 모델에는 스크립트의 최종 출력만 돌아가요.

예를 들어 “이번 주 커밋을 작성자별로 세어줘”라고 하면 모델은 이런 스크립트를 짤 수 있습니다.

const { output } = await tools.bash({
  command: "git log --since='1 week ago' --pretty=%an",
});

const counts = {};
for (const name of output.trim().split("\n")) {
  counts[name] = (counts[name] ?? 0) + 1;
}
return counts;

git log가 수천 줄을 쏟아내도 모델이 받는 건 작성자별 숫자 몇 개뿐입니다. 여러 도구를 Promise.all()로 한꺼번에 부르거나 MCP 서버가 돌려준 큰 JSON을 걸러서 넘길 수도 있죠. 컨텍스트를 아끼는 것은 물론, 모델이 도구를 한 번 부를 때마다 응답을 기다리는 왕복도 줄어듭니다.

코드모드에서 MCP 도구는 처음부터 목록에 올라가지 않습니다. 스크립트가 searchTools()나 describeTool()로 필요한 도구를 찾아 쓰는 지연 로딩(deferred tool loading) 방식이에요. 그래서 MCP 서버를 여러 개 연결해도 프롬프트가 거의 커지지 않습니다. 1.0에서는 코드모드 설명 자체도 다듬어서, 기본 도구에 코드모드를 켠 GPT-5.6 요청이 약 5,300토큰에서 3,300토큰으로 40% 가까이 줄었다고 합니다.

자주 쓰는 도구라면 서버별로 노출 방식을 바꿀 수 있습니다. exposure를 direct로 두면 일반 도구처럼 모델에 바로 선언되고, deferred는 tool_search 도구로 검색해서 불러오며, hidden은 아예 숨깁니다. toolExposure로 도구 단위의 예외도 지정할 수 있어요.

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "toolExposure": {
        "search_code": "direct",
        "delete_*": "hidden"
      }
    }
  }
}

코드모드는 MCP 없이도 쓸 수 있습니다. MCP 서버가 연결되면 자동으로 켜지지만, 항상 쓰고 싶다면 설정의 defaultTools에 "+codemode"를 추가하세요. 스크립트 안에서는 models.classify()로 분류 모델을 돌리거나 models.generateImages()로 이미지 생성 모델을 부를 수도 있어 언어 모델이 아닌 모델과도 함께 일할 수 있습니다.

{
  "defaultTools": ["+codemode"]
}

MCP 연동이 기본으로 들어왔다고 해서 확장으로 대체하는 길이 막힌 것은 아닙니다. /mcp 명령을 등록하는 확장을 설치하면 내장 MCP 지원을 통째로 바꿀 수 있고, 필요 없으면 설정에서 끌 수도 있어요. 내장 기능조차 갈아 끼울 수 있게 둔 점에서 Pi의 철학은 그대로입니다.

스킬과 확장

Pi의 사용자 정의 수단은 역할이 나뉘어 있습니다. 프롬프트 템플릿은 자주 쓰는 요청을 재사용하고 테마는 TUI 모양을 바꿉니다. Agent Skills는 특정 작업의 지침과 스크립트를 필요할 때만 불러옵니다. 자세한 참고자료도 스킬 안에 함께 둘 수 있어요.

TypeScript로 작성하는 확장은 손댈 수 있는 범위가 훨씬 넓습니다. 도구 호출 전후나 세션 시작 같은 생명주기 이벤트(lifecycle event)를 가로챌 수 있어요. 새 도구와 슬래시 명령을 등록하고 TUI까지 바꿉니다.

Pi에는 기본 권한 확인 창이 없는데요. 위험한 명령만 확인받고 싶다면 프로젝트의 .pi/extensions/에 다음과 같은 확장을 만들 수 있습니다.

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

export default function (pi: ExtensionAPI) {
  pi.on("tool_call", async (event, ctx) => {
    if (event.toolName === "bash" && event.input.command?.includes("rm -rf")) {
      if (!ctx.hasUI) {
        return { block: true, reason: "확인할 UI가 없어 차단했습니다." };
      }

      const allowed = await ctx.ui.confirm(
        "위험한 명령",
        "rm -rf 실행을 허용할까요?",
      );

      if (!allowed) {
        return {
          block: true,
          reason: "사용자가 명령 실행을 거부했습니다.",
        };
      }
    }
  });
}

ctx.hasUI 확인은 뒤에서 볼 출력 모드처럼 확인 창을 띄울 수 없는 환경을 위한 장치예요. 물어볼 수 없으면 기본으로 막아 둡니다. 저장하고 /reload를 실행하면 곧바로 적용됩니다. 완성된 기능을 따로 기다릴 필요 없이 하네스를 실행 중에 고쳐 쓰는 셈이죠.

tool_call 이벤트는 MCP 도구 호출과 코드모드 스크립트 안의 호출에도 똑같이 발생합니다. MCP 서버가 도구마다 선언한 readOnlyHint나 destructiveHint 같은 주석(annotation)도 pi.getAllTools()로 읽을 수 있어서, “읽기 전용이 아닌 도구만 확인받기” 같은 규칙을 몇 줄로 만들 수 있어요.

1.0에서는 확장으로 가상 모델(virtual model)도 등록할 수 있습니다. 사용자는 router/auto 같은 모델 하나를 고르고, 확장이 요청마다 실제 모델을 정하는 방식이에요. 계획은 Claude Opus에, 구현은 GPT 계열 모델에 맡기는 라우터를 직접 짤 수 있죠. 이렇게 라우팅된 비용은 /session에서 실제 모델별로 나눠 보여줍니다. 경로 보호와 Git 체크포인트부터 사용자 정의 도구와 장기 메모리까지 같은 방식으로 만들 수 있습니다. 상태줄도 예외가 아니고요.

여러 자원을 묶어 공유하려면 Pi 패키지를 사용합니다. 확장, 스킬, 프롬프트, 테마를 하나로 묶어 npm이나 Git 저장소에서 설치할 수 있어요.

$ pi install npm:@acme/pi-team-tools
$ pi install git:github.com/acme/pi-workflow

다만 Pi 패키지의 확장은 사용자 계정과 같은 시스템 권한으로 실행됩니다. 스킬도 에이전트에게 임의의 명령 실행을 지시할 수 있고요. 설치 전에 반드시 소스와 변경 이력을 확인해야 합니다.

대화형 터미널 밖의 Pi

Pi는 터미널에서 사람과 대화하는 용도에만 머물지 않습니다. 실행 방식은 네 가지입니다.

대화형 모드는 TUI에서 직접 작업할 때 씁니다. 출력 모드(print mode)는 pi -p로 한 번 요청하고 결과를 받는 자동화에 어울려요. JSON 모드는 이벤트를 구조화해 내보냅니다. 원격 프로시저 호출(remote procedure call, RPC) 모드는 표준 입출력의 JSONL 프로토콜로 다른 언어의 프로그램과 연결합니다.

마지막으로 소프트웨어 개발 키트(software development kit, SDK)를 이용하면 Pi의 에이전트 세션을 TypeScript 애플리케이션에 직접 넣을 수 있습니다.

import {
  createAgentSession,
  SessionManager,
} from "@earendil-works/pi-coding-agent";

const { session } = await createAgentSession({
  sessionManager: SessionManager.inMemory(),
});

try {
  await session.prompt("현재 디렉터리의 파일을 요약해줘.");
  console.log(session.getLastAssistantText());
} finally {
  session.dispose();
}

모델과 설정은 따로 넘기지 않아도 Pi CLI가 쓰는 기본값을 그대로 불러옵니다. 세션을 다 쓰고 나면 dispose()로 진행 중인 작업과 이벤트 리스너를 정리해 주세요. 다만 SDK 세션은 MCP와 코드모드 같은 내장 확장을 불러오지 않으니, MCP 서버가 필요하면 해당 확장을 직접 추가해야 합니다.

사내 개발 도구에 에이전트를 넣거나 자체 UI를 만들 때 유용합니다. CI 파이프라인에서 판단이 필요한 작업도 처리할 수 있어요. 터미널 제품과 SDK가 별개의 구현이 아니라 같은 하네스를 공유한다는 점도 눈에 띕니다.

Earendil은 1.0과 함께 실험 단계의 Pi Durable도 공개했습니다. 터미널 세션이 끝나도 이어지는 긴 대화와 작업을 여러 화면에서 이어받을 수 있게 하는 런타임인데요. Pi 코어를 작게 유지하려고 @earendil-works/pi-durable이라는 별도 패키지로 나왔습니다. 아직 실험 단계이니 관심이 있다면 공개 글부터 읽어보세요.

직접 설계하는 보안

Pi를 평가할 때 가장 주의 깊게 봐야 할 부분입니다. Pi에는 내장 격리 환경(sandbox)이 없습니다. Pi가 실행한 도구는 Pi를 시작한 사용자 계정의 권한으로 동작합니다. 프로젝트 신뢰(project trust) 기능은 로컬 설정과 확장을 불러올지 결정합니다. 프로젝트의 .pi/mcp.json과 패키지도 여기 포함되지만 파일이나 명령 접근을 격리해 주지는 않습니다.

코드모드가 격리 환경에서 돈다는 말에 오해하면 안 됩니다. QuickJS 격리 환경은 모델이 짠 스크립트가 파일 시스템이나 네트워크에 직접 손대지 못하게 막을 뿐이에요. 스크립트가 tools.bash()를 부르면 그 명령은 평소처럼 사용자 권한으로 실행됩니다.

출처를 모르는 저장소에서 곧바로 Pi를 실행하거나 검토하지 않은 확장을 설치하면 위험할 수 있습니다. 중요한 환경에서는 Docker 같은 컨테이너(container)나 별도의 격리 환경 안에서 실행해야 해요. 공식 문서는 일반 Docker와 Docker Sandboxes, OpenShell에서 Pi를 통째로 돌리는 방법을 안내합니다. Earendil의 경량 가상 머신인 Gondolin으로 기본 도구만 격리하는 예제 확장도 있고요. 어느 쪽이든 쓰기 권한이 필요한 경로만 연결하세요. 인증 정보와 운영 환경 접근 권한도 최소화하는 편이 좋습니다.

권한 확인 창이 없어서 편하다는 말은 아무 명령이나 믿고 실행해도 된다는 뜻이 아닙니다. Pi는 보안 정책도 작업 흐름의 일부로 직접 설계하라는 도구입니다. 앞서 만든 확인 확장은 실수를 줄여주지만 격리 환경을 대신하지는 못합니다.

Pi가 잘 맞는 개발자

Pi는 코딩 에이전트를 설치하자마자 모든 기능이 갖춰진 제품으로 쓰고 싶은 사람보다 자신의 작업 방식을 직접 설계하고 싶은 개발자에게 잘 맞습니다. 여러 모델을 오가며 비교하는 분이라면 특히 재미있을 거예요. TypeScript로 도구와 UI를 만들거나 팀의 스킬과 확장을 패키지로 공유하기도 좋습니다. MCP 서버를 여러 개 붙여 쓰면서 컨텍스트가 도구 정의로 가득 차는 게 불만이었다면 코드모드도 시험해 볼 만해요.

반면 내장 계획 모드와 세밀한 권한 승인을 원한다면 다른 제품이 더 편할 수 있습니다. 공식 IDE 통합처럼 정돈된 기본 경험이 중요한 경우도 마찬가지예요. Pi에서도 구현할 수 있지만 가능하다는 것과 처음부터 편하다는 것은 다른 이야기니까요.

결국 선택 기준은 기능 개수가 아닙니다. 제품이 정한 안전하고 완성된 길을 선호하는지, 작은 코어를 바탕으로 자신만의 하네스를 만들고 싶은지의 차이에 가깝습니다.

마치며

Pi는 “또 하나의 코딩 에이전트”라기보다 코딩 에이전트를 만드는 재료에 가깝습니다. 기본 도구와 세션 관리, 여러 모델 연결은 바로 쓸 수 있게 제공하면서도 계획 모드, 하위 에이전트, 권한 확인 같은 기능은 의도적으로 사용자의 선택에 맡깁니다.

1.0은 이 철학을 버리지 않으면서 안정 버전의 무게를 더했습니다. MCP를 받아들이되 코드모드와 지연 로딩으로 작은 하네스에 맞게 길들였고, 그마저도 확장으로 바꿀 수 있게 남겨뒀죠. 기존 제품의 작업 흐름이 답답했다면 작은 프로젝트에서 Pi를 한번 실행해보세요. 먼저 기본 기능만 써보다가 반복해서 아쉬운 지점이 생길 때 확장이나 스킬을 하나씩 더해보면 됩니다.

설치 옵션과 최신 제공자 목록은 Pi 공식 문서에서 확인할 수 있습니다. 1.0의 전체 변경 사항은 릴리스 노트에, 확장을 만들 때 사용할 수 있는 이벤트와 API는 확장 문서에 정리돼 있어요.