셋으로 묶고 셋으로 가른다 — 협업 패턴 3종과 격리 3계층

첫 편이 한 명을 정의했다. 정의서 한 장에 필드를 채우고 담당·비담당 경계를 긋는 일이었다. 이 글은 그 한 명을 여럿으로 늘린다.

늘리는 방법은 셋뿐이다. 줄로 세우거나(파이프라인), 옆으로 펼치거나(분업), 위에 한 명을 두거나(팀장-팀원). 셋은 비용도 속도도 무너지는 방식도 다르고, 셋 다 실패 모드를 넷씩 가지고 있다.

그리고 패턴을 골랐다고 끝이 아니다. 패턴은 무엇을 그릴 것인가이고, 그것을 실제로 돌리려면 무엇으로 구현할 것인가를 또 골라야 한다. 후반부의 Subagents·Agent Teams·Worktree가 그것이다. 셋은 상하 관계가 아니라 서로 다른 축의 격리 수단이라, 겹쳐 쓸 수 있다.

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

아래 세 패턴의 「실전 예」 행은 원 자료가 든 패턴 예시이며 실제 운영 사례가 아니다.

용어 정리

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

왜 팀으로 나누는가

3인 팀 실습 챕터의 표현을 그대로 옮기면 이렇다.

컨텍스트 희석: 검색 결과 수천 줄이 컨텍스트를 채우면 핵심 사실이 흐려진다.

자기 편향: 자기가 쓴 글을 자기가 검토하면 오류를 못 찾는다. 사람도 마찬가지다.

역할 충돌: 조사·작성·검토를 동시에 하면 어떤 것에도 집중하지 못한다.

이건 프롬프트 문제가 아니다. 구조의 문제는 구조로 해결해야 한다.

가운데 항목이 나머지 둘과 성격이 다르다. 컨텍스트 희석과 역할 충돌은 나누면 완화되지만, 자기 편향은 나누지 않으면 원리적으로 해결되지 않는다. 같은 컨텍스트를 가진 주체가 자기 산출물을 검토하기 때문이다. 이 셋을 이렇게 가르는 것은 이 글의 정리다.

단일 에이전트를 언제까지 유지하고 어디서 쪼개는지, 그리고 쪼갠 뒤의 토폴로지 세 가지를 중앙 통제와 종료 판정 주체로 가른 정리는 언제 에이전트를 쪼개는가에 따로 있다.

패턴 1 — 파이프라인 (Assembly Line, 라인 생산)

앞 단계 산출물이 다음 단계 입력이 되는 단방향 순차 처리다. 각 단계가 데이터를 변환한다.

패턴 2 — 분업 (Parallel Workstation)

오케스트레이터가 N개 에이전트에 동시 배포(Fan-out)하고, 결과를 다시 모아 통합(Fan-in)한다. 에이전트끼리는 서로를 기다리지 않는다.

원 자료가 Google/MIT 2025 연구에서 인용한 수치: 독립 작업을 병렬화하면 +81% 향상, 순차 의존 작업을 무리하게 병렬화하면 -70% 악화.

즉 분업은 "동시에 할 수 있는 일인지"를 먼저 판정한 다음에 쓰는 패턴이다.

패턴 3 — 팀장-팀원 (Orchestrator-Worker, Hub-and-Spoke)

리더가 위임·조율·종합·의사결정을 맡고, 팀원은 전문 작업만 하고 리더에게만 보고한다. 리더는 중간 결과를 보고 다음 단계를 동적으로 정한다.

세 패턴 표의 행 구조가 완전히 같다.

적합 업무 · 실전 예 · 장점 · 실패 모드 ①~④ · 상대 비용. 그래서 세 표는 나란히 놓고 같은 행끼리 읽도록 만들어져 있다. 특히 「실패 모드」가 셋 다 정확히 네 개라는 점이 눈에 띈다 — 어느 패턴도 실패 모드가 하나뿐인 것은 없다. 패턴 선택은 무결점을 고르는 일이 아니라 어느 네 가지를 감당할지 고르는 일이다.

앞의 「4배·15배」는 원 자료가 인용한 Anthropic 공식 수치다. 이 시리즈의 성능·비용 수치는 직접 측정한 것이 아니다. 대부분 원 자료가 인용한 외부 연구·벤치마크 값이고, 하나(Phase 분리 85%)는 원 자료 자체의 운영 사례이며, 출처를 밝히지 않은 값도 섞여 있다.

