---
type: knowledge
domain: aws
status: active
last-reviewed: 2026-07-12
tags:
  - aws
  - messaging
  - event-driven
---

# 메시징과 애플리케이션 통합

> 한 줄 정의
> 큐, 발행/구독, 이벤트 버스, 스트림, 워크플로를 구분하고 모든 비동기 처리는 중복·지연·순서 변경·실패를 전제로 설계한다.

## 무엇을 고를까

| 요구 | 서비스 | 핵심 |
|---|---|---|
| 작업 버퍼·소비자 분리 | SQS Standard | at-least-once, 고처리량, 순서 비보장 |
| 순서·중복 제거가 중요 | SQS FIFO | message group 안 순서, 처리량 제약 확인 |
| 한 메시지를 여러 구독자에 푸시 | SNS | fan-out, 필터 정책 |
| AWS/SaaS/앱 이벤트 라우팅 | EventBridge | 이벤트 버스, 규칙, 스키마 |
| 고처리량 재생 가능한 스트림 | Kinesis Data Streams | shard·partition key·consumer |
| Kafka 호환 | Amazon MSK | Kafka 생태계와 운영 비용 |
| 단계·분기·보상 워크플로 | Step Functions | Standard/Express 특성 비교 |
| API | API Gateway | REST/HTTP/WebSocket API, 인증·스로틀 |
| GraphQL·실시간 데이터 API | AppSync | GraphQL, 구독, 데이터 소스 통합 |

## 신뢰성 불변식

- **at-least-once를 기본으로 가정**하고 소비자를 멱등하게 만든다.
- 메시지에 event id, type, version, occurred-at, producer, correlation id를 포함한다.
- visibility timeout은 최대 처리 시간보다 길게, heartbeat 또는 연장 전략을 둔다.
- 재시도는 지수 백오프와 jitter, 최대 횟수, 재시도 가능한 오류 분류가 필요하다.
- DLQ는 묘지가 아니다. 알람, 원인 분류, redrive 절차, 보존 기간을 둔다.
- 페이로드가 크면 S3에 저장하고 메시지에는 포인터와 무결성 정보를 보낸다.
- 이벤트 스키마는 하위 호환으로 진화시키고 소비자가 모르는 필드를 무시하게 한다.

## 패턴

### Queue-based load leveling

급증 트래픽을 SQS에 쌓고 소비자 수를 queue depth/age로 확장한다. 하류 DB의 처리 한도를 넘지 않게 backpressure를 건다.

### Fan-out

SNS → 여러 SQS 큐로 알림, 분석, 검색 색인 등 소비자별 실패와 속도를 격리한다.

### Transactional outbox

DB 상태 변경과 이벤트 발행의 이중 쓰기 문제를 줄이기 위해 같은 DB 트랜잭션에 outbox 레코드를 저장하고 별도 퍼블리셔가 전송한다.

### Saga

분산 트랜잭션 대신 단계별 로컬 트랜잭션과 보상 작업을 Step Functions 등으로 명시한다.

> [!WARNING] Exactly once
> 전 구간 exactly-once를 구호로 삼기보다, 중복 전달을 허용하고 멱등 키·조건부 쓰기·처리 기록으로 비즈니스 효과를 한 번만 만들도록 설계한다.

## 공식 문서

- [Amazon SQS](https://docs.aws.amazon.com/sqs/)
- [Amazon SNS](https://docs.aws.amazon.com/sns/)
- [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/)
- [AWS Step Functions](https://docs.aws.amazon.com/step-functions/)
- [Amazon Kinesis](https://docs.aws.amazon.com/kinesis/)

## 관련 문서

- [[05_컴퓨팅 컨테이너 서버리스]] · [[07_데이터베이스와 캐시]] · [[12_신뢰성과 재해 복구]]