휴대폰 인증 로직 중복을 컴포넌트로 통합

휴대폰 본인인증 처리를 공통 컴포넌트로 추상화하고, 회원가입의 중간 단계(step2)와 기존회원의 재인증 플로우에 적용했다.

배경: 반복되는 인증 코드

어느 시점부터인가 팀에서 여러 건의 피처 요청이 들어오기 시작했다. 회원가입 과정 중 휴대폰 본인인증이 필요하고, 기존 회원이 특정 작업(예: 민감한 정보 변경)을 할 때도 재인증이 필요했다. 각 시나리오마다 담당 개발자들이 비슷한 로직을 따로 구현했다.

처음엔 당연했다. 서로 다른 페이지고, 다른 팀에서 담당하니까. 하지만 몇 주 후 버그가 터졌다. 한쪽에서 인증 유효시간을 변경했는데 다른 곳은 기존 시간을 쓰고 있었다. 뭔가 빠진 게 있나 싶어 코드를 뜯어봤더니 같은 로직이 3곳에 흩어져 있었다.

이때 피실감했다. "이게 수정할 때마다 모든 곳을 찾아다니면서 고쳐야 한다고?" 팀장 입장에서도 리뷰할 때 매번 다른 구현을 체크해야 했다.

작업: 공통 컴포넌트화

이번 커밋은 이 문제를 정면으로 해결했다. 휴대폰 본인인증 플로우를 공통 JSP 컴포넌트 (_phone-auth.jsp)로 분리하고, 웹 설정 레이어에 인증 인터셉터를 통합했다.

변경 구조는 대략:

핵심은 로직은 한 곳에, 여러 플로우에서 재사용한다는 것. 회원가입이든 재인증이든 _phone-auth.jsp 안의 폼 처리, 인증번호 검증, 타이머는 모두 같다. 다른 점은 인증 후 이어지는 다음 단계뿐이다.

[회원가입 폼] → [step2 (공통 인증)] → [가입 완료 또는 추가 정보 입력]
[로그인] → [재인증 (공통 인증)] → [민감 작업 진행]

웹 설정 레이어에서 "인증이 끝났으면 다음 스텝으로 가라" / "기존회원인데 미인증 상태면 여기서 막아라" 같은 가드를 중앙 집중식으로 관리할 수 있게 됐다.

이 작업에서 배운 점들

1. 적절한 타이밍에 리팩토링하기
초반에 한두 곳에서 썼을 땐 리팩토링이 과도했을 거다. 그런데 세 번째 플로우에서 같은 로직이 필요해졌을 때가 신호였다. "2번은 우연, 3번은 패턴"이라는 말이 있는데, 정확히 그 시점이었다. 팀장으로서 이 "신호"를 감지하고 개발자들이 리팩토링에 투자할 수 있도록 일정을 조정해준 것도 의사결정 중 하나였다.

2. 설정 레이어와 비즈니스 로직의 분리
처음엔 "그냥 controller에서 처리하면 안 되나?" 싶을 수도 있다. 하지만 인증 여부를 판단하는 로직이 여러 엔드포인트에서 필요하면, 중복을 막으려면 설정 레이어(intercept, filter)에서 먼저 체크하는 게 낫다. 요청이 controller에 도달하기 전에 막을 수 있으니까. 이번 WebMvcConfig 변경도 그 원칙을 따랐다.

3. 마이그레이션의 위험
기존 회원의 재인증 로직을 새 컴포넌트로 옮길 때 주의해야 할 점이 있었다. 기존에 저장된 인증 타임스탬프, 만료 정책, 세션 바인딩 같은 세부 사항들이 미묘하게 달랐을 수 있다. 쿼리 매퍼 변경사항을 자세히 검토했고, 테스트에서 "기존 회원 로그인 후 재인증" 시나리오를 명시적으로 커버했다.

4. 컴포넌트 경계 정하기
_phone-auth.jsp로 얼마만큼을 묶을지가 중요했다. 너무 좁으면 (예: 버튼만) 재사용 가치가 없고, 너무 넓으면 (예: 인증까지의 전 단계 포함) 다양한 UX를 수용할 수 없다. 우리는 "인증번호 입력 & 검증" 부분까지만 컴포넌트화하고, "인증 전 선택지" (휴대폰번호 변경 필요한지 등)는 부모 페이지의 책임으로 남겼다.

다음 기회

이번 작업으로 인증 로직의 일관성이 생겼다. 하지만 다음엔 비슷한 패턴이 생기기 전에 미리 컴포넌트 설계를 고려하는 문화를 정착시켜야겠다. 즉, "3번째가 되기를 기다리지 말고 2번째에 신호를 읽고 준비하자"는 식으로.

그리고 이커머스 PG 플랫폼의 다른 민감 작업들(예: 결제수단 등록, 배송지 변경)도 같은 재인증 메커니즘을 공유할 수 있을 것 같다. 그건 다음 단계.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.