13개의 AI 에이전트로 소프트웨어를 출시합니다. 실제 모습은 이렇습니다

이것이 지금 제 터미널입니다.

13개의 Claude Code 에이전트가 각자의 tmux 페인에서 같은 코드베이스로 작업하고 있습니다. 실험이 아닙니다. 과시도 아닙니다. 매일 소프트웨어를 출시하는 방법이 바로 이것입니다.

프로젝트는 Beadbox입니다. AI 코딩 에이전트를 모니터링하는 리얼타임 대시보드입니다. 모니터링 대상인 에이전트 플릿이 직접 Beadbox를 구축합니다. 에이전트가 코드를 작성하고, 테스트하고, 리뷰하고, 패키징하고, 출시합니다. 저는 조율합니다.

2~3개 이상의 에이전트를 실행하면서 모든 에이전트가 무엇을 하는지 파악하는 방법을 고민하고 있다면, 수개월의 이터레이션 끝에 도달한 형태가 이것입니다.

편성

모든 에이전트에 CLAUDE.md 파일이 있습니다. 에이전트의 정체성, 담당 범위, 담당하지 않는 범위, 다른 에이전트와의 커뮤니케이션 방법을 정의합니다. "아무거나 다 하는" 범용 어시스턴트가 아닙니다. 각각 좁은 업무와 명확한 경계를 갖습니다.

핵심 단어는 경계입니다. eng2는 이슈를 클로즈할 수 없습니다. qa1은 코드를 작성하지 않습니다. pmm은 앱 소스에 손대지 않습니다. super는 작업을 디스패치하지만 구현하지 않습니다. 경계가 존재하는 이유는 경계가 없으면 에이전트가 드리프트하기 때문입니다. 리팩토링이 필요 없는 코드를 리팩토링해서 "도와주려" 하고, 검증되지 않은 이슈를 클로즈하고, 자격이 없는 아키텍처 결정을 내립니다.

모든 CLAUDE.md는 정체성 단락과 경계 섹션으로 시작합니다. eng2의 간략 버전입니다:

## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests.
You own implementation quality: the code you write is correct, tested,
and matches the spec.

## Boundary with QA
QA validates your work independently. You provide QA with executable
verification steps. If your DONE comment doesn't let QA verify without
reading source code, it's incomplete.

이 패턴은 스케일합니다. 3개 에이전트로 시작했을 때는 하나의 느슨한 프롬프트를 공유할 수 있었습니다. 13개에서는 명시적인 역할과 프로토콜이 코디네이션과 카오스의 차이입니다.

코디네이션 레이어

3가지 도구가 플릿을 하나로 묶습니다.

**beads**는 정확히 이 워크플로를 위해 만들어진 오픈소스 Git 네이티브 이슈 트래커입니다. 모든 태스크는 상태, 우선순위, 의존성, 코멘트 스레드를 가진 "bead"입니다. 에이전트는 bd라는 CLI를 통해 같은 로컬 데이터베이스를 읽고 씁니다.

bd update bb-viet --claim --actor eng2   # eng2가 버그를 담당
bd show bb-viet                           # 전체 스펙 + 코멘트 확인
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2가 플랜 게시

gn / gp / ga는 tmux 메시징 도구입니다. gn은 다른 에이전트의 페인에 메시지를 보냅니다. gp는 다른 에이전트의 최근 출력을 엿봅니다(중단 없이). ga는 긴급하지 않은 메시지를 큐에 넣습니다.

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # 디스패치
gp eng2 -n 40                                               # 진행 상황 확인
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # 보고

CLAUDE.md 프로토콜이 에스컬레이션 경로, 커뮤니케이션 포맷, 완료 기준을 정의합니다. 모든 에이전트가 알고 있습니다: bead를 담당하고, 코딩 전에 플랜을 코멘트하고, 푸시 전에 테스트를 실행하고, 검증 단계와 함께 DONE을 코멘트하고, QA 대기로 마킹하고, super에게 보고합니다.

super는 5~10분마다 패트롤 루프를 실행합니다: 각 활성 에이전트의 출력을 엿보고, bead 상태를 확인하고, 파이프라인이 정체되지 않았는지 검증합니다. 프로덕션 온콜 로테이션과 같지만, 서비스가 AI 에이전트이고 인시던트가 "eng2가 20분째 수상하게 조용하다"인 것입니다.

실제 하루

2026년 2월 하순 수요일에 실제로 일어난 일입니다.

오전 9:14 - GitHub 사용자 ericinfins가 Issue #2를 엽니다: Beadbox를 리모트 Dolt 서버에 연결할 수 없습니다. 앱은 로컬 연결만 지원합니다. owner가 이를 보고 super에게 플래그합니다.

