GDG Korea Android: 2026 I/O Extended 후기

현승·2026년 7월 28일

행사

목록 보기
1/1

Android의 변화를 만나러 간 GDG

GDG Korea Android 2026 I/O Extended 행사장

GDG Korea Android 2026 I/O Extended 행사장에 도착했다.

7월 25일 토요일, 우테코 안드로이드 크루들과 함께 GDG Korea Android에서 진행한 2026 I/O Extended 행사에 참여했다.

이번 행사는 Google I/O에서 공개된 Android 생태계의 최신 변화와 개발 도구를 살펴보고, App Functions를 직접 체험해볼 수 있는 핸즈온 세션으로 구성되어 있었다.

우테코에서 Android와 Jetpack Compose를 학습했었던 만큼, 공식 문서나 수업을 통해 접하던 기술들이 실제 현업과 개발자 커뮤니티에서는 어떻게 받아들여지고 있는지 확인해보고 싶었다. 크루들과 함께 새로운 기술을 경험하고, 각자가 받아들인 내용을 나눠보고 싶다는 마음도 있었다.

발표 세션과 App Functions 핸즈온이 동시에 진행되었기 때문에, 핸즈온에 참여하는 동안 Android 17의 MessageQueue, Android CLI, On-device AI 세션을 직접 듣지는 못했다. 듣지 못한 세션에 대한 아쉬움은 남았지만, 행사 이후 크루들이 공유해준 발표 자료를 읽으며 내용을 추가로 학습해보았다.

이번 행사는 단순히 Android의 새로운 기능을 소개받는 자리는 아니었다. Android 플랫폼의 내부 구조와 AI를 활용한 개발 방식, 그리고 개발자의 역할까지 조금씩 달라지고 있다는 것을 확인할 수 있었던 시간이었다.


1. Android 개발의 기본값이 Compose로 바뀌고 있다

첫 번째 세션은 Google I/O에서 공개된 Android의 주요 변화를 살펴보는 What's New in Android였다. 발표에서는 UI와 개발 환경, 성능과 빌드 최적화, AI, 보안, 미디어와 멀티 디바이스 등 Android 생태계의 다양한 변화가 소개되었다.

그중에서도 가장 인상 깊었던 내용은 Android UI 개발의 중심이 Jetpack Compose로 이동하고 있다는 점이었다. View에 대한 업데이트가 줄어들고 Compose에 힘을 싣고 있다는 이야기는 이전에도 들었지만, 실제 발표에서 듣게 되니 새롭게 다가왔다.

기존 View 시스템은 유지보수 단계에 들어갔으며, 새로운 기능은 Compose를 중심으로 제공되고 있었다. 그렇다고 기존 프로젝트를 모두 Compose로 다시 작성해야 하는 것은 아니었다. 기존 화면은 유지하면서 새롭게 만드는 화면부터 Compose를 적용하는 점진적인 전환 방식이 권장되고 있었다.

우테코에서 Compose를 학습하고 있었기 때문에 이 내용이 더욱 가깝게 느껴졌다. 지금까지는 Compose를 단순히 XML을 대신하는 새로운 UI 작성 도구로 생각한 부분도 있었다. 하지만 이번 세션을 통해 Compose가 여러 선택지 중 하나라기보다 앞으로 Android UI 개발의 기본이 되는 방향이라는 점을 다시 확인할 수 있었다.

또한 XML 화면을 Compose로 변환하는 과정을 AI 에이전트가 도울 수 있도록 Android Skill이 제공된다는 점도 흥미로웠다. 발표 사례에서는 결과를 그대로 적용하지 않고, 기존 프로젝트의 아키텍처를 유지하도록 Skill을 팀 환경에 맞게 수정해 사용하고 있었다.

이를 보면서 AI 도구를 잘 활용한다는 것은 단순히 코드를 생성하게 하는 것이 아니라, 프로젝트의 규칙과 의도를 정확히 전달하는 과정이라는 생각이 들었다.


2. 눈에 보이지 않는 구조가 앱의 반응성을 바꾼다

다음으로 살펴본 내용은 Android 17의 Lock-Free MessageQueue였다. 이 세션은 핸즈온에 참여하느라 현장에서 직접 듣지는 못했지만, 행사 이후 발표 자료를 읽으며 따로 학습해보았다.

Android 앱에서는 Handler, Looper, MessageQueue를 통해 메인 스레드에서 실행할 작업을 순서대로 처리한다. 기존 MessageQueue는 여러 스레드가 하나의 lock을 공유하고, 메시지를 실행 순서에 맞게 정렬하는 과정까지 lock 내부에서 처리했다. 이로 인해 메시지가 많아질수록 lock 경쟁과 작업 지연이 발생할 가능성이 있었다.

Android 17의 DeliQueue는 메시지를 등록하는 Producer와 실행 순서를 정리하는 Looper의 책임을 분리해 이를 개선했다. 개발자가 사용하는 Handler API는 그대로 유지하면서 내부 구조를 변경해 앱의 시작 시간과 프레임 처리 성능을 개선하려는 변화였다.

