📶 터널 속에서도 멀쩡한 앱 만들기: 안드로이드 오프라인 퍼스트 앱 개발 완전 정복 가이드 🚇

🧭 1. 오프라인 퍼스트란 정확히 무엇일까?

먼저 오해부터 하나 풀고 갈게요. 오프라인 퍼스트는 "인터넷 없이 쓰는 앱"이 아닙니다. 오히려 대부분의 오프라인 퍼스트 앱은 서버와 열심히 통신하는 앱이에요. 차이점은 통신 결과를 화면에 바로 뿌리지 않고, 일단 로컬 저장소에 기록한 뒤 화면은 로컬 저장소만 바라본다는 데 있습니다.

안드로이드 개발자 공식 문서(Android Developers의 "Build an offline-first app" 가이드)는 오프라인 퍼스트 앱을 "인터넷 접속 없이도 핵심 기능의 전부 또는 중요한 일부를 수행할 수 있는 앱"으로 설명하고, 이를 위해 데이터 레이어에 로컬 데이터 소스와 네트워크 데이터 소스를 함께 두되 로컬 쪽을 정규 소스(canonical source)로 삼으라고 안내합니다.

🎯 왜 지금 오프라인 퍼스트인가

5G 시대에 웬 오프라인 타령이냐고요? 현실의 네트워크는 생각보다 자주 흔들립니다. 지하 주차장, 고층 엘리베이터, 비행기 모드, 해외 로밍 제한, 데이터 요금 절약 모드, 사람이 몰린 공연장과 경기장의 혼잡 셀… 그리고 "연결은 되어 있지만 사실상 안 되는" 저속·불안정 연결(일명 Lie-fi)이 가장 골치 아픈 상황이죠.

🏛️ 2. 공식 아키텍처로 보는 뼈대: 데이터 레이어의 재구성

안드로이드 권장 앱 아키텍처는 크게 UI 레이어, (선택적) 도메인 레이어, 데이터 레이어로 나뉩니다. 오프라인 퍼스트의 승부처는 단연 데이터 레이어, 그중에서도 Repository입니다. Repository가 로컬과 원격 데이터 소스를 조율하고, 바깥(ViewModel)에는 "로컬 기준의 데이터 스트림"만 노출하는 구조죠.

📌 핵심 원칙 세 가지

🗂️ 모델을 세 겹으로 나누는 이유

실무에서는 같은 '할 일' 데이터라도 모델을 레이어별로 분리하는 경우가 많습니다. 구글의 공식 샘플 앱 Now in Android도 네트워크 모델, 엔티티(DB) 모델, 외부 노출용 모델을 분리하는 구조를 보여 줍니다.

이렇게 나누면 서버가 필드명을 바꿔도 UI 코드는 무사하고, DB에 syncState 같은 내부용 컬럼을 추가해도 화면 코드가 오염되지 않습니다. 처음엔 번거로워 보여도 앱이 커질수록 효과가 커지는, 일종의 '아키텍처 적금'이에요. 💰

🧱 3. 로컬 저장소 고르기: Room, DataStore, 그리고 파일

오프라인 퍼스트의 체력은 로컬 저장소에서 나옵니다. 안드로이드에서 많이 쓰는 선택지를 비교해 볼게요.

🧩 동기화를 고려한 엔티티 설계

오프라인 퍼스트 엔티티는 "데이터 + 동기화 메타데이터"를 함께 품습니다. 아래는 할 일 앱을 예로 든 엔티티예요.

enum class SyncState { SYNCED, PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE }

@Entity(tableName = "tasks")
data class TaskEntity(
    @PrimaryKey val id: String,          // 클라이언트에서 생성한 UUID
    val title: String,
    val done: Boolean,
    val updatedAt: Long,                 // 마지막 수정 시각(밀리초)
    val serverVersion: Long? = null,     // 서버가 부여한 버전(충돌 감지용)
    val syncState: SyncState = SyncState.SYNCED,
    val isDeleted: Boolean = false       // 소프트 삭제(톰스톤)
)

