Google ADK for Kotlin 1.0 출시: Android AI 에이전트 개발이 바뀌는 지점

Google이 ADK for Kotlin 1.0을 일반 공개했습니다. Android 개발자에게 중요한 이유는 “Kotlin에서도 AI 에이전트를 만들 수 있다”가 아닙니다. 이미 API를 호출하면 AI 기능은 붙일 수 있었습니다. 이번 변화의 핵심은 모바일 앱 안에서 에이전트를 운영 제품처럼 다룰 수 있는 기본 부품이 생겼다는 점입니다.

Google 발표에 따르면 ADK for Kotlin 1.0은 Python, Java ADK Core와 기능 동등성을 맞췄고, Kotlin Multiplatform 기반 코어와 Android 우선 확장을 함께 제공합니다. 주요 기능에는 계층형 멀티 에이전트, 컨텍스트 압축, 멀티턴 대화, human-in-the-loop 승인 흐름, 장시간 실행, annotation 기반 도구, 세션 복원, Java 상호운용, Vertex AI 연동이 포함됩니다.

문제: 모바일 AI 기능은 데모와 운영의 간극이 큽니다

모바일 앱에서 AI 기능을 붙이는 첫 단계는 어렵지 않습니다. 버튼을 누르면 Gemini나 다른 모델 API에 요청을 보내고, 결과를 화면에 보여주면 됩니다. 하지만 실제 사용자에게 배포하면 다른 문제가 바로 나옵니다.

• 앱이 백그라운드로 내려갔을 때 세션을 어떻게 이어갈 것인가
• 네트워크가 불안정할 때 로컬 모델과 클라우드 모델을 어떻게 나눌 것인가
• 결제, 송금, 예약처럼 민감한 액션은 어떻게 확인받을 것인가
• Android 저장소, Room, AppSearch, Firebase와 어떻게 자연스럽게 연결할 것인가
• 도구 스키마를 사람이 손으로 관리하다가 깨지는 문제를 어떻게 줄일 것인가

ADK for Kotlin 1.0은 이 질문에 대한 Google식 답입니다. 모델 호출 SDK라기보다 Android 앱 안에 에이전트 런타임을 넣기 위한 프레임워크에 가깝습니다.

원인: 에이전트는 UI 기능이 아니라 상태 머신입니다

AI 에이전트를 단순 채팅 UI로 보면 구조가 꼬입니다. 에이전트는 사용자의 요청을 읽고, 필요한 도구를 고르고, 중간 상태를 저장하고, 때로는 사용자 승인을 기다리고, 다시 이어서 실행합니다. 이 흐름은 전통적인 모바일 화면 전환보다 백엔드 워크플로우에 더 가깝습니다.

예를 들어 금융 앱의 개인 비서 기능을 생각해봅시다. 사용자가 “이번 달 구독료 줄일 방법 찾아줘”라고 요청하면 에이전트는 거래 내역을 읽고, 반복 결제를 분류하고, 취소 후보를 제안할 수 있습니다. 여기까지는 읽기 작업입니다. 하지만 “이 구독 해지해줘”는 다릅니다. 실제 해지 API 호출 전에는 명시적 승인, 감사 로그, 실패 복구가 필요합니다.

모바일에서는 여기에 수명주기 문제가 더해집니다. 사용자가 앱을 닫고 다시 열어도 대화와 작업 상태가 유지되어야 합니다. 네트워크가 끊기면 로컬에서 가능한 일과 클라우드가 필요한 일을 분리해야 합니다.

해결: ADK for Kotlin 1.0의 실무 포인트

첫째, Kotlin Symbol Processing 기반 도구 정의가 중요합니다. Google 예시에서는 @Tool, @Param annotation을 사용해 일반 Kotlin 함수를 에이전트 도구로 노출합니다. 빌드 시점에 함수 호출 정의가 생성되므로 런타임 리플렉션 의존을 줄이고, 타입 안정성을 확보할 수 있습니다.

둘째, human-in-the-loop 흐름이 기본 기능으로 들어왔습니다. 모바일 AI에서 승인 UX는 부가 기능이 아니라 안전장치입니다. 사용자가 돈, 개인 정보, 외부 메시지, 계정 변경과 관련된 액션을 요청하면 에이전트가 바로 실행하지 않고 확인을 받아야 합니다.

