[ALL] 임시 회원 → 가입 회원 데이터 연동

[gitchannn]

(23.09.14 추가)

연동 성공하고, 내용 포스팅했습니다.
아래 링크 들어가서 보는게 더 읽기 편해요!

[우테코] 임시 회원 ↔ 가입회원 데이터 연동기(1): 6가지 시도와 실패한 이유(JPA 상속 관계 매핑의 한계)
[우테코] 임시 회원 ↔ 가입회원 데이터 연동기(2): 테이블 구조 대공사, 데이터 연동 API 구현!

---

현재 우리 서비스는 전화번호를 통한 간편한 적립을 우리 서비스의 핵심 가치로 생각하고 있다.

따라서 이전에 스탬프크러쉬 서비스에 가입한 적이 없던 고객도 전화번호만 눌러서 간편하게 적립을 할 수 있어야 하고, 이후에 직접 웹사이트로 들어와 서비스를 이용하려면 간편한 회원가입을 해야 한다.

이 때, 간편 회원가입을 하게 되면, 기존에 임시 회원(비회원)일 때 쌓아두었던 데이터를 모두 연동해야 한다.

우리 데이터베이스 구조는 위와 같다.

Diagram으로 나타내면 아래와 같다.

임시 회원 데이터 연동을 위해 정리한 플로우는 크게 아래와 같다.

1. 회원가입 (절차에서 전화번호 입력 없음.)
2. 회원가입 이후에 등록할 전화번호 입력
3. 입력받은 전화번호가 이미 존재하는지 전화번호로 고객 조회 API 호출
4. 조회 결과에 따른 대응
   • 가입 회원 중에서 이미 해당 번호가 존재하는 경우 ⇒ 전화번호 등록 거부 (재입력 요구)
   • 임시 회원 중 이미 해당 번호가 존재하는 경우
     • 프론트엔드에서 데이터를 연동할 것인지 물어봄
       • 연동하기 선택 ⇒ 데이터 연동 API 호출
       • 거부 선택 ⇒ 전화번호 등록 거부 (재입력 요구)
   • 회원 중에 해당 번호가 존재하지 않는 경우 ⇒ 전화번호 저장 API 호출

결과적으로 3가지 API를 통해서 해당 작업을 할 수 있다.

이미 전화번호 저장 API는 만들어져 있으므로, 그대로 사용하도록 했다.

사실 이미 전화번호로 고객을 조회하는 API는 사장모드에서 사용하기 위해 만들어 놓았다.

하지만 이 API를 사용하지 않기로 결정한데는 2가지 이유가 있다.

1. 조회된 회원이 Register Customer, Temporary Customer 중 어떤 것인지 확인하지 못한다.
2. 사장 모드를 위해 만들어진 API이기 때문에, 해당 API를 고객모드에서도 활용한다면 응집도가 낮아진다.

그러면, 위 내용을 바탕으로 3가지 API를 아래와 같이 설계했다.

전화번호로 고객 조회 API

Request

GET /api/customers/profiles/search?phone-number=01038626099 HTTP/1.1
Authorization: Bearer k21h3keeoiu3k2lkl12j3kdksuhxcb_120909

Body

None

Response

Header

HTTP/1.1 200 OK

Body

• 해당 전화번호의 임시 회원(Temporary Customer)이 존재하는 경우

{
	"customers": [
		{
			"id": 300,
			"nickname": "6099",
			"phoneNumber": "01038626099",
			"registerType": "temporary"
		}
	]
}

• 해당 전화번호의 가입 회원(Register Customer)이 존재하는 경우

{
	"customers": [
		{
			"id": 300,
			"nickname": "6099",
			"phoneNumber": "01038626099",
			"registerType": "register"
		}
	]
}

• 해당 전화번호의 회원이 존재하지 않는 경우

{
	"customers": []
}

데이터 연동 API

Request

POST /api/profiles/link-data HTTP/1.1
Authorization: Bearer k21h3keeoiu3k2lkl12j3kdksuhxcb_120909

• URI 이름은 좋은 게 생각이 안나서 임시로 일단 만들었음.

Body

{
	"id": 300
}

• 기존에 존재하던 temporary customer의 id를 넘겨주면 됨.

Response

Header

HTTP/1.1 200 OK

Body
None

전화번호 저장 API

그리고, 마지막으로 이전 스프린트에 만들었던 전화번호 저장 API다.

Request

POST /api/profiles/phone-number HTTP/1.1
Authorization: Bearer k21h3keeoiu3k2lkl12j3kdksuhxcb_120909

Body

{
	"phoneNumber": "01038626099"
}

Response

Header

HTTP/1.1 200 OK

Body

None

데이터 연동의 구체적인 방법

우리 Customer 테이블은 상속 구조를 조인 전략으로 구현했지만, 아래 설명의 편의를 위해서는 하나의 테이블에 합친 단일 테이블 전략으로 설명하겠다.

레코드 주소는 DB 상에 보이지는 않지만, 설명의 편의를 위해 추가했다.

• 과거에 존재하던 Customer Table 내 임시 회원의 레코드

Customer Table

