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

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

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

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

2~3개 이상의 에이전트를 실행하면서 모든 에이전트가 무엇을 하는지 파악하는 방법을 고민하고 있다면, 수개월의 이터레이션 끝에 도달한 형태가 이것입니다. 오전 9시에 버그가 보고되어 오후 3시에 수정이 배포되었고, 그 동안 4개의 다른 작업 스트림이 병렬로 진행되었습니다. 항상 순조롭지는 않지만, 처리량은 실제입니다.

편성

모든 에이전트에 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에게 보고합니다.

실제로는 이렇게 동작합니다. 오늘의 실제 bead입니다: super가 작업을 할당하고, eng2가 번호가 매겨진 계획을 댓글로 남기고, eng2가 QA 검증 단계와 체크된 승인 기준이 포함된 DONE을 댓글로 남기고, super가 QA에 전달합니다.

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개 에이전트가 병렬이기 때문입니다.