결제 기능 토글 엣지 케이스 보강으로 배치 잡 차단 해소
목차
배경
이커머스 결제 플랫폼에서 기능 토글 관련 두 컴포넌트(코드 해석기 / 활성 판별기)가 엣지 케이스를 못 잡고 있었음. 파트너별로 활성 정책이 다르고, 한 곳에서 기능 코드를 해석한 뒤 다른 곳이 활성 여부를 판별하는 2단계 구조라 둘 다 보강 필요했음.
어떤 문제였나
- 해석기 쪽은 입력이 null/공백이면 그냥 false 반환. 호출부에서는 "기능이 꺼졌다"로 오해해서 디폴트 분기 탐.
- 판별기 쪽은 파트너 컨텍스트 비면 무조건 차단. 그런데 시스템 잡 일부 흐름은 컨텍스트가 비는 게 정상이라 죄다 막힘.
- 두 컴포넌트가 캐시 키를 따로 잡고 있어서, 같은 파트너 · 같은 기능인데도 가끔 결과가 갈리는 케이스 발견됨.
보강 포인트
| 구분 | 기존 | 변경 |
|---|---|---|
| 입력 검증 | null → false | null → 미해석(Optional) |
| 시스템 잡 흐름 | 컨텍스트 없으면 차단 | 정책 디폴트로 위임 |
| 캐시 | 컴포넌트별 별도 키 | 공통 키 + 네임스페이스 분리 |
코드로 보면
val resolved = resolver.resolve(code)
return resolved
.map { checker.isEnabled(it, partnerCtx) }
.orElseGet { policy.defaultFor(code) }
orElseGet 이 핵심이었음. 예전엔 false 로 떨어뜨렸는데, 이번엔 정책 객체에 위임함. 정책은 파트너 그룹별로 다르게 주입되니까 호출부에 산재해 있던 if-else 도 같이 걷어냄.
회고
- 작은 유틸이라고 방심하면 안 됨. 도메인이 결제·정산·배치까지 걸쳐 있으면 같은 컴포넌트가 흐름마다 의미가 달라짐.
- "기본값을 false 로" 식 설계는 편하지만 의미가 흐려짐. Optional / Result 한 겹을 끼우면 호출부가 "없음"과 "꺼짐"을 구분할 수 있게 됨.
- 캐시 키 컨벤션은 처음 깔 때 정해놨어야 함. 두 컴포넌트 키 합치는 마이그레이션 작업이 추가로 붙음.
- 보강 후 결제대행사 연동 분기에서 잘못 차단되던 잡 한 묶음이 정상화됨. 운영 알림이 조용해진 게 제일 체감이 컸음.
다음
댓글 0
첫 댓글 달아줘.