software-design
집을 구할 때 직접 집주인에게 연락하지 않고, 부동산 중개인을 통해 정보를 받고 계약을 진행하는 과정을 떠올려봅시다. 이때 중개인은 수요자(클라이언트)와 공급자(서버)를 연결해주는 역할만 할 뿐, 거래되는 실제 집에는 관여하지 않습니다. 이처럼 서로 직접 연결되지 않은 구성 요소들 사이에서 중재자 역할을 하는 구조가 소프트웨어의 브로커(Broker) 패턴과 닮아 있습니다.
Broker Pattern은 분산된 소프트웨어 구성 요소(컴포넌트)들 간의 통신을 중앙 중재자(Broker)가 관리하는 아키텍처 구조입니다. 클라이언트는 브로커에게 서비스를 요청하고, 브로커는 적절한 서버 컴포넌트와 연결해 요청을 전달합니다. 이 과정에서 클라이언트와 서버는 서로의 존재나 위치를 알 필요가 없으며, 네트워크 주소, 프로토콜, 세부 구현은 모두 브로커가 숨깁니다. 즉, 브로커가 연결·라우팅·전달·정책 적용을 전담하는 셈입니다.
브로커 패턴은 다양한 환경에서 구현됩니다. 예를 들어, 분산 시스템에서는 여러 서버 간 작업을 조율하고 요청을 분배하는 데 활용되며, RPC(Remote Procedure Call)에서는 원격 함수 호출을 가능하게 하는 핵심 메커니즘으로 사용됩니다. CORBA나 Java RMI 같은 분산 객체 기술에서도 표준적으로 적용되고, 마이크로서비스 환경에서는 서비스 메시(mesh)나 API 게이트웨이가 사실상 브로커 역할을 합니다. 또한 Kafka, RabbitMQ, ActiveMQ 같은 메시지 브로커는 이 패턴의 대표적인 실체 구현입니다.
Broker Pattern의 강점은 느슨한 결합과 확장성입니다. 클라이언트와 서버가 직접 연결되지 않기 때문에 서비스 교체나 확장이 용이하며, 새로운 서버나 서비스가 추가되더라도 클라이언트는 오직 브로커만 바라보면 됩니다. 또한 브로커가 서비스 레지스트리, 로드 밸런싱, 인증·보안 정책을 중앙에서 관리할 수 있어 운영 효율성이 높습니다. 이뿐만 아니라 서로 다른 프로토콜과 플랫폼 간 통신도 브로커가 중재하여 이기종 연동을 지원합니다.
하지만 브로커 패턴은 단일 장애 지점(SPOF)이라는 치명적 단점이 있습니다. 브로커에 문제가 생기면 전체 통신이 중단될 수 있습니다. 또한 모든 요청이 브로커를 거치므로 성능 병목이나 지연(latency) 증가가 발생할 수 있습니다. 따라서 운영 환경에서는 브로커 자체를 분산·고가용성 구조로 설계해야 안정성을 보장할 수 있으며, 모니터링과 장애 대응 체계 또한 반드시 마련되어야 합니다.
| 구분 | Broker Pattern | Event-Bus Pattern | Client-Server 아키텍처 |
|---|---|---|---|
| 핵심 개념 | 중개자(Broker)가 요청 라우팅·서비스 발견·보안/정책을 중앙에서 중재 | 발행자–버스–구독자 구조로 이벤트를 느슨하게 전달 | 클라이언트가 서버에 직접 요청/응답 |
| 적용 범위 | 분산 시스템 간 동기/비동기 호출 중재 | 애플리케이션 내부(또는 경량 분산) 의 이벤트 흐름 | 단일/다중 서버 기반 서비스 전반 |
| 결합도 | 낮음(서비스 위치/프로토콜 숨김) | 매우 낮음(발행자–수신자 서로 모름) | 중간(클라이언트가 서버 엔드포인트 인지) |
| 통신 방식 | RPC/메시징(동기·비동기 혼용) | 비동기 이벤트(주로 메모리/경량 버스) | 주로 동기 요청/응답(HTTP 등) |
| 중앙 구성요소 | Broker(서비스 레지스트리, 라우팅, 정책, LB) | Event Bus(이벤트 분배) | Server(리소스/로직 보유) |
| 라우팅/정책 | 고급 라우팅·버전·A/B·보안 정책 적용 용이 | 토픽/채널 기반 분배, 라우팅은 제한적 | 서버 주소/경로 기반 단순 라우팅 |
| 확장성 | 높음(브로커 수평 확장/클러스터) | 높음(구독자 추가로 확장) | 서버 수평/수직 확장 필요 |
| 장점 | 서비스 발견, 프로토콜 추상화, 중앙 보안/관찰성, 이기종 연동에 강함 | 모듈 결합도 최소화, 확장·재사용 용이, 이벤트 중심 설계에 적합 | 단순·직관, 구현 쉬움, 디버깅 용이 |
| 단점 | 브로커 SPOF/지연 위험, 운영 복잡도↑, 장애전환 필요 | 흐름 추적/디버깅 어려움, 이벤트 남용 시 복잡성↑ | 서버 SPOF/병목 위험, 결합도 상대적으로↑ |
| 대표 기술 | gRPC + 서비스 디스커버리, API Gateway, Service Mesh(Envoy/Istio), Kafka/RabbitMQ(브로커형) | 앱 내부 EventBus(Guava, Node/EventEmitter), 경량 메시지 버스 | Nginx/Express/Spring MVC, REST/GraphQL |
| 적합한 상황 | 마이크로서비스, 이기종 서비스 통합, 중앙 정책/보안/가시성 필요 | UI/게임/IoT/도메인 이벤트 처리, 플러그인형 모듈 확장 | 단순 웹/백엔드, 명확한 요청-응답 흐름 |
Broker 패턴은 중앙의 브로커가 클라이언트와 서버를 똑똑하게 연결해주는 구조이고, Event-Bus 패턴은 발행자가 이벤트만 던지면 관심 있는 구독자가 알아서 반응하는 구조입니다. 반면 Client-Server 패턴은 특정 서버에 직접 요청하고 응답을 받는 가장 단순한 구조로, 각 패턴은 연결 방식과 유연성, 단순성 측면에서 서로 다른 강점을 가집니다.
Broker Pattern은 분산된 클라이언트와 서버 간의 직접적인 연결 없이, 중간에 위치한 브로커 컴포넌트가 요청을 중계하는 구조입니다. 이로써 유연성·확장성·중앙 관리 기능을 얻을 수 있지만, 브로커 자체가 시스템의 핵심 단일 장애 지점이 될 수 있으므로 성능, 복제, 장애 대응 설계가 반드시 고려되어야 합니다.