본문으로 건너뛰기

© 2026 Molayo

GeekNews헤드라인2026. 05. 25. 19:59

모든 카드에서 병렬 에이전트를 실행하는 오픈소스 Kanban 데스크톱 앱

요약

KanBots는 Claude Code와 Codex를 칸반 카드 단위로 병렬 실행하는 오픈소스 데스크톱 앱입니다. 각 에이전트는 독립된 git worktree에서 격리되어 동작하며, 페르소나 기반의 자동화된 작업 분배와 실시간 비용 및 진행 상황 모니터링을 지원합니다.

핵심 포인트

  • Claude Code 및 Codex 에이전트의 병렬 실행 지원
  • git worktree를 활용한 작업 환경 격리 및 브랜치 관리
  • 페르소나 기반의 Autopilot 모드로 작업 자동 분배
  • 로컬 우선 방식의 무료 MIT 라이선스 데스크톱 앱 제공
  • 팀 협업을 위한 유료 Cloud 서비스 옵션 제공

KanBots는 칸반 카드마다 Claude Code와 Codex를 병렬 실행하고, 진행 상황·결정·비용을 보드에 실시간 표시하는 데스크톱 앱임

각 실행은 kanbots/issue-N 브랜치의 별도 git worktree에서 격리되며, 폴더를 넣어 보드를 만들고 카드별 에이전트를 배정할 수 있음

Autopilot은 제품·엔지니어·리뷰어·테스터 같은 페르소나를 최대 병렬도 4로 순회하며 작업을 나누고 백로그를 갱신함

에이전트는 판단이 필요한 지점에서 멈춰 선택지를 제시하고, 사용자는 번호 선택·수정 재제출·/spec·/review·/split으로 이어갈 수 있음

데스크톱 앱은 무료 MIT 라이선스와 로컬 우선 방식을 채택하며, Cloud는 좌석당 월 $19로 팀 동기화·알림·대시보드를 제공함

KanBots의 기본 개념

KanBots는 Claude Code와 Codex 에이전트를 칸반 보드의 카드 단위로 병렬 실행하는 데스크톱 앱임

각 에이전트는 kanbots/issue-N 브랜치의 별도 git worktree에서 실행되며, 보드는 진행 상황·결정 요청·비용을 실시간으로 갱신함

폴더를 넣으면 보드가 생성되고, 여러 카드에 Claude Code 또는 Codex 에이전트를 배정할 수 있음

자동 실행 모드에서는 페르소나가 작업을 나누고 병렬로 실행하며 결과를 점검함

데스크톱 앱은 무료, MIT 라이선스, 기부 기반이며 로컬 우선 방식으로 동작함

제품 구성과 과금

데스크톱 OSS

Desktop은 로컬 우선, 계정 없음, 원격 측정 없음, 무료 영구 제공, MIT 라이선스 방식임

macOS, Linux, Windows를 지원하고 모든 기능을 포함함

주요 기능에는 병렬 에이전트 실행, 자동 실행, 결정 프롬프트, 내장·사용자 정의 페르소나, 실시간 비용 분석, 레시피 라이브러리, kanbots-mcp-server, Sentry 가져오기, GitHub Issues 모드, 브랜치 미리보기, PR 초안 생성, Claude Code·Codex 지원, 사전 푸시 훅이 포함됨

팀용 Cloud

Cloud는 호스팅형 다중 사용자 제품이며, 에이전트는 사용자 하드웨어에서 로컬로 실행됨

가격은 좌석당 월 $19이며, 연간 청구 시 $190임

OSS 기능에 더해 보드 실시간 존재 표시, 팀원 할당 알림, 기기 간 동기화, Slack 알림, 조직 전체 비용 집계, 실시간 공동 카드 편집, 조직별 에이전트 활동 대시보드, Managed GitHub App을 제공함

에이전트가 밤새 작업한 결과를 사람들이 어떻게 받아들이는지 계속 의문이 듦
개인 사이드 프로젝트 저장소에서도 30분 계획하고 30분 구현한 결과는 검토하기에 너무 크다고 느낌. 5분쯤 지나면 코드가 쏟아지는 중에도 AI에게 다시 하라고 시킬 때가 있음

