Wednesday, August 29, 2018

안드로이드 네트워크 상태 점검의 변천사와 최신 구현 전략
  /   No comments   

오늘날 대부분의 안드로이드 애플리케이션은 네트워크 연결을 기반으로 동작합니다. 사용자에게 최신 정보를 제공하고, 서버와 데이터를 동기화하며, 소셜 미디어 피드를 업데이트하는 등 네트워크는 앱의 핵심 기능과 사용자 경험(UX)을 좌우하는 생명선과도 같습니다. 하지만 사용자의 네트워크 환경은 끊임없이 변화합니다. 안정적인 Wi-Fi 환경에 있다가도 갑자기 신호가 약한 셀룰러 데이터 영역으로 이동할 수 있고, 비행기 모드로 전환되거나, 연결된 Wi-Fi가 실제로는 인터넷 접속이 불가능한 'Captive Portal' 상태일 수도 있습니다. 이러한 변화에 앱이 적절히 대응하지 못한다면, 사용자는 무한 로딩 화면을 보거나, 원인 모를 오류 메시지에 직면하며 큰 불편을 겪게 됩니다. 따라서, 현재 네트워크 상태를 정확하게 파악하고 그에 맞춰 앱의 동작을 제어하는 것은 현대적인 앱 개발의 필수 요건입니다.

안드로이드 플랫폼은 이러한 요구에 부응하기 위해 여러 세대에 걸쳐 네트워크 상태 확인 API를 발전시켜 왔습니다. 초창기의 간단한 연결 유무 확인에서부터, 특정 네트워크 유형(Wi-Fi, 셀룰러)을 구분하고, 나아가 네트워크의 실제 '품질'(실제 인터넷 사용 가능 여부, 과금 여부 등)까지 파악할 수 있는 정교한 메커니즘으로 진화했습니다. 이 글에서는 안드로이드 네트워크 상태 확인 API의 변천사를 살펴보고, 과거 방식의 문제점과 함께 현재 구글이 권장하는 가장 현대적이고 효율적인 방법을 심층적으로 탐구합니다. 단순히 '연결됨' 또는 '연결되지 않음'을 넘어, 네트워크의 세부적인 특성을 파악하고 이를 앱의 로직에 통합하여 사용자에게 최상의 경험을 제공하는 실용적인 구현 전략까지 자세히 다룰 것입니다.


1. 과거의 유산: `ConnectivityManager`와 `NetworkInfo` (Deprecated)

안드로이드 개발을 오래 해온 개발자라면 ConnectivityManager와 NetworkInfo 클래스에 매우 익숙할 것입니다. API 레벨 29 (Android 10)에서 공식적으로 deprecated 되기 전까지, 이들은 네트워크 상태를 확인하는 표준적인 방법이었습니다. 이 방식의 핵심은 시스템 서비스인 ConnectivityManager를 통해 현재 활성화된 네트워크에 대한 정보를 담고 있는 NetworkInfo 객체를 얻어오는 것이었습니다.

1.1. 기본 사용법과 한계

과거 방식의 코드는 일반적으로 다음과 같은 형태를 띱니다.


// 이 코드는 현재 Deprecated 되었으므로 새로운 프로젝트에는 사용하지 않는 것을 권장합니다.
public boolean isNetworkAvailable(Context context) {
    ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
    if (cm == null) {
        // ConnectivityManager를 얻어올 수 없는 극히 드문 경우
        return false;
    }
    
    // getActiveNetworkInfo()는 API 29에서 deprecated 되었습니다.
    NetworkInfo activeNetwork = cm.getActiveNetworkInfo();
    
    // activeNetwork가 null이 아니면서, isConnected()가 true인 경우에만 연결된 것으로 간주합니다.
    return activeNetwork != null && activeNetwork.isConnectedOrConnecting();
}

위 코드는 getActiveNetworkInfo()를 통해 현재 시스템이 기본으로 사용하는 네트워크의 정보를 가져옵니다. NetworkInfo 객체가 존재하고, 그 객체의 isConnectedOrConnecting() (또는 더 엄격하게 isConnected()) 메소드가 true를 반환하면 네트워크에 연결된 것으로 판단했습니다. 여기서 더 나아가 네트워크의 종류를 구분하기도 했습니다.


