Pi 1.0, Claude Code·Codex 대신 쓸 이유가 있을까?

Claude Code나 Codex로 코드를 고치고 테스트까지 돌리고 있다면, 새 코딩 도구가 나왔다는 소식만으로 옮길 이유는 약합니다. 필요한 것은 도구 하나를 더 배우는 일이 아니라 지금 막힌 일을 풀어 주는 차이입니다.

10월 1일 공개된 Pi 1.0은 여러 모델과 도구를 자신의 작업 방식에 맞게 조합할 수 있는 에이전트 하네스입니다. 하네스는 모델에게 자료를 전달하고, 모델이 고른 도구를 실행하며, 작업 기록을 이어 주는 바깥 프로그램을 말합니다. Earendil의 출시 발표는 작은 핵심과 확장 가능성을 강조합니다.

저는 Pi를 ‘다른 도구보다 코드를 더 잘 쓰는 AI’로 보기보다 이미 좋은 AI를 우리 팀의 방식으로 움직이고 싶을 때 검토할 작업 환경으로 보는 편이 맞다고 생각합니다. 이 차이를 작은 서비스 팀의 릴리스 보고서로 따라가 보겠습니다. 이번에 고친 오류와 아직 남은 문제를 모으는 일에서도, 좋은 문장을 쓰는 능력과 일을 끝내는 구조는 갈립니다.

Pi는 모델을 얹어 쓰는 작업 환경입니다

Pi에 “이번 릴리스 후보를 정리해 주세요”라고 요청하면, 연결한 모델이 어떤 자료를 읽을지 판단합니다. Pi는 도구 호출을 실행하고 그 결과를 다시 모델에 전달합니다. 이슈 조회 도구는 실제 업무 시스템에서 항목을 가져오고, 파일 도구는 보고서를 저장합니다. 공식 작동 설명은 모델 요청, 도구 실행, 문맥 구성, 세션 저장을 Pi의 역할로 구분합니다.

비유하면 모델은 작업자, Pi는 바꿔 끼울 수 있는 작업대, 도구는 드라이버와 측정기에 가깝습니다. 작업대에 좋은 드라이버를 달아도 작업자가 설계도를 잘못 읽으면 결과는 틀릴 수 있습니다. 반대로 유능한 작업자에게도 부품과 측정 결과가 도착할 길은 필요합니다.

크게 보기

×확대 이미지 닫기

Pi는 터미널에서 사용하는 앱으로 시작할 수 있고, 개발자는 그 기반을 다른 프로그램 안에 넣을 수도 있습니다. 공식 저장소는 코딩 에이전트, 실행 런타임, 여러 공급자를 연결하는 모델 API를 별도 패키지로 제공합니다. Pi를 이용하려고 처음부터 이 패키지들을 모두 공부할 필요는 없습니다.

하네스라는 말이 아직 추상적이라면 하네스 엔지니어링에서 AI 코딩의 기준을 세우는 방법을 함께 읽으면 좋습니다. Pi는 그런 실행 환경을 직접 바꿀 수 있게 만든 구체적인 선택지입니다.

Pi 1.0에서 달라진 것

1.0의 핵심 변화는 CodeMode, MCP 기본 지원, 도구 지연 로딩, 가상 모델 확장입니다. 여러 모델을 연결하는 기능 자체가 이번에 처음 생긴 것은 아닙니다. 그 위에서 도구를 더 유연하게 조합하고, 필요한 도구 설명을 늦게 불러오며, 요청마다 사용할 모델을 고르는 방법이 추가됐습니다. 공식 발표의 변경 목록에는 대화 중 시스템 메시지 변경과 일부 모델의 캐시 유지, 터미널 화면 개선도 포함됩니다.

MCP는 업무 시스템과 AI 도구를 연결하는 공통 규격입니다. 이전의 Pi 소개를 읽었다면 “MCP를 기본으로 넣지 않는다”는 설명이 기억날 수 있습니다. 개발팀은 설계 변경을 설명한 글에서 도구들을 코드로 조합하는 방식과 함께 MCP를 핵심에 포함했다고 설명합니다. 오래된 장단점 목록을 그대로 적용하면 현재 제품을 다르게 이해할 수 있습니다.

기능이 늘었다고 전부 켜야 하는 것은 아닙니다. 파일 몇 개를 고치는 작업에는 기존의 읽기·편집·명령 실행만으로도 충분할 수 있습니다. 새 기능의 가치는 연결할 서비스나 반복되는 작업이 있을 때 드러납니다.

