156. 파사드 패턴 (Facade Pattern)

핵심 인사이트 (3줄 요약)

본질: 파사드 패턴 (Facade Pattern)은 GoF 구조 패턴으로, 복잡한 서브시스템(Subsystem)의 복잡한 인터페이스들을 하나의 단순화된 통합 인터페이스(Facade)로 감싸, 클라이언트가 서브시스템의 복잡성을 알지 못해도 쉽게 사용할 수 있게 하는 패턴이다.

가치: 서브시스템과 클라이언트 간의 결합도를 낮추고, 복잡한 초기화·설정·순서 의존성을 파사드가 캡슐화하여 클라이언트 코드를 단순화한다. 레이어드 아키텍처에서 계층 간 결합도 감소에 효과적이다.

판단 포인트: 파사드는 서브시스템 기능을 제한하는 것이 아니라 '단순화된 진입점'을 제공하는 것이다. 고급 사용자는 여전히 서브시스템에 직접 접근할 수 있으며, 파사드는 일반적인 사용 사례를 위한 편의 레이어다. 어댑터 패턴(인터페이스 변환)과 혼동하지 않아야 한다.

Ⅰ. 개요 및 필요성

복잡한 라이브러리나 프레임워크, 또는 관련 클래스들의 복잡한 사용 방법을 하나의 간단한 API로 감싸는 것이 파사드 패턴이다. '파사드(Facade)'는 건물의 외관을 의미하는 프랑스어로, 복잡한 내부 구조를 가진 건물이라도 외관(파사드)은 단순하고 아름다운 것처럼, 복잡한 서브시스템을 단순한 인터페이스로 감싸는 패턴이다.

실제 예: 비디오 변환 라이브러리는 VideoFile, CodecFactory, MPEG4CompressionCodec, OggCompressionCodec, BitrateReader 등 복잡한 클래스들을 갖는다. VideoConverter.convert(file, format)처럼 단일 메서드로 감싸면 클라이언트는 내부 복잡성을 알 필요가 없다.

┌─────────────────────────────────────────────────────────────┐
│              파사드 패턴 구조                                 │
├─────────────────────────────────────────────────────────────┤
│  클라이언트                                                  │
│      │ (단일 인터페이스만 사용)                              │
│      ▼                                                      │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  Facade                                               │   │
│  │  + simpleOperation(): void {                          │   │
│  │      subsystem1.doThis();                            │   │
│  │      subsystem2.doThat();                            │   │
│  │      subsystem3.finish();                            │   │
│  │  }                                                   │   │
│  └──────────────────────────────────────────────────────┘   │
│       │           │           │                              │
│  Subsystem1  Subsystem2  Subsystem3  (복잡한 내부 구조)     │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 여행사(파사드)는 복잡한 항공권 예약, 호텔 예약, 렌터카 예약(서브시스템)을 한 번에 처리해준다. 여행객(클라이언트)은 각 서비스 시스템을 직접 알 필요 없이 여행사에 한 번만 요청한다.

Ⅱ. 아키텍처 및 핵심 원리

파사드 패턴의 핵심 원칙은 최소 지식 원칙(Law of Demeter)과 연결된다. 클라이언트가 직접 알아야 하는 클래스 수를 최소화하여 결합도를 낮춘다. 레이어드 아키텍처에서 계층 간 인터페이스로 파사드를 사용하면 계층 간 결합도가 감소한다.

항목	설명	포인트
Facade	단순화된 통합 인터페이스	VideoConverter, HomeTheaterFacade
Subsystem	복잡한 기능 구현	CodecFactory, BitrateReader
Client	Facade를 통해 서브시스템 사용	애플리케이션 코드

┌─────────────────────────────────────────────────────────────┐
│     레이어드 아키텍처에서 파사드 역할                       │
├─────────────────────────────────────────────────────────────┤
│  Presentation Layer (컨트롤러)                              │
│       │ (파사드를 통해서만 비즈니스 계층 접근)              │
│  Service Facade (파사드)                                    │
│       │           │           │                             │
│  OrderService  PaymentService  ShippingService              │
│  (서브시스템들 - 복잡한 내부 로직)                          │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 회사 대표전화(파사드)로 연락하면 담당 부서(서브시스템)로 연결된다. 고객(클라이언트)은 각 부서의 내선 번호(서브시스템 인터페이스)를 알 필요가 없다.

