디자인 패턴

Circuit Breaker 의 차단 트리거와 회복 전략은 함께 설계되어야 한다. 회복 없는 차단은 의존성을 영구히 끊고, 차단 기준 없는 회복은 무의미한 반복 전이다.

Rate Limit 알고리즘을 고르기 전에, 어느 계층에서 보호할지가 먼저 알고리즘의 선택지를 좌우한다. L4/L7/Application 계층과 Token/Leaky/Sliding/Fixed 알고리즘의 교차 관계를 정리한다.

Observer는 상태 변화를 구독자에게 통지하는 일대다 관계로 결합을 끊는다. Subject는 누가 듣는지 모른 채 통지만 한다. EventEmitter, RxJS, 이벤트 기반 아키텍처가 모두 여기서 확장된다. 브로커를 매개하는 pub/sub와는 구분된다.

Strategy는 알고리즘군을 같은 인터페이스로 캡슐화해 런타임에 교체한다. if/switch 분기 수정 대신 전략 추가로 확장한다. 일급 함수가 있는 언어에서는 별도 Strategy 클래스가 함수 하나로 흡수된다.

Facade는 복잡한 서브시스템에 단순한 진입점을 제공해 클라이언트와 내부 구현의 결합을 끊는다. 서비스 레이어, 라이브러리 SDK가 사실상 Facade다. Adapter는 인터페이스 변환, Mediator는 양방향 조정이라는 점에서 구분된다.

Decorator는 상속의 조합 폭발을 조합으로 대체한다. 같은 인터페이스를 유지하는 래퍼를 런타임에 겹쳐 기능을 동적으로 더한다. java.io, Python 함수 데코레이터, 웹 미들웨어 체인이 모두 같은 의도의 변주다.

Builder 는 생성자의 세 가지 한계가 동시에 모일 때의 해결책이다. 매개변수 수가 많고, 일부가 선택적이고, 단계적 검증이 필요한 경우. 셋이 같이 모이지 않으면 다른 도구로 충분하다. 언어가 named/default 매개변수를 제공하면 Builder 의 필요도 자연스럽게 줄어든다.

Factory 의 공통 의도는 객체 생성과 사용의 분리다. 세 변형 (Factory Method / Abstract Factory / Static Factory Method) 은 분리 방식이 다르고 적합한 상황도 다르다. 실무에서는 Static Factory Method 가 가장 자주 쓰이고, DI 컨테이너가 등장하면 명시적 Factory 의 일부 역할이 컨테이너로 흡수된다.

Singleton 은 가장 단순한 패턴이지만 안티패턴 논란의 대표 사례다. 단일 인스턴스 보장과 전역 접근을 한 패턴에 묶은 결정이 강한 결합과 테스트 어려움의 원인. DI 가 두 의도를 분리한 일반 대안이다.

DIP(원칙), IoC(패턴), DI(기법)는 서로 다른 추상 수준에 있는 개념이다. 위계를 분명히 봐야 프레임워크 기능과 설계 원리가 섞이지 않는다.