머천트 계좌 검증 회귀 버그 수정
목차
결제 플랫폼의 WELCOME 시스템에서 머천트 잔액 조회 및 계좌 검증이 일부 코드 경로에서 누락되었던 로직을 보충했다. 주요 변경은 파트너 관리 웹 계층과 공통 유틸리티 계층에 걸쳐 이루어졌다.
왜 회귀가 발생했나
이 버그는 전형적인 리팩토링 회귀다. 검증 로직이 여러 코드 경로에 흩어져 있는데, 한쪽 경로만 보강하고 다른 경로는 못 본 경우다.
- 초기 구현: 특정 시나리오(예: 초기 가입)에 맞춰서 검증 로직 작성
- 개선 작업: 일부 경로(예: 정산 사이클) 검증 강화 → 주 사용 경로만 수정
- 덜 쓰는 경로: 계좌 검증 호출 빈도가 낮은 곳은 눈에 띄지 않음
- 회귀 드러남: 특정 상황(분기별 정산, 루틴 체크 등)에서 검증 누락 발생
웹 컨트롤러(partner/web)와 유틸리티 계층(utl)이 분리되어 있을 때, 데이터 흐름이 여러 갈래로 나뉘면 한쪽에서 검증이 빠지기 쉽다.
변경 범위와 의도
| 파일 영역 | 계층 | 주요 변경 |
|---|---|---|
| partner/web | 웹 핸들러 | 머천트 조회 후 유효성 재확인 |
| partner/web | 응답 생성 | 검증 결과 포맷 정규화 |
| utl | 비즈니스 함수 | 검증 헬퍼 강화 |
| utl | 유틸리티 | 누락된 가드 로직 추가 |
컨트롤러 단계에서는 "이 요청에 실제 머천트 정보가 있는가"를 확인하고, 유틸리티 단계에서는 "그 머천트의 계좌가 우리 시스템에서 유효한 상태인가"를 검사하는 식으로 이중 확인 체계를 구성했다.
비슷한 패턴의 예
결제/정산 도메인에서 이런 회귀가 또 어디서 나타날까.
머천트 상태 검증 흐름 (개념)
// 초기 구현 (가입 경로)
validateForSignup(partnerId) {
partner := fetch(partnerId)
if (!partner) error
if (!partner.account) error
return partner
}
// 개선된 정산 경로 (검증 강화)
validateForSettlement(partnerId) {
partner := fetch(partnerId)
if (!partner) error
if (!partner.account?.isVerified) error
if (partner.balance < 0) error // 신규 검증
return partner
}
// ❌ 계좌 변경 경로 (회귀: 신규 검증 누락)
validateForAccountUpdate(partnerId) {
partner := fetch(partnerId)
if (!partner) error
if (!partner.account) error
// balance < 0 체크 누락! ← 회귀 지점
return partner
}
// ✓ 개선: 공통 검증 함수로 통합
validateMerchantForOperation(partnerId) {
partner := fetch(partnerId)
if (!partner) error
if (!partner.account?.isVerified) error
if (partner.balance < 0) error
return partner // 모든 경로가 같은 검증을 거침
}
이 패턴처럼, 같은 검증을 여러 함수가 제각각 구현하면 나중에 개선할 때 누락이 생긴다.
개선 방향
1. 검증 로직의 중앙화
검증은 한 곳에만 두고, 모든 호출 경로에서 재사용해야 한다. 유틸리티 함수로 단일 진입점을 만들면, 유지보수가 훨씬 쉬워진다. 검증 규칙이 바뀔 때도 한 군데만 수정하면 된다.
2. 계층별 책임 분명히
웹 계층은 "요청 데이터가 문법적으로 유효한가" 정도만 확인하고, 비즈니스 로직 계층은 "그 데이터가 우리 도메인 규칙을 만족하는가"를 책임진다. 계층을 명확히 하면, 개선 시 "유틸리티를 수정하면 모든 경로가 자동으로 개선됨"이라는 확신을 가질 수 있다.
3. 경로별 테스트 커버리지
가입, 정산, 계좌 변경, 관리자 수정 등 각 코드 경로를 직접 호출하는 통합 테스트가 있었다면, 회귀를 놓치지 않았을 것이다. 특히 우선순위가 낮은 경로일수록 테스트가 더 중요하다.
4. 코드 리뷰 체크리스트
검증 로직을 건드리는 PR에서는 "이 함수를 호출하는 모든 곳을 찾았는가?", "영향받는 경로가 모두 테스트되는가?", "공통화할 수 있는 부분이 있는가?"를 반드시 확인해야 한다. 정산, 계좌 관리 같은 민감한 영역은 특히 신경 써야 한다.
마무리
결제 플랫폼에서 "한 번 빠진 검증"은 시간이 지날수록 더 큰 버그가 될 수 있다. 금액, 계좌, 파트너 신분 같은 데이터는 한 번 틀리면 정산 오류, 감시 알림, 규정 위반까지 이어질 수 있기 때문이다. 이번 수정은 작은 패치처럼 보이지만, 여러 코드 경로의 검증을 다시 정렬한 결과다. 비슷한 회귀를 줄이려면 검증을 중앙화하고, 시나리오별 테스트를 촘촘히 하고, 리뷰 때 영향 범위를 꼼꼼히 확인하는 습관이 필요하다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.