Ⅲ. 비교 및 연결

파사드와 어댑터 패턴의 차이를 명확히 해야 한다. 어댑터는 기존 인터페이스를 다른 인터페이스로 변환하지만, 파사드는 복잡한 여러 인터페이스를 단순한 하나로 통합한다.

비교 축	A	B
목적	복잡성 은닉 (단순화)	인터페이스 변환 (호환성)
인터페이스 수	여러 → 하나	하나 → 다른 하나
결합도	클라이언트-서브시스템 낮춤	클라이언트-Adaptee 연결
사용 시점	복잡한 서브시스템 사용 시	호환되지 않는 인터페이스 연결 시

📢 섹션 요약 비유: 파사드는 복잡한 집(서브시스템)의 현관문(단일 입구)을 제공하는 것이고, 어댑터는 한국 콘센트(인터페이스)를 미국 플러그(다른 인터페이스)에 맞게 변환하는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

스프링에서 파사드의 가장 일반적인 구현은 서비스 레이어(Service Layer)다. 여러 도메인 서비스(리포지토리, 이메일 서비스, 알림 서비스)를 조합하는 OrderApplicationService처럼, 애플리케이션 서비스가 도메인 서비스들의 파사드 역할을 한다.

판단 체크리스트

파사드가 서브시스템의 복잡한 사용 순서와 초기화를 캡슐화하는가?
클라이언트가 파사드를 통해서만 서브시스템을 사용하고 있는가?
파사드가 서브시스템 기능을 제한하지 않고 필요 시 서브시스템 직접 접근이 가능한가?
파사드와 어댑터 패턴을 혼동하지 않고 목적에 맞게 사용하는가?
레이어드 아키텍처에서 파사드로 계층 간 결합도가 감소했는가?

📢 섹션 요약 비유: 콜센터(파사드)는 복잡한 사내 시스템(서브시스템)을 고객(클라이언트) 대신 처리한다. 고객은 콜센터 번호 하나만 알면 된다.

Ⅴ. 기대효과 및 결론

파사드 패턴을 적용하면 클라이언트 코드가 단순해지고, 서브시스템 내부 변경이 클라이언트에 영향을 주지 않아 변경 격리가 달성된다. 레이어드 아키텍처에서 계층 간 결합도를 낮추는 데 효과적이며, 복잡한 라이브러리나 서드파티 시스템 통합 시 ACL과 함께 사용하면 강력하다.

한계는 파사드가 모든 기능을 노출하지 않아 고급 사용에 제한이 있을 수 있고, 파사드 자체가 너무 커지면 '신(God) 파사드'가 되어 SRP를 위반할 수 있다.

미래 방향으로는 ① BFF(Backend for Frontend) 패턴이 마이크로서비스의 파사드로 발전, ② API Gateway가 외부 클라이언트를 위한 서비스 파사드로 진화하고 있다.

📢 섹션 요약 비유: 리모컨(파사드)은 TV의 복잡한 내부 회로(서브시스템) 없이 사용자(클라이언트)가 TV(서브시스템)를 간단하게 제어하게 해준다.

📌 관련 개념 맵

[복잡한 서브시스템 사용 문제] → [파사드 패턴] → [서비스 레이어] → [API 게이트웨이] → [BFF 패턴]

개념	연결 포인트
어댑터 패턴	인터페이스 변환 (파사드는 단순화)
API 게이트웨이	마이크로서비스의 외부용 파사드
BFF 패턴	클라이언트별 최적화된 파사드
Law of Demeter	파사드로 달성하는 최소 지식 원칙

📈 관련 키워드 및 발전 흐름도

[GoF Facade 패턴(1994)] → [레이어드 아키텍처 계층 파사드] → [API 게이트웨이] → [BFF(Backend for Frontend)] → [GraphQL 파사드]

👶 어린이를 위한 3줄 비유 설명

파사드는 여행사처럼, 복잡한 항공·호텔·렌터카 예약을 한 번에 처리해줘요.
여행객(클라이언트)은 각 시스템을 알 필요 없이 여행사(파사드)에만 말하면 돼요.
API 게이트웨이나 서비스 레이어가 바로 이 파사드 역할을 해요!