ADK for Kotlin 1.0, 한국 Android 팀이 먼저 설계할 네 가지 경계

Google은 2026년 9월 9일 ADK for Kotlin 1.0의 정식 출시를 발표했다. 발표의 핵심은 Kotlin Multiplatform 기반 코어, ADK 1.0 코어 기능 정렬, Android 중심의 온디바이스 확장, 그리고 Room·AppSearch를 활용한 상태 지속이다. 한국 Android/Kotlin 제품팀에 중요한 질문은 “에이전트를 넣을 수 있는가”가 아니라 “어떤 작업을 어디에서 실행하고, 어떤 상태와 권한을 제품 경계 안에 둘 것인가”다.

이 글은 공식 발표, ADK 문서, 공식 GitHub 저장소에서 확인되는 내용을 사실로 표시하고, 그 사실을 국내 제품 개발과 운영 조건에 적용한 판단을 POEMORA 해석으로 분리한다. 특정 모델의 품질이나 비용 우위를 단정하지 않으며, 금융·의료·공공 규제 적합성을 보증하지 않는다.

1.0이 확정한 것과 아직 제품팀이 결정할 것

사실. Google Developers Blog는 ADK for Kotlin 1.0이 ADK 1.0 Core와 기능 수준을 맞추고, 멀티 에이전트 조정, 사람 확인 흐름, 장기 실행 도구, 세션 재개, Java 상호운용을 제공한다고 설명한다. Kotlin 도구는 KSP가 컴파일 시점에 함수 호출 정의를 생성하며, 공식 설치 문서는 코어와 KSP 프로세서의 1.0.0 의존성을 안내한다. 공식 저장소는 코어 외에 LiteRT-LM, ML Kit, Firebase, A2A, 웹 서버 등의 모듈을 분리해 제시한다.

사실. Android 확장에서는 LiteRT-LM을 통한 로컬 모델, ML Kit의 Gemini Nano, Firebase AI Logic을 통한 클라우드 모델을 선택할 수 있다. 다만 공식 저장소의 현재 설명에서 ML Kit 모듈은 베타이고 도구 호출을 아직 지원하지 않는다. LiteRT-LM은 도구 호출을 지원하지만 모델 파일 배포, 기기 자원, 호환성은 앱이 책임져야 한다. 따라서 “같은 Agent API”가 “모든 백엔드의 능력이 동일하다”는 뜻은 아니다.

POEMORA 해석. 1.0은 프레임워크 API의 기준선을 제공하지만 제품의 준비 완료를 대신하지 않는다. 팀은 기능표를 그대로 로드맵으로 옮기기보다, 지원 단말 분포와 앱 용량, 배터리·발열, 네트워크 실패율, 개인정보 처리 흐름, 서버 관측 가능성을 별도 승인 조건으로 두어야 한다. 특히 베타 모듈은 핵심 거래 경로가 아니라 되돌릴 수 있는 보조 기능에서 먼저 검증하는 편이 낫다.

온디바이스와 하이브리드는 모델 선택이 아니라 데이터 경계다

사실. 공식 Android 문서는 ADK 에이전트가 로컬, 호스팅 서비스, Android 기기에서 실행될 수 있으며, Gemini Nano 기반 기능은 네트워크 없이도 개인정보 보호와 낮은 지연 시간에 유리한 경험을 만들 수 있다고 설명한다. 공식 저장소는 LiteRT-LM과 ML Kit를 온디바이스로, Firebase AI를 클라우드로 구분하고 동일한 LlmAgent API 뒤에 모델 백엔드를 배치한다.

POEMORA 해석. 실무의 첫 분류 기준은 모델명이 아니라 데이터의 이동 가능 범위다. 예를 들어 입력기 보조, 로컬 문서 요약, 민감 텍스트의 1차 분류는 기기 안에서 처리할 후보가 된다. 반면 최신 사내 지식 검색, 대규모 문맥 추론, 중앙 정책이 필요한 작업은 클라우드가 유리할 수 있다. 하이브리드는 “로컬 실패 시 전부 서버로 전송”하는 단순 폴백이 아니라, 로컬에서 비식별화·요약한 최소 정보만 서버로 넘기는 명시적 파이프라인이어야 한다.

