버미

[안드로이드] Compose Navigation 3 개괄적 이해

Bum_2 — Tue, 26 May 2026 17:41:15 +0900

기존에 사용하던 Navigation 2(NavHost + NavController + NavGraph)에 익숙한 입장에서, 2025년 11월에 1.0 안정 버전이 출시된 Jetpack Navigation 3(이하 Nav3)는 어떤 점이 달라졌고, 왜 새로 설계됐는지, 그리고 실제로 어떻게 사용하는지 살펴보고자 한다.

Nav3가 등장한 이유

Nav2는 2018년에 설계된 라이브러리다. Compose가 세상에 나오기도 전이다. 그래서 Nav2는 본질적으로 명령형(imperative) 패러다임을 따른다.

navController.navigate("home")
navController.popBackStack()

위 코드는 "컨트롤러에게 명령을 내리면 → 내부 백스택이 바뀌고 → UI가 갱신된다"는 흐름이다.

문제는 Compose가 모든 영역에서 상태 기반(state-driven) 모델을 채택하고 있다는 점이다. mutableStateOf, remember, collectAsState 등 Compose의 모든 도구는 "상태가 바뀌면 UI가 다시 그려진다"는 단방향 흐름을 따른다.

결국 Compose 앱 안에서 내비게이션만 다른 패러다임으로 동작하는 구조였고, 이것은 다음과 같은 실질적 문제를 만들었다.

백스택이 라이브러리 내부에 숨겨져 있어서 직접 조작이 어려움
인자 전달이 라우트 문자열 파싱 기반이라 타입 안전성이 약함
"한 화면에 한 destination" 가정 때문에 태블릿/폴더블의 list-detail 같은 적응형 레이아웃 구현이 어색함
ViewModel 스코핑이 라이브러리 내부에 숨어 있어 디버깅이 어려움
테스트하려면 인스트루먼트 테스트가 필요

Nav3는 이 문제들을 해결하기 위해 백스택을 개발자에게 완전히 노출시키는 방향으로 다시 설계됐다.

Nav2와 Nav3의 개념 대응

기존 Nav2의 요소를 그대로 매핑해보면 다음과 같다.

	Nav3	Nav2
NavHost	NavDisplay	화면을 그려주는 컨테이너 Composable
NavController	backStack (리스트 그 자체)	화면 이동 / 백스택 조작
NavGraph	entryProvider	키 → 화면 매핑 정의
라우트 문자열 "product/{id}"	NavKey를 구현한 데이터 클래스	화면 식별자 + 인자

핵심은 NavController라는 별도의 객체가 사라지고, 백스택 리스트 자체가 곧 내비게이션 상태가 됐다는 점이다.

Nav3의 구성 요소

본격적으로 살펴보기 전에, Nav3에서 등장하는 핵심 요소들을 먼저 정리하면 다음과 같다.

요소	타입 / 형태	역할	Nav2
NavKey	인터페이스 (데이터 클래스로 구현)	화면 식별, 인자	라우트 문자열 "product/{id}"
backStack	SnapshotStateList<NavKey>	현재 쌓여 있는 화면들의 리스트(상태)	NavController 내부 백스택
NavDisplay	Composable	백스택을 관찰해 마지막 항목을 그리는 컨테이너	NavHost
entryProvider	람다 (DSL)	키를 통한 화면 매핑	NavGraph

NavKey

화면을 식별하는 키다. 라우트 문자열 대신 데이터 클래스로 정의한다.

@Serializable
data object Home : NavKey

@Serializable
data class ProductDetail(val productId: String) : NavKey

@Serializable
data class Checkout(
    val items: List<CartItem>,
    val couponCode: String?
) : NavKey

NavKey 인터페이스 구현 → 라이브러리에 "이 키는 저장 가능하다"고 알림
@Serializable → 프로세스 죽음(process death) 후에도 복원 가능

문자열 라우트 시절에는 arguments?.getString("productId")처럼 꺼내야 했던 인자가, Nav3에서는 그냥 key.productId로 접근된다. 컴파일러가 타입을 검증해주고, IDE의 리팩토링 기능도 완벽하게 동작한다.

backStack

현재 쌓여 있는 화면들의 리스트다. 정확히는 SnapshotStateList<NavKey>다.

val backStack = rememberNavBackStack(Home)

rememberNavBackStack은 구성 변경과 프로세스 죽음을 가로질러 백스택을 유지해주는 편의 함수다. 초기값으로 넣은 Home이 Nav2의 startDestination 역할을 한다.

이 리스트는 개발자가 직접 소유하고 직접 조작한다.

backStack.add(ProductDetail("abc"))   // navigate
backStack.removeLastOrNull()           // popBackStack
backStack.clear()                      // 백스택 비우기

NavDisplay

백스택을 관찰하다가 마지막 항목을 그려주는 Composable이다. Nav2의 NavHost에 해당한다.

NavDisplay(
    backStack = backStack,
    onBack = { backStack.removeLastOrNull() },
    entryProvider = entryProvider {
        // ...
    }
)

onBack은 시스템 백버튼을 눌렀을 때 실행되는 람다다. 보통 마지막 항목을 제거한다.

entryProvider

키 → 화면 매핑을 정의한다. Nav2의 NavGraph에 해당한다.

entryProvider = entryProvider {
    entry<Home> {
        HomeScreen()
    }
    entry<ProductDetail> { key ->
        ProductDetailScreen(productId = key.productId)
    }
}

entry<T> { ... } DSL은 내부적으로 when (key) { is T -> ... } 패턴매칭을 깔끔하게 표현한 것이다. 람다의 key 파라미터는 자동으로 해당 타입으로 추론된다.

기본 사용 예제

위 요소들을 모두 합친 최소한의 코드는 다음과 같다.

@Serializable
data object Home : NavKey
@Serializable
data class ProductDetail(val productId: String) : NavKey

@Composable
fun App() {
    val backStack = rememberNavBackStack(Home)

    NavDisplay(
        backStack = backStack,
        onBack = { backStack.removeLastOrNull() },
        entryProvider = entryProvider {
            entry<Home> {
                HomeScreen(
                    onProductClick = { id ->
                        backStack.add(ProductDetail(id))
                    }
                )
            }
            entry<ProductDetail> { key ->
                ProductDetailScreen(
                    productId = key.productId,
                    onBack = { backStack.removeLastOrNull() }
                )
            }
        }
    )
}

흐름은 다음과 같다.

사용자가 HomeScreen에서 상품을 탭
backStack.add(ProductDetail("abc")) 실행
backStack은 SnapshotStateList이므로 변경을 Compose가 감지
NavDisplay가 리컴포지션되면서 리스트의 마지막 항목을 확인
entryProvider에서 ProductDetail 타입에 매칭되는 람다 실행
ProductDetailScreen("abc")가 화면에 렌더링됨

별도의 컨트롤러도, 그래프 탐색도 없다. 상태 변경 → UI 갱신이라는 Compose의 기본 패턴 그대로다.

백스택 조작 — popUpTo, launchSingleTop은 어떻게?

Nav2의 DSL(popUpTo, inclusive, launchSingleTop 등)이 모두 사라졌다. 대신 백스택이 리스트이므로 Kotlin Collection API로 직접 조작한다.

popUpTo 패턴

fun SnapshotStateList<NavKey>.popUpTo(
    key: NavKey,
    inclusive: Boolean = false
) {
    val index = indexOfFirst { it == key }
    if (index < 0) return
    val targetSize = if (inclusive) index else index + 1
    while (size > targetSize) removeLastOrNull()
}

// 사용
backStack.popUpTo(Login, inclusive = true)
backStack.add(Home)

launchSingleTop 패턴

fun SnapshotStateList<NavKey>.navigateSingleTop(key: NavKey) {
    if (lastOrNull() != key) add(key)
}

로그아웃 등 백스택 초기화

backStack.clear()
backStack.add(Login)

특정 화면으로 돌아가기

fun SnapshotStateList<NavKey>.popBackTo(key: NavKey) {
    val index = indexOfFirst { it == key }
    if (index < 0) return
    while (size > index + 1) removeLastOrNull()
}

Nav2의 DSL로 표현 불가능했던 케이스

// 백스택에서 모든 ProductDetail 화면 제거
backStack.removeAll { it is ProductDetail }

// 특정 조건을 만족하는 가장 최근 화면까지 돌아가기
val targetIndex = backStack.indexOfLast { it is Home || it is Login }
if (targetIndex >= 0) {
    while (backStack.size > targetIndex + 1) backStack.removeLastOrNull()
}

Nav2 시절에는 Google이 제공하는 DSL의 조합으로 표현 가능한 흐름만 만들 수 있었지만, Nav3는 자료구조를 직접 다루기 때문에 표현 가능한 케이스의 폭이 훨씬 넓다.

EntryDecorator — 횡단 관심사 처리

각 NavEntry에 공통 동작을 추가하는 메커니즘이다. Nav2에서 라이브러리가 알아서 처리해주던 상태 보존, ViewModel 스코핑 같은 동작을 Nav3는 명시적으로 데코레이터로 부착한다.

NavDisplay(
    backStack = backStack,
    entryDecorators = listOf(
    // rememberSaveable 동작 보장 (configuration change, process death 대응)
    rememberSaveableStateHolderNavEntryDecorator(),
    // ViewModel을 NavEntry 생명주기에 스코프
    rememberViewModelStoreNavEntryDecorator()
    ),
    onBack = { backStack.removeLastOrNull() },
    entryProvider = entryProvider { /* ... */ }
)

