에이전트 12명 뽑아놓고도 직원은 야근시키는 회사들

회사에 인재를 12명이나 뽑아놓고 서로 인사도 못 하게 각방을 쓰게 한다면, 그건 채용의 문제가 아니라 조직 설계의 문제겠죠. 그런데 지금 기업들의 AI 도입 현황이 딱 그 모습이라는 조사가 나왔어요.

숫자가 말해주는 것: 도입은 했는데 팀이 아니다

Salesforce의 2026 커넥티비티 벤치마크를 인용한 최근 조사에 따르면, 기업들은 평균 12개의 AI 에이전트를 운영하고 있고 2027년에는 20개까지 늘어날 전망이래요. 정작 그중 절반은 다른 에이전트와 전혀 연결되지 않은 채 혼자 일하고 있고요. 더 뼈아픈 숫자도 있어요. 도입하겠다던 에이전트 활용 사례 가운데 실제 프로덕션까지 간 건 11%뿐이었다는 것. 다들 에이전트를 만들긴 하는데 만든 것들이 팀으로 굴러가는 단계까지는 대부분 못 갔다는 얘기죠.

왜 이렇게 될까요? 생각해 보면 자연스러운 결과예요. 마케팅팀은 마케팅팀대로, CS팀은 CS팀대로 각자 급한 불부터 끄느라 에이전트를 하나씩 만들었을 거예요. 그 에이전트들은 서로 다른 도구 위에서 서로 다른 방식으로 태어났을 테니까요. 문제는 진짜 업무가 팀 하나 안에서 끝나는 경우가 드물다는 데 있어요. 고객 불만 하나만 봐도 CS가 받아서 개발팀이 확인하고 마케팅이 후속 안내를 하는 릴레이잖아요. 에이전트가 각방을 쓰는 한, 이 릴레이의 바통 터치는 결국 전부 사람 몫으로 남습니다.

오케스트레이션이 올해의 단어가 된 이유

그래서 요즘 업계에서 부쩍 자주 들리는 단어가 오케스트레이션, 그러니까 '지휘'예요. 작년이 "에이전트 하나 만들어봤어요"의 해였다면, 올해의 진짜 격차는 만든 에이전트들에게 같은 악보를 쥐여주고 한 곡을 연주하게 만드느냐에서 벌어지고 있거든요. 각 에이전트를 코드로 일일이 이어 붙이는 방법도 있긴 해요. 그런데 에이전트가 늘어날 때마다 연결 지점이 기하급수적으로 늘어나는 구조라 유지보수를 생각하면 답이 아니에요. 필요한 건 에이전트들이 올라서는 공용 무대입니다. 흐름 전체를 한눈에 보며 설계하고 지휘할 수 있는 레이어죠.

Dify 워크플로우로 에이전트 팀 만들기

Dify의 워크플로우가 바로 이 지휘대 역할로 설계돼 있어요. 하나의 캔버스 위에 역할이 다른 에이전트 노드를 여러 개 올리고 분기 로직으로 일을 나눠주는 구조예요. 그래서 에이전트 협업을 코드가 아니라 눈에 보이는 흐름으로 설계할 수 있거든요.

감이 잘 안 온다면 Dify 팀이 직접 만든 고객 피드백 라우터 사례를 보면 좋아요. 구조는 이렇습니다. 피드백이 들어오면 유형을 분류해요. 버그 제보인지 기능 요청인지 일반 문의인지에 따라 각각 전문화된 에이전트 세 개 중 하나에게 넘기고요. 배정받은 에이전트는 MCP로 연결된 Linear의 도구들을 써서 담당 팀 프로젝트에 태스크를 직접 생성하고요. 흥미로운 건 구현 방식이 두 갈래였다는 점이에요. 하나는 AI가 상황을 보고 어떤 도구를 쓸지 스스로 정하게 하는 에이전트 방식이고, 또 하나는 라우팅 규칙을 사람이 명시적으로 정의하는 워크플로우 방식이었는데, 통제 수준에 따라 이 둘을 골라 쓸 수 있었대요. 그리고 이렇게 완성된 흐름 전체를 다시 MCP 서버로 내보내서 피드백이 발생하는 다른 시스템이 이 라우터를 부품처럼 호출하게 만들었습니다. 에이전트 팀 하나가 또 다른 시스템의 팀원이 되는 구조인 거죠.

이 사례를 우리 회사에 대입해 보면 출발점이 보여요. 지금 사내에 흩어져 있는 에이전트들의 목록을 만들고 그중 실제 업무에서 릴레이로 이어지는 것들을 찾아 하나의 워크플로우 캔버스 위에 올려보는 것. 에이전트를 하나 더 만드는 건 이제 누구나 합니다. 문제는 열두 번째 에이전트가 첫 번째 에이전트와 같은 악보를 보고 있느냐예요. 올해 하반기 팀 로드맵에서 먼저 점검해 볼 대목은 아마 여기일 거예요.