[D2C-35] 회원가입 화면 및 사용자 생성 흐름 구현

[jjunier]

개요

본 PR은 D2C-35 회원가입 화면 및 사용자 생성 흐름 구현 작업을 develop 브랜치에 통합하기 위한 PR입니다.

D2C-34까지 구현된 상품 탐색 및 장바구니 담기 흐름에 이어, 사용자가 회원가입을 통해 사용자 계정을 생성하고 프론트엔드 로그인 상태로 전환될 수 있도록 회원가입 화면과 API 연동 흐름을 구현했습니다.

이번 작업에서는 회원가입 폼 UI, 입력값 검증, POST /auth/signup API 연동, 회원가입 성공 후 사용자 정보 저장, 헤더 로그인 상태 반영, 로그인 사용자의 회원가입 페이지 접근 제한, PR 작성자 자동 Assignee 설정을 포함했습니다.

---

포함 범위

회원가입 화면 구현

• 회원가입 페이지 UI 구성
• 이름 입력 필드 추가
• 이메일 입력 필드 추가
• 비밀번호 입력 필드 추가
• 마케팅 정보 수신 동의 체크박스 추가
• 로그인 페이지 이동 링크 추가
• 회원가입 화면 전용 스타일 추가

사용자 생성 API 연동

• 회원가입 요청 타입 추가
• 인증 사용자 타입 추가
• POST /auth/signup API client 추가
• 회원가입 폼 제출 시 백엔드 사용자 생성 API 호출
• 회원가입 성공/실패 피드백 메시지 표시

사용자 상태 저장 및 헤더 반영

• 회원가입 성공 시 생성된 사용자 정보를 localStorage에 저장
• d2c_user 기반 로그인 상태 유지
• 사용자 상태 변경 이벤트 추가
• MainLayout에서 사용자 상태 변경 이벤트 구독
• 회원가입 성공 후 헤더가 로그인 상태로 즉시 변경되도록 반영
• 로그인 상태에서 주문 내역 / 사용자명 / 로그아웃 메뉴 표시
• 로그아웃 시 사용자 정보 및 장바구니 식별자 제거

인증 상태 기반 페이지 접근 제어

• 로그인 상태에서 /signup 직접 접근 시 /products로 redirect
• redirect 시 replace: true를 적용하여 뒤로가기 시 회원가입 페이지로 재진입되는 흐름 방지

PR 자동화 설정

• PR 생성 시 작성자를 Assignee로 자동 지정하는 workflow 추가
• auto assign 설정 파일 추가
• 기존 CI workflow와 중복되지 않도록 PR Assignee 자동화만 별도 구성

---

검증 결과

프론트엔드 타입 체크를 실행하여 정상 통과를 확인했습니다.

cd apps/web
npm run typecheck

프론트엔드 빌드를 실행하여 정상 통과를 확인했습니다.

cd apps/web
npm run build

프론트엔드 개발 서버와 백엔드 서버를 함께 실행하여 회원가입 흐름을 수동 확인했습니다.

cd apps/api
uvicorn backend.main:app --reload

cd apps/web
npm run dev

수동 확인 항목:

• http://localhost:5173/signup 접속 확인
• 비로그인 상태에서 회원가입 화면 접근 가능 확인
• 회원가입 화면 렌더링 확인
• 이름 / 이메일 / 비밀번호 / 마케팅 수신 동의 입력 확인
• 빈 값 제출 시 검증 메시지 표시 확인
• 잘못된 이메일 제출 시 검증 메시지 표시 확인
• 8자 미만 비밀번호 제출 시 검증 메시지 표시 확인
• 정상 입력 시 회원가입 API 호출 확인
• 회원가입 성공 후 localStorage에 d2c_user 저장 확인
• 회원가입 성공 후 /products 이동 확인
• 회원가입 성공 후 헤더가 로그인 상태로 변경되는 것 확인
• 로그인 상태에서 /signup 직접 접근 시 /products로 redirect 확인
• 로그아웃 시 비로그인 메뉴로 복귀 확인

---

브랜치 통합 방식

이번 PR의 통합 흐름은 아래와 같습니다.

feature/D2C-35-signup-user-flow
→ develop

D2C-35 병합 후에는 develop 브랜치에서 D2C-36 전용 feature 브랜치를 새로 분기하여 로그인 화면 및 사용자 상태 저장 흐름 구현을 진행합니다.

---

향후 브랜치 운영 원칙

Sprint 2에서는 아래 브랜치 운영 원칙을 유지합니다.

• Jira 이슈키별 독립 feature 브랜치 생성
• 각 feature 브랜치는 develop에서 분기
• 작업 완료 후 develop으로 개별 PR 생성
• PR 단위로 CI 검증 후 병합
• 의미 있는 사용자 흐름 단위가 완료되면 develop을 main에 병합
• main은 배포 기준 브랜치로 유지
• 기능 작업이 누적된 장기 브랜치는 지양

---

체크리스트

• develop 브랜치에서 분기한 feature 브랜치에서 작업
• D2C-35 이슈키를 PR 제목과 설명에 포함
• 회원가입 화면 UI 구현
• 이름 / 이메일 / 비밀번호 / 마케팅 수신 동의 입력 구현
• 기본 입력값 검증 구현
• 회원가입 API 연동
• 회원가입 성공 시 사용자 정보 localStorage 저장
• 회원가입 성공 후 /products 이동 처리
• 회원가입 후 헤더 로그인 상태 즉시 반영
• 로그인 상태에서 /signup 접근 제한 처리
• 로그아웃 시 사용자 상태 초기화 확인
• PR 작성자 자동 Assignee workflow 추가
• .env, node_modules, dist, cache 파일이 커밋에 포함되지 않도록 확인
• 로컬에서 프론트엔드 typecheck / build / dev 실행 확인