rememberViewModelStoreNavEntryDecorator()를 추가하면 ViewModel이 Activity가 아니라 해당 화면 단위로 스코프된다. Nav2에서 backstack entry 단위로 ViewModel을 묶던 것과 비슷하지만, 동작이 코드에 드러난다는 점이 중요하다.

적응형 레이아웃 — Scenes

Nav2의 가장 큰 한계 중 하나가 "한 번에 한 화면"이라는 가정이었다. 태블릿에서 list-detail을 동시에 보여주려면 별도의 SlidingPaneLayout이나 Adaptive 라이브러리를 끌어와야 했다.

Nav3는 백스택이 그냥 리스트이므로 마지막 두 개를 동시에 그린다 같은 동작이 자연스럽게 가능하다. 이를 위해 sceneStrategy 파라미터를 제공한다.

NavDisplay(
    backStack = backStack,
    sceneStrategy = ListDetailSceneStrategy(),
    // ...
)

SinglePaneSceneStrategy(기본값), ListDetailSceneStrategy 등의 전략을 선택할 수 있고, 직접 구현도 가능하다.

폴더블/태블릿/Compose Multiplatform을 고려해야 하는 시대에 결정적인 차이다.

결과 전달은 어떻게?

Nav2에서 가장 어색했던 부분 중 하나가 previousBackStackEntry.savedStateHandle.set(...) 패턴으로 이전 화면에 결과를 넘기는 것이었다.

Nav3에서는 공유 상태로 해결한다.

보통 공유 ViewModel을 쓰거나, 단순한 경우 콜백을 활용한다.

class CheckoutFlowViewModel : ViewModel() {
    var selectedAddress by mutableStateOf<Address?>(null)
}

entry<AddressList> {
    val vm: CheckoutFlowViewModel = hiltViewModel(/* 공유 스코프 */)
    AddressListScreen(
        onAddressSelected = { addr ->
            vm.selectedAddress = addr
            backStack.removeLastOrNull()
        }
    )
}

entry<Checkout> {
    val vm: CheckoutFlowViewModel = hiltViewModel(/* 같은 스코프 */)
    CheckoutScreen(address = vm.selectedAddress)
}

내비게이션이 상태로 표현되니, 화면 간 데이터 공유도 일반적인 상태 공유 패턴 그대로 해결할 수 있다.

정리

Nav2가 "컨트롤러가 그래프를 따라 화면을 옮긴다"였다면, Nav3는 "백스택은 내가 들고 있는 리스트고, NavDisplay는 그 리스트를 관찰해 마지막 항목을 그린다" 가 전부다.

패러다임	명령형(Nav2)	상태 기반(Nav3)
백스택 소유	라이브러리 내부	개발자
화면 식별	라우트 문자열	데이터 클래스
이동 명령	navigate("route")	backStack.add(Route)
뒤로가기	popBackStack()	backStack.removeLastOrNull()
인자 전달	문자열 파싱	프로퍼티 접근
적응형 UI	별도 라이브러리 필요	SceneStrategy 기본 지원
테스트	인스트루먼트 테스트	유닛 테스트 가능

Compose의 나머지 모든 부분이 상태 기반으로 동작하는데, 내비게이션만 명령형이었던 일관성의 균열이 Nav3에 와서야 비로소 메워졌다고 볼 수 있다.

기존 Nav2를 사용 중인 프로젝트라면 당장 마이그레이션할 필요는 없지만, 신규 Compose 프로젝트나 적응형 UI / Compose Multiplatform을 염두에 둔 프로젝트라면 Nav3로 시작하는 것을 고려해볼 만하다.

- Reference

[안드로이드] API 36 버전 업데이트 정리

Bum_2 — Fri, 1 May 2026 21:40:50 +0900

안드로이드 API 36버전에서 변화되는 내용을 정리하고자 한다.

먼저, 안드로이드 16(API 레벨 36) OS를 갖는 모든 디바이스에 적용되는 내용부터 살펴보자.

정식 출시는 25년 6월에 출시되었고 구글 플레이 의무화는 26년 8월 부터다.

다음은 targetSdkVersion에 관계없이, Android 16 기기 위에서 실행되는 모든 앱에 적용된다.

1. Job 스케줄링 실행 쿼터 강화

백그라운드 Job의 실행 시간 쿼터가 더 엄격하게 관리된다.

아래 세 가지 조건에 따라 쿼터 적용 방식이 달라진다.

앱 대기 버킷(Standby Bucket): Active 버킷에도 넉넉한 쿼터가 적용되기 시작
앱 가시성 상태: 앱이 화면에 보이는 동안 시작된 Job이 숨겨진 후에도 계속되면 쿼터 적용
포그라운드 서비스 동시 실행: 포그라운드 서비스와 함께 실행 중인 Job도 쿼터 적용 대상

대용량 데이터 전송 작업은 User-initiated data transfer jobs 사용을 권장

앱 대기 버킷(App Standby Bucket)과 쿼터

앱 대기 버킷은 Android 9(API 28)부터 도입된 배터리 관리 메커니즘으로, 시스템이 각 앱을 사용 빈도와 패턴에 따라 다섯 등급(Active, Working Set, Frequent, Rare, Restricted) 중 하나로 자동 분류하는 개념이다.
분류는 전적으로 개인화되어 있어서 같은 앱이라도 사용자의 행동 패턴에 따라 다른 버킷에 들어간다. 매일 출퇴근길에 쓰는 지도 앱은 누군가에겐 Active 버킷이지만, 1년에 한 번 여행 갈 때만 쓰는 사람에겐 Rare 버킷이 되는 식이다.
머신러닝(Adaptive Battery)이 탑재된 기기에서는 한 발 더 나아가 "이 사용자가 이 시간대에 이 앱을 쓸 가능성"까지 예측해서 동적으로 버킷을 조정하고, ML이 없는 기기에서는 단순히 최근 사용 시점 기준으로 정렬한다.

쿼터는 이 버킷 등급에 따라 차등 적용되는 백그라운드 잡(Job)의 실행 시간 예산이다.
일회성 타이머가 아니라 롤링 시간 윈도우 안에서의 누적 실행 시간 한도라서, "지난 60분 동안 이미 20분을 썼다면 더 못 돌리고 시간이 지나면서 예산이 다시 차오른다"는 식으로 동작한다.
Working Set은 60분당 일반 잡 20분,
Frequent는 4시간당 10분,
Rare는 24시간당 10분으로 점점 빡빡해지며,
Restricted는 하루 1회 10분 배치 세션 안에서 다른 앱 잡들과 묶여서만 실행될 정도로 가혹하다.
Active 버킷은 Android 16 이전엔 무제한이었지만, 이제는 "넉넉한(generous)" 쿼터가 적용되기 시작했다.

Android 16의 핵심 변경은 이 쿼터의 사각지대를 없앤 것이다. 기존엔 앱이 화면에 떠 있는 동안 시작된 잡이나 포그라운드 서비스와 함께 도는 잡은 사실상 무제한으로 돌 수 있었는데, 이런 우회로가 막혔다. 단 포그라운드 서비스(FGS) 자체는 별도 규칙을 따르므로 mediaPlayback이나 location 같은 타입은 여전히 무기한 실행되고, 쿼터에 걸려 중단되는 건 어디까지나 그 옆에서 함께 돌던 백그라운드 잡들이다.
즉 Spotify의 음악 재생이나 카카오맵의 내비게이션은 그대로 살아 있고, 그 앱들이 사용자 모르게 묻어 돌리던 동기화·캐싱·통계 업로드 같은 잡들이 제어 대상이 된다.

대용량 데이터 전송은 User-initiated data transfer job을 쓰고, 일반 백그라운드 작업은 WorkManager에 맡겨 시스템이 최적 타이밍을 잡도록 하며, 충전 중·Wi-Fi 연결 같은 제약 조건을 적극 활용해 사용자 버킷이 무엇이든 시스템이 알아서 풀어주는 시점에 작업이 실행되도록 설계하는 것이 핵심이다.

2. Intent 리다이렉션 공격 기본 차단

악성 앱이 인텐트 extras를 조작해 취약한 앱의 비공개 컴포넌트를 실행하는 Intent Redirection 공격에 대해 플랫폼 수준의 보안이 기본 적용된다. 일반적인 방식으로 인텐트를 사용하는 앱은 영향이 없다.

3. 블루투스 본드 손실 처리 개선

기존에는 블루투스 기기와의 본드(페어링 정보)가 손실되면 시스템이 자동으로 재페어링을 시도한다.

Android 16부터는 연결을 끊고 본드 정보를 유지한 채 사용자에게 시스템 다이얼로그로 알려준다. 아울러 두 가지 새 인텐트가 추가된다.

- ACTION_KEY_MISSING: 원격 본드 손실 감지 시 수신
- ACTION_ENCRYPTION_CHANGE: 링크 암호화 상태 변경 시 수신

OEM마다 구현 방식이 다를 수 있으므로 실기기 테스트를 권장

4. 가상 디바이스 디스플레이 오버라이드

차량 인포테인먼트, VR 기기 등 가상 디바이스 소유자가 앱을 외부 화면에 투영할 때, 해당 앱의 방향(orientation), 비율, 리사이즈 제한을 무시하도록 설정할 수 있습니다.

targetSdk 36 지정 시 추가 적용 사항
build.gradle에서 targetSdkVersion = 36으로 설정했을 때만 추가로 적용된다.

1. 대화면 Adaptive Layout 강제 적용

