📝 김철수님의 '개발자의 글쓰기'를 읽고 정리한 글입니다. 문제가 될 경우 삭제 조치하도록 하겠습니다.

1. 에러 메시지를 쓰기 전에 에러부터 없애자

1.1 친절한 404, 불친절한 404

구글의 404 에러 페이지는 That’s all we know 인데 반해 네이버는 죄송합니다. 요청하신 페이지를 찾을 수 없습니다. 라고 친절하게 알려준다. 국내 서비스는 대부분 친절하게 알려주는 편이다.

1.2 404 에러가 죄송할 일인가?

그러면 404 에러가 죄송한 일인가? 404 에러가 뜨는 이유는 아래와 같다.

1. 사용자가 URL을 잘못 입력한 경우
2. 사용자가 링크를 클릭했으나 해당 페이지가 없는 경우

1번의 경우에는 사용자의 실수거나 장난이며 2번의 경우는 개발자의 문제이긴 하다. 이는 깨진 링크를 없애지 않는 개발자 잘못이다.

그래서 많은 사이트에서 죄송하다고 표시하는 것 같다.

1.3 깨진 링크는 개발자의 책임이다

정상적인 개발자라면 깨진 링크는 넣지 않을 것이다. 다만 예외가 있는데 외부 사이트에서 자신의 사이트의 링크를 넣는 경우이다.

내 생각은 약간 다르다. 페이지의 URL 바뀌는 경우가 꽤 있기에 이는 문제가 된다. 저자는 구글 서치 콘솔에서 깨진 링크를 찾으면 된다고 하는데, 외부 사이트에서 내 사이트를 연결한 경우가 문제다.

나만 확인한다고 모든 사이트가 내 링크를 확인해 주진 않을 것이다. 그러면 필연적으로 내 페이지의 404에러를 보게 될 것이라고 생각한다.

그래서 나는 저자의 생각과 다르게 404 에러 페이지에다가 사과를 하는 등 문구를 좋게 표시하는 게 좋은 거 같다.

1.4 개발자용 에러 메시지와 사용자용 에러 메시지를 분리하자

개발 중 혹은 테스트 중에 개발자용 에러 메시지를 사용하는 경우가 많다. 이는 실수로 지우지 않고 배포하게 될 가능성이 높다.

이런 경우를 피하려면 개발자용 에러 메시지와 사용자용 에러 메시지를 분리하면 좋을 것이다.

2. 사용자 에러 메시지를 제대로 쓰는 법

2.1 사용자 에러에 대처하는 메시지

사용자는 개발자가 의도한 대로 프로그램을 사용해야 하는데 그렇지 않은 경우가 많다. 이는 회원가입하는 것만 봐도 알 수 있다.

회원가입을 할 때 전화번호를 010-0000-0000 를 입력하면

✉️ 휴대폰 번호를 잘못 입력했습니다.

라는 에러가 뜬다고 가정해 보자 그러면 사용자는 없는 번호를 입력한 것인지 잘못 입력한 것인지 알 수 없어 사용자 경험이 매우 좋지 않을 것이다.

✉️ 휴대폰 번호는 -를 빼고 입력해 주세요. ex(01000000000)

이와 같은 에러 메세지가 뜬다면 사용자는 개발자의 의도대로 입력하게 되며 사용자 경험도 나빠질 리 없을 것이다.

이를 보면 에러 메시지의 목적은 사용자에게 에러가 났다고 알려주는 용도가 아니라 사용자 스스로 에러를 해결하게 하는 것이다.

따라서 아래 3가지가 포함되어야 한다.

1. 에러의 내용 : 오류로 인한 문제와 종류
2. 에러의 원인 : 오류를 발생시킨 직접적이고 근본적인 원인
3. 에러 해결 방법 : 사용자가 오류를 해결할 가장 쉽고 빠른 방법

2.2 에러 메시지를 보여주는 순서

앞에서 에러 메시지에 포함되어야 할 3가지를 순서대로 서술했다. 그런데 에러 내용과 원인이 복잡할 때는 에러 해결 방법을 먼저 보여주고 나머지의 내용과 원인을 간결하게 보여주면 된다.

2.3 오락가락 메시지와 버튼 메시지

나쁜 예

✉️ 지금 이 페이지를 떠나면 편집한 내용이 취소될 수 있습니다. 취소하시겠습니까?
(예, 아니오)

이 알림창은 예를 누르면 이 알림창을 닫는 건지 이 페이지를 나가는 건지 헷갈릴 수 있다. 해당 메시지는 취소 라는 단어를 2번 써서 그렇기도 하다.

✉️ 편집한 내용을 삭제하고 다른 페이지로 이동하시겠습니까?
(예, 아니오)

그러면 이렇게 쓰면 좋은가? 그것도 아니다. 이는 개발자적인 true, false의 사고방식이다. 버튼은 특정한 행동을 유도하는 것이기에 좋지 않은 방식이다.

좋은 예

그렇다면 좋은 예는 뭘까? 페이스북에서 글을 쓰다가 다른 페이지로 이동할 때 뜨는 에러 메시지를 보면 잘 알 수 있다.

✉️ 아직 글을 올리지 않았습니다. 올리지 않고 나가시겠어요?
(이 페이지에 머물기, 페이지에서 나가기)

이렇게 취소라는 말보다 더 구체적인 행동을 말로 전하기에 사용자가 헷갈릴 일이 없어 더 좋은 에러 메시지이다.

