Compose HotSwan v2 베타: 핫 리로드로 화면 전체 변경 및 AI로 실시간 편집

Compose 세계에서 핫 리로드(hot reload)는 아직 생소합니다. JetBrains에서 제공하는 Desktop용 Hot Reload마저도 값을 바꾸면 그 값이 보이는 것, 딱 거기까지였습니다. 색상을 바꾸고 패딩을 살짝 조정하고 문자열을 고치는 정도입니다. 유용하지만 솔직하게 한계가 뚜렷합니다. 컴포저블을 하나 추가하거나 레이아웃 순서를 바꾸거나 제어 흐름을 손대는 순간, 곧바로 앱 전체 빌드와 재실행으로 되돌아가야 합니다. AI 시대에서는 대부분의 사람들이 LLM을 통해서 코드를 작성하기 때문에 정밀한 디자인 수정 작업이 아닌 이상 크게 효용성이 떨어집니다.

Compose HotSwan v2는 그 경계를 한참 넘어섭니다. 레이아웃을 다시 짜고, 컴포저블을 추가하거나 제거하고, 화면이 분기하는 방식을 바꾸고, 심지어는 화면 하나를 통째로 교체할 수도 있습니다. 핫 리로드가 동작하는 동안 앱은 재시작되지 않습니다. 내비게이션 스택도 있던 자리에 그대로 남아 있습니다. 화면에 띄워 둔 상태 역시 새 코드가 렌더링될 때 여전히 그 자리에 있습니다.

아래 영상에서는 Now in Android의 For You 화면이 완전히 다른 테마로 교체됩니다. 단순한 값 조정이 아닙니다. 새로운 구조, 새로운 컴포저블, 새로운 코드를 실행 중인 앱에 제자리에서 그대로 적용한 결과입니다.

그런데 핫 리로드 같은 도구가 굳이 왜 필요할까요? 핫 리로드가 처음이신 분들을 위해, 이 도구가 해결해 주는 문제를 짚어 보겠습니다. 저희가 개발하고 있는 화면이 5~7개 정도의 depth를 거쳐야 하는 위치에 있다고 떠올려 봅시다. 코드를 하나 수정하면, 재컴파일, 앱 재설치, 앱 재실행, 스플래시 화면을 보는 과정까지 거쳐 디버그하려는 화면까지 이동해서 네트워크 데이터를 불러오고, 보고 싶은 영역까지 스크롤하느라 시간을 써야 합니다. 코드 한 줄 바꾸면 이 행동을 또 해야 합니다. 저희가 하고 싶은 일은 단순히 텍스트 사이즈를 조금 더 키우는 것뿐입니다. fontSize = 16.sp를 18.sp로 바꾸면, Gradle이 빌드를 하기 시작하고 어느새 노트북은 뜨끈해집니다.

작은 프로젝트라면 30초쯤 기다립니다. 멀티 모듈로 이뤄진 큰 코드베이스라면 5분, 10분, 길게는 30분이 걸리기도 합니다. 빌드가 끝나면 앱이 다시 설치되고, 홈 화면부터 새로 시작됩니다. 상태는 사라졌고, 숫자 하나 바뀐 걸 보겠다고 그 일곱 화면을 다시 거치고, 데이터를 다시 불러오고, 같은 위치까지 다시 스크롤해야 합니다. 몇 분에 걸쳐 쌓아 올린 맥락이 단 한 번의 빌드 사이클에 무너집니다. 이것이 바로 빌드 비용이고(영어로는 빌드 세금, build tax), 변경할 때마다 꼬박꼬박 치러야 하는 대가입니다.

핫 리로드를 쓰면 같은 변경이 몇 초 남짓이면 끝납니다. 앱은 재시작되지 않습니다. 같은 데이터, 같은 스크롤 위치, 같은 내비게이션 상태를 그대로 둔 채 같은 화면에 머무르기 때문에, 조금 전까지 16.sp였던 바로 그 자리에서 18.sp를 확인하고 그 자리에서 바로 결정할 수 있습니다. 특히 문자열이나 컬러 색상 같은 리터럴 값은 거의 밀리초 단위로 즉각 반영이 됩니다.

핫 리로드의 장점은 도달하기 까다로운 화면을 수정할 때 빛을 발합니다. 특정 API 실패 뒤에 나타나는 에러 상태, 텅 빈 목록, 결제를 마쳐야만 보이는 영수증 화면 같은 곳이 일례가 될 수 있습니다. HotSwan은 리로드를 하는 중에도 내비게이션 스택과 앱 상태를 유지하므로, 직접 만들어 둔 바로 그 상태 그대로 머물 수 있습니다. 여기서 상태 보존은 있어도 되고 없어도 되는 기능이 아닙니다. 상태 보존이 바로 핫 리로드의 핵심입니다. 내비게이션과 remember 값을 모두 날려 버리는 형태의 새로고침은, 그 변경이 실제 사용 흐름에서 어떤 느낌인지 거의 아무것도 알 수 없습니다. 그냥 빠른 재빌드랑 다를 것이 없습니다. 이와 관련하여 깊게 살펴보고 싶으신 분은 핫 리로드가 중요한 이유를 읽어보실 수 있습니다.

