자율 협업 AI 개발 팀: 운영 모델

좋은 아침입니다, 천사들.

요약 (TL;DR): 하나의 저장소(Repository)에 여러 개의 자율 AI 에이전트(Autonomous AI agents)를 투입했을 때 실패하는 이유는 에이전트가 충분히 똑똑하지 않아서가 아니라, 구조(Structure)가 없기 때문입니다. 그 구조는 바로 운영 모델(Operating model)입니다. 네 가지 역할, 유일한 조정 계층(Coordination layer)으로서의 이슈 트래커(Issue tracker), 제품 고도(Product altitude)에 머무는 인간, 그리고 에이전트가 넘을 수 없는 철저한 가드레일(Guardrails) 세트가 필요합니다. 이 가드레일은 작업자(Workers)가 준수해야 하며, 관리자(Steward)에 의해 독립적으로 재검증되어야 합니다. 그 전체 내용을 소개합니다.

대상 독자: 한 번에 하나 이상의 AI 코딩 에이전트(AI coding agent)를 운영 중이거나 운영할 예정이며, 이들이 서로 충돌하거나 확신에 찬 헛소리(Confident nonsense)를 배포하지 않도록 유지하는 방법을 고민하는 모든 분.

Designing AI Teammates 시리즈의 일부입니다.

"당신의 방법론은 구식이고 취약합니다. 당신의 승인 절차는 가장 급진적이지 않은 아이디어만이 보상받도록 보장합니다. 그동안 당신의 경쟁자는 혁신하고 있습니다." -- Alex, Charlie's Angels

모든 변경 사항을 인간이 수동으로 승인하는 것이 바로 그 승인 절차이며, 이는 가장 느리고 가장 급진적이지 않은 경로입니다. 그래서 우리는 인간을 모든 작업 중간의 패킷 라우터(Packet routers)로 만드는 것을 중단했습니다. 대신 우리는 자율 AI 코딩 에이전트 팀을 운영하며, 인간의 손은 진정으로 인간이 필요한 두 가지, 즉 무엇을 만들지 결정하는 것과 그것이 맞는지 확인하는 것에만 둡니다.

그리고 아래의 모든 내용이 이를 증명하는 논지는 다음과 같습니다: 에이전트들은 지능에 의해 조정되는 것이 아니라, 구조에 의해 조정됩니다.

수치로 보는 성과: 지난 한 주 동안 팀은 단일 저장소에서 **52개의 티켓(Tickets)**에 대한 코드를 반영했습니다. 각각은 CI를 통과한 실제 PR(Pull Request)이었습니다. 그동안 우리는 제품 고도(Product altitude)에서 한 주를 보냈습니다. 이것은 특별한 이벤트가 아닌 평범한 활동 주간입니다. 이 모델은 몇 달 동안 이와 같은 스프린트(Sprints) 방식으로 운영되어 왔습니다. 이어지는 내용은 이 모델을 유지하게 만드는 구조, 즉 역할, 조정 기질(Coordination substrate), 가드레일, 그리고 어렵게 얻어낸 규칙들입니다. (관련 글: "하나의 저장소에서 세 명의 AI 작업자를 처음 실행했을 때 무너진 것들")

핵심 아이디어

우리가 에이전트(agent) 사이에서 패킷을 직접 전달하는 순간 — 질문을 전달하거나, 한 터미널에서 다른 터미널로 상태를 복사하여 붙여넣거나, 모든 변경 사항을 수동으로 검토하고 병합하는 순간 — 우리는 병목 현상(bottleneck)이 됩니다. 따라서 우리는 조율(coordinating), 조정(reconciling), 병합(merging), 큐(queue)를 채워두는 것과 같은 기계적인 (mechanical) 작업들을 에이전트들에게 맡기고, 인간만이 할 수 있는 두 가지 일, 즉 무엇을 만들지 결정하는 것과 그것이 옳은지 판단하는 것을 위해 스스로를 남겨둡니다.

네 가지 역할 (Four roles)

역할 (Role)	수 (Count)	모드 (Mode)	소유 (Owns)
작업자 (Workers)	여러 명	자율 루프 (autonomous loop)	작업 큐(task queue) 소진 → 풀 리퀘스트(pull requests) 생성
...

