개발 slecs

결제 경고 25개 케이스를 레이어 전반에 걸쳐 하나로 묶어 구조화

목차

결제 경고(payment-warning) 관련 케이스들을 하나로 묶는 작업을 했다. 5C 시리즈 중 6번부터 9번까지, 출금 1건 + 등급 10건 + 회원정지·체크 12건 + 콜백 2건, 총 25개 케이스를 wrap하는 코드 작업이었음. "코드만, 운영 X" 조건이 붙어 있어서 실제 운영 반영은 아직이고, 이번 커밋은 구조를 잡아두는 단계다.


왜 이 묶음 작업이 필요했나

결제 경고 처리는 단일 흐름이 아니다. 출금 여부, 회원 등급, 정지 상태, 콜백 수신까지 각각 독립적으로 판단해야 하면서도 결국 하나의 경고 결과로 수렴해야 한다. 이게 흩어져 있으면 케이스가 늘어날수록 어디서 처리하는지 파악하기가 어려워진다.

이번에 6/7/8/9 네 개 케이스를 한 커밋에 wrap한 이유도 거기에 있다. 개별로 커밋하면 리뷰 시점에 "이 케이스가 다른 케이스랑 어떻게 연결되는지"를 추적하기 힘들어진다. 한 단위로 묶어두면 리뷰어가 케이스 간 의존 관계를 한눈에 볼 수 있고, 나중에 이슈가 생겼을 때 되돌아보기도 편하다.

파일 분포를 보면 이 작업이 얼마나 여러 레이어에 걸쳐 있는지 바로 보인다.

패키지 영역 역할
grade/web 등급 관련 웹 레이어 처리
member/web 회원정지·체크 웹 레이어
batch/grade 등급 배치 처리
co/pay/web 출금 관련 웹 레이어
co/payment/web 결제 공통 웹 레이어
utl 유틸리티 (공통 처리)

웹 레이어 4개 + 배치 1개 + 유틸 1개. 단순 기능 추가가 아니라 시스템 전반에 경고 처리 포인트를 심는 작업임을 알 수 있다.


케이스 설계에서 신경 쓴 부분

출금 1건은 케이스 수가 적다고 단순한 게 아니다. 출금 흐름은 결제 경고 중 가장 민감한 영역 중 하나라서, wrap할 때 조건 분기를 최소화하고 명확하게 유지하는 게 중요했다. 코드가 복잡해지면 나중에 다른 팀원이 "이 조건이 왜 있지?" 하고 헤매게 된다.

등급 케이스 10건은 반대로 분기가 많다. 등급별로 경고 임계값이 다를 수 있고, 배치(batch/grade)에서도 별도로 처리되기 때문에 웹 레이어 처리와 배치 처리가 겹치지 않도록 설계 경계를 명확히 해야 했다.

회원정지·체크 12건이 이번 커밋에서 볼륨이 가장 크다. 정지 상태 체크는 여러 시점(로그인, 결제 요청, 콜백 수신 등)에서 발생할 수 있어서 케이스가 자연스럽게 많아진다. 이걸 member/web에 집중시키되 유틸(utl)에서 공통 처리를 뽑아내는 구조로 잡았다.

// 경고 케이스 wrap 패턴 (예시)
// 각 케이스는 PaymentWarningCase enum 또는 상수로 관리
// wrap 메서드는 케이스 식별자 + 컨텍스트를 받아서 경고 처리를 위임

PaymentWarningContext ctx = PaymentWarningContext.builder()
    .caseId("5C-7")          // 등급 케이스
    .memberId(memberId)
    .gradeCode(gradeCode)
    .build();

paymentWarningHandler.wrap(ctx);

실제 코드가 위와 완전히 같진 않지만, 핵심은 케이스 식별자를 명시적으로 들고 다니는 것. 경고 처리 로직이 흩어지면 어떤 케이스가 실행됐는지 로그에서도 추적이 안 된다.

콜백 2건은 케이스 수는 작지만 비동기 흐름이 끼어 있어서 정지 체크나 등급 처리와 타이밍이 맞지 않으면 경고가 누락될 수 있다. 이번 wrap에서는 콜백 수신 시점에 경고 컨텍스트가 이미 세팅되어 있어야 한다는 전제를 코드 구조에 반영해뒀다.


"코드만, 운영 X" 원칙에 대해

이 커밋에 붙은 조건 중 하나가 "코드만, 운영 X"다. 팀 리딩 관점에서 이 구분은 꽤 중요하다. 코드가 머지됐다고 운영에 즉시 영향이 가면 안 되는 작업들이 있고, 그런 작업은 feature flag든 배포 분리든 의도적으로 운영 적용 시점을 통제해야 한다.

이번 케이스들이 그 사례다. 경고 처리 로직이 25개 케이스에 걸쳐 여러 레이어에 심기는 작업이니, 코드 구조가 완성된 후 QA와 검증을 거쳐서 운영에 올리는 게 맞다. 커밋 단계에서 이 의도를 명시해두면 나중에 "이거 운영 반영됐어요?" 같은 혼선을 줄일 수 있다.

코드 리뷰할 때도 마찬가지다. 운영 반영 여부가 불분명한 커밋은 리뷰어가 "이게 지금 바로 나가는 건지" 확인하느라 에너지를 쓴다. 커밋 메시지에 상태를 명시해두는 것만으로 리뷰 비용이 줄어든다.

5C 시리즈 나머지 케이스들 마무리되면 전체 wrap 구조를 한 번 더 정리할 예정이다.

다음


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

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

댓글 0

첫 댓글 달아줘.