웰컴 서비스 비활성 시 인증 요청 차단
목차
결제 플랫폼의 일부 결제 수단(웰컴)이 2026년 6월부터 비활성화되면서, 이를 반영한 차단 로직을 member·pay 도메인에 추가했다. 단순해 보이지만 여러 진입점에서 동일한 정책을 강제해야 하는 일이었다.
비활성화는 "끄는 것"이 아니다
웰컴 서비스 비활성화라는 요구사항이 들어왔을 때, 처음에는 설정만 바꾸면 되겠다고 생각했다. 하지만 실제로는 그게 아니었다. 사용자가 비활성화된 서비스에 접근하는 여러 흐름이 있었기 때문이다.
구체적으로 문제가 될 수 있는 경로:
- KYC 본인인증 흐름: 사용자가 결제 시 본인인증이 필요한 상황에서 웰컴을 선택했을 때
- 결제 연동 URL 발급: 외부 시스템과의 연결(connect)을 요청할 때
이런 경우들에서 "비활성 서비스인데 왜 인증 프로세스를 시작하나?"라는 모순이 발생한다. 결국 사용자는 실패 화면을 보게 되거나, 디버깅하기 어려운 에러를 마주하게 되는 것이다.
진입점을 찾아 차단 로직을 심다
member 웹 컨트롤러와 pay 웹 컨트롤러 두 곳에서 수정이 필요했다. 이는 같은 정책을 두 개의 도메인에서 각각 관리해야 한다는 의미였다.
변경 영역의 의미:
| 영역 | 역할 | 이번 수정 내용 |
|------|------|--------------|
| member/web | 사용자 인증 흐름 관리 | KYC 본인인증 요청 시 웰컴 활성 여부 체크 |
| pay/web | 결제 시스템 API | connect URL 발급 전 웰컴 비활성 체크 |
각 컨트롤러에서 요청이 들어오면, 웰컴이 비활성 상태인지 먼저 확인하고, 그렇다면 적절한 에러(또는 대체 흐름)로 조기 종료하는 방식이다.
회고: 비활성화 작업의 숨겨진 복잡도
이 작업을 하면서 느낀 것은, 서비스 기능을 제거하거나 비활성화하는 것이 생각보다 섬세하다는 점이었다.
체크해야 할 것들:
- 그 기능에 직접 접근하는 API 엔드포인트는 몇 개인가?
- 다른 도메인에서 간접적으로 호출하는 곳은?
- 관리자 화면에서도 차단해야 하나?
- 이미 진행 중인 결제는 어떻게 처리할 것인가?
- 로그/모니터링은 비활성 시도를 기록할 것인가?
이번의 경우, member + pay 두 곳이 접점이었지만, 실은 더 많은 곳에서 웰컴을 참조할 수 있다. "jeju Step 2 보강"이라는 표현으로 봐서, 이게 단계적 비활성화의 두 번째 단계라는 의미 같다. 첫 단계에서 놓친 부분들을 보강하는 것이었을 수도 있다.
결제 관련 비활성화는 특히 위험하다. 사용자 경험뿐 아니라 정산, 환불, 감시 시스템까지 영향을 줄 수 있기 때문이다. 그래서 이런 변경은 테스트 시나리오가 복잡해진다. 단순히 "웰컴 비활성이면 차단"이 아니라, "비활성 상태에서 사용자가 실수로 웰컴을 선택했을 때 정말로 적절한 메시지를 보는가?"를 확인해야 한다.
앞으로 비슷한 비활성화 작업을 할 때는 미리 "모든 진입점 리스트" 작업을 하고, 각 팀과 협업해서 누락이 없는지 여러 번 확인하는 패턴을 쓸 것 같다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.