update sequence diagram

LoginController는 필요가 없다고 판단하여 현재는 비움.
추후에 프론트와 맞추면서 로그인 페이지에서 필요한 정보가 있다면 그때 추가할 수 있게 파일은 지우지 않음.

findByEmail로 판단하는 것보다 JPA의 exists 메서드를 사용하도록 구현함.
실제 쿼리는 `select member_id from meber_account where email = ? limit 1`이 수행되며 성능 상 더 좋은 결과를 예상할 수 있다.

@EnableWebSecurity 삭제

`handleMemberProcess()`에서 회원의 존재 여부를 판단 후 존재하는 경우의 프로세스와 존재하지 않는 경우의 프로세스 invoke
`handleExistingMember()`에서 회원이 존재하는 경우 `SharedPostPrincipal` 객체 반환
`handleNonExistingMember()`에서 회원이 존재하지 않는 경우 DB에 save하고 `SharedPostPrincipal` 객체 반환

소셜 로그인 시 발생할 수 있는 3가지 경우를 최적화하여 처리함
findByEmail()로 분기 처리

1. 첫 회원가입인 경우: saveMember() 호출
2. 이미 회원인 경우: return
3. 다른 소셜로 회원가입이 되어 있는 경우: throw Exception

2번과 3번의 경우 findByEmail 쿼리 1번
1번의 경우 findByEmail, save 쿼리 2번

데이터 일관성을 위해 반드시 DB에서 가져온 데이터로 SharedPostPrincipal 객체를 만들도록 설계함

기본적으로 JPA의 save 쿼리는 2번의 쿼리가 발생한다. 첫 쿼리는 id로 동일한 데이터가 있는지 확인한 후 insert 쿼리를 보내는데 현재 로직에서는 데이터가 중복인지 검증하는 코드를 직접 작성했기 때문에 불필요한 검증 쿼리가 발생하지 않도록 설정함