이 문서는 역할 기반 멀티 에이전트 팀(Team) 과 단계형 파이프라인(Pipeline) 두 워크플로우를 직접 운영해 보면서, 어떤 상황에서 무엇이 더 효율적인지 정리한 실험 기록입니다. 구체적인 조직/프로젝트/서드파티 SaaS 이름은 의도적으로 제거했고, 구조·원리·운영 인사이트만 남겼습니다.
¶ TL;DR
- 단일 태스크를 끝까지(End-to-End) 완결해야 하면:
Pipeline(단계형 체인) 쪽이 운영 비용이 낮고 결과물이 더 안정적으로 남는다. - 여러 개의 독립 과제를 병렬로 처리하거나 동시에 여러 축(기획/개발/디자인/검증)을 굴려야 하면:
Team(상주형 팀) 쪽이 더 자연스럽다. - 단, Team은 메시지/상태 동기화 오버헤드가 크고, Pipeline은 정교한 병렬화/실시간 협업에는 한계가 있다.
¶ 용어 교정 (정확한 워딩)
이 문서에서 비교하는 두 접근은 “좋다/나쁘다”의 문제가 아니라, 오케스트레이션(조율) 방식의 선택이다.
¶ Execution Modes 관점
Team과Pipeline은 특정 플러그인/런타임에서 공식 실행 모드(Execution Modes) 로 취급되는 동급 개념이다.- 따라서 “OMC Pipeline”을 플러그인 전체 운영 체계를 의미하는 말로 썼다면, 더 정확한 표현은:
- “실행 모드(Execution Modes)” 또는
- “단계형 파이프라인 실행 모드(Pipeline execution mode)”
처럼 “Pipeline = 하나의 모드”라는 점을 드러내는 것이다.
중요한 포인트:
Team과Pipeline은 서로의 상위/하위가 아니라 형제 모드다.
¶ 이 문서에서의 용어 매핑
| 이 문서의 표현 | 의미 | 구현 관점 힌트 |
|---|---|---|
| Team(상주형 팀) | 역할이 있는 여러 에이전트를 “상주”시키고, 태스크/메시지로 협업시키는 방식 | 태스크 리스트 + 메시지 + 상태 업데이트가 중심 |
| Pipeline(단계형 체인) | Step/Stage를 순차로 연결하고, 각 단계가 산출물을 다음 단계로 넘기는 방식 | Stage 격리 + 파일 산출물 전달이 중심 |
¶ 실험 설계
¶ 비교 대상
¶ A. Team(역할 기반 멀티 에이전트 팀)
- 여러 에이전트(예: 기획/기술/구현/디자인/검증)가 각자 작업 공간과 컨텍스트를 갖는다.
- 리더(조율자)가 태스크를 쪼개고 의존성을 잡고, 메시지로 흐름을 관리한다.
- 장점은 병렬성, 단점은 동기화 오버헤드다.
¶ B. Pipeline(단계형 파이프라인)
- 문제를 Step 0~N 단계로 고정하고(예: 분석→설계→계획→개발→리뷰→보고), 각 단계에 “맞는 에이전트/스킬”을 필요할 때만 호출한다.
- 단계 산출물(문서/체크리스트/리뷰 결과)을 파일로 남기고, 다음 단계는 그 파일을 입력으로 삼는다.
¶ 평가 기준(운영 관점)
- 완결성: “중간에 끊겨도 다시 이어서 끝낼 수 있는가?”
- 컨텍스트/토큰 효율: 컨텍스트 누적과 메시지 왕복이 비용을 폭발시키는가?
- 병렬 처리 효율: 실제로 동시에 돌아가는 시간이 유의미한가, 대기 시간이 많은가?
- 품질 게이트: 리뷰/보안/검증이 구조적으로 강제되는가?
- 유지보수성: 워크플로우 자체를 개선/확장하기 쉬운가?
¶ Pipeline 방식 상세
¶ 핵심 아이디어
- Stage(단계) = 책임의 단위다.
- 단계마다 “무엇을 입력으로 받고, 무엇을 출력하는지”를 명확히 해서 컨텍스트를 파일로 외부화한다.
¶ 대표적인 6단계 예시
- Step 0: 초기화(입력 정리, 작업 분류, 산출물 디렉토리 준비)
- Step 1: 분석(요구사항 구조화, 범위/제약/리스크)
- Step 2: 설계(아키텍처/접근 방식)
- Step 3: 계획(태스크 분해, 커밋 단위/검증 전략)
- Step 4: 개발(구현 + 타입/테스트/빌드)
- Step 5: 리뷰(품질/보안/완료성 검증)
- Step 6: 보고(요약, 변경 영향, 다음 액션)
Step 번호/명칭은 팀마다 다를 수 있지만, “분석→실행→검증→보고”로 수렴하는 경우가 많다.
¶ 산출물 패턴(예시)
Pipeline은 “대화” 대신 “파일”로 상태를 남기는 게 핵심이다.
work/
README.md (업무 개요/요구사항)
MEMORY.md (핵심 결정/현재 상태)
HISTORY.md (완료 이력)
todos.md (실행 상태)
analysis/ (분석 산출물)
planning/ (설계/계획 산출물)
review/ (리뷰 산출물)
report/ (최종 보고/회고)
¶ 관찰된 장점
- 완결성/재개성: 파일 산출물 덕분에 “중단 후 재개”가 쉽다.
- 컨텍스트 보호: 단계별 격리(또는 파일 기반 전달)로 대화 컨텍스트가 덜 폭발한다.
- 유지보수성: Step별 스킬/프롬프트를 고도화하는 방식으로 개선이 단순하다.
¶ 관찰된 단점
- 병렬 작업의 상한: 단계형 구조라 “선행 단계가 끝나야” 다음이 자연스럽다.
- 즉흥 협업에는 둔감: 실시간 상호작용(디자인↔개발 즉시 피드백 등)은 Team이 더 자연스럽다.
¶ Team 방식 상세
¶ 핵심 아이디어
- Role(역할) = 책임의 단위다.
- 작업은 “단계”가 아니라 “사람(에이전트)” 기준으로 배치되며, 조율자가 메시지와 태스크 의존성으로 흐름을 만든다.
¶ 지속 컨텍스트(메모리) 패턴
Team 방식은 특히 프로젝트 메모리(MEMORY.md) 같은 장기 기록이 중심이 된다.
- Append-only(추가 전용)로 기록하면 “왜 그렇게 했는지”가 오래 살아남는다.
- 단점은, 기록이 커질수록 “현재 상태”를 뽑아내는 비용이 증가한다.
¶ 산출물 패턴(예시)
역할(부서/기능)별로 산출물이 분산되는 형태가 흔하다.
project/
commons/projects/{name}/MEMORY.md (공유 메모리)
planning/projects/{name}/... (기획 산출물)
engineering/projects/{name}/... (구현 산출물)
design/projects/{name}/... (디자인 산출물)
business/projects/{name}/... (비즈니스/법무/보안 등)
marketing/projects/{name}/... (마케팅)
¶ 관찰된 장점
- 동시성: 독립 태스크가 많을수록 Team의 장점이 커진다.
- 전문화: 역할별 “관점”이 나뉘어 있어 결과물의 폭이 넓어진다.
- 큰 프로젝트의 현실성: 실제 조직의 일하는 방식(기획/디자인/개발/검증)을 그대로 흉내내기 쉽다.
¶ 관찰된 단점 (실험에서 크게 체감)
- 토큰/컨텍스트 오버헤드: 메시지 왕복과 상태 공유가 누적되면 비용이 급격히 증가한다.
- 대기 시간: 순차 의존 구조의 작업에서는 한 에이전트가 끝날 때까지 다른 에이전트가 “대기”하게 된다.
- 운영 복잡도: 태스크 의존성/상태를 잘못 설계하면 오히려 혼란이 커진다.
¶ 비교 표 (운영/실전 관점)
| 항목 | Team(상주형 팀) | Pipeline(단계형 파이프라인) |
|---|---|---|
| 목표 적합성 | “여러 축을 동시에” | “하나를 끝까지” |
| 비용(토큰/컨텍스트) | 높아지기 쉬움 | 상대적으로 예측 가능 |
| 병렬성 | 강함(독립 태스크일 때) | Stage 내부 병렬은 가능, 전체는 순차적 |
| 완결성/재개 | 메모리가 좋으면 강함 | 산출물 기반이라 강함 |
| 품질 게이트 | 설계 없으면 약함 | 단계에 넣으면 강제 가능 |
| 운영 난이도 | 높음(조율 능력 필요) | 중간(단계 설계가 핵심) |
¶ 인사이트: 왜 Pipeline이 “실제 개발 업무”에서 유리했나
¶ 1) 개발 업무는 결국 순차 의존이 많다
겉으로는 병렬로 보이지만, 실제로는 다음과 같은 “의존성”이 강하다.
- 요구사항이 확정되기 전에는 설계를 확정하기 어렵다
- 설계가 없으면 구현이 흔들린다
- 구현이 끝나야 리뷰가 의미가 있다
즉, 병렬 워커를 많이 띄워도 앞 단계가 끝날 때까지 대기가 생기기 쉽다.
¶ 2) 메시지 대신 “산출물(파일)”이 컨텍스트 비용을 줄인다
- Team은 메시지 자체가 컨텍스트가 된다.
- Pipeline은 결과를 파일로 남기고, 다음 단계는 “파일을 읽는” 방식이라 컨텍스트가 덜 누적된다.
¶ 3) 실패를 ‘단계’로 격리하면 복구가 쉽다
- Pipeline은 Stage 단위로 “어디서 실패했는지”가 명확하고, 해당 단계만 재실행하면 된다.
- Team은 실패가 메시지와 태스크에 퍼지면 복구 비용이 커진다.
¶ 선택 가이드 (실전 체크리스트)
¶ Pipeline을 먼저 고려
- 단일 이슈/단일 기능을 분석→구현→검증→보고까지 한 흐름으로 끝내고 싶다
- 산출물을 남겨서 나중에 재개/인수인계 가능해야 한다
- 리뷰/보안/검증을 프로세스에 강제하고 싶다
¶ Team을 먼저 고려
- 독립 태스크가 3개 이상이고, 각 태스크가 서로 파일 충돌이 적다
- 기획/디자인/개발/검증을 동시에 진행해야 한다
- “역할 전문성”이 결과 품질에 크게 영향을 준다
¶ 운영 팁 (두 방식 모두 공통)
¶ 1) Orchestrator-Workers로 사고하기
- 오케스트레이터의 일은 대부분 결정(범위/우선순위) 과 검증(품질 게이트) 이다.
- 워커에게는 “파일 1개 / 섹션 1개 / 테스트 1개” 수준으로 책임을 좁혀야 한다.
¶ 2) HANDOFF(인수인계) 문서를 습관화하기
- “완료된 것 / 실패한 것 / 다음 커맨드 / 위험 요소” 4가지만 있어도 재개 효율이 급상승한다.
¶ 관련 문서
- Oh My ClaudeCode(OMC) 기능 총정리 레퍼런스dev/ai-agent/oh-my-claudecode-reference
- Oh My ClaudeCode(OMC) 온라인 활용기·팁 총정리dev/ai-agent/oh-my-claudecode-online-tips
- Claude Code Native Team vs OMC Team/Swarm — 아키텍처 심층 비교dev/ai-agent/claude-code-native-team-vs-omc-team
- Agent Team 구축 완벽 가이드dev/ai-agent/agent-team-building-guide
- Part 2: 5가지 워크플로우 패턴dev/ai-agent/claude-agent-guide/02-workflow-patterns
- Part 07: 오케스트레이션(마스터-워커, DAG, HANDOFF)dev/ai-agent/claude-code-agent-factory/07-orchestration-master-worker-handoff
- Part 08: 운영(비용/품질/가드레일/로그)dev/ai-agent/claude-code-agent-factory/08-ops-cost-quality-guardrails
- AI Agent/Claude Code 컨텍스트·토큰 관리 효율화dev/ai-agent/context-token-management
- Claude Code 토큰 효율화 실전 플레이북tips/claude-code-token-optimization-playbook