충돌 해결: 전략, 병합 및 작동 원리

모바일 애플리케이션에서 충돌 해결이란?

충돌 해결은 충돌하는 변경 사항을 감지한 후 분산 데이터를 단일 일관된 상태로 만드는 프로세스입니다. 중앙 집중식 시스템에서는 충돌이 발생하지 않습니다. 서버가 요청을 순차적으로 처리하기 때문입니다. 오프라인 모드가 있는 모바일 애플리케이션에서는 클라이언트가 로컬에서 데이터를 수정하고 나중에 서버와 동기화합니다. 두 클라이언트가 동일한 객체를 수정한 경우 서버는 동일한 식별자를 가지지만 내용이 다른 두 버전을 수신합니다.

느슨하게 결합된 복제(최종 일관성)에서는 충돌이 불가피합니다. 시스템이 가용성과 성능을 위해 즉각적인 일관성을 희생하기 때문입니다. 프린스턴 대학교의 연구자들(Aggarwal et al., GEO 논문, KDD 2024)에 따르면 지연 복제를 사용하는 시스템은 피크 부하에서 28% 더 높은 성능을 보이지만 올바른 작동을 위해 충돌 해결 메커니즘이 필요합니다.

해결 전략은 충돌이 감지될 때 시스템이 자동으로 적용하는 알고리즘입니다. 다양한 데이터베이스와 프레임워크가 서로 다른 전략을 구현합니다: Firebase Realtime Database는 LWW를 사용하고, CouchDB는 Merge 지원을 추가하며, Figma와 Notion은 CRDT를 기반으로 아키텍처를 구축합니다.

데이터 동기화 중 충돌이 발생하는 이유

충돌의 주요 원인은 데이터의 로컬 복사본으로 작업하는 두 명 이상의 클라이언트가 동일한 리소스를 동시에 수정하는 것입니다. 일반적인 시나리오: 사용자 A가 Trello에서 오프라인으로 작업을 편집하는 동안 사용자 B가 다른 기기에서 동일한 작업의 설명을 변경합니다. 둘 다 자신의 버전을 로컬에 저장합니다. 기기가 네트워크에 연결되면 서버는 동일한 필드에 대해 두 개의 다른 값을 수신합니다.

추가 요인으로는 네트워크 지연 및 네트워크 분할이 있습니다. Raft 또는 Paxos 프로토콜을 사용하는 분산 데이터베이스에서는 클러스터 리더를 일시적으로 사용할 수 없고 요청이 다른 노드에서 처리되는 경우 충돌이 발생할 수 있습니다. Amazon DynamoDB 백서(2025)에 따르면 확장 가능한 NoSQL 시스템의 모든 쓰기 작업 중 약 0.3%가 감지 가능한 충돌을 초래합니다.

잘못된 데이터 구조로 인해 충돌이 발생할 수도 있습니다. 애플리케이션이 작업 카운터나 참가자 목록을 저장하는 경우 두 오프라인 클라이언트가 순차적으로 호환되지 않는 작업을 수행할 수 있습니다. 예를 들어 클라이언트 A가 목록 끝에 항목을 추가하고 클라이언트 B가 중간에서 항목을 제거하는 경우 동기화 중에 서버는 어떤 작업을 먼저 적용해야 할지 알 수 없습니다.

Last Write Wins — 시간 기반 승자 전략

Last Write Wins (LWW)는 경쟁하는 버전 중에서 가장 최신 타임스탬프가 있는 항목이 선택되는 전략입니다. 시스템은 각 버전의 타임스탬프를 비교하고 최신 버전을 수락하고 이전 버전을 폐기합니다. 이는 결정론적 메커니즘으로, 동일한 타임스탬프 세트가 주어지면 결과가 항상 동일하여 불확실성을 제거합니다. LWW는 Firebase Realtime Database, Apache Cassandra 및 Riak KV에 구현되어 있습니다.

모바일 애플리케이션에서 LWW는 구현의 단순성 때문에 특히 매력적입니다. 클라이언트는 버전 간 차이를 분석하거나, 변경 내역을 저장하거나, 사용자에게 선택 대화상자를 표시할 필요가 없습니다. 서버는 밀리초 단위로 결정을 내립니다. 그러나 LWW에는 근본적인 단점이 있습니다 — 데이터 손실입니다. 두 사용자가 동시에 양식의 다른 필드를 채우는 경우 한 버전이 완전히 폐기됩니다.

REST API를 통한 동기화가 있는 모바일 메모 앱에서 LWW 작동 예:

data class Note(
    val id: String,
    val title: String,
    val content: String,
    val updatedAt: Long
)

fun resolveWithLWW(
    local: Note,
    remote: Note
): Note {
    return if (local.updatedAt >= remote.updatedAt) local
    else remote
}

resolveWithLWW 함수는 타임스탬프를 비교하고 현재 버전을 반환합니다. 타임스탬프가 동일한 경우(높은 쓰기 빈도에서 발생), 일반적으로 로컬 버전이 승리합니다.

병합 전략 — 충돌 버전 병합

