[32호] Agent도 조직도가 필요할까요?

우리 회사에 몇 개의 Agent가 있는지 아시나요?

요즘 회사 안에서 AI Agent 하나를 만드는 것은 더 이상 큰 프로젝트가 아닙니다.

몇 명이 아이디어를 내고, 사내 데이터나 API를 연결하고, 프롬프트와 업무 흐름(Workflow)을 구성하면 며칠 만에도 꽤 그럴듯한 Agent를 만들 수 있습니다. 그러다 보니 이제 회사에 몇 개의 Agent가 있는지 아무도 정확히 모르는 상황이 되어가고 있는 것 같습니다.

Agent가 늘어날수록 기존 조직의 업무 경계도 함께 흐려지고 있습니다.

예전에는 직무마다 사용하는 도구와 전문성이 달랐기 때문에 업무의 경계가 비교적 명확했습니다. PM이 문제를 정의하고, 데이터 분석가가 데이터를 분석하고, 개발자가 구현하고, AI팀이 모델과 AI 시스템을 만드는 식이었습니다. 하지만 LLM과 Agent는 조금 다릅니다. 자연어로 데이터를 조회하고, 코드를 작성하고, 문서를 검색하고, 고객의 목소리(VOC)를 분석하고, 그 결과를 바탕으로 다음 행동까지 제안할 수 있습니다. 같은 문제를 여러 직군이 서로 다른 Agent를 통해 풀 수 있게 된 것입니다.

예를 들어 이런 요청이 있다고 해볼까요?

“최근 우리 서비스의 고객 이탈이 늘어나고 있는 원인을 분석해서 개선안을 만들어주세요”

예전이라면 하나의 요청 안에서도 여러 역할이 나뉘었습니다. PM이 문제를 정의하고, 데이터 분석가가 필요한 데이터를 추출해 분석합니다. 분석 결과를 함께 해석한 뒤 PM이 개선 방향을 정하고, 필요하다면 개발팀과 구현 가능성을 검토합니다.

그런데 Agent는 이 과정을 한 번에 가로지를 수 있습니다.

데이터를 찾고 → 분석하고 → 패턴을 발견하고 → 원인을 추론하고 → 과거 문서를 검색하고 → 개선안을 제안합니다.

여기에 코딩 Agent까지 연결하면 간단한 시제품(Prototype)을 만드는 데까지 갈 수 있습니다. 

그러면 조금 복잡한 상황이 만들어지는데요. 

프로덕트팀은 고객 문제를 더 빨리 발견하기 위해 고객 인사이트 Agent를 만들 수 있습니다.  데이터팀은 반복되는 분석 요청을 자동화하기 위해 데이터 분석 Agent를 만들 수 있습니다. AI팀은 여러 조직이 공통으로 사용할 수 있도록 사내 문서와 데이터를 검색하고 분석하는 리서치 Agent를 만들 수 있습니다.

각 팀이 Agent를 만든 이유는 다릅니다. 그런데 Agent의 이름을 지우고 실제로 무엇을 하는지만 펼쳐놓으면, 검색 → 분석 → 추론 → 제안처럼 일의 상당 부분이 겹칩니다. 

비슷한 기능을 가진 Agent가 여러 개 생기면, 새로운 문제들이 생깁니다.

같은 데이터를 분석하는 Agent가 서로 다른 결과를 내놓는다면 무엇을 신뢰해야 할지, 분석의 품질은 누가 책임질지, 고객 데이터에 대한 접근 권한은 어디까지 허용할지 등의 이슈들이 떠오르지요. 더 나아가 여러 팀이 검색, 분석, 추론처럼 비슷한 역량을 각자의 Agent 안에서 반복해서 만들고 있다면, 어디까지 각 팀이 개별적으로 만들고 어디부터 조직의 공통 역량으로 관리할 것인지도 결정해야 합니다.

결국 Agent가 많아질수록 중요한 것은 개별 Agent를 잘 만드는 것만이 아닙니다.

조직 전체에 어떤 Agent와 역량이 존재하는지 파악하고, 겹치는 것은 재사용하고, 각 Agent의 책임과 권한을 명확하게 만드는 일이 함께 필요해집니다. Agent를 만드는 문제에서, Agent들을 어떻게 운영할 것인가의 문제로 넘어가는 것입니다.

Agent를 관리하는 시스템을 만들기 시작했다

에이전트 스프롤(Agent Sprawl)이라는 말을 들어보셨나요?

