기업은 AI를 늘 비즈니스 프로세스의 특수한 구성 요소로 보아 왔지, 항상 곁에 있는 조수 같은 존재로 여기지 않았다. 기업이 말하는 ‘에이전트’ AI 모델은 바로 이런 개념이다. 사람과 직접 상호작용할 수도 있고 워크플로우 상의 소프트웨어와 상호작용할 수도 있으며, 심지어 다른 에이전트와도 연결될 수 있다. 하지만 거의 항상 기업의 데이터와 연결된다. 일반 사용자가 주로 활용하는 온라인 채팅형 AI와는 다르며, 이런 차이가 기업, 네트워크 트래픽, 예산에 미치는 영향은 매우 크다.

AI 에이전트는 여러 면에서 연쇄 구조라고 할 수 있다.

첫 번째 차이는 온라인 생성형 AI나 기업 훈련 챗봇과 달리 에이전트는 사전 학습된 기초 모델을 기반으로 하는 경우가 많다는 점이다. 따라서 모델을 구축하는 과정에서만 데이터가 몰리는 것이 아니라, 지속적으로 데이터를 요구한다. 에이전트는 생성형 AI 서비스보다는 소프트웨어 구성 요소와 더 비슷할 수 있지만, 데이터 접근 방식은 일반 소프트웨어와 다르다. 그래서 트래픽 영향, 비용, 거버넌스와 보안을 평가하는 소프트웨어 중심 절차에는 추가적인 주의가 필요하다.

프로그래머가 소프트웨어처럼 AI 모델에 읽기/쓰기 명령을 직접 구현하지는 않는다. 실제로 에이전트에는 그런 명령 자체가 없다. 대신 모델 컨텍스트 프로토콜(MCP)이 기업 데이터와 모델을 연결하는 역할을 한다. 이 연결은 MCP 서버와 그 위에서 실행되는 ‘도구’들을 통해 간접적으로 이뤄진다. 모델이 서버에서 동작하는 도구를 호출하면 도구가 데이터를 접근한다. 서버나 도구 구성을 바꾸면 “무엇을, 어디서, 얼마나” 접근할 수 있는지가 달라질 수 있으며, 이것이 에이전트의 두 번째 연쇄적 특성이다.

기업은 MCP 도구가 교묘한 성격을 가지고 있다고 말한다. 데이터베이스 접근, 이벤트 접근, 업데이트와 실행 같은 기능의 프록시 역할을 하기 때문이다. 직원이 에이전트에 접근하면, 에이전트가 MCP 서버와 도구를 통해 할 수 있는 모든 권한과 기능이 그대로 부여된다. 사용자는 자신이 그런 작업을 하고 있다는 사실조차 깨닫지 못한다. 모델이 도구와 데이터를 활용하는 방식은 사실상 블랙박스 안에 존재하기 때문이다.

이처럼 데이터와 연결된 연쇄 구조는 에이전트 사용 시 데이터 트래픽에 미치는 영향을 평가하기 어렵게 만든다. 게다가 대부분의 경우 단일 도구나 단일 MCP 서버만 사용하는 일은 거의 없다. 따라서 AI 에이전트 데이터 정책은 먼저 어떤 서버를 모델이 사용할 수 있는지, 이어 서버가 어떤 도구를 제공하는지, 마지막으로 도구가 어떤 데이터에 접근할 수 있는지 순서로 정해야 한다. 그래야 특정 에이전트가 제한된 데이터에 실수로 접근하는 상황을 막고, 권한이 없는 사람에게 잘못된 접근 권한이 주어지는 것도 방지할 수 있다.

이 연쇄적 비유는 매우 중요하다. 현실적인 AI 에이전트 활용은 핵심 데이터베이스 접근을 반드시 포함한다. 기업의 중요한 데이터를 사용하지 않는 AI 비즈니스 케이스란 사실상 존재할 수 없기 때문이다. 이들 애플리케이션을 구성하는 네 가지 핵심 요소, 즉 에이전트, MCP 서버, 도구, 데이터는 서로 연결되어 있으며, 네트워크 트래픽이 이들을 이어주는 연결고리 역할을 한다.

그렇다면 얼마나 많은 트래픽이 발생할까? 기업은 또 하나의 놀라운 사실을 발견했다. 초기에는 AI 호스팅을 ‘AI 클러스터’로 보고, 주요 데이터센터 네트워크와는 느슨한 데이터 링크로 연결된 형태로 상상했다. 하지만 에이전트를 도입하면서 작은 AI 서버가 주요 데이터센터 내부에 직접 설치되고, 모델 내부와 입출력을 포함한 모든 트래픽이 데이터센터 네트워크를 타고 흐르게 됐다.

AI 네트워킹이 지대한 영향을 미칠 것이라는 솔루션 업체들의 주장이 옳았던 셈이다. 에이전트를 통해 쿼리를 실행하거나 작업을 수행하면, 수천 개에서 수백만 개의 레코드를 가진 전체 데이터베이스를 탐색할 수도 있다. 에이전트 애플리케이션이 데이터 사용에 어떤 의미를 가지는지 잘 모르는 사람이 요청을 실행하면, 평소 일주일간의 정상적 트래픽과 맞먹는 양이 한 번에 발생할 수 있다. 기업은 이 정도면 네트워크 용량과 다른 애플리케이션의 서비스 품질에 영향을 줄 수 있다고 말한다. 게다가 이 트래픽이 클라우드를 오가면, 비용이 폭증할 수도 있다. 실제로 약 1/3의 기업이 에이전트로 인해 네트워크 혼잡이나 클라우드 비용 급증이 발생해 재무 검토에 들어간 적이 있다고 밝혔다.

