도메인 2: 새로운 솔루션을 위한 설계
이 도메인은 가중치가 가장 높습니다(29%). 하지만 다루는 원칙 자체는 새롭지 않습니다 — 배포 전략, 보안 제어, 신뢰성, 성능, 비용 최적화는 모두 ② SAA 섹션 에서 이미 단일 워크로드 단위로 배운 내용입니다. 이 도메인이 SAA와 다른 점은 딱 하나입니다. 그 결정을 도메인 1에서 세운 조직 표준(계정 구조, 네트워크, 보안 규정, 비용 가시성) 안에서, 그리고 IaC·CI/CD 같은 배포 자동화까지 포함해서 내려야 한다는 것입니다.
Task 2.1: 비즈니스 요구 사항을 충족하는 배포 전략 설계
이 작업은 SAA 범위에 없던 내용으로, SAP에서 새로 등장하는 핵심 주제입니다.
코드형 인프라(IaC): AWS CloudFormation으로 인프라를 코드로 정의하면 동일한 스택을 여러 계정·리전에 일관되게 재현할 수 있습니다. StackSets을 사용하면 Organizations의 여러 계정에 동일한 스택을 한 번에 배포·업데이트할 수 있어, 도메인 1의 멀티 계정 구조와 직접 맞물립니다.
CI/CD와 배포 전략: 새로운 버전을 안전하게 배포하는 대표적인 패턴은 다음과 같습니다.
| 전략 | 동작 방식 | 롤백 속도 | 적합한 경우 |
|---|---|---|---|
| 한 번에 모두 배포(All at once) | 전체 인스턴스를 동시에 교체 | 느림(재배포 필요) | 다운타임 허용 가능, 개발 환경 |
| 롤링 배포(Rolling) | 일부씩 순차 교체 | 중간 | 점진적 위험 분산이 필요한 경우 |
| 블루/그린 배포 | 새 환경을 완전히 별도로 띄운 뒤 트래픽 전환 | 빠름(트래픽만 되돌리면 됨) | 빠른 롤백이 중요한 프로덕션 |
| 카나리 배포 | 트래픽 일부만 신규 버전으로 점진 전환 | 빠름 | 실 사용자 트래픽으로 위험을 최소화하며 검증 |
Systems Manager는 패치 관리, 구성 관리, Run Command를 통한 원격 실행을 표준화해, 수동 SSH 접속 없이도 수백 대의 인스턴스를 일관되게 관리할 수 있게 해줍니다.
Task 2.2: 비즈니스 연속성을 보장하는 솔루션 설계
RTO/RPO와 DR 4단계(Backup and Restore → Pilot Light → Warm Standby → Multi-Site Active/Active)의 개념 자체는 도메인 1의 Task 1.3 에서 다뤘습니다. 이 작업에서는 그 전략을 신규 솔루션에 실제로 구성하는 데 초점을 둡니다 — 데이터/데이터베이스 복제(replication) 구성, 재해 복구 테스트(DR Drill) 수행, Route 53의 라우팅 정책(장애 조치 라우팅, 다중 값 응답)을 이용한 자동 페일오버, 그리고 가동 중단 시에도 애플리케이션 가용성을 지키는 아키텍처 설계가 핵심 기술입니다.
Task 2.3: 요구 사항에 따라 보안 제어 결정
IAM 최소 권한, 보안 그룹/NACL, 암호화 전략의 구체적인 적용 사례는 SAA: 보안 아키텍처 에서 다뤘습니다. 이 작업에서 새로 강조되는 것은 대규모 웹 애플리케이션을 위한 공격 완화 전략입니다.
- AWS Shield: DDoS 공격 방어. Standard는 모든 계정에 무료 적용되고, Advanced는 더 정교한 공격에 대한 24/7 대응 지원과 비용 보호를 제공
- AWS WAF: SQL 인젝션, XSS 같은 웹 계층 공격을 룰 기반으로 차단. Rate-based rule로 비정상적인 요청 폭증도 제한
- Amazon GuardDuty: 신규 솔루션이 배포된 이후의 비정상 행위 탐지(도메인 1 Task 1.2에서 조직 차원 설정을 다룸)
서비스 엔드포인트(VPC Endpoint, PrivateLink)를 이용해 인터넷을 거치지 않고 AWS 서비스에 접근하도록 설계하는 것도 이 작업의 범위입니다.
Task 2.4: 신뢰성 요구 사항을 충족하는 전략 설계
다중 AZ·다중 리전 아키텍처, 오토 스케일링 정책, 약결합(loose coupling) 설계의 기본 패턴은 SAA: 복원력 있는 아키텍처 에서 다뤘습니다. SAP 수준에서 추가되는 것은 애플리케이션 통합 서비스로 결합도를 낮추는 설계입니다.
- Amazon SQS: 생산자와 소비자 사이에 큐를 두어 처리 속도 차이를 흡수(버퍼링)
- Amazon SNS: 하나의 이벤트를 여러 구독자에게 동시에 전달(Pub/Sub)
- AWS Step Functions: 여러 Lambda·서비스 호출을 상태 머신으로 orchestration하여 재시도·에러 처리를 표준화
서비스 할당량(Service Quotas)을 사전에 확인하고 필요시 상향 요청을 미리 해두는 것도 신뢰성 설계의 일부입니다 — 트래픽이 급증하는 시점에 할당량 때문에 장애가 발생하는 것을 막기 위함입니다.
Task 2.5: 성능 목표를 충족하는 솔루션 설계
캐싱(CloudFront, ElastiCache), 스토리지 선택, 컴퓨팅 인스턴스 패밀리 선택, 목적별 데이터베이스 선택의 기본 판단 기준은 SAA: 성능과 비용 아키텍처 에서 다뤘습니다. 이 작업은 그 판단을 다양한 액세스 패턴을 가진 대규모 애플리케이션에 적용하는 데 초점을 둡니다 — 읽기 폭주 워크로드에는 읽기 복제본(Read Replica)과 캐싱 레이어를 조합하고, 쓰기 폭주 워크로드에는 샤딩이나 DynamoDB 같은 수평 확장형 데이터베이스를 검토하는 방식입니다.
Task 2.6: 솔루션 목적 및 목표를 충족하기 위해 비용 최적화 전략 결정
요금제 모델(예약 인스턴스, Savings Plans)과 적정 규모 산정의 기본 개념은 도메인 1의 Task 1.5 에서 다뤘습니다. 신규 솔루션 설계 시점에 추가로 고려할 것은 데이터 전송 비용입니다 — 같은 리전·같은 AZ 내 전송은 무료에 가깝지만, 리전 간 전송과 인터넷 아웃바운드 전송은 비용이 빠르게 누적됩니다. CloudFront를 캐싱 레이어로 두면 오리진에서의 아웃바운드 전송량을 줄여 비용을 절감할 수 있고, 같은 가용 영역 내에서 통신이 끝나도록 배치하는 것만으로도 데이터 전송 비용을 크게 줄일 수 있습니다.
다음 단계
새로운 솔루션을 설계하는 기준을 세웠다면, 이제 시간 축을 바꿔 이미 운영 중인 솔루션을 어떻게 지속적으로 개선하는가를 다룰 차례입니다. 도메인 3: 기존 솔루션의 지속적인 개선 으로 이어가세요.