CodeMode는 도구 사이의 왕복을 줄이는 방식입니다

서비스 팀이 이슈 수십 건과 코드 변경 기록을 확인한다고 가정해 보겠습니다. 이슈 하나를 읽고 모델에 보여 주고, 다음 이슈를 읽고 다시 보여 주는 식으로만 진행하면 중간 결과가 계속 대화에 쌓입니다. 정작 필요한 것은 모든 원문보다 ‘이번 배포에 들어간 수정과 아직 검증되지 않은 항목’일 수 있습니다.

CodeMode에서는 모델이 스크립트를 작성해 서로 독립적인 조회를 병렬로 실행하고, 필요한 항목을 고르고, 결과를 묶어 반환할 수 있습니다. CodeMode 문서가 설명하는 핵심은 스크립트 내부의 모든 중간값 대신 출력으로 선택한 내용이 모델에 전달된다는 점입니다. 모델이 다음 행동을 고민할 때 읽는 자료를 줄일 여지가 생깁니다.

크게 보기

×확대 이미지 닫기

여기서 ‘코드로 묶는다’는 것이 ‘조회료도 없어지고 언제나 더 빠르다’는 뜻은 아닙니다. 각 서비스의 호출은 여전히 발생하고, 잘못 작성한 스크립트는 수정해야 합니다. 적은 자료를 한 번 읽는 일이라면 스크립트를 준비하는 과정이 더 번거로울 수도 있습니다. CodeMode는 다른 도구에서도 쓰이는 접근이므로 이것만으로 Pi의 독점적인 우위를 말하기도 어렵습니다.

도구 지연 로딩은 다른 문제를 다룹니다. CodeMode가 결과를 어떻게 가공할지에 관한 기능이라면, 지연 로딩은 도구의 설명을 언제 모델에게 보여 줄지에 관한 기능입니다. MCP 문서는 직접 노출, 검색 뒤 노출, CodeMode를 통한 호출 등을 구분합니다. 연결한 도구가 많을 때 유용하지만, 도구 설명이 부정확하면 필요한 도구를 찾지 못할 수 있습니다.

보고서 사례에서는 이슈 본문을 짧게 만드는 것만 목표로 삼으면 안 됩니다. ‘수정 완료’라는 댓글만 남기고 ‘아직 배포 전’이라는 상태를 걸러 버리면 짧고 틀린 보고서를 얻게 됩니다. 줄여도 되는 정보와 남겨야 할 근거를 먼저 정해야 이 구조의 이익을 볼 수 있습니다.

좋은 요청문이 보고서의 기준을 만듭니다

“이번 주 수정 내용을 알아서 정리해 주세요”에는 완료의 뜻이 빠져 있습니다. 코드가 합쳐졌다는 것인지, 테스트가 통과했다는 것인지, 실제 사용자에게 배포됐다는 것인지 모델이 임의로 채울 수 있습니다. Pi로 옮겨도 이 문제가 저절로 해결되지는 않습니다.

보고서의 범위를 먼저 정한 뒤 다음처럼 요청할 수 있습니다. 이슈 조회 연결과 읽기 권한, 비교할 코드 변경 범위가 준비됐다는 가정의 예시입니다.

지정한 릴리스 후보의 이슈와 코드 변경 기록으로 검토용 보고서를 만들어 주세요.

1. 먼저 조회할 프로젝트, 버전, 코드 변경 범위를 확인해 주세요.
   정해지지 않은 범위는 임의로 채우지 말고 질문해 주세요.
2. 항목을 '수정과 검증 근거가 있음', '수정됐지만 검증 미확인',
   '이번 배포에서 제외'로 나눠 주세요.
3. 각 항목에 이슈 ID, 변경 근거, 검증 결과의 위치를 남겨 주세요.
   찾지 못한 근거는 '미확인'으로 적어 주세요.
4. 조회 실패나 누락 가능성이 있으면 본문과 별도로 모아 주세요.
5. 검토용 로컬 보고서만 작성해 주세요.
   이슈 상태 변경, 외부 댓글 등록, 배포는 하지 마세요.

기대하는 산출물은 매끄러운 한 페이지 요약만이 아닙니다. 담당자가 “이 항목은 왜 완료로 분류됐지?”라고 물었을 때 원래 이슈와 검증 기록으로 돌아갈 수 있어야 합니다. 실패한 조회를 빈 결과로 취급하지 않는지도 확인해야 합니다.

