결제·이커머스 회원가입 폼 검증 구멍 두 곳 동시 수정
목차
두 플랫폼 회원가입 폼을 동시에 손봄
결제 플랫폼이랑 이커머스 쪽 회원가입 폼이 둘 다 깨져 있길래 한 번에 잡았음. 같은 이름의 register 파일이 두 개라 어느 쪽 고치는 중인지 헷갈려서 처음에 한참 봤음.
무엇이 문제였나
- 이메일 검증 정규식이 두 폼에서 서로 달랐음 (한쪽은 .co.kr 거부)
- 비밀번호 확인 필드에 blur 이벤트가 안 붙어 있어서 제출 누른 뒤에야 에러 노출
- 약관 동의 체크박스가 disabled일 때도 submit 통과 (프론트만 막혀있고 서버 검증 누락)
- 파트너 가입 분기에서 사업자번호 필드가 일반 가입 폼에도 같이 노출됨
어떻게 고쳤나
이메일 검증은 두 플랫폼이 서로 다른 정책을 갖고 있는 게 맞아서, 통일하기보단 정규식을 명시적으로 분리하고 주석으로 차이를 박아뒀음. 괜히 합치려다 한쪽 정책 흐트러뜨리는 게 더 위험.
| 항목 | 변경 전 | 변경 후 |
|---|---|---|
| 이메일 검증 | 클라 only | 클라 + 서버 |
| 비번 확인 | submit 시점 | blur + submit |
| 약관 동의 | 프론트 disabled | 프론트 + 서버 재검증 |
| 파트너 분기 | 조건부 렌더 누락 | 가입 타입별 분기 |
서버 검증을 추가하면서 에러 응답 포맷이 두 플랫폼에서 살짝 달라서, 프론트에서 받아 처리하는 쪽에 어댑터 한 겹만 둠. 백엔드 응답 포맷 통일은 이번 범위 밖이라 안 건드림.
회고
- 공통화 욕심 참았음: 두 폼이 비슷해 보여도 정책이 달라서 함부로 합치면 안 된다는 걸 다시 확인. 차이를 명시적으로 남기는 게 안전함.
- 서버 검증 누락이 진짜 위험: 프론트 disabled만 믿으면 개발자도구로 뚫림. 약관 동의처럼 사소해 보이는 것도 서버에서 다시 검증해야 함.
- 테스트 빈약: 회원가입 폼 자동화가 없어서 손으로 확인했는데, 다음에는 핵심 케이스만이라도 e2e로 박아둬야 할 듯. 정규식 한 줄 차이로 특정 도메인 가입자가 통째로 막히는 경험은 한 번이면 충분함.
폼 검증은 매번 비슷한 함정에 빠짐. "프론트만 막아도 되겠지" 라는 방심이 제일 비쌈.
다음
댓글 0
첫 댓글 달아줘.