이음새 트러블 슈팅 정리(공통 닉네임 등록 페이지 이동 중 오류 발생)

[트러블슈팅] 소셜 로그인 이후 닉네임 설정 페이지로 이동하지 못하는 문제

🧩 기획 구조

프로젝트에서는 사용자 회원가입을 다음과 같이 2단계로 분리해서 처리하고 있었다.

• 1단계: 이름, 이메일, 비밀번호 입력
• 2단계: 닉네임 설정

자체 회원가입의 경우, 1단계에서 사용자가 입력한 정보를 localStorage에 저장해두고, 2단계 페이지(/signupNickname)로 이동 후 닉네임을 추가 입력 받아 최종 회원가입을 처리하는 방식으로 구현했다. 이 구조는 단순하고 사용자 경험도 나쁘지 않아 자체 회원가입 시에는 문제없이 작동했다.

소셜 로그인도 동일하게, 로그인 후 닉네임 설정은 필수로 받도록 기획했다.
하지만 소셜 로그인 후 닉네임 페이지로 이동한 시점에서, 필요한 사용자 정보가 없는 문제가 발생했다.

---

❗ 발생한 문제

소셜 로그인 후 /signupNickname 페이지로는 정상 이동된다.
문제는 이 페이지에서 사용자 정보(이름, 이메일 등)를 꺼내 쓸 수 있는 상태가 아니었다는 점이다.

자체 회원가입은 사용자가 직접 입력한 값을 localStorage에 저장하기 때문에
닉네임 페이지에서 쉽게 꺼내 쓸 수 있었지만,
소셜 로그인은 백엔드에서 OAuth 인증을 처리한 뒤 클라이언트로 리다이렉트되는 구조다.

즉, 로그인 후 클라이언트에서는 아무런 사용자 정보가 남아 있지 않고,
닉네임 설정 시 필요한 정보를 얻을 방법이 없었다.

---

🔍 문제 원인 정리

• 자체 회원가입은 프론트엔드에서 폼 데이터를 직접 다루기 때문에 localStorage 활용이 가능
• 소셜 로그인은 서버 주도 흐름 → 사용자 인증 정보를 서버에서 받고, 이후 클라이언트로 리다이렉트됨
• 이 과정에서 localStorage나 sessionStorage에 값을 저장할 타이밍 자체가 없음
• 결국 닉네임 페이지에서는 사용자 정보가 없어서 API 호출이 불가능

처음엔 자체 회원가입 로직을 그대로 재활용해서 소셜 로그인에도 localStorage를 활용해보려 했지만, 구조상 불가능한 방식이었다.

---

🔄 해결을 위한 접근

1) 사용자 정보를 URL query string으로 전달

소셜 로그인 성공 후, 서버에서 사용자 정보를 query parameter로 함께 전달하여 닉네임 페이지에 넘기는 방법을 시도했다.
예: /signupNickname?email=test@gmail.com&name=홍길동

하지만 이 방식은 개인정보가 브라우저 주소창에 노출된다는 보안 이슈가 있었고, URL 길이 제한, 히스토리 저장 등의 문제로 부적절하다고 판단했다.

2) sessionStorage 사용

서버에서 클라이언트로 넘긴 사용자 정보를 JS 실행 시점에 sessionStorage에 저장하는 방식도 고려했지만,
서버에서 클라이언트의 sessionStorage에 직접 접근할 수는 없고, 리다이렉션 직후 JS가 실행될 타이밍이 없기 때문에 현실적으로 불가능했다.

3) 임시 사용자 저장 + 단계적 회원가입 처리

결국 가장 깔끔한 해결책은, 소셜 로그인 성공 시 임시로 사용자 정보를 DB에 먼저 저장하고, 닉네임 설정 단계에서 나머지 정보를 채우는 방식이었다.

 

 

---

✅ 최종 해결 방식

DB에 isCompleted 컬럼 추가

• users 테이블에 isCompleted라는 boolean 타입 컬럼 추가 (기본값: false)
• 닉네임을 입력받기 전까지는 해당 사용자는 미완성 상태로 관리

 

흐름

1. 소셜 로그인 성공 시, 사용자 이름과 이메일을 받아 백엔드에서 사용자 레코드를 생성 (닉네임은 null, isCompleted=false)
2. 클라이언트는 해당 사용자 ID 또는 JWT 토큰을 전달받은 채 /signupNickname 페이지로 리다이렉트
3. 닉네임 입력 → PATCH /api/users/{id} 요청을 통해 닉네임 추가 및 isCompleted를 true로 변경
4. 닉네임 입력 완료 후 홈으로 이동하며 회원가입 완료 처리

---

회고

처음에는 자체 회원가입과 소셜 로그인 모두 동일한 구조로 처리하려 했다.
하지만 인증 방식이 다르면 데이터 흐름 자체가 달라진다는 점을 명확히 깨달았다.

소셜 로그인은 프론트엔드 주도가 아닌 서버 주도 흐름이라,

클라이언트에서 데이터를 직접 다루는 방식(localStorage 등)은 한계가 있었다. 이 점을 명확히 구분하지 못하고 동일한 처리 방식을 고집하면서 문제를 더 꼬이게 만들었다.

isCompleted와 같은 상태 컬럼을 활용하니,

• 회원가입 미완료 상태 추적이 가능하고
• 향후 다른 소셜 로그인 방식 확장 시에도 재사용 가능한 구조를 만들 수 있었다

또한 사용자에게는 단절 없는 회원가입 흐름을 제공하면서도,
서버에서는 데이터를 명확하게 통제할 수 있는 구조가 되었다.

결과적으로 프론트 코드도 단순해지고, 전체 회원가입 구조도 더 유연하고 확장 가능한 방향으로 개선할 수 있었다.