대규모 언어 모델(LLM)을 활용한 서비스는 빠르게 늘어나고 있지만, 실제 서비스 환경에서 요구되는 기능은 단순한 질의응답을 훨씬 넘습니다.
사용자와의 이전 대화를 기억해야 하고, 상황에 따라 외부 시스템을 호출해야 하며, 하나의 질문을 처리하기 위해 여러 단계를 거쳐야 하는 경우도 많습니다.
Google의 **Agent Development Kit(ADK)**는 바로 이런 요구를 해결하기 위해 등장한 프레임워크입니다.
이 글에서는 ADK가 무엇인지부터 시작해, 기존 LLM 활용 방식과의 차이, 핵심 아키텍처 구성 요소, 그리고 날씨 에이전트 예제를 통해 실제 동작 흐름까지 차근차근 정리합니다.
Google Agent Development Kit(ADK)란 무엇인가
**Agent Development Kit(ADK)**는 Google이 제공하는 이벤트 기반 AI 에이전트 개발 프레임워크입니다.
기존 LLM 활용 방식은 대부분 다음과 같은 구조였습니다.
- 사용자가 질문을 보낸다
- 모델이 한 번 응답한다
- 응답이 끝나면 모든 맥락이 사라진다
이 방식은 간단한 챗봇에는 충분하지만, 실제 서비스에서는 여러 한계가 있습니다.
ADK는 이 구조를 다음과 같이 바꿉니다.
- 대화 맥락을 세션 단위로 유지
- LLM이 필요하다고 판단하면 외부 툴을 호출
- 처리 과정 전체를 이벤트 단위로 관리
즉, ADK는 **LLM을 중심으로 한 애플리케이션 실행 환경(Runtime)**을 제공하며, 이를 통해 상태를 유지하는 AI 에이전트를 만들 수 있게 합니다.
ADK 런타임 아키텍처의 핵심 개념
ADK의 가장 큰 특징은 이벤트 루프 기반 런타임 구조입니다.
전체적인 동작 흐름은 다음 세 가지 상호작용으로 구성됩니다.
- 사용자 요청 입력
- 사용자 메시지와 함께 세션 ID 전달
- 세션 ID는 대화의 연속성을 유지하는 핵심 요소
- 이벤트 루프 처리
- LLM 호출
- 툴 실행
- 내부 로직 처리
- 이벤트 스트리밍 반환
- 중간 처리 과정
- 최종 응답
이 구조 덕분에 ADK는 단순히 “결과만 반환하는 시스템”이 아니라, 처리 과정을 단계별로 다룰 수 있는 시스템이 됩니다.
Runner: 모든 요청의 중심 역할
Runner는 ADK 아키텍처의 중심에 위치한 컴포넌트입니다.
모든 사용자 요청은 Runner를 통해 에이전트로 전달됩니다.
Runner를 생성할 때 다음 요소가 함께 묶입니다.
- 실행할 Agent
- 애플리케이션 이름
- Session Service
Runner의 중요한 특징은 run() 메서드가 단일 응답이 아니라 이벤트 스트림을 반환한다는 점입니다.
이 방식의 의미는 분명합니다.
- 툴 호출 시점과 결과를 확인할 수 있음
- 처리 중간 단계 로그 수집 가능
- 실시간 UI나 진행 상태 표시 가능
기존의 동기식 API 호출과 달리, ADK는 과정을 노출하는 실행 모델을 채택하고 있습니다.
이벤트 루프(Event Loop)의 동작 방식
이벤트 루프는 Runner와 Execution Logic 사이에서 동작하며, ADK의 핵심 혁신이라고 볼 수 있습니다.
동작 흐름은 다음과 같습니다.
- Runner가 사용자 메시지를 Execution Logic에 전달
- Execution Logic이 요청을 분석
- 필요에 따라
- LLM 호출
- 툴 실행
- 콜백 처리
- 각 단계마다 이벤트를 생성
- 이벤트가 Runner를 통해 다시 외부로 전달
이 구조는 한 번의 질문을 여러 단계로 나누어 처리하는 멀티 스텝 추론을 자연스럽게 지원합니다.
Execution Logic과 Tool 연동 구조
Execution Logic은 실제 처리를 담당하는 계층입니다.
이 계층에서는 다음 작업이 수행됩니다.
- LLM 호출
- Python 기반 툴 함수 실행
- 사용자 정의 로직 처리
ADK에서 Tool이란
ADK에서 Tool은 복잡한 개념이 아닙니다.
타입 힌트가 정의된 Python 함수 그 자체입니다.
예를 들어, 특정 도시의 날씨를 조회하는 함수는 다음과 같은 역할을 합니다.
- 입력값: 도시 이름
- 출력값: 날씨 정보 또는 오류 메시지
LLM이 대화를 분석한 뒤 “이 질문은 날씨 정보가 필요하다”고 판단하면, ADK는 자동으로 다음을 수행합니다.
- 함수 호출 파라미터 생성
- Python 함수 실행
- 결과를 다시 LLM에 전달
개발자는 함수 구현에만 집중하면 되고, 호출 과정은 ADK가 책임집니다.
Agent 설정: 에이전트의 행동 규칙 정의
Agent는 다음 요소를 하나로 묶은 개념입니다.
- 사용할 LLM 모델
- 에이전트 설명
- Instruction(행동 지침)
- 사용 가능한 Tool 목록
Instruction은 사실상 시스템 프롬프트 역할을 합니다.
예를 들어,
- 사용자가 날씨를 물으면 툴을 사용한다
- 오류가 발생하면 정중하게 안내한다
와 같은 규칙을 정의합니다.
이 설정 덕분에 LLM은
- 언제 툴을 호출해야 하는지
- 결과를 어떻게 해석해 사용자에게 전달할지
를 명확하게 판단할 수 있습니다.
Services Layer와 상태 관리
ADK가 상태를 유지할 수 있는 이유는 Services Layer 덕분입니다.
Session Service
- 대화 이력을 저장
- 여러 요청 간 맥락 유지
- 예제에서는 InMemorySessionService 사용
이는 개발 및 테스트 환경에 적합하며, 실제 운영 환경에서는 영속 스토리지로 교체할 수 있습니다.
기타 서비스
- Artifact Service: 파일, 이미지 등 관리
- Memory Service: 세션을 넘어서는 장기 정보 저장
이 모든 서비스는 인터페이스로 추상화되어 있어, 스토리지를 변경해도 에이전트 로직은 그대로 유지됩니다.
날씨 에이전트 요청 흐름 정리
“런던 날씨가 어때?”라는 질문이 들어오면 시스템은 다음 순서로 동작합니다.
- 사용자 메시지와 세션 ID 전달
- Runner가 이벤트 루프 시작
- Execution Logic이 LLM 호출
- LLM이 날씨 툴 호출 필요성 판단
- Python 함수 실행
- 결과를 LLM에 전달
- LLM이 자연어 응답 생성
- 최종 응답 이벤트가 사용자에게 전달
이후 “그럼 파리는?”이라는 질문이 와도, 세션 덕분에 날씨 맥락이 유지됩니다.
ADK 아키텍처가 주는 시사점
ADK의 설계는 다음과 같은 중요한 의미를 가집니다.
- 이벤트 기반 구조로 처리 과정 관찰 가능
- 컴포넌트 분리로 테스트와 유지보수 용이
- 서비스 추상화로 인프라 변경에 유연
이는 단순 실험용 챗봇이 아닌, 실제 운영 환경을 고려한 AI 에이전트 설계에 초점을 맞추고 있음을 보여줍니다.
Google Agent Development Kit는
LLM을 단순한 응답 엔진이 아니라 상태를 가지는 애플리케이션 구성 요소로 끌어올립니다.
이벤트 루프, 세션 관리, 툴 통합 구조를 이해하면
- 맥락을 이해하고
- 외부 시스템과 연동하며
- 실제 문제를 해결하는
AI 에이전트를 설계할 수 있는 기반을 갖추게 됩니다.
앞으로 ADK는 단순한 대화형 AI를 넘어, 업무 중심의 지능형 에이전트 개발에서 중요한 역할을 하게 될 것으로 기대됩니다.
What Is Google’s Agent Development Kit? An Architectural Tour
Agent Development Kit (ADK) is an event-driven framework for building stateful AI agents. Learn about its core architecture and components.
thenewstack.io
