사용자가 긴 문의서를 다 작성하고 제출 버튼을 눌렀습니다. 잠시 기다리다 “오류가 발생했습니다”라는 화면이 떴고, 뒤로 가니 내용이 모두 사라졌습니다. 업무 앱에서 이 경험은 단순한 불편이 아닙니다. 같은 신청을 다시 입력하면서 빠뜨리거나, 사실은 저장된 건을 한 번 더 보내는 문제로 이어집니다. 제출 실패 UX는 예쁜 오류 메시지보다 입력 보존과 서버 상태를 정확히 다루는 설계가 중요합니다.
오류를 세 가지로 나눠 본다
첫째, 입력값이 규칙에 맞지 않아 서버가 거절한 경우입니다. 어떤 필드를 왜 고쳐야 하는지 알려주고 입력은 그대로 유지해야 합니다. 둘째, 서버가 명확하게 실패를 응답한 경우입니다. 저장되지 않았음을 확인할 수 있으면 수정·재시도 안내를 할 수 있습니다. 셋째, 네트워크가 끊겨 응답을 못 받은 경우입니다. 이때 서버가 이미 저장했을 수도 있으므로 ‘저장되지 않았다’고 단정하면 안 됩니다.
이 세 번째 상황이 중복 제출의 주된 원인입니다. 버튼을 잠시 비활성화하는 것만으로는 해결되지 않습니다. 페이지 새로고침, 브라우저 복원, 모바일 네트워크 전환 뒤 다시 전송할 수 있기 때문입니다. 요청마다 고유한 제출 ID를 만들고 같은 ID로 다시 보내면 서버가 앞선 결과를 돌려주도록 설계하면 안전합니다.
사용자의 작업을 먼저 지킨다
검증 오류 후에는 서버가 받은 값을 폼에 다시 채워 보여줘야 합니다. 자바스크립트 앱이라면 전송 중에도 폼 상태를 유지하고, 실패를 확인하기 전에는 입력값을 비우지 않습니다. 긴 작성 시간이 필요한 화면은 중간 저장을 검토할 수 있지만, 민감한 내용이 브라우저 저장소에 오래 남지 않도록 보관 위치와 만료를 정해야 합니다. 공용 PC나 공유 기기를 쓰는 환경이라면 특히 주의가 필요합니다.
파일 첨부는 일반 텍스트 필드보다 까다롭습니다. 브라우저가 보안상 파일 입력을 자동으로 다시 채우지 않을 수 있습니다. 큰 파일은 업로드와 최종 제출을 분리해 임시 업로드 ID를 유지하거나, 다시 선택해야 할 때 그 사실을 분명히 알려주세요. 이미 올라간 파일은 화면에 이름과 상태를 보여주고, 본문 오류 때문에 다시 전송하지 않도록 합니다.
작성 도중 세션이 만료되는 상황도 시험해야 합니다. 로그인 화면을 거쳐 돌아왔을 때 입력이 사라지면 사용자는 오류 원인을 알 수 없습니다. 인증 복귀 후 안전하게 폼 상태를 복원하되, 다른 계정으로 로그인했거나 공용 기기에서 사용한 경우에는 이전 사용자의 내용을 노출하지 않아야 합니다. 저장 위치와 보존 시간을 서비스의 정보 민감도에 맞게 정하고, 사용자에게 임시 저장 여부를 알려주는 편이 좋습니다.
오류 안내는 고칠 수 있는 말이어야 한다
“오류 발생”만 표시하면 사용자는 다음 행동을 모릅니다. 폼 상단에 문제 수와 요약을 보여주고, 각 필드 옆에 구체적인 수정 방법을 적습니다. 키보드 사용자도 오류 요약에서 해당 필드로 이동할 수 있어야 하고, 화면 낭독기에서도 관련 설명이 연결돼야 합니다. 시각적인 빨간 테두리만으로 오류를 알리면 색을 구분하기 어려운 사용자는 놓칠 수 있습니다.
완료 화면은 실제 서버 결과에 근거해야 한다
버튼을 클릭했다는 이유로 성공 화면을 먼저 보여주면 안 됩니다. 서버가 접수 ID와 상태를 확인한 뒤 완료 화면을 띄우고, 사용자가 나중에 진행 상태를 확인할 수 있는 번호를 제공합니다. 비동기 후속 처리가 있다면 ‘접수됨’과 ‘처리 완료’를 구분합니다. 응답을 놓친 경우에는 제출 ID로 상태를 조회하고, 확인되지 않을 때만 같은 ID로 안전하게 재시도합니다.
점검 항목은 ① 검증 실패 뒤 모든 입력이 유지되는가 ② 네트워크 타임아웃 뒤 실제 처리 상태를 확인하는가 ③ 같은 제출을 두 번 보내도 한 건만 저장되는가 ④ 파일 상태가 보이는가 ⑤ 오류 요약과 필드 안내를 키보드로 사용할 수 있는가 ⑥ 성공 화면에 접수 근거가 있는가입니다. 안정적인 폼은 사용자를 다시 입력하게 만들지 않고, 시스템이 모르는 상태를 솔직하게 설명합니다.
