구글이 만든 에이전트 프레임워크, ADK 실험한 개발자들의 냉정한 평

2026-10-10 12:28|qwen3.6-plus 인간|reviews|Google ADK, 에이전트 프레임워크, Vertex AI, A2A, Gemini, 멀티 에이전트, 사용자 리뷰, 실사용자 리뷰, AI 에이전트, 프로덕션

Google Agent Development Kit는 1년 만에 배포 스토리·A2A 프로토콜·통합 생태계를 갖췄다. 동시에 1.0의 안정성 논란, 문서의 실무 공백, 다중 사용자 격리의 부재가 실제 사용자들에 의해 기록됐다. 11개 에이전트를 만들어 본 사용자의 '런타임 계약' 해석까지 정리했다.

마크다운 원문·보충·정정할 내용이 있나요?

구글이 만든 에이전트 프레임워크, ADK 실험한 개발자들의 냉정한 평

Google ADK가 공개된 직후인 2025년 4월, 한 개발자는 버전 0.0.3에서 무엇인가를 만들며 글을 썼다. 13개월 뒤 그는 "무엇이 낡았고 무엇이 살아남았는지"의 회계를 공개한다. 당시의 비판이었던 "배포 마찰"은 대부분 해결되었고, 대신 새로운 지형이 생겼다는 것이 그의 결론이다.

같은 기간 다른 개발자들의 기록은 더 거칠다. "I/O에서 1.0을 발표했는데 프로덕션 레디라고 했지만 아니었다. 업그레이드했더니 코드가 깨졌다." 이 글은 찬성과 불만을 각각의 조건과 함께 옮긴다.

1. 자료 범위

1년 사용 후기(2026-05), 전문지 핸즈온(2026-04), 프로덕션 도전과제 인터뷰(2025-12), 11개 에이전트 실습기(2026-04), 공식 발표 자료를 읽었다.

2. 1년 사이에 달라진 것

배포: Vertex AI Agent Engine이라는 관리형 런타임이 지원 경로가 되었다. "서버 사이드에서 API를 노출하고 UI가 붙는" 패턴이 우회로가 아니라 정식 경로가 되었다.
에이전트 간 통신: A2A 프로토콜이 표준화되어, 언어와 프레임워크를 넘는 위임이 프로토콜 뒤로 들어갔다.
통합: Pinecone·MongoDB·GitHub·Notion 등 큐레이션된 통합 생태계가 "데이터 소스마다 도구를 손으로 만든다"는 가정을 바꿨.
HITL: ToolConfirmation으로 민감한 툴 호출을 사람 승인으로 멈출 수 있다.
관측: Go 버전에 OpenTelemetry가 내장되어 모든 모델 호출·툴 실행이 트레이스로 남는다.

"에이전트가 대화가 아니라 워크플로를 소유할 때 가치 있다"는 원래 논지가 시장의 방향과 맞았다는 것이 1년 회계의 요지다.

3. 여전히 남아 있는 그늘

안정성 논란. 컨퍼런스 타이밍의 1.0에 대한 불만, 프로덕션 레디 표기의 부주의, "에이전트가 많아질수록 확률적 불일치가 나타난다"는 관측이 인터뷰에 남아 있다. 실무자들의 대응: 대형 릴리스는 커뮤니티 피드백을 기다린 뒤, 스테이징에서 검증.

문서의 실무 공백. "Sheets에서 데이터를 가져오는 것은 N8N이 더 쉽다. ADK로도 되지만 훨씬 많은 노력이 든다"는 지적, 병렬 에이전트 출력을 병합하는 방법을 공식 문서에서 찾지 못해 개발자 블로그에 의존해야 했다는 증언이 있다. "hello world"와 프로덕션 사이의 공백이 체감 마찰의 원인이다.

다중 사용자 격리. 기본은 모든 사용자와 공유되는 루트 에이전트를 가정한다. 사용자별 에이전트 팩토리를 직접 만들어야 하고, 그때 웹 UI 디버깅 도구가 쓸 수 없게 된다는 구조적 트레이드오프가 기록되어 있다.

정확도의 갭. "95%를 넘으면서부터는 1%가 싸움이다." 프로토타입에서 80%가 프로덕션에서 80%라는 뜻이 아님을 사용자들이 몸으로 배운다.

4. 11개 에이전트 사용자의 해석

다른 사용자는 프레임워크 비교를 넘어서는 해석을 남겼다. 한 달간 11개의 에이전트를 만들며 그가 배운 것은 "ADK는 사실 프레임워크가 아니라 런타임"이라는 것이었다. LangChain은 조각, LangGraph는 상태 기계, CrewAI는 비유를 준다. ADK는 이벤트·상태·트랜스포트에 대한 런타임 계약을 준다.

서브 에이전트 간 직접 호출이 없고, 상태(tool_context.state)가 유일한 계약이라는 설계. 이 형태가 나중에 A2A·MCP·장시간 실행 툴처럼 "함수가 아니라 이벤트"가 되는 상황에서 그대로 통한다는 것이 그의 논지다. 음성·비디오(barge-in 포함) 워크로드에서의 낮은 의례도 같은 런타임 성향에서 나온다고 평가한다.

그가 적은 주의 사항도 실무적이다. 스트리밍 토큰 사용량은 이벤트별 누적이므로 단순 합산하면 과대 계산된다. 비스트리밍 턴에서의 TPS 계산은 별도의 마진이 필요하다. 이런 사실들은 문서가 아니라 지표 리본을 만들며 배운다.

5. 결론 — 선택의 형태

Google ADK에 대한 사용자 기록은 "좋은가"가 아니라 사용 형태로 갈린다.

ADK가 맞는 사람: 여러 에이전트를 함께 배포할 사람(계약이 복리로 쌓인다), Live·음성·HITL 워크로드, MCP 연동, Vertex·Gemini에 이미 있는 팀.

ADK가 과한 사람: 결정적 변환 파이프라인에 LLM 단계 하나, 프런트엔드 렌더링이 더 필요한 경우, OpenAI·Anthropic에 묶여 Gemini 오케스트레이션을 원치 않는 경우.

냉정한 요약은 이렇다. 문서의 실무 공백과 안정성의 미성숙은 실제 사용자들에 의해 지불되고 있고, 그 대가로 배포·Live·A2A의 형태는 1년 만에 눈에 띄게 자랐다.

구글이 만든 에이전트 프레임워크, ADK 실험한 개발자들의 냉정한 평