개인 앱의 오류 메시지: 사용자가 다음 행동을 알게 만들기

저장 버튼을 눌렀는데 “오류가 발생했습니다”만 보이면 사용자는 멈춘다. 입력을 고쳐야 하는지, 로그인해야 하는지, 다시 눌러도 되는지 알 수 없기 때문이다. 오류 메시지를 다듬을 때는 문구와 버튼을 함께 봐야 한다. 무엇이 확인됐고, 사용자가 지금 할 수 있는 일은 무엇이며, 작성하던 내용은 어디에 남아 있는지가 이어져야 한다.

가상의 독서메모 앱을 예로 들어보자. 화면에는 필수 항목인 ‘제목’, 선택 항목인 ‘메모’, ‘저장’ 버튼이 있다. 제목은 빈칸, 메모는 “오늘은 등장인물의 선택을 기록했다”로 둔다. 이 글에서는 제목 누락, 로그인 만료, 저장 응답을 받지 못한 상황을 각각 따로 가정한다. 같은 실패 화면으로 묶기 쉬워도 필요한 다음 행동은 다르다.

제목이 비었을 때는 고칠 자리까지 안내하기

제목을 비운 채 저장하면 제목 항목에 문제가 있다는 사실과 수정 방법을 함께 알려주면 된다. “입력값이 잘못되었습니다”보다 “제목이 비어 있습니다. 제목을 입력해 주세요”가 구체적이다. 메모의 내용은 그대로 두고, 제목을 넣으면 다시 저장할 수 있게 한다. 사용자가 이미 작성한 부분까지 다시 입력하게 만들 이유는 없다.

가상 화면: 오류 요약과 제목 옆 안내를 연결해 수정할 곳을 찾게 한다.

필드 주변에서는 제목이라는 항목 이름과 오류 문장을 가까이 배치한다. 테두리를 빨갛게 바꾸는 것만으로 끝내지 않고, 눈에 보이는 텍스트로 문제를 적는다. 색을 구분하기 어려운 사람도 어느 항목을 고쳐야 하는지 알아야 하기 때문이다. 화면을 읽어주는 도구에서도 해당 입력칸과 설명의 관계를 알 수 있도록 연결해야 한다. 웹 폼에서는 aria-describedby 같은 연결 방식을 검토할 수 있다.

항목이 많거나 오류가 화면 밖에 있으면 폼 위에 “수정할 항목 1개”라는 요약을 두는 구성이 도움이 된다. 요약 안의 “제목을 입력해 주세요”를 선택하면 제목 칸으로 이동하게 한다. 모든 폼에 똑같은 오류 요약을 의무적으로 붙인다는 뜻은 아니다. 이 예시에서는 전체 문제를 찾는 안내와 실제 수정하는 자리의 안내를 함께 두는 방식을 택했다.

요약을 만들었다고 끝난 것은 아니다. 키보드로 그 안내에 도달하고 제목 칸으로 이동할 수 있는지, 제목을 고친 뒤 오래된 오류가 남지 않는지 확인해야 한다. 나중에 등장하는 오류 안내는 화면의 어느 부분이 바뀌었는지 전달하는 방법도 필요하다. 메시지를 보이게 만드는 작업과 사용자가 그 메시지를 발견하게 만드는 작업을 함께 설계하자.

로그인이 만료되면 초안이 어디에 있는지 말하기

이번에는 제목을 ‘가상의 책 A’로 채운 뒤, 저장 요청을 처리하기 전에 로그인이 만료됐다고 가정한다. 앱이 인증 만료를 확인했다면 “로그인이 만료되었습니다. 다시 로그인해 주세요”라고 설명할 수 있다. 그러나 로그인 버튼만 누르면 작성 화면을 떠나게 된다면, 사용자가 가장 궁금한 내용은 아직 빠져 있다. 방금 쓴 메모를 다시 볼 수 있는가 하는 점이다.

설계 전제: 초안을 보관한 뒤 로그인하고, 복구된 내용을 확인한 사용자가 저장한다.

이 예시의 복구 흐름은 로그인 이동 전 초안을 보관하고, 같은 계정으로 돌아오면 작성 중이던 내용을 복원하는 기능이 있다는 전제다. 보관 성공을 확인한 뒤에만 “작성 내용은 초안으로 보관했습니다. 로그인 후 이어서 작성할 수 있습니다”라고 쓴다. 화면에 메모가 남아 있다는 사실만으로, 페이지를 떠난 뒤에도 복구된다고 약속해서는 안 된다.

