2026년 7월 30일, 도쿄 빅사이트에서 개최된 「Google Cloud Next Tokyo」의 Day 1에 참여하고 왔습니다.

올해 이벤트에서는 AI 에이전트를 비롯한 「Agentic AI」와 Gemini를 활용한 기업용 솔루션이 비중 있게 다뤄졌습니다.

행사장의 Expo 에리어에서는 Google Cloud의 최신 기술뿐만 아니라, 국내외 기업의 구체적인 도입 사례나 데모도 다수 전시되어 있었습니다. 공식 안내에서도 최신 Agentic AI와 클라우드를 체험할 수 있는 장으로서 Expo가 소개되고 있습니다.

이 기사에서는 다음 내용을 중심으로 현지에서 느낀 점을 정리합니다.

• Agentic AI를 중심으로 한 Expo 에리어의 모습
• 엔터프라이즈(Enterprise)에서 AI 에이전트를 구현할 때의 아키텍처 (Architecture)
• Google Cloud의 모든 자격증 보유자로서 받은 인증 배지
• 향후 스스로 검증해 보고 싶은 것

본 기사는 Google Cloud Next Tokyo에 참가한 필자 개인의 감상과 기술적인 고찰입니다. Google Cloud의 공식 견해를 나타내는 것이 아닙니다.

이번 Google Cloud Next Tokyo에서 특히 인상 깊었던 것은, 단순한 생성형 AI (Generative AI)의 활용에 그치지 않고, AI가 도구(Tool)나 데이터를 이용하며 처리를 진행하는 「Agentic AI」 전시와 세션입니다.

Expo 에리어에서는 Google Cloud 및 스폰서 기업의 부스를 통해 AI 에이전트, 데이터 분석, 보안, Google Workspace 등 다양한 영역의 활용 사례가 소개되었습니다.

많은 참가자가 발길을 멈추고 설명 직원에게 질문하거나 데모를 지켜보는 모습이 인상적이었습니다.

저 자신도 평소 다음과 같은 Google Cloud 서비스를 접하고 있습니다.

• Vertex AI
• Cloud Run
• Identity-Aware Proxy (IAP)
• Secret Manager
• Cloud Key Management Service (Cloud KMS)

이번 전시를 통해 이러한 서비스들이 AI 에이전트의 기반으로서 어떻게 조합되어, 엔터프라이즈 환경에서 안전하게 운용되는지 더욱 구체적으로 그려볼 수 있게 되었습니다.

AI 모델을 구동하는 것뿐만 아니라, 개발, 배포, 인증·인가, 모니터링, 운용까지 포함한 라이프사이클 (Lifecycle) 전체를 어떻게 설계할 것인가.

아키텍트 (Architect)의 관점에서는 그 부분이 매우 흥미로운 포인트였습니다.

전시와 세션을 통해 특히 사고를 자극받은 것은, AI 에이전트를 운영 환경(Production)에 어떻게 전개할 것인가라는 아키텍처의 관점입니다.

저는 얼마 전, LangGraph와 Ollama를 이용하여 Human-in-the-loop를 포함한 블로그 집필·리뷰용 멀티 에이전트 시스템을 로컬 환경에서 구축했습니다.

이 경험을 바탕으로 Google Cloud의 서비스로 매핑해 보면, Vertex AI와 Cloud Run의 조합은 엔터프라이즈용 Agentic AI를 구현할 때 유력한 선택지가 될 것 같다는 느낌을 받았습니다.

사용자
│
▼
...

이것은 이번 이벤트에서 공식적으로 제시된 유일한 구성이라는 의미가 아니라, 제가 전시 내용과 자신의 개발 경험을 바탕으로 생각해 본 구성 예시입니다.

에이전트의 실행·관리 기반으로서는 Vertex AI Agent Engine이 중요한 역할을 담당합니다.

Vertex AI Agent Builder는 운영 환경에서 AI 에이전트를 구축, 스케일링 (Scaling), 관리하기 위한 프로덕트 군으로 제공되고 있습니다.

Gemini를 이용한 추론에 더해, 에이전트에는 다음과 같은 역할을 부여할 수 있습니다.

