모바일 개발의 캐시 및 데이터 동기화: 개념, 전략 및 작동 방식

모바일 애플리케이션의 데이터 처리: Repository 패턴 및 Data Source

Repository 패턴은 단일 리포지토리 클래스가 모든 데이터 작업을 관리하고 원격 REST API 및 로컬 저장소(Room 또는 SwiftData)를 추상화하는 아키텍처 접근 방식입니다. 이 데이터 처리 방식은 애플리케이션이 먼저 Memory Cache 또는 Disk Cache에서 정보를 검색한 다음 네트워크에서 검색하여 응답 시간을 단축할 수 있게 합니다. 모바일 개발에서 Repository는 Google과 Apple의 권장 사항 덕분에 사실상의 표준이 되었습니다.

Remote Data Source 및 Local Data Source

Remote Data Source는 HTTP 요청을 통해 서버에서 최신 정보를 제공합니다. Local Data Source는 장치의 로컬 저장소로, Android에서는 Room, iOS에서는 SwiftData를 통해 구현됩니다. 리포지토리는 두 소스를 결합합니다: 먼저 로컬 캐시를 확인하고 데이터가 없으면 원격 API에 요청합니다. 이러한 데이터 처리 구성은 애플리케이션이 오프라인 모드에서 작동할 수 있게 하고 서버 부하를 줄입니다.

Kotlin의 Repository 예제

class UserRepository(
    private val remoteDataSource: UserRemoteDataSource,
    private val localDataSource: UserLocalDataSource
) {
    suspend fun getUsers(): List<User> {
        localDataSource.getCachedUsers()?.let { return it }
        val users = remoteDataSource.fetchUsers()
        localDataSource.cacheUsers(users)
        return users
    }
}

Swift의 Repository 예제

class UserRepository {
    private let remote: UserRemoteDataSource
    private let local: UserLocalDataSource
    
    func getUsers() async throws -> [User] {
        if let cached = await local.getCached() { return cached }
        let users = try await remote.fetch()
        await local.save(users)
        return users
    }
}

데이터 캐싱: LRU Cache, Disk Cache 및 Memory Cache

LRU Cache(Least Recently Used)는 제한에 도달하면 가장 오랫동안 액세스되지 않은 요소를 제거하는 캐싱 알고리즘입니다. 모바일 애플리케이션에서 LRU Cache는 이미지, API 응답 및 직렬화된 객체에 사용됩니다. 적절한 데이터 캐싱은 네트워크 요청 수를 줄이고 콘텐츠 로딩 속도를 높입니다. 모바일 애플리케이션의 캐시는 높은 성능을 위한 필수 구성 요소입니다.

Memory Cache vs Disk Cache

Memory Cache는 RAM에 데이터를 저장합니다 — 액세스가 매우 빠르지만 용량은 애플리케이션의 힙 크기로 제한됩니다. Disk Cache는 파일 시스템에 정보를 저장합니다 — 느리지만 더 많은 데이터를 보유할 수 있고 세션 간에 유지됩니다. 모바일 개발의 최적 전략은 2계층 캐시입니다: 핫 데이터용 Memory Cache와 콜드 데이터용 Disk Cache입니다. 데이터를 처리할 때 먼저 메모리의 1계층 캐시를 확인한 다음 디스크의 2계층 캐시를 확인합니다.

LRU Cache 구현 예제

class MemoryCache<K, V>(
    private val maxSize: Int = 100
) {
    private val cache = LinkedHashMap<K, V>(0, 0.75f, true)

    fun get(key: K): V? = cache[key]

    fun put(key: K, value: V) {
        if (cache.size >= maxSize) {
            cache.remove(cache.keys.first())
        }
        cache[key] = value
    }
}

캐시 무효화 전략

TTL 캐시(Time To Live)는 지정된 시간 간격 후에 자동으로 항목을 제거합니다 — API 데이터에 적합합니다. 이벤트 기반 무효화는 변경 사항에 대한 푸시 알림을 수신할 때 캐시를 지웁니다. 모바일 애플리케이션에서 캐싱 전략의 선택은 데이터 유형에 따라 다릅니다: 이미지는 오래 캐시되는 반면 뉴스 피드는 빈번한 무효화가 필요합니다. Android의 Coil과 iOS의 Kingfisher는 이미 이미지 작업을 위해 LRU Cache를 내장하고 있습니다.

오프라인 큐: Offline Queue 및 Sync Manager

Offline Queue는 장치가 오프라인일 때 사용자 작업(생성, 업데이트, 삭제)을 로컬 데이터베이스에 저장하는 데이터 구조입니다. 연결이 복원되면 Sync Manager가 이러한 작업을 서버에 순차적으로 적용합니다. 이러한 유형의 데이터 동기화는 일시적인 네트워크 손실 중에 변경 사항이 손실되지 않도록 보장합니다. 모바일 개발에서 Offline Queue는 불안정한 연결을 가진 애플리케이션의 중요한 구성 요소입니다.

Offline Queue 아키텍처

큐는 Room 또는 SwiftData의 테이블 위에 구축되며 필드는 다음과 같습니다: 작업 유형, JSON 요청 본문, 타임스탬프 및 상태. Sync Manager는 보류 중인 작업을 처리하고 서버에 전송하며 상태를 업데이트하고 성공한 항목을 제거하는 백그라운드 서비스입니다. Android의 WorkManager 또는 iOS의 BGTaskScheduler를 통한 데이터 동기화는 장치 재부팅 후에도 계속됩니다. 적절한 데이터 처리와 Offline Queue를 함께 사용하면 원활한 사용자 경험이 보장됩니다.

