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 (입력 ~200·출력 ~250배) ◎
중첩 tool call·에러 복구 양호 더 신뢰성 높음 ◎
긴 멀티턴 instruction adherence 보통 우수 ◎
agentic 벤치 (MCP Atlas, Toolathlon 등) Flash가 상회 (구글 발표 기준) — ○

해석:

  • orchestrator는 vision/zone/enter 같은 사람-상호작용 페이스의 이벤트 트리거다. 동시성도 같은 로봇은 단일 priority queue로, orchestrator 그래프는 이벤트 단위로 처리되어 직렬화·분산된다 (SYSTEM_DESIGN §7.3). 초당 수십 번 도는 tight loop이 아니므로 Flash의 속도 우위가 결정적이지 않다.
  • 반대로 출력은 로봇 물리 동작 명령이다. 중첩 tool call 신뢰성·조건부 instruction 준수가 안전과 직결되어 Opus의 강점이 정당화된다. 이는 SYSTEM_DESIGN §15에서 Opus(품질) vs Sonnet(latency)을 저울질하던 축과 같다.
  • 비용이 100배를 훌쩍 넘는 차이(입력 ~200배)는 무시 못 한다. 가드레일이 이미 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가 프로세스로는 하나여도, 그 안의 판단을 역할별 서브 에이전트로 나눌 수 있다. 예) 안전 판단 → 로봇 동작 계획 / 태블릿 UX 응답. ADK는 이런 위임 구조를 LlmAgent+sub_agents, Sequential/Parallel/Loop 같은 기성 추상화로 적은 코드로 선언할 수 있다. 단 이는 ADK만의 고유 능력이 아니다 — 현재 LangGraph 설계도 call_claude 한 노드를 여러 노드로 쪼개면 동일하게 된다(아래 §3.2). 즉 차이는 "할 수 있느냐"가 아니라 "얼마나 적은 손으로 표현하느냐"의 편의 문제다.
  • 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 경유로 부르는 경우에도 LiteLLM은 Anthropic cache_control을 그대로 통과시키므로 캐싱 자체는 동작한다. 다만 라우팅 경로(예: 직접 Anthropic vs Vertex 경유)에 따라 캐시 헤더 관련 버그 사례가 보고된 바 있어, 실제 채택 시 선택한 경로에서 캐시 적중을 한 번 확인하면 된다.

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

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

먼저 용어 정리. 여기서 "상태(state)"는 로봇·시스템이 대화를 진행하는 동안 적어 두는 메모장이라고 보면 된다. 예를 들어 "이 손님은 좀 전에 커피를 골랐다" 같은 내용을 적어 뒀다가 다음 단계에서 다시 꺼내 쓰는 식이다. 이 메모장을 잠깐 쓰고 버릴지(처리 중에만), 아니면 어딘가에 오래 보관할지가 두 프레임워크의 비교 포인트다.

두 프레임워크가 대화 내용을 다루는 방식

항목 LangGraph Google ADK
대화 도중 기억하는 법 공용 메모장을 단계마다 돌려가며 읽고 씀 공용 메모장에 단계마다 적고 읽음 (거의 동일)
오래 저장하고 싶을 때 "체크포인터(Checkpointer)"가 단계마다 자동으로 저장 "세션 서비스(SessionService)"가 저장
저장 장소 선택 메모리·SQLite·Postgres·Redis 중 골라 끼움 (MemorySaver/SqliteSaver/PostgresSaver/RedisSaver) 메모리 / 일반 DB(SQLite·Postgres·MySQL) / 구글 Vertex AI 중 선택 (InMemory/Database/VertexAiSessionService)
여러 대화를 길게 누적 외부 저장소를 직접 연결 전용 "메모리 서비스"(벡터 DB 등) 제공
특이 기능 과거 시점으로 되감아서 디버깅(time-travel) A2A·구글 클라우드와 매끄러운 연동
특정 플랫폼에 묶이나 안 묶임 — 어디서 돌리든 같은 코드 안 묶임 — DatabaseSessionService로 일반 DB에 저장 가능 (Vertex는 선택지 중 하나)

