결제 선택 패널 제거하고 브랜드 자동 진입으로 단순화
목차
결제 모드 선택 패널을 완전히 걷어내고, brand 진입을 자동화하는 리팩토링을 했다.
왜 선택 패널을 폐기했는가
POS 환경에서 결제 시트를 띄울 때, 기존에는 사용자가 "어떤 모드로 진입할지" 직접 고르는 패널이 중간에 끼어 있었다. 처음 이 구조가 생겼을 때는 나름 이유가 있었을 것이다. 브랜드 진입 경로가 여럿이었거나, 운영자가 수동으로 흐름을 제어해야 하는 시점이 있었거나. 그런데 시스템이 성숙해지면서 그 "선택"이 실질적인 의미를 잃었다. 어차피 99%는 같은 경로로 빠지고, 나머지 케이스는 코드 레벨에서 조건 분기로 충분히 처리 가능했다.
이런 상황에서 선택 패널이 UI 중간에 남아 있으면 생기는 문제가 있다:
- UX 단절: 사용자 입장에서 "굳이 왜 고르지?"라는 마찰이 생김
- 유지보수 부채: 실제로 분기되지 않는 로직인데 코드에는 분기 구조가 남아 있어, 이후 개발자가 왜 이게 있는지 파악하는 데 시간을 씀
- 테스트 경우의 수 증가: 없어도 되는 상태 전이가 QA 체크리스트를 늘림
팀 리뷰 때도 "이 패널 거치는 케이스가 실제로 발생하는지" 질문이 나왔고, 확인해보니 사실상 dead path였다. 그 순간 결론은 하나였다 — 없애는 게 맞다.
작업 내용: 자동 brand 진입 + POS 텍스트 링크
변경의 핵심은 두 가지다.
| 항목 | 변경 전 | 변경 후 |
|---|---|---|
| brand 진입 방식 | 선택 패널에서 수동 선택 | 조건 판단 후 자동 진입 |
| POS 연결 UX | 패널 내 버튼 형태 | 텍스트 링크로 간소화 |
| 중간 UI 레이어 | 존재 (선택 패널 JSP 블록) | 제거 |
paymentSheet.jsp 하나만 건드린 건 의도된 핀포인트 수정이다. 결제 시트 컴포넌트는 여러 흐름에서 공유되는 파일이라, 범위를 최소화하는 게 중요했다. 괜히 공통 레이아웃이나 서블릿 쪽까지 손댔다가 다른 결제 흐름에 사이드 이펙트가 튈 수 있다.
자동 brand 진입 로직은 대략 이런 패턴이다:
<%-- 변경 후: 조건 판단 즉시 brand 진입, 별도 선택 UI 없음 --%>
<c:choose>
<c:when test="${not empty paymentContext.brandCode}">
<%-- brand 자동 진입 처리 --%>
</c:when>
<c:otherwise>
<%-- fallback: POS 텍스트 링크 노출 --%>
<a href="${posEntryUrl}" class="pos-text-link">POS 결제로 이동</a>
</c:otherwise>
</c:choose>
실제 코드 그대로는 아니지만, 이번 변경의 의도를 구조로 표현하면 이렇다. brandCode가 컨텍스트에 이미 있으면 패널을 거칠 이유가 없고, 없는 경우에만 POS 텍스트 링크를 보여주는 심플한 구조.
POS 텍스트 링크로 바꾼 것도 포인트다. 기존 버튼 형태는 패널 UI 안에서만 의미 있는 스타일이었는데, 패널이 사라지면서 같은 위계의 버튼이 뜬금없이 남을 수 없었다. 텍스트 링크로 낮추는 게 시각적 위계상 맞고, "이건 주 흐름이 아닌 대체 경로"라는 UX 시그널도 줄 수 있다.
리팩토링인데 왜 우선순위를 뒀는가
사실 이 작업은 당장 버그를 잡는 것도 아니고, 신규 기능도 아니다. 그런데 내가 스프린트에 넣은 이유가 있다.
JSP 기반 레거시 결제 시트는 손대기 겁나는 파일 1순위다. 건드릴수록 어디서 뭔가 터지는 구조. 그래서 팀원들이 자연스럽게 "그냥 두자"는 선택을 반복한다. 그 결과 dead UI, 안 쓰는 분기, 의미 없는 상태들이 쌓인다. 이게 누적되면 나중에 진짜 중요한 변경을 해야 할 때 "어디가 실제로 살아있는 코드인지" 파악하는 데만 하루가 날아간다.
리팩토링 우선순위는 "지금 아프냐"가 아니라 "이게 쌓이면 나중에 얼마나 아프냐"로 판단해야 한다. 선택 패널 하나지만, 이걸 제거함으로써:
- 신규 입사자가
paymentSheet.jsp읽을 때 "이 패널은 언제 뜨는 거야?"라는 질문이 사라짐 - QA가 결제 시트 테스트할 때 체크해야 하는 시나리오 수가 줄어듦
- 다음에 결제 흐름을 건드릴 때 출발점이 더 깔끔해짐
팀 리드 입장에서 이런 정리는 팀 전체 생산성에 직접 연결된다. 코드 한 파일이지만 그 파일을 둘러싼 인지 비용이 줄었다는 게 핵심이다.
레거시 JSP 파일에서의 리팩토링은 항상 조심스럽다. 변경 범위를 최소화하고, 의도를 명확히 하고, 리뷰어가 "왜 이걸 지금 했는지" 바로 이해할 수 있게 커밋 메시지를 쓰는 것까지가 작업의 일부다. 이번엔 그 흐름이 잘 맞아떨어진 케이스였음.
끝.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.