러스트로 다시 만든 로컬 코딩 에이전트 ‘파이’, 자동화까지 노린다

코딩 에이전트인데, 목표가 채팅 UI는 아님

• 파이는 기존 pi 코딩 에이전트를 러스트로 다시 만든 터미널 기반 AI 코딩 에이전트임

  • 프로젝트 디렉터리 안에서 실행하고, 파일을 읽고 수정하고, 셸 명령을 돌리고, 이전 세션을 이어갈 수 있음
  • 작성자는 원래 로컬 DS v4 모델로 장기 자동화 작업을 돌리려다가 커스터마이즈 가능한 에이전트 런타임이 필요했다고 설명함
  • 코드 대부분은 AI가 작성했다고 솔직하게 밝힘. AI 생성 코드에 민감하면 그냥 넘기라고까지 말함

• 이 프로젝트가 노리는 건 “코딩 챗봇 하나 더”가 아니라 로컬 개발 워크플로 런타임임

  • 슬래시 명령, 세션 히스토리, 스킬, MCP 도구, 크론, 트리거를 묶으려는 방향임
  • 서로 다른 머신에서 도는 에이전트끼리 메시지를 보낼 수 있는 작은 허브도 포함됨
  • 로컬 프로젝트 디렉터리에서 상태를 갖고 오래 살아있는 에이전트를 만들려는 느낌이 강함

모델과 세션은 로컬 우선으로 설계됨

• 파이는 사용 가능한 모델 제공자 자격 증명을 자동으로 감지함

  • API 키를 환경에 설정하거나, 파이 내부에서 제공자별 키를 저장할 수 있음
  • 로컬 오픈AI 호환 서버도 모델 정의 파일로 붙일 수 있음
  • 사용자 전역 설정은 ~/.pie/models.json, 프로젝트별 설정은 <project>/.pie/models.json에 둘 수 있고 프로젝트 설정이 우선함

• 로컬 DeepSeek V4 Flash 서버 같은 구성도 염두에 둠

  • Responses 엔드포인트를 Codex 스타일 클라이언트에 선호한다고 설명함
  • 단순 통합에는 chat completions도 동작한다고 함
  • DS4 같은 로컬 제공자는 placeholder bearer token을 쓸 수 있고, 실제 OpenAI API 키와 분리된 제공자 이름으로 관리할 수 있음

• 세션 상태는 프로젝트 단위로 남김

  • 세션 히스토리는 ~/.pie/sessions/<cwd-hash>/<uuidv7>.jsonl 아래 저장됨
  • 메모리, 인증 키, 모델 정의, MCP 설정, 트리거, 크론 설정도 ~/.pie 아래에 정리됨
  • PIE_DIR로 기본 상태 디렉터리를 바꿀 수 있음

슬래시 명령이 꽤 넓게 깔려 있음

• REPL 안에서는 세션 제어용 명령들이 제공됨

  • /help, /model, /thinking, /sessions, /save, /compact, /undo, /cost 같은 기본 명령이 있음
  • /login, /logout으로 제공자별 API 키를 저장하거나 제거할 수 있음
  • 컨텍스트가 길어지면 /compact로 압축하고, 최근 턴은 /undo로 제거할 수 있음

• 자동화 명령도 별도 영역으로 들어가 있음

  • /triggers 계열로 트리거 규칙을 보고, 켜고, 끄고, 제거할 수 있음
  • /cron add "<minute hour dom month dow>" <prompt> 형식으로 로컬 스케줄 작업을 만들 수 있음
  • /hub 계열 명령으로 공개 허브 상태 확인, 로그인, 메시지 전송, 받은 알림 조회를 처리함

• 코딩 도구도 일반적인 에이전트 도구 세트를 갖춤

  • 파일 읽기, 쓰기, 편집
  • 파일 목록과 검색
  • 셸 명령 실행
  • 영속 메모리 관리
  • 하위 작업 위임
  • 이미지 첨부, 세션 재개, 훅 실행까지 포함됨

트리거와 크론이 핵심 차별점임

• 트리거는 자연어로 자동화 조건을 설명하면 동적 규칙으로 바뀌는 구조임

  • 규칙은 활성 세션 옆에 저장돼서 새 세션은 깨끗하게 시작함
  • --resume으로 세션을 재개하면 해당 세션의 규칙도 돌아옴
  • 동적 트리거는 기본적으로 한 번만 실행되고, 반복 실행을 원하면 그렇게 요청해야 함

• 트리거 액션은 별도 하위 에이전트에서 실행됨

  • 부모 모델, 도구, 훅, 추론 수준, 스킬 목록은 상속함
  • 대신 부모 대화 전체를 기본으로 넘기지는 않음
  • 결과는 TUI에 표시되고 트리거 감사 기록에 저장됨
  • 사용자가 미래 대화에서도 결과가 보이길 원하면 promote_to_chat=true로 성공 결과를 메인 채팅 컨텍스트에 넣음