릴리스 명세에는 작업별로 입력 데이터 등급, 허용 실행 위치, 네트워크 단절 시 동작, 클라우드 전환 전 사용자 고지, 로그에 남길 수 없는 필드를 적어야 한다. 온디바이스 추론 실패가 조용히 클라우드 전송으로 바뀌면 사용자가 기대한 개인정보 경계가 깨진다. 반대로 무조건 로컬만 고집하면 저사양 단말에서 품질과 응답성이 급격히 달라질 수 있다. 원격 설정으로 경로를 바꾸더라도 데이터 등급 규칙은 앱 내부의 결정적 코드로 고정하는 편이 안전하다.

상태 지속은 대화 저장보다 넓은 복원 계약이다

사실. ADK 문서는 Session을 한 대화 흐름과 이벤트의 시간순 기록, State를 해당 세션의 임시 데이터, Memory를 여러 세션에 걸쳐 검색 가능한 정보로 구분한다. 인메모리 구현은 로컬 테스트와 빠른 개발용이며 앱이나 프로세스가 재시작되면 데이터가 사라진다고 명시한다. 1.0 발표는 Android에서 Room 기반 세션, AppSearch 기반 메모리, Android 저장소의 아티팩트를 조합하고, 실행 중인 상호작용을 일시 정지·직렬화·복원할 수 있다고 설명한다.

POEMORA 해석. 제품팀은 “채팅이 다시 보인다”와 “작업이 안전하게 재개된다”를 분리해 검증해야 한다. 결제 요청 직전 앱이 종료됐다면 재실행 후 승인 화면을 다시 보여 줄지, 요청을 폐기할지, 서버의 처리 결과를 조회할지 결정해야 한다. 세션 이벤트, UI 초안, 사용자별 장기 메모리, 파일 아티팩트, 도구 실행 영수증은 수명과 삭제 책임이 서로 다르다.

권장 복원 계약은 네 가지다. 첫째, 외부 변경 도구마다 멱등성 키와 최종 상태 조회 경로를 둔다. 둘째, 승인 대기 상태는 원래 인자와 정책 버전을 함께 보존하되 일정 시간이 지나면 만료한다. 셋째, 로그아웃·계정 삭제·기기 이전 때 Room, AppSearch, 파일 저장소를 같은 사용자 경계로 정리한다. 넷째, 스키마 마이그레이션 실패 시 자동 실행을 재개하지 않고 안전한 읽기 전용 화면으로 전환한다. 상태 지속은 편의 기능이 아니라 데이터 보존과 중복 실행을 다루는 제품 계약이다.

도구 권한은 프롬프트 밖에서 강제해야 한다

사실. ADK Kotlin은 @Tool과 KSP 생성 래퍼를 제공하고, 공식 API 문서는 위험한 함수에 확인 요구를 설정해 실행을 멈춘 뒤 사용자의 승인을 받아 재개하는 흐름을 설명한다. ADK 콜백 문서는 모델 호출 전후와 도구 실행 전후에 입력·출력을 검사하거나 실행을 중단할 수 있다고 설명한다. 안전 문서는 도구 내부 검증, 사용자 권한 위임, 콜백·플러그인, 샌드박스, 네트워크 통제를 함께 권고한다.

POEMORA 해석. 확인 버튼 하나가 권한 모델 전체는 아니다. 조회 도구와 변경 도구를 다른 인터페이스로 나누고, 각 도구에는 필요한 최소 범위의 자격 증명만 제공해야 한다. 사용자 ID, 금액, 대상 리소스, 테넌트 같은 인자는 세션 상태와 서버 정책으로 다시 대조한다. “사용자가 승인했다”는 이벤트에는 보여 준 요약, 실제 실행 인자, 정책 버전, 호출 ID가 연결돼야 하며, 승인 뒤 인자가 달라지면 재승인을 요구해야 한다.

