feature: 회원가입 api 개발

[Combi153]

📌 관련 이슈

• closed feature: 회원가입 api 개발 #112

📁 작업 설명

• 회원가입에 필요한 API 들을 개발했습니다.
  • 기존 로그인 api 수정
  • 금지 단어 검증 api 추가
  • 어종 검색어 자동완성 api 추가
  • 회원가입 api 추가
  • 물생활에 관한 회원 정보 기입 api 추가
• 기존 Member 객체를 AuthMember, Member 로 나누어 관심사를 분리했습니다.

작업 상세 설명

작업한 코드가 많아서 상세히 설명을 적어두려합니다. 정보 전달을 효과적으로 하기 위해 기획 및 디자인 등에 나타난 사실(Fact)과 그에 대한 구현(Impl)을 설명하겠습니다. 그후 Member 객체를 AuthMember, Member 로 나누어 관심사를 분리할 때 했던 고민과 결과를 설명하겠습니다.

Fact 1. 회원가입 버튼이 존재하지 않는다.

현재 펫쿠아는 카카오 로그인을 유일한 인증 방식으로 채택하고 있습니다. 회원가입을 위한 첫 번째 과정은 카카오 로그인을 하는 것입니다. OAuth가 아닌 펫쿠아만의 인증 방식이 따로 존재하지 않기에 회원가입 버튼 등을 누르지 않습니다.

따라서 서버는 로그인 API에서 사용자가 기가입한 회원인지 아닌지를 구분하고 사용자에 따라 다른 응답을 내려주어야 합니다.

Impl 1. 사용자에 따라 로그인 API 의 응답을 구분한다.

이러한 방식을 구현하기 위해 기존 로그인 API 리팩터링했습니다. 사용자가 회원인지 아닌지 구분하고 다음과 같이 다른 응답 코드를 내려주도록 했습니다.

상태	응답 코드	응답 헤더/본문
기가입 회원	200 OK	Authorization: AccessToken Set-Cookie: RefreshToken
미가입 사용자 (최초 로그인)	201 CREATED

---

Fact 2. 회원가입 API를 요청하기 위해 별도의 인증 과정이 필요하다.

로그인 API 응답을 통해 미가입 사용자인 것을 알게 되었을 경우, 클라이언트는 사용자를 회원가입 페이지로 이동시키고, 회원가입 API를 요청할 것입니다.

이때 서버는 회원가입 API를 요청하는 사용자가 "누구인지" 알야아 합니다. 서버가 사용자의 OAuth 정보(카카오 로그인 정보 ex. oauthId)를 DB에 기록하고 인증 과정에서 활용하기 때문입니다. 만약 서버가 사용자가 누구인지 모른 채로 회원가입을 진행한다면, 이미 가입한 회원이라도 매번 회원가입을 다시 하게 될 수 있습니다.

Impl 2. 미가입 사용자(최초 로그인)에게 임시 토큰을 발급한다.

회원가입 API의 인증을 위해 로그인 API 에서 미가입 사용자에게 임시 토큰(SignUpToken)을 발급하고 이를 Body에 담아 반환하도록 했습니다. 따라서 로그인 API의 응답은 다음과 같이 바뀌었습니다.

상태	응답 코드	응답 헤더/본문
기가입 회원	200 OK	Authorization: AccessToken Set-Cookie: RefreshToken
미가입 사용자 (최초 로그인)	201 CREATED	{ "signUpToken": "xxx.yyy.zzz" }

물론, 회원가입 API의 인증을 위해 반드시 임시 토큰을 사용해야 하는 것은 아닙니다. 기가입 회원에게 응답하는 것과 마찬가지로 AccessToken, RefreshToken 을 내려줄 수도 있을 것입니다. 그러나 다음과 같은 이유에서 AccessToken 을 직접 내려주는 선택은 배제했습니다.

1. 아직 회원가입을 완료하지 않은 회원에게 AccessToken 등을 제공하는 것은 안전하지 않습니다. AccessToken 은 특정 자원에 접근할 수 있는 권한을 포함합니다. 미가입 사용자에게 이러한 권한을 부여하는 것이 보안 문제를 일으킬 여지가 있습니다. 한편, 회원가입 조차 완료하지 않아 아직 어떠한 private한 자원도 갖고 있지 않은 사용자에게 AccessToken 을 제공하는 것 자체가 모순적입니다.
2. 미가입 사용자에게 AccessToken 을 제공하면 사용자가 이미 서비스에 가입했다고 착각할 수 있습니다. 이는 사용자에게 혼란을 초래할 수 있습니다.
3. 데이터 관리 측면에서도 AccessToken, RefreshToken 을 남발하는 것은 비효율적입니다.

