정적에서 적응형으로: 공유 작업 공간 기반의 동적 에이전트 오케스트레이션 시스템

Cockpit 아키텍처와 크로스 플랫폼 에이전트 협업 모드

📌 핵심 요약

대규모 언어 모델(LLM)의 성능이 향상됨에 따라, 단일 에이전트는 복잡하고 장기적인 작업을 처리할 때 에이전트 태만, 자기 선호 편향, 목표 이탈과 같은 본질적인 한계를 드러냈습니다.

Claude Code가 제안한 동적 워크플로우는 다중 인스턴스 격리와 작업 맞춤형 오케스트레이션을 통해 이러한 문제를 해결하지만, 단일 모델 제품군과 상태 비저장 오케스트레이션 설계로 인해 실제 적용 시나리오가 제한됩니다.

이 글에서는 Cockpit 아키텍처—공유 작업 공간을 기반으로 하는 적응형 에이전트 오케스트레이션 시스템을 제안합니다. 이 아키텍처는 다음을 도입합니다:

• 🎯 중앙 집중식 상태 관리 계층 (Cockpit)
• 🧠 지능형 코디네이터 (PM)
• 🤖 이기종 에이전트 풀 (Worker Pool)

동적 워크플로우의 핵심 장점을 유지하면서, 크로스 플랫폼 에이전트 협업과 과거 성과 기반 적응형 최적화를 달성합니다.

실제 적용 결과, Cockpit 아키텍처는 코드 마이그레이션 및 심층 연구와 같은 복잡한 작업에서 더 높은 작업 완료율과 더 나은 엔지니어링 제어 가능성을 보여줍니다.

키워드

: 동적 워크플로우 · 에이전트 오케스트레이션 · 공유 작업 공간 · 적응형 시스템 · 크로스 플랫폼 협업

01 서론: 딜레마에서 돌파구로

🔴 단일 컨텍스트의 세 가지 딜레마

실제 AI 에이전트 애플리케이션에서 개발자는 일반적으로 가장 직접적인 접근 방식을 취합니다: Claude, GPT 또는 다른 LLM이 단일 대화 창에서 작업을 완료하도록 하는 것입니다.

이 방식은 간단한 시나리오에서는 잘 작동하지만, 작업이 복잡해져 50개의 파일 검토, 전체 코드베이스 마이그레이션, 또는 심층 연구 수행이 필요해지면 단일 컨텍스트 방식은 시스템적인 문제를 드러내기 시작합니다.

Anthropic의 Claude Code 동적 워크플로우 출시 문서는 세 가지 실패 모드를 명확히 지적합니다:

💤 에이전트 태만 (Agentic Laziness)

에이전트가 작업의 일부만 완료하고 작업이 완료되었다고 조기에 주장합니다.

일반적인 시나리오: 보안 감사에서 50개 항목 중 20개를 처리하고 나머지는 "처리됨"으로 표시합니다.

🎭 자기 선호 편향 (Self-preferential Bias)

에이전트가 자신의 출력을 검증하도록 요청받을 때, 자신의 결과를 선호하는 경향이 있습니다.

핵심 문제: 결과에 이해관계가 있는 검증자는 공정한 판사가 될 수 없습니다.

🌊 목표 이탈 (Goal Drift)

다중 턴 상호 작용, 특히 컨텍스트 압축 후에 에이전트가 원래 목표에서 점차 벗어납니다.

실제 사례: "X를 하지 마라"는 제약 조건이 대화 47번째 라운드쯤에 조용히 사라집니다.

🟢 동적 워크플로우의 약속

이러한 문제를 해결하기 위해 Anthropic은 2026년 5월에 동적 워크플로우(Dynamic Workflows) 기능을 출시했습니다.

핵심 아이디어: Claude가 특정 작업에 대해 맞춤화된 조정 프레임워크를 자동으로 생성하도록 하는 것입니다. 이는 특수 함수를 통해 여러 하위 에이전트를 생성하고 조정하는 JavaScript 파일이며, 각 하위 에이전트는 독립적인 컨텍스트 창과 집중된 목표를 가집니다.

세 가지 핵심 기능

✅ 에이전트별 격리: 각 하위 에이전트는 독립적인 컨텍스트를 가지므로 간섭을 방지합니다.

✅ 에이전트별 모델 선택: 복잡한 추론에는 Opus를, 저비용 탐색에는 Haiku를 사용합니다.

✅ 에이전트별 격리 수준: 작업 트리(독립적인 Git 체크아웃) 또는 원격 저장소.

