Google ADK 직접 써봤습니다 — 프로덕션에서 막히는 지점

Google ADK(Agent Development Kit)는 2025년 4월 Google Cloud NEXT에서 등장했습니다. 출시 11개월 만에 GitHub 스타 15,600개를 찍었고, 2026년 2월에는 TypeScript 지원과 30개 이상의 서드파티 통합이 한꺼번에 추가됐습니다. 숫자만 보면 완성도 높은 프레임워크처럼 보입니다. 그런데 막상 프로덕션에 올려보면 얘기가 달라집니다.

Google ADK가 뭔지 30초 안에 정리

Google ADK(Agent Development Kit)는 AI 에이전트를 코드로 만들고, 테스트하고, 배포하는 오픈소스 프레임워크입니다. 공식 문서에는 “에이전트 개발이 소프트웨어 개발처럼 느껴지도록 설계했다”고 딱 이렇게 나와 있습니다. (출처: google.github.io/adk-docs, 2026.03.24 기준)

핵심 개념은 세 가지입니다. LLM 에이전트(LLM이 동적으로 판단하며 도구 사용), 워크플로우 에이전트(Sequential·Parallel·Loop로 순서 제어), 커스텀 에이전트(BaseAgent 상속해서 완전히 직접 구현). 이 세 유형을 조합하면 단순 챗봇부터 복잡한 멀티에이전트 파이프라인까지 커버됩니다.

▲ 목차로 돌아가기

2026년 2월에 무슨 일이 있었나 — 통합 생태계 대폭 확장

2026년 2월 27일, Google은 ADK 통합 생태계를 한 번에 대폭 확장했습니다. (출처: Google Developers Blog, 2026.02.27) 이전까지 ADK에서 외부 서비스를 연결하려면 직접 API를 구현해야 했습니다. 이제는 몇 줄 코드로 끝납니다.

연결 방식은 MCP 프로토콜 기반의 McpToolset이나 플러그인 아키텍처입니다. 에이전트 핵심 로직을 건드리지 않고 도구만 교체할 수 있다는 게 핵심입니다. GitHub 통합을 추가하는 코드가 실제로 10줄 안쪽입니다 — ADK 공식 블로그에 그대로 실려 있습니다.

StackOne을 쓰면 200개 이상의 SaaS 프로바이더를 단일 게이트웨이로 연결할 수 있습니다. Hugging Face 통합도 포함돼 있어서, 에이전트가 직접 모델을 검색하고 Gradio 앱까지 활용할 수 있습니다. 숫자만으로는 LangChain(1,000개 이상)에 한참 못 미치지만, 카테고리 커버리지는 이제 실무에서 자주 쓰는 영역을 대부분 포함합니다.

▲ 목차로 돌아가기

ADK 2.0 Alpha: 그래프 기반 워크플로우의 가능성과 경고

ADK 공식 문서 첫 화면에 현재 “ADK Python 2.0 Alpha” 배너가 떠 있습니다. 그래프 기반 워크플로우(Graph-based workflows), 협업 에이전트(Collaborative agents), 동적 워크플로우(Dynamic workflows)가 핵심 추가 기능입니다. (출처: google.github.io/adk-docs/2.0) LangGraph와 비슷한 방향이지만, ADK 특유의 계층적 에이전트 구조를 유지하면서 그래프 라우팅을 얹는 방식입니다.

이게 단순한 주의사항처럼 보이지만, 실제로는 심각한 제약입니다. ADK 1.x 기반으로 이미 프로덕션에 올라가 있는 에이전트가 있다면, ADK 2.0을 테스트하려면 저장소 자체를 완전히 분리해야 합니다. 같은 인프라에서 1.0과 2.0을 병행 운영할 수 없습니다.

설치는 pip install google-adk --pre로 하는데, 이미 1.0이 깔린 환경이라면 --force를 추가해야 합니다. Python 3.11 이상 필수이며, 공식 문서는 “프로덕션 환경에서는 사용하지 마십시오”라고 명시했습니다. Alpha는 Alpha입니다.

▲ 목차로 돌아가기

프로덕션에서 실제로 막히는 지점 3가지

① “1.0은 프로덕션 레디” — 실제로는 아니었습니다

2025년 Google I/O에서 ADK 1.0이 발표됐습니다. “프로덕션 레디”라는 표현과 함께였습니다. 그런데 실제 사용자 인터뷰에서는 정반대 경험이 나왔습니다. “1.0으로 업그레이드했더니 코드가 깨졌다. GitHub 이슈가 비슷한 리포트로 가득 찼고, 사람들은 롤백하라는 말을 들었다.” (출처: dlabs.ai 인터뷰, 2025.12.02) 컨퍼런스 발표 타이밍에 맞춰 릴리스가 나왔지만, 안정성은 따라오지 못한 경우입니다.

현재(2026.03) 버전은 0.6.0입니다. 2주 간격으로 릴리스가 나옵니다. 빠른 업데이트는 장점이지만, 프로덕션에 올린 뒤 자동 업그레이드했다가 깨지는 리스크도 함께 따라옵니다. 버전 고정을 먼저 하고, 스테이징에서 검증한 뒤 올리는 게 지금 단계에서는 필수입니다.

② 멀티유저 지원은 기본 제공이 아닙니다

