자동화 slecs

결제·환불·정산 배치 전 영역에 결제경고 래핑 완료

목차

Phase 5C 본진 wrap이 끝났다. 백오피스, 배치, 결제, 환불 전반에 걸쳐 34개 호출처를 한 번에 정리한 커밋.

왜 이 시점에 "코드만, 운영 X"인가

payment-warning 관련 처리를 팀 전체가 단계적으로 롤아웃하는 구조였다. Phase 1~5B까지는 각 영역별로 핵심 경로부터 차례로 랩핑 대상을 좁혀왔고, 5C는 말 그대로 나머지 34곳을 한 방에 쓸어담는 단계였음.

"코드만, 운영 X"는 이 커밋의 가장 중요한 제약이다. 코드는 머지되지만 실제 운영 트리거는 별도 배포/설정 전환 시점에 맞춰 나간다는 뜻. 이 방식을 택한 이유가 있다.

  • 34곳을 한꺼번에 운영 적용하면 영향 범위 추적이 사실상 불가능
  • 코드 머지와 운영 전환을 분리하면 QA 및 스테이징 검증 윈도우를 확보할 수 있음
  • 롤백이 필요한 상황에서도 "코드 롤백"이 아닌 "설정 전환 되돌리기"로 대응 가능 → 다운타임 최소화

팀 리딩 관점에서 이 분리 원칙을 지키는 게 생각보다 쉽지 않다. 개발 완료와 운영 적용을 같은 날 처리하고 싶다는 압박이 항상 있고, 일정 타이트할수록 더 그렇다. 그래서 이 커밋 메시지에 "(코드만, 운영 X)"를 명시적으로 박아둔 것 — 이게 PR 리뷰어나 이후 배포 담당자에게 주는 안전핀 역할을 한다.

34 호출처가 걸쳐 있는 영역들

변경된 파일들을 보면 도메인이 꽤 넓다.

영역 패키지 위치 성격
쿠폰 외부 연동 coupon/external 외부 쿠폰 시스템과의 연동 처리
회원 웹 레이어 member/web 회원 관련 백오피스 호출
결제 웹 레이어 pay/web 결제/환불 요청 진입점
잔액 배치 batch/balance 주기적 잔액 정산 배치
충전 배치 batch/charge 충전 처리 배치
등급 배치 batch/grade 등급 산정 배치

이 구성이 흥미로운 건, 동기 요청(web 레이어)과 비동기 처리(batch)가 동시에 포함된다는 점이다. payment-warning 처리를 래핑하는 로직이 두 실행 컨텍스트에서 동일하게 동작해야 한다는 의미고, 이 부분이 구현할 때 가장 신경 써야 하는 지점이었음.

배치에서의 호출은 특히 주의가 필요하다. 웹 요청이야 한 건씩 들어오지만, 배치는 수백~수천 건을 루프 돌면서 처리할 수 있기 때문에 경고 처리 로직 안에서 불필요한 IO나 상태 변경이 일어나면 배치 성능에 바로 직격탄이 된다.

// 배치 컨텍스트에서 wrap 할 때 주의해야 하는 패턴 (일반 예시)
for (TargetItem item : items) {
    // 경고 체크를 루프 안에서 개별 호출하면 N+1 문제 발생 가능
    // → 배치 시작 전 일괄 조회 후 Map으로 캐싱하는 구조 권장
    warningWrapService.process(item, cachedWarningMap.get(item.getId()));
}

팀원들에게 코드리뷰 때 이 부분을 집중적으로 잡아달라고 요청했다. 배치 쪽 wrap은 web 쪽과 패턴이 달라야 한다는 걸 모르고 그냥 동일하게 붙이면 나중에 성능 이슈로 돌아오는 케이스가 많다.

Phase 방식으로 쪼개서 했을 때 체감한 것들

34곳을 한 번에 다 커밋하긴 했지만, 여기까지 오는 데 Phase 1부터 쌓아온 맥락이 있다. 각 단계에서 빠진 케이스나 예외 패턴이 나왔고, 그걸 다음 Phase 정의에 반영하면서 5C에선 상대적으로 큰 변수 없이 진행할 수 있었음.

이 방식의 트레이드오프를 솔직하게 적어두면:

  • 장점: 영향 범위를 단계별로 검증할 수 있음. 초기에 잡은 패턴이 후반 Phase에서도 그대로 통하는지 확인되면서 신뢰도가 쌓임
  • 단점: Phase 간 경계 정의가 모호하면 호출처가 어느 Phase에 속하는지 팀원들이 헷갈린다. 5C가 "본진 wrap"이라는 이름이 붙은 것도 그 이유 — "여기가 메인이고 나머지는 엣지케이스"라는 걸 명시한 것
  • 관리 비용: Phase 번호가 늘어날수록 커밋 히스토리 추적이 복잡해짐. 나중에 "5A랑 5C 차이가 뭐야?"라는 질문이 꼭 나온다

다음 단계는 5C 코드를 기반으로 스테이징 검증 후 운영 전환 일정 잡는 것. 34곳 전부 한 번에 전환이냐, 도메인별로 나눠서 전환이냐는 QA 결과 보고 결정할 예정.


다음 커밋은 아마 운영 전환 설정이나 모니터링 연동 쪽이 될 것 같다.


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

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

댓글 0

첫 댓글 달아줘.