팀을 굴리면 첫날 무엇이 멈추는가 — 운용 규칙과 완제품 환경

첫 편이 한 명을 정의했고, 앞 편이 여럿을 묶는 패턴과 격리 수단을 골랐다. 구조는 다 섰는데, 팀을 실제로 띄우면 첫날 부딪히는 것은 패턴 선택이 아니다.

이론이 "무엇이 존재하는가"라면, 운용은 "어떻게 돌리는가"다.

주방 배치도(구조)를 완성한 요리사가 첫 영업(운용)에서 부딪히는 문제는 다르다. 주방장이 셰프에게 지시를 어떻게 전달하는가, 주문 대기열이 막히면 어떻게 푸는가, 두 셰프가 같은 칼을 동시에 쥐려 할 때 어떻게 막는가.

구조 지식은 필요조건이지 충분조건이 아니다.

이 글은 그 운용을 다룬 뒤 실습 두 건과 오픈소스 환경 사례를 본다.

이 글이 옮긴 원 자료의 작성 기준일은 2026-07-26이다. 도구 이름·기능·제약은 그 시점의 것이다.

아래의 실습 두 건은 원 자료의 예제이며 실제 운영 사례가 아니다. 마지막에 나오는 Claude Forge는 실재하는 MIT 오픈소스이고, 이 글이 적는 구성 수치는 원 자료가 옮긴 것이다.

용어 정리

첫 편의 용어표에서 이 글이 쓰는 행만 추렸다.

팀 가동 4단계 — 만들고, 일 쌓고, 사람 부른다

팀원 유형(권한 프로파일)

팀 이름은 소문자-하이픈 컨벤션을 쓰고, 같은 팀을 여러 번 돌릴 때는 날짜를 붙여 로그를 분리한다.

메시지는 비동기다 — Phase 전환의 핵심

메시지를 보내도 수신자가 즉시 깨어나지 않는다. 메시지는 수신자의 inbox에 적재되고, 수신자가 다음 턴을 시작할 때 읽힌다.

파일 폴링을 금지하는 4가지 이유

넷째 행이 나머지 셋과 성격이 다르다. 앞의 셋은 폴링이 틀린 이유이고, 넷째는 폴링을 하고 싶어지는 동기를 제거한다.

의존성 해제 ≠ 깨우기

의존성 필드는 상태 표시이고, 실제 실행 트리거는 메시지다. 이 둘을 혼동하면 다음 Phase가 영원히 시작되지 않는다.

Hub-and-Spoke를 쓰는 진짜 이유 — 오류 억제

원 자료는 이 수치를 Google/MIT 2025 연구에서 인용했다. 함의는 분명하다.

Hub-and-Spoke는 성능을 희생하는 보수적 선택이 아니라, 오류 억제 메커니즘이다.

팀원끼리 검증 없이 판단을 주고받으면 오류가 체인을 타고 증폭된다.

허용/금지 경계

가운데 행이 이 표의 실질이다. P2P를 통째로 막는 것이 아니라 조율은 허용하고 종결만 막는다 — 앞 편의 "팀원은 리더에게만 보고한다"를 한 칸 더 나눈 것이다.

리더의 3책임과 금지 사항

넷째 행이 앞의 셋을 포함하고, 앞의 셋은 그 원칙이 깨지는 세 지점에 이름을 붙인 것이다. 완전 위임까지 못 가는 간극을 능력이 아니라 신뢰·구조의 문제로 본 정리는 위임 격차에 있다.

컨텍스트 외부화 — 결정 기록 파일

리더의 컨텍스트는 팀 전체 작전을 기억하는 유일한 장소다. 컨텍스트가 가득 차면 압축이 일어나고, 이때 핵심 결정이 유실된다(원 자료는 관련 버그 이슈를 근거로 든다).

이건 사실상 ADR(Architecture Decision Record)과 회의록 문화다. "왜 그렇게 정했고 무엇을 버렸는지"를 남기지 않으면, 사람 팀에서도 몇 달 뒤 같은 논쟁을 반복한다.

교착 방지 4대 증상과 처방

처방 넷 중 둘이 순수한 사전 정의다.

파일을 미리 갈라 두고, 규칙을 미리 적어 둔다. 셋째는 미리 정한 순서를 종료 시점에 지키는 것이고, 넷째는 사전 정의(시간 상한)에 초과 시 대응(현재까지 결과로 종합)을 함께 적는다. 그래도 넷 다 미리 정해 두는 것에서 출발하므로, 이 표는 장애 대응표보다 가동 전 점검표에 가깝다 — 그렇게 가르는 것은 이 글의 정리다.

