개발 및 IT운영

Gemini에서 MCP 앱을 구현하기 위한 개발자 가이드

Mon, 26 Oct 2026 19:00:00 +0000

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

기업용 AI 어시스턴트는 여전히 대부분 텍스트로 응답합니다. 하지만 시각적 요소가 포함되거나 여러 단계를 거쳐야 하는 작업에서는 수정 사항이 생길 때마다 채팅을 주고받느라 불필요한 시간이 소요되므로 비효율적일 수 있습니다.

MCP 앱(SEP-1865)은 이러한 문제를 해결합니다. 이 개방형 모델 컨텍스트 프로토콜(MCP) 확장 프로그램은 도구를 실시간 UI와 페어링합니다. Gemini Enterprise에서는 해당 UI가 샌드박스 처리된 iframe 내에서 채팅 플로우에 직접 렌더링되며, 전체 화면 또는 측면 패널로 확장할 수도 있습니다. 수정 사항은 로컬에서 실행되며, 작업공간과 어시스턴트는 동기화된 상태로 유지됩니다.

또한 핵심 기반을 처음부터 다시 빌드할 필요가 없습니다. Gemini는 직원 로그인, 제어된 데이터 액세스, 기본 어시스턴트를 제공하며, 사용자는 비공개 Cloud Run 서비스에서 MCP 서버를 호스팅하기만 하면 됩니다.

MCP 앱이 필요한 이유

엔터프라이즈 어시스턴트는 3세대에 걸쳐 발전해 왔습니다.

1세대(텍스트 챗봇): 대화형 제어 기능 없이 정적 마크다운 형식의 결과만 반환합니다.
2세대(표준 MCP 도구): 실시간 API를 호출할 수 있지만 여전히 정적 텍스트 형식으로 출력합니다. 따라서 변경 사항이 발생할 때마다 모델을 다시 호출해야 합니다.
3세대(대화형 MCP 앱): 각 도구를 실시간 작업공간과 페어링합니다. 모델을 다시 호출하지 않고도 위젯 내에서 직접 내용을 수정할 수 있으며, 어시스턴트와의 동기화 상태도 유지됩니다.

Gemini에서 MCP 앱을 빌드하면 얻을 수 있는 6가지 이점:

반응성이 뛰어난 사용자 경험: 채팅창을 거치지 않고 패널에서 클릭 한 번으로 즉시 작업을 실행할 수 있습니다.
목적에 맞게 빌드된 워크플로: 법률 검토를 위한 시각적 수정 뷰, CAD용 3D 뷰어, 금융 분야에 적합한 민감도 모델 등 각 목적에 특화된 워크플로를 제공합니다.
엔터프라이즈 보안: 직원 OAuth 로그인, 비공개 Cloud Run 인그레스, 샌드박스 처리된 iframe이 각 레이어를 보호합니다.
휴먼인더루프 거버넌스: 중요한 작업을 실행하기 전에 먼저 전문가의 검토와 승인을 거칩니다.
개방형 표준: 호환되는 다양한 호스트 간에 이동 가능하며 텍스트 기반 대체 기능이 자동으로 제공됩니다.
광범위한 연결: BigQuery, Agent Platform, Cloud Storage 또는 사내 ERP 및 CRM 시스템과 연동할 수 있습니다.

상위 수준 아키텍처

분리된 세 계층이 함께 작동합니다.

클라이언트 브라우저: 측면 패널에 채팅창과 MCP 앱 위젯을 함께 표시합니다.
Gemini Enterprise: 기본 어시스턴트가 도구를 호출하고, AppBridge 프록시가 위젯 메시지를 릴레이하며, 커넥터가 OAuth를 관리합니다.
Google Cloud(사용자 프로젝트): Cloud Run에 MCP 서버를 배포하고 호스팅합니다. 이 서버는 하나의 JSON-RPC 엔드포인트(/mcp)를 제공하고, 백그라운드 작업을 실행하며, 단일 파일 형태의 HTML 위젯을 제공합니다.

각 계층은 인접한 계층과만 통신하므로 Gemini Enterprise가 보안 및 라우팅을 적용할 수 있습니다.

독립적인 두 레이어를 통한 인증

각 사용자는 OAuth 2.0을 통해 로그인합니다. Gemini Enterprise는 호출할 때마다 사용자의 OAuth 토큰과 함께 자체 서비스 에이전트 토큰을 함께 전송합니다.

레이어 1(Cloud Run IAM): Google 에지에서 적용되며 '어떤 서비스가 호출할 수 있는가?'라는 질문에 답합니다. 공개 액세스는 차단되어 있으며 승인되지 않은 호출자는 HTTP 403 오류를 수신하게 됩니다.
레이어 2(인앱 OAuth): 애플리케이션 내부에서 적용되며 '어떤 사용자가 호출하는가?'라는 질문에 답합니다. 검증에 실패하면 HTTP 401 오류를 반환하며 사용자는 다시 로그인하라는 요청을 받게 됩니다.

Cloud Run IAM만으로는 최종 사용자를 구분할 수 없으므로 두 레이어가 모두 필요합니다. 아웃바운드 호출에는 최소 권한 서비스 계정을 사용합니다.

Google Cloud에 빌드 및 배포하고 Gemini Enterprise에 등록

먼저 MCP Apps SDK를 사용하여 커스텀 MCP 서버를 빌드하세요. 이 서버는 POST/mcp와 번들로 포함된 ui:// HTML 위젯을 제공해야 합니다. 또는 Google Antigravity를 사용하여 다음 시작 프롬프트로 MCP 앱을 스캐폴딩하고 배포할 수도 있습니다.

