PG 원가를 DB 조회로 파라미터화
목차
결제 게이트웨이의 원가를 하드코딩된 값에서 데이터베이스 조회로 전환했다. 운영 환경에서 코드 배포 없이 원가 정보를 유연하게 관리하기 위한 작업이었다.
배경: 왜 코드에 박아둔 값이 문제였나
이전에는 대시보드에서 PG 원가를 여러 곳에 하드코딩해서 사용 중이었다. partner, pay, system 같은 다양한 웹 컨트롤러 모듈과 결제 유틸리티 클래스들이 각각 원가 값을 가지고 있었고, 매번 원가를 조정하려면 해당 코드를 수정한 후 배포해야 했다.
실무에서 보면 PG 원가라는 건 절대 고정값이 아니다. 거래액이 커지거나 협력사 계약이 바뀔 때마다 변할 수 있다. 게다가 대시보드는 여러 팀이 참고하는 정산/분석 영역이라 원가 오류는 곧 신뢰도 하락으로 이어진다. 그런데 그때마다 개발 배포를 거쳐야 한다는 건 순환 시간(turnaround time)이 길어지고, 긴급 상황에 대응이 느려진다는 뜻이다.
또 다른 문제는 중복이었다. 같은 원가 값이 여러 파일에 산재해 있으면, 하나를 빼먹고 수정할 가능성이 높아진다. 실제로 정산 시 컨트롤러마다 원가가 다르게 계산되는 버그가 발생하기도 쉽다.
작업 내용: DB 테이블에서 조회하도록 변경
tb_platform_fee 테이블에 pg_cost 컬럼으로 PG 원가를 저장하고, 필요할 때마다 조회하게끔 파라미터화했다. 변경 범위는 다음과 같았다:
| 영역 | 변경 내용 |
|---|---|
| Web 컨트롤러 (partner, pay, system) | 하드코딩된 원가 제거, DB 조회 호출로 변경 |
| 결제 유틸리티 (payment) | 상수나 고정값 대신 조회 메서드 호출 |
| SQL 매퍼 | pg_cost 조회 쿼리 추가 |
코드 패턴으로 보면, 이전엔 이런 식이었을 것이다:
// Before: 하드코딩
int PG_COST = 20; // 수수료 2.0%
int calculatedFee = amount * PG_COST / 100;
이제는:
// After: DB 조회
int pgCost = platformFeeService.getPgCost(); // tb_platform_fee에서 조회
int calculatedFee = amount * pgCost / 100;
여러 클래스가 동일한 원가를 필요로 했기 때문에, 중앙화된 서비스나 유틸리티 메서드로 단일화한 후 모두 그곳을 참조하도록 정리했다. 이렇게 하면 원가 변경 시 DB 한 곳만 업데이트하면 된다.
운영 관점의 이점들
첫 번째로는 배포 주기 단축이다. 원가 변경이 필요할 때 더 이상 개발팀의 배포를 기다릴 필요가 없다. 운영자가 직접 (또는 권한 있는 관리자가) DB를 업데이트할 수 있으면 분 단위로 반영된다.
두 번째는 데이터 일관성이다. 모든 계산이 동일한 DB 값을 참고하므로, 컨트롤러마다 다른 원가를 쓰는 버그가 원천 차단된다. 감사(audit) 추적도 DB 로그로 남으므로, 언제 뭐가 바뀌었는지 쉽게 추적할 수 있다.
세 번째는 확장성이다. 나중에 원가가 거래처별, 상품별로 다르게 적용되어야 한다면, DB 스키마에 컬럼만 추가하면 된다. 코드 변경은 최소화된다.
이런 작업에서 배운 점
하드코딩을 DB로 옮기는 건 단순해 보이지만, 실제로는 몇 가지 신경 써야 할 부분이 있다.
첫째, 조회 성능이다. 매 요청마다 DB를 hit하면 오버헤드가 생길 수 있다. 원가처럼 자주 안 바뀌는 값이라면 애플리케이션 시작 시 캐시해두거나, Redis 같은 빠른 캐시를 둬서 DB 부하를 줄이는 게 좋다.
둘째, 기본값 처리다. DB 조회가 실패했을 때 어떻게 할 건지 정해야 한다. 예외를 던질 건지, 안전한 기본값(예: 원가 0, 즉 수수료 면제)을 쓸 건지 미리 정해두면 운영 중 황당한 상황을 피할 수 있다.
셋째, 마이그레이션 전략이다. 이미 운영 중인 시스템이라면, 기존 하드코딩 값과 DB 값이 처음엔 일치해야 한다. 검증 단계를 거친 후 천천히 전환하면 리스크가 줄어든다.
일반적으로 이런 류의 "설정값 외부화" 작업은 초기 개발 때 놓치기 쉽다. 개발 단계에선 고정값으로 충분해 보이기 때문이다. 하지만 운영 환경으로 가면서 유연성의 필요성이 드러난다. 그래서 이런 작업을 꾸준히 작은 규모로 진행하는 게, 나중에 큰 리팩토링으로 고생하는 것보다 훨씬 낫다는 걸 느낀다. 팀으로 일할 때도 "이 값이 정말 고정일까?"를 코드리뷰 때 가볍게 던지는 게 이런 부채를 줄인다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.