여기에는 오프라인 퍼스트의 단골 노하우가 세 가지 숨어 있습니다.

🔍 DAO: 읽기는 Flow, 쓰기는 suspend

@Dao
interface TaskDao {
    @Query("SELECT * FROM tasks WHERE isDeleted = 0 ORDER BY updatedAt DESC")
    fun observeTasks(): Flow<List<TaskEntity>>

    @Query("SELECT * FROM tasks WHERE syncState != 'SYNCED'")
    suspend fun getPendingTasks(): List<TaskEntity>

    @Upsert
    suspend fun upsert(task: TaskEntity)

    @Upsert
    suspend fun upsertAll(tasks: List<TaskEntity>)

    @Query("DELETE FROM tasks WHERE id = :id")
    suspend fun hardDelete(id: String)
}

@Upsert는 Room 2.5.0부터 제공되는 어노테이션으로, 기본 키가 있으면 갱신하고 없으면 삽입합니다. 서버에서 받은 데이터를 로컬에 덮어쓸 때 아주 편리합니다. 그리고 observeTasks()가 반환하는 Flow는 해당 테이블이 바뀔 때마다 새 목록을 다시 내보내기 때문에, 화면을 '다시 그리는 책임'을 DB가 대신 지게 됩니다.

📖 4. 읽기 전략: 로컬을 보여주고, 원격으로 채운다

오프라인 퍼스트 읽기의 기본 패턴은 아주 단순합니다. Repository는 DAO의 Flow를 그대로(모델 변환만 해서) 내보낸다. 끝이에요. 서버 호출은 이 흐름에 끼어들지 않습니다.

class OfflineFirstTaskRepository @Inject constructor(
    private val taskDao: TaskDao,
    private val api: TaskApi,
) : TaskRepository {

    override fun observeTasks(): Flow<List<Task>> =
        taskDao.observeTasks().map { list -> list.map { it.asExternalModel() } }

    // 동기화는 별도 함수 — 화면 흐름과 분리
    override suspend fun refresh(): Result<Unit> = runCatching {
        val remote = api.getTasks()
        taskDao.upsertAll(remote.map { it.asEntity() })
    }
}

ViewModel은 이 Flow를 stateIn으로 UI 상태로 바꿔 둡니다.

@HiltViewModel
class TaskViewModel @Inject constructor(
    repository: TaskRepository
) : ViewModel() {
    val uiState: StateFlow<TaskUiState> = repository.observeTasks()
        .map { TaskUiState.Success(it) }
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5_000),
            initialValue = TaskUiState.Loading
        )
}

WhileSubscribed(5_000)은 화면 회전처럼 짧게 구독자가 사라지는 경우에는 상류 Flow를 유지하고, 5초 이상 아무도 보지 않으면 정지하도록 하는 설정입니다. 공식 샘플들에서도 자주 보이는 값이에요.

🧊 빈 화면 vs 로딩 vs 오프라인: 상태를 정직하게

로컬 우선이라고 해서 모든 상황이 아름답진 않습니다. 앱을 설치하고 처음 연 순간 오프라인이라면 로컬 DB는 텅 비어 있죠. 이때 "할 일이 없습니다 🎉"를 보여주면 거짓말이 됩니다. 그래서 UI 상태는 최소한 다음을 구분하는 것이 좋습니다.

"진짜 비어 있음"과 "아직 못 받아옴"을 구분하려면 최초 동기화 완료 여부나 마지막 동기화 시각을 DataStore 등에 저장해 두면 됩니다.

📜 대용량 목록: Paging 3의 RemoteMediator

피드처럼 끝없이 이어지는 목록은 전체를 한 번에 받아둘 수 없습니다. 이럴 때 Paging 3 라이브러리의 RemoteMediator가 오프라인 퍼스트 방식의 페이지네이션을 지원합니다. 구조는 이렇습니다.

@OptIn(ExperimentalPagingApi::class)
val pager = Pager(
    config = PagingConfig(pageSize = 30),
    remoteMediator = ArticleRemoteMediator(api, db),
    pagingSourceFactory = { db.articleDao().pagingSource() }
).flow