가장 영향이 큰 변경사항으로, 최소 너비 600dp 이상인 화면(태블릿, 폴더블 펼침 화면 등)에서 아래 속성이 모두 무시된다.

  - android:screenOrientation
  - resizeableActivity="false"
  - 가로세로 비율(Aspect Ratio) 제한 전체

앱이 디스플레이 전체를 채우며, 필러박스(letterbox / pillarbox)가 사라진다. 세로 고정으로 개발된 앱은 레이아웃이 깨질 수 있어 사전 검증이 필수.

예외 대상
  - 게임 앱 (android:appCategory="game" 설정 시)
적용 대상

- Galaxy Z Fold 펼친 상태, 갤럭시 탭 등

2. 엣지 투 엣지(Edge-to-Edge) 강제 적용

앱 배경이 상태 바, 내비게이션 바 아래까지 확장된다. UI 요소와 터치 영역은 기존과 동일하게 safe zone 내에 유지되지만, 배경 색상이 시스템 바 영역까지 채워진다. Android 11(API 30) 이상 기기에 적용.

3. MediaStore 버전 앱별 고유값 변경

MediaStore.getVersion()이 이제 앱마다 다른 고유값을 반환.

버전 문자열의 포맷을 파싱해서 추가 정보를 추출하는 로직이 있다면 수정이 필요하다.

4. scheduleAtFixedRate 누락 실행 제한

앱이 유효하지 않은 라이프사이클 상태에 있는 동안 예약 실행이 여러 번 누락되더라도, 앱 복귀 시 최대 1번만 즉시 실행된다.

기존에는 누락된 모든 실행이 한꺼번에 몰아서 실행되었다.

STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 호환 플래그로 사전 테스트 가능.

5. 로컬 네트워크 접근 권한 (옵트인 단계)

LAN 기기(프린터, 스마트TV, NAS 등)와의 통신에 별도 권한이 필요해진다.

API 36에서는 옵트인 테스트 단계이며, API 37부터 의무화.

6. 카메라 Pro API 강화

야간 모드 씬 감지, 하이브리드 자동 노출, 정밀 색온도 조절, 모션 포토 Intent 액션 추가,

UltraHDR HEIC 인코딩 지원이 추가된다.

7. Health Connect 업데이트

새 데이터 타입 ACTIVITY_INTENSITY가 추가되고, WHO 가이드라인 기반의 FHIR 포맷 의료 기록 읽기·쓰기 API가 도입된다.

8. 예측 뒤로가기 (3-button 내비게이션)

기존에 제스처 내비게이션에서만 지원되던 Predictive Back 애니메이션이 3-button 내비게이션에서도 동작한다. finishAndRemoveTaskCallback(), moveTaskToBackCallback()도 함께 추가된다.

9. 내장 사진 선택기 API

앱 뷰 계층 구조에 사진 선택기를 직접 임베드할 수 있는 새 API가 추가됩니다. 광범위한 미디어 접근 권한 없이 사용할 수 있다.

10. SDK_INT_FULL / 마이너 버전 지원

VERSION_CODES_FULL 열거형과 Build.getMinorSdkVersion() 메서드가 추가되어 주 버전(36)과 부 버전(36.1 등)을 구분한 API 분기 처리가 가능해진다.

11. WiFi 위치 보안 강화

WiFi 6(802.11az) 기반 근접 센싱의 정확도와 보안이 향상된다.

- Reference

  - Android 16 동작 변경사항 — 모든 앱

  - Android 16 동작 변경사항 — targetSdk 36 앱

  - Android 16 새 기능 및 API

  - Android 16 Orientation & Resizability 변경사항 (공식 블로그)

[안드로이드] 웹뷰와 커스텀 탭

Bum_2 — Mon, 23 Mar 2026 21:02:40 +0900

웹뷰와 커스텀 탭 모두 웹 페이지의 내용을 보여주는 컴포넌트다. 이 글을 통해 웹뷰를 상기해보고 커스텀 탭이 어떻게 차이가 있는지 알아보자.

웹뷰

웹뷰는 안드로이드에서 지원하는 컴포넌트로, 앱 내부에 웹 브라우저를 내장하여 웹 페이지를 렌더링하는 컴포넌트이다.

즉, 앱 안에 브라우저를 직접 구현하는 방식이다.

WebView의 핵심은 “렌더링”과 “제어”를 분리해서 이해하는 것이다. HTML을 파싱하고 DOM을 구성하며, 레이아웃을 계산하고 화면에 그리는 작업은 모두 Chromium 기반의 웹 엔진이 담당한다. 하지만 그 엔진은 앱 프로세스 안에서 동작하며, 앱은 WebView API를 통해 이 엔진을 제어할 수 있다. 즉, 렌더링 자체는 엔진이 수행하지만, 어떤 페이지를 로드할지, 어떤 JavaScript를 실행할지, 어떤 이벤트를 가로챌지는 전부 앱이 결정한다.

이 구조 덕분에 WebView에서는 일반 브라우저에서는 불가능한 수준의 제어가 가능하다. 예를 들어 evaluateJavascript()를 사용하면 웹 페이지 내부의 DOM에 접근해 데이터를 가져올 수 있다. 또한 JavaScript 인터페이스를 통해 웹과 네이티브 간 양방향 통신도 구현할 수 있다. 이처럼 WebView는 단순히 웹 페이지를 보여주는 것을 넘어, 웹을 앱의 일부처럼 동작하게 만드는 강력한 도구다.

하지만 이러한 강력함은 동시에 책임을 의미한다. WebView는 앱 내부에서 실행되기 때문에 보안과 안정성을 개발자가 직접 관리해야 한다. 외부에서 로드한 HTML에 대한 검증 없이 JavaScript 인터페이스를 열어두면 XSS와 같은 취약점이 발생할 수 있고, 잘못된 설정은 사용자 데이터 유출로 이어질 수 있다. 또한 웹 렌더링을 앱 내부에서 수행하기 때문에 성능에 대한 고려도 필요하다.

결국 WebView는 “브라우저를 여는 기술”이 아니라, 브라우저 엔진을 앱 안에 두고 직접 웹을 렌더링하고 제어하는 환경이다. 웹과 네이티브의 경계를 허물고 하나의 사용자 경험으로 통합할 수 있다는 점에서 매우 유용하지만, 그만큼 구조를 정확히 이해하고 사용하는 것이 중요하다.

한 줄로 정리하면 다음과 같다.
WebView는 브라우저를 실행하는 것이 아니라, 브라우저 엔진을 앱 내부에서 사용해 웹을 직접 제어하는 기술이다.

특징

HTML, CSS, JavaScript 를 직접 렌더링 가능
JavaScript 인터페이스를 통해, 안드로이드 ↔ 웹 양방향 통신 가능

장점

완전 제어가 가능해서 높은 자유도
앱 상태와 강하게 연동 가능

단점

앱 내부에서 렌더링이 되기 때문에, 성능 부담
XSS, JS Injection 등 보안 취약점 존재

커스텀 탭

크롬과 같은 외부 브라우저를 앱 위에서 실행하는 방식이다.

즉, 브라우저를 직접 구현하는 것이 아닌, 빌려서 사용하는 방식이다.

안드로이드에서 웹 페이지를 열 때 흔히 “브라우저를 빌려쓴다”는 표현을 사용한다. 특히 Custom Tabs를 설명할 때 자주 등장하는 말인데, 이 표현은 방향은 맞지만 정확한 구조를 이해하지 않으면 쉽게 오해로 이어진다.

우선 중요한 전제부터 짚고 가야 한다. 안드로이드에서 브라우저는 단순히 “항상 백그라운드에서 실행되고 있는 존재”가 아니다. Chrome이든 Samsung Internet이든 브라우저 앱은 단지 설치된 애플리케이션일 뿐이며, 사용하지 않으면 프로세스가 아예 존재하지 않을 수도 있다. 즉, “기본 브라우저가 있으니 항상 프로세스도 떠 있다”는 생각은 틀린 가정이다. 안드로이드는 필요할 때만 프로세스를 생성하고, 필요 없으면 종료하는 구조이기 때문이다.

그렇다면 Custom Tabs에서 말하는 “브라우저를 빌려쓴다”는 것은 무엇을 의미할까? 핵심은 브라우저의 내부 인스턴스에 직접 접근하는 것이 아니라, 브라우저 앱과 IPC(Inter-Process Communication), 정확히는 Binder를 통해 협업하는 구조라는 점이다. Custom Tabs를 사용할 때 앱은 브라우저 프로세스 내부 객체를 직접 제어하는 것이 아니라, 브라우저가 제공하는 CustomTabsService에 바인딩하여 세션을 생성하고, 필요한 기능을 요청한다. 이후 실제 웹 콘텐츠는 브라우저 쪽 Activity가 실행되어 렌더링을 담당한다.

동작 흐름을 보면 더 명확하다. 앱에서 CustomTabsIntent.launchUrl()을 호출하면, 시스템은 Custom Tabs를 지원하는 브라우저를 찾는다. 이때 브라우저 프로세스가 이미 실행 중이라면 그대로 재사용하고, 실행 중이 아니라면 OS가 새로 프로세스를 생성한다. 이후 (선택적으로) bindCustomTabsService()를 통해 브라우저의 서비스에 연결할 수 있는데, 이 단계는 필수가 아니라 성능 최적화를 위한 선택 사항이다. 여기서 warmup()이나 세션 생성, URL prefetch 같은 작업을 통해 페이지 로딩 속도를 개선할 수 있다. 마지막으로 브라우저의 Activity가 foreground로 올라오며 실제 화면이 표시된다.