// 네트워크 유형(Wi-Fi, Mobile)을 구분하는 레거시 코드
// 이 또한 Deprecated된 API를 사용합니다.
public void checkNetworkType(Context context) {
    ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
    NetworkInfo activeNetwork = cm.getActiveNetworkInfo();

    if (activeNetwork != null && activeNetwork.isConnected()) {
        if (activeNetwork.getType() == ConnectivityManager.TYPE_WIFI) {
            // Wi-Fi에 연결됨
            Log.d("NetworkCheck", "Connected to WIFI");
        } else if (activeNetwork.getType() == ConnectivityManager.TYPE_MOBILE) {
            // 모바일 데이터에 연결됨
            Log.d("NetworkCheck", "Connected to Mobile Data");
        }
    } else {
        // 인터넷에 연결되지 않음
        Log.d("NetworkCheck", "Not connected to the internet");
    }
}

getType() 메소드를 사용해 ConnectivityManager.TYPE_WIFI나 ConnectivityManager.TYPE_MOBILE 같은 상수와 비교하여 현재 연결된 네트워크의 종류를 알아낼 수 있었습니다. 그러나 이 오래된 방식은 현대적인 네트워크 환경의 복잡성을 다루기에 여러 가지 명백한 한계를 가지고 있었습니다.

  • 부정확한 '연결'의 의미: isConnected()가 true라는 것은 디바이스가 Wi-Fi 공유기나 이동통신사 기지국에 성공적으로 '연결'되었다는 의미일 뿐, 해당 연결을 통해 '실제로 인터넷에 도달할 수 있는지'를 보장하지는 않습니다. 예를 들어, 인터넷 회선이 끊긴 Wi-Fi 공유기에 연결된 경우나, 로그인 인증이 필요한 Captive Portal Wi-Fi에 연결된 경우에도 isConnected()는 true를 반환하여 앱이 네트워크 요청을 시도하다가 타임아웃 오류를 발생시키는 원인이 되었습니다.
  • 다중 네트워크 환경 처리의 어려움: 최신 안드로이드 기기는 Wi-Fi와 셀룰러 데이터를 동시에 활성화하고 상황에 따라 더 나은 네트워크를 사용하는 '스마트 네트워크 전환' 기능을 지원합니다. 하지만 getActiveNetworkInfo()는 오직 '기본(active)' 네트워크 하나에 대한 정보만 반환하므로, 앱이 특정 목적(예: MMS 메시지 전송은 셀룰러로)으로 다른 네트워크를 사용해야 할 때 이를 유연하게 처리하기 어려웠습니다.
  • 네트워크 유형의 경직성: getType()은 Wi-Fi, Mobile, Ethernet 등 미리 정의된 정수 상수로 네트워크 유형을 구분합니다. 만약 VPN이나 Wi-Fi Aware와 같은 새로운 유형의 네트워크가 등장하면, 이를 제대로 처리하기 위해 앱 코드의 수정이 필요할 수 있었습니다. 즉, 네트워크의 '종류'가 아니라 네트워크의 '기능' 또는 '특성'에 기반한 판단이 필요해졌습니다.

1.2. 네트워크 변경 감지: `CONNECTIVITY_ACTION` BroadcastReceiver

네트워크 상태의 '변경'을 감지하기 위해 과거에는 CONNECTIVITY_ACTION 이라는 브로드캐스트를 사용하는 것이 일반적이었습니다. 개발자는 `BroadcastReceiver`를 구현하고 AndroidManifest.xml에 이를 등록하여 네트워크 연결 상태가 변경될 때마다 시스템으로부터 알림을 받을 수 있었습니다.



<receiver android:name=".MyNetworkReceiver" android:exported="false">
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>


