유효성 검사(validation)의 역할과 방법, 목적 찾기

 

💡 validation은 서비스를 구현하다보면 반드시 마주하는 일 중 하나이고, 그만큼 기본적이며 필수적으로 밟아야 할 절차이다. 이번 주제에서는 validation이 무엇이고 왜 하는지, 보통 어디서 어떻게 검증하는지를 간략히 살펴보자. 그리고 클라이언트의 validation의 범위는 어디까지이며 어느정도의 검증이 적절할지를 고민해보자.

validation 하면 생각나는 모습은 바로 이런 것...

 

validation

validation이란 데이터가 어떤 특정 조건에 맞는 값을 가질 수 있도록 검사하는 것을 말한다. 유효성 검사는 서버에 데이터를 제출하거나, 사용자를 인증할 때 흔히 시행된다. 이러한 데이터 검증은 클라이언트 단에서만 검증하는 경우도 있고, 서버의 결과값에 의존하는 경우도 있다. (예외적 상황에 대한 대비는 서버, 클라이언트 모두 필요하다!)

 

클라이언트의  validation

유효성 검사는 사용자 경험과도 밀접한 연관이 있다. 클라이언트에서는 잘못된 데이터 입력을 초기에 잡아서 사용자가 제출 전 수정할 기회를 주는 것이 좋다.

이 때 가능한 많은 정보를 제공해서 입력을 수정하도록 안내하는 것이 중요하다.
잘못된 데이터가 서버에 도착해서 거부당하고, 다시 사용자가 데이터를 수정하는 과정을 거치지 않도록 설계하면 사용자의 피로도를 낮출뿐만 아니라 네트워크의 비용도 감소되는 효과가 있다.

 

CASE 2가 CASE 1에 비해서 단계가 적다. 당연히 CASE 2에서 유저가 피로감을 덜 느낀다.

 

입력한 값에 대한 검증은 최대한 그 자리에서 끝낼 수 있도록 정보를 제공하고, 사용자가 최종적인 입력을 마친 후 제출 버튼을 누를 수 있도록 하면, 위에서 언급한 것처럼 불필요한 네트워크 요청을 줄이고 사용자의 경험을 향상시킬 수 있다.

 

 

브라우저 단에서의 validation 방법

클라이언트 영역에서의 validation 방법에 대해서도 잠시 짚어보자.

• 먼저 자바스크립트에 의존하지 않아도 HTML의 태그 속성에서 데이터를 어느정도 검증할 수 있다.
  • required, minlength/maxlength, min/max, type , pattern 등을 사용한다.
• 자바스크립트의 validation 방법은 직접 input이나 데이터 값을 검사하는 로직을 짜는 방법과, 거의 모든 브라우저를 지원하는 Contstraint Validation API 를 사용하는 방법이 있다.
  • validation Message : 유효성 검사에 걸릴 경우 제약 조건을 설명
  • checkValidity() : 유효성 검사가 통과되면 true, 아니면 false 값 반환
    • 값이 유효하지 않으면 알리는 유효 조건을 알릴 수 있는 이벤트도 발생시킴
  • validitystate 유효성 상태를 설명하는 객체 반환
  • setCustomValidity(message) : 사용자 정의 오류 메시지 추가

Client-side form validation - Learn web development | MDN

• Vue
  • 일반적으로 컴포넌트 단에서 validation을 가져간다.
  • Form Validation - Vue.js
  • 상황마다 다르겠지만 validation의 로직이나 조건등을 store에 저장하지는 않는다. 여러 컴포넌트에서 데이터가 공유되지 않는다면 해당 컴포넌트에서 처리가 가능하도록 하는 것이 좋다. store에 많은 로직을 담게 되면 애플리케이션에 부담을 주기 때문이다.

 

validation의 적절한 정도 찾기

이 쯤에서 validation을 더 들여다보자. 데이터 검증은 어느 범위까지 진행하는 것이 좋을까?
validation이 어느 정도로 어디까지 이루어져야 예외적 상황이 최대한 방어될까?

• 데이터는 어디서든 검증될 수 있고 (단순한 if문을 통해서라도), 검증의 기준은 느슨할 수도, 엄격할 수도 있다.
• 아무런 예외가 일어나지 않을 것 같은 이상적인 validation 절차를 만들어내서 사용하고 싶겠지만 역시나 상황은 언제나 다르고, 리소스는 제한적이다.
• 입력한 데이터는 클라이언트뿐만 아니라 서버의 여러 단계를 거쳐 데이터베이스에 들어갈 것이다.

모든 곳에서 100% 로 예외를 막아내는 것은 현실적으로 거의 불가능하다. 레이어마다 검증하는 단계와 검증의 목적을 잘 구분해놓고, 구분된 단계들이 일관적으로 잘 수행된다면 나쁘지 않은 효율로 최대한 많은 예외를 막아낼 수 있을 것 같다.

 

레이어마다의 검증이라는 말은 좀 추상적이니 예를 들어보자.

1. 브라우저 단에서는 유저가 기대값을 입력할 수 있도록 검증하고, 조건에 불만족하거나 검증되지 않은 데이터라면 요청을 막아야한다.
2. 그럼에도 버그나 어떤 이유에 의해서 해당 검증이 뚫려 요청에 성공한다면? graphql 을 사용한다고 해보자. 스키마에 맞지 않는 데이터를 요청하면 에러를 발생시킨다. 즉 통신부에서 어느 정도 자체적으로 validate 를 하고 있다.
3.  전 단계들에서 데이터가 어느정도 검증된 상태이니 추가적인 검증 단계가 필요하다면 비즈니스 로직에서 수행한다.
4. 모든 검증 단계가 완료된 데이터가 DB에 들어간다.

역시 중요한 것은 검증 기준의 일관성 은 반드시 유지되어야 한다는 점이겠다.

 

클라이언트는 서버에 어떤 데이터를 주느냐도 중요하지만 사용자의 UX 개선에도 중심을 두어야 한다는 점을 고려해봤을 때, 클라이언트에서의 validation 역할은 결국 이 데이터가 포맷은 비즈니스적으로 정말 완벽히 유효한 값인지를 검사하는 것보다는, 데이터의 포맷 정도를 예외가 없도록 잘 검증해서 서버에 던져주는 것이다. 그리고 사용자가 어떤 데이터 값을 입력해야하는지에 대한 정보를 충분히 주는 것을 통해 더 나은 사용자 경험을 가져갈 수 있도록 하는 것이라 생각한다! 실제 클라이언트에서 주는 정보는 중간에 어떤 조작이 일어날지 알 수 없기 때문에 서버는 그에 대한 무조건적인 신뢰를 할 수 없기 때문이다!

 

 

 

 

- 도움이 된 자료

- https://softwareengineering.stackexchange.com/questions/81062/data-input-validation-where-how-much

Data input validation - Where? How much?

- https://elvanov.com/2414

데이터 검증 (Data Validation)은 언제, 얼마나 해야 할까? – Under The Pencil