Repository navigation
feat(onboarding): 계정 찾기 공용 이메일 인증 화면 및 auth find 데이터 계층 #456
Description
📜 Overview (Required)
로그인 "아이디/비밀번호 찾기" 진입점과 찾기 흐름 공용의 이메일 인증 화면, 그리고 auth find 데이터 계층을 추가한다.
원래 범위는 아이디 찾기 전체(결과 화면 포함)였으나, 아이디 찾기 존치 자체가 검토에 들어가면서(아래 코멘트 3건 참조) 존치 결론과 무관하게 살아남는 공용 토대로 범위를 축소했다. 결과 화면과 "다음" 배선은 결정 대기 이슈로 분리.
시안 (Figma UP9ZR186jHvRBicjA2SOea)
| 화면 | node-id |
|---|---|
| 이메일 인증하기 (초기) | 2383-16061 |
| 인증번호 전송됨 (안내 문구) | 2383-16470 |
| 인증번호 틀림 (에러 문구) | 2431-14204 |
API (현행 Swagger 실측 2026-07-16)
| 엔드포인트 | 요청 | 응답 | 비고 |
|---|---|---|---|
POST /api/v1/auth/find/send/code |
{email} |
— | 아이디/비밀번호 찾기 공용 발송. 미가입 이메일은 400/1219 |
POST /api/v1/auth/email/find |
{email, certificateCode} |
{name, email} |
인증번호 인라인 "확인" 용도로 소비 |
수용 기준
- 로그인 화면 "아이디/비밀번호 찾기"가 고객센터 안내 팝업 대신 인증 화면으로 진입 (
login_find_account_message스텁 제거) - 이메일 입력 → "인증번호 받기"(재전송 쿨다운 포함) → 인증번호 입력 → 인라인 "확인"
- 전송 성공 안내 2줄(파랑) / 인증번호 불일치 에러 2줄(빨강,
colors.error) / 그 외 실패 스낵바 - 미가입 이메일(1219) 실패가 서버 메시지로 사용자에게 표시됨
-
./gradlew build그린
📍 Note (Optional)
- base =
feat/444(stack) - 인증 화면의 "다음" 은 결과 화면 존치 결정 전까지 의도적 미배선 — 배선은 분리 이슈에서
- 인라인 "확인" 은
auth/email/find호출(검증+조회 겸용)로 구현 — 찾기 흐름 전용 검증 API 존재 여부는 BE 확인 항목으로 유지 - 시안에 인증번호 만료 타이머 없음 — 회원가입 쪽 임의 타이머 정리는 fix(onboarding): 회원가입 인증번호 화면 시안 정합 — 임의 타이머 제거·실패 분기 정리 #472
- 비밀번호 찾기 — 이메일 인증 후 비밀번호 재설정 #457 비밀번호 찾기가 이 화면과
find/send/code배선을 공유(이 이슈 위 stack)
Activity
OnlyReadOneBook commentedon Jul 16, 2026
Note 의 "결과 화면 표시값" 질문을 실측으로 확장한다. 이건 표시값 문제가 아니라 흐름의 전제 문제다.
순환성 지적: 이 화면은 "가입 시 사용한 이메일"을 입력받아 가입 이메일을 알려준다 — 아이디=이메일인 이 앱에서는 문면상 순환이다.
서버 실측 (2026-07-16): 미가입 이메일로
POST /auth/find/send/code→ 메일 발송 없이 즉시{"status":400,"code":1219,"message":"가입되지 않은 이메일입니다."}. 회원가입용POST /auth/email/send는 같은 주소를 200 으로 수락 — 찾기 흐름에만 넣은 의도적 분기다.따라서 이 흐름의 실효는 "가입 이메일 판별": 여러 이메일 중 어느 걸로 가입했는지 모르는 사용자가 후보를 넣어보면, 아닌 건 1219 로 즉시 걸러지고 맞는 것만 인증번호가 온다. 결과 화면은 확정 안내(이름+이메일)다. 이메일을 아예 모르는 사용자는 구제 불가 — 계정 모델에 전화번호가 없어 대체 조회 채널이 존재하지 않는다.
시안 결손 전제: 결과 화면의
parkchae01은 유저네임 꼴 — 별도 아이디 체계를 전제로 그려진 것으로 보이나 서버에 그런 체계가 없다. 디자이너/PM 확인 항목:구현은 (a) 기준으로 진행하고, 회신에 따라 결과 화면만 조정한다.
OnlyReadOneBook commentedon Jul 16, 2026
위 코멘트의 (a) 입장 근거를 정정한다.
"BE 가 1219 분기로 판별 용도를 구현했다"는 아이디 찾기 특정 근거가 아니다.
POST /auth/find/send/code는 아이디/비밀번호 찾기 공용 발송 엔드포인트다(Swagger summary: "아이디/비밀번호 찾기 인증번호 발송 API"). 따라서 미가입 이메일 1219 거절은 비밀번호 찾기 1단계에서도 동일하게 발동하고, "어느 이메일로 가입했는지" 판별 효용은 비밀번호 찾기에 완전히 포섭된다 — 후보 이메일을 넣는 순간(인증번호 입력 전) 1219 여부로 답이 나온다.아이디 찾기 고유 효용으로 남는 것: (i) 비밀번호를 리셋하지 않고 가입 이메일만 확인 — 비밀번호는 기억하는데 이메일만 잊은 드문 케이스, (ii) 가입자 이름 표시, (iii) 아이디/비밀번호 찾기 쌍 관례. 기능 기준으로는 (b)(비밀번호 찾기 단독, 이메일 로그인 서비스 표준형)가 우세하다.
FE 비용 관점: 어느 쪽이든 이해관계 없음. 이메일 인증 화면·
find/send/code배선은 #457 비밀번호 찾기와 공유라 폐지 시 제거분은 결과 화면 1장 + 라우트뿐. 유지/폐지는 PM·디자이너 판단 대기, 구현은 회신 전까지 현행(유지) 기준 진행.OnlyReadOneBook commentedon Jul 16, 2026
분석 마지막 조각 — 아이디 찾기 흐름에서 인증번호의 역할.
판별(가입 이메일 확인) 용도에는 인증번호가 불필요하다 — 답은 코드 입력 전,
find/send/code의 1219 vs 발송 성공에서 이미 나온다. 서버 계약상 인증번호가 게이트하는 것은 결과 화면의 이름 공개뿐이다: 가입 여부는 무인증으로 응답되지만{name, email}반환은auth/email/find뿐이고 거기만certificateCode를 요구한다(메일함 통제 증명 없이 타인 이메일로 실명을 얻는 것 방지). 비밀번호 찾기의 인증번호가 새 비밀번호 설정 게이트(계정 탈취 방지)라는 명확한 역할을 갖는 것과 대조된다.함의: 이름 표시를 빼면 인증번호가 지킬 것이 없고, 인증번호를 빼면 이 화면의 실질은 1단계 에러 안내 한 줄이다. 존치 판단 시 "인증 2단계 + 결과 화면 = 이름 1개 공개 비용"이라는 구조를 감안할 것 — (b)(비밀번호 찾기 단독) 논거를 추가 강화.
부수 (BE/제품 판단 영역, 요구 아님): 1219 는 무인증 계정 열거 오라클이다 — 가입 여부는 전면 누설하면서 이름만 코드 뒤에 두는 비대칭. 열거 방지형 응답으로 바꾸면 판별 UX 와 상충하므로 트레이드오프 인지만 기록해 둔다.
[-]feat(onboarding): 아이디 찾기 — 이메일 인증 후 가입 이메일 안내[/-][+]feat(onboarding): 계정 찾기 공용 이메일 인증 화면 및 auth find 데이터 계층[/+]OnlyReadOneBook commentedon Jul 16, 2026
범위 축소: 아이디 찾기 결과 화면(시안 2383-16514)과 인증 화면 "다음" 배선을 별도 이슈로 분리 — 아이디 찾기 존치 검토(위 코멘트 3건)와 무관하게 이 이슈의 공용 토대는 진행 가능하도록. 분리 이슈 번호는 곧 아래에.
OnlyReadOneBook commentedon Jul 16, 2026
분리 이슈: #474 (아이디 찾기 결과 화면, 존치 결정 대기)