에이전트를 다른 축으로 열한 개로 가르고 각각의 자율성 수준과 무너지는 지점을 세운 카탈로그는 에이전트 패턴 카탈로그 11종에 있다. 위의 세 패턴을 세분한 목록이 아니다.

트레이드오프 매트릭스

첫 행의 세 값은 서로 같은 단위가 아니다.

~1배와 ~4배는 상수인데 ~N배만 변수다. N은 붙이는 에이전트 수라서, 분업이 팀장-팀원보다 싼지 비싼지를 이 표는 명시하지 않는다 — 표기를 그대로 따르면 넷을 붙였을 때 비슷해지고 다섯이면 넘어선다. 첫 행을 "분업이 중간"으로 읽으면 안 된다는 뜻이다. 단위가 섞여 있다는 지적은 이 글의 것이고, 원 자료는 세 값을 한 행에 나란히 적는다.

하이브리드 — 실전은 항상 조합

패턴 선택 판단 흐름

질문 두 개면 셋 중 하나가 나온다. 첫 질문이 의존성이라는 점이 중요하다 — 비용도 속도도 아니고, 동시에 할 수 있는 일인가가 먼저다.

Subagents vs Agent Teams vs Worktree

패턴이 무엇을 그릴 것인가라면, 여기서부터는 무엇으로 구현할 것인가다. 셋은 상하 관계가 아니라 서로 다른 축의 격리 수단이다.

세 기법의 정체

한 장 비교표

셋째 열에 「해당 없음」이 두 번 나온다는 것이 이 표의 핵심이다.

Worktree는 역질문도 결과 반환도 없다. 통신 수단이 아니기 때문이다. 즉 이 표는 세 후보를 같은 잣대로 줄 세우는 표가 아니라, 왼쪽 둘과 오른쪽 하나가 애초에 다른 것을 한다는 것을 보여주는 표다. 마지막 행의 결정 기준 세 개가 서로 배타적이지 않은 것도 그래서다 — 셋 다 "예"일 수 있다.

워커가 서로를 부르지 않게 만들고 결정 로그로 감사 가능성을 확보하는 아키텍처는 워커는 서로를 부르지 않는다에서 따로 다뤘다.

세 계층은 겹쳐 쓸 수 있다

Worktree가 실제로 제거하는 충돌은 세 가지다.

세 행 모두 논리적 격리로는 막히지 않는 충돌이다. 컨텍스트를 아무리 갈라 놓아도 두 에이전트가 같은 경로에 쓰면 부딪힌다. 격리 계층을 겹쳐 쓰는 이유가 여기 있다.

선택 판단 흐름도

흐름도가 두 단으로 나뉘어 있다는 점을 보자. 위쪽에서 Subagents냐 Agent Teams냐를 정한 다음, 어느 쪽으로 갔든 아래쪽에서 Worktree를 얹을지 다시 묻는다. 앞 표의 「해당 없음」 두 칸이 흐름도에서는 이 구조로 나타난다.

Agent Teams가 정당화되는 4가지 상황

흔한 착각 3가지

가운데 행이 첫 편의 frontmatter 확장 필드표로 되돌아간다. isolation은 거기서 확장 필드 다섯 중 하나로 한 줄만 차지하고 있었는데, 그 한 줄이 여기서 물리적 격리 계층 전체에 해당한다.

다음

세 패턴을 고르고 격리 수단까지 정했다면 구조는 선 것이다. 그런데 구조를 안다고 팀이 굴러가지는 않는다.

팀을 실제로 띄우면 첫날 부딪히는 것은 패턴 선택이 아니라 운용이다. 팀원이 spawn 되자마자 idle로 돌아가고, 메시지를 보냈는데 상대가 깨어나지 않고, 두 팀원이 같은 파일을 동시에 연다.

• 마지막 편 — 팀을 굴리면 첫날 무엇이 멈추는가: 팀 가동 4단계, 비동기 메시지와 Phase 전환, Hub-and-Spoke의 오류 억제 근거, 교착 방지 4대 증상, 비용 관리 3원칙, 그리고 완제품 환경 사례