Vibe Kanban 대안: 이제 코딩 에이전트를 어디서 실행할까?

보드를 중심으로 습관을 만들어 오셨을 겁니다. 작업마다 컬럼 하나, 카드마다 코딩 에이전트 하나, 각자 자기만의 git worktree에서 작업하니 충돌도 없었죠. 에이전트 서너 개를 동시에 돌리면서도 diff를 하나씩 검토할 수 있는 깔끔한 방식이었습니다. 그런데 그 도구를 유지하던 회사가 클라우드 서비스를 종료하면서, 정직한 질문이 떠올랐습니다. 이제 코딩 에이전트는 어디서 돌려야 하고, 그 답이 노트북 한 대와 사람 한 명을 넘어서도 확장될까요?

Vibe Kanban 대안을 찾고 있다면, Claude Code나 Codex를 대체할 무언가를 찾는 게 아닙니다. 그 런타임들을 감싸는 계층, 즉 각 에이전트에게 작업을 넘기고, 작업을 격리된 상태로 유지하며, 병합되기 전에 무엇이 바뀌었는지 보여주는 계층을 찾는 겁니다. 이 가이드는 바로 그 계층을 다룹니다. Vibe Kanban이 증명한 패턴은 충분히 인정하되, 로컬 보드가 멈추는 정확한 지점을 짚고, 그 너머로 이어져 Sharkly가 팀 전체를 위한 공유 Task, Crew, Sprint로 나아가는 모습을 보여드립니다.

TL;DR

Vibe Kanban은 에이전트별 보드 모델을 처음 열었습니다. 여러 코딩 에이전트를 병렬로 실행하고, 각자 자기 worktree에서 작업하며, 내 컴퓨터의 칸반 보드에서 결과를 검토하는 방식이죠. Sharkly는 이 모델을 그대로 유지하면서 그 주위에 팀 계층을 더합니다. 공유 Task 레코드, 연결된 Computer, Crew, Sprint, 그리고 요청부터 릴리스까지 이어지는 사람의 검토입니다. 한 대의 컴퓨터에서 혼자 작업한다면 로컬 보드로 충분합니다. 팀이 공유 컨텍스트와 검토 게이트를 필요로 한다면, 바로 그 지점에서 Sharkly가 시작됩니다.

Vibe Kanban 대안이 실제로 해결하는 문제

Vibe Kanban은 대부분의 도구가 놓친 무언가를 제대로 짚었습니다. AI 코딩 에이전트를 여러 개 동시에 돌릴 때 어려운 부분은 모델이 아닙니다. 충돌입니다. 두 에이전트가 같은 파일을 수정하고, 결과물은 터미널 탭마다 흩어지고, 어떤 작업이 끝났는지, 어떤 게 막혔는지, 어떤 게 조용히 옆길로 샜는지 한눈에 볼 방법이 없죠.

에이전트별 보드라는 답은 우아했습니다. 작업마다 카드를 하나씩 주고, 카드마다 git worktree를 따로 주어 에이전트가 격리된 디렉터리의 격리된 브랜치에서 작업하게 합니다. Claude Code, Gemini CLI, Codex 또는 다른 런타임이 그 샌드박스 안에서 작업을 처리하고, diff를 다시 가져와 검토합니다. "에이전트가 다섯 개인데 뭘 했는지 하나도 모르겠다"는 상황이 실제로 읽을 수 있는 보드로 바뀐 거죠. 이 병렬 패턴의 작동 원리 자체가 궁금하다면, 여러 Claude Code 에이전트를 병렬로 실행하는 방법 가이드에서 worktree 설정을 자세히 다룹니다.

