Facade 패턴: 복잡한 서비스, 한 줄 인터페이스로 끝!

왜 또 Facade인가?

서비스 레이어에 Repository가 열 댓 개씩 붙고, 컨트롤러가 여러 서비스·유틸을 직접 호출하기 시작하면 의존성 지옥이 열린다. Facade 패턴은 이런 상황을 ‘CS 상담원’처럼 중간에 세워 단순한 진입점 하나로 묶어 결합도를 확 줄인다.

---

1️⃣ Facade 패턴, 핵심 개념

• 정의 : 서브시스템의 여러 인터페이스를 하나로 통합해, 고수준 인터페이스만 노출하는 구조 패턴.
• 효과 : 클라이언트는 내부 구조를 몰라도 되고, 변경은 Facade 뒤에서만 일어나므로 유지보수 위험이 급감한다.

---

2️⃣ 언제 쓰면 딱 좋을까?

• 서브 시스템·Repository가 과다해 테스트, 모킹 비용이 폭증할 때
• 컨트롤러가 순환 참조를 유발할 만큼 많은 서비스를 부르는 상황
• 레거시·외부 라이브러리 API를 숨겨 계약만 안정적으로 유지하고 싶을 때

---

3️⃣ Spring Boot 실전 – 주문 처리 Facade 예시

@Service
@RequiredArgsConstructor
public class OrderFacade {

    private final InventoryService inventory;
    private final PaymentService payment;
    private final ShippingService shipping;

    @Transactional
    public OrderReceipt placeOrder(OrderRequest req) {
        inventory.reserve(req.items());           // 재고 차감
        PaymentResult paid = payment.charge(req); // 결제
        shipping.requestPickup(req, paid);        // 배송
        return new OrderReceipt(paid.getId(), "READY");
    }
}

컨트롤러는 orderFacade.placeOrder() 한 줄이면 끝이다. 내부 서비스가 얼마나 바뀌든 Facade 시그니처만 지키면 상위 계층은 안전하다. 실무에서도 Repository 20여 개를 Facade로 정리하며 테스트 난이도를 대폭 낮춘 사례가 보고됐다.

---

4️⃣ 구현 꿀팁

1. 도메인별 Facade 분리 : MemberFacade, PaymentFacade처럼 책임을 작게 나눠 거대 클래스화를 방지.
2. 트랜잭션 경계는 Facade에 : 여러 서비스 호출을 하나의 트랜잭션으로 묶어 일관성을 확보한다.
3. 테스트 더블 : Facade를 Mock 교체하면 하위 의존성을 일일이 Mock 하지 않아도 단위 테스트가 가능하다.
4. 과도한 래핑 주의 : 모든 것을 Facade로 숨기면 또 다른 ‘블랙박스 괴물’이 된다. 변경 가능성이 높은 흐름만 추려 적용한다.

---

5️⃣ 장·단점 스냅샷

• 👍 결합도↓ / 응집도↑ : 클라이언트 코드가 얇고 읽기 쉬워진다.
• 👍 변경 파급 최소화 : 서브시스템 교체·API 통합이 수월.
• ⚠️ Facade 비대화 : 책임 분리가 안 되면 또 다른 레거시가 된다.

---

한 줄 요약

Facade 패턴은 “복잡함은 안으로 숨기고, 밖으론 단 하나의 깔끔한 문만 남기는” 가장 현실적인 의존성 다이어트다.