Atlas 에이전트 엔진이 MongoDB의 내부 AI 전략을 지원하는 방법

저는 25년 넘게 기술 업계에 몸담아 온 만큼 새로운 기술에 놀랄 일이 거의 없습니다. 대개 일반에 공개되기 전에 가까이에서 먼저 접하기 때문입니다. IT 리더로서 저는 새로운 기능을 그 자체만 놓고 평가하지 않습니다. 언제나 기업의 실제 활용 사례와 그에 따르는 위험을 함께 따져 봅니다. 요즘 저는 AI 시대의 CIO는 두 가지 역할을 동시에 맡아야 하는 자리라고 말합니다. 댐을 보강하는 엔지니어이면서 결국은 수문을 열어야 하는 운영자이기도 하다는 뜻입니다.

이번 주 MongoDB는 Atlas Agent Engine의 퍼블릭 프리뷰를 발표했고 이 제품이 고객에게 제공할 혁신적인 가치를 생각하면 매우 기대가 큽니다. Atlas Agent Engine은 프로덕션 환경에서 AI 에이전트를 안전하게 구축하고 배포하며 거버넌스를 적용할 수 있는 방법을 제공합니다. Atlas Agent Engine은 메모리와 검색 기능을 내장하고 있어 기업 데이터가 있는 그 자리에서 바로 인덱싱하고 정확한 컨텍스트를 실시간으로 제공합니다. 그 결과 정확도는 높이고 토큰 비용은 줄일 수 있습니다. 또한 아키텍처 자체가 개방적이고 유연하게 설계되어 있어 팀은 선호하는 LLM 및 프레임워크를 자유롭게 선택해 시스템을 구축할 수 있으며, 조만간 원하는 어떤 환경에서도 제약 없이 운영할 수 있게 될 것입니다.

고객들도 Atlas Agent Engine이 자사 비즈니스에 가져다줄 가능성에 이미 큰 기대를 보이고 있습니다. 예를 들어, Paysafe는 MongoDB Atlas를 기반으로 트랜잭션 데이터에 대해 자연어를 SQL 쿼리로 변환하는 에이전틱 시스템을 운영하고 있습니다. 이 시스템은 Paysafe가 향후 활용 사례의 템플릿으로 삼기 위해 구축할 계획인 재사용 가능한 워크플로 파이프라인 시리즈의 첫 번째 사례입니다.

현재 이 회사의 Snowflake MCP 구성 환경에서는 API 클라이언트가 기반 데이터 스키마를 제한적으로만 파악할 수 있습니다. MongoDB Atlas의 유연한 문서 아키텍처와 안정적인 확장성은 이러한 구성을 더 강력하고 재사용 가능한 파이프라인으로 대체하도록 설계된 에이전트를 뒷받침합니다. API 클라이언트는 이 파이프라인에 자연어로 직접 질의할 수 있습니다.

Paysafe의 결제 엔지니어링 부문 SVP인 자나 자나르타난은 다음과 같이 말했습니다. “현재 당사의 결제 네트워크에서 이상 징후를 조사하려면 분석가들이 여러 시스템의 데이터를 일일이 수작업으로 취합해야 하며 시간에 쫓기는 경우도 많습니다. MongoDB Atlas Agent Engine을 기반으로 구축한 지능형 에이전트가 문제가 나타난 시점부터 팀이 대응에 나서기까지의 시간을 줄여 줄 것으로 기대하고 있습니다. 그렇게 되면 분석가들이 가장 중요한 의사 결정에 더 많은 시간을 집중할 수 있습니다.”

MongoDB 팀이 Atlas Agent Engine을 처음 보여 주었을 때 “설계 단계부터 보안과 거버넌스를 갖췄다”는 문구가 단번에 제 관심을 끌었습니다. 제가 밤잠을 설치게 만드는 것이 하나 있다면 에이전트가 MongoDB(또는 고객)의 시스템 내에서 통제 불능 상태가 되는 상황이기 때문입니다.

에이전트 거버넌스는 저만의 고민이 아닙니다. 뉴스에서도 다뤄지고 있으며 업계 전반의 CIO들이 고심하고 있는 문제이기도 합니다. 업계 동료들과 이야기를 나눌 때마다 같은 점을 확인하게 됩니다. 기업 전반에서 에이전트에 대한 수요는 계속 늘고 있지만 IT 리더에게는 에이전트를 빠르게 배포하는 것만이 아니라 안전하고 보안이 확보된 방식으로 배포할 방법이 필요하다는 것입니다.

근본적으로 이는 중앙 집중화 대 분산화의 문제입니다. 개발자는 마찰 요인을 최소화하며 에이전트를 빠르게 배포할 수 있는 자율성을 원하고 IT 리더는 대규모로 운영되는 에이전트의 동작을 중앙에서 통제하고 가시성을 확보하며 비용을 최적화할 수 있는 제어 수단을 원합니다. 이 문제를 제대로 풀어내는 조직은 두 가지를 모두 충족하는 아키텍처를 구축하게 될 것입니다.

