ADK_REVIEW

Google ADK 검토 — 논의 자료

⚠️ 이 문서는 논의·검토용 자료입니다. 현재 설계 결정에 반영된 내용이 아니며, 7개 설계 deliverable의 불변식을 바꾸지 않습니다. ADK(Agent Development Kit, 에이전트 개발 키트) 채택 여부는 미결 상태입니다.

작성일: 2026-05-23

현재 orchestrator는 LangGraph + Claude Agent SDK(Software Development Kit, 소프트웨어 개발 키트) 로 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜) 서버 3개를 LLM(Large Language Model, 대규모 언어 모델) 도구로 노출한다 (OSS_INTEGRATION §3.3). "Google ADK로도 동일하게 구성할 수 있는가, 그리고 도입 이점이 있는가"를 검토한 메모.

1. 두 결정은 서로 독립적이다

가장 먼저 분리해야 할 점: 프레임워크 교체와 모델 교체는 별개의 결정이다.

결정 축	선택지	비고
프레임워크	LangGraph + Claude Agent SDK ↔ Google ADK	ADK는 모델 중립적
모델	Claude(Opus/Sonnet) ↔ Gemini ↔ 기타	LiteLLM 래퍼로 교차 사용 가능

따라서 "ADK + Claude" 도, "Claude Agent SDK 유지 + 모델만 Gemini" 도 가능하다. ADK 도입이 곧 Gemini 채택을 의미하지 않는다.

MCP는 표준 프로토콜이라 서버 측(mcp-robot-adapter 등 3개)은 어느 경우든 변경 불필요하다. 바뀌는 것은 orchestrator 안의 LLM 호출자뿐이다.

2. 모델 성능 — Gemini 3.5 Flash vs Claude Opus 4.7

항목	Gemini 3.5 Flash	Claude Opus 4.7	이 프로젝트 중요도
출력 속도 / TTFT(Time To First Token, 첫 토큰까지 시간)	~4배 빠름, <500ms	1–3초	△
비용 (input/output, 1M tokens)	~$0.075 / ~$0.30	~$15 / ~$75 (~100배)	◎
중첩 tool call·에러 복구	양호	더 신뢰성 높음	◎
긴 멀티턴 instruction adherence	보통	우수	◎
agentic 벤치 (MCP Atlas, Toolathlon 등)	Flash가 상회 (구글 발표 기준)	—	○

해석:

• orchestrator는 vision/zone/enter 같은 사람-상호작용 페이스의 이벤트 트리거이고 per-session lock으로 직렬화된다 (SYSTEM_DESIGN §7.3). 초당 수십 번 도는 tight loop이 아니므로 Flash의 속도 우위가 결정적이지 않다.
• 반대로 출력은 로봇 물리 동작 명령이다. 중첩 tool call 신뢰성·조건부 instruction 준수가 안전과 직결되어 Opus의 강점이 정당화된다. 이는 SYSTEM_DESIGN §15에서 Opus(품질) vs Sonnet(latency)을 저울질하던 축과 같다.
• 비용 100배 차이는 무시 못 한다. 가드레일이 이미 MCP 서버 측에 강제되므로(JSON schema → capability whitelist → zone polygon clamp → velocity clamp), "모델이 가끔 틀려도 서버에서 막힌다"는 안전망이 있다. → 저빈도 단순 결정은 저비용 모델, 고위험 결정은 Opus 같은 티어링 여지가 있다.

요지: Gemini로 바꿀 강한 이유는 성능이 아니라 비용이다. 안전·신뢰성 관점에선 Claude Opus가 이 워크로드에 여전히 더 부합한다.

3. Google ADK 도입 이점 (프레임워크)

ADK는 2026년 1.0 GA(General Availability, 정식 출시) 에 도달했고 (Python/Go/Java/TypeScript), 주요 강점은 다음과 같다.

좋은 점

