오프라인 편집 UX: 기기 저장, 동기화, 충돌을 구분하는 방법

“저장됨”이라는 표시는 페이지를 닫아도 작업이 남는지, 서버가 저장을 완료했는지, 동료들도 같은 버전을 볼 수 있는지를 알려야 합니다. 이 세 가지는 서로 다른 약속입니다. 오프라인 편집을 지원하는 앱이라면 아직 저장되지 않은 변경, 기기에 저장된 작업, 동기화 대기, 동기화 확인, 사용자의 결정이 필요한 변경을 구분해야 합니다.

통신이 불안정한 건물에서 사용하는 시설 관리 앱을 생각해 보세요. 현장 기사가 점검 메모를 수정하고 우선순위를 높이는 동안, 사무실의 담당자도 같은 기록을 업데이트합니다. 이때 설계해야 할 것은 단순한 오프라인 배너가 아닙니다. 두 사람의 작업을 모두 보호하면서 현장 기사가 다시 연결했을 때 무엇을 해야 하는지 이해할 수 있게 해야 합니다.

저장 메시지가 보장하는 범위를 정확히 정하기

상태 문구를 작성하기 전에 앱이 무엇을 확인할 수 있는지 개발팀과 합의하세요. 메모리에만 남아 있는 수정 내용은 페이지를 닫아도 유지되는 기기 저장이 아닙니다. 전송 대기열에 들어간 요청은 서버 저장 성공을 뜻하지 않습니다. 서버가 저장을 완료했더라도 모든 동료가 이미 그 내용을 전달받았다고 볼 수는 없습니다.

이 구분은 상태의 의미를 정하기 위한 것이지, 배지 다섯 개를 한꺼번에 표시하라는 뜻이 아닙니다. 평소에는 기록 이름 옆에 눈에 거슬리지 않는 상태 하나만 보여 줘도 충분합니다. 사용자가 조치해야 하거나 작업을 잃을 위험이 있을 때 더 눈에 띄게 표시하세요. 해결되지 않은 문제를 잠깐 나타났다 사라지는 토스트 메시지로만 알려서는 안 됩니다.

“이 기기에 저장됨”도 언제까지나 복구할 수 있다는 약속은 아닙니다. 비공개 브라우징, 저장소 정책, 계정 변경, 앱의 구현 방식에 따라 보존 범위가 달라질 수 있습니다. 사용자의 다음 행동에 영향을 주는 제한은 바로 그 시점에 설명하세요. 안심시키는 초록색 체크 표시 뒤에 제한을 숨기지 마세요.

연결 상태는 단서일 뿐, 저장의 증거가 아님을 구분하기

네트워크 표시는 서비스가 해당 기록을 받아 저장했다는 사실을 확인해 주지 못합니다. 기기가 네트워크에 연결되어 있어도 서비스에 접근하지 못할 수 있습니다. MDN도 브라우저의 온라인 신호를 신뢰할 수 없다고 설명합니다(영문). 이 신호는 인터페이스에 참고 정보로 활용하되, 저장 확인은 실제 작업의 결과를 바탕으로 표시하세요.

네트워크 상태와 기록의 저장 상태를 분리하세요. “연결이 복구되었습니다”와 “변경 내용 2개가 동기화를 기다리고 있습니다”는 동시에 참일 수 있습니다. 현장 기사의 우선순위 변경이 아직 대기열에 있는데 두 메시지를 “모두 저장됨”으로 바꾸면 끝나지 않은 작업이 가려집니다.

연결이 끊겨도 읽을 수 있는 콘텐츠와 이미 입력한 내용은 그대로 유지하세요. 안전하게 수행할 수 없는 행동만 비활성화해야 합니다. 기기 내 처리를 지원하는 메모 수정은 계속 허용하더라도, 알림 전송이나 작업 지시 배정에는 서버가 필요할 수 있습니다. 화면 전체를 오류로 덮는 대신 사용할 수 없는 행동 옆에서 그 차이를 설명하세요.

