개발 slecs

결제·이커머스 회원가입 폼 검증 구멍 두 곳 동시 수정

목차

두 플랫폼 회원가입 폼을 동시에 손봄

결제 플랫폼이랑 이커머스 쪽 회원가입 폼이 둘 다 깨져 있길래 한 번에 잡았음. 같은 이름의 register 파일이 두 개라 어느 쪽 고치는 중인지 헷갈려서 처음에 한참 봤음.

무엇이 문제였나

  • 이메일 검증 정규식이 두 폼에서 서로 달랐음 (한쪽은 .co.kr 거부)
  • 비밀번호 확인 필드에 blur 이벤트가 안 붙어 있어서 제출 누른 뒤에야 에러 노출
  • 약관 동의 체크박스가 disabled일 때도 submit 통과 (프론트만 막혀있고 서버 검증 누락)
  • 파트너 가입 분기에서 사업자번호 필드가 일반 가입 폼에도 같이 노출됨

어떻게 고쳤나

이메일 검증은 두 플랫폼이 서로 다른 정책을 갖고 있는 게 맞아서, 통일하기보단 정규식을 명시적으로 분리하고 주석으로 차이를 박아뒀음. 괜히 합치려다 한쪽 정책 흐트러뜨리는 게 더 위험.

항목 변경 전 변경 후
이메일 검증 클라 only 클라 + 서버
비번 확인 submit 시점 blur + submit
약관 동의 프론트 disabled 프론트 + 서버 재검증
파트너 분기 조건부 렌더 누락 가입 타입별 분기

서버 검증을 추가하면서 에러 응답 포맷이 두 플랫폼에서 살짝 달라서, 프론트에서 받아 처리하는 쪽에 어댑터 한 겹만 둠. 백엔드 응답 포맷 통일은 이번 범위 밖이라 안 건드림.

회고

  • 공통화 욕심 참았음: 두 폼이 비슷해 보여도 정책이 달라서 함부로 합치면 안 된다는 걸 다시 확인. 차이를 명시적으로 남기는 게 안전함.
  • 서버 검증 누락이 진짜 위험: 프론트 disabled만 믿으면 개발자도구로 뚫림. 약관 동의처럼 사소해 보이는 것도 서버에서 다시 검증해야 함.
  • 테스트 빈약: 회원가입 폼 자동화가 없어서 손으로 확인했는데, 다음에는 핵심 케이스만이라도 e2e로 박아둬야 할 듯. 정규식 한 줄 차이로 특정 도메인 가입자가 통째로 막히는 경험은 한 번이면 충분함.

폼 검증은 매번 비슷한 함정에 빠짐. "프론트만 막아도 되겠지" 라는 방심이 제일 비쌈.

다음

댓글 0

첫 댓글 달아줘.