• MCP 1급 지원 — MCPToolset으로 MCP 서버를 붙이면 도구 자동 등록. 기존 MCP 서버 3개는 그대로 재사용.
• orchestrator 내부 서브 에이전트 분해에 적합 — orchestrator가 프로세스로는 하나여도, 그 안의 추론을 역할별 서브 에이전트로 쪼개 root agent가 위임하는 구조를 잘 지원한다. 예) 컨텍스트 조립 → 안전 판단 → 로봇 동작 계획 / 태블릿 UX 응답 을 각각 서브 에이전트로 정의. ADK의 멀티 에이전트·워크플로우 추상화(Sequential/Parallel/Loop + LlmAgent 위임)로 이를 깔끔하게 표현할 수 있다. 서브 에이전트를 어떻게 정의하느냐에 따라 실질적 이점이 커진다. (다만 같은 분해를 현재 LangGraph 노드 구조로도 표현 가능 → "ADK여야만 하는가 vs LangGraph로 충분한가"는 §4에서 다루는 비교 대상)
• Vertex AI / GKE(Google Kubernetes Engine, 구글 쿠버네티스 엔진) 배포 통합 — GCP(Google Cloud Platform, 구글 클라우드 플랫폼) 위에서 운영한다면 매끄러움.

이 프로젝트에 한해 회의적인 점

• 서비스 간 통신(A2A(Agent-to-Agent, 에이전트 간 통신)) — ADK는 별개로 떠 있는 에이전트들이 서로 직접 대화하며 일을 나누는 방식을 잘 지원한다. 하지만 우리는 모든 서비스가 MQTT 한 곳을 거쳐서만 메시지를 주고받기로 정했고(설계 불변식), 외부에 노출되는 별도 에이전트 서비스도 없다. 이 층위에서는 A2A를 쓸 자리가 거의 없다. (orchestrator "안"의 서브 에이전트 분해는 별개로 실익이 있어 위 "좋은 점"에 정리)
• 세션 상태 관리 — ADK는 대화 맥락·진행 상태를 자기 안에 저장해 주는 기능을 갖고 있다. 그런데 우리는 이미 모든 상태를 Home Assistant 한 곳에만 저장하기로 못 박았다(orchestrator는 상태를 안 들고 매번 HA에서 조회하는 stateless graph). ADK의 상태 저장 기능을 전면적으로 켜면 "상태를 두 곳에 두는" 셈이라 원칙과 충돌한다. 다만 서브 에이전트 분해를 쓰더라도 영속 상태는 HA에 두고 ADK 세션 상태는 단일 요청 처리 중의 휘발성 메모리로만 제한하면 충돌 없이 양립 가능하다.
• 배포 모델이 ghcr.io 기반 cloud-build/local-run (DEPLOYMENT) 이라 GCP 종속 이점이 약하다.
• 프롬프트 캐싱 리스크: "system prompt + zone playbook → Anthropic prompt caching" 최적화는 Claude Agent SDK가 Anthropic API를 직접 칠 때 가장 깔끔하다. ADK가 Claude를 LiteLLM 경유로 부르면 cache_control 전달 여부를 검증해야 하고, 안 되면 비용 이점이 깎인다.

4. 정리 / 권고 방향

• 모델: Gemini의 매력은 속도보다 비용(100x). 단 안전 명령 디스패치 워크로드 특성상 Claude의 tool-use 신뢰성이 더 부합 → 전면 교체보다 티어링 검토가 합리적.
• 프레임워크: ADK는 훌륭하나, MQTT 중심·HA 상태저장·非GCP 배포 구조에서는 LangGraph 대비 추가 이득이 제한적이고 prompt caching 검증 부담이 생긴다.
• 두 변경 모두 SYSTEM_DESIGN §15에 없는 신규 아키텍처 결정이므로, 설계 반영 전 합의가 필요하다.

5. 출처

• Model Context Protocol (MCP) — ADK
• Google ADK 1.0 and A2A Protocol — n1n.ai
• Gemini 3.5 Flash vs Claude Opus 4.7: Agentic Workflows — MindStudio
• Gemini 3.5 Flash vs Claude Opus 4.7: Speed, Cost, Agentic Performance — MindStudio
• Claude Opus 4.7 vs Gemini 3.1 Pro — DataCamp