브라우저 기본 유효성 검사와 커스텀 유효성 검사, 무엇이 더 좋을까?

이번에 웹 프론트엔드 보안 스터디를 진행하면서 HTML의 다양한 속성을 활용하여 간편하게 유효성 검사를 설정하는 것에 대해서 학습하게 되었다. 책을 읽는 과정에서 들었던 궁금증에 대해 고민해보고 답을 찾는 시간을 가졌던 것을 글로 적어보았다.

웹 form을 만들다 보면 input 태그에 pattern, required 등 HTML 속성을 활용해 간편하게 유효성 검사를 설정할 수 있다. 특히 pattern 속성은 정규표현식을 통해 특정 패턴을 강제할 수 있어서 자주 활용된다.

하지만 브라우저의 기본 유효성 검사를 사용할 때는 늘 한 가지 고민이 생긴다. 브라우저에서 제공하는 유효성 알림창은 디자인 커스터마이징이 어렵고, 사용자 경험을 해치거나 서비스의 UI와 어울리지 않는 경우가 많다는 점이다.

이러한 이유로 많은 개발자들이 브라우저 기본 유효성 검사를 꺼버리고, 자바스크립트나 프레임워크 내부 로직을 통해 직접 유효성 검사를 구현한다. 그렇다면, 유효성 검사를 어떤 방식으로 처리하는 것이 더 좋을까?


🖥️ 브라우저 기본 유효성 검사의 장단점

장점

  • HTML 속성만으로 쉽게 설정할 수 있다.
  • 스크린 리더를 포함한 보조기기에서 접근성이 우수하다.
  • 추가적인 로직 없이도 기본적인 유효성 검사 기능을 제공한다.

단점

  • 브라우저마다 디자인이 달라 통일된 UI 제공이 어렵다.
  • 사용자에게 보여지는 메시지를 커스터마이징하기 어렵다.
  • 커스텀 조건이나 비동기 검사(예: 이메일 중복 확인 등)를 구현할 수 없다.

🔨 직접 구현하는 커스텀 유효성 검사의 장단점

장점

  • UI/UX를 서비스의 스타일에 맞게 완전히 커스터마이징할 수 있다.
  • 실시간 검사, blur 시점 검사, 서버와의 연동 등 복잡한 로직 구현이 가능하다.
  • 오류 메시지를 구체적이고 직관적으로 설계할 수 있다.

단점

  • 개발 비용과 시간이 더 든다.
  • 접근성을 신경 쓰지 않으면 사용자에게 불친절한 폼이 될 수 있다.

어떤 방식이 더 좋을까?

방식 디자인 자유도 UX 제어 접근성 비동기 검사 추천도
브라우저 기본 낮음 제한적 기본 제공 안됨
JS 커스텀 높음 자유 구현 필요 가능 ⭐⭐⭐⭐
둘 다 병행 혼란 가능 이중 알림 가능 강화 구현 복잡 ⭐⭐ (권장 X)

결론적으로 브라우저 기본 유효성 검사는 단순한 폼이나 초기 프로토타입 단계에서는 유용할 수 있으나, 사용자 경험을 중요하게 생각하는 서비스에서는 커스텀 유효성 검사를 직접 구현하는 방식이 더 적합하다고 생각한다.

특히 커스텀 방식으로 구현하되, 접근성을 해치지 않도록 aria-invalid, aria-describedby 같은 WAI-ARIA 속성을 함께 사용하는 것이 좋다. 또한 <form> 태그에 novalidate 속성을 추가하면 브라우저의 기본 유효성 검사를 비활성화할 수 있어, 이중 알림을 방지할 수 있다.


결론

브라우저 기본 유효성 검사는 빠르게 적용할 수 있는 장점이 있지만, 사용자 경험이나 UI 일관성을 중요하게 생각한다면 커스텀 유효성 검사를 구현하는 것이 더 낫다. 개발자는 유효성 검사 방식의 선택에 있어 서비스의 성격, 사용자 환경, 접근성 기준 등을 종합적으로 고려해 적절한 방법을 선택해야 한다.

📚 참고

Comments