Sync Engine: 주요 개념, 유형 및 작동 메커니즘

싱크 엔진이란?

Sync Engine — 로컬 데이터베이스와 원격 API 사이의 아키텍처 계층으로, 양방향 데이터 흐름을 관리합니다. 작업 내용: 변경 사항 추적, 서버로 전송, 서버 변경 사항 수신 및 충돌 해결입니다. 사용자는 로컬 데이터와 상호 작용하고 Sync Engine은 이를 서버와 원활하게 동기화합니다.

Sync Engine은 내장형(Firebase Firestore, Couchbase Lite, Realm) 또는 사용자 정의형 — 특정 비즈니스 로직에 맞게 작성될 수 있습니다. 내장형 엔진은 즉시 사용 가능한 offline-first 기능과 충돌 해결을 제공합니다. 사용자 정의형 엔진은 데이터 형식, 동기화 프로토콜 및 충돌 정책을 완전히 제어할 수 있습니다.

Sravana Karthik (2024) — 「Mobile Sync Engine Design Patterns」의 저자에 따르면, 사용자 정의 Sync Engine은 복잡한 비즈니스 로직(금융, 의료, IoT)이 있는 앱에 적합하며, 사용자 정의 병합 규칙이 중요합니다. 일반적인 시나리오(메모, 채팅, 피드)의 경우 내장형 Firestore 또는 Realm으로 충분합니다.

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

이 인터페이스는 Sync Engine의 최소 계약을 설명합니다: pull(서버 변경 사항 로드), push(로컬 변경 사항 전송), resolve(충돌 처리) 및 observe(동기화 상태 모니터링). 이 추상화를 통해 프레젠테이션 계층을 수정하지 않고 구현을 변경할 수 있습니다.

동기화 유형: 전체, 증분 및 푸시

전체 동기화(Full sync) — 각 세션마다 서버에서 전체 데이터 세트를 로드합니다. 구현은 간단하지만 대용량에는 부적합합니다: 앱을 열 때마다 10,000개의 레코드를 다운로드하면 트래픽과 배터리를 소모합니다. 전체 동기화는 업데이트가 드문 참조 데이터(국가 목록)에 적합합니다.

증분 동기화 — 마지막 동기화 이후 변경된 레코드만 전송됩니다. 서버는 각 레코드 또는 전체 세트의 마지막 변경 타임스탬프를 저장합니다. 클라이언트는 lastSyncTimestamp를 보내고 updated_at > 해당 값인 레코드만 수신합니다. Instagram Engineering (2024)에 따르면, 증분 동기화는 전체 동기화에 비해 데이터 전송량을 97% 줄입니다.

푸시 동기화(서버 시작) — 서버 자체가 FCM(Firebase Cloud Messaging), WebSocket 또는 SSE(Server-Sent Events)를 통해 클라이언트에 동기화 필요성을 알립니다. 클라이언트는 정기적인 폴링에 리소스를 낭비하지 않습니다. 푸시 동기화는 실시간 앱(채팅, 알림, 좋아요)에 최적의 선택입니다. Google Firebase Firestore는 HTTP Polling으로 자동 폴백되는 WebSocket을 통한 실시간 동기화를 사용합니다.

하이브리드 접근 방식 — 유형의 조합: 앱 시작 시 기본 데이터에 대한 전체 동기화, 업데이트에 대한 증분 동기화, 중요 이벤트에 대한 FCM을 통한 푸시 동기화입니다. 이를 통해 속도와 리소스 절약을 모두 얻을 수 있습니다.

증분 동기화 — 체크포인트와 델타 작동 방식

체크포인트(Checkpoint) — 클라이언트가 동기화 세션 간에 저장하는 값입니다. 일반적으로 마지막으로 성공적으로 동기화된 레코드의 updated_at입니다. 다음 동기화에서 클라이언트는 체크포인트를 서버에 보내고 서버는 체크포인트 이후의 updated_at이 있는 모든 레코드를 반환합니다. 커서 기반 페이지네이션 — 서버가 데이터와 함께 커서(다음 페이지에 대한 포인터)를 반환하는 고급 버전입니다.

델타 동기화 — 서버가 현재 데이터 상태와 클라이언트가 마지막으로 본 스냅샷 간의 차이를 계산합니다. 모든 레코드를 보내는 대신 작업(insert, update, delete)만 전송됩니다. 이는 몇 개의 레코드만 변경된 대규모 데이터 세트에 특히 효과적입니다. Google Drive API(2025)는 파일 델타 동기화를 위해 pageToken과 함께 changes.list를 사용합니다.

«지연 델타» 전략 — 모바일 클라이언트에서 변경 사항은 즉시 전송되지 않고 오프라인 큐에 버퍼링됩니다. 임계값(10개 작업 또는 30초)에 도달하면 델타 패킷이 생성되어 서버로 전송됩니다. Dropbox Mobile Engineering (2024)에 따르면, 델타 배치 처리로 HTTP 요청 수가 65% 감소하고 배터리 소모가 12% 감소했습니다.

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

SyncCheckpoint는 긴 목록을 위해 타임스탬프와 페이지네이션 커서를 모두 저장합니다. 이중 매개변수 체크포인트는 큰 데이터 세트를 동기화할 때 레코드가 누락되거나 중복되지 않도록 보장합니다.

푸시 동기화 — WebSocket 및 FCM을 통한 즉시 동기화