셋째, Android 저장소와 세션 복원이 핵심입니다. ADK for Kotlin은 Room, AppSearch 같은 Android 구성 요소와 연결되는 방향을 제시합니다. 이는 “대화 내용을 서버에 모두 올릴 것인가”라는 질문을 다시 생각하게 만듭니다. 민감한 일부 데이터는 로컬에 남기고, 클라우드 모델은 필요한 요약과 도구 결과만 받는 하이브리드 구조가 현실적입니다.

넷째, 로컬 모델과 클라우드 모델을 분리해 쓸 수 있습니다. Google은 LiteRT-LM, ML Kit, Firebase AI 같은 조합을 언급합니다. 모든 추론을 클라우드로 보내는 방식은 비용과 개인정보 리스크가 큽니다. 반대로 모든 것을 로컬에서 처리하면 성능과 최신성이 부족할 수 있습니다. 실무에서는 분류, 초안, 캐시 가능한 분석은 로컬로, 복잡한 추론과 최신 지식이 필요한 작업은 클라우드로 보내는 식의 분리가 필요합니다.

Android 팀이 설계할 때 피해야 할 실수

첫 번째 실수는 에이전트 응답을 화면 상태와 직접 묶는 것입니다. 에이전트 실행은 오래 걸릴 수 있고, 중간에 승인 대기가 생길 수 있습니다. ViewModel 안에서 모든 상태를 임시로 들고 있으면 프로세스 종료, 화면 회전, 백그라운드 전환에 취약합니다. 세션 저장소를 별도로 두고 UI는 상태를 구독하는 구조가 낫습니다.

두 번째 실수는 도구 권한을 너무 넓게 주는 것입니다. “사용자 프로필 수정” 같은 큰 도구 하나보다 “배송지 읽기”, “배송지 변경 초안 생성”, “배송지 변경 실행”처럼 권한을 쪼개는 편이 안전합니다. 특히 실행 도구에는 승인 조건을 붙여야 합니다.

세 번째 실수는 로컬 모델을 성능 절감용으로만 보는 것입니다. 로컬 모델의 진짜 가치는 개인정보와 지연 시간입니다. 예를 들어 사용자의 알림, 메모, 거래 내역을 사전 분류하는 작업은 로컬 처리 후보입니다. 서버에는 민감 원문이 아니라 요약과 사용자가 승인한 컨텍스트만 보내는 편이 좋습니다.

적용 예시: 모바일 SRE, 금융 비서, 학습 코치

ADK for Kotlin 1.0은 소비자 앱과 업무 앱 모두에 쓸 수 있습니다.

모바일 SRE 앱에서는 장애 알림을 받고, 지표를 조회하고, 최근 배포와 연결해 원인 후보를 제시할 수 있습니다. 단, 롤백이나 알림 발송은 승인 후 실행해야 합니다.

금융 비서 앱에서는 반복 지출을 분류하고 예산 초안을 만들 수 있습니다. 카드 해지, 자동이체 변경, 투자 주문 같은 작업은 반드시 별도 승인과 로그가 필요합니다.

학습 코치 앱에서는 오프라인 상태에서도 복습 문제를 만들고, 네트워크가 가능할 때 클라우드 모델로 장기 학습 계획을 갱신할 수 있습니다. 이 경우 로컬 모델은 빠른 상호작용, 클라우드 모델은 깊은 분석을 맡습니다.

실행 체크리스트

• AI 기능을 “응답 생성”, “도구 실행”, “승인 대기”, “완료/실패” 상태로 나눕니다.
• 민감 액션은 human-in-the-loop를 기본값으로 둡니다.
• Kotlin 도구 함수는 작은 단위로 만들고 @Tool, @Param 같은 스키마 생성 방식을 우선 검토합니다.
• 세션 저장은 UI 상태와 분리합니다. Room 또는 서버 세션 저장소를 별도로 설계합니다.
• 로컬 모델 후보 작업과 클라우드 모델 후보 작업을 표로 나눕니다.
• 개인정보 원문을 클라우드로 보내기 전에 로컬 요약, 마스킹, 사용자 승인 단계를 둡니다.
• Android 앱 수명주기 테스트에 화면 회전, 백그라운드 복귀, 네트워크 끊김, 프로세스 재시작을 포함합니다.

ADK for Kotlin 1.0은 Android에 AI 에이전트를 붙이는 일을 더 쉽게 만드는 도구입니다. 하지만 쉽게 붙이는 것보다 중요한 것은 안전하게 운영하는 것입니다. 모바일 AI 제품을 준비하는 팀이라면 지금부터 화면 설계보다 세션, 권한, 승인, 로컬·클라우드 분리 기준을 먼저 정해야 합니다.