// BroadcastReceiver 구현체 (레거시 방식)
public class MyNetworkReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        if ("android.net.conn.CONNECTIVITY_CHANGE".equals(intent.getAction())) {
            // isNetworkAvailable() 같은 메소드를 호출하여 현재 상태를 다시 확인
            boolean isConnected = isNetworkAvailable(context);
            Log.d("NetworkChange", "Network status changed. Connected: " + isConnected);
        }
    }
    // isNetworkAvailable() 구현은 위에 정의된 것을 사용
}

이 방식 역시 여러 문제점을 안고 있었습니다. 특히 안드로이드 7.0 (Nougat, API 24)부터는 백그라운드 최적화를 위해 앱이 Manifest에 `CONNECTIVITY_ACTION`을 등록하더라도 시스템이 이를 전달하지 않습니다. 앱이 포그라운드에 있을 때 동적으로 `registerReceiver()`를 통해 등록해야만 수신할 수 있게 되었고, 안드로이드 8.0 (Oreo, API 26)에서는 백그라운드 실행 제한이 더욱 강화되어 이 방식의 유용성은 크게 떨어졌습니다. 또한, 브로드캐스트는 시스템 전반에 영향을 미치는 무거운 작업이며, 짧은 시간 동안 네트워크가 여러 번 끊어졌다 연결될 때 불필요한 알림을 여러 번 발생시키는 비효율성도 있었습니다.

이러한 한계들로 인해 구글은 더 정교하고, 효율적이며, 현대적인 네트워크 환경에 적합한 새로운 API를 도입하게 되었습니다.


2. 현대적인 접근법: `NetworkRequest`와 `NetworkCallback`

안드로이드 5.0 (Lollipop, API 21)에서 처음 소개되었고 이후 지속적으로 개선된 NetworkRequest와 NetworkCallback은 레거시 API의 단점을 해결하기 위한 현대적인 솔루션입니다. 이 접근법의 핵심 철학은 '네트워크의 유형(type)이 아닌 기능(capability)에 집중'하고, '필요한 네트워크를 명시적으로 요청(request)하고 변경 사항을 콜백(callback)으로 받는' 것입니다. 이는 더 선언적이고, 효율적이며, 시스템 리소스를 적게 사용합니다.

2.1. 핵심 구성 요소

  • NetworkRequest: 앱이 필요로 하는 네트워크의 조건을 명시하는 객체입니다. 예를 들어, "나는 인터넷 접속이 가능하고, 데이터 사용량 과금이 되지 않는 Wi-Fi 네트워크가 필요해" 와 같은 요구사항을 코드로 표현할 수 있습니다. NetworkRequest.Builder를 통해 생성합니다.
  • NetworkCallback: NetworkRequest로 요청한 조건에 맞는 네트워크가 발견되거나(onAvailable), 사라지거나(onLost), 혹은 그 특성이 변경될 때(onCapabilitiesChanged) 호출되는 콜백 메소드들을 담고 있는 추상 클래스입니다. 개발자는 이 클래스를 상속받아 필요한 로직을 구현합니다.
  • ConnectivityManager: 여전히 중심적인 역할을 하지만, 이제는 registerNetworkCallback(), unregisterNetworkCallback(), getNetworkCapabilities()와 같은 새로운 메소드들을 통해 NetworkRequest와 NetworkCallback을 관리하는 브로커 역할을 합니다.
  • Network: 특정 네트워크 자체를 나타내는 객체입니다. 과거의 NetworkInfo가 정보의 '묶음'이었다면, Network는 네트워크 연결에 대한 '핸들' 또는 '식별자'에 가깝습니다. 이 객체를 사용하여 특정 네트워크의 상세 정보를 얻거나, 해당 네트워크를 통해서만 통신하도록 프로세스를 바인딩할 수도 있습니다.
  • NetworkCapabilities: 특정 Network 객체가 가진 기능과 특성을 설명하는 객체입니다. 이 객체를 통해 네트워크가 인터넷에 실제로 연결되어 있는지, 과금되는 네트워크인지, VPN을 통하는지 등을 확인할 수 있습니다.

2.2. 실시간 네트워크 상태 감지 구현 (Kotlin + Coroutines + Flow)

