Gas Town은 Git 커밋을 에이전트 시스템의 유일한 진실로 삼았다

소프트웨어 개발 패러다임이 단일 AI 에이전트에서 수십 개의 에이전트가 동시에 협력하는 방향으로 빠르게 전환되고 있다. Gas Town은 2026년 1월 Steve Yegge가 공개한 오픈소스 멀티 에이전트 오케스트레이션 시스템으로, 20~30개의 Claude Code 인스턴스를 동일한 코드베이스에서 병렬로 조율하는 접근법을 제시한다. Git 호환 분산 데이터베이스인 Dolt를 데이터 플레인으로 삼아 에이전트 간 상태를 일관되게 유지하는 설계가 핵심이다.

Kubernetes의 비유가 어울리는 이유

Gas Town은 Claude Code, GitHub Copilot, Codex, Gemini 등 여러 AI 코딩 에이전트를 단일 워크스페이스에서 관리하는 오케스트레이션 레이어다. "AI 에이전트를 위한 Kubernetes"라는 비유가 자주 쓰이듯, 개별 에이전트의 실행 단위를 추상화하고 조율하는 인프라 역할을 한다.

핵심 철학은 모든 상태를 Git에 저장하는 것이다. 에이전트가 수행 중인 작업, 완료된 결과물, 메시지 라우팅 정보 모두가 Git 커밋으로 기록된다. 이는 시스템 장애 시 임의의 시점으로 복구할 수 있으며, 에이전트 간 작업 이력 감사(audit trail)를 자연스럽게 확보한다는 의미다.

⤢✕

Mayor부터 Convoy까지 이어지는 추상화 계층

Gas Town의 아키텍처는 네 계층으로 구성된다. Mayor는 전체 워크스페이스에 대한 완전한 컨텍스트를 보유한 마스터 Claude Code 인스턴스로, 새로운 작업 요청을 수신하고 적절한 Rig에 분배하며 전체 진행 상황을 모니터링한다. 단일 진입점으로서 에이전트 오케스트레이션의 일관성을 보장하는 역할이다. Rigs는 Gas Town이 관리하는 프로젝트 단위, 즉 Git 저장소에 대응하며, 각 Rig는 독립적인 작업 공간으로 격리돼 여러 에이전트가 동일한 Rig 내에서 충돌 없이 병렬 작업할 수 있는 구조를 제공한다.

Beads는 구조화된 태스크 단위로, Git 이슈와 유사한 개념이다. 각 Bead는 수행해야 할 작업의 명세, 입력 데이터, 기대 출력, 현재 상태를 포함하며 데이터 플레인이자 컨트롤 플레인으로 기능해 시스템 전체의 상태가 이 구조체에 집약된다. Convoys는 실행을 위해 묶인 Bead 그룹으로, 관련된 작업들을 하나의 Convoy로 묶어 일괄 실행함으로써 에이전트 간 의존성 관리와 순서 제어를 단순화한다.

⤢✕

Dolt가 상태 저장소로 선택된 이유

Gas Town의 가장 독창적인 설계 결정은 Dolt를 상태 저장소로 채택한 것이다. Dolt는 Git 호환 분산 데이터베이스로, SQL 쿼리와 Git 워크플로우를 동시에 지원한다. 이를 통해 Gas Town은 전통적인 RDBMS의 구조화된 데이터 관리 능력과 Git의 버전 관리·브랜칭·머지 기능을 동시에 활용한다.

항목	설명
Bead ID	고유 식별자 (Git 커밋 해시 기반)
상태	pending / in-progress / completed / failed
담당 에이전트	현재 Bead를 처리 중인 에이전트 식별자
입력 컨텍스트	작업 수행에 필요한 파일·코드·명세
출력 결과	에이전트가 생성한 코드·문서·리포트
타임스탬프	각 상태 전환 시각

