발표일: 2026년 9월 9일 · 확인일: 2026년 9월 13일
Google이 AI 에이전트를 Kotlin으로 개발하는 ADK for Kotlin 1.0의 정식 공개를 발표했습니다. Android 앱과 Kotlin·Java 서버에서 도구 호출, 여러 단계의 작업과 상태 관리를 구성하는 개발 도구의 소식입니다. 새 언어 모델 하나가 출시되었다는 의미는 아닙니다. Google 공식 발표
이번 발표에서 확인할 변화
Google은 Kotlin Multiplatform 기반 코어에 다중 에이전트 구성, 대화 맥락 압축, 사람의 확인을 기다리는 흐름과 세션 재개 기능을 제공한다고 설명했습니다. Kotlin 함수의 도구 정의를 KSP로 컴파일 시점에 생성하는 방식도 소개했습니다. 공식 발표의 코어 기능 설명
모바일 쪽에서는 LiteRT-LM·ML Kit·Firebase AI와 연결하는 확장, Room을 이용한 상태 저장과 AppSearch 기반 메모리 구성을 다룹니다. 다만 코어가 1.0이라고 모든 확장 기능의 성숙도가 같은 것은 아닙니다. 설치 전에 필요한 모듈의 조건을 따로 확인해야 합니다.
로컬 추론과 클라우드 추론 선택하기
공식 저장소가 안내하는 Android 백엔드를 기준으로 차이를 정리하면 다음과 같습니다.
| 백엔드 | 주된 실행 위치 | 확인할 조건 |
|---|---|---|
| LiteRT-LM | 기기 내부 | 모델·메모리·실행 환경과 도구 호출 지원 |
| ML Kit의 Gemini Nano | 지원되는 Android 기기 | 베타 모듈, 현재 도구 호출 미지원 |
| Firebase AI | 클라우드 | 네트워크, 인증·프로젝트 설정, 사용량 |
이 구분은 9월 13일 확인한 저장소 설명에 따른 것입니다. 예를 들어 ML Kit 경로는 단순 생성에 사용할 수 있어도, 같은 방식의 함수 호출을 전제로 한 에이전트와 기능이 같지는 않습니다. 구현할 때는 ADK Kotlin 공식 저장소의 Android 안내를 확인하세요.
IoT 관리 앱에는 어떻게 적용할 수 있을까
다음은 이번 발표를 바탕으로 한 적용 아이디어입니다. Google이 특정 IoT 제품의 성능을 보장했다는 뜻은 아닙니다.
현장 작업자가 “최근 10분 동안 통신이 끊긴 센서를 찾아줘”라고 입력하면, 앱이 이미 권한을 가진 상태 조회 API를 호출하고 단절 기록을 설명하도록 만들 수 있습니다. 이때 모델에는 장치 목록 조회와 로그 읽기처럼 범위가 정해진 도구를 제공합니다.
장치의 출력 상태를 바꾸는 기능을 추가한다면 조회와 실행을 분리하는 설계가 필요합니다. 모델이 제안한 장치 ID, 변경 전후 값과 실행 조건을 앱의 결정적인 코드로 검사하고 사용자가 실행 내용을 확인할 수 있게 합니다. 자연어 응답만으로 실제 설정 변경 성공을 판단하지 말고 장치의 결과를 다시 읽어야 합니다.
오프라인 환경이 중요한 앱은 네트워크를 끈 상태에서 핵심 조회·설명 기능이 어디까지 동작하는지 시험해야 합니다. 모델 파일 준비, 메모리 사용량과 기기별 지연 시간도 측정 대상으로 둡니다.
도입 전에는 작은 작업 하나를 끝까지 시험하기
처음부터 여러 에이전트를 연결하기보다 “시험 장치 한 대의 오류 로그를 읽고 근거와 함께 설명하기”처럼 결과를 확인할 수 있는 작업으로 시작하는 방법을 제안합니다.
- 테스트용 장치와 가상 로그를 준비합니다.
- 읽기 도구가 반환하는 구조와 오류 형식을 고정합니다.
- 정상 질문·없는 장치·권한 없는 장치·네트워크 단절을 시험합니다.
- 앱을 종료했다가 열어도 이전 작업의 상태를 잘못 재실행하지 않는지 확인합니다.
- 답변의 정확도와 함께 도구 호출 횟수·지연·클라우드 사용량을 기록합니다.
이 시험 결과를 확인한 뒤 실제 장치와 쓰기 작업으로 범위를 넓히면 문제가 생긴 단계가 어디인지 추적하기 쉽습니다. 도구 실행이 반복될 수 있는 환경에서는 MQTT 중복 처리 글에서 설명한 이벤트 ID·중복 방지 원칙도 함께 검토할 수 있습니다.
이 글은 공식 발표와 저장소를 바탕으로 작성한 뉴스·기술 해설입니다. 실제 Android 앱의 빌드·기기 성능 측정은 수행하지 않았습니다.