구현 세부사항 대신 대기 중인 작업을 보여 주기

현장 기사가 알아야 하는 것은 어떤 기록이 대기 중인지이지, 네트워크 재시도를 몇 번 했는지가 아닙니다. 수정한 기록 옆에 상태를 두고, 여러 기록에 걸쳐 작업할 수 있을 때만 간결한 대기 목록을 제공하세요. 개수를 표시할 때는 단위를 밝혀야 합니다. “기록 3건 대기 중”과 “필드 변경 3개 대기 중”은 서로 다릅니다.

대기열이 어떻게 동작할지 팀과 함께 정하세요. 다시 연결하기 전에 같은 메모를 두 번 고쳤다면 최종 값만 안전하게 보낼 수 있나요, 아니면 변경 이력을 순서대로 보존해야 하나요? 두 번째 행동을 실행하려면 먼저 기록이 생성되어 있어야 하는 경우, 두 행동을 각각 독립적으로 다시 실행할 수 있는 것처럼 보여서는 안 됩니다. 사용자가 전송 방식까지 따질 필요가 없도록 하되, UI는 실제로 지원하는 처리 방식을 반영해야 합니다.

사용자가 자신의 작업을 알아보는 데 도움이 된다면 기기에서 수정한 시각을 명확히 보여 주세요. 다만 화면에 표시된 시각이 더 늦다는 이유만으로 항상 그 버전을 우선해서는 안 됩니다. 기기 시계의 차이, 지연된 요청, 서버의 처리 순서 때문에 그런 판단이 틀릴 수 있습니다. “아직 동기화되지 않은 내 수정 내용”과 “현재 서버 버전”이라는 표시는 두 버전의 관계를 더 직접적으로 전달합니다.

다시 연결되었을 때의 처리 과정 보여 주기

다시 연결되는 순간 서버의 이전 값이 사용자의 대기 중인 수정 내용을 잠깐이라도 덮어 표시하지 않게 하세요. 앱이 변경을 확인하고 전송하는 동안에도 기기에서 작업하던 화면을 유지해야 합니다. 서비스가 저장을 완료하면 해당 버전의 대기 상태를 확인 상태로 바꿉니다. 요청을 처리하는 사이 더 새로운 수정이 생겼다면 그 수정은 계속 대기 중으로 보여야 합니다.

검토하기 좋은 시나리오는 메모를 두 번 수정하는 경우입니다. 버전 A를 전송한 뒤, A의 저장 확인이 오기 전에 사용자가 버전 B를 입력합니다. 개발자에게 응답이 어느 버전에 대한 확인인지 보여 달라고 요청하세요. A가 성공했다는 이유만으로 B까지 동기화되었다고 표시해서는 안 됩니다.

제출 뒤 결과를 확신할 수 없는 응답이 오면 중복 작업을 만들 수 있는 행동을 곧바로 권하지 마세요. 팀은 원래 작업이 어떻게 처리되었는지 확인할 수 있는 방법을 마련해야 합니다. 대기 또는 복구 화면도 그 확인 방식에 맞춰 설계하세요. 점검 기록의 경우 즉시 다시 제출하라고 하기보다 “이 업데이트가 수신되었는지 확인하는 중입니다”라고 표시하는 것이 더 정확합니다.

설명 없는 두 기록 대신 충돌한 변경을 비교하기

동시에 수정되었다고 해서 모두 모달 창을 띄울 필요는 없습니다. 제품의 규칙에 따라 서로 독립적인 필드를 안전하게 결합할 수 있다면 앱이 이를 병합하고 결과를 알려 줄 수 있습니다. 두 사람이 같은 필드를 바꿨거나 한쪽 변경으로 다른 변경이 유효하지 않게 된다면, 영향을 받는 필드를 보여 주고 시스템이 안전하게 내릴 수 없는 결정을 사용자에게 요청하세요.

