현장 앱에서 오프라인으로 작업 내용을 고친 뒤 연결이 돌아왔습니다. 그 사이 사무실 사용자가 같은 기록을 수정했다면 어느 쪽이 최신일까요? 단순히 마지막 전송 시각으로 덮어쓰면 중요한 메모가 사라질 수 있습니다. 충돌을 감지하고 업무 기준으로 해결해야 합니다.
기록의 기준 버전을 남긴다
오프라인 수정이 시작될 때 서버 기록의 버전을 함께 저장합니다. 동기화 때 서버 버전이 달라졌다면 같은 내용을 덮어쓰지 않고 충돌로 표시합니다.
기기 시계가 정확하지 않을 수 있으므로 클라이언트의 수정 시각만으로 승자를 정하지 않습니다. 서버 버전과 작업 ID가 더 안정된 비교 기준입니다.
필드별로 합칠 수 있는지 판단한다
서로 다른 필드를 바꿨다면 자동 병합이 가능할 수 있지만 같은 상태 값을 다르게 바꿨다면 사람이 판단해야 할 수 있습니다. 사진 추가와 작업 완료 상태 변경도 성격이 다릅니다.
무조건 필드 단위 병합하면 전체 업무 규칙이 깨질 수 있습니다. 예를 들어 '취소' 상태와 이후 사진 추가가 동시에 허용되는지 확인해야 합니다.
사용자에게 차이를 보여 준다
오프라인 변경과 서버의 현재 값을 나란히 보여 주고 각 변경자와 시각, 근거를 표시합니다. '동기화 실패'만 보여 주면 사용자는 어떤 내용을 잃는지 알 수 없습니다.
사용자가 다시 작성하지 않도록 로컬 초안을 보존합니다. 충돌을 해결하는 동안 다른 기기에서 또 변경될 수 있어 최종 저장 때 버전을 다시 확인합니다.
가상 사례: 점검 메모와 완료 상태
기술자가 오프라인에서 고장 메모를 보충했고 사무실 담당자가 같은 점검을 완료로 표시했다고 가정해 봅시다. 메모는 합칠 수 있어도 완료 상태를 유지할지 재검토할지는 업무 규칙이 필요합니다.
두 변경을 모두 기록하고 담당자에게 차이를 보여 줍니다. 이 사례는 오프라인 동기화의 가상 상황입니다.
동기화 상태를 분명히 한다
기기에만 저장됨, 서버 전송 중, 충돌 대기, 서버 반영 완료를 구분합니다. 서버가 확인하기 전에는 완료라고 표시하지 않습니다.
앱 종료와 저장 공간 부족, 계정 전환 시 로컬 데이터가 어떻게 보호되는지도 시험합니다. 오프라인 지원은 단순 캐시가 아니라 데이터 수명 관리입니다.
현장에 적용할 때의 순서
- 로컬 수정의 서버 버전을 저장한다
- 동기화 때 충돌을 비교한다
- 사용자에게 두 변경을 보여 준다
주의할 실패: 기기의 수정 시각만 믿고 최신이라고 덮어쓰면 다른 사용자의 작업이 사라질 수 있다.
관찰할 지표: 충돌 유형과 보존된 초안의 재사용 비율을 확인한다.
적용 전 체크리스트
- 수정 시작 당시 서버 버전을 저장하는가
- 충돌 시 두 변경 내용을 모두 보존하는가
- 서버 반영 전 완료 상태로 오인시키지 않는가
참고 자료
MDN IndexedDB API. MDN은 브라우저 로컬 데이터 저장 API를 설명합니다. 충돌 해결과 동기화 상태는 애플리케이션에서 따로 설계해야 합니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#오프라인앱 #동기화충돌 #모바일앱 #IndexedDB #현장앱 #데이터정합성 #버전관리 #사용자경험 #앱아키텍처 #재시도