한 줄로 요약한 흐름: 디스패처(dispatcher)가 큐를 채우고, 작업자(workers)가 이를 소진하며, 스튜어드(steward)가 이를 진행시키고, 인간이 결정하고 검증합니다.

등장인물 (The cast), 역할이 잘 기억나도록 돕기 위해 비유하자면: "옛날 옛적에 매우 다른 세 명의 어린 소녀들이 있었습니다. 그들은 자라나서 세 가지 공통점을 가진 매우 다른 세 명의 여성이 되었습니다. 그들은 똑똑하고, 아름다우며, 저를 위해 일합니다. 제 이름은 찰리(Charlie)입니다." **작업자(workers)**는 엔젤(Angels)입니다 — 미션을 수행하는 요원들이죠. **찰리(Charlie)**는 디스패처(dispatcher)입니다 — 스피커를 통해 임무를 하달하는 목소리입니다: "좋은 아침입니다, 엔젤들." **보슬리(Bosley)**는 스튜어드(steward)입니다 — 모든 완료된 미션을 검토하고 집으로 가져오는 현장 관리자입니다.

이슈 트래커(issue tracker)는 조율 계층(coordination layer)이다

어떤 에이전트도 다른 에이전트에게 직접 메시지를 보내지 않습니다. 그들은 작업 큐(work queue) 역할을 겸하는 공유 트래커의 **작업 상태 (task status)**를 통해서만 완전히 조율합니다.

백로그 (Backlog) → 준비됨 (Ready) → 진행 중 (In Progress) → 입력 필요 (Needs Input) → 검토 중 (In Review) → 변경 요청됨 (Changes Requested) → 완료 (Done)

준비됨 (Ready) -- 완료 정의 (Definition of Done)가 명확하고 완전히 명시된 상태입니다. 작업자(Worker)는 오직 이 상태(및 변경 요청됨 상태)에서만 작업을 가져옵니다. 이것이 게이트(Gate) 역할을 합니다.
입력 필요 (Needs Input) -- 작업이 차단된 경우, 작업자는 질문과 함께 이를 이 상태에 둡니다. 관리자(Steward) 또는 사람이 댓글로 답변하면 다시 선택 가능한 상태로 돌아갑니다.
검토 중 (In Review) -- 변경 사항이 CI(지속적 통합)에서 통과(Green)되었으며, 사람 또는 관리자의 결정을 기다리는 상태입니다.
변경 요청됨 (Changes Requested) -- 이미 배포되었거나 PR(Pull Request)이 생성되었으나, 검토자가 수정을 원하는 상태입니다. 작업자는 이를 다시 선택하되, "이것이 이미 완료되었는가?"라는 확인 과정을 건너뜁니다 (기존 커밋이 있을 것으로 예상됨). 최신 댓글을 읽고 수정을 진행합니다. 이 상태가 존재하는 이유는 작업자가 "이것을 수정하라"와 "이미 완료되었다"를 구분하기 위해 커밋과 댓글 사이를 뒤지는 고고학적 작업(Archaeology)을 할 필요가 없도록 하기 위함입니다.

하나의 태스크의 생애 주기

**사람 + 디스패처 (Dispatcher)**가 기능을 **독립적인 준비된 태스크 (Self-contained ready task)**로 명세합니다: 컨텍스트(Context), 범위(Scope), 수락 기준(Acceptance criteria, 예상되는 테스트 포함) 및 포인터(Pointers)를 포함하며, 범위(Scope)는 댓글에 숨기지 않고 설명(Description)에 작성합니다.
**작업자 (Worker)**가 대기열의 최상단 항목을 점유합니다 (점유(Claim) → 조정(Reconcile) → 빌드(Build): 먼저 점유하여 잠금(Lock)을 걸고, 그 다음 태스크의 현재 범위에 비추어 이미 배포된 것이 아닌지 확인한 후, 빌드를 진행합니다). 작업은 **태스크별 브랜치 (Per-task branch)**의 자신만의 격리된 체크아웃 (Isolated checkout) 환경에서 이루어집니다.
작업자가 **풀 리퀘스트 (Pull Request)**를 생성하면 CI가 실행됩니다.
**관리자 (Steward)**가 통과된(Green) PR을 검토합니다:
- 객관적이고 완전함 (로직/테스트, 요구되는 테스트 포함) → 자동 병합 (Auto-merge) → 완료 (Done).
- 시각적 요소 / 불완전함 / 판단이 필요한 경우 → 변경 요청됨 (Changes Requested)으로 라우팅하거나 검토 중 (In Review) 상태로 두며, 무엇을 확인해야 하는지 정확히 명시하여 **사람에게 알림(Ping)**을 보냅니다.
사람이 에스컬레이션된 소수의 항목을 검증하면 → 관리자가 이를 종결합니다.