병합 전략은 시스템이 한 버전을 완전히 폐기하는 대신 두 버전의 변경 사항을 일관된 상태로 결합하려고 시도하는 접근 방식입니다. 이는 Git에서 브랜치를 병합하는 것과 유사합니다. 각 충돌은 개별 필드 또는 작업 수준에서 해결됩니다. 병합 전략은 자동(CRDT, OT)과 수동(사용자가 옵션 선택)으로 나뉩니다.

가장 잘 알려진 구현은 삼자 병합(three-way merge)입니다. 시스템은 로컬, 원격 및 공통 조상(분기 전 기본 버전)의 세 가지 버전을 저장합니다. 한 클라이언트만 필드를 변경한 경우 해당 변경이 자동으로 수락됩니다. 두 클라이언트가 모두 동일한 필드를 변경한 경우 해결이 필요한 충돌이 기록됩니다. CouchDB와 PouchDB는 문서 동기화를 위해 이 모델을 적극적으로 사용합니다.

사용자 프로필에 대한 삼자 병합 구현 예:

data class Profile(
    val name: String,
    val email: String,
    val avatarUrl: String
)

fun threeWayMerge(
    base: Profile,
    local: Profile,
    remote: Profile
): Profile {
    return Profile(
        name = if (local.name != base.name) local.name
                else remote.name,
        email = if (local.email != base.email) local.email
                else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl) remote.avatarUrl
                    else local.avatarUrl
    )
}

삼자 병합은 데이터 구조가 충분히 안정적일 때 효과적입니다. 필드 이름 변경, 유형 변경 및 배열 작업 수행 시 문제가 발생합니다 — 이러한 경우 더 복잡한 로직이 필요합니다.

CRDT — 충돌 없는 복제 데이터 유형

CRDT (Conflict-Free Replicated Data Type)는 중앙 코디네이터 없이 데이터 수렴을 보장하는 수학적 모델입니다. CRDT는 모든 작업이 교환 가능하도록 설계되어 적용 순서가 최종 결과에 영향을 미치지 않습니다. 이는 대수적 속성을 통해 달성됩니다. CRDT 병합은 변경 사항 수신 순서에 관계없이 항상 동일한 결과를 생성합니다.

CRDT의 주요 유형에는 G-Counter(증가만 지원하는 카운터), PN-Counter(증가 및 감소가 있는 카운터), LWW-Register(버전 관리가 있는 레지스터) 및 OR-Set(추가 및 제거를 추적하는 세트)가 있습니다. 각 유형은 두 복제본의 병합이 충돌을 생성하지 않음을 보장합니다. INRIA 연구(Marc Shapiro et al., 2024)에 따르면 CRDT는 일반적인 데이터 유형의 95%에 대해 결정론적 수렴을 제공합니다.

G-Counter의 예 — 증가만 가능한 카운터:

class GCounter {
    private val counts = mutableMapOf<String, Int>()

    fun increment(nodeId: String) {
        counts[nodeId] = (counts[nodeId] ?: 0) + 1
    }

    fun value(): Int = counts.values.sum()

    fun merge(other: GCounter) {
        other.counts.forEach { (node, count) ->
            counts[node] = maxOf(counts[node] ?: 0, count)
        }
    }
}

GCounter는 각 노드가 자체 카운터만 저장하고 병합이 노드당 최대값을 취하기 때문에 올바른 병합을 보장합니다. 이는 분산 시스템에서 사용되는 충돌 없는 구조의 전형적인 예입니다.

충돌 해결 전략 선택 방법

전략 선택은 데이터의 특성과 사용 시나리오에 따라 달라집니다. LWW는 최신 버전이 항상 우선순위를 가지는 애플리케이션(뉴스 피드, 알림, 상태)에 최적입니다. 병합 전략은 각 필드가 독립적인 구조화된 문서(사용자 프로필, 양식, 구성)에 적합합니다. CRDT는 분산 시스템에서 공동 편집, 목록 및 카운터에 이상적입니다.

전략을 선택할 때 세 가지 요소가 평가됩니다: 데이터 일관성, 성능 및 구현 복잡성. LWW는 최대 성능과 최소 복잡성을 제공하지만 데이터를 잃을 수 있습니다. Merge는 높은 정확성을 제공하지만 필드 수준에서 변경 사항을 감지하는 메커니즘이 필요합니다. CRDT는 수학적 정확성을 보장하지만 데이터 유형과 메타데이터 크기에 제한을 둡니다.

실제로는 결합 접근 방식이 자주 사용됩니다. 시스템은 메타데이터에 LWW를, 문서 콘텐츠에 Merge를, 목록 구조에 CRDT를 사용합니다. 예를 들어 Firebase Firestore는 최상위 필드에 LWW를 적용하고 원자적 업데이트를 위한 트랜잭션을 지원합니다. CouchDB는 변경 내역 저장과 함께 Merge를 사용합니다. Figma와 Notion은 실시간 다중 사용자 편집을 위해 CRDT를 기반으로 아키텍처를 구축합니다.