여섯 가지 핵심 패턴

Anthropic 엔지니어들은 반복적으로 나타나는 여섯 가지 오케스트레이션 패턴을 요약했습니다:

• 🔀 분류 및 라우팅 (Classify-and-Route)
• 🌟 분산 및 합성 (Fan-out & Synthesize)
• ⚔️ 적대적 검증 (Adversarial Verification)
• 🎯 생성 및 필터링 (Generate-and-Filter)
• 🏆 토너먼트 순위 (Tournament Ranking)
• 🔄 완료될 때까지 반복 (Loop Until Done)

이러한 패턴은 단일 컨텍스트의 실패 모드를 구조적으로 해결합니다.

▲ 단일 컨텍스트의 세 가지 실패 모드: 에이전트 태만, 자기 선호 편향, 목표 이탈

🟡 이론과 엔지니어링 실제 사이의 격차

그러나 동적 워크플로우는 실제 엔지니어링 애플리케이션에서 두 가지 주요 제한 사항에 직면합니다:

⚠️ 단일 모델 제품군 제한

동적 워크플로우는 Claude 제품군 모델(Opus/Sonnet/Haiku)만 사용할 수 있습니다.

실제 시나리오에서는 다양한 플랫폼의 에이전트가 각기 다른 강점을 가지고 있습니다:

• Claude Code는 코드 리팩토링에 탁월합니다.
• Codex는 알고리즘 구현에서 뛰어난 성능을 보입니다.
• Gemini는 멀티모달 작업에서 장점이 있습니다.

단일 모델 제품군으로는 다양한 플랫폼의 전문성을 완전히 활용할 수 없습니다.

⚠️ 상태 비저장 오케스트레이션

모든 작업은 완전히 새로운 워크플로우 스크립트를 생성합니다. 에이전트 간에 과거 기록이 없습니다.

문제점:

• 과거 성과를 기반으로 에이전트 선택 전략을 최적화할 수 없습니다.
• 작업 간에 지식을 축적할 수 없습니다.
• 매번 "처음부터 시작"해야 합니다.

💡 Cockpit 아키텍처: 격차를 해소하는 솔루션

이 글에서 제안하는 Cockpit 아키텍처는 이러한 격차를 해소하기 위해 설계되었습니다.

우리는 동적 워크플로우의 핵심 장점을 유지합니다:

• ✅ 다중 인스턴스 격리
• ✅ 동적 오케스트레이션

동시에 새로운 기능을 도입합니다:

• 🆕 공유 작업 공간
• 🆕 적응형 메커니즘
• 🆕 크로스 플랫폼 협업

더 유연하고 지능적인 에이전트 협업 모드를 달성합니다.

02 동적 워크플로우 이론 검토

정적 vs. 동적: 두 패러다임의 비교

동적 워크플로우를 이해하기 전에 정적 워크플로우의 개념을 명확히 할 필요가 있습니다.

🔵 정적 워크플로우: 사전 정의된 고정 프로세스

N8N 또는 Zapier와 같은 시각적 자동화 플랫폼을 사용하든, Claude Agent SDK로 작성된 조정 스크립트를 사용하든, 특징은 다음과 같습니다:

예시: N8N에서 설계된 "코드 리뷰 워크플로우"

1코드 추출 → Claude 호출하여 분석 → 결과 저장 → 알림 전송

검토하는 코드가 무엇이든 프로세스는 동일합니다.

🟣 동적 워크플로우: 작업 맞춤형 실행 계획

Claude가 현재 작업에 맞춰 조정한 실행 계획:

예시: 동일한 코드 리뷰에 대해 동적 워크플로우는 다음과 같이 할 수 있습니다:

1. 먼저 코드베이스를 스캔하여 React 프로젝트임을 식별합니다.
2. 컴포넌트 복잡성에 따라 Haiku 또는 Opus를 사용할지 결정합니다.
3. Hooks 사용에 대한 전문 리뷰 에이전트를 생성합니다.
4. TypeScript 타입 검사 단계를 추가합니다.
5. 순차적으로 처리하는 대신 병렬로 처리합니다.

여섯 가지 핵심 패턴 상세 설명

Anthropic 엔지니어들은 실제 경험에서 반복적으로 나타나는 여섯 가지 오케스트레이션 패턴을 요약했습니다:

1️⃣ 분류 및 라우팅 (Classify-and-Route)