요즘 서사는 AI가 코드의 전부나 대부분을 쓴다는 쪽에 집중돼 있지만, 실제로는 사람이 검토한 코드 비율이 사람들이 깨닫거나 인정하는 것보다 훨씬 빠르게 0에 가까워지고 있을 것 같음

그런 에이전트 활동의 상당 부분은 이전에 만든 것을 훑고, 제약을 강제로 걸어서 검토할 때 책상 위에 올라올 결과를 어느 정도 예측 가능하게 만드는 일임
개인적으로는 강한 파일 구조도 도움이 됨. 방금 생성한 3,000줄짜리 파일을 검토하는 건 최악이고, 사람에게도 기계에게도 그런 결과는 받지 않을 것임. 알맞은 위치에 여러 파일로 나뉘어 있으면 인지 부담이 줄어듦
때로는 에이전트와 대화하면서 같이 검토함. 먼저 검토할 가장 중요한 파일이 무엇인지 묻는 식임
변경 사항을 “LGTM” 더미에 스테이징해 두는 걸 좋아함. 이후 수정이 필요하면 에이전트에게 “스테이징되지 않은 변경을 검토해줘. 여기서는 다른 방식으로 해줬으면 해”라고 시킴

아무도 코드를 검토하지 않음. 관리자들도 우리가 코드를 검토하길 원하지 않음. 병목이기 때문임
뭔가 잘못되면, 즉 버그가 생기면 그때그때 고침. 소프트웨어 엔지니어링의 매우 슬픈 시대임. 우리 업계에 엔지니어링이란 게 있었다면 이제는 대부분 사라졌고, “버그를 넣지 말아줘”나 “너는 세입자가 아니라 소유자야” 같은 skills 파일을 쓰며 대충 짐작하고 있음
노력 수준도 낮고 결정성도 매우 낮음. GitHub 같은 큰 앱들이 AI 쓰레기 때문에 계속 내려가고 있고, 덜 유명한 시스템에서도 더 자주 보임. 우리 회사나 우리가 쓰는 다른 SaaS에서도 마찬가지임
제품 관리자는 원래 코드에 관심이 없었고, 엔지니어링 관리자는 엔지니어였을 때만큼 코드에 관심이 없음. 디렉터는 코드에 전혀 신경 쓰지 않고, CTO는 이제 코드가 어떻게 생겼는지도 모름
우리는 사슬의 끝에 있고, 좋은 시스템은 좋은 코드 위에 세워진다는 걸 깊이 알았기 때문에 잘 쓰이고 유지보수 가능한 코드에 자부심을 가져왔음. 그런데 이제는 우리 스스로를 위험에 빠뜨리고 있고, 코드에 더 이상 신경 쓰지 않는 쪽이 바로 엔지니어인 우리이며 AI가 그 문제를 증폭하고 있음

보통 Claude가 밤새 작업한 뒤 최종적으로 약 500줄의 코드만 남기도록 목표를 잡음
대부분의 시간은 여러 접근법을 실험하고 요약한 뒤, 내가 검토하고 수정할 수 있는 비교적 작은 차이를 주는 데 쓰임

나도 같은 의문이 듦. 실제로 잘 운용하는 사람들에게서 보통 듣는 답은 코드를 보지 않는다는 것, 적어도 자세히 보지는 않는다는 것임
개인적으로는 에이전트가 만든 결과를 늘 뭔가 손보게 됨. 그 통제를 내려놓아야 하는지 고민됨

