ADK for Kotlin 1.0 정식 출시…온디바이스와 클라우드를 한 계층에 묶었다

Google이 2026년 9월 9일 Agent Development Kit의 Kotlin 구현인 ADK for Kotlin 1.0을 정식 출시했다. Google의 출시 발표 는 일반 제공(GA), ADK 1.0 Core와의 기능 동등성, Kotlin Multiplatform 코어, Android용 온디바이스·클라우드 확장을 이번 버전의 핵심으로 명시한다.

2026년 9월 9일 GA 전환은 독립 기술 매체의 확인 보도 에서도 같은 사건과 상태로 확인된다. 설치는 Maven Central의 core 1.0.0 의존성에서 시작하며, JVM 서버와 Android가 에이전트 구조를 공유할 수 있다. 다만 LiteRT-LM, ML Kit, Firebase AI Logic은 실행 위치와 도구 호출 지원, 안정성 단계가 서로 다르다.

1.0에서 공통 계층이 된 범위

ADK for Kotlin 1.0의 중심은 특정 모델이 아니라 모델 백엔드와 실행 환경에서 분리된 에이전트 계층이다. Kotlin Multiplatform 코어는 모델, 세션 저장소, 메모리 구현에 종속되지 않으며, LlmAgent 아래에 서로 다른 역할과 모델을 가진 에이전트를 배치할 수 있다. 이 구조가 JVM 서버와 Android, 온디바이스와 클라우드를 한 계층에 묶는다는 제목의 근거다.

정식 코어에는 전문 하위 에이전트로 작업을 넘기는 계층형 구성과 순차·병렬·반복 워크플로가 포함된다. 긴 대화의 컨텍스트 압축, 사용자의 확인을 받은 뒤 실행을 재개하는 human-in-the-loop 흐름, 중단된 세션의 직렬화와 복원, 장시간 실행 도구도 지원한다. 기존 Java 애플리케이션에서 Kotlin 에이전트를 호출하는 상호운용성 역시 1.0 범위다.

함수 도구는 Kotlin 함수에 @Tool과 @Param을 붙이고 KSP로 호출 스키마를 생성하는 방식이다. 스키마가 컴파일 단계에서 만들어지므로 런타임 리플렉션이 필요하지 않고 suspend 함수도 연결할 수 있다. 코어 설치만으로 주석 기반 도구 코드가 생성되는 것은 아니며 KSP 프로세서를 별도로 추가해야 한다.

Gradle 설치는 core와 KSP부터 시작한다

최소 JVM 프로젝트는 repositories에 mavenCentral()을 지정하고 dependencies에 implementation("com.google.adk:google-adk-kotlin-core:1.0.0")을 추가하면 된다. @Tool 기반 함수를 쓴다면 ksp("com.google.adk:google-adk-kotlin-processor:1.0.0")도 필요하다. HTTP 서버, A2A, LiteRT-LM, Firebase, ML Kit는 별도 모듈이므로 사용하는 경로만 선택할 수 있다.

그다음 LlmAgent에 이름, 설명, 모델과 지시문을 전달하고 필요한 도구 또는 하위 에이전트를 연결한다. 멀티에이전트를 위해 다른 프레임워크를 설치하는 구조가 아니라, 루트 에이전트가 역할별 하위 에이전트에 작업을 위임하는 방식이다. 각 하위 에이전트는 서로 다른 Model 구현을 사용할 수 있다.

Android에서 클라우드 Gemini를 연결할 때에는 서버용 GenAI SDK 구성을 그대로 옮기지 않도록 주의해야 한다. Android의 Gemini 연결은 API_KEY나 GoogleCredentials를 직접 사용하는 방식을 지원하지 않으며 Firebase AI Logic 모듈이 안내된다. 반대로 온디바이스 실행을 택하면 모델 파일과 지원 기기, 런타임 요구 사항을 별도로 확인해야 한다.

네 실행 경로는 도구 호출과 안정성이 다르다

