ADK for Kotlin 1.0 출시: 안드로이드 AI 에이전트 개발자가 볼 변화

Google이 ADK for Kotlin 1.0 정식 버전을 공개했다. Kotlin, Java, Android 개발자에게 중요한 이유는 “AI 에이전트를 만들 수 있다”는 추상적인 메시지 때문이 아니다. 타입 안전한 도구 호출, 멀티 에이전트 오케스트레이션, 세션 복원, Android 저장소와 온디바이스 확장을 한 묶음으로 제공한다는 점 때문이다. 안드로이드 앱에 AI 기능을 붙일 때 흔히 생기는 문제는 모델 호출보다 상태 관리, 권한 확인, 로컬 데이터 접근, 사용자 승인 흐름이다. 이번 1.0은 이 운영 문제를 정면으로 다룬다.

Google 발표에 따르면 ADK for Kotlin은 Kotlin Multiplatform 코어 위에 만들어졌고, Python·Java ADK 1.0 core와 기능 동등성을 맞췄다. 동시에 Android-first 확장으로 LiteRT-LM, ML Kit, Firebase AI Logic, Room, AppSearch 같은 구성요소를 연결한다. 서버 사이드 Kotlin 개발자도 쓸 수 있지만, 검색 의도가 가장 강한 곳은 “Android 앱에서 프로덕션급 AI 에이전트를 어떻게 만들까”다.

ADK for Kotlin 1.0의 핵심 변화

가장 먼저 볼 것은 도구 호출 방식이다. ADK for Kotlin은 Kotlin Symbol Processing, 즉 KSP를 사용해 @Tool, @Param으로 정의한 함수를 컴파일 타임에 스키마로 만든다. 런타임 reflection에 기대지 않는다는 뜻이다. 금융, 헬스케어, 사내 업무 앱처럼 인자 타입과 승인 조건이 중요한 앱에서는 이 차이가 크다. 문자열 JSON을 손으로 맞추는 방식보다 컴파일 단계에서 깨지는 편이 운영 사고를 줄인다.

두 번째는 멀티 에이전트와 세션 관리다. 계층형 멀티 에이전트, 컨텍스트 압축, human-in-the-loop, long-running tool, session resumability가 포함됐다. 모바일에서는 앱이 백그라운드로 가거나 프로세스가 죽는 일이 자연스럽다. 대화와 작업 상태가 메모리에만 있으면 사용자는 다시 처음부터 설명해야 한다. Room 기반 session service와 AppSearch memory service가 중요한 이유가 여기에 있다.

안드로이드 앱에서 특히 유용한 장면

첫 번째 장면은 개인 금융·커머스 앱이다. 사용자가 “지난달 식비를 줄이고 다음 주 카드값을 맞춰 줘”라고 말하면 앱은 계좌 조회, 예산 계산, 결제 예정 내역 확인을 해야 한다. 하지만 송금이나 결제 일정 변경은 자동 실행하면 안 된다. 발표 예시처럼 requireConfirmation = true가 붙은 도구를 만들면 민감한 행동에 사용자 승인을 요구할 수 있다. 모델이 말로 설득해서 실행하는 것이 아니라 앱 레벨의 승인 흐름이 막아야 한다.

두 번째 장면은 현장 업무 앱이다. 물류, 설비 점검, 영업 방문 앱에서는 네트워크가 불안정하거나 오프라인 상태가 자주 생긴다. 이때 모든 추론을 클라우드 모델에 맡기면 사용자 경험이 끊긴다. 간단한 분류, 문서 검색, 이전 작업 이력 조회는 온디바이스 또는 로컬 인덱스로 처리하고, 복잡한 추론만 Firebase AI나 클라우드 모델로 넘기는 구조가 현실적이다.

세 번째 장면은 고객지원·진단 앱이다. 앱이 로그와 사용자 입력을 모아 원인을 좁히고, 필요한 경우 상담원에게 요약을 전달한다. 여기서 중요한 것은 “그럴듯한 답변”이 아니라 출처와 재현 경로다. 도구 호출로 가져온 메트릭, 최근 배포, 사용자 환경, 앱 버전을 구조화해 남겨야 상담원이 실제로 쓸 수 있다.

