SAA-C03에서 가장 자주 출제되는 패턴 중 하나는 "이 단단히 결합된 시스템을 어떻게 확장 가능하게 바꿀 것인가"입니다. 느슨한 결합(Loosely Coupled)은 현대 클라우드 아키텍처의 핵심 원칙입니다.
느슨한 결합이 왜 필요한가요?
레스토랑을 예로 들어봅시다. 만약 서빙 직원이 주문을 받는 즉시 주방에 뛰어가서 직접 설명한다면 어떻게 될까요? 주방이 바쁜 시간에는 주문이 쌓이고, 서빙 직원도 기다려야 합니다. 하나가 막히면 전체가 멈춥니다.
대신 주문 전표 시스템을 사용하면? 서빙 직원은 전표를 꽂고 다음 테이블로 갑니다. 주방은 전표를 순서대로 처리합니다. 둘은 독립적으로 일합니다. 이것이 느슨한 결합입니다.
느슨한 결합의 세 가지 핵심 이점: 각 구성 요소가 독립적으로 확장됩니다 하나가 실패해도 다른 부분은 계속 동작합니다 각 부분을 독립적으로 배포하고 업데이트할 수 있습니다
Amazon SQS — 주문 전표 시스템
SQS(Simple Queue Service)는 AWS의 메시지 큐 서비스입니다. 생산자(메시지를 보내는 쪽)와 소비자(메시지를 받는 쪽) 사이에 버퍼 역할을 합니다.
SQS Standard 큐는 처리량에 제한이 없습니다. 메시지 순서는 보장되지 않지만, 초당 수백만 건의 메시지를 처리할 수 있습니다. 대부분의 워크로드에 적합합니다.
SQS FIFO 큐는 정확한 순서와 중복 방지를 보장합니다. "주문 1번이 주문 2번보다 먼저 처리되어야 한다"처럼 순서가 중요할 때 사용합니다. 처리량은 초당 3,000개(배치 처리 시)로 제한됩니다.
Dead Letter Queue(DLQ)는 처리에 실패한 메시지를 별도 큐로 이동시키는 기능입니다. 실패한 메시지를 분석하고 재처리할 수 있습니다. 오류 격리와 디버깅에 필수적입니다.
가시성 타임아웃은 중요한 개념입니다. 소비자가 메시지를 가져가면, 그 메시지는 지정한 시간 동안 다른 소비자에게 보이지 않습니다. 처리가 완료되면 삭제하고, 실패하면 타임아웃 후 다시 큐에 나타납니다.
Amazon SNS — 공개 방송 스피커
SNS(Simple Notification Service)는 하나의 메시지를 여러 구독자에게 동시에 전달하는 팬아웃(Fan-out) 서비스입니다. 학교 방송실에서 전교에 방송하는 것과 같습니다.
SNS 토픽에 메시지를 게시(Publish)하면, 그 토픽을 구독(Subscribe)하는 모든 대상에게 동시에 전달됩니다. 구독자는 SQS 큐, Lambda 함수, HTTP 엔드포인트, 이메일 등이 될 수 있습니다.
SNS + SQS 팬아웃 패턴은 시험에 매우 자주 출제됩니다. SNS 토픽 하나에 여러 SQS 큐를 구독시키면, 하나의 이벤트가 여러 처리 파이프라인에 동시에 전달됩니다. 예를 들어 주문 완료 이벤트를 결제 처리 큐, 재고 업데이트 큐, 이메일 발송 큐에 동시에 전달할 수 있습니다.
!Amazon SQS vs SNS
Amazon EventBridge — 이벤트 기반 아키텍처의 중앙 허브
EventBridge는 이벤트를 수집하고, 규칙에 따라 필터링하여, 적절한 대상으로 라우팅하는 이벤트 버스 서비스입니다.
SQS/SNS와의 차이점: EventBridge는 이벤트 내용을 보고 어디로 보낼지를 결정합니다. "EC2 인스턴스가 종료되면 Lambda를 실행하라", "S3에 파일이 업로드되면 Step Functions를 시작하라"처럼 복잡한 이벤트 기반 워크플로를 구성할 수 있습니다.
EventBridge는 AWS 서비스의 이벤트뿐 아니라, 서드파티 SaaS 서비스의 이벤트도 수신할 수 있습니다.
Amazon API Gateway — 서버리스 API의 문지기
API Gateway는 REST, HTTP, WebSocket API를 생성하고 관리하는 서비스입니다. Lambda와 결합하면 서버를 한 대도 운영하지 않는 완전 서버리스 API를 구축할 수 있습니다.
API Gateway가 제공하는 기능: 인증 및 권한 부여 (IAM, Cognito, Lambda Authorizer) 요청 제한 (Throttling) 및 할당량 관리 SSL/TLS 종료 캐싱으로 백엔드 부하 감소
시험 힌트: "서버리스 REST API" 또는 "Lambda를 HTTP로 노출"이 나오면 API Gateway를 선택합니다.
컨테이너 오케스트레이션
마이크로서비스 아키텍처에서 컨테이너는 각 서비스를 패키징하는 표준 방법입니다.
| 서비스 | 설명 | 비유 | |--------|------|------| | Amazon ECS | AWS 네이티브 컨테이너 오케스트레이션 | AWS가 직접 만든 컨테이너 관리 플랫폼 | | Amazon EKS | Kubernetes 기반 컨테이너 관리 | 업계 표준 Kubernetes를 AWS에서 관리 | | AWS Fargate | 서버 없이 컨테이너 실행 | 컨테이너의 서버리스 버전 |
Fargate를 사용하면 EC2 인스턴스를 직접 관리할 필요가 없습니다. "이 컨테이너를 실행해줘"라고 하면 Fargate가 알아서 서버를 프로비저닝하고 실행합니다. Fargate + ALB 조합이 서버리스 컨테이너 아키텍처의 표준 패턴입니다.
AWS Step Functions — 워크플로 오케스트레이터
여러 단계로 이루어진 비즈니스 프로세스를 자동화할 때 Step Functions를 사용합니다. 예를 들어 "사용자 등록 → 이메일 인증 → 환영 메시지 발송 → CRM 등록"처럼 순서가 있는 작업을 시각적 워크플로로 정의합니다.
각 단계는 Lambda 함수, SNS 알림, SQS 메시지, DynamoDB 업데이트 등 다양한 AWS 서비스가 될 수 있습니다. 단계 간 데이터 전달, 오류 처리, 재시도, 병렬 실행 등을 자동으로 관리합니다.
시험 핵심 정리
"구성 요소 간 비동기 통신, 버퍼 역할" — Amazon SQS
"하나의 이벤트를 여러 대상에 동시 전달" — Amazon SNS 팬아웃
"SNS → 여러 SQS 큐 동시 전달" — SNS+SQS 팬아웃 패턴 (매우 자주 출제)
"처리 실패한 메시지 별도 보관·분석" — Dead Letter Queue (DLQ)
"메시지 정확한 순서 보장, 중복 방지" — SQS FIFO 큐
"이벤트 내용 기반 라우팅, 규칙 필터링" — Amazon EventBridge
"서버리스 REST API 구축" — API Gateway + Lambda
"서버 없이 컨테이너 실행" — AWS Fargate (ECS 또는 EKS와 함께)
"여러 Lambda를 순서대로 또는 병렬로 실행" — AWS Step Functions