만약 검증 결과를 찾지 못한 항목까지 ‘완료’로 들어갔다면 “더 정확하게 해 주세요”보다 기준을 고쳐야 합니다. **“검증 결과 링크가 없는 항목은 모두 검증 미확인으로 옮기고, 분류가 바뀐 이유를 적어 주세요”**처럼 오류를 확인 가능한 규칙으로 바꿉니다. 이 규칙이 매번 반복되면 확장 기능으로 옮길 후보가 됩니다.

반복되는 규칙이 생기면 확장이 의미를 갖습니다

팀에서 매주 같은 보고서를 만든다면 매번 긴 요청문을 붙이는 대신 재사용할 수 있습니다. 단순한 작성 지침은 프롬프트나 스킬로, 실제 도구와 명령·이벤트 처리가 필요하면 확장으로 구분하는 편이 좋습니다. Pi의 확장 문서는 TypeScript 모듈로 도구, 명령, 실행 중 처리, 화면 요소 등을 추가하는 방식을 제공합니다.

예를 들어 팀의 완료 상태를 해석하고 필수 근거가 빠진 항목을 분리하는 전용 도구를 만들 수 있습니다. 이때 “Pi에게 알아서 확장해 달라”고 요청할 수 있다는 편의와 확장의 품질은 별개입니다. 읽어야 할 필드를 빠뜨리지 않는지, 오류를 숨기지 않는지, 변경 가능한 범위가 맞는지 검토할 코드가 생깁니다.

가상 모델도 같은 관점으로 볼 수 있습니다. 이름은 새 모델처럼 들리지만 실제로는 요청을 어느 모델에 보낼지 고르는 규칙입니다. Pi의 가상 모델 문서는 작업·비용·대화 상태에 따른 선택을 지원합니다. 이슈 제목 정리와 까다로운 변경 위험 검토에 서로 다른 모델을 배정하는 식의 설계가 가능합니다.

다만 ‘싼 모델을 섞으면 무조건 절약된다’는 계산은 이릅니다. 선택 자체에 분류 모델을 쓰면 호출과 대기가 더해지고, 모델을 바꾸면 프롬프트 캐시를 잃을 수 있습니다. 두 모델을 오가느라 같은 작업을 다시 설명하거나 결과를 수정한다면 예상했던 이익이 줄어듭니다. 먼저 한 모델로 충분히 안정적으로 끝나는지 확인한 뒤 분리할 단계가 있는지 보는 편이 합리적입니다.

저라면 보고서 양식만 다른 정도에서는 확장을 만들지 않겠습니다. 여러 프로젝트가 같은 규칙을 반복하고, 그 규칙을 사람이 계속 보정하는 상황부터 보겠습니다. 새로운 도구가 주는 자유는 유지해야 할 코드가 늘어나는 비용과 함께 평가해야 합니다.

Claude Code·Codex로도 같은 일을 할 수 있지 않을까요?

릴리스 보고서를 만드는 것 자체는 Pi만의 기능이 아닙니다. 터미널이나 로컬 개발 환경에서 같은 이슈 묶음, 코드 변경 범위, 완료 기준을 주고 비교해야 합니다. 원하는 결과도 같습니다. 근거가 있는 수정과 검증 미확인 항목을 구분하고, 원래 기록으로 돌아갈 링크를 남긴 보고서입니다.

Claude Code를 이미 쓴다면 보고서 규칙을 스킬에 넣고 이슈 조회를 MCP로 연결할 수 있습니다. 공식 플러그인 설명은 스킬·하위 에이전트·훅·MCP를 묶어 팀에 배포하는 방식과 JavaScript로 동작·화면을 바꾸는 mod도 안내합니다. 훅은 특정 작업 전후에 정해진 처리를 실행하는 장치입니다. 따라서 ‘기존 도구는 못 고치고 Pi만 확장할 수 있다’는 구분은 맞지 않습니다.

Codex에서도 스킬로 보고서 순서와 누락 처리 규칙을 재사용하고, MCP 연결에서 사용할 도구를 제한할 수 있습니다. 로컬 파일과 명령의 접근 범위를 정하는 권한 설정도 제공합니다. 다만 로컬 실행 제한과 외부 MCP의 권한은 별도이므로, 보고서용 계정에 이슈 쓰기 권한이 있는지는 따로 확인해야 합니다.

최적화 기능도 겹칩니다. Claude Code는 지원되는 환경에서 MCP 도구 설명을 필요할 때 불러오는 검색을 제공하며, opusplan으로 계획에는 Opus, 실행에는 Sonnet을 쓰는 구성도 지원합니다. Codex에도 사용자 지정 모델 공급자 설정이 있습니다. 현재 문서의 지원 통신 방식은 Responses이므로 어떤 모델 API든 주소만 넣으면 된다는 뜻은 아닙니다. 지연 로딩이나 모델 변경이 있다는 사실만으로 Pi로 옮길 이유가 되지는 않습니다.