오전 9:30 - super가 작업을 디스패치합니다. arch가 연결 인증 플로(TLS 토글, 사용자명/비밀번호 필드, 환경 변수 전달)를 설계합니다. PM이 수락 기준이 포함된 스펙을 작성합니다. eng가 픽업하여 구현을 시작합니다.

그 사이, 병렬로:

PM이 릴리스 테스트 중 발견한 2개의 버그를 등록합니다. 하나는 외관상의 문제: 헤더 배지가 최종 빌드에서 "v0.10.0"이 아닌 "v0.10.0-rc.7"을 표시합니다. 다른 하나는 플랫폼별 문제: 스크린샷 자동화 도구가 ARM64 Mac에서 빈 띠를 반환합니다. Apple Silicon이 Tauri의 WebView를 Metal 합성으로 렌더링하여 배킹 스토어가 비어 있기 때문입니다.

ops가 스크린샷 버그의 근본 원인을 파악합니다. 수정은 깔끔합니다: 캡처 후 이미지 높이가 의심스럽게 작은지(800px여야 할 윈도우에 50px 미만인지) 확인하고, 좌표 기반 화면 캡처로 폴백합니다.

growth가 PostHog 데이터를 가져와서 IP 상관 분석을 실행합니다. 발견: Reddit 광고가 96클릭에 귀속 가능한 리텐션 사용자 제로. GitHub README 트래픽은 15.8% 전환. 이 글이 존재하는 이유가 바로 그 분석 결과입니다.

eng1이 arch의 Activity Dashboard 설계로 언블로킹되어 크로스 필터 상태 관리와 유틸리티 함수 구축을 시작합니다. 687개 테스트 통과.

qa1이 헤더 배지 수정을 검증합니다: 테스트 서버를 띄우고, 브라우저 자동화로 배지가 올바르게 렌더링되는지 확인하고, 665개 유닛 테스트가 통과하는지 확인하고, PASS를 마킹합니다.

오후 2:45 - shipper가 릴리스 후보 PR을 머지하고, v0.10.0 태그를 푸시하고, 프로모트 워크플로를 트리거합니다. CI가 5개 플랫폼(macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe)의 아티팩트를 빌드합니다. shipper가 각 아티팩트를 검증하고, 양쪽 리포지토리의 릴리스 노트를 업데이트하고, 웹사이트를 재배포하고, Homebrew cask를 업데이트합니다.

오후 3:12 - owner가 GitHub Issue #2에 답변합니다:

Good news: v0.10.0 just shipped with full Dolt server auth support. Update and you should be unblocked.

오전에 보고된 버그가 오후에 수정되어 출시되었습니다. 그리고 그 사이에 다음 기능이 설계되고, 다른 버그의 근본 원인이 분석되고, 애널리틱스가 해석되고, QA가 독립적으로 별도의 수정을 검증하고 있었습니다.

13개 에이전트가 빠르기 때문이 아닙니다. 13개 에이전트가 병렬이기 때문입니다.

잘못되는 것들

"이런 AI 셋업을 사용합니다" 류의 글이 대부분 빼놓는 부분입니다.

높은 동시성에서 레이트 리밋에 부딪힙니다. 13개 에이전트가 모두 같은 API 계정으로 실행되면 토큰을 빠르게 소모합니다. 이 특정 날에는 super, eng1, eng2가 동시에 레이트 리밋 상한에 도달했습니다. 모두 멈춥니다. 기다리는 수밖에 없습니다. 사무실의 모든 사람이 동시에 프린터를 쓰려는 것의 AI 버전이지만, 프린터는 페이지당 과금되고 분당 페이지 수에 상한이 있습니다.

QA가 작업을 되돌립니다. 이것은 설계에 의한 것이지만 사이클이 추가됩니다. QA가 빌드를 리젝했습니다. 엔지니어의 "DONE" 코멘트에 검증 단계가 없었기 때문입니다. 수정은 동작했지만 QA가 소스 코드를 읽지 않고는 확인할 수 없었습니다. eng에게 되돌리고, 완료 코멘트를 재작성하고, QA에 다시 돌리고, 재검증. 5분이면 될 일에 20분이 걸렸습니다. 프로토콜이 마찰을 만들지만, 그 마찰은 하중을 지탱합니다. QA를 건너뛸 때마다 프로덕션에서 무언가가 깨졌습니다.

컨텍스트 윈도우가 차갑니다. 에이전트는 세션 중 컨텍스트를 축적합니다. super에는 컨텍스트 사용률 65%에서 "작업을 저장하라" 디렉티브를 보내는 프로토콜이 있습니다. 그 타이밍을 놓치면 에이전트가 하던 일을 잃어버립니다.

