Day 3 - EventBridge: Event Bus, Pipes, Scheduler의 통합 모델

마이크로서비스가 다섯 개를 넘어가는 순간, 시스템의 가장 큰 비용은 코드가 아니라 **결합(coupling)**이 된다. A 서비스가 B를 직접 호출하고 B는 C를 호출하는 식의 체인은 처음엔 단순해 보이지만, B의 장애가 A에게 전파되고 D 같은 새 서비스를 끼워 넣을 때마다 양쪽 코드를 모두 수정해야 한다. 이 문제를 푸는 패턴이 **Event-Driven Architecture(EDA)**다. 서비스는 이벤트를 발행하고, 다른 서비스가 그 이벤트를 구독한다. 발행자는 누가 듣는지 모르고, 구독자는 누가 보냈는지 모른다.

AWS의 EDA 도구는 SNS·SQS·Kinesis·EventBridge 등 여러 개가 있지만, 최근 5년간 가장 큰 변화는 EventBridge가 사실상의 표준 라우터가 됐다는 점이다. 2019년 CloudWatch Events의 후속으로 출시된 이후, Pipes(2022)와 Scheduler(2022)가 추가되면서 "이벤트의 모든 것"을 다루는 플랫폼으로 진화했다. SAP 시험에서 EventBridge는 도메인 1·2·3에 흩어져 출제되고, 특히 "SNS vs EventBridge" / "Pipes vs Step Functions" 같은 선택 시나리오가 단골이다.

EDA가 왜 필요한가 — 분산 시스템의 결합 문제

Conway의 법칙은 "시스템 구조는 그 시스템을 만든 조직의 커뮤니케이션 구조를 닮는다"고 했다