구글 로그인 기반 회원가입 시 DB구조

 

 

 

 

구글 로그인(Google OAuth2/OIDC) 기반 회원가입으로 바꾸면 핵심은:

"비밀번호를 우리 DB에 저장하지 않는다"

 

가 가장 큰 차이다.

---

기존 일반 회원가입

보통:

ID/PW 직접 관리

 

한다.

DB 구조 예시

 

USER
- user_id
- login_id
- password_hash
- email

 

---

구글 로그인 기반이면?

사용자 인증 자체를:

Google이 담당

 

한다.

즉 우리 서비스는:

"이 구글 사용자가 누구인지"

 

만 관리하면 된다.

---

그래서 핵심 저장값

보통 가장 중요한 건:

Google의 고유 사용자 ID(sub)

 

다.

---

실제 OIDC 사용자 정보 예시

Google이 주는 정보:

 

{
  "sub": "1092381029381023",
  "email": "test@gmail.com",
  "name": "Hoon",
  "picture": "https://..."
}

여기서 핵심 : sub 이다.

왜 email이 아니라 sub 쓰냐?

이메일은: 변경 가능, 재사용 가능

 

반면 

sub는 Google 내부 불변 고유값

 

즉 진짜 사용자 식별자

 

---

실무 DB 구조 추천

USER 테이블

 

USER
- user_id
- email
- name
- status
- created_at

 

SOCIAL_ACCOUNT 테이블

 

SOCIAL_ACCOUNT
- social_account_id
- user_id
- provider
- provider_user_id
- provider_email
- created_at

 

예시 데이터

provider	provider_user_id
GOOGLE	1092381029381023
KAKAO	88123123

왜 테이블 분리하냐?

나중에 확장 가능

예:

하나의 USER에
Google + Kakao 연동

 

가능하게.

즉 구조

USER
↕
SOCIAL_ACCOUNT

 

추천.

---

로그인 흐름

STEP 1

사용자:

Google 로그인

 

클릭.

STEP 2

Google 인증 성공 후:

sub
email
name

 

받음.

STEP 3

DB 조회

 

SELECT *
FROM SOCIAL_ACCOUNT
WHERE provider='GOOGLE'
AND provider_user_id=?

 

STEP 4

없으면 회원가입.

있으면 로그인.

---

중요한 실무 포인트

---

1. Access Token 저장 여부

보통:

저장 안 하는 경우 많음

 

왜?

로그인만 필요하면:

Google 토큰 재사용 필요 없음

 

하지만 저장하는 경우

예:

• Gmail API
• Calendar API
• Drive 연동

사용 시.

이 경우

• Access Token
• Refresh Token

암호화 저장 필요.

---

2. 비밀번호 컬럼 어떻게?

소셜 전용 계정이면:

password NULL

 

가능.

하지만 실무 추천

로컬 로그인도 고려해:

login_type

 

구분 많이 둔다.

예시

 

USER
- login_type
-- LOCAL
-- GOOGLE
-- KAKAO

 

---

3. 이메일 중복 문제

엄청 중요.

상황

기존 일반회원:
test@gmail.com

Google 로그인:
test@gmail.com

 

정책 필요

보통 선택:

방식	설명
자동 연동	같은 이메일이면 연결
별도 계정	provider 기준 분리
사용자 선택	계정 연결 유도

실무 추천

보통:

이메일 검증 후 계정 연결

 

방식 많이 사용.

---

4. 탈퇴 처리

주의점.

DB에서 삭제해도

Google 계정 자체는 살아있음

 

이다.

즉 의미는

우리 서비스와 연결만 제거

 

하는 것.

---

5. JWT/Session은 별개

많이 헷갈림.

Google 로그인 성공 후에도 보통:

우리 서비스 자체 JWT 발급

 

한다.

왜?

매 API마다 Google 토큰 검증하면 비효율.

그래서:

Google 인증
↓
우리 서비스 세션/JWT 발급

 

구조가 일반적.

---

Spring Security 실무 구조

많이 쓰는 구조:

• Spring Security OAuth2 Client
• OAuth2UserService

---

로그인 성공 후

 

oauth2User.getAttribute("sub")

 

등으로 사용자 정보 추출.

그리고 자체 회원 처리

회원 조회
없으면 가입
있으면 로그인

 

실무 권장 구조 정리

추천

USER
+
SOCIAL_ACCOUNT
분리

 

---

provider_user_id(sub) 기준 식별

이게 핵심.

---

비밀번호 저장 안 함

Google이 인증 담당.

---

자체 JWT/Session은 별도 운영

실무 대부분 이 구조.

---

핵심 한 줄

구글 로그인 기반 회원 시스템에서는:

Google의 고유 사용자 ID(sub)를 기준으로 사용자를 식별하고,
우리 서비스는 별도의 USER/SOCIAL_ACCOUNT 구조로 회원 정보를 관리하며,
비밀번호는 직접 저장하지 않는 방식

 

이 가장 일반적인 실무 구조다.