공식 저장소의 모듈 문서 는 LiteRT-LM·ML Kit·Firebase AI를 같은 LlmAgent API 뒤의 Model 구현으로 설명하면서도 실행 위치와 도구 지원을 구분한다. 같은 인터페이스는 모델 교체와 에이전트 조합을 단순화하지만 네트워크 조건, 데이터 처리 위치, 기능 수준까지 같게 만들지는 않는다.

• JVM 서버: core 1.0의 정식 범위다. 네트워크 사용 여부는 선택한 Model 구현에 달려 있으며, 주석 기반 함수 도구, 세션 복원과 멀티에이전트 구성을 사용할 수 있다. 서버 실행 자체를 로컬 추론 또는 클라우드 추론으로 단정할 수는 없다.
• LiteRT-LM: Android와 JVM 데스크톱에서 Gemma 같은 모델을 기기 안에서 실행하고 도구 호출을 지원한다. 해당 모듈은 JDK 21 이상을 요구한다. 모델이 준비된 뒤에는 추론 시 API 키와 네트워크가 필요하지 않지만, 모델 확보와 배포 과정은 별개의 문제다.
• ML Kit: Android에서 ML Kit GenAI Prompt API를 통해 Gemini Nano를 사용하는 온디바이스 경로다. 모듈은 1.0 계열이라도 베타 사전 출시 구성요소이며 functionCall과 functionResponse를 아직 처리하지 않는다. 현재는 도구 실행이 없는 대화·생성 용도에 한정해 봐야 한다.
• Firebase AI Logic: Android에서 클라우드 Gemini 모델에 연결하는 경로다. 모델 요청에는 네트워크가 필요하고 전체 도구 호출을 지원하며, 앱에 API 키를 직접 넣지 않는 연결 방식으로 안내된다. Firebase 프로젝트와 Android 앱 구성은 별도로 필요하다.

따라서 ‘한 줄로 모델을 바꿀 수 있다’는 설명은 API 구조에 관한 말이다. 같은 입력이 모든 백엔드에서 같은 지연 시간과 기능, 개인정보 처리 경계를 가진다는 뜻은 아니다. 특히 ML Kit 에이전트에 LiteRT-LM이나 Firebase 에이전트와 같은 도구 목록을 배정하면 현재 지원 범위와 맞지 않는다.

하이브리드 구성과 ‘프로덕션 준비’의 경계

공통 계층의 실질적 효과는 로컬 모델과 클라우드 모델을 역할별로 조합할 수 있다는 데 있다. 조건부 예로, 민감한 텍스트의 간단한 분류는 LiteRT-LM 에이전트에서 끝내고 더 큰 모델이 필요한 작업만 Firebase 에이전트에 위임할 수 있다. 그러나 ADK가 입력의 민감도나 난도를 자동 판정하는 것은 아니며, 전환 조건과 외부 전송 범위는 애플리케이션이 정해야 한다.

‘프로덕션 준비’라는 표현은 우선 ADK for Kotlin 코어의 GA와 기능 범위를 가리킨다. Android 확장 전체가 동시에 GA가 된 것은 아니고 ML Kit 연결부는 명시적으로 베타다. 실제 배포 여부를 판단할 때에는 코어, 모델 어댑터, 기기 런타임과 사용하는 모델을 각각 나눠 검증해야 한다.

내장 HTTP 서버에도 운영상 경계가 있다. API 엔드포인트는 자체 인증을 제공하지 않아 기본적으로 루프백 주소에 바인딩되며, 외부 주소로 열려면 앞단에 인증을 추가해야 한다. Development UI는 테스트·평가·디버깅을 위한 개발 표면이므로 그대로 공개 서비스의 관리 화면으로 노출하는 구성은 피해야 한다.

출시 시점에 확정된 상태는 core 1.0.0과 공통 멀티에이전트 계층의 GA다. LiteRT-LM은 온디바이스 도구 호출을, Firebase AI Logic은 클라우드 도구 호출을 지원하지만 ML Kit 연결부는 베타이고 도구 호출도 지원하지 않는다. 이후 남은 확인점은 ML Kit 모듈의 정식 전환과 function calling 추가 여부, 각 로컬 모델의 기기별 배포·성능 조건이다.

함께 읽기:

• Socure에 1억5600만달러, 직원 현금화와 AI 인수를 함께 묶었다