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

> Clean Markdown view of GeekNews topic #29830. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29830](https://news.hada.io/topic?id=29830)
- GeekNews Markdown: [https://news.hada.io/topic/29830.md](https://news.hada.io/topic/29830.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-25T03:35:04+09:00
- Updated: 2026-05-25T03:35:04+09:00
- Original source: [kanbots.dev](https://www.kanbots.dev/)
- Points: 1
- Comments: 1

## Topic Body

- **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을 제공함
  - Enterprise 기능에는 감사 로그, SSO / SCIM, REST API와 PAT, 아웃바운드 웹훅이 포함됨
  - Cloud 전용 기능은 다른 사람이나 다른 기기가 있어야 의미 있는 기능으로 제한되며, 한 명이 한 기계에서 쓰는 기능은 OSS에 포함됨

### 지원 도구와 연동
- **Claude Code**와 **Codex** CLI를 지원함
- GitHub Issues와 PR 작업을 지원함
- Sentry 오류 가져오기를 지원함
- Cursor와 Claude Desktop은 **MCP 클라이언트**로 연동 가능함
- 로컬 저장소는 SQLite를 사용함
- 데스크톱 셸은 Electron 기반으로 제공됨

### 핵심 기능
- ## 병렬 카드 실행
  - 여러 카드에서 에이전트를 동시에 실행할 수 있으며, 각 실행은 자체 git worktree와 `kanbots/issue-N` 브랜치에서 진행됨
  - 보드는 실행 진행, 에이전트의 결정 요청, 비용 누적을 실시간으로 갱신함
- ## 자동 실행과 페르소나
  - 제품, 엔지니어, 리뷰어, 테스터 같은 **페르소나**를 연결하고 병렬도는 최대 4까지 설정할 수 있음
  - 오케스트레이터가 페르소나를 라운드로빈으로 순회하고, 상위 이슈를 하위 작업으로 나누며, 에이전트가 발견한 작업으로 백로그를 갱신함
  - 페르소나가 다른 페르소나를 생성할 수 있음
- ## 결정 중심 실행
  - 에이전트는 필요한 결정을 만나면 멈추고 선택지를 표시함
  - 사용자는 번호 선택, 수정 후 재제출, `/spec`, `/review`, `/split` 같은 슬래시 명령으로 실행을 이어갈 수 있음
  - 작업 트리를 조용히 바꾸는 대신 검토 가능한 결정 흐름을 남김
- ## Claude Code와 Codex 통합
  - Claude Code 또는 Codex를 같은 보드, 같은 worktree, 같은 결정 UI에서 사용할 수 있음
  - KanBots는 단일 **AgentCliAdapter** 뒤에서 두 스트림 형식을 처리함
  - 기존 `claude /login` 또는 `OPENAI_API_KEY`를 사용할 수 있음
- ## 로컬 우선 저장
  - 모든 데이터는 저장소 옆 `.kanbots/` 안에 위치함
  - SQLite 데이터베이스, 설정, worktree가 로컬에 저장됨
  - 클라우드 계정, 원격 측정, HTTP 서버가 없고 코드가 기계를 떠나지 않음
- ## 비용 분석과 예산 제한
  - 실행별, 카드별, 프로젝트별 비용 집계를 제공함
  - 에이전트 작업 중 비용 미터가 누적됨
  - 실행별·세션별 한도를 설정할 수 있고, 예산에 도달하면 실행이 중단됨
- ## GitHub 워크플로
  - 개인 PAT로 실제 GitHub 이슈를 다룰 수 있음
  - worktree를 커밋으로 승격하거나, 한 번의 클릭으로 초안 PR을 열 수 있음
  - 사전 푸시 훅을 통해 에이전트가 스스로 게시하지 못하게 함
- ## MCP 서버
  - `kanbots-mcp-server`가 Model Context Protocol을 통해 보드를 노출함
  - Cursor, Claude Desktop 또는 MCP를 이해하는 도구가 보드를 다룰 수 있음
  - 보드가 다른 에이전트가 사용할 수 있는 도구가 됨

### 앱 내부 워크플로
- ## Autopilot
  - 하나 이상의 페르소나를 선택하고 병렬도를 설정한 뒤 자동 실행을 시작함
  - 최대 4개의 병렬 슬롯이 페르소나 목록을 라운드로빈으로 순회함
  - 각 슬롯은 다음 페르소나를 원자적으로 가져오고, 에이전트는 진행 중 상위 이슈를 하위 작업으로 나눔
  - 완료 또는 세션 예산 도달 시 중단됨
  - 예시 화면에는 Claude Opus 4.7, `medium` effort, 병렬도 2, Product Manager와 Senior Engineer 페르소나가 선택된 상태가 표시됨
- ## Decisions
  - 실행 스레드는 모든 `tool_use`와 `tool_result`를 실시간으로 스트리밍함
  - 에이전트가 판단이 필요한 지점에서 실행을 멈추고 번호가 붙은 선택지를 제시함
  - 답장 입력창은 `/spec`, `/review`, `/split` 같은 명령을 받음
  - 비밀번호 재설정 토큰 구현 예시에서는 단일 사용 JWT, DB 저장 불투명 토큰, 매직 링크, 먼저 트레이드오프 설명 같은 선택지가 표시됨
  - 실행 화면에는 모델, 경과 시간, 토큰 수, 비용, 상태, 우선순위, 폴더, worktree, 브랜치, 기준 브랜치, 작성자가 표시됨
- ## Personas
  - **페르소나**는 이름이 붙은 시스템 프롬프트 조각임
  - 기본 페르소나는 앱에 포함되며, 사용자가 새 페르소나를 작성해 저장하고 재사용할 수 있음
  - 사용자 정의 페르소나는 해당 기계에 로컬로 저장됨
  - 기본 예시로 Product Manager, Senior Engineer, UX Designer, Growth Lead, Reliability Engineer가 제공됨
- ## Providers
  - Claude Code와 Codex를 하나의 `AgentCliAdapter` 뒤에서 사용할 수 있음
  - 기존 `claude /login` 또는 `codex login`을 재사용하며, 추가 계정이나 추가 키 관리가 필요 없음
  - 실행마다 공급자를 전환할 수 있음
  - Codex CLI는 `codex`가 `PATH`에 있어야 하며, 이슈 초안 작성과 Sentry 분석은 여전히 Claude에서 실행됨
  - Codex 로그인은 브라우저에서 `auth.openai.com`을 열거나 환경 변수 `OPENAI_API_KEY`를 사용할 수 있음
- ## Tasks
  - 새 작업은 버그 수정, 기능, 리팩터링, 리뷰, 스파이크 템플릿을 제공함
  - 시작 방식은 **spec-first**, 생성 후 즉시 실행, 나중에 큐에 넣기 중 선택함
  - 제목은 브랜치와 PR 제목으로 사용됨
  - `spec-first`는 `/spec`을 실행해 인수 조건을 다듬고 승인 대기 상태로 둠
  - 새 작업은 fresh worktree를 만들고, `main` 기준으로 `.kanbots/worktrees/issue-N` 아래 브랜치를 생성함
- ## Chat
  - 워크스페이스에 대해 질문할 수 있는 범용 에이전트가 제공됨
  - 에이전트는 저장소, 테스트, git 상태를 알고 질문에 답함
  - rate limiting이 없는 API 라우트를 찾고, `/api/login`과 `/api/signup`에 `rateLimit({ windowMs: 60_000, max: 10 })`을 추가한 뒤 테스트를 작성해 통과시키는 예시가 제시됨

### Autopilot의 동작 방식
- **Autopilot**은 이슈와 예산을 받아 백로그를 스스로 갱신하는 모드임
- 오케스트레이터가 페르소나 목록을 라운드로빈으로 순회하고, 최대 4개 슬롯을 병렬로 실행함
- 상위 이슈를 하위 작업으로 나누고, 작업이 수렴하거나 비용 한도에 도달할 때까지 순환함
- 예시에는 병렬도 4, 모델 `opus 4.7`, 세션 예산 $25.00 중 $4.27 사용, 14번째 사이클 상태가 표시됨
- ## 페르소나 목록 선택
  - 기본 페르소나를 사용하거나 직접 시스템 프롬프트를 정의해 저장하고 재사용할 수 있음
  - 사용자 정의 페르소나는 기계를 떠나지 않음
- ## 병렬도 설정
  - 병렬도는 1부터 4까지 설정 가능함
  - 각 슬롯은 라운드로빈 카운터를 통해 다음 페르소나를 원자적으로 가져감
  - 네 에이전트가 네 관점과 네 worktree에서 동시에 실행될 수 있음
- ## 작업 분할
  - 에이전트가 작업을 발견하면 새 카드를 보드에 생성함
  - 이후 사이클이 새 카드를 가져가며 백로그가 오케스트레이터 아래에서 늘어나고 줄어듦
- ## 예산 또는 완료 시 중단
  - 세션별 비용 예산이 전체 지출을 제한함
  - 중지 버튼은 부모 실행과 모든 자식 실행을 종료함
  - 진행 중인 실행은 현재 반복을 깨끗하게 마침

### QA 모드
- **QA 모드**는 worktree 안에서 typecheck, tests, lint, build, e2e를 실행함
- 필요하면 개발 서버를 시작하고 감시할 수 있음
- 실패한 각 검사에 대해 파생된 자식 이슈에서 수정 실행을 배정함
- 검사가 통과할 때까지 반복함

### 제공 방식과 마무리
- OSS 데스크톱 앱은 무료, MIT 라이선스, 계정 없음 방식으로 제공됨
- 모든 에이전트 실행을 칸반 위에 올려 가시화하고, 결정 가능하게 만들고, 격리하는 흐름을 강조함
- 팀이 보드를 공유해야 할 때는 Cloud로 전환할 수 있음
- 다운로드 형식은 macOS `.dmg`, Windows `.exe`, Linux `.AppImage` / `.tar.xz`임

## Comments



### Comment 58161

- Author: neo
- Created: 2026-05-25T03:35:04+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48239413) 
- 에이전트가 **밤새 작업한 결과**를 사람들이 어떻게 받아들이는지 계속 의문이 듦  
  개인 사이드 프로젝트 저장소에서도 30분 계획하고 30분 구현한 결과는 검토하기에 너무 크다고 느낌. 5분쯤 지나면 코드가 쏟아지는 중에도 AI에게 다시 하라고 시킬 때가 있음
  - 요즘 서사는 AI가 코드의 전부나 대부분을 쓴다는 쪽에 집중돼 있지만, 실제로는 **사람이 검토한 코드 비율**이 사람들이 깨닫거나 인정하는 것보다 훨씬 빠르게 0에 가까워지고 있을 것 같음
  - 그런 에이전트 활동의 상당 부분은 이전에 만든 것을 훑고, 제약을 강제로 걸어서 검토할 때 책상 위에 올라올 결과를 어느 정도 예측 가능하게 만드는 일임  
    개인적으로는 **강한 파일 구조**도 도움이 됨. 방금 생성한 3,000줄짜리 파일을 검토하는 건 최악이고, 사람에게도 기계에게도 그런 결과는 받지 않을 것임. 알맞은 위치에 여러 파일로 나뉘어 있으면 인지 부담이 줄어듦  
    때로는 에이전트와 대화하면서 같이 검토함. 먼저 검토할 가장 중요한 파일이 무엇인지 묻는 식임  
    변경 사항을 “LGTM” 더미에 스테이징해 두는 걸 좋아함. 이후 수정이 필요하면 에이전트에게 “스테이징되지 않은 변경을 검토해줘. 여기서는 다른 방식으로 해줬으면 해”라고 시킴
  - 아무도 코드를 검토하지 않음. 관리자들도 우리가 코드를 검토하길 원하지 않음. 병목이기 때문임  
    뭔가 잘못되면, 즉 버그가 생기면 그때그때 고침. 소프트웨어 엔지니어링의 매우 슬픈 시대임. 우리 업계에 엔지니어링이란 게 있었다면 이제는 대부분 사라졌고, “버그를 넣지 말아줘”나 “너는 세입자가 아니라 소유자야” 같은 **skills 파일**을 쓰며 대충 짐작하고 있음  
    노력 수준도 낮고 결정성도 매우 낮음. GitHub 같은 큰 앱들이 AI 쓰레기 때문에 계속 내려가고 있고, 덜 유명한 시스템에서도 더 자주 보임. 우리 회사나 우리가 쓰는 다른 SaaS에서도 마찬가지임  
    제품 관리자는 원래 코드에 관심이 없었고, 엔지니어링 관리자는 엔지니어였을 때만큼 코드에 관심이 없음. 디렉터는 코드에 전혀 신경 쓰지 않고, CTO는 이제 코드가 어떻게 생겼는지도 모름  
    우리는 사슬의 끝에 있고, 좋은 시스템은 좋은 코드 위에 세워진다는 걸 깊이 알았기 때문에 잘 쓰이고 유지보수 가능한 코드에 자부심을 가져왔음. 그런데 이제는 우리 스스로를 위험에 빠뜨리고 있고, 코드에 더 이상 신경 쓰지 않는 쪽이 바로 엔지니어인 우리이며 AI가 그 문제를 증폭하고 있음
  - 보통 Claude가 밤새 작업한 뒤 최종적으로 **약 500줄의 코드**만 남기도록 목표를 잡음  
    대부분의 시간은 여러 접근법을 실험하고 요약한 뒤, 내가 검토하고 수정할 수 있는 비교적 작은 차이를 주는 데 쓰임
  - 나도 같은 의문이 듦. 실제로 잘 운용하는 사람들에게서 보통 듣는 답은 코드를 보지 않는다는 것, 적어도 자세히 보지는 않는다는 것임  
    개인적으로는 에이전트가 만든 결과를 늘 뭔가 손보게 됨. 그 통제를 내려놓아야 하는지 고민됨

- 이건 대부분의 프로젝트에서 코딩 에이전트를 관리할 때 쓰는 **Vibe Kanban**([https://vibekanban.com/](<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에서 이 프로젝트를 보니 반가움  
    작업 내용을 따라가보는 게 즐거울 것 같음
  - Stripe 개발 블로그의 **minions** 글을 확인해보면 좋겠음. 방향성이 비슷해 보임

- 이건 기본적으로 Windsurf가 하고 있는 것 아닌가? 결국 이런 모든 UI는 에이전트 위에 얹힌 **겉치장**일 뿐임  
  [0] [https://windsurf.com/blog/windsurf-2-0](<https://windsurf.com/blog/windsurf-2-0>)
  - Kanban 보드에서 에이전트에게 넘기는 걸 돕는 앱은 몇 가지 있음  
    내게는 더 **사람이 개입하는 흐름**이 필요했음. 변경 집합을 잘 볼 수 없고 방향을 틀 기회도 없이 에이전트에게 넘기는 방식은 맞지 않음  
    [https://www.agentkanban.io](<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’가 손상되어 열 수 없습니다. 휴지통으로 이동해야 합니다”라니  
  **바이브 코딩 소프트웨어**에서 처음 마주치기에 너무 어울리는 오류임

- 이건 그냥 vibe-kanban 아닌가?  
  [https://github.com/BloopAI/vibe-kanban](<https://github.com/BloopAI/vibe-kanban>)
  - 경쟁자는 존재할 수 있음
  - 말 그대로 Bloop에 올라와 있음. Bloop 원작임