ADK for Kotlin 1.0 실전 적용: Android·서버 에이전트 설계법

Google이 ADK for Kotlin 1.0을 공개하면서 Kotlin, Java, Android 개발자에게 에이전트 개발 경로가 더 뚜렷해졌다. 발표에서 강조된 내용은 Kotlin Multiplatform 기반 코어, ADK Python·Java와의 기능 정렬, Android-first 확장, Firebase AI Logic과 Vertex AI 연동, Room·AppSearch 기반 상태 저장이다.

개발자 입장에서 중요한 점은 “Kotlin에서도 에이전트를 만들 수 있다”가 아니다. 이미 REST API를 호출하면 어떤 언어에서도 에이전트 비슷한 것을 만들 수 있다. ADK for Kotlin 1.0의 의미는 Android 앱과 JVM 서버에서 에이전트 구조를 타입 안정성, 세션, 메모리, 도구 스키마, human-in-the-loop까지 포함한 형태로 다룰 수 있다는 점이다.

특히 Android 개발팀은 온디바이스 모델, 클라우드 모델, 로컬 저장소, 사용자 승인 UI를 한 앱 안에서 다뤄야 한다. ADK for Kotlin은 이 지점을 정면으로 겨냥한다.

ADK for Kotlin 1.0의 핵심 구성

공개 글에 따르면 ADK for Kotlin 1.0은 KMP 코어를 중심으로 특정 모델 백엔드, 세션 제공자, 메모리 시스템에 종속되지 않게 설계됐다. 여기에 Android 확장이 붙는다.

주요 기능은 다음과 같다.

• 계층형 multi-agent 구성: 루트 에이전트가 하위 전문 에이전트에 작업을 위임한다.
• context compaction과 multi-turn conversation: 긴 대화를 요약하며 토큰 한계를 관리한다.
• human-in-the-loop 흐름: 민감한 액션 전 사용자 확인을 받고 이어서 실행한다.
• annotation 기반 도구 정의: Kotlin 함수에 @Tool, @Param을 붙여 스키마를 생성한다.
• session resumability: 중단된 에이전트 상호작용을 직렬화하고 복원한다.
• Java interoperability: 기존 Java 애플리케이션에서도 Kotlin 에이전트를 호출할 수 있다.
• Vertex AI Agent Platform 연동: 세션, RAG 메모리, 메모리 뱅크를 연결한다.

이 목록을 보면 ADK는 단순 SDK가 아니라 에이전트 런타임에 가깝다.

Android 앱에서 먼저 고려할 설계 질문

Android에 에이전트를 넣을 때 가장 먼저 정해야 할 것은 모델 위치다. 모든 요청을 클라우드로 보내면 구현은 쉽지만 지연 시간, 비용, 개인정보 문제가 생긴다. 반대로 모든 것을 온디바이스로 처리하면 기능 범위와 모델 성능에 제약이 생긴다.

따라서 기능을 세 등급으로 나누는 편이 좋다.

첫째, 온디바이스 처리 영역이다. 개인 메모 요약, 간단한 분류, 오프라인 초안, 민감한 로컬 데이터 검색처럼 개인정보와 반응성이 중요한 작업이 여기에 해당한다. LiteRT-LM이나 ML Kit 기반 베타 확장이 이런 영역에 맞다.

둘째, 하이브리드 영역이다. 사용자의 로컬 상태를 일부 반영하되, 복잡한 reasoning은 클라우드 모델에 맡기는 작업이다. 예를 들어 여행 일정 앱에서 로컬 캘린더와 선호도를 읽고, 전체 일정 최적화는 Gemini로 처리하는 식이다.

셋째, 서버 처리 영역이다. 결제, 팀 데이터, 회사 문서, 운영 시스템과 연결되는 작업은 서버에서 정책 검증과 로그를 남기는 편이 안전하다.

@Tool 기반 함수 호출의 장점과 함정

ADK for Kotlin 글에서 흥미로운 부분은 KSP를 사용해 컴파일 타임에 function call 정의를 생성한다는 점이다. Kotlin 함수에 @Tool과 @Param을 붙이면 타입 안정적인 도구 스키마를 만들 수 있다. 런타임 reflection 없이 suspend 함수까지 지원한다는 설명도 포함됐다.