조직 곳곳에서 Agent가 빠르게 만들어지면서 어떤 Agent가 존재하는지, 누가 운영하는지, 무엇을 하는지, 어떤 데이터와 Tool에 접근하는지 파악하기 어려워지는 현상을 말합니다. 

최근 몇 달 동안 이러한 문제를 겪은 글로벌 기업들의 움직임을 보면 흥미로운 공통점이 있습니다. Agent를 더 많이 만드는 것에서 한발 더 나아가 “조직에 존재하는 Agent들을 어떻게 관리할 것인가?”라는 문제를 고민하기 시작했다는 것입니다.

Microsoft는 2026년 8월 자사 IT 조직인 Microsoft Digital에서 50만 개가 넘는 Agent를 파악하고 관리하고 있다고 공개했습니다.

Microsoft가 택한 방법은 모든 Agent를 하나의 조직에서 만들어 배포하는 것이 아닙니다. 각 팀은 자신의 업무에 필요한 Agent를 계속 만들 수 있습니다. 대신 회사 안에 어떤 Agent가 있는지를 한곳에서 확인할 수 있도록 했습니다.

이를 위해 Microsoft는 Agent 365를 활용합니다. 여기에서 각 Agent가 무슨 일을 하는지, 누가 만들고 관리하는지, 얼마나 사용되고 있는지, 어떤 데이터와 시스템에 접근할 수 있는지 등을 확인하고 관리합니다.

쉽게 말하면 Agent를 위한 사내 구성원 명부를 만든 것과 비슷합니다.

회사에 구성원이 많아지면 이름만 아는 것으로는 충분하지 않습니다. 어느 조직에 속해 있는지, 어떤 역할을 맡고 있는지, 어떤 시스템에 접근할 수 있는지를 함께 관리합니다. Agent도 마찬가지입니다. 

그래서 Microsoft는 Agent를 만드는 것은 각 조직에 맡기되, 어떤 Agent가 존재하고 누가 책임지며 어떤 권한을 가지고 있는지는 조직 전체에서 파악할 수 있도록 하는 방식을 택했습니다. 

사람이 많아지면 조직도가 필요하듯, Agent가 많아지면 어떤 Agent가 어디에서 무엇을 하고 있는지 보여주는 지도가 필요해지는 것입니다.

AWS도 비슷한 문제에 주목했습니다.

AWS는 여러 조직이 각자 Agent를 만들기 시작하면 비슷한 기능을 중복해서 개발하거나, 여러 Agent가 같은 시스템에 접근하면서 충돌하거나, 관리해야 할 권한과 비용이 계속 늘어날 수 있다고 설명했습니다.

AWS가 주목한 것은 “Agent가 많다”는 사실보다 서로 무엇을 만들고 있는지 모른 채 각자 만들고 있다는 점이었습니다. 그래서 AWS는 26년 8월 Agent Registry를 정식 출시했습니다. 쉽게 말하면 회사에서 사용할 수 있는 Agent와 그 기능을 모아놓은 검색 가능한 목록입니다.

AWS는 여기서 한 단계 더 나아가 이런 접근을 ‘조직 차원의 Agent 포트폴리오 관리(Organizational Agent Portfolio Management)’라는 개념으로 설명합니다.

개별 Agent 하나하나만 잘 만드는 것이 아니라, 조직 전체에 어떤 Agent와 기능이 있는지 보고, 중복되는 것은 합치거나 재사용하고, 필요한 것은 새로 만들고, 쓰이지 않는 것은 정리하는 것입니다.

Agent를 하나의 제품으로 보는 것이 아니라, 회사가 보유한 Agent 전체를 하나의 포트폴리오로 바라보기 시작한 것입니다.

새로운 Agent를 만들기 전에는 비슷한 Agent나 기능이 이미 있는지 먼저 확인하고, 운영 중인 Agent는 사용량, 비용 대비 가치, 중복 여부 등을 살펴봅니다. 이를 바탕으로 새로 만들지, 재사용할지, 더 투자할지, 비슷한 Agent를 합칠지, 더 이상 필요하지 않은 Agent를 종료할지를 결정합니다. Agent끼리 연결되어 있다면 의존 관계도 함께 봅니다. 하나의 Agent를 변경하거나 종료했을 때 다른 Agent와 업무에 어떤 영향을 미치는지 알아야 하기 때문입니다.

즉, Agent 포트폴리오 관리란 “우리 회사에 어떤 Agent가 있는가?”를 파악하는 데서 나아가, “이 Agent들을 앞으로 어떻게 가져갈 것인가?”를 조직 차원에서 결정하는 것입니다.

