파트너 등록 위저드 실명인증 강제 검증 해제

파트너 등록 위저드의 Step3에서 실명인증이 강제 검증으로 묶여 있던 걸 해제하는 작업을 했다.

왜 강제 검증이 문제였나

파트너 등록 플로우는 위저드 형태로 여러 단계를 순서대로 밟아가는 구조다. Step3에서 실명인증을 요구하는 건 자연스러운 흐름이지만, "강제"로 묶여 있으면 일부 예외 케이스에서 등록 자체가 막혀버리는 상황이 생긴다.

예를 들어 운영자가 직접 등록을 대행하거나, 내부 정책 상 실명인증을 별도 단계에서 처리하도록 분리된 경우, 혹은 특정 파트너 유형은 인증 주체나 방식이 달라서 일반 실명인증 API를 태울 수 없는 경우 — 이런 상황에서 강제 검증이 걸려 있으면 다음 단계로 아예 진입이 안 된다. UX 관점에서도 "왜 막히는지 모르겠다"는 문의가 발생하기 쉬운 구조다.

이번 fix는 그 강제 검증 조건을 해제해서, 실명인증이 충족되지 않은 상태에서도 위저드가 다음 단계로 넘어갈 수 있도록 풀어준 작업이다.

wizard.jsp 파일 하나에서 벌어지는 일

변경 파일이 wizard.jsp 단일 파일이라는 게 이 작업의 특징이다. 핀포인트 수정에 가깝다.

JSP 기반 위저드에서 단계별 검증은 보통 세 군데 중 한 곳에서 걸린다:

이번 변경이 wizard.jsp 단일 파일에서 이루어졌다는 건, 클라이언트 사이드 검증 또는 JSP 렌더링 레이어에서의 조건부 블로킹이었다는 뜻이다. 서버 레이어까지 건드리지 않아도 됐다는 점에서 영향 범위는 제한적이고, 그게 오히려 이 fix의 안전성을 높여준다.

코드 패턴으로 보면 대략 이런 식의 조건이 풀렸을 것이다:

// 변경 전: 실명인증 완료 여부를 강제 체크
function validateStep3() {
    if (!isIdentityVerified) {
        alert("실명인증을 완료해주세요.");
        return false;
    }
    return true;
}

// 변경 후: 강제 검증 해제, 흐름 계속 허용
function validateStep3() {
    // 실명인증은 선택 또는 별도 프로세스에서 처리
    return true;
}

이런 fix에서 팀장으로서 챙기는 것

실명인증 같은 보안/정책성 검증을 "해제"하는 작업은, 단순 UI 버그 수정과 다르게 반드시 맥락을 남겨야 한다고 생각한다. 코드만 보면 "왜 뺐지?" 싶은 변경이기 때문이다.

이런 작업을 리뷰할 때 내가 항상 확인하는 것들:

• 왜 해제인가: 내부 정책 변경인지, 버그 수정인지, 예외 케이스 대응인지 명확히
• 해제 범위: 전체 파트너 유형에 적용되는 건지, 특정 유형만인지
• 후속 보완 장치: 강제 검증을 뺐으면, 다른 단계나 서버에서 최종 인증 여부를 체크하는 안전망이 있는지
• 롤백 시나리오: 이 변경이 문제가 됐을 때 빠르게 되돌릴 수 있는지

특히 마지막 포인트 — "후속 보완 장치" — 가 없으면 이 fix는 반쪽짜리다. 클라이언트 검증을 풀었어도 서버에서 실명인증 상태를 파트너 최종 승인 전에 한 번 더 확인하는 로직이 있어야, 검증 해제가 보안 구멍이 아닌 유연성 확보로 읽힌다.

위저드 UI는 사용자 경험을 위한 레이어고, 진짜 정책 강제는 서버와 데이터 레이어에서 담당한다는 원칙을 팀원들에게도 계속 이야기하는 편이다. 이번 건도 그 원칙 안에서 움직인 변경이었다고 본다.

끝.