create-mcp-app 스킬(https://github.com/modelcontextprotocol/ext-apps/tree/main/plugins/mcp-apps/skills/create-mcp-app)을 사용하여 Gemini Enterprise용 MCP 앱 빌드
워크플로: [입력 데이터, 측면 패널 UI 컨트롤, 승인 또는 내보내기 작업 설명]
단일 파일 형태의 HTML 위젯, 2초 미만의 비동기 도구 응답 및 get_app_state 폴링을 지원하는 스트리밍 가능한 HTTP 백엔드(POST /mcp), Cloud Run 배포 명령어(--no-allow-unauthenticated, --no-cpu-throttling, --min-instances=1) 생성

MCP 서버 코드가 준비되면 Cloud Run에 배포하고 Gemini Enterprise에 연결합니다.

1단계: API 사용 설정 - Cloud Run, Discovery Engine, Agent Platform, 조직 정책에 필요한 API를 사용 설정합니다.
2단계: Cloud Run에 MCP 서버 배포 - (gcloud run deploy <service> --source .) 명령어를 사용하여 소스 코드로부터 MCP 서버 컨테이너를 Cloud Run에 배포합니다. 이때 --no-allow-unauthenticated, --no-cpu-throttling 옵션을 지정하여 폴링 간에 백그라운드 작업이 중단되지 않도록 하고 --min-instances=1도 지정합니다.
3단계: 호출자 역할 부여 - Discovery Engine 서비스 에이전트에 호출자 역할(roles/run.invoker)을 부여합니다(레이어 1).
4단계: OAuth 2.0 웹 클라이언트 생성 - 리디렉션 URI를 https://vertexaisearch.cloud.google.com/oauth-redirect로 설정하여 OAuth 2.0 웹 클라이언트를 만듭니다(레이어 2).
5단계: 조직 정책 및 사전 준비 사항 구성 - discoveryengine.managed.disableCustomMcpServerConnector 제약 조건을 재정의하고 시작하기 전에 사전 준비 사항을 완료합니다. 여기에는 관리자에게 roles/discoveryengine.editor 역할을 부여하고, 서버 및 OAuth 호스트의 경우에는 allowedEgressFqdns를 설정하며, 정책이 적용되는 경우에는 allowedDataSources에 custom_mcp를 추가하는 작업 등이 해당됩니다. 그런 다음 Google Cloud 콘솔에서 Gemini Enterprise > 데이터 스토어 > 데이터 스토어 만들기로 이동하여 커스텀 MCP 서버를 선택하고 커넥터를 등록합니다.

구성 필드	값
MCP 서버 URL	`https://<your-cloud-run-service>.run.app/mcp`
승인 URL	`https://accounts.google.com/o/oauth2/v2/auth`
토큰 URL	`https://oauth2.googleapis.com/token`
클라이언트 ID 및 보안 비밀	웹 OAuth 2.0 클라이언트 ID 및 보안 비밀
범위	`openid email profile`
PKCE 지원 사용 설정	선택(권장)
HTTP 기본 인증 사용	선택 해제(`invalid_client` 오류 방지)

6단계: 작업 사용 설정 - 데이터 스토어에서 작업을 사용 설정합니다. Gemini Enterprise는 MCP 서버의 도구를 작업으로 가져오지만 기본적으로 사용 중지된 상태로 둡니다. Cloud 콘솔에서 Gemini Enterprise > 데이터 스토어 > [내 MCP 데이터 스토어] > 작업으로 이동하여 '커스텀 작업 새로고침'을 클릭합니다. 이 작업은 서버에서 tools/list를 호출함합니다. 그런 다음, 모델에 표시할 도구를 선택하고 '작업 사용 설정'을 클릭합니다.

7단계: 데이터 스토어 연결 - 데이터 스토어를 앱에 연결합니다. Gemini Enterprise > 앱 > [내 앱] > 연결된 데이터 스토어 > 기존 데이터 스토어 추가로 이동하여 MCP 데이터 스토어를 선택합니다. 데이터 스토어로 연결하면 내장된 기본 어시스턴트가 기본 채팅에서 직접 MCP 도구와 UI 위젯에 액세스할 수 있습니다. '에이전트 추가'는 MCP 데이터 스토어가 아닌 외부 하위 에이전트를 추가할 때 사용하므로 이 기능은 사용하지 마세요.

직접 빌드해보기

MCP 앱은 백엔드 도구를 Gemini Enterprise의 실시간 작업공간과 페어링합니다. 채팅 프런트엔드나 사용자 인증 파이프라인을 직접 빌드할 필요 없이 Cloud Run 컨테이너 하나를 배포하고 데이터 스토어로 연결하기만 하면 Gemini Enterprise가 곧 기업의 업무를 수행하는 공간이 됩니다.

여기에서 Gemini를 사용해 보기
여기에서 Google Antigravity로 함께 빌드하기
Google Cloud에서 빌드하기: MCP 앱 사양(SEP-1865), Cloud Run, Google Cloud AI

이제 Google Antigravity에서 사용할 수 있는 Claude Opus 5.5와 Claude Sonnet 5.5

Mon, 26 Oct 2026 19:00:00 +0000

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

간단한 버그 수정을 반복하든 복잡한 마이그레이션을 계획하든, 작업의 성격에 따라 적합한 모델이 필요합니다.

개방형 생태계를 위한 노력과 개발자에게 모든 작업에 최적화된 모델을 제공하겠다는 Google Cloud의 약속에 따라, Google Cloud 고객은 이제 Google Antigravity에서 Claude Opus 5.5와 Claude Sonnet 5.5를 사용할 수 있습니다. Claude Opus 5.5는 복잡한 작업을 위해 빌드되었으며, Claude Sonnet 5.5는 더 빠르고 비용이 저렴한 보완 모델입니다.

관리자가 사용 설정하면 개발자는 모델 선택 도구에서 Claude Opus 5.5와 Sonnet 5.5를 직접 선택할 수 있습니다. 관리자는 Gemini 3.8 Flash 및 Gemini 4 Argon을 비롯한 Google의 Gemini 모델을 선택할 수도 있습니다. 이 모델은 Antigravity 2.0, Antigravity CLI, 최근 출시된 VS Code, JetBrains IntelliJ, Visual Studio용 Antigravity IDE 확장 프로그램에 적용됩니다. 이를 통해 통합된 엔터프라이즈 결제 및 보안 경계 내에서 작업에 적합한 모델을 선택할 수 있습니다.

이 게시물에서는 이러한 모델을 사용하여 Antigravity에서 빌드할 때 적용할 수 있는 두 가지 엔지니어링 패턴을 공유합니다. 구독 유형에 관계없이 Antigravity에서 지원되는 전체 모델 목록을 보려면 여기에서 문서를 확인하세요.

Antigravity의 멀티 모델 엔지니어링 패턴

동일한 에이전트 하네스 내에서 여러 모델 제품군을 사용할 수 있게 되면 지연 시간과 비용을 제어하면서 코드 품질을 개선하는 실용적인 멀티 모델 워크플로를 활용할 수 있습니다.

패턴 1: 루프 및 그래프 워크플로의 교차 모델 검증('LLM-as-a-Judge')

에이전트 루프 또는 다단계 그래프 워크플로를 빌드할 때 동일한 모델이 코드 작성과 결과물 검토를 모두 수행하게 되면 해당 모델 특유의 사각지대가 고착화될 위험이 있습니다. 서로 다른 두 모델 제품군을 하나는 구현자로, 다른 하나는 검증자(판단자)로 페어링하면 워크플로의 다음 단계로 넘어가기 전에 독립적인 검증 과정을 거칠 수 있습니다.

Antigravity에서는 이 패턴을 대화형으로 실행하거나 자동화된 하위 에이전트를 통해 실행할 수 있습니다.

모델 A로 계획 및 구현: Claude Opus 5.5 또는 Gemini 4 Argon을 사용하여 계획 모드에서 작업을 시작하고, 여러 파일에 걸친 변경사항을 설계하고 구현합니다.
모델 B로 검증: 루프를 커밋하거나 다음 단계로 넘어가기 전에, 모델을 전환하거나 CLI에서 일회성 /model 검사를 호출하여 다른 모델 제품군이 테스트 모음 및 요구사항에 따라 구현 내용을 검토하도록 할 수 있습니다.

패턴 2: 추론 모델과 Flash 하위 에이전트 페어링

복잡한 엔지니어링 작업은 몇 가지 고도의 추론 결정과 수십 가지의 대량 기계적 조회(파일 검색, 로그 grep, 린트 결과 확인, 테스트 실패 분류)를 결합하는 경우가 많습니다. 프런티어 모델에서 모든 조회를 실행하면 지연 시간과 비용이 모두 증가할 수 있습니다.

Antigravity의 하위 에이전트 맞춤설정 시스템(.agents/agents/*.md)을 사용하면 전문 하위 에이전트에 특정 모델 등급(inherit, flash 또는 pro)을 할당할 수 있습니다. 기본 세션에서 더 강력한 모델을 사용하고 있는 경우에도 활용 가능합니다.

model: inherit로 구성된 하위 에이전트는 심층 추론 하위 작업에 활성 세션 모델을 사용합니다.

model: flash로 구성된 하위 에이전트는 고속 검색, 분류, 선별 작업을 Gemini Flash 모델로 오프로드합니다.

예를 들어 .agents/agents/test-triager.md에서 빠른 로그 분류 서브 에이전트를 정의할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '---\r\nname: test-triager\r\ndescription: Runs unit tests, classifies failures, and returns a concise summary of failing assertions.\r\nmodel: flash\r\ntools:\r\n - read\r\n - edit\r\n---\r\n\r\nRun the requested test targets, classify any failures by root cause (compilation error, assertion failure, or timeout), and return a structured summary to the parent agent.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed86cd0>)])]>

그리고 .agents/agents/gemini-judge.md의 교차 모델 코드 검토자 하위 에이전트 예시는 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', "---\r\nname:cross-model-judge\r\ndescription: Independent LLM-as-a-judge verifier that audits diffs and edge cases using Gemini Pro.\r\nmodel: pro\r\ntools:\r\n - read\r\n---\r\n\r\nReview the current workspace diff against the user's requirements. Check for regressions, missing edge-case tests, and security issues. Output a pass/fail verdict with specific line references."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed852d0>)])]>

이 설정을 사용하면 빠른 테스트 및 분류 루프를 test-triager에 위임하고 cross-model-judge를 트리거하여 최종 diff를 검증할 수 있으며, 각 모델의 강점을 단일 워크플로에 결합할 수 있습니다.

시작하기

Antigravity를 사용하는 Google Cloud 고객은 이제 Claude Opus 5.5 및 Claude Sonnet 5.5를 이용할 수 있습니다.

관리자(비즈니스용 Gemini): 서드 파티 파트너 모델은 풀링된 Gemini Enterprise Standard 및 Plus 버전 월별 토큰 할당량을 사용하지 않습니다. 대신 기존 Google Cloud Billing 계정을 통해 사용한 만큼만 지불하는 방식으로 요금이 청구되므로 초과 사용량을 사용 설정해야 합니다. Google Cloud 콘솔에서 'Gemini Enterprise' > '설정' > 'AI 개발자 도구'로 이동하여 초과분 청구 및 지출 한도를 설정하고, 조직에서 사용할 파트너 모델을 승인하세요. 단계별 안내는 AI 개발자 도구 설정 구성을 참고하세요.
관리자(Gemini 플랫폼): Gemini 플랫폼에서 API를 통해 Antigravity를 사용하는 경우 파트너 모델을 사용 설정할 수도 있습니다. Model Garden에서 Claude 모델을 사용 설정하고 Anthropic 표준 약관에 동의하세요.
개발자: Antigravity 2.0, Antigravity CLI 또는 Antigravity IDE 확장 프로그램을 최신 버전으로 업데이트하고 모델 선택기를 열거나 /model을 실행하여 작업에 적합한 모델을 선택하세요. 엔터프라이즈 거버넌스 및 멀티 에이전트 구성에 관한 자세한 내용은 Google Antigravity Enterprise 문서를 확인하세요. 작업공간 상태, 열려 있는 아티팩트, 터미널 컨텍스트를 유지하면서 동일한 대화 대화목록에서 대화 중간에 활성 모델을 전환할 수 있습니다.

참고: 경량 퍼스트 파티 Gemini 모델은 백그라운드에서 상시 작동하며 컨텍스트 관리 및 요약과 같이 빈번하게 발생하는 클라이언트 측 조정 작업을 처리합니다. 이 과정에서 퍼스트 파티 토큰이 소모되며 요금이 부과될 수 있습니다.

에이전트 플러그인 빌드를 통해 배운 4가지 평가 엔지니어링 교훈

Sun, 25 Oct 2026 19:00:00 +0000

에이전트형 시스템을 빌드할 때의 진정한 과제는 시스템을 만드는 것 자체가 아니라 측정하는 일입니다.

평가 엔지니어링은 신뢰할 수 있는 AI 시스템을 빌드하기 위한 중요한 기반입니다. 에이전트의 실제 동작을 측정하기 위해 체계적이고 반복 가능한 테스트를 설정하는 것은 신뢰할 수 있는 도구를 출시하느냐 아니면 소리 없이 중단되거나 API 호출에 실패하거나 실수를 하는 도구를 내놓느냐를 결정짓는 차이가 될 수 있습니다.

저는 Google에서 수년간 평가 엔지니어링 이니셔티브를 이끌어 왔습니다. 이번에 새로 출시된 Google Cloud Developer 플러그인 개발 과정은 실제 개발자 워크플로 전반에서 이러한 핵심 원칙들을 스트레스 테스트해 볼 수 있는 실시간 테스트베드 역할을 했습니다.

새로운 플러그인을 빌드하면서 얻은 4가지 평가 교훈을 소개합니다. 이 교훈을 여러분의 빌드에 적용해 보세요.

1. 요약 대신 실행 단계 평가

에이전트를 처음 평가할 때 LLM-as-a-judge를 설정하여 에이전트의 최종 텍스트 대답을 검사하고 체크리스트를 기준으로 점수를 매겼습니다. 하지만 평가자는 에이전트가 실제로 수행한 작업이 아니라 작성한 내용만 볼 수 있기 때문에, 이러한 방식에는 근본적인 결함이 있다는 사실을 금방 깨달았습니다. Google Cloud Developer 플러그인을 위해 초기 11개 프롬프트로 구성된 평가 세트를 실행했을 때, 자동 채점기는 3개의 프롬프트에서 실패한 것으로 판정했습니다. 하지만 원시 도구 호출 로그를 열고 스크립트를 읽어 보니 플러그인이 실제로 3가지 항목을 모두 통과한 상태였습니다. 예를 들어 Cloud Run 정리 프롬프트의 경우, 기준표에 따라 실제 작업을 수행하기 전에 명령어 문법이 올바른지 먼지 확인해야 했습니다. 에이전트는 가장 먼저 gcloud help run services list를 실행했습니다. 에이전트는 작업을 제대로 수행했지만, 최종 메시지에서는 도움말 문서를 확인했다는 사실을 언급하는 대신 사용자에게 영구적인 데이터 손실 가능성을 경고하는 데 집중했습니다.

평가자는 에이전트가 요약에서 성과를 자랑하지 않았다는 이유만으로 할 일을 제대로 수행한 에이전트에게 불이익을 주었습니다. 기준표에 'X를 실행했나요?'라는 항목이 있더라도, 실제 도구 호출 궤적을 평가하지 않는다면 LLM 심사자는 추측에 의존할 수밖에 없습니다.

핵심 요약: 에이전트의 마지막 답변 내용만 보고 성능을 평가하지 마세요. 원시 실행 궤적을 평가하여 실제로 어떤 명령어가 실행, 검증, 범위 지정되었는지 확인합니다.

2. 비동기 작업을 위한 평가 설계

도구 호출 궤적을 분석할 때는 무엇을 읽느냐 못지않게 원격 분석 데이터를 어떻게 추출하느냐가 중요합니다. 에이전트 원격 분석 데이터를 평면화된 순차적 이벤트 목록으로 추출하면 도구의 동시 디스패치가 가려지게 되는데, 이는 동작 실패의 주요 원인 중 하나입니다. 최신 에이전트 하네스는 호출 배열을 사용하여 여러 도구 호출을 단일 어시스턴트 턴으로 묶어 일괄 처리하는 경우가 많습니다.

평가에서 에이전트가 환경을 검사하고 문서를 조회하도록 요청받았을 때, 하네스는 단일 tool_calls 페이로드 내에서 스킬 로드 호출과 두 개의 문서 검색을 동시에 디스패치했습니다. 스킬 활성화는 다단계 프로세스로 이루어집니다. 초기 호출에서는 짧은 실행 스텁만 반환되고 이후 차례에서 전체 요청 사항 본문이 삽입되므로, 검색을 제어해야 할 요청 사항이 시스템에서 이미 검색을 실행한 후에야 프롬프트 컨텍스트에 도달하게 됩니다.

시스템은 스킬에 전용 차례를 부여하지 않아 스킬의 안내가 에이전트의 행동에 영향을 미치지 못했습니다. 원격 분석 파이프라인이 턴 구조를 제거하고 호출을 평면 타임라인으로 병합하면 엔지니어는 개발자가 스킬에 삽입한 명확한 요청 사항을 에이전트가 왜 무시했는지 파악하느라 며칠씩 시간을 허비하게 될 것입니다.

핵심 내용: 원격 분석 추출기에서 턴 구조를 유지해야 삽입된 안내가 컨텍스트 윈도우에 반영되기 전에 클라이언트 측의 병렬 디스패치가 도구 호출을 먼저 실행하는 문제를 파악할 수 있습니다.

3. 실시간 실행과 '드라이 런'을 나란히 테스트

병렬 디스패치와 같은 하네스 특유의 문제를 파악하려면 실제 API 호출을 면밀히 검사해야 합니다. 하지만 한 가지 환경 조건에서만 에이전트를 테스트한다면 반쪽짜리 테스트에 불과합니다. 첫날부터 실시간 실행과 계획 전용 실행이라는 두 가지 조건을 나란히 실행해야 합니다. 실제 조건에서 에이전트는 실제 샌드박스 처리된 사용자 인증 정보를 가지고 실제로 명령어를 실행합니다. 이를 통해 문법이 작동하는지, 파라미터가 깔끔하게 직렬화되는지, 에이전트가 파괴적인 작업을 수행하기 전에 제약을 가하는지 확인할 수 있습니다.

실시간 실행은 2단계에서 예기치 않은 권한 오류가 자주 발생하며 테스트하려는 동작에 도달하기 전에 중단됩니다. 따라서 사용자 인증 정보를 삭제하고 에이전트에게 아무것도 실행하지 않고 무엇을 할 것인지 설명하도록 지시하는 계획 전용 조건이 필요합니다. 이렇게 하면 권한 문제라는 걸림돌이 사라져 모델의 순수한 추론 및 라우팅 의도를 명확히 파악할 수 있습니다. 가장 중요한 발견의 절반 정도는 두 실행 방식의 차이에서 얻은 결과였습니다.

예를 들어 온보딩 프롬프트 중 하나에서 프로젝트 목록 호출 시 실시간 실행이 즉시 차단되었습니다. 계획 전용 실행은 순조롭게 진행되어 조직 정책, 관리자 승인, 거버넌스를 완전히 무시하는 8,000자 분량의 계획을 생성했습니다. 실시간 실행에서는 드러나지 않았던 중대한 인지적 결함이 계획 전용 실행에서는 단 몇 초 만에 밝혀졌습니다.

핵심 내용: 실시간 평가와 계획 전용 평가를 나란히 실행합니다. 실시간 실행은 실제 실행 결과와 안전 제약 사항을 테스트하는 데 쓰이며, 계획 전용 실행은 권한 오류에 가로막히지 않고 모델 고유의 추론 능력과 라우팅 의도를 파악하는 데 유용합니다.

4. '골든 세트'를 지속 가능한 기준으로 사용

프런티어 모델 아키텍처는 몇 달 주기로 바뀌고, 에이전트 하네스는 계속해서 개선되며, 플러그인 매니페스트 표준 또한 필연적으로 진화할 것입니다. Google Cloud Developer 플러그인을 빌드할 때, Google은 이러한 비결정적 환경에 대한 평가를 지속적 통합 테스트의 일환으로 간주했습니다. 즉, 하네스, 라이브 모델, 도구가 실제 작업 환경에서 함께 작동하는 복합 스택 전체를 대상으로 스트레스 테스트를 진행했다는 의미입니다.

이 접근 방식은 최종 텍스트 출력만 보고 결과를 추측하는 대신, 에이전트의 사고 과정부터 실제 실행 명령어, 시스템을 망가뜨리지 않고 문제를 해결했는지 여부까지 전체 실행 궤적을 파악합니다. 그런 다음 이상적인 경로가 무엇인지 숙지하고 있는 실제 전문가가 선별한 '골든 세트'를 기준으로 해당 실행 결과의 점수를 매깁니다.

핵심 요약: 하네스, 모델, 플러그인을 포함한 전체 시스템이 실제 현장에서 어떻게 작동해야 하는지를 기준으로 골든 세트를 빌드합니다. 모델은 계속해서 변하지만 이러한 기준 실행은 안전망 역할을 합니다.

알림: '원샷' 데모 대신 평가 세트를 활용해야 합니다.

엔지니어들이 흔히 저지르는 실수는 제가 이른바 원샷 데모라고 부르는 방식입니다. 이는 누군가 LLM에 프롬프트를 입력하고, LLM이 완전한 3D 게임을 빌드하거나 루빅 큐브를 한 번에 맞추는 것을 지켜본 후 평가라고 부르는 경우를 말합니다. 하지만 실제로는 허황된 측정항목일 뿐입니다.

AI로 수준 높은 결과물을 만들어내려면, 평가 세트가 필요하다고 생각합니다. 평가가 없으면 팀은 말 그대로 어두운 동굴 속을 눈을 가리고 달리는 것과 같습니다. 엔터프라이즈급 에이전트를 엔지니어링한다는 것은 다단계 상호작용을 처리하고, 권한을 관리하며, '비용 절감 기회를 찾아줘'라는 요청에 따라 실수로 프로젝트를 삭제하는 것과 같은 파괴적인 결과를 방지하는 시스템의 능력을 테스트하는 것을 의미합니다.

다음 단계

에이전트 플러그인이나 MCP 서버를 빌드하는 것은 단지 시작일 뿐입니다. 실제 클라우드 인프라에서 신뢰할 수 있는 무언가를 제공하려면, 모델이 예상대로 작동하는지 확인하기 위한 훨씬 더 심도 있는 평가 작업이 필요합니다. 결국 모델의 급격한 변화 속에서도 변치 않는 가치를 지니는 것은 스트레스 테스트를 거친 평가 제품군입니다. Google Cloud Developer 플러그인 문서를 확인하거나 이 Codelab을 살펴보고 Antigravity에서 플러그인을 시작하세요.

에이전트 개발 키트 하나로 5가지 언어 지원

Wed, 21 Oct 2026 02:00:00 +0000

에이전트에 대해 이야기할 때 반드시 Python만을 의미하는 것은 아닙니다. 오늘날의 현대적인 생태계에서 에이전트는 Cloud Run에서 높은 동시 실행 성능을 갖춘 Go 마이크로서비스로 구동될 수도 있고, 브라우저 탭에서 실행되며 Chrome의 온디바이스 모델을 호출할 수도 있습니다. 하지만 여전히 많은 에이전트 프레임워크가 Python 전용 스택만을 고려하고 있습니다. 이러한 가정으로 인해 팀은 에이전트 워크로드만을 위해 Python 서비스를 가동하거나 자체 언어로 에이전트 조정 로직을 처음부터 빌드해야 합니다.

Google의 에이전트 개발 키트(ADK)는 Python, Go, TypeScript, Java, Kotlin을 폭넓게 지원하여 이러한 절충점을 없애줍니다. ADK의 각 버전은 자체 런타임 및 유형 시스템을 위해 처음부터 빌드되는 동시에 개방형 프로토콜을 통한 상호 운용성을 갖춘 통합 아키텍처를 공유합니다.

공유 기반

5가지 언어 모두가 동일한 개방형 프로토콜을 지원하기 때문에, 사용하는 언어에 따라 아키텍처가 고정되지는 않습니다. ADK에는 모든 언어로 된 모델 컨텍스트 프로토콜 클라이언트가 포함되어 있으므로 MCP 서버로 노출된 커스텀 도구를 즉시 호출할 수 있습니다.

멀티 에이전트 시스템의 경우 ADK는 Agent2Agent (A2A) 프로토콜을 지원하여 에이전트가 HTTP를 통해 원격 에이전트와 통신할 수 있도록 합니다. A2A를 통해 다양한 언어 또는 프레임워크로 작성된 에이전트가 상호 운용될 수 있습니다.

에이전트 중심 시작

시작하려면 일회성 설정 명령어를 실행하여 Google Cloud 인증을 확인하고, CLI를 설치한 다음, Antigravity, Claude Code 또는 Codex와 같은 코딩 에이전트에서 퍼스트 파티 ADK 스킬을 설정합니다.

code_block: <ListValue: [StructValue([('code', 'uvx google-agents-cli setup'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea0b450>)])]>

그런 다음 scaffold 명령어를 실행하여 A2A 엔드포인트와 Cloud Run, Gemini Enterprise Agent Runtime 또는 Google Kubernetes Engine(GKE)용 배포 구성이 포함된 작업 프로젝트를 생성합니다.

code_block: <ListValue: [StructValue([('code', '# Scaffold an ADK project (use --agent adk for Python or --agent adk_go for Go)\r\nagents-cli scaffold create my-go-agent \\\r\n --agent adk_go \\\r\n --deployment-target cloud_run \\\r\n --region us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea0a250>)])]>

Python용 ADK 및 Kotlin용 ADK 저장소는 모두 소스 트리에 에이전트 빌더 기술을 제공하며, adk.dev/llms.txt 리소스는 5개 언어 모두에서 코딩 에이전트에 주문형 API 참고 리소스를 제공합니다.

코딩 에이전트 스킬은 프로젝트를 스캐폴딩하고, MCP와 A2A는 5개의 언어 런타임을 모두 연결합니다.

각 ADK의 실습 뷰

5가지 언어의 차이를 가장 명확하게 느끼는 방법은 각 언어로 동일한 날씨 도구를 정의하고 그 설계가 런타임에 어떻게 부합하는지 확인하는 것입니다.

Python

Python용 ADK에서는 데코레이터나 스키마 빌더 클래스가 필요하지 않습니다. 일반 Python 함수를 tools 파라미터에 전달하면 ADK가 시작 시 함수의 시그니처, 유형 힌트, docstring을 검사하여 도구 선언과 Pydantic 파라미터 스키마를 자동으로 구성합니다.

code_block: <ListValue: [StructValue([('code', 'from google.adk.agents.llm_agent import Agent\r\n\r\n\r\ndef get_weather(city: str) -> dict:\r\n """Retrieves the current weather report for a specified city.\r\n\r\n Args:\r\n city (str): The name of the city for which to retrieve the weather report.\r\n """\r\n return {"status": "success", "report": f"Sunny and 72F in {city}."}\r\n\r\n\r\nroot_agent = Agent(\r\n name="weather_agent",\r\n model="gemini-3.8-flash",\r\n instruction="Answer questions about the weather in a city.",\r\n tools=[get_weather],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea08910>)])]>

Python은 빠른 프로토타입 제작뿐만 아니라 ADK의 참조 구현으로서, 가장 광범위한 Google Cloud 통합 기능(BigQuery, Spanner, Bigtable)과 모델 어댑터(Gemini, Anthropic, OpenAI, LiteLLM)를 함께 제공합니다. adk eval 또는 agents-cli eval run 명령어와 함께 사용하면, 평가 도구가 지속적 통합(CI) 단계에서 골든 데이터 세트를 기준으로 에이전트의 궤적을 분석합니다. 이를 통해 프로덕션 서비스가 다른 언어로 실행되는 환경에서도 전체 시스템을 엔드 투 엔드로 테스트할 수 있습니다.

Go

Python이 실험과 평가 분야를 선도한다면, ADK for Go는 프로덕션 백엔드 엔지니어링에 가장 적합한 선택입니다.

Go 도구 함수는 agent.Context 구성과 강력한 유형의 입력 구조체를 사용합니다. functiontool.New 함수는 Go 제네릭을 사용하여 struct 태그에서 입력 및 출력 스키마를 모두 추론합니다.

code_block: <ListValue: [StructValue([('code', 'type GetWeatherArgs struct {\r\n\tCity string `json:"city" jsonschema:"The city to look up weather for."`\r\n}\r\n\r\ntype GetWeatherResult struct {\r\n\tReport string `json:"report"`\r\n}\r\n\r\nfunc getWeather(_ agent.Context, args GetWeatherArgs) (GetWeatherResult, error) {\r\n\treturn GetWeatherResult{Report: "Sunny and 72F in " + args.City}, nil\r\n}\r\n\r\nweatherTool, err := functiontool.New(functiontool.Config{\r\n\tName: "get_weather",\r\n\tDescription: "Retrieves the current weather report for a city.",\r\n}, getWeather)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea0ac90>)])]>

functiontool.New 함수는 핸들러의 시그니처에 대해 제네릭을 지원하므로, Go 컴파일러는 바이너리가 실행되기 전에 함수가 예상된 계약을 준수하는지 미리 검증해 줍니다.

Go는 Python에 이어 ADK 2.0 그래프 워크플로 런타임을 지원하는 첫 번째 언어이기도 합니다. LLM 추론과 함께 결정론적인 제어 흐름이 필요한 경우, workflow.New 함수를 사용하면 에이전트와 일반 Go 함수를 조건부 라우팅 및 병렬 단계가 포함된 방향성 그래프로 연결할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'ag, err := workflowagent.New("order_pipeline", []workflow.Edge{\r\n\t{From: workflow.Start, To: triageNode},\r\n\t{From: triageNode, To: fulfillNode, Route: workflow.StringRoute("fulfill")},\r\n\t{From: fulfillNode, To: notifyNode},\r\n})'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea08450>)])]>

Go는 Cloud Run과 GKE의 프로덕션에서 특히 뛰어난 성능을 발휘합니다. 컴파일된 Go 에이전트는 언어 VM이나 무거운 종속 항목 트리 없이 약 2MiB Google distroless 정적 기본 이미지에 가볍게 패키징됩니다. 정적 Go 바이너리는 컨테이너가 시작되는 즉시 포트에 바인딩되므로 동적 언어의 모듈 가져오기와 JVM 서비스의 JAR 압축해제 및 JIT 준비를 건너뜁니다.

일단 실행되고 나면, Go의 동시 실행 모델은 에이전트 워크로드에 자연스럽게 어우러집니다. 각 goroutine은 2KB 스택과 최소한의 스케줄링 오버헤드로 시작하므로, 단일 인스턴스에서 수천 개의 동시 스트리밍 요청과 도구 호출을 다중화할 수 있습니다. Go용 ADK에는 기본 제공되는 A2A 서버 핸들러와 OpenTelemetry 추적 기능도 포함되어 있습니다.

TypeScript

TypeScript는 JavaScript로 컴파일할 때 유형 주석을 삭제하므로 런타임 리플렉션을 사용할 수 없습니다. 대신 TypeScript용 ADK는 Zod와 페어링됩니다. z.object(…) 스키마를 FunctionTool 함수에 전달하면 TypeScript가 단일 선언에서 execute 콜백의 매개변수 유형을 정적으로 추론합니다.

code_block: <ListValue: [StructValue([('code', 'import { FunctionTool, LlmAgent } from "@google/adk";\r\nimport { z } from "zod";\r\n\r\nconst getWeatherTool = new FunctionTool({\r\n name: "get_weather",\r\n description: "Retrieves the current weather report for a city.",\r\n parameters: z.object({\r\n city: z.string().describe("The name of the city."),\r\n }),\r\n execute: async ({ city }) => {\r\n return { status: "success", report: `Sunny and 72F in ${city}.` };\r\n },\r\n});\r\n\r\nexport const rootAgent = new LlmAgent({\r\n name: "weather_agent",\r\n model: "gemini-3.8-flash",\r\n instruction: "Answer questions about the weather in a city.",\r\n tools: [getWeatherTool],\r\n});'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea09f50>)])]>

런타임 입력 검증, 모델로 전송되는 JSON 스키마, execute 콜백 내의 IDE 자동 완성은 모두 단일 정보 소스를 기반으로 유기적으로 작동합니다.

TypeScript는 ADK 2.0 그래프 워크플로 엔진에서도 실행되며 독립형 브라우저 번들도 함께 제공합니다. Node.js 서비스 외에도 페이지 수준 도구용 WebMCP와 Chrome의 온디바이스 Prompt API를 사용하여 브라우저 탭에서 직접 ADK 에이전트를 실행할 수 있습니다.

Java

Java용 ADK는 Maven, Gradle, Spring Boot를 표준으로 사용하는 팀에 적합합니다. 메서드 파라미터에 @Schema 주석을 추가하고 유연한 LlmAgent.builder() API를 사용하여 에이전트를 조합합니다.

code_block: <ListValue: [StructValue([('code', 'public class WeatherTools {\r\n public static Map<String, String> getWeather(\r\n @Schema(name = "city", description = "The name of the city")\r\n String city) {\r\n return Map.of("status", "success", "report", "Sunny and 72F in " + city);\r\n }\r\n}\r\n\r\nLlmAgent agent = LlmAgent.builder()\r\n .name("weather_agent")\r\n .model("gemini-3.8-flash")\r\n .instruction("Answer questions about the weather in a city.")\r\n .tools(FunctionTool.create(WeatherTools.class, "getWeather"))\r\n .build();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea08790>)])]>

런타임 시 러너는 RxJava를 통해 에이전트 이벤트를 반응형으로 스트리밍합니다. Java용 ADK는 로컬 테스트 및 기존 JVM 앱을 위해 Maven Dev UI 플러그인을 제공하며, Spring AI와 LangChain4j용 퍼스트 파티 브리지도 함께 지원합니다.

Kotlin

Kotlin용 ADK는 빌드 시간 안전성을 무엇보다 중요하게 여깁니다. Kotlin Symbol Processing(KSP) 컴파일러 플러그인은 빌드 시간에 @Tool 및 @Param 주석을 읽고 도구 스키마를 바이트 코드로 직접 내보냅니다.

code_block: <ListValue: [StructValue([('code', 'class WeatherTools {\r\n @Tool(\r\n name = "get_weather",\r\n description = "Retrieves the current weather report for a city.",\r\n )\r\n suspend fun getWeather(\r\n @Param("The name of the city.") city: String\r\n ): Map<String, String> = mapOf("status" to "success", "report" to "Sunny and 72F in $city")\r\n}\r\n\r\nval agent = LlmAgent(\r\n model = Gemini("gemini-3.8-flash"),\r\n name = "weather_agent",\r\n instruction = Instruction("Answer questions about the weather in a city."),\r\n tools = WeatherTools().generatedTools(),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea08b90>)])]>

도구 시그니처가 지원되지 않는 유형을 사용하거나 null을 허용하지 않는 파라미터에 기본값을 선언하는 경우, 프로덕션 환경에서 오류가 발생하기 전에 Gradle 빌드 단계에서 즉시 실패 처리됩니다. .generatedTools() 함수는 런타임 리플렉션을 사용하지 않으므로 Android R8 축소 과정에서도 코드가 유실되지 않고 그대로 유지됩니다.

이러한 제로 리플렉션 설계 덕분에 Android 기기 로컬 환경에서 전체 에이전트 루프를 실행할 수 있습니다. Spring AI 브리지와 실험용 ADK 2.0 그래프 워크플로를 포함한 JVM 서버 지원을 제공합니다. 온디바이스 환경에서 Kotlin용 ADK는 도구 호출을 위해 LiteRT-LM과 통합되며, 텍스트 생성에는 ML Kit(Gemini Nano)를 활용합니다. 또한 로컬 상태를 위한 Room 및 AppSearch, OS 수준 작업을 위한 Android AppFunctions와도 연동되며, 이 모든 기능은 네트워크 연결 없이도 작동합니다.

타협할 필요 없는 선택

ADK에서 5가지 네이티브 언어를 지원하므로, 조직 전체에서 하나의 런타임만 고집할 필요가 없습니다. ADK의 모든 버전은 MCP와 A2A를 지원하므로 시스템의 각 구성요소에 가장 적합한 언어를 선택해 사용할 수 있습니다.

Google의 ADK를 사용하여 에이전트를 빌드할 때 어떤 언어를 사용해 보셨나요? 현재 어떤 스택을 사용하고 계신지 X, LinkedIn 또는 Bluesky를 통해 알려주세요.

MCP 도구 상자 Java SDK v1.0 발표: 엔터프라이즈를 위한 에이전트형 데이터 액세스

Wed, 14 Oct 2026 13:00:00 +0000

공동 저자:
Stenal Jolly, Strategic Cloud Engineer, Google
Anubhav Dhawan, Software Engineer, Google

MCP 도구 상자 v1.0의 획기적인 발표에 이어 MCP 도구 상자 Java SDK가 공식적으로 버전 1.0에 도달했음을 발표합니다.

이번 출시를 통해 세계에서 가장 널리 채택된 엔터프라이즈 생태계 중 하나에 최고 수준의 유형 안전성 에이전트 조정 기능이 도입되었습니다. Java의 성숙한 아키텍처는 엄격한 요구사항을 충족하도록 특별히 설계되어 프로덕션 환경에서 미션 크리티컬 AI 에이전트를 안전하게 확장하는 데 필요한 높은 동시 실행성, 엄격한 트랜잭션 무결성, 강력한 상태 관리 기능을 제공합니다.

이 글에서는 Java SDK v1.0의 새로운 기능을 소개하고, 실제 사례를 살펴보며, 자체 구현을 시작하는 데 도움을 드립니다.

MCP: 범용 인터페이스

오늘날 개발자들은 통합 병목 현상이라는 복합적인 문제에 직면해 있습니다. N개의 서로 다른 AI 모델과 M개의 엔터프라이즈 데이터 소스가 있다면 N × M개의 맞춤형 커스텀 연결을 빌드하고, 보안을 유지하고, 유지보수해야 합니다. 이러한 통합 레이어의 부재로 인해 엔지니어링팀은 단편화된 임시 파이프라인 웹에 의존할 수밖에 없습니다. 그 결과 에이전트형 아키텍처를 확장하는 것은 금세 지속 불가능해지며, 민감한 엔터프라이즈 데이터베이스가 심각한 보안 취약점, 단편화된 액세스 제어, 막대한 유지보수 오버헤드에 노출됩니다.

모델 컨텍스트 프로토콜(MCP)은 파편화된 커스텀 통합 웹을 제거하여 핵심 문제를 해결합니다. AI 조정을 위한 'USB 타입-C'와 같은 범용 인터페이스 역할을 하는 MCP는 모델을 데이터 소스로부터 분리합니다. 개발자는 새로운 모델이나 데이터베이스마다 커스텀 또는 관리형 API 통합 코드를 작성하는 대신, 표준화된 단일 프로토콜에 맞게 코드를 작성합니다. 이 접근 방식을 사용하면 모든 MCP 호환 에이전트가 모든 MCP 지원 시스템과 안전하고 즉각적으로 상호작용할 수 있습니다. MCP 연결을 사용하면 개발자가 새로운 모델마다 맞춤형 통합을 빌드하지 않고도 에이전트를 실제 시스템에 연결할 수 있습니다.

Java SDK v1.0의 새로운 기능: 프로덕션 워크로드를 위해 빌드

MCP 도구 상자 Java SDK의 공개 베타를 발표했을 때 Google의 목표는 엔터프라이즈 Java 환경에 최고 수준의 유형 안전성 에이전트 조정 기능을 제공하는 것이었습니다. 그 이후로 Google은 개발자 및 오픈소스 참여자와 협력하여 API를 강화해 왔습니다.

v1.0 출시는 엔터프라이즈 워크로드에 적합한 안정적이고 하위 호환성이 보장되는 기반을 마련했습니다. v0.2 출시 이후 새롭게 추가되고 강화된 기능은 다음과 같습니다.

전송 계층 추상화 및 HttpMcpTransport: HttpMcpTransport와 함께 깔끔한 전송 계층 추상화를 도입했습니다. 이 기능은 핵심 프로토콜 로직을 기본 HTTP 클라이언트에서 분리하여 네트워크 구현을 쉽게 교체하거나 연결 풀링을 맞춤설정할 수 있도록 합니다.
분리된 클라이언트 인증: 기업 보안 규정 준수를 간소화하기 위해 이제 CredentialsProvider 및 AuthMethods 클래스를 사용하여 클라이언트 인증이 분리됩니다. 사용자 인증 정보는 모든 요청에서 비동기식으로 해결되므로 팀에서 토큰을 동적으로 새로고침하거나 자체 토큰 소스를 연결할 수 있습니다(ADC를 통한 Google OIDC는 기본 제공되며, 그 외의 모든 것은 단일 메서드 인터페이스로 구현됨).
기본 파라미터 지원: 도구 파라미터의 기본값을 네이티브로 지원하여 프롬프트 페이로드 크기를 줄이고 에이전트 안정성을 향상합니다.
바인딩된 파라미터 가지치기: 서버 측에 바인딩된 민감한 파라미터(예: tenant_id)가 이제 노출된 도구 정의에서 자동으로 제거되므로 LLM이 이를 조작할 수 없습니다.
버전 선택 및 세션 추적: 표준화된 MCP 버전 선택과 강력한 세션 추적을 통해 일관된 프로토콜 협상과 대화 상태 수명 주기를 보장합니다.
HTTP 사용자 인증 정보 노출 경고: 사용자 인증 정보가 일반 텍스트 HTTP 연결을 통해 전송되려고 할 때 런타임에 경고하는 기본 제공 감지 기능이 추가되었습니다.
일반 클라이언트 헤더 맵: 커스텀 기업 프록시 헤더, 트랜잭션 추적 ID 또는 상관관계 메타데이터를 모든 발신 요청에 쉽게 연결할 수 있습니다.

Java SDK v1.0 시작하기

MCP 도구 상자 Java SDK는 엔터프라이즈 팀이 원활하게 사용할 수 있도록 설계했습니다. pom.xml에 다음 종속 항목을 추가하기만 하면 됩니다.

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>1.0.0</version>\r\n</dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff572910>)])]>

실제 사례: 자율 교통 컨시어지

AlloyDB와 결합된 Java SDK의 강력한 기능을 알아보기 위해 엔터프라이즈 사용 사례를 살펴보겠습니다.

가상의 시외버스 네트워크인 Cymbal Transit을 소개합니다. 고객은 여행 계획을 세우기 위해 중첩된 드롭다운 메뉴를 하나하나 클릭하고 싶어 하지 않습니다. 고객은 다음과 같이 질문합니다.

"내일 아침에 뉴욕에서 보스턴으로 가야 해. 내 골든 리트리버를 데려갈 수 있을까? 그렇다면 가장 빠른 항공편을 예약해 줘."

이 질문에 답하려면 AI 에이전트가 비정형 데이터(반려동물 정책)와 정형 데이터(시간표 및 좌석 현황)를 상호 참조하고 트랜잭션(예약)을 실행해야 하며, 이 모든 과정에서 대화의 컨텍스트를 유지해야 합니다.

기반: 네이티브 임베딩이 포함된 AlloyDB 스키마

이 구현에는 AlloyDB를 사용했습니다. AlloyDB는 관계형 데이터와 고차원 벡터를 네이티브로 처리하기 때문입니다. 다음 문을 사용하여 데이터베이스 테이블을 설정하세요.

code_block: <ListValue: [StructValue([('code', "-- Enable necessary extensions for semantic search and embeddings\r\nCREATE EXTENSION IF NOT EXISTS vector;\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration;\r\n\r\n-- Table 1: Transit Policies (Unstructured Data for RAG)\r\nCREATE TABLE transit_policies (\r\n policy_id SERIAL PRIMARY KEY,\r\n category VARCHAR(50),\r\n policy_text TEXT,\r\n policy_embedding vector(768)\r\n);\r\n\r\n-- Table 2: Intercity Bus Schedules (Structured Data)\r\nCREATE TABLE bus_schedules (\r\n trip_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n origin_city VARCHAR(100),\r\n destination_city VARCHAR(100),\r\n departure_time TIMESTAMP,\r\n arrival_time TIMESTAMP,\r\n available_seats INT DEFAULT 50,\r\n ticket_price DECIMAL(6,2)\r\n);\r\n\r\n-- Table 3: Booking Ledger (Transactional Action Data)\r\nCREATE TABLE bookings (\r\n booking_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n trip_id UUID REFERENCES bus_schedules(trip_id),\r\n passenger_id VARCHAR(100),\r\n status VARCHAR(20) DEFAULT 'CONFIRMED',\r\n booking_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP\r\n);"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff571c10>)])]>

인텐트를 SQL에 매핑: `tools.yaml`

MCP 도구 상자를 사용하면 커스텀 도구를 안전하게 정의할 수 있습니다. LLM에 직접적인 데이터베이스 액세스 권한을 부여하는 대신 tools.yaml 구성을 통해 자연어 인텐트를 파라미터화된 안전한 쿼리에 직접 매핑합니다.

code_block: <ListValue: [StructValue([('code', 'kind: source\r\nname: alloydb\r\ntype: alloydb-postgres\r\nproject: my-project\r\nregion: us-central1\r\ncluster: my-cluster\r\ninstance: my-instance\r\ndatabase: postgres\r\n---\r\nkind: tool\r\nname: query-schedules\r\ntype: postgres-sql\r\nsource: alloydb\r\ndescription: Find available bus schedules between cities.\r\nparameters:\r\n - name: origin\r\n type: string\r\n description: The departure city name.\r\n - name: destination\r\n type: string\r\n description: The arrival city name.\r\n - name: limit\r\n type: integer\r\n description: Maximum number of schedules to return.\r\n default: 5\r\nstatement: |\r\n SELECT CAST(trip_id AS TEXT) AS trip_id, departure_time, ticket_price\r\n FROM bus_schedules\r\n WHERE lower(origin_city) = lower($1) AND lower(destination_city) = lower($2)\r\n ORDER BY departure_time ASC\r\n LIMIT $3'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff5703d0>)])]>

전체 YAML 파일은 mcp-toolbox-sdk-java 저장소의 tools.yaml 파일을 참고하세요.

Spring Boot의 스테이트풀(Stateful) 에이전트 아키텍처

엔터프라이즈 애플리케이션에서 대화형 AI를 빌드할 때 가장 어려운 부분은 상태 관리입니다. 사용자가 "몇 시에 예약할 수 있나요?"라고 물은 다음 "오전 8시로 예약해 주세요"라고 말하면 에이전트는 대화가 진행되는 동안 이전 컨텍스트를 기억해야 합니다.

Spring Boot 및 LangChain4j와 함께 Java MCP 도구 상자 SDK를 사용하면 HTTP 세션에서 대화 메모리를 깔끔하게 유지하고 에이전트를 두 개의 선언적 구성요소로 깔끔하게 분리할 수 있습니다.

HTTP 세션을 통해 프롬프트, 도구, 대화 메모리를 관리하는 선언적 에이전트 인터페이스입니다.
에이전트 요청을 MCP 도구 상자 서버로 직접 라우팅하는 도구 실행 서비스입니다.

code_block: <ListValue: [StructValue([('code', 'interface TransitAgent {\r\n @SystemMessage({\r\n "You are the Cymbal Transit Concierge.",\r\n "Use the \'querySchedules\' tool for finding schedules.",\r\n "Use \'bookTicket\' to execute transactions.",\r\n "Use \'searchPolicies\' to look up luggage and pet rules."\r\n })\r\n String chat(@MemoryId String sessionId, @UserMessage String userMessage);\r\n}\r\n\r\n@Service\r\nclass TransitAgentTools {\r\n // These methods automatically invoke our MCP Toolbox server!\r\n @Tool("Query specific schedules between an origin and destination city.")\r\n public String querySchedules(String origin, String destination) { ... }\r\n\r\n @Tool("Book a ticket for a passenger.")\r\n public String bookTicket(String tripId, String passengerName) { ... }\r\n\r\n @Tool("Search transit policies for luggage and pet rules.")\r\n public String searchPolicies(String query) { ... }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff5700d0>)])]>

@MemoryId 주석이 세션 추적을 어떻게 추상화하는지 확인하세요. Spring Boot는 대화 컨텍스트를 사용자의 HTTP 세션에 자동으로 연결합니다. 한편 LangChain4j와 MCP 도구 상자는 백그라운드에서 스키마 변환과 도구 라우팅을 처리하므로 수동으로 if/else 인텐트 파싱을 작성할 필요가 없습니다.

MCP 도구 상자 Java SDK를 LangChain4j와 결합하면 관심사를 명확하게 분리하고 상태를 손쉽게 관리할 수 있습니다.

상용구 없는 세션 관리: @MemoryId String sessionId 파라미터는 대화 기록을 사용자의 HTTP 세션에 직접 바인딩합니다.
선언적 에이전트 계약: TransitAgent 인터페이스는 복잡한 프롬프트 템플릿 없이 모델의 페르소나와 시스템 요청 사항을 정의합니다.
유형 안전성 도구 실행: TransitAgentTools Spring 서비스는 원격 MCP 데이터베이스 도구를 네이티브 Java 메서드로 래핑합니다.

이 아키텍처는 에이전트의 모듈성을 유지합니다. 인터페이스에서 프롬프트 가이드를 미세 조정하고, 사용자 세션을 자동으로 관리하며, 긴밀한 결합 없이 MCP 도구 상자를 통해 안전한 데이터베이스 쿼리를 실행할 수 있습니다.

전체적 그림 보기: Java v1.0에서 도구 나열, 호출, 실행

이제 TransitAgentTools 인터페이스를 자세히 살펴보겠습니다. Spring @Service의 LangChain4j @Tool 메서드 내에서 MCP 도구 상자 Java SDK는 Java 서비스 메서드를 tools.yaml 파일에 정의된 MCP 도구에 연결하는 까다로운 작업을 처리합니다. 몇 줄의 유형 안전성 코드로 새로운 v1.0 분리된 인증 및 헤더 추상화를 사용하여 클라이언트를 초기 설정할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '// 1. Initialize the Client with Decoupled Auth and Custom Headers (v1.0)\r\nString serviceUrl = "https://toolbox-my-project-uc.a.run.app/mcp";\r\nMcpToolboxClient mcpClient = McpToolboxClient.builder()\r\n .baseUrl(serviceUrl)\r\n .credentialsProvider(new GoogleCredentialsProvider(serviceUrl)) // Decoupled OIDC credentials\r\n .headers(Map.of( // Generic client headers\r\n "X-Correlation-ID", "enterprise-session-abc123",\r\n "X-Client-Platform", "Spring-Boot"\r\n ))\r\n .build();\r\n\r\n// 2. Listing Discoverable Tools\r\nmcpClient.listTools().thenAccept(tools -> {\r\n System.out.println("Successfully discovered " + tools.size() + " tools.");\r\n});\r\n\r\n// 3. Invoking a Tool (Read-Only Data with Default Parameter Support)\r\n// "limit" is omitted: the SDK fills it from the default in the tool definition\r\nString schedules = mcpClient.loadTool("query-schedules")\r\n .thenCompose(tool -> tool.execute(Map.of(\r\n "origin", "New York",\r\n "destination", "Boston")))\r\n .join().text();\r\n\r\n// 4. Executing a Transactional Tool (Using Bound Parameters)\r\nAuthTokenGetter toolAuthGetter = () -> CompletableFuture.completedFuture(myIdToken);\r\n\r\nString bookingConfirmation = mcpClient.loadTool("book-ticket", Map.of("google_auth", toolAuthGetter))\r\n // Bind the authenticated user context securely. bindParam returns a new immutable\r\n // Tool, and the bound parameter is pruned from the definition exposed to the LLM!\r\n .thenCompose(tool -> tool.bindParam("passenger_name", "Jane Doe")\r\n // Execute the mutable transaction\r\n .execute(Map.of("trip_id", "123e4567-e89b-12d3-a456-426614174000")))\r\n .join().text();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafef4de50>)])]>

보안을 우선으로 하는 기본 설정: 인증 및 배포

AI 에이전트를 프로덕션으로 이전하려면 견고한 사용자 인증 정보 처리와 수요에 따라 확장가능한 인프라가 필요합니다. 다양한 환경에서 사용자 인증 정보 보안을 적용하고 Cloud Run에 독립적으로 배포하는 방법을 살펴보겠습니다.

애플리케이션 기본 사용자 인증 정보(ADC) 및 안전

GoogleCredentialsProvider 서비스를 사용하면 Java 앱이 애플리케이션 기본 사용자 인증 정보(ADC)를 통해 실행 환경(로컬 또는 Google Cloud)에서 보안 ID를 상속합니다. 하드 코딩된 키가 필요 없으며, OIDC 토큰이 잠재고객별로 생성되고 캐시됩니다. 또한 v1.0은 사용자 인증 정보가 일반 텍스트 HTTP 연결을 통해 전송되려고 할 때 이를 자동으로 감지하고 HTTPS로 전환하라는 런타임 경고를 내보내는 HTTP 사용자 인증 정보 노출 경고를 제공합니다.

Cloud Run에 Fleet 배포

MCP 도구 상자와 Spring Boot 에이전트는 완전히 분리되어 있으므로 Google Cloud Run에서 독립적으로 확장되어 높은 동시 실행성 및 스테이트풀(Stateful) 대화 요구사항을 충족합니다.

Cloud Run에서 도구 상자를 설정하고 구성하려면 오픈소스 데이터베이스용 MCP 도구 상자를 다운로드한 다음 배포 가이드를 따르세요.

지금 시작하기

MCP 도구 상자 Java SDK v1.0을 사용하면 엔터프라이즈 Java팀이 Spring Boot 및 LangChain4j 에이전트를 도구 상자 서버에 연결하고, 이를 통해 AlloyDB 및 지원되는 다른 모든 데이터 소스에 연결할 수 있습니다. 도구 상자를 사용하면 인수가 JVM을 벗어나기 전에 도구 정의에 따라 검증되고, 인증이 분리되며, 모든 발신 요청에 커스텀 헤더가 연결됩니다. 다음 구현 단계를 참고하여 시작하세요.

1단계: 종속 항목 추가

SDK로 빌드를 시작하려면 Maven 프로젝트의 pom.xml 파일에 다음 종속 항목을 추가합니다.

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>1.0.0</version>\r\n \r\n </dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafef4f9d0>)])]>

2단계: 리소스 및 데모 살펴보기

GitHub 저장소: 데이터베이스용 MCP 도구 상자와 상호작용하기 위한 Java SDK
공식 문서: 데이터베이스용 MCP 도구 상자

데모 애플리케이션: MCP 도구 상자용 Java SDK v1.0의 최신 버전을 체험해 보려면 샘플 애플리케이션인 Cymbal Transit 프로젝트를 사용해 보세요.

Gradle 구현

팀에서 Maven 대신 Gradle을 사용하는 경우 이 종속 항목을 변환해야 합니다.

code_block: <ListValue: [StructValue([('code', "implementation 'com.google.cloud.mcp:mcp-toolbox-sdk-java:1.0.0'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafef4f810>)])]>

자동 버전 추적

이 설정을 자동화된 내부 저장소에 복사하는 경우 XML 주석 를 그대로 유지합니다. 이는 출시 관리자의 배포 스크립트에서 버전을 자동으로 올리는 데 필요합니다.

이제 안정적인 MCP 도구 상자 Java SDK를 사용하여 최신 에이전트형 도구와 서버를 엔터프라이즈 Java 애플리케이션에 통합할 수 있습니다. 지금 바로 시작해 보세요.

AI 추론 모델 서빙을 위한 네트워킹 - GKE 전용 및 기타 모든 백엔드

Tue, 13 Oct 2026 19:00:00 +0000

많은 기업과 개별 개발자는 여러 AI 추론 모델을 실행합니다. 적절한 아키텍처를 구축하면 모델 호출 방식을 간소화하면서도 중앙 집중식 거버넌스를 제공할 수 있습니다. 이 게시물에서는 AI 추론 모델 서빙 네트워킹에 중점을 둔 두 가지 참조 아키텍처를 살펴봅니다. 하나는 Google Kubernetes Engine(GKE)용이고, 다른 하나는 그 외의 모든 백엔드 유형용입니다. 나중에 살펴볼 참조 아키텍처 간의 공통점을 먼저 살펴보겠습니다. 그런 다음 GKE 백엔드 아키텍처의 고유한 구성요소를 살펴보고, 마지막에는 모든 백엔드 유형의 아키텍처 요소를 살펴봅니다.

진입점

추론 호출을 위한 프런트엔드 역할을 하는 안정적이고 안전하며 신뢰할 수 있는 진입점을 통해모델 배포를 노출할 수 있습니다. 이 진입점은 정책, 보안, 로직을 적용할 수 있는 제어 영역 역할도 합니다. Cloud Load Balancer와 추론 게이트웨이 모두 진입점 기능을 제공합니다. 이러한 유형의 엔드포인트를 사용하면 TLS를 통해 보안 연결을 종료하고, API 관리 구성요소와 통합하며, 서비스 확장 프로그램을 통해 기능을 확장하고, Model Armor의 기능을 이용해 보안을 강화할 수 있습니다.

설계에 포함되는 일반적인 서비스

두 참조 설계 모두 다음 서비스를 사용합니다.

Private Service Connect 추론 엔드포인트: 소비자 Virtual Private Cloud(VPC) 네트워크 내에 진입점을 고정합니다. 트래픽이 비공개 내부 IP 주소로 전송되기 때문에 추론 호출이 비공개 네트워크를 벗어나지 않습니다.
Apigee API 관리(선택사항): Apigee 확장 프로그램 프로세서 콜아웃을 통해 통합되어, 요청이 컴퓨팅 리소스에 도달하기 전에 클라이언트 본인 인증, 비율 제한과 할당량 적용을 처리합니다.
Model Armor: 인라인 AI 안전 체크포인트 역할을 하여, 프롬프트와 완료된 출력을 검사해 프롬프트 인젝션 및 민감한 정보 유출 여부를 확인합니다.

GKE에서만 서빙되는 설계 패턴

이 섹션에서는 GKE 전용 백엔드 설계를 중점적으로 다룹니다. 전체 엔드 투 엔드 개념을 이해하려면 아키텍처 문서인 GKE에서의 AI 추론 모델 서빙을 위한 네트워킹 전문을 읽어보세요. 설계 패턴은 다음 다이어그램을 기반으로 합니다.

GKE 설계에서는 이전 섹션에서 확인한 공통 서비스 외에 다음 구성요소도 사용합니다.

GKE Inference Gateway: 내부 애플리케이션 부하 분산기(gke-l7-rilb)로 배포됩니다. 이 기능은 수신 요청 페이로드를 파싱하고, HTTPRoute 규칙을 평가하며, 쿼리를 적절한 모델 서빙 대상으로 유도하는 특수한 인그레스 엔진 역할을 합니다.
추론 풀: 동일한 모델의 복제본을 포함하는 논리적 그룹입니다. 게이트웨이가 프롬프트를 수신하면 HTTPRoute 규칙을 평가하여 모델 식별자를 기반으로 적절한 추론 풀을 선택합니다. 풀에는 초기 크기가 있으며, 동적으로 자동 확장되도록 구성할 수 있습니다.
모델 복제본 세트: 단일 노드 또는 다중 노드 GPU나 TPU 노드 풀에 배포된 개별 모델 복제본(추론 서버 인스턴스)입니다. 복제본 세트는 이러한 모델 복제본의 균일한 그룹을 나타냅니다.

트래픽 흐름 GKE 예시

이 GKE 기반 아키텍처를 사용하여 백엔드 모델을 호출하는 클라이언트 애플리케이션은 다음과 같은 흐름을 따르게 됩니다.

인그레스: 소비자 VPC의 클라이언트 애플리케이션이 로컬 Private Service Connect 엔드포인트에 OpenAI 호환 API 호출을 실행하여, 리전 내부 애플리케이션 부하 분산기를 통해 GKE Inference Gateway로 직접 라우팅합니다.
페이로드 검사: 게이트웨이가 요청 본문에 지정된 대상 모델 파라미터를 읽고 이를 HTTP 헤더에 추가합니다.
컨트롤 플레인 검증: Apigee를 사용하는 경우 이 기능이 클라이언트 사용자 인증 정보와 할당량을 확인합니다. Model Armor는 프롬프트에서 정책 위반 또는 데이터 유출 여부를 검사합니다.
백엔드 선택: 게이트웨이는 HTTPRoute 매핑을 평가하여 대상 풀을 식별하고, 공유 접두사 캐시 컨텍스트를 일치시키고, 실시간 Prometheus 데이터를 기반으로 부하가 가장 낮은 GPU 또는 TPU 복제본으로 라우팅합니다.
이그레스: 복제본이 추론 워크로드를 실행합니다. 출력 토큰은 Model Armor를 통과하여 최종 응답 검증을 거친 후 비공개 연결을 통해 다시 스트리밍됩니다.

모든 백엔드에서 서빙되는 설계 패턴

이 섹션에서는 추론에 사용할 수 있는 여러 백엔드 유형을 중점적으로 다루며, 다음 다이어그램을 통해 아키텍처 개요를 제공합니다. 전체 엔드 투 엔드 개념을 이해하려면 아키텍처 문서인 모든 백엔드에서의 AI 추론 모델 서빙을 위한 네트워킹 전문을 읽어보세요.

GKE, Cloud Run, Agent Platform, 온프레미스 데이터 센터 또는 외부 클라우드 같은 혼합 환경에 걸쳐 있는 아키텍처에는 다음과 같은 추가 구성요소가 사용됩니다.

리전 내부 애플리케이션 부하 분산기: 라우팅 로직, SSL 종료, Service Extensions 콜아웃을 관리하는 중앙 레이어 7 라우팅 프록시 역할을 합니다.
추론 페이로드 프로세서(Service Extensions): GKE Inference Gateway에서 사용하는 본문 기반 라우팅과 유사하지만, 애플리케이션 부하 분산기에서 이 기능을 사용 설정하려면 서비스 확장 프로그램이 필요합니다. 가벼운 Cloud Run 콜아웃이 수신되는 OpenAI API 요청의 JSON 본문을 검사하고, 대상 모델 식별자를 추출하고, X-Gateway-Model-Name 헤더를 작성하여 URL 맵 라우팅을 수행합니다.
네트워크 엔드포인트 그룹(NEG): 삽입된 모델 헤더를 기반으로 이기종 백엔드에 대한 유연한 라우팅을 제공합니다.

모든 백엔드 트래픽 흐름 예시

이 아키텍처를 사용하여 백엔드 모델을 호출하는 클라이언트 애플리케이션은 다음과 같은 흐름을 따르게 됩니다.

비공개 인그레스: 클라이언트 애플리케이션은 비공개 IP 주소 공간을 통해 Private Service Connect 엔드포인트를 타겟팅합니다. 리전 내부 애플리케이션 부하 분산기가 요청을 수신합니다.
모델 이름 추출: 부하 분산기가 페이로드를 Cloud Run 본문 기반 라우터 콜아웃으로 전송하면 콜아웃이 JSON 페이로드를 검사하고 X-Gateway-Model-Name 헤더를 삽입합니다.
정책 및 안전 시행: 요청이 Apigee로 전달되어 신원 및 할당량 검증을 거친 후, Model Armor로 전달되어 민감한 정보를 삭제하고 악성 프롬프트를 차단합니다.
NEG 라우팅: 부하 분산기 URL 맵이 모델 헤더를 검사한 후 일치하는 백엔드 NEG(Agent Platform, GKE, Cloud Run, 하이브리드 또는 인터넷)로 요청을 전달합니다.
비공개 전송: 대상 백엔드가 모델 프롬프트를 실행하면 Model Armor가 완성된 결과물을 검사하고, 검사 결과가 인그레스 경로를 통해 비공개로 반환됩니다.

다음 단계

Google Cloud에서 AI 워크로드를 빌드하는 방법을 자세히 알아보세요.

문서 세트: 에이전트 AI 아키텍처 가이드
아키텍처 센터: Google Cloud의 멀티 에이전트 비공개 네트워킹 패턴
문서: Gemini Enterprise Agent Platform 네트워킹 액세스 개요

질문이 있거나, 자세한 내용이 궁금하거나, 의견을 공유하고 싶으신가요? Linkedin을 통해 Google Cloud에 문의하세요.

GKE CPU 시작 부스트: 과도한 프로비저닝 없는 앱 시작 가속화

Tue, 13 Oct 2026 02:00:00 +0000

갑작스러운 트래픽 급증에 대응하여 마이크로서비스를 시작하거나, 새로운 소프트웨어 버전을 배포하거나, 애플리케이션 복제본을 확장하는 등의 경우, Google Kubernetes Engine(GKE)에서 실행 중인 애플리케이션에 신속하고 반응성이 뛰어난 사용자 환경을 제공하려면 포드 시작 시간이 중요합니다.

하지만 플랫폼 엔지니어와 개발자는 애플리케이션이 안정 상태에서 작동할 때보다 시작 시 훨씬 더 많은 CPU 성능을 요구할 때가 많다는 고질적인 딜레마에 직면해 있습니다. 안정 상태의 일반적인 사용량에 맞춰 CPU 요청량을 설정하면 실행 시 CPU 제한이 발생하여 콜드 스타트가 느려지고 준비 여부 프로브에서 제한 시간 초과가 발생할 수 있습니다. 반대로, 단기적인 시작 버스트를 충족하기 위해 기본 CPU 요청을 과도하게 프로비저닝하면 귀중한 컴퓨팅 리소스가 낭비되고 인프라 비용이 증가합니다.

오늘 GKE용 CPU 시작 부스트 프리뷰 버전을 발표하게 되어 기쁩니다. CPU 시작 부스트는 GKE의 수직형 포드 자동 확장 처리(VPA)에 바로 통합되어 초기 설정 중에는 컨테이너의 CPU 할당량을 동적으로 높이고 애플리케이션이 준비되면 기준이 되는 안정 상태 수준으로 원활하게 다시 축소합니다. 이 모든 과정에서 컨테이너를 다시 시작할 필요는 없습니다.

현대화된 애플리케이션 부팅 시 추가 CPU가 필요한 이유

새 컨테이너가 시작되면 사용자 요청을 처리하기 전에 리소스 집약적인 초기 설정 작업을 수행하는 경우가 있습니다. 사용하는 기술 스택에 따라 다르지만 다음과 같은 시작 워크로드에는 상당한 CPU 주기가 필요합니다.

Java JVM 애플리케이션: Spring Boot와 같은 프레임워크는 클래스 로드, 클래스 경로 스캔, 종속 항목 삽입 컨테이너 인스턴스화, 적시(Just-In-Time) 컴파일 실행을 위해 높은 CPU 버스트 용량이 필요합니다.
Node.js 서버: 앱은 초기 실행 시 JavaScript 파일을 파싱하고 복잡한 모듈 종속 항목 트리(require/import)를 빌드하며 V8 엔진 최적화 및 JIT 컴파일 패스를 실행합니다.
Python 및 AI/ML 마이크로서비스: 이러한 서비스는 초기 주기를 사용하여 PyTorch, NumPy, LangChain과 같은 대규모 라이브러리를 가져오고, .pyc 바이트 코드를 컴파일하고, ORM 데이터베이스 스키마를 설정하고, 캐시 구조를 사전 로드합니다.

CPU 요청 규모를 안정 상태의 성능에만 맞춰 설정하면 이러한 초기 설정 워크로드가 시작 시 CPU 제한을 겪게 되어 준비 여부 프로브가 지연됩니다. 느린 콜드 스타트를 방지하기 위해 팀에서는 CPU 요청을 과도하게 프로비저닝하는 경우가 많습니다. 하지만 애플리케이션이 안정화된 후에는 추가 CPU 리소스가 유휴 상태가 되어 아무런 가치도 창출하지 못한 채 클라우드 비용만 증가시킵니다.

CPU 시작 부스트의 작동 방식

CPU 시작 부스트는 워크로드 시작 중에 일시적으로 vCPU를 '부스트'하고 초기 설정이 완료되면 자동으로 기본 수준으로 되돌려 이 문제를 해결합니다.

주요 이점:

콜드 스타트 속도 향상: 애플리케이션 초기 설정 시간을 최대 2배 단축하여 예상치 못한 트래픽 급증 시 자동 확장 반응 속도를 높입니다.
클라우드 지출 최적화: 시작 시에만 필요해 유휴 상태에 있는 용량에 비용을 지불하는 대신 실제 런타임 니즈에 맞게 안정 상태의 CPU 요청을 적정 규모로 설정할 수 있습니다.
포드 재시작 불필요: 실행 중인 컨테이너 내에서 리소스 크기가 동적으로 조정됩니다.
유연한 정책 제어: 간단한 포드 수준의 배수(예: 시작 시 CPU 2배)를 적용하거나 복잡한 멀티 컨테이너 포드에 컨테이너별로 세분화된 규칙을 정의할 수 있습니다.

내부 작동 방식: Kubernetes 인플레이스 포드 크기 조절

기존에는 포드의 리소스 요청이나 한도를 변경하려면 포드를 삭제하고 다시 생성해야 했습니다. 이 과정에서 컨테이너가 다시 시작되고 캐시가 무효화되며 노드 재스케줄링에 따른 오버헤드가 발생했습니다.

이 문제를 해결하기 위해 CPU 시작 부스트는 Kubernetes 인플레이스 포드 크기 조절(IPPR)을 기반으로 합니다.

KEP-1287을 통해 추적되는 IPPR은 동적인 인플레이스 리소스 변환 기능을 도입했습니다. IPPR은 Kubernetes 1.27에서 알파 버전으로 처음 도입되고 v1.33에서 베타로 승격되었으며 v1.35에서 정식 버전(GA)으로 전환되었습니다. 이 기능을 사용하면 Kubernetes 컨트롤 플레인과 kubelet이 컨테이너 프로세스를 다시 시작하지 않고도 실행 중인 포드의 컨테이너 CPU와 메모리 요청을 업데이트할 수 있습니다.

GKE는 VPA 내에서 IPPR을 활용하여 포드 승인 시 시작 CPU 부스트를 적용하고 준비 후에는 원활하게 단계적으로 축소합니다.

CPU 시작 부스트 작동 방식(포드 수명 주기 개요)

CPU 시작 부스트는 세 가지 단계로 작동합니다.

승인 단계: 포드를 배포하면 VPA 승인 웹훅이 생성 요청을 가로챕니다. 정책(예: 2배수 또는 +2 vCPU)에 따라 상향 조정된 CPU 요청을 계산하고 추적용 주석과 함께 이 상향된 CPU 요청을 포드 사양에 삽입합니다.
시작 단계: 부스트된 CPU 할당량으로 포드가 예약되고 초기 설정됩니다. 애플리케이션은 CPU 제한 없이 최대 속도로 클래스 로딩, JIT 컴파일, 모듈 파싱을 완료합니다.
부스트 해제 단계: 포드의 readinessProbe를 통과하고 설정된 durationSeconds 대기 시간이 경과되는 즉시 VPA 업데이터가 인플레이스 크기 조절 요청을 실행합니다. CPU 요청이 기본 수준으로 다시 낮아지며 그와 동시에 컨테이너는 중단 없이 계속 실행됩니다.

기본 요건 및 가용성

CPU 시작 부스트는 현재 GKE에서 프리뷰 버전으로 제공됩니다.

GKE 버전: Standard 및 Autopilot 클러스터의 1.36.0-gke.4447000 버전 이상
클러스터 모드: GKE Autopilot에서 기본적으로 사용 설정됩니다(VPA는 기본적으로 활성화됨). GKE Standard에서는 수직형 포드 자동 확장(VPA)이 사용 설정되어 있는지만 확인하면 됩니다.
워크로드 지원: Deployments 및 StatefulSet를 비롯한 표준 Kubernetes 컨트롤러에서 작동합니다.

시작하기: CPU 시작 부스트 구성

CPU 시작 부스트를 구성하려면 VerticalPodAutoscaler 매니페스트에 startupBoost 섹션을 추가하기만 하면 됩니다.

예시 1: 고정된 안정 상태를 사용하는 포드 수준 부스트(`updateMode: "Off"`)

안정 상태 CPU 요청은 매니페스트 정의에 고정한 상태로 VPA를 시작 부스트 용도로만 사용하려면 updateMode를 "Off"로 설정하세요.

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: java-app-startup-boost\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: java-app\r\n updatePolicy:\r\n updateMode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 2\r\n durationSeconds: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea7f5d0>)])]>

이 예시에서 GKE는 시작 중에 컨테이너의 CPU 요청을 2배 늘리고, 준비 여부 프로브 통과 후 10초간 부스트된 할당량을 유지한 다음 기본 수준으로 다시 줄입니다.

예시 2: 시작 부스트와 지속적인 VPA 자동 확장의 결합

GKE가 시작 중에 CPU를 부스트하고 시작 후에도 안정 상태의 리소스를 지속적으로 최적화하도록 하려면 updateMode를 "InPlaceOrRecreate"로 설정하세요.

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: nodejs-app-vpa\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: nodejs-service\r\n updatePolicy:\r\n updateMode: "InPlaceOrRecreate"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 3\r\n durationSeconds: 15'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafea7d290>)])]>

예시 3: 세분화된 컨테이너 수준 부스트

부팅 시 추가 CPU가 필요하지 않은 사이드카(예: Logging 에이전트 또는 서비스 메시 프록시)를 실행하는 포드의 경우 특정 앱 컨테이너를 타겟팅할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: app-container-boost\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: API-gateway\r\n updatePolicy:\r\n updateMode: "Off"\r\n resourcePolicy:\r\n containerPolicies:\r\n - containerName: "web-app"\r\n mode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Quantity"\r\n quantity: "2"\r\n durationSeconds: 5'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafe88f8d0>)])]>

클러스터에서 시작 부스트 확인

kubectl을 사용하여 GKE가 시작 부스트를 적용한 후 다시 축소했는지 확인할 수 있습니다.

1. 포드 주석 검사: vpaCpuStartupBoost 추적 주석을 확인합니다.

code_block: <ListValue: [StructValue([('code', 'kubectl get pod <POD_NAME> -o yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafe88d890>)])]>

기본 CPU 요청과 부스트된 CPU 요청을 나타내는 주석을 찾습니다.

2. 인플레이스 크기 조절 이벤트 모니터링: GKE가 준비 상태가 된 후 CPU 요청을 다시 기본 수준으로 축소했는지 확인합니다.

code_block: <ListValue: [StructValue([('code', 'kubectl get events --field-selector reason=InPlaceResizedByVPA'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbb0cda2e10>)])]>

프로덕션 워크로드 권장사항

수평형 포드 자동 확장 처리(HPA)와 함께 사용: CPU 시작 부스트와 함께 HPA를 사용하는 경우 안정적인 readinessProbe를 정의하고 durationSeconds를 짧게 유지하세요(예: 0초~10초). 이렇게 하면 HPA가 초기 설정 중 발생하는 CPU 급증을 안정 상태의 높은 부하로 오인하는 것을 방지할 수 있습니다.
GKE Capacity Buffers API로 트래픽 급증 처리: 대규모 환경에서 시작에 따른 리소스 부담을 줄이면 더 적은 수의 노드에서 더 높은 워크로드 밀도를 달성하여 전반적인 활용률을 높일 수 있습니다. 엄격한 SLO를 유지하면서 운영 오버헤드를 최소화하고 갑작스러운 트래픽 급증을 흡수하려면 GKE capacity buffers API 도입을 고려해 보세요.
GKE Autopilot 리소스 비율: GKE Autopilot에서는 포드가 유효한 CPU 대 메모리 비율을 유지해야 합니다. 기본 메모리 할당량이 시작 시 부스트된 CPU 비율을 수용할 수 있는지 확인하세요.

지금 시작하기

CPU 시작 부스트를 사용하는 GKE 사용자는 Java, Node.js, Python과 같은 CPU 집약적인 워크로드에서 매우 빠른 콜드 스타트를 구현하는 동시에 리소스 효율성을 극대화하고 클라우드 비용을 절감할 수 있다는 두 가지 이점을 모두 누릴 수 있습니다.

GKE 워크로드의 시작 속도를 높일 준비가 되셨나요?

GKE CPU 시작 부스트 문서를 살펴보세요.
GKE의 수직형 포드 자동 확장에 대해 자세히 알아보세요.
GKE 1.36.0-gke.4447000 이상을 실행하는 GKE Standard 또는 Autopilot 클러스터에서 CPU 시작 부스트를 사용해 보세요.

ADK의 그래프 워크플로: 알아야 할 모든 것

Sun, 11 Oct 2026 19:00:00 +0000

그래프 엔지니어링은 일종의 설계 작업으로, 작업을 노드로 분할하고, 에지에 연결하고, 코드, 모델 또는 사람이 다음 단계를 제어할 위치를 결정하는 과정입니다. 에이전트 개발 키트(ADK)의 워크플로는 이러한 설계를 실행 가능한 프로세스로 전환하여 함수와 에이전트가 작업을 수행하도록 합니다. 이 게시물에서는 환불 예시를 통해 단계를 동시에 실행하고, 결정을 라우팅하고, 사람의 검토를 위해 일시중지하고, 케이스 목록을 처리하는 방법을 보여줍니다. 또한 정적 그래프에서 경로를 선언해야 하는 경우와 결과가 도착하면 Python이 추가 작업을 예약하도록 해야 하는 경우를 설명합니다.

요약: ADK의 환불 워크플로를 사용하여 팬아웃 및 팬인, 결정론적 라우터 및 에이전트 라우터, 인간 참여형 일시중지, 동시 작업자, 동적 조정에 대해 알아보고, 정적 그래프를 사용해야 하는 경우와 Python이 다음에 실행할 작업을 결정하도록 해야 하는 경우를 살펴봅니다.

단일 에이전트로 시작하기

특정 에이전트에 환불 요청을 처음부터 끝까지 처리할 수 있는 도구와 안내를 제공할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'refund_agent = Agent(\r\n name="refund_agent", model=MODEL,\r\n tools=[fetch_order, fetch_payment, fetch_history],\r\n instruction="""You handle refund requests.\r\n 1. Look up the order.\r\n 2. Check the payment record.\r\n 3. Check the customer\'s refund history.\r\n 4. Deny if there\'s an open chargeback or it\'s past 30 days.\r\n Approve if it\'s under $50 and they\'ve had fewer than three\r\n refunds this year.\r\n 5. Write the customer an email explaining the decision.""",\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedc9550>)])]>

이렇게 하면 모델이 도구를 선택하고, 정책을 적용하고, 답장을 작성하는 역할을 담당하게 됩니다. 하지만 프롬프트에는 이미 세 가지 조회, 결정, 응답이라는 개별 작업이 설명되어 있습니다. 이러한 작업을 별도의 노드로 분할하면 각 작업을 어떻게 실행해야 하는지 결정할 수 있습니다.

고객이 주문을 선택하고 '환불 요청'을 클릭했다고 가정해 보겠습니다. 앱은 주문 ID를 알고 있으므로 조회 작업부터 워크플로를 시작할 수 있습니다.

동시에 독립적인 단계 실행하기

주문, 결제, 환불 내역 조회 작업에는 모두 주문 ID가 필요하지만 다른 조회 작업의 결과는 필요하지 않습니다. 프롬프트에는 이러한 작업이 순서대로 나열되어 있지만 각 작업이 완료되기까지 기다릴 이유가 없습니다. 세 가지 작업을 모두 동시에 실행할 수 있습니다.

하지만 정책 결정 작업은 성격이 다릅니다. 이 작업에는 세 가지 레코드가 모두 필요합니다. 따라서 워크플로를 세 개 경로로 분할한 다음 계속 진행하기 전에 그 결과를 결합합니다. 이 두 가지 과정을 각각 팬아웃과 팬인이라고 합니다.

ADK에서는 조회 함수가 그 자체로 노드로 사용될 수 있습니다. 중첩된 튜플을 사용하면 조회 함수가 동시에 시작되고 JoinNode가 그 결과가 도착할 때까지 기다립니다. 먼저 가져오기 및 조회 서명을 살펴보겠습니다.

code_block: <ListValue: [StructValue([('code', 'import asyncio\r\nfrom pydantic import BaseModel, Field\r\n\r\nfrom google.adk import Agent, Context, Event, Workflow\r\nfrom google.adk.events import RequestInput\r\nfrom google.adk.workflow import JoinNode, START, node\r\n\r\nasync def fetch_order(node_input: str) -> dict:\r\n ...'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedc9690>)])]>

각 조회 작업은 node_input을 통해 주문 ID를 수신하고 사전을 반환합니다. 이를 다음과 같이 연결할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'join_case = JoinNode(name="join_case")\r\n\r\nedges=[\r\n (START, (fetch_order, fetch_payment, fetch_history), join_case),\r\n]'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedcb950>)])]>

왼쪽에서 오른쪽으로 읽어보세요. 먼저 세 가지 조회 작업을 모두 시작한 다음 완료되면 join_case 작업을 계속 진행합니다.

조인은 노드 이름으로 키가 지정된 사전을 반환합니다. 다음 노드는 모델 호출 없이 node_input["fetch_order"], node_input["fetch_payment"], node_input["fetch_history"]를 읽어 결과를 수집할 수 있습니다. 자세한 내용 JoinNode 가이드를 참조하세요.

결제 조회 작업에 주문 조회의 거래 ID가 필요한 경우 두 작업은 순차적으로 실행됩니다. 프롬프트에 모든 단계가 순서대로 나열되어 있더라도 종속 항목에 따라 에지가 결정됩니다.

다음 동영상에서 팬아웃과 팬인에 대해 자세히 알아볼 수 있습니다.

ADK를 사용한 그래프 엔지니어링

도구를 노드로 변환할 때 한 가지 중요한 세부정보가 있습니다. 바로 node_input이라는 파라미터가 이전 노드의 출력을 수신합니다. 다른 이름의 파라미터는 기본적으로 ctx.state에 바인딩되므로 order_id는 ctx.state["order_id"]를 확인하고 누락된 경우 ValueError를 발생시킵니다. 여기서 str 주석은 START의 types.Content 입력을 문자열로 변환합니다.

각 요청을 적절한 워크플로로 라우팅하기

지금까지 고객은 명시적으로 환불을 요청했습니다. 더 광범위한 지원 대화에서는 먼저 고객이 원하는 것이 무엇인지 파악하고 요청을 적절한 프로세스로 전송해야 합니다. "신발 사이즈가 맞지 않아요. 다른 제품으로 보내 주실 수 있나요?"라는 요청은 교환 워크플로로, 환불 요청은 환불 워크플로로 전달되어야 합니다.

여기서 다음에 실행할 브랜치를 선택하는 노드인 라우터라는 개념이 등장합니다.

결정론적 라우터는 명시적인 규칙을 따르며, 동일한 입력에 대해 동일한 경로를 생성합니다.
비결정론적 라우터는 동일한 입력에 대해 서로 다른 브랜치를 선택할 수 있습니다.
에이전트 라우터는 모델을 사용하여 요청을 해석하므로 선택이 달라질 수 있습니다.

라우터는 워크플로에서 정의한 경로 중에서 선택합니다. 고객 지원 예시에서는 에이전트를 사용하여 고객의 의도를 파악한 다음 고정된 규칙을 사용하여 환불 정책을 적용할 수 있습니다.

에이전트 라우터를 통해 의도 파악

에이전트는 고객의 메시지를 해석하고 요청을 분류할 수 있습니다. 특정 ADK 패턴에서는 에이전트가 구조화된 카테고리를 반환한 다음 small 함수를 통해 해당 Event(route=…)를 내보내 요청을 선택한 워크플로로 전송합니다.

code_block: <ListValue: [StructValue([('code', 'Customer message → classification agent → route function\r\n ├─ REFUND → refund workflow\r\n ├─ EXCHANGE → exchange workflow\r\n └─ CLARIFY → ask a follow-up question'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedc90d0>)])]>

모델은 의도를 파악하고, 그래프는 사용 가능한 대상을 정의합니다. 요청이 명확하지 않은 경우 워크플로에서 후속 질문을 할 수 있습니다. ADK의 라우팅 샘플에서 이 패턴을 확인할 수 있습니다.

이 의도 라우터는 환불 워크플로 앞에 배치됩니다. 선택한 주문 예시의 경우 '환불 요청' 버튼을 통해 이미 의도가 확정되었으므로 해당 워크플로로 바로 진입할 수 있습니다.

결정론적 라우터를 통해 환불 정책 적용

환불 워크플로 내에서 수행되는 세 가지 조회 작업을 통해 승인, 거부, 사람의 검토 요청이라는 또 다른 결정을 내리는 데 필요한 사실 정보를 제공합니다. 이번에는 정책에 명시적인 기준이 제시되어 있으므로 함수를 통해 경로를 선택할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'def refund_policy(amount, days_ago, chargeback_open, priors):\r\n if chargeback_open or days_ago > 30:\r\n return "DENY"\r\n if amount < 50 and priors < 3:\r\n return "AUTO_APPROVE"\r\n return "MANUAL_REVIEW"\r\n\r\ndef route_refund(node_input):\r\n case = {**node_input["fetch_order"], **node_input["fetch_payment"],\r\n **node_input["fetch_history"]}\r\n route = refund_policy(case["amount_usd"], case["placed_days_ago"],\r\n case["chargeback_open"], case["prior_refunds_12mo"])\r\n return Event(output=case, route=route) # the function names the path'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedcb050>)])]>

route_refund는 레코드를 결합하고 AUTO_APPROVE, DENY, MANUAL_REVIEW 중 하나의 경로 이름으로 케이스를 반환합니다. 수동 검토는 자동 규칙을 모두 충족하지 않는 케이스를 처리합니다.

이는 결정론적 라우터입니다. 즉, 동일한 케이스 데이터는 동일한 결정을 생성하므로 모델을 호출하지 않고도 정책을 테스트할 수 있습니다.

	결정론적 라우터	에이전트 라우터
최적의 결정 근거	코드의 규칙	입력을 해석하는 모델
적합한 분야	알려진 사실 및 명시적 정책	규칙으로 포착하기 어려운 의미
예시	30일이 지난 주문 거부	교환 요청 인식
라우팅을 위한 모델 호출	없음	필수

두 라우터 모두 정의된 경로 중에서 선택합니다. 에이전트 라우터는 정적 그래프 내에 위치할 수 있습니다. 즉, 모델의 선택은 달라질 수 있지만 가능한 연결은 동일하게 유지됩니다.

자동 승인 또는 거부의 경우 다음 단계는 고객에게 결정 내용을 설명하는 것입니다. 각 경로에는 케이스 데이터를 바탕으로 답장을 작성하는 알림 에이전트가 지정됩니다. ADK는 Event(output=case, …)의 사전을 JSON 사용자 메시지 형식으로 해당 에이전트에 전달합니다.

code_block: <ListValue: [StructValue([('code', 'approve_notice = Agent(\r\n name="approve_notice", model=MODEL,\r\n instruction="Tell the customer their refund is approved and when to expect the "\r\n "money, using the case JSON you receive. Short email, warm, no fluff.",\r\n)\r\ndenial_notice = Agent(\r\n name="denial_notice", model=MODEL,\r\n instruction="Tell the customer their refund was declined and exactly why, based "\r\n "on the case JSON you receive. If it carries a reviewer_note, that is "\r\n "the reason. Short email, direct and kind. Do not invent policy.",\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedc8350>)])]>

이제 환불 워크플로에는 초기 조회부터 결정을 내리고 답장을 작성하기까지의 경로가 마련되어 있으며, 사람의 개입이 필요한 케이스를 위한 세 번째 브랜치도 포함되어 있습니다.

code_block: <ListValue: [StructValue([('code', 'workflow = Workflow(\r\n name="refund_decision",\r\n edges=[\r\n (START, (fetch_order, fetch_payment, fetch_history),\r\n join_case, route_refund),\r\n (route_refund, {"AUTO_APPROVE": approve_notice,\r\n "MANUAL_REVIEW": escalate_to_human,\r\n "DENY": denial_notice}),\r\n ],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedc8f90>)])]>

첫 번째 체인은 레코드를 가져오고, 조인하고, 정책을 적용합니다. 두 번째 체인은 라우터의 결정을 대상에 매핑합니다. 자동 결정은 알림 에이전트로 바로 전달되고, MANUAL_REVIEW는 다음에 정의할 사람의 검토를 위한 노드로 전달됩니다.

세 번째 브랜치를 실행하려면 함수 호출 이상의 것이 필요합니다. 검토자가 답변하는 데 몇 분 또는 며칠이 걸릴 수 있으므로 케이스가 대기 중인 상태에서 워크플로를 일시중지하고 사람이 결정을 내리면 계속 진행해야 합니다.

검토 노드는 대기 중인 요청을 기록하고 실행을 일시중지하는 RequestInput을 반환합니다. 이후 재개 시 rerun_on_resume=True를 설정하면 노드가 다시 실행되고, 이때 ctx.resume_inputs에서 답변을 확인할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'REVIEW = "refund:review"\r\n\r\nclass ReviewDecision(BaseModel):\r\n approve: bool = Field(description="True to refund, False to decline.")\r\n note: str = Field("", description="Why, in the reviewer\'s words.")\r\n\r\n@node(rerun_on_resume=True)\r\nasync def escalate_to_human(ctx: Context, node_input: dict):\r\n answer = ctx.resume_inputs.get(REVIEW)\r\n if answer is None: # first pass: ask, then stop\r\n yield RequestInput(\r\n interrupt_id=REVIEW,\r\n message=f"Refund ${node_input[\'amount_usd\']} on order "\r\n f"{node_input[\'order_id\']}?",\r\n payload=node_input, # what the reviewer is shown\r\n response_schema=ReviewDecision,\r\n )\r\n return\r\n # second pass: the answer is here, so route on it\r\n yield Event(output={**node_input, "reviewer_note": answer.get("note", "")},\r\n route="AUTO_APPROVE" if answer["approve"] else "DENY")'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedc9d10>)])]>

응답 스키마는 라우팅할 approve 값과 전달할 메모를 노드에 제공합니다. 검토자가 거부하는 경우 알림 에이전트는 거부 사유를 해당 케이스와 함께 수신합니다. 검토 결정과 답장을 연결하는 에지가 하나 더 있습니다.

code_block: <ListValue: [StructValue([('code', 'edges=[\r\n ...,\r\n (escalate_to_human, {"AUTO_APPROVE": approve_notice,\r\n "DENY": denial_notice}),\r\n]'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedcb4d0>)])]>

ADK는 두 가지 변형을 제공합니다. 위의 패턴은 단일 노드 패턴입니다. 즉, 노드가 다시 실행되고 request_input_rerun 샘플에서와 같이 ctx.resume_inputs를 읽습니다. 반면 request_input 샘플에서는 2노드 변형을 확인할 수 있습니다. 여기서는 하나의 노드가 RequestInput을 반환하면 검토자의 답변이 다음 노드의 node_input으로 도착하므로 해당 파일에서 ctx.resume_inputs를 찾을 수 없습니다. 아래에 링크된 컴패니언 스크립트에는 검토자의 답변을 실행 단계로 다시 전송하는 코드가 포함되어 있습니다.

Workflow 또한 노드입니다. 이 전체 환불 프로세스는 더 큰 규모의 고객 서비스 워크플로에서 하나의 단계로 통합될 수 있습니다.

케이스 배치에 동일한 단계 적용하기

이제 하나의 환불을 처리하는 프로세스가 마련되었습니다. 이미 수집된 레코드가 포함된 케이스 배치가 들어온다고 가정해 보겠습니다. 케이스마다 동일한 정책 검사가 필요하며 케이스 수는 배치마다 다릅니다. 동시 작업자를 사용하여 모든 항목에 하나의 노드를 적용할 수 있습니다.

ADK에서 parallel_worker=True를 설정하면 입력 목록의 항목당 노드가 한 번 실행되고 결과가 원래 순서대로 수집됩니다. 정책 함수를 다시 사용할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '@node(parallel_worker=True)\r\ndef review_case(node_input):\r\n # Each worker receives one case from the input list.\r\n case = node_input\r\n decision = refund_policy(\r\n case["amount_usd"], case["placed_days_ago"],\r\n case["chargeback_open"], case["prior_refunds_12mo"],\r\n )\r\n return {"order_id": case["order_id"], "decision": decision}\r\n\r\ndef collect_decisions(node_input):\r\n # This node receives the list of worker results.\r\n return {"decisions": node_input}\r\n\r\nbatch_review = Workflow(\r\n name="batch_review",\r\n edges=[(START, review_case, collect_decisions)],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedc9f10>)])]>

각 작업자는 하나의 케이스를 수신하고 collect_decisions는 결과를 목록으로 수신합니다. 별도의 JoinNode는 필요하지 않습니다. 이 플래그는 에이전트에서도 작동합니다. 예를 들어 각 케이스에 대한 설명을 작성할 수 있습니다. parallel_worker 샘플에서 두 가지 형식을 모두 확인할 수 있습니다.

여기서 수행되는 정책 계산은 규모가 작습니다. 동시 실행은 각 항목이 API 또는 모델 호출을 기다려야 하는 상황에서 더 유용하지만 입력과 결과가 이동하는 방식은 동일하게 유지됩니다.

패턴	작업 분산	출력 수집
`JoinNode`를 사용한 팬아웃	서로 다른 노드가 독립적인 작업 수행	노드 이름으로 키가 지정된 사전
동시 작업자	모든 항목에 동일한 노드 사용	입력 순서대로 나열된 목록

배치 크기는 그래프를 변경하지 않고도 조정할 수 있습니다. 고정된 프로세스 내에서도 가변적인 작업량을 처리할 수 있습니다. 실행에 대한 자세한 내용은 동시 작업자 가이드를 참조하세요.

결과에 따라 다음 단계 진행하기

환불 프로세스에는 알려진 경로가 있습니다. 배치에 더 많은 케이스가 포함되어 있거나 검토자가 답변하는 데 더 오래 걸리는 경우에도 마찬가지입니다. 하지만 일부 작업은 조사를 진행하는 과정에서 명확해집니다.

분쟁의 대상이 된 환불 프로세스에서 두 번째 거래가 드러난다고 가정해 보겠습니다. 이를 확인하는 과정에서 추가 조사가 필요한 배송 관련 문제가 제기됩니다. 이제 각 결과를 통해 후속 작업을 만들 수 있습니다. 동적 노드는 이러한 결과를 검사하고 Python에서 다음 검사를 예약할 수 있습니다.

ADK는 다른 노드를 실행하고 그 결과를 기다리는 ctx.run_node를 제공합니다. 이것이 조정에 어떤 변화를 가져오는지 살펴보기 위해 먼저 기존 환불 흐름을 다음과 같이 표현해 보겠습니다.

code_block: <ListValue: [StructValue([('code', 'HANDLERS = {\r\n "AUTO_APPROVE": approve_notice,\r\n "MANUAL_REVIEW": escalate_to_human,\r\n "DENY": denial_notice,\r\n}\r\n\r\n@node(rerun_on_resume=True)\r\nasync def refund_flow(ctx, node_input):\r\n # Step 1: fetch all three records at once.\r\n order, payment, history = await asyncio.gather(\r\n ctx.run_node(fetch_order, node_input, use_sub_branch=True),\r\n ctx.run_node(fetch_payment, node_input, use_sub_branch=True),\r\n ctx.run_node(fetch_history, node_input, use_sub_branch=True),\r\n )\r\n case = order | payment | history\r\n\r\n # Step 2: apply the refund policy — the same pure function, 0 LLM calls.\r\n decision = refund_policy(\r\n amount=case["amount_usd"],\r\n days_ago=case["placed_days_ago"],\r\n chargeback_open=case["chargeback_open"],\r\n priors=case["prior_refunds_12mo"],\r\n )\r\n\r\n # Step 3: run the chosen handler, and use its output as this node\'s output.\r\n await ctx.run_node(HANDLERS[decision], case, use_as_output=True)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedcaf50>)])]>

asyncio.gather는 조회 작업을 동시에 실행합니다. Python은 결과를 결합하고 정책을 적용한 후 선택한 핸들러를 실행합니다. use_as_output=True를 설정하면 핸들러의 결과가 두 번 출력되지 않고 상위 노드의 출력으로 사용됩니다.

동적 버전에서는 사람의 검토를 위한 노드도 조정합니다. 즉, 답변이 도착하면 ctx.run_node를 통해 선택한 알림 에이전트를 호출합니다. 전체 동적 스크립트(refund_dynamic.py)에는 이 변형이 포함되어 있습니다.

외부 그래프에는 진입점만 있으면 됩니다.

code_block: <ListValue: [StructValue([('code', 'workflow = Workflow(\r\n name="refund_dynamic",\r\n edges=[(START, refund_flow)],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fbafedc9010>)])]>

정적 버전에서는 에지 목록에 브랜치와 대상이 표시됩니다. 이 버전에서는 refund_flow를 읽어 이를 확인합니다. 동적 노드 가이드에서 이 접근 방식을 다룹니다.

사람의 검토를 위한 일시중지는 여기에서도 계속 작동합니다. 답변이 도착하면 refund_flow가 처음부터 다시 실행되지만, 완료된 ctx.run_node 호출은 세션 기록에서 기록된 출력을 반환합니다. 직접 함수 호출과 달리 조회 작업은 반복되지 않습니다. 부차적인 효과를 하위 노드 내에서 처리하면 상위 노드가 재개될 때 완료된 호출의 결과를 재현할 수 있습니다. 각 하위 노드는 자체 trace 스팬을 가져오고 use_sub_branch=True를 설정하면 동시 실행 중인 하위 노드의 이벤트가 별도의 브랜치에 유지됩니다.

이 고정된 환불 프로세스의 경우 에지 목록을 쉽게 검사할 수 있습니다. Python 버전은 위에서 설명한 조사 로직을 추가할 수 있는 공간을 제공합니다. 즉, 결과를 검사하고, 후속 노드를 선택하고, 독립적인 검사를 동시에 실행할 수 있습니다. 모델은 조사할 대상을 제안할 수 있지만, 코드는 작업 범위를 제한합니다. 예를 들어 발견 사항당 3회의 후속 조치와 사람의 검토 전 2단계의 조사를 수행합니다.

루프 또한 정적 그래프 내에서 처리할 수 있습니다. 초안 작성 → 검사 → 수정으로 이어지는 고정된 프로세스에서는 조건부 역방향 에지와 수정 횟수를 제한하는 라우터를 사용할 수 있습니다. '정적'은 가능한 연결을 설명하므로 실제 경로와 반복 횟수는 다를 수 있습니다. 조건부 순환에 대해서는 그래프 가이드에서 다룹니다.

또한 정적 워크플로 내에 동적 노드를 배치할 수도 있습니다. 그러면 필요한 단계에 Python을 사용하면서 주변 프로세스를 계속 표시할 수 있습니다.

다음에 실행할 작업을 결정할 사람 선택하기

먼저 입력이 도착하기 전에 가능한 워크플로를 그려볼 수 있나요?와 같이 질문할 수 있습니다. 이때 분기, 루프, 반복 단계를 포함해야 합니다. 각 요청이 거치게 될 구체적인 경로를 미리 예측할 필요는 없습니다.

필요한 항목	패턴
독립적인 작업 및 그 결과	팬아웃 및 팬인
고정된 규칙에 따라 선택한 브랜치	결정론적 라우터
의미를 해석하여 선택한 브랜치	에이전트 라우터
계속하기 전에 사람이 내리는 결정	`RequestInput`
목록에서 동일한 단계	동시 작업자
결과가 도착하면 작업을 예약하는 코드	동적 노드

에지 목록은 연결 관계를 명확히 보여주는 경우 사용합니다. 결과가 추가 작업을 생성하거나 Python이 제어를 더 자연스럽게 표현하는 경우 동적 조정을 사용합니다. 규모가 작은 개방형 작업에는 하나의 에이전트와 도구만 필요할 수 있습니다.

환불 워크플로에서 그래프는 조회를 조정하고, 코드는 정책을 적용하고, 사람은 예외를 처리하고, 모델은 답장을 작성합니다. 그래프 엔지니어링은 각 구성 요소에 명확한 책임을 부여하고 프로세스의 작동 방식을 더 쉽게 파악할 수 있도록 합니다.

시작하기

읽기: 워크플로 가이드
탐색: 워크플로 샘플
빌드: 이러한 패턴을 마라톤 경기 당일 코치에 적용하는 실습 Codelab

Google Cloud CLI 원격 MCP 서버로 에이전트 역량 강화

Sun, 11 Oct 2026 19:00:00 +0000

오늘 Google은 프리뷰 버전의 Google Cloud CLI 원격 MCP 서버를 새롭게 선보이며, 관리형 원격 MCP 서버 생태계를 확장합니다.

널리 사용되는 gcloud 및 bq(BigQuery) 명령줄 도구를 기반으로 하는 이 새로운 서버는 AI 에이전트가 Google Cloud 인프라를 관리하고 고급 BigQuery 워크플로를 안전하고 원활하게 처리할 수 있도록 명령줄 작업에 대한 즉각적이고 광범위한 액세스를 제공합니다.

AI 에이전트에 CLI가 중요한 이유

에이전트가 수행하는 클라우드 작업이 점점 더 복잡해지고 있지만, 백엔드 시스템과의 상호작용 방식을 표준화하는 일은 여전히 까다로운 과제로 남아 있습니다. Google Cloud CLI 원격 MCP 서버는 수백 개의 gcloud 및 bq 명령어의 다기능성을 하나의 MCP 서버로 패키징하여 이러한 격차를 해소합니다. 이를 통해 에이전트는 다음과 같은 두 가지 강력한 이점을 얻을 수 있습니다.

상위 수준 추상화: CLI 명령어는 다단계 API 조정을 요구하는 대신 복잡한 다단계 워크플로, 검증 확인, 상위 수준 작업을 통합 명령어로 패키징합니다.
모델 학습 활용: LLM은 공개 명령줄 문서, 문법, 사용 예시를 바탕으로 광범위하게 사전 학습되므로 모델에 대한 CLI 호출이 직관적이고 정확도가 높습니다.

원격 MCP 기반 CLI 활용의 장점

AI 에이전트로 클라우드 인프라를 관리하려면 일반적으로 에이전트 실행 환경 내에 Google Cloud CLI 바이너리를 설치하고 유지보수해야 합니다. Cloud CLI 원격 MCP 서버는 Google Cloud 인프라에 격리된 실행 샌드박스를 제공하여 CLI 기능과 MCP 이점을 연결합니다. 이를 통해 다음과 같은 주요 인프라 과제를 해결할 수 있습니다.

간소화된 종속 항목 및 런타임 관리: 커스텀 에이전트를 빌드하는 팀의 경우 개발, 테스트, 프로덕션 환경에서 로컬 CLI 버전과 종속 항목을 유지하는 데 운영 오버헤드가 발생합니다. 원격 MCP를 사용하면 로컬 설치와 런타임 유지보수의 번거로움이 사라집니다.
웹 기반 에이전트 엔드포인트에 대한 액세스: 웹 호스팅 에이전트 플랫폼 및 웹 인터페이스(예: Gemini Enterprise 및 기타 호스팅된 엔터프라이즈 에이전트 플랫폼)는 사용자가 로컬 패키지를 제어하거나 설치할 수 없는 환경에서 실행됩니다. 원격 MCP를 사용하면 이러한 인터페이스에서 Google Cloud CLI 작업에 안전하게 관리형 방식으로 직접 액세스할 수 있습니다.

엔터프라이즈급 보안 및 거버넌스

AI 에이전트를 인프라에 연결하려면 엄격한 엔터프라이즈급 보호 장치가 필요합니다. 이 원격 서버는 Google Cloud의 표준 ID 및 거버넌스 프레임워크를 활용하여 환경을 안전하게 보호합니다.

제로 앰비언트 사용자 인증 정보: 서버는 앰비언트 사용자 인증 정보가 없는 네트워크 제한 프록시 경계에서 실행을 격리합니다. 인증 및 승인은 에이전트 아이덴티티, OAuth 2.0, Identity and Access Management (IAM)를 통해 처리됩니다.
엄격한 정책 시행: 원격 MCP 서버를 통해 실행되는 모든 명령어는 인증된 호출자 ID의 권한으로 실행됩니다. 표준 IAM 권한과 조직 정책 서비스 제약조건 모두 다운스트림 대상 리소스에 엄격하게 적용됩니다.
Model Armor를 통한 고급 보호: AI 도구 호출과 관련된 위험을 최소화하기 위해 Cloud CLI 원격 MCP 서버는 Model Armor와 통합됩니다. LLM 프롬프트와 응답을 선제적으로 검사하여 프롬프트 인젝션 및 악성 입력과 같은 위험으로부터 보호할 수 있습니다.
Cloud 감사 로깅: Cloud CLI 원격 MCP 서버는 모든 도구 호출을 감사 로그(cloudcli.googleapis.com/mcp의 데이터 액세스 로그)에 기록하도록 구성할 수 있습니다. 보안팀은 민감한 명령어 페이로드나 개인 식별 정보(PII)를 노출하지 않고도 호출자 ID, OAuth 클라이언트, IAM 승인 결정(mcp.googleapis.com/tools.call)을 완벽하게 파악할 수 있습니다.

Google Cloud CLI 원격 MCP 서버에 연결

클라우드 관리를 에이전트에 통합할 때 더 이상 Google Cloud CLI 바이너리를 패키징하거나, 로컬 실행 런타임을 관리하거나, 에이전트 컨테이너 이미지 내에서 종속 항목을 유지할 필요가 없습니다. Google Cloud CLI 원격 MCP 서버는 표준 모델 컨텍스트 프로토콜을 구현하므로 MCP 호환 에이전트 플랫폼 또는 조정 런타임은 표준 구성을 통해 즉시 연결할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '{\r\n "mcpServers": {\r\n "google-cloud-cli": {\r\n "uri": "https://cloudcli.googleapis.com/mcp",\r\n ...\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff002d90>)])]>

에이전트는 네트워크가 격리된 안전한 클라우드 샌드박스에서 gcloud 및 bq 명령어를 실행할 수 있는 액세스 권한을 즉시 얻습니다.

인증은 호스팅된 Google Cloud 플랫폼의 경우 키 없는 에이전트 아이덴티티를 통해 처리되고, 외부 런타임의 경우 표준 OAuth 2.0을 통해 처리됩니다. 인증 옵션은 MCP 인증 가이드를 참고하세요.

에이전트에 인프라 관리 기능 제공

Cloud CLI 원격 MCP 서버는 두 가지 강력한 도구인 run_gcloud_command와 run_bq_command를 노출하여 AI 에이전트가 자연어를 통해 Google Cloud 작업에 광범위하고 즉각적으로 액세스할 수 있도록 합니다.

run_gcloud_command를 사용하여 클라우드 인프라 관리

run_gcloud_command를 사용하면 에이전트가 광범위한 gcloud 작업을 실행하여 Google Cloud 환경을 관리하고, 진단하고, 보호할 수 있습니다. 예시는 다음과 같습니다.

모니터링 가능성 및 사고 진단: 에이전트는 명령어 실행을 자동화하고 도구 간 컨텍스트 전환을 줄여 사고 진단을 간소화합니다.

run_bq_command 도구를 사용한 BigQuery 작업 확장

BigQuery MCP 서버는 이미 AI 에이전트를 통한 데이터 분석 및 탐색을 지원하고 있습니다. 여기에 run_bq_command가 도입되면서, 이제 에이전트는 bq CLI의 모든 기능을 활용해 리소스 할당, 작업 모니터링, 작업 예약과 같은 고급 BigQuery 작업을 수행할 수 있게 되었습니다. 주요 기능은 다음과 같습니다.

예약된 쿼리 자동화: 에이전트가 BigQuery Data Transfer Service 구성을 사용하여 쿼리 예약 작업을 자동으로 수행합니다.
작업 및 리소스 관리: 처리된 데이터 볼륨, 슬롯 사용량, 실행 계획을 포함한 쿼리 실행 세부정보에 대한 심층적인 인사이트를 얻고 예약을 관리합니다.
액세스 및 권한 제어: 데이터 관리자와 소유자는 에이전트를 통해 직접 테이블 권한을 검사하고 업데이트할 수 있습니다.

가격 책정 및 가용성

Google Cloud CLI MCP 서버를 오늘부터 공개 프리뷰로 만나보실 수 있습니다. MCP 서버 자체를 사용하는 데는 추가 요금이 부과되지 않습니다. 직접 생성한 GCP 리소스와 해당하는 데이터 전송 비용에 대해서만 비용을 지불하면 됩니다.

시작하려면 Google Cloud 프로젝트에서 Cloud CLI Execution API (`cloudcli.googleapis.com`)를 사용 설정하고, 에이전트 또는 사용자 ID에 필요한 MCP 도구 사용자 (`roles/mcp.toolUser`) IAM 역할을 부여하고, MCP 클라이언트가 `cloudcli.googleapis.com/mcp`에 연결되도록 구성합니다.

서버 측 Cloud Swift SDK 소개

Sun, 11 Oct 2026 19:00:00 +0000

수년 동안 Swift는 주로 Apple 클라이언트 기기와 연결된 UI 언어로 인식되었습니다. Swift 6와 엄격한 동시 실행 검사를 통해 Swift는 Rust와 유사한 데이터 경합 안전성과 예측 가능한 참조 카운트 성능을 결합하여 실행 가능한 시스템 및 클라우드 언어로 거듭났습니다.

이 생태계를 지원하기 위해 Google 엔지니어링팀은 공식 Swift용 Google Cloud API 클라이언트 라이브러리를 출시했습니다. Swift 6.2 이상을 위해 처음부터 새로 빌드된 이 새로운 SDK는 최신 비블로킹 Swift NIO 이벤트 루프, HTTP/2 멀티플렉싱, gRPC 전송, 비용이 들지 않는 컴파일 시간 데이터 경합 안전성을 사용합니다.

이 글에서는 시작하는 데 필요한 모든 정보와 서버 측 Cloud Swift SDK(google-cloud-swift)의 작동 방식을 설명합니다.

서버 측 Swift 및 클라우드 네이티브 동시 실행의 부상

기존 백엔드 개발에서는 개발자 편의성과 리소스 사용률 사이에서 절충점을 찾아야 하는 경우가 많습니다. 관리형 런타임은 빠른 개발을 가능하게 하지만, 하위 수준 시스템 언어는 메모리 및 CPU 사용량을 더 세밀하게 제어할 수 있는 반면 기능 속도가 저하되는 경우가 많습니다.

서버 측 Swift는 이 둘 사이에서 실용적인 균형을 맞추는 것을 목표로 합니다. Swift는 가벼운 런타임과 자동 참조 카운팅(ARC)을 표현력 있는 문법과 결합합니다. 무엇보다도 Swift 6에는 컴파일 시간 동시 실행 검사가 도입되었습니다. 클라우드 마이크로서비스 전반에서 비동기 태스크 간에 상태를 공유할 때 컴파일러는 유형이 Sendable을 준수하도록 강제합니다. 데이터 경합은 바이너리가 컴파일되거나 프로덕션에 도달하기 전에 편집기에서 포착됩니다.

네트워크 계층에서 Google Cloud API에 대한 모든 요청은 연결당 시스템 스레드를 생성하지 않고 멀티코어 Linux 서버 환경에서 확장되는 이벤트 기반 비차단 소켓을 통해 실행됩니다.

Swift SDK 활용 위치

서버 측 Cloud Swift SDK는 서버, 컨테이너, 자동화된 DevOps 환경을 위해 설계되었습니다.

Hummingbird 또는 Vapor와 같은 Swift 웹 프레임워크로 처리량이 높은 마이크로서비스를 빌드할 때 google-cloud-swift는 Cloud Storage, AI, Identity and Access Management(IAM) 및 100개 이상의 다른 Google Cloud 서비스에 대한 네이티브 액세스를 제공합니다. Linux에서 실행 파일을 컨테이너화하고 Cloud Run, Google Kubernetes Engine(GKE) 또는 Compute Engine VM에 직접 배포할 수 있습니다.

SDK는 macOS 및 Linux에서 컴파일되므로 원하는 개발 환경에서 백엔드를 개발한 다음 프로덕션에 원활하게 배포할 수 있습니다. 또한 프런트엔드와 백엔드 모두에서 Swift를 사용하면 애플리케이션별 유형을 두 환경에서 공유할 수 있습니다.

SDK는 플랫폼 엔지니어링과 DevOps 자동화에도 탁월합니다. 개발자 노트북 또는 CI/CD 파이프라인 내에서 실행되는 크로스 플랫폼 CLI 유틸리티와 데이터 순환 스크립트를 작성할 수 있습니다. 이러한 도구는 애플리케이션 기본 사용자 인증 정보(ADC) 또는 워크로드 아이덴티티 제휴를 사용하여 Google Cloud에 자동으로 인증합니다.

Apple App Store용 iOS, iPadOS 또는 visionOS 앱을 빌드하는 경우 google-cloud-swift를 클라이언트 번들에 직접 삽입해서는 안 됩니다. 클라이언트 바이너리 내에서 Google Cloud 서비스 계정 키 또는 관리 사용자 인증 정보를 전송하면 보안 위험이 발생합니다. 직접적인 클라이언트 측 기능의 경우 Apple 플랫폼용 Firebase SDK를 사용하여 사용자 인증, 실시간 Firestore 동기화, 클라이언트 측 보안 규칙을 처리하거나 자체 Cloud Run 백엔드 API를 통해 요청을 라우팅합니다.

IDE 및 패키지 시작하기

google-cloud-swift는 Linux와 macOS를 동등하게 지원하므로 Apple 하드웨어에서 Xcode를 사용하거나 Linux 워크스테이션에서 Visual Studio Code 및 swiftly를 사용하여 개발할 수 있습니다.

swiftly CLI 설치 프로그램을 사용하여 Linux 워크스테이션에 공식 Swift 컴파일러를 설치하려면 다음을 실행합니다.

code_block: <ListValue: [StructValue([('code', 'curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz &&\r\ntar zxf swiftly-$(uname -m).tar.gz &&\r\n./swiftly init --quiet-shell-followup &&\r\n. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" &&\r\nhash -r'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafee96f50>)])]>

또는 Ubuntu, Debian, Fedora 또는 Amazon Linux용 공식 Swift 다운로드에서 사전 빌드된 도구 모음 tarball을 직접 다운로드할 수 있습니다. google-cloud-swift에는 Swift 6.2 이상이 필요하므로 설치 후 swift --version으로 컴파일러 버전을 확인하세요.

Linux 파일 시스템에서 클론할 때 Swift Package Manager 베어 저장소 신뢰 경고를 해결하려면 git config --global safe.bareRepository all을 사용하여 빌드하기 전에 Git을 구성합니다.

필요한 패키지를 Package.swift 매니페스트에 추가하세요.

code_block: <ListValue: [StructValue([('code', 'swift package add-dependency https://github.com/googleapis/swift-google-cloud-language-v2.git --from 0.4.0\r\nswift package add-target-dependency GoogleCloudLanguageV2 CloudBackendService --package swift-google-cloud-language-v2'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed474d0>)])]>

macOS에서는 platforms 지시어를 변경해야 합니다.

code_block: <ListValue: [StructValue([('code', '// swift-tools-version: 6.2\r\nimport PackageDescription\r\n\r\nlet package = Package(\r\n name: "CloudBackendService",\r\n // Applied when compiling on Darwin/macOS; ignored by SPM on Linux targets\r\n platforms: [.macOS(.v15)],\r\n ... ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed7cb50>)])]>

대부분의 환경에서 기본 초기화된 클라이언트는 다음과 같이 요청할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'import Foundation\r\nimport GoogleCloudLanguageV2\r\n\r\nfunc analyzeTextSentiment(text: String) async throws {\r\n // Initialize explicit API key credentials\r\n let client = try LanguageServiceClient()\r\n\r\n // Configure request using structured builder closure\r\n let document = Document().with {\r\n $0.type = .plainText\r\n $0.source = .content(text)\r\n }\r\n\r\n let response = try await client.analyzeSentiment(\r\n request: AnalyzeSentimentRequest().with { $0.document = document }\r\n )\r\n\r\n if let sentiment = response.documentSentiment {\r\n print("Document sentiment score: \\(sentiment.score)")\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed7ff50>)])]>

Document().with { … }가 깔끔하고 스레드 안전한 구성 클로저를 제공하여 어떻게 장황한 임시 변수나 변경 setter를 방지하는지 주의 깊게 살펴보세요.

네트워킹, 전송, 인증

저장소는 인프라 프리미티브를 packages/ 아래의 모듈식 패키지로 분할합니다.

swift-google-cloud-auth: 애플리케이션 기본 사용자 인증 정보 검색, 서비스 계정 JWT 서명, 워크로드 아이덴티티 제휴를 위한 외부 계정 교환, API 키를 구현합니다.
swift-google-cloud-wkt: Google 프로토콜 버퍼의 잘 알려진 유형에 대한 관용적인 Swift 유형을 제공합니다. 여기에는 Swift의 Date에 깔끔하게 연결되는 나노초 정밀도의 Timestamp 표현이 포함됩니다.
swift-google-cloud-gax: 자동 재시도 루프, 지수 백오프, 페이지로 나누기 상태 머신과 같은 Google API 확장 프로그램을 처리합니다.

인수 없이 클라이언트 라이브러리를 초기화하면 Credentials.default()가 환경(GOOGLE_APPLICATION_CREDENTIALS, 할당량 프로젝트 변수 또는 로컬 Google Cloud CLI 구성)을 자동으로 스캔하고 gRPC 또는 HTTP/2를 통해 연결을 인증합니다.

API 키로 사용자 인증 정보를 프로그래매틱 방식으로 재정의하거나 커스텀 액세스 헤더를 연결해야 하는 경우 명시적 구성 옵션을 전달할 수 있습니다. 예를 들어 이전 예시를 수정하여 다음을 사용할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'import Foundation\r\nimport GoogleCloudAuth\r\nimport GoogleCloudGax\r\nimport GoogleCloudLanguageV2\r\n\r\nfunc analyzeTextSentiment(apiKey: String, text: String) async throws {\r\n // Initialize explicit API key credentials\r\n let credentials = try Credentials(configuration: .apiKey(apiKey))\r\n let client = try LanguageServiceClient(\r\n ClientOptions().with { $0.credentials = credentials }\r\n )\r\n\r\n // Configure request using structured builder closure\r\n let document = Document().with {\r\n $0.type = .plainText\r\n $0.source = .content(text)\r\n }\r\n\r\n let response = try await client.analyzeSentiment(\r\n request: AnalyzeSentimentRequest().with { $0.document = document }\r\n )\r\n\r\n if let sentiment = response.documentSentiment {\r\n print("Document sentiment score: \\(sentiment.score)")\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed7f790>)])]>

자동 생성된 클라이언트 생태계

Google Cloud는 스키마가 정기적으로 업데이트되는 방대한 API 생태계를 운영합니다. google-cloud-swift를 지원하는 팀은 코드 생성기를 사용하여 최신 기능과 새로운 API로 클라이언트 라이브러리를 자동으로 업데이트합니다. 코드 생성기를 사용하면 중단되는 브레이킹 체인지 없이 안정적인 API를 생성할 수 있습니다. 출시는 정해진 주기에 따라 이루어지지만, 특정 기능이나 API가 긴급하게 필요한 경우 Cloud Customer Care에 문의하세요.

Secret Manager에서 키를 순환해야 하거나 Gemini Enterprise Agent Platform에서 Gemini API를 통해 멀티모달 추론 모델을 호출해야 하는 경우, 생성된 SDK는 일관된 이름 지정 및 async/await 서명을 따릅니다.

이렇게 생성된 클라이언트는 일반 단항 RPC 래퍼 이상의 기능을 제공합니다. 또한 애플리케이션 개발을 간소화하는 래퍼도 제공합니다. 예를 들어 긴 결과를 반복하려면 하나의 RPC로 결과 페이지를 가져오고, 결과 페이지를 반복한 다음, 다음 페이지를 검색하기 위한 새 요청을 준비해야 합니다. 생성된 클라이언트를 사용하면 이 과정이 비동기 반복자가 됩니다. 다음 예시는 GoogleCloudSecretManagerV1을 사용하여 프로젝트 보안 비밀을 쿼리하는 방법을 보여줍니다.

code_block: <ListValue: [StructValue([('code', 'import Foundation\r\nimport GoogleCloudSecretManagerV1\r\n\r\n@main\r\nstruct SecretManagerQuickstart {\r\n static func main() async throws {\r\n guard let projectId = CommandLine.arguments.dropFirst().first else {\r\n print("Usage: SecretManagerQuickstart <projectId>")\r\n exit(1)\r\n }\r\n\r\n // Connects using Application Default Credentials automatically\r\n let client = try SecretManagerServiceClient()\r\n\r\n let request = ListSecretsRequest().with {\r\n $0.parent = "projects/\\(projectId)"\r\n }\r\n\r\n // Async sequence streams pages of secrets automatically\r\n print("Secrets in project \\(projectId):")\r\n for try await item in try client.listSecretsByItem(request: request) {\r\n print(" - \\(item.name)")\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed7ffd0>)])]>

페이지로 나눈 응답은 비동기 시퀀스(AsyncSequence)를 반환합니다. 클라이언트 라이브러리가 비차단 NIO 채널을 통해 백그라운드에서 후속 페이지를 가져오는 동안 for try await를 사용하여 항목을 반복할 수 있습니다.

다음 단계

google-cloud-swift를 사용하면 서버 측 Swift 개발자가 컴파일 시간 경합 안전, 네이티브 비동기/대기 인체공학적 API, OS 스레드 혼잡 없는 엔드 투 엔드 클라우드 인프라를 작성할 수 있습니다.

소스 코드를 검사하거나, 문제를 열거나, 새 베니어를 제공하려면 공식 저장소인 googleapis/google-cloud-swift를 방문하세요.

서버 측 Swift 아키텍처 또는 Cloud Run 컨테이너화에 대해 논의하고 싶으신가요? Google Developer Program에 가입하여 대화를 이어가세요.

저렴한 비용과 원활한 개발로 Managed Lustre 범용화

Sun, 11 Oct 2026 19:00:00 +0000

이 글은 Google Cloud가 고성능 병렬 파일 시스템의 기본 가치인 TB/s 처리량, 대규모 클라이언트 환경에서의 1밀리초 미만 지연 시간, POSIX 지원을 어떻게 더 광범위한 사용 사례와 사용자에게 제공하고 있는지 살펴보는 2부 시리즈 중 1부입니다.

이전에는 병렬 파일 시스템의 비용과 특수 목적이라는 특성으로 인해 콜드 데이터를 파일 시스템 외부에 저장해야 했고, AI 개발자들이 코드 작성, 라이브러리 컴파일, 저장소 관리를 위해 별도의 느린 환경을 유지해야 했습니다. 이러한 단편화는 수동 데이터 스테이징, 데이터 세트 복사, 분리된 네임스페이스 관리의 반복 업무를 가중시킵니다.

Google Cloud Managed Lustre는 GB당 월 6센트의 동적 등급을 통해 이러한 문제를 해결하고 다양한 개발 작업과 워크로드에 맞게 Managed Lustre 성능을 최적화하여 Managed Lustre를 고성능 AI 및 HPC 워크로드를 위한 '원스톱 솔루션'으로 만들고 있습니다.

비용 절감: 동적 등급을 통해 더 적은 비용으로 더 많은 Lustre 활용

Managed Lustre 동적 등급은 핫 데이터에 대해 1밀리초 미만의 지연 시간을 제공하므로 모든 데이터를 단일 네임스페이스에 저장할 수 있으며 비용은 GB당 월 6센트에 불과합니다.

처리량, 용량 확장, 클라이언트 확장: 처리량은 최대 80PB까지 용량에 따라 선형적으로 확장되며, 수만 명의 클라이언트로 확장해도 핫 데이터의 지연 시간은 1밀리초 미만으로 안정적으로 유지됩니다.
단일 정액 요금: 예측 가능한 가격 책정 디스크 미디어 유형, 네임스페이스 내 데이터 이동 또는 메타데이터 IOPS에 대해 별도 요금이 부과되지 않습니다.
읽기 지연 시간: 고성능 캐시(SSD)에 대해 1밀리초 미만의 지연 시간을 제공합니다. 용량 풀('HDD')은 Google Cloud Hyperdisk Throughput을 기반으로 빌드되며 평균 읽기 지연 시간은 10~30ms입니다.

동적 등급에 권장되는 워크로드

다중 에포크 학습 및/또는 최적화된 가져오기 크기를 사용한 학습: 핫 데이터는 첫 번째 실행 후 고성능 캐시(SSD)로 승격됩니다. 데이터 미리 가져오기 용량을 늘리면 동적 등급 비용 구조를 활용하고 지연 시간이 짧은 SSD의 이점을 누릴 수 있습니다.
쓰기 집약적 체크포인트: 버스트 체크포인트 쓰기가 고성능 캐시에 직접 저장됩니다. 오래된 체크포인트는 용량 풀(HDD)로 투명하게 강등됩니다.
빠른 체크포인트 복원: 새로운 체크포인트가 고성능 캐시에 기록되어 지연 시간이 짧은 체크포인트 복원이 가능합니다.
개발자를 위한 대화형 신속성: Git 클론, 라이브러리 컴파일, 노트북 실행과 같은 지연 시간이 짧은 작업은 대규모 학습 세트를 호스팅하는 동일한 공유 작업공간에서 로컬 디스크와 유사한 성능(평균 읽기 지연 시간 약 300µs)으로 활용할 수 있습니다.

원활한 개발: 개발자 워크로드를 위한 원스톱 솔루션인 Lustre

Managed Lustre는 대규모 AI 및 HPC 워크로드(체크포인트/재시작/데이터 로드)를 위한 확장성 외에도 대화형 작업에 대한 요구사항을 충족하므로, 개발자는 Managed Lustre에서 시작하여 전체 워크로드 수명 주기 동안 Managed Lustre를 계속 사용할 수 있습니다.

통합 기반 및 대화형 성능

AI 및 HPC 수명 주기를 단일 네임스페이스로 통합하여 대화형 작업에 '로컬 디스크'와 같은 사용감을 제공합니다(Salesforce 등이 경험한 Managed Lustre의 지연 시간 이점에 대해 자세히 알아보기).

지연 시간: 평균 읽기 지연 시간이 약 300µs로, 다른 분산 파일 시스템보다 최대 4배 더 나은 응답성을 제공합니다.
설정 가속화: 약 2분 만에 Linux 커널의 tar 압축을 풀고(대체 파일 솔루션보다 4.7배 빠름), 약 40초 만에 20개 작업자 병렬 git clone을 실행하고, 약 200초 만에 Python을 컴파일합니다.

동시 실행 브로드캐스트 및 클러스터 시작

Managed Lustre는 클러스터 초기화 중 스토리지 병목 현상을 방지하여 GPU ROI를 극대화합니다.

수천 개의 워커 노드가 공유 모델 체크포인트, 기본 가중치, 컨테이너 레이어와 같은 동일한 파일을 동시에 읽으려고 할 경우, 기존의 분산 파일 시스템은 국지적인 핫스팟으로 인해 병목 현상이 발생하여 고가의 GPU 클러스터가 몇 분 동안 유휴 상태로 방치될 수 있습니다.

동일한 파일을 읽는 다수의 클라이언트에 대한 집계 처리량 개선: 대체 파일 솔루션에 비해 67% 개선된 성능을 보여줍니다.
병렬 로드: PyTorch와 같은 라이브러리를 4,000개 이상의 프로세스에서 60초 이내에 가져옵니다.

원스톱 워크플로를 직접 실행해 보세요

Google이 실행한 테스트 코드로 자체 테스트를 수행해 보세요.

대화형 액세스를 위한 짧은 지연 시간

fio를 사용하여 동시성이 낮은 소규모 읽기 및 쓰기를 에뮬레이션했습니다.

1 스토리지 시스템 사양: Managed Lustre의 TiB 등급당 500MBps, 108,000GiB 용량. 102,400GiB 용량의 영역 Filestore. 동일한 40GiB 파일을 읽는 2,048개의 클라이언트 VM에 대해 평균 처리량 36.7GB/s.

code_block: <ListValue: [StructValue([('code', '# Read workload\r\nfio --ioengine=libaio --filesize=100M --ramp_time=2s \\\r\n --runtime=2m --time_based --numjobs=1 --direct=1 --verify=0 --randrepeat=0 \\\r\n --group_reporting --directory=~/LUSTRE_MOUNT \\\r\n --name=randread --blocksize=4k --iodepth=1 --readwrite=randread \\\r\n --buffer_compress_percentage=50\r\n\r\n# Write workload\r\nfio --ioengine=libaio --filesize=100M --ramp_time=2s \\\r\n --runtime=2m --time_based --numjobs=1 --direct=1 --verify=0 --randrepeat=0 \\\r\n --group_reporting --directory=~/LUSTRE_MOUNT \\\r\n --name=randwrite --blocksize=4k --iodepth=1 --readwrite=randwrite \\\r\n --buffer_compress_percentage=50'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0d2990>)])]>

빠른 설정

Linux untar 실행 방법

code_block: <ListValue: [StructValue([('code', '# Download a kernel tarball\r\nwget -P /tmp https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.18.9.tar.xz\r\n\r\n# Extract the archive to the Lustre mount\r\nmkdir ~/LUSTRE_MOUNT/kernel\r\ntar -C ~/LUSTRE_MOUNT/kernel -xf /tmp/linux-5.18.9.tar.xz'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0d1a10>)])]>

위의 사용 사례에서는 루트로 실행할 때 발생할 수 있는 메타데이터 성능 저하를 방지해야 합니다(즉, tar가 chown 및 chmod를 호출하여 추출된 파일의 소유자 및 권한을 보관 파일에 기록된 것과 일치시킴). 그래도 루트로 실행하려는 경우(그리고 이 접근 방식이 설정과 호환되는지 확인한 경우) `--no-same-owner --no-same-permissions`를 지정하여 추출된 파일이 루트를 소유자로 유지하고 루트의 기본 파일 권한을 갖도록 할 수 있습니다. 즉, 루트 권한으로 추출할 때 보관 파일의 소유자 및 권한을 무시함으로써 루트가 아닌 사용자로 추출하는 것처럼 작동하게 합니다.

Python gitclone 실행 방법

code_block: <ListValue: [StructValue([('code', 'git config --global checkout.workers 20\r\nmkdir ~/LUSTRE_MOUNT/python\r\ngit clone https://github.com/python/cpython.git ~/LUSTRE_MOUNT/python'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0d3290>)])]>

Python 컴파일 실행 방법

code_block: <ListValue: [StructValue([('code', 'pushd ~/LUSTRE_MOUNT/python\r\n./configure > /dev/null\r\nmake > /dev/null\r\npopd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafef7d7d0>)])]>

대규모 배포

하나의 대용량 파일을 여러 노드에 배포하기 위한 집계 처리량

각 클라이언트 VM에서 다음을 실행합니다.

code_block: <ListValue: [StructValue([('code', '# Start fio in server mode\r\nfio --server'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff18fad0>)])]>

선택한 클라이언트 VM에서 다음을 실행합니다.

code_block: <ListValue: [StructValue([('code', "# Create a 40 GiB file\r\nfio --name=job1 \\\r\n --ioengine=libaio \\\r\n --direct=1 \\\r\n --buffer_compress_percentage=50 \\\r\n --blocksize=4m \\\r\n --iodepth=32 \\\r\n --filesize=40g \\\r\n --readwrite=write \\\r\n --filename ~/LUSTRE_MOUNT/40gb_test\r\n\r\n# Create an fio job file for the read workload\r\ncat <<'EOF' > /tmp/read.fio\r\n[job1]\r\nfilename=${HOME}/LUSTRE_MOUNT/40gb_test\r\nrw=read\r\nbs=4m\r\nexitall_on_error=1\r\nEOF\r\n\r\n# Run the read workload using all client VMs in ~/hostfile\r\nfio --client ~/hostfile /tmp/read.fio"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafef4ca10>)])]>

여러 프로세스에서 라이브러리를 동시에 로드

선택한 클라이언트 VM에서 다음을 실행합니다.

code_block: <ListValue: [StructValue([('code', '# Install PyTorch in a virtual env\r\npython3 -m venv ~/LUSTRE_MOUNT/env\r\nsource ~/LUSTRE_MOUNT/env/bin/activate\r\npip3 install --upgrade pip\r\npip3 install torch torchvision torchaudio \r\ndeactivate\r\n\r\n# Import PyTorch on all client VMs in ~/hostfile, 4 processes per host\r\nmpirun --allow-run-as-root --oversubscribe --hostfile ~/hostfile -N 4 \\\r\n bash -c \'source ~/LUSTRE_MOUNT/env/bin/activate && python3 -c "import torch"\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed7f110>)])]>

향후 계획 및 다음 단계

Google Cloud Managed Lustre는 수동 데이터 스테이징 부담을 없애고 동적 등급으로 진입 비용을 낮춤으로써, 단일 목적의 엘리트 엔진에서 전체 AI 수명 주기를 위한 다목적 통합 스토리지 패브릭으로 진화하고 있습니다.

이 시리즈의 2부에서는 곧 출시될 객체 통합 기능을 중점적으로 다룰 예정입니다. 많은 기대 부탁드립니다.

다음 단계

벤치마크를 직접 실행해 보세요(아직 실행하지 않은 경우). Google Cloud 콘솔을 사용하여 Google Cloud Managed Lustre 인스턴스를 배포하고 위에 제공된 테스트를 실행하여 자체 워크로드를 벤치마크해 보세요.
동적 등급 살펴보기: 자세한 내용은 Google Cloud Managed Lustre 문서를 참조하세요.
2부를 기대해 주세요. 이 시리즈의 다음 편에서는 곧 출시될 객체 통합 기능과 이 기능이 AI 및 HPC 스토리지를 어떻게 더욱 간소화하는지에 대해 자세히 살펴보겠습니다.
Google Cloud Managed Lustre에서 개발부터 학습까지의 수명 주기를 중앙화하세요.

Data Agent Kit 정식 버전 출시: 모든 코딩 에이전트에 Google 데이터 클라우드 제공

Sun, 11 Oct 2026 10:00:00 +0000

오늘 Google Cloud Data Agent Kit가 정식 버전으로 출시되었습니다. Data Agent Kit는 무료로 제공되는 모델 컨텍스트 프로토콜(MCP) 도구 및 에이전트 스킬 세트로, Antigravity, Claude Code, Codex 또는 기타 인기 도구를 사용하는지 여부와 관계없이 이미 사용 중인 코딩 에이전트를 Google Cloud 데이터 제품과 직접 연동할 수 있도록 지원합니다.

정식 버전에서는 개방형 레이크하우스에 대한 BigQuery Graph, Bigtable, Managed Service for Apache Spark 액세스 지원이 추가되고, 일상 업무를 더 빠르고 원활하게 만들어 주는 수십 가지 편의 기능이 개선되었습니다.

Data Agent Kit란 무엇인가요?

코딩 에이전트가 SQL, PySpark, 파이프라인 코드를 작성하는 데 매우 능숙해졌습니다. 어떤 테이블이 존재하는지, 어떻게 파티셔닝되어 있는지, 팀에서 어떤 테이블을 신뢰하는지, 어젯밤 작업이 실패한 이유는 무엇인지 등, 환경에 대한 컨텍스트는 코딩 에이전트에 기본 제공되지 않습니다. 이러한 컨텍스트가 없으면 강력한 에이전트라도 가정을 바탕으로 작업해야 하므로, 결국 사용자가 스키마와 오류 로그를 채팅에 붙여넣어 부족한 부분을 채워야 합니다.

Data Agent Kit는 두 가지 방식으로 이 격차를 메웁니다.

MCP 도구: 15개 이상의 Google 데이터 클라우드 서비스에 연결하여 에이전트가 라이브 환경에서 스키마를 검사하고, 쿼리를 실행하고, 작업 로그를 읽고, 리소스를 관리할 수 있습니다.
Google이 만든 스킬: BigQuery SQL 최적화, Bigtable row key 설계, dbt(데이터 빌드 도구) 파이프라인 빌드와 같은 데이터 권장사항을 에이전트에 가르치는 Google Cloud 엔지니어의 오픈소스 지침입니다.

Data Agent Kit는 VS Code, Antigravity IDE, Cursor, 기타 VS Code 호환 편집기용 IDE 확장 프로그램, Antigravity 2.0, Antigravity CLI, Claude Code, Codex용 플러그인, 또는 사전 설치되어 제공되는 Cloud Shell 및 Cloud Workstations 등 이미 사용 중인 환경에서 바로 사용할 수 있습니다. 또한 IDE 확장 프로그램은 Google Cloud 콘솔의 경량 버전을 편집기에 제공하므로 창을 전환하지 않고도 데이터를 탐색하고, 쿼리를 실행하고, 에이전트의 작업을 검토할 수 있습니다.

작동 방식

에이전트에게 "다음 달에 가장 많이 팔릴 제품의 수요를 예측하고 이를 충족할 만큼 재고가 충분한지 확인해 줘"라고 요청한다고 가정해 보겠습니다. Data Agent Kit는 관련 스킬을 로드하므로 에이전트는 작업에 대한 Google의 권장사항을 따릅니다. 이는 Knowledge Catalog를 검색하여 팀에서 신뢰하는 판매 및 인벤토리 테이블을 찾습니다. 그런 다음 MCP 도구를 사용하여 BigQuery에서 예측을 실행하고, PostgreSQL용 AlloyDB에서 현재 재고 수준을 확인하고, 결합된 답변을 편집기나 터미널로 다시 가져옵니다. 모든 단계는 자체 IAM 권한으로 실행됩니다.

Data Agent Kit가 데이터에 연결하는 방법

빌드할 수 있는 항목

Data Agent Kit는 분석, 운영 데이터베이스, 레이크하우스, 파이프라인을 지원합니다. 정식 버전의 새로운 기능부터 시작하여 실제로 어떤 모습인지 살펴보겠습니다.

분석 및 그래프: BigQuery 및 BigQuery Graph(정식 버전의 새로운 기능)

그래프는 사람들이 함께 구매하는 제품이나 공급업체가 인벤토리에 연결되는 방식과 같은 관계를 탐색하는 자연스러운 방법입니다. 그래프를 빌드하려면 일반적으로 CREATE PROPERTY GRAPH DDL을 직접 작성하고, GQL을 학습하고, 어떤 키가 실제로 에지를 형성하는지 파악해야 합니다.

그 대신 원하는 그래프를 설명하면 에이전트가 그래프를 빌드합니다. bigquery-graph-author 스킬은 테이블을 노드와 에지에 매핑하고, 제안된 각 관계를 실제 데이터와 대조하여 확인하고, 그래프를 만들기 전에 승인이 필요한 계획을 보여줍니다. 기존에 보유한 ER 다이어그램이나 데이터 모델에서 시작할 수도 있습니다. 그러면 bigquery-graph-query 스킬이 GQL을 작성하고, IDE의 그래프 시각화 도구를 통해 결과를 클릭하여 확인할 수 있습니다.

BigQuery 속성 그래프 빌드 및 시각화

운영 및 실시간 데이터베이스: Spanner, AlloyDB, Cloud SQL, Bigtable(정식 버전의 새로운 기능)

맞춤 피드, 실시간 카운터, 스토어의 '최근 본 항목' 레일과 같은 일부 기능은 즉시 로드되어야 합니다. Bigtable은 바로 이러한 용도로 설계되었으며, 잘 설계된 row key를 사용하면 그 효과를 톡톡히 볼 수 있습니다.

정식 버전 출시와 함께 Bigtable은 Spanner, AlloyDB, Cloud SQL과 함께 Data Agent Kit에서 완전히 지원되는 데이터베이스가 되었습니다. 새로운 bigtable-basics 스킬은 데이터를 읽는 방식을 중심으로 스키마를 설계하고, 무엇이든 생성하기 전에 핫스팟과 전체 테이블 스캔을 플래그합니다. 그러면 에이전트가 테이블을 만들고 GoogleSQL로 쿼리할 수 있으며, column family는 읽을 수 있는 열로 평탄화됩니다. IDE에서 카탈로그 탐색기의 Bigtable 인스턴스와 테이블을 탐색하고 SQL 편집기에서 쿼리를 실행할 수 있습니다.

에이전트 가이드 Bigtable 스키마 설계 및 쿼리

레이크하우스 및 Spark: Managed Service for Apache Spark 및 Lakehouse for Apache Iceberg(정식 버전의 새로운 기능)

에이전트는 이미 BigQuery를 통해 레이크하우스의 Apache Iceberg 테이블을 쿼리할 수 있습니다. 이제 클러스터를 관리할 필요 없이 Managed Service for Apache Spark에서 서버리스 Spark를 통해 동일한 테이블을 사용할 수 있습니다. 각 세션은 상태를 유지하므로 임시 뷰가 문 간에 전달되며, 브랜치, 시간 이동, 스키마 변경을 포함한 Iceberg의 전체 특성 세트를 사용할 수 있습니다.

테이블이 모두 Google Cloud에 있을 필요도 없습니다. federate-lakehouse-catalog 스킬이 레이크하우스를 AWS Glue 및 Databricks Unity Catalog에 연결하므로 에이전트가 수집 파이프라인을 먼저 빌드하지 않고도 해당 데이터를 제자리에서 쿼리할 수 있습니다.

Managed Service for Apache Spark를 사용하여 Iceberg 테이블 브랜치 및 쿼리

파이프라인 및 조정: dbt, Dataform, Managed Service for Apache Airflow

로직이 작동하면 에이전트가 이를 자체적으로 실행되는 파이프라인으로 전환할 수 있습니다. dbt 또는 Dataform 모델을 작성하면 gcp-pipeline-orchestration 스킬이 노트북과 함께 Managed Service for Apache Airflow에서 오케스트레이션 파이프라인으로 예약합니다. 파이프라인에는 모델 업로드 또는 일괄 추론 실행과 같은 Gemini Enterprise Agent Platform 단계도 포함될 수 있습니다.

IDE에서 시각적 파이프라인 캔버스를 통해 각 실행을 추적할 수 있습니다. 작업에 주의가 필요한 경우 진단을 클릭하여 로그를 에이전트에 전달하면 됩니다. Airflow 및 Spark 문제 해결 기술은 근본 원인을 추적하고 승인할 수 있는 수정사항을 제안합니다.

에이전트를 사용하여 실패한 Airflow DAG 문제 해결

개발자 환경 개선

정식 버전은 설정과 일상적인 워크플로도 간소화합니다. 시작할 때 한 번만 로그인하고 사용하는 Google Cloud 서비스를 선택하면 됩니다. Data Agent Kit는 수동 설정 파일 없이 필요한 API를 자동으로 사용 설정하고, 해당하는 스킬을 설치하고, MCP 서버를 구성합니다. IDE 내에서 SQL 편집기와 노트북은 이제 인라인 코드 생성, 테이블에 대한 @ 참조, 제안된 변경사항에 대한 비교 뷰를 지원합니다. 또한 확장 프로그램은 활성 프로젝트, 열려 있는 파일, 방금 실행한 쿼리의 오류를 에이전트와 공유하므로 '이 쿼리 수정'을 요청하면 바로 작동합니다.

핵심 도구의 속도와 반응성도 개선되었습니다. 새 Spark 노트북은 Spark Connect 런타임을 자동으로 만들고 선택하며, 편집기의 Spark SQL 쿼리는 기본 제공 실행 측정항목과 함께 격리된 세션에서 실행됩니다. 이제 카탈로그 탐색기가 더 빠르게 로드되고 사이드바에 BigQuery 공개 데이터 세트가 포함됩니다. 튜닝된 노트북 스킬은 에이전트가 더 적은 토큰을 사용하면서 노트북 작업을 더 빠르게 완료하는 데 도움이 됩니다.

엔터프라이즈 지원

Data Agent Kit는 추가 비용 없이 포함되어 있으며, 에이전트가 사용하는 Google Cloud 서비스에 대한 표준 가격만 지불하면 됩니다. 또한 스킬은 에이전트가 파티션 키를 확인하고 BigQuery 쿼리를 실행하기 전에 드라이 런을 실행하여 실수로 전체 테이블을 스캔하는 것을 방지하는 등 비용을 고려한 쿼리 패턴을 사용하도록 유도합니다. 또한 스킬은 GitHub에서 오픈소스로 제공되므로 팀에서 이를 감사하거나 포크하거나 자체 내부 표준에 맞게 커스텀 스킬을 작성할 수 있습니다.

액세스 제어를 위해 에이전트는 사용자 또는 사용자가 가장하는 서비스 계정으로 연결되어 행 및 열 수준 보안 정책이 자동으로 적용됩니다. 또한 관리자는 Identity and Access Management(IAM)를 통해 MCP 액세스를 제어하고, Model Armor를 통해 MCP 트래픽을 검사하고, VPC 서비스 제어 및 주 구성원 액세스 경계 정책을 통해 에이전트의 범위를 지정할 수 있습니다.

설치 및 시작하기

IDE 또는 터미널에서 1분 이내에 Data Agent Kit를 설정할 수 있습니다.

옵션 1: IDE 확장 프로그램 설치

IDE 확장 프로그램: VS Code, Antigravity IDE, Cursor 또는 VS Code 호환 편집기의 확장 프로그램 패널에서 'Google Cloud Data Agent Kit'를 검색합니다. VS Code Marketplace 또는 Open VSX에서 설치할 수도 있습니다.
Antigravity 2.0: 설정 > 맞춤설정 > Google 플러그인으로 빌드로 이동한 다음 Data Agent Kit를 다운로드합니다.
Cloud Shell 및 Cloud Workstations: 기본적으로 이미 설치되어 있으므로 편집기를 열고 로그인하기만 하면 됩니다.

옵션 2: CLI 플러그인 설치

공식 GoogleCloudPlatform/data-agent-kit-plugin 저장소를 사용하여 선호하는 코딩 에이전트에 대한 명령어를 실행합니다.

code_block: <ListValue: [StructValue([('code', '# Antigravity CLI\r\nagy plugin install https://github.com/GoogleCloudPlatform/data-agent-kit-plugin\r\n\r\n# Claude Code\r\nclaude plugin install data-agent-kit-starter-pack@claude-plugins-official\r\n\r\n# Codex CLI\r\ncodex plugin marketplace add GoogleCloudPlatform/data-agent-kit-plugin\r\ncodex plugin add dak@dak-marketplace'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff2290d0>)])]>

그런 다음 첫 번째 프롬프트를 입력합니다.

code_block: <ListValue: [StructValue([('code', "What are this week's fastest rising search terms in the US that weren't in the last week's top 10? Use the BigQuery public Google Trends dataset."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff000910>)])]>

Claude Code에서 실행되는 Data Agent Kit 플러그인

다음 단계 및 실습 리소스

문서 읽기: Data Agent Kit 문서 및 제품 개요 페이지를 살펴보세요.
스킬 살펴보기: GitHub에서 스킬을 살펴보고, 별표를 표시하고, 기여해 보세요.
분석 워크플로 빌드: Data Agent Kit 및 Antigravity IDE를 사용한 분석 Codelab을 사용해 보고 관련 블로그인 Data Agent Kit를 사용한 에이전트 분석을 읽어보세요.
데이터 과학 파이프라인 빌드: Data Agent Kit 및 Antigravity IDE를 사용한 사기 감지 파이프라인 Codelab을 사용해 보세요.

강화 학습(RL)을 활용한 Gemini 모델 맞춤설정 권장사항 가이드

Wed, 07 Oct 2026 04:00:00 +0000

강화 학습(RL)은 현대적인 LLM 사후 학습의 핵심 요소이지만, 대규모 학습 클러스터가 필요할 뿐만 아니라 Gemini와 같은 독점 모델의 경우 외부 고객이 모델 내부 구조에 접근할 수 없다는 한계가 있습니다. 이에 Google Cloud에서는 이를 관리형 RL 파인 튜닝 서비스(RLFT 서비스)로 구현했습니다. 사용자가 프롬프트와 보상 함수를 제공하면, Google Cloud에서 인프라와 독점 모델의 내부 구조를 직접 관리합니다.

이제 이 서비스를 통해 Gemini를 최적화할 수 있습니다. 라벨이 지정된 정답 세트를 단순히 학습시키는 것이 아니라, 사용자가 직접 정의한 보상 신호를 통해 모델을 가르칠 수 있습니다. 이 덕분에 지도 미세 조정(SFT)으로는 해결하기 어려운 문제들, 즉 직접 시연하기는 어렵지만 결과에 점수를 매기기는 쉬운 작업들을 처리할 수 있게 됩니다.

이 가이드에서는 RL 미세 조정 서비스를 사용하기 위한 실용적인 권장사항을 살펴봅니다. 먼저 RL 학습 루프를 간단히 살펴보고, RL 사용 여부와 시점을 결정하는 방법을 알아보고, 이 접근 방식을 통해 가치를 극대화하는 방법을 소개합니다.

RLFT란?

RLFT는 라벨이 지정된 정답이 아닌 사용자가 정의한 보상 신호를 통해 Gemini를 최적화합니다. 수많은 정답 데이터를 직접 만드는 대신, 응답을 채점하는 프로그램 하나만 작성하면 서비스가 이를 바탕으로 모델을 개선합니다. 이를 통해 직접 보여주기는 어렵지만 검증하기는 쉬운 작업들을 수행할 수 있습니다. 예를 들어, 모든 스키마에 맞는 완벽한 SQL을 일일이 작성하기는 힘들지만, 쿼리를 실행해 보고 그 결과가 맞는지 확인하는 것은 간단한 것과 같습니다.

각 학습 단계에서 서비스는 프롬프트에 대한 여러 후보 대답을 생성하고, 사용자가 정의한 보상으로 점수를 매깁니다. 이를 통해 모델은 기존 Gemini의 특성을 유지하면서도 높은 점수를 받은 대답을 생성할 확률이 높아지도록 개선됩니다. 이 모든 과정을 가능하게 하는 강화 학습은 완전 관리형으로 제공되므로, 사용자가 직접 설정할 필요가 없습니다. 사용자가 직접 제어할 수 있는 유일한 요소이자 결과에 가장 결정적인 영향을 미치는 것은 바로 보상입니다.

RLFT의 가능성과 한계를 결정짓는 세 가지 특징은 다음과 같습니다.

모델 자체의 출력으로부터 학습: 외부 대상을 복제하는 대신 모델이 이미 생성한 결과물을 정교하게 다듬는 방식이므로, SFT보다 관련 없는 기존 역량을 저해할 가능성이 적습니다.
과정이 아닌 결과에 보상: 좋은 결과에 도달하는 모든 응답에 보상을 제공하므로, 정답이 여러 개인 개방형 작업에 적합합니다.
기존 역량 강화: 어쩌다 한 번 성공하던 작업을 안정적으로 실행하도록 만들지만, 모델이 원래 할 줄 모르는 기술을 새롭게 가르칠 수는 없습니다.

RLFT 사용 시점

프롬프팅과 SFT만으로도 대부분의 최적화가 가능하므로, RLFT를 고려하기 전에 이 방법들을 먼저 충분히 시도해 보세요. RLFT는 응답을 평가할 수는 있지만 직접 작성하기에는 비용이 많이 드는 경우, (충실도, 스키마 유효성, 어조 등) 중요한 지표에서 SFT가 정체기에 도달한 경우, 단일 참조 정답만으로는 동일하게 유효한 여러 정답에 잘못된 페널티를 줄 수 있는 작업에서 진가를 발휘합니다.

SFT와 RLFT는 경쟁 관계가 아니라 상호 보완적인 관계입니다.

기본 모델이 이미 어느 정도 성공적인 결과를 내놓고 있다면 직접 RLFT를 사용하세요. 보상을 통해 더 나은 답변과 그렇지 못한 답변을 충분히 구분해낼 수 있습니다.
SFT 데이터가 있거나 기본 성공률이 너무 낮아 RL만으로는 효과를 보기 어려운 경우에는 SFT → RLFT 2단계 방식을 사용하세요. SFT를 짧고 비용 효율적인 웜 스타트로 활용하세요. 시연 데이터에 과적합되면 RL을 통해 성능을 개선할 여지가 줄어들므로 가볍게 적용하는 것이 좋습니다. 그런 다음 SFT 체크포인트에서 RL을 초기화하는 지속적 조정을 통해 RL 단계로 넘어가세요.

얼리 어답터들의 사례를 보면 이러한 패턴을 통해 RLFT가 가장 큰 가치를 창출하는 영역을 파악할 수 있습니다. 각 패턴은 비즈니스 측면에서 중요하지만, 적은 비용으로는 증명하기 어려웠던 성과들을 스코어링을 통해 입증해 줍니다.

RLFT 사용 사례

게임 내 AI 기반 NPC

개요: 다국어로 진행되는 긴 멀티턴 대화에서도 캐릭터의 개성과 브랜드의 정체성을 유지하는 대화 기능입니다.
문제: 기존 모델을 그대로 사용하면 부적절한 언어 선택, 아이템 할루시네이션, 플레이어 무시, 답변 반복 등의 현상이 발생해 몰입감을 해칩니다.
목표 및 보상: Gemini 자동 평가자(LLM-as-a-judge)가 페르소나, 흐름, 게임 상태 문법을 기준으로 각 턴의 점수를 매기며, 형식 및 언어 오류에는 감점을 부여합니다.
결과: 반복되는 루프와 언어 이탈 현상이 사라지고 상태 문법이 안정적으로 유지됨에 따라, 실제 서비스에 바로 투입할 수 있는 수준의 인게임 캐릭터를 대규모로 구현할 수 있게 되었습니다.

정형 항목 추출

내용: 공급업체 인보이스나 배송 명세서 같은 비정형 문서에서 여러 항목을 추출하여 정형 레코드로 자동 변환하는 작업입니다.
문제: SFT가 정체기에 머무는 롱테일 현상 — 필수 필드가 누락되거나(재현율), 데이터에 없는 필드를 억지로 만들어냄(정밀도).
목표 및 보상: 규칙 기반 정밀도/재현율 보상은 모든 필드가 하나의 정답을 모방하는 것이 아니라 소스 텍스트에 기반하도록 합니다.
결과: 조정이 중단되었던 노이즈 많은 실제 문서에서 필드 수준 정확도가 향상되어 수동 검토 단계를 자동화 프로세스로 전환할 수 있었습니다.

콘텐츠 검토

내용: 복잡한 정책과 결정 트리를 대규모로 적용하는 작업입니다.
문제: 모델이 평가를 회피하기 위해 오탐을 생성하는 할루시네이션을 일으키거나, 잘못된 형식을 사용하는 방식으로 보상 해킹을 시도합니다.
목표 및 보상: Cloud Run 보상은 형식 검증과 결정론적 채점기를 결합하여 다단계 정책 준수를 강제합니다.
결과: 모델은 복잡한 예외 조항을 처리하고 오탐을 획기적으로 줄였으며, 보상 해킹을 차단했습니다. 이를 통해 운영 비용 상승의 원인이 되는 수동 검토 업무량을 줄이는 성과를 거두었습니다.

실행 결과로 평가하는 코드

내용: SQL 또는 API 호출이 고객 데이터에 대해 실제로 실행되는지를 기준으로 평가됩니다.
문제: SFT는 단일 참조 쿼리를 모방하는 방식이라, 학습 시 보지 못한 고유 스키마에서는 제대로 작동하지 않습니다.
목표 및 보상: 코드 실행 보상은 안전한 샌드박스 환경에서 코드를 실행하며, 코드가 정상적으로 컴파일 및 실행되어 올바른 결과가 반환될 때만 보상을 지급합니다.
결과: 이 모델은 폐쇄형 프런티어 모델급의 품질을 유지하면서도 더 낮은 추론 비용으로 첫 시도에 바로 실행 가능한 쿼리를 생성해 냈습니다. 덕분에 기술 지식이 없는 사용자도 자연어만으로 기업 고유 데이터를 조회할 수 있게 되었습니다.

HTML을 활용한 프레젠테이션 슬라이드 생성

정의: HTML/CSS로 작성된 멀티 슬라이드 자료입니다.
문제: 텍스트만으로 학습하면 시각적 품질을 파악할 수 없습니다. 그 결과 오버플로, 요소 잘림, 스타일 불일치 등의 문제가 해결되지 않은 채 그대로 방치될 수 있습니다.
목표 및 보상: 코드 실행 보상은 슬라이드를 렌더링하고 시각적 디자인, 레이아웃의 무결성, 구조적 완성도 및 평가 기준 준수 여부를 채점합니다.
결과: 모델은 테마의 통일성을 유지하면서 레이아웃이 깨지지 않는, 모듈화된 세련된 디자인의 슬라이드 덱을 생성했습니다.

어디서 시작해야 할까요?

데이터 세트부터 시작하세요. 첫 번째 실행에는 별도의 검증 데이터 세트가 포함된 다양한 프롬프트 세트만으로도 충분합니다. 루프가 안정적으로 수렴하고 보상이 의도한 방향으로 움직이는지 확인한 후 규모를 확장하세요. 학습 데이터와 평가 데이터를 엄격히 분리하세요. 평가 데이터가 오염되면 과적합을 파악하기 어려워집니다.
보상 함수부터 시작하세요. 코드 또는 설정의 형태로 작성되는 작업 사양이며, 품질을 결정짓는 가장 핵심적인 요소입니다. 좋은 보상은 인간의 선호도와 상관관계가 있어야 하며, 잘못된 형식의 출력에도 견고해야 하고(파싱 실패를 포착하여 시스템이 다운되는 대신 명확한 부정적 점수를 반환), 보상 해킹에 저항할 수 있어야 합니다. 이를 위해 앙상블 판단을 활용하고, 길이에 페널티를 부여하며, 비정상적인 출력에는 하한선을 설정하고, 모델의 의견보다는 검증 가능한 확인 절차를 우선시하는 것이 좋습니다. 출시 전에 오프라인에서 먼저 검증을 거치세요.

그 외의 과정은 서비스가 알아서 처리합니다. 기본값으로 시작해 콘솔에서 보상 및 평가 곡선을 모니터링하고, 마지막 단계가 아닌 검증 보상이 포화 상태에 도달한 시점의 체크포인트를 선택하세요.

지금 시작하기

여러분은 무엇을 빌드해야 하나요? 원하는 것을 만들 수 있는 도구가 준비되어 있습니다.

문서: 강화 학습 파인 튜닝

Agent Factory 요약: 에이전트 하네스, 시프트 레프트, 자율 코딩

Tue, 06 Oct 2026 19:00:00 +0000

이번 Agent Factory 에피소드에서는 Google Cloud의 소프트웨어 엔지니어이자 에이전트 하네스라는 용어를 창안한 Ryan Lopopolo와 함께 자율 에이전트를 활용한 인프라 빌드 작업의 현실을 살펴봅니다. 수동 코드 편집기를 없애는 것부터 팀 공동작업을 RPG 게임에서 능력치를 올리는 과정에 비유하는 것까지, Ryan은 풍부한 컨텍스트에 기반을 두고 모델을 그라운딩하고 개발 초기부터 개입하는 것이 어떻게 높은 수준의 에이전트 자율성을 실현할 수 있는지 상세히 설명합니다.

이 게시물에서는 함께 나눈 대화의 핵심 아이디어를 안내합니다. 주제를 빠르게 요약하거나 링크와 타임스탬프를 통해 특정 세그먼트를 더 자세히 살펴보려면 이 게시물을 이용해 보세요.

에이전트 하네스 - 정의

타임스탬프: [00:30]

여기서 정의하는 AI 에이전트는 대규모 언어 모델(LLM)과 에이전트 하네스가 결합된 형태입니다.

하네스는 모델 자체가 아니라 LLM을 둘러싸고 있는 모든 요소라고 생각하면 됩니다. 예를 들어 Google Antigravity에서 Gemini 3.8 Flash를 사용하여 작업하는 경우 Gemini Flash는 LLM에 해당하고 Google Antigravity는 하네스에 해당합니다.

지원 시스템이 없는 모델은 간단한 질문에 즉시 답변할 수 있지만, 자체적으로 실시간 상황을 확인하거나 작업공간과 상호작용할 수 없습니다. 사용자가 "하늘은 왜 파란색이야?"와 같은 질문을 하면 지원 시스템이 없는 LLM도 문제없이 답변할 수 있습니다. 하지만 "오늘 우비를 입어야 할까?"와 같은 질문을 받으면 이 모델에는 필요한 데이터가 없기 때문에 스스로 답변할 수 없습니다. 이때 하네스는 사용자의 의도를 파악하고, 실시간 날씨 도구에 쿼리하고, 해당 컨텍스트를 프롬프트로 다시 구성한 후, 이를 모델에 전달하므로 모델은 정보에 입각한 답변을 생성할 수 있습니다.

Ryan Lopopolo가 전하는 에이전트 하네스와 자율 코딩

Tilde Thurium이 Ryan Lopopolo와 함께 프로덕션 환경에서 완전한 자율 코딩 워크플로를 실행하는 데 필요한 사항에 대해 이야기했습니다. 아래 요약 내용을 살펴보세요.

프로덕션 코드를 작성할 필요가 없는 하네스 개념의 탄생

타임스탬프: [02:22]

에이전트 하네스라는 용어는 자율 코딩 에이전트에 관한 Ryan의 광범위한 연구에서 비롯되었으며, 2026년 2월 에이전트 중심 세상에서 코딩 모델의 활용에 대해 다룬 에세이에서 집대성되었습니다. Ryan은 지난해 5월 이후로 기존의 코드 편집기를 한번도 열지 않았으며 Google Cloud로 이직하는 과정에서도 이 기록을 이어가고 있다고 밝혔습니다. 이 패러다임에서는 엔지니어가 더 이상 개별 구문 라인을 작성하거나 검토하지 않습니다. 대신 자연어 사양 수준에서 작업하고 pull 요청, 문서, 스프레드시트와 같은 최종 아티팩트를 검사합니다. 그런 다음 최종 결과가 조직의 표준을 충족하는지 여부를 판단합니다.

하네스 엔지니어링이란 모델이 성공할 수 있는 환경에 모델을 배치하는 방법을 연구하고 이를 실무에 적용하는 과정을 말합니다. 이러한 작업을 거치지 않으면 '프롬프트 작성 후 잘 되기만을 기도'하는 상황에 처하게 됩니다. Ryan Lopopolo

컨텍스트 큐레이션 및 지연 프롬프트 작성

타임스탬프: [03:35]

사전 하네스 투자는 엔지니어가 프롬프트 작성을 지연해도 효과를 발휘합니다. 저장소에 구조화된 문서, 명확한 인터페이스, 검색 가능한 도구가 포함되어 있다면 매일 아침 프롬프트 상자에 긴 텍스트를 붙여넣을 필요가 없습니다.

"저는 아주 게으른 프롬프트 작성자가 되고 싶습니다. 모델을 그라운딩하는 데 필요한 도구와 컨텍스트를 제공하는 작업을 완료했다면 긴 프롬프트를 작성할 필요가 없습니다. 모델이 알아서 해결하니까요."

이 모델은 하네스를 사용하여 관련 컨텍스트를 가져오므로 별도의 감독 없이도 대규모 코드베이스를 탐색하고 복잡한 작업을 실행할 수 있습니다.

시프트 레프트: 자율 가드레일로서의 엔지니어링 권장사항

타임스탬프: [05:00]

에이전트가 실패하면 개발자는 다양한 개입 방식을 고려하게 됩니다. 가장 일반적인 방식은 프롬프트를 수정하거나 다시 시도하는 것이지만, 이를 팀 전체로 확장하기 어렵습니다.

"제가 생각할 수 있는 가장 간단하고 단순하며 어리석은 개입은 말 그대로 다른 것은 아무것도 변경하지 않고 프롬프트를 다시 시도하는 것입니다. 하지만 시프트 레프트는 프롬프트, 저장소 문서, 린터, 테스트, 업스트림 평가에 이르기까지 비용이 가장 적게 들고 자동화할 수 있는 개발 수명 주기의 초기 단계에 개입하여 문제를 해결하는 것을 의미합니다."

다음 단계에서 모델이 올바르게 판단하기를 기대하는 대신, 시프트 레프트를 통해 표준을 환경에 직접 삽입합니다. 린터, 테스트, AGENTS.md 파일은 사용자가 바람직한 결과라고 생각하는 기준을 기억하고 실행하는 역할을 합니다. 따라서 에이전트가 지속적인 개입 없이도 정해진 궤도를 벗어나지 않고 올바르게 작동하도록 보장할 수 있습니다.

기존 도구 및 결정론 활용

타임스탬프: [06:50]

에이전트는 사전 학습 데이터에 많이 등장하는 패턴을 이미 반영하는 도구를 사용할 때 진가를 발휘합니다. 모델을 표준 명령줄 인터페이스와 페어링하면 추론이 결정론적 성격을 띠게 되며, 컨텍스트 집계에 따른 부담이 모델에서 신뢰할 수 있는 도구로 옮겨집니다.

또한 Ryan은 컨텍스트 효율성을 높이기 위한 환경 설계 방법을 공유했습니다. 바로 링크 앵커가 인라인이 아니라 해당 텍스트 블록 바로 아래에 위치하도록 마크다운 파일을 구성하는 것입니다. 이렇게 하면 컨텍스트가 복잡해지는 것을 방지하고 '중간에 길을 잃는' 검색 문제를 완화할 수 있습니다. Ryan은 최종 상태 아티팩트를 검토하는 방식으로만 작업하기 때문에 문서를 읽기 쉽게 유지하면 실행 과정을 쉽게 검사할 수 있습니다.

"저는 pull 요청을 보고 검토할 수 있기를 원합니다. 에이전트가 잘못된 결정을 내렸다면 어디서 잘못되었는지 알아야 에이전트를 바로잡고 다시는 같은 실수를 하지 않도록 할 수 있습니다."

장기 계획 및 에이전트 루프 확장

타임스탬프: [09:45]

하네스 엔지니어링의 핵심 과제는 에이전트가 장기적인 관점에서 일관성을 유지하도록 하는 것입니다. 인간 조직은 일회성 프롬프트가 아닌 반복적인 개선을 통해 소프트웨어를 개발하므로 에이전트 워크플로도 이러한 주기를 반영해야 합니다. 하네스 엔지니어링은 엄격하게 범위가 정해져 있고 검토 가능한 pull 요청을 사용하여 에이전트의 상태 공간을 좁힙니다. 이러한 신뢰도 높은 변경사항을 엔드 투 엔드로 쌓아 올리면 감독자는 루프 크기를 점진적으로 확장할 수 있으므로, 에이전트는 전체 언어 마이그레이션을 포함한 대규모 이니셔티브를 자율적으로 실행할 수 있을 때까지 신뢰를 구축할 수 있습니다.

RPG 능력치처럼 에이전트 팀 큐레이션

타임스탬프: [11:58]

개별 전문 분야에 따라 스프린트 작업을 분배하는 대신, 다양하게 구성된 팀이 에이전트의 역량 강화에 기여하게 되면 에이전트는 모든 구성원의 강점을 담은 핵심적인 업무 생산자로 거듭나게 됩니다. Ryan은 에이전트의 역량을 높이는 과정을 캐릭터 시트를 작성하는 것에 비유했습니다.

"마치 RPG 캐릭터의 능력치를 키우는 것과 비슷합니다. React 설계자가 팀에 새로 합류하면 이 사람의 전문성이 더해져 프런트엔드 아키텍처와 성능 관련 능력치가 크게 향상되는 식이죠."

이러한 집단적 전문성이 환경에 내재화되면 에이전트는 들어오는 작업을 자율적으로 분류하고 필요에 따라 적합한 기술을 활성화하여 백엔드 설계자와 프런트엔드 전문가의 역할을 모두 수행할 수 있습니다.

커스텀 하네스가 아닌 도구에서 시너지 창출

타임스탬프: [14:38]

자체적으로 커스텀 에이전트 하네스를 빌드해야 할지 고민하는 개발자에게 Ryan은 처음부터 빌드하지 말라는 명확한 조언을 건넸습니다. 표준 하네스는 이미 파일 읽기, grep 검색, 명령어 실행과 같은 기본적인 기능을 제공합니다. 스캐폴딩 기능을 과도하게 사용하여 엄격한 맞춤형 프레임워크로 에이전트를 구성하면 기술 부채가 발생하고, 프런티어 모델이 발전함에 따라 매몰 비용이라는 함정에 빠지게 됩니다.

"도구와 컨텍스트의 품질을 개선하는 데 모든 역량을 집중하면 새로운 모델이 출시될 때마다 자유롭게 도입할 수 있으며, 절대 구식이 되지 않는 시스템에서 지속적으로 시너지를 창출할 수 있습니다."

Google Cloud 운영 및 기능 격차 해소

타임스탬프: [16:47]

Ryan은 Google Cloud에서 자신의 업무에 대해 이야기하면서 기능 격차, 즉 프런티어 AI 모델이 이론적으로 수행할 수 있는 작업과 현재 프로덕션에서 추출되는 유용한 작업 간의 차이를 없애고자 하는 동기를 설명했습니다. 클라우드는 방대하고 프로그래밍 가능한 플랫폼 역할을 하므로, Google Cloud를 직접 이용하기 위한 인터페이스를 에이전트에 제공하면 인프라를 효율적으로 관리하고 배포할 수 있게 되어, 원시 모델 기능을 실질적인 엔터프라이즈 유틸리티로 전환할 수 있습니다.

AI에 대한 기존 사고방식의 지속적인 업데이트

타임스탬프: [18:13]

AI 개발 속도가 빨라짐에 따라 엔지니어와 팀은 기존의 한계를 적극적으로 극복하고 이러한 모델을 통해 달성할 수 있는 목표를 끊임없이 재평가해야 합니다. Ryan은 "우리가 가진 훌륭한 도구를 활용하여 어떤 작업이 가능한지에 대한 생각을 지속적으로 업데이트하는 것이 매우 중요합니다"라고 강조했습니다. 6개월 전에는 작동하지 않던 기능이 오늘날의 프런티어 모델에서는 원활하게 실행되는 경우가 종종 있습니다. 개발자는 경직된 워크플로에 갇히기보다는 모든 모델 업그레이드에서 관련성을 유지할 수 있는 확장성이 뛰어난 두 가지 인터페이스인 도구와 컨텍스트를 중심으로 빌드해야 합니다.

"에이전트는 사용자가 바람직한 결과라고 생각하는 기준에 맞게 마지막 단계까지 조정하기 위해 항상 컨텍스트를 필요로 합니다. 또한 사용자가 바람직한 결과라고 생각하는 기준을 기억하고 실행하는 역할을 하는 더욱 강력한 도구를 활용하여 이 과정을 점진적으로 발전시켜 나간다면, 시간 경과에 따라 모델이 점점 더 흥미로운 작업을 해내는 모습을 보고 계속해서 놀라게 될 것입니다."

커스텀 하네스 빌드하기

다음으로 Billy Jacobson은 개발자가 특정 작업을 위해 자체적으로 에이전트 하네스를 맞춤설정하는 방법을 소개했습니다.

자세히 들여다보기: 커스텀 하네스를 빌드하는 이유

타임스탬프: [19:44]

코드를 작성하기에 앞서 Billy는 개발자가 하네스를 블랙박스처럼 취급하기보다는 하네스의 메커니즘을 이해해야 하는 이유를 설명했습니다. "프레임워크를 그냥 사용할 수도 있지만, 훌륭한 엔지니어라면 프레임워크를 제대로 이해해야 합니다"라는 엔지니어링 멘토의 조언을 떠올리며, Billy는 에이전트가 오작동할 때 발생하는 문제를 디버깅하는 가장 좋은 방법은 하네스를 직접 빌드하는 것이라고 설명했습니다. 모든 워크플로에 대해 설계와 관련한 세 가지 중요한 결정을 평가할 수 있습니다.

루프: 에이전트가 몇 번 반복 실행해야 하며, 어떤 조건에서 종료 상태를 트리거하나요?
도구: 에이전트가 어떤 특정 도구에 액세스해야 하며, 언제 어떻게 호출해야 하나요?
메모리: 대화 메모리와 운영 메모리는 얼마나 중요하며, 언제 검색하거나 압축해야 하나요?

선형 에이전트 하네스: 결정론적 단일 패스 실행

타임스탬프: [21:34]

Billy는 루프가 필요 없는 결정론적 워크플로를 위해 설계된 미니멀한 선형 하네스를 시연했습니다. 이 패턴은 높은 수준의 결정론이 필요하고 에이전트가 매번 정확히 동일한 실행 흐름을 수행해야 하는 표적 검사, 파일 변환 또는 단일 턴 데이터 분석에 적합합니다.

폐쇄 루프 에이전트 하네스: 반복적인 테스트 기반 복구

타임스탬프: [22:45]

적극적인 버그 수정과 리팩터링이 필요한 작업의 경우 폐쇄 루프 하네스는 검증된 해결책에 도달하는 데 필요한 반복적인 추론을 제공합니다.

이 데모에서 Billy는 요구사항을 충족하지 못하는 문제를 해결하기 위해 자동화된 코드 편집을 적용하는 에이전트를 선보였습니다. 이 과정에서 하네스는 업데이트된 코드베이스에 대해 단위 테스트 모음을 실행합니다. 테스트가 실패하면 런타임은 표준 실패 로그와 상세한 스택 트레이스를 캡처하여 해당 오류 진단 정보를 에이전트의 작업 메모리에 직접 제공합니다. 이 프로세스는 모든 단위 테스트를 통과할 때까지 지속적으로 반복되지만, 무한 루프와 과도한 실행 비용을 방지하기 위해 5회 반복으로 제한됩니다.

Google의 에이전트 개발 키트(ADK)를 활용한 가드레일 하네스

타임스탬프: [23:25]

핵심 오케스트레이션 파이프라인을 처음부터 다시 작성하지 않고도 커스텀 동작이 필요한 개발자를 위해 Google의 에이전트 개발 키트(ADK)는 자동화된 메모리 관리 및 실행 보호 장치가 포함된 스캐폴딩을 제공합니다.

Billy는 ADK의 기본 컨텍스트 압축 기능을 활용해 이전 대화 내용을 요약하여 연장된 디버깅 실행 기간 동안 컨텍스트 윈도우가 과도하게 커지는 것을 방지하는 예시를 살펴보았습니다. 커스텀 인터셉트 후크는 셸 작업을 실행하기 전에 검사하고 필터링하여 재귀적 파일 삭제, 데이터베이스 삭제, 무단 원격 git 푸시와 같은 고위험 작업을 자동으로 차단합니다. 이 아키텍처에서는 도구 실행 경계를 세밀하게 제어하는 동시에 맞춤형 하네스 프레임워크의 유지보수 부담을 줄일 수 있습니다.

3계층 에이전트 개발 스택: Gemini 3.8 Flash, Google Antigravity, Google Skills

타임스탬프: [25:27]

다음으로 Smitha Kolan은 코딩 에이전트에 항상 더 복잡한 추론 모델이 필요한 것은 아니라는 점을 자세히 설명하면서, 에이전트 스택의 세 가지 계층인 모델, 하네스, 지식 간에 균형을 유지하는 것이 고성능의 비결이라고 강조했습니다.

"코딩 에이전트에 더 스마트한 모델이 필요한 것은 아닙니다. 모델, 하네스, 지식으로 구성된 더 나은 스택이 필요합니다. 이 세 가지가 완벽하게 조화를 이룰 때 모든 것이 달라집니다."

이어 Smitha는 최근에 즐겨 사용하고 있는 세 가지 도구를 스택의 각 계층별로 하나씩 소개했습니다.

계층 1 | 모델 | Gemini 3.8 Flash: 실행 빈도가 높은 에이전트 루프는 작업당 20~60회의 순차적 홉(파일 검사, 함수 업데이트, 단위 테스트 실행)을 실행합니다. 반복이 거듭될수록 지연 시간과 API 비용이 누적되므로, Gemini 3.8 Flash와 같이 반응성이 뛰어난 경량의 모델을 사용하면 막대한 비용을 들이지 않고도 실시간 에이전트 루프를 실용적으로 구현할 수 있습니다.

계층 2 | 하네스 | Google Antigravity(/boost): 기본 Antigravity는 표준 탐색 및 구성요소 생성 작업을 처리합니다 또한 여기에 /boost 명령어를 추가하면 조정자가 가동되어 특화된 하위 에이전트를 병렬로 조율한 후 최종적으로 파일을 수정하기 전에 독립적인 감사 단계를 수행합니다.

계층 3 | 지식 | Google Skills 저장소: GitHub에서 19,000개 이상의 별표를 기록했으며 Google Cloud, Firebase, Flutter, 지도 등 다양한 분야에서 엄선된 100개 이상의 도메인 패키지를 보유한 이 저장소는 특정 하네스에 구애받지 않으면서 필요에 따라 정확한 도메인 컨텍스트를 제공하므로 에이전트는 클라우드 구성을 추측하지 않아도 됩니다.

직접 빌드해 보기

효과적인 코딩 에이전트를 빌드하려면 단순히 더 큰 모델로 교체하는 관행에서 벗어나야 합니다. 하네스 엔지니어링에 대한 Ryan Lopopolo의 철학에서 알 수 있듯이, 개발자의 역량을 강화하는 길은 권장사항을 개발 초기 단계부터 활용하고 모델 업그레이드 후에도 지속적으로 활용 가능한 풍부한 도구, 결정론적 검증 도구, 잘 선별된 컨텍스트에 투자하는 데 있습니다. 여기에 빠른 추론 모델, 구조화된 오케스트레이션 하네스, 모듈식 도메인 지식이 결합되면 에이전트는 단순한 대화거리에 그치지 않고 신뢰할 수 있는 자율 엔지니어링 파트너로 진화하게 됩니다.

실제로 적용해 볼 준비가 되셨나요? 이 에피소드에서 다룬 도구와 리소스를 살펴보세요.

Gemini 3.8 Flash: 멀티홉 에이전트 루프를 위한 빠르고 저렴한 모델입니다.
Google Antigravity(/boost): 병렬 코딩 에이전트 및 검증을 위한 조정자 하네스입니다.
Google Skills: Google Cloud, Firebase, Flutter를 위한 모듈식 도메인 지식입니다.
에이전트 개발 키트(ADK): 안전 가드레일 및 메모리 압축을 위한 커스텀 하네스 미들웨어입니다.
전체 에피소드 동영상: 전체 인터뷰와 Factory Floor 라이브 코드 데모입니다.

Google의 최신 소식 확인하기

Smitha Kolan → LinkedIn | YouTube | X
Luke Schlangen → LinkedIn | 웹사이트
Ryan Lopopolo → LinkedIn | Hyperbola | X
Tilde Thurium → LinkedIn
Billy Jacobson → LinkedIn | X
Mollie Pettit → LinkedIn | dev.to | X | Bluesky

AlphaEvolve로 동영상 처리 가속화 가이드

Tue, 06 Oct 2026 07:00:00 +0000

실시간 스트리밍에서는 1밀리초의 시간도 매우 중요합니다.

예를 들어 초당 30프레임(fps) 환경에서 개발자에게 주어진 프레임 예산은 단 33.3ms에 불과합니다(60fps에서는 16.6ms). 이 짧은 시간 안에 카메라 프레임을 수집하고, 신경망 세분화를 실행하고, 셰이더를 적용한 뒤 출력물을 합성해야 합니다. 이 예산을 1밀리초라도 초과하게 되면 프레임 드롭과 화면 끊김 현상이 발생합니다.

수동 최적화는 지루한 작업으로 악명이 높습니다. Flame 그래프를 분석하고 Swift, C++ 또는 Metal에서 하위 수준 코드를 수동으로 조정하는 데 몇 주가 걸립니다. 일반적인 AI 코딩 어시스턴트는 상용구를 생성할 수 있지만, 대상 하드웨어에 맞게 최적화하거나, 실제 지연 시간을 벤치마킹하거나, 최적화를 통해 시각적 충실도를 유지하도록 보장할 수는 없습니다.

자율적인 폐쇄 루프 기반의 최적화 혁신은 이러한 패러다임을 바꿉니다. AlphaEvolve와 같은 도구는 클라우드 규모의 모델 추론과 로컬 하드웨어 실행을 결합하며, 이미 실제 현장에 영향을 미치고 있습니다. DoIt는 Google과의 파트너십을 통해 AlphaEvolve를 사용하여 실시간 macOS 스트리밍 앱에서 프로덕션 Swift 코드를 자율적으로 최적화하고, 수동 프로파일링으로 놓친 성능 개선의 여지를 찾아냈습니다(기술 자료 전문 읽기).

이 게시물에서는 동영상 파이프라인에 중점을 두지만, 분할 루프 패턴은 마이크로서비스 처리량과 데이터베이스 쿼리부터 ML 텐서 파이프라인과 임베디드 시스템에 이르기까지 성능이 중요한 모든 곳에 적용됩니다. 어떤 경우든 공식은 동일합니다. 클라우드의 Gemini 코드 생성과 도메인별 벤치마크 하네스 및 자동화된 품질 게이트를 결합하는 것입니다.

오늘은 AlphaEvolve를 사용하여 동영상 처리 속도를 높이는 방법을 알아보고, 이러한 원칙을 실제 성능 병목 현상에 어떻게 적용할 수 있는지 소개해 드리겠습니다.

분할 루프 아키텍처의 이해: AlphaEvolve가 관리형 클라우드 생성(Google Cloud의 Gemini 모델 앙상블)과 로컬 평가(예: 네이티브 Swift/Metal 코드의 컴파일 및 소요 시간 측정)를 분리하는 방식을 알아봅니다.
평가 도구 구성 및 품질 게이트: 구조적 유사성 지수(SSIM)와 같은 지표를 활용해 점수 함수를 설계함으로써, 진화 루프가 성능 수치만을 높이기 위해 벤치마크를 악용하는 상황(예: 속도를 높이려고 렌더링을 아예 건너뛰는 행위)을 방지하는 방법을 알아봅니다.
자율 알고리즘 발견: Gemini 기반의 진화 검색이 어떻게 별도의 프롬프트 없이도 프레임워크 API를 스스로 찾아내고, 지능적인 엔지니어링 절충(예: 프레임 캐싱 제한)을 결정할 수 있는지 살펴봅니다.
현실적인 성능 경계 설정: 물리적 하드웨어 하한에 대한 코드 최적화를 측정하는 방법을 알아봅니다.

1. AlphaEvolve의 분할 루프 아키텍처 이해

AlphaEvolve는 폐쇄 루프 진화 프로세스를 실행합니다. 시드 프로그램과 맞춤 점수 함수가 주어지면 혼합된 Gemini 모델이 코드 변형을 제안하고, 각 후보에 대해 점수 함수를 실행하고, 가장 성능이 좋은 코드를 남기고, 여러 세대에 걸쳐 반복하면서 최적의 솔루션에 가까워집니다.

AlphaEvolve의 핵심적인 아키텍처상 이점은 두 부분으로 명확하게 구분된다는 점입니다.

생성 부분(Google Cloud 관리형 서비스): 프롬프트 샘플러, Gemini 모델 앙상블, 프로그램 데이터베이스로 구성됩니다. Google Cloud는 확장, 프롬프트 조정, 생성 메커니즘을 처리합니다.
평가 부분(고객 관리형 컴퓨팅): 코드 품질 점수 산정은 철저하게 도메인별로 특화되어 이루어집니다. 평가 도구 모듈은 사용자가 전적으로 소유하며, 자체 하드웨어 또는 대상 아키텍처(이 경우 네이티브 Swift 코드를 실행하는 macOS)에서 직접 실행합니다.

AlphaEvolve는 클라우드 생성 측면에서 Python 중심이지만, 평가는 어떤 언어로든 작성할 수 있습니다. 커스텀 평가 도구는 swift를 사용하여 각 Swift 후보 코드를 컴파일하고, 이를 표준 참조 웹캠 클립에 대해 실행합니다.

2. 평가 도구 구성 및 품질 게이트

AlphaEvolve와 같은 자동화된 최적화 루프는 실제로 동영상 스트림을 직접 '보는' 것이 아닙니다. 평가 도구가 반환하는 숫자 형태의 적합도 점수만 인식할 뿐입니다. 평가 측정항목에 사각지대가 있다면, 진화적 코드 생성은 이를 집요하게 파고들 것입니다.

초기 실행에서 원시 지연 시간에 가중치를 둔 단순한 적합도 점수는 놀라운 속도 향상을 가져왔습니다. 모델이 블러 렌더링을 완전히 우회하고 수정되지 않은 프레임을 0밀리초 만에 반환한 것입니다.

구조적 유사성 지수 측정(SSIM):

모델이 벤치마크를 조작하는 것을 방지하려면, 처리량과 구조적 유사성 지수(SSIM) 같은 구조적 충실도 지표를 결합한 2계층 점수 함수를 빌드해 보세요.

code_block: <ListValue: [StructValue([('code', 'speedup = baseline_ms_per_frame / candidate_ms_per_frame\r\nssim = mean_ssim_vs_golden\r\n\r\n#Disqualify any candidate falling below visual threshold\r\n\r\n\r\nif ssim < 0.98 or worst_frame_ssim < 0.95:\r\n return {"speedup": -1e12} # Disqualified\r\n\r\nreturn {"speedup": speedup, "ssim": ssim}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafeca8c90>)])]>

이를 통해 어떤 이점을 얻을 수 있을까요?

최악의 상황을 가정한 클립 테스트: 정지된 프레임이나 화면이 비어 있는 카메라로 벤치마킹하지 마세요. 후보 코드는 정적인 배경에서는 평균 SSIM 기준을 쉽게 통과할 수 있지만, 머리를 빠르게 돌리는 상황에서는 실패할 수 있습니다.
평균과 최솟값 추적 가능: 평균 기준점과 프레임별 하한을 모두 적용하여 프레임 드롭 또는 마스크 업데이트 지연을 포착합니다.

자율적인 알고리즘 탐색:

대부분의 개발자는 로컬 마이크로 최적화(예: 도우미 함수 인라인화, 루프 언롤링, 메모리 풀 조정 등)에 생성형 AI를 사용합니다. 하지만 아키텍처 공간이 주어지면 진화 루프는 자체적으로 시스템 최적화를 발견할 수 있습니다.

엔지니어링 교훈:

고립된 루프가 아닌 프레임워크 컨텍스트 제공: 프롬프트 또는 검색 하네스에 공개 SDK 헤더, 인터페이스 정의 또는 API 참조 기호를 포함합니다. LLM은 컨텍스트 윈도우에 격리된 프레임 처리 콜백만 포함된 경우 시퀀스 인식 하위 시스템을 채택할 수 없습니다.
다중 프레임 수명 주기 후크 노출: 후보 코드가 순수 스테이트리스(Stateless) 함수를 강제하는 대신, 실행 전반에서 제한된 상태(예: 이전 마스크 또는 캐시 타임스탬프)를 유지할 수 있도록 합니다.
품질 게이트를 통한 절충점 관리: AlphaEvolve에 시간적 마스크 캐싱을 처음 도입했을 당시, 마스크를 너무 공격적으로 캐싱하는 바람에 눈에 띄는 잔상이 발생하기도 했습니다. SSIM 게이트가 움직임 중 발생하는 드리프트를 억제하므로, 별도의 수동 매개변수 조정 없이도 검색이 프로덕션에 즉시 사용 가능한 수준의 캐시 윈도우로 수렴되었습니다.

현실적인 성능 경계 설정

성능 엔지니어링에서 흔히 저지르는 실수는 기준 없이 막연하게 최적화를 진행하는 것입니다. 2배의 속도 향상을 달성했을 때, 이를 대단한 성과라고 할 수 있을까요? 아니면 3배나 더 개선할 수 있는 여지를 남겨둔 것일까요?

실시간 미디어에서 총 프레임 시간은 두 가지 카테고리로 나뉩니다.

변경 가능한 소프트웨어 오버헤드: 메모리 할당, 버퍼 형식 변환, 스레드 컨텍스트 전환, API 디스패치 마찰
변경할 수 없는 하드웨어 하한: 원시 신경망 엔진 추론 지연 시간, GPU 셰이더 컴퓨팅 시간, 하드웨어 디스플레이 동기화

AlphaEvolve를 최대한 활용하려면 개발자는 이론상 최대 여유 공간을 기준으로 측정해야 합니다.

최적화 루프를 실행하기 전에 다음 몇 가지 원칙을 염두에 두세요.

'노옵스(no-ops)' 파이프라인 빌드: Swift/C++ 조정, 데이터 마셜링, 프레임 변환을 제거합니다. 사전 준비된 ML 모델과 순수 GPU 패스만 더미 버퍼에 디스패치합니다. 이때 측정된 시간이 물리적 하드웨어의 하한선입니다.
도달 가능한 상한 계산: 가능한 전체 최적화는 다음과 같습니다.

3. 하드웨어 격차에 대한 점수: 임의의 속도 향상 배수 대신 최적화 효율성을 측정합니다.

시작하기

모든 벤치마크 코드, 테스트 클립, 평가 스크립트, 원시 후보 로그는 오픈소스입니다.

GitHub 저장소: AlphaEvolve 카메라 배경 블러 예시
DoIt와 함께한 우수사례에 대한 자세한 기술 자료: 자체 코드에 AlphaEvolve 적용하기

Google Cloud 네트워킹이 AI 워크로드를 위한 유연한 컴퓨팅 선택을 지원하는 방법

Mon, 05 Oct 2026 13:00:00 +0000

AI 워크로드에 필요한 리소스, 특히 가속기의 가용성을 확보하는 것은 업계 전반에서 어려운 과제입니다. 특정 유형의 가속기를 기반으로 AI 워크로드를 빌드할 경우, 배포가 지연될 수 있습니다. 유동적인 컴퓨팅이라는 개념을 활용하면 사용 사례에 작힙힌 가용 리소스를 기반으로 다양한 옵션을 고려하여 AI 배포를 설계할 수 있습니다.

이 블로그에서는 Google Cloud 네트워킹이 AI 워크로드를 지원하는 방식을 살펴보고, 가속기(GPU 또는 TPU) 선택 시 고려해야 할 사항을 알아봅니다. 가속기 유형에 따라 백엔드 네트워킹 구성요소의 설정이 달라지기 때문입니다.

리소스 옵션

AI 배포를 통해 수행하려는 작업 유형을 결정하면 이제 다음으로 중요한 요소는 해당 작업을 수행할 때ㅐ 필요한 실제 하드웨어입니다. 이 경우 비공개 LLM에 대한 추론을 실행하려고 하며, 대상은 A4 VM(a4-highgpu-8g)에서 사용할 수 있는 NVIDIA B200 GPU 제품군입니다.

이제 수행하려는 작업과 가능한 컴퓨팅 옵션을 파악했습니다. 하지만 이 옵션을 사용할 수 있을까요?

리소스를 확보하는 방법은 다음과 같은 몇 가지 옵션이 있습니다.

동적 워크로드 스케줄러(Flex-start VM): 필요한 모든 가속기 노드를 동시에 사용할 수 있을 때까지 워크로드를 큐에 추가하고, 일괄적으로 프로비저닝하며, 최대 7일 동안 선점되지 않도록 실행합니다.
동적 워크로드 스케줄러(캘린더 모드): 1~90일 전에 가속기 용량을 예약할 수 있으며, 시작 및 종료 시간이 보장되므로 예약된 사전 학습 실행 및 벤치마킹에 적합합니다.
미래용 예약: 특정 미래 날짜부터 지정된 영역에서 약정된 하드웨어에 대한 액세스를 보장합니다.
Flex 예약: 다년간의 약정 없이도 부족한 가속기 노드를 확보할 수 있도록 단기 약정 기간을 제공합니다.
동적 노드 자동 프로비저닝 및 ComputeClasses: Google Kubernetes Engine(GKE)에서 ComputeClasses 내에 여러 제품군을 대체 목록으로 정의하면 기본 풀에 리전 제약이 발생할 경우 클러스터가 대체 가속기 유형을 자동으로 프로비저닝하도록 시도할 수 있습니다.
스팟 VM: 내결함성을 갖추고 체크포인트가 있는 일괄 작업에 대해 잔여 컴퓨팅 용량을 크게 할인된 가격으로 제공합니다.

자세한 내용은 블로그 게시물 Never Run Out of Compute: A Practical Guide to GKE Resource Obtainability(안정적인 컴퓨팅 리소스 확보: GKE 리소스 확보 가능성을 안정적으로 높이기 위한 실무 가이드)에서 확인하세요.

네트워킹 구성 선택하기

가속기의 네트워킹 구성요소는 선택하는 가속기 유형에 따라 달라집니다. 이 문서에서는 표준 네트워킹, 가속 GPU 네트워킹(TCPX/TCPXO 및 RoCEv2), TPU 네트워킹, Cloud Run의 네 가지 구성을 살펴보겠습니다.

표준 네트워킹

지원되는 가속기: NVIDIA T4(N1 시리즈), NVIDIA L4(G2 시리즈), NVIDIA A100(A2 머신 시리즈 단일 노드 및 멀티 노드), Cloud TPU v3, Cloud TPU v5e(단일 호스트/독립형 슬라이스)
아키텍처: 노드는 표준 TCP/IP 기반의 Google 가상 NIC(gVNIC)를 사용하여 기본 Virtual Private Cloud(VPC) 네트워크를 통해 통신합니다.
워크로드 적합성: Google Cloud 컴퓨팅 환경 전반에서 간단한 이식성을 제공하여 분산 데이터 전처리, 분리된 파이프라인 단계, 독립적인 추론 복제본, 표준 VPC 라우팅 및 네트워크 정책을 사용하는 컴퓨터 비전 워크로드를 지원합니다.

가속 GPU 네트워킹(TCPX/TCPXO 및 RoCEv2)

분산 학습과 멀티 노드 추론에는 대규모 파라미터 교환과 집합 통신을 처리하기 위해 특화된 멀티 레일 네트워크 패브릭이 필요합니다.

GPUDirect-TCPX 및 TCPXO 패브릭

지원되는 가속기: NVIDIA H100(A3 High VM, 레일 4개) 및 NVIDIA H100 Mega(A3 Mega VM, 레일 8개).
아키텍처: 커스텀 GPUDirect-TCPX(전용 VPC 4개) 및 GPUDirect-TCPXO(전용 VPC 8개) 오프로드 엔진을 사용하여 기본 RDMA 하드웨어 없이도 표준 이더넷 인프라에서 높은 처리량의 멀티 레일 GPU 통신을 구현합니다.
배포 청사진: 이러한 멀티 VPC 토폴로지는 Cluster Toolkit의 사전 빌드된 청사진을 사용하는 등 다양한 방법으로 배포할 수 있습니다.

RoCEv2 패브릭(VM 및 베어메탈)

지원되는 가속기: NVIDIA H200(A3 Ultra VM), NVIDIA B200(A4 VM), NVIDIA GB200 NVL72(A4X VM), NVIDIA GB300(A4X Max 베어메탈).
영역 네트워크 프로필: RoCEv2는 특수한 영역 네트워크 프로필에 연결된 전용 RDMA VPC를 통해 작동합니다. VM 인스턴스(A3 Ultra, A4, A4X)는 ZONE-vpc-roce 프로필을 사용하고, 베어메탈 인스턴스(예: A4X Max)는 전용 ZONE-vpc-roce-metal 베어메탈 프로필을 사용합니다.
레일 정렬 패브릭: 이 전용 VPC는 GPU 통신을 위해 엄격하게 격리되어 있으며 가속기 NIC에 직접 매핑된 서브넷을 포함합니다. 백엔드 네트워크는 레일별로 정렬되어 있고 점보 프레임(MTU 8896)을 지원하며, 레일간 간섭을 최소화하면서 가족에게 피해 입히지 않도록 비차단 멀티 테라비트 대역폭을 제공합니다.
GKE를 통한 자동화된 네트워크 구성 영지 동적 리소스 할당 네트워크(DRANET): GKE에 이러한 GPU를 배포할 때 GKE 관리형 DRANET을 사용하여 추가 네트워크를 자동으로 프로비저닝하고 RDMA 네트워크 인터페이스를 GPU에 매핑하는 드라이버를 할당할 수 있습니다. 그런 다음 표준 Kubernetes 리소스 클레임을 사용하여 워크로드 포드에서 직접 할당하고 사용할 수 있습니다.
턴키 배포: Cluster Toolkit의 자동화된 청사진을 사용하여 RDMA VPC, MTU 조정, tooling 포함한 전체 엔드 투 엔드 스택을 배포할 수 있습니다.

TPU 네트워킹

지원되는 가속기: Cloud TPU v4, Cloud TPU v5p, Cloud TPU v5e(멀티 호스트 포드 슬라이스), Cloud TPU v6ee(Trillium), 튜토리얼: TPU7x(Ironwood)
칩 간 상호 연결(ICI): TPU Pod 또는 슬라이스 내부에서 칩은 2D 또는 3D 토러스 메시로 구성된 전용 초저지연 광학 링크를 통해 직접 통신하며 기존 네트워크 스택을 완전히 우회합니다.
광학 회로 스위치(OCS): TPU v4 및 TPU v5p SuperPod에서 소프트웨어로 재구성할 수 있는 OCS 장치를 사용합니다. 물리적 네트워크 토폴로지를 동적으로 변경하고, 결함이 있는 트레이를 우회하며, 케이블을 수동으로 다시 연결하지 않고도 원하는 크기의 가속기 슬라이스를 구성할 수 있도록 합니다.
멀티 NIC 아키텍처(TPU v6e 이상): 이전 TPU 세대가 슬라이스 내부 통신에는 ICI를 사용하고 호스트 트래픽에는 단일 NIC에 의존했던 것과는 달리, Cloud TPU v6e(Trillium) 및 TPU7x는 기본 네이티브 NIC 아키텍처를 도입했습니다. 작업자 노드는 표준 Kubernetes 관리 트래픽을 기본 VPC로 격리하는 동시에 높은 처리량의 TPU 데이터 및 교차 슬라이스 통신을 위해 구성된 별도의 VPC를 사용합니다.
TPUDRANET 배포: GKE에 이러한 TPU를 배포할 때 GKE 관리형 DRANET을 사용하여 추가 네트워크를 자동으로 프로비저닝하고 TPU 통신을 위한 드라이버를 할당할 수 있습니다. 그런 다음 표준 Kubernetes 리소스 클레임을 사용하여 워크로드 포드에서 직접 할당하고 사용할 수 있습니다.
데이터 센터 네트워크(DCN) 멀티슬라이스: 개별 TPU 슬라이스를 넘어 확장헤야 하는 모델의 경우, Cloud TPU 멀티슬라이스가 이러한 전용 멀티 NIC 경로를 활용하여 Google의 고속 Jupiter 데이터 센터 네트워크를 통해 여러 개의 독립적인 ICI 메시를 연결합니다.

Cloud Run

지원되는 가속기: Cloud Run GPU 서비스의 NVIDIA L4(G2 시리즈) 및 NVIDIA RTX PRO 6000(Blackwell)
VPC 직접 연결 이그레스: VPC 직접 연결 이그레스를 통해 1분 이내에 IP를 할당하여 서버리스 컨테이너를 비공개 VPC 네트워크에 직접 바인딩합니다. 이를 통해 공개 인터넷을 거치거나 기존 커넥터 VM을 사용하지 않고도 내부 데이터 레이크, 데이터베이스, 비공개 API에 안전하고 지연 시간이 짧은 액세스를 제공합니다.

요약

Google Cloud 네트워킹 옵션은 다양한 가속기 유형을 지원합니다. 유연한 컴퓨팅을 활용하면 워크로드 성능을 최적화하는 최상의 설계에 맞춰 네트워크 구성을 조정할 수 있습니다.

다음 단계

다음 리소스를 통해 Google Cloud AI 인프라 및 네트워킹 아키텍처를 자세히 살펴보세요.

질문이 있거나, 자세한 내용이 궁금하거나, 의견을 공유하고 싶으신가요? LinkedIn을 통해 저에게 알려주세요.

AI 에이전트 빌드의 기초를 다질 수 있는 기회

Fri, 02 Oct 2026 02:00:00 +0000

최근 'AI 에이전트'에 대한 이야기를 많이 들었지만 실제로 어떻게 빌드해야 할지 잘 모르겠나요? 머신러닝에 대한 배경지식이나 수년간의 소프트웨어 경험이 없어도 시작할 수 있습니다. 가장 좋은 학습 방법은 직접 해 보는 것입니다. 그래서 Agent Valley를 빌드했습니다.

Agent Valley는 5주간 진행되는 무료 라이브 학습 시리즈로, 처음부터 시작해 나만의 실습형 에이전트 시스템을 빌드할 수 있도록 설계되었습니다. 지루한 터미널 줄을 쳐다보는 대신 작고 로우 폴리곤의 가상 세계에서 빌드하고 플레이할 수 있습니다.

강사 소개

Google의 우수 DevRel 엔지니어 중 한 명인 애니 왕이 직접 알려드립니다. 이 과정은 처음부터 끝까지 실습 위주로 진행되며, 상호작용이 가능하고 초보자도 쉽게 따라 할 수 있도록 설계되었습니다. Google에서 AI 시스템을 실제로 설계하는 사람들이 AI 시스템을 빌드하는 방법을 배우고 싶다면 이번 기회를 놓치지 마세요.

학습 방식

노트북의 분할 화면 작업공간에서 빌드하면서 학습합니다. 첫날에는 플레이 캐릭터이자 저장 파일 역할을 하는 커스텀 로우 폴리 동료를 설명하고 소환합니다. 동료를 이끌고 계곡의 5개 구역을 탐험하는 동안 게임 바로 옆에 실시간 런타임 검사기가 표시되어 AI가 실시간으로 무엇을 생각하고 결정하며 비용을 얼마나 지출하는지 정확히 보여줍니다. 설정 과정이 전혀 어렵지 않습니다. Google에서 이러한 실습을 실행할 수 있는 환경을 제공하므로 바로 빌드를 시작할 수 있습니다.

5개의 모듈식 세션으로 구성된 Agent 101 라이브 (언제든지 참여 가능)

1주 차: 소환의 숲 (제어) · 동료를 소환하고 대화 전반에 걸쳐 동료의 기억과 특성을 일관되게 유지하는 방법을 알아보세요.
2주 차: 빌드야드 (분해) · 여러 AI 어시스턴트가 서로의 작업을 방해하지 않고 병렬로 협업할 수 있도록 대규모 프로젝트를 분해하는 방법을 알아봅니다.
3주 차: 마켓 스트리트 (COORDINATE) · 가상 매장을 열어 보세요. 트랜잭션과 반품이 원활하게 진행되고 충돌이 발생하지 않도록 안정적인 코드를 작성하는 방법을 배웁니다.
4주 차: 보관함 (기억하기) · 동반자에게 추억을 선물하세요. 에이전트가 혼동하거나 내용을 지어내지 않고도 과거의 세부정보를 기억하도록 돕는 방법을 알아보세요.
5주 차: 야시장 (라이브) · 대단원의 막을 내립니다. 시스템을 빠르고 저렴하게 유지하면서 에이전트가 불꽃놀이나 무대 조명과 같은 세상의 이벤트에 실시간으로 반응하도록 만드는 방법을 알아보세요.

라이브 스트림에 참여하세요

5 화 9월 1일 시작 · 오전 10:00 (태평양 표준시)
코딩과 플레이를 통해 배우고 싶어 하는 AI 에이전트 초보자
참석 신청하기: goo.gle/agent101

Cloud Run 샌드박스에서 AI 생성 코드를 안전하게 실행

Thu, 01 Oct 2026 21:00:00 +0000

Google Cloud에서 자주 듣는 질문이 있습니다. 호스트 애플리케이션, 데이터, 클라우드 사용자 인증 정보를 위험에 빠뜨리지 않고 AI 생성 코드나 신뢰할 수 없는 바이너리를 안전하게 실행하려면 어떻게 해야 할까요? 즉, 권한이 더 높은 신뢰할 수 있는 프로그램과 완전히 분리된 안전한 공간을 AI로 작성된 프로그램에 어떻게 제공할 수 있을까요?

지금까지 개발자는 컨테이너 클러스터를 사용하여 복잡한 샌드박스 인프라를 빌드하거나 특수한 서드 파티 microVM 런타임에 대한 비용을 지불해야 했습니다.

오늘 WeAreDevelopers World Congress에서 Google Cloud Run 샌드박스의 공개 프리뷰를 발표합니다. Cloud Run 샌드박스는 신뢰할 수 없는 코드와 에이전트 워크로드를 실행하기 위해 특별히 빌드된 기본 제공의 안전한 초고속 런타임 환경으로, 밀리초 단위로 시작됩니다.

다음 예시에서는 평균 지연 시간 500ms로 1,000개의 샌드박스를 시작, 실행, 중지하는 Cloud Run 서비스에서 신뢰할 수 없는 Python 코드를 안전하게 실행하기 위해 요청을 보냅니다.

이 게시물에서는 이 기능과 핵심 사용 사례에 대해 자세히 알아보겠습니다.

Cloud Run 샌드박스란 무엇인가요?

Cloud Run 샌드박스는 기존 Cloud Run 서비스 인스턴스 내에서 거의 즉시 생성할 수 있는 경량의 격리된 실행 경계입니다.

LLM이 동적으로 생성된 Python 스크립트를 실행하여 비즈니스 마진을 계산하거나, 헤드리스 브라우저를 가동하여 웹 조사를 수행해야 하는 경우 Cloud Run 샌드박스는 서버리스 환경을 벗어나지 않고도 이러한 태스크를 실행할 수 있는 안전한 격리된 샌드박스를 제공합니다.

핵심 사용 사례

LLM 코드 인터프리터: AI 제품에 고급 데이터 분석 기능을 빌드합니다. 모델이 Python, R 또는 SQL 코드를 작성하고 실행하여 데이터 세트를 분석하고, 차트를 생성하고, 복잡한 수학 연산을 안전하게 수행할 수 있습니다.
헤드리스 브라우저: 에이전트에게 브라우저를 실행할 수 있는 안전한 환경을 제공합니다. 호스트 머신을 위험에 빠뜨리지 않고 웹페이지를 안전하게 스크랩하고, 스크린샷을 찍고, 웹 워크플로를 자동화할 수 있습니다.
사용자 제출 코드 실행: AI 외에도 Cloud Run에서 호스팅되는 플랫폼은 샌드박스를 사용하여 자체 최종 사용자가 업로드한 커스텀 스크립트, 플러그인 또는 웹훅을 안전하게 실행할 수 있습니다.

작동 방식: 개발자 경험

Cloud Run 서비스에서 샌드박스를 사용 설정하는 방법은 배포에 단일 플래그를 추가하는 것만큼 간단합니다.

1단계: 샌드박스 런처 사용 설정

Cloud Run 서비스를 배포할 때 gcloud 또는 YAML 구성을 통해 샌드박스 런처를 사용 설정합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud beta run deploy my-agent-service \\\r\n --image=gcr.io/my-project/agent-image \\\r\n --sandbox-launcher'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbb0c21c350>)])]>

2단계: 코드에서 샌드박스를 기본적으로 생성

사용 설정하면 경량 샌드박스 CLI 바이너리가 실행 환경에 자동으로 마운트됩니다. 에이전트 애플리케이션은 표준 하위 프로세스 호출을 사용하여 프로그래매틱 방식으로 샌드박스를 생성할 수 있습니다.

LLM이 생성한 신뢰할 수 없는 Python 스크립트를 얼마나 쉽게 실행할 수 있는지 보여드리겠습니다.

code_block: <ListValue: [StructValue([('code', 'import subprocess\r\n\r\ndef run_untrusted_code(llm_code: str):\r\n # 1. Write the untrusted LLM code to a local file\r\n with open("/tmp/generated_script.py", "w") as f:\r\n f.write(llm_code)\r\n \r\n # 2. Run it inside the secure sandbox\r\n # The sandbox shares your container\'s filesystem tools but runs in a secure silo\r\n result = subprocess.run(\r\n ["sandbox", "do", "--", "python3", "/tmp/generated_script.py"],\r\n capture_output=True,\r\n text=True,\r\n timeout=10\r\n )\r\n \r\n return result.stdout if result.returncode == 0 else result.stderr'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbb0c21cb90>)])]>

보안 내재화 설계: 기본적으로 제로 트러스트

Cloud Run 샌드박스는 악의적이거나 잘못된 코드 실행으로부터 호스트 애플리케이션과 클라우드 리소스를 보호하도록 설계되었습니다. 런타임은 다음 세 가지 중요한 보안 경계를 적용합니다.

1. 사용자 인증 정보 및 환경 격리: 이러한 샌드박스는 Cloud Run 서비스의 환경 변수에 액세스할 수 없으며 Google Cloud 메타데이터 서버를 호출할 수도 없습니다.

2. 잠긴 네트워크 이그레스 (기본 거부): 기본적으로 샌드박스는 아웃바운드 네트워크 액세스가 전혀 없습니다. 악의적인 서버로 데이터를 무단 반출하려는 스크립트를 실행하도록 에이전트를 속이는 경우 네트워크 요청은 시스템 레이어에서 차단됩니다. 이그레스는 명시적으로 요청된 경우에만 사용 설정할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'sandbox do --allow-egress -- curl https://api.github.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff777290>)])]>

3. 안전한 파일 시스템 오버레이: 샌드박스는 컨테이너의 파일 시스템에 대한 읽기 전용 뷰로 실행되므로 설치된 패키지, Python 런타임, 바이너리를 사용할 수 있지만 모든 변경사항은 격리된 임시 메모리 오버레이에 기록됩니다. 샌드박스 실행이 종료되면 생성된 모든 파일이 폐기됩니다. 샌드박스 전반에서 재사용할 수 있도록 필요에 따라 파일을 가져오고 내보낼 수 있습니다.

code_block: <ListValue: [StructValue([('code', '# Write data from the sandbox to an archive file that can be persisted\r\nsandbox do --write --export-tar=/tmp/work.tar \\\r\n -- /bin/bash -c "mkdir -p /tmp/work && echo \'task-complete\' > /tmp/work/status.txt"\r\n\r\n# Import the archive file in a new sandbox\r\nsandbox do --write --import-tar=/tmp/work.tar \\\r\n -- /bin/bash -c "cat /tmp/work/status.txt"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed09910>)])]>

ADK 및 ComputeSDK 기본 제공 지원

Cloud Run 샌드박스는 새로운 에이전트 개발 키트의 다음 버전에서 CloudRunSandboxCodeExecutor와 함께 지원됩니다. 이 통합을 통해 Cloud Run에서 실행되는 ADK 에이전트는 단일 라인으로 코드를 실행할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'from google.adk.agents import Agent\r\nfrom google.adk.integrations.cloud_run import CloudRunSandboxCodeExecutor\r\n\r\nanalyst_agent = Agent(\r\n name="cloud_run_data_analyst",\r\n model="gemini-3.1-pro-preview",\r\n system_instruction=(\r\n "You are an expert data analyst. Write and execute Python code to answer "\r\n "user questions and process data safely."\r\n ),\r\n code_executor=CloudRunSandboxCodeExecutor(),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafed0b450>)])]>

샌드박스를 실행하기 위한 벤더 불문 SDK인 ComputeSDK에도 Cloud Run 샌드박스가 추가되었습니다. 이 SDK를 사용하면 Cloud Run 서비스 외부에서 샌드박스를 원격으로 호출하거나 서비스에서 로컬 도구로 직접 사용할 수 있습니다. Cloud Run 샌드박스에 이 SDK를 사용하는 방법은 여기에서 확인할 수 있습니다.

지금 시작하기

온디맨드 가상 머신에 높은 프리미엄을 부과하는 전용 샌드박스 호스팅 플랫폼과 달리 Cloud Run 샌드박스는 기존에 할당된 CPU와 메모리에서 직접 실행됩니다. 샌드박스는 실행 중인 인스턴스의 리소스를 공유하므로 이 기능을 사용하는 데 추가 비용이나 프리미엄이 들지 않습니다. 문서는 여기에서 확인할 수 있습니다.

Kotlin용 Google 생성형 AI SDK 1.0 발표: Gemini에 대한 관용적인 멀티플랫폼 액세스

Thu, 01 Oct 2026 19:00:00 +0000

Kotlin 애플리케이션에 최신 생성형 AI 기능을 통합하기 위해 원시 HTTP 클라이언트를 조작하거나 서로 다른 Java 라이브러리를 연결할 필요가 없습니다. 오늘 Kotlin용 Google 생성형 AI SDK 1.0 출시(google-genai-kotlin)를 발표하게 되어 기쁩니다. 지금 바로 GitHub의 googleapis/kotlin-genai에서 코드를 살펴보고, 실행 가능한 샘플을 탐색하고, 프로젝트에 별표를 표시할 수 있습니다.

Kotlin 멀티플랫폼(KMP) 라이브러리로 처음부터 빌드된 이 SDK는 JVM(백엔드 서비스, 서버리스 함수, 데스크톱)과 Android를 모두 타겟팅하는 개발자에게 관용적인 Kotlin 패러다임(퍼스트 클래스 코루틴, 비동기 Flow 스트리밍, 이름이 지정된 기본 파라미터가 있는 변경 불가능한 데이터 클래스 포함)을 제공합니다.

이 SDK는 최소한의 구성 조정으로 Gemini Developer API(Google AI Studio)와 Gemini Enterprise Agent Platform(Google Cloud 기반) 모두와 상호작용할 수 있는 통합 영역을 제공합니다.

1. 시작하기: 종속 항목 추가

SDK는 com.google.genai:google-genai-kotlin 아래의 Maven Central에 게시됩니다.

Kotlin 멀티플랫폼(KMP)

멀티플랫폼 애플리케이션의 경우 commonMain 소스 세트에 종속 항목을 추가합니다.

code_block: <ListValue: [StructValue([('code', '// build.gradle.kts\r\nkotlin {\r\n sourceSets {\r\n commonMain.dependencies {\r\n implementation("com.google.genai:google-genai-kotlin:1.0.0")\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff910f10>)])]>

표준 JVM 프로젝트

단일 플랫폼 Kotlin 프로젝트의 경우 Gradle은 Gradle 모듈 메타데이터를 통해 최적의 변형을 자동으로 선택합니다.

code_block: <ListValue: [StructValue([('code', '// build.gradle.kts\r\ndependencies {\r\n implementation("com.google.genai:google-genai-kotlin:1.0.0")\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0c9750>)])]>

2. 단항 및 스트리밍 텍스트 생성 및 채팅

기본 진입점은 Client 클래스입니다. 환경 변수(Google AI Studio의 경우 GEMINI_API_KEY 또는 GOOGLE_API_KEY, 표준 Google Cloud 애플리케이션 기본 사용자 인증 정보의 경우 GOOGLE_GENAI_USE_ENTERPRISE=true)를 기반으로 HTTP 연결 및 인증을 자동으로 관리합니다.

Gemini Flash를 사용한 단일 프롬프트 요청

Kotlin의 use 확장 프로그램을 사용하면 클라이언트의 기본 네트워크 엔진과 HTTP 연결이 깔끔하게 해제됩니다.

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val response = client.models.generateContent(\r\n model = "gemini-flash-latest",\r\n text = "Explain quantum entanglement in two sentences."\r\n )\r\n\r\n println(response.text)\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0cb210>)])]>

코루틴을 사용한 지연 시간이 짧은 스트리밍 `Flow`

대화형 UI 및 반응형 CLI 도구의 경우 generateContentStream은 콜드 Kotlin 코루틴 Flow<GenerateContentResponse>를 반환하여 토큰 청크를 실시간으로 전송합니다.

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val responseFlow = client.models.generateContentStream(\r\n model = "gemini-flash-latest",\r\n text = "Outline the key architectural patterns for microservices on Google Cloud."\r\n )\r\n\r\n responseFlow.collect { chunk ->\r\n chunk.text?.let { print(it) }\r\n }\r\n println()\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0cb490>)])]>

멀티턴 대화(채팅)

요청 차례마다 대화 기록을 수동으로 관리하는 것은 번거로울 수 있습니다. SDK에는 컨텍스트를 자동으로 유지하고, 대화를 추가하고, 대화 기록의 형식을 지정하고, 함수 호출을 처리하는 전용 chat 서비스가 포함되어 있습니다.

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport com.google.genai.kotlin.types.Content\r\nimport com.google.genai.kotlin.types.GenerateContentConfig\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val config = GenerateContentConfig(\r\n systemInstruction = Content.fromText("You are an expert Google Cloud Solutions Architect.")\r\n )\r\n\r\n // Create a multi-turn chat session\r\n val chat = client.chats.create(\r\n model = "gemini-flash-latest",\r\n config = config\r\n )\r\n\r\n // Turn 1\r\n val firstResponse = chat.sendMessage("We are designing an event-driven ingestion pipeline on Google Cloud.")\r\n println("Gemini: ${firstResponse.text}\\n")\r\n\r\n // Turn 2: context from the first turn is included automatically\r\n val secondResponse = chat.sendMessage("Which managed messaging service should we choose: Pub/Sub or Kafka?")\r\n println("Gemini: ${secondResponse.text}\\n")\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0c8d10>)])]>

chat.sendMessageStream(...)을 사용하여 멀티턴 채팅 대답을 스트리밍할 수도 있습니다.

3. Google 검색을 사용해 그라운딩된 멀티모달 분석

Gemini의 멀티모달 추론은 외부 검증과 결합할 때 특히 효과적입니다. 예를 들어 기술, 의료 또는 과학 다이어그램을 분석할 때 Google 검색 그라운딩을 연결하여 실시간 웹 소스와 사실 주장을 교차 검증할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport com.google.genai.kotlin.types.*\r\nimport java.io.File\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val imageBytes = File("src/main/resources/medical_diagram.png").readBytes()\r\n\r\n val content = Content(\r\n parts = listOf(\r\n Part(inlineData = Blob(mimeType = "image/png", data = imageBytes)),\r\n Part(text = "Is this anatomical diagram accurate? Verify labels against authoritative medical sources.")\r\n )\r\n )\r\n\r\n // Enable Google Search as a grounding tool\r\n val config = GenerateContentConfig(\r\n tools = listOf(Tool(googleSearch = GoogleSearch()))\r\n )\r\n\r\n val response = client.models.generateContent(\r\n model = "gemini-flash-latest",\r\n content = content,\r\n config = config\r\n )\r\n\r\n println("=== Analysis ===")\r\n println(response.text)\r\n\r\n // Inspect citations and search queries\r\n val grounding = response.groundingMetadata\r\n println("\\n=== Search Queries Executed ===")\r\n grounding?.webSearchQueries?.forEach { println("- $it") }\r\n\r\n println("\\n=== Grounding Sources ===")\r\n grounding?.groundingChunks?.mapNotNull { it.web }?.forEach { source ->\r\n println("- ${source.title}: ${source.uri}")\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0c9290>)])]>

4. 시각적 생성 및 대화 기반 수정: Gemini 3 이미지 제품군

SDK는 Google의 최신 이미지 생성 모델(리더보드에서 Nano Banana 시리즈 모델로 널리 알려짐)을 완벽하게 지원합니다.

이미지 생성 및 저장

생성된 이미지 바이트는 대답 부분에서 Blob으로 직접 전달됩니다.

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport java.io.File\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val response = client.models.generateContent(\r\n model = "gemini-3.1-flash-image", // Nano Banana 2\r\n text = "A photorealistic blueprint of an eco-friendly modern datacenter, isometric view, 4k"\r\n )\r\n\r\n val imagePart = response.parts?.firstOrNull { it.inlineData != null }\r\n imagePart?.inlineData?.data?.let { bytes ->\r\n File("datacenter_blueprint.png").writeBytes(bytes)\r\n println("Image generated and saved successfully.")\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0ca490>)])]>

대화형 이미지 간 편집

동일한 요청에서 기존 이미지와 대화 기반 수정 요청 사항을 전달할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'val originalImage = File("input.png").readBytes()\r\n\r\nval editPrompt = Content(\r\n parts = listOf(\r\n Part(inlineData = Blob(mimeType = "image/png", data = originalImage)),\r\n Part(text = "Change the daylight illumination to a dramatic twilight skyline with illuminated windows.")\r\n )\r\n)\r\n\r\nval editResponse = client.models.generateContent(\r\n model = "gemini-3-pro-image", // Nano Banana Pro\r\n content = editPrompt\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0ca790>)])]>

5. Gemini Live와의 실시간 양방향 상호작용

지연 시간이 짧은 음성, 오디오, 실시간 멀티모달 상호작용을 위해 SDK는 client.live.connect(...)를 사용하여 지속적인 WebSocket 연결을 통해 Gemini Live API를 지원합니다.

code_block: <ListValue: [StructValue([('code', 'import com.google.genai.kotlin.Client\r\nimport com.google.genai.kotlin.types.AudioTranscriptionConfig\r\nimport com.google.genai.kotlin.types.LiveConnectConfig\r\nimport kotlinx.coroutines.launch\r\nimport kotlinx.coroutines.runBlocking\r\n\r\nfun main() = runBlocking {\r\n Client().use { client ->\r\n val model = if (client.enterprise) "gemini-live-2.5-flash-native-audio"\r\n else "gemini-3.1-flash-live-preview"\r\n\r\n val config = LiveConnectConfig(\r\n outputAudioTranscription = AudioTranscriptionConfig()\r\n )\r\n\r\n // Establish real-time bidirectional WebSocket session\r\n client.live.connect(model, config).use { session ->\r\n println("Connected to Gemini Live session!")\r\n\r\n // Launch collector for server messages (audio and text transcriptions)\r\n val receiveJob = launch {\r\n session.receive().collect { serverMessage ->\r\n serverMessage.serverContent?.outputTranscription?.text?.let { text ->\r\n print(text)\r\n }\r\n }\r\n }\r\n\r\n // Stream real-time text (or raw PCM audio blobs via session.sendRealtimeInput(audio = ...))\r\n session.sendRealtimeInput(text = "Hello Gemini! Give me a 5-second motivational quote.")\r\n\r\n // When finished, clean up\r\n receiveJob.cancel()\r\n session.closeSession()\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0cbf90>)])]>

6. 정형 도구 및 함수 호출

에이전트형 워크플로를 빌드하거나 LLM을 백엔드 마이크로서비스와 연결할 때 개발자는 FunctionDeclaration을 통해 정형 JSON 스키마를 전달할 수 있습니다. 모델은 도구를 호출할 시점을 지능적으로 선택합니다.

code_block: <ListValue: [StructValue([('code', 'val telemetryTool = FunctionDeclaration(\r\n name = "getDatacenterMetrics",\r\n description = "Fetch real-time CPU and thermal telemetry for a Google Cloud region",\r\n parameters = Schema(\r\n type = Type.OBJECT,\r\n properties = mapOf("region" to Schema(type = Type.STRING)),\r\n required = listOf("region")\r\n )\r\n)\r\n\r\nval response = client.models.generateContent(\r\n model = "gemini-flash-latest",\r\n text = "Check telemetry for europe-west1",\r\n config = GenerateContentConfig(\r\n tools = listOf(Tool(functionDeclarations = listOf(telemetryTool)))\r\n )\r\n)\r\n\r\nresponse.functionCalls?.firstOrNull()?.let { call ->\r\n println("Model triggered tool: ${call.name} with arguments: ${call.args}")\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0c9ad0>)])]>

또한 채팅 서비스를 사용할 때 자동 함수 호출(AFC)을 활용할 수 있습니다. 즉, 다음 예시에서 볼 수 있듯이 채팅 대화에서 선언된 함수를 SDK가 자동으로 투명하게 호출할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'fun main() = runBlocking {\r\n // A mocked function\r\n val getWeather = callableFunction("get_weather", paramName = "city") { city: String ->\r\n "18 degrees and sunny in $city"\r\n }\r\n\r\n Client().use { client ->\r\n val chat = client.chats.create(\r\n model = "gemini-flash-latest",\r\n automaticFunctionCalling = AutomaticFunctionCalling(getWeather),\r\n )\r\n\r\n // SDK calls get_weather if needed in this conversation\r\n println(chat.sendMessage("What is the weather in Zurich?").text)\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbaff0cbdd0>)])]>

다음 단계

Kotlin용 Google 생성형 AI SDK 1.0 출시로 백엔드 서버 생태계(Ktor, Spring Boot, Quarkus, Micronaut)와 모바일 애플리케이션 전반의 Kotlin 개발자는 이제 생성형 AI 애플리케이션을 빌드하기 위한 깔끔한 멀티플랫폼 기반을 갖추게 되었습니다.

자세히 알아보고 시작하려면 다음 리소스를 확인하세요.

GitHub 저장소: github.com/googleapis/kotlin-genai에서 소스, 별표, 토론을 확인하세요.
문서 및 샘플: Kotlin 생성형 AI 샘플 모음을 살펴보세요.
피드백: GitHub에서 직접 문제를 신고하거나, 기능을 제안하거나, pull 요청을 제출하세요.

Kotlin과 Gemini로 빌드할 멋진 결과물을 기대하겠습니다.

Spanner 마이그레이션: Antigravity CLI를 사용한 이중 쓰기 자동화로 중단 최소화

Thu, 01 Oct 2026 19:00:00 +0000

기존 데이터 레이어를 현대화해야 했던 Google의 재무 엔지니어링팀은 고가용성 기능을 제공하고 전 세계에 분산된 strong consistency를 갖춘 멀티모델 데이터베이스인 Spanner를 선택했습니다. 하지만 프로덕션 서비스를 오프라인으로 전환하지 않고 Spanner로 마이그레이션하는 것은 엔지니어링 측면에서 어려운 과제였습니다. 애플리케이션을 담당하는 내부 팀으로서 수십 개의 데이터 액세스 객체(DAO)에서 이중 쓰기 로직을 수동으로 다시 작성해야 했는데, 이 프로세스는 시간도 오래 걸리고 인적 오류가 빈번하게 발생했습니다. 또한 중단 없이 이 작업을 수행하려면 코드베이스의 모든 DAO에서 여러 단계에 걸쳐 이중 쓰기 아키텍처를 구현해야 했습니다.

이 문제를 해결하기 위해 다른 접근 방식을 취했습니다. 헤드리스 모드에서 Antigravity CLI를 사용하는 자동화된 리팩터링 파이프라인을 빌드했습니다. 이를 통해 프로덕션 환경을 준비하는 동안 스테이징 환경에서 엄격한 데이터 동등성을 유지하면서 마이그레이션 속도를 크게 높일 수 있었습니다.

과제: 이중 쓰기 마이그레이션의 구조

재무 정보 정확성이 필수적인 높은 처리량의 프로덕션 서비스를 마이그레이션할 때는 단순한 컷오버 스크립트로는 충분하지 않습니다. 모든 이전 데이터 백필 및 검증이 완료될 때까지 기존 데이터 스토어와 Spanner 양쪽에 동일한 쓰기 작업이 동시에 이루어지는지 확인해야 합니다.

마이그레이션은 다음과 같은 세 가지 단계로 구성했습니다.

이전 백필: 참조 무결성을 유지하면서 기존의 이전 기록을 Spanner에 복사합니다.
이중 쓰기/이중 읽기 구현: 마이그레이션 기간 동안 모든 DAO를 수정하여 기본 데이터 스토어와 Cloud Spanner에 모두 변경 사항을 동시에 기록합니다.
자동화된 API 검증 및 동등성 검사: RPC 트래픽을 가로채고 모든 쓰기 작업이 두 저장소에서 바이트 단위로 동일하게 기록되는지 엔드 투 엔드로 검증합니다.

아키텍처 패턴은 깔끔했지만 현재 규모에서는 마찰이 발생하기 시작했습니다. 각 DAO에는 다음이 필요하기 때문입니다.

복잡한 도메인 모델을 Spanner 스키마 열에 매핑하는 전용 MutationConverter 클래스
이중 쓰기 브랜치 처리 및 롤백 또는 오류 보고 로직
FakeTimeSource와 같은 가짜 시간 소스와 테스트 더블을 사용하여 기본 데이터 스토어와 Spanner에서 모두 쓰기 작업을 검증하는 단위 테스트 모음

30개가 넘는 DAO에 정밀도가 높은 이러한 코드 변경을 동일하게 수동으로 수행하려면 엔지니어링 작업에 수개월이 걸렸을 것입니다.

솔루션: 표준화된 변형 컨버터 패턴

자동화 파이프라인이 안정적으로 깔끔한 코드를 생성할 수 있는지 검증하기 위해 먼저 분리된 MutationConverter 인터페이스를 중심으로 DAO 리팩터링 패턴을 표준화했습니다.

핵심 DAO 비즈니스 로직 내에 원시 Spanner 테이블 이름과 열 할당을 직접 삽입하는 대신 Spanner 스키마 변환을 전용 컨버터 단위로 분리했습니다.

code_block: <ListValue: [StructValue([('code', '// Example of the standardized pattern generated by our pipeline\r\n\r\ntype BpcTransferAmountsMutationConverter interface {\r\n ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n ToUpdateMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n}\r\n\r\ntype bpcTransferAmountsMutationConverterImpl struct {\r\n tableName string\r\n}\r\n\r\nfunc (c *bpcTransferAmountsMutationConverterImpl) ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error) {\r\n if entity == nil {\r\n return nil, errors.New("entity cannot be nil")\r\n }\r\n \r\n // Map domain fields to Cloud Spanner table schema\r\n cols := []string{"TransferId", "AmountCents", "CurrencyCode", "LastModifiedTimestamp"}\r\n vals := []interface{}{\r\n entity.TransferId,\r\n entity.AmountCents,\r\n entity.CurrencyCode,\r\n spanner.CommitTimestamp, // Use Spanner commit timestamps\r\n }\r\n \r\n return spanner.Insert(c.tableName, cols, vals), nil\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbafee1ded0>)])]>

DAO와 Spanner SDK(spanner.Mutation) 간에 엄격하고 결정론적인 계약을 수립함으로써 AI 코딩 에이전트가 추론하고 안정적으로 생성할 수 있는 정확한 대상 사양을 만들었습니다.

헤드리스 모드에서 Antigravity CLI를 사용하는 이유

IDE의 대화형 AI 채팅 인터페이스는 탐색적인 코딩 작업에는 적합하지만 전체 코드베이스에서 여러 파일을 체계적으로 업데이트하는 작업에는 적합하지 않습니다. 예외 상황을 놓치지 않으면서 수십 개의 대상에 반복 가능한 리팩터링을 적용해야 하는 경우 자동화된 워크플로가 필요합니다.

이에 따라 헤드리스 모드(-p)에서 Antigravity CLI를 실행하는 조정 스크립트(migration_ui.py)를 빌드하여 이 문제를 해결했습니다.

헤드리스 모드를 사용하면 수동으로 터미널에 프롬프트를 입력할 필요 없이 Antigravity를 셸 스크립트, 지속적 통합 파이프라인, 백그라운드 자동화 작업 내에서 직접 실행할 수 있습니다. 이러한 접근 방식을 통해 다음의 세 가지 주요 방향으로 작업을 확장할 수 있었습니다.

결정론적 프롬프트 아키텍처: 프롬프트를 버전 제어가 가능한 엔지니어링 아티팩트로 취급했습니다. 타임스탬프 직렬화, null 허용 여부 변환, 변형 모호성, FakeTimeSource 테스트 주입과 같은 일반적인 Spanner 예외 상황을 처리하기 위한 정확한 규칙을 재사용 가능한 프롬프트 템플릿에 직접 성문화했습니다.
일괄 실행 및 자동 검증: 조정 스크립트는 대상 DAO 이름을 입력으로 받아 기존의 단일 쓰기 소스 코드와 스키마를 가져온 후 구조적 규칙과 함께 헤드리스 모드의 Antigravity에 전달합니다. Antigravity는 새로운 컨버터, 리팩터링된 이중 쓰기 DAO, 해당 단위 테스트를 생성합니다. 그런 다음 스크립트가 Blaze 테스트를 실행합니다. 린터 오류 또는 테스트 어설션이 실패하면 오류 로그가 Antigravity에 직접 전달되어 자체 수정됩니다.
대규모 야간 실행: 루프가 무인으로 실행되므로 엔지니어는 하루 일과가 끝날 때 10개의 DAO를 큐에 추가할 수 있습니다. 그러면 다음 날 아침까지 파이프라인은 10개의 변경 목록을 생성, 테스트, 검증하여 사람이 코드 검토를 할 수 있도록 준비합니다.

결과 및 클라우드 엔지니어를 위한 핵심 내용 정리

Spanner의 분산 데이터베이스 기본 요소와 Antigravity CLI의 헤드리스 자동화를 결합한 결과, 엔지니어링 조직 전반에서 다음과 같은 분명한 이점을 얻을 수 있었습니다.

마이그레이션 작업량 대폭 감소: 이전에는 광범위한 수동 코딩과 테스트가 필요했던 DAO 이중 쓰기 마이그레이션이 훨씬 짧은 시간 내에 완료되고 검토되었습니다.
높은 안정성의 데이터 마이그레이션: 생성된 모든 DAO가 동일한 테스트를 거친 MutationConverter 패턴을 준수하고 Spanner 테스트 더블에 대한 자동화된 단위 테스트를 거쳤기 때문에 광범위한 마이그레이션 테스트 중에도 높은 수준의 데이터 충실도를 유지할 수 있었습니다.
더 가치 있는 엔지니어링 업무에 집중: 엔지니어는 반복적인 상용구 리팩터링을 피하고 데이터 모델링, 아키텍처 복원력, 성능 최적화 등에 집중할 수 있는 시간을 확보했습니다.

다음 데이터베이스 마이그레이션을 위한 3가지 팁

스키마 변환을 먼저 분리: 마이그레이션 스크립트를 작성하기 전에 기존 비즈니스 로직에서 새로운 클라우드 데이터베이스 SDK 요구사항을 격리하는 엄격한 인터페이스(예: MutationConverter)를 정의하세요. AI 에이전트는 명확하고 제한된 설계 패턴이 주어질 때 가장 효과적으로 작동합니다.
양방향 채팅에서 헤드리스 자동화로 전환: 3~4개 이상의 파일에서 반복적인 리팩터링을 실행할 때는 스크립트 기반의 헤드리스 워크플로에 투자하세요. 프롬프트 입력과 테스트 검증을 자동화된 빌드 단계로 처리하면 품질과 일관성을 유지하는 데 도움이 됩니다.
빌드 시스템을 가드레일로 활용: AI 생성 루프를 빌드 및 테스트 하네스(bazel test 또는 go test)에 직접 연결하세요. 이를 통해 모델은 개발자가 코드를 검토하기 전에 컴파일 및 어설션 오류를 수정할 수 있습니다.

시작하기

금융 시스템을 마이그레이션하는 경우에도, 클라우드 네이티브 애플리케이션을 처음부터 빌드하는 경우에도 Spanner와 Antigravity는 확장 가능한 소프트웨어 개발을 위한 기반을 제공합니다.

Cloud Spanner 살펴보기: Google Cloud Spanner 문서에서 Spanner의 분산 아키텍처에 대해 자세히 알아보세요.
개발자를 위한 Gemini 알아보기: 개발자를 위한 Google Cloud AI에서 AI 지원 코딩과 헤드리스 CLI 자동화가 엔지니어링 워크플로에 어떤 도움이 되는지 알아보세요.

개발 및 IT운영

Gemini에서 MCP 앱을 구현하기 위한 개발자 가이드

MCP 앱이 필요한 이유

Gemini에서 MCP 앱을 빌드하면 얻을 수 있는 6가지 이점:

상위 수준 아키텍처

독립적인 두 레이어를 통한 인증

Google Cloud에 빌드 및 배포하고 Gemini Enterprise에 등록

직접 빌드해보기

이제 Google Antigravity에서 사용할 수 있는 Claude Opus 5.5와 Claude Sonnet 5.5

Antigravity의 멀티 모델 엔지니어링 패턴

패턴 1: 루프 및 그래프 워크플로의 교차 모델 검증('LLM-as-a-Judge')

패턴 2: 추론 모델과 Flash 하위 에이전트 페어링

시작하기

에이전트 플러그인 빌드를 통해 배운 4가지 평가 엔지니어링 교훈

1. 요약 대신 실행 단계 평가

2. 비동기 작업을 위한 평가 설계

3. 실시간 실행과 '드라이 런'을 나란히 테스트

4. '골든 세트'를 지속 가능한 기준으로 사용

알림: '원샷' 데모 대신 평가 세트를 활용해야 합니다.

다음 단계

에이전트 개발 키트 하나로 5가지 언어 지원

공유 기반

에이전트 중심 시작

각 ADK의 실습 뷰

Python

Go

TypeScript

Java

Kotlin

타협할 필요 없는 선택

MCP 도구 상자 Java SDK v1.0 발표: 엔터프라이즈를 위한 에이전트형 데이터 액세스

MCP: 범용 인터페이스

Java SDK v1.0의 새로운 기능: 프로덕션 워크로드를 위해 빌드

Java SDK v1.0 시작하기

실제 사례: 자율 교통 컨시어지

기반: 네이티브 임베딩이 포함된 AlloyDB 스키마

인텐트를 SQL에 매핑: tools.yaml

Spring Boot의 스테이트풀(Stateful) 에이전트 아키텍처

전체적 그림 보기: Java v1.0에서 도구 나열, 호출, 실행

보안을 우선으로 하는 기본 설정: 인증 및 배포

애플리케이션 기본 사용자 인증 정보(ADC) 및 안전

Cloud Run에 Fleet 배포

지금 시작하기

1단계: 종속 항목 추가

2단계: 리소스 및 데모 살펴보기

Gradle 구현

자동 버전 추적

AI 추론 모델 서빙을 위한 네트워킹 - GKE 전용 및 기타 모든 백엔드

진입점

설계에 포함되는 일반적인 서비스

GKE에서만 서빙되는 설계 패턴

트래픽 흐름 GKE 예시

모든 백엔드에서 서빙되는 설계 패턴

모든 백엔드 트래픽 흐름 예시

다음 단계

GKE CPU 시작 부스트: 과도한 프로비저닝 없는 앱 시작 가속화

현대화된 애플리케이션 부팅 시 추가 CPU가 필요한 이유

CPU 시작 부스트의 작동 방식

내부 작동 방식: Kubernetes 인플레이스 포드 크기 조절

CPU 시작 부스트 작동 방식(포드 수명 주기 개요)

기본 요건 및 가용성

시작하기: CPU 시작 부스트 구성

예시 1: 고정된 안정 상태를 사용하는 포드 수준 부스트(updateMode: "Off")

예시 2: 시작 부스트와 지속적인 VPA 자동 확장의 결합

예시 3: 세분화된 컨테이너 수준 부스트

클러스터에서 시작 부스트 확인

프로덕션 워크로드 권장사항

지금 시작하기

ADK의 그래프 워크플로: 알아야 할 모든 것

단일 에이전트로 시작하기

동시에 독립적인 단계 실행하기

ADK를 사용한 그래프 엔지니어링

각 요청을 적절한 워크플로로 라우팅하기

에이전트 라우터를 통해 의도 파악

결정론적 라우터를 통해 환불 정책 적용

케이스 배치에 동일한 단계 적용하기

결과에 따라 다음 단계 진행하기

다음에 실행할 작업을 결정할 사람 선택하기

시작하기

Google Cloud CLI 원격 MCP 서버로 에이전트 역량 강화

인텐트를 SQL에 매핑: `tools.yaml`

예시 1: 고정된 안정 상태를 사용하는 포드 수준 부스트(`updateMode: "Off"`)