Markdown 버전

AI-translated from English; not yet reviewed by a fluent editor.

# Google, 바이오테크를 위한 세 계층 에이전트 스택 제안

> Google의 바이오테크 참조 설계는 에이전트의 계획 수립, GPU 기반 과학 연산, 접근 제어를 분리한다. 통합 워크플로는 아직 성능이 측정되지 않은 제안이다.

By BIG CHANGE Editorial

Published: 2026-10-18T17:10:34.892Z
Updated: 2026-10-18T17:10:34.892Z
Canonical: https://bigchange.ai/blog/google-biotech-agent-architecture

![Conceptual charcoal illustration of a researcher examining a ball-and-stick molecular model, with generic compute racks in a separate room behind glass.](https://bigchange.ai/api/media/file/google-biotech-compute-concept-v2.png)
AI-generated conceptual illustration by BIG CHANGE; no actual Google facility, completed biotech workflow, drug candidate or test result is depicted.

Google Cloud가 계획을 수립하는 에이전트와 GPU 자원을 많이 쓰는 과학 연산, 그리고 양쪽을 둘러싼 제어를 분리하는 바이오테크 에이전트 참조 아키텍처를 공개했다. [10월 16일 설계 게시물](https://cloud.google.com/blog/topics/healthcare-life-sciences/architecting-scalable-agentic-biotech-workloads)은 신약 개발팀이 Google Cloud에서 단백질 접힘 예측, 분자 생성, 후보물질 검토를 어떻게 조율할 수 있는지 설명한다. 패턴과 예시 스택을 제시하지만, 성능을 측정한 고객 배포 사례나 처리량 결과, 검증된 신약 후보물질을 제시하지는 않는다.

연구용 에이전트 시스템을 평가하는 팀에는 이 구분이 중요하다. 언어 모델은 작업을 배분하고 결과를 요약할 수 있지만, 단백질 구조나 도킹 궤적은 일반적인 채팅 문맥으로 취급하기에는 너무 크다. 과학 연산에는 자체 런타임, 대기열, 접근 제어도 있다. Google의 제안은 이 요소들을 명확한 경계 뒤에 배치해, 팀이 통합 워크플로에 의존하기 전에 각 부분을 살펴볼 수 있게 한다.

## 서로 다른 역할을 맡는 세 계층

첫 번째 계층은 [Agent Runtime](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime)에서 실행되는 주 오케스트레이터다. Google의 예시에는 후보물질 최적화용과 안전성 스크리닝용으로 두 전문 하위 에이전트가 등장한다. 주 에이전트는 요청을 분해하고 작업을 배분해 답변을 조합한다. 이 설계안에서 내부 에이전트 간 인계는 동일한 프로세스 안에서 이뤄진다. Agent Runtime은 관리형 배포 환경이다. Google 문서는 에이전트를 호출하기 전에 프로젝트 설정, Agent Platform SDK for Python, 에이전트 개발과 배포를 거치도록 설명한다. 컨테이너화된 에이전트는 [런타임 계약](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime)을 충족해야 한다.

두 번째 계층은 비용이 많이 드는 과학 작업을 실행한다. Google의 예시는 RTX PRO 6000 Blackwell GPU를 탑재한 G4 가상 머신을 사용해 Google Kubernetes Engine에서 NVIDIA의 ESMFold와 GenMol 추론 마이크로서비스를 구동한다. 단백질 접힘 예측과 분자 생성은 오케스트레이터가 요청하는 작업의 예이며, 범용 언어 모델이 직접 수행하는 계산이 아니다. 게시물은 콜드 스타트 지연을 줄이기 위해 GKE 노드를 적어도 하나 활성 상태로 유지하고 파드가 시작될 때 모델 가중치를 로드하도록 권고한다. 준비된 노드와 로드된 가중치는 자원을 소모하지만, 게시물은 이 선택에 대한 지연 시간, 활용률, 비용 비교를 제공하지 않는다.

세 번째 계층은 접근을 관리한다. [Agent Identity](https://docs.cloud.google.com/iam/docs/agent-identity-overview)는 에이전트에 SPIFFE ID와 관리형 X.509 인증서를 부여하며, 이를 IAM 권한 및 감사 로그와 함께 사용할 수 있다. [Agent Gateway](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview)는 지원되는 인바운드 및 아웃바운드 경로에서 접근 규칙을 적용할 수 있다. [Agent Registry](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-registry)는 에이전트, MCP 서버, 도구, 엔드포인트를 목록화한다. Google은 중요한 영향을 미치는 단계에 Model Armor 검사와 사람의 승인을 적용하는 방안도 제안한다. 이런 제어에는 배포와 정책 설정이 필요하다. 아키텍처 도면에 표시돼 있다는 사실만으로 특정 데이터 경로가 비공개이거나 모든 결정이 감사된다고 볼 수는 없다.

## 파일은 프롬프트가 아니라 스토리지를 통해 전달

이 설계에서 다른 환경에도 가장 쉽게 적용할 수 있는 부분은 대용량 과학 데이터를 다루는 방식이다. 제안된 워크플로는 PDB 파일, 도킹 포즈, 궤적 로그를 Cloud Storage에 기록한다. 에이전트는 객체 참조와 짧은 요약을 교환하고, 도구가 필요로 할 때 원본 데이터를 가져온다. 이렇게 하면 좌표 배열을 LLM의 컨텍스트 창에 밀어 넣지 않아도 되고, 팀은 파일 접근과 보관 기간을 별도로 통제할 수 있다.

Google은 이 패턴에서 서명된 객체 URI를 설명한다. 서명된 URL은 그 자체로 명시된 범위와 유효기간에 대한 접근 자격 증명이므로, 팀은 실제 워크플로의 만료 시간, 권한, 로깅을 여전히 설정해야 한다. 설계 게시물은 운영용 바이오테크 파이프라인의 완전한 스토리지 정책, 데이터 저장 위치 설정, 위협 모델을 문서화하지 않는다. 비공개로 호스팅한 연산 컨테이너가 독점적인 구조 정보를 기업 경계 안에 유지한다는 주장은 스토리지, 모델 호출, 로그, 외부로 향하는 엔드포인트를 포함해 그 구조를 받거나 전달하는 모든 구성 요소에 달려 있다.

게시물은 긴 시뮬레이션 연쇄를 명확한 도구 인터페이스로 감싸고, 단계가 끝날 때마다 진행 상황을 내보내는 방식도 권고한다. 이는 실제 백엔드 대기열에 비춰 평가해야 할 설계 선택이다. 과학 서비스가 요청을 내부적으로 순차 처리한다면 요청을 더 많이 병렬로 보내도 도움이 되지 않는다. 글에는 제안된 구성이 결정론적인 처리량을 갖는다는 벤치마크가 없다.

## 사람의 결정을 어디에 둘 것인가

Google의 제안은 구조 조회나 화학명 확인처럼 되돌릴 수 있는 준비 작업을 에이전트에 맡기되, 비용이 크거나 중요한 영향을 미치는 행동에는 사람의 승인을 요구한다. 예시로는 여러 GPU를 사용하는 도킹 실행, 후보물질을 실제 실험실 합성 단계로 넘기는 일, 프로그램을 보관 처리하는 일이 있다. 연구 조직은 이런 승인 지점과 승인자, 각 지점에서 제시할 근거를 정의해야 한다. 게시물은 검증된 안전성 스크리닝 결과를 보고하지 않으며, 모델이 전문가 검토 없이 약리학적 판단을 내릴 수 있다고 입증하지도 않는다.

거버넌스 문서는 블로그의 일부 포괄적인 표현에 범위를 부여한다. Gateway는 Agent Runtime에서 인바운드와 아웃바운드를 모두 지원하지만 Gemini Enterprise에서는 아웃바운드만 지원한다. 명시적 IAM 정책이 해당 URL을 대상으로 하면 미등록 목적지에도 접근할 수 있으므로, 등록 자체가 알 수 없는 도구를 모두 차단하는 장치는 아니다. Model Armor 검사는 팀이 *설정할 수 있는* 가드레일 중 하나다. Agent Identity의 문서상 제한에는 에이전트 주체에 레거시 Cloud Storage 버킷 역할을 부여할 수 없다는 점이 포함되며, 에이전트를 삭제할 때 IAM 바인딩을 수동으로 정리해야 한다.

검증 측면에서는 Google Cloud가 별도로 소개한 [에이전트 플러그인 평가에서 얻은 네 가지 교훈](https://cloud.google.com/blog/topics/developers-practitioners/four-eval-engineering-lessons/)이 유용한 맥락을 제공한다. 다만 그 플러그인은 다른 시스템이다. 팀은 에이전트의 최종 답변만 판단하면 도구 호출 로그에 드러나는 행동을 놓친다는 사실을 발견했다. 동시 호출 구조를 보존하고, 실제 실행과 계획만 수립하는 실행을 비교하며, 전문가가 선별한 기준 작업을 유지할 것을 권고한다. 이를 바이오테크 제안에 적용하면 실제 스토리지 쓰기, 모델 엔드포인트, 권한 결정, 대기열 동작, 사람의 승인을 확인해야 한다는 뜻이다. BIG CHANGE는 이 아키텍처를 구축하거나 시험하지 않았다.

앞서 다룬 [Google Antigravity의 항균 펩타이드 선별](https://bigchange.ai/blog/google-antigravity-antimicrobial-peptide-candidate-triage)은 다른 과학 에이전트 작업에 관한 것이다. 여기서 제안한 인프라가 구축되거나 검증됐다는 근거가 되지는 않는다.

## 이용 조건, 비용, 출시 상태

팀에는 Google Cloud 프로젝트, 관련 API와 IAM 설정, Agent Runtime 배포, GKE GPU 용량, 스토리지, 설정을 마친 거버넌스 구성 요소가 필요하다. 가용성과 한도는 선택한 리전, 할당량, 제품 구성에 따라 달라진다. [Agent Runtime 문서](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime)는 리전과 할당량 목록을 안내하고 무료 등급을 이용할 수 있다고 설명한다. [Agent Platform 요금 페이지](https://cloud.google.com/products/gemini-enterprise-agent-platform/pricing)는 런타임 연산 및 메모리 과금과 Gateway 아웃바운드 요금 청구를 설명한다. 모델 사용, GPU 인프라, Cloud Storage에는 각각 추가 비용이 발생한다. Google의 [요금 계산기](https://cloud.google.com/products/calculator)로 선택한 구성의 비용을 추산할 수 있다. 항상 준비 상태로 유지하는 GPU 풀도 이 추정에 포함해야 한다.

구성 요소 문서는 사용할 수 있는 서비스를 설명하지만, 그렇다고 통합 바이오테크 패턴이 일반 제공되는 성능 측정 완료 제품이 되는 것은 아니다. Registry의 독립형 스킬은 명시적으로 Preview로 표시돼 있지만, 여기서 확인한 페이지들은 제안된 스택의 모든 요소에 하나의 공통 출시 단계 표기를 적용하지 않는다. 정확한 모델 컨테이너, 네트워크 제어, 연구 애플리케이션 간 호환성은 실제 사용할 리전과 배포 환경에서 확인해야 한다. 이 글은 10월 16일 제안을 문서에 기반해 살펴본 것이며, 설치 안내나 작동 중인 시스템에 대한 보고가 아니다.

## 큰 변화

Google은 바이오테크 에이전트 워크플로를 계획 수립, 전용 과학 연산, 통제된 접근으로 나누는 방식을 제시했다. 대규모 구조 데이터는 참조로 전달하고, 비용이 크거나 중요한 영향을 미치는 행동에는 사람의 승인을 남겨 둔다. 이 설계는 연구 인프라팀이 평가할 구체적인 경계를 제공한다. 속도, 격리, 과학적 신뢰성, 운영 비용은 실제 구성한 배포와 측정 시험을 통해 답해야 할 문제로 남아 있다.

## 출처 및 추가 읽을거리

- [Google Cloud, 「자율성 설계하기」](https://cloud.google.com/blog/topics/healthcare-life-sciences/architecting-scalable-agentic-biotech-workloads): 10월 16일 참조 아키텍처와 제안된 구성 요소, 워크로드 패턴, 승인 지점.
- [Agent Runtime 문서](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime): 관리형 에이전트 배포, 사전 요건, 프레임워크 지원, 리전 및 할당량 링크, 요금 안내 시작점.
- [Agent Identity 개요](https://docs.cloud.google.com/iam/docs/agent-identity-overview): ID 및 자격 증명 작동 방식, IAM 수명주기, Cloud Storage 역할 제한.
- [Agent Gateway 개요](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview): 정책 적용 모델, 런타임 모드, 구성에 따라 달라지는 가드레일, 명시된 제한.
- [Agent Registry 문서](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-registry): 등록되는 리소스 유형과 독립형 스킬의 Preview 상태.
- [Agent Platform 요금](https://cloud.google.com/products/gemini-enterprise-agent-platform/pricing): Runtime과 Gateway의 과금 기준. 전체 스택은 별도로 추산해야 한다.
- [Google Cloud의 네 가지 평가 교훈](https://cloud.google.com/blog/topics/developers-practitioners/four-eval-engineering-lessons/): 실행 추적과 평가 설계 점검에 관한 다른 에이전트 플러그인의 맥락.

2026년 10월 18일 출처를 확인했다. BIG CHANGE는 제안된 바이오테크 시스템을 배포하거나 벤치마크하지 않았다.

## Sources

- [Google Cloud 바이오테크 에이전트 아키텍처](https://cloud.google.com/blog/topics/healthcare-life-sciences/architecting-scalable-agentic-biotech-workloads) — 10월 16일 설계 제안과 계층별 설명.
- [Agent Runtime](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime) — 배포 워크플로, 지원 프레임워크, 계약, 할당량 및 요금 링크.
- [Agent Identity 개요](https://docs.cloud.google.com/iam/docs/agent-identity-overview) — ID 자격 증명, IAM 수명주기, 감사와 제한.
- [Agent Gateway 개요](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview) — 모드, 정책, 미등록 목적지와 제한.
- [Agent Registry](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-registry) — 목록과 독립형 스킬의 Preview 표기.
- [Agent Platform 요금](https://cloud.google.com/products/gemini-enterprise-agent-platform/pricing) — Runtime과 Gateway의 과금 기준.
- [Google Cloud 요금 계산기](https://cloud.google.com/products/calculator) — 구성별 추정치.
- [평가 엔지니어링의 네 가지 교훈](https://cloud.google.com/blog/topics/developers-practitioners/four-eval-engineering-lessons/) — 다른 플러그인에서 얻은 맥락이며, 바이오테크 설계를 검증한 것은 아니다.