분류 에이전트를 사용하여 작업 유형을 결정한 다음, 다른 처리 에이전트로 라우팅합니다.

시나리오: "인증 모듈이 어떻게 작동하는지 설명하세요"

• 분류 에이전트가 먼저 복잡성을 평가합니다.
• 간단한 모듈은 Sonnet을 사용합니다.
• 복잡한 모듈은 Opus를 사용합니다.

2️⃣ 분산 및 합성 (Fan-out & Synthesize)

작업을 여러 독립적인 하위 작업으로 분해하고, 병렬로 실행한 후, 마지막으로 결과를 집계합니다.

핵심 가치: "한 번에 너무 많은 것을 처리하는" 문제를 해결합니다. 각 하위 에이전트는 자신의 부분만 보고 50개의 관련 없는 세부 사항에 주의가 산만해지지 않습니다.

💡

이것은 가장 많이 사용되는 패턴입니다.

3️⃣ 적대적 검증 (Adversarial Verification)

각 생성된 결과에 대해 독립적인 검증 에이전트를 만듭니다. 이 검증자는 원본 작업을 본 적이 없으므로 자기 선호 편향을 생성할 수 없습니다.

구조적 해결책: 자기 선호 편향을 해결하는 근본적인 방법입니다.

4️⃣ 생성 및 필터링 (Generate-and-Filter)

여러 후보 솔루션을 생성한 다음 검증자를 사용하여 필터링합니다.

핵심 차이점: "최고의 답변"을 직접 요청하는 것과 달리, 이 패턴은 에이전트가 약속을 지연하여 모든 옵션이 검토된 후에 결정을 내리도록 합니다.

5️⃣ 토너먼트 순위 (Tournament Ranking)

동일한 작업에 대해 여러 에이전트가 경쟁하게 하고, 쌍별 비교를 통해 승자를 결정합니다.

적용 가능 시나리오: 취향 중심 작업

• 디자인 선택
• 명명 방식
• UI 결정

핵심 장점: 비교 판단이 절대 점수보다 더 신뢰할 수 있습니다.

6️⃣ 완료될 때까지 반복 (Loop Until Done)

중지 조건이 충족될 때까지 에이전트를 계속 생성합니다.

중지 조건 예시:

• 새로운 발견이 없음
• 로그에 오류 없음
• 이론 검증됨

보장: "완료되었다고 주장하는 것"이 아닌 "진정한 완료".

▲ 여섯 가지 핵심 오케스트레이션 패턴: 분류 및 라우팅, 분산 및 합성, 적대적 검증, 생성 및 필터링, 토너먼트 순위, 완료될 때까지 반복

기존 솔루션의 한계

동적 워크플로우는 이론적으로 우아하지만, 엔지니어링 실제에서는 네 가지 주요 단점이 있습니다:

핵심 질문: 동적 오케스트레이션의 장점을 유지하면서 엔지니어링 제어 가능성을 갖춘 아키텍처를 설계할 수 있을까요?

03 Cockpit 아키텍처 설계

시스템 개요: 3계층 아키텍처

Cockpit 아키텍처는 3계층 설계를 채택합니다:

1┌─────────────────────────────────────────┐
2│      Cockpit (공유 작업 공간 계층)        │
3│  ┌──────┬──────┬──────────────────┐    │
4│  │ Plan │ Tasks│ Research         │    │
5│  │ 목표  │ 진행  │ 연구             │    │
6│  ├──────┼──────┼──────────────────┤    │
7│  │Reports│Issues│ Knowledge Base  │    │
8│  │ 보고서│ 이슈  │ 지식 베이스       │    │
9│  └──────┴──────┴──────────────────┘    │
10└─────────────────────────────────────────┘
11              ↕️ 읽기/쓰기 액세스
12┌─────────────────────────────────────────┐
13│         PM (조정 계층)                    │
14│  • 작업 분해                             │
15│  • 작업자 선택 (과거 성과 기반)            │
16│  • 진행 상황 모니터링                     │
17│  • 계획 유지 관리                        │
18└─────────────────────────────────────────┘
19         ↕️ 작업 할당 및 결과 수집
20┌─────────────────────────────────────────┐
21│      Worker Pool (실행 계층)              │
22│  ┌────────┬────────┬──────────────┐    │
23│  │ Claude │ Codex  │ Gemini       │    │
24│  │ Code   │ Agent  │ Agent        │    │
25│  └────────┴────────┴──────────────┘    │
26│       ↕️ Cockpit에 작업 상태 업데이트       │
27└─────────────────────────────────────────┘

