기준: SAA-C03 시험 가이드오류 제보
Week 7 내내 우리가 본 네 가지 서비스 — SQS, SNS, EventBridge, Kinesis — 는 콘솔의 카테고리로 보면 모두 "Application Integration"에 묶여 있지만, 그 안에서 푸는 문제는 사실 서로 다른 종류다. 같은 화면에 나란히 놓여 있다고 해서 같은 결을 가진 서비스라고 오해하면 시험은 물론 실무에서도 잘못된 도구를 고른다.
이 글에서는 다섯째 날답게 새로운 서비스를 더 얹지 않는다. 대신 지난 4일 동안 본 모델들을 분산 시스템 이론과 시나리오 키워드의 관점에서 다시 한 번 정리하고, 시험에서 자주 헷갈리는 결정 축들을 한 번에 풀어본다. 마지막으로 12문항의 시나리오 문제로 그동안 쌓아둔 사고를 점검한다.
각 서비스가 풀려는 문제부터 다시 짚는다. 외울 정의가 아니라 "이 서비스가 없으면 어떤 고통이 있는가"의 관점이다.
SQS (Day 31) — 생산자와 소비자의 시간을 분리하는 큐. 핵심 추상화는 "소비자가 잠시 죽어도 메시지는 큐에 남아있다". 이걸로 사용자 요청 처리 속도와 워커 처리 속도의 불일치(burst)를 흡수한다. 한 메시지는 한 소비자가 가져가서 끝낸다(point-to-point).
SNS (Day 32) — 한 이벤트를 N개 시스템으로 동시에 전달하는 팬아웃. 핵심 추상화는 "발행자는 누가 듣는지 모른다". 토픽에 한 번 publish하면 모든 구독자(SQS, Lambda, HTTP, Email, SMS, Mobile Push, …)가 각자 받는다.
EventBridge (Day 33) — 이벤트의 모양과 규칙을 기반으로 라우팅하는 버스. 핵심 추상화는 "이벤트가 왔을 때 어떤 규칙에 매칭되는지로 동작이 결정된다". 즉 SNS가 "구독 채널" 모델이라면 EventBridge는 "필터링 라우팅" 모델. SaaS·AWS 서비스·내부 앱의 이벤트를 한 번에 받고, JSON 패턴으로 라우팅한다.
Kinesis (Day 34) — 시간 순서대로 정렬된 이벤트의 강(stream). 핵심 추상화는 "같은 데이터를 여러 소비자가 자기 페이스로 재생할 수 있다". 메시지를 가져가도 사라지지 않고, 보관 기간 동안 누구나 다시 읽을 수 있다. 분석·머신러닝 학습·재처리에 결정적이다.
메시징 시스템의 네 모델은 Enterprise Integration Patterns(EIP, Hohpe & Woolf, 2003)에서 정리한 4가지 핵심 패턴과 거의 1:1 대응된다. SQS = Point-to-Point Channel, SNS = Publish-Subscribe Channel, EventBridge = Content-Based Router, Kinesis = Event Sourcing / Replayable Log. 즉 AWS는 EIP를 매니지드 서비스로 구현한 셈이다. 시험에서 "어느 서비스" 문제는 결국 "어느 패턴" 문제로 환원되며, 이 매핑이 머리에 있으면 시나리오에서 키워드만 잡아도 답이 나온다.
같은 "메시징"이라도 at-least-once vs exactly-once, 순서 보장 vs 무관, 메시지 영속성 vs 일회성, fanout 1:N vs point-to-point 네 축으로 분류하면 모든 메시징 시스템이 그 좌표 위 한 점이다. Kafka는 (at-least-once, partition 내 순서, replayable, 1:N), SQS Standard는 (at-least-once, 순서 없음, consume 후 삭제, 1:1), SNS는 (best-effort, 순서 없음, 일회성, 1:N), SQS FIFO는 (exactly-once-ish, group 내 순서, 1:1), EventBridge는 (at-least-once, 순서 없음, rule 기반 fanout). 이 좌표를 그리면 시험 시나리오 키워드가 어디로 가는지 보인다.
가장 먼저 묻는 질문이다. 메시지가 들어왔을 때 단 하나의 소비자가 처리해서 끝나는 일인지(점대점), 아니면 여러 시스템이 같은 사건을 듣고 각자 다른 행동을 해야 하는지(팬아웃).
점대점이면 SQS. 결제 처리 큐가 좋은 예다. 한 주문은 한 번만 결제되어야 하므로 워커 인스턴스 중 하나가 메시지를 가져가서 처리하면 다른 워커는 그 메시지를 보지 못한다. 가시성 타임아웃이 정확히 이 단일 소유권을 보장한다.
팬아웃이면 SNS 또는 EventBridge. "주문 완료 이벤트가 일어났는데 이메일도 보내고, 분석 시스템에도 기록하고, 창고 시스템에도 알리고, 추천 엔진에도 입력해야 한다." 이때 발행자가 그 모든 구독자를 직접 호출하면 결합도가 폭발하고, 새 구독자가 생길 때마다 발행자 코드가 바뀌어야 한다. 팬아웃이 그 결합을 끊는다.
| 축 | SQS | SNS | EventBridge | Kinesis |
|---|---|---|---|---|
| 전달 모델 | 점대점 (1:1) | 팬아웃 (1:N) | 규칙 기반 라우팅 (1:N) | 스트림 (1:N, replay) |
| 메시지 영속성 | 가져가서 삭제 | 일회 전달, 안 남음 | 일회 전달, 안 남음 | 보관 기간 동안 누구나 재read |
| 순서 | Standard 없음 / FIFO 그룹 내 | 없음 | 없음 | shard 내 엄격 |
| 처리 보장 | At-least-once / FIFO exactly-once | At-least-once | At-least-once | At-least-once |
| 백프레셔 | 큐 길이로 ASG 스케일 | 없음 (발행 즉시) | 없음 | 소비자 페이스로 재생 |
| 통합 | Lambda, EC2, ECS | Lambda, SQS, HTTP, Email, SMS | 100+ SaaS / AWS / 자체 | Lambda, Firehose, KCL |
이 질문 하나로 Kinesis가 다른 셋과 갈린다. SQS·SNS·EventBridge는 모두 메시지가 "한 번 전달되고 사라지는" 모델이다. 소비자가 처리에 실패하면 DLQ로 가거나(SQS) 재시도 큐로 가거나(SNS/EventBridge target에 따라) 사라진다. 어쨌든 그 시점이 지나면 다시 그 이벤트를 볼 수 없다.
Kinesis는 다르다. 메시지는 보관 기간(기본 24시간, 최대 365일) 동안 스트림에 남아 있고, 소비자가 이미 가져갔어도 그 자리에 그대로 있다. 다른 소비자가 같은 시점부터 다시 읽을 수 있고, 어제의 데이터를 오늘 모델 학습에 다시 쓸 수 있다.
이 차이는 분산 시스템에서 immutable log 패턴의 가치와 직결된다. Jay Kreps의 "The Log: What every software engineer should know about real-time data's unifying abstraction"(2013, LinkedIn Engineering)이 정리한 핵심이다. 데이터를 가변 상태(mutable state)가 아니라 변하지 않는 이벤트의 시퀀스로 보면, 새로운 소비자가 생겼을 때 처음부터 다시 재생해서 동일한 상태를 재구성할 수 있다. Event Sourcing 패턴, CDC(Change Data Capture), Lambda Architecture(batch + streaming) 모두 이 가정 위에서 동작한다. SQS는 가변 상태(메시지를 가져가면 사라짐)이고 Kinesis는 불변 로그라는 점이 두 서비스를 완전히 다른 도구로 만든다.
사례: Netflix는 2016년 이후 Keystone Pipeline에서 하루 1조 건 이상의 이벤트를 Kinesis 기반으로 처리한다. "왜 SQS가 아닌 Kinesis인가"의 답이 곧 이 축이다 — A/B 테스트, 추천 모델 학습, 실시간 대시보드 등 같은 이벤트를 여러 소비자가 다른 목적으로 사용하기 때문. SQS는 한 소비자가 가져가면 끝이라 같은 데이터를 여러 시스템이 분석하려면 fanout(SNS→SQS) 패턴이 필요한데, 새 소비자가 생기면 그 시점부터의 이벤트만 받을 수 있다(이전 이벤트 재생 불가). Kinesis는 보관 기간 안이면 새 소비자도 처음부터 재생 가능. Netflix Tech Blog 참고.
SNS와 EventBridge가 자주 헷갈리는 지점이다. 둘 다 1:N 팬아웃처럼 보이지만, 결정 모델이 다르다.
SNS는 토픽 = 채널이다. 토픽에 publish하면 그 토픽을 구독한 모든 엔드포인트가 받는다. 구독자를 늘리거나 줄이는 식으로 동작을 바꾼다. 메시지 필터링(Message Filtering)도 가능하지만 단순한 속성 매칭 수준이다.
EventBridge는 버스 + 규칙이다. 같은 버스에 들어온 이벤트를 JSON 패턴으로 매칭하고, 매칭된 규칙별로 다른 타겟(Lambda, SQS, Step Functions, SNS, 다른 EventBridge bus, …)에 보낸다. 규칙은 {"source": ["custom.order"], "detail-type": ["OrderPlaced"], "detail": {"amount": [{"numeric": [">", 1000]}]}} 같은 식으로 이벤트의 구조 자체를 본다.
또 EventBridge는 SaaS 이벤트(Zendesk, Datadog, Stripe, Auth0, MongoDB 등)와 AWS 서비스 이벤트(EC2 상태 변화, S3 PutObject, CodePipeline 단계 등)를 같은 버스에서 받을 수 있다는 점에서 SNS보다 위쪽 추상화에 있다. SNS가 "내가 만든 토픽에 내가 발행"이라면, EventBridge는 "온갖 곳에서 오는 이벤트를 내가 받아서 라우팅"이다.
EventBridge의 라우팅은 내부적으로 finite state automaton 기반의 패턴 매처로, 규칙 패턴을 컴파일해서 들어오는 이벤트와 빠르게 매칭한다. 수천 개 규칙이 있어도 단일 이벤트의 라우팅 결정은 마이크로초 단위로 끝나기 때문에 표현력이 SNS Message Filtering(단순 string 비교)과 다른 차원이다 — 숫자 비교, IP 매칭, 존재 여부, 접두사 등이 가능. 다만 EventBridge는 PutEvents 이벤트당 평균 0.5초 지연(p99 < 1.5초)이 있어, 1초 미만 SLA가 필요한 hot path에서는 SNS 또는 SQS 직접 호출이 더 낫다.
⚠️ 함정: "SaaS 통합", "스케줄링", "이벤트 패턴 필터링", "AWS 서비스 이벤트 라우팅" 키워드가 보이면 EventBridge가 답이다. "단순 fanout SQS + Lambda + 이메일"이면 SNS가 답이다. EventBridge로 모든 fanout을 하면 latency가 누적되고 비용도 SNS의 ~10배. 반대로 단순 SNS만 쓰면 SaaS 통합이 어려워서 매번 Lambda를 끼워야 한다.
분산 시스템에서 가장 자주 오해받는 단어가 "exactly-once delivery"다. SQS FIFO와 Kafka(EOS)와 SNS가 각자 다른 의미로 이 단어를 쓴다.
SQS Standard / SNS — at-least-once. 같은 메시지가 두 번 도착할 수 있다. 네트워크 재시도 때문에 발행자가 두 번 보낼 수도, 소비자가 ack 전에 죽어서 다시 가져갈 수도 있다. 해결은 소비자 측 idempotency(메시지 ID로 중복 체크).
SQS FIFO — "exactly-once processing"을 광고하지만 엄밀히는 5분 deduplication window 안에서 중복 발행을 막아주는 것이다. ContentBasedDeduplication 또는 명시적 MessageDeduplicationId 기준으로 5분 이내 같은 ID는 무시된다. 즉 5분 넘어서 또 보내면 여전히 중복 발행 가능. 그리고 소비자가 처리 후 ack 안 하고 죽으면 visibility timeout이 풀려 다시 가져간다(여전히 한 번 처리 ≠ 한 번 도착).
Kinesis — at-least-once. KCL이 consumer side에서 sequence number를 DynamoDB에 checkpoint하지만, 한 record가 두 워커에 동시에 보일 짧은 순간이 있다. consumer 코드에서 idempotency 보장 필수.
Two Generals' Problem(1975)이 증명한 것 — 두 노드 간 안정적인 합의는 비동기 네트워크에서 불가능하다. 즉 발행자와 소비자 사이의 "정확히 한 번"은 메시징 시스템 단독으로는 절대 보장할 수 없고, 소비자 측의 멱등성(idempotency)이나 트랜잭션 outbox 패턴 같은 애플리케이션 협력이 반드시 필요하다. Confluent의 EOS(Exactly Once Semantics, KIP-98)도 transactional producer + read-process-write가 모두 같은 Kafka 클러스터 안에서 끝나야 가능한 좁은 의미의 보장이다. AWS 메시징을 설계할 때 "FIFO 쓰면 중복 없어"라고 외우면 함정에 빠진다.
같은 워크로드라도 어떤 도구를 쓰느냐에 따라 한 달 청구서가 10배 차이날 수 있다. 시험에서도 비용 키워드가 분명한 시나리오는 답이 거의 정해진다.
| 시나리오 | 저렴한 답 | 비싼 답 (오답) |
|---|---|---|
| 하루 100만 건 단순 fanout | SNS | EventBridge |
| 하루 1억 건 분석 스트림 | Kinesis Firehose → S3 (서버리스) | Kinesis Data Streams + 자체 KCL EC2 |
| 잦은 빈 폴링 비용 | Long Polling 20초 | Short Polling |
| SaaS 이벤트 라우팅 | EventBridge | Custom Lambda + 큐 |
| 단순 비동기 워커 | SQS | Step Functions |
| 200KB 이상 메시지 | S3 + SQS Extended Client | base64로 잘라 보내기 |
사례(가상): 2020년 한 핀테크 스타트업이 모든 비동기 처리를 EventBridge로 통일했다가 월 청구서가 SNS+SQS 조합 대비 12배 폭증한 사례가 회자된다. 원인은 EventBridge가 이벤트당 $1/M USD(처음 100M까지)인 데 비해 SNS는 publish가 $0.50/M USD + 구독자 전달은 SQS면 무료에 가까웠던 것. EventBridge의 가치는 "라우팅 표현력 + SaaS 통합"이고, 단순 fanout이라면 SNS가 비용 효율적이다. 시험에서도 "수억 건의 단순 fanout"이라면 비용 키워드가 SNS 쪽을 가리킨다.
시험에서 "갑자기 트래픽이 10배 늘어났다, 무엇이 부족한가" 류 문제가 나온다. 이때 각 서비스의 처리량 모델이 판단 기준이 된다.
| 서비스 | 처리량 |
|---|---|
| SQS Standard | 무제한 (사실상) |
| SQS FIFO | 300 TPS / 그룹 (배치 시 3,000), High Throughput FIFO는 그룹 분산으로 수만 |
| SNS Standard | 무제한 (지역별 publish quota 있음) |
| SNS FIFO | 300 TPS / 그룹 |
| EventBridge | default bus 400 TPS PutEvents, increase 가능 |
| Kinesis Data Streams | shard당 in 1MB/s 또는 1,000 record/s, out 2MB/s (Enhanced Fan-Out은 소비자별 2MB/s) |
| Kinesis Firehose | 자동 스케일 (관리형) |
⚠️ 함정: Kinesis "shard"를 SQS와 같은 큐로 오해하지 말 것. shard는 partition key 해시로 결정되며, 한 partition key는 항상 같은 shard로 간다(순서 보장의 기반). hot partition key가 있으면 그 shard가 한도(in 1MB/s)에 막혀서 throttling이 일어나는데, 다른 shard는 한가해도 도움이 안 된다. 시험 시나리오에 "특정 키만 처리량이 막힌다"가 나오면 partition key 설계 문제 답.
메시징을 잘못 다루면 데이터 유출이나 중복 처리로 이어진다. 핵심 패턴 3개만 기억하면 안전하다.
1) 암호화 — 모든 4개 서비스가 SSE(KMS 키)를 지원한다. SQS·SNS·Kinesis는 KMS data key caching으로 비용 최적화하고, EventBridge는 모든 이벤트가 자동 in-transit TLS + at-rest encryption.
2) VPC Endpoint — Lambda 같은 VPC 안 워크로드가 SQS·SNS·Kinesis·EventBridge에 접근할 때 인터넷 우회 없이 PrivateLink로 연결. 보안 + NAT Gateway 비용 절감.
3) Resource Policy로 cross-account — SNS Topic Policy, SQS Queue Policy, EventBridge Bus Policy로 다른 계정의 ARN에 접근 허용. 멀티 계정 환경에서 중앙 audit 큐로 모든 계정 이벤트 모으기.
멱등성 키(idempotency key) 설계는 분산 시스템의 핵심 디펜스 라인이다. Stripe의 idempotency-key 헤더 패턴이 사실상 업계 표준 — 클라이언트가 UUID를 생성해서 보내면 서버는 그 키로 처리 결과를 캐싱하고, 동일 키 재요청은 캐시된 결과만 반환한다. SQS/SNS의 at-least-once를 다루는 워커도 같은 원리로 메시지 ID + 처리 결과를 DynamoDB(TTL)에 저장하면 중복 처리를 차단할 수 있다. RFC draft "The Idempotency-Key HTTP Header Field"(Sanyal & Vyas, IETF 2021)가 이 패턴을 표준화하려 한다.
Week 8은 데이터베이스의 깊이로 들어간다. RDS · Aurora · DynamoDB · ElastiCache가 각각 어떤 워크로드를 풀고, 같은 "데이터 저장" 문제를 어떤 분산 모델로 접근하는지를 본다. Week 7에서 본 "메시징은 시간을 분리한다"는 결의 그림이, Week 8의 "데이터베이스는 일관성과 가용성을 분리한다"는 그림과 같은 분산 시스템의 두 얼굴이라는 것을 알게 될 것이다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
한 e-commerce 회사의 주문 시스템이 "주문 완료" 이벤트를 발생시키면 다음 4가지를 동시에 해야 한다: (1) 결제 처리 큐로 메시지 전송, (2) 분석 시스템에 기록, (3) 사용자에게 이메일 알림, (4) 창고 시스템에 알림. 또한 향후 새로운 구독자가 추가될 수 있다. 가장 적합한 아키텍처는?
문제 2
결제 시스템에서 "한 결제는 정확히 한 번 처리되어야 한다 + 같은 고객의 결제는 순서대로 처리되어야 한다"가 요구된다. 가장 적합한 큐 구성은?
문제 3
한 회사가 자사 워크로드에서 GitHub, Stripe, Datadog 같은 SaaS의 이벤트를 받아 자동화 규칙으로 다른 AWS 서비스(Lambda, Step Functions, SQS)에 라우팅하려고 한다. 가장 적합한 솔루션은?
문제 4
IoT 디바이스 100만 대가 초당 평균 50,000건의 텔레메트리 데이터를 보내고, 이 데이터를 (1) S3에 원본 저장, (2) Lambda로 실시간 이상 탐지, (3) 다음 분기에 ML 모델 학습용으로 재사용해야 한다. 가장 적합한 솔루션은?
문제 5
한 회사의 워커가 SQS에서 메시지를 받아 외부 API를 호출하는데, 외부 API 호출이 평균 45초 걸리고 가끔 90초까지 간다. 그런데 같은 메시지가 두 번 처리되는 사고가 가끔 발생한다. 원인과 해결은?
문제 6
한 회사는 CodePipeline 배포가 실패할 때만 Slack에 알림을 보내고 싶다. 가장 적합한 구성은?
문제 7
Kinesis Data Streams 소비자가 1개일 때는 잘 동작하지만, 같은 데이터를 분석하는 두 번째 소비자를 추가하니 둘 다 throttling이 자주 발생한다. 원인과 해결은?
문제 8
한 회사가 SQS 큐의 메시지를 Lambda로 처리하는데, 가끔 외부 API의 일시적 장애로 한 메시지의 처리가 5번 연속 실패한다. 정상 메시지는 계속 처리되어야 하고, 실패한 메시지는 격리해서 나중에 분석 후 재처리하고 싶다. 어떻게?
문제 9
한 회사가 EventBridge로 SaaS·AWS·내부 이벤트를 모두 받아 라우팅하는데, 장애 시 모든 이벤트를 검사해서 재처리해야 한다. 가장 적합한 백업 전략은?
문제 10
한 회사가 글로벌하게 분산된 모바일 앱에서 푸시 알림을 보내야 한다 (iOS APNs, Android FCM, 웹 푸시). 최소한의 운영 부담으로 어떻게?
문제 11
한 회사가 SQS 큐의 메시지 수에 따라 EC2 워커 수를 자동 조정하려고 한다. 가장 적절한 메트릭과 패턴은?
문제 12
한 회사가 메시지 크기 600KB의 PDF 데이터를 SQS로 보내야 한다. SQS 메시지 최대 크기는 256KB. 가장 적절한 방법은?