이번 주 전혀 다른 세 곳에서 같은 움직임이 보였습니다.

Flow가 ‘AI 워크 에이전트’를 선언했고, Claude Tag가 Slack 채널 안으로 들어왔고, Mistral은 Workflows를 별도 SKU로 꺼냈습니다. 모두 “에이전트 오케스트레이션”이라는 단어를 쓰지만, 방향이 정반대입니다.

에이전트 오케스트레이션 전쟁이 두 전선으로 분기하고 있습니다.

첫 번째 전선: 협업툴의 선점 선언

Claude Tag가 중요한 이유부터 짚겠습니다. “Slack에 Claude가 들어왔다”는 소식이 아닙니다. Claude Tag는 채널 권한, 에이전트 정체성, 대화 로그, 토큰 한도를 채널 단위로 분리해서 제어할 수 있게 합니다.

달리 말하면, 협업툴이 에이전트의 신원과 접근 권한을 관리하는 컨트롤 플레인이 된다는 선언입니다.

Flow의 ‘AI 워크 에이전트’도 같은 방향입니다. 팀원들이 이미 매일 쓰는 커뮤니케이션 도구 안에 에이전트를 심으면, 별도의 에이전트 플랫폼을 배울 필요가 없습니다. 오케스트레이션의 채택 장벽이 사실상 사라집니다.

이 진영의 핵심 논리는 단순합니다. 사람이 있는 곳에 에이전트를 가져간다. 에이전트를 쓰려고 사람이 움직이게 하지 않는다.

동시에 눈에 띄는 기술 신호가 하나 더 있습니다. SaaS 조작 방식이 GUI에서 CLI·API 레이어로 이동하고 있습니다. Google Workspace CLI가 대표적입니다. 에이전트가 화면을 보고 클릭하는 방식이 아니라, SaaS의 CLI와 API를 직접 호출하는 방향으로 가고 있습니다. 오케스트레이션 표면 자체가 바뀌는 겁니다.

협업툴 진영이 이기면, 앞으로 에이전트를 배포한다는 것은 곧 Slack 채널을 만들고 권한을 부여하는 일이 됩니다.

두 번째 전선: 플랫폼 표준 레이어

반대편에서는 다른 전략이 진행 중입니다.

Google이 I/O 2026에서 Managed Agents와 A2A(Agent-to-Agent) 프로토콜을 공개한 건, 에이전트 간 통신 표준을 선점하겠다는 신호입니다. 개별 협업툴 안이 아니라, 에이전트들이 서로 대화하는 방식 자체를 표준화하는 방향입니다.

AWS Bedrock Agent Core는 이미 프로덕션에서 작동하는 사례가 있습니다. Samsung TV 앱 스토어가 200개국, 1,500개 이상의 앱을 AWS Bedrock Agent Core 기반 오케스트레이션으로 운영하고 있습니다. 화려한 데모가 아니라, 실제 글로벌 프로덕션 환경입니다.

그리고 Mistral이 가장 명확한 시그널을 보냈습니다. 오케스트레이션을 별도 SKU로 꺼냈습니다. 모델 제공과 운영 레이어를 분리해서 판다는 선언입니다. 이건 오케스트레이션이 “에이전트에 딸려오는 기능”이 아니라 “독립적으로 구매하는 운영 인프라”가 된다는 뜻입니다.

최근 Salesforce가 AI 고객서비스 에이전트 플랫폼 Fin을 36억 달러에 인수한 것도 같은 맥락입니다. 멀티채널 고객 질의를 자율 해결하는 에이전트 인프라를 직접 흡수한 겁니다. 에이전트 오케스트레이션이 인수합병 대상이 되는 시대입니다.

플랫폼 레이어 진영이 이기면, 앞으로 에이전트를 배포한다는 것은 A2A 프로토콜을 따르는 실행 유닛을 등록하고 Managed 인프라에 올리는 일이 됩니다.

두 전선이 노리는 것은 같다

표면적으로는 협업툴 vs 플랫폼 표준의 싸움처럼 보입니다. 하지만 두 진영이 실제로 경쟁하는 자원은 하나입니다.

오케스트레이션 제어권.

누가 에이전트의 권한을 부여하고, 로그를 소유하고, 비용을 청구하는가의 싸움입니다.

협업툴 진영(Claude Tag, Flow)은 채널 단위 권한 제어를 통해 이 제어권을 쥐려 합니다. 플랫폼 레이어 진영(A2A, AWS, Mistral Workflows)은 에이전트 간 통신 표준과 실행 인프라를 통해 제어권을 쥐려 합니다.