▲ Cockpit 3계층 아키텍처: 공유 작업 공간 계층, PM 조정 계층, Worker 실행 계층

핵심 설계 개념: 모든 에이전트는 메시지 전달을 통해 협업하는 대신 동일한 "화이트보드"(Cockpit)를 중심으로 작업합니다.

💡

소프트웨어 팀이 서로 이메일을 보내는 대신 Git 저장소 + 프로젝트 보드를 중심으로 협업하는 것과 유사합니다.

Cockpit 컴포넌트 설계: 6가지 핵심 컴포넌트

Cockpit은 시스템의 신경 중추이며, 6가지 핵심 컴포넌트를 포함합니다.

다음은 실제 운영 중인 Cockpit 인터페이스입니다:

▲ Cockpit Plan 뷰 - 프로젝트 목표 및 마일스톤 진행 상황 표시

▲ Cockpit Task 뷰 - 작업 완료 상태 실시간 추적

▲ Cockpit Timeline 뷰 - Worker 활용도 분석 및 Dispatch 추세

📋 Plan (목표 고정)

기능:

• 핵심 프로젝트 목표와 제약 조건을 저장합니다.
• 모든 에이전트는 실행 전에 Plan을 읽어 목표를 정렬해야 합니다.

가치: 목표 이탈을 방지합니다. 여러 번의 상호 작용 후에도 원래 의도가 명확하게 유지됩니다.

실제 데이터: 스크린샷에서 HippoTeam 프로젝트 진행률은 89% (187/209)이며, M1-M6의 6개 마일스톤을 포함하며 각각 명확한 완료 상태가 있습니다.

✅ Tasks (진행 상황 추적)

기능:

• 모든 하위 작업의 상태(보류 중, 진행 중, 완료됨)를 기록합니다.
• Worker는 작업 완료 후 상태를 업데이트합니다.
• PM은 실시간 상태를 기반으로 후속 오케스트레이션을 조정합니다.

가치: "에이전트 태만"을 해결합니다. 작업 완료 여부가 한눈에 파악되어 허위 보고를 방지합니다.

실제 데이터: 실제 운영 중 408개의 작업이 있으며, 완료율은 401/408이고 상세한 디스패치 기록을 볼 수 있습니다.

🔬 Research (연구 축적)

기능:

• 연구 과정에서 수집된 정보를 저장합니다.
• 모든 에이전트가 액세스할 수 있어 중복 연구를 방지합니다.

가치: 지식 재사용 및 반복적 심화를 지원합니다.

실제 데이터: 현재 시스템에 71개의 연구 기록이 있습니다.

📊 Reports (산출물 관리)

기능:

• 각 단계의 출력 결과를 저장합니다.
• 버전 추적 및 롤백을 지원합니다.

가치: 최종 집계 및 품질 검사를 용이하게 합니다.

실제 데이터: 시스템에 78개의 보고서가 축적되었습니다.

⚠️ Issues (이슈 관리)

기능:

• 실행 중 발견된 문제를 기록합니다.
• 모든 에이전트가 Issue를 추가할 수 있습니다.

가치: PM은 Issue를 기반으로 전략을 조정하거나 수리 작업을 할당합니다.

📚 Knowledge Base (지식 베이스)

기능:

• 작업 간 지식 축적.
• Worker의 운영 통계를 기록합니다.

가치: 인간 분석 및 미래의 적응형 최적화를 위한 데이터 기반을 제공합니다.

실제 구현: Timeline 뷰를 통해 Worker 과거 성과를 기록합니다. 스크린샷에서 Guan Yu (55회 디스패치, 평균 12분), Zhao Yun (21회 디스패치, 평균 10분), Dian Wei (20회 디스패치, 평균 10분), Zhang Fei (4회 디스패치, 평균 7분)에 대한 상세 데이터와 05-20부터 05-25까지의 Dispatch 추세 차트를 볼 수 있습니다. 이 데이터는 현재 모니터링 및 인간 분석에 사용되며, 향후 자동 피드백 루프를 구축하는 데 사용될 수 있습니다.

💡

보조 컴포넌트: 실제 시스템에는 Ideas (아이디어 풀, 평가 보류 중 4개) 및 Decisions (의사 결정 기록, 24개) 와 같은 보조 모듈도 포함되어 있어 "생성 및 필터링"과 같은 고급 패턴을 지원합니다.

데이터 흐름 및 상호 작용 메커니즘

