워크플로우 디자인 패턴

오케스트레이션 패턴을 조합해 실제 도메인에서 쓰이는 완결된 워크플로우를 설계하는 방법과 다양한 사례를 다룬다.

워크플로우란 무엇인가

2장 §4에서 배운 오케스트레이션 패턴 5가지 — 프롬프트 체이닝(파이프라인), 라우팅, 병렬화(팬아웃/투표), 오케스트레이터-워커, 평가자-최적화(검증-후-적용) — 은 단일 작업 단위에서 에이전트 간 협력을 구성하는 기본 빌딩 블록이다. 하지만 실무에서는 이 블록 하나만으로 업무를 완수하는 경우보다 여러 블록을 연결하고 겹쳐서 하나의 완결된 흐름을 만드는 경우가 훨씬 많다.

워크플로우(workflow)는 "하나 이상의 에이전트가 협력하여 복잡한 작업을 완수하는 과정 전체"를 말한다. 오케스트레이션 패턴이 어떻게 협력하는가에 대한 답이라면, 워크플로우는 전체 과정이 어떤 순서와 구조로 진행되는가에 대한 답이다. 워크플로우는 보통 다음 세 가지가 결합된다.

• 오케스트레이션 패턴의 조합 — 어떤 단계는 순차(파이프라인), 어떤 단계는 병렬(팬아웃), 어떤 분기는 조건(라우팅)으로 나뉜다.
• 도메인 규칙 — "코드 리뷰에서는 보안 관점과 성능 관점을 반드시 별도 검토해야 한다"처럼, 해당 업무 도메인에서 요구되는 규칙이다.
• 인간 승인 게이트 — 3장에서 배운 가드레일 원칙에 따라, 되돌릴 수 없는 지점 앞에서 반드시 사람이 확인하는 단계다.

이 장에서는 2장의 패턴을 이미 알고 있다고 전제한다. 모르는 용어가 나오면 2장 §4 오케스트레이션 패턴과 §4b 동적 팀 구성을 먼저 읽고 오자. 다음 절에서는 패턴을 넘어, 워크플로우를 구성하는 6가지 요소를 정리한다.

워크플로우 구성요소

복잡한 워크플로우를 분해하면 몇 가지 반복되는 구조 요소가 나온다. 2장의 5가지 패턴은 에이전트 간 협력 방식에 초점을 맞추었지만, 여기서는 워크플로우의 구조적 뼈대에 초점을 맞춘다.

이 요소들을 조합하면 거의 모든 실무 워크플로우를 표현할 수 있다. 다음 절에서는 실제 도메인에 이 요소들을 어떻게 배치하는지 사례별로 살펴본다.

실제 워크플로우 사례

5가지 도메인 워크플로우를 사례별로 정리한다. 각 사례는 핵심 패턴 조합, 스테이지 흐름, 담당 에이전트, 인간 게이트 위치를 보여준다. 이미 ai-workspace-standards에 구현된 베리언트(variant)와 연결된 사례도 포함한다.

사례에서 보이는 공통 패턴

5가지 사례에서 몇 가지 공통 구조가 드러난다.

• 모든 워크플로우에 인간 게이트가 있다. 자동화가 아무리 진척되어도 최종 산출물 확정, 병합, 배포 같은 되돌리기 어려운 결정 앞에는 사람의 승인이 필요하다. 이것이 3장에서 배운 가드레일의 실제 적용 지점이다.
• 팬아웃 뒤에는 반드시 취합이 온다. 병렬로 나뉜 결과를 그냥 나란히 놓아두면 소비자(다음 단계의 에이전트나 사람)가 직접 합성해야 한다. 취합 단계에서 명시적으로 하나의 산출물로 만들어야 다음 파이프라인 단계로 깔끔하게 넘어갈 수 있다.
• 검증 단계에서 루프이냐 에스컬레이션이냐가 워크플로우의 복잡도를 결정한다. 자동 수정이 가능한 문제(형식 위반, 오타)는 루프로 해결하고, 판단이 필요한 문제(설계 결함, 보안 취약점)는 에스컬레이션으로 사람에게 넘긴다.
• 단순한 파이프라인은 잘 쓰이지 않는다. 5가지 사례 중 "순수하게 순차적인" 워크플로우는 없다. 최소한 한 곳에 라우팅(분기)이나 팬아웃(병렬)이 들어간다.

서브에이전트 로스터 — 워크플로우를 구성하는 에이전트 목록

2장에서 "에이전트"를 역할(role)로 모델링한다는 것을 배웠다. 실제 워크스페이스에서는 이 역할들이 구체적인 파일과 티어 배정으로 정의되어 로스터에 등록된다. AGENTS.md의 서브에이전트 로스터는 이 정의를 한눈에 볼 수 있는 테이블이다.