레코드 저장 위치	id	nickname	phone_number	dtype	oauth_provider	oauth_id
1004	2	6099	01038626099	temporary	null	null

• 시간이 흘러, 회원가입을 했을 경우에 추가된 가입 회원의 레코드

레코드 저장 위치	id	nickname	phone_number	dtype	oauth_provider	oauth_id
2004	300	차영호	null	register	KAKAO	2966537070

데이터 연동은 두 레코드를 하나의 레코드로 합치고, 기존에 임시 회원으로 활동하던 당시의 Coupon 등에 이미 2번 id가 등록되어 있다.

따라서 데이터를 연동하기 위해서는,

• 2번 아이디를 사용하도록 함.
• 가입 회원의 nickname, dtype, oauth_provider, oauth_id를 사용하도록 함.

아래와 같은 방법을 생각해볼 수 있다.

1. 1004 레코드를 삭제한 후, 2004 레코드의 id를 2로 변경하고, phone_number를 update한다.
   • 우리 프로젝트에서 사용하는 MySQL의 InnoDB는 클러스터링 인덱스를 지원하는 스토리지 엔진이다.
   • 1004 레코드를 삭제한다면, pk를 기준으로 모든 레코드의 위치가 재구성될 가능성이 있다. (극한의 비효율)
   • 2004 레코드의 id를 2로 바꾼다면 해당 레코드의 저장 위치까지 1004로 바꿔야 한다는 문제점이 있다.
2. 1004 레코드의 dtype , nickname, dtype, oauth_provider, oauth_id를 update하고, 2004 레코드를 삭제한다.
   • 2004 레코드 이후에 더 많은 레코드가 쌓였을 지라도, 1004 뒤에 비해서는 덜 쌓였을 테니, 레코드 위치 재구성이 덜 치명적일 것으로 예상한다.

따라서 2번 방법을 사용해서 구현하는 것이 좋을 것 같다고 생각한다.

[youngh0]

연동 방법 2번째 동의합니다!

전화번호 겹치는건 해결 방법을 생각해봐야겠네요.
고생하셨습니다 😁

[gitchannn]

레오 컨펌 완료.

[2yunseong]

확인했습니다. 저는 문제 없어보여요~!

[yenawee]

깃짱 플로우 생각하느라 수고햇어요 짱짱

데이터연동 방법 저도 아까 들었을때 2번이 좋다고 생각했는데요..!

이게 temporary 랑 register 는 스키마가 달라서 기존 임시회원에는 oauthId 등의 column 이 없을거같은데 update 를 칠수가 있을까용??

[gitchannn]

pk는 어차피 customer 테이블에 들어있으니깐,
register_customer에 레코드 추가하고,
temporary_customer에서는 레코드 삭제하는 과정이 필요하긴 할 것 같네요...! ㅠㅠ

[regularPark]

좋은 아이디어네요! 구현되는 날을 기다리고 있습니당🥹

[gitchannn]

구구의 심리상담

• 현재 구조로 인해서 여기까지 한계를 느낌.
• Native Query로 dtype 바꾸는건 신입 개발자가 절대 알아볼 수 없는 코드임.
• 유지보수가 최악임.
• 지금이 최적이다.

깃짱, 제나, 레오의 결심

• dtype을 제거하고 enum으로 바꾼다.
• RegisterCustomer, TemporaryCustomer 없애고, 그냥 Customer만 사용하도록 한다. (상속 구조 없앰.)

[jundonghyuk]

현재 우리 서비스는 전화번호를 통한 간편한 적립을 우리 서비스의 핵심 가치로 생각하고 있다.

따라서 이전에 스탬프크러쉬 서비스에 가입한 적이 없던 고객도 전화번호만 눌러서 간편하게 적립을 할 수 있어야 하고, 이후에 직접 웹사이트로 들어와 서비스를 이용하려면 간편한 회원가입을 해야 한다.

이 때, 간편 회원가입을 하게 되면, 기존에 임시 회원(비회원)일 때 쌓아두었던 데이터를 모두 연동해야 한다.

우리 데이터베이스 구조는 위와 같다.

Diagram으로 나타내면 아래와 같다.

임시 회원 데이터 연동을 위해 정리한 플로우는 크게 아래와 같다.

1. 회원가입 (절차에서 전화번호 입력 없음.)

2. 회원가입 이후에 등록할 전화번호 입력

3. 입력받은 전화번호가 이미 존재하는지 전화번호로 고객 조회 API 호출

4. 조회 결과에 따른 대응

   • 가입 회원 중에서 이미 해당 번호가 존재하는 경우 ⇒ 전화번호 등록 거부 (재입력 요구)

   • 임시 회원 중 이미 해당 번호가 존재하는 경우

     • 프론트엔드에서 데이터를 연동할 것인지 물어봄

       • 연동하기 선택 ⇒ 데이터 연동 API 호출
       • 거부 선택 ⇒ 전화번호 등록 거부 (재입력 요구)

   • 회원 중에 해당 번호가 존재하지 않는 경우 ⇒ 전화번호 저장 API 호출

