서론: 왜 이벤트 기반 아키텍처(EDA)가 필요한가?
복잡한 모놀리식 시스템에서 서비스 간 결합도가 높아지면, 한 서비스의 장애가 연쇄적으로 전파되어 전체 시스템을 마비시키는 '도미노 현상'이 발생하기 쉽습니다. 아마존 키 팀도 비슷한 고통을 겪었는데요, 특정 디바이스 벤더의 문제가 해당 배송 운영뿐만 아니라 여러 시스템 서비스에 광범위한 장애를 유발한 사례가 대표적입니다. 이처럼 강결합된 아키텍처는 변경과 확장이 어려워 혁신의 발목을 잡곤 합니다.
이 글에서는 아마존 키 팀이 어떻게 AWS EventBridge를 중심으로 한 이벤트 기반 아키텍처로 전환하여 시스템의 신뢰성, 확장성, 유지보수성을 획기적으로 개선했는지 그 구체적인 설계와 구현 노하우를 살펴봅니다. 자세한 근거자료는 AWS Architecture Blog에서 확인할 수 있습니다.
본론 1: 핵심 설계 패턴과 3대 구성 요소
아마존 키 팀은 '단일 버스, 멀티 계정' 패턴을 채택했습니다. 각 서비스 팀은 자신의 애플리케이션 스택에 대한 완전한 소유권과 자율성을 유지하면서, 중앙 DevOps 팀이 이벤트 버스 규칙, 타겟 구성, 서비스 통합을 관리하는 인프라 스택을 담당합니다. 이렇게 관심사를 분리함으로써 명확한 책임 경계와 중앙 집중식 거버넌스를 동시에 확보할 수 있었죠.
이 아키텍처를 구현하기 위해 그들이 만든 세 가지 핵심 컴포넌트는 다음과 같습니다.
- Event Schema Repository (스키마 저장소): 이벤트 정의의 단일 출처(Single Source of Truth) 역할을 합니다. 스키마 버전 관리, 데이터 품질 검증, 변경 감사 추적을 제공하며, 팀 간 협업을 위한 자체 서비스식 스키마 발견과 문서화의 기반이 되었습니다.
- Client Library (클라이언트 라이브러리): 개발자 경험(Developer Experience)을 극대화한 도구입니다. 빌드 시점에 스키마 저장소의 정의를 기반으로 타입 세이프(Type-safe) 코드 바인딩을 생성하여, 발행자와 구독자가 직관적이고 안전하게 이벤트를 생성하고 처리할 수 있도록 돕습니다. 발행 전 로컬에서 스키마 유효성 검증을 수행해 잘못된 이벤트가 시스템에 유입되는 것을 방지합니다.
- Subscriber Constructs Library (구독자 구성 라이브러리): AWS CDK로 개발된 이 라이브러리는 구독자 통합을 표준화하고 단순화합니다. 필요한 IAM 역할, 전용 이벤트 버스, 모니터링 설정을 자동으로 프로비저닝하여, 각 팀이 인프라 구성보다 비즈니스 로직에 집중할 수 있게 해줍니다.
본론 2: 성과, 주의사항, 그리고 국내 적용 시 고려사항
도입 성과: 숫자로 보는 변화
- 신뢰성 & 확장성: 초당 2000개 이벤트를 99.99% 성공률로 처리. 수신부터 타겟 호출까지의 P90 지연 시간은 80ms로 일관성을 유지.
- 개발자 생산성: 새로운 사용 사례의 서비스 통합 시간이 5일에서 1일로 80% 단축. 새로운 이벤트 온보딩은 48시간에서 4시간으로 감소.
- 보안 & 거버넌스: 단일 제어 평면으로 100%의 이벤트 버스 인프라 관리. 자동화된 보안 검사로 비인가 데이터 교환 패턴을 100% 탐지.
이 기술의 한계와 주의사항
EDA는 만능 해결사가 아닙니다. 이벤트의 최종 일관성(Eventual Consistency)을 기본으로 하기 때문에, 강한 트랜잭션 일관성이 요구되는 비즈니스 로직(예: 금융 결제의 정확한 잔고 관리)에는 부적합할 수 있습니다. 또한, 분산 시스템 특성상 디버깅과 트랜잭션 추적이 더 복잡해질 수 있어, X-Ray나 세분화된 로깅 전략이 필수적입니다.
한국 개발 생태계에서의 적용 맥락
국내 SI 환경에서는 빠른 납기와 변화하는 요구사항 대응에 초점이 맞춰져 있어, 초기에는 모놀리식이나 강결합 아키텍처로 시작하는 경우가 많습니다. 그러나 서비스가 성장하고 복잡도가 증가하면, 아마존 키 팀이 겪은 것과 유사한 통합 지옥(Integration Hell)에 빠지기 쉽습니다. EDA 도입은 '빠른 시작'보다 '장기적인 유지보수성과 확장성'에 투자하는 관점으로 접근해야 합니다. 특히, 스키마 저장소와 클라이언트 라이브러리 같은 내부 도구에 대한 투자는 초기 부담처럼 느껴질 수 있지만, 팀 간 협업 비용을 획기적으로 낮추고 시스템 전반의 품질을 높이는 데 결정적 역할을 합니다. 국내에서도 MSA로의 전환을 고민 중이라면, 서비스 간 통합 방식으로 HTTP API 호출만 고려하기 전에, 이벤트 기반의 비동기 통합 패턴을 적극적으로 검토해볼 시점입니다. 이는 에이전트 기반 개발과 같은 새로운 패러다임에서도 빠른 피드백 루프를 구축하는 데 핵심적일 수 있습니다.
결론: 다음 단계 학습 방향 제시
아마존 키 팀의 사례는 EDA가 단순한 기술 선택이 아니라, 조직의 협업 방식과 시스템 신뢰성에 근본적인 변화를 가져오는 전략적 도입임을 보여줍니다. 성공을 위한 핵심은 EventBridge 같은 관리형 서비스를 활용하는 것뿐만 아니라, 스키마 거버넌스, 개발자 경험, 표준화된 인프라 패턴이라는 '三大 기둥'을 함께 세우는 데 있습니다.
실무에 적용을 고려한다면, 먼저 기존 시스템에서 '도미노 장애'가 발생할 가능성이 높은 결합도가 높은 부분을 식별해보세요. 그 부분을 시작으로 작은 규모의 이벤트 기반 프로토타입을 구축하고, 스키마를 어떻게 관리할지, 실패한 이벤트는 어떻게 재처리할지에 대한 운영 체계를 미리 설계하는 연습이 필요합니다.
이러한 아키텍처 진화는 궁극적으로 더 민첩하고 복원력 있는 소프트웨어를 만드는 길입니다. 함께 보면 좋은 글로, ML/AI 개발에서 빠른 반복을 가능하게 하는 메타플로우 스핀에 대한 인사이트와, 에이전트 개발 시대에 대응하는 테스팅 패러다임의 변화를 다룬 글을 추천합니다.