이제 현대적인 방식을 사용하여 앱 전역에서 네트워크 상태를 실시간으로 관찰할 수 있는 관리자 클래스를 만들어 보겠습니다. Kotlin의 Coroutines와 StateFlow를 사용하면 비동기적인 네트워크 변경 이벤트를 UI 레이어에 반응형으로 쉽게 전달할 수 있습니다.

먼저, 네트워크 상태를 나타내는 sealed class를 정의합니다.


// NetworkStatus.kt
sealed class NetworkStatus {
    object Available : NetworkStatus()
    object Unavailable : NetworkStatus()
}

다음으로, NetworkCallback을 사용하여 네트워크 변경을 감지하고 StateFlow로 상태를 발행하는 클래스를 만듭니다. 이 클래스는 애플리케이션 생명주기 동안 싱글톤으로 관리하는 것이 좋습니다.


// NetworkStatusTracker.kt
import android.content.Context
import android.net.ConnectivityManager
import android.net.Network
import android.net.NetworkCapabilities
import android.net.NetworkRequest
import kotlinx.coroutines.channels.awaitClose
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.callbackFlow
import kotlinx.coroutines.flow.conflate

class NetworkStatusTracker(context: Context) {

    private val connectivityManager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    // callbackFlow는 콜백 기반 API를 Flow로 변환하는 데 유용합니다.
    val networkStatus: Flow<NetworkStatus> = callbackFlow {
        // 1. 네트워크 요청 정의: 인터넷 기능이 있는 모든 네트워크를 대상으로 합니다.
        val networkRequest = NetworkRequest.Builder()
            .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
            .build()

        // 2. NetworkCallback 구현
        val callback = object : ConnectivityManager.NetworkCallback() {
            override fun onAvailable(network: Network) {
                super.onAvailable(network)
                // 새로운 네트워크가 사용 가능할 때, 상태를 Available로 변경
                // trySend는 소비자가 늦어 버퍼가 꽉 찼을 때 요소를 드롭하여 앱 비정상 종료를 방지합니다.
                trySend(NetworkStatus.Available)
            }

            override fun onLost(network: Network) {
                super.onLost(network)
                // 네트워크 연결이 끊겼을 때
                // 현재 연결된 네트워크가 있는지 다시 확인하여 정확도를 높입니다.
                val activeNetwork = connectivityManager.activeNetwork
                if (activeNetwork == null) {
                    trySend(NetworkStatus.Unavailable)
                }
            }
        }
        
        // 초기 상태 확인 및 전송
        // 앱 시작 시점에 네트워크 상태를 즉시 알 수 있도록 합니다.
        val initialNetwork = connectivityManager.activeNetwork
        if (initialNetwork != null) {
            trySend(NetworkStatus.Available)
        } else {
            trySend(NetworkStatus.Unavailable)
        }

        // 3. 콜백 등록
        connectivityManager.registerNetworkCallback(networkRequest, callback)

        // 4. Flow가 취소될 때 (Scope가 끝날 때) 콜백 등록 해제
        // awaitClose는 Flow 소비가 취소될 때까지 기다렸다가 블록 안의 코드를 실행합니다.
        // 메모리 릭을 방지하기 위해 필수적입니다.
        awaitClose {
            connectivityManager.unregisterNetworkCallback(callback)
        }
    }.conflate() // 중간에 값이 여러 번 발행되면 최신 값만 받도록 합니다.
}

이 `NetworkStatusTracker`를 ViewModel이나 Activity/Fragment에서 구독하여 UI를 업데이트할 수 있습니다.


// MyViewModel.kt
import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.flow.SharingStarted
import kotlinx.coroutines.flow.StateFlow
import kotlinx.coroutines.flow.stateIn

class MyViewModel(networkStatusTracker: NetworkStatusTracker) : ViewModel() {

    val networkStatus: StateFlow<NetworkStatus> = networkStatusTracker.networkStatus
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5000), // 구독자가 있을 때만 Flow를 활성화
            initialValue = NetworkStatus.Unavailable // 초기 값 설정
        )
}