여기서 중요한 포인트는 Custom Tabs가 “앱 내부에 웹을 렌더링하는 방식”이 아니라는 것이다. 즉, WebView처럼 앱 프로세스 안에서 웹을 그리는 것이 아니라, 브라우저 프로세스가 별도로 존재하고 그 Activity가 화면에 표시되는 구조다. 다만 툴바 색상 커스터마이징, 애니메이션, 뒤로가기 동작 등으로 인해 사용자 입장에서는 마치 앱 내부 화면처럼 자연스럽게 이어지는 경험을 제공한다.

또 하나 중요한 점은 모든 브라우저가 Custom Tabs를 지원하는 것은 아니라는 것이다. 따라서 실제 구현에서는 CustomTabsClient.getPackageName() 등을 통해 지원 브라우저를 먼저 탐색하고, 없는 경우에는 ACTION_VIEW로 fallback하는 구조를 사용한다. 이 fallback은 “같은 방식으로 동작한다”는 의미가 아니라, 단순히 “어쨌든 URL은 열리게 한다”는 의미에 가깝다. 즉, Custom Tabs가 제공하는 최적화된 UX와 성능은 포기하고 기본 브라우저 실행으로 대체하는 것이다.

정리하면 Custom Tabs는 단순히 브라우저를 여는 기술이 아니라, 브라우저 앱의 기능을 IPC 기반으로 재사용하면서도 앱과 자연스럽게 이어지는 사용자 경험을 제공하는 방식이다. 브라우저 프로세스는 항상 존재하는 것이 아니라 필요할 때 생성되며, 서비스 바인딩은 성능 최적화를 위한 선택적 단계다. 그리고 최종적으로 화면을 그리는 주체는 여전히 브라우저라는 점을 이해하는 것이 가장 중요하다.

한 줄로 정리하면 다음과 같다.
Custom Tabs는 브라우저를 “내 앱 안에 띄우는 기술”이 아니라, 브라우저와 협업하여 “브라우저가 그린 화면을 앱처럼 보이게 사용하는 기술”이다.

특징

크롬(or 기본) 브라우저 엔진 사용
쿠키 및 로그인 상태 자동 공유
주소창 및 보안 UI 제공

장점

이미 실행 중인 브라우저를 활용하여 빠른 성능
크롬 정책을 적용하여 높은 보안

단점

HTML/DOM 제어 불가능
JavaScript 주입 불가
앱과의 직접적인 데이터 연결 어려움

Reference

- custom-tabs-client 코드

[KMP] Ktor Auth Plugin은 401을 어떻게 처리할까? Bearer 토큰 자동 갱신 흐름 분석

Bum_2 — Sat, 14 Feb 2026 00:26:29 +0900

OkHttp를 사용할 때는 OkHttp 클라이언트에 체이닝을 걸어 Interceptor와 Authenticator로 access token을 헤더에 추가하고, 401이 발생하면 refresh token을 통해 토큰을 갱신하는 구조를 직접 설계했다.

하지만 Ktor Client에서는 Auth 플러그인과 Bearer Provider만 설정하여 이러한 흐름을 처리할 수 있다.

그렇다면 Ktor는 내부적으로 어떤 흐름으로 401을 감지하고, 언제 refreshTokens를 호출하며, 어떻게 동일한 요청을 재시도하는 걸까? 이번 글에서는 Ktor Bearer 인증의 내부 동작 과정을 코드 레벨에서 분석해보려고 한다.

Ktor

Ktor는 코틀린에서 사용할 수 있는 비동기 HTTP 클라이언트 기반 라이브러리다.

내부적으로 코루틴을 기반으로 동작하며 각 플랫폼(iOS, Android, Desktop)에 맞는 엔진을 통해 네트워크 통신을 수행한다.

AuthProvider

ktor-client-auth 에서 공식적으로 제공하는 AuthProvider는 Bearer, Basic, Digest Auth 프로바이더가 있다.

이 외에도 AuthProvider를 자신의 서비스에 맞게 생성하여 사용할 수 있다.

Basic은 (TLS 위에서) 단순 자격증명 방식이라 토큰 기반(OAuth/JWT) 시나리오에는 보통 사용하지 않으며, Digest는 현대 API에서는 덜 쓰인다.

BearerAuthProvider

BearerAuthProvider는 Authorization 에 "Bearer $token"을 붙이는 API에 사용하는 프로바이더다.

시그니처는 아래와 같다.

public class BearerAuthProvider(
    private val refreshTokens: suspend RefreshTokensParams.() -> BearerTokens?,
    loadTokens: suspend () -> BearerTokens?,
    private val sendWithoutRequestCallback: (HttpRequestBuilder) -> Boolean = { true },
    private val realm: String?,
    cacheTokens: Boolean = true,
    private val nonCancellableRefresh: Boolean = false,
)

bearer 을 사용하면 AuConfig 의 bearer가 호출되고 생성자를 통해 BearerAUthProvider를 통해 초기화되는 구조다.

흐름과 같이 이해하기 위해 아래와 같이 코드를 작성했다고 하자.

fun creatApiHttpClient(
    engine: HttpClientEngine,
    tokenManager: TokenManager,
    isDebug: Boolean = true,
    baseUrl: String,
    additionalConfig: HttpClientConfig<*>.() -> Unit = {}
): HttpClient = HttpClient(engine = engine) {
    defaultRequest {
        url.takeFrom(baseUrl)
    }

	...

    install(Auth) {
        bearer {
            sendWithoutRequest { request ->
                val path = request.url.encodedPath
                !(path.startsWith(ApiPaths.LOGIN_PLATFORM) ||
                        path.startsWith(ApiPaths.TOKEN_REFRESH))
            }
            loadTokens {
                val access = tokenManager.loadAccessToken().takeIf { it.isNotBlank() }
                val refresh = tokenManager.loadRefreshToken().takeIf { it.isNotBlank() }
                if (access != null && refresh != null) {
                    BearerTokens(accessToken = access, refreshToken = refresh)
                } else null
            }
            refreshTokens {
                tokenManager.refreshAndGetNewAccessToken()
                    .takeIf { it.isNotBlank() }
                    ?.let { newAccess ->
                        val newRefresh = tokenManager.loadRefreshToken().takeIf { it.isNotBlank() }
                        BearerTokens(accessToken = newAccess, refreshToken = newRefresh ?: "")
                    }
            }
        }
    }

    additionalConfig()
}

설명할 부분은 bearer 블럭에서 sendWithoutRequest 블럭, loadTokens 블럭, refreshTokens 블럭이다.

먼저 sendWithoutRequest 블럭부터 살펴보자.

sendWithoutRequest 블럭

이 블럭은 API 요청을 하기 직전에, onRequest 블럭에서 sendWithoutRequest가 true를 반환하는 provider에 한해서 Authorization 헤더를 붙인다. Authorization 헤더를 붙이지 말아야할 API Path 들에 대해서 사용한다.

아래 코드를 보자.

@OptIn(InternalAPI::class)
public val Auth: ClientPlugin<AuthConfig> = createClientPlugin("Auth", ::AuthConfig) {
    val providers = pluginConfig.providers.toList()

    client.attributes.put(AuthProvidersKey, providers)

    val tokenVersions = ConcurrentMap<AuthProvider, AtomicCounter>()
    val tokenVersionsAttributeKey =
        AttributeKey<MutableMap<AuthProvider, Int>>("ProviderVersionAttributeKey")

	...
    
   onRequest { request, _ ->
        providers.filter { it.sendWithoutRequest(request) }.forEach { provider ->
            LOGGER.trace { "Adding auth headers for ${request.url} from provider $provider" }
            val tokenVersion = tokenVersions.computeIfAbsent(provider) { AtomicCounter() }
            val requestTokenVersions = request.attributes
                .computeIfAbsent(tokenVersionsAttributeKey) { mutableMapOf() }
            requestTokenVersions[provider] = tokenVersion.atomic.value
            provider.addRequestHeaders(request)
        }
    } 
}

<ktor-client-auth의 Auth.kt 중 일부>

토큰의 최신화 파악을 위해, 프로바이더에서 사용한 토큰의 Counter 값을 스냅샷 처리한다. 이는 refreshTokens에서 사용한다.

이 부분에서 이해가가지 않은 점이 있었다. sendWithoutRequest 네이밍을 사용해서 이 프로바이더가 True라면 헤더에 Authorization 값을 붙여서 보낸다는 점이다. 그렇다면 sendWithoutRequest가 아니라, sendRequest 이라는 네이밍을 사용했다면 직관적으로 와닿지 않았을까라는 생각을 했다.

찾아보니, 이 콜백의 원래 의도는 401을 기다리지 말고, 처음 요청부터(= without challenge) Authorization을 붙일지 말지 결정하는 용도라고 한다.
즉 네이밍은
"send (auth) without request(ing auth)" 보다는 "challenge(WWW-Authenticate)를 기다리지 않고 먼저 보낼래?” 같은 뉘앙스에 더 가깝다. 이는 “challenge 없이도 Authorization을 선제적으로 붙일지” 의 의미가 숨어있다.

즉 sendWithoutRequest 에서 "request"가 "내가 보내는 HTTP 요청"이 아니라 "서버가 보내는 인증 요구(challenge)" 아는 것이다.
결론적으로, 서버의 인증 없이 보내도 되는 API 라는 것.

loadTokens