우리 설계(기억은 Home Assistant 한 곳에만 보관, orchestrator는 아무것도 안 들고 있음)에 대입하면:

  • 가장 중요한 사실: 두 도구 모두 "오래 저장하는 기능을 꺼둘 수 있다." LangGraph는 저장 장치를 안 붙이거나 메모리용만 쓰면 되고, ADK도 기본 메모리 모드만 쓰면 된다. 그러면 대화 내용이 디스크에 남지 않고 처리하는 동안만 잠깐 기억했다가 버린다.
  • 우리는 "진짜 기억(영구 보관)은 Home Assistant(HA)에만 둔다"고 정했으므로, 어느 도구를 쓰든 프레임워크 자체 저장은 꺼두고 필요한 값은 HA에서 읽어오면 된다.
  • 따라서 대화 기억·저장만 놓고 보면 ADK가 꼭 필요하지는 않다. ADK가 내세우는 저장 기능(메모리 서비스, Vertex 영구 저장)은 우리가 일부러 안 쓰기로 한 것이라 이 부분에서는 장점이 되지 못한다.
  • 저장 유연성은 두 도구가 사실상 대등하다. 한때 "ADK는 영속 저장이 구글 Vertex로 묶인다"고 적었으나 이는 부정확하다 — ADK도 DatabaseSessionService로 SQLite·Postgres·MySQL 같은 일반 DB에 저장할 수 있어 구글 클라우드에 묶이지 않는다(LangGraph의 SqliteSaver/PostgresSaver와 동급). 따라서 이 축은 어느 쪽도 우열이 없는 비차별 요소다.

결론(이 항목 한정): 대화 내용 기억·저장 능력은 두 프레임워크가 비슷하고, 우리는 어차피 HA에 저장하므로 이 축은 ADK 도입의 근거가 되지 못한다(= LangGraph로 충분). ADK를 고려한다면 그 이유는 저장 기능이 아니라 추론을 서브 에이전트로 쪼개 표현하는 편의(§3 좋은 점)에서 찾아야 한다. 단 그 편의조차 "없던 능력"은 아니다(§3.2 참고).

3.2 현재 설계(LangGraph)로도 서브 에이전트 분해가 되는가?

된다. 서브 에이전트 분해는 LangGraph가 본래 하는 일이라, 현재 설계에 빠진 기능이 아니다.

현재 §3.3의 그래프는 LLM 호출을 call_claude 노드 하나로 단순하게 그려 놨을 뿐이다.

현재:  assemble_context → call_claude → guardrail → dispatch

이 call_claude 한 노드를 역할별로 나누면 그대로 서브 에이전트 분해가 된다.

분해 예:
  assemble_context → safety_reason ─┐         (안전·금지구역 판단)
                     action_plan   ─┤         (로봇 동작 계획)
                     tablet_reply  ─┴→ guardrail → dispatch   (태블릿 UX 응답)
  (필요하면 supervisor 노드가 조건에 따라 어디로 보낼지 위임)

LangGraph는 노드를 묶는 subgraph, 조건에 따라 갈라지는 조건부 엣지, 한 노드가 다른 노드에 일을 맡기는 supervisor(멀티 에이전트) 패턴을 모두 기본으로 제공한다. 즉 새 프레임워크(ADK) 도입 없이 지금 구조에서 바로 확장할 수 있다.

남는 차이는 "능력"이 아니라 "표현 방식"뿐이다.

LangGraph (현재 설계) Google ADK
분해하는 법 노드·엣지·subgraph를 직접 조립 LlmAgent+sub_agents 위임을 선언
성향 더 명시적, 세밀하게 제어 코드가 적고 빠르게 구성
안전 보장 분해를 어디서 표현하든 동일 — 가드레일은 MCP 서버 측에 있음 동일

요약: 서브 에이전트 분해는 현재 설계의 한계가 아니다. ADK가 주는 건 "더 적은 코드로 선언하는 편의"이지 "없던 능력"이 아니다. 따라서 이 항목도 ADK 도입의 결정적 근거는 되지 못한다.

4. 정리 / 권고 방향

  • 모델: Gemini의 매력은 속도보다 비용(입력 ~200·출력 ~250배 저렴). 단 안전 명령 디스패치 워크로드 특성상 Claude의 tool-use 신뢰성이 더 부합 → 전면 교체보다 티어링 검토가 합리적.
  • 프레임워크: ADK는 훌륭하나, MQTT 중심·HA 상태저장·非GCP 배포 구조에서는 LangGraph 대비 추가 이득이 제한적이고 prompt caching 검증 부담이 생긴다. 대화 상태 저장 축은 자료 조사(§3.1) 결과 LangGraph로 충분하다. 서브 에이전트 분해도 현재 LangGraph 설계로 가능하므로(§3.2), ADK가 주는 것은 "고유 능력"이 아니라 "더 적은 코드로 선언하는 편의"에 그친다 — 단독으로 도입을 정당화할 결정적 근거는 약하다.
  • 두 변경 모두 SYSTEM_DESIGN §15에 없는 신규 아키텍처 결정이므로, 설계 반영 전 합의가 필요하다.

5. 출처

설계 문서

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

논의 자료

팀

Clone this wiki locally