Pi를 구체적으로 검토할 상황은 “이슈 정리는 한 공급자의 모델, 변경 위험 검토는 다른 모델로 보내되, 팀이 정한 규칙으로 요청마다 선택하고 싶다”처럼 요구가 더 분명해질 때입니다. Pi는 여러 공급자·로컬 모델 연결과 확장으로 작성하는 가상 모델을 이 조합의 재료로 제공합니다. 이 방식이 우리 팀의 기존 설정보다 다루기 쉬운지 확인할 가치가 있다는 뜻이지, 다른 도구로는 구현할 수 없다는 뜻은 아닙니다.

반대로 세 도구 모두 검증 기록이 없는 이슈를 완료로 분류한다면, 바꿔야 할 것은 먼저 완료 기준과 근거 검사입니다. 기준을 고친 뒤에도 수작업으로 자료를 옮기거나 모델을 바꾸는 단계가 계속 남을 때 도구 구성을 비교하면 됩니다. 저는 보고서의 정확성과 누락을 고치는 수고가 비슷하다면, 이미 관리할 줄 아는 도구를 유지하는 쪽이 낫다고 봅니다. 새 도구가 늘리는 설정과 검토 부담까지 줄어야 이동할 이유가 생깁니다.

오픈소스여도 모델 사용료는 별도입니다

Pi는 MIT 라이선스로 공개된 소프트웨어입니다. 프로그램을 설치할 수 있다는 사실과 연결한 모델을 무료로 호출할 수 있다는 사실은 다릅니다. Pi의 모델 연결 문서는 지원되는 구독 로그인, API 키, 로컬 모델과 호환 엔드포인트를 구분합니다. 어떤 구독이든 그대로 연결된다고 생각해서는 안 되며, 사용하려는 공급자의 지원 방식과 이용 조건을 확인해야 합니다.

API 키를 쓰면 공급자의 과금이 적용됩니다. 로컬 모델을 쓰면 외부 API 비용 대신 실행할 장비와 관리 부담을 고려해야 합니다. 구독으로 연결하는 경우에도 사용량 한도와 허용되는 이용 방식은 해당 서비스의 조건을 따릅니다. 실제 연결 수단은 공급자 문서에서 확인할 수 있습니다.

이 글의 보고서 작업을 비교한다면 요금표의 입력 단가 하나보다 검토를 통과한 보고서 한 건을 만드는 전체 비용이 중요합니다. 모델 호출, 재시도, 연결 서비스의 요금, 사람이 누락을 고치는 시간을 함께 봐야 합니다. 사용료가 조금 줄어도 매주 확장을 수리해야 한다면 팀 전체의 비용은 늘어날 수 있습니다.

처음 시험할 때는 같은 이슈 묶음과 같은 완료 기준을 준비하는 것이 좋습니다. 기존 도구와 Pi에서 누락한 항목, 잘못 분류한 항목, 근거를 다시 찾는 데 든 수고를 비교합니다. 가능한 경우 같은 모델과 비슷한 설정을 사용해야 모델 교체의 효과를 작업 환경의 효과로 오해하지 않습니다.

CodeMode의 격리가 PC 전체를 보호하지는 않습니다

Pi를 평가할 때는 확장성과 함께 실제로 접근할 수 있는 파일과 서비스를 봐야 합니다. 공식 보안 문서는 Pi의 도구와 확장이 실행한 계정의 권한을 사용하고, 모든 도구 호출마다 승인을 받는 방식은 아니라고 설명합니다. 작업 폴더를 하나 지정했다고 다른 접근 가능한 폴더까지 자동으로 차단되는 것도 아닙니다.

CodeMode의 JavaScript 실행 환경에는 파일 시스템이나 네트워크를 직접 사용하는 기능이 없지만, 스크립트가 호출하는 도구는 실제 작업을 수행합니다. 또 CodeMode 문서는 스크립트가 중간에 실패해도 이미 실행된 도구의 효과를 되돌리지 않는다고 명시합니다. ‘샌드박스 안에서 실행한다’는 한 문장만 보고 외부 변경까지 취소된다고 기대하면 안 됩니다.