파일 소유권 테이블 예시

종료 프로토콜

비용 관리 3원칙

에이전트 팀의 비용은 메인 세션 대비 대략 7~15배다. 그래서 "이 작업에 정말 팀이 필요한가"가 첫 질문이 된다.

수치 출처: 세 행의 출처가 다르다. 모델 계층화의 +90.2%·-50%는 Anthropic 멀티에이전트 리서치 시스템, 병렬화의 +81%·-70%는 Google/MIT 2025 연구에서 원 자료가 인용한 값이다. Phase 분리 85% 절감만 원 자료 자체의 운영 사례라 성격이 다르다 — 앞의 둘은 외부에서 확인되고 셋째는 원 자료 안에서만 확인된다. 이 시리즈의 성능·비용 수치는 직접 측정한 것이 아니다. 대부분 원 자료가 인용한 외부 연구·벤치마크 값이고, 하나(Phase 분리 85%)는 원 자료 자체의 운영 사례이며, 출처를 밝히지 않은 값도 섞여 있다.

운용 7 체크리스트

태스크 분할 원칙 — 팀원당 5~6개

5~6개가 두 문제 사이의 실용적 균형점이다. 또한 팀 일부가 실패해도 전체가 멈추지 않도록 부분 실패 시 대체 경로를 미리 정의해 둔다.

왼쪽 열은 둘 다 「너무」로 시작하는데 오른쪽 열의 부호가 반대다. 위 행의 결과(실패 고립)는 이득이고 아래 행의 결과(인지 오버헤드)는 손해이며, 균형점으로 지목된 5~6개는 위 행 괄호 안의 숫자와 같다. 형식은 두 극단의 대조지만 실제로 읽히는 내용은 5~6개가 10개 이상보다 낫다에 가깝다.

실습 1 — 마케팅 전문가 에이전트 만들기

단일 에이전트를 처음부터 만들어 실행한다. 결과물은 블로그 작성 에이전트 한 명이다.

완성본

---
name: blog-writer
description: When to use when user asks for blog draft
model: opus
tools: Read, Write, Edit, WebSearch
color: blue
---

# Blog Writer Agent

## 역할 (Role)
1인 사업자의 블로그를 대신 작성하는 전문 블로그 작성자.
타깃: 1인 사업자, 소규모 창업자, 프리랜서.

## 절차 (Process)
1. 트렌드 리서치 — 웹 검색으로 관련 키워드 + 최신 트렌드 조사
2. 제목 5개 생성 — 클릭율 높은 후보 5가지 제안
3. 초안 작성 — 선택된 제목으로 본문 초안 생성 (300단어 이상)
4. 퇴고 — SEO 키워드 3개 삽입 + 가독성 최적화

## 제약 (Constraints)
- 최소 300단어 이상
- SEO 키워드 3개 반드시 포함
- 셸 실행·하위 에이전트 호출 금지

도구 선정 근거 — 왜 넣고 왜 뺐나

제외 열의 마지막 행만 도구가 아니다. Bash·Task·질의 도구는 실제 도구인데 「미지정」은 필드를 비우는 선택이다. 첫 편에서 원 자료가 미지정 결과를 적어 둔 유일한 필드로 짚었던 tools가, 여기서는 제외 목록의 한 행으로 다시 나온다.

컨텍스트 격리 — 가장 흔한 오해

• 서브에이전트는 별도 독립 컨텍스트에서 실행되고, 위임 프롬프트에 명시한 내용만 안다.
• 대응책은 하나다. 필요한 맥락을 위임 프롬프트에 명시적으로 실어 보낸다.
• 대신 격리 덕분에 병렬 실행이 가능하고 민감정보가 새지 않는다.

정량 제약이 에이전트를 통제한다

트러블슈팅

확장 경로 — 1인에서 팀으로

이 팀 구조가 곧 Reasoning Sandwich의 팀 버전이다. 단일 에이전트를 완전히 이해한 뒤 팀으로 확장하는 순서를 권장한다.

실습 2 — 3인 팀 구축 (리서처 + 작성자 + 검토자)

비유 — 신문사 편집부 3인조

역할별 정의 — 도구 제한이 프롬프트보다 먼저다

이 챕터의 핵심 문장: "프롬프트보다 도구 제한이 먼저다. 쓰기 권한이 있으면 쓴다."