점검 사례에서 마지막으로 동기화된 기록은 우선순위가 “낮음”이고 메모는 비어 있었습니다. 현장 기사는 우선순위를 “긴급”으로 바꾸고 누수 메모를 추가했으며, 사무실 담당자는 우선순위를 “보통”으로 바꾸고 메모는 건드리지 않았습니다. 두 사람 모두 우선순위를 바꿨지만 메모를 바꾼 사람은 현장 기사뿐입니다. 어떤 기록인지 식별할 수 있게 하고 기기의 값과 현재 서버 값을 함께 보여 주면서, 각각을 선택하면 무엇이 달라지는지 설명하세요. 권한이 허용하고 정보가 있다면 관련 수정자나 변경 시각도 덧붙이세요. 사용자가 더 이상 볼 권한이 없는 정보는 절대 노출해서는 안 됩니다.

비교 화면은 선택의 결과가 분명해야 의미가 있습니다. 여러 필드를 한꺼번에 바꾸는 행동을 “내 내용 유지”라고만 표시하면 범위가 모호합니다. “우선순위를 긴급으로 적용”처럼 충돌한 필드에 한정된 결정을 제시하는 편이 좋습니다. 충돌과 관련 없는 기기 내 수정 내용은 그대로 유지하세요. 제품이 값을 결합하거나 직접 수정하는 방법을 지원한다면, 두 값 중 하나만 고르도록 강요하지 말고 해당 선택지도 분명히 보여 주세요.

비교 화면을 열어 둔 사이에 기록이 다시 바뀔 수 있습니다. 개발팀과 합의한 처리 규칙은 이 상황까지 포함해야 합니다. HTTP 기반 구현에서는 조건부 요청으로 업데이트 유실을 방지하는 데 도움을 받을 수 있습니다(영문). 이에 따라 화면에서도 다음과 같이 처리해야 합니다. 이전 버전을 기준으로 내린 결정이 거부되면 최신 비교 화면을 다시 열되, 사용자가 제안한 해결안은 보존해야 합니다. 더 새로운 기록을 알리지 않고 덮어써서는 안 됩니다.

충돌과 저장·접근·유효성 검사 실패 구분하기

동기화가 실패했다고 모두 같은 충돌 화면으로 보내지 마세요. 원인에 따라 사용자가 안전하게 할 수 있는 행동이 달라집니다. 기기 저장이 실패했다면 페이지를 닫은 뒤 복구할 초안이 없을 수 있습니다. 유효성 검사에 실패했다면 고쳐야 할 필드를 보여 줘야 합니다. 접근 권한이 바뀌었다면 재시도로 권한을 되찾을 수는 없습니다.

• 기기 저장 실패: 현재 입력 내용을 계속 보여 주고, 무엇이 저장되지 않았는지 설명합니다. 제품이 지원한다면 승인된 복구 경로를 제공합니다.
• 인증 만료: 계속하려면 로그인해야 한다고 설명합니다. 로그인 과정에서도 수정 내용을 보존하는 것은 구현 방식과 정책이 허용하는 경우에만 가능합니다.
• 권한 제거: 권한 없는 쓰기 작업을 중단하고, 복구나 내보내기는 사용자에게 아직 허용된 행동으로 제한합니다.
• 기록 삭제: 변경을 적용할 대상이 없어졌다고 설명합니다. 기록 복원이나 새 기록 생성은 권한이 필요한 별도의 결정이며, 자동 재시도로 처리할 일이 아닙니다.
• 유효성 검사 규칙 변경: 영향받지 않은 필드는 보존하고, 수정해야 할 필드 옆에 현재 규칙을 보여 줍니다.

문구와 조작 요소도 이 차이를 따라야 합니다. 어떤 제품에서는 기록 소유자에게 “초안 내보내기”가 적절할 수 있지만, 다른 제품에서 접근 권한이 제거된 협업자에게 같은 행동을 허용하면 안전하지 않을 수 있습니다. 설계에 넣기 전에 보안 담당자 및 제품 책임자와 함께 허용되는 복구 경로를 정하세요.

키보드와 스크린 리더로도 이해할 수 있는 상태 안내