오프라인일 때 사용자는 이미 받아 둔 페이지까지 스크롤할 수 있고, 연결이 돌아오면 이어서 로드됩니다. 구조 자체가 오프라인 퍼스트예요.

✍️ 5. 쓰기 전략: 세 가지 선택지

읽기는 비교적 쉽습니다. 진짜 어려운 건 쓰기죠. 공식 가이드는 오프라인 퍼스트 앱의 쓰기를 크게 세 가지 전략으로 정리합니다. 기능마다 다른 전략을 섞어 쓰는 것이 정상입니다.

⚡ 지연 쓰기 구현: 낙관적 업데이트

사용자가 할 일을 체크하는 순간, 서버 응답을 기다리지 않고 바로 체크된 모습을 보여주는 것을 낙관적 업데이트(Optimistic Update)라고 합니다. 오프라인 퍼스트에서는 로컬 DB에 쓰기만 하면 Flow가 알아서 화면을 바꾸니, 낙관적 업데이트가 거의 공짜로 따라옵니다.

override suspend fun toggleDone(id: String, done: Boolean) {
    val current = taskDao.getById(id) ?: return
    taskDao.upsert(
        current.copy(
            done = done,
            updatedAt = System.currentTimeMillis(),
            syncState = if (current.syncState == SyncState.PENDING_CREATE)
                SyncState.PENDING_CREATE   // 아직 서버에 없는 항목이면 생성 대기 유지
            else SyncState.PENDING_UPDATE
        )
    )
    syncScheduler.requestSync()  // WorkManager에 동기화 예약
}

override suspend fun delete(id: String) {
    val current = taskDao.getById(id) ?: return
    if (current.syncState == SyncState.PENDING_CREATE) {
        taskDao.hardDelete(id)    // 서버에 간 적 없으니 그냥 삭제
    } else {
        taskDao.upsert(current.copy(isDeleted = true,
            syncState = SyncState.PENDING_DELETE,
            updatedAt = System.currentTimeMillis()))
        syncScheduler.requestSync()
    }
}

📮 아웃박스(Outbox) 패턴: 변경 사항을 별도 테이블로

엔티티에 동기화 상태 컬럼을 두는 방식 외에, 변경 명령 자체를 별도 테이블에 쌓는 아웃박스 패턴도 많이 씁니다. 특히 "좋아요 누르기 → 취소 → 다시 누르기"처럼 동작의 순서와 의미가 중요한 경우에 유리합니다.

@Entity(tableName = "outbox")
data class OutboxEntity(
    @PrimaryKey(autoGenerate = true) val seq: Long = 0,
    val entityId: String,
    val operation: String,      // "CREATE" | "UPDATE" | "DELETE"
    val payloadJson: String,
    val createdAt: Long,
    val attempt: Int = 0
)

중요한 점은 데이터 변경과 아웃박스 기록을 하나의 트랜잭션으로 묶는 것입니다. Room의 withTransaction 블록(room-ktx)을 쓰면 "데이터는 바뀌었는데 아웃박스 기록은 빠졌다" 같은 반쪽 상태를 막을 수 있어요.

suspend fun addTask(title: String) {
    val entity = TaskEntity(UUID.randomUUID().toString(), title, false,
        System.currentTimeMillis(), syncState = SyncState.PENDING_CREATE)
    db.withTransaction {
        db.taskDao().upsert(entity)
        db.outboxDao().insert(OutboxEntity(entityId = entity.id,
            operation = "CREATE", payloadJson = json.encodeToString(entity.asNetwork()),
            createdAt = System.currentTimeMillis()))
    }
    syncScheduler.requestSync()
}

🔄 6. 동기화 엔진: WorkManager로 '절대 포기하지 않는' 전송

로컬에 쌓인 변경 사항을 서버로 보내고, 서버의 새 데이터를 받아오는 작업이 동기화입니다. 이 일은 앱이 백그라운드로 가거나 프로세스가 종료돼도 이어져야 하므로, Android Jetpack의 WorkManager가 권장 도구입니다. WorkManager는 앱이 종료되거나 기기가 재부팅되어도 예약된 작업이 실행되도록 보장하는 지속형(persistent) 백그라운드 작업 API예요.