충돌을 피하는 방법

태스크 상태(Task status) = "무엇을 해야 하는가"에 대한 단일 진실 공급원 (Single source of truth)
선점 우선 (Claim-first) -- 가장 먼저 작성된 점유(claim) 댓글이 우선권을 갖습니다 (에이전트들이 종종 하나의 트래커 로그인 계정을 공유하므로, 담당자(assignee)가 아닌 댓글이 결정적인 기준이 됩니다).
작업자당 하나의 격리된 체크아웃 + 태스크당 하나의 브랜치/PR -- 엉킨 편집을 방지합니다. 버전 관리(Version control)는 설계된 목적 그대로 머지(merge) 시점에 조정됩니다.
단방향 채팅 피드 (A one-way chat feed) -- 스튜어드(Steward)가 매 단계마다 참고용(FYI) 요약을 게시합니다. 인간이 정말로 필요할 때만 인간을 @멘션합니다. 인간은 중간에 끼어들지 않고 지켜보기만 합니다.
시작 시에는 가벼운 표준 코어, 필요할 때만 깊이 추가 -- 모든 에이전트는 항상 켜져 있는 작은 코어(프로토콜 + 모든 것에 적용되는 규칙)를 로드합니다. 영역별 세부 사항(엔지니어링, 테스트, 디자인)은 태스크가 해당 영역을 다룰 때만 불러오며, 모든 컨텍스트에 한꺼번에 쏟아붓지 않습니다. **플레이북 (Playbook)**은 트래커/CI 배관(plumbing) 구조를 캡처하여 에이전트가 매번 이를 다시 도출할 필요가 없게 합니다.

신뢰 조절 다이얼 (The trust dial)

이를 **정교화 단계 (Refinement stage)**로 취급하십시오. 스튜어드는 객관적인 (objective) 작업(테스트 통과, UI 판단 제외)은 자동으로 머지하지만, 시각적이거나 제품 형태와 관련된 작업은 인간에게 에스컬레이션합니다. CI, 필수 테스트, 셀프 리뷰, 독립적인 리뷰어 에이전트와 같은 게이트(gates)가 제 역할을 수행한다는 것이 증명됨에 따라, 더 많은 작업이 완전 자율 단계로 졸업합니다. 시각적 및 제품 관련 결정은 무기한으로 인간의 영역으로 남습니다.

전기 울타리 (The electric fences)

이 작업자 군집(worker hive)이 풀을 뜯는 목초지에는 전기 울타리가 쳐져 있습니다.

이 부분이 바로 에이전트들을 풀어주어도 안전하게 만드는 요소입니다. 에이전트들은 필드 내부에서는 자유롭게 돌아다니지만, 필드는 그들이 넘을 수 없는 철저한 가드레일(guardrails) 세트로 둘러싸여 있습니다. 모든 가드레일은 코드화되어 있습니다. 에이전트가 항상 지니고 다니는 가벼운 코어와, 태스크가 해당 영역을 다룰 때만 불러오는 나머지 요소들로 구성되며, 다음과 같은 게이트에서 강제됩니다: CI, 프리-푸시 훅(pre-push hook), 그리고 스튜어드의 리뷰:

엔지니어링 (Engineering)