이 테이블의 "병렬 실행" 열은 8장 §4에서 다룬 Tier Adjustment Rules과 함께 해석해야 한다. 예를 들어 docs-writer는 "설계 이후"에만 병렬 실행 가능한데, 이것은 설계가 확정되지 않은 상태에서 문서를 병렬로 작성하면 나중에 전부 갈아 엎야 할 위험이 있기 때문이다. 반면 Auditor는 "독립 QA"로, 다른 에이전트의 작업과 무관하게 언제든 독립적으로 실행될 수 있다.

역할 경계 매트릭스 — "누가 이 작업을 해야 하는가"

에이전트가 여럿일 때, "누가 이 작업을 맡아야 하는가"가 모호해질 수 있다. 다음 매트릭스는 그 모호함을 해소하는 역할 경계(role boundary)를 정의한다.

이 매트릭스의 핵심 원칙은 "설계와 실행을 분리"한다는 것이다. architect는 설계만 하고 스크립트를 직접 작성하지 않으며, automation-engineer는 스크립트를 작성하지만 구조를 설계하지 않는다. docs-writer가 문서를 검증하는 것이 아니라 auditor가 검증하고, docs-writer는 auditor가 쓴 피드백을 반영해 문서를 수정하는 식이다.

PM 페이즈 파이프라인 — 워크플로우의 거버넌스 관점

이 장에서 다룬 워크플로우 패턴(라우팅, 팬아웃, 파이프라인 등)은 기술적 구성요소의 관점이다. 실제 워크스페이스에서는 이 기술적 패턴 위에 거버넌스 페이즈가 겹쳐진다. PM이 관리하는 7단계 페이즈를 워크플로우 관점에서 정리하면 다음과 같다.

이 7단계 페이즈는 §3의 워크플로우 사례와 직접 대응된다. 예를 들어 "코드 리뷰" 사례의 전체 흐름은 Phase 1~2(분석) → Phase 4(검토 실행) → Phase 6(QA)의 축소판이다. 실무에서 새 워크플로우를 설계할 때 이 페이즈를 염두에 두면 "어디에 인간 게이트를 둘 것인가"와 "병렬 실행이 안전한 단계는 어디인가"를 더 체계적으로 결정할 수 있다.

절차 스키마 — 워크플로우의 선언적 SSOT (ADR-0063)

이 장의 패턴들이 "사례"라면, 절차 스키마는 그 사례들을 기계가 읽는 선언으로 끌어올린 장치다. variant 템플릿의 procedures/<name>/schema.yaml에 워크플로우 단계를 {id, agent_key, skill_key, output_type, description}으로 기록하고, 단계 사이의 관계는 follows·enables·composes_with 타입으로 선언한다(참고 C 참조).

• 검증은 저장소 일관성 검사 — scripts/validate-procedures.ts가 스키마 형태, 열거형, 닫힌 _output-types.yaml 어휘, 그리고 모든 agent_key/skill_key가 실제 에이전트 파일·스킬 디렉터리로 해결되는지를 검사한다. /sync가 실패 시 중단된다
• 그래프와의 연결 — 절차에서 유도된 그래프 노드(procedure, output_type)와 엣지(step_uses_skill, step_by_agent, produces)는 생성 투영이다. 손으로 고치는 것은 금지되고, 절차를 고쳐 재생성한다
• 커버리지는 (agent_key, phase) 단위 — 에이전트 프론트매터의 phases:가 필요한 쌍을 선언하면, 실제 절차 단계가 그 쌍을 덮는지 scripts/procedure-coverage.ts가 보고한다. 갭은 절대 자동 채워지지 않고, --tickets로 결정적 키(<variant>:<agent_key>:<phase>)의 거버넌스 티켓이 등록돼 사람이 판단한다

요컨대 워크플로우 지식 — 어느 에이전트가 어느 단계에서, 어떤 스킬로, 무엇을 산출하는가 — 가 산문이 아니라 검증 가능한 데이터가 된다. 이것이 9장의 패턴들과 절차 스키마의 차이다.

2026-09부터는 이 절차 계층 위에 도메인 스테이지 축이 얹혀, 활동들을 도메인 업무 흐름의 단계로 묶고 RACI와 결정 게이트로 책임과 판정까지 선언하는 Domain Operating Model 구조가 갖춰졌다. 자세한 내용은 13장 · Domain Operating Model에서 다룬다.

워크플로우 선택 가이드

새로운 업무에 멀티 에이전트 워크플로우를 도입하려면, 어떤 패턴으로 시작하고 어떻게 확장해 나갈지 결정해야 한다. 다음 의사결정 나무는 첫 단계를 고르는 데 도움이 된다.

업무 유형별 시작 패턴

의사결정 나무의 결과를 업무 유형별로 정리하면 다음과 같다.

패턴 조합 가이드

어떤 패턴을 함께 쓰면 시너지가 나는지 정리한다.