Pi 멀티 에이전트 오케스트레이션 (Multi Agent Orchestration) 확장 기능

요약 (TLDR)

저는 Pi 코딩 에이전트가 저의 agent-shell 라이브러리를 통해 다른 에이전트 하네스 (agentic harnesses)를 호출할 수 있도록 하는 확장 기능을 구축했습니다.

GitHub Repo

한번 확인해보고 싶으시다면 다음과 같이 빠르게 시작할 수 있습니다.

Vercel 기술 사용 시

pi install npm:@scottrbk/pi-agentshell-extension

소스 코드로부터 설치 시

pi install git:github.com/ScottRBK/pi-agentshell-extension

저는 지난 몇 주 동안 agent-shell을 활용하는 작업을 해왔습니다. 가장 눈에 띄는 점은 에이전트 하네스 (agent harnesses)와 모델을 평가하기 위해 제가 만든 평가 하네스 (evaluation harness) 애플리케이션의 일부로 이를 포함시킨 것이었습니다.

저는 에이전트를 고도화된 검색 엔진 및 코드 리뷰어로 활용하여, 평가 하네스 (eval harness)를 위한 실제 코드를 직접 손으로 작성하는 데 많은 시간을 보냈습니다. 저 또한 몇몇 프로젝트를 바이브 코딩 (vibe coded) 해본 적이 있지만, 제 워크플로에 있어 매우 중요하거나 더 중요하게는 다른 사람들이 사용할 그 어떤 중요한 작업에 대해서도, AI가 작성한 것을 안심하고 사용할 수 있는 단계에 도달한 적은 없었습니다.

그렇긴 하지만, 저는 단순히 코드를 작성하거나 높은 수준을 요구하는 소프트웨어를 제작하기 위해서만 에이전트를 사용하는 것은 아닙니다. 일상적인 업무에서 저는 수많은 작업을 수행하기 위해 에이전트를 사용합니다.