이건 대부분의 프로젝트에서 코딩 에이전트를 관리할 때 쓰는 Vibe Kanban(https://vibekanban.com/)이 떠오름
안타깝게도 Vibe Kanban 개발자들은 수익화 경로가 보이지 않는다고 판단해 프로젝트 투자를 멈췄음. 오픈소스라서 로컬에서 실행하거나 포크할 수는 있지만, 개선이 멈췄고 아직 고쳐야 할 성가신 버그가 남아 있음. 개인적으로 유지보수할 시간은 없음
기꺼이 Vibe Kanban에 돈을 낼 생각이 있었기에 아쉬움. 다만 유료 플랜 기능이 필요하지 않았음. 돌이켜보면 그냥 냈어야 했을지도 모름
Kanbots도 한번 써보겠음. Vibe Kanban의 기능을 적극적으로 베껴도 좋을 듯함. 특히 원격 지원과 “Open in VS Code” 버튼은 내게 핵심적임. 내 경우 이 버튼은 원격 VSCode 서버를 가리키는 로컬 VSCode 클라이언트를 열어줌

Vibe Kanban은 유용한 기능 면에서 정말 보물창고임
지난 1~2주 동안 새 도구를 VK와 기능 동등성 수준까지 끌어올리고, 추가 개선도 넣는 작업을 하고 있음. Vibe Kanban Discord에도 스크린샷을 몇 개 올렸음. 출시 준비가 끝나면 당신의 사용 사례에도 잘 맞기를 바람
내 도구는 Kanban 보드와 에이전트 작업공간 양쪽에서 VK보다 나은 기능을 목표로 하고, 데스크톱 창 관리, 플러그인, 브라우저 내 VSCode 통합, htmx 비슷한 서버 렌더링 UI 같은 추가 시스템도 넣고 있음
원격 접근 방식도 다름. 노트북에서 웹 서버를 띄워 원격 코딩 에이전트에 접근하는 대신, OpenClaw처럼 전체를 호스팅하고 브라우저에서 원격 데스크톱 UI에 접근함

“로컬 우선, 서버 없음. 모든 것이 저장소 옆 .kanbots/에 있음: SQLite 데이터베이스, 설정, 작업트리. 클라우드 계정 없음, 원격 측정 없음, HTTP 서버 없음. 이것이 오픈소스 데스크톱 에디션”이라는 점은 이런 도구 도입을 검토하기 위한 기본 조건임

“이런 도구”가 무엇을 말하는지 모르겠음
AI가 에이전트형이라면, 어떤 제품 관리자든 한 시간 정도 대화해서 Jira와 어떤 에이전트 루프를 통합할 수 있어야 한다고 기대함
Jira, Trello, Linear, Basecamp는 모두 API가 있고, 에이전트가 쓸 수 있는 CLI도 있을 것 같음. 작업을 시작하면 티켓이 체크아웃되고 지시사항을 담고 있으며, 끝나면 DONE으로 옮긴다는 걸 이해시키는 데 개발자나 SaaS가 필요하진 않아야 함

페이지를 보면 로컬에서 쓰더라도 이 기능이 동작하려면 클라우드 계정 로그인이 필요하다고 되어 있어서 시도하지 않기로 했음
솔직히 멋져 보이긴 함. 하지만 이미 멋져 보이는 도구가 꽤 많음

원래 “Kanban”이라는 단어는 Toyota가 카드 시스템을 설명할 때 썼고, 그 시스템은 동시에 너무 많은 일을 하지 않도록 하는 것과 작업을 시각화하는 것 등 몇 가지 중요한 목적을 달성하게 해줬음
전반적으로 Kanban은 결함이 통과하지 않도록 작업 흐름을 관리하는 데 쓰였음
그런데 이 도구는 “생각해낼 수 있는 일을 최대한 병렬로 생성되게 밀어 넣기”에 가까움. 품질 있는 산출물의 흐름을 관리하지도 않고, 작업을 제한하지도 않음. 그냥 모든 것을 에이전트에 집어넣고 토큰을 미친 듯이 태움
이런 걸 “Kanban”이라고 부르는 게 정말 거슬림. 신성모독 같은 느낌임

에이전트를 감독 없이 돌려봤을 때 성공보다 좌절이 더 많았음
기술은 결국 거기까지 갈 거라고 믿지만, 지금은 에이전트마다 IDE 하나가 필요하고 작업 병합도 번거로움

최신 오픈소스 프로젝트를 공유함. 병렬 에이전트가 있는 Kanban 보드임
더 많은 기능으로 개선하려고 하고 있고, 코드 기여든 아이디어든 저장소에 기여해주면 좋겠음

좋은 작업임. 기존 Jira 프로젝트에서 워크플로별로 분류해 자체 에이전트들이 Kanban을 돌리게 해본 적이 있는데, 오늘 HN에서 이 프로젝트를 보니 반가움
작업 내용을 따라가보는 게 즐거울 것 같음

Kanban 보드에서 에이전트에게 넘기는 걸 돕는 앱은 몇 가지 있음
내게는 더 사람이 개입하는 흐름이 필요했음. 변경 집합을 잘 볼 수 없고 방향을 틀 기회도 없이 에이전트에게 넘기는 방식은 맞지 않음 https://www.agentkanban.io는 확장을 통해 작업 보드와 VS Code의 GitHub Copilot Chat을 연결해서, 작업 관리와 채팅에서 작업으로 이어지는 맥락 캡처를 함께 얻도록 함. 그래서 VS Code라는 상위 실행 환경의 장점과 작업/프로젝트 관리 기능을 동시에 쓸 수 있음

여기서 문제가 보이지 않음. 문제가 있나?
Linear도 직접 이 방향으로 작업 중임

Windsurf는 오픈소스인가?

이런 도구들에서 이해가 안 되는 부분은 서로 다른 작업트리의 인프라 기동을 어떻게 처리하느냐임
예를 들어 웹앱이 있다면 각 작업트리가 자기 인프라를 띄우고, 각자 고유한 로컬 URL로 접근 가능해야 함. 그래야 각 작업트리의 변경을 로컬에서 보거나, agent-browser 같은 것으로 에이전트가 시각 확인을 자동화할 수 있음
현재는 인프라에 Docker를 쓰고, 각 서비스는 자체 컨테이너에서 실행함. ./app worktree create worktreename 스크립트가 있고, 이 스크립트는 “worktreename” 작업트리를 만든 다음 “WORKTREENAME” 같은 접두사를 붙여 Docker 인프라를 전부 띄움. 그래서 모든 URL을 worktreename.myapp.test에서 접근할 수 있고, 메인 작업트리는 그냥 myapp.test를 씀
지금은 잘 돌아가지만, 이런 앱 중 하나가 이 개념과 호환되면 그쪽으로 옮길 수 있어서 좋겠음

직장에서 같은 문제가 있어서, CC에게 작업트리를 만들고 삭제하고 나열하는 아주 단순한 bun CLI 도구를 만들어달라고 했음
그 CLI는 .env 파일에 해당 작업트리용 URL과 데이터베이스를 채워 넣고, Vercel의 오픈소스 패키지 portless로 고유 포트의 개발 서버를 띄움. 그래서 작업트리마다 URL을 얻음

emdash.sh를 확인해보면 좋음. 각 작업은 자체 작업트리를 띄우고, 미리 정의된 환경 변수들이 주입됨
여기에는 10개 포트 범위에 대한 고유 포트인 EMDASH_PORT가 포함됨. 단일 모노레포에서 여러 서비스를 실행할 때 매우 유용함

작업트리를 만들고 없애는 셸 스크립트를 쓰고 있음
셸 스크립트가 기존 모든 작업트리에서 쓰이지 않는 고유 포트를 찾아 작업트리 생성 시 로컬 .env에 할당함. 작업트리가 병합되고 제거되면 포트도 해제됨
작업트리별이 아닌 비밀값은 로컬 .env에 두지 않고 셸로 주입함
솔직히 개발 작업 자동화를 위한 이런 로컬 스크립트 작성은 아주 간단했고, 다른 모든 CLI 도구와 잘 결합됨. 그래서 아직 GUI 앱을 써보지 않았음. 내가 원하는 방식 그대로 동작하는 맞춤 로컬 설정과 경쟁할 수 있을지 모르겠음

그냥 direnv를 쓰면 되지 않나? 로컬 페이지를 호스팅하는 포트는 조정해야겠지만, 작업트리 이름 기반 해시로 N=mod(...)를 잡고 port=default_port+N으로 하면 됨
Claude에게 설정하라고 하면 됨. 프롬프트 하나로 해낼 것임

“‘kanbots’가 손상되어 열 수 없습니다. 휴지통으로 이동해야 합니다”라니 바이브 코딩 소프트웨어에서 처음 마주치기에 너무 어울리는 오류임

AI 자동 생성 콘텐츠

본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0