이 내용을 보면서 평소 사용하는 API의 뒤에서도 성능을 개선하기 위한 많은 고민과 변화가 이루어지고 있다는 것을 느꼈다. 앱을 개발할 때는 화면에 직접 보이는 기능이나 내가 작성한 코드의 성능에만 집중하기 쉽지만, 프레임워크 내부의 자료구조와 스레드 처리 방식 역시 사용자 경험에 영향을 줄 수 있었다.

모든 내부 구현을 세세하게 외울 필요는 없겠지만, 플랫폼의 구조가 왜 변경되었는지를 살펴보는 과정은 Android를 더 깊게 이해하는 데 도움이 될 것 같다.


3. AI와 함께하는 Android 개발 방식

다음으로 살펴본 내용은 AI 에이전트를 위한 Android CLI였다. 이 세션 역시 현장에서 직접 듣지는 못했지만, 발표 자료를 통해 Android 개발 도구가 어떻게 변화하고 있는지 살펴보았다.

Android CLI는 AI 에이전트가 Android 앱을 더 효율적으로 개발할 수 있도록 돕는 명령줄 도구다. 프로젝트 생성과 빌드, 앱 실행, 에뮬레이터 제어, 공식 문서 검색, 실행 중인 화면의 UI 구조 확인 등을 터미널에서 수행할 수 있다. 또한 Claude Code, Codex, Gemini처럼 특정 AI 에이전트에 종속되지 않고 공통으로 사용할 수 있다는 특징이 있었다.

기존에는 AI가 Android 공식 문서를 확인하기 위해 웹을 검색하고 필요한 내용을 다시 정리해야 했다. Android CLI는 필요한 데이터를 AI가 이해하기 쉬운 형태로 전달하고, 빌드나 앱 실행이 끝날 때까지 확인한 뒤 결과를 반환한다. 이를 통해 AI가 Android Studio와 에뮬레이터의 기능까지 활용할 수 있게 된다.

특히 실행 중인 앱의 UI 구조를 분석하는 방식이 인상 깊었다. 기존 adb 명령으로 화면 정보를 가져오면 많은 속성이 포함된 XML을 다뤄야 하지만, Android CLI는 AI가 화면을 조작하는 데 필요한 정보만 추려서 전달했다. 단순히 명령어를 묶어놓은 도구가 아니라, Android 개발 환경과 AI 에이전트 사이를 연결하는 도구에 가깝다고 느꼈다.

이번 내용을 보면서 AI 시대의 개발 생산성은 코드를 얼마나 빠르게 생성하는지만으로 결정되지 않는다는 생각이 들었다. AI가 프로젝트와 실행 환경을 이해하고 자신이 만든 결과를 직접 검증할 수 있어야 실제 개발에서도 신뢰할 수 있기 때문이다.

개발자의 역할도 모든 코드를 직접 작성하는 것에서 요구사항을 명확하게 정의하고, AI가 만든 결과를 검토하며 올바른 방향으로 이끄는 쪽으로 변화할 것 같다. 나 역시 코드가 동작한다는 이유만으로 넘어가기보다, 왜 이러한 구조가 만들어졌고 기존 코드에 어떤 영향을 주는지를 판단하는 힘을 길러야겠다고 느꼈다.


4. AI가 클라우드를 벗어나 기기 안으로 들어오다

이 발표는 Android에서의 On-device AI에 관한 내용이었다. 이 세션도 핸즈온과 동시에 진행되어 현장에서 직접 듣지는 못했지만, 행사 이후 발표 자료를 통해 내용을 살펴보았다.

On-device AI는 AI 모델의 연산을 서버가 아닌 사용자의 기기 안에서 직접 수행하는 방식이다. 외부 서버로 데이터를 보내지 않아 개인정보 보호에 유리하고, 네트워크가 없는 상황에서도 사용할 수 있으며 응답 속도를 줄일 수 있다는 장점이 있었다.

반면 스마트폰은 서버에 비해 메모리와 연산 자원이 제한되어 있고, 배터리와 발열도 함께 고려해야 한다. 따라서 모든 기능을 기기에서 처리하기보다 어떤 기능을 기기에서 처리하고 어떤 기능을 서버에 맡길지 구분하는 과정이 필요했다.

지금까지 앱에 AI 기능을 적용할 때는 외부 API를 호출하는 방식을 먼저 생각했지만, 앞으로는 개인정보나 반복적으로 사용하는 데이터를 기기 안에서 처리할 수 있는지도 함께 고민해볼 수 있을 것 같다.


5. 화면을 넘어 AI에게 앱의 기능을 공개하다

앞선 발표들이 진행되는 동안 나는 App Functions를 직접 다뤄보는 핸즈온 세션에 참여했다.

기존 앱에서는 사용자가 화면을 열고 버튼을 누르거나 값을 입력해 기능을 사용했다. 반면 App Functions는 앱의 핵심 기능을 시스템이나 AI 에이전트가 호출할 수 있는 함수로 공개하는 API였다.

기존 Kotlin 함수에 @AppFunction을 선언하면 에이전트가 해당 기능을 발견하고 실행할 수 있다. 앱이 사람에게 보여주는 UI뿐만 아니라, AI 에이전트에게 제공하는 또 하나의 진입점을 갖게 되는 셈이었다.