• 로컬 동적 체크는 기본 10분마다 폴링함

  • 활성화된 동적 규칙이 하나 이상 있을 때만 체크를 방출함
  • ~/.pie/config.toml에서 간격을 바꿀 수 있음
  • 단일 실행에서는 --trigger-poll-secs 60처럼 오버라이드 가능함

• 크론은 트리거와 별도인 시간 기반 자동화임

  • 표준 5필드 크론 표현식을 지원하고 로컬 시간을 기준으로 동작함
  • 작업이 실행될 시간이 되면 일반 프롬프트, 트리거 액션과 같은 직렬 에이전트 턴 큐에 들어감
  • 다운타임 동안 놓친 tick은 백필하지 않음
  • 이전 작업이 아직 실행 중이면 다음 tick은 건너뛰고 상태에 기록함

MCP 알림과 허브는 프라이버시 경계를 꽤 보수적으로 잡음

• MCP 서버의 푸시 알림도 트리거 소스로 취급함

  • 파이는 MCP 서버가 제공하는 서버 푸시 스트림을 NotificationHook으로 소비함
  • 알림은 제한된 트리거 envelope로 변환되고, 중복 제거, 감사, 프롬프트, 액션 큐 흐름을 같이 탐
  • 도구, 리소스, 프롬프트 목록 변경 같은 내장 MCP 알림은 안정적인 replacement key로 최신 이벤트만 남김

• 커스텀 알림은 dedup key 없으면 드롭됨

  • notifications/* 이벤트는 _meta.pie_dedup_key 또는 _pie_dedup_key가 필요함
  • 없으면 어댑터에서 버리고 hook 상태에 카운트만 남김
  • 자동화 시스템에서 중복 이벤트 폭주를 막으려는 설계로 보임

• 알림 프라이버시 정책은 꽤 제한적임

  • 원본 MCP 알림 params를 채팅 컨텐츠나 트리거 감사 로그에 그대로 저장하지 않음
  • 알 수 없는 커스텀 알림은 제한된 method 스타일 요약만 저장함
  • 서버가 _meta.pie_summary를 제공하면 길이 제한과 redaction을 거친 뒤 표시하거나 기록함

• 공개 허브는 에이전트끼리 짧은 알림 요약을 주고받는 용도임

  • pie.0xfefe.me 허브에 한 번 가입하면 토큰이 예약된 credential key에 저장됨
  • /hub send는 bounded summary만 보내고, 전체 payload는 로컬에 남김
  • 다른 에이전트는 알림 요약만 받고, transcript, 파일, 도구 출력, provider credential은 받지 않음
  • 첫 연락을 보낸 상대는 한 번 허용, 신뢰, 차단, 건너뛰기 중 선택할 수 있음

sequenceDiagram
    participant 사용자
    participant 파이
    participant 트리거런타임
    participant 하위에이전트
    participant MCP서버

    사용자->>파이: 자연어로 자동화 요청
    파이->>트리거런타임: 동적 트리거 규칙 생성
    MCP서버->>트리거런타임: 푸시 알림 전달
    트리거런타임->>트리거런타임: 중복 제거와 요약 처리
    트리거런타임->>하위에이전트: 조건 일치 시 작업 실행
    하위에이전트->>파이: 결과와 감사 기록 반환

기술 맥락

• 파이가 고른 핵심 방향은 코딩 에이전트를 단발성 대화 도구가 아니라 로컬 런타임으로 보는 거예요. 파일 편집만 잘하는 도구라면 이미 많지만, 장기 작업을 세션으로 저장하고 트리거와 크론으로 다시 깨우는 구조는 개발 자동화에 더 가깝거든요.

• 트리거 액션을 하위 에이전트에서 실행하는 이유도 이해돼요. 부모 대화 전체를 넘기지 않으면 컨텍스트 오염과 민감 정보 노출을 줄일 수 있고, 그래도 모델과 도구 설정은 상속하니 작업 환경은 유지돼요.

• MCP 알림을 같은 트리거 런타임으로 흘려보내는 설계는 꽤 실용적이에요. 로컬 체크, 서버 푸시, 허브 알림을 각각 따로 처리하면 자동화 경로가 복잡해지는데, 파이는 중복 제거와 감사 기록, 액션 큐를 한 번에 태우려는 쪽이에요.

• 크론에서 놓친 tick을 백필하지 않는 결정도 중요해요. 에이전트 작업은 일반 배치 작업보다 오래 걸리고 비용도 생길 수 있어서, 다운타임 뒤에 밀린 작업을 전부 실행하면 예상 못 한 폭주가 생길 수 있거든요.

• 허브 메시징에서 전체 payload 대신 요약만 보내는 것도 같은 맥락이에요. 에이전트끼리 협업은 시키되, 로컬 파일과 세션, API 키는 밖으로 나가지 않게 경계를 먼저 긋는 설계예요.