이 두 전선이 수렴하지 않고 분기하는 이유가 있습니다. 근본적으로 접근 방식이 다릅니다. 협업툴은 사람의 경험(UX)에서 출발하고, 플랫폼 레이어는 운영의 안정성(Ops)에서 출발합니다.

PM이 지금 결정해야 하는 것

이 분기가 PM에게 던지는 질문은 한 가지입니다.

“우리 팀의 에이전트가 어느 표면에서 작동하게 할 것인가?”

협업툴 안에 에이전트를 심으면 사용자 채택이 빠릅니다. 팀원들이 이미 Slack이나 Teams에 있기 때문입니다. Claude Tag처럼 채널 단위로 에이전트를 배포하면, 새로운 UI를 학습할 필요가 없습니다. 하지만 협업툴이 오케스트레이션 제어권을 갖게 되면, 권한 설계와 비용 관리가 벤더에 종속됩니다.

플랫폼 표준 레이어(A2A, Bedrock)를 선택하면 통제권은 유지됩니다. 에이전트 간 통신, 권한, 상태 관리를 직접 설계할 수 있습니다. 하지만 팀원 입장에서는 “또 다른 도구”가 됩니다. 채택 속도가 느립니다.

100 Agents를 설계하면서 내린 결론은 이렇습니다.

오케스트레이션 표면은 사람을 따라가야 하고, 오케스트레이션 인프라는 운영을 따라가야 합니다.

두 전선을 경쟁 관계로 보지 말고, 역할이 다른 두 레이어로 봐야 합니다.

지금 당장 적용할 수 있는 설계 패턴 세 가지

첫째, 채널을 에이전트 정체성의 단위로 설계한다.

Claude Tag의 핵심 아이디어를 적용합니다. 각 에이전트에게 채널을 할당하고, 그 채널이 에이전트의 권한 범위, 로그 경계, 토큰 예산의 단위가 되게 합니다. 에이전트가 “어디에 속하는가”를 명확히 하면, 나중에 어느 인프라 레이어로 이동해도 설계 원칙은 유지됩니다.

둘째, SaaS 조작은 GUI가 아닌 API·CLI 레이어에서 한다.

에이전트에게 화면을 보고 클릭하게 하는 방식은 불안정합니다. 가능하다면 SaaS의 API 또는 CLI를 직접 호출하게 설계합니다. Google Workspace CLI가 보여주는 방향입니다. 오케스트레이션 표면이 GUI에서 도구 레이어로 이동하는 흐름에 먼저 올라타는 팀이 유리합니다.

셋째, 트리거는 협업툴, 실행은 인프라에서 분리한다.

Slack에서 “@에이전트 이거 처리해줘”라고 하면, 그 신호를 받는 건 협업툴입니다. 하지만 실제 실행 — 데이터 조회, 외부 API 호출, 서브에이전트 위임 — 은 별도의 실행 인프라에서 돌아가야 합니다. 이 분리가 명확할수록, 나중에 어느 플랫폼 레이어로 이동해도 에이전트를 재사용할 수 있습니다.

에이전트 오케스트레이션은 이미 시장 구조를 바꾸고 있다

오케스트레이션을 별도 SKU로 판다는 것(Mistral Workflows), 36억 달러에 에이전트 플랫폼을 인수한다는 것(Salesforce × Fin), 글로벌 1,500개 앱의 오케스트레이션 인프라로 쓴다는 것(AWS × Samsung TV). 이 세 가지 신호가 같은 주에 나왔습니다.

에이전트 오케스트레이션은 더 이상 “멋진 데모” 수준의 이야기가 아닙니다. 자본이 움직이고, 인수합병이 일어나고, 독립 제품 카테고리가 만들어지는 단계입니다.

지금 이 분기를 이해하지 못하고 에이전트를 배포하면, 1~2년 후에 두 전선 중 하나가 제어권을 가져갈 때 선택지가 없는 상태가 됩니다.

두 전선을 모두 이해하고, 각각 어떤 레이어를 담당하게 할지 명확히 하는 것 — 그게 오케스트레이션 시대 PM의 설계 과제입니다.

여러분 팀의 에이전트는 지금 어느 표면에서 작동하고 있나요? 협업툴 안인가요, 아니면 독립 인프라 레이어인가요?