이 방식의 장점은 명확하다. 도구 정의가 코드와 분리되어 썩는 문제를 줄인다. 파라미터 타입이 바뀌면 컴파일 단계에서 드러난다. 기존 Kotlin 서비스 클래스를 에이전트 도구로 노출하기 쉽다.

하지만 함정도 있다. 함수가 쉽게 도구가 된다고 해서 아무 함수나 노출하면 안 된다. 예를 들어 deleteUser, refundPayment, sendSlackMessage 같은 함수는 @Tool을 붙이는 순간 모델이 호출 가능한 행동이 된다. 따라서 도구 노출 정책이 필요하다.

실무 기준은 다음과 같다.

• 조회 함수와 변경 함수를 분리한다.
• 변경 함수에는 dry-run 또는 preview 모드를 둔다.
• 민감 액션에는 confirmation token을 요구한다.
• 파라미터 설명에는 제한 조건과 금지 조건을 명확히 적는다.
• 도구 결과에는 필요한 필드만 반환한다.

Skill 기반 playbook은 운영 지식을 코드 밖으로 꺼낸다

Google 예시에서는 데이터베이스 incident triage agent가 등장한다. 도구는 메트릭 조회, 최근 배포 조회, 온콜 알림 같은 실행 능력을 제공하고, skill은 “어떤 순서로 진단할지”를 담는다. SKILL.md에 표준 운영 절차를 넣고, 필요한 경우에만 로드하는 progressive disclosure 방식이다.

이 구조는 SRE나 운영 자동화에 특히 좋다. 모든 절차를 프롬프트에 항상 넣으면 토큰이 낭비되고, 업데이트도 어렵다. 반대로 playbook을 skill로 분리하면 팀의 운영 지식을 문서처럼 관리하면서 에이전트가 필요할 때만 가져다 쓴다.

예를 들어 장애 대응 skill은 다음 정보를 가질 수 있다.

• 증상별 첫 진단 순서
• 절대 하면 안 되는 조치
• 피크 시간대 금지 작업
• 알림 채널과 severity 기준
• rollback 판단 기준
• 사람이 승인해야 하는 조치 목록

이렇게 분리하면 개발자는 도구를 만들고, SRE는 playbook을 관리하는 협업 구조가 가능하다.

서버 사이드 Kotlin에서의 활용 패턴

ADK for Kotlin은 Android만을 위한 도구가 아니다. 서버 사이드 Kotlin 팀도 활용할 수 있다. Spring Boot나 Ktor 기반 서비스에서 내부 운영 에이전트, 고객지원 보조, 문서 검색, 배치 분석을 만들 때 Kotlin 타입 시스템을 그대로 쓸 수 있다.

추천 패턴은 백엔드 안에 모든 것을 넣기보다, agent orchestration 레이어를 별도로 두는 것이다. 기존 서비스는 도메인 API를 제공하고, 에이전트 레이어는 그 API를 도구로 호출한다. 이렇게 해야 에이전트 도입 때문에 핵심 비즈니스 로직이 오염되지 않는다.

또한 에이전트 호출은 일반 API와 다르게 시간이 길고 실패 양상이 다양하다. HTTP 요청 하나 안에서 끝내려 하지 말고 job, session, event log 구조를 두는 편이 낫다. 사용자는 진행 상태를 보고, 필요하면 중간 승인이나 중단을 할 수 있어야 한다.

도입 전 체크리스트

• 온디바이스, 하이브리드, 서버 처리 영역을 기능별로 나눴는가
• @Tool로 노출할 함수와 절대 노출하지 않을 함수를 분리했는가
• 변경 작업에는 preview, confirmation, audit log가 있는가
• Skill 문서에 운영 절차와 금지 조치를 코드 밖에서 관리하는가
• Room/AppSearch 같은 로컬 상태 저장이 개인정보 정책과 맞는가
• 세션 복원 시 이전 승인 상태와 권한 상태를 안전하게 검증하는가
• 서버 사이드 에이전트는 job/session 구조로 긴 작업을 다루는가

ADK for Kotlin 1.0은 Kotlin 생태계에 에이전트 개발을 억지로 끼워 넣는 도구가 아니다. 기존 Kotlin 팀이 이미 가진 타입 안정성, 코루틴, Android 저장소, JVM 서버 자산을 에이전트 구조로 연결하는 시도다. 좋은 출발점은 거대한 자율 에이전트가 아니라, 명확한 도구와 playbook을 가진 작은 업무 에이전트다.