핸즈온에서는 공식 android/appfunctions 샘플 프로젝트를 내려받고, 제공된 API Key를 사용해 에이전트 앱을 실행했다. 일반 앱은 다른 앱의 함수를 마음대로 실행할 수 없기 때문에, 별도의 스크립트로 에이전트 앱에 필요한 권한을 부여했다.

우리가 주로 다룬 것은 App Function을 호출하는 에이전트보다 자신의 기능을 제공하는 앱의 입장이었다. Kotlin 함수에 @AppFunction을 붙이고 KDoc으로 함수의 역할과 매개변수를 설명하면, KSP가 시스템에 등록할 메타데이터와 호출 코드를 자동으로 생성해주었다.

특히 인상 깊었던 것은 KDoc이 단순한 개발 문서를 넘어 AI가 함수를 이해하기 위한 명세가 된다는 점이었다. 함수가 언제 호출되어야 하는지, 먼저 호출해야 할 다른 함수가 있는지, 예외가 발생했을 때 사용자에게 무엇을 다시 물어봐야 하는지까지 KDoc에 작성할 수 있었다.

결국 AI가 함수를 올바르게 사용하는지는 함수 구현뿐만 아니라, 개발자가 기능의 의도를 얼마나 명확히 설명했는지에도 영향을 받았다.

처음에는 App Functions를 앱 내부 함수를 외부에서 호출할 수 있게 해주는 단순한 기능이라고 생각했다. 하지만 실습 이후에는 앱을 설계할 때 고려해야 할 사용자가 사람에서 AI 에이전트까지 확장되고 있다는 느낌을 받았다.

앞으로는 화면을 어떻게 만들지 고민하는 것을 넘어, 앱의 기능을 어떤 단위와 형태로 외부에 제공할지도 함께 고민해야 할 수 있겠다는 생각이 들었다.

이후에는 각자 자신의 앱에 App Functions를 적용해보는 시간도 주어졌다. 하지만 당시에는 내가 만들고 있던 서비스에서 어떤 기능을 공개하면 좋을지 아이디어가 떠오르지 않아 직접 적용해보지는 못했다. 실습까지 이어가지 못한 점은 아쉬웠지만, 앱의 기능을 사람뿐만 아니라 AI 에이전트에게도 제공할 수 있다는 발상 자체는 충분히 흥미로웠다.


6. 예상하지 못한 선물

행사 마지막에는 참가자를 대상으로 추첨도 진행되었다. 큰 기대 없이 결과를 기다리고 있었는데, 운 좋게도 Skydoves 님의 친필 사인이 담긴 Jetpack Compose Mechanisms 책을 받게 되었다.

우테코에서 Jetpack Compose를 학습하고 있는 시기에 Compose의 내부 동작을 다루는 책을 받게 되어 더욱 의미 있게 느껴졌다. 아직 내가 이해하기에는 어려운 내용도 많겠지만, 앞으로 Compose를 조금 더 깊게 공부하면서 천천히 읽어보고 싶다.

추첨으로 받은 Jetpack Compose Mechanisms

Skydoves 님의 친필 사인이 담긴 책까지 받으며 기분 좋게 행사를 마무리했다.


7. 기술의 변화 속에서 개발자가 해야 할 일

이번 행사에서 살펴본 기술들은 서로 다른 주제를 다루고 있었지만, 결국 하나의 방향으로 연결되어 있다는 생각이 들었다.

Jetpack Compose는 Android UI 개발의 기본적인 방식으로 자리 잡아가고 있었고, Android 17에서는 플랫폼 내부에서도 앱의 반응성을 높이기 위한 변화가 이루어지고 있었다. Android CLI는 AI 에이전트가 Android 개발 환경을 이해하고 결과를 직접 검증할 수 있도록 돕고 있었으며, On-device AI는 AI 기능이 사용자의 기기 안으로 들어오고 있다는 점을 보여주었다. App Functions는 AI가 앱의 기능을 직접 발견하고 실행할 수 있는 가능성을 보여주었다.

이번 행사에서 가장 크게 느낀 점은 새로운 기술이 등장한다고 해서 개발자의 역할이 줄어드는 것은 아니라는 점이었다. 오히려 기술을 어떤 상황에 적용할지 판단하고, 프로젝트의 의도를 명확하게 정의하며, 만들어진 결과를 검증하는 역량이 더욱 중요해지고 있었다.

앞으로도 새로운 기술을 빠르게 사용해보는 것에서 그치지 않고, 이 기술이 어떤 문제를 해결하기 위해 등장했는지와 내 프로젝트에는 어떤 방식으로 적용할 수 있을지를 함께 고민해보고 싶다.

이번 GDG I/O Extended는 Android 개발의 현재를 살펴보는 시간이면서, 변화하는 환경 속에서 내가 어떤 개발자로 성장해야 할지를 고민해볼 수 있었던 자리였다.

profile
끊임없이 배우고 나아가기를 좋아하는 개발자!

0개의 댓글