모든 Bead 상태 변경은 Dolt 커밋으로 기록되므로, 특정 시점의 시스템 상태를 완전히 재현할 수 있다. 이는 장애 분석과 디버깅에 결정적인 이점을 제공한다. mail.Router는 에이전트 간 구조화된 메시지 전달을 담당하는데, 단순한 큐가 아니라 메시지 타입과 우선순위에 따라 적절한 에이전트로 라우팅하는 스마트 메시징 레이어다. 에이전트가 작업 완료를 보고하거나 추가 정보를 요청할 때 mail.Router를 통해 통신하며, 이 메시지 흐름 역시 Dolt에 기록된다.

같은 코드베이스에서 부딪히지 않는 법

20~30개의 에이전트가 동일한 코드베이스에서 작업할 때 발생하는 핵심 과제는 충돌 해결과 작업 분배의 공정성이다. Gas Town은 이를 Git 브랜치 전략과 Bead 잠금 메커니즘으로 해결한다. 각 에이전트는 독립적인 Git 브랜치에서 작업하며 Mayor가 머지 순서와 충돌 해결 전략을 결정하고, Bead 단위의 잠금(lock) 메커니즘은 두 에이전트가 동일한 태스크를 중복 수행하는 것을 방지한다.

⤢✕

태스크 분배 알고리즘은 에이전트의 현재 부하, 전문화 영역(예: 프론트엔드 특화 에이전트 vs. 백엔드 특화 에이전트), 이전 성공률을 종합적으로 고려한다. Mayor는 이 메트릭을 기반으로 Bead를 최적의 에이전트에 할당함으로써 전체 처리량을 극대화한다.

실패는 격리하고, 재시도는 단계적으로

멀티 에이전트 시스템에서 오류는 피할 수 없다. Gas Town은 오류가 전파되지 않도록 Bead 단위 격리 원칙을 적용해, 하나의 Bead 실패가 동일 Convoy 내 다른 Bead의 실행을 차단하지 않도록 의존성 그래프를 명시적으로 선언한다. 재시도 전략은 일시적 오류(네트워크 타임아웃, API 속도 제한)에 지수 백오프로 3회 재시도하는 즉시 재시도, 동일 Bead를 다른 에이전트에 재할당해 에이전트 자체의 오류를 우회하는 에이전트 교체, 반복 실패 시 Mayor가 직접 개입해 Bead를 분해하거나 전략을 재수립하는 Mayor 에스컬레이션 세 단계로 구성된다.

모니터링은 Dolt의 변경 이력을 실시간으로 구독하는 방식으로 구현된다. 대시보드는 Bead 상태 분포, 에이전트별 처리량, 평균 완료 시간, 실패율을 시각화하며 비정상적인 패턴 감지 시 Mayor에게 경고를 전달한다.

시간당 100달러가 아깝지 않은 상황

초기 사용자 보고에 따르면 12~30개의 병렬 에이전트를 운용할 때 시간당 약 100달러의 비용이 발생한다. 개인 개발자에게는 부담스러운 금액이지만, 기업 환경에서의 ROI를 평가할 때는 다른 관점이 필요하다. Gas Town이 현실적으로 가치를 발휘하는 시나리오로는 수천 개의 파일을 특정 패턴으로 일괄 변환할 때 에이전트를 파일 단위로 병렬 분배해 작업 시간을 대폭 단축하는 대규모 마이그레이션, 여러 저장소에 걸친 API 변경이나 의존성 업데이트 시 각 저장소를 독립 Rig로 관리하는 크로스 레포지토리 리팩토링, 풀 리퀘스트마다 전문화된 에이전트들이 보안·성능·스타일을 분산 검토하는 자동화된 코드 리뷰가 꼽힌다.

현 시점에서 Gas Town은 실험적 단계에 있다. 프로덕션 도입을 검토한다면 소규모 파일럿 프로젝트로 시작해 비용 대비 생산성을 측정한 후 확대하는 점진적 접근이 권장된다. Mayor-Rig-Bead-Convoy 계층 구조와 Dolt 기반 상태 관리는 Git을 단순한 코드 저장소가 아니라 시스템 상태의 단일 진실 원천으로 재정의한 시도이며, 아직 성숙 단계에 이르지는 못했지만 AI 에이전트 팀이 인간 팀을 보조하거나 대체하는 미래를 구체적으로 상상하게 만드는 프로젝트다.