핵심 요약 (TL;DR): AI 에이전트 오케스트레이션이란 하나의 목표를 위해 여러 AI 에이전트를 조율하는 것을 의미합니다. 즉, 어떤 에이전트가 어떤 작업을, 어떤 순서로, 어떤 컨텍스트를 가지고 수행하며, 그 결과물을 어떻게 하나로 취합할지 결정하는 과정입니다. 대부분의 시스템은 순차(Sequential), 라우팅(Routing), 병렬(Parallel), 오케스트레이터-워커(Orchestrator-workers), 리뷰 루프(Review loop)의 5가지 패턴으로 설명할 수 있습니다. Anthropic의 멀티 에이전트 시스템 조사에 따르면 일반 챗봇 대화 대비 약 15배의 토큰이 소모되므로, 실제로 작동하는 가장 단순한 구성부터 시작하는 것이 기본 원칙입니다. 코딩 에이전트를 도입한 팀에 있어 오케스트레이션은 사실상 업무 관리의 문제입니다. 즉, 작업 할당, 환경 격리, 인수인계(handoff), 인간 검토가 핵심입니다.
2026년의 흔한 화요일 풍경을 떠올려 보십시오. Claude Code는 코드 마이그레이션 작업을 세 개의 서브에이전트로 나누어 처리합니다. Codex는 다른 터미널에서 테스트 스위트를 실행하고 있습니다. 옆자리 동료의 Gemini 세션은 어제 올린 풀 리퀘스트를 리뷰 중입니다. 각각의 도구는 저마다 보조 에이전트를 훌륭하게 조율합니다. 하지만 도구 간의 조율은 전혀 이루어지지 않아, 두 도구가 동일한 설정 파일을 동시에 수정하고 리뷰는 이미 변경되어 버린 코드를 대상으로 진행되는 일이 벌어집니다.
바로 이러한 공백을 메우는 것이 AI 에이전트 오케스트레이션의 핵심입니다. 이 용어는 여러 에이전트를 그래프 형태로 연결하는 Python 프레임워크부터, 어떤 코딩 에이전트에게 어떤 티켓을 맡길지 결정하는 팀 단위의 의사결정까지 폭넓게 아우릅니다. 이 가이드에서는 바로 인용할 수 있는 명확한 정의, 주요 벤더들이 문서화한 5가지 패턴, 오케스트레이션에 따르는 비용, 그리고 에이전트가 코드를 작성할 때 달라지는 점들을 알기 쉽게 정리해 드립니다. 실무 적용 방법이 궁금하시다면 여러 Claude Code 에이전트를 병렬로 실행하는 방법 가이드를 참고해 보시기 바랍니다.
AI 에이전트 오케스트레이션의 정의
AI 에이전트 오케스트레이션이란 공통의 목표를 달성하기 위해 여러 AI 에이전트를 조율하는 과정입니다. 즉, 어떤 에이전트가 작업의 어느 부분을, 어떤 순서로, 어떤 컨텍스트를 받아 처리할지, 그리고 그 결과를 어떻게 통합하고 검증할지를 체계적으로 결정하는 것을 뜻합니다. IBM의 정의 역시 이와 유사합니다. "통합된 단일 시스템 내에서 여러 전문 AI 에이전트를 조율하는 프로세스"(IBM). GitHub의 정의에는 목표 지향성이 더해졌습니다. 자율 에이전트들이 "공동의 목표를 향해 함께 협력하도록" 조율하는 것(GitHub).
여기서 중요한 구분점은 바로 조율에 관한 결정을 '누가' 내리는가입니다. Anthropic의 효과적인 에이전트 구축 가이드에서는 워크플로와 에이전트를 구분합니다. 워크플로는 "LLM과 도구가 사전 정의된 코드 경로를 통해 오케스트레이션되는 시스템"인 반면, 에이전트는 "LLM이 자체 프로세스와 도구 사용을 동적으로 직접 지휘하는 시스템"입니다. OpenAI의 Agents SDK 오케스트레이션 가이드 역시 코드를 통한 오케스트레이션과 LLM을 통한 오케스트레이션으로 동일하게 구분하며, 두 방식을 혼합하여 활용할 수 있도록 지원합니다.
코드를 통한 오케스트레이션은 동작이 예측 가능하며 디버깅 비용이 저렴합니다. 반면 모델 기반 오케스트레이션은 실행 결과를 온전히 예측하기 어렵다는 대가가 따르지만, 정형화되지 않은 개방형 목표를 유연하게 다룰 수 있습니다. 따라서 대부분의 프로덕션 시스템은 전체 뼈대를 코드로 잡고, 그 내부의 세부 판단을 모델에 맡기는 절충 방식을 채택합니다.
5가지 AI 에이전트 오케스트레이션 패턴
주요 프레임워크마다 패턴을 부르는 이름은 제각각이지만, 기본 구조를 살펴보면 대동소이합니다. AutoGen과 Semantic Kernel의 후속작인 Microsoft의 Agent Framework는 5가지 오케스트레이션 방식을 제공합니다. Google의 ADK 패턴 페이지에는 7가지가 정리되어 있습니다. 이를 상호 매핑해 보면 다음과 같습니다.
| 패턴 | 작업 흐름 | 다른 명칭 | 적합한 작업 | 주의할 점 |
|---|---|---|---|---|
| 순차 (Sequential) | 에이전트 A의 출력이 B로, 이어 C로 전달됨 | 프롬프트 체이닝, 파이프라인 | 초안 작성 후 검토, 서식 지정 등 고정 단계별 작업 | 앞선 단계 하나에서 오류가 나면 이후 전 단계가 오염됨 |
| 라우팅 (Routing) | 분류기 또는 에이전트가 각 요청을 적절한 전문 에이전트로 전달 | 핸드오프, 트리아지, 코디네이터 | 서로 다른 전문 지식이 필요한 복합 요청 처리 | 라우팅 실패가 전문 에이전트 자체의 실패처럼 보일 수 있음 |
| 병렬 (Parallel) | 독립적인 작업을 동시에 실행하고 결과를 병합 | 동시성, 팬아웃/팬인, 섹셔닝, 보팅 | 자료 검색, 다각도 검토 등 광범위한 분석 작업 | 서로 충돌하는 결과물을 병합하는 과정이 까다로움 |
| 오케스트레이터-워커 (Orchestrator-workers) | 리드 에이전트가 계획 수립, 작업 위임, 결과 종합을 총괄 | 슈퍼바이저, 마젠틱(magentic), 계층형 | 사전에 단계를 세분화하기 어려운 유동적인 작업 | 토큰 비용 증가 및 리드 에이전트의 판단 실수 리스크 |
| 리뷰 루프 (Review loop) | 한 에이전트가 생성하고 다른 에이전트가 평가하기를 반복 | 평가자-최적화기(Evaluator-optimizer), 생성 및 검토 | 품질 기준이 명확하게 정해져 있는 작업 | 루프가 수렴하지 않고 무한 반복될 위험 |
흔히 사람들이 "오케스트레이션"이라고 할 때 떠올리는 구조는 주로 Anthropic이 설명하는 오케스트레이터-워커 패턴입니다. 즉, "중앙의 LLM이 작업을 동적으로 분해하고, 이를 워커 LLM들에게 위임한 뒤 그 결과를 종합하는 방식"을 말합니다. 일부 프레임워크에서는 에이전트들이 단일 대화 스레드에서 상호 토론하는 그룹 챗(Group chat)을 여섯 번째 패턴으로 추가하기도 합니다. Microsoft의 아키텍처 가이드에서는 그룹 챗 구성 시 에이전트 수를 3개 이하로 유지할 것을 권장합니다.
AI 에이전트 오케스트레이션에 따르는 비용
오케스트레이션 도입의 효과는 분명합니다. Anthropic의 멀티 에이전트 연구 시스템(리드 에이전트가 3~5개의 서브에이전트를 병렬로 띄우는 구조)은 내부 연구 평가에서 "단일 에이전트 Claude Opus 4 대비 90.2% 더 뛰어난 성능"을 보였으며, 병렬 처리를 통해 "복잡한 쿼리에 대한 연구 시간을 최대 90%까지 단축"했습니다.
하지만 동일한 글에서 그에 따른 비용 청구서도 함께 공개했습니다. 에이전트는 일반 대화형 챗봇 대비 약 4배의 토큰을 사용하며, "멀티 에이전트 시스템은 일반 챗봇보다 약 15배 더 많은 토큰을 소모"합니다. BrowseComp 벤치마크 결과에 따르면 "성능 편차의 80%는 오로지 토큰 사용량 차이만으로 설명"됩니다. 에이전트 수를 늘린다는 것은 본질적으로 읽어야 할 데이터 양이 늘어남을 뜻하므로, 광범위한 조사 작업에는 큰 도움이 되지만 범위가 좁고 단순한 작업에서는 불필요한 비용 낭비가 됩니다.
Anthropic과 Microsoft가 모두 서두에서 같은 조언을 건네는 이유가 여기에 있습니다. Anthropic은 "가능한 한 가장 단순한 솔루션을 찾고, 꼭 필요한 경우에만 복잡성을 높이라"고 권장합니다. Microsoft의 가이드 역시 "요구사항을 안정적으로 충족하는 가장 낮은 수준의 복잡성을 선택하라"고 강조합니다. 잘 작성된 단일 작업을 처리할 때는 정교하게 작성된 프롬프트를 갖춘 단일 에이전트가 5개 에이전트로 얽힌 복잡한 그래프보다 대부분 더 낫습니다.
코딩 도구에서 가장 작은 단위의 실제 오케스트레이션이 어떻게 구현되는지 살펴보겠습니다. Claude Code의 서브에이전트는 .claude/agents/ 디렉터리에 위치한 파일이며, 메인 세션이 이 에이전트에게 작업을 위임합니다.
---
name: test-writer
description: Writes missing unit tests for a module after a feature lands.
tools: Read, Edit, Bash
isolation: worktree
---
Write unit tests for the module you are given. Match the existing test style.
Run the suite and report which tests you added and whether they pass.
이것이 바로 8줄로 구현된 오케스트레이터-워커 패턴입니다. 메인 세션이 리드 역할을 맡고, 서브에이전트는 자체 컨텍스트 윈도우와 전용 워크트리(worktree)에서 작업을 수행하며, 최종 결과는 다시 리드에게 반환됩니다.
코딩 에이전트를 위한 AI 에이전트 오케스트레이션
코딩 에이전트는 리서치 에이전트와는 다른 제약 조건을 갖습니다. 작업 결과물이 공유 코드 저장소(리포지토리)에 반영되기 때문에, 두 에이전트가 각자 독립적으로는 완벽하게 올바른 코드를 작성했더라도 서로 충돌을 일으킬 수 있습니다. 현재 실험 단계이며 기본적으로 비활성화되어 있는 Claude Code의 에이전트 팀 문서에서도 이를 분명히 지적합니다. "두 팀원이 동일한 파일을 수정하면 코드 덮어쓰기가 발생합니다."
현재 주요 벤더들은 각자의 도구 내부에서 오케스트레이션을 제공하고 있습니다. Claude Code는 서브에이전트와 에이전트 팀 기능을 제공합니다. Codex는 서브에이전트 워크플로를 기본적으로 활성화하고 있습니다. GitHub은 지난 2월 Agent HQ를 발표하면서 "하나의 이슈를 Copilot, Claude, Codex 또는 세 도구 모두에 할당해 결과를 비교할 수 있는" 기능을 선보였습니다. 하지만 이들 중 어느 도구도 서로 다른 도구와 사람 간의 협업까지 조율해 주지는 못합니다. 그러나 개발 팀이 일상에서 절실히 마주하는 문제는 바로 이 영역입니다.
- 작업 할당(Assignment): 어떤 에이전트에게, 어느 컴퓨터(Computer) 환경에서 이 작업을 맡길지 결정합니다. 라우팅 전략은 어떤 코딩 에이전트에게 작업을 맡겨야 할까 포스트를 참고하시기 바랍니다.
- 환경 격리(Isolation): 작업 단위별로 독립된 작업 디렉터리를 부여하여 병렬 작업 간의 코드 오염을 원천 차단합니다.
- 인수인계(Handoff): 작업을 마친 에이전트가 다음 주자에게 전달해야 할 사항을 명문화합니다. 자세한 내용은 코딩 에이전트 인수인계 템플릿을 확인하세요.
- 사람 검토(Review): 코드가 메인 브랜치에 병합(merge)되기 전에 사람이 최종 검토 및 승인을 거칩니다. 이러한 승인 단계 설정은 Human-in-the-loop 검토 워크플로에서 다룹니다.
에이전트 기반 제품을 자체 제작 중이며 모든 실행 단계를 직접 제어해야 한다면 LangGraph, OpenAI Agents SDK, Microsoft Agent Framework, ADK 같은 오케스트레이션 프레임워크를 사용하는 것이 맞습니다. 반면 이미 Claude Code, Codex, Gemini CLI 세션 같은 코딩 에이전트를 실무에 쓰고 있고, 팀 단위에서 이들의 작업을 매끄럽게 조율하는 것이 핵심 과제라면 전문 관리 레이어를 도입해야 합니다.
AI 에이전트 오케스트레이션에서 Sharkly의 역할
Sharkly는 에이전트를 개발하기 위한 프레임워크가 아니며, Claude Code나 Codex 같은 실행 도구를 대체하는 도구도 아닙니다. Sharkly는 이러한 도구들 위에서 작동하는 관리 및 오케스트레이션 레이어입니다. 여러분이 이미 보유하고 있는 코딩 에이전트들을 하나의 유기적인 팀으로 결속시켜 줍니다.
오케스트레이터-워커 패턴은 Sharkly에서 '크루(Crew)'라는 개념으로 구현됩니다. 크루는 한 명의 리더 에이전트가 조율하는 사람과 에이전트의 재사용 가능한 협업 그룹입니다. Sharkly의 Crews 문서에서는 다음과 같은 명확한 기준을 제시합니다. "작업 범위가 작고 명확하다면 작업을 에이전트 한 명에게 직접 할당하십시오. 리더가 목표를 해석하고, 다른 에이전트 멤버들을 참여시키며, 그 결과를 다시 취합해야 할 때는 크루를 활용하십시오." 실행은 리더 우선 방식으로 진행되며, 백로그(Backlog) 상태에 남아 있는 크루 작업은 리더 에이전트를 임의로 시작시키지 않습니다.
어떤 구성을 선택하든 작업 기록 방식은 일관되게 유지됩니다. 작업(Task)에 최종 목표가 기록되고, 각 실행은 사용자의 컴퓨터 환경 중 하나에서 기본적으로 독립된 디렉터리를 통해 격리 실행되며, 실행 상태와 장애 요인(blocker), 최종 결과가 다시 작업으로 취합됩니다. 에이전트는 조사, 실행, 테스트, 보고를 담당합니다. 사람은 방향을 설정하고, 권한을 부여하며, 최종 결과를 승인합니다. 리더 에이전트가 작업을 위임하는 구체적인 방식은 에이전트 기능 소개 페이지의 Crews 섹션에서 확인하실 수 있으며, 실제 작동 예시는 Sharkly Crews 포스트에서 자세히 안내합니다.
에이전트가 이미 개별적으로 잘 작동하고 있고, 사람들과 여러 저장소에 걸쳐 이들을 효과적으로 조율하는 것이 진정한 난관이라면, 바로 그것이 Sharkly가 해결하고자 하는 핵심 문제입니다.
자주 묻는 질문 (FAQ)
AI 에이전트 오케스트레이션은 멀티 에이전트 시스템과 같은 개념인가요? 유사하지만 완전히 같지는 않습니다. 멀티 에이전트 시스템이 에이전트들의 집합 자체를 의미한다면, 오케스트레이션은 조율 로직을 가리킵니다. 즉, 누가 언제 어떤 컨텍스트를 가지고 실행되며 결과를 어떻게 병합할지를 제어하는 체계입니다. 단 하나의 에이전트가 여러 도구를 다루는 시스템이라면 복잡한 오케스트레이션이 거의 필요하지 않습니다.
AI 에이전트 오케스트레이션과 일반 AI 오케스트레이션의 차이는 무엇인가요? 일반적인 AI 오케스트레이션은 주로 여러 AI 모델, 데이터 파이프라인, 도구들을 하나의 정해진 워크플로로 엮는 작업을 의미합니다. 반면 AI 에이전트 오케스트레이션은 보다 좁고 특화된 개념으로, 주어진 작업 범위 내에서 스스로 자율적인 판단을 내리는 에이전트들을 조율하는 데 초점을 둡니다.
에이전트를 조율하려면 LangGraph 같은 프레임워크가 반드시 필요한가요? 에이전트 자체를 바닥부터 직접 개발하는 경우에만 필요합니다. Claude Code나 Codex 같은 코딩 에이전트는 이미 자체 서브에이전트를 오케스트레이션하고 있으므로, 실무에서 필요한 것은 작업 할당, 환경 격리, 사람 검토 같은 전체 실행 단위의 조율입니다. 자세한 시작 방법은 AI 에이전트에게 첫 번째 작업 할당하기 가이드를 참조하세요.
어떤 AI 에이전트 오케스트레이션 패턴부터 시작해야 할까요? 명확한 단일 작업을 처리하는 단일 에이전트로 시작한 후, 코드로 제어 가능한 순차 또는 병렬 실행으로 확장하는 것을 권장합니다. 사전에 작업 단계를 분할하기 어렵고 추가 토큰 비용을 감수할 가치가 충분할 때 오케스트레이터-워커 패턴으로 전환하십시오.
