새로운 상품권 공급사 연동 간편화

새로운 상품권 발송 공급사인 클라이프스를 시스템에 추가하는 작업을 완료했다. 단순해 보이는 "공급사 추가"지만, 팀이 이후 계속해서 공급사를 확장할 수 있도록 구조적 기반을 다지는 중요한 마일스톤이었다.

상품권 발송 시스템, 왜 여러 공급사를 대비해야 하는가

실무에서 상품권 발송 시스템은 여느 외부 연동 기능처럼, 한 공급사만으로는 부족한 경우가 많다. 거래량 증가 시 공급사 처리 능력 부족, 가격 변동에 따른 공급사 변경, 장애 발생 시 페일오버, 지역별로 지원하는 공급사가 다름 등등. 만약 처음부터 "클라이프스만 쓰면 되지" 하고 하드코딩했다면, 6개월 뒤 "아, 다른 공급사도 추가해야겠다"는 요청이 들어올 때 전체 로직을 뜯어고쳐야 한다. 그게 얼마나 비용이 드는지는 이미 다 안다.

이번 작업: Provider 패턴으로 확장성 확보

이 문제를 풀기 위해 Provider 패턴을 도입했다. 공급사별 구현을 분리하고, 실행 시점에 어떤 공급사를 쓸지 선택하는 구조다.

변경 사항은 세 가지:

이 구조의 핵심은 기존 코드를 최소한으로 건드린다는 것이다. 새로운 공급사를 추가할 때는:
- 새 공급사 구현체 클래스 하나 작성
- Factory에 "공급사명 X가 들어오면 클래스 Y를 쓰라" 한 줄 추가
- 필요한 DB 쿼리를 매퍼에 추가

딱 이것뿐이다.

왜 이런 설계를 선택했는가

다른 접근법과 비교해보자:

조건문으로 처리한다면:

if (provider.equals("CHLIFES")) {
    // 클라이프스 로직
} else if (provider.equals("OTHER")) {
    // 다른 공급사 로직
}

새 공급사가 들어올 때마다 기존 조건문을 건드려야 한다. 그러면 회귀 테스트 부담이 늘어난다. 또 코드를 읽는 입장에서도 모든 공급사 로직이 한 메서드에 섞여 있으니 복잡도가 떨어진다.

Provider 패턴을 쓰면:
- 기존 코드는 그대로. 새 공급사는 새 클래스로 추가 (Open-Closed 원칙)
- 각 공급사 구현을 독립적으로 테스트 가능
- 신입 팀원도 "아, 이 구조구나" 하고 빠르게 공급사를 추가할 수 있음

팀 관점에서는, 초기 아키텍처를 제대로 잡으면 나중에 요청사항 추가할 때 팀의 속도를 잃지 않는다.

실제 운영 관점에서의 고민

솔직하게 말하면, 처음부터 Provider 패턴을 쓸지 말지 고민이 있었다. "아직 클라이프스 하나뿐인데, 과하게 복잡한 설계 아닌가?"라는 생각도 들었다. 하지만 경험상 상품권, 결제, 배송처럼 "외부 파트너 연동" 기능은 시간이 지날수록 다양한 요청이 생긴다. 초기 몇 개월은 한두 공급사로 충분하지만, 비즈니스 확장 시기가 오면 반드시 "다른 공급사도 지원해달라"는 요청이 들어온다. 그때 "구조를 다시 짜야 합니다"라고 할 수 없다. 이미 프로덕션에서 상품권을 발송하고 있으니까.

그래서 이번에는 미리 확장 가능한 구조를 깔았다. 조금 더 코드는 늘겠지만, 다음 공급사를 추가할 때 기존 로직을 건드리지 않을 수 있다. 그게 팀의 리스크를 낮추는 길이라고 봤다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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