문제는 애초에 패턴이 아니었습니다. 문제는 로컬 보드가 닿을 수 없는 영역입니다. 내 컴퓨터에 있는 보드는 나만을 위한 보드입니다. 동료는 그 작업을 볼 수 없고, 막힌 카드를 이어받을 수 없고, 병합 전에 diff를 검토할 수 없고, 멀리서 스프린트가 제대로 가고 있는지 알 수 없습니다. 혼자 하는 작업이라면 괜찮습니다. 하지만 팀의 작업이라면 빠진 조각은 공유 레코드이고, 그것은 성격이 다른 도구입니다.

Vibe Kanban이 증명한 것, 분명하게 짚어보기

이 도구에는 최고의 평가를 내려야 합니다. 그만한 자격이 있으니까요. Vibe Kanban은 에이전트 실행을 일회성 터미널 세션이 아니라 일급 작업 단위로 다뤘습니다. worktree 격리를 기본값으로 만들어 병렬 에이전트들이 서로 발을 밟지 않게 했습니다. 런타임 전환을 저렴하게 만들어 하나의 모델에 묶이지 않게 했습니다. 그리고 카드를 완료로 옮기기 전에 diff를 먼저 보여줌으로써 검토를 나중에 덧붙이는 일이 아니라 하나의 단계로 만들었습니다.

이 네 가지 아이디어는 옳습니다. 진지한 대안이라면 이 모두를 유지해야 합니다. worktree 격리를 포기하거나, diff를 숨기거나, 하나의 런타임에 묶어버리는 Vibe Kanban 대안은 다른 무엇을 더하든 하향 평준화입니다. 보드가 세운 기준은 천장이 아니라 바닥입니다.

달라진 것은 유지보수 이야기입니다. 이 프로젝트는 오픈 소스이고 여전히 로컬에서 실행할 수 있지만, 회사가 운영하던 클라우드 기능은 제거되었고 지속적인 수정은 이제 커뮤니티 기여자에게 달려 있습니다. 혼자 하는 개발자라면 충분히 받아들일 만합니다. 하지만 분기 단위로 납품을 이 도구에 걸고 있는 팀이라면, "누가 나서느냐에 달려 있다"는 건 실제로 저울질해야 할 리스크이며, 지금 마이그레이션을 고민하는 사람들이 많은 솔직한 이유입니다.

로컬 보드가 끝나고 Sharkly가 이어지는 지점

선택이 실제로 갈리는 방식 그대로, 두 가지 경우를 정리해 보겠습니다.

한 대의 컴퓨터에서 혼자 작업하고, 작업이 전적으로 나만의 것이며, 내가 풀 리퀘스트를 열기 전까지 아무도 그 작업을 볼 필요가 없다면 로컬 보드를 쓰세요. 에이전트별 보드 구성은 가볍고, 내가 실행하는 환경에서 그대로 돌아가며, 조율할 상대가 없으니 조율 부담이 전혀 없습니다. 이 경우 팀 플랫폼을 꺼내 드는 건 과잉입니다.

에이전트 실행이 더 이상 사적인 영역이 아니게 되는 순간 Sharkly를 쓰세요. 두 번째 사람이 작업을 배정하거나, 막힌 일을 이어받거나, 병합 전에 diff를 검토해야 하는 순간, 내 노트북에 사는 보드는 병목이 됩니다. 그게 바로 그 선입니다. Sharkly는 이미 쓰고 있는 같은 런타임들을 감싸는 계층으로서, 모든 실행을 나만이 아니라 팀이 배정하고, 보고, 검토할 수 있게 만듭니다.

이후 내용이 여기에 달려 있으니, 용어집 수준으로 빠르게 정의하겠습니다. Task는 Sharkly의 핵심 작업 단위입니다. 목표, 배정된 Agent, 런타임, 진행 상황, 블로커, 결과 diff, 사람의 검토를 하나의 공유 레코드에 담습니다. 로컬 보드의 카드가 나의 것이라면, Task는 팀의 것입니다.