// MyActivity.kt
class MyActivity : AppCompatActivity() {

    private lateinit var viewModel: MyViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        val networkStatusTracker = NetworkStatusTracker(this)
        // 실제 프로젝트에서는 DI(Dependency Injection) 라이브러리를 사용해 주입하는 것이 좋습니다.
        viewModel = MyViewModel(networkStatusTracker)
        
        // UI에서 네트워크 상태 구독
        lifecycleScope.launch {
            viewModel.networkStatus.collect { status ->
                when (status) {
                    is NetworkStatus.Available -> {
                        // 네트워크 사용 가능 UI 표시
                        // 예: 오프라인 배너 숨기기
                        showOnlineUI() 
                    }
                    is NetworkStatus.Unavailable -> {
                        // 네트워크 사용 불가 UI 표시
                        // 예: 오프라인 배너 표시, 재시도 버튼 활성화
                        showOfflineUI()
                    }
                }
            }
        }
    }
    // ... UI 업데이트 메소드
}

이 접근 방식은 생명주기를 인지하며, 콜백 등록 및 해제를 자동으로 관리하여 메모리 릭을 방지하고, 반응형 프로그래밍 모델을 통해 UI 로직을 간결하게 유지할 수 있다는 큰 장점이 있습니다.

3. 더 깊이 파고들기: `NetworkCapabilities`의 세부 기능 활용

단순히 인터넷 연결 유무(NET_CAPABILITY_INTERNET)를 확인하는 것을 넘어, NetworkCapabilities는 훨씬 더 풍부하고 세밀한 정보를 제공합니다. 이를 활용하면 사용자 경험을 한 차원 높일 수 있습니다.

3.1. 실제 인터넷 사용 가능 여부 확인: `NET_CAPABILITY_VALIDATED`

앞서 레거시 API의 문제점으로 지적했던 Captive Portal 문제를 해결하는 강력한 기능입니다.

  • NET_CAPABILITY_INTERNET: 이 네트워크가 인터넷에 연결되도록 '설정'되었음을 의미합니다. 즉, 라우터나 기지국까지는 연결되었지만, 그 너머의 실제 인터넷 세상과 통신이 가능한지는 보장하지 않습니다.
  • NET_CAPABILITY_VALIDATED: 시스템이 실제로 이 네트워크를 통해 외부 인터넷(예: 구글의 서버)에 접속할 수 있음을 '검증'했음을 의미합니다. 이 Capability가 있다면, 네트워크 요청이 성공할 확률이 매우 높습니다.

따라서, 가장 신뢰도 높은 인터넷 연결 확인은 NET_CAPABILITY_VALIDATED를 확인하는 것입니다.


// 한 번만 현재 상태를 확인하는 유틸리티 함수
fun isInternetValidated(context: Context): Boolean {
    val connectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    
    val activeNetwork: Network? = connectivityManager.activeNetwork
    if (activeNetwork == null) return false
    
    val capabilities: NetworkCapabilities? = connectivityManager.getNetworkCapabilities(activeNetwork)
    if (capabilities == null) return false
    
    return capabilities.hasCapability(NetworkCapabilities.NET_CAPABILITY_VALIDATED)
}

네트워크 요청을 보내기 직전에 이 함수를 호출하여 한번 더 확인하는 로직을 추가하면, 불필요한 API 호출과 그로 인한 오류를 사전에 방지할 수 있습니다.

3.2. 데이터 과금 네트워크 구분: `NET_CAPABILITY_NOT_METERED`

사용자가 셀룰러 데이터 요금제에 민감할 수 있으므로, 대용량 데이터를 다운로드하거나 동영상을 스트리밍하기 전에 현재 네트워크가 과금되는(metered) 네트워크인지 확인하는 것이 좋습니다.

  • Metered Network (종량제 네트워크): 사용한 데이터 양에 따라 요금이 부과될 수 있는 네트워크입니다. 일반적으로 셀룰러 데이터가 여기에 해당합니다.
  • Unmetered/Not-Metered Network (정액제/무료 네트워크): 데이터 사용량에 제한이 없는 네트워크입니다. 대부분의 Wi-Fi가 여기에 해당합니다.

