pi-multi-agent-skill: 토큰 낭비를 줄인 미니멀리스트 서브에이전트 접근법

워크플로우 툴을 꺼도 에이전트 툴 자체가 3k 토큰 정도를 먹고, 확장 프로그램 기능이 늘어날수록 점점 더 무거워짐. 확장 프로그램 켜고 끌 때 세션 시작해서 토큰 수 비교해 보니까 확실하더라.

그래서 스스로 물어봤지. 내가 거의 쓰지도 않는 옵션(worktree 격리 같은 거)이 잔뜩 적힌 복잡한 JSON 스키마를 항상 컨텍스트에 들고 다닐 필요가 있을까? 답은 '아니오'였음.

pi는 이미 --mode rpc로 헤드리스 실행이 가능하고, CLI 플래그만으로도 서브 에이전트가 필요한 툴, 확장 프로그램, 모델, 사고 수준, 세션 재개 같은 걸 다 커버할 수 있음. 그러니까 적절한 플래그로 pi를 실행해 주는 작은 CLI랑, 사용법을 알려주는 스킬 하나만 있으면 전용 툴은 필요 없는 거임. 스킬은 단계별로 불러올 수 있는데 툴은 그게 안 되거든. 에이전트는 처음에 스킬의 짧은 설명만 보고, 위임할 때 메인 지침을 불러오고, 진짜 특이한 옵션이 필요할 때만 상세 레퍼런스를 읽으면 됨. 조종(steering)도 툴이 필요 없음. 그냥 실행 중인 pi 프로세스에 RPC 메시지 하나 쏘면 끝이니까.

토큰 소모 비교

• pi-subagents: 서브 에이전트 도구랑 주입된 시스템 프롬프트 때문에 토큰을 3k 정도 잡아먹음. 거기다 기본으로 켜져 있어서 일일이 꺼줘야 하는 동적 워크플로우 도구까지 합치면 6k가 더 추가됨. 둘 다 첫 메시지부터 세션마다 따라붙으니까, 기본 설정만 해도 뭘 시키기도 전에 9k 토큰은 그냥 날아가는 셈임.

• 이 스킬(에이전트가 위임하기 전): 스킬 설명만 들어가니까 토큰 몇십 개 수준.

• 이 스킬(에이전트가 위임한 후): SKILL.md가 로드되는데 1.2k 토큰 정도고, 멀티 에이전트 돌리기엔 이걸로 충분함.

• 명령어 세부 정보, 프로필 형식, 라이프사이클, 문제 해결 방법은 별도 참조 파일에 다 있음. 에이전트는 필요할 때만 이걸 읽어옴.

대부분 세션에서는 위임할 일이 없으니 비용이 거의 안 듦. 위임하더라도 도구 스키마 하나만 쓰는 것보다 훨씬 저렴함.

솔직히 말해서 이건 1:1 비교는 아님. pi-subagents가 이 스킬보다 기능이 훨씬 많거든. 도구 옵션도 엄청 많고, 각각 스키마에 파라미터가 필요하고 시스템 프롬프트에 텍스트도 추가하니까. 토큰 비용 일부는 워크트리 격리 같은, 이 스킬에는 없는 기능들 유지하는 데 쓰이는 거임. 근데 난 멀티 에이전트 작업에 그런 기능까지 필요한가 싶음. 에이전트한테 워크트리 쓰라고 시키면 알아서 잘하는데, 굳이 도구가 그걸 대신해 줄 필요가 있나? 에이전트는 이미 git 쓰는 법을 알고 있는데 말이야.

pi-subagents를 까려는 건 아님. 여전히 훌륭한 확장 프로그램이고, 특히 깔끔한 UI랑 내장된 기능 많은 거 좋아하는 사람들한테는 잘 맞을 거임. 그냥 나랑은 이제 안 맞는다는 거지. 난 에이전트가 필요한 것만 딱 로드하고 나머지는 스스로 알아서 처리하는 미니멀한 방식을 선호함.

트레이드오프

UI를 포기했음. 보기엔 진짜 예쁜데, 나한테는 1월에 큰맘 먹고 산 실내 자전거 같았음. 방구석에 있을 땐 그럴싸해 보이는데, 3월쯤 되면 그냥 옷걸이로 전락하는 거 알지? 첫 주에는 서브 에이전트 기록 다 챙겨봤는데, 그 뒤로는 거의 안 읽게 되더라. 결국 서브 에이전트의 최종 답변은 나 보라고 있는 게 아니라 메인 에이전트 보라고 있는 거더라고.

대신 더 중요한 걸 얻었음. 각 서브 에이전트는 CLI 플래그로 실행되는 진짜 pi 프로세스라 내 메인 pi랑 똑같은 확장 프로그램, MCP 서버, 스킬, 설정을 그대로 불러옴. 이 스크립트는 pi의 확장 API를 전혀 안 쓰고, 훨씬 덜 바뀌는 CLI 플래그랑 RPC만 써서 pi 업데이트 영향도 거의 안 받음. 프로세스가 분리되니까 내가 제일 좋아하는 기능도 쓸 수 있는데, 메인 에이전트가 죽어도 백그라운드 작업은 계속 돌아가고 나중에 아무 세션에서나 결과를 가져올 수 있다는 거임.

프로세스를 따로 돌리면 인프로세스 세션보다 신경 쓸 게 좀 많음. 그래서 이 스크립트는 단순한 CLI 래퍼가 아니라 에이전트가 귀찮은 일을 안 하게끔 다 처리해 줌. 예를 들어, pi는 stdout 쓰다가 에러 나면 종료 루틴 타기도 전에 뻗어버려서 에이전트 명령어가 좀비처럼 남거든. 그래서 각 작업마다 pi가 종료될 때까지 출력을 계속 읽어주는 러너 프로세스를 따로 붙였음. 이런 상황 대비해서 테스트 코드도 제대로 짜놨지만, 핵심은 간단함. pi 실행하고, 프롬프트 던지고, steer나 abort 메시지 전달하고, 작업 결과는 이름별로 저장하는 거임.

명령어 사용법

에이전트가 알아서 실행하겠지만, 터미널에서 직접 쳐도 됨:

# 읽기 전용 에이전트한테 질문 던지고 답변 기다리기
multi_agent.py run --profile Explore "재시도 정책이 어디 정의되어 있어?"

백그라운드에서 리뷰 시작하고 나중에 결과 가져오기

multi_agent.py run --background --name review "src/server/ 에러 처리 방식 리뷰해 줘"
multi_agent.py wait review --timeout 120

실행 중인 작업 수정하고, 끝나면 후속 작업 시키기

multi_agent.py steer review "생성된 파일은 건너뛰어"
multi_agent.py resume review "이제 클라이언트 쪽 확인해 봐"

작업 목록이랑 상태 확인하기

multi_agent.py list

직접 해보고 나서 뭐가 잘 되고 뭐가 박살 나는지 꼭 좀 알려줘.