software-design
회사에서 공지를 알리는 단체 메신저 공지를 본 적 있으실겁니다. 인사팀이 메시지를 보내면, 이를 필요한 부서나 개인이 각자 확인하고 반응합니다. 인사팀은 누가 읽는지, 누가 반응할지 알지 못해도 필요한 사람에게는 정보가 전달되죠. 이처럼 이벤트를 한 번 발행하면 관심 있는 수신자만 이를 받아 처리하는 구조가 바로 이벤트-버스(Event-Bus) 패턴입니다. 이 방식은 조직 내 공지처럼 "누구에게 갈지 직접 알 필요 없는 메시지"를 효율적으로 전달할 때 특히 유용합니다.
Event-Bus 패턴은 시스템 내에서 컴포넌트 간 직접적인 의존 관계 없이 메시지를 주고받을 수 있도록 해주는 아키텍처 패턴입니다.
이 구조에서는 발행자와 수신자가 서로를 알 필요가 없으므로 결합도가 낮아지고, 모듈 간 독립성이 높아집니다.
Event-Bus 패턴은 이벤트 기반 시스템에서 특히 강력한 효과를 발휘합니다. 예를 들어 UI 시스템에서는 버튼 클릭이나 키 입력 같은 사용자 이벤트를 View가 발행하고, 이를 구독하는 로직 모듈이 처리할 수 있습니다. 게임 엔진에서는 플레이어 충돌이나 점수 증가 같은 게임 이벤트를 버스를 통해 전달해 여러 컴포넌트가 동시에 반응하도록 할 수 있습니다. 또한 IoT 플랫폼에서는 센서 데이터가 이벤트로 발행되면, 이를 여러 서비스가 구독하여 동시에 활용할 수 있습니다. 마지막으로 마이크로서비스 아키텍처에서는 서비스 간의 직접적인 의존성을 줄이고, 이벤트 버스를 통해 느슨하게 연결된 통신을 가능하게 합니다. 이러한 구조는 몇 가지 중요한 장점을 제공합니다. 첫째, 결합도가 낮아져 모듈 간 직접 참조를 제거할 수 있습니다. 둘째, 새로운 구독자를 추가하는 방식으로 손쉽게 확장성을 확보할 수 있습니다. 셋째, 발행자는 자신이 알지 못하는 다양한 구독자들에게 데이터를 제공할 수 있어, 재사용성 또한 높아집니다.
그러나 Event-Bus 패턴에는 단점도 존재합니다. 이벤트의 흐름이 코드에 명시적으로 드러나지 않기 때문에 디버깅이 어렵고, 이벤트를 무분별하게 남발하면 시스템 전체의 동작 경로를 추적하기 힘들어질 수 있습니다. 이는 프로젝트가 커질수록 유지보수성을 떨어뜨리는 요인이 됩니다. 따라서 이 패턴을 적용할 때는 몇 가지 가이드라인이 필요합니다. 먼저, 이벤트의 의미를 명확히 하기 위해 이벤트 이름 규칙을 정의해야 합니다. 예를 들어 user.created, order.completed와 같이 직관적이고 일관된 이름을 사용하는 것이 좋습니다. 둘째, 구독자가 더 이상 필요하지 않을 경우에는 반드시 구독 해제 처리를 하여 메모리 누수를 방지해야 합니다. 마지막으로, 이벤트 흐름이 분산되는 만큼 로깅과 모니터링 전략을 함께 도입하여 시스템 동작을 추적할 수 있어야 합니다.
| 구분 | Event-Bus 패턴 | Pub-Sub 패턴 |
|---|---|---|
| 적용 범위 | 주로 애플리케이션 내부 모듈 간 통신 | 분산 시스템 간 메시징(네트워크 기반) |
| 중앙 역할 | 애플리케이션 내부의 Event Bus 객체 | 외부 메시지 브로커 (예: Kafka, RabbitMQ, Redis Pub/Sub) |
| 결합도 | 모듈 간 직접 의존성을 제거, 단일 애플리케이션 내에서 결합도 낮춤 | 서비스 간 독립성 보장, 마이크로서비스 간 결합도 낮춤 |
| 데이터 흐름 | 주로 메모리 내 이벤트 전달 (동일 프로세스 내 빠른 처리) | 네트워크를 통한 메시지 큐 기반 전달 |
| 확장성 | 단일 애플리케이션 규모에서 적합, 대규모 분산에는 한계 | 수평 확장 및 대규모 이벤트 스트리밍에 강점 |
| 대표 사례 | UI 이벤트 처리, 게임 엔진 이벤트, IoT 디바이스 내부 이벤트 흐름 | Kafka 이벤트 스트리밍, RabbitMQ 기반 마이크로서비스 통신 |
Event-Bus는 애플리케이션 내부 모듈 간의 느슨한 결합을 위해 설계된 경량 패턴입니다. Pub-Sub은 메시지 브로커를 활용해 분산 시스템 간 확장성과 독립성을 강화하는 패턴입니다. 두 개념은 유사하지만 적용 범위(내부 vs 분산) 와 중앙 중재자(Event Bus vs Broker) 에서 차이가 있습니다.
Event-Bus 패턴은 발행자와 수신자가 직접 연결되지 않고, 중간의 버스를 통해 메시지를 주고받는 아키텍처입니다. 이를 통해 컴포넌트 간 결합도를 낮추고, 유연성과 확장성을 확보할 수 있습니다. 다만 이벤트가 분산되어 관리되므로 흐름 추적과 운영 관리에 주의가 필요합니다. 잘 설계된 이벤트 버스는 대규모 시스템에서 모듈을 독립적이고 유연하게 연결하는 강력한 도구가 될 수 있습니다.