최근과 같은 AI 시대에 코드를 찍어내고 수정하는 일은 AI 덕분에 2배 3배 그 어느 때보다 빨라졌지만 빌드는 여전히 변화가 없습니다. 즉, 느린 빌드 시스템이 어느새 반복적인 피드백 루프에서 가장 느린 병목 구간이 되어 가고 있다는 뜻입니다. 웹은 거의 빌드 즉시 결과가 나타나기 때문에 웹 개발 시장에서는 핫 리로드라는 것이 필요가 없습니다. 모바일은 다릅니다. 때문에, 핫 리로드가 단순한 편의 기능이라기보다 차세대 앱 개발에서 아주 중요한 가치로 평가받는 이유입니다.

AI 에이전트는 이제 사실상 선택이 아니라 필수처럼 자리하고 있습니다. 그런데 AI 에이전트를 통해서 수많은 코드의 패키지나 구조적 변경이 발생하면 기존의 핫 리로드 시스템으로는 할 수 있는 것이 아무것도 없습니다. 하지만 v2에서는 광범위한 구조적 변경을 가능하게 하고, 안드로이드 스튜디오의 텍스트 편집기를 관찰하여, AI 에이전트의 코드 수정 사항을 즉각 반영할 수 있는 수준까지 도달했습니다. 아래 영상을 보시면 에이전트가 화면을 완전히 다른 스타일로 다시 작성하고, 그 작업이 진행되는 동안 기기가 실시간으로 갱신됩니다. 여러분들은 그냥 실행 중인 안드로이드 기기에 에이전트가 짠 코드의 결과를 실시간으로 지켜보기만 하면 됩니다.

v2는 별도의 릴리스 채널에서 베타로 제공되기 때문에, Stable 버전을 설치할 때보다 한 가지 과정이 더 필요합니다.

버전 카탈로그에 HotSwan 컴파일러 플러그인을 2.0.0-beta01 버전으로 선언한 다음, 앱 모듈에 적용합니다.

1[plugins]
2hotswan-compiler = { id = "com.github.skydoves.compose.hotswan.compiler", version = "2.0.0-beta01" }

1alias(libs.plugins.hotswan.compiler) apply false

1alias(libs.plugins.hotswan.compiler)

Gradle 플러그인 버전과 IDE 플러그인 버전은 반드시 일치해야 합니다. 둘 다 2.0.0-beta01로 맞춰야 합니다.

베타 빌드는 별도 채널에 게시되기 때문에 기본 마켓플레이스 검색에는 나타나지 않습니다. 베타 빌드를 한 번 내려받아 디스크에서 직접 설치하면 됩니다.

1. 베타 버전 페이지를 열고 2.0.0-beta01 빌드를 다운 받으실 수 있습니다.
2. IDE에서 Settings > Plugins를 열고, 톱니바퀴 아이콘을 클릭한 뒤 Install Plugin from Disk를 선택하세요. 방금 내려받은 파일을 고르면 됩니다.
3. 안내가 뜨면 IDE를 재시작하세요.

평소처럼 Run 버튼으로 앱을 실행하세요. View > Tool Windows > HotSwan에서 HotSwan 도구 창을 엽니다. 창에 WATCHING이라고 표시되면 연결된 것입니다.

이제 컴포저블을 수정하고 저장한 뒤, 실행 중인 기기에 변경이 반영되는 모습을 지켜보시면 됩니다. 앱 재컴파일, 재설치, 화면을 거슬러 돌아가는 일도 없습니다. 앱 모듈이 :app이 아니라면(가령, Kotlin Multiplatform 프로젝트는 :app:androidApp을 쓰는 경우가 많습니다) Settings > Tools > Compose HotSwan에서 모듈 경로를 지정하실 수 있습니다.

v1도 이미 상태를 보존했고 값 변경을 빠르게 적용했습니다. v2는 그 모든 것을 그대로 유지하면서, 컴파일러가 이해할 수 있는 변경의 범위를 넓힙니다. 짧게 요약하면 v1이 이미 존재하는 화면을 다듬는 데 강했다면, v2는 화면이 무엇인지 그 자체를 바꾸는 데 초점을 맞춰 만들어졌습니다.