이 블럭은 앱 내부에서 엑세스 토큰을 로드하는 로직을 담당한다.

BearerTokens(access_token, refresh_token)을 반환해야하며, access_token을 담아 리턴해야한다.

public val Auth: ClientPlugin<AuthConfig> 에서 addRequestHeaders 메소드를 사용할 때 내부에서 AuthTokenHolder 인스턴스가 호출한다.

public class BearerAuthProvider(
    private val refreshTokens: suspend RefreshTokensParams.() -> BearerTokens?,
    loadTokens: suspend () -> BearerTokens?,
    private val sendWithoutRequestCallback: (HttpRequestBuilder) -> Boolean = { true },
    private val realm: String?,
    cacheTokens: Boolean = true,
    private val nonCancellableRefresh: Boolean = false,
)  : AuthProvider {

    private val tokensHolder = AuthTokenHolder(loadTokens, cacheTokens)
    
        override suspend fun addRequestHeaders(request: HttpRequestBuilder, authHeader: HttpAuthHeader?) {
        val token = tokensHolder.loadToken() ?: return

        request.headers {
            val tokenValue = "Bearer ${token.accessToken}"
            if (contains(HttpHeaders.Authorization)) {
                remove(HttpHeaders.Authorization)
            }
            if (request.attributes.contains(AuthCircuitBreaker).not()) {
                append(HttpHeaders.Authorization, tokenValue)
            }
        }
    }

    public override suspend fun refreshToken(response: HttpResponse): Boolean {
        val newToken = tokensHolder.setToken(nonCancellableRefresh) {
            refreshTokens(RefreshTokensParams(response.call.client, response, tokensHolder.loadToken()))
        }
        return newToken != null
    }
	
	...
}

<ktor-client-auth의 BearerAuthProvider.kt 중 일부>

refreshTokens

이 블럭은 엑세스 토큰 갱신 로직을 수행하는 블럭이다.

이것 또한, loadTokens와 마찬가지로 BearerTokens(access_token, refresh_token)을 반환해야하며, access_token은 담아 리턴해야한다.

@OptIn(InternalAPI::class)
public val Auth: ClientPlugin<AuthConfig> = createClientPlugin("Auth", ::AuthConfig) {
    val providers = pluginConfig.providers.toList()

    client.attributes.put(AuthProvidersKey, providers)

    val tokenVersions = ConcurrentMap<AuthProvider, AtomicCounter>()
    val tokenVersionsAttributeKey =
        AttributeKey<MutableMap<AuthProvider, Int>>("ProviderVersionAttributeKey")

	...
    
    suspend fun Send.Sender.executeWithNewToken(
        call: HttpClientCall,
        provider: AuthProvider,
        oldRequest: HttpRequestBuilder,
        authHeader: HttpAuthHeader?
    ): HttpClientCall {
        val request = HttpRequestBuilder()
        request.takeFromWithExecutionContext(oldRequest)
        provider.addRequestHeaders(request, authHeader)
        request.attributes.put(AuthCircuitBreaker, Unit)

        LOGGER.trace { "Sending new request to ${call.request.url}" }
        return proceed(request)
    } 
    
    suspend fun refreshTokenIfNeeded(
        call: HttpClientCall,
        provider: AuthProvider,
        request: HttpRequestBuilder
    ): Boolean {
        val tokenVersion = tokenVersions.computeIfAbsent(provider) { AtomicCounter() }
        val requestTokenVersions = request.attributes
            .computeIfAbsent(tokenVersionsAttributeKey) { mutableMapOf() }
        val requestTokenVersion = requestTokenVersions[provider]

        if (requestTokenVersion != null && requestTokenVersion >= tokenVersion.atomic.value) {
            LOGGER.trace { "Refreshing token for ${call.request.url}" }
            if (!provider.refreshToken(call.response)) {
                LOGGER.trace { "Refreshing token failed for ${call.request.url}" }
                return false
            } else {
                requestTokenVersions[provider] = tokenVersion.atomic.incrementAndGet()
            }
        }
        return true
    }
    
    on(Send) { originalRequest ->
        val origin = proceed(originalRequest)
        if (!pluginConfig.isUnauthorizedResponse(origin.response)) return@on origin
        if (origin.request.attributes.contains(AuthCircuitBreaker)) return@on origin

        var call = origin

        val candidateProviders = HashSet(providers)

        while (pluginConfig.isUnauthorizedResponse(call.response)) {
            LOGGER.trace { "Unauthorized response for ${call.request.url}" }

            val (provider, authHeader) = findProvider(call, candidateProviders) ?: run {
                LOGGER.trace { "Can not find auth provider for ${call.request.url}" }
                return@on call
            }

            LOGGER.trace { "Using provider $provider for ${call.request.url}" }

            candidateProviders.remove(provider)
            if (!refreshTokenIfNeeded(call, provider, originalRequest)) return@on call
            call = executeWithNewToken(call, provider, originalRequest, authHeader)
        }
        return@on call
    }
}

<Auth.kt>

on(Send) 블럭에서 API를 호출한 resonse값을 pluginConfig.isUnauthorizedResponse() 메서드로 401이 발생했는지 아닌지 확인해서 401이 아니라면 return 하여 추가적인 로직을 수행하지 않는다.

401이 발생했다면, Providers 중에서 최신화된 토큰 counter을 사용하지 않는 것을 대상이 있다면 refreshTokenIfNeeded 메소드를 통해 업데이트한다.

refreshTokenIfNeeded 메소드에서 최신화된 Counter 값을 사용하여 401이 발생한 경우, refreshTokens 블럭이 콜백으로 호출된다.

refreshTokenIfNeeded 가 호출되기 까지의 흐름을 정리해보자면 아래와 같다.

요청을 보낼 때(onRequest) “이 요청이 어떤 토큰 버전으로 나갔는지” 스냅샷을 request attribute에 저장함.
401이 왔을 때(on(Send)), 무조건 refresh를 요청하면 동시에 여러 요청이 401일 때 refresh 폭발이 날 수 있음.
그래서 아래의 케이스인지 비교:

case 1) 이 요청이 보낸 토큰이 ‘최신 버전’이었다
→ 그럼 “진짜로 토큰이 만료된 것”일 가능성이 높으니 refresh 시도.

case 2) 이 요청이 보낸 토큰이 ‘최신이 아니게 되어버렸다’ (다른 코루틴/요청이 이미 refresh 해버림)
→ 굳이 또 refresh 하지 말고, 그냥 새 토큰으로 재시도.

AuthCircuitBreaker로 내가 재시도한 요청이 또 401이어도 다시 auth 로직 타지 않도록 무한 루프 방지.

- Refrences

[KMP] KMP에서 iOS 라이브러리는 어떻게 연결될까?

Bum_2 — Wed, 28 Jan 2026 21:20:28 +0900

Kotlin Multi Platform(KMP) 사용하다가 플랫폼 별로 라이브러리를 연결해야하는 상황에서 추가적인 작업이 필요하다.

Android 에서는 Gradle dependency로 간단하게 연결할 수 있지만, iOS에서는 어떻게 연결할지 알아보자.

KMP에서 플랫폼별 구현이 필요한 이유

KMP는 공통 Kotlin 코드를 작성하고,
각 플랫폼(Android / iOS)에서 실제 구현(actual)을 제공한다.

문제는 iOS SDK가 Swift 와 Objective-C 으로 구성되어있다는 점이다.

코틀린에서는 이를 직접 사용할 수 없기 때문에, 연결 과정이 필요하다.

iOS SDK가 KMP에 연결되는 흐름을 보면 아래와 같다.

CocoaPods

CoCoaPods는 iOS에서 사용하는 의존성 관리자다.

마치, 안드로이드의 Gradle과 같이 라이브러리를 설치 & 관리해준다고 생각하면 될 것 같다.

KMP에서 CocoaPods는 아래와 같은 역할을 한다.

iOS 네이티브 라이브러리 다운로드
Objective-C 헤더 노출
Kotlin Native가 접근할 수 있는 구조 제공

Gradle 에서는 아래와 같이 선언한다.

cocoapods {
    pod("NMapsMap")
}

cinterop

cinterop은 Kotlin Native 도구다.

KMP에서 cinterop은 아래와 같은 역할을 한다.

Objective-C 헤더 분석
Kotlin 타입으로 변환
네이티브 함수 연결

예를 들어 iOS SDK에 아래와 같은 코드가 있다고 하자.

@interface MapView
- (void)setZoom:(double)zoom;
@end

여기서 cinterop은 아래와 같이 바인딩 한다.

val map = MapView()
map.setZoom(10.0)

Swift SDK 역시 대부분 아래와 같은 과정을 거쳐서 연결된다.

Swift → Objective-C 인터페이스 노출 → cinterop 처리

처음에 cinterop이 바인딩 역할을 해준다고해서 RN의 브릿지와 어떤 차이가 있을까 궁금해졌다.
간략하게 정리하면,

RN(Reat Native)의 브릿지는 JS ↔ Native 런타임 연결 역할을한다.
반면, KMP의 cinterop은 컴파일 타임 네이티브 바인딩 역할을 한다.

두 방식 모두 네이티브 API를 호출한다는 공통점이 있지만,
React Native의 브릿지는 런타임에 JS와 네이티브 사이를 중계하는 통신 계층이고,
KMP의 cinterop은 컴파일 단계에서 네이티브 API에 대한 Kotlin 바인딩을 생성한다는 차이가 있다.

