Google ADK 통합 생태계, 써봤더니 이 조건에서만 제대로 됩니다

Google이 2026년 2월 27일 공식 발표한 ADK Integrations Ecosystem은 GitHub, Jira, MongoDB 등 30개 이상 서드파티 도구를 몇 줄의 코드로 연동하는 에이전트 개발 인프라입니다. 그런데 막상 공식 문서를 뜯어보면 “모델 비종속성”이라는 말을 그대로 믿다가 빌트인 도구 제한에 걸리는 경우가 생깁니다. 결론부터 말씀드리면, ADK는 강력하지만 몇 가지 조건을 모르면 개발 중간에 구조를 통째로 바꿔야 할 수 있습니다.

ADK 통합 생태계, 어떤 도구들이 들어왔나

Google ADK(Agent Development Kit)는 2025년 Cloud NEXT에서 오픈소스로 공개된 AI 에이전트 개발 프레임워크입니다. Python, TypeScript, Java, Go를 지원하며, 복잡한 멀티에이전트 시스템을 구축할 수 있는 기반을 제공합니다. 그런데 2026년 2월 27일 공식 블로그를 통해 한 번에 30개 이상의 서드파티 통합이 추가됐습니다. (출처: Google Developers Blog, 2026.02.27)

이번 통합 생태계는 크게 8개 카테고리로 나뉩니다. 코드·개발 도구(GitHub, GitLab, Postman, Daytona, Restate), 프로젝트 관리(Asana, Atlassian/Jira, Linear, Notion), 데이터베이스(Chroma, MongoDB, Pinecone), 메모리(GoodMem, Qdrant), 옵저버빌리티(AgentOps, Arize AX, MLflow 등 7개), 커넥터(n8n, StackOne), AI 모델·데이터셋(Hugging Face), 결제(PayPal, Stripe)가 포함됩니다. 자신이 이미 쓰고 있는 스택이 여기 있다면, 에이전트가 그 안에서 직접 작업을 수행할 수 있다는 뜻입니다.

연동 방법은 ADK의 McpToolset 프리미티브 또는 플러그인 아키텍처를 사용하며, 에이전트의 핵심 로직은 도구와 분리됩니다. 도구를 바꿔도 에이전트 로직 자체는 건드리지 않아도 됩니다. GitHub 연동을 추가하는 예시 코드를 공식 블로그에서 직접 확인했을 때, 실제로 import 두 줄에 McpToolset 설정 블록 하나면 됩니다.

▲ 목차로 돌아가기

“Toolkit”이 아니라 “Execution Framework”입니다

“ADK = 도구 모음”이라는 이름에서 오는 인상이 있는데, 실제로는 다릅니다. Futurum Research의 Mitch Ashley는 2026년 3월 3일 분석 리포트에서 이 점을 정면으로 짚었습니다. “Google은 ADK를 개발 키트로 출시했지만, 통합 생태계는 다른 이야기를 합니다. GitHub, Jira, MongoDB와 5개의 옵저버빌리티 플랫폼에 연결하는 프레임워크는 단순히 에이전트를 조립하는 도구가 아닙니다. 에이전트가 실행·관찰·통제되는 아키텍처 레이어를 구축하는 것입니다.” (출처: futurumgroup.com, 2026.03.03)

이 차이가 실용적으로 중요한 이유가 있습니다. LangChain, AutoGen, CrewAI 같은 기존 에이전트 오케스트레이션 프레임워크는 에이전트가 어떻게 협력하는지(how agents cooperate)에 집중합니다. ADK는 거기서 한 단계 더 나아가 에이전트가 어떤 엔지니어링 인프라 안에서 실행되는지(where agents execute)를 구조화합니다. GitHub으로 PR을 열고, Jira 티켓을 업데이트하고, MongoDB를 쿼리하고, 그 모든 과정을 MLflow에서 OTel 트레이스로 추적합니다. 이런 일을 하는 시스템을 “도구 모음”이라 부르기는 어렵습니다.

▲ 목차로 돌아가기

빌트인 도구 1개 제한, 공식 문서에 딱 이렇게 나옵니다

