Next '26 고객 사례를 아키텍처로 읽기: 800개의 에이전트는 어떻게 굴러갈까

숫자부터 의심하고 시작하기

키노트의 고객 사례 슬라이드에는 늘 큰 숫자가 붙어 있습니다. Next '26도 마찬가지였습니다. 구글은 이번 행사에서 300개 넘는 AI 고객 사례를 새로 공개해, 누적 1,302개가 됐다고 밝혔습니다.

솔직히 이런 숫자는 그대로 믿지 않습니다. 측정 기준을 모르니까요. "95% 단축"이 무엇의 95%인지, 어떤 기간을 비교한 건지 슬라이드에는 나오지 않습니다.

그래서 이번에는 다르게 읽어 보기로 했습니다. 숫자는 옆으로 치워두고, 그 숫자를 만들려면 어떤 구조가 필요했을까를 상상해 보는 겁니다. 아래 내용 중 사례 자체는 구글이 공개한 것이고, 구조에 대한 해석은 제 추측입니다.

800개라는 숫자가 말하는 것

가장 먼저 눈에 들어온 건 개수였습니다.

• GE Appliances: 제조, 물류, 공급망 전반에 Gemini Enterprise 기반 에이전트 800개 이상
• Tata Steel: 9개월 만에 전문 에이전트 300개 이상 배포
• Merck: 연구개발, 제조, 영업, 경영지원에 걸친 에이전트 플랫폼을 직원 75,000명에게 제공

800개의 에이전트를 800명의 개발자가 만들었을 리는 없습니다. 이 숫자가 가능하려면 현업 담당자가 직접 에이전트를 만들 수 있어야 합니다. Gemini Enterprise 앱의 노코드 Agent Designer나, 플랫폼의 저코드 Agent Studio 같은 도구가 전제되어야 합니다.

그렇다면 다음 질문이 생깁니다. 현업이 만든 800개를 누가 관리할까요.

여기서 앞선 거버넌스 글의 Agent Registry와 Identity가 다시 등장합니다. 승인된 도구 목록이 없으면 800개의 에이전트가 800가지 방식으로 데이터에 접근합니다. 에이전트 수가 늘어날수록 중요한 건 에이전트가 아니라 공용 도구 계층입니다.

작은 팀에게도 이 교훈은 유효합니다. 에이전트를 몇 개 만들었다면, 다음 에이전트를 만들기 전에 공용 도구부터 정리하는 게 순서입니다.

운영 이벤트를 받는 멀티 에이전트

Deutsche Telekom의 MINDR는 결이 달랐습니다. Gemini 기반 멀티 에이전트로 네트워크 운영을 처리하고, 이벤트 관리 시간을 95% 이상 줄였다고 발표했습니다.

네트워크 운영은 사람이 질문하는 구조가 아닙니다. 알람이 먼저 옵니다. 장비 수천 대에서 쏟아지는 이벤트를 받아 상관관계를 찾고, 원인을 좁히고, 조치를 제안해야 합니다.

이런 구조에서는 에이전트가 "대화 상대"보다 "이벤트 처리기"에 가깝습니다. 아마도 이벤트를 분류하는 에이전트, 원인을 추적하는 에이전트, 조치안을 만드는 에이전트가 나뉘어 있을 겁니다. 앞서 ADK 글에서 다룬 그래프 워크플로가 정확히 들어맞는 형태입니다.

우리 데이터 파이프라인에 대입하면 이렇습니다. 배치 실패 알람이 오면 로그를 읽고 원인을 분류하는 에이전트. Data Engineering Agent의 장애 분석 기능이 하려는 일이기도 합니다.

기억이 곧 고객 경험인 경우

Papa John's는 Gemini Enterprise for Customer Experience의 주문 에이전트를 처음 도입한 고객으로 소개됐습니다. 사례 설명에서 눈에 띈 건 단골의 "늘 먹던 메뉴"를 기억한다는 부분이었습니다.