위의 구조 덕분에 KMP에서는 Cocoapods를 사용하여 Kotlin 코드 베이스로 iOS의 라이브러리를 호출하여 확장할 수 있게 된다.

[안드로이드] MVI에서 Event 처리: Channel vs SharedFlow

Bum_2 — Mon, 22 Dec 2025 16:42:24 +0900

MVI(Model-View-Intent)로 앱을 만들다 보면, 사용자 입력(Event)을 처리할 때, Channel를 사용할지 SharedFlow 을 사용할지 고민이 되곤 했다. 이번 포스팅에서 이 둘의 차이점과 MVI패턴의 어떤 상황에서 사용하는 것이 유리할지 정리해보자.

Channel

코루틴 간, 값을 전달하기 위해 설계된 통신 도구이다.

핵심은 보내는 쪽과 받는 쪽의 역할이 명확히 분리되어있다.

이게 무슨 말이냐면,

Channel에서는:

Sender는 send만 할 수 있다.
Receiver는 receive만 할 수 있다.

한 쪽이 다른 한 쪽의 상태를 직접 관찰하거나 침범할 수 없다는 것이다.

즉, 생산자와 소비자가 "서로를 모른다"는 것이다.

특징

1. 소비 중심 모델이다

이벤트는 받는 쪽이 가져가야만 사라진다.
한 번 receive 된 값은 다시 받을 수 없다.

위 특성 때문에, 이벤트는 정확히 한 번만 처리된다.

2. 버퍼 크기(Capacity)

Channel은 버퍼 크기에 따라 동작이 달라진다.

RENDEZVOUS(0)
- 받는 쪽이 준비되지 않으면 send 가 suspend
BUFFERED
- 일정량이 버퍼에 쌓임
UNLIMITED
- 사실상 메모리 주의 필요

Channel은 이벤트가 얼마나 쌓일 수 있는지,

생산자가 소비자를 얼마나 기다릴지를 제어할 수 있다.

이는 이벤트 발생 빈도가 큰 경우에 중요하다.

SharedFlow

SharedFlow의 목표는 Flow를 여러 곳에서 동시에 수집할 수 있도록 하는 것이다.

특징

Hot Flow

수집 여부와 상관없이 값을 emit한다.
값은 흘러가고 Collector는 그 흐름에 참여 한다.

Broadcast Stream

하나의 emit에 대해서 여러 Collector에게 동시 전달이 가능하다.
Collector 간에는 서로 독립이다.

┌─ Collector A
Emitter ──┼─ Collector B
└─ Collector C

이벤트 정책

SharedFlow는 기본적으로 이벤트를 보장하지 않는다.

대신, 정책을 개발자가 선택할 수 있다.

replay
- 새 Collector가 과거 이벤트를 받을지
extraBufferCapacity
- 순간 폭주 흡수
onBufferOverflow
- 넘치면 멈출지 / 버릴지

SharedFlow는 '스트림'을 전제로 하기 때문에,
기본적으로 큐(버퍼)를 중심 개념으로 갖지 않는다.
정책 상, 선택적으로 버퍼를 사용한다.
Channel은 처음부터 큐를 중심으로 설계된 구조여서
버퍼(capacity)가 통신 의미와 강하게 결합되어 있다.

Channel은 다음 조건에 잘 맞는다.

이벤트는 반드시 한 번만 처리되어야 할 때
- 저장, 제출, 결제 등
입력 순서가 의미 있을 때
단일 이벤트 처리 루프를 유지하고 싶을 때
- Event → Reduce → State/Effect 흐름이 명확
이벤트 유실이나 중복 처리를 피하고 싶을 때

SharedFlow는 다음 조건에 잘 맞는다.

이벤트가 연속적/빈번하게 발생할 때
- 검색어 입력, 스크롤, 드래그
최신 입력만 처리해도 될 때
- 이전 요청 취소하고 최신만 반영
Flow 연산자로 이벤트를 가공하고 싶을 때
- debounce, throttle, flatMapLatest 등
여러 곳에서 이벤트를 받거나 관찰할 가능성이 있을 때

필자는 Channel과 SharedFlow를 고민하다가 SharedFlow를 선택하게 되었다.

그 이유는 아래와 같다.

1. 안드로이드 생명주기와의 궁합

repeatOnLifecycle 같은 패턴과 자연스럽게 결합이 가능하다.
UI는 스트림을 구독하고 해제하는 역할만 담당하고,
이 구독/해제의 타이밍이 화면의 활성/비활성 상태와 맞물리면서
마치 생명주기 이벤트에 반응하는 것처럼 보인다.

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.events.collect { event ->
            handle(event)
        }
    }
}

2. debounce/ flatMapLatest 같은 체인 제공

입력 이벤트를 스트림으로 다루는 경우,
debounce, flatMapLatest 같은 Flow 연산자를 바로 적용할 수 있다는 점이 크다.

Channel에서도 consumeAsFlow()로 변환하면 유사한 처리는 가능하지만,
이 경우 스트림 가공을 위해 구조가 한 단계 더 복잡해진다.

입력 이벤트를 사용하기 편하게 가공한다는 관점에서는
SharedFlow가 더 자연스럽게 느껴졌다.

위의 이유 때문에 결국 안드로이드에서 UI-Compose의 궁합에 잘 맞게 된 것 같고 선택하게 된 계기가 되었다.

[안드로이드] JDK, JRE, JVM 그리고 Gradle JDK

Bum_2 — Thu, 9 Oct 2025 16:53:23 +0900

안드로이드 프로젝트 세팅을 위해, Gradle 파일에 JDK를 설정하는 부분이 있다. 이번 글에서는 Gradle에 JDK가 왜 필요한지, 간단한 관련 개념과 함께 포스팅하여 남기고자 한다.

JVM

Java Virtual Machine 으로 자바의 핵심이다. .java 파일이 컴파일되어 생성된 .class 바이트코드를 실제로 실행하는 가상 머신이다.

JVM 내부에는 다음의 요소들이 존재한다.

클래스 로더 시스템
런타임 데이터 영역 (Heap, Stack, Method Area 등)
실행 엔진 (Interpreter, JIT 컴파일러)

자바 코드가 운영체제와 직접 연결되지 않고 실행할 수 있도록 해주는 엔진이다.

JRE

Java Runtime Environment 으로 JVM에 자바 표준 라이브러리와 런타임 환경을 더한 개념이다.

JVM
표준 클래스 (java.lang, java.util 등)
실행에 필요한 런타임 라이브러리

JRE는 자바 프로그램을 실행하는데 필요한 최소 환경이며 컴파일이나 디버깅과 같은 개발 도구는 포함하지 않는다.

JDK

Java Development Kit 으로 JRE에 개발 도구까지 포함한 패키지다.

JRE
javac (컴파일러)
jdb (디버거)
javadoc 등 각종 개발 도구

자바 개발자는 결국 JDK 를 설치해서 개발과 실행을 모두 수행하게 된다.

네이티브 안드로이드 프로젝트에서 build Gradle 파일을 보면 아래와 같이 어떤 JDK를 지정해야하는 코드를 볼 수 있다.

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }
    kotlinOptions {
        jvmTarget = "17"
    }
    
    ...
}

먼저 이 설정은 실행 시점이 아닌 컴파일 시점에 사용된다.

JDK에 있는 개발도구인 javac나 kotlinc 컴파일러가 어떤 JVM 버전을 기준으로 코드를 해석하고, 어떤 바이트 코드를 만들어야 하는지 결정하는 설정이다.

compileOptions

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }
    
    ...
}

자바 코드에 대한 설정이다.

sourceCompatibility

자바 소스 코드의 문법 기준이다. 어디까지의 Java 문법을 허용할 것인가를 정한다.

예를 들어,

VERSION_8 : lambda 가능
VERSION_17 : record, sealed class 등 가능

targetCompatibility

생성되는 .class 바이트코드의 JVM 버전이다.

이 클래스 파일은 최소 어떤 JVM 에서 실행 가능하도록 할 것인가를 정한다.

대부분의 경우, 문법과 실행 대상 JVM을 맞추기 때문에 sourceCompatibility 와 targetCompatibility는 동일하다.

여기서 궁금한 점은 굳이 이 둘을 따로 설정하도록 나눠놨다는 것이다.
찾아본 결과, 새로운 자바 문법을 사용하면서도 오래된 JVM 환경과의 호환성을 유지해야하는 경우를 지원하기 위해서다.
sourceCompatibility = 11, targetCompatibility = 8 와 같은 경우는 그나마 자주 사용되지만,
sourceCompatibility = 17, targetCompatibility = 11 와 같은 경우는 record나 sealed 문법을 사용할 수 없어서 잘 사용하지 않는다.

kotlinOptions

android {
    kotlinOptions {
        jvmTarget = "17"
    }
    
    ...
}

위의 블럭은 코틀린 컴파일러 전용 옵션이다.

Kotlin은 JVM 바이트 코드로 컴파일되는데, 이 때 생성되는 .class 파일의 JVM 타겟 버전을 지정한다.

즉, 코틀린 코드가 최소 JVM 몇 버전 부터 이해할 수 있는 .class 파일 형식으로 컴파일할지 설정한다.

javac와 달리 kotlinc의 컴파일 옵션에는 source 버전을 별도로 지정할 필요가 없다.
이는 Kotlin의 언어 규칙이 컴파일 타임에 모두 처리·변환되어, 람다나 타입 추론과 같은 개념이 실행 시점(JVM)에는 남지 않도록 설계되었기 때문이다.
그 결과 JVM은 Kotlin 언어를 해석하지 않고, 최소한의 바이트코드 정보만을 기반으로 실행을 담당한다.

