[8] 디자인패턴: 퍼사드 패턴 (Facade)

1. 들어가며

 '퍼사드(Facade)'는 프랑스어로 건물의 정면을 뜻한다. 우리가 건물을 볼 때 내부의 복잡한 배관이나 전기 배선은 보지 않고 정면 외벽만 보듯이, 소프트웨어 설계에서도 내부의 복잡한 의존 관계를 감추고 단순한 '창구'를 마련하는 것이 핵심인 것이다.

1.1. 문제 상황: 복잡성의 전이

 만약 '상품 주문'이라는 기능을 구현하기 위해 클라이언트(Controller)가 주문 서비스, 재고 서비스, 결제 서비스, 배송 서비스를 각각 직접 호출해야 한다면 어떻게 될까?

1. 클라이언트 코드가 너무 비대해진다 (Fat Controller).
2. 내부 서비스 구조가 변경될 때마다 클라이언트 코드도 함께 수정해야 한다.
3. 클라이언트가 내부 시스템의 동작 순서나 의존성을 모두 파악하고 있어야 하므로 결합도가 극도로 높아진다.

---

2. 퍼사드 패턴의 구조

퍼사드 패턴은 클라이언트와 복잡한 서브 시스템 사이에서 '중재자' 역할을 수행한다.

2.1. 구성 요소

1. 퍼사드 (Facade): 서브 시스템의 기능을 조합하여 단순화된 메서드를 제공한다. 클라이언트는 오직 이 퍼사드와 통신한다.
2. 서브 시스템 (Subsystems): 실제 기능을 수행하는 다양한 클래스들이다. 퍼사드가 존재한다는 사실조차 모르며 각자의 역할에만 충실하다.
3. 클라이언트 (Client): 퍼사드를 호출함으로써 복잡한 시스템을 간접적으로 이용한다.

---

3. 스프링 부트로 구현하는 퍼사드 패턴

실무에서 가장 흔히 볼 수 있는 '주문 프로세스 오케스트레이션'을 예로 들어본다.

3.1. 개별 서브 시스템 (Subservices)

@Service
public class OrderService {
    public void createOrder() { System.out.println("주문을 생성합니다."); }
}

@Service
public class PaymentService {
    public void processPayment() { System.out.println("결제를 진행합니다."); }
}

@Service
public class StockService {
    public void decreaseStock() { System.out.println("재고를 차감합니다."); }
}

3.2. 퍼사드 클래스 구현

 여러 서비스를 조합하여 하나의 완성된 비즈니스 흐름을 만든다. 스프링에서는 주로 ~Facade 또는 서비스 통합 역할을 하는 서비스 클래스가 이 역할을 수행한다.

@Component
@RequiredArgsConstructor
public class OrderFacade {

    private final OrderService orderService;
    private final PaymentService paymentService;
    private final StockService stockService;

    // 복잡한 과정을 하나의 단순한 인터페이스로 통합
    @Transactional
    public void placeOrder() {
        orderService.createOrder();
        paymentService.processPayment();
        stockService.decreaseStock();
        System.out.println("주문 완료 프로세스가 성공적으로 종료되었습니다.");
    }
}

3.3. 클라이언트에서의 사용

 컨트롤러는 이제 단 하나의 퍼사드 메서드만 호출하면 된다. 내부에서 결제가 먼저인지 재고 차감이 먼저인지 고민할 필요가 없는 것이다.

@RestController
@RequiredArgsConstructor
public class OrderController {
    private final OrderFacade orderFacade;

    @PostMapping("/orders")
    public ResponseEntity<String> order() {
        orderFacade.placeOrder();
        return ResponseEntity.ok("주문 성공");
    }
}

---

4. 실무에서의 응용과 스프링 내부 사례

4.1. 서비스 오케스트레이션 (Orchestration)

 여러 개의 미세한 서비스(Granular Services)를 조합하여 거대한 비즈니스 유스케이스를 완성할 때 퍼사드 패턴이 필수적으로 사용된다. 이는 단일 책임 원칙(SRP)을 지키면서도 사용자에게 편리한 API를 제공하는 방법인 것이다.

4.2. 외부 라이브러리 추상화

 복잡한 설정과 사용법을 가진 외부 SDK(예: AWS S3 SDK, 외부 결제 모듈 등)를 사용할 때, 이를 감싸는 퍼사드 클래스를 두면 라이브러리가 교체되더라도 비즈니스 로직에는 영향이 없다.

4.3. 스프링 내부의 SLF4J

 자바 진영의 로깅 라이브러리인 SLF4J가 퍼사드 패턴의 전형이다. SLF4J는 실제 로깅 구현체(Logback, Log4j2 등)가 무엇이든 상관없이 개발자에게 일관된 로깅 인터페이스를 제공하는 '로깅 퍼사드'인 것이다.

---

5. 장단점 및 주의사항

5.1. 장점

• 낮은 결합도: 클라이언트와 서브 시스템 사이의 의존성을 끊어준다.
• 가독성 향상: 클라이언트 코드가 단순해지고 전체적인 비즈니스 흐름을 파악하기 쉬워진다.
• 계층화된 설계: 각 계층이 자신의 역할에만 집중할 수 있게 된다.

5.2. 주의사항: 거대 객체(God Object)의 위험

퍼사드가 너무 많은 서브 시스템을 관리하다 보면, 퍼사드 클래스 자체가 비대해져서 관리가 힘들어지는 상황이 발생할 수 있다. 이럴 때는 도메인별로 퍼사드를 쪼개거나 다른 디자인 패턴과의 조합을 고민해야 하는 것이다.