채팅만으로는 부족했다: GitHub Kanban으로 AI 봇 팀 운영하기

왜 채팅만으로는 부족했나

처음에는 Discord thread만으로도 충분해 보였습니다.

• 사람과 봇을 빠르게 호출할 수 있고
• 짧은 질문과 즉석 조율이 쉽고
• 실행 속도도 빠릅니다

하지만 작업이 2개, 3개, 여러 프로젝트로 늘어나면 바로 문제가 생깁니다.

• 누가 맡았는지 헷갈림
• 지금 막힌 이유가 남지 않음
• 결과물이 thread 안에 묻힘
• 며칠 뒤 다시 보면 "뭐가 끝났고 뭐가 남았지?"가 반복됨

채팅은 실행 인터페이스로는 훌륭하지만, 지속 기억 계층으로는 약합니다.

---

왜 GitHub Issue만으로도 부족했나

반대로 모든 걸 GitHub Issue로만 시작하면 durable 하긴 합니다.

• 기록이 남고
• PR과 연결되고
• 상태 추적이 쉽습니다

그런데 봇 협업 초반에는 이 방식도 답답했습니다.

• 작은 탐색 질문까지 issue로 만들면 오버헤드가 큼
• 아직 owner가 안 정해진 아이디어도 많음
• 범위가 작은 실험은 채팅 한두 번으로 끝날 수 있음

즉, GitHub는 잠그는 곳으로 좋지만, 탐색 시작점으로는 무거울 수 있습니다.

---

그래서 나온 운영 모델: Discord + GitHub Kanban

제가 정리한 권장 모델은 이렇습니다.

1. Discord는 intake

Discord에서는 이런 일을 합니다.

• 사람의 요청 받기
• 봇 호출하기
• 짧은 질문/탐색
• 범위 줄이기
• 중간 진행 공유

즉, 빠른 대화와 조율은 Discord가 맡습니다.

2. GitHub Project는 control tower

GitHub Kanban에서는 이런 일을 합니다.

• 현재 상태 추적
• owner 지정
• 우선순위 정리
• blocker 기록
• PR / 문서 / issue 연결
• 여러 봇과 여러 프로젝트를 가로지르는 시야 확보

즉, 책임과 상태를 durable 하게 잠그는 곳이 GitHub입니다.

---

실제로 중요한 것은 "상태 컬럼"보다 "카드 계약"이다

처음엔 보드에 Ready, Review, Blocked 같은 상태를 많이 두고 싶어집니다.
그런데 봇 협업에서는 상태를 세분화하는 것보다 봇이 해석 가능한 최소 계약이 더 중요했습니다.

현재 제가 권장하는 최소 상태는 3개입니다.

• Todo
• In progress
• Done

그리고 봇이 실제로 카드를 집으려면 아래 정보가 꼭 있어야 합니다.

• Owner
• Type
• Priority
• Blocker
• Human required
• Related thread
• Repository

핵심은 이겁니다.

Ready는 별도 컬럼이 아니라, issue-backed Todo + 필요한 정보가 다 채워진 상태입니다.

이 기준이 없으면 봇은 카드를 집지 못하거나, 반대로 잘못 집게 됩니다.

---

Draft 카드는 왜 위험한가

GitHub Project의 Draft item은 생각보다 편합니다.
빠르게 메모를 남기고, 나중에 정리할 수 있으니까요.

하지만 멀티봇 운영에서는 Draft가 오래 남아 있으면 문제가 됩니다.

• 실행 가능한 일인지 애매함
• 어느 repo 기준인지 불명확함
• 누가 집어야 하는지 모호함
• 봇 입장에서는 그냥 intake 메모인지 실제 backlog인지 구분이 안 됨

그래서 제 기준은 단순합니다.

• DraftIssue는 intake 전용
• 실행 대상으로 넘길 카드는 가능한 빨리 issue로 승격

이 규칙 하나만 있어도 보드가 훨씬 깔끔해집니다.

---

봇별로 같은 보드를 다 보게 하면 안 된다

여기서 또 중요한 점이 있습니다.

모든 봇이 모든 카드를 읽게 하면, 자동화가 아니라 충돌이 됩니다.