Kotlin의 Offline Queue 예제

@Entity
data class SyncOperation(
    @PrimaryKey val id: Long,
    val endpoint: String,
    val method: String,
    val body: String,
    val createdAt: Long
)

class SyncManager(
    private val dao: SyncOperationDao,
    private val api: ApiService
) {
    suspend fun syncPending() {
        dao.getPendingOperations().forEach { op ->
            try {
                api.execute(op.endpoint, op.method, op.body)
                dao.delete(op.id)
            } catch (e: Exception) {
                // retry on next cycle
            }
        }
    }
}

재시도 정책 및 타임아웃

재시도 간 지수 백오프(1초, 2초, 4초, 8초)는 서버를 과부하로부터 보호하고 무한 재시도를 방지합니다. 5회 시도 제한은 큐 오버플로를 방지합니다. 서버 측 멱등성 지원이 있는 모바일 애플리케이션의 데이터 동기화는 중복을 피하면서 안전한 재시도를 허용합니다. 이는 금융 거래 및 주문에 특히 중요합니다.

데이터 동기화: Conflict Resolution 및 Schema Migration

Conflict Resolution은 동일한 데이터가 여러 장치에서 동시에 수정되는 상황을 위한 전략 집합입니다. 기본 데이터 동기화는 접근 방식을 선택해야 합니다: Last-Write-Wins(마지막 쓰기가 승리), 버전 관리(더 높은 버전이 승리) 또는 수동 해결입니다. 복잡한 시나리오에서는 데이터의 수학적 수렴을 보장하는 CRDT(Conflict-Free Replicated Data Types)가 사용됩니다.

충돌 해결 전략

Last-Write-Wins는 구현이 가장 간단하지만 사용자 변경 사항을 잃을 수 있습니다. Version Vector — 각 레코드는 버전 번호와 장치 식별자를 저장하며, 버전이 일치하지 않으면 충돌이 발생합니다. CRDT는 가장 안정적이지만 복잡한 전략입니다: 데이터는 중앙 조정자 없이 수학적으로 단일 상태로 수렴합니다. CRDT 기반 모바일 애플리케이션의 데이터 동기화는 Google Docs의 공동 편집 및 Notion 노트 동기화에 사용됩니다.

Schema Migration: 안전한 데이터베이스 업데이트

애플리케이션이 업데이트되면 로컬 데이터베이스 구조가 변경됩니다: 열, 테이블, 인덱스가 추가됩니다. Schema Migration은 데이터 손실 없이 기존 데이터베이스를 새 스키마로 변환하는 프로세스입니다. Room은 이전 및 새 버전의 Migration 클래스를 통해 마이그레이션을 지원합니다. SwiftData는 변경 사항을 설명하기 위해 VersionedSchema를 사용합니다. 애플리케이션 버전 간의 적절한 데이터 동기화를 위해서는 마이그레이션이 멱등적으로 테스트되어야 합니다.

Room의 Schema Migration 예제

val migration1to2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE users ADD COLUMN avatar_url TEXT")
    }
}

@Database(
    entities = [User::class],
    version = 2
)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Swift의 Conflict Resolution 예제

enum ConflictStrategy {
    case lastWriteWins
    case versionVector
    case crdt
}

struct VersionedDocument {
    let id: String
    let version: Int
    let data: Data
    let editedBy: String
    
    func resolve(with remote: VersionedDocument) -> VersionedDocument {
        return version >= remote.version ? self : remote
    }
}

로컬 저장소를 위한 Room 및 SwiftData

Room은 Android용 Google의 로컬 저장소 라이브러리로, SQLite 위에 구축되었으며 선언적 쿼리 설명을 위한 어노테이션을 제공합니다. SwiftData는 간결한 Swift Macro 구문을 가진 Core Data의 후속 제품으로, iOS, macOS, watchOS 및 visionOS용 Apple 프레임워크입니다. 두 도구 모두 장치에서 데이터 처리 작업을 해결하지만 코드 구성에 대한 접근 방식이 다릅니다. 모바일 애플리케이션의 캐시는 종종 이러한 기술 위에 구축됩니다.

Room: DAO, Entities 및 Type Converters

Room은 테이블에 @Entity 어노테이션을, 쿼리에 @Dao를 사용합니다. DAO는 컴파일 타임 검사로 모든 SQL 작업을 캡슐화하여 SQL 구문 오류가 런타임 전에 감지됩니다. Type Converter는 복합 유형(Date, List)을 SQLite 기본 유형으로 변환합니다. Android 애플리케이션의 현대적인 데이터 처리는 Room + Flow를 중심으로 구축되어 캐시 또는 로컬 데이터베이스 변경 시 반응형 UI 업데이트를 제공합니다.

SwiftData: @Model 및 @Query

SwiftData는 엔터티를 정의하기 위해 매크로 @Model을, 데이터를 관찰하기 위해 @Query를 사용합니다. 프레임워크는 자동으로 종속성을 추적하고 변경 시 인터페이스를 업데이트합니다. 스키마 마이그레이션은 모든 버전을 설명하는 VersionedSchema를 사용합니다. SwiftData와 서버 간의 데이터 동기화는 @Query를 통해 업데이트를 구독하는 사용자 정의 Sync Manager를 통해 구현됩니다.

SwiftData 모델 예제

@Model
final class UserModel {
    var id: String
    var name: String
    var email: String
    var updatedAt: Date
    
    init(id: String, name: String, email: String) {
        self.id = id
        self.name = name
        self.email = email
        self.updatedAt = Date()
    }
}

Room vs SwiftData 비교