회원가입 API를 요청할 때는 "Sign-Up-Authorization" custom 헤더에 임시 토큰을 넣어주면 됩니다. 서버는 임시 토큰을 바탕으로 사용자가 누구인지 구분하고, 카카오 정보와 회원 정보를 매칭시킵니다.

---

Fact 3. 물생활 정보를 입력하지 않은 사용자도 회원이다.

사용자가 서비스 이용 약관에 동의를 하고 나면, 물생활에 관한 전반적인 정보를 입력하게 됩니다. 그런데 이때 사용자는 정보를 입력하지 않는 항목 "일단 둘러볼게요" 등을 선택할 수도 있습니다. 정보를 입력하지 않고도 회원으로서 애플리케이션 이용이 가능합니다. 따라서 물생활에 관한 정보를 입력하기 전에 "회원가입"은 이미 끝나 있어야 합니다.

Impl 3. 회원가입 API와 물생활 정보 수집 API를 구분한다.

너무 간단하게도, API 를 분리하면 됩니다.

회원가입 API 에서는 마케팅 약관 정보에 대한 동의만 받고 AccessToken, RefreshToken 을 응답합니다.
물생활 정보 수집 API 에서는 다른 정보들을 추가로 입력하고 DB에 이 정보들을 저장합니다.

---

Fact 4. 이름 설정 시 부적절한 단어를 사용할 수 없다.

회원가입 이후 회원은 자신의 물생활 정보를 기입할 때 수조 이름을 설정합니다.

이때 수조 이름에는 부적절한 단어(금지 단어)를 포함할 수 없습니다.

Impl 4. 금지 단어 검증 API 추가

금지 단어는 클라이언트보다는 서버에서 관리하기 용이한 정보입니다. 금지 단어들을 DB에 저장해두었다가 필요에 따라 업데이트하면서 사용하는 것이 데이터의 일관성을 유지하기에 유리합니다.

클라이언트가 서버를 통해 수조 이름을 검증할 수 있도록 API 를 추가했습니다. 서버는 금지 단어 목록을 조회해오고, 수조 이름 안에 이러한 단어가 포함되는지 여부를 확인합니다.

이때 금지 단어 데이터에 대한 작업은 변화(Create, Update, Delete)보다 조회(Read)가 더 잦을 것이라 예상할 수 있습니다. 따라서 금지 단어를 캐싱해두었습니다.

interface BannedWordRepository : JpaRepository<BannedWord, Long> {

    @Cacheable("bannedWords")
    override fun findAll(): List<BannedWord>
}

---

AuthMember와 Member 의 분리 고민

기존에는 Member 객체가 회원의 정보를 모두 갖고 있었습니다. 회원 정보에는 카카오 로그인 정보, 닉네임 등이 있었습니다.

회원가입 API 를 작업하면서 Member 객체를 AuthMember, Member 로 분리할 필요성을 느꼈습니다. AuthMember 에는 카카오 로그인과 같은 인증 정보만 저장해두고, Member 에 도메인에서 사용할 정보를 저장하는 방식입니다. 분리의 필요성을 느낀 이유는 다음과 같습니다.

1. 다루어야 할 회원 정보가 많아졌습니다. 기존에 간결하게 만들어 둔 Member와 다르게 마케팅 수신 동의 여부, 수조 개수, 물생활 경력 등 다양한 Column 들이 추가되었습니다. 만약 이러한 정보들을 기존과 같이 모두 하나의 Table(Member Entity) 에 담게 된다면, Member 관련 작업을 할 때 사용하지 않아도 될 Column 까지 조회하는 일이 잦게 될 것입니다. 즉, 데이터를 다룰 때 비효율적인 부분이 생깁니다.

2. 중복 회원가입 등을 다루기에 편리합니다. 기존처럼 Member에 모든 데이터를 담게 된다면, 회원가입을 마치지 않았을 시점에도 Member 가 이미 생성되며 Member Table 에 일부 정보(카카오 로그인 정보 등)가 기록되게 됩니다.
   
   따라서 중복 회원가입을 여부를 확인하기 위해서는 사용자의 닉네임이 null인지 검증하거나, hasSignedUp 등의 boolean column 을 추가해 이를 확인하는 방법을 택해야 합니다. 사용자의 닉네임이 null 인지 검증하는 방법은 별도의 비즈니스 규칙에 의존하는 방법이기 때문에, 비즈니스 규칙이 변경되었을 때 더 이상 활용할 수 없게 됩니다. hasSignedUp column 을 추가하는 방법은 관리포인트를 늘리는 방법이라 비효율적입니다.
   
   만약 AuthMember와 Member 를 분리한다면, 회원가입을 마치기 전에는 Member 를 아예 생성하지 않을 수 있습니다. 카카오 로그인에 따른 정보만 AuthMember에 저장해두면 됩니다. 중복 회원가입을 검증할 때는 Member가 생성되었는지 여부를 판단하면 되므로 훨씬 편리합니다.