⚙️ 동기화 워커 만들기

@HiltWorker
class SyncWorker @AssistedInject constructor(
    @Assisted context: Context,
    @Assisted params: WorkerParameters,
    private val syncer: TaskSyncer,
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result = try {
        syncer.pushLocalChanges()   // 1) 로컬 변경 사항 업로드
        syncer.pullRemoteChanges()  // 2) 서버 변경 사항 다운로드
        Result.success()
    } catch (e: IOException) {
        Result.retry()              // 네트워크 오류: 백오프 후 재시도
    } catch (e: HttpException) {
        if (e.code() in 500..599) Result.retry() else Result.failure()
    }
}

오류 종류를 구분하는 것이 중요합니다. 네트워크 단절이나 서버 5xx 오류는 일시적이니 재시도할 가치가 있지만, 400(잘못된 요청) 같은 영구적 오류를 무한 재시도하면 배터리만 녹입니다. 영구 오류 항목은 따로 표시해서 사용자에게 알리거나 격리하세요.

📅 동기화 예약: 제약 조건과 고유 작업

class SyncScheduler @Inject constructor(
    @ApplicationContext private val context: Context
) {
    private val constraints = Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED)
        .build()

    fun requestSync() {
        val request = OneTimeWorkRequestBuilder<SyncWorker>()
            .setConstraints(constraints)
            .setBackoffCriteria(BackoffPolicy.EXPONENTIAL,
                WorkRequest.MIN_BACKOFF_MILLIS, TimeUnit.MILLISECONDS)
            .build()
        WorkManager.getInstance(context).enqueueUniqueWork(
            "task-sync", ExistingWorkPolicy.KEEP, request)
    }

    fun schedulePeriodicSync() {
        val request = PeriodicWorkRequestBuilder<SyncWorker>(6, TimeUnit.HOURS)
            .setConstraints(constraints)
            .build()
        WorkManager.getInstance(context).enqueueUniquePeriodicWork(
            "task-periodic-sync", ExistingPeriodicWorkPolicy.KEEP, request)
    }
}

🚀 앱 시작 시 동기화

Now in Android 샘플은 앱 시작 시 동기화 작업을 등록하는 구조를 보여줍니다. 앱 시작 시점에 고유 작업으로 동기화를 한 번 걸어 두면, 사용자가 화면을 보는 동안 백그라운드에서 최신 데이터가 채워집니다. 즉시 실행이 중요하다면 setExpedited()로 긴급 작업을 요청할 수 있는데, 긴급 작업은 시스템 할당량의 제약을 받으므로 할당량 초과 시의 정책(OutOfQuotaPolicy)도 함께 지정해야 합니다.

📡 7. Pull vs Push: 서버의 변화를 어떻게 알아챌까

로컬 변경을 서버로 올리는 건 앱이 주도하지만, 서버에서 생긴 변화를 아는 방법은 설계 선택이 필요합니다. 공식 가이드는 이를 풀(Pull) 기반과 푸시(Push) 기반 동기화로 구분합니다.

실무에서는 하이브리드가 흔합니다. Now in Android 샘플은 FCM 같은 메시지로 "변경이 있다"는 신호를 받으면 동기화를 실행하는 방식을 설명하는데, 이때 메시지에는 실제 데이터 대신 "무엇이 바뀌었는지"만 담긴 가벼운 신호를 보내고, 앱이 그 신호를 받으면 WorkManager로 실제 데이터를 내려받는 구조가 일반적입니다. FCM 메시지는 페이로드 크기 제한(데이터 메시지 기준 최대 4KB)이 있고 전달 시점도 보장되지 않으니, 푸시 누락을 대비해 주기적 Pull도 함께 두는 것이 안전합니다.

📦 변경분만 가져오기: 델타 동기화