소프트웨어 아키텍처가 점점 헤드리스 및 에이전트 주도형으로 진화함에 따라 현재 CIO들에게는 즉각 도입 가능한 선택지가 필요합니다. 달리 말하면 미래는 이미 도래했고 우리의 일은 그 미래를 책임감 있게 만들어 가는 것입니다.

고객 제로(Customer Zero): 사내 AI 전략의 실제 활용 사례

MongoDB가 이를 실천하는 방법 중 하나는 자사 제품에 대해 스스로 '고객 제로' 역할을 하는 것입니다. 업계에서는 이 관행을 부르는 이름이 여러 가지입니다. '도그푸딩(Dogfooding)'과 '자사 샴페인 마시기(Drinking Your Own Champagne)'가 그 예이지만 의미는 모두 같습니다. MongoDB는 제품을 출시하기 전에 직접 고객이 되어 실제 사용 사례와 상황을 바탕으로 프로덕션 환경에서 소프트웨어를 테스트합니다.

예를 들어 2024년에 MongoDB 8.0이 출시되었을 때 제 동료 짐 샤프는 8.0이 팀의 생산성을 얼마나 향상시켰는지를 다룬 블로그 게시물을 작성했습니다.

Atlas Agent Engine을 활용한 MongoDB의 도그푸딩은 Holly라는 형태로 나타났습니다. Holly는 MongoDB 영업 담당자에게 필요한 모든 것을 일곱 군데가 아닌 한곳에서 해결할 수 있게 해 주는 통합 에이전틱 워크스페이스입니다. Holly 이전에는 고객사 하나를 준비하려면 서로 컨텍스트를 공유하지 않는 일곱 개의 분리된 도구를 오가야 했습니다. 딜 사이클마다 고객사당 4~6시간이 순전히 여러 도구를 오가는 데 따르는 비효율로 낭비되었습니다. Holly는 이런 상황을 해결합니다. 일곱 개의 도구가 하나의 에이전틱 경험으로 통합되고 영업 담당자는 그 시간을 되찾아 가장 중요한 곳, 바로 고객과 함께하는 데 쓸 수 있습니다.

Holly: 수많은 작업 시간을 몇 분으로 단축

MongoDB의 GTM 팀은 고객의 현재 상태와 목표, 그리고 그 목표에 도달하기 위해 필요한 것이 무엇인지를 파악하는 표준화된 단계별 방법론을 따릅니다. 영업 담당자들은 이를 '스포크'라고 부르며, 결코 짧은 시간에 끝나는 작업이 아닙니다. MongoDB의 전략 고객 계정 관리자인 잭 번켄버그는 스포크 작업이 매주 그의 일주일 중 하루나 이틀을 소요한다고 말합니다.

문제는 프로세스가 아니라 도구였습니다. 담당자에게는 활용하는 전체 데이터를 이해하는 도구와, 이전에는 서로 소통한 적이 없던 시스템 간에 기억을 전달해 주는 도구가 필요했습니다.

이러한 환경이 없다면 일곱 가지 도구에 걸쳐 고객사 하나를 담당하는 일은 하나의 질환 때문에 전문의 일곱 명을 만나면서도 그중 누구도 다른 의사가 찾아낸 내용을 볼 수 없는 상황과 비슷합니다. 진료를 받을 때마다 매번 처음부터 다시 시작해야 합니다. 증상과 병력, 그리고 앞서 만난 의사가 이미 파악한 내용까지 다시 설명해야 하기 때문입니다. 전문의 한 명 한 명은 훌륭할 수 있습니다. 하지만 컨텍스트가 전달되지 않는 탓에 시스템은 여전히 제 역할을 하지 못합니다. 오가는 것은 환자, 즉 여러분뿐입니다.

팀은 무언가를 구축하기에 앞서 실제로 업무가 어떻게 이루어지는지부터 살폈는데 현장의 실상은 번켄버그의 표현을 빌리면 문서상에 정의된 프로세스보다 '훨씬 더 혼란스럽고 복잡'했습니다. 고객사 조사 하나를 위해서만 여러 AI 도구(ChatGPT, Claude, Gemini)를 동시에 다뤄야만 했습니다. 이 도구들은 서로, 그리고 MongoDB의 시스템과도 컨텍스트를 공유하지 않아 누구에게나 천편일률적이고 원론적인 답변만 내놓았습니다. 입증 사례를 찾는 일도 모두 수작업이었습니다. 결과에서 정말 중요한 내용만 추려 내는 일도 마찬가지였습니다.

Holly는 다른 도구에는 없던 공유 컨텍스트를 제공하는 해결책입니다. 단 하나의 인터페이스에서 도구 전환 없이 영업 담당자가 리서치, 준비, 실행에 필요한 모든 요소를 하나로 통합하여 제공합니다. 그 밑바탕에는 Atlas Agent Engine이 자리하여 런타임, 보안, ID 관리, 오케스트레이션, 상태 관리, 관측성 및 라이프사이클 관리 등 가장 까다로운 백엔드 작업을 도맡아 처리합니다. 이를 통해 Holly의 에이전트는 단순 데모 수준을 넘어 실제 운영 환경에서 작동합니다.