3. 확장과 유지보수에 강합니다. 인증 방식이 바뀐다거나, 도메인에서 사용할 회원 정보가 바뀌는 경우, AuthMember가 Member 를 분리되어 있을 때 서로에게 변화의 영향을 전파하지 않을 수 있습니다. 만약 하나의 Member 엔티티가 모든 정보를 관리한다면, 다른 종류의 두 변화가 서로에게 전파될 것입니다. 이는 확장에 매우 불리한 구조입니다.

AuthMember, Member 분리 결과

AuthMember에 Oauth 인증 관련 정보를 담고, Member에 도메인 회원 관련 정보를 담았습니다.

• 연관 관계
  Member 가 authMemberId 를 관리하도록 했습니다. 회원가입 플로우가 카카오 로그인 -> 회원가입 순으로 진행되어 AuthMember가 우선 생성되고 이후 Member 가 생성되므로 이러한 관계가 자연스럽다 생각했습니다. 또한 로그아웃, 회원 탈퇴(카카오 연결 해제)와 같이 Member 에서 AuthMember 를 필요로 하는 일이 더 잦아서 이러한 관계가 합리적이라 생각했습니다.

• AccessToken 생성 시 사용하는 Id
  AccessToken 을 통해 인가 로직을 필요로 하는 대부분의 기능이 도메인 회원과 관련이 있습니다. 찜, 장바구니, 주문 등의 기능들이 예시입니다. 따라서 AccessToken 에는 Member 의 id를 담을 수 있도록 했습니다.

• 의존성(패키지, Class)
  가장 숙고했던 부분입니다.

저는 AuthMember와 Member 를 분리하면서 Controller 와 Service layer 도 아예 다른 패키지로 각각 분리할 목적이었습니다. 그러나 두 패키지가 서로의 기능을 필요로 해 양방향 의존이 생겼습니다.

Auth 패키지에서는 로그인 기능에서 다음과 같이 Member 패키지의 클래스를 필요로 했습니다.

로그인
- MemberRepository 를 통해 Member 를 조회
- Member 를 통해 AccessToken을 생성

반대로 Member 패키지에서는 회원가입 기능에서 Auth 패키지의 클래스를 필요로 했습니다.

회원가입
- 회원가입 성공 시 AccessToken, RefreshToken 을 생성하기 위해 AuthTokenProvider 등을 사용

처음에는 두 패키지가 필요로 하는 기능이 모두 Token 관련 기능임을 알고 Auth 에서 Token 패키지를 분리하려고 했습니다. 그러나 현재 Auth와 Token이 매우 강하게 결합되어 있어, 쉽게 분리할 수 없었습니다. 결과적으로 다음과 같이 의존성 방향을 정리했습니다.

token 패키지에 TokenService 를 Interface 로 둡니다. auth 패키지에서는 AuthTokenService 가 TokenService 를 구현합니다. 그리고 AuthService(AuthFacadeService), MemberService 는 TokenService 를 의존하도록 합니다.

의존성의 큰 방향은 정리된 것으로 보이나, Authority class를 Member entity 가 다루는 점 등에서는 여전히 정리해야 할 코드들이 남아있습니다. 다만, Authority 는 앞으로 어떻게 사용될지 알지 못해 일단 두었습니다. 그밖에도 의도적으로 정리하지 않은 코드와 제가 놓친 코드가 섞여있을 것입니다. 모든 의존성을 다 정리하는 것도 좋지만 PR의 내용이 상당히 많으니 일단 리뷰를 주고 받고 소통을 거친 후에 추가적인 작업을 하는 것이 낫다고 판단했습니다.

여러분은 지금 구조의 의존성에 대해 어떻게 보시는지 적극적으로 의견 남겨주시면 감사하겠습니다.

기타

회원가입 API 가 이렇게 큰 작업량을 가질지 몰랐네요. 고봉밥 PR에 죄송합니다. 설명이 불충분한 부분에 대해서도 미리 사과 드립니다. 모든 질문 환영합니다. 제가 놓쳤다고 생각하는 부분이 있으시다면 과감하게 말씀 부탁드립니다!

[TaeyeonRoyce]

고생하셨습니다!!👍👍
회원 가입 정책도 까다롭고 디테일한 영역이 많았네요.
그래도 친절하게 설명 첨부해주셔서 다 확인했습니다!

몇가지 코멘트 남겨두었어요!

[TaeyeonRoyce]

이번 커밋에 국한된 리뷰는 아니지만, facade에서 @transactional 없이 Entity를 꺼내다 보니 EntitiyManager의 관리를 못받아서 변경감지가 잘 안되는 것 같더라고요!
나중에 이부분도 수정하면 좋을 것 같습니다!

[Combi153]