NET_CAPABILITY_NOT_METERED capability는 현재 네트워크가 과금되지 않는 네트워크임을 나타냅니다.


// 특정 작업 전, 비과금 네트워크인지 확인하는 로직
fun startLargeDownload(context: Context) {
    val connectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    val activeNetwork = connectivityManager.activeNetwork
    val capabilities = connectivityManager.getNetworkCapabilities(activeNetwork)
    
    if (capabilities != null && capabilities.hasCapability(NetworkCapabilities.NET_CAPABILITY_NOT_METERED)) {
        // 비과금 네트워크이므로 바로 다운로드 시작
        initiateDownload()
    } else if (capabilities != null && capabilities.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR)) {
        // 과금될 수 있는 셀룰러 네트워크인 경우, 사용자에게 확인 받기
        showConfirmationDialog {
            initiateDownload()
        }
    } else {
        // 다운로드를 위한 적절한 네트워크가 아님을 알림
        showDownloadError("Wi-Fi 연결 후 다시 시도해주세요.")
    }
}

이러한 확인 로직은 사용자의 데이터 요금을 아껴주고, 앱에 대한 신뢰를 높이는 중요한 사용자 경험 요소입니다.

3.3. 전송 수단 확인: `hasTransport()`

네트워크의 '기능'을 우선시하는 것이 현대적인 접근법이지만, 때로는 Wi-Fi인지 셀룰러인지와 같은 '전송 수단(transport type)'을 직접 확인해야 할 때도 있습니다. NetworkCapabilities 객체의 hasTransport() 메소드를 사용하면 됩니다.


val capabilities: NetworkCapabilities? = connectivityManager.getNetworkCapabilities(activeNetwork)

if (capabilities?.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) == true) {
    Log.d("NetworkCheck", "전송 수단은 Wi-Fi 입니다.")
} else if (capabilities?.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) == true) {
    Log.d("NetworkCheck", "전송 수단은 셀룰러입니다.")
} else if (capabilities?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true) {
    Log.d("NetworkCheck", "VPN을 통해 연결되어 있습니다.")
} else if (capabilities?.hasTransport(NetworkCapabilities.TRANSPORT_ETHERNET) == true) {
    Log.g("NetworkCheck", "유선 이더넷에 연결되어 있습니다.")
}

4. 고급 활용 및 모범 사례

4.1. WorkManager와 함께 사용하기

안드로이드의 백그라운드 작업을 관리하는 권장 라이브러리인 WorkManager는 네트워크 제약 조건을 매우 쉽게 설정할 수 있도록 지원합니다. 예를 들어, '비과금 Wi-Fi에 연결되었을 때만' 사진을 백업하는 작업을 예약하고 싶다면 다음과 같이 제약(Constraints)을 설정할 수 있습니다.


import androidx.work.Constraints
import androidx.work.NetworkType
import androidx.work.OneTimeWorkRequestBuilder
import androidx.work.WorkManager

// 제약 조건 설정
val constraints = Constraints.Builder()
    // UNMETERED: Wi-Fi 등 비과금 네트워크 필요
    .setRequiredNetworkType(NetworkType.UNMETERED)
    // 기기가 충전 중일 때만 실행
    .setRequiresCharging(true) 
    .build()

// 작업 요청 생성
val backupWorkRequest = OneTimeWorkRequestBuilder<PhotoBackupWorker>()
    .setConstraints(constraints)
    .build()

// 작업 큐에 추가
WorkManager.getInstance(context).enqueue(backupWorkRequest)

WorkManager가 내부적으로 NetworkCallback과 유사한 메커니즘을 사용하여 조건이 충족될 때까지 기다렸다가 작업을 실행해주므로, 개발자가 직접 네트워크 상태를 모니터링할 필요가 없습니다. 이는 배터리와 시스템 리소스를 매우 효율적으로 사용하는 방법입니다.

