Facade vs Adapter: 언제 퍼사드, 언제 어댑터?

왜 둘을 헷갈릴까?

두 패턴 모두 ‘겉’만 바꿔서 클라이언트를 편하게 해 준다는 공통점이 있다. 하지만 목표가 다르다.

• Adapter : 기존 클래스 한두 개의 인터페이스만 변환해 호환성을 맞춘다. 스마트폰 C-타입 젠더처럼 “맞지 않는 잭”을 바꿔 끼우는 느낌.
• Facade : 여러 서브시스템을 하나의 단순한 인터페이스로 감싼다. 건물 정면(façade)만 보이게 해서 내부 배선을 숨기는 전략.

---

핵심 차이, 한눈에 정리

• 의도
  • Adapter : “인터페이스 호환 안 되는데?” → 변환기 추가.
  • Facade : “인터페이스가 너무 많아 복잡해!” → 정면 하나로 통합.
• 스코프
  • Adapter는 보통 단일 객체를 래핑한다.
  • Facade는 여러 객체 혹은 모듈을 한데 묶는다.
• 영향 범위
  • Adapter 뒤에는 클래스 한두 개만 숨어 있지만,
  • Facade 뒤에는 ‘서비스 센터’처럼 복잡한 프로세스 전체가 숨겨진다.

---

선택 가이드—실전 시나리오 3컷

1. 레거시 라이브러리 메서드가 파라미터 순서까지 다르다?
   → Adapter로 시그니처만 맞추면 끝.
2. 결제·인벤토리·배송을 컨트롤러에서 각각 호출하기 버겁다?
   → Facade로 orderService.placeOrder() 한 줄에 압축.
3. 외부 결제 SDK를 교체하면서 API 경계도 단순화하려 한다?
   → Adapter로 새 SDK를 맞춘 뒤, Facade가 전체 흐름을 담당하도록 이중 적용하면 깔끔.

---

함께 쓰면 더 강력하다

• Facade 안에 Adapter : 복잡한 서브시스템(PayPal·Stripe·토스)이 서로 다른 인터페이스를 가진다면, 각 모듈을 Adapter로 맞추고 Facade가 최상위 진입점을 제공한다.
• Adapter 뒤에 Facade : 단일 라이브러리를 일단 Adapter로 호환시켜 놓고, 기능이 늘어나면 Facade로 ‘슈퍼 API’를 만든다.

---

마무리 한 줄

Adapter는 “잭 변환기”, Facade는 “서비스 창구”. 무엇을 바꾸고 감출지 먼저 정하면 선택은 쉬워진다.