PM 오케스트레이션 메커니즘을 자세히 살펴보기 전에 에이전트와 Cockpit 간의 데이터 흐름을 이해해 보겠습니다.

🔄 에이전트-Cockpit 데이터 흐름 다이어그램

▲ 에이전트와 Cockpit 간의 완전한 데이터 흐름 상호 작용

핵심 상호 작용 경로:

핵심 설계:

• ✅ 단방향 종속성: Worker는 Cockpit에 종속되지만 PM이나 다른 Worker와 직접 통신하지 않습니다.
• ✅ 중앙 집중식 상태: 모든 상태 변경은 Cockpit을 통해 이루어져 전역 일관성을 보장합니다.
• ✅ 비동기 디커플링: Worker는 작업 완료 후 PM의 응답을 기다리지 않고 상태를 업데이트하기만 하면 됩니다.

🔒 동시 액세스를 위한 상태 동기화 메커니즘

여러 Worker가 동시에 Cockpit에 액세스할 때 데이터 일관성은 어떻게 보장됩니까?

▲ 다중 Worker 동시 액세스를 위한 상태 동기화 메커니즘

3계층 보장 메커니즘:

1️⃣ 낙관적 잠금 (Optimistic Lock)

각 Cockpit 컴포넌트는 버전 번호를 유지 관리합니다:

1Tasks v1 → Worker A 읽음
2Tasks v1 → Worker B 읽음
3
4Worker A 업데이트 제출 → 버전 v1 확인 → 성공 → Tasks v2
5Worker B 업데이트 제출 → 버전 v1 확인 → 충돌 감지 → 자동 재시도

장점: 대부분의 경우 잠금이 필요 없어 성능이 높습니다.

2️⃣ 트랜잭션 큐 (Transaction Queue)

모든 쓰기 작업은 큐에 들어가 순차적으로 실행됩니다:

1Worker #1: Task-001 상태 업데이트 → 큐 위치 1
2Worker #2: Report-042 쓰기 → 큐 위치 2
3Worker #3: Issue-015 추가 → 큐 위치 3
4Worker #4: Task-002 상태 업데이트 → 큐 위치 4

보장: 쓰기 작업의 원자성과 순서.

3️⃣ 충돌 감지 및 자동 재시도

버전 충돌이 감지되면:

1. 롤백: 현재 업데이트를 폐기합니다.
2. 재읽기: 최신 상태를 가져옵니다.
3. 재계산: 새 상태를 기반으로 업데이트를 다시 생성합니다.
4. 재제출: 다시 쓰기를 시도합니다.

실제 사례:

Worker A와 Worker B가 Task-001과 Task-002를 동시에 완료하고, 둘 다 Tasks 컴포넌트의 완료율 통계를 업데이트하려고 합니다.

- Worker A가 먼저 제출하고, Tasks가 v5에서 v6으로 업데이트되며, 완료율은 400/408입니다.

- Worker B는 제출 시 버전이 (자신이 읽은 v5가 아닌) v6으로 변경되었음을 감지합니다.

- 시스템은 자동으로 Worker B가 v6을 다시 읽고 완료율을 401/408로 다시 계산하도록 합니다.

- Worker B가 성공적으로 제출하고, Tasks가 v7로 업데이트됩니다.

성능 최적화:

• 🟢 잠금 없는 읽기 작업: 여러 Worker가 동시에 읽을 수 있으며 서로를 차단하지 않습니다.
• 🟡 경량 쓰기 작업: 대부분의 업데이트는 추가 작업(Reports, Issues 추가)이므로 충돌 가능성이 낮습니다.
• 🔴 드문 충돌: 충돌은 동일한 작업 상태를 동시에 업데이트할 때만 발생하며, 실제 발생률은 < 2%입니다.

PM 적응형 오케스트레이션 메커니즘

PM(Project Manager)은 시스템의 두뇌이며 동적 오케스트레이션을 담당합니다.

Claude 동적 워크플로우의 상태 비저장 오케스트레이션과 달리, Cockpit PM은 메모리와 학습 능력을 가지고 있습니다.

🧩 작업 분해

프로세스:

1. 사용자 요구 사항을 받은 후 PM은 작업 특성을 분석합니다.
2. Cockpit에서 과거 데이터와 현재 컨텍스트를 읽습니다.
3. 작업을 병렬 또는 직렬 하위 작업으로 분해합니다.
4. Plan 및 Tasks 컴포넌트를 업데이트합니다.

