Skip to content

ADK_REVIEW

Jump to bottom
lazybrain80 edited this page May 23, 2026 · 8 revisions

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 전달 여부를 검증해야 하고, 안 되면 비용 이점이 깎인다.

3.1 대화 상태 저장: ADK vs LangGraph (자료 조사)

위 "세션 상태 관리" 항목의 핵심 질문 — 대화 상태 저장 때문에 ADK가 꼭 필요한가, 아니면 LangGraph로 충분한가 — 를 공개 자료로 확인했다.

두 프레임워크의 상태 저장 방식

구분 LangGraph Google ADK
작업 중 상태 TypedDict 공유 State가 노드 사이를 흐름 State 딕셔너리(blackboard)에 step별로 read/write
영속화 메커니즘 Checkpointer + thread_id (스텝마다 스냅샷) SessionService + session_id
영속 백엔드 MemorySaver / Postgres / Redis / SQLite 교체 가능 InMemorySessionService → 영속은 VertexAiSessionService
장기 메모리 (외부 스토어 직접 연결) Memory Service (벡터 DB 등) 별도 제공
부가 기능 time-travel(과거 체크포인트 되감기) 디버깅 A2A 연계, GCP 통합
종속성 백엔드 교체로 dev=prod 동일 코드, 벤더 락인 없음 영속 경로가 Vertex AI(GCP)에 묶이는 경향

우리 제약("Home Assistant가 단일 상태 저장소, orchestrator는 stateless")에 대입하면:

  • 핵심은 둘 다 "자기 영속 계층을 끄고" 운영할 수 있다는 점이다. LangGraph는 영속 checkpointer 없이(또는 휘발성 MemorySaver만) 쓰면 그래프 상태가 디스크에 남지 않고, ADK도 InMemorySessionService만 쓰면 세션 상태가 휘발성으로만 존재한다. 어느 쪽이든 영속 진실은 HA에 두고 프레임워크 상태는 단일 요청 처리 중 working memory로만 한정할 수 있다.
  • 즉 대화 상태 저장만 놓고 보면 ADK가 "반드시 필요한" 이유는 없다. ADK 상태 기능의 진짜 강점(Memory Service, VertexAiSessionService 영속)은 우리가 의도적으로 쓰지 않기로 한 것들이라, 이 축에서는 이점으로 환산되지 않는다.
  • 오히려 우리 제약에는 LangGraph가 더 잘 맞는 면이 있다: 영속 백엔드가 교체식이라 GCP로 끌려가지 않고, 필요해지면 checkpointer를 SQLite/Postgres로 붙이는 선택지가 코드 변경 없이 열려 있다(반면 ADK 영속은 Vertex 쪽으로 기우는 경향).

결론(이 축 한정): 대화 상태 저장은 LangGraph로 충분하며, 이 항목이 ADK 채택의 근거가 되긴 어렵다. ADK를 고려할 동기는 상태 관리가 아니라 서브 에이전트 분해의 표현력(§3 좋은 점) 쪽에서 찾아야 한다.

4. 정리 / 권고 방향

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

5. 출처

설계 문서

  1. 시스템 설계
  2. OSS 통합
  3. 서비스
  4. MQTT 스키마
  5. 배포
  6. 개발
  7. 운영

논의 자료

팀

Clone this wiki locally