ADK 통합 생태계를 쓸 때 가장 먼저 알아야 할 제약이 하나 있습니다. ADK 공식 문서의 Tool Limitations 페이지에는 이런 내용이 있습니다. “다음 ADK 빌트인 도구들은 단일 에이전트 객체 안에서 다른 도구 없이 단독으로만 사용할 수 있습니다: Gemini API Code Execution, Gemini API Google Search, Vertex AI Search.” (출처: google.github.io/adk-docs/tools/limitations/, 2026.03 기준)

쉽게 말하면 이렇습니다. Google Search 도구를 쓰는 에이전트에 커스텀 함수나 다른 도구를 같이 넣으면 작동하지 않습니다. 검색도 하고 코드도 실행하는 에이전트를 만들고 싶다면, 각각을 별도 에이전트로 분리한 뒤 AgentTool.create()로 묶어야 합니다. 이 구조 변경을 모르고 개발을 시작하면 단일 에이전트에 도구를 쌓다가 런타임 오류를 만나게 됩니다.

search_agent = Agent(model='gemini-2.0-flash', tools=[google_search])
coding_agent = Agent(model='gemini-2.0-flash', code_executor=BuiltInCodeExecutor())
root_agent = Agent(
name="RootAgent",
model="gemini-2.0-flash",
tools=[AgentTool(agent=search_agent), AgentTool(agent=coding_agent)]
)

빌트인 도구를 서브에이전트 안에 넣는 것도 제한이 있습니다. URL Context 도구, Code Execution 도구는 서브에이전트 내부에서 사용할 수 없습니다. 예외적으로 Python v1.16.0 이상에서 GoogleSearchTool과 VertexAiSearchTool은 bypass_multi_tools_limit=True 파라미터로 제한을 우회할 수 있습니다. 버전 확인이 먼저입니다.

▲ 목차로 돌아가기

모델 비종속이라는 말, Gemini 의존 비용부터 계산하세요

ADK는 “모델 비종속(model-agnostic)”이라고 공식 문서에 명시되어 있습니다. LiteLLM을 통해 100개 이상의 LLM 프로바이더를 연결할 수 있습니다. 그런데 실제 프로덕션에서는 이 말을 그대로 믿으면 비용 문제가 생깁니다.

LinkedIn에 공개된 실제 구현 사례에서 한 개발자 팀은 콘텐츠 분류 + 심층 분석 에이전트 시스템을 ADK로 구축했습니다. 초기에 Gemini 모델만 사용했을 때 모든 단계에 프론티어 모델을 쓰는 구조가 됐고, 이후 분류 작업에 Qwen3 같은 경량 모델로 전환한 뒤 LiteLLM 게이트웨이를 도입한 결과 비용이 68% 줄었습니다. 응답 속도는 45% 빨라졌습니다. (출처: LinkedIn 기술 케이스 스터디, 2026.01.02)

결론부터 말씀드리면, ADK의 모델 비종속성은 기술적으로는 사실입니다. 하지만 기본 설정으로 시작하면 자연스럽게 Gemini로 모든 작업을 처리하는 구조가 됩니다. 분류·라우팅 같은 단순 작업에도 프론티어 모델을 쓰는 건 비용 낭비입니다. LiteLLM을 게이트웨이로 연결해서 작업 성격에 맞게 모델을 분리하는 것이 프로덕션 전 필수 과정입니다.

▲ 목차로 돌아가기

옵저버빌리티가 7개인 이유, 숫자가 말해줍니다

이번 통합 생태계 발표에서 옵저버빌리티 카테고리에만 AgentOps, Arize AX, Freeplay, MLflow, Monocle, Phoenix, W&B Weave 총 7개가 들어왔습니다. 코드 도구(5개), 프로젝트 관리(4개), 데이터베이스(3개)보다 많습니다. Futurum Research의 2026년 1월 소프트웨어 라이프사이클 엔지니어링 의사결정자 설문에서 기업의 37.4%가 AI 옵저버빌리티를 플랫폼 구매 결정의 최우선 기준으로 꼽았습니다. (출처: Futurum Research Software Lifecycle Engineering Decision-Maker Study, 2026.01) 기업들이 에이전트를 배포하기도 전에 모니터링 요건을 먼저 챙기고 있다는 뜻입니다.

