연결 끊김 — 일반적인 원인과 해결 방법

모바일 앱에서 “연결 끊김”의 의미

연결 끊김 — 앱이 서버와의 연결을 잃거나, 작업에 응답하지 않거나, 오류로 종료되는 상황을 설명하는 사용자 용어입니다. 기술적으로는 네트워크 오류(타임아웃, DNS 실패), ANR(UI 스레드 멈춤), 충돌(처리되지 않은 예외) 또는 경쟁 조건(race condition)일 수 있습니다.

사용자의 관점에서 이러한 모든 시나리오는 동일하게 보입니다: 앱이 작동을 멈춥니다. 개발자에게 차이점은 진단 및 수정 접근 방식에 있습니다. 네트워크 오류는 재시도 메커니즘으로 해결되고, ANR은 UI 스레드에서 작업을 분리하여, 충돌은 예외 처리로 해결됩니다.

Crittercism(현재 Apteligent)에 따르면, 모바일 앱은 충돌할 때마다 평균 1~2%의 사용자를 잃습니다. 100만 사용자 앱의 경우, 단일 버그당 1만~2만 건의 설치 손실을 의미합니다. 이는 금융 및 의료 분야 앱에서 특히 중요합니다.

연결 손실의 주요 원인

불안정한 네트워크 — 모바일 기기는 지속적으로 Wi-Fi와 모바일 네트워크 간을 전환하며, 커버리지가 없는 영역(지하철, 엘리베이터, 지하실)에 진입합니다. 각 전환은 일시적인 연결 손실을 일으키며 앱이 올바르게 처리해야 합니다.

타임아웃 — 서버가 설정된 타임아웃(보통 10~30초) 내에 응답하지 않으면 클라이언트가 SocketTimeoutException을 던집니다. 피드백 없는 긴 타임아웃은 사용자에게 멈춤으로 인식됩니다. 타임아웃은 15초를 초과하지 않도록 설정하는 것이 좋습니다.

val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .build()

경쟁 조건(race condition) — 여러 스레드가 동기화 없이 동시에 동일한 데이터를 읽고 쓸 때 발생합니다. 예를 들어, 네트워크에서 캐시를 업데이트하는 것과 동시에 UI 스레드에서 캐시에서 데이터를 로드하면 오래되었거나 잘못된 데이터가 표시될 수 있습니다.

• 처리되지 않은 예외가 콜백이나 코루틴에서 발생하면 앱이 충돌함
• 메모리 압박 — 포그라운드 앱에 충분한 메모리가 없으면 시스템이 앱을 종료함
• 라이프사이클 경쟁 — Activity/Fragment가 파괴된 후 비동기 작업이 완료됨
• UI 차단 — 메인 스레드에서 네트워크 또는 데이터베이스 작업을 수행하면 5초 후 ANR 발생

내결함성 애플리케이션을 위한 아키텍처

Offline-first — 로컬 스토리지(Room, CoreData)를 유일한 신뢰할 수 있는 정보 소스로 사용하는 아키텍처 패턴입니다. 네트워크는 백그라운드 데이터 동기화에 사용됩니다. 사용자는 네트워크 연결 없이도 로컬 캐시에서 항상 최신 데이터를 볼 수 있습니다.

Repository 패턴 — 네트워크에서 데이터를 가져올지 캐시에서 가져올지 결정하는 데이터의 단일 진입점입니다. Repository는 ViewModel 및 UI에서 데이터 소스를 추상화합니다. 네트워크 오류 시 Repository는 자동으로 로컬 소스로 전환합니다.

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): Result<List<User>> {
        return try {
            val remote = api.fetchUsers()
            dao.insertAll(remote)
            Result.success(remote)
        } catch (e: IOException) {
            val cached = dao.getAll()
            if (cached.isNotEmpty()) {
                Result.success(cached) // return cache on network error
            } else {
                Result.failure(e)
            }
        }
    }
}

서킷 브레이커 — 서버를 사용할 수 없을 때 요청 폭주로부터 보호하는 패턴입니다. N번 연속 오류 후 서킷 브레이커가 열리고 모든 요청은 연결을 시도하지 않고 즉시 오류를 반환합니다. 지정된 타임아웃 후 서킷 브레이커는 테스트 요청을 위해 반열림 상태로 전환됩니다.

네트워크 오류 처리 방법

지수 백오프(Exponential backoff) — 표준 재시도 메커니즘입니다. 첫 번째 실패 후 1초, 두 번째 후 2초, 그 다음 4, 8, 16초를 기다립니다. 서버와 배터리에 과부하를 주지 않도록 최대 재시도 횟수(보통 3~5회)를 제한하세요.

사용자 피드백 — 네트워크 오류 시 명확한 메시지를 표시합니다: “연결 없음”, “서버를 일시적으로 사용할 수 없음”, “인터넷 연결을 확인하세요”. Snackbar 또는 Inline State View를 사용하세요. 절대 기술적 오류(HTTP 500, SocketException)를 사용자에게 표시하지 마세요.

ConnectivityManager — 네트워크 모니터링을 위한 Android API입니다. 앱이 변경 사항에 반응하도록 합니다: 연결 손실 시 플레이스홀더를 표시하고, 복원 시 자동으로 데이터를 업데이트합니다. iOS에서는 Network 프레임워크의 NWPathMonitor를 사용하세요.

class NetworkMonitor(private val context: Context) {
    private val manager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    fun isOnline(): Boolean {
        val network = manager.activeNetwork ?: return false
        val caps = manager.getNetworkCapabilities(network) ?: return false
        return caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    }
}

모니터링 및 로깅 도구

Crashlytics(Firebase) — 모바일 앱을 위한 표준 충돌 보고 도구입니다. 모든 처리되지 않은 예외의 스택 추적, OS 버전, 기기 모델 및 충돌 시간을 수집합니다. 오류를 그룹화하고 수정 책임자를 지정할 수 있습니다.

Sentry — 성능 모니터링을 지원하는 Crashlytics의 대안입니다. 특정 트랜잭션(예: “사용자 인증”)을 추적하고 어떤 단계에서 오류가 발생했는지 확인할 수 있습니다. 성능 추적은 네트워크 타임아웃과 앱 로직 버그를 구별하는 데 도움이 됩니다.

Timber — 클래스별로 자동으로 태그를 추가하는 Android용 로깅 라이브러리입니다. 디버그 빌드에서는 모든 네트워크 요청과 응답을 기록합니다. 릴리스 빌드에서는 Crashlytics.setCustomLog를 통해 오류와 경고만 기록합니다.

Firebase Summit 2023에 따르면, Crashlytics + Performance Monitoring을 구현한 앱은 중요한 버그를 감지하고 수정하는 평균 시간을 3일에서 4시간으로 단축했습니다. 활성 사용자의 0.1%를 초과하는 빈도의 충돌마다 알림을 설정하는 것이 좋습니다.