현재 PaliPay 라는 외국인 관광객 대상 가상 지갑 서비스를 진행중이다. 우리가 사용하는 페이서비스처럼 가상 지갑이 있고, 내가 가진 은행의 계좌를 등록시켜 거기서 돈을 빼오는 형식이다.
이러한 과정을 보여주기 위해 World Bank 라는 다국적 금융 서비스도 함께 개발한다.
나는 이번 프로젝트에서 World Bank와 PaliPay의 유저 백엔드, 프론트 역할을 맡아 진행중이다.
이번 블로그 내용은 World Bank의 User 서비스를 구현하면서 배운
Strategy + Factory Patten에 대해 작성해보려고 한다.
1. Design Patten
1-1. Strategy Patten
**전략 패턴**은 객체의 행위를 동적으로 바꾸고 싶을 때, 직접 로직을 수정하지 않고 전략이라고 부르는 알고리즘을 갈아 끼우며 사용하는 패턴이다. (행위 패턴)
핵심 : '무엇을 하는가' 와 '어떻게 하는가' 를 분리한 것.
장점 : 새로운 기능(전략)이 추가되어도 기존의 본체 코드를 수정할 필요가 없어 유지보수가 매우 유연하다.
1-2. Factory Patten
**팩토리 패턴**은 객체 생성 로직을 별도의 클래스로 분리하여, 클라이언트가 직접 객체를 생성하지 않고 팩토리를 통해 필요한 객체를 얻는 패턴이다. (생성 패턴)
핵심 : 객체 생성의 책임과 사용의 책임 분리
장점 : userservice는 그냥 factory.getStrategy(국적) 한 줄만 호출하면 국적이 추가되던말던 수정될 필요가 없다. 팩토리 내부나 새로운 전략 클래스만 만들면 된다.
1-3. 실과 바늘 같은 Strategy 와 Factory
- Strategy Pattern (전략): "국적별로 다른 로직을 수행하는 클래스들을 만든 것" 그 자체 (예: `KoreaUserStrategy`, `USAUserStrategy` 등)
- Factory Pattern (팩토리): "사용자의 국적 정보를 보고 어떤 전략 클래스를 꺼내줄지 결정하는 관리자" 역할
만약 팩토리(StrategyFactory)가 없다면, 유저 가입 서비스 코드 안에
if (국적 == 한국) { new KoreaStrategy() } ... 같은 지저분한 코드가 들어갔을 텐데, 팩토리를 만듦으로써 그 선택 로직마저 깔끔하게 분리
2. 우리의 ERD
각 국적별 Bank Entity 가 유저, 거래 내역과 1:1 관계로 연결되어 있다.
사용자는 하나의 국적을 가지고, 그 국적에 해당하는 전용 은행 계좌와 연결된다.
3. 팀원이 설계한 폴더 분석
이체나 계좌 연결 로직이 국적별로 파편화되지 않도록 공통 인터페이스를 두고 나라별 은행 로직을 전략 클래스로 독립시켜 둠.
나라마다 계좌 번호 체계, 통화 단위가 모두 다르기 때문에 이를 하나의 service에서 if 혹은 switch 를 사용해 처리했다면 끝도 없이 길어졌을 것이다 ..
4. 나도 할래
| '확장성'과 '일관성'
World Bank 라는 시스템 전체가 '국적'을 기준으로 돌아가고 있었고, 먼저 개발된 finance 폴더가 흐름을 전략 패턴으로 깔끔하게 풀어내고 있었다.
내가 만드는 유저 서비스도 결국 국적별 Bank Entity와 1:1 로 매핑되어야 했기 때문에, 시스템 전체의 코드 일관성을 위해 동일한 설계 철학을 가져가기로 했다.
5. 앞으로 어떤 상황에서 이 패턴을 적용하면 좋을까?
-
분기 처리가 데이터가 아닌 로직일 때
- 단순한 값 비교가 아니라 조건에 따라 실행되어야 하는 알고리즘 자체가 완전히 다를 때
-
요구사항 확장이 빈번할 때
- 지금의 국적처럼 앞으로 어떤 케이스가 추가될지 모르는 가변적인 상황일 때 -
코드의 가독성을 높이고 싶을 때
- 복잡한 if 문, switch 문을 사용하지 않고 각 로직을 명확한 이름을 가진 클래스로 캡슐화 하고 싶을 때