매번 전체 목록을 내려받는 건 데이터가 적을 땐 괜찮지만, 수천 건이 넘어가면 금세 부담이 됩니다. 그래서 변경분(Delta)만 주고받는 동기화를 설계합니다. 대표적인 방법은 두 가지예요.

suspend fun pullRemoteChanges() {
    val since = syncPrefs.lastVersion()            // DataStore에 저장된 커서
    val changes = api.getTaskChanges(since)        // { items, deletedIds, latestVersion }
    db.withTransaction {
        // 아직 서버에 안 보낸 로컬 변경은 덮어쓰지 않도록 보호
        val pendingIds = taskDao.getPendingTasks().map { it.id }.toSet()
        taskDao.upsertAll(changes.items
            .filter { it.id !in pendingIds }
            .map { it.asEntity() })
        changes.deletedIds.filter { it !in pendingIds }.forEach { taskDao.hardDelete(it) }
    }
    syncPrefs.saveLastVersion(changes.latestVersion)
}

위 코드의 pendingIds 필터가 바로 다음 장에서 다룰 충돌의 가장 단순한 방어선입니다. 여기서는 로컬에 대기 중인 변경을 보호했지만, 이건 하나의 정책일 뿐이에요. 어떤 정책이 맞는지는 데이터 성격에 따라 달라집니다.

⚔️ 8. 충돌 해결: 오프라인 퍼스트의 최종 보스

휴대폰과 태블릿으로 같은 메모를 각각 오프라인에서 수정했다고 상상해 보세요. 둘 다 연결이 돌아오면 서버는 누구 말을 들어야 할까요? 이것이 동기화 충돌입니다. 오프라인 퍼스트의 난이도는 사실상 이 문제를 얼마나 정교하게 다루느냐로 결정돼요.

🧠 충돌 해결 전략 지도

공식 가이드는 많은 앱에서 마지막 쓰기 승리(Last Write Wins)를 합리적인 기본값으로 소개하면서, 이를 위해 기기 쪽 데이터에 쓰기 시각 같은 메타데이터를 함께 저장하라고 안내합니다. 단, LWW를 쓸 때는 기기 시계는 사용자가 바꿀 수 있고 틀릴 수 있다는 점을 기억하세요. 판정 기준을 서버 수신 시각으로 두거나, 서버가 발급한 버전 번호를 함께 쓰는 식으로 보완하는 경우가 많습니다.

🛡️ 버전 기반 충돌 처리 예시

suspend fun pushLocalChanges() {
    for (task in taskDao.getPendingTasks()) {
        try {
            when (task.syncState) {
                SyncState.PENDING_CREATE -> {
                    val saved = api.createTask(task.asNetwork())
                    taskDao.upsert(task.copy(serverVersion = saved.version,
                        syncState = SyncState.SYNCED))
                }
                SyncState.PENDING_UPDATE -> {
                    val saved = api.updateTask(task.id, task.asNetwork(),
                        ifMatchVersion = task.serverVersion)
                    taskDao.upsert(task.copy(serverVersion = saved.version,
                        syncState = SyncState.SYNCED))
                }
                SyncState.PENDING_DELETE -> {
                    api.deleteTask(task.id)
                    taskDao.hardDelete(task.id)
                }
                SyncState.SYNCED -> Unit
            }
        } catch (e: HttpException) {
            if (e.code() == 409) resolveConflict(task) else throw e
        }
    }
}

여기서 resolveConflict()는 앱의 정책을 담는 자리입니다. 서버 최신본을 받아 필드 단위로 병합할 수도, 사용자에게 선택을 맡길 수도, 단순히 서버 쪽을 채택할 수도 있어요. 중요한 건 충돌이 '조용히' 처리되지 않도록 정책을 명시적으로 정하는 것입니다.

🔁 멱등성: 같은 요청이 두 번 가도 괜찮게

모바일 네트워크에서는 "요청은 서버에 도착해 처리됐는데, 응답이 오는 길에 연결이 끊기는" 일이 실제로 일어납니다. 앱은 실패로 판단하고 재시도하겠죠. 그럼 같은 할 일이 두 개 생길 수 있습니다. 😱

