KanBots: Kanban 인터페이스를 통한 병렬 AI 에이전트 오케스트레이션

AI 에이전트의 약속은 오랫동안 '채팅' 인터페이스, 즉 사용자가 모델에 프롬프트를 입력하고 응답을 기다리는 선형적인 대화에 집중되어 왔습니다. 하지만 복잡한 소프트웨어 엔지니어링의 경우, 단일 채팅 스레드만으로는 충분한 경우가 드뭅니다. 실제 개발은 큰 기능을 하위 작업으로 나누고, 의존성을 관리하며, 여러 버그를 동시에 반복적으로 수정하는 과정을 포함합니다.

KanBots는 Kanban 보드를 단순한 프로젝트 관리 도구가 아닌, 병렬 AI 에이전트를 위한 런타임으로 재구상한 오픈 소스 데스크톱 애플리케이션입니다. 에이전트를 개별 카드에 할당함으로써, KanBots는 개발자가 여러 AI 작업을 별도의 git worktrees를 통해 배포할 수 있게 하여, 시각적 보드를 자율적인 코드 생성의 살아있는 기록 시스템으로 변모시킵니다.

병렬 에이전시의 아키텍처

KanBots의 핵심은 '채팅 탭' 메타포에서 벗어나는 것입니다. 대신, Kanban 보드 위의 모든 카드를 잠재적인 실행 단위로 취급합니다.

Git Worktrees를 통한 격리 계층

KanBots의 가장 기술적인 장점 중 하나는 git worktrees를 사용하는 것입니다. 에이전트가 카드에 배포될 때, 단순히 현재 디렉토리를 수정하는 것이 아니라 특정 브랜치(예: kanbots/issue-N)에서 전용 worktree를 실행합니다. 이를 통해 병렬 에이전트들이 서로의 변경 사항을 덮어쓰지 않도록 보장하며, 개발자가 메인 작업 디렉토리를 오염시키지 않고도 다양한 에이전트 주도 실험 사이를 전환할 수 있게 합니다.

Bring Your Own CLI

특정 모델에 사용자를 종속시키기보다, KanBots는 어댑터 역할을 수행합니다. Claude Code 및 Codex와 같은 인기 있는 에이전트형 CLI를 지원합니다. AgentCliAdapter를 활용함으로써, 앱은 기존 인증(예: claude /login 또는 OPENAI_API_KEY)을 활용하므로 사용자가 새로운 자격 증명이나 계정을 관리할 필요가 없습니다.

Local-First 철학

클라우드 중심의 AI 도구 시대에, KanBots는 엄격한 로컬 퍼스트(local-first) 접근 방식을 취합니다. 이 애플리케이션은 로컬 SQLite 데이터베이스를 사용하며, 모든 설정과 worktree를 저장소 내의 .kanbots/ 폴더에 저장합니다. 이는 사용자가 명시적으로 원격 저장소에 푸시하지 않는 한 코드가 기계 밖으로 나가지 않도록 보장합니다.

고급 오케스트레이션: Autopilot 및 Persona

단순한 배포를 넘어, KanBots는 자기 진화형 기능 개발을 위해 설계된 "Autopilot" 모드를 도입합니다. 이 시스템은 Personas—이름이 지정된 시스템 프롬프트 조각(예: Product Manager, Engineer, Reviewer, Tester)—를 활용하여 전체 개발 팀을 시뮬레이션합니다.

  1. Round-Robin 실행: 오케스트레이터는 최대 4개의 병렬 슬롯을 실행할 수 있으며, 사용 가능한 작업에 Persona를 라운드 로빈 방식으로 할당합니다.
  2. Dynamic Backlog Evolution: 에이전트가 구현 과정에서 새로운 요구 사항이나 버그를 발견하면, 보드 위에 새로운 카드를 자율적으로 생성할 수 있습니다. 이를 통해 에이전트의 실행 중에 실제 발견된 작업에 따라 백로그이 늘어나거나 줄어들 수 있습니다.
  3. Human-in-the-Loop 결정: 코드베이스의 "조용한 변이(silent mutations)"를 방지하기 위해, KanBots는 결정 UI를 구현합니다. 에이전트가 갈림길에 도달하면 실행이 일시 중지되고, 사용자에게 번호가 매겨진 옵션이나 /spec 또는 /review와 같은 슬래시 명령어를 위한 응답 박스가 제공됩니다.

커뮤니티 관점 및 기술적 트레이드오프

"보드-as-오케스트레이터"라는 개념은 매우 찬사를 받고 있지만, Hacker News 커뮤니티에서는 자율 에이전트의 실제 적용에 대해 몇 가지 비판적인 지점을 제언했습니다.

리뷰 병목 현상

개발자들 사이에서 반복되는 우려 사항은 에이전트가 생성한 코드를 리뷰하는 인지적 부하입니다. 한 사용자가 다음과 같이 언급했습니다:

"제 개인 사이드 프로젝트 저장소에서 30분간의 계획과 30분간의 구현이 이루어지면 리뷰하기에 너무 큽니다."

이는 근본적인 긴장 관계를를 보여줍니다: 에이전트가 코드를 병렬로 생성할 수 있는 반면, 인간의 리뷰 및 통합 능력은 여전히 선형적입니다. 머지(merge)하기에 너무 번거로운 방대한 양의 작업을 생성하기 위해 "토큰을 낭비(burning tokens)"할하는 위험이 실재합니다.

전체 IDE 통합의 필요성

일부 사용자들은 보드에 정리된 형태라 하더라도 제한된 채팅 인터페이스는 불충분하다고 주장했습니다. 사용자들이 원하는 것은 "1 작업 = 1 worktree = 1 전체 IDE"입니다. 즉, 개발자가 단순화된 UI를 통해 상호작용하는 대신, 각 에이전트의 worktree를 중심으로 Cursor와 같은 전체 도구 모음을 사용할 수 있어야 한다는 것입니다.

"Kanban" 논쟁

흥미롭게도, 일부 순수주의자들은 이 도구의 철학학이 Kanban의 원래 의도와 상모합니다. Toyota가 Kanban을 사용하여 작업 진행 상황(WIP)을 제한하기 위해 사용했다면, KanBots는 병렬 작업을 최대화하도록 권합니다합니다. 이는 KanBots가 진화하기 위해서는, 보드가 반쯤 끝난 작업들의 혼란스러운 집합체가 되지 않도록 하기 위해 더 엄격한 WIP 제한이나 더 더 강력한 품질 관리 게이트 메커니즘을 포함해야 할 수도 있음을 시사합니다.

통합 및 생태계

KanBots는 다음과 같은 여러 통합을 통해 기존 워크플로우에 녹아들도록 설계되었습니다:

  • GitHub Mode: Personal Access Token (PAT)를 통해 worktree를 커밋으로 승격시키거나 드래프트 PR을 생성할 수 있게 합니다.
  • MCP Server: Model Context Protocol (MCP) 서버를 포함하여, 다른 MCP 인식 도구(예: Claude Desktop 또는 Cursor)가 Kanban 보드 자체를 구동할 수 있게 합니다.
  • Cost Analytics: 실행별 및 카드별 실시간 비용 추적을 제공하여, 사용자가 예상치 못한 API 비용 발생을 피하기 위해 엄격한 예산을 설정할 수 있게 합니다.

대화를 넘어 기록 시스템으로 초점을 전환함으로써, KanBots는 단순한 AI 보조를 넘어 구조화되고 에이전트 중심의 개발 파이프라인을으로 향하고하고자 하는 이들을 위한 프레임워크를 제공합니다.

Sources