개발 slecs

결제 기능 토글 엣지 케이스 보강으로 배치 잡 차단 해소

목차

배경

이커머스 결제 플랫폼에서 기능 토글 관련 두 컴포넌트(코드 해석기 / 활성 판별기)가 엣지 케이스를 못 잡고 있었음. 파트너별로 활성 정책이 다르고, 한 곳에서 기능 코드를 해석한 뒤 다른 곳이 활성 여부를 판별하는 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

첫 댓글 달아줘.