그리고 경계도 짚어야 합니다. 보드에서 옮겨오는 독자라면 그렇지 않아도 잘못 짐작할 테니까요. Sharkly는 Claude Code, Codex, Gemini를 대체하는 게 아닙니다. 모델을 실행하거나 코드를 작성하지 않습니다. 팀이 이미 쓰는 실행 도구 주위에 공유 Task, 연결된 Computer, 컨텍스트, 제어, 검토 계층을 더할 뿐입니다. Vibe Kanban이 런타임을 자유롭게 바꿀 수 있게 해준 점이 좋았다면, Sharkly는 그 자유를 유지하면서 그 주위에 팀을 세웁니다.

마이그레이션 경로: 런타임은 그대로, 저장소도 그대로, 검토 계층만 추가

서비스가 종료되는 보드에서 옮겨갈 때 가장 좋은 점은 포기해야 할 게 거의 없다는 것입니다. 스택을 다시 만드는 게 아닙니다. 잘 작동하던 부분은 유지하고, 빠져 있던 부분만 더하는 겁니다.

런타임은 그대로 두세요. Claude Code, Codex, Gemini CLI, OpenCode, Cline 등은 이전과 똑같이 실행을 담당합니다. 모델 사용은 해당 도구에 이미 설정된 구독이나 API 키를 통해 계속됩니다. 구독은 직접 가져오면 되고, Sharkly가 에이전트와 모델 사이에 끼어들지 않습니다. 이 런타임들이 실제로 무엇을 하는지 개념부터 잡고 싶다면, 개발 팀에게 에이전틱 코딩이란 무엇인가 해설에서 용어를 정리해 드립니다.

저장소와 worktree 습관도 그대로 두세요. Sharkly는 연결된 Computer의 격리된 worktree에서 에이전트를 실행합니다. 여러분이 의지했던 바로 그 격리가, 이제 로컬 카드가 아니라 공유 Task에 연결됩니다. 프런트엔드, 백엔드, 버그 수정, 테스트 커버리지가 충돌 없이 동시에 진행될 수 있고, 이게 바로 에이전트별 보드 모델이 존재했던 이유입니다.

빠져 있던 검토 계층을 더하세요. 여기가 새로운 부분입니다. 실행, 블로커, 결과, 후속 논의가 팀이 볼 수 있는 Task 타임라인으로 돌아옵니다. Agent는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 자동화는 팀의 판단이 필요한 지점에서 멈추고, 완전한 컨텍스트와 검증 가능한 근거를 갖춘 결과물을 돌려줍니다. 이 마지막 문장이 로컬 보드가 강제할 수 없었던 계약입니다. 그 반대편에 팀이 없었으니까요.

그래서 마이그레이션은 더하기입니다. Computer를 연결하고, 이미 가진 런타임을 Sharkly에 지정하고, 팀이 이미 이해하고 있는 프로세스를 다시 만들지 않은 채 작업을 라우팅하기 시작하면 됩니다. 보드는 에이전트를 병렬로 돌리는 법을 가르쳐 줬습니다. Sharkly는 나머지 팀도 그 흐름에 들어오게 합니다.

1인 보드에서 팀 시스템으로: Crew, Sprint, Project

실행이 공유되는 순간, 1인용 보드가 제공할 수 없었던 세 가지 역량이 열립니다.

Crew, 에이전트 하나 이상이 필요한 작업을 위해. Crew는 리더 Agent 하나가 조율하는 People과 Agent의 재사용 가능한 그룹입니다. 작고 명확하게 정의된 작업에는 필요 없습니다. Task를 단일 Agent에 배정하고 움직이는 부품을 0으로 유지하세요. 리더 Agent가 더 넓은 목표를 해석하고, 다른 Agent 멤버를 끌어들이고, 그 결과를 하나의 Task로 다시 모아야 할 때 Crew를 쓰세요. 이게 정직한 규칙입니다. 작업이 진짜로 여러 부분으로 나뉠 때 Crew는 레버리지가 되고, 그렇지 않으면 군살이 됩니다.