상태 문구는 해당 기록 가까이에 두고, 아이콘이나 색상이 전달하는 상태를 텍스트로도 설명하세요. 회전하는 표시만으로는 기기에 저장하는 중인지, 서버에 접속하는 중인지, 응답을 기다리는 중인지 알 수 없습니다.

일상적인 저장 상태 업데이트가 편집 중인 필드에서 포커스를 빼앗아서는 안 됩니다. 보조 기술이 인식할 수 있는 적절한 상태 메시지로 전달하되, 키 입력이나 재시도마다 계속 알리지 마세요. W3C의 상태 메시지 안내(영문)는 포커스를 옮기지 않고 전달할 수 있는 업데이트와 맥락이 바뀌는 상호작용을 구분합니다. 충돌 대화상자가 꼭 필요하다면 포커스가 어떻게 들어가고, 사용자가 완료하거나 취소했을 때 어디로 돌아오는지도 정하세요.

좁은 화면에서도 같은 복구 경로를 제공하세요. 나란히 놓인 비교값은 위아래로 바꾸되, 각 값 앞에 필드 이름을 반복하고 명확한 라벨을 붙일 수 있습니다. 기기의 버전과 서버 버전을 구별할 때 좌우 위치, 빨강·초록 색상이나 마우스를 올려야만 보이는 설명에 의존하지 마세요.

Pixso에서 점검 기록의 흐름 검토하기

하나의 Pixso 파일에 같은 점검 기록의 세 가지 상태를 만드세요. 기기에 저장한 메모가 동기화를 기다리는 상태, 우선순위 충돌을 비교하는 상태, 선택한 우선순위가 서버에 반영된 상태입니다. 기록 이름, 메모와 필드 라벨은 일관되게 유지하세요. 프레임 사이에서 달라져야 하는 것은 저장 상태와 사용자가 내리는 결정입니다.

관련 화면을 프로토타입으로 연결하고 동료에게 연결 복구 후 점검을 계속해 달라고 요청하세요. 메모가 서버에 저장되었는지 알 수 있나요? 충돌한 우선순위를 찾고 메모를 버리지 않은 채 그 필드만 해결할 수 있나요? 개발팀에 전달할 때는 서버의 저장 확인과 새로 발생한 기기 내 수정의 차이를 주석으로 남기세요. 디자인에서 코드로 이어지는 핸드오프 안내(영문)에서 이런 구현 결정을 기록하는 더 넓은 틀을 참고할 수 있습니다.

Pixso에서 동기화 충돌 흐름을 설계하고 검토하기 →

작업을 가리거나 잃게 할 수 있는 상태 전환 테스트하기

각 화면을 따로 보는 데 그치지 말고 상태가 바뀌는 과정을 테스트하세요. 점검 기록에서 특히 많은 문제를 드러내는 순서는 오프라인 편집, 재연결, 충돌 발생, 해결하기 전에 서버가 다시 바뀌는 상황입니다. 이 과정 내내 선택하려는 우선순위와 처음 입력한 메모를 알아볼 수 있어야 합니다.

기기 저장이 확인된 뒤 페이지를 닫았다가 다시 여는 경우, 기기 저장 단계가 실패하는 경우, 요청 처리 중 필드를 바꾸는 경우, 인증이 만료되는 경우, 재연결 전에 접근 권한이 제거되는 경우도 시험하세요. 다시 열기 동작은 앱이 실제로 지원한다고 약속한 범위에서 테스트해야 합니다. 입력 내용이 남는지, 각 메시지가 어느 버전을 가리키는지, 제공하는 모든 행동에 여전히 권한이 있는지 기록하세요.

성공은 단순히 대기열이 비는 것이 아닙니다. 현장 기사가 최종 반영된 우선순위를 확인하고, 자신이 쓴 점검 메모를 찾고, 아직 대기 중인 작업이 있는지 알 수 있어야 합니다. 인터페이스가 이 세 질문에 답하지 못한다면 애니메이션을 다듬기 전에 상태 표시와 복구 동작부터 개선하세요.