혼자서도 코드를 짜고, 버그를 찾고, 리서치 보고서를 쓰는 AI 에이전트가 이제는 매우 일반적인 흐름이 되었습니다. 문제는 그 다음입니다. “에이전트 하나가 잘한다면, 여러 개를 붙이면 몇 배는 더 잘하지 않을까?”라는 자연스러운 기대에서 AI Orchestration이라는 영역이 태어났습니다.
오늘 포스트에서는 AI Orchestration이 무엇인지, 어떤 기능이 핵심인지, 어떤 도구와 상용 플랫폼이 있는지, 그리고 앞으로 전망을 조심스럽게 예측해봅니다.
1. AI Orchestration이란 무엇인가
AI Orchestration(AI 오케스트레이션)은 여러 AI 에이전트(또는 하나의 에이전트가 만들어내는 여러 서브에이전트)가 하나의 목표를 향해 협력하도록 제어·조율·자동화하는 시스템 설계 방식을 말합니다. 단일 LLM 호출이 “질문 하나에 답 하나”를 내놓는 방식이라면, 오케스트레이션은 작업을 쪼개고, 알맞은 에이전트나 모델에 분배하고, 병렬 또는 순차로 실행하고, 결과를 검증하고 합치는일련의 파이프라인을 다룹니다.
여기서 꼭 구분해야 할 개념이 하나 있습니다. 워크플로우 프레임워크(LangGraph, CrewAI처럼 미리 정해진 파이프라인 안에서 에이전트를 실행하는 방식)와, 자율 조직형 오케스트레이션(Gastown, Paperclip처럼 실행 중에 에이전트를 동적으로 생성하고 분산 관리하는 방식)은 성격이 다릅니다. 전자는 “정해진 그래프를 따라가는 자동화”에 가깝고, 후자는 “회사 조직처럼 스스로 굴러가는 자율 시스템”을 지향합니다. 두 접근 모두 AI Orchestration이라는 큰 우산 안에 있지만, 성숙도와 신뢰도는 꽤 다릅니다.
최근에는 여기서 한 걸음 더 나아간 동적 워크플로우(Dynamic Workflows) 개념도 등장했습니다. Anthropic이 Claude Code에 도입한 이 방식은, 사람이 미리 오케스트레이션 절차를 짜두는 대신 Claude가 주어진 작업에 맞춰 오케스트레이션 스크립트를 그 자리에서 직접 작성하고, 그 스크립트가 수십~수백 개의 서브에이전트를 한 세션 안에서 병렬 실행하는 방식입니다. “정적 워크플로우”가 모든 엣지 케이스에 대응해야 해서 범용적으로 짜여지는 반면, 동적 워크플로우는 사용자의 구체적인 사용 사례에 꼭 맞는 맞춤형 하네스(harness)를 즉석에서 만들어낸다는 점이 다릅니다.
정리하면, AI Orchestration은 다음 세 층위를 아우르는 개념입니다.
- 프레임워크 레벨: 에이전트 하나가 어떻게 추론하고 도구를 쓰는가 (Claude Agent SDK, OpenAI Agents SDK 등)
- 오케스트레이션 레벨: 여러 에이전트가 어떻게 조율되는가 (LangGraph, CrewAI, Dynamic Workflows 등)
- 운영/내구성 레벨: 그 실행이 장애와 재시작을 견디며 어떻게 살아남는가 (Temporal, Prefect, AWS Bedrock AgentCore 등)
2. AI Orchestration의 주요 핵심 기능
실제 오케스트레이션 시스템들을 비교해보면 대체로 아래 기능들을 공통으로 갖추려 합니다.
① 작업 분해와 라우팅(Task Decomposition & Routing) 큰 작업을 하위 작업으로 쪼개고, 작업 성격에 맞는 에이전트나 모델(Opus/Sonnet/Haiku 같은 지능 수준 포함)로 라우팅합니다. 분류기(classifier) 에이전트가 작업 유형을 판단해 서로 다른 경로로 보내는 “분류 후 실행(Classify-and-Act)” 패턴이 대표적입니다.
② 병렬 실행과 파이프라이닝(Parallel Execution & Pipelining) 여러 서브에이전트를 동시에 띄워 실행 시간을 줄이는 기능입니다. 모든 작업이 끝날 때까지 기다리는 “배리어(barrier)” 방식의 병렬 실행(parallel)과, 각 항목이 독립적으로 여러 단계를 흘러가는 파이프라인(pipeline) 방식이 함께 쓰입니다. “펼치고 종합(Fan-out-and-Synthesize)” 패턴이 이 기능을 잘 보여줍니다.
③ 메모리와 상태 관리(Memory & State Management) 세션이 끝나도 맥락이 유지되도록 하는 지속 메모리 시스템입니다. 예컨대 Claude-Flow는 프로젝트마다 SQLite 기반의 .swarm/memory.db를 두어 세션 간 학습과 컨텍스트를 이어갑니다. 상태 관리가 약하면 매번 “지금 상황이 뭐지?”부터 다시 파악해야 하는 비용이 반복적으로 발생합니다.
④ 검증과 적대적 리뷰(Verification & Adversarial Review) 에이전트는 자기 결과물을 관대하게 평가하는 경향(자기 선호 편향)이 있기 때문에, 별도의 검증·비평 에이전트를 두는 것이 사실상 필수 기능이 되었습니다. 생성한 결과를 다른 에이전트가 반증하게 하는 “적대적 검증(Adversarial Verification)” 패턴, 실행(Executor)-검증(Validator)-판정(Critic)의 3단 구조가 대표적인 구현입니다.
⑤ 훅(Hooks)과 자동화 트리거 코드 수정 전후, 명령 실행 전후 같은 특정 시점에 자동으로 후처리·전처리 작업(포매팅, 보안 검증, 요약 생성 등)을 붙이는 기능입니다. 일종의 “AI 운영 자동화(AIOps)” 역할을 합니다.
⑥ 격리(Isolation)와 권한 분리 서브에이전트를 별도의 워크트리(worktree)나 샌드박스에서 실행해 서로 간섭하지 않게 합니다. 특히 신뢰할 수 없는 외부 콘텐츠를 읽는 에이전트가 고권한 동작을 직접 수행하지 못하도록 막는 “격리(quarantine)” 패턴은 프롬프트 인젝션 방어와도 직결됩니다.
⑦ 관측 가능성(Observability) 어떤 에이전트가 무엇을 하고 있는지, 어디서 막혔는지, 토큰을 얼마나 썼는지를 실시간 또는 사후에 투명하게 볼 수 있는 능력입니다. 에이전트 수가 늘어날수록 이 기능의 중요도는 기하급수적으로 커집니다.
3. 생태계 안에서 쓸 수 있는 도구들
오케스트레이션 생태계는 크게 세 부류로 나눌 수 있습니다.
3.1 코드 우선(Code-first) 프레임워크
엔지니어가 파이썬/타입스크립트로 명시적인 그래프나 로직을 짜는 방식입니다.
- LangGraph: 에이전트 워크플로우를 상태가 있는 방향 그래프(directed graph)로 모델링합니다. 조건부 분기, 순환(cycle), 재시도, 사람 개입(human-in-the-loop) 체크포인트, 시간여행 디버깅을 지원해 규제 산업의 감사 추적 요구에도 강합니다. 월간 다운로드 수 기준으로 가장 널리 쓰이는 에이전트 오케스트레이션 프레임워크로 꼽힙니다.
- OpenAI Agents SDK: 기존 Swarm을 흡수해 OpenAI 진영의 표준 코드 우선 프레임워크로 자리잡았습니다. 에이전트 간 “핸드오프(handoff)” 개념이 특징입니다.
- Microsoft Agent Framework: AutoGen과 Semantic Kernel을 하나의 런타임으로 통합한 신규 제품입니다. AutoGen v0.4는 유지보수 모드로 전환되고 투자가 이쪽으로 옮겨가는 중입니다.
- Claude Agent SDK: Claude Code를 구동하는 것과 같은 아키텍처(훅, MCP 도구 통합, 스킬, 서브에이전트)를 그대로 SDK로 노출합니다.
- Google ADK(Agent Development Kit): 에이전트 간 상호운용을 위한 A2A(Agent-to-Agent) 프로토콜을 지원해 프레임워크 간 호환에 강점이 있습니다.
3.2 설정 우선(Config-first) 프레임워크
역할과 목표를 선언적으로 정의하고, 프로토타입을 빠르게 뽑아내는 방식입니다.
- CrewAI: 각 에이전트에 페르소나·도구·역할을 부여하는 “크루(crew)” 방식입니다. 30~60줄 정도의 코드로 동작하는 멀티에이전트를 띄울 수 있어 프로토타이핑 속도가 가장 빠르다는 평가를 받습니다. 다만 프로덕션 수준의 durability, 대규모 병렬 fan-out, 관측 가능성은 Temporal이나 LangGraph 같은 워크플로우 엔진과 함께 조합해야 하는 경우가 많습니다.
3.3 워크플로우 우선(Workflow-first) 엔진
이미 비즈니스 워크플로우를 운영하던 팀이 AI 에이전트를 얹는 방식입니다.
- Temporal / Prefect / Dagster / n8n: 배포가 죽어도 상태가 살아남는 내구성 있는 실행(durable execution), 재시도 정책, 체크포인팅을 제공합니다. 2026년 현재 프로덕션 에이전트 스택 대다수는 “프레임워크(LangGraph 등)를 워크플로우 엔진(Temporal 등) 위에서 돌리는” 조합으로 수렴하고 있다는 분석이 나옵니다.
3.4 오픈소스 자율조직형 오케스트레이터
Claude Code 위에서 동작하며 “팀”이나 “도시” 메타포로 다중 에이전트를 조직하는 도구들입니다.
- Claude-Flow: Anthropic Claude SDK를 기반으로 ‘스웜(Swarm)’과 ‘하이브 마인드(Hive-Mind)’ 개념의 다중 에이전트 시스템을 제공하는 오픈소스 오케스트레이션 플랫폼입니다. 87개의 MCP 도구와 SQLite 기반 메모리 시스템, 코드 수정 전후 자동 훅 시스템을 갖췄고,
Flow Nexus라는 클라우드 확장을 통해 AI 스웜을 클라우드에 직접 배포할 수도 있습니다. 빠른 1회성 작업에는swarm명령을, 장기 협업 프로젝트에는hive-mind명령을 쓰도록 구분되어 있습니다. - Gastown / Beads: Steve Yegge가 만든, 에이전트들을 “도시” 메타포(시장-작업장-워커)로 조직하는 시스템입니다. 연계 메모리 시스템인 Beads는 출시 5개월 만에 GitHub 스타 2만 개를 넘길 정도로 커뮤니티 반응이 뜨거웠습니다.
- Paperclip: “제로 휴먼 컴퍼니”를 표방하며 에이전트들을 회사 조직도(미션→프로젝트 목표→에이전트 목표→개별 작업)로 관리하는 오픈소스 프로젝트로, 이슈 트래커가 내장되어 있습니다.
- ClawTeam: 리더 에이전트가 워커를 동적으로 생성해 대규모 ML 실험(8개 H100에서 2,430개 이상)을 자동화하는 데 쓰이는 시스템입니다.
4. 상용 플랫폼 소개, 특장점과 단점
AWS Bedrock AgentCore
특장점: AWS 인프라(IAM, VPC, Secrets Manager)와 네이티브로 통합되어 있어 관리형 배포가 가장 마찰 없이 이뤄집니다. Strands Agents 같은 AWS 오픈소스 프레임워크와 짝지어 쓰기 좋습니다.
단점: AWS 생태계에 락인(lock-in)되는 구조이며, 다른 클라우드나 모델 프로바이더로 옮기려면 재작업이 필요합니다.
Google Vertex AI Agent Builder(+ ADK)
특장점: A2A 프로토콜 기반의 프레임워크 간 상호운용성이 강점이며, Google Cloud 워크로드와 통합이 쉽습니다.
단점: 오픈소스 프레임워크 대비 커스터마이징의 자유도가 제한적일 수 있고, 역시 클라우드 종속성이 있습니다.
Microsoft Copilot Studio + Agent Framework(Azure AI Foundry)
특장점: M365/Azure 환경에 이미 투자한 조직이라면 아이덴티티, 감사, 데이터 거버넌스를 벤더 테넌트에서 그대로 상속받을 수 있어 조달·컴플라이언스 측면에서 유리합니다. AutoGen과 Semantic Kernel을 하나의 런타임으로 합쳐 개발 경험이 통일됐습니다.
단점: 통합 초기라 생태계 문서나 커뮤니티 사례가 아직 상대적으로 얇고, Azure 바깥에서의 이식성이 떨어집니다.
Salesforce Agentforce 360 / ServiceNow AI Agents / IBM watsonx Orchestrate
특장점: 각 벤더의 기존 SaaS(CRM, ITSM, 규제 산업 워크플로우)에 에이전트가 원어민처럼 통합되어, 별도 인프라 구축 없이 업무 프로세스 안에 바로 얹을 수 있습니다.
단점: 해당 SaaS 생태계 바깥의 커스텀 로직을 구현하기는 어렵고, 오픈소스 프레임워크만큼의 세밀한 제어는 포기해야 합니다.
LangGraph Cloud / LangSmith(LangChain)
특장점: 오픈소스 LangGraph의 상태 그래프·체크포인팅·시간여행 디버깅을 그대로 관리형으로 제공하며, LangSmith를 통한 트레이싱과 평가(eval)까지 한 파이프라인에서 처리할 수 있습니다. Klarna, Uber, LinkedIn 등이 프로덕션에서 LangGraph를 쓰고 있다고 알려져 있습니다.
단점: 코드 우선 프레임워크 특성상 러닝 커브가 CrewAI보다 가파릅니다.
Claude Code Dynamic Workflows(Anthropic)
특장점: 별도의 오케스트레이션 코드를 사람이 짜지 않아도, Claude가 작업에 맞춰 즉석에서 agent(), parallel(), pipeline() 같은 함수로 하니스를 작성하고 실행합니다. 세션이 끊겨도 저장된 지점부터 재개되며, 저장한 워크플로우는 스킬로 배포·공유할 수 있습니다. Bun 런타임을 Zig에서 Rust로 75만 줄, 11일 만에 포팅한 사례처럼 대규모 마이그레이션에서 효과가 검증되고 있습니다.
단점: 일반 세션보다 토큰을 훨씬 많이 소비하며, 아직 리서치 프리뷰 단계입니다. Anthropic 스스로도 “일상적인 코딩 작업에 다섯 명의 리뷰어 패널이 필요한 것은 아니다”라며 고가치·고복잡도 작업에만 선별적으로 쓸 것을 권합니다.
요약 비교
| 구분 | 강점 | 약점 |
|---|---|---|
| 하이퍼스케일러형(AWS/GCP/Azure) | 관리형 인프라, 거버넌스·감사 상속 | 클라우드 락인 |
| SaaS 임베디드형(Salesforce/ServiceNow/IBM) | 기존 업무 프로세스에 즉시 통합 | 커스텀 로직 한계 |
| 프레임워크 클라우드형(LangGraph Cloud) | 세밀한 제어 + 관리형 운영 | 상대적으로 높은 학습 비용 |
| 벤더 네이티브형(Claude Dynamic Workflows) | 오케스트레이션 코드 작성 자체를 자동화 | 높은 토큰 비용, 프리뷰 단계 |
5. 최근 소식: 현장은 지금 무엇을 배우고 있나
“멀티에이전트가 항상 좋은 것은 아니다”는 데이터가 쌓이고 있습니다. UC Berkeley의 MAST(Multi-Agent System failure Taxonomy) 연구는 1,642개의 실행 기록을 분석해 실패의 약 41.8%를 맥락 붕괴(Context Collapse), 36.9%를 유령 위임(Ghost Delegation, 인수인계가 끊기는 현상), 21.3%를 검증 오류(Verification Error)로 분류했습니다. Google DeepMind와 MIT의 공동 연구에서도 순차적으로 풀어야 하는 작업에서는 멀티에이전트가 단일 에이전트보다 오히려 39~70% 성능이 떨어졌고, 체계 없이 에이전트를 묶으면 오류가 최대 17.2배까지 증폭된다는 결과가 나왔습니다. 다만 중앙에서 조율하는 구조로 바꾸면 이 증폭이 약 4.4배로 억제된다는 점도 함께 확인됐습니다.
“도시”나 “회사” 메타포의 실전 오케스트레이션은 아직 비용 대비 성과가 박합니다. Gastown 같은 시스템을 실제로 운영해본 사례에서는 토큰이 단일 에이전트 세션 대비 최소 10배 가까이 소비되면서도 생산성은 오히려 떨어졌고, Paperclip 같은 회사형 오케스트레이션도 인수인계 시점마다 캐시가 깨지고 상태 확인(heartbeat) 비용이 반복되면서 최소 5배 이상의 토큰을 더 쓴 것으로 보고됩니다. 반면 오류 비용이 낮고 검증이 쉬운 리서치 영역에서는 사정이 다릅니다. Anthropic의 멀티에이전트 리서치 시스템은 단일 에이전트 대비 90.2% 성능 향상을 보였고, 병렬 도구 호출로 리서치 시간을 최대 90% 단축했습니다. Spotify도 광고 미디어 플래닝에 라우터-서브에이전트 구조를 프로덕션에 적용해 기존 15~30분 걸리던 작업을 3~5초로 줄였다고 밝혔습니다. 요컨대 “도메인별로 깊게, 영역 간에는 느슨하게” 오케스트레이션하는 쪽이 지금 시점에서는 더 잘 통합니다.
Anthropic은 정적 워크플로우에서 동적 워크플로우로 넘어가고 있습니다. 2026년 5월 말 연구 프리뷰로 공개된 Claude Code의 Dynamic Workflows는, Claude Opus 4.8 수준의 모델이면 사용자의 구체적 요구에 맞는 하니스를 스스로 설계할 수 있다는 전제 위에 서 있습니다. Klarna는 대규모 코드베이스의 데드 코드 식별과 정리에, CyberAgent는 “계획에서 구현까지” 자연스럽게 이어지는 장시간 실행에 이 기능을 활용하고 있다고 밝혔습니다.
“자율 조직” 메타포 자체에 대한 회의론도 커지고 있습니다. 인간 조직 구성원에게는 지속적 기억, 평판, 내적 동기가 있어 계층 구조(디렉터→매니저→워커)가 정보 필터링과 권한 위임의 효율을 높여주지만, 이 세 가지가 없는 AI 에이전트에게는 오히려 계층을 깊게 쌓을수록 목표 변질의 기회만 늘어난다는 지적이 나옵니다. 그래서 실무에서는 총괄 에이전트 하나가 전체 목표를 끝까지 쥔 채 수평적으로 위임하는 구조, 그리고 에이전트끼리 직접 대화하기보다 이슈 트래커·Git·메시지 큐 같은 공유 환경(블랙보드 패턴)을 읽고 쓰게 하는 방식이 더 안정적이라는 공감대가 형성되고 있습니다.
자율성을 단일 축이 아니라 두 개의 축으로 나눠 보자는 제안도 나왔습니다. Addy Osmani가 제시한 프레임워크는 “에이전시(agency, 에이전트 하나를 얼마나 멀리 보낼 것인가)”와 “오케스트레이션(orchestration, 여러 에이전트를 얼마나 잘 조율할 것인가)”을 별개의 질문으로 분리합니다. 그 위에서 Assist → Supervised Action → Scoped Task Delegation → Goal-driven Autonomy → Parallel Delegation → Managed-by-Exception Orchestration이라는 6단계 사다리를 제시하며, “무엇을 검증할 수 있는가”가 자율성 수준의 진짜 상한선이라고 강조합니다. Anthropic 자체 연구에서도 사람은 여전히 계획 결정의 약 70%를 내리고, Claude가 실행의 약 80%를 담당하는 분업 구조가 관찰됐습니다 — 고자율성이 “사람을 루프 밖으로 빼는 것”이 아니라 “매 단계 개입에서 다음 방향만 결정하는 것”으로 옮겨가는 흐름이라는 뜻입니다.
6. 결론 및 전망
지금까지의 흐름을 종합하면 세 가지 결론으로 모입니다.
첫째, 에이전트 수를 늘리는 것 자체가 답은 아닙니다. 여러 실전 사례와 연구 모두 “같은 도구·정보 접근 권한이 주어졌을 때 단일 에이전트가 상당수 작업에서 멀티에이전트를 따라잡거나 능가한다”는 결론에 도달합니다. 멀티에이전트가 실제로 역전하는 지점은 ① 단일 컨텍스트 창으로 감당 안 되는 복잡한 작업, ② 병렬 실행이 꼭 필요한 작업, ③ 교차 검증이 필요한 작업, 이 셋으로 제한적입니다.
둘째, 좋은 오케스트레이터 설계는 “계층”보다 “총괄-워커” 구조와 “검증”에 있습니다. 총괄 에이전트가 목표를 끝까지 쥐고 재계획하는 구조, 서브에이전트마다 별도의 컨텍스트와 격리된 작업 공간을 주는 구조, 그리고 실행-검증-판정이 분리된 구조가 반복적으로 효과를 냅니다. 워크플로우를 설계할 때는 “몇 개의 에이전트를 쓸까”보다 “이 작업을 어떤 패턴(분류 후 실행, 펼치고 종합, 적대적 검증, 생성 후 필터링, 토너먼트, 완료까지 반복)으로 쪼갤 수 있을까”를 먼저 고민하는 편이 실전에서 유효합니다.
셋째, 위임 여부는 감이 아니라 기준으로 판단해야 합니다. 오류 비용, 검증 용이성, 암묵지 의존도, 컨텍스트 범위, 피드백 루프 길이라는 다섯 가지 축으로 작업을 채점해보면, 에이전트에게 맡길 영역과 사람이 쥐고 있어야 할 영역이 비교적 선명하게 갈립니다. 리서치, 코드 리뷰, 정형화된 마이그레이션처럼 결과를 기계적으로 검증할 수 있고 실패해도 되돌리기 쉬운 영역부터 오케스트레이션을 도입하고, 고객 커뮤니케이션이나 아키텍처 결정처럼 암묵지와 되돌리기 어려운 판단이 필요한 영역은 당분간 사람 주도로 남겨두는 점진적 확산이 현실적인 경로입니다.
전망을 짧게 요약하면, 자율주행에 비유했을 때 지금의 AI 에이전트 오케스트레이션은 L2에서 L3로 넘어가는 단계에 있습니다. “도시”나 “회사” 메타포로 곧바로 L5(완전 자율)를 구현하려는 시도들은 아직 맥락 붕괴, 위임 실패, 검증 오류라는 구조적 병목을 완전히 넘지 못했습니다. 그렇다고 발전이 멈춘 것은 아닙니다. 동적 워크플로우처럼 “오케스트레이션 코드를 작성하는 일 자체”를 에이전트에게 맡기는 시도, 도메인별로 깊게 파고드는 특화형 오케스트레이션(리서치, 광고 플래닝, 코드 마이그레이션), 그리고 검증과 관측 가능성을 표준 기능으로 내장한 상용 플랫폼들이 빠르게 성숙하고 있습니다. 앞으로 몇 년의 관건은 “얼마나 많은 에이전트를 동시에 돌리는가”가 아니라 “얼마나 신뢰할 수 있는 근거(evidence) 위에서 자율성을 확장하는가”가 될 가능성이 높습니다.
답글 남기기