Sprint와 Project, 카드 하나를 넘어 지속되는 추적을 위해. 로컬 보드는 오늘 내 눈앞에 있는 작업을 보여줍니다. Sprint는 일정 기간에 걸친 작업 묶음의 완료율, 담당, 의존성, 범위 변경, 블로커를 추적합니다. People과 Agent가 섞인 하이브리드 팀에게 이건 "이번 주에 에이전트가 몇 개 했다"와 실제로 보고할 수 있는 계획 사이의 차이입니다. 개발 팀을 위한 AI 에이전트 오케스트레이션 입문 글에서 팀 처리량이 모델이 아니라 조율 계층에서 갈리는 이유를 다룹니다.

팀 투명성, 화면 공유가 아니라 기본값으로. 요청부터 릴리스까지 컨텍스트, 진행 상황, 블로커, 결과, 사람의 검토를 계속 볼 수 있게 유지하세요. 로컬 보드에서 가시성은 내 모니터에서 끝났습니다. 공유 시스템에서 레버리지는 AI 채팅을 더 많이 여는 데서 나오지 않습니다. 역할, 규칙, 컨텍스트, 워크플로를 공유해서 잘 짜인 하나의 설정이 팀 전체가 재사용하는 역량이 되는 데서 나옵니다.

Vibe Kanban vs Sharkly: 공정한 비교

이 표는 점수판이 아니라 역할 분담으로 읽어 주세요. 무료 로컬 보드만 원하는 1인 개발자라면 커뮤니티가 유지하는 프로젝트가 여전히 정답일 수 있고, 거기에 머무는 걸 부끄러워할 이유는 없습니다. 실행이 공유되고, 배정 가능하고, 검토 가능해야 하는 팀이라면 보드는 언젠가 한계에 부딪힐 수밖에 없었고, Sharkly는 같은 런타임이 팀을 더한 채 계속 작동하는 곳입니다. Sharkly를 다운로드하고 Computer 하나를 연결해 실제 작업에서 차이를 확인해 보세요.

로컬 보드에서 옮겨갈 때 흔한 실수

• 같은 것을 맞바꾸는 이전으로 보는 것. 다른 보드를 찾는 게 아닙니다. 보드에 없던 팀 계층을 찾는 겁니다. 대안이 컬럼과 카드만 재현한다면 아무것도 해결하지 못한 것입니다.
• 더 빨리 가려고 worktree 격리를 버리는 것. 병렬 에이전트가 충돌하지 않는 이유가 바로 그 격리입니다. 유지하세요. 에이전트가 작업 디렉터리를 공유하게 만드는 도구는 실제 문제를 다시 떠안는 것입니다.
• 단일 에이전트 작업에 Crew를 붙이는 것. 리더 Agent가 멤버를 조율해야 하는 목표일 때만 Crew를 꺼내세요. 범위가 잘 잡힌 작업에는 Agent 하나와 움직이는 부품 0이 정답입니다.
• 생산적인 느낌을 받으려고 검토 게이트를 건너뛰는 것. 이 계층의 핵심은 사람이 결과를 승인한다는 점입니다. 빠르다는 이유로 에이전트 diff를 검토 없이 병합하면, 이 시스템 전체가 제공하려는 안전장치를 그대로 되돌려주는 셈입니다.
• 첫날에 모든 것을 옮기는 것. 실제 요구사항 하나와 위험도 낮은 Task 하나로 시작하세요. 루프를 검증한 뒤 넓혀 가면 됩니다.

결론

Vibe Kanban은 지킬 가치가 있는 패턴을 증명했습니다. 에이전트는 병렬로, 각자의 worktree에 격리되어, 검토를 진짜 단계로 두고 실행될 때 가장 잘 작동합니다. 이 패턴은 이제 최소 기준이며, 이를 버리는 Vibe Kanban 대안은 뒤로 가는 것입니다.

