[Feat] 유효성 검사 기능 추가

[kwiyoon]

🛰️ Issue Number

• close : [Feat] 회원가입 및 로그인 기능 - 검증 추가 #8

🪐 작업 내용

• CommonErrorCode 구조 개선
  기존 방식 : BaseErrorCode 클래스를 멤버로 사용하여 각 enum 상수마다 별도의 BaseErrorCode 인스턴스가 생성됨
  • 단순한 에러 코드 정보만 필요하다는 점을 고려하여 enum이 ErrorCode를 직접 구현하는 방식으로 변경
• ExceptionHandler 분리
• Valid 관련 커스텀 어노테이션 구현
• 커스텀 Validator interface 추가

✅ Check List

• 코드 작성 시 최선을 다했나요?
• 코드가 정상적으로 컴파일되나요?
• 테스트 코드를 작성 및 통과했나요?
• merge할 브랜치의 위치를 확인했나요?
• Label을 지정했나요?

[beomzun]

고생하셨습니다!! 하단의 코멘트 참고부탁드립니다ㅎㅎ

1. Controller에서 유효성 검증을 진행하고자 Validation 과정을 추가하신 것으로 이해했습니다!

• 제가 이해하기로는 @validated 는 Controller 외부 계층에서 검증하고자 할때 클래스단에 적용하고 @Valid 와 같이 사용하는 것으로 알고있습니다. 혹시 @Valid 가 아닌 @validated를 사용하신 이유를 여쭤볼수 있을까요? (제가 참고한 레퍼런스는 하단에 첨부하겠습니다!)
• https://mangkyu.tistory.com/174

2. ErrorCode 생성시마다 인스턴스가 생성되는것 맞습니다!

• 저도 이전에 수정해주신 방식을 사용하였고 지금의 방식으로 수정하였습니다. 제가 사용한 방식은 모든 에러 응답 형식을 정형화하고자 각 enum에서 composition 방식으로 구현하였습니다.
• 수정해주신 방식은 모든 에러코드에서 동일한 필드를 관리해야하고, 에러응답에 수정이 필요한 경우 모든 클래스에서 수정이 발생하는데 파급효과와 인스턴스 생성 비용의 트레이드오프 고려하신 것인지 여쭤보고 싶습니다!

[kwiyoon]

1. @validated와 @Valid의 차이를 명확하게 인지하지 않은 상태에서 사용을 했습니다. 둘 차이 인지 후 코드 수정했습니다! 피드백 너무 감사합니다 🥹
2. 계속하여 .getErrorCode()를 호출하는 방식이 복잡하게 느껴져 해당 방향으로 수정하였었는데, 유지보수가 어려울 거 같다는 범준님 말씀에 일리가 있는 거 같습니다. 해당 부분 수정하겠습니다!
3. 추가 고민사항
   도메인별로 에러코드를 관리하면 도메인 번호 지정 등의 문제로 관리가 어려울 것 같은데, 에러번호 지정시에 도메인 이름을 넣는 건 어떨까요?

• 얘기나눴던 수정 방향 : 도메인번호 + 일련번호 [ex) Member 도메인 번호 : 1 => 1001]
• 에러번호에 도메인 이름을 넣고 String으로 관리 [ex) MEMBER_001]