• 사용자로부터 의뢰받은 내용의 이해
• 태스크 (Task) 분해
• 실행 절차 계획
• 호출할 도구 (Tool) 선택
• 도구의 실행 결과에 기반한 다음 판단
• 최종적인 답변 생성

로컬 환경에서 LangGraph 등을 사용하여 구축한 워크플로우 (Workflow)를 Google Cloud 상의 매니지드 (Managed) 기반과 조합해 나가는 이미지입니다.

모든 것을 매니지드 서비스로 가져갈 것인지, 오케스트레이션 (Orchestration)의 일부를 독자적으로 구현할 것인지는 시스템의 요구사항에 따라 달라질 것 같습니다.

AI 에이전트가 호출하는 도구나 독자 API의 실행 환경으로서 Cloud Run은 매우 사용하기 쉬운 서비스입니다.

예를 들어, 다음과 같은 처리를 각각 컨테이너 (Container)화하여 Cloud Run에 배치할 수 있습니다.

• 사내 데이터를 검색하는 API
• 외부 서비스와 연계하는 API
• 문서를 생성하는 처리
• 데이터를 검증·변환하는 처리
• LangGraph 등으로 구현한 독자적인 워크플로우 (Workflow)
• AI 에이전트로부터 호출하는 업무 로직

Cloud Run은 이벤트 주도 (Event-driven) 서비스나 컨테이너화된 잡 (Job)을 실행할 수 있으며, 부하에 따라 0부터 자동으로 스케일링 (Scaling)할 수도 있습니다.

다만, 비동기 처리를 Cloud Run만으로 완결짓는 것이 아니라, 요구사항에 따라 다음 서비스들을 조합할 필요가 있습니다.

Eventarc: Google Cloud 상에서 발생한 이벤트를 처리
Cloud Tasks: 비동기 태스크의 실행, 재시도, 유량 제어 수행
Pub/Sub: 서비스 간을 느슨한 결합 (Loosely coupled) 상태로 만들어 메시지를 연계
Cloud Run Jobs: 배치 처리나 완료될 때까지 실행해야 하는 처리를 구동

AI 에이전트의 처리 시간이나 트래픽은 예측하기 어렵기 때문에, 동기 처리와 비동기 처리를 적절히 나누는 것이 중요해 보입니다.

Agentic AI에서는 AI가 자율적으로 도구 (Tool)를 호출하기 때문에, "누가 무엇을 실행할 수 있는가"를 기존보다 더욱 엄격하게 관리해야 합니다.

사내 사용자가 이용하는 웹 애플리케이션 (Web Application)이라면, IAP를 이용하여 인증됨(Authenticated) 및 인가됨(Authorized) 상태의 사용자만 액세스할 수 있도록 하는 구성을 고려할 수 있습니다.

IAP는 Cloud Run 등에서 동작하는 애플리케이션으로의 액세스를 사용자의 ID를 기반으로 제어하는 서비스입니다.

한편, AI 에이전트가 Cloud Run 상의 도구 API를 호출하는 것과 같은 서비스 간 통신에서는 IAM과 서비스 계정 (Service Account)을 이용합니다.

각각의 에이전트나 도구에 전용 서비스 계정을 할당하고, 필요 최소한의 권한만 부여하는 것이 중요합니다.

예를 들어, "문서를 검색하는 에이전트"에게 데이터 삭제 권한까지 줄 필요는 없습니다.

AI 에이전트라고 해서 특별한 보안 대책을 세우기보다는, 기존의 클라우드 네이티브 (Cloud-native) 베스트 프랙티스를 더욱 엄격하게 적용해야 한다고 느꼈습니다.

외부 API의 API 키, 비밀번호, 인증서 등을 관리할 때는 Secret Manager를 이용합니다.

Secret Manager는 API 키, 사용자 이름, 비밀번호, 인증서 등의 기밀 정보를 저장하고 관리하기 위한 서비스입니다.

반면, Cloud KMS는 데이터 암호화에 사용하는 암호 키를 생성·관리하고, 암호화나 복호화 등의 암호 처리를 수행하기 위한 서비스입니다.

역할을 정리하면 다음과 같습니다.

AI 에이전트가 이용하는 권한이나 기밀 정보를 한데 모아 공유하는 것이 아니라, 에이전트나 도구별로 분리하는 것이 중요합니다.

