오류 안내, 화면 위와 입력칸 옆 중 어디에 둘까요?

방문 예약서를 채운 사람이 ‘예약하기’를 눌렀는데 다음 단계로 넘어가지 않습니다. 이메일 주소에 @가 빠졌다는 안내를 화면 위에서 보여줄지, 이메일 입력칸 옆에 보여줄지 비교해보려 합니다.

실제 서비스나 제 과거 프로젝트가 아닌, 오류 안내의 위치를 검토하기 위해 새로 만든 설계 예시입니다. 이미지의 이름과 입력값도 가상의 정보입니다.

AI 제작 · 설계 예시. 성과를 측정한 A/B 테스트 결과가 아닙니다.

같은 문구, 다른 위치

A와 B 모두 ‘이메일에 @를 넣어주세요’라고 안내합니다. 입력 항목, 이미 적은 값, 버튼, 안내 색상은 같게 두고 문구의 위치만 바꿨습니다. 비교가 흐려지지 않도록 빈 공간을 남겨 각 입력칸과 버튼의 높이도 맞췄습니다. 이 여백 자체를 최종 화면의 해법으로 제안하는 것은 아닙니다.

A에서는 제출이 멈춘 이유를 화면 위에서 알 수 있습니다. 다만 실제 모바일 화면에서 사용자가 아래쪽 버튼을 보고 있었다면, 위에 새 안내가 생긴 사실을 알아차릴지는 별도로 확인해봐야겠죠. 안내를 발견한 뒤에도 문구를 읽고 해당 입력칸을 찾아가야 합니다.

B에서는 잘못 적은 값과 고칠 방법을 가까이 볼 수 있습니다. 반면 오류가 여러 개 생기거나 입력칸이 화면 밖에 있다면, 눈앞의 한 항목만 고치고 다른 오류는 놓칠 가능성도 생각해볼 수 있겠습니다.

두 경우 모두 아직 검증하지 않은 가설입니다. 이 정지 이미지에서는 스크롤, 키보드, 포커스 이동이나 스크린 리더의 동작을 확인할 수 없으니까요.

발견하는 일과 고치는 일

GOV.UK Design System의 Error summary 가이드는 오류를 페이지 위에서 요약하고, 오류가 있는 입력 항목으로 연결하도록 안내합니다. Error message 가이드는 해당 입력 항목 옆에도 오류 문구를 보여주도록 합니다. 이 시스템에서는 둘 중 하나를 고르기보다 두 역할을 함께 제공하는 셈입니다.

이 자료를 읽으며 ‘안내가 잘 보이는가’와 ‘고칠 곳까지 쉽게 이어지는가’를 다른 질문으로 살펴보면 좋겠다는 생각이 들었습니다. 화면 위의 안내는 지금 무슨 문제가 있는지 알려주고, 입력칸 옆의 안내는 수정하는 동안 참고할 수 있게 해줄 수 있겠죠.

그래서 실제 예약 흐름을 만든다면 A와 B만 놓고 승자를 정하기보다, 요약에서 해당 입력칸으로 이동하고 그곳에서 같은 문구를 다시 확인하는 조합도 후보에 넣어보고 싶습니다. 다만 GOV.UK의 지침을 모든 제품에 그대로 적용해도 된다는 뜻은 아닙니다. 입력 항목 수와 제출 방식, 사용하는 기기 등을 놓고 검토해야 할 것 같습니다.

오류를 고치는 순간에는 잠시 멈췄던 과업을 다시 이어가야 합니다. 무엇이 잘못됐는지 기억한 채 화면을 오가는 부담을 줄일 수 있다면, 안내의 위치도 사람의 주의와 시간을 다루는 설계가 되지 않을까요?

테스트 질문을 조금 바꿔본다면

‘A와 B 중 무엇이 더 깔끔한가요?’ 대신 이렇게 물어보려 합니다.

“예약하기를 누른 뒤, 무엇을 고쳐야 한다고 생각하셨나요? 그 항목으로 가서 고쳐주세요.”

답변뿐 아니라 처음 시선이 간 곳, 다시 훑은 입력칸, 안내와 입력값 사이를 오간 과정도 함께 살펴보면 좋겠습니다. 같은 과업과 오류를 두고 화면 순서를 바꿔 보여주며, 한 오류를 고친 뒤 다른 오류도 발견하는지 확인해볼 수 있겠죠. 이후에는 키보드만 사용하는 흐름과 스크린 리더에서 안내가 어떻게 전달되는지도 별도로 검토하고 싶습니다.

이 이미지로는 이탈률이나 완료율의 우열을 말할 수 없습니다. 제가 확인하고 싶은 것은 ‘잘 보이는 안내’가 실제로 ‘고칠 수 있는 안내’까지 이어지는지입니다.

여러분이 다루는 입력 화면에서는 오류를 알아차리는 단계와 고칠 곳을 찾는 단계 중, 어느 쪽에서 더 자주 멈추나요?

출처

• GOV.UK Design System — Error summary
• GOV.UK Design System — Error message

2026년 10월 8일 원문 확인. 출처의 지침과 이 글의 설계 가설을 구분해 정리했습니다.