재사용성 (Reusability) -- 작성하기 전에 grep으로 검색하세요. 존재하는 것을 재사용하고, 절대 중복하지 마세요 (복사-붙여넣기 탐지기가 새로운 중복 발생 시 빌드를 실패시킵니다).
관심사 분리 (Separation of concerns) -- 레이어 경계가 유지되어야 합니다 (서비스가 스크린에 직접 접근하거나 순환 의존성(circular dependencies)이 발생해서는 안 됨). 엄격한 라인 수 제한을 넘는 거대 파일(god files)을 허용하지 않으며, UI에 비즈니스 로직을 몰래 삽입하지 않습니다.
타입 안정성 (Type safety) -- strict 모드 활성화, any 사용 금지, 설명 없는 @ts-ignore 금지; 모든 외부 경계는 타입이 지정되어야 합니다.
데드 코드 및 과도한 방어 코드 금지 (No dead code, no over-guarding) -- 도달할 수 없는 코드가 없어야 하며, 발생할 수 없는 형태(shapes)에 대한 방어 로직을 만들지 않습니다.

테스팅 (Testing)

필수 테스트는 코드와 함께 배포됩니다 -- 사용자에게 노출되는 모든 기능에 대해 유닛 테스트(unit test), 회귀 테스트(regression test), 엔드 투 엔드(end-to-end) 흐름을 포함해야 합니다. 테스트가 누락된 머지(merge)는 절대 허용되지 않습니다.
단언(assertion)이 없는 테스트 및 .only 커밋 금지 -- CI 가드(guard)가 이 두 경우 모두 빌드를 실패시킵니다.
핵심 경로 서비스에 대한 변이 테스트 (Mutation testing) -- 커버리지(coverage)는 실행 여부를 증명하지만, 변이 점수(mutation score)는 테스트가 실제로 회귀를 잡아낼 수 있는지 증명합니다.
API에 대한 계약 테스트 (Contract tests) -- 클라이언트와 서버가 서로 어긋나지 않도록 합니다.

디자인 (Design)

디자인 토큰(Design tokens)만 사용 -- 스크린에 생(raw) 헥스(hex) 코드, 간격(spacing), 또는 폰트 크기를 직접 사용하지 않습니다. 공유 컴포넌트는 재구현하는 것이 아니라 추출하여 사용합니다.
접근성 예산 (Accessibility budget) -- 레이블, 대비, 터치 타겟 등을 단순히 기대하는 것이 아니라 반드시 검증(asserted)해야 합니다.

보안 (Security)

코드 내 비밀 정보(secrets) 포함 금지 -- 자격 증명(credentials)은 시크릿 스토어(secret store)에 저장되며, 저장 시 암호화되어야 합니다.
인증 패턴은 임의 수정을 금지함 -- OAuth/PKCE/keychain 흐름; 인젝션 벡터(injection vectors) 금지; 모든 PR(Pull Request)에서 의존성 취약점(dependency vulnerabilities)을 스캔합니다.

배포 (Deployment)

CI 통과(green), 올바른 브랜치 사용, 프로덕션으로의 지름길 금지 -- 민감한 코드(인증, 결제, 마이그레이션, 데이터 삭제)는 절대 자동 머지(auto-merge)되지 않습니다.
마이그레이션은 실행 전 라이브 스키마(live schema)를 대상으로 검증되어야 하며, 롤백(rollback) 경로를 확보해 두어야 합니다.
성능 예산 (Performance budgets) -- 번들 크기(bundle size)와 주요 쿼리 횟수가 조용히 퇴보(regress)하는 것을 방지합니다.

…그리고 울타리(fence line)는 계속해서 늘어납니다. 새로운 실패 모드(failure mode)를 가르쳐주는 모든 사고는 다음 날 아침 새로운 철사 한 줄이 됩니다.

그리고 여기서 핵심적인 부분(load-bearing part)이 있습니다. 울타리는 방목하는 동물들이 명예 시스템(honor system)에 따라 스스로 지키도록 내버려 두는 것이 아닙니다. 작업자(worker)는 울타리를 준수하며, 관리자(Steward)는 무언가가 병합(merge)되기 전에 그 준수 여부를 독립적으로 재검증합니다. 작업자는 테스트가 통과되었고, 자신의 차이점(diff)이 올바른 헬퍼(helper)를 재사용하며, 표준이 유지되고 있다고 보고합니다. 관리자는 매 통과 시마다 울타리 라인을 따라 점검하며 실제로 그러한지를 확인합니다. 준수는 작업자의 업무이고, 검증은 관리자의 업무입니다. 에이전트(agent)의 선의가 아니라, 이 두 번째 독립적인 확인이 있기에 작업이 통제 불능(feral) 상태로 빠지지 않으면서도 신뢰 수치(trust dial)를 높일 수 있는 것입니다.

