refactor(onboarding): 이메일 형식 검사 한 줄을 세 UiState 에서 OnboardingEmailRule 로 모은다 #1851

작업 유형

refactor — 동작 변경 없는 구조·책임·경계 개선

주 담당 모듈

onboarding — 온보딩

개요

같은 판정 한 줄이 온보딩 UiState 세 곳에 복제돼 있다.

• feature/onboarding/presentation/.../signup/SignUpUiState.kt:81
• feature/onboarding/presentation/.../findaccount/FindIdUiState.kt:38
• feature/onboarding/presentation/.../findaccount/FindPasswordUiState.kt:43 (비밀번호 찾기 — 이메일 인증 후 비밀번호 재설정 #457 에서 추가)

셋 다 email.isNotBlank() && Patterns.EMAIL_ADDRESS.matcher(email).matches() 이고, 각 KDoc 이 "회원가입과 동일 방식" 이라고 서로를 가리키는 것으로 동기화를 대신하고 있다.

바로 옆의 비밀번호 규칙은 이미 OnboardingPasswordRule.isSatisfied(...) 라는 순수 함수로 빠져 있어 비대칭이다. 이메일만 각 UiState 가 프레임워크 API 를 직접 부른다.

완료 조건

• OnboardingEmailRule.isValid(email) 을 OnboardingPasswordRule 과 같은 자리에 신설한다.
• 세 UiState 의 isEmailFormatValid 게터가 그 함수를 부른다.
• import android.util.Patterns 가 세 파일에서 사라진다.

하지 말 것 — Patterns 를 자체 정규식 사본으로 되돌리지 않는다.

2026-05-26 d5cc062d4(#273)가 SignUpViewModel 에 있던 AOSP 사본 EMAIL_ADDRESS_REGEX 를 지우고 Patterns 로 옮긴 결정이 이미 있다. 사본은 AOSP 원본과 조용히 갈라지고, Android 정규식은 문자 클래스를 Unicode 로 판정해 서버 검증과 어긋날 여지를 새로 만든다.

따라서 이 추출로 Robolectric 을 벗지는 못한다. FindPasswordViewModelTest 가 RobolectricTestRunner 를 쓰는 이유는 isEmailFormatValid 가 android.util.Patterns 를 읽기 때문이고(테스트 KDoc 에 명시), 추출 후에도 그대로다. 이 이슈의 목적은 중복 제거이지 테스트 러너 경량화가 아니다 — 러너를 가볍게 하려고 정규식 사본을 되살리면 위 결정을 되돌리는 것이 된다.

자식 이슈

No response

참고

경위 — #150 이 회원가입에 형식 검증을 도입(1e20d89e1, 2026-05-16) → 753e46d1a 가 UiState 로 옮김 → #273 이 VM 의 정규식 사본을 걷어내고 Patterns 로 통일(d5cc062d4) → 아이디 찾기가 같은 줄을 복제(d8c767249, 2026-07-17) → 비밀번호 찾기(#457)가 세 번째.

OnboardingPasswordRule 쪽은 서버 규칙과의 정합성이라는 별개 축으로 #1628 이 열려 있다. 이 이슈는 이메일 축이고 서로 독립이다.

FindPasswordUiState 는 #457 머지 전에는 develop 에 없다.