이번 전시를 보며 다시 한번 느낀 점은, 엔터프라이즈 (Enterprise)에서 Agentic AI를 활용할 경우 모델의 성능만으로는 시스템이 성립되지 않는다는 것입니다.

실제 업무에서 이용하기 위해서는 적어도 다음과 같은 메커니즘이 필요합니다.

• 인증·인가
• 최소 권한 설계
• 도구 호출 제한
• 실행 이력 기록
• 모니터링
• 에러 발생 시 재시도
• 비용 관리
• Human-in-the-loop
• 오조작을 방지하기 위한 가드레일 (Guardrail)

특히 AI 에이전트가 데이터를 업데이트하거나 외부 시스템을 조작하는 경우, 모든 것을 완전히 자율화하기보다는 사람에 의한 확인을 어디에 남겨둘지가 중요해집니다.

"가장 똑똑한 AI를 사용하는 것"뿐만 아니라, "안전하게 멈출 수 있는 것"이나 "나중에 행동을 확인할 수 있는 것"이 엔터프라이즈에서는 큰 가치가 된다고 느꼈습니다.

이번에 개인적인 하이라이트 중 하나가 된 것은 인증 자격 보유자 라운지 방문입니다.

저는 지금까지 지속적으로 Google Cloud 자격 취득에 힘써왔으며, 대상이 되는 모든 인증 자격증을 취득했습니다.

이번에는 회장에서 모든 자격 보유자임을 나타내는 특별한 인증 배지를 받을 수 있었습니다.

지금까지 꾸준히 해온 학습과 자격 취득이 이처럼 눈에 보이는 형태로 나타나니, 역시 동기부여가 됩니다.

회장에서 같은 배지를 달고 있는 분들이나 전문가분들과,

"어떤 시험이 가장 어려웠는지"

"앞으로 어떤 분야를 공부해 나갈 것인지"

와 같은 이야기를 나눌 수 있었던 것도 오프라인 이벤트만의 특별한 경험이었습니다.

온라인으로 기술 정보를 수집하는 것만으로는 얻을 수 없는, 사람과의 연결 또한 이벤트의 큰 매력이라고 생각합니다.

Google Cloud Next Tokyo '26 Day 1에서는 AI가 단순히 질문에 답변하는 단계를 넘어, 도구(Tool)와 데이터(Data)를 활용하며 업무를 수행하는 단계로 넘어가고 있음을 실감했습니다.

특히 인상 깊었던 점은 다음과 같습니다.

• Agentic AI가 구체적인 업무나 서비스에 통합되기 시작하고 있음
• AI 에이전트의 실무 운영(Production)에서는 모델 이외의 기반(Infrastructure)이 중요해짐
• Vertex AI와 Cloud Run은 Agentic AI를 구현하는 데 있어 강력한 조합이 됨
• IAP, IAM, 서비스 계정(Service Account)을 사용한 액세스 제어가 필수적임
• Secret Manager와 Cloud KMS를 용도에 따라 구분하여 사용할 필요가 있음
• 완전 자율화뿐만 아니라, Human-in-the-loop 및 감사성(Auditability)이 중요해짐

이번에 얻은 지식에 대해서는 저 스스로도 직접 손을 움직여 검증해 나가고자 합니다.

우선, 얼마 전 구축한 LangGraph와 Ollama를 이용한 블로그 작성 AI 에이전트를 베이스로 하여, 다음과 같은 구성을 시도해 보고 싶습니다.

• Gemini를 이용한 추론(Inference) 처리
• Vertex AI Agent Engine으로의 에이전트 배포
• Cloud Run에 도구 API(Tool API) 배치
• Secret Manager를 이용한 기밀 정보 관리
• IAM과 서비스 계정을 통한 최소 권한 원칙(Least Privilege) 적용
• Human-in-the-loop를 포함한 승인 플로우(Approval Flow)
• Cloud Logging 및 Cloud Monitoring을 통한 가관측성(Observability) 확보

검증 결과에 대해서는 추후 Qiita나 Zenn을 통해 기술 기사로 다시 아웃풋할 예정입니다.

Day 2에 참가하시는 분들도 꼭 현장에서 최신 Google Cloud와 Agentic AI를 체험해 보시기 바랍니다.