회원 본인인증을 웰컴 팝업에서 SMS로 전환
목차
회원 본인인증 방식을 기존의 웰컴 팝업 기반에서 제주(kp-pay)의 휴대폰 SMS 인증으로 전환했다. 보안과 사용자 경험, 그리고 규정 준수 관점에서 실제로 필요했던 작업이었다.
왜 본인인증 방식을 바꿨는가
본인인증(KYC, Know Your Customer)은 금융 거래 서비스에서 절대 타협할 수 없는 영역이다. 기존의 웰컴 팝업 방식은 실제로는 UX 친화적으로 보일 수 있지만, 몇 가지 문제가 있었다.
첫째, 팝업 기반 인증은 사용자의 실제 신원을 강하게 검증하기 어렵다. 단순히 개인정보를 입력받는 단계를 거치는 것만으로는 '정말 본인인가'를 확인하는 데 한계가 있다. 특히 금융서비스의 관점에서 본다면, 더 강력한 인증 메커니즘이 필요했다.
둘째, SMS 인증은 물리적 장치(휴대폰)를 검증하는 방식으로, 실제 본인 확인의 신뢰도가 훨씬 높다. 사용자가 입력한 전화번호의 소유자임을 SMS 수신으로 증명할 수 있기 때문이다. 이는 단순 데이터 검증을 넘어 실제 신원 확인으로 나아가는 단계다.
셋째, 규정 준수 관점에서도 SMS 기반 인증이 더 강력한 입증 근거가 된다. 감시 기관이나 감사 시에도 "사용자가 직접 수신한 SMS 인증 코드를 입력했다"는 로그가 훨씬 명확한 증거가 된다.
변경 영역과 그 의미
이번 작업은 회원 인증 전 흐름에 걸쳐 이루어졌다.
| 영역 | 역할 | 변경 포인트 |
|---|---|---|
| 회원(Member) Web 클래스 | 회원가입/인증 UI 로직 및 흐름 제어 | 웰컴 팝업 호출 → SMS 인증 요청 플로우로 변경 |
| 인증(Identity) 유틸 | 본인인증 검증 및 상태 관리 | 팝업 입력값 검증 → SMS 토큰 검증 로직으로 전환 |
| 결제(Payment) 유틸 | 제주(kp-pay) 결제 게이트웨이 연동 | SMS 인증 API 호출 및 응답 처리 추가 |
| KYC JSP | 본인인증 화면 UI | 입력폼 → SMS 수신 대기 → 인증 확인 UX로 개선 |
web 클래스는 사용자의 인증 요청을 받아서 이제는 SMS 인증 단계로 라우팅한다. 기존처럼 팝업에서 바로 검증하는 게 아니라, 외부 SMS 서비스(제주)로 요청을 던지고 그 결과를 기다리는 흐름으로 바뀌었다.
identity 유틸은 이제 단순히 사용자가 입력한 정보를 검증하는 것 이상으로, SMS 발송 후 사용자가 입력한 인증 코드가 실제 발송된 코드와 일치하는지 확인하는 책임을 진다. 이 과정에서 타임아웃, 재시도 횟수 제한 등 보안 정책도 함께 들어간다.
payment 유틸은 제주(kp-pay)와의 통신을 담당한다. SMS 인증 요청 API를 호출하고, 응답을 파싱해서 성공/실패/재시도 필요 등의 상태를 정확히 전달해야 한다. API 타임아웃, 네트워크 오류, 제주 측 에러 코드 등을 모두 처리해야 하므로 이 부분이 꽤 견고해야 한다.
kyc.jsp는 UI가 가장 크게 달라진 부분이다. 이전에는 단순 입력폼이었다면, 이제는 "SMS 발송 → 대기 → 코드 입력 → 재전송 버튼" 같은 다단계 플로우를 그려야 한다. UX 측면에서도 "몇 초 남았습니다" 같은 타이머나 "코드를 받지 못했습니다" 같은 에러 가이드도 필요하다.
이런 전환에서 주의할 점들
비슷한 작업을 할 때 고려해야 할 패턴들이 있다:
-
상태 관리의 복잡도: 팝업 검증은 한 번의 요청-응답인 반면, SMS는 발송-대기-입력-검증이라는 여러 단계를 거친다. 사용자가 중간에 페이지를 떠났을 때, 재시도했을 때, 시간 초과됐을 때 등 다양한 시나리오를 대비해야 한다.
-
외부 서비스 의존성: 제주(kp-pay) API가 느리거나 장애가 나면 전체 인증 프로세스가 영향을 받는다. 타임아웃 설정, 재시도 로직, fallback 시나리오를 미리 설계해야 한다.
-
보안 이슈: SMS 코드의 유효 시간, 재전송 횟수 제한, rate limiting 같은 정책을 엄격히 구현하지 않으면 사기나 브루트 포스 공격에 노출될 수 있다.
-
로깅과 모니터링: 인증 관련 작업은 반드시 감사 로그를 남겨야 한다. "언제 누가 어떤 번호로 SMS를 받아 인증했는가"라는 추적 가능성이 중요하다.
개인적 회고
이 작업을 하면서 느낀 점은, 단순한 '기술 전환'이 아니라 '보안 정책의 업그레이드'라는 관점으로 접근해야 한다는 것이다. 내가 코딩하는 것도 중요하지만, 왜 이 인증 방식을 택했는가, 어떤 규제 요건을 만족하는가, 사용자 입장에서 더 안전해지는가라는 질문들이 먼저였다.
팀 관점에서도, 이런 변경은 보안팀, UX팀, 백엔드팀이 함께 논의해야 하는 작업이다. 제주(kp-pay)와의 연동도 외부 업체와의 협의가 필요한 부분이고, SMS 발송 비용도 함께 고려해야 한다. 작은 코드 변경처럼 보이지만, 실제로는 꽤 많은 이해관계자가 투입되는 작업이었다.
앞으로도 이런 '기술만의 결정'이 아닌 '비즈니스와 보안을 함께 고려한 결정'을 더 많이 다룰 것 같다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.