Android에서는 인텐트, 파일, 연락처, 위치처럼 OS 권한과 연결된 도구가 많다. 앱 권한이 있다고 에이전트가 항상 사용할 수 있는 것은 아니다. 화면이 잠긴 상태, 백그라운드 실행, 기업용 관리 프로필, 보호자 통제 등 제품 맥락을 추가로 검사해야 한다. 프롬프트는 허용 범위를 모델에 설명하지만, 최종 허용·거부는 테스트 가능한 Kotlin 코드와 서버 권한 정책이 결정해야 한다.

평가는 답변과 실행 경로를 함께 본다

사실. ADK 평가 문서는 확률적인 에이전트에는 전통적인 단일 pass/fail만으로 부족하며, 최종 응답의 품질뿐 아니라 도구 선택과 단계 순서인 trajectory를 평가해야 한다고 설명한다. 먼저 성공 조건, 핵심 작업, 관련 지표를 정의하고 실제 경로를 기대 경로와 비교하는 방식을 권한다. 콜백은 입력·출력 검증과 도구 차단 지점으로 사용할 수 있고, 안전 문서는 모델 필터만이 아니라 도구 검증, 샌드박스, 평가와 추적을 다층 방어로 제시한다.

POEMORA 해석. 한국 제품팀의 최소 회귀 세트에는 정상 요청만 넣어서는 안 된다. 권한 없는 다른 사용자 데이터 요청, 금액 변조, 프롬프트 인젝션이 섞인 문서, 네트워크 단절, 앱 강제 종료 뒤 복원, 같은 승인 이벤트의 재전송, 낮은 사양 단말의 시간 초과를 포함해야 한다. 각 케이스에서 최종 문장 점수와 함께 호출된 도구, 인자, 순서, 승인 여부, 외부 변경 횟수를 기록한다.

가드레일도 평가 대상이다. 차단율만 높이면 정상 사용자를 막을 수 있으므로 위험 요청 차단, 정상 요청 통과, 개인정보 노출, 중복 실행, 복구 성공을 따로 본다. 모델 변경이나 프롬프트 수정뿐 아니라 앱 버전, 정책 버전, 저장 스키마 변경 때도 같은 세트를 실행한다. 운영에서는 원문 전체를 수집하기보다 민감정보를 제거한 이벤트와 정책 결정 이유를 남겨 재현 가능성과 개인정보 최소화를 함께 지킨다.

한국 Android 팀을 위한 단계별 도입 순서

POEMORA 해석. 첫 단계는 읽기 전용 한 가지 작업을 고르는 것이다. 온디바이스와 클라우드 후보를 같은 입력 세트로 비교하고, 지원 단말·응답 시간·오프라인·개인정보 경계를 문서화한다. 두 번째는 Session, State, Memory, Artifact의 보존 기간과 삭제 트리거를 정하고 강제 종료와 업그레이드 복원 테스트를 만든다. 세 번째에만 변경 도구를 추가하되 최소 권한, 인자 검증, 명시적 확인, 멱등성, 감사 이벤트를 출시 조건으로 묶는다.

네 번째는 답변과 trajectory를 함께 보는 자동 평가를 CI에 연결하는 것이다. 마지막으로 제한된 사용자군에서 관측한 실패 유형을 바탕으로 경로를 넓힌다. ADK 1.0의 가치는 이 순서를 생략하게 하는 데 있지 않다. Kotlin 코드, Android 저장소, 로컬·클라우드 모델, 확인 흐름을 한 구조에서 다룰 수 있게 해 제품팀이 경계를 더 명시적으로 구현하도록 돕는 데 있다.

도입 설계와 위험 경계 검토가 필요하다면 POEMORA의 AI 자동화 개발 서비스를 참고하거나, 현재 앱 구조를 기준으로 상담을 요청할 수 있다.