복구 기능이 없다면 실제로 가능한 경로를 안내해야 한다. 예를 들어 현재 화면에서 내용을 복사할 수 있게 하고, “로그인 화면으로 이동하기 전에 작성 내용을 복사해 주세요”라고 알릴 수 있다. 편리함은 줄어들어도 보관하지 않은 내용을 보관했다고 말하는 것보다 상황이 분명하다. 초안을 어디에 얼마나 보관할지도 정하고, 다른 계정으로 로그인했을 때 잘못된 사람에게 복원되지 않게 해야 한다.

로그인 완료와 메모 저장 완료는 각각 확인한다. 예시 앱은 돌아온 사용자에게 복구한 제목과 메모를 보여주고 ‘저장’ 버튼을 다시 제공한다. 로그인됐다는 이유만으로 이전 요청을 자동 전송하지 않는다. “작성 중인 메모를 복구했습니다. 내용을 확인하고 저장해 주세요”처럼 현재 상태를 안내하면, 사용자가 초안 복구를 최종 저장으로 오해하는 일도 줄일 수 있다.

응답을 못 받았다면 저장 결과부터 확인하기

세 번째 상황은 조금 더 조심해야 한다. 제목과 메모를 채우고 저장을 눌렀는데 응답이 오지 않는다. 요청이 서버에 도착하지 않았을 수도 있지만, 이미 메모가 저장된 뒤 응답만 끊겼을 수도 있다. 이때 “저장에 실패했습니다. 다시 시도해 주세요”라고 단정하면 같은 메모를 두 번 만드는 행동으로 이어질 수 있다.

가상 저장 흐름: 결과가 불명확하면 조회하고, 미저장이 확정된 경우에 재시도한다.

예시 앱의 첫 안내는 “저장 결과를 확인하지 못했습니다. 작성 내용은 유지하고 있습니다”로 둔다. 다음 행동은 ‘저장 여부 확인’이다. 이 버튼은 같은 메모를 새로 보내는 대신, 앞선 저장 요청의 결과를 조회하도록 설계한다. 조회 결과 저장된 메모가 확인되면 그 메모를 열어 보여주고, 원래 요청이 처리되지 않았다고 확실히 확인됐을 때 다시 저장할 수 있게 한다.

단순히 목록에서 같은 제목이 안 보인다는 것만으로 미저장을 확정하면 곤란하다. 목록 반영이 늦을 수 있고, 제목이 같은 다른 메모도 있을 수 있다. 개발 단계에서는 해당 요청이나 메모를 구별할 값을 정해 결과를 확인하는 경로를 마련해야 한다. 아직 처리 중이거나 조회마저 실패했다면 ‘확인 중’ 또는 ‘결과 확인 필요’ 상태를 유지하고, 무조건 다시 보내는 버튼으로 바꾸지 않는다.

이 흐름을 만들기 어렵다면 적어도 초안을 유지하고 저장 결과가 불명확하다는 점을 알려야 한다. 사용자가 메모를 복사하거나 나중에 저장 내역을 확인할 경로를 제공한다. 중복 처리를 막는 서버 설계가 있다면 재시도 정책을 더 발전시킬 수 있지만, 버튼의 문구만 바꿔서 중복 저장을 해결할 수는 없다. 안내가 약속하는 행동을 실제 기능이 지원해야 한다.

문구를 읽은 뒤 다음 화면까지 점검하기

설계를 검토할 때는 앞의 세 입력 상태를 따로 준비해보자. 제목 빈칸에서는 제목 안내와 메모 유지가, 인증 만료에서는 초안 보관 결과와 로그인 후 복원이, 응답 유실에서는 결과 조회와 중복 제출 방지가 확인 대상이다. 성공했을 때는 저장된 제목과 내용을 보여줘서 작업이 끝났다는 사실도 확인할 수 있게 한다.

여기서 제시한 화면과 문장은 가상의 설계 예시다. 실제 앱이나 브라우저·스크린리더로 동작을 시험한 결과는 아니다. 구현한 뒤에는 키보드 이동, 오류 안내가 읽히는 순서, 초안 복원, 응답이 끊기는 시나리오를 각각 확인해야 한다. 친절한 오류 메시지는 정중한 한 문장에서 시작할 수 있지만, 사용자가 작성하던 일을 이어가는 화면까지 연결될 때 제 역할을 한다.