에이전트가 막힙니다. 에이전트가 에러 루프에 빠져서 같은 실패 명령을 계속 재시도하는 경우가 있습니다. super의 패트롤 루프가 이를 잡아내지만, 충분한 빈도로 확인할 때만 가능합니다. 정중하게 침묵 속에서 실패하던 에이전트에 30분을 낭비한 적이 있습니다.

코디네이션 오버헤드는 현실입니다. CLAUDE.md 파일, 디스패치 프로토콜, 패트롤 루프, bead 코멘트, 완료 리포트. 2개 에이전트 셋업에는 과잉입니다. 13개에서는 최소한의 구조입니다. 비공식적 코디네이션이 작동을 멈추고 명시적 프로토콜 없이는 무슨 일이 일어나는지 파악할 수 없게 되는 크로스오버 포인트가 약 5개 에이전트 즈음에 있습니다.

배운 것

전문화가 범용화를 이깁니다. 포커스된 13개 에이전트가 "풀스택" 3개 에이전트를 능가합니다. qa1이 검증만 하고 코드를 작성하지 않을 때, eng가 놓친 것을 매번 잡아냅니다. arch가 설계만 하고 구현하지 않을 때, 구현을 쉽게 하려고 스펙을 간소화하는 유혹이 없어 설계가 깔끔해집니다.

독립적 QA는 타협할 수 없습니다. QA는 자체 리포지토리 클론을 갖고 있습니다. 워킹 트리가 아닌 푸시된 코드를 테스트합니다. 엔지니어의 자체 보고를 신뢰하지 않습니다. 느리게 느껴질 수 있습니다. 매 릴리스마다 버그를 잡아냅니다.

가시성이 없으면 플릿이 드리프트합니다. 5개 이상의 에이전트에서는 tmux 페인을 전환하며 머릿속으로 bd list를 실행하는 것만으로는 상태를 추적할 수 없습니다. 의존성 트리, 어떤 에이전트가 무엇을 작업하고 있는지, 어떤 bead가 블로킹되어 있는지를 보여주는 대시보드가 필요합니다. 이것이 Beadbox를 만든 이유입니다.

재귀 루프가 중요합니다. 에이전트가 Beadbox를 구축합니다. Beadbox가 에이전트를 모니터링합니다. 에이전트가 Beadbox에 버그를 만들면, 다른 모든 버그를 잡아낸 것과 같은 QA 프로세스로 플릿이 그것을 잡아냅니다. 도구가 개선되는 이유는 가장 많이 사용하는 팀이 그것을 만드는 팀이기 때문입니다. 이것이 천재적인지 역사상 가장 정교한 루브 골드버그 머신인지 자각하고 있습니다. 출시된 기능은 전자를, 토큰 청구서는 후자를 시사합니다.

스택

직접 시도해 보고 싶다면 필요한 것은 다음과 같습니다:

• beads: 오픈소스 Git 네이티브 이슈 트래커. 코디네이션의 백본입니다. 모든 에이전트가 이것을 읽고 씁니다.
• Claude Code: 에이전트 런타임. 각 에이전트는 자체 CLAUDE.md 아이덴티티 파일이 있는 tmux 페인의 Claude Code 세션입니다.
• tmux + gn/gp/ga: 에이전트를 나란히 실행하는 터미널 멀티플렉서. 메시징 도구로 공유 메모리 없이 에이전트 간 통신이 가능합니다.
• Beadbox: 플릿이 무엇을 하고 있는지 보여주는 리얼타임 비주얼 대시보드. 지금 읽고 있는 것이 바로 이것입니다.

시작부터 13개 에이전트가 전부 필요하지 않습니다. 엔지니어 2개와 QA 에이전트 1개를 beads로 코디네이션하면, 한 명의 개발자가 무엇을 출시할 수 있는지에 대한 사고방식이 바뀝니다.

다음은 무엇인가

현재 셋업에서 가장 큰 공백은 세 가지 질문에 한눈에 답하는 것입니다: 어떤 에이전트가 활성, 유휴, 또는 멈춰 있는가? 파이프라인 어디에 작업이 쌓이고 있는가? 그리고 내가 관심 있는 에이전트나 파이프라인 단계로 필터링했을 때, 방금 무슨 일이 있었는가?

지금은 순찰 루프와 수많은 gp 명령이 필요합니다. 그래서 Beadbox에 직접 코디네이션 대시보드를 구축하고 있습니다: 상단에 에이전트 상태 스트립, beads가 어디에 축적되고 있는지 보여주는 파이프라인 플로우, 그리고 에이전트나 파이프라인 단계를 클릭하면 나머지 모든 것이 그에 맞춰 필터링되는 크로스 필터 이벤트 피드. 세 레이어 모두 같은 실시간 데이터 소스를 공유합니다. 세 레이어 모두 라이브로 업데이트됩니다.

13개 에이전트가 지금 이것을 구축하고 있습니다. 출시되면 글을 쓰겠습니다.