🎯 역할 기반 Worker 선택

PM은 작업 유형과 Worker 역할에 따라 지능적으로 할당합니다:

의사 결정 프로세스:

11️⃣ 작업 유형 식별
2   코드 리팩토링 / 알고리즘 구현 / 코드 리뷰 / 멀티모달 분석
3
42️⃣ 역할 사전 설정 매칭
5   coder / tester / reviewer / researcher
6
73️⃣ 명시적 사용자 할당 고려
8   특정 Worker에게 할당된 특정 작업
9
104️⃣ 현재 부하 고려
11   Worker의 현재 작업 수 및 가용성

실제 운영 사례:

HippoTeam의 실제 운영 데이터에서 다음을 볼 수 있습니다:

코드 리팩토링 작업

→ coder 역할을 가진 Worker(Guan Yu, Zhao Yun, Dian Wei)에게 할당됨

코드 리뷰 작업

→ 적대적 검증을 보장하기 위해 독립적인 reviewer 역할(Zhong Kui)에게 할당됨

알고리즘 구현 작업

→ 복잡성에 따라 적절한 coder Worker가 선택됨

Timeline 모니터링: 시스템은 Timeline 뷰를 통해 각 Worker의 디스패치 횟수와 평균 완료 시간(예: Guan Yu 55회/평균 12분, Zhao Yun 21회/평균 10분)을 기록하여 인간 분석 및 역할 구성 조정을 용이하게 합니다.

💡

향후 방향: 현재 Timeline 데이터는 표시용입니다. 향후 피드백 루프를 구축하여 PM이 과거 성과를 기반으로 Worker 선택 전략을 자동으로 최적화하도록 할 수 있습니다.

📈 진행 상황 모니터링 및 동적 조정

실시간 기능:

• Tasks 상태를 실시간으로 읽습니다.
• Worker가 장시간 응답하지 않으면 작업을 재할당합니다.
• Issues에 차단 문제가 나타나면 실행 계획을 조정합니다.

Worker Pool 설계

Worker Pool은 시스템의 실행 계층이며 여러 이기종 에이전트를 포함합니다.

🌐 크로스 플랫폼 이기종 에이전트

Claude 동적 워크플로우가 Claude 제품군만 사용할 수 있는 것과 달리, Cockpit은 모든 플랫폼의 에이전트를 지원합니다:

