케빈 트루옹(Kevin Truong)은 코딩 에이전트 하나에 의존할 때 생기는 코드 검토 품질, 사용량 제한, 여러 에이전트 사이의 맥락 관리 문제를 해결하려고 SpurCode를 만들고 있다. 이 글은 사용자가 대화하는 ‘브레인’ 에이전트가 서로 다른 코딩 에이전트에 작업을 맡기고 결과를 검토하는 구조와, 이를 뒷받침하는 아키텍처를 소개하는 1부다.
SpurCode는 터미널 사용자 인터페이스(TUI)를 갖춘 코딩 에이전트 오케스트레이터다. 사용자는 TUI에서 브레인 에이전트와 해결책과 작업 계획을 논의하고, 브레인은 작업에 맞는 워커 에이전트를 실행한다. 워커는 한 번에 하나의 작업을 수행한 뒤 결과와 산출물을 브레인에게 돌려준다. 작업 중 브레인과 워커가 주고받지는 않으며, 브레인은 결과를 검토한다. 사용자는 중요 결정에 개입해 흐름을 통제할 수 있다.
트옹은 이 구조를 아파치 스파크의 드라이버-워커 모델에서 착안했다고 설명한다. 기존 에이전트 내부의 하위 에이전트 위임과 달리, 브레인과 워커가 서로 다른 코딩 에이전트일 수 있다. 예를 들어 Claude Code가 작업을 맡기고 Codex가 워커로 수행하는 식이다.
처음부터 코딩 에이전트를 새로 만들거나 기존 오픈소스 에이전트를 포크하는 대신, 트옹은 에이전트와 편집기·IDE를 연결하는 공개 표준인 ACP(Agent Client Protocol)를 기반으로 삼았다. ACP 호환 에이전트를 백그라운드에서 실행하고, SpurCode는 TUI와 ACP 메시지 처리, 작업 위임을 위한 MCP 서버를 담당한다. ACP 관련 라이브러리는 Agent Client Protocol 저장소에서 확인할 수 있다.
SpurCode는 ACP 메시지를 내부 이벤트 형식으로 표준화하는 Spur-Core를 두어 TUI가 에이전트별 차이를 직접 처리하지 않도록 설계했다. ACP를 준수하는 에이전트의 메시지는 공식 형식으로 읽어 그대로 전달하고, 형식이 다른 에이전트는 어댑터에서 변환한다. 트옹은 Pi 에이전트가 터미널 출력을 비표준 메타데이터에 담는 경우, 어댑터가 출력을 누적해 표준 필드에 넣는다고 설명한다. 다만 현재는 여러 연결 방식을 지원하려던 초기 계획과 달리, 개발의 중심이 네이티브 ACP로 옮겨갔다고 덧붙였다.
메시지 순서도 설계의 핵심이다. 에이전트의 알림을 프롬프트 실행 전에 구독하고, 각 에이전트의 메시지를 도착 순서대로 하나씩 처리한다. 이후 브레인·워커 등 여러 발신자의 이벤트는 단일 이벤트 퍼널이 순번을 붙여 전달한다. 따라서 개별 에이전트 안에서는 도착 순서를 유지하고, 여러 에이전트 사이의 순서는 퍼널에서 정한다. TUI는 같은 SpurEvent 버스에 구독해 에이전트별 메시지를 공통 방식으로 렌더링하고 작업 흐름을 관찰한다.
트옹은 다음 편에서 장시간 작업의 계획과 실행을 다루는 작업 플래너를 설명하겠다고 밝혔다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요