그중에서도 MLflow 통합이 중요합니다. ADK는 에이전트 실행, 도구 호출, 모델 요청에 대한 OTel(OpenTelemetry) 스팬을 네이티브로 방출합니다. MLflow v3.6.0 이상이 있으면 OTLP 인제스천으로 이 트레이스를 바로 수집할 수 있습니다. 별도 인스트루멘테이션 없이 기존 인프라에 에이전트 텔레메트리가 흘러들어갑니다. 그냥 편리함이 아니라 설계 결정의 문제입니다.

▲ 목차로 돌아가기

MCP와 ADK 통합 생태계, 뭐가 다를까요

Anthropic의 MCP(Model Context Protocol)는 이미 사실상 표준처럼 쓰이고 있는 에이전트-도구 연결 프로토콜입니다. ADK도 McpToolset을 통해 MCP 서버와 연결됩니다. 즉, ADK 통합 생태계와 MCP는 경쟁 관계가 아니라 ADK가 MCP 위에 올라탄 구조입니다.

차이는 “큐레이션”에 있습니다. MCP는 “누구든 서버 만들어 연결하면 된다”는 오픈 프로토콜입니다. ADK 통합 생태계는 Google이 직접 파트너십을 맺고 테스트한 공식 통합 카탈로그입니다. devops.com의 분석대로 “managed ecosystem은 reliability를 제공하고, open protocol은 flexibility를 제공합니다.” (출처: devops.com, 2026.03.02) 스택이 GitHub, Jira, MongoDB면 ADK 공식 통합을 쓰는 게 빠릅니다. 카탈로그에 없는 도구라면 MCP 기반 커스텀 통합이 더 유연합니다.

StackOne 통합은 특이한 포지션을 갖고 있습니다. 200개 이상의 SaaS 프로바이더를 단일 게이트웨이로 묶어서 연결해줍니다. ADK 카탈로그에 없는 서비스도 StackOne이 지원한다면 카탈로그 안에서 처리할 수 있습니다. 커스텀 MCP 서버를 만들기 전에 StackOne 지원 목록부터 확인하는 게 시간을 아끼는 방법입니다.

▲ 목차로 돌아가기

자주 나오는 질문 5가지

▲ 목차로 돌아가기

마치며 — 정말 써볼 만한가요?

ADK 통합 생태계는 개발 환경에서 이미 쓰고 있는 툴과 에이전트를 붙이는 데 확실히 빠릅니다. GitHub PR 관리, Jira 티켓 업데이트, MongoDB 쿼리를 에이전트가 직접 처리하는 구조를 몇 줄로 만들 수 있고, 그 과정 전체를 OTel 트레이스로 뽑아볼 수 있습니다.

다만 두 가지는 먼저 잡아야 합니다. 첫째, 빌트인 도구 제한을 모르면 개발 중간에 에이전트 구조를 통째로 바꿔야 합니다. 공식 문서의 Tool Limitations 페이지는 필독입니다. 둘째, LiteLLM 없이 ADK만 쓰면 모든 작업을 Gemini로 돌리는 구조가 되기 쉽고, 이건 비용 낭비로 이어집니다. 이 두 가지를 알고 시작하면 ADK는 프로덕션에서 꽤 견고한 선택지입니다.

본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. ADK 공식 문서(google.github.io/adk-docs)에서 최신 내용을 확인하는 것을 권장합니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Google Developers Blog — Supercharge your AI agents: The New ADK Integrations Ecosystem (2026.02.27)
2. Google ADK 공식 문서 — Tool Limitations (google.github.io/adk-docs)
3. Futurum Research — Google ADK Is Not a Toolkit – It Is an Agent Execution Framework (2026.03.03)
4. DevOps.com — Google ADK Opens the Door to AI Agents That Work Inside Your DevOps Toolchain (2026.03.02)