인터넷이 끊긴 동안 작성한 내용은 서버에 어떻게 전달될까요?

2. ‘이 기기에 저장됨’은 다른 사람에게 전달됐다는 뜻일까요?

이제 담당자의 기기에는 ‘필터 교체 필요’가 있지만, 서버에는 아직 새 내용이 없습니다. 사무실 관리자도 바뀐 내용을 볼 수 없습니다. 같은 기록 번호를 두 화면에 표시하면 어디까지 전달됐는지 비교할 수 있습니다.

저장에 실패했다면 안내도 달라져야 합니다. ‘기기에 저장하지 못했습니다. 입력 화면을 유지하고 다시 저장해 주세요’처럼 남은 행동을 알려야 합니다. 이 상태에서 저장 완료 표시를 하거나 전송 대기로 넘기면 안 됩니다.

또한 기기 보관을 영구 보관으로 약속해서는 안 됩니다. 웹 앱의 브라우저 저장은 용량, 브라우저 설정과 사용자의 데이터 삭제 등의 영향을 받습니다. 이 설명은 웹 저장에 관한 것이며 모든 네이티브 앱의 보관 방식에 그대로 적용되는 것은 아닙니다. MDN 브라우저 저장 보존과 삭제 조건

3. 저장한 기록을 ‘전송 대기’로 남깁니다

담당자가 ‘전송 대기에 넣기’를 누릅니다. 이 예시에서는 저장된 점검 기록을 보낼 대상으로 등록한 뒤 ‘기록 전송 대기 1건’을 보여줍니다. 점검 상세에는 ‘연결 후 이 기록을 다시 보내 주세요’라는 안내가 붙습니다.

관리자 화면은 여전히 ‘점검 전’입니다. 서버에 없는 새 내용을 관리자가 이미 받은 것처럼 표시하지 않습니다. 담당자는 남은 한 건을 대기 목록에서 다시 찾을 수 있어야 합니다.

4. 연결이 돌아와도 해당 기록의 접수를 확인해야 합니다

인터넷 연결이 돌아오면 담당자가 앱에서 ‘다시 보내기’를 누릅니다. 화면은 ‘전송 중 · 서버 접수 확인 전’으로 바뀝니다. 그동안 앱은 보관한 내용과 사진을 보내고, 서버는 같은 기록 번호의 현재 내용과 변경 여부를 확인합니다.

응답을 받지 못했을 때도 구분이 필요합니다. 서버에 저장됐을 수도 있으므로 ‘결과 확인 필요’라고 안내하고, 기존 처리 결과를 확인할 방법을 제공합니다. 곧바로 성공이라고 하거나 서버에 전혀 반영되지 않았다고 단정하지 않습니다. 재전송과 중복 방지의 자세한 과정은 요청이 실패하거나 두 번 전송되면 서버는 어떻게 처리할까요?에서 이어서 볼 수 있습니다.

실시간 통신을 사용하는 앱도 재연결과 기록 저장 확인을 구분해야 합니다. 통신 방식 자체가 궁금하다면 실시간 통신·WebSocket을 참고하세요.

5. 서버 접수 뒤에는 관리자 확인이 남습니다

정상 흐름에서는 서버가 INS-A-001의 새 내용과 사진 한 개를 저장하고 그 결과를 돌려줍니다. 담당자 앱은 해당 기록과 첨부 상태를 확인한 뒤 ‘서버 접수 확인 · 사진 1/1개 접수’를 표시합니다.

이 예시에서 서버 접수는 점검 자료가 도착했다는 뜻입니다. 점검 결과를 받아들일지, 교체를 지시할지, 보완을 요청할지는 정한 업무 규칙과 담당자 판단에 따라 이어집니다. 필터 교체 필요라는 기록을 받았는데 ‘업무 완료’로 표시하면 실제 남은 일을 놓칠 수 있습니다.