조회와 삭제 로직을 서로 다른 트랜잭션에서 작업하다보니 저는 어쩔 수 없는 부분이라고 생각하고 있었어요! 혹시 어떻게 수정하면 좋을 거라 생각하시나요?

[TaeyeonRoyce]

제가 생각했던건 memberId로 전달 받아서 한번더 꺼내는 방식이었습니다!

    fun delete(memberId: Long, authMemberId: Long) {
        memberRepository.deleteById(memberId)
        authMemberRepository.deleteById(authMemberId)

        cartProductRepository.deleteByMemberId(member.id)
        refreshTokenRepository.deleteByMemberId(member.id)
    }

[Combi153]

추후 고민해보고 적용하면 좋겠네요 👍
그런데 DB에 조회 요청을 한 번 더 날리는 것이 비용인데, 이 비용보다 편의가 더 크다고 생각하시는 걸까요?

[TaeyeonRoyce]

위 delete 로직에서는 커넥션이 추가되지 않을 것 같아요!
다른 메서드에서도, 예측가능한 connection에 대해선 대응 가능하고 문제 없다고 생각했어요..! (1개니깐...?)

오히려 Service Layer의 메서드를 호출 할 때, 도메인을 전달 해야하는게 어색하지 않을까 싶었습니다.
Facade 패턴에 굉장히 의존적인 코드가 않닐까 싶었습니다! (다른 Service는 도메인 전달 받는 경우는 없어서..?)

[hgo641]

로이스 좀 천재같아요

오히려 Service Layer의 메서드를 호출 할 때, 도메인을 전달 해야하는게 어색하지 않을까 싶었습니다.
Facade 패턴에 굉장히 의존적인 코드가 않닐까 싶었습니다! (다른 Service는 도메인 전달 받는 경우는 없어서..?)

이거보고 무릎침
도메인대신 id를 받게 통일하면 좋을 것 같네요! 생각도 못함

[Combi153]

어떤 말씀이신지 이해했습니다! 현재 Facade 가 Payment 에도 적용되어 있어서 다른 PR에서 작업하면 좋을 것 같습니다!

[github-actions]

Test Results

 56 files  +14   56 suites  +14   20s ⏱️ +3s
274 tests +62  274 ✅ +62  0 💤 ±0  0 ❌ ±0 
375 runs  +79  375 ✅ +79  0 💤 ±0  0 ❌ ±0 

Results for commit 6ebdfef. ± Comparison against base commit 92a71c0.

This pull request removes 5 and adds 67 tests. Note that renamed tests count towards both.

com.petqua.domain.member.MemberTest ‑ 로그아웃 처리를 한다
com.petqua.domain.member.MemberTest ‑ 삭제된 회원에 대해 삭제 여부를 검증하면 예외를 던진다
com.petqua.domain.member.MemberTest ‑ 회원 삭제 여부를 검증한다
com.petqua.domain.member.MemberTest ‑ 회원을 삭제한다
com.petqua.presentation.auth.AuthControllerTest ‑ Then: 회원이 삭제된다

com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 임시 토큰을 발급한다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 입력한 회원의 개인 정보를 삭제한다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 입력한 회원의 인증 정보를 삭제한다
com.petqua.application.auth.AuthFacadeServiceTest ‑ Then: 회원의 인증 토큰을 발급한다
com.petqua.application.fish.FishServiceTest ‑ Then: 관련된 어종 목록을 조회할 수 있다
com.petqua.application.fish.FishServiceTest ‑ Then: 예외를 던진다
com.petqua.application.fish.FishServiceTest ‑ Then: 입력한 개수만큼 관련된 어종 목록을 조회할 수 있다
com.petqua.application.member.MemberServiceTest ‑ Then: 닉네임을 여러 번 생성한다
com.petqua.application.member.MemberServiceTest ‑ Then: 닉네임을 한 번만 생성한다
com.petqua.application.member.MemberServiceTest ‑ Then: 동의 여부가 반영되고 회원의 닉네임이 생성된다
…

♻️ This comment has been updated with latest results.

[hgo641]

알찬 PR이군요...👍 내일 이어서 코멘트 달겠습니다!!!

[TaeyeonRoyce]

고생하셨습니다!!
리뷰 반영된 부분도 확인했어요!👍👍👍

회원과 관련하여 큼직한 산 하나 넘겼네요ㅎㅎ 고생하셨어요~!!

[hgo641]

으아아 코드 보는게 오랜만이라 속도가 더디네요... ㅠㅠ
내일 아침에 또 보고 추가할 게 있으면 추가하겠습니다.......ㅜㅜ🙇‍♀️

[hgo641]

고민을 많이 하신게 드러나는 아주 좋은 코드였습니다... 많이 배우고 갑니다👍👍👍
긴 작업하시느라 고생하셨습니다!