멀티 사이트 PG 분기 로직 통합과 관제 페이지 신규 구성

사이트별 PG 관제 페이지를 새로 붙이면서, 분기 처리 로직을 PgConfigUtil로 뽑아낸 작업이었다.

왜 이 작업이 필요했나

내부 서비스가 멀티 사이트 구조로 운영되다 보니, 사이트마다 활성화된 PG가 다르다. 어떤 사이트는 A 방식만 쓰고, 어떤 사이트는 B 방식도 같이 쓰는 식. 근데 기존엔 이 분기 판단 로직이 각 Controller나 JSP 안에 흩어져 있었다. 관제 목적으로 "현재 이 사이트에서 어떤 PG가 활성화돼 있고, 설정 상태는 어떤지" 한눈에 보는 페이지가 필요해졌을 때, 산재된 분기 코드를 그대로 쓰면 View 레이어가 너무 더러워지는 게 눈에 보였다.

그래서 이번 작업의 핵심은 두 가지였다.

• 관제 페이지(console.jsp + Controller) 신규 구성
• PgConfigUtil에 분기 가드 집중 → 사이트 ID를 받아서 "이 사이트에서 이 PG가 유효한지" 판단하는 로직을 한 곳으로

작업 내용

변경된 파일 구성을 보면 레이어가 꽤 넓게 걸쳐 있다.

PgConfigUtil을 별도 유틸 클래스로 뽑은 게 이번 작업에서 제일 잘한 결정이라고 본다. 분기 가드를 한 곳에 모아두면 나중에 "사이트 C를 추가해야 해요"라는 요청이 와도 Controller를 건드릴 필요 없이 유틸 하나만 수정하면 된다.

코드 구조로 보면 대략 이런 느낌이다.

// PgConfigUtil - 분기 가드 예시 패턴
public static boolean isAvailable(String siteId, String pgType) {
    PgSiteConfig config = PgSiteConfig.of(siteId);
    if (config == null) return false;
    return config.getSupportedTypes().contains(pgType);
}

Controller에서는 이 가드를 통과한 경우만 실제 로직으로 진입하도록 처리하고, 통과 못하면 관제 페이지에서 "비활성" 상태로 표시되게 했다.

메뉴 SQL(MENU_PAYMENT_CONSOLE_2026_05_18.sql)을 함께 커밋한 것도 의도적이었다. 운영자가 메뉴 수동 등록해달라고 따로 요청해야 하는 구조를 피하고 싶었다. 배포 일자가 파일명에 박혀 있어서 히스토리 추적도 된다.

회고

멀티 사이트에서 PG 분기 로직이 여러 레이어에 퍼져 있을 때 발생하는 전형적인 문제가 있다. QA에서 "사이트 A는 되는데 사이트 B는 왜 안 되죠?"라는 버그 리포트가 올라오면, 원인을 찾으러 Controller, Service, JSP를 번갈아 뒤져야 한다. 이번에 PgConfigUtil로 분기 판단을 집중시킨 덕분에 다음 이슈가 터지면 볼 파일이 명확해졌다.

관제 페이지(console.jsp)는 운영 단계에서 생각보다 효용이 크다. 설정이 DB에 들어갔는지, 올바른 PG 타입이 활성화 상태인지를 코드 안 보고도 확인할 수 있다. 운영자 입장에서 "개발자 불러야 하나" 싶은 상황을 셀프 체크할 수 있게 되는 거라, 팀 리소스 낭비도 준다.

한 가지 아쉬운 점은 PgConfigUtil 단위 테스트를 이번 커밋에 같이 못 넣었다는 것. 분기 가드 로직이 사이트 ID 케이스별로 꼼꼼히 커버되는지 테스트로 보장해두었으면 더 좋았을 텐데, 일정상 다음으로 밀렸다. 유틸 클래스는 사이드이펙트 없이 순수 판별 로직이라 테스트 작성 난이도가 낮은 편이니, 다음 PR에서 먼저 챙길 생각이다.

다음

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

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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