AI Agent의 확장성은 모델보다 ‘도구 연결 구조’에서 결정된다.
HS, HwangAX / DXAgent이매진팩토리황현식
AI Agent를 개발할 때
우리는 흔히 어떤 LLM을 사용할지,
얼마나 복잡한 추론이 가능한지,
어떤 프레임워크를 선택할지에 집중합니다.
그러나 AI Agent가 실제 기업 환경으로 확장되기 시작하면 전혀 다른 문제가 등장합니다.
기업 내부에 이미 존재하는 수백 개의 API를 AI Agent와 어떻게 연결할 것인가?
Agent가 필요한 도구를 어떻게 찾아낼 것인가?
그리고 각 Agent가 실행할 수 있는 작업의 범위는 어떻게 통제할 것인가?
AI Agent의 확장성은 모델의 추론 능력뿐 아니라, 기업의 시스템을 AI가 활용할 수 있도록 연결하고 통제하는 아키텍처에 달려 있습니다.
최근 공개된 MoEngage의 사례는 이 문제를 구체적으로 보여줍니다.
MoEngage는 7개 AWS 리전에 분산된 약 400개의 내부 REST API를 10개의 AI Agent가 활용할 수 있도록 구성했습니다.
여기서 주목할 점은 각각의 API를 위한 MCP 서버를 별도로 개발하지 않았다는 것입니다.
대신 기존 OpenAPI 명세를 활용해 API를 Agent가 사용할 수 있는 도구로 변환하고,
중앙화된 MCP 계층에서 도구의 발견과 실행을 관리하도록 설계했습니다.
기술적으로 흥미로운 부분은 크게 세 가지입니다.
첫째, API의 도구화를 표준화했습니다.
기존 API 명세를 기반으로 도구를 생성하되, 개발자를 위한 API 설명과 LLM이 도구를 선택할 때 참고하는 설명을 분리했습니다.
이를 통해 개별 개발팀이 MCP를 직접 구현하지 않더라도, 기존 API를 Agent가 활용할 수 있는 형태로 제공할 수 있습니다.
둘째, 도구를 나열하는 방식에서 검색하는 방식으로 전환했습니다.
수백 개의 도구 정의를 모두 LLM의 컨텍스트에 포함하면 불필요한 토큰 비용이 발생하고, 모델이 적절한 도구를 선택하기도 어려워집니다.
MoEngage는 Agent가 수행하려는 작업을 자연어로 설명하면 의미 기반 검색을 통해 관련 도구를 찾아 제공하도록 구성했습니다.
즉, Agent가 모든 도구를 미리 알고 있어야 하는 구조에서, 필요한 순간에 필요한 도구를 발견하는 구조로 전환한 것입니다.
셋째, 도구 선택과 실행 권한을 분리했습니다.
LLM이 특정 도구를 선택했다고 해서 해당 작업을 실행할 권한까지 갖는 것은 아닙니다.
MoEngage는 서버 측 정책을 통해 Agent별 도구 접근 범위를 제한하고, 사용자 및 테넌트의 인증 정보를 LLM이 수정할 수 있는 도구 인자에서 분리했습니다. 내부 API 역시 외부 인터넷에 공개하지 않았습니다.
이러한 구조는 AI Agent의 판단 능력과 실제 시스템의 실행 권한을 구분한다는 점에서 중요합니다.
이 사례에서 사용된 개별 기술이 모두 새로운 것은 아닙니다.
OpenAPI, MCP, 정책 기반 접근 통제, 의미 기반 검색은 이미 알려진 기술입니다.
주목할 변화는 이러한 기술을 조합해, 기업의 기존 시스템을 AI Agent가 활용할 수 있는 공통 실행 환경으로 구성했다는 점입니다.
물론 중앙화된 연결 계층이 새로운 병목이나 장애 지점이 될 수 있고,
의미 기반 도구 검색의 정확도와 정책 관리 복잡도도 검증해야 합니다.
그럼에도 이 사례는 기업 AX에서 중요한 시사점을 제공합니다.
지금까지 AI Agent 개발의 주요 관심사가 'AI가 어떤 일을 할 수 있는가'였다면,
이제는 '기업이 보유한 기능들을 AI가 얼마나 안전하고 유연하게 활용할 수 있는가'라는 질문도 중요해지고 있습니다.
AI Agent를 하나 만드는 것과,
수십 개의 Agent가 수백 개의 기업 시스템을 안정적으로 활용할 수 있는 환경을 만드는 것은 전혀 다른 엔지니어링 문제입니다.
그리고 기업 AX의 확장성을 결정하는 것은 때로 더 강력한 모델이 아니라,
그 모델이 기업의 시스템과 상호작용하도록 설계된 구조일 수 있습니다.
댓글 0
첫 댓글을 남겨주세요.