기술적으로 풀면 장기 기억과 고객 식별의 문제입니다. 플랫폼 발표의 Memory Bank와, 세션 ID를 CRM 레코드와 묶을 수 있게 한 Agent Sessions가 이 그림에 맞아떨어집니다.

Home Depot의 전화 에이전트는 고객의 필요를 10초 안에 파악한다고 했습니다. 전화는 텍스트 채팅보다 기다림에 훨씬 민감합니다. 이 요구는 Agent Runtime의 빠른 콜드 스타트, TPU 8i 같은 추론 인프라 발표와 연결해서 읽혔습니다.

두 사례를 함께 보면 하나가 분명해집니다. 고객 접점 에이전트에서는 모델의 똑똑함보다 기억과 응답 속도가 체감 품질을 더 크게 좌우합니다.

연결이 끊기는 곳의 에이전트

개인적으로 가장 흥미로웠던 사례는 Virgin Voyages였습니다. 크루즈 선상의 컨시어지 에이전트 'Rovey'를 Gemini Enterprise와 Google Distributed Cloud 위에서 운영합니다. 바다 위처럼 연결이 제한된 환경에서도 동작한다는 게 핵심이었습니다.

클라우드 에이전트는 대개 네트워크가 늘 연결돼 있다고 가정합니다. 이 사례는 그 가정을 깨야 하는 현장이 있다는 걸 보여줍니다. 공장, 매장, 선박처럼요.

구조로 보면 모델 추론과 필요한 데이터를 현장 가까이 두고, 연결될 때 동기화하는 형태일 겁니다. 일반적인 사내 에이전트에서 만날 일은 드뭅니다. 그래도 "네트워크가 끊기면 이 에이전트는 무엇을 하는가"는 한 번쯤 던져볼 만한 질문입니다.

조달, 연구, 그리고 조용한 사례들

나머지 사례들도 짧게 적어 둡니다.

Unilever는 Agent Platform 위에서 멀티 에이전트 조달 솔루션을 만들고 있습니다. 37억 명의 소비자를 상대하는 회사라는 소개가 붙었습니다. 조달은 계약서, 공급사 데이터, 내부 승인 규정이 얽힌 업무입니다. 에이전트가 판단하는 부분과 사람이 승인하는 부분의 경계가 중요한 영역입니다.

Citadel Securities는 TPU 위에 연구 환경을 꾸려 AI 워크로드를 최대 4배 빠르게, 비용은 30% 낮췄다고 밝혔습니다. 에이전트보다는 인프라 사례에 가깝습니다.

Highmark Health는 사내 AI 어시스턴트 Sidekick으로 2025년 한 해에만 2,790만 달러의 가치를 만들었다고 했습니다. Capcom은 게임 플레이 테스트에 시각 검사, 예측, 사내 지식 에이전트를 나눠 씁니다.

큰 회사의 사례에서 작은 팀이 가져갈 것

수백 개의 에이전트, 수만 명의 사용자. 작은 팀과는 거리가 먼 숫자처럼 보입니다. 그런데 구조로 다시 읽어 보면, 작은 규모에서 먼저 겪는 문제들이 그대로 커진 모습이었습니다.

에이전트가 세 개일 때 공용 도구를 정리하지 않으면, 서른 개일 때 손을 쓸 수 없습니다. 첫 에이전트부터 신원을 나눠두지 않으면, 나중에 감사 로그를 읽을 수 없습니다. 실패 로그를 쌓지 않으면, 개선은 늘 감으로 하게 됩니다.

Next '26의 사례 슬라이드에서 가장 크게 적힌 건 성과 숫자였습니다. 반년 뒤 다시 읽으며 제 눈에 남은 건 그 숫자 아래에 깔려 있었을 지루한 기반 작업들입니다. 화려한 에이전트를 만드는 일보다, 그 에이전트가 기대어 설 바닥을 다지는 일이 먼저라는 것. 이 시리즈를 쓰면서 가장 많이 되새긴 생각이기도 합니다.