멀티 AI 에이전트 구현과 운영은 이제 마음만 먹으로 도전할 수 있는 목표가 되었습니다. 시장의 예상보다 AI 에이전트 시대가 빨리 온 이유로 많은 이들이 도구의 진화를 꼽습니다. 관련해 이번 포스팅에서는 Agent Development Kit(ADK)가 AI 에이전트 구현에 어떤 변화를 불어 오고 있는지 알아보겠습니다.
ADK가 가져온 AI 에이전트 개발 방식의 전환
AI 에이전트 구현 방식의 변화는 ADK 등장 후 드라마틱하게 일어났습니다. ADK 등장 전 구글 클라우드에서 대화형 AI 챗봇 구현도 만만치 않은 작업이었습니다. 당시에는 주로 Vertex AI Agent Builder나 그 전신인 Dialogflow CX 같은 도구를 사용했습니다.
이런 도구로 개발을 하려면 손이 많이 갑니다. 개발자는 콘솔에서 데이터 저장소를 생성하고 흐름(Flows)을 시각적으로 설계해야 했고 의도(Intent)를 정의하기 위해 수많은 훈련 문구를 일일이 입력해야 했습니다. 외부 API를 연동하려면 웹훅(Webhook)을 위해 별도의Cloud Functions를 배포하고 등록하는 복잡한 과정도 거쳐야 했습니다.
이러한 접근 방식은 유연성이 부족하고 대화 로직이 틀에 갇히는 한계가 있었습니다. 결정적으로 Git을 사용한 버전 관리, 자동화된 테스트, CI/CD 파이프라인 통합 같은 현대적인 소프트웨어 개발 워크플로우에 자연스럽게 녹아들기 어려웠습니다.
ADK는 기존 개발의 불편함과 보이지 않는 문제들을 해결합니다. ADK는 파이썬 중심의 오픈 프레임워크로 모델이나 배포 방식에 구애받지 않고 멀티 AI 에이전트 개발할 수 있는 길을 열었습니다. 개발자는 더 이상 각종 라이브러리와 서비스를 개별적으로 조립할 필요 없이 ADK가 제공하는 AI 에이전트, 세션, 도구의 추상화를 그대로 사용하면 됩니다. 이는 Python 개발자가 익숙한 도구와 작업 방식으로 AI 에이전트의 생명주기를 관리할 수 있게 되었음을 뜻합니다.
서버리스 컴퓨팅 아키텍처가 대세인 이유
ADK의 가치는 서버리스 컴퓨팅 환경과 맞나 더욱 커집니다. 거대 언어 모델(LLM) 기반 AI 에이전트 플랫폼 아키텍처의 설계 원칙은 ‘분리’입니다. 이에 있어 구글 클라우드의 Cloud Run 같은 서버리스 환경은 매우 이상적이라 할 수 있습니다.
왜 ‘분리’를 강조하는 것일까요? 이는 LLM과 AI 에이전트의 자원 요구량 다르기 때문입니다. LLM 기반 추론 서비스는 복잡한 신경망 연산을 수행하는 자원 집약적 워크로드로 값비싼 GPU가 필수입니다. 반면에 AI 에이전트 서비스는 웹 요청 처리, 세션 관리 등 가벼운 작업을 수행하는 경량 워크로드로 GPU 없이도 실행할 수 있습니다. 이 두 워크로드를 하나로 묶는 것은 가벼운 웹 요청을 처리하기 위해 값비싼 GPU 자원을 불필요하게 사용하는 것과 같아 비효율을 초래합니다. 따라서 이 둘을 분리하는 것은 선택이 아닌 필수라 할 수 있습니다.
분리 원칙을 반영한 멀티 AI 에이전트 플랫폼 아키텍처는 Cloud Run와 ADK로 구현할 수 있습니다. Cloud Run은 인프라 관리가 필요 없는 완전 관리형 서버리스 플랫폼으로 LLM 추론에 필수인 고성능 GPU 자원을 온디맨드 방식으로 제공합니다. AI 추론 워크로드를 위해 특별히 설계된 NVIDIA L4 GPU로 실시간 응답성을 보장하는 빠르고 비용 효율적인 성능을 확보할 수 있습니다.
더불어 Cloud Run으로 모델 배포와 서빙 프레임워크 운영도 간소화할 수 있습니다. 다음 그림은 Gemma와 Olama를 Cloud Run 환경에서 GPU 자원과 연계해 운영하는 컨셉을 보여줍니다. Gemma의 작은 크기와 Olama의 단순성이 결합해 Cloud Run의 서버리스 모델 위에서 실행하면 민첩하고 비용 효율적인 솔루션이 탄생합니다. 이 조합에서 Olama 대신 vLLM을 적용하는 것도 고려할 수 있습니다.
참고로 구글이 제공하는 오픈 소스 모델인 Gemma는 2억 7천만 개의 매개변수를 가진 소형 크기 덕분에 빠른 로딩과 적은 메모리 점유율을 보장하며 프로덕션 환경에 즉시 적용 가능한 양자화(quantization) 기술이 내장되어 효율성이 높습니다. 그리고 Olama는 오픈 소스 모델을 API 엔드포인트로 노출하는 과정을 극도로 단순화하는 LLM 서빙 프레임워크입니다.
Cloud Run과 짝을 이루는 멀티 AI 에이전트 플랫폼 아키텍처의 다른 한 축은 바로 ADK입니다. 이를 활용해 AI 에이전트 서비스를 구현할 수 있습니다. AI 에이전트 서비스는 시스템의 소통 창구이자 관문입니다. 사용자와의 직접적인 상호작용, 즉 대화 흐름 제어, 세션 관리 등을 담당하며 LLM 추론 서비스로 요청을 전달하는 역할을 합니다. ADK로 구현한 AI 에이전트 서비스는 분리 원칙에 따라 CPU 자원을 할당한 Cloud Run 환경에 배포합니다. LLM 모델과 서빙과 완전히 별도의 서비스로 배포하는 것입니다.
분리형 아키텍처의 비즈니스 가치
앞서 소개한 분리형 아키텍처를 채택하는 것은 기술적 이점을 넘어 비즈니스 운영에 직접적인 영향을 미칩니다. 긍정적인 영향을 끼치는 데 크게 두 가지로 정리해 볼 수 있습니다.
먼저 독립적 확장을 통해 비용을 급진적으로 최적화합니다. 분리형 아키텍처의 가장 큰 경제적 이점은 트래픽 증가에 대응하는 방식에 있습니다. 동시 접속자 수가 1명에서 1,000명으로 급증할 때 통합 아키텍처는 GPU가 포함된 값비싼 인스턴스 1,000개를 확장해야 할 수 있습니다. 하지만 분리형 아키텍처에서는 트래픽 부하를 대부분 경량의 AI 에이전트 서비스가 흡수합니다. 이 서비스는 GPU가 없으므로 매우 저렴한 비용으로 확장될 수 있습니다. 반면에 고비용의 GPU 기반 LLM 추론 서비스는 실제 추론 요청량에 맞춰 최소한의 수준으로만 확장됩니다. 이처럼 웹 트래픽과 GPU 비용의 연결고리를 끊음으로써 가시적인 비용 효율성을 달성할 수 있습니다.
다음으로 개발 민첩성을 높일 수 있습니다. LLM 추론과 AI 에이전트 서비스의 분리는 개발팀의 생산성을 향상시킵니다. AI 에이전트 팀은 대화 흐름 개선을 위해 경량의 agent.py 파일만 수정하고 즉시 재배포할 수 있습니다. AI/ML 플랫폼 엔지니어링 팀은 AI 에이전트 서비스와 무관하게 Gemma 모델을 더 큰 버전으로 업그레이드하거나, 특정 도메인에 최적화된 모델로 미세 조정(Fine-tuning)하여 교체할 수 있습니다.
미래 지향적 AI 구축을 위한 청사진
구글 클라우드 환경에서는 Cloud Run과 ADK로 완벽하게 작동하는 프로덕션 수준의 멀티 AI 에이전트 플랫폼을 구축할 수 있습니다. 분리를 원칙으로 하는 아키텍처를 Cloud Run을 토대로 설계택하면 “수천, 수만 명의 사용자로 트래픽이 급증할 때 시스템은 어떻게 반응할 것인가?”라는 질문에 답을 할 수 있습니다. 더불어 조직의 AI 에이전트 전략의 로드맵 수립도 투명하게 할 수 있습니다. 구글 클라우드는 Agent Builder, Agent Engine, Agentspace 및 Agent2Agent(A2A) 프로토콜 등 광범위한 AI 에이전트 관련 기술 스택을 지속해서 강화하고 있습니다. 미래 지향적인 멀티 AI 에이전트 플랫폼 구축을 고민 중이라면 메가존소프트가 도움을 드리겠습니다.
