오류의 층을 나눕니다
필수값 누락, 형식 오류, 서버 검증 실패와 네트워크 오류는 원인과 개선 방법이 다릅니다. 하나의 form_error로만 합치면 설명이 부족한지 전송 인프라가 실패하는지 알기 어렵습니다. 필요한 고정 분류를 정하고 화면이 보여주는 오류와 분석 코드가 같은 의미인지 확인합니다.
입력값을 수집하지 않습니다
가정한 예로 잘못된 이메일을 오류 문장에 포함해 화면에 보여줄 수 있어도 그 문장 전체를 분석으로 보내서는 안 됩니다. 필드 이름도 내부 DOM 식별자를 무조건 복사하기보다 승인된 코드로 매핑합니다. 자유 서술의 문의 내용이나 전화번호가 로그를 거쳐 전달되지 않는지 봅니다.
발생 시점의 의미
사용자가 제출을 시도했을 때의 실패와 입력창에서 포커스를 옮길 때의 경고를 구분합니다. 오류가 고쳐진 뒤 같은 코드가 다시 발생하는 상황을 새 시도로 볼지도 정합니다. 구현의 상태 변화 횟수를 사용자 행동 횟수로 잘못 집계하지 않게 이벤트 명세에 조건을 적습니다.
시나리오 검수
- 필수값을 비운 채 제출합니다.
- 형식 오류를 넣고 수정하는 과정을 실행합니다.
- 서버 거절과 네트워크 실패를 분리해 시험합니다.
- 이벤트 수·오류 코드·개인정보 유무를 확인합니다.
여러 오류가 동시에 있을 때 필드별로 보낼지 제출 시도 한 번으로 보낼지 결정합니다. 두 방식을 섞으면 오류 건수의 분모가 달라집니다. 키보드 Enter 제출과 버튼 클릭도 같은 정책으로 처리되는지 봅니다.
보고서에서의 활용
오류 안내가 스크린리더와 키보드 사용자에게 전달되는지도 확인합니다. 이벤트가 생겼다는 사실은 사용자가 수정 방법을 이해했다는 증거가 아닙니다.
오류율의 분모가 제출 시도인지 폼 시작인지 표시합니다. 특정 오류가 많다면 필드 설명과 입력 형식, 모바일 키보드를 함께 점검합니다. 오류 이벤트 수가 줄어도 검증 기능을 제거해 잘못된 접수가 늘었다면 개선이라고 볼 수 없습니다. 완료 기준은 실제 사용자의 수정 경로가 작동하고 오류의 종류와 발생 단위가 일관되게 관찰되는 상태입니다.
자주 묻는 질문
- 에러 메시지를 그대로 이벤트 라벨로 보내도 되나요?
- 메시지에 사용자가 입력한 이메일이나 내용이 포함될 수 있습니다. 고정 오류 코드와 필드 종류로 분류하고 실제 전송값을 확인해야 개인정보와 값의 무한 증가를 줄일 수 있습니다.
- 입력 중 오류가 열 번 보이면 실패도 열 번인가요?
- 검증 호출 수와 사용자가 제출에 실패한 횟수는 다릅니다. 무엇을 측정할지 정하고 반복 렌더링이나 매 타이핑으로 오류 수가 부풀지 않도록 합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.