[#10] refactor: login service and anything related

[msugo1]

Issue

• 로그인 메소드를 각각의 컨트롤러에 구현을 해줘야 할까?
  = 현재, 세 다른 타입을 가진 멤버들이 존재하며, 각각 멤버들은 다른 repository를 사용한다.
  = spring security는 UserDetailsService를 구현하고, UserDetails 객체를 만들어 제공해주면, 자동으로 아이디/비밀번호를 DB에서 체크하여 해당 사용자가 제공한 credentials 들이 맞는지 확인해준다.
• 문제는

1. UserDetailsService를 구현할 때, loadBy ~ 메소드를 구현하게 되는데, 파라미터로 받는 것은 userId: String 하나 뿐이다..
2. 그래서, 어떤 타입의 사용자인지 체크할 방법이 없다...
   = 동적으로 로그인할 사용자에 맞는 repository를 제공하는 것은 불가능...
3. 로그인 메소드는 멤버 타입에 상관없이 아이디/비밀번호만 있으면 해결이 가능하다...

Idea

1. repository를 세개 모두 주입받아서 DB에 세번 체크?
   = 운 좋다면 한 번에 끝나겠지만, 최악의 경우에 DB에 세번의 요청을 보낸다;
   = 거기에 현재 프로젝트에서 그럴일은 없겠지만, 멤버 타입이 늘어나기라도 한다면??;;

2. userDetailsService를 각각 타입마다 구현한다.

• 추가로, SecurityConfig도 각각 설정해준다.

= 이 방법 괜찮아 보이긴 했는데, 설정을 위해서는 뭔가 Priority가 필요하다. (세 사용자 간의 우선순위를 매기기가 불가능해서, 현재 단계에서는 priority를 어디에 부여할 지 애매하다.)
= 설정 중복의 가능성. url 별로 다른 처리가 가능해보이기는 하는데, 예시를 보니 모두 중복설정이 들어가 있다;
= 공통 설정을 묶어주기가 애매하다 (현 상태에서는)
= 요 방법을 적용하려면 뭔가 더 많은 예시를 보고, 해당 내용에 대한 학습이 조금 더 필요해 보인다.
(하루 종일 구글 뒤졌는데... 뭔가 없다 ㅜㅜ)

3. 세 타입을 하나로 묶어줄 방법이 없을까?
   = 좀 복잡하지만 떠올린 방법이 MemberSummary 테이블을 두어, 아이디/패스워드/멤버타입 을 두고, 로그인에 활용하는 것이었다.
   = 저장내용이 중복될 수 있는 부분은, 각 멤버 타입 엔티티에서 제거 한 후 MemberSummary 엔티티 <-> 멤버 타입 엔티티 간의 1:1 관계를 부여해주는 생각을 해봤다.
   = 멤버타입 엔티티를 가져올 때, 매번 조인이 발생하는 문제가 있다

Applied

• 일단 3번을 채택했다. 1번은 사실 가장 단순한 방법이지만, 가장 비효율 적이라 논외로 둔다.
• 프로젝트를 진행하면서 2번과 계속 비교/고민하면서, 2번이 조금 더 낫다면 바꿔줄 예정이다.