그렇다면 위의 나쁜 예를 아래와 같이 수정하면 좋은 예가 될 것이다.

✉️ 편집한 내용을 삭제하고 다른 페이지로 이동하시겠습니까?
(삭제하고 이동하기, 계속 편집하기)

3. 사용자의 에러를 줄이는 메시지 구조화

3.1 사용자의 에러를 줄이는 메시지 구조화

페이스북, 크롬, 윈도우, MacOS에서 버튼의 확인-취소 순서는 뒤죽박죽이다. 그래서 내 서비스에서 확인-취소의 순서를 고민하게 될 텐데 이는 OS나 타 서비스를 따르는 것보다는 내 서비스에서 정한 대로 일관성을 유지하면 유저들이 헷갈리지 않을 것이다. 더불어 취소에는 빨간색 글자를 사용한다 던지 UI/UX적으로도 좋게 할 수 있다.

2.3에서 언급한 확인-취소보다 행동을 명확하게 표시하는 게 좋을 것이다.

3.2 사용자의 반복 에러를 막는 법

사용자가 로그인을 할 때 비밀번호를 여러 번 틀리는 경우가 있을 것이다. 사용자가 이런 행동을 내버려 두는 것은 사용자 경험에 좋지 않기에 로그인 틀린 횟수와 시도 가능한 횟수를 표시해 주면 사용자는 더 집중하고 주의해서 비밀번호를 입력하게 될 것이다.

이는 초창기의 인터넷 뱅킹을 보면 알 수 있다. 비밀번호를 5번 틀리면 무작정 로그인을 막아버렸었는데 해당 은행에게 문의가 엄청나게 왔다고 한다. 하지만 로그인 시도 횟수를 표시하고 나서는 문의가 많이 줄어 비용도 줄었다고 한다.

이렇게 에러 메시지는 사용자 경험을 위한 것도 있지만 서비스를 운영하는 개발자 입장에서도 선한 효과를 갖다 준다. 무엇보다 사용자 경험이 좋으면 애플의 포장에서 오는 디테일의 감동과 사용자는 팬이 될 것이다.

4. 에러 메시지 대신 예방 메시지를 쓰자

4.1 서비스를 이해하면 에러를 예방할 수 있다

에러를 줄이려면 개발자도 사용자의 사용 방식을 이해해야 한다.

사용자가 어떻게 사용할지 충분히 이해하고 테스트를 해봐야 한다.

예를 들어 예약 앱을 보면 알 수 있는데 사용자 관점에서 보지 않은 개발자는 그냥 달력을 만들 것이다. 하지만 사용자 입장에서는 이전 날짜도 선택할 수 있게 해 의도치 않는 에러를 보게 될 것이다. 이러한 참사를 방지하려면 사용자 관점에서 생각하면 에러를 예방할 수 있을 것이다.

그렇다면 사용자 관점에서 서비스를 이해했다면 달력은 어떻게 구현하면 되겠는가? 이전 날짜를 비활성화해서 선택 자체를 막아 놓으면 에러 자체를 발생하지 않게 할 수 있을 것이다.

4.2 사용자를 이해하면 에러를 예방할 수 있다

위와 느낌이 비슷하지만 이 헤더는 사용자 입력에 중점적이다.

계좌번호를 입력하는 칸이 있다고 보자

• 0000000000000000
• 0000 0000 0000 0000

어떤 게 보기 좋냐고 물으면 2번째가 무조건 좋다. 사용자가 오타를 식별할 수도 있어 오타도 줄어들 것이다. 비슷한 예시로 이메일을 선택해서 입력받는 것과 CapsLock이 켜져 있습니다. 라는 토스트창을 볼 수 있을 것이다.

4.3 닭이 먼저? 알이 먼저?

사용자가 결제 요청 버튼을 누르면 재확인을 해야 하는가? 아니면 결제 요청 버튼을 눈에 띄게 버튼으로 만들어야 하는가? 이는 철학의 문제이다.

개발자가 사용자가 불완전한 존재로 인식하면 항상 경고 메시지가 뜨는 것이며 이는 시스템이 불완전해진다고 한다. 사용자를 성인이 아닌 미숙하로 취급하는 것이라고 한다. 그렇게 개발자에 철학에 따라 경고를 넣냐 안 넣냐도 나뉜다고 개발자 철학에 달렸다고 한다.

나는 저자의 철학과는 다르게 중요한 기능을 하는 버튼들에는 항상 경고 메시지가 들어가는 걸 추구한다. 물론 본 글에서는 결제 시스템에 대해 취약점을 예로 들었지만 그래도 나는 경고가 있어야 한다고 본다.

실제로 어른이 아닌 얘기들이 실수로 버튼을 클릭할 수 있으며 주머니나 무의식 속에서 의도치 않게 클릭할 수도 있기 때문에 항상 경고창을 표시하는게 좋다고 본다.

5. 3장을 읽고 느낀 점

• 에러 핸들링이 사용자 경험은 물론 개발자에게도 좋은 경험을 준다.
• 개발용 에러 메시지와 프로덕션용 에러 메시지를 분리해서 사용하자.
• 사용자가 어느 에러 메시지를 반복해서 본다면 UI/UX적으로 집중 할 수 있도록 표기하자.
• 개발자 관점 말고도 서비스를 이해하고 사용자 관점에서도 생각해 보고 테스트를 하자.
• 에러 메시지 버튼에 확인-취소 말고 구체적인 행동을 넣자.
• 중요한 버튼에는 경고 창을 띄어주자