결과적으로 3가지 API를 통해서 해당 작업을 할 수 있다.

이미 전화번호 저장 API는 만들어져 있으므로, 그대로 사용하도록 했다.

사실 이미 전화번호로 고객을 조회하는 API는 사장모드에서 사용하기 위해 만들어 놓았다.

하지만 이 API를 사용하지 않기로 결정한데는 2가지 이유가 있다.

1. 조회된 회원이 Register Customer, Temporary Customer 중 어떤 것인지 확인하지 못한다.
2. 사장 모드를 위해 만들어진 API이기 때문에, 해당 API를 고객모드에서도 활용한다면 응집도가 낮아진다.

그러면, 위 내용을 바탕으로 3가지 API를 아래와 같이 설계했다.

전화번호로 고객 조회 API

Request

GET /api/customers/profiles/serach?phone-number=01038626099 HTTP/1.1
Authorization: Bearer k21h3keeoiu3k2lkl12j3kdksuhxcb_120909

Body

None

Response

Header

HTTP/1.1 200 OK

Body

• 해당 전화번호의 임시 회원(Temporary Customer)이 존재하는 경우

{
	"customers": [
		{
			"id": 300,
			"nickname": "6099",
			"phoneNumber": "01038626099",
			"registerType": "temporary"
		}
	]
}

• 해당 전화번호의 가입 회원(Register Customer)이 존재하는 경우

{
	"customers": [
		{
			"id": 300,
			"nickname": "6099",
			"phoneNumber": "01038626099",
			"registerType": "register"
		}
	]
}

• 해당 전화번호의 회원이 존재하지 않는 경우

{
	"customers": []
}

데이터 연동 API

Request

POST /api/profiles/link-data HTTP/1.1
Authorization: Bearer k21h3keeoiu3k2lkl12j3kdksuhxcb_120909

• URI 이름은 좋은 게 생각이 안나서 임시로 일단 만들었음.

Body

{
	"id": 300,
	"nickname": "6099",
	"phoneNumber": "01038626099",
	"registerType": "temporary"
}

• 해당 API는 registerType이 temporary인 경우에만 호출하는 것이 규칙이므로, 늘 저 형태로 명시해서 받으면 좋을 것 같음.

Response

Header

HTTP/1.1 200 OK
Location: /customers/300

Body None

전화번호 저장 API

그리고, 마지막으로 이전 스프린트에 만들었던 전화번호 저장 API다.

Request

POST /api/profiles/phone-number HTTP/1.1
Authorization: Bearer k21h3keeoiu3k2lkl12j3kdksuhxcb_120909

Body

{
	"phoneNumber": "01038626099"
}

Response

Header

HTTP/1.1 200 OK

Body

None

데이터 연동의 구체적인 방법

우리 Customer 테이블은 상속 구조를 조인 전략으로 구현했지만, 아래 설명의 편의를 위해서는 하나의 테이블에 합친 단일 테이블 전략으로 설명하겠다.

레코드 주소는 DB 상에 보이지는 않지만, 설명의 편의를 위해 추가했다.

• 과거에 존재하던 Customer Table 내 임시 회원의 레코드

Customer Table

레코드 저장 위치 id nickname phone_number dtype oauth_provider oauth_id
1004 2 6099 01038626099 temporary null null

• 시간이 흘러, 회원가입을 했을 경우에 추가된 가입 회원의 레코드

레코드 저장 위치 id nickname phone_number dtype oauth_provider oauth_id
2004 300 차영호 null register KAKAO 2966537070
데이터 연동은 두 레코드를 하나의 레코드로 합치고, 기존에 임시 회원으로 활동하던 당시의 Coupon 등에 이미 2번 id가 등록되어 있다.

따라서 데이터를 연동하기 위해서는,

• 2번 아이디를 사용하도록 함.
• 가입 회원의 nickname, dtype, oauth_provider, oauth_id를 사용하도록 함.

아래와 같은 방법을 생각해볼 수 있다.

1. 1004 레코드를 삭제한 후, 2004 레코드의 id를 2로 변경하고, phone_number를 update한다.

   • 우리 프로젝트에서 사용하는 MySQL의 InnoDB는 클러스터링 인덱스를 지원하는 스토리지 엔진이다.
   • 1004 레코드를 삭제한다면, pk를 기준으로 모든 레코드의 위치가 재구성될 가능성이 있다. (극한의 비효율)
   • 2004 레코드의 id를 2로 바꾼다면 해당 레코드의 저장 위치까지 1004로 바꿔야 한다는 문제점이 있다.

2. 1004 레코드의 dtype , nickname, dtype, oauth_provider, oauth_id를 update하고, 2004 레코드를 삭제한다.

   • 2004 레코드 이후에 더 많은 레코드가 쌓였을 지라도, 1004 뒤에 비해서는 덜 쌓였을 테니, 레코드 위치 재구성이 덜 치명적일 것으로 예상한다.

따라서 2번 방법을 사용해서 구현하는 것이 좋을 것 같다고 생각한다.

저는 2번 방법이요.
1번 방법은 외래키 걸려있는 애들 때문에 힘들 것 같네요