Skills와 playbook은 프롬프트 덩어리가 아니다

ADK for Kotlin 예시에는 database incident triage용 skill이 등장한다. 표준 운영 절차를 코드에 하드코딩하지 않고 SKILL.md와 보조 리소스로 두고, 에이전트가 필요한 상황에 로드하는 방식이다. 이 구조는 모바일 앱에도 그대로 적용할 수 있다. 예를 들어 환불 처리, 본인 인증 실패, 배송 지연, 위험 거래 검토 같은 절차는 각각 별도 skill로 둘 수 있다.

중요한 점은 모든 절차를 시스템 프롬프트에 한꺼번에 넣지 않는 것이다. 컨텍스트가 길어질수록 모델은 중요한 규칙을 놓치고 비용도 늘어난다. 필요한 skill만 로드하는 progressive disclosure 구조를 쓰면 토큰을 줄이고 모델의 집중도를 높일 수 있다. 다만 skill 파일은 곧 운영 정책이므로 코드 리뷰와 버전 관리 대상이어야 한다. “프롬프트라서 가볍게 수정”하면 실제 앱 행동이 바뀐다.

기존 Android 아키텍처와 연결할 때 주의할 점

ADK를 붙인다고 MVVM, Clean Architecture, Repository 패턴이 사라지는 것은 아니다. 오히려 더 엄격해야 한다. 에이전트는 사용자 의도를 해석하고 도구를 선택하지만, 실제 데이터 접근과 변경은 앱의 도메인 계층을 통해야 한다. ViewModel에서 모델 응답 문자열을 직접 보고 DB를 수정하는 식으로 만들면 테스트와 감사가 어려워진다.

권장 구조는 이렇다. UI는 사용자 메시지와 승인 이벤트를 수집한다. Agent Runner는 대화와 도구 호출 루프를 관리한다. Tool layer는 도메인 use case를 감싼다. Repository는 네트워크·DB·파일 접근을 처리한다. 민감한 tool은 항상 confirmation 이벤트를 발생시키고, UI가 사용자에게 금액·대상·결과를 명확히 보여 준 뒤 실행한다. 이렇게 해야 AI 기능이 추가돼도 기존 앱의 보안 경계를 유지할 수 있다.

도입 전 체크리스트

• 에이전트가 호출할 수 있는 도구를 읽기, 초안, 변경, 외부 전송으로 분류한다.
• @Tool 함수의 인자 타입을 명확히 만들고 문자열 만능 인자를 줄인다.
• 송금, 구매, 삭제, 개인정보 공유에는 confirmation 흐름을 강제한다.
• Room이나 AppSearch에 저장되는 대화·메모리의 보존 기간을 정한다.
• 오프라인에서 가능한 기능과 반드시 네트워크가 필요한 기능을 나눈다.
• Skills 파일은 코드처럼 PR 리뷰, 버전 관리, 롤백 절차를 적용한다.
• 모델 결과가 아니라 도구 호출과 상태 전이를 테스트한다.

결론

ADK for Kotlin 1.0은 안드로이드 개발자에게 “AI 앱을 빠르게 만들어라”보다 “AI 에이전트를 앱 아키텍처 안에 안전하게 넣어라”에 가까운 메시지를 준다. 좋은 모델 하나를 호출하는 것만으로는 프로덕션 앱이 되지 않는다. 타입 안전한 도구, 세션 복원, 사용자 승인, 로컬 저장소, skill 기반 운영 절차가 같이 있어야 한다. Android 앱에 AI 에이전트를 넣으려는 팀이라면 데모 챗봇부터 만들기보다 도구 경계와 승인 흐름부터 설계하는 것이 맞다.

핵심 출처

• Google Developers Blog, Announcing ADK for Kotlin 1.0
• ADK Kotlin GitHub repository 및 ADK documentation