릴리스 보고서에는 읽기 전용 이슈 권한과 필요한 파일만 주는 구성이 맞습니다. 보고서를 만드는 데 운영 배포 자격 증명이나 이슈 삭제 권한까지 줄 이유는 없습니다. 신뢰하기 어려운 저장소나 확장을 다룬다면 Pi 전체를 제한된 실행 환경에 두는 방법도 검토해야 합니다. 확장은 Pi 프로세스 안에서 실행되므로 설치한 확장의 출처와 코드를 확인하는 책임도 생깁니다.

요청문에 “외부 상태를 바꾸지 마세요”라고 적는 것은 작업 지시입니다. 실제 쓰기 권한을 제거하는 것과는 역할이 다릅니다. 연결과 접근 범위를 더 알고 싶다면 MCP의 도구 연결과 권한 관리에서 이 구분을 이어 볼 수 있습니다.

오래 실행하는 앱에는 Pi Durable이라는 별도 선택지가 있습니다

매주 담당자가 Pi를 열어 보고서를 만드는 일과, 서버에서 계속 돌아가며 여러 사람의 요청을 처리하는 앱은 요구가 다릅니다. 후자에는 프로세스가 종료된 뒤의 재개, 대기 중인 작업의 보존, 여러 대화의 관리가 필요할 수 있습니다.

함께 발표된 Pi Durable은 이 방향의 별도 실험 패키지입니다. 기존 Pi 코딩 에이전트를 대체하는 제품으로 소개되지 않았으며, API가 달라질 수 있다고 안내합니다. 중단된 작업을 저장된 상태에서 이어 가고, 안전하게 다시 실행할 수 있다고 지정한 도구를 재시도하는 구조를 다룹니다.

그러나 보고서를 다시 만드는 것과 외부 시스템에 같은 보고서를 두 번 게시하는 것은 다른 문제입니다. 재시작을 지원하는 실행기라도 외부 변경의 중복 여부, 확인이 필요한 시점, 복구 규칙은 앱에서 설계해야 합니다. Pi 1.0을 설치하면 이런 장기 실행 서비스가 모두 갖춰진다고 이해해서는 안 됩니다.

이 단계가 필요하다면 루프·그래프 엔지니어링에서 반복과 상태를 나누는 기준을 함께 검토할 만합니다. 일반적인 코딩 도구를 고르는 일과 계속 운영할 에이전트 앱을 설계하는 일은 분리해서 판단하는 편이 좋습니다.

어떤 프로젝트라면 옮길 만할까요

작은 웹사이트의 화면을 고치고 테스트하는 일이 중심이고 지금 쓰는 Claude Code·Codex가 충분하다면, Pi 1.0이 나왔다는 이유만으로 옮길 필요는 없습니다. 이번 주 보고서도 자료가 적고 한 번으로 끝난다면 기존 도구에 기준을 보완하는 쪽이 먼저입니다.

반면 여러 서비스의 자료를 반복해서 연결하거나, 팀 규칙을 재사용 가능한 도구로 만들거나, 모델 공급자를 바꿔 가며 같은 작업 환경을 유지하려는 경우라면 Pi를 시험할 이유가 생깁니다. 핵심은 거대한 프로젝트인지보다 지금 쓰는 도구 바깥에서 매번 사람이 해 주는 일이 무엇인지입니다.

또 하나의 후보는 일반 스크립트입니다. 입력과 처리 순서가 매번 같고, 판단 기준을 코드로 정확히 표현할 수 있다면 모델에게 매번 실행 순서를 맡길 이유가 약합니다. 정해진 조회·집계는 스크립트가 하고, 설명문이 필요한 부분만 모델에 맡기는 구성이 더 단순할 수 있습니다.

저라면 기존 작업 하나를 골라 Pi에서 작게 비교하겠습니다. 릴리스 보고서라면 완료 분류와 근거 보존이 더 안정적인지, 사람이 중간에서 자료를 옮기는 일이 줄었는지, 그 대신 유지할 설정과 확장이 얼마나 늘었는지를 보겠습니다. 코드를 수정하는 작업으로 넓힐 때는 변경을 작게 나누고 PR을 검토하는 기준도 그대로 필요합니다.

Pi를 선택할 이유는 새 이름의 AI를 하나 더 갖는 데 있지 않습니다. 좋은 모델을 사용하는 방식까지 바꿔야 풀리는 문제가 있을 때, 그 작업 환경을 직접 조립할 수 있다는 점에 있습니다. 지금 도구가 이미 문제를 풀어 준다면 그대로 쓰고, 매번 우회하던 연결과 규칙이 있다면 그 한 가지부터 비교하는 것이 합리적입니다.