대규모의 복잡한 엔터프라이즈 규모 저장소(repositories)에서 정보를 가져오는 것부터, Azure DevOps 작업 항목(work items)과 위키(wikis)를 작성, 편집 및 관리하고, 발표 자료를 제작하며, 회의록과 이메일을 기반으로 할 일(To Do's)과 활동을 정리하는 일까지 수행합니다.

이 모든 것을 저는 CLI, tmux 워크플로 및 다양한 CLI 에이전트를 사용하여 관리합니다. 업무 외적으로는 제가 만들고 있는 바이브 코딩 (vibe coded) 앱들이나, 조기 은퇴를 가능하게 해줄 문샷 SaaS (moonshot SaaS)를 위한 몇 가지 탐색적인 아이디어 등 재미있는 작은 프로젝트들을 진행하고 있습니다. 이 모든 과정은 저로 하여금 많은 tmux 창을 다루게 만들며 (아직 herdr로 넘어가지 않았습니다), 많은 인지적 과부하 (cognitive overload)를 남깁니다.

인지적 부하 (cognitive load) 감소

제가 초기에 파악한 것 중 하나는 대부분의 작업에 대해 단 하나의 에이전트 (Agent)와 대화해야 하며, 그 에이전트가 이 워크플로 (workflow) 상의 다른 에이전트들에게 작업을 위임 (delegating)하는 책임을 맡아야 한다는 점이었습니다. 다른 많은 사람들도 이 점을 빠르게 깨달았다고 생각하며, 이에 대한 가장 우아한 사례는 First Mate라는 훌륭한 리포지토리 (repository)입니다. 이 프로젝트는 제가 도달하고자 하는 방향과는 약간 다르지만 유사한 원칙을 가지고 있습니다. 아직 확인하지 않으셨다면 Kun Chen의 YouTube 채널과 에이전트 워크플로 (Agentic Workflows)에 관한 그의 영상들도 확인해 보시길 권장합니다. 그는 인지적 부하 (cognitive load)를 줄이는 원칙을 채택하는 방법에 대해 많은 훌륭한 아이디어와 실천 방안을 가지고 있습니다.

어디서부터 시작할까요? 당연히 Pi입니다

저는 이전에 Claude Code, Codex, 그리고 OpenCode (그들의 Go 구독 및 제가 로컬에 호스팅한 모델 포함) 사이를 오가며 시도해 보았습니다. 이들 모두 훌륭한 앱이라고 생각하지만, Pi를 발견한 순간 즉시 매료되었습니다. Pi의 미니멀리즘적이고 커스터마이징 가능한 측면이 매우 매력적이었으며, 마치 Neovim의 에이전트 버전처럼 느껴졌습니다.

저는 오케스트레이션 레이어 (orchestration layer)를 위해 어떤 에이전트를 사용하든, 그에 대해 많은 제어권 (control)을 가져야 한다고 느꼈고, Pi의 적응형 특성을 고려할 때 이는 명백한 선택지로 보였습니다. 적어도 제가 시작하기에는 말이죠. 나중에 어떤 오케스트레이터 에이전트 (orchestrator agent) 주변에 더 결정론적인 래퍼 (deterministic wrapper)를 구축하기로 결정할 수도 있겠지만, 지금 당장은 그럴 필요가 없다고 생각합니다.

첫 번째 빌딩 블록 (First building block)

웹 페치/검색/스크린샷(web fetch/search/screenshots)과 같은 명백한 확장 기능들을 포함시킨 후, 저는 제 Pi 에이전트가 서브 에이전트(sub agent)를 호출할 수 있는 능력을 구축하는 것이 핵심이라는 것을 깨달았습니다. 현재 서브 에이전트를 호출하기 위해 이미 존재하는 다른 Pi 에이전트 확장 기능들이 있지만, 다양한 상황을 고려했을 때 저는 특정 작업에 특정 모델과 하네스(harnesses)를 사용하는 것을 선호합니다. 제가 원했던 것은 다른 하네스 내부에서 에이전트를 호출할 수 있는 능력이었습니다. 특정 모델의 RL(강화학습 (RL))이 해당 제공자의 자체 하네스에서 작동할 때 서로 다른 동작을 유발할 수 있다는 것을 발견했으며, 따라서 특정 상황에서 이를 활용하는 것이 유용하다고 생각합니다.

그래서 에이전트 셸(agent shell)을 활용하는 것이 당연한 선택처럼 느껴졌습니다.

Python <-> TypeScript

음, 그것은 당연한 선택처럼 보였지만 한 가지 눈에 띄는 문제가 있었습니다. Pi는 그 확장 기능들과 마찬가지로 TypeScript로 작성되어 있는 반면, agent-shell은 Python 애플리케이션이라는 점입니다.

저의 TypeScript 경험은 몇 년 전 프론트엔드 개발에 관심을 가졌을 때 했던 Angular Tour of Heroes 실습과, 거의 20년 전 ASP.NET 앱에서 클라이언트 측 유효성 검사를 위해 작성했던 JavaScript 경험을 제외하면 매우 제한적입니다. 따라서 제 미래 워크플로우에 이토록 근본적인 것을 AI에게 맡겨 제가 정말 편안하게 느끼지 못하는 언어로 agent shell을 다시 작성하고 싶지도 않았고, 그렇다고 이 작업을 직접 수행하고 싶지도 않았습니다.

그래서 저는 AI와 협력하여 subprocess를 통해 TypeScript에서 Python으로 이어지는 브릿지(bridge)를 구축하기로 결정했습니다. 적어도 제가 이것을 직접 사용하며(dogfood) 익숙해질 때까지는 말입니다. 여기에는 index.ts에 등록된 도구 호출(tool calls)을 Python 핸들러로 전달하여 명령을 agent-shell 요청으로 변환하는 간단한 runner.ts 파일이 포함되었습니다.

확장 기능 동작 (Extension Behaviour)

현재로서는 도구 (tools)를 노출하는 것 외에 별도의 기술 (skills)이나 그 이상의 기능을 래핑(wrapped)하지는 않았습니다. 이는 향후 더 구체적인 의견(opinionated)이 반영될 무언가를 위한 빌딩 블록 (building block)이며, 현재 이 확장 기능 자체는 언제 어떤 하위 에이전트 (sub agents)를 호출해야 하는지에 대한 어떠한 규칙도 강제하지 않도록 설계되었습니다. 이는 확장 기능의 사용자 (consumer)에게 달려 있습니다. 저는 이것이 Pi 자체의 전반적인 철학에 부합하도록 하기 위해 이렇게 구현했다고 생각합니다. 단순히 모델에게 하위 에이전트를 호출하도록 요청하면, 모델은 도구를 호출하게 되며, 이때 하네스 (agent_type), model, 그리고 (지정된 경우) effort가 표시됩니다.

사이런트 모드 (Silent Mode)

Kun Chen의 에이전틱 워크플로우 (Agentic Workflow)에서 가져온 또 다른 아이디어는 First Mate의 출력을 줄여주는 'Calm Mode'의 사용이었습니다. 저는 이것이 좋은 기능이라고 생각하여 agent-shell 확장 기능에 통합했습니다. /agentshell-silent를 사용하면 하위 에이전트의 응답에 출력이 포함되지 않도록 트리거합니다.

다음 단계 (Next Steps)

저는 명령 (commands)과 기술 (skills)을 추가하고, Kun Chen이 First Mate에서 영감을 준 단일 에이전트 오케스트레이터 (single agent orchestrator) 접근 방식을 채택하기 시작할 것입니다. 저는 이미 agent-shell이나 제가 에이전틱 워크플로우를 위해 만든 forgetful 같은 도구들을 통해 이러한 개념을 향해 구축해 오고 있었습니다. 저만의 에이전틱 프레임워크 (agentic framework)도 구축했지만, Pi가 제가 이미 계획했던 모든 것을 제공해 주었기 때문에, 사이드 프로젝트가 부족하지 않은 상황에서 이를 어느 정도 보관(mothball)해 두어도 괜찮을 것 같습니다.

확장 기능 자체에 대해서는, 아키텍처의 다음 단계에 대해 아직 결정을 내리지 못했습니다. 그대로 둘 수도 있지만, TypeScript 브리지 (TypeScript bridge)가 다른 애플리케이션에서도 흥미로운 요소가 될 수도 있을 것 같습니다. 따라서 그 분야에는 두 가지 가능한 다음 단계가 있습니다:

1. 브리지 (bridge)를 별도의 라이브러리로 분리하거나, 안정성이 증명된다면 Agent Shell 라이브러리 내부로 이동합니다. 2. Agent Shell을 TypeScript로 다시 작성합니다. 저는 이미 많은 Python 라이브러리에서 Agent Shell을 사용하고 있기 때문에, 라이브러리의 두 가지 인스턴스를 유지하고 싶지 않은 한 이는 매력적인 옵션이 아닙니다 (AI 시대에는 이것이 그리 큰 문제가 아닐 수도 있습니다).

자, 여기까지입니다. 이만큼 읽어주셔서 감사합니다. 만약 이 확장 기능을 사용하게 된다면 어떤 피드백이든 환영하며, 사용이 즐거우셨다면 자유롭게 별점(star)을 남겨주세요.

여기서 논의된 것과 같은 주제에 관심이 있으시다면, forgetful Discord에 참여하여 뜻이 맞는 사람들과 자유롭게 이야기를 나누어 보세요.