ADK는 기본 구조에서 root agent를 여러 사용자가 공유합니다. 채팅 서비스나 고객 지원 봇처럼 사용자마다 대화를 격리해야 하는 서비스에서는 직접 팩토리 클래스를 구현해야 합니다. “멀티유저 지원을 위해 사용자당 에이전트를 따로 생성하는 클래스를 만들어야 했다”는 사례가 실제 개발자 인터뷰에 그대로 나옵니다. (출처: dlabs.ai, 2025.12.02) 더 문제는 이렇게 커스텀 구현을 하면 ADK가 기본 제공하는 Web UI 디버거를 쓸 수 없게 된다는 점입니다.

B2C 서비스에서 ADK를 쓰려면 이 부분을 처음부터 설계에 넣어야 합니다. 나중에 추가하려면 세션 관리 전체를 다시 짜야 하는 경우가 생깁니다.

③ 프로토타입 80%, 프로덕션 95%+의 간격

의료 코딩 시스템을 ADK로 구현한 개발자 사례입니다. “약 80% 정확도로 작동하는데, 나머지 20%는 랜덤 실패다. 그리고 멀티에이전트라 토큰이 엄청 타들어간다.” (출처: dlabs.ai 인터뷰, 2025.12.02) 80%는 데모에서 충분히 인상적이지만, 프로덕션에서는 20% 실패가 치명타입니다.

ADK 자체의 문제라기보다 에이전틱 AI 전반의 현실입니다. 그런데 ADK는 기본 내장 관측성(observability) 도구가 없습니다. MLflow나 AgentOps 같은 서드파티를 연결해야 하고, 이 연결 설정도 시간이 걸립니다. LangChain은 LangSmith가 기본으로 붙어 있어서 에이전트 실행 흐름을 바로 볼 수 있습니다 — ADK는 그 부분을 직접 조립해야 합니다.

▲ 목차로 돌아가기

LangChain과 수치로 비교해봤습니다

2026년 3월 기준 두 프레임워크의 수치를 나란히 놓으면 이렇습니다. (출처: Reliable Data Engineering, Medium, 2026.03.07)

C.H. Robinson(물류) 사례를 보면 ADK의 실력이 더 명확합니다. 하루 5,500건 주문 처리 파이프라인을 ADK로 구축했고, 결과는 하루 600시간 절감, 연간 230만 달러 비용 절감, 정확도 99.2%입니다. (출처: Reliable Data Engineering, Medium, 2026.03.07) 이 수치가 말하는 건 단순합니다 — Google Cloud 인프라 위에서 Gemini와 함께 쓸 때 ADK는 강력합니다.

▲ 목차로 돌아가기

ADK가 맞는 사람, 안 맞는 사람

직접 써보고 나서 내린 결론은 간단합니다. ADK는 “Google Cloud 위에서 Gemini로 돌리는 B2B 자동화 파이프라인”에서 가장 잘 맞습니다. 그 맥락을 벗어나면 장점이 절반으로 줄어듭니다.

솔직히 말하면, ADK가 매력적인 이유 중 하나는 코드가 깔끔하다는 겁니다. 에이전트를 모듈처럼 조립하는 느낌이 LangChain보다 훨씬 직관적입니다. 설치 후 처음 에이전트를 실행하는 데 15분도 안 걸립니다. 그 경험이 “이거 쓰면 되겠다”는 착각을 만들기도 합니다. 프로토타입 단계에서는 진짜 좋습니다. 문제는 그 이후입니다.

Google I/O 2026이 얼마 남지 않았습니다. ADK 2.0 정식 버전과 추가 기능 발표가 예고돼 있습니다. 지금 ADK 1.x로 실험하면서 구조를 익혀두고, 2.0 정식 버전을 보고 프로덕션 적용 여부를 판단하는 게 현실적인 접근입니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

ADK는 잘 만든 프레임워크입니다. 코드가 깔끔하고, 설치가 쉽고, 30개 이상의 서드파티 통합이 두 달 전에 한꺼번에 붙었습니다. Gemini와 함께 Google Cloud 위에서 쓰면 속도나 비용 면에서도 경쟁력이 있습니다.

다만 아직 1살도 안 됐습니다(2025년 4월 출시). “프로덕션 레디” 선언 직후에 버그가 쏟아진 이력, 멀티유저를 직접 구현해야 하는 구조적 한계, 기본 관측성 도구 부재 — 이 세 가지는 지금 시점에서 프로덕션에 올리기 전에 반드시 알고 들어가야 하는 부분입니다.

ADK 2.0 Alpha의 그래프 기반 워크플로우가 정식 릴리스로 나오고, 멀티유저 지원이 기본 기능으로 들어오는 시점이 되면 평가가 달라질 수 있습니다. 지금은 그 전 단계입니다.

Google Cloud 스택 위에서 Gemini로 내부 자동화를 만들 계획이라면, 지금 ADK를 배워두는 건 좋은 선택입니다. 그 외의 상황이라면, 지금 당장 프로덕션보다는 실험용으로 접근하는 게 현실적입니다.

▲ 목차로 돌아가기

📌 본 포스팅 참고 자료

1. Google ADK 공식 문서 (google.github.io/adk-docs)
2. Google Developers Blog — ADK 통합 생태계 발표 (2026.02.27)
3. ADK 2.0 Alpha 공식 문서 (google.github.io/adk-docs/2.0)
4. DLabs.AI — Google ADK 프로덕션 4가지 과제 (2025.12.02)
5. Reliable Data Engineering — Google ADK vs LangChain 2026 비교 (2026.03.07)