점검 내용을 입력하고 저장을 눌렀는데 통신이 끊겼습니다. 화면에는 계속 처리 중이라고 나옵니다. 사용자는 다시 눌러야 할지, 기다려야 할지 판단하기 어렵습니다. 서버에 이미 반영됐는데 한 번 더 입력하면 같은 작업이 두 건 생길 수도 있습니다.
현장 앱을 검수할 때는 ‘오프라인 지원’이라는 항목만 확인하지 말고 기기에 저장된 상태와 서버에 반영된 상태가 구분되는지 살펴봐야 합니다. 조회, 입력, 승인, 결제는 통신 없이 처리할 수 있는 범위도 서로 다릅니다.
저장 완료라는 문구부터 나눠봅니다
기기에만 저장된 자료라면 아직 다른 담당자는 볼 수 없을 수 있습니다. 사용자가 이를 업무 완료로 오해하지 않도록 ‘기기에 저장됨’, ‘전송 대기’, ‘서버 반영 완료’, ‘확인 필요’처럼 상태를 구분하는 방식을 검토할 수 있습니다.
통신이 복구됐을 때 자동으로 전송할지, 사용자가 확인하고 전송할지도 정해야 합니다. 앱을 종료하거나 단말이 재시작돼도 대기 중인 작업이 보존되는지까지 시험해야 합니다.
Android 공식 가이드도 오프라인 데이터 저장, 작업 대기열, 재연결 후 동기화와 충돌 처리를 구분합니다. 특히 쓰기 작업은 조회와 달리 다른 변경과 충돌할 수 있어 별도 설계가 필요합니다. 오프라인 우선 앱 설계 안내
다시 보내도 같은 업무가 반복되면 안 됩니다
서버에 저장됐지만 응답을 받지 못한 경우를 생각해보세요. 앱 입장에서는 성공 여부가 불명확합니다. 재전송을 허용하려면 같은 요청인지 식별하고 중복 업무가 만들어지지 않게 처리할 기준이 필요합니다.
사진 첨부도 별도로 봐야 합니다. 본문은 저장됐지만 사진만 실패했을 때 전체 기록을 다시 만들어야 하는지, 실패한 파일만 이어서 보낼 수 있는지 확인하세요. 업무와 첨부의 처리 상태가 서로 맞아야 사용자가 빠진 내용을 알 수 있습니다.
검수 시나리오에 아래 상황을 넣어보세요
다음은 점검·현장 입력 앱을 가정한 시험 예시입니다. 실제 위험도와 업무 규칙에 맞춰 기대 결과를 정해야 합니다.
| 시험 상황 | 확인할 결과 |
|---|---|
| 입력 중 통신 차단 | 작성한 내용의 보존 여부와 사용자 안내 |
| 저장 요청 직후 통신 차단 | 재접속 후 성공 여부 확인, 중복 생성 방지 |
| 사진 일부만 전송 실패 | 실패한 파일 표시와 재전송 방법 |
| 대기 작업이 있는 상태에서 앱 종료 | 재실행 후 남은 작업의 복구 |
| 다른 담당자가 같은 기록을 변경 | 충돌 표시와 최종 처리 기준 |
| 사용자 권한이 변경된 뒤 재전송 | 현재 권한 재확인과 보류 처리 |
마지막으로 입력한 값이 항상 정답인 것은 아닙니다. 재고나 승인 상태처럼 중요한 자료는 충돌이 생겼을 때 담당자에게 확인을 맡기거나, 서버의 현재 상태를 기준으로 다시 처리해야 할 수 있습니다.
모든 기능을 통신 없이 쓰게 할 필요는 없습니다
점검 메모를 임시 저장하는 일과 재고를 최종 확정하는 일은 영향이 다릅니다. 통신이 없으면 조회 자료를 보여주되 갱신 시각을 표시하고, 확정 작업은 연결 후에만 허용하는 방식도 검토할 수 있습니다.
기기에 저장하는 자료의 보안과 보존 기간도 함께 정해야 합니다. 오프라인 편의를 위해 민감한 자료를 필요 이상으로 내려받거나 오래 남기지 않도록 범위를 제한합니다.
케이엠웍스의 삼성서울병원 WearSMC에서는 Galaxy Watch·Samsung Health의 데이터를 주기적 또는 수동으로 서버에 전송하는 기능을 구축했습니다. 이 사례는 모바일과 서버 사이의 데이터 전달 경험을 보여줍니다. 위의 모든 오프라인 검수 항목이 해당 프로젝트에 납품됐다는 의미는 아닙니다.
IoT·현장 앱 개발 가이드도 함께 확인할 수 있습니다. 사용 장소와 단말, 통신이 끊겨도 계속해야 하는 업무를 개발 문의에 알려주시면 필요한 저장·전송·검수 범위를 정리하겠습니다.