그림 1. Holly의 에이전트 아키텍처.

실제로 Holly는 회의 녹취록을 선별해 요약하고 브리프 초안을 작성합니다. 또한 영업 담당자가 아직 답을 찾지 못한 질문을 짚어 주고, 아웃리치 문안 작성도 돕습니다. 그 결과 Holly를 사용하는 영업 담당자는 아웃바운드 잠재 고객 발굴 목록을 조사하고 구축하는 데 드는 시간을 약 95% 단축했으며 이전에는 몇 시간이 걸리던 사전 준비 과정을 이제 단 몇 분 만에 완료하고 있습니다. 이는 영업 담당자가 단순히 빠르게 움직이는 것에 그치지 않고 모든 미팅에 더욱 철저히 대비된 상태로 임할 수 있음을 의미합니다.

번켄버그는 “Holly를 도입하기 전에는 리서치와 아웃리치를 진행하기 위해 십여개가 넘는 서로 다른 도구를 사용해야 했습니다. 모든 작업을 단일 인터페이스로 통합하여 처리할 수 있게 된 점이 큰 실질적 가치를 더해주었습니다”라며 “많은 도구는 MongoDB의 비즈니스나 우리가 그 도구로 달성하려는 정확한 목표를 이해하지 못하는 반면 Holly는 이를 명확히 파악합니다”라고 밝혔습니다.

AI 시대를 위한 지능형 데이터 플랫폼

앞으로 우리가 그리는 비전은 Holly가 MongoDB와 고객, 그리고 개별 고객사를 깊이 이해하는 완전히 통합된 인텔리전스 레이어로 자리 잡는 것입니다. 이를 통해 GTM 조직 전체가 엔드투엔드 워크플로를 더 효과적으로 실행하도록 돕게 됩니다.

제가 가장 주목하는 부분은 Holly를 지탱하는 그 이면의 아키텍처입니다. Holly는 현재 모두 동일한 Atlas Agent Engine 아키텍처를 기반으로 구축된 약 30개의 에이전트를 가동하고 있습니다. 해당 아키텍처는 에이전트를 추가한다고 해서 불안정해지지 않으며 30개를 가동하든 3,000개를 가동하든 안정성을 유지하도록 설계되었습니다. MongoDB는 GTM 팀을 위한 도구를 만드는 데 그치지 않았습니다. 조직에 새로운 에이전트가 추가될 때마다 리스크가 누적되는 것이 아니라 안정적으로 확장이 가능한 청사진을 성공적으로 입증해 낸 것입니다.

이것이 바로 Atlas Agent Engine이 보여주는 변화입니다. 단일 클라우드, 모델 또는 프레임워크에 얽매이지 않고, 일회성 에이전트를 넘어 거버넌스 기반의 재사용 가능한 플랫폼으로 나아가는 것입니다. 에이전트가 제대로 동작하길 바라기만 하는 것과, 몇 개를 운영하든 제대로 동작한다고 확신하는 것의 차이입니다.

Atlas Agent Engine 출시는 MongoDB 9.0, Atlas Infinite와 함께 이번 주 MongoDB가 내놓은 세 가지 주요 발표 중 하나입니다. 이 세 가지 발표는 상호 보완적으로 결합되어 시너지를 창출합니다. MongoDB 9.0은 모든 MongoDB 고객이 사용하는 기존 기반을 강화하고 Atlas Infinite는 해당 기반의 확장 한계를 제거합니다. 또한 Atlas Agent Engine은 이 둘 위에서 AI 에이전트가 철저한 거버넌스 체계를 준수하며 실시간 데이터를 바탕으로 구동될 수 있도록 지원합니다.

엔지니어와 개발자들은 도큐먼트 모델(Document Model)이 애플리케이션 데이터의 자연스러운 형태이자 AI 시스템이 정보를 표현하고 교환하는 방식에 부합한다는 이유로 늘 MongoDB를 선택해 왔습니다. 이는 애플리케이션의 구축 속도를 높이고 변화에 보다 용이하게 대응할 수 있도록 해줍니다. MongoDB는 데이터에 자연스럽게 맞아떨어지는 이 특성에 실시간 운영 데이터, 탄력적인 확장, 어디서든 실행할 수 있는 자유를 더했고 이제는 에이전틱 시대를 위해 설계된 플랫폼까지 갖췄습니다. 점점 더 많은 기업이 MongoDB를 선택하는 이유입니다.

단 하나의 플랫폼. 원하는 수의 에이전트. MongoDB의 지능형 데이터 플랫폼을 활용해 데이터가 이미 존재하는 곳에서 빌드, 배포 및 실행하세요.