아래와 같이 코틀린 컴파일러의 버전을 Gradle 플러그인/의존성이 결정하기만 하면, source 버전을 자동으로 컴파일러의 버전으로 따라간다.

plugins {
    kotlin("android") version "1.9.25"
}

지금까지 언급했던 내용은 빌드 결과물에 대한 버전 지정에 관한 내용이었다.

이제, Gradle JVM에 대해 알아보자.

Gradle JVM은 Gradle 이라는 빌드 도구 자체를 실행하는 JVM을 말한다.

Gradle은 Java/Kotlin으로 작성된 JVM 어플리케이션이다.

즉, 실행 자체가 JVM 없이는 불가능하다.

Gradle JVM은 다음을 실행한다:

Gradle core
build.gradle.kts (Kotlin DSL)
Gradle plugin (AGP, Kotlin plugin 등)
각종 task 로직
테스트 JVM fork 관리

Gradle JVM 버전에 따라 컴파일에 직접적으로 영향을 주지는 않지만,

Kotlin plugin이 특정 JDK 이상 요구한다던지, AGP 8.x 이상은 그래들 JDK 가 최소 17 이상이어야 한다던지하는 간접적으로 영향을 미친다.

Gradle JVM 버전 설정은 Settings에서 Build Tools에서 Gradle JDK를 지정할 수 있다.

정리하면, Gradle JVM은 빌드 결과물의 JVM 버전을 의미하는 것이 아니라,

Gradle이라는 빌드 시스템 자체를 실행하는 JVM을 의미하며, 컴파일러와 타겟 JVM 설정과는 완전히 독립적인 개념이다.

[안드로이드] 안드로이드 스튜디오 무선 연결이 안될 때

Bum_2 — Thu, 2 Oct 2025 18:02:04 +0900

안드로이드 스튜디오에서 무선 연결이 가끔 안될 때가 있다. 와이파이를 다시 연결하던가 IDE를 종료 후 다시 실행시켜도 동작하지 않으면 아래와 같은 방법을 사용하자.

1. CMD 실행

먼저, CMD를 실행하자. 관리자로 실행하지 않아도 된다.

안드로이드 스튜디오를 설치할 때, 대부분 platform-tools를 함께 설치했을 것이다.

안되어있다면,
Android Studio → Settings > Languages & Frameworks 에서 Android SDK Platform-Tools 항목을 클릭해 설치하자

2. platform-tools 폴더로 이동

CMD 창에서 아래 명령어를 입력하자. <계정 이름> 에는 독자가 사용하고 있는 계정 이름을 넣으면 된다.

cd C:\Users\<계정 이름>\AppData\Local\Android\Sdk\platform-tools

대부분 AppData 경로에 있지만, 혹시나 해당 경로에 platform-tools이 없는 경우,
1. 항목에 있는 경로에 들어가면 ANdroid SDK Location을 알 수 있다. 여기에서 platform-tools path로 이동하면 된다.
(Android Studio → Settings > Languages & Frameworks 에서 Android SDK Platform-Tools)

3. 디바이스 기기 페어하기 (보안 연결)

디바이스 설정에서 페어링 코드로 기기 페어링을 클릭하면 <사진 1> 같이 나오는데 DeviceIp : Port 를 가지고 페어를 할 수 있다.

명령어는 아래의 명령어를 입력하자.

adb pair DeviceIp:Port

<사진 1>

입력하면 기기 페어링 코드를 입력하는 문구가 나오는데, Wi-Fi 페어링 코드를 입력하자.

4. 디바이스 기기 연결하기 (실제 디버깅 연결)

3번 항목은 보안을 위해 진행하는 연결이며, 4번 항목이 실제로 기기를 연결하는 과정이다.

3번 항목에서 사용했던 다이얼로그 창(기기 페어링)은 자동으로 사라지는데 안 사라졌다면 취소로 제거하자.

그러면 <사진 2> 와 같은 화면으로 되돌아오는데 그 곳에서 Device Ip : Port를 사용하면 된다.

명령어는 아래의 명령어를 입력하자.

adb connect DeviceIp:Port

<사진 2>

[안드로이드] Gson과 kotlinx.serialization 차이

Bum_2 — Tue, 23 Sep 2025 19:01:35 +0900

안드로이드에서 Retrofit을 주입할 때, ConverterFactory로 Gson을 사용할지 kotlinx.serialization 중에 어떤걸 사용할지 고민한 경험이 있다. 이 둘은 어떤 목적에 따라 사용하는지 정리해보자.

네트워크 통신을 수행하기 위해서는 서버와 데이터를 주고받아야 하며, 안드로이드에서는 일반적으로 Retrofit을 사용한다.

이때 응용 계층에서는 주로 JSON이나 XML과 같은 데이터 형식을 통해 정보를 교환한다.
하지만 Java나 Kotlin은 객체 지향 언어이기 때문에, 네트워크로 전달받은 데이터를 객체 형태로 변환하여 관리해야 한다.

따라서 이러한 데이터 직렬화 과정을 수행할 때, Gson 또는 kotlinx.serialization과 같은 라이브러리를 사용하게 되며, 두 라이브러리의 차이는 바로 객체와 JSON 간 변환을 수행하는 방식에 있다.

kotlinx.serialization

kotlinx.serialization은 Kotlin 언어 공식 직렬화(Serialization) 라이브러리다.

Kotlin 객체를 JSON, ProtoBuf, CBOR 등 다양한 데이터 형식으로 변환하거나 반대로 역직렬화(Deserialization) 하기 위해 사용한다. JetBrains 이 직접 개발 및 유지보수하며, Kotlin 컴파일러와 함께 사용하는 컴파일 시점에 변환 코드를 자동 생성하는 것이 가장 큰 특징이다.

주요 특징 정리

1. Kotlin 공식 지원

JetBrains에서 개발한 Kotlin 전용 라이브러리.
Kotlin 컴파일러와 통합되어 있기 때문에, Kotlin 코드 스타일 및 기능(예: data class, sealed class 등)과 자연스럽게 연동.

2. 컴파일 타임 코드 생성

@Serializable 어노테이션이 붙은 클래스에 대해, Kotlin 컴파일러가 JSON 변환 로직을 자동으로 생성.
런타임에 리플렉션(reflection)을 사용하지 않으므로 속도가 빠르고, 메모리 사용량이 적다.

@Serializable
data class User(val name: String, val platForm: String)

// 직렬화 (encode)
Json.encodeToString(User("Bum2", "Tistory"))
// → {"name":"Bum2","platForm":"Tistory"}

// 역직렬화 (decode)
Json.decodeFromString<User>("""{"name":"Bum2","platForm":"Tistory"}""")
// → User(name="Bum2", platForm="Tistory")

3. 플러그인 설정 필요

코드를 자동 생성하기 위해선 org.jetbrains.kotlin.plugin.serialization 플러그인을 Gradle에 등록해야 한다.

// Data Module Gradle

plugins { id("org.jetbrains.kotlin.plugin.serialization") }

4. 타입 안정성과 Null 안전성 보장

컴파일 시점에 직렬화 가능한 필드와 타입을 검사하여, 런타임 오류를 최소화.
ignoreUnknownKeys, explicitNulls 등의 설정으로 서버 응답에도 유연하게 대응.

val json = Json {
    ignoreUnknownKeys = true // 서버에서 불필요한 키가 와도 무시
    explicitNulls = false // null 필드는 생략
}

5. Kotlin Multiplatform 지원

JVM(Android)뿐만 아니라 JS, iOS, Native 등 Kotlin Multiplatform 프로젝트에서도 사용 가능.
Gson이나 Moshi보다 확장성이 뛰어남.

6. Retrofit과의 연동

Retrofit에서 ConverterFactory로 연동 가능:

@Provides
@Singleton
@Bum2
fun provideSeraRetrofit(
    okHttpClient: OkHttpClient,
    json: Json,
    @Bum2 baseUrl: String,
): Retrofit {
    return Retrofit.Builder()
        .baseUrl(baseUrl)
        .client(okHttpClient)
        .addConverterFactory(
            json.asConverterFactory((requireNotNull("application/json".toMediaTypeOrNull()))),
        )
        .build()
}

7. 다양한 데이터 포맷 지원

단순 JSON뿐만 아니라, CBOR, ProtoBuf, Properties 등 다양한 포맷으로 직렬화 가능.

항목	설명
이름	kotlinx.serialization
만든 곳	JetBrains (Kotlin 공식)
용도	Kotlin 객체 ↔ JSON/CBOR/ProtoBuf 등 데이터 형식 변환
작동 시점	컴파일 타임 (Code Generation)
핵심 특징	빠름, 타입 안전, 리플렉션 없음, 멀티플랫폼 지원
Retrofit 연동법	.addConverterFactory(json.asConverterFactory(...))
플러그인 필요 여부	org.jetbrains.kotlin.plugin.serialization 등록 필수

Gson

Gson은 Google에서 개발한 JSON 직렬화(Serialization) 및 역직렬화(Deserialization) 라이브러리다.

Retrofit이나 OkHttp 같은 네트워크 라이브러리와 함께 사용되어 서버에서 주고받는 JSON 데이터를 자동으로 객체 형태로 처리할 수 있게 해준다.

주요 특징 정리

1. Google에서 개발한 JSON 파서

“Google JSON”의 약자로, Google이 직접 개발한 라이브러리.