사람 조직으로 옮기면 "하지 말라고 말하는 것"과 "할 수 없게 권한을 조정하는 것"의 차이다. 후자가 훨씬 강하게 작동한다.

역할별 출력 계약

리서처 정의의 핵심 규칙 두 가지가 특히 중요하다. 공식 출처를 우선하고, 불확실한 정보에는 "미확인:" 접두어를 붙인다 → 작성자의 할루시네이션을 예방한다.

검토자의 검토 순서는 3단계 우선순위로 고정한다.

검토자에 상위 모델을 배정하는 이유도 Reasoning Sandwich다. 검증 단계에 깊은 추론 모델을 쓴다.

실행 흐름과 비용 감각

비용은 3인 팀 기준 약 7,500토큰으로, 단일 에이전트 대비 2~3배 수준이다.

프로덕션 에이전트가 갖추는 5가지

원 자료는 실습용과 실제 운영용의 차이를 이렇게 정리한다.

앞의 셋은 첫 편에서 이미 채운 것이라, 실습과 운영을 가르는 것은 뒤의 둘이다. 예컨대 리서처는 검색 도구가 실패할 때를 대비해 도구 에스컬레이션 체인(1차 → 2차 → 3차 도구)을 갖는다.

올인원 개발 환경 — Claude Forge 사례

에이전트·명령어·훅·MCP를 한 번에 세팅해 주는 오픈소스 환경 사례다. 챕터 제목은 "11에이전트 + 40커맨드"인데, 원 자료가 본문에서 v3.0.1 기준 명령어 33개·스킬 24개로 정정한다. 정정한 주체는 원 자료이고, 인용할 때는 정정된 수치를 쓴다.

11 에이전트 카탈로그

E2E 파이프라인 6단계

이 파이프라인은 앞 편의 파이프라인 패턴이 실제 개발 공정에 적용된 형태다. 각 단계가 하나의 전문 에이전트에 대응하고, 검증 게이트가 통과해야 다음으로 넘어간다.

6단계 보안 방어 레이어

이 6층 구조가 곧 "AI가 안전하게 일할 수 있는 틀"의 구체적 형태다. 정책 문서가 아니라 실행 시점에 강제되는 게이트로 구현되어 있다는 점이 핵심이다.

훅과 MCP

실시간 문서 조회 MCP는 코드 작성 전에 항상 먼저 실행하는 것이 권장 패턴이다. 학습 데이터 대신 최신 공식 문서를 참조해 할루시네이션을 줄인다.

배포·설치에서 배울 점

원 자료는 설치 과정의 함정 2가지(인증 방식 기본값 문제, 여러 줄 붙여넣기 시 개행 손실)를 다루며, 가장 안전한 기본 경로를 문서에 명시하는 것을 해법으로 제시한다. 도구를 만드는 쪽이 못 고치는 문제는 문서의 기본값으로 우회시킨다는 접근이다.

또한 기본 MCP 세트를 6개에서 4개로 줄인 결정을 ADR로 남긴 사례가 등장한다. 왜 이 결정을 내렸는지 기록하는 문화의 예다.

사람 조직에서 하던 일과의 대응 — 핵심 6개

여섯 행이 이 시리즈의 순서를 따라간다. 1번이 첫 편, 2번이 앞 편, 3·6번이 이 글이고, 4번(Reasoning Sandwich)은 첫 편과, 5번(Worktree 물리 격리)은 앞 편과 걸친다. 여섯 행 오른쪽 열이 전부 앞에서 이미 나온 개념이라는 것이 요점이다. 원 자료도 이 여섯을 핵심 6개라 적었다 — 전수 목록이 아니라 선별이다.

팀을 계층으로 쌓고 상태를 격리하는 구조를 그래프 관점에서 본 정리는 Hierarchical 계층화에 따로 있다.

시리즈를 닫으며

첫 편이 "누구"를 한 장의 정의서로 만들었고, 앞 편이 여럿을 어떤 모양으로 묶고 무엇으로 갈라 둘지 정했고, 이 글이 묶인 팀을 켜고 끄는 규칙을 봤다.

세 편에서 반복된 원칙 하나만 남긴다면 이것이다. 말로 금지하는 것보다 할 수 없게 만드는 것이 강하다. 정의서에서는 tools에서 도구를 빼는 것, 팀 운용에서는 파일 소유권을 미리 갈라 두는 것, 완제품 환경에서는 실행 시점에 걸리는 게이트였다. 셋 다 같은 문장의 다른 구현이다.