각 플랫폼은 여러 인스턴스(예: Claude Code #1, #2, #3)를 가질 수 있어 진정한 병렬 처리를 달성합니다.

⚖️ 고정 역할 vs. 동적 책임

이것은 핵심 엔지니어링 트레이드오프입니다.

Cockpit은 "고정 역할 풀 + 동적 책임 할당" 모드를 채택합니다:

✅ 고정 역할: Worker 능력 경계가 사전 정의됩니다(Claude Code는 코드 전문가, Gemini는 멀티모달 전문가).

✅ 동적 책임: 특정 작업은 상황에 따라 PM이 동적으로 할당합니다.

설계 장점:

🔄 상태 업데이트 프로토콜

작업을 완료한 후 Worker는 Cockpit을 업데이트해야 합니다:

• ✅ Tasks에서 작업 상태를 업데이트합니다.
• 📄 결과를 Reports에 씁니다.
• ⚠️ 문제가 발견되면 Issue를 추가합니다.
• 📚 축적된 지식을 Research에 씁니다.

이것은 시스템 상태의 일관성과 추적 가능성을 보장합니다.

▲ 공유 작업 공간을 중심으로 협업하는 크로스 플랫폼 이기종 에이전트

Cockpit에서의 6가지 패턴 구현

Cockpit 아키텍처는 Claude 동적 워크플로우의 6가지 패턴과 완벽하게 호환되며 구현을 향상시킵니다:

🔀 분류 및 라우팅 (Classify-and-Route)

구현:

• PM이 분류자 역할을 하여 작업 특성에 따라 적절한 Worker를 선택합니다.

향상:

• 원래 패턴과 달리 PM의 분류 결정은 과거 데이터를 기반으로 하여 더 정확합니다.

🌟 분산 및 합성 (Fan-out & Synthesize)

구현:

• PM이 작업을 분해하고 여러 Worker에 병렬로 할당합니다.
• 모든 Worker는 결과를 Cockpit의 Reports에 씁니다.
• PM은 모든 결과를 읽고 집계 및 합성을 수행합니다.

⚔️ 적대적 검증 (Adversarial Verification)

구현:

• PM은 각 생성 작업에 대해 독립적인 검증 Worker를 할당합니다.
• 검증 Worker는 Reports에서 결과만 읽고 누가 생성했는지 알지 못합니다.
• 검증 결과는 Issues에 기록되며, PM은 Issues를 기반으로 재실행 여부를 결정합니다.

🎯 생성 및 필터링 (Generate-and-Filter)

구현:

• PM은 여러 Worker를 할당하여 후보 솔루션을 생성합니다.
• 그런 다음 검증 Worker를 할당하여 필터링하고 점수를 매깁니다.
• 최적의 솔루션은 Reports에 기록됩니다.

🏆 토너먼트 순위 (Tournament Ranking)

구현:

• PM이 쌍별 비교를 구성하고, 매번 두 개의 비교 작업을 Worker에게 할당합니다.
• 비교 결과는 Cockpit에 기록되며, PM이 순위를 유지 관리합니다.
• 최종 승자는 Reports에 기록됩니다.

🔄 완료될 때까지 반복 (Loop Until Done)

구현:

• PM은 Tasks 및 Issues의 상태를 확인합니다.
• 완료되지 않은 작업이나 해결되지 않은 Issue가 있는 한 계속 Worker를 할당합니다.
• 모든 Tasks가 완료로 표시되고 Issues가 비워질 때까지 계속합니다.

04 주요 설계 결정

왜 고정 역할 풀을 선택했는가?

Cockpit을 설계할 때 우리는 핵심 질문에 직면했습니다:

Claude 동적 워크플로우처럼 매번 에이전트를 임시로 생성해야 할까요, 아니면 고정 에이전트 풀을 유지해야 할까요?

우리는 다음과 같은 이유로 후자를 선택했습니다:

💰 비용 제어 가능성

에이전트를 임시로 생성하면 비용이 통제 불능이 될 수 있습니다.

위험 시나리오: 복잡한 작업에서 제한 없이 시스템이 수십 또는 수백 개의 에이전트 인스턴스를 생성할 수 있습니다.

해결책: 고정 역할 풀은 동시 실행 상한을 설정하여 비용을 예측 가능하게 만듭니다.

🛠️ 엔지니어링 안정성

고정 역할은 각 에이전트의 능력 경계가 명확하다는 것을 의미하며, 다음을 용이하게 합니다:

• 모니터링
• 디버깅
• 최적화

비교: 임시로 생성된 에이전트는 추적하기 어렵고 문제 발생 시 위치를 찾기 어렵습니다.

🌐 크로스 플랫폼 장점

고정 역할 풀을 사용하면 다양한 플랫폼의 에이전트를 통합하고 각자의 강점을 활용할 수 있습니다.

제한 사항: 임시 생성 모드는 플랫폼 간 조정이 어렵습니다.

📊 적응형 학습의 기반

고정 역할이 있어야만 각 에이전트의 과거 성과 데이터를 축적하고 성과에 따라 지능적으로 할당할 수 있습니다.

이것이 유연성을 잃는다는 의미는 아닙니다

PM은 여전히 동적으로 다음을 결정할 수 있습니다:

• ✅ 이 작업을 누구에게 할당할지.
• ✅ 병렬 처리를 위해 몇 명의 Worker를 사용할지.
• ✅ 적대적 검증이 필요한지 여부.
• ✅ 루프를 중지할 시기.

💡

고정된 것은 역할이고, 동적인 것은 오케스트레이션 전략입니다.

공유 워크스페이스 vs. 메시지 전달 방식

Agent 협업 분야에서 주류 솔루션은 메시지 전달 모드입니다:

1Agent A가 작업 완료 → 결과를 메시지로 전송 → Agent B

이 모드는 간단하고 직관적이지만 문제점이 있습니다:

❌ 메시지 전달 방식의 세 가지 주요 문제점

✅ Cockpit의 공유 워크스페이스 모드

장점:

비유: 소프트웨어 개발의 패러다임 전환

1"이메일 커뮤니케이션" → "Git 저장소 기반 협업"

후자는 협업 효율성을 획기적으로 향상시킵니다.

크로스 플랫폼 Agent의 장점

Cockpit 아키텍처의 가장 큰 장점 중 하나는 크로스 플랫폼 Agent 하이브리드 오케스트레이션을 지원한다는 점입니다.

🎯 플랫폼 강점 활용

🛡️ 플랫폼 의존성 리스크 감소

단일 플랫폼에 종속되지 않으므로, 플랫폼 장애나 속도 제한 발생 시 빠르게 대안으로 전환할 수 있습니다.

💰 비용 최적화

작업 복잡도에 따라 적합한 모델을 선택하세요:

• 간단한 작업 → 저비용 모델
• 복잡한 작업 → 고성능 모델

PM의 적응형 메커니즘은 점진적으로 최적의 비용-품질 균형점을 찾아갑니다.

🏗️ 실제 사례

시나리오: 코드베이스 마이그레이션 작업

💡

이러한 하이브리드 오케스트레이션은 단일 플랫폼 솔루션에서는 구현이 불가능합니다.

세 가지 모드 종합 비교

▲ 세 가지 워크플로우 패러다임의 진화: 정적 → 동적 → 협업

적용 시나리오 추천

🔵 정적 워크플로우(N8N/Zapier) 사용 시:

• ✅ 작업 프로세스가 매우 고정적이고 변경이 거의 필요 없을 때
• ✅ 복잡한 Agent 협업이 필요하지 않을 때
• ✅ 극도의 단순성과 시각화를 추구할 때

🟣 Claude 동적 워크플로우 사용 시:

• ✅ 작업이 복잡하고 멀티 Agent 격리가 필요할 때
• ✅ Claude 플랫폼만 사용할 때
• ✅ 작업 간 지식 축적이 필요하지 않을 때
• ✅ 높은 토큰 소비를 감수할 수 있을 때

🟢 Cockpit 아키텍처 사용 시:

• ✅ 크로스 플랫폼 Agent 하이브리드 오케스트레이션이 필요할 때
• ✅ 작업 간 지식 재사용이 필요할 때
• ✅ 고정된 역할 풀과 역할 기반 지능형 할당이 필요할 때
• ✅ 비용 관리 및 추적 가능성에 대한 요구사항이 있을 때
• ✅ 시스템 구축에 엔지니어링 리소스를 투자할 의향이 있을 때

결론

본 문서에서 제안하는 Cockpit 아키텍처는 동적 워크플로우의 이론적 기반 위에 공유 워크스페이스와 역할 기반 오케스트레이션 메커니즘을 도입하여 엔지니어링적 돌파구를 마련했습니다:

✅ 동적 워크플로우의 핵심 장점 유지

• 멀티 Agent 인스턴스 격리로 Agent의 나태함과 목표 이탈 해결
• 적대적 검증으로 자기 선호 편향 해결
• 특정 작업에 최적화된 동적 오케스트레이션

🚀 기존 솔루션의 한계 극복

• 크로스 플랫폼 Agent 풀로 각 플랫폼의 강점 활용
• 역할 기반 지능형 할당으로 작업과 역량 매칭 보장
• 공유 워크스페이스로 상태 일관성 및 지식 재사용 달성
• 고정 역할 풀로 비용 관리 가능성 및 엔지니어링 안정성 확보

실제 검증

HippoTeam 프로젝트의 실제 운영 데이터(408개 작업, 8개 고정 Worker, 71개 연구 기록, 78개 보고서)는 Cockpit 아키텍처가 복잡한 작업 협업에서 다음을 입증함을 보여줍니다:

• ✅ 더 나은 엔지니어링 관리 용이성
• ✅ 더 높은 협업 효율성
• ✅ 완벽한 추적 가능성

향후 전망

LLM 성능이 지속적으로 향상되고 Agent 애플리케이션이 심화됨에 따라, 우리는 다음과 같이 믿습니다:

공유 워크스페이스 모드는 복잡한 Agent 협업 시스템의 표준 패러다임이 될 것입니다.

참고 자료

1. Anthropic. (2026). "Claude Code의 동적 워크플로우: 6가지 패턴과 14단계"
2. "Claude Code에서 동적 워크플로우를 마스터하는 방법: Anthropic 엔지니어가 실제로 사용하는 6가지 패턴과 14단계"
3. AutoGPT 프로젝트. "자율 AI Agent 프레임워크"
4. LangChain 문서. "Agent 및 체인 오케스트레이션"
5. CrewAI. "역할 기반 Agent 협업 프레임워크"

저자: Huangserva 날짜: 2026년 6월 키워드: 동적 워크플로우 · Agent 오케스트레이션 · 공유 워크스페이스 · 적응형 시스템 · 크로스 플랫폼 협업

💡

이 글이 도움이 되셨다면, AI Agent 아키텍처에 관심 있는 더 많은 친구들과 공유해 주세요!