2. 리플렉션(Reflection) 기반의 런타임 변환

Gson은 앱이 실행 중일 때(런타임) 클래스의 필드 정보를 읽어(JSON 키와 매칭) 객체를 생성.
컴파일 시점에 코드를 생성하지 않고, 런타임에 리플렉션을 사용하기 때문에 설정이 단순하고 빠르게 적용가능.
하지만 런타임 오버헤드(성능 비용)는 약간 존재.

3. Retrofit과의 쉬운 연동

별도의 플러그인 설정 없이 한 줄 의존성으로 바로 사용 가능.

// Data Module dependencies
implementation("com.squareup.retrofit2:converter-gson:2.11.0")

@Provides
@Singleton
@Bum2
fun provideRetrofit(
    okHttpClient: OkHttpClient,
    @Bum2 baseUrl: String,
): Retrofit {
    return Retrofit.Builder()
        .baseUrl(baseUrl)
        .client(okHttpClient)
        .addConverterFactory(GsonConverterFactory.create())
        .build()
}

4. 어노테이션 기반 매핑

JSON 키 이름과 객체 프로퍼티 이름이 다를 때는 @SerializedName 어노테이션을 사용해 매핑.

data class User(
    @SerializedName("user_name") val name: String,
    @SerializedName("user_age") val age: Int
)

5. 유연한 설정과 커스터마이징

날짜 포맷, 널 처리, pretty print, 필드 제외 등 다양한 옵션 제공

val gson = GsonBuilder()
    .setPrettyPrinting()
    .serializeNulls()
    .create()

항목	설명
이름	Gson (Google JSON)
만든 곳	Google
용도	Java/Kotlin 객체 ↔ JSON 데이터 형식 변환
작동 시점	런타임 (Reflection 기반)
핵심 특징	설정이 간단, 직관적인 사용법, 런타임 리플렉션 사용, 널 처리 및 매핑 유연
Retrofit 연동법	.addConverterFactory(GsonConverterFactory.create())
플러그인 필요 여부	별도 플러그인 불필요 (의존성 추가만으로 사용 가능)

결국 Gson과 kotlinx.serialization은 객체 ↔ JSON으로 변환하기 위한 도구다.
Gson은 런타임에 리플렉션을 사용해 변환을 수행한다.
별도의 설정 없이 빠르게 적용할 수 있다는 장점이 있지만, 앱이 실행 중일 때 클래스 구조를 탐색하므로 약간의 성능 오버헤드가 발생한다.

반면 kotlinx.serialization은 컴파일 시점에 변환 코드를 미리 생성한다.
Kotlin 컴파일러와 직접 통합되어 리플렉션 없이 빠르고 타입 안정적으로 작동하며, 멀티플랫폼 환경에서도 동일한 직렬화 로직을 공유할 수 있다는 강점을 지닌다.

[안드로이드] Gradle 이란

Bum_2 — Tue, 16 Sep 2025 18:13:11 +0900

안드로이드 개발을 하다보면 그래들 파일에 대해서 자주 접하게 되는데 Gradle이 뭔지 알아보자.

Gradle

소프트웨어를 빌드할 수 있는 오픈소스 빌드 자동화 툴이다.

안드로이드에서 빌드란 .apk 파일을 만드는 과정이다.

인텔리제이 IDE는 다양한 빌드 자동화 도구(Maven, Ant, Gradle)를 지원하지만, 안드로이드 스튜디오 IDE는 빌드 배포 시스템으로 Gradle만 사용할 수 있다.

Gradle 빌드 과정

Gradle의 빌드 진행 과정은 다음과 같다.

초기화(Initialization) : 어떤 프로젝트들을 빌드할지 결정하고, 각 프로젝트에 대한 초기 환경을 설정하는 단계이다. 즉, 멀티 모듈 구조에서 어떤 모듈을 빌드에 포함할지 결정하고, 각 모듈의 Gradle Project 객체를 구성하는 단계.
구성(Configutation) : 초기화 단계에서 생성된 각 모듈의 build.gradle(또는 build.gradle.kts) 파일을 실행해, 빌드에 필요한 Task를 구성하고 의존 관계를 설정하는 단계.
실행(Execution) : 구성 단계에서 생성된 Task를 기반으로, 사용자가 요청한 Task와 그에 의존하는 Task를 실제로 실행하여 빌드를 수행하는 단계.

1. 초기화 단계

어떤 프로젝트들을 빌드할지 결정하고, 각 프로젝트에 대한 초기 환경을 설정하는 단계이다. 즉, 멀티 모듈 구조에서 어떤 모듈들을 빌드에 포함할지 결정하고, 각 모듈의 Gradle Project 객체를 구성하는 단계이다.

첫 번째로, settings.gradle.kts 파일이 실행되어 include(":app", ":data", ":domain") 등의 코드를 통해 빌드에 포함할 모듈을 결정한다.

이 과정에서 Gradle은 각 모듈에 대응하는 Project 객체를 생성하고, 이를 기반으로 전체 빌드의 프로젝트 트리를 구성한다.

//settings.gradle.kts 코드 예시
pluginManagement {
    ...
}
dependencyResolutionManagement {
   ...
}

rootProject.name = "Bum2_tistory"
include(":app")
include(":data")
include(":domain")
include(":core")

2. 구성 단계

Project 객체에 빌드 설정을 적용하는 단계. Gradle은 각 모듈의 build.gradle(또는 build.gradle.kts) 파일을 실행하여, 초기화 단계에서 생성된 Project 객체에 Android Gradle Plugin(AGP)을 포함한 플러그인과 빌드 설정을 적용한다.

// Domain 모듈 build.gradle.kts 예시
plugins {
    alias(libs.plugins.android.library)
    alias(libs.plugins.kotlin.android) 
}

android {
    namespace = "com.tistory.bum2"
    compileSdk = 35

    defaultConfig {
        minSdk = 28

        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        consumerProguardFiles("consumer-rules.pro")
    }

    packaging {
        resources.excludes.add("META-INF/gradle/incremental.annotation.processors")
    }

    buildTypes {
        release {
            isMinifyEnabled = false
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro",
            )
        }
    }
    buildFeatures {
        buildConfig = true
    }
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }
    kotlinOptions {
        jvmTarget = "17"
    }
}

dependencies {
    testImplementation(libs.junit) 
    
    // paging
    implementation(libs.androidx.paging.compose)

    // timber
    implementation(libs.timber)

    implementation(libs.javax.inject)
}

build.gradle 파일의 각 블럭으로 Project 객체의 메서드가 호출된다. 각 블럭의 속성을 정리해보자면 다음과 같다.

plugins 블록
Android Gradle Plugin(AGP) 과 Kotlin Plugin 등 필요한 플러그인을 프로젝트에 적용.
- id("com.android.application") : Android 애플리케이션 빌드를 위한 플러그인
- id("org.jetbrains.kotlin.android") : Kotlin 언어를 지원하기 위한 플러그인
- 여기서는 Android 애플리케이션 빌드를 위한 Android Plugin과 Kotlin 언어를 사용하기 위한 Kotlin Plugin이 적용되어 있습니다.

android 블록
Android Gradle Plugin(AGP) 이 제공하는 DSL로, 애플리케이션의 전반적인 빌드 설정을 정의하는 핵심 영역
- namespace: 애플리케이션의 기본 패키지 이름
- compileSdk: 컴파일 시 사용할 Android API 버전
- defaultConfig { ... }: 앱의 기본 설정을 정의 (예: applicationId, minSdk, targetSdk, versionCode, versionName)
- buildTypes { ... }: 빌드 유형 정의 (예: release 빌드에서 isMinifyEnabled, ProGuard 설정 등)
- compileOptions { ... }: Java 소스 및 대상 호환성 지정
- kotlinOptions { ... }: Kotlin 컴파일러 옵션 지정. (jvmTarget 등)
- buildFeatures { ... }: 빌드 기능을 활성화/비활성화 (예: Compose 활성화)
- composeOptions { ... }: Compose 관련 컴파일러 확장 버전 설정
- packaging { ... }: 패키징 시 특정 리소스나 파일을 제외하도록 설정

dependencies 블록
dependencies 블록은 프로젝트가 빌드될 때 필요한 외부 라이브러리나 모듈 의존성을 정의

3. 실행 단계

구성단계에서 생성·설정된 모든 Project의 Task 그래프 중에서, 사용자가 요청한 Task 및 그 의존 Task를 실제로 실행하는 단계.

안드로이드 스튜디오에서 ./gradlew build --scan 명령어를 사용하면, 아래와 같이 독자의 프로젝트의 빌드 단계 과정에 따라 시간이 측정된다.

Gradle이 Task 기반으로 동작하는 이유

Gradle은 작업 단위를 명확히 정의하고, 그들 간의 의존 관계를 그래프 형태로 관리하기 위해 Task 기반으로 설계되었다.

Task는 독립적인 빌드 단위다.

예를 들어 다음과 같은 Task가 존재한다.

Task	입력	출력
compileDebugKotlin	.kt 파일	.class 파일
mergeResources	XML/이미지 등	병합된 리소스 폴더
packageDebug	클래스	.apk

위와 같이, 각 Task의 입력과 출력을 명시적으로 추적하기 때문에, 변경이 감지되지 않은 Task는 재실행하지 않고 결과를 재활용할 수 있다. 따라서 이 Task기반 구조 덕분에 변경된 부분만 빌드함으로써 증분 빌드가 가능하다.

안드로이드 개발자라면 알아야 하는 Gradle 원리