AWS EventBridge로 밀리초 단위 지연 해결 Amazon Key의 이벤트 기반 아키텍처 전환기

왜 이벤트 기반 아키텍처인가?

Amazon Key 팀은 스마트 홈 접근 관리 솔루션을 운영하면서 전형적인 마이크로서비스 간 강결합 문제에 직면했습니다. 한 서비스의 장애가 연쇄적으로 다른 서비스로 전파되는 '데드락' 상황이 발생했고, 단일 디바이스 벤더의 문제가 전체 시스템 성능을 저하시키는 일도 있었습니다. 이런 상황에서 AWS EventBridge를 중심으로 한 이벤트 기반 아키텍처(EDA)는 자연스러운 선택이었죠.

이번 글에서는 Amazon Key 팀이 실제로 어떻게 EDA를 설계하고 구현했는지, 그 과정에서 얻은 인사이트를 실무에 바로 적용할 수 있도록 정리했습니다.

참고 자료: Mastering millisecond latency and millions of events: The event-driven architecture behind the Amazon Key Suite

핵심 설계: Single-Bus, Multi-Account 패턴

Amazon Key 팀이 선택한 아키텍처는 **단일 중앙 이벤트 버스(Single Bus)**를 두고, 각 서비스 팀이 자신의 AWS 계정에서 독립적으로 운영되는 멀티 어카운트 패턴입니다. 이 설계의 핵심 장점은 다음과 같습니다.

• 명확한 소유권 경계: 서비스 팀은 비즈니스 로직에 집중하고, DevOps 팀이 이벤트 버스, 규칙, 타겟을 중앙 관리합니다.
• 중앙 집중식 거버넌스: 모든 이벤트 라우팅 패턴과 보안 정책을 일관되게 적용할 수 있습니다.
• 운영 단순화: 단일 버스로 인한 복잡성 감소와 논리적 분리를 동시에 달성합니다.
• 보안 강화: 멀티 어카운트 구조로 자연스러운 격리(isolation)를 제공하면서도, 필요한 경우 계정 간 이벤트 흐름을 제어합니다.

세 가지 핵심 컴포넌트

1. 이벤트 스키마 저장소 (Schema Repository)

Amazon EventBridge는 스키마 검색 및 문서화 기능을 제공하지만, 네이티브 스키마 검증 기능은 없습니다. Amazon Key 팀은 이를 해결하기 위해 자체 스키마 저장소를 구축하고, **클라이언트 측 검증(Client-side validation)**을 선택했습니다. 중앙 집중식 검증 서비스를 고려했지만, 추가 인프라 관리와 네트워크 홉으로 인한 지연을 피하기 위해 이 방식을 채택했습니다.

이 저장소는 단일 진실 공급원(Single Source of Truth) 역할을 하며, 스키마 버전 관리, 변경 이력 추적, 게시자-구독자 간 데이터 호환성 보장에 사용됩니다.

2. 클라이언트 라이브러리 (Client Library)

빌드 타임에 스키마로부터 코드 바인딩을 생성하여, 개발자에게 타입 세이프한 인터페이스를 제공합니다. 주요 기능은 다음과 같습니다.

• 로컬 스키마 기반 사전 검증: 이벤트가 버스에 발행되기 전에 유효성을 검사합니다.
• 자동 직렬화/역직렬화: 게시자와 구독자 모두 데이터 변환을 신경 쓰지 않도록 추상화합니다.
• 개발자 경험 향상: 통합 오류의 90%를 표준화된 라이브러리로 해결했습니다.

3. 구독자 구성 라이브러리 (Subscriber Constructs Library)

AWS CDK(Cloud Development Kit)로 구현된 이 라이브러리는 구독자 계정에 필요한 인프라(전용 이벤트 버스, IAM 역할, 모니터링)를 자동으로 프로비저닝합니다. 팀은 비즈니스 로직에만 집중하면 됩니다.

// 구독자 Constructs 라이브러리 사용 예시 (실제 Amazon Key 구현 단순화)
import { SubscriberConstruct } from '@amazon-key/subscriber-library';

const subscriber = new SubscriberConstruct(this, 'MySubscriber', {
  centralEventBusArn: 'arn:aws:events:us-east-1:123456789012:event-bus/central-bus',
  subscriberAccountId: '210987654321',
  // 구독할 이벤트 패턴 정의
  eventPattern: {
    source: ['com.amazon.key.delivery'],
    'detail-type': ['DeliveryCompleted']
  }
});

// CDK 스택에 추가
subscriber.addToStack(this);

성능 및 개발자 경험 개선 수치

Amazon Key 팀이 EDA를 도입한 후 얻은 구체적인 성과입니다.

보안 및 거버넌스

• 단일 컨트롤 플레인이 모든 이벤트 버스 인프라를 관리 (100%)
• 자동화된 보안 준수 검사로 무단 데이터 교환 패턴 100% 차단
• 실시간 모니터링 대시보드로 모든 이벤트 흐름과 스키마 변경 추적
• 스키마 저장소가 시스템 변경에 대한 완전한 감사 추적 제공

결론: 국내 실무에 적용할 때 주의할 점

Amazon Key의 사례는 이벤트 기반 아키텍처의 강력함을 잘 보여줍니다. 하지만 국내 환경에서 바로 적용하기 전에 몇 가지 고려할 점이 있습니다.

주의사항 및 한계

1. 스키마 저장소 유지보수: 자체 구축한 스키마 저장소는 초기 구축 비용과 지속적인 유지보수가 필요합니다. 소규모 팀이나 스타트업은 AWS EventBridge의 기본 스키마 레지스트리로 충분할 수 있습니다.
2. 클라이언트 라이브러리 의존성: 모든 팀이 동일한 클라이언트 라이브러리를 사용해야 합니다. 버전 충돌이나 호환성 문제가 발생할 수 있습니다.
3. 멀티 어카운트 관리 비용: 계정이 많아질수록 AWS Organizations와 IAM 정책 관리가 복잡해집니다. 충분한 DevOps 역량이 필요합니다.
4. 이벤트 스키마 진화: 하위 호환성을 유지하면서 스키마를 진화시키는 것은 여전히 어려운 과제입니다. 명확한 Deprecation 정책과 마이그레이션 경로가 필요합니다.

다음 단계 학습 방향

• AWS EventBridge 공식 문서와 모범 사례 학습
• 이벤트 스키마 설계 패턴 (CloudEvents, AsyncAPI) 이해
• 실제 프로젝트에 작은 규모의 EDA를 먼저 도입해 경험 쌓기

함께 보면 좋은 글

• 90일 걸리던 인프라 구축, 몇 시간으로 줄인 산탄데르의 플랫폼 엔지니어링 전략
• 게임을 실시간으로 생성하는 AI, Waypoint-1의 가능성과 작동 원리