4.2. 올바른 생명주기 관리

registerNetworkCallback()을 사용했다면, 반드시 짝이 맞는 `unregisterNetworkCallback()`을 호출하여 리스너를 해제해야 합니다. 그렇지 않으면 메모리 릭이 발생하고 앱의 배터리 소모가 증가합니다. 앞서 제시한 `callbackFlow` 예제에서는 `awaitClose` 블록이 이 역할을 자동으로 처리해줍니다. 만약 `ViewModel`이나 다른 클래스에서 직접 관리한다면, Activity/Fragment의 `onStart()`/`onStop()` 또는 `onResume()`/`onPause()` 생명주기 콜백에 맞춰 등록/해제 로직을 신중하게 구현해야 합니다.

  • onStart() / onStop(): 앱이 사용자에게 보일 때만 네트워크 상태를 관찰해야 하는 경우에 적합합니다. 백그라운드 상태에서는 리소스를 사용하지 않습니다.
  • onResume() / onPause(): 화면이 활성화되어 상호작용이 가능할 때만 필요한 경우에 사용합니다. 멀티 윈도우 환경에서는 `onStart` 이후에도 `onPause` 상태일 수 있음을 유의해야 합니다.
  • 애플리케이션 전역: `Application` 클래스의 `onCreate`에서 등록하고 프로세스가 종료될 때까지 유지하는 방법도 있지만, 앱이 항상 네트워크 상태를 알아야 하는 경우가 아니라면 권장되지 않습니다. `ProcessLifecycleOwner`를 사용하여 앱의 포그라운드/백그라운드 전환을 감지하는 것이 더 나은 대안이 될 수 있습니다.

결론: 스마트한 앱을 위한 현명한 네트워크 관리

안드로이드 앱에서 네트워크 상태를 확인하는 방법은 단순한 연결 유무 확인에서 벗어나, 네트워크의 실제 '품질'과 '특성'을 파악하는 방향으로 진화했습니다. 낡은 NetworkInfo API는 현대적인 멀티 네트워크 환경과 실제 인터넷 접속 가능성 여부를 제대로 반영하지 못하는 명백한 한계로 인해 역사의 뒤안길로 사라졌습니다.

이제 우리의 선택은 명확합니다. NetworkRequest와 NetworkCallback, 그리고 NetworkCapabilities를 중심으로 하는 현대적인 API를 적극적으로 활용해야 합니다. 이 새로운 접근법은 다음과 같은 핵심적인 이점을 제공합니다.

  1. 정확성: NET_CAPABILITY_VALIDATED를 통해 '연결됨'을 넘어 '실제 인터넷 사용 가능' 상태를 확인할 수 있습니다.
  2. 효율성: 불필요한 시스템 전역 브로드캐스트 대신, 앱에 필요한 네트워크 변경 사항만 콜백으로 받아 리소스를 절약합니다.
  3. 유연성: 네트워크의 '종류'가 아닌 '기능'에 기반하여 로직을 작성하므로, 미래에 등장할 새로운 네트워크 기술에도 유연하게 대응할 수 있습니다.
  4. 사용자 경험 향상: NET_CAPABILITY_NOT_METERED 등을 활용해 사용자의 데이터 요금제를 고려하는 똑똑한 기능을 구현할 수 있습니다.

Kotlin Coroutines의 `Flow`와 같은 현대적인 비동기 처리 방식을 접목하면, 이러한 네트워크 상태 변화를 앱의 UI와 로직에 더욱 간결하고 안정적으로 통합할 수 있습니다. 궁극적으로, 네트워크는 보이지 않는 곳에서 앱을 움직이는 혈관과 같습니다. 이 혈관의 상태를 얼마나 지능적으로 파악하고 대응하느냐에 따라 앱의 안정성과 사용자 만족도가 결정될 것입니다. 이제, 과거의 유산에서 벗어나 더욱 견고하고 사용자 친화적인 앱을 만들기 위한 현대적인 네트워크 관리 전략을 여러분의 코드에 적용할 때입니다.


0 개의 댓글:

Post a Comment