WebSocket — 클라이언트와 서버 간 지속적인 양방향 연결입니다. 서버는 데이터가 변경되면 즉시 업데이트를 보냅니다. WebSocket은 실시간 앱(채팅, 스트리밍, 협업)에 최적입니다. 단점: 연결 유지(하트비트)를 위한 배터리 및 트래픽 소모. Android의 OkHttp WebSocket과 iOS의 URLSessionWebSocketTask — 내장 구현입니다.

Firebase Cloud Messaging (FCM) — 서버가 사용자에게 표시하기 위해가 아니라 동기화를 트리거하기 위해 보내는 푸시 알림입니다. 사일런트 푸시(데이터 메시지)를 수신하면 앱이 깨어나 Sync Engine을 시작합니다. FCM은 영구 연결이 필요하지 않으며 드문 알림의 경우 WebSocket보다 경제적입니다.

SSE (Server-Sent Events) — 서버가 클라이언트에 이벤트를 보내는 단방향 채널입니다. WebSocket보다 구현이 간단하지만 양방향 통신을 지원하지 않습니다. EventSource API(JavaScript) 및 OkHttp SSE(Android) — 인기 있는 라이브러리입니다. SSE는 클라이언트가 동일한 채널을 통해 데이터를 다시 보낼 필요가 없을 때 새 데이터에 대한 알림에 적합합니다.

WhatsApp Engineering (2024)에 따르면, 그들의 Sync Engine은 활성 세션에 WebSocket을 사용하고 백그라운드에서 앱을 깨우는 데 FCM을 조합하여 사용합니다. WebSocket은 5분 동안 비활성 상태이면 연결이 끊어지고 이후 업데이트는 사일런트 푸시를 통해 전달됩니다.

스냅샷 동기화 및 데이터 버전 관리

스냅샷 기반 동기화 — 서버가 주기적으로 전체 데이터 스냅샷을 생성하고 버전을 할당합니다. 클라이언트는 현재 버전 번호를 저장합니다. 오래된 경우 새 스냅샷을 다운로드합니다. 이는 간단하고 안정적인 전략이지만 빈번한 변경에는 비효율적입니다 — 매번 전체 데이터 세트가 다운로드됩니다.

레코드별 버전 관리 — 각 레코드에는 version 필드가 있습니다. 동기화 중에 클라이언트는 모든 레코드의 버전을 보내고 서버는 버전이 변경된 레코드만 반환합니다. 이는 스냅샷 동기화보다 효율적이지만 클라이언트에 버전을 저장해야 합니다. 벡터 클록(Vector Clocks) — 분산 시스템을 위한 고급 기술로, 각 노드가 자체 버전을 할당하고 충돌이 부분 순서로 해결됩니다.

증분 diff가 있는 스냅샷 — 하이브리드 접근 방식: 드문 전체 스냅샷(하루 1회) + 그 사이의 증분 동기화입니다. 오랜 부재 후 시작 시 클라이언트는 스냅샷을 로드하고 빈번한 동기화 중에는 델타만 로드합니다. Git과 유사한 접근 방식 — 각 데이터 커밋에는 해시가 있으며 클라이언트는 어떤 커밋에서 시작해야 하는지 알고 있습니다. 이는 Couchbase Lite Sync Gateway(2024)에서 구현되었으며 안정성의 표준입니다.

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

버전 해결 규칙: 버전이 일치하면 변경 사항이 없습니다. 로컬 버전이 최신이면 로컬이 승리합니다. 서버 버전이 최신이면 서버가 승리합니다. 버전이 같지만 데이터가 다른 경우에만 충돌 해결사가 호출됩니다. 버전 플래그가 있는 Last Write Wins — 가장 간단하지만 안정적인 전략입니다.

모바일 앱용 Sync Engine 구축 방법

1단계: 데이터 모델 정의 — 어떤 엔터티가 동기화되는지, 얼마나 자주 변경되는지, 볼륨은 얼마인지 확인합니다. 각 엔터티에 대해 전략(증분 / 전체 / 푸시)과 허용 가능한 동기화 지연 시간을 결정합니다.

2단계: 프로토콜 선택 — 체크포인트가 있는 REST, Subscriptions가 있는 GraphQL 또는 양방향 스트림이 있는 gRPC. GraphQL Subscriptions — 최신 앱을 위한 인기 있는 선택: pull과 push 모두에 하나의 프로토콜. Apollo Client(2025)는 기기 캐시를 통한 오프라인 동기화를 지원합니다.

3단계: 오프라인 큐 구현 — 멱등성 키가 있는 로컬 변경 저장소(기사 «Offline Queue» 참조). 큐는 안정적인 Sync Engine의 기초입니다: 이것 없이는 동기화가 변경 전달을 보장하지 않습니다.

4단계: 충돌 해결사 선택 — 간단한 경우 LWW, 공동 편집을 위한 CRDT, 비즈니스 로직을 위한 사용자 정의 병합. 규칙: 해결사는 멱등성이 있어야 합니다 — 동일한 작업을 다시 적용하면 동일한 결과가 나와야 합니다.

5단계: 모니터링 및 메트릭스 — 각 동기화를 기록: 레코드 수, 실행 시간, 충돌 수, 오류. Firebase Crashlytics 또는 Sentry(2025)를 통해 실시간으로 동기화 오류를 추적할 수 있습니다.

Realm Team (2024)에 따르면, 일반적인 모바일 앱 Sync Engine은 기기당 하루 100–500회의 동기화를 처리하며 세션당 평균 50–200KB의 데이터를 전송합니다. 프로토콜 최적화 — JSON 대신 Protobuf 압축 사용 — 데이터 전송량을 40–60% 추가로 줄입니다.