• 에이전트별 보드 모델은 옳았습니다. 병렬로 worktree에 격리된 에이전트와 diff 검토가 올바른 형태입니다.
• 로컬 보드는 한 대의 컴퓨터 위 한 사람에서 끝납니다. 공유 작업에는 공유 레코드가 필요합니다.
• Sharkly는 런타임, 저장소, worktree 습관을 그대로 두고 그 주위에 팀 계층을 더합니다.
• Task는 목표, 런타임, 진행 상황, 블로커, diff, 검토를 한곳에 담습니다.
• Crew, Sprint, Project는 병렬 실행을 팀이 보고할 수 있는 계획으로 바꿉니다.
• Agent는 조사하고 실행하고 테스트하고 보고하며, 사람은 방향을 정하고 권한을 부여하고 결과를 승인합니다.

앞으로 코딩 에이전트를 어디서 돌릴지 고민 중이라면, 팀이 이미 쓰는 도구는 그대로 두고 실행을 배정 가능하고 추적 가능하게 만드는 계층을 더하세요. Computer 하나를 연결하고, Agent 하나를 만들고, 지루한 일 하나를 맡겨 보세요. 그러고 나서 나머지 팀이 그 작업이 Task로 돌아오는 걸 지켜보게 하면 됩니다. Sharkly에서 시작하고, 각 개념은 docs.sharkly.ai 문서에서 더 자세히 다룹니다.

FAQ

Bloop가 종료된 뒤에도 Vibe Kanban을 쓸 수 있나요? 네. 이 프로젝트는 오픈 소스이고 여전히 로컬에서 실행할 수 있습니다. 회사가 운영하던 클라우드 기능은 제거되었고, 수정과 업데이트는 이제 커뮤니티 기여자에게 달려 있습니다. 혼자 쓰는 용도라면 괜찮을 수 있지만, 납품을 이 도구에 의존하는 팀이라면 유지보수 리스크를 저울질해 볼 만합니다.

Sharkly는 Claude Code나 Codex를 대체하나요? 아닙니다. Sharkly는 Claude Code, Codex 또는 다른 실행 도구를 대체하지 않습니다. 실행은 그 런타임들이 담당합니다. Sharkly는 그 주위에 공유 Task, Computer, 컨텍스트, 제어, 검토 계층을 더합니다. 같은 에이전트를 계속 쓰시면 됩니다.

병렬 worktree에서 에이전트를 돌리는 걸 포기해야 하나요? 아닙니다. Sharkly는 연결된 Computer의 격리된 worktree에서 에이전트를 실행합니다. 에이전트별 보드 모델이 의지했던 것과 동일한 격리입니다. 프런트엔드, 백엔드, 테스트가 충돌 없이 동시에 진행될 수 있습니다. 바탕이 되는 패턴은 여러 Claude Code 에이전트를 병렬로 실행하는 방법을 참고하세요.

로컬 보드에서 마이그레이션하려면 실제로 무엇을 해야 하나요? 런타임과 저장소는 그대로 두세요. Computer를 연결하고, 이미 쓰는 실행 도구를 Sharkly에 지정하고, 작업을 공유 Task로 라우팅하기 시작하면 됩니다. 모델 사용은 해당 도구에 이미 설정된 구독이나 API 키를 통해 계속되므로 과금은 바뀌지 않습니다.

Sharkly를 쓰지 말아야 할 때는 언제인가요? 한 대의 컴퓨터에서 혼자 작업하고, 다른 누구도 그 작업을 보거나 검토할 필요가 없다면 로컬 보드로 충분합니다. 두 번째 사람이 에이전트 실행을 배정하거나 이어받거나 검토해야 하는 순간 Sharkly가 제 몫을 합니다.

카드와 Task의 차이는 무엇인가요? 로컬 보드의 카드는 나의 것이고 내 컴퓨터에 있습니다. Task는 팀의 공유 레코드로, 목표, 배정된 Agent, 런타임, 진행 상황, 블로커, diff, 사람의 검토를 담고 있고 실행 결과가 여기로 돌아옵니다.