이 글은 김철수님께서 집필하신 "개발자의 글쓰기" 중 3장의 내용을 기반으로 저의 생각을 덧붙여보았습니다.
사용자와 소통하는 에러 메시지 쓰기
[Q1] 에러메시지란 무엇인가?
= 사용자가 컴퓨터에 요청한 작업을 컴퓨터가 수행하지 못하였을 때 보내는 대답이라고 생각합니다.
그러므로 요청을 수행하지 못한 대답을 고민하기 이전에 요청을 어떻게 수행할 지를 고민하고 해결해야합니다.
01 에러 메시지를 쓰기 전에 에러부터 없애자
친절한 404, 불친절한 404
[Q2] 404란 무엇인가?
= 404는 HTTP 응답코드 중 하나로 서버(컴퓨터)가 사용자의 요청을 찾기 못하였을 때 사용됩니다.
저자가 정의한 '친절한 404, 불친절한 404'의 차이는 사용자의 요청을 수행하지 못했음을 알림에 그치느냐, 후속조치를 안내하고 사과까지 하느냐의 차이입니다. 사용자의 요청을 수행하지 못했으면 사과해야하지 않을까요?
404 에러가 죄송할 일인가?
사용자가 404 에러 페이지를 만나는 경우는 다음과 같이 두 가지밖에 없다.
- 사용자가 URL을 잘못 입력한 경우
- 사용자가 링크를 클릭했으나 해당 페이지가 없는 경우
사용자가 URL을 잘못 입력한 경우는 개발자의 책임이 없기에 사과할 이유가 없습니다. 그러나 2 번째 경우는 개발자의 문제입니다.
링크가 있어서 클릭했는데 해당 페이지가 없는 경우, 이것을 깨진 링크, 죽은 링크, 나쁜 링크라고 한다.
깨진 링크는 개발자 책임이다
사용자가 깨진 링크를 접했다는 것은 개발자가 미리 깨진 링크를 수정하지 못했다는 의미입니다. 물론 문제가 발생하였다면 사과해야하지만, 문제를 사전에 방지해야 합니다. 저자는 깨진 링크를 확인하는 2가지 방법을 제시하고 있으니 읽어보시고 활용해보시길 바랍니다.
개발자용 에러 메시지와 사용자용 에러 메시지를 분리하자
저자는 개발자용 메시지가 사용자에게 노출되는 것을 방지하기 위해 개발자용 에러 메시지와 사용자용 에러 메시지를 분리해 작성하는 것을 추천합니다. 개발자용 에러 메시지에 [개발자]와 같은 prefix를 작성하고 컴파일 전에 검색 후 삭제하는 식으로 진행하면 어떨까 합니다.
02 사용자가 에러 메시지를 제대로 쓰는 법
에러 메시지를 제대로 쓴다는 의미는 에러 메시지의 목적에 부합하게 작성한다는 것입니다. 그렇다면 에러메시지의 목적은 무엇일까요?
에러 메시지의 목적은 사용자에게 에러가 났음을 알려주는 것이 아니라 사용자 스스로 에러를 해결하게 하는 것이다.
사용자 에러에 대처하는 메시지
사용자 스스로 에러를 해결하게 하기위한 에러 메시지에는 에러의 내용, 에러의 원인, 에러의 해결 방법이 포함돼야 합니다.
에러 내용: 오류로 인한 문제와 종류에러의 원인: 오류를 발생시킨 직접적이고 근본적인 원인에러 해결 방법: 사용자가 오류를 해결할 가장 쉽고 빠른 방법
에러 메시지를 보여주는 순서
에러 메시지에는 에러의 내용, 에러의 원인, 에러의 해결 방법이 포함돼야 한다고 했습니다. 여기서 우리는 에러 메시지의 목적에 대해 다시 생각해봐야 합니다. 사용자가 에러를 스스로 해결하기에 충분하다면, 모든 내용을 작성할 이유는 없습니다.
오락가락 메시지와 버튼 메시지
에러 메시지 알림창에는 버튼이 함께 제시됩니다. 이 버튼은 주로 true, false의 의미로 제시되는데 이는 버튼의 본래 역할에 부합되지 않기에 사용자가 헷갈릴 수 있습니다. 그렇다면 버튼의 본래 역할은 무엇일까요?
버튼의 역할은 단순히 옳고 그름의 의견을 제시하거나 '예, 아니오'로 대답하는 것이 아니다. 버튼의 본래 역할은
특정한 행동을 유도하는 것이다.
예를 들어 페이지에서 나가는 것을 묻는 알림창이라면 페이지에서 나가는 것을 예, 아니오로 답하게 하는 것이 아니라 페이지에서 머물기, 페이지에서 나가기로 답하게 하는 것입니다.
가능하다면 '취소'라는 말보다 더 구체적인 행동을 말로 전하는 것이 좋다. 짧고 애매한 것보다는 길더라도 부명한 것이 더 낫다.
03 사용자의 에러를 줄이는 메시지 구조화
버튼의 순서
윈도우에서 '확인-취소'로 나오는 반면, 맥 OS에서는 '취소-확인' 순으로 제시됩니다. 현재 표준으로 정해진 바가 없기에, 서비스 내에서 일관성을 가지는 것이 중요합니다. 그리고 OS에 종속되지 않게끔 '확인-취소'가 아닌 행동을 유도하는 유니크한 버튼을 만드는 것도 좋은 방법일 것입니다. 물론 이 방법은 협업하는 개발자, UI/UX 담장자와 논의해 결정해야 합니다.
사용자의 반복 에러를 막는 법
반복되는 에러에 같은 에러 메시지를 노출하면 사용자는 주의하지 않습니다. 그리고 갑자기 자동입력 방지 문자같은 상황을 제시하면 사용자는 당황하게 됩니다. 이를 방지하기 위해 제한횟수를 갱신하면서 보여주게되면 사용자는 자기 행동에 주의하게 될 것입니다.
04 에러 메시지 대신 예방 메시지를 쓰자
에러를 줄이려면 개발자도 사용자의 사용 방식을 이해해야 한다. 사용자가 어떻게 사용할 지를 충분히 이해하고 조사하고 분석해야 에러를 줄일 방법을 찾을 수 있다.
서비스를 이해하면 에러를 예방할 수 있다
서비스를 개발한 이후에 사용자가 서비스를 이용하는 방식을 테스트해봐야 합니다. 그리고 개발자가 원하지 않는 방식으로 사용자가 이용하지 않도록 방지해야 합니다.
사용자를 이해하면 에러를 예방할 수 있다
사용자의 실수가 나오는 상황을 개발자가 예방 메시지를 띄움으로써 사용자가 스스로 결정하게 만들어줘야 합니다.
처음부터 에러 메시지를 예방 메시지라고 생각하면 에러를 없애는 단순 개발자가 아니라 사용성을 높이고 서비스를 활성화하는 비즈니스 감각이 있는 개발자가 될 것이다.
닭이 먼저? 알이 먼저?
저자는 에러 메시지에 대한 관점의 차이에 대해 이야기합니다.
사용자의 실수가 있고 이를 고치기 위한 에러메시지를 보여줄 것인가? 아니면 사용자의 실수를 예방하기 위한 메시지를 고안할 것인가? 이는 개발자의 철학의 문제라고 저자는 말합니다.
에러 메시지에 대한 김민성의 철학
이용에 멈춤이 없게 돕는
윤활유
에러 메시지는 사용자가 서비스를 원활하게 이용할 수 있도록 돕는 또 하나의 서비스라고 생각합니다. 사용자가 불편함을 느끼지 않게끔 최대한의 경우를 방지 하고 예방 메시지 를 제안하여 이용에 멈춤이 없게끔 도와야한다고 생각합니다.
느낀점
개발의 모든 경우에서 사용자의 경험을 중시해야 한다는 것을 느꼈습니다. 에러란 개발자가 생각하지 못한 방식으로 이용되는 경우입니다. 생각하지 못했다는 것은 개발자의 직무를 다하지 못했다는 변명이기에 계속해서 사용자의 사용방식을 고민하고 개선해나가야 합니다. 물론 생각치못한 부분에 대해서는 솔직하게 말하고, 알려주신다면 개선하겠다는 식의 에러메시지를 표현하는 게 좋지 않을까 생각합니다.
참고자료
- 개발자의 글쓰기 3장
- HTTP 상태 코드_MDN(https://developer.mozilla.org/ko/docs/Web/HTTP/Status)