멱등성은 서버 API 설계와 맞물려 있어서, 앱 개발자 혼자 해결할 수 없는 경우가 많습니다. 오프라인 퍼스트를 도입하기 전에 백엔드 팀과 ID 생성 주체, 버전 규칙, 삭제 표현 방식, 충돌 응답 코드를 먼저 합의해 두면 시행착오가 크게 줄어요.

📶 9. 네트워크 상태 감지: 알되, 의존하지 말 것

사용자에게 "오프라인입니다" 배너를 보여주려면 연결 상태를 알아야 합니다. 안드로이드에서는 ConnectivityManager의 NetworkCallback으로 상태 변화를 감지할 수 있어요. 예전의 CONNECTIVITY_ACTION 브로드캐스트 방식은 API 28에서 지원 중단(deprecated)되었으니 콜백 방식을 쓰는 것이 좋습니다.

class ConnectivityNetworkMonitor @Inject constructor(
    @ApplicationContext private val context: Context
) : NetworkMonitor {
    override val isOnline: Flow<Boolean> = callbackFlow {
        val cm = context.getSystemService(ConnectivityManager::class.java)
        val callback = object : ConnectivityManager.NetworkCallback() {
            private val networks = mutableSetOf<Network>()
            override fun onAvailable(network: Network) {
                networks += network; trySend(true)
            }
            override fun onLost(network: Network) {
                networks -= network; trySend(networks.isNotEmpty())
            }
        }
        val request = NetworkRequest.Builder()
            .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
            .build()
        cm.registerNetworkCallback(request, callback)
        trySend(cm.activeNetwork
            ?.let { cm.getNetworkCapabilities(it) }
            ?.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET) == true)
        awaitClose { cm.unregisterNetworkCallback(callback) }
    }.conflate()
}

이 코드는 ACCESS_NETWORK_STATE 권한이 필요합니다. 그리고 꼭 기억할 점이 있어요.

🧪 10. 테스트: 비행기 모드 버튼만 누르면 끝일까?

오프라인 퍼스트 앱의 버그는 대부분 타이밍과 상태 전이에서 나옵니다. "오프라인에서 생성 → 수정 → 삭제 → 온라인" 같은 시나리오는 손으로 재현하기 어렵기 때문에 자동화 테스트의 가치가 특히 큽니다.

@Test
fun 오프라인_수정은_대기상태로_저장된다() = runTest {
    val dao = FakeTaskDao(listOf(task(id = "1", state = SyncState.SYNCED)))
    val repo = OfflineFirstTaskRepository(dao, FailingTaskApi(), FakeSyncScheduler())

    repo.toggleDone("1", done = true)

    val saved = dao.getById("1")!!
    assertEquals(true, saved.done)
    assertEquals(SyncState.PENDING_UPDATE, saved.syncState)
}

🧳 마이그레이션 테스트도 잊지 말 것

오프라인 퍼스트 앱의 로컬 DB에는 아직 서버에 가지 않은 사용자 데이터가 들어 있습니다. 앱 업데이트 중 스키마 마이그레이션이 실패해 DB를 날리면, 그 데이터는 영원히 사라집니다. 그래서 fallbackToDestructiveMigration()은 오프라인 퍼스트 앱에선 특히 신중하게 써야 하고, Room의 MigrationTestHelper로 마이그레이션을 테스트하는 습관이 중요합니다. Room 2.4부터 제공되는 자동 마이그레이션(AutoMigration)은 컬럼 추가 같은 단순 변경을 편하게 처리해 주지만, 테이블·컬럼 이름 변경 같은 모호한 경우에는 명세(Spec)를 직접 지정해야 합니다.

🎨 11. UX 디자인: 사용자가 '안심'하게 만드는 신호들

기술적으로 완벽한 동기화도, 사용자가 이해하지 못하면 불안의 원인이 됩니다. "내가 쓴 거 저장된 거 맞아?"라는 질문에 화면이 답해 줘야 해요.

