오프라인 편집을 여러 기기에서 합치려면 CRDT만으로 충분할까?

CRDT(충돌 없는 복제 데이터 타입)는 여러 복제본이 독립적으로 수정된 뒤, 같은 업데이트를 받으면 같은 상태로 수렴하도록 설계하는 데이터 구조 계열입니다. 이는 애플리케이션 전체가 자동으로 오프라인 동기화·개인정보 보호·데이터 소유권을 보장한다는 뜻은 아닙니다. Shapiro 외, CRDT 논문

구조를 고를 때 먼저 정할 것

  • 1. 병합할 데이터 의미를 정의합니다. 장바구니 수량처럼 합산 가능한 값, 여러 사람이 추가·삭제하는 태그 목록, 한 문서 속 문장 편집은 서로 다른 충돌 규칙이 필요합니다. “마지막 수정이 이긴다”가 맞는지, 삭제와 동시 수정이 어떻게 되어야 하는지 제품 요구를 먼저 적습니다.
  • 2. 상태 기반(CvRDT)과 연산 기반(CmRDT) 방식 중 데이터 흐름에 맞는 것을 고릅니다. 2011년 논문은 상태 병합에 필요한 반격자 단조성 조건과, 연산 기반 수렴에 필요한 동시 연산의 가환성 조건을 구분합니다. 전자는 상태를 교환·병합하고, 후자는 연산 전달 전제와 메시지 처리 조건이 중요합니다. 이름만 보고 둘이 같은 구현이라고 취급하지 마세요.
  • 3. 재접속·중복·순서 변경을 시험합니다. 두 기기에서 동시에 목록 항목을 추가하고, 한쪽은 다른 항목을 완료 처리한 뒤 네트워크를 끊었다가 복구합니다. 같은 변경을 여러 번 전달하거나 다른 순서로 도착시켜도 원하는 최종 상태인지 검사합니다.
  • 4. 동시 변경이 같은 필드에 겹칠 때 사용자 경험을 정합니다. Ink & Switch의 Automerge 사례는 서로 다른 항목 변경은 자동 병합할 수 있지만, 동일 객체의 동일 속성을 동시에 바꾼 충돌은 앱이나 사용자가 선택해야 할 수 있다고 설명합니다. “conflict-free”는 모든 의미상 충돌이 사라진다는 약속이 아닙니다.

예: 오프라인 할 일 목록

기기 A와 B가 같은 목록을 동기화했다고 가정합니다. 연결이 끊긴 동안 A는 “장보기”를 추가하고 B는 “세탁”을 완료 처리합니다. 서로 다른 데이터 항목을 조작했다면 CRDT가 두 변경을 보존해 합칠 수 있습니다. 반면 두 기기가 같은 작업 제목을 서로 다르게 고쳤다면, 앱이 하나를 자동 선택할지, 두 버전을 보여 줄지, 사용자에게 선택을 맡길지 정해야 합니다. 선택은 작업의 의미에 따라 달라집니다.

CRDT 바깥에서 구현해야 할 부분

CRDT 자료형은 복제·병합 규칙을 제공하지만 네트워크 전송, 피어 발견, 인증·권한, 암호화, 데이터 저장, 백업, 버전 호환, 사용자 계정 복구를 자동으로 해결하지 않습니다. Ink & Switch는 CRDT가 동기화 네트워크 자체를 규정하지 않으며, 로컬 우선의 이상을 완전히 실현한다고 주장하지 않는다고 밝힙니다. 변경 이력의 크기와 정리 가능 시점도 메모리·저장소 설계에서 따로 다뤄야 합니다.

출처