데이터 과부하에서 실행 가능한 통찰로: 벨로우즈 커넥트가 10만 명의 사용자를 위한 에이전트 AI를 확장한 방식

Verizon Connect 사례는 텔레매틱스 차량 관제(fleet management)에서 쏟아지는 방대한 센서·위치·운행 데이터를 LLM 기반 에이전트가 자연어 질의로 풀어내도록 한 구조입니다. 핵심은 단순 챗봇이 아니라 "에이전틱(agentic)" 아키텍처라는 점인데, 모델이 사용자의 질문을 받으면 스스로 작업을 분해하고 어떤 도구(tool)를 호출할지 추론(reasoning)한 뒤, 데이터 조회 API나 분석 함수를 순차적으로 실행해 답을 조립합니다. AWS 환경이라는 점을 감안하면 Amazon Bedrock 위에 기반 모델을 두고, 도메인 데이터에 대한 환각을 줄이기 위해 RAG(검색 증강 생성)로 운행 기록·차량 상태를 컨텍스트에 주입하며, function calling으로 정형 데이터베이스를 질의하는 패턴일 가능성이 큽니다. 즉 LLM은 "무엇을 어떻게 계산할지"를 판단하는 오케스트레이터 역할을 하고, 실제 수치 계산과 데이터 정합성은 결정적(deterministic) 도구가 책임지는 역할 분리가 신뢰성의 핵심입니다.

엔지니어 관점에서 가장 주목할 부분은 PoC가 아니라 하루 10만 명 규모의 프로덕션으로 확장했다는 점입니다. 데모 수준의 에이전트를 만드는 것과, 동시 사용자·지연 시간·토큰 비용·환각 통제를 모두 만족시키며 운영하는 것은 완전히 다른 난이도의 문제입니다. 10만 사용자 규모에서는 매 요청을 LLM에 그대로 태우면 비용과 레이턴시가 폭발하므로, 의미 기반 캐싱(semantic caching), 자주 묻는 질의의 결과 재사용, 작은 모델로 라우팅하는 모델 게이트웨이, 그리고 무엇보다 잘못된 답을 막는 가드레일(guardrails)과 평가(evaluation) 파이프라인이 필수가 됩니다. 또한 에이전트가 다단계로 도구를 호출하는 만큼 각 단계의 추적성(observability)과 실패 시 폴백 전략이 운영 안정성을 좌우합니다.

개발자가 실무에서 취해야 할 시사점은 명확합니다. 첫째, 에이전트에게 자유 텍스트 생성을 맡기기보다 "데이터 접근은 검증된 도구를 통해서만" 하도록 경계를 긋고, 모델은 의사결정·요약·자연어 변환에 한정하는 것이 환각과 데이터 오류를 동시에 줄이는 가장 현실적인 설계입니다. 둘째, 처음부터 평가셋과 회귀 테스트를 갖춰 프롬프트나 모델을 교체할 때 품질 저하를 정량적으로 잡아내야 하며, 이것이 없으면 스케일업 과정에서 신뢰가 무너집니다. 셋째, 비용·지연은 사후 최적화 대상이 아니라 초기 아키텍처 결정 사항으로 다뤄야 합니다 — 캐싱 계층과 모델 라우팅을 설계 단계에 포함시키는 것이 10만 규모 운영의 전제 조건입니다.

마지막으로, 이 사례는 "데이터가 많다"는 것 자체가 가치가 아니라 사용자가 즉시 행동으로 옮길 수 있는 인사이트로 가공될 때 비로소 가치가 된다는 점을 보여줍니다. 사내에 미활용 데이터가 쌓여 있는 조직이라면, 거대한 BI 대시보드를 더 만드는 대신 자연어 질의 위에 에이전트를 얹어 "질문 → 도구 호출 → 검증된 답변"의 좁고 신뢰할 수 있는 경로를 먼저 만드는 접근이 투자 대비 효과가 큽니다. 다만 도메인 도구·가드레일·평가 체계 없이 LLM만 붙이는 시도는 데모에서는 그럴듯해도 프로덕션 스케일에서 반드시 무너지므로, 처음부터 운영 가능한 형태로 작게 시작해 확장하는 전략이 권장됩니다.