다음은 ‘연결된 AI 인텔리전스(Connected AI Intelligence)’

포트폴리오의 목적은 Agent 목록을 예쁘게 정리하는 데 있지 않습니다.

궁극적으로는 각자 만들어진 Agent가 고립되어 일하는 것이 아니라 필요한 맥락과 역량을 공유하면서 하나의 연결된 지능처럼 작동하도록 만드는 것입니다.

예를 들어 고객 VOC Agent가 최근 “배달 예상 시간이 정확하지 않다”는 불만이 증가했다는 사실을 발견했다고 해보겠습니다.

그 인사이트가 리포트 하나로 끝나는 대신 프로덕트 인사이트 Agent에게 전달됩니다. 프로덕트 인사이트 Agent는 관련 전환 흐름(Funnel)과 실험 결과를 확인합니다. 데이터 Agent는 문제가 집중되는 고객군(Segment)을 분석합니다. 실험 Agent는 과거 유사 실험과 결과를 찾습니다. 전략 Agent는 이 정보들을 종합해 가장 큰 기회(Opportunity)가 어디에 있는지 정리합니다.

여기서 중요한 것은 Agent가 다섯 개 있다는 사실이 아니며 각 Agent가 똑같은 검색과 분석 기능을 다섯 번 새로 만드는 것도 아닙니다. 공통 지식(Knowledge)과 도구, 역량을 재사용하면서 각 Agent는 자신이 가장 잘 아는 맥락에서 역할을 수행합니다.

100개의 독립적인 Agent를 갖는 것과 100개의 Agent가 연결된 하나의 지능 네트워크(Intelligence Network)를 갖는 것은 전혀 다른 이야기입니다.

그렇다면 우리는 무엇부터 해야 할까요?

거창한 시스템을 처음부터 만들 필요는 없습니다. 몇 가지 작은 작업부터 시작해볼 수 있습니다.

1. 우리 회사의 Agent를 한번 세어보세요

간단한 Agent Registry를 만들어봅니다.

정도만 정리해도 좋습니다. 놀랍게도 이 작업만 해도 조직에서 비슷한 Agent가 여러 개 존재한다는 사실을 발견할 가능성이 높습니다.  아래 예시를 참고해보세요. (Microsoft Agent 365 Registry 실제 관리 항목을 참고하셔도 좋아요)

2. Agent가 아니라 Capability를 정리합니다.

다음으로 Agent 이름을 지워봅니다. 대신 Agent가 무엇을 할 수 있는지만 적습니다.

처럼 Capability를 정리합니다. 그러면 서로 다른 이름의 Agent가 사실 같은 Capability를 반복해서 만들고 있었다는 사실이 보이기 시작합니다.

3. 운영 원칙을 만듭니다.

새로운 Agent를 만들기 전에 세 가지를 확인합니다.

Agent를 만드는 비용이 낮아질수록 이 질문은 더 중요해집니다. 개발 비용은 싸졌지만 운영 비용과 복잡성은 Agent의 숫자와 함께 증가하기 때문입니다.

4. 포트폴리오를 연결합니다.

마지막으로 Agent들이 각자 같은 데이터를 찾고 같은 역량을 반복해서 만드는 대신 공통 지식과 데이터, 도구와 기능을 재사용할 수 있도록 연결합니다.

필요하다면 한 Agent가 모든 일을 처리하려고 하지 않고, 자신보다 특정 업무를 더 잘하는 Agent에게 일을 넘길 수도 있습니다.

그렇게 되면 Agent 포트폴리오는 단순한 관리 대상에서 서로 역할을 나누고 지식을 공유하는 하나의 지능 네트워크로 발전할 수 있습니다.

📮 다음 호 예고

[33호] AI 냄새 나는 글은 왜 3초 만에 티가 날까

슬랙 메시지도, 기획서도, SNS 글도 이제 AI가 대신 써주는 시대입니다. 그런데 묘하게 읽자마자 “이거 AI가 썼네” 싶은 글들이 있습니다. 비슷한 문장 구조, 과도하게 매끈한 표현, 그럴 듯한데 나이브한 결론까지…

회사 동료에게 제대로 검토하지 않은 AI 결과물을 바로 넘기는 일을 ‘Slope grenade(쓰레기 폭탄)‘이라고 부르는 현상도 생겨났어요. 다음 호에서는 우리가 AI 글을 알아차리는 이유와 함께 내 글처럼 보이게 만드는 방법을 함께 살펴볼게요.

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.