🔐 12. 보안·저장 공간·배터리: 숨은 운영 이슈

🔒 기기에 남는 데이터의 보안

오프라인 퍼스트는 정의상 더 많은 데이터를 더 오래 기기에 저장합니다. 기본적으로 앱 전용 내부 저장소의 데이터는 다른 앱이 접근할 수 없도록 샌드박스로 보호되고, 최신 안드로이드 기기는 저장소 암호화를 사용합니다. 그래도 의료·금융처럼 민감한 데이터라면 추가 조치를 검토하세요.

💾 저장 공간 관리

로컬 DB가 끝없이 커지면 결국 문제가 됩니다. 오래된 피드 데이터는 일정 기간·개수 기준으로 정리하고, 이미지 캐시는 용량 상한을 두며, 동기화가 끝난 아웃박스 행은 삭제합니다. 정리 작업도 WorkManager의 주기 작업으로 기기가 충전 중일 때(setRequiresCharging(true)) 돌리면 사용자 경험을 해치지 않습니다.

🔋 배터리를 아끼는 동기화

안드로이드는 도즈(Doze) 모드와 앱 대기 버킷(App Standby Buckets) 같은 장치로 백그라운드 작업을 제한합니다. WorkManager는 이런 시스템 정책을 존중하면서 작업을 실행하도록 설계되어 있으므로, 직접 알람이나 서비스를 돌리기보다 WorkManager에 맡기는 것이 배터리와 정책 준수 면에서 유리합니다. 또 변경을 하나하나 즉시 보내기보다 묶어서(batch) 보내는 것이 무선 모듈이 깨어나는 횟수를 줄여 배터리에 이롭습니다.

🧰 13. 실전 시나리오 세 가지

이론을 현장에 대입해 볼게요. 같은 오프라인 퍼스트라도 앱의 성격에 따라 설계 포인트가 달라집니다.

🧭 14. 도입 로드맵: 기존 앱을 오프라인 퍼스트로 바꾸려면

처음부터 새로 만드는 앱이 아니라면, 한 번에 모든 기능을 바꾸기보다 단계적으로 전환하는 편이 안전합니다.

이 과정은 앱 설계, 백엔드 API, UX 디자인이 한꺼번에 얽히는 작업이라 팀 구성이 작다면 부담이 될 수 있어요. 이럴 땐 재능넷 같은 재능 공유 플랫폼에서 안드로이드 아키텍처 경험이 있는 개발자나 모바일 UX 디자이너의 도움을 받아, 설계 리뷰나 특정 단계만 맡기는 방식도 현실적인 선택지가 됩니다.

✅ 15. 출시 전 셀프 체크리스트

오프라인 퍼스트는 단순한 '캐시 기능 추가'가 아니라, 데이터가 어디에 살고 어떻게 흘러가는지를 다시 설계하는 일입니다. 처음엔 메타데이터 컬럼 하나, 상태 전이 규칙 하나가 귀찮게 느껴지지만, 그 디테일이 쌓이면 지하철 터널 속에서도, 산꼭대기에서도 묵묵히 일하는 앱이 완성됩니다. 사용자는 그 노력을 눈치채지 못하겠지만, 바로 그게 성공의 증거예요. 🚇✨

📚 참고 자료

· Android Developers — Build an offline-first app: https://developer.android.com/topic/architecture/data-layer/offline-first
· Android Developers — Guide to app architecture: https://developer.android.com/topic/architecture
· Android Developers — Save data in a local database using Room: https://developer.android.com/training/data-storage/room
· Android Developers — WorkManager (Schedule tasks): https://developer.android.com/develop/background-work/background-tasks/persistent
· Android Developers — Page from network and database (Paging 3): https://developer.android.com/topic/libraries/architecture/paging/v3-network-db
· Android Developers — Monitor connectivity status: https://developer.android.com/training/basics/network-ops/reading-network-state
· GitHub — Now in Android 샘플 앱: https://github.com/android/nowinandroid
· Firebase — Access data offline (Cloud Firestore): https://firebase.google.com/docs/firestore/manage-data/enable-offline