AI 에이전트의 MCP 도구 사용은 보안과 거버넌스 측면에서도 큰 골칫거리다. MCP 표준이 항상 강력한 인증을 요구하지 않았으며, 도구가 실제로 데이터를 수정할 수 있기 때문에 구조가 잘못됐거나 해킹된 도구가 데이터를 오염시키거나 조작하거나 삭제할 위험이 있다고 지적한다. 이를 피하려면 에이전트가 데이터를 수정하거나 현실에서 행동을 실행하는 도구에 접근하지 못하도록 해야 하며, 반드시 에이전트와 도구 설계 단계에서 철저한 관리가 이뤄져야 한다.

이 문제뿐만 아니라 모든 문제를 통제하는 열쇠는 역시 검토와 설계다. 트래픽 문제는 에이전트 모델을 신중하게 배치하면 완화할 수 있다. 에이전트는 온라인 생성형 AI에 사용되는 LLM보다 요구사항이 적기 때문에, 에이전트 호스트를 분산 배치하거나 기존 서버와 같은 랙에 배치할 수도 있다. 여기에는 에이전트가 사용할 데이터베이스를 제어하는 서버도 포함된다. 다수의 기업은 데이터센터 네트워크의 토폴로지와 용량을 검토해 에이전트가 발생시키는 추가 트래픽을 감당할 수 있도록 해야 한다고 말했다. 다만 어떤 기업도 인피니밴드가 필요하다고 보지 않았고, 이더넷으로 충분하다고 판단했다. 이는 데이터센터 네트워크 아키텍트와 관련 솔루션 업체에 긍정적 소식이다.

기업은 처음에는 AI 호스팅을 ‘AI 클러스터’ 개념으로, 주요 데이터센터 네트워크와 느슨하게 연결된 구조라고 여겼다. 그러나 에이전트를 도입한 후에는 작은 AI 서버가 실제 데이터센터 내부에 설치됐고, 모델 내부와 입출력을 포함한 모든 트래픽이 데이터센터 네트워크를 통해 흐르게 됐다. 결국 AI 네트워킹이 기업에 큰 영향을 미칠 것이라는 솔루션 업체들의 말이 사실로 드러났다.

기업이 말하는 다음 단계는 MCP 도구를 강력한 인증을 요구하는 방식으로 설계하고, 트래픽과 비용을 폭증시킬 수 있는 ‘제어 불가능한 프롬프트(runaway prompt)’를 방어하는 것이다. 가장 좋은 방법은 비전문가가 쓰는 에이전트에 대형 데이터베이스를 노출하지 않는 것이다. 이를 방지하는 좋은 방법은 아예 MCP 도구를 제공하지 않는 것이다. 다만 특정 직무에서는 접근이 필요하고, 그 비용과 위험성을 정당화할 수 있다. 따라서 직무별로 접근 수준과 사용할 데이터베이스 유형을 반영한 MCP 서버를 운영해야 한다.

일부 기업은 채팅 에이전트, 즉 대화형으로 동작하는 AI 에이전트를 피하는 것이 좋은 전략이라고 제안했다. 이들 기업은 에이전트 앞단에 GUI를 구축해 허용되지 않은 기능은 아예 노출하지 않고, 로그인 정보에 따라 정책을 적용해 선택지를 통제하도록 했다.

기업들은 단순히 직원 교육만으로는 트래픽과 비용을 통제할 수 없다는 데도 공감했다. 그러나 더 강력한 통제를 적용하는 것은 문제가 아니며, 일정 수준의 트래픽과 클라우드 비용 증가는 정당화될 수 없다고 강조했다. 기업의 AI에 대한 관점은 과거와 현재가 동일하다. AI의 가치는 결국 기업의 자체 정보, 그것이 과거 데이터이든 실시간 데이터이든, 데이터를 분석할 때 비로소 실현된다는 것이다. 기업은 에이전틱 AI의 리스크를 충분히 인지하면서도, AI의 이점을 얻기 위해 이를 수용하고 있다.

남은 질문은 솔루션 업체들이 이런 문제를 인정하고 해법을 약속하느냐이다. 기업들은 솔루션 업체가 문제 해결에 진심이라고 생각하지 않는다.

한 대기업은 “AI 솔루션을 팔려는 업체는 많지만, 실제 비즈니스 문제를 해결해 주는 AI 솔루션을 제공하려는 업체는 많지 않다”라고 말했다. 기업은 에이전트를 통해 AI를 적용하고 있지만, 약간의 지원만 있다면 훨씬 더 빠르고 효율적으로 움직일 수 있다고 강조했다. AI 지지자들은 지원 방법을 더 고민해야 할 것이다.
dl-itworldkorea@foundryco.com