울타리 없이 자율 에이전트(autonomous agents)를 풀어놓는다면, 그들은 느리게 움직이는 것이 아니라 잘못된 방향으로 빠르고 자신감 있게 움직일 것입니다. 가드레일(guardrails)은 팀의 속도를 늦추는 요소가 아닙니다. 가드레일은 팀을 실행하도록 내버려 두어도 안전하게 만드는 유일한 이유입니다.

시스템을 유지하는 규칙들

주석(comment)이 아닌 설명(description)에 범위를 명시할 것 -- 내용이 비어 있는 "준비 완료(ready)" 작업은 작업자가 잘못된 것을 자신 있게 구축하게 만드는 근본 원인입니다.
점유(Claim) → 조정(reconcile) → 구축(build) -- 점유하기 전에 조정하지 마십시오. 이는 동료가 분석 도중에 작업을 가로채게 만들고, 대기열(queue)에서 오래된 작업을 정리하는 과정을 건너뛰게 합니다.
범위가 재조정된 작업은 유예된 "파트 2"가 될 수 있음 -- 단순히 "커밋(commit)이 존재하는가"가 아니라, 현재 범위(설명 + 최근 댓글)를 기준으로 조정하십시오.
필요한 테스트가 누락된 작업은 절대 병합(merge)하지 마십시오.
작업당 하나의 브랜치(branch) 사용 -- 작업자의 유휴 홈 브랜치(idle home branch)에 절대 커밋하지 마십시오.

작동 원리

더 똑똑한 모델이 조율(coordination) 문제를 해결하는 것이 아닙니다. **구조(structure)**가 해결합니다. 검증(Verification)은 신뢰를 해결하고, 격리(isolation)는 충돌을 해결하며, 워크플로(workflow)는 모호함을 해결합니다. 따라서 이 모든 것은 에이전트를 더 똑똑하게 만드는 것에 관한 것이 아닙니다. 이는 공유된 진실의 원천 (shared source of truth) (트래커), 격리 (isolation) (에이전트당 하나의 체크아웃 및 브랜치), 리뷰 게이트 (a review gate) (PR + CI), 명확한 에스컬레이션 경로 (a clear escalation path) (객관적인 작업은 스스로 진행되며, 판단은 인간에게 전달됨), 그리고 울타리 (the fences) (Steward에 의해 독립적으로 검증되며 에이전트가 넘을 수 없는 철저한 가드레일)에 관한 것입니다. 이 다섯 가지를 제대로 갖추면 팀은 대부분 스스로 운영됩니다. 인간은 무엇을 만들지 결정하고 그것이 좋은지 확인하는 단계로 올라가게 되는데, 이것이야말로 인간이 결코 대체될 수 없는 유일한 영역입니다.

겉치레를 벗겨내면 익숙한 형태가 나타납니다. 바로 **스크럼 팀 (scrum team)**입니다. 백로그(backlog), 보드(board), 상태별 스탠드업(standups), 리뷰(reviews), 그리고 완료 정의(definition of done)가 존재합니다. 팀원들은 그저 차이점을 빠르고 조용하게 해결하며, 아주 가끔씩 울타리에 의해 '제지'를 당할 뿐입니다.

하지만 핵심은 자율 코딩(autonomous coding)이 아니었습니다. 에이전트가 코드를 작성하고, 구조가 그들이 서로 충돌하지 않도록 방지하며, 인간은 제품의 고도(product altitude)를 유지합니다. 즉, 무엇이 중요한지 결정하고 그것이 맞는지 확인하는 것입니다. 그것이 바로 운영 모델(operating model)입니다.

수고했다, 엔젤스(Angels).

리소스 (Resources)

이것은 AI 코딩 에이전트와 함께 작업하기 위한 오픈 시스템인 Mother CLAUDE의 일부입니다. 하나의 공개 리포지토리(public repo)이며, 대부분은 포크(fork)하여 적응시킬 수 있는 일반적인 마크다운(markdown) 형식입니다.