프로젝트

OAuth 회원가입/닉네임 등록 과정에서 만난 브레이킹 체인지 및 디버깅 기록

Chansman 2025. 6. 13. 03:40

📌 OAuth 소셜 로그인/닉네임 강제등록 실전 브레이킹 체인지 기록 (feat. Django DRF, JWT, 쿠키 인증)


🕓 0. 배경과 목적

  • 목표:
    • 네이버/깃허브 소셜 로그인 → JWT 쿠키 기반 인증 → 닉네임 강제등록 → 내 정보 호출까지
    • 실전 서비스 흐름을 Django DRF로 완성
  • 문제:
    • “회원가입, 인증 다 되는 줄 알았는데 계속 401/500 에러… 진짜 브레이킹 체인지가 한 번에 여러 개 터짐!”

⚡️ 1. 실전 문제 상황 (파일별, 변수별, 단계별 정리)

1) 비밀번호 임시 생성에서의 AttributeError

  • 문제 파일:
  • 에러 라인:
user.set_password(User.objects.make_random_password())
  • 에러 메시지:
AttributeError: 'CustomUserManager' object has no attribute 'make_random_password'
  • 원인 분석:
    • 커스텀 User 모델 사용 중 → Django 기본 메서드 없음
    • 공식 문서/StackOverflow 검색, 여러 시행착오 끝에 발견
  • 해결 과정:
    • User.objects.make_random_password() ❌
    • User.make_random_password() ❌
    • BaseUserManager.make_random_password() ❌
    • (최신 Django에서는 더 이상 지원X)
    • 최종 해결:
from django.utils.crypto import get_random_string
user.set_password(get_random_string(12))  # 12자리 랜덤 임시 비번

 

  • 정리:
    • 실무에선 "비밀번호 생성 함수는 Django 버전에 따라 직접 만들어야 한다"는 교훈.

2) 쿠키 기반 JWT 인증 실패 (쿠키명 불일치 & 인증기 오동작)

  • 문제 파일:
    • accountbook/authentication.py (커스텀 인증 클래스)
    • oauth/oauth_views.py (JWT 쿠키 발급 함수)
  • 문제 상황:
    • /api/users/me/에서 계속
    • json
       
{ "detail": "Authentication credentials were not provided." }

 

  • 쿠키에는 분명히가 정상적으로 발급돼 있는데 인증 실패
access=eyJ0eXAiOiJKV1QiLCJhbGci... (JWT)
refresh=...
  • 원인:
    • 인증기 코드:
raw_token = request.COOKIES.get('access_token')
  • 여기서 쿠키 이름이 access_token!

 실제로 발급한 쿠키 이름:

response.set_cookie(key='access', value=access_token, ...)

 

  • 실제 쿠키 이름은 access!
  • 해결 과정:
    • 여러 번 쿠키, 인증기, Swagger, 브라우저 콘솔까지 확인 후
    • 최종적으로 인증기 코드 수정:
      • 이름 일치시켜주니 바로 인증 성공!
raw_token = request.COOKIES.get('access')
  • 정리:
    • "실전 쿠키 기반 인증에선 쿠키명/변수명 불일치가 실제로 진짜 브레이킹 포인트!"
    • (로그 찍고, 쿠키-코드 동시 체크 강추)

3) Swagger, 브라우저, curl 간의 인증/쿠키 연동 난항

  • 문제 상황:
    • curl로는 회원가입/로그인 성공
    • Swagger/브라우저에선 인증 쿠키가 안 붙어 계속 401
  • 원인 분석:
    • curl로 access/refresh 쿠키를 받아도,
      브라우저/Swagger에선 직접 쿠키 저장/전달이 안 됨
    • 커스텀 인증기 없이 기본 JWTAuthentication만 있으면 헤더만 읽고 쿠키는 무시
  • 해결:
    • 브라우저 환경에서 회원가입/로그인 플로우 직접 밟기
    • 커스텀 인증 클래스(CookieJWTAuthentication) 설정 확인
    • F12 > Application > Cookies에서 쿠키 정상 발급되는지 반복 점검

4) 기타 브레이킹 포인트들

  • HTTPOnly, Secure, SameSite 등 쿠키 설정 옵션 차이
    • 로컬/배포 환경마다 쿠키가 안 먹히는 현상 반복
  • OAuth Provider(Naver/GitHub)에서 콜백 URL 미등록/오타
    • redirect/callback 단계에서 인증 실패

🔎 2. 디버깅 시도 & 시행착오 (실제 작업 흐름)

  • 구글/StackOverflow 검색만으론 안 풀림 → 실제 로그 print, 터미널 추적 필수
  • 쿠키, 인증기, 사용자 모델, Swagger 요청/응답 모두 하나씩 다 체크
  • 에러 터질 때마다 파일별로
    ① 어디서 무슨 변수명이 오타났는지
    ② 어떤 메서드가 없는지
    ③ 실제 response/request에 뭐가 들어오는지
    꼼꼼하게 확인

🛠️ 3. 실전 팁 & 주의사항

  • 쿠키명/인증기 key 반드시 일치!
    (access/access_token/Authorization 등 섞여 있으면 실무에서 반드시 막힘)
  • 비밀번호 생성 등 유틸 함수는 Django 버전마다 미묘하게 다르니 공식 문서+내장 모듈 적극 활용
  • curl, Swagger, 브라우저 각각 인증 유지 방식이 다름을 항상 염두에 둘 것
  • 서버 로그/Traceback에서 실제 터진 곳의 변수, 라인 번호 꼭 확인

4. 흔한 실수 vs 올바른 해결법

실수 사례올바른 해결법
커스텀 인증기에서 쿠키 이름만 다르게 썼다가 인증 실패 쿠키 발급/인증기 모두 같은 이름(access 등) 맞추기
커스텀 User에서 비번 생성 함수만 맹신했다가 함수 미존재 오류 get_random_string 등 내장 함수로 임시비번 생성
curl/Postman에서만 인증 확인하고 브라우저에선 동작 안 함 실서비스처럼 브라우저 환경/쿠키/리다이렉트까지 직접 검증
 

💡 5. 실무에서 배우는 진짜 교훈

  • "작은 변수명, 함수 하나가 전체 인증/회원가입/로그인 플로우를 멈추게 하는 blocker/브레이킹 체인지가 된다!"
  • 문제 생겼을 땐 내가 만든 모든 파일/코드/로그/쿠키/요청을 꼼꼼하게 한 번 더 확인
  • 직접 print/log/debugging으로 확인하는 습관을 들이면
    실무 어디서든 브레이킹 이슈 빠르게 잡을 수 있음!

최종 결론:
실무 OAuth/인증 플로우, 변수명/함수/환경 세팅 하나하나가 곧 브레이킹 포인트!
다시 안 겪으려면

  • (1) 코드/쿠키명 일치
  • (2) 버전별 함수 확인
  • (3) 실제 로그 꼼꼼히 보는 습관
    이 세 가지가 실전 경험의 핵심입니다!