그래서 각 봇은 자기 lane만 보게 해야 합니다.

예를 들면:

• Neo: triage, 우선순위, owner 정리
• Morpheus: 구현, 버그 수정, infra
• Kusanagi: 문서, 리서치, release notes
• Batou: risk, approval boundary, security review
• Tachikoma: waiting, follow-up, monitoring

이렇게 하면 같은 보드를 공유하더라도 각 봇은 다른 역할로 움직입니다.

즉, 보드는 하나지만 행동 규칙은 owner/type 기준으로 분리됩니다.

---

봇이 카드를 집어도 되는 조건

아래 조건이 맞을 때만 봇이 자동으로 움직이게 하는 것이 좋습니다.

• owner가 자신으로 지정되어 있음
• Status가 Todo 또는 In progress
• Owner, Type, Blocker가 비어 있지 않음
• 외부 승인이나 민감 권한이 필요하지 않음
• 작업 범위가 문서화 / 작은 구현 / 내부 정리에 해당함

반대로 아래 조건이면 멈춰야 합니다.

• owner가 다른 사람/봇임
• blocker가 아직 해소되지 않음
• 배포, 공개, 결제, secret 변경이 걸려 있음
• 카드 설명이 너무 모호함
• 아직 Draft item 상태임

이 멈춤 규칙이 없으면, 봇은 열심히 일하지만 팀은 더 혼란스러워집니다.

---

이 방식의 가장 큰 장점

이 모델의 장점은 단순히 "칸반을 쓴다"가 아닙니다.

1. 사람이 매번 직접 호출하지 않아도 된다

봇은 자기 lane의 pickup-ready 카드를 보고 움직일 수 있습니다.

2. 중간 상태가 남는다

"왜 아직 안 했는지"가 blocker로 남습니다.

3. 결과물이 흩어지지 않는다

PR, issue, 문서, thread가 한 카드에 다시 연결됩니다.

4. 멀티프로젝트 운영이 가능해진다

하나의 control tower에서 cross-project 시야를 확보할 수 있습니다.

5. 봇의 실수를 줄인다

카드 계약이 없으면 봇은 추정합니다.
계약이 있으면 추정 대신 확인하고, 부족하면 되돌립니다.

---

시작은 작게 하는 게 맞다

처음부터 모든 봇, 모든 프로젝트, 모든 상태를 한 번에 넣을 필요는 없습니다.

오히려 이렇게 시작하는 편이 좋습니다.

Phase 1

• GitHub Project 하나 생성
• 상태는 Todo / In progress / Done 세 개만 사용
• Neo + 구현 봇(Morpheus)만 먼저 연결

Phase 2

• 문서/리서치 봇 추가
• blocker / approval 경계 정리
• PR/문서 링크 연결 습관 만들기

Phase 3

• waiting/follow-up/monitoring bot 추가
• cron 기반 daily sweep 도입
• cross-project 운영으로 확장

핵심은 보드를 크게 만드는 게 아니라, 봇이 안전하게 해석할 수 있는 운영 계약부터 만드는 것입니다.

---

운영하면서 얻은 가장 큰 교훈

가장 중요한 건 툴이 아니라 계약이었습니다.

봇 협업에서 GitHub Kanban이 잘 작동하려면:

• status가 단순해야 하고
• owner가 명확해야 하고
• blocker가 글로 남아야 하고
• Draft와 ready를 구분해야 하고
• 완료 기준이 GitHub artifact와 연결되어야 합니다.

정리하면 이렇습니다.

채팅은 속도를 주고, GitHub Kanban은 기억과 책임을 준다.
멀티봇 협업은 그 둘을 연결할 때 가장 안정적으로 굴러갑니다.

---

마무리

저는 지금 봇 협업을 위해 GitHub Kanban을 단순한 todo board가 아니라,
여러 bot이 같은 현실을 공유하는 control surface로 보고 있습니다.

사람은 요청하고 조율하고,
봇은 자기 lane을 보고 움직이고,
GitHub는 그 결과를 durable 하게 남깁니다.

이 구조가 잡고, 봇 협업이 어떻게 성장하는지 보게 될 것 같습니다. 제 기대는 그때부터 "대화"에서 운영 시스템이 되는 것입니다.