Vibe-Coded에서 신뢰 가능한 에이전트까지: Gemini Enterprise Agent Platform을 활용한 빌드, 확장, 거버넌스
요약
본 글은 Gemini Enterprise Agent Platform을 활용하여 에이전트를 구축하고, 신뢰성(신뢰할 수 있는 작동 여부)과 거버넌스 측면에서 검증하는 과정을 다룹니다. 주변 환경 기반 경비 지출 에이전트 데모를 통해, 단순한 코딩을 넘어 보안 검증 및 사람의 개입이 필요한 복잡한 시나리오 처리 방법을 제시합니다.
핵심 포인트
- Gemini Enterprise Agent Platform은 Build, Scale, Govern, Optimize 4단계로 구성되어 신뢰성 확보에 중점을 둡니다.
- Ambient Expense Agent는 Pub/Sub 이벤트 기반으로 작동하며, 금액별 다른 규칙(승인/보안 검증)을 적용합니다.
- 단순 코딩보다 '검토(Review)' 과정에서 발견한 버그 수정 및 로직 개선이 에이전트의 핵심 가치를 높입니다.
에이전트(agent)를 구축하는 것은 이제 쉽습니다. 하지만 그것을 신뢰하는 것이 어려운 부분입니다. 제가 실제로 하나의 에이전트를 어떻게 완성했는지, 실제 스크린샷과 GitHub 코드를 통해 보여드리겠습니다.
에이전트 구축은 이제 매우 쉬워졌습니다. 코딩 에이전트와 Google의 codelabs 중 하나를 활용하여 저는 하루 만에 작동하는 에이전트를 만들었습니다. 하지만 그것을 신뢰하는 것이 어려운 부분입니다.
만약 여러분이 보안팀이나 비즈니스 오너에게 에이전트를 보여준다면, 아무도 "작동하나요?"라고 묻지 않습니다. 그들은 네 가지 질문을 던집니다.
- 올바른 일을 수행합니까?
- 모두에게 신뢰성 있게 작동합니까?
- 경계 내에서 유지될 수 있습니까?
- 개선되고 있다는 것을 증명할 수 있습니까?
Gemini Enterprise Agent Platform은 바로 이 네 가지 질문을 중심으로 구성되어 있습니다: 구축(Build), 확장(Scale), 거버넌스(Govern), 최적화(Optimize). 본문에서는 제가 직접 진행한 프로젝트의 실제 스크린샷을 사용하여 하나의 에이전트가 이 네 단계를 모두 거치는 과정을 보여드리겠습니다. 이는 10월 29일 NM TechFest에서 열리는 저의 기조연설과 11월 6일 DevFest Montréal에서의 세션의 미리 보기입니다. 코드, 설정 가이드, 테스트 증거를 포함하여 여러분이 보게 될 모든 것은 GitHub에 있습니다.
데모: 주변 환경 기반 경비 지출 에이전트 (Ambient Expense Agent)
이 에이전트는 Google의 codelab인 Vibecode an ADK 2.0 Ambient Agent with Antigravity and Agents CLI에서 각색된 주변 환경 기반 경비 지출 승인기입니다. "주변 환경 기반(Ambient)"이라는 것은 채팅을 기다리지 않는다는 의미입니다. Pub/Sub을 통해 경비 지출이 도착하는 것과 같은 이벤트에 반응합니다. 이 에이전트는 세 가지 규칙을 따릅니다:
- 100달러 미만: 일반 코드가 승인합니다. 모델 호출은 없습니다.
- 100달러 이상: 보안 검증(security checkpoint)이 실행된 후, Gemini가 위험도를 검토하고, 워크플로우는 사람의 개입을 위해 일시 중지됩니다.
- 프롬프트 주입 (Prompt injection): 모델은 완전히 건너뛰어지고, 해당 사례는 보안 이벤트로 플래그 지정되어 바로 담당자에게 전달됩니다.
왜 비용 지출일까요? 모두가 이해하는 위험 요소들이 있기 때문입니다. 돈, 개인 데이터, 그리고 시스템을 속이려는 누군가가 있습니다. 비용 지출을 보험 청구, 환불 또는 접근 요청으로 바꿔도 디자인은 같습니다. 쉬운 케이스에는 규칙을 적용하고, 어려운 케이스에는 판단을 내리며, 위험한 모든 것에는 사람의 개입이 필요합니다.
Vibe coding: 설명하고, 에이전트가 작성하게 한 다음, 검토하기
저는 지금 우리 중 많은 사람이 구축하는 방식으로 이 시스템을 만들었습니다. 저는 Google의 agentic IDE인 Antigravity에게 행동 방식을 설명했고, Agents CLI 스킬을 로드하여 실제 ADK 2.0 API를 사용하도록 했습니다. 코드를 작성하는 것은 쉬운 부분이었습니다. 가치를 창출한 곳은 '검토(Review)'였습니다.
검토 과정에서 행복한 경로(happy-path) 데모에서는 괜찮아 보였을 두 가지 버그를 발견했습니다.
- '거부(DISAPPROVE)'를 '예(yes)'로 읽는 승인 확인 로직. 첫 번째 버전은 사람이 답장에 "APPROV"라는 문자가 포함되어 있으면 승인했고, 단어 DISAPPROVE에도 이 문자들이 포함되어 있었습니다. 따라서 DISAPPROVE가 비용 지출을 승인하는 결과를 낳았습니다. 의심스러울 때는 '예'라고 말하는 것이었습니다. 즉, 실패 시 열리는(fail open) 방식이었습니다. 수정된 로직은 실패 시 닫히는(fail closed) 방식으로 변경되어, 정확한 APPROVE, YES 또는 ACCEPT만 승인을 하고 그 외의 모든 것은 거부하도록 했습니다.
- 에이전트 패키지가 포함되지 않은 컨테이너. Dockerfile에서 앱 래퍼는 복사했지만, 가져오는 에이전트 패키지는 복사하지 않아 배포된 서비스가 시작 시 실패할 것이었습니다.
제가 작성한 가장 유용했던 프롬프트 중 하나는 빌드(build) 프롬프트가 아니라 검토(review) 프롬프트였습니다: "검토만 하세요. 파일을 수정, 생성 또는 실행하지 마세요. 승인 결정이 어떻게 작동하는지 설명하고, 정확한 줄을 인용하며, 왜 부분 문자열 체크(substring check)가 안전하지 않은지 설명하세요."
검토 전용 모드의 Antigravity: 실패 시 닫히는(fail-closed) 로직을 인용하고 부분 문자열 체크가 안전하지 않은 이유를 설명합니다.
코딩 에이전트의 출력을 동료의 풀 리퀘스트(pull request)처럼 취급하세요. 읽어보고, 스스로 설명해달라고 요청하며, 발견하는 모든 버그를 테스트 케이스로 만드세요.
빌드(Build): 코드가 무엇을 알지 결정하고, 모델이 조언합니다
기능성. ADK 2.0 그래프 워크플로우를 사용하면 일반 Python 노드와 모델 노드를 하나의 그래프에 배치할 수 있으며, 사용자 개입을 위한 내장 일시 정지 기능도 제공됩니다. 이 기능을 개발자 UI인 adk web에서 시작하는 ADK Web에서 실행하고 검사하며 추적할 수 있습니다.
중요성. 프롬프트는 제안일 뿐이지만, 코드는 보증입니다. 만약 $100 임계값이 프롬프트에 존재한다면, 교묘한 설명만으로 모델을 속여 그 기준을 무효화시킬 수 있습니다. 그래프에서는 모델에게 어떤 것이 승인되어야 하는지 묻는 적이 없습니다. 단지 얼마나 위험해 보이는지만 묻습니다.
ADK Web의 에이전트 그래프입니다. 코드 노드(f)가 규칙을 만들고, 하나의 Gemini 노드(spark)만 위험도를 평가합니다. 녹색은 $150 요청이 거쳐간 경로를 보여줍니다.
위 그래프에서 _f_로 표시된 모든 노드는 코드 노드입니다: 파싱, 임계값 설정, 주입 확인 및 마스킹(redaction). spark으로 표시된 risk_reviewer 노드가 유일한 Gemini 노드입니다. 이것이 제공하는 이점은 다음과 같습니다:
- $100 미만: 임계값 노드는 즉시 자동 승인 경로로 이동합니다. Gemini는 호출되지 않으므로 토큰 소모가 없고, 지연 시간도 없으며, 단위 테스트(unit-test)할 수 있는 규칙이 됩니다.
- $100 이상: 체크포인트가 먼저 설명을 스캔한 다음, Gemini가 구조화된 출력(위험 수준, 요약, 플래그 및 권장 사항)을 반환하며 이는 스키마에 따라 검증됩니다. 이것은 결정이 아니라 권장 사항입니다.
- 임계값 초과 시, 워크플로우는 ADK의 RequestInput을 사용하여 일시 정지합니다. 사람이 APPROVE 또는 REJECT를 입력하면, 인간의 결정이 승리합니다. 명확한 '예'가 아닌 것은 모두 '아니오'입니다.
제가 가장 중요하게 생각하는 사례는 프롬프트 주입(prompt injection)입니다: 설명에 _
1백만 달러짜리 프롬프트 주입(prompt injection): SSN은 마스킹되고, 체크포인트가 이를 감지하며, Gemini 노드(회색 처리된 왼쪽)는 실행되지 않습니다.
다른 것이 보기 전에 숫자가 [REDACTED_SSN]으로 대체되고, 체크포인트가 주입을 감지하여 Gemini 노드는 실행되지 않습니다. 이 사례는 플래그와 함께 곧바로 사람에게 전달됩니다. 분명히 하자면, 이 체크포인트는 간단한 정규 표현식(regex)입니다. 실제로 작동하는 실제 코드이지만, 프로덕션 보안 제어(production security control)는 아닙니다. 이것이 Govern가 추가하는 부분입니다.
하지만 채팅 창의 말만 믿지는 마세요. 추적 기록(Traces)은 실제로 무엇이 실행되었는지 보여줍니다:
추적 기록은 실제로 실행된 것을 보여줍니다: 150달러 요청에 대한 모델 실행, 그리고 주입(injection)에는 모델 스팬이 전혀 없습니다.
150달러 요청(상단)에서는 모델이 실행되었습니다. 주입(하단)에서는 모델 스팬 자체가 없습니다. 중요한 모든 규칙은 총 33개의 단위 테스트(unit test)로도 커버되며, 여기에는 DISAPPROVE 사례와 여러 사회 보장 번호(social security number) 형식이 포함됩니다.
방법: 그래프는 expense_agent/agent.py에 있습니다. README를 참조하세요.
확장성(Scale): 하나의 명령으로 관리형 런타임(managed runtime)까지
기능: Agent Runtime은 에이전트를 호스팅하고 자동 스케일링하며, 일시 중지 상태에서도 세션을 유지하고, 모든 배포를 리비전(revision)으로 만듭니다.
중요한 이유: 관리할 인프라가 없으며, 인간의 속도에 맞춘 워크플로우는 요청 사이에 생존합니다.
배포(Deployment)는 세 가지 명령어로 이루어집니다. 변경될 내용을 확인하는 드라이 런(dry run)을 실행하고, 프로젝트와 리전(region)을 지정하여 agents-cli deploy를 사용한 다음, agents-cli deploy --status를 실행합니다. 재배포(redeploy)는 동일한 엔진을 제자리에서 업데이트합니다. 제가 배포한 환경은 0개부터 10개의 인스턴스로 확장되었으며, 각 인스턴스는 1 vCPU와 4 GiB의 메모리를 사용했습니다.
하나의 명령어로 agents-cli deploy가 컨테이너를 빌드하고 Agent Runtime에 있는 엔진을 업데이트합니다.
제가 가장 마음에 드는 부분은 일시 중지된 승인(paused approval)이 라이브 세션이라는 점입니다. 콘솔 플레이그라운드(Console Playground)에서 배포된 엔진의 주입 사례(injection case)를 살펴보겠습니다: 내용이 가려지고, 에스컬레이트(escalated)되었으며, 사람이 검토하기 위해 일시 중지되었습니다.
콘솔 플레이그라운드에서 배포된 엔진에 동일하게 주입되었으며, 내용이 가려지고 에스컬레이트되어 사람이 검토하기 위해 일시 중지되었습니다.
플레이그라운드에서 APPROVE 또는 REJECT를 입력하면 일시 중단되었던 실행(run)이 재개되어 완료됩니다. 플레이그라운드는 미리 보기 기능이라서, 답장이 JSON 형식이 아니라는 오류가 표시될 수도 있지만 결과는 정확합니다. 실제 운영 환경에서는 사용자의 승인 애플리케이션(approval app)이 제 테스트 스크립트처럼 작동하여, 몇 분 또는 몇 시간 후에 답변을 function_response로 동일한 세션에 전송하게 됩니다.
방법: README에서 Agent Runtime으로 배포하는 과정을 확인하거나, Google의 코랩(codelab)인 Deploy an ADK agent to Agent Runtime using Agents CLI를 따라해 보세요.
거버넌스(Govern): 정책은 모델 외부에 존재해야 한다
기능(The capability). 모든 에이전트를 파악할 수 있는 Agent Registry, 각 에이전트에게 고유한 신원을 부여하는 Agent Identity, 그리고 Model Armor를 통해 에이전트에 도달하기 전 트래픽을 검열하는 Agent Gateway가 있습니다. Google의 2026년 9월 23일자 문건에 따르면 이 기능들은 일반적으로 사용 가능(generally available)합니다. Semantic governance (Preview)와 anomaly detection (Private Preview)도 존재하지만, 저는 이를 설정하지 않았습니다.
중요한 이유(Why it matters). 프롬프트는 보안 경계가 아닙니다. 게이트웨이는 그 뒤에 있는 모든 에이전트에게 동일한 보호를 제공하며, 보안 팀이 정책을 소유하고 개발자는 무언가를 호출하는 것을 기억할 필요가 없습니다.
신원 우선(Identity first). Agent Identity로 재배포한 후, 제 에이전트는 공유 서비스 계정 대신 이 엔진에 한정된 자체 주체(principal)를 갖게 되었습니다. 그 행동은 자신에게 귀속되며, 게이트웨이를 바인딩하려면 이것이 필요합니다. 이는 조직이 없는 프로젝트에서도 작동했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기