아래 표는 기능 체크리스트가 아니라 적용 범위를 비교한 것입니다. 일상적으로 하게 되는 수정 유형을 묶어, v2가 구조적인 영역으로 얼마나 더 깊이 커버가 가능한지 확인하실 수 있습니다.

핫 리로드 시스템은 Desktop이라고 하더라도 어렵습니다. 논문 한두 편은 낼 수 있는 수준입니다. 내부 시스템이 궁금하신 분들은 JetBrains에서 작성한 The Journey to Compose Hot Reload 1.0.0을 읽어보시길 바랍니다.

안드로이드에서는 ART라는 런타임 제약 덕분에 몇 배는 어렵습니다. Compose HotSwan을 사용하는 데 이런 내용을 꼭 알아야 하는 건 아니지만, 알아 두면 이 반복 루프가 왜 이렇게 느껴지는지 이해하는 데 도움이 됩니다. v2는 수정 하나하나마다 가장 비용이 적게 드는 방식을 채택하였습니다.

가장 빠른 방식은 리터럴 패칭(literal patching)입니다. 색상 16진수 값, 치수, 문자열, 숫자처럼 리터럴 값을 바꾸면, HotSwan은 그 값만 실행 중인 앱으로 보내고 컴파일은 통째로 건너뜁니다. 그래서 50밀리초도 채 안 되어 반영됩니다. 리터럴을 넘어서는 변경, 가령 새로운 구조나 새로운 로직은 조금 더 긴 경로를 탑니다. HotSwan이 바뀐 코드만 컴파일해 실행 중인 앱에 적용하면, Compose가 그 코드에 의존하는 스코프를 리컴포즈합니다. 이 경로도 1초쯤이면 끝납니다.

상태가 살아남는 이유는, Compose가 이미 UI를 슬롯 테이블(slot table) 안의 스코프 트리로 추적하고 있기 때문입니다. 슬롯 테이블은 각 컴포저블의 상태와 매개변수, 자식 요소를 담아 두는 구조입니다. v2가 변경을 적용하면 런타임은 어떤 스코프가 영향을 받는지 정확히 알고, 그 스코프만 리컴포즈합니다. remember 값, 스크롤 위치, 내비게이션 스택은 전혀 건드리지 않습니다. 컴포저블의 순서를 바꿔도 이 동작은 그대로 유지되는데, 상태가 파일 안에서의 위치가 아니라 컴포저블의 정체성을 기준으로 추적되기 때문입니다.

타깃 리컴포즈로 감당하기엔 변경이 너무 깊을 때, v2는 단순히 앱을 재실행하여 상태를 다 초기화하는 대신 한 단계씩 차분하게 내려갑니다. rememberSaveable 값과 ViewModel, 내비게이션을 그대로 유지한 채 컴포지션을 초기화할 수 있고, 정말 마지막 수단으로만 Activity를 재시작합니다. 변경에 맞는 가장 가벼운 방식을 v2가 알아서 선택합니다.

그래도 몇몇 변경은 여전히 전체 빌드가 필요합니다. 완전히 컴파일 없이 코드의 결과를 만들어 낼 수는 없습니다. 이게 가능했다면 컴파일러라는 존재가 진작 무의미해졌을 것입니다. 가령, 함수 매개변수를 추가하거나 제거하는 경우, 클래스 계층을 바꾸는 경우, 인라인 함수를 수정하는 경우가 그렇습니다. 해당 목록을 외워 둘 필요는 없습니다. v2는 리로드를 하기 전에 구조 검사를 실행하고, 이런 변경이 감지되면 조용히 평범한 증분 빌드와 설치로 물러났다가, 다음 수정부터 다시 핫 리로드를 이어 갑니다. 툴체인 쪽을 보면, v2는 하나의 플러그인으로 코틀린 2.3과 2.4에서 모두 동작하고, Gradle 플러그인이 디버그 빌드에 맞는 클라이언트 라이브러리를 알아서 가져옵니다.

더 자세한 내용을 살펴보고 싶으시다면 리로드 파이프라인, 전체 상태 보존 표, 지원되는 변경, 제약 사항 등을 읽어보실 수 있습니다.

v2는 아직 베타입니다. 실제 프로젝트에 써볼 수 있을 만큼 성숙했지만, 아직 다듬어야 할 다양한 엣지 케이스들이 남아 있습니다. 사용하다가 여러 에러에 마주치셨다면, HotSwan 로그 및 크래시 로그 등을 포함하여 Compose HotSwan 이슈 트래커에 제보해 주시면 감사하겠습니다.

언제나 즐거운 코딩 되시길 바랍니다.

엄재웅 (skydoves) 드림