"AWS DevOps 도구가 뭐냐"고 물으면 대부분 "CodeCommit, CodeBuild, CodeDeploy, CodePipeline"이라고 답한다. 틀린 답은 아니지만 절반도 못 본 답이다. AWS의 DevOps 생태계는 30개가 넘는 서비스가 SDLC 전 단계에 걸쳐 분포해 있고, 이들이 어떻게 맞물리는지 한 장의 지도로 보지 못하면 시험 시나리오의 "이 서비스 조합 중 가장 적합한 것은?"이라는 질문에 답할 수 없다.
오늘은 그 지도를 그린다. 도메인 1-6 전부에 걸친 도구 카탈로그를, "어디서 어떤 기능을 담당하는가"의 흐름으로.
2014년 11월 re:Invent에서 AWS는 CodeCommit, CodeDeploy, CodePipeline을 동시 발표했다. 그 전까지 AWS는 IaaS 인프라(EC2, S3, RDS)에 집중했고, CI/CD는 고객이 알아서 Jenkins로 깔라는 입장이었다. 그런데 점점 "AWS에 배포할 건데 왜 Jenkins 서버를 따로 운영해야 하나"라는 요구가 커졌고, 답이 Code* 시리즈였다.
| 서비스 | 출시 | 대체 대상 |
|---|---|---|
| CodeDeploy | 2014.11 | Capistrano, Fabric, Ansible |
| CodePipeline | 2015.07 | Jenkins, Bamboo, GoCD |
| CodeCommit | 2015.07 | GitHub Enterprise, GitLab, Bitbucket |
| CodeBuild | 2016.12 | Jenkins agents, Travis CI |
| CodeStar | 2017.04 (지금은 deprecating) | — |
| CodeArtifact | 2020.06 | JFrog Artifactory, Sonatype Nexus |
| CodeGuru | 2020.06 | SonarQube, Snyk |
| CodeCatalyst | 2022.12 | GitHub, GitLab (통합 플랫폼) |
이 진화에서 주목할 패턴은 두 가지. 첫째, AWS는 각 단계의 도구를 분리해서 출시했다(CodeBuild 따로, CodeDeploy 따로). 이게 GitLab/GitHub의 "한 플랫폼에 다 통합" 모델과 정반대다. 둘째, 2022년 CodeCatalyst가 등장하면서 AWS도 통합 플랫폼으로 가는 신호를 보냈다. 다만 시험 비중은 여전히 Code* 분리형 모델이 중심이다.
💡 관련 이론: Unix 철학의 "Do one thing and do it well"이 AWS Code* 시리즈에 직접적으로 반영되어 있다. 각 서비스가 한 단계만 담당하고, 다른 서비스와 IAM·이벤트 기반으로 느슨하게 결합. 이게 GitHub Actions의 "한 yaml에 다 적기"와 대비된다. trade-off: Code* 분리형은 학습 곡선이 가파르지만 fine-grained IAM 제어가 가능, 통합형은 빠르게 시작할 수 있지만 권한 분리가 어렵다.
[ SDLC 단계별 AWS 도구 지도 ]
PLAN → CODE → BUILD → TEST → RELEASE → DEPLOY → OPERATE
| | | | | | |
Issues CodeCommit CodeBuild CodeBuild CodePipeline CodeDeploy CloudWatch
JIRA/ GitHub GitHub Inspector CodeArtifact ECS deploy X-Ray
Linear GitLab Actions CodeGuru (versioning) Lambda alias Systems Manager
S3 (artifact) Docker SAST/DAST EB/AppRunner DevOps Guru
ECR build Incident Manager
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
CodePipeline의 한 Stage 결과를 다음 Stage로 전달하는 메커니즘은?
문제 2
CodeBuild가 VPC 내부의 RDS에 접근해야 한다. 가장 정확한 설정은?
문제 3
CloudWatch EMF(Embedded Metric Format)의 가장 큰 장점은?
문제 4
SSM Automation을 EventBridge와 결합한 자동 복구 시나리오의 일반적 흐름은?
문제 5
X-Ray와 ADOT 중 어떤 것을 선택해야 하는 시나리오로 가장 정확한 매칭은?
문제 6
AWS DevOps Guru가 가장 적합한 시나리오는?
문제 7
CodePipeline의 Custom Action에 Lambda를 사용할 때 그 본질적 이유는?
문제 8
"Pipeline-as-Code" 원칙에 가장 부합하는 CodePipeline 운영 방식은?
각 단계의 핵심:
AWS는 자체 issue tracker가 없다. JIRA, Linear, Asana 같은 외부 도구를 쓰되, EventBridge로 통합. CodeCatalyst는 자체 issue tracker를 가지고 있어 통합 플랫폼 모델에 가깝다.
CodePipeline은 단순한 trigger 도구가 아니다. 내부적으로 action provider model이라는 플러그인 아키텍처를 가진다.
[ CodePipeline 구조 ]
Pipeline
└─ Stage (직렬 실행)
├─ Stage: Source
│ └─ Action: CodeCommit / S3 / ECR / GitHub
├─ Stage: Build
│ └─ Action: CodeBuild / Jenkins
├─ Stage: Test
│ └─ Action (병렬): CodeBuild / DeviceFarm / 3rd party
└─ Stage: Deploy
└─ Action: CodeDeploy / ECS / CFN / Lambda invoke / Step Functions
각 Action은 3가지 type 중 하나:
Action 간 데이터는 artifact로 전달된다. Source Action이 산출물을 S3에 zip으로 올리고, Build Action이 그 zip을 다운로드해 처리한 뒤 결과를 다시 S3에. 이 S3 bucket이 "pipeline artifact bucket"이고 KMS 키로 암호화된다.
🔍 더 깊이: Pipeline의 artifact passing은 모두 S3 PutObject/GetObject 호출이다. 그래서 한 stage 결과가 다음 stage로 가는 "전달 시간"은 사실 S3 업로드/다운로드 시간이다. 큰 모노레포(예: 500MB monorepo)는 stage 전이마다 수십 초씩 깎인다. 해결법 1) Artifact를 작게 쪼개기 2) Build Action에서 다음 단계가 쓸 것만 zip으로 묶기 3) CodeBuild local cache 활용 (artifact가 아닌 캐시 형태로).
💡 관련 이론: Action provider model은 Jenkins의 plugin model과 본질적으로 같지만, isolation 모델이 다르다. Jenkins plugin은 JVM 안에서 같이 돌아 plugin 하나가 죽으면 master 전체에 영향. CodePipeline action은 별도 IAM principal로 실행되며 각자 격리. 보안 측면에서는 CodePipeline이 우월, 유연성에서는 Jenkins가 우월하다는 trade-off.
CodeBuild는 매 빌드마다 Docker container를 띄워서 buildspec.yml의 phase를 실행하고 끝나면 destroy한다. 이게 곧 격리성과 멱등성의 핵심이다.
[ CodeBuild 빌드 한 번의 lifecycle ]
1. 트리거 (CodePipeline / EventBridge / API)
2. 컨테이너 provisioning (보통 5-30초)
3. INSTALL phase → 의존성 설치
4. PRE_BUILD phase → 로그인, 환경 변수 셋업
5. BUILD phase → 실제 빌드/테스트
6. POST_BUILD phase → 산출물 정리
7. Artifact upload → S3
8. 컨테이너 destroy
각 phase는 shell command 시퀀스. 한 command가 실패하면 그 phase가 실패하고, on-failure 옵션이 없으면 전체 빌드가 fail.
📚 사례: 한 회사가 CodeBuild로 Docker 이미지 빌드 시 매번 base image를 다시 pull 하는 문제로 빌드 시간이 20분 걸렸다. 분석 결과 컨테이너가 매번 destroy 되어 Docker layer cache가 사라지는 게 원인. 해결: ① S3 cache로 docker layer 저장 ② Docker Hub pull rate limit 회피 위해 ECR로 base image 이전 ③ Local NVMe SSD cache 옵션 활성화. 결과 빌드 시간 20분 → 4분.
⚠️ 함정: CodeBuild는 기본적으로 별도 VPC 없이 실행된다(AWS-managed VPC 사용). 그래서 사내 패키지 저장소(VPC 내부 Artifactory)나 RDS에 접근하려면 별도로 VPC 설정 + ENI 생성이 필요하다. 이 ENI 생성이 빌드 시작 시간을 30-60초 늘린다. 시험에서 "VPC 내부 자원 접근하면서 빌드 시간 최소화" 시나리오의 답은 "VPC 설정 + ENI warm-up" 또는 "VPC 외부에서 접근 가능한 패키지 미러 사용".
Systems Manager(SSM)는 시험에서 가장 깊고 가장 자주 출제되는 서비스 중 하나다. 단순히 "Parameter Store가 있는 곳"이 아니다.
| 기능 | 용도 | DevOps 시나리오 |
|---|---|---|
| Parameter Store | 구성 값 저장 (계층적 path) | env별 DB 연결 문자열, feature flag |
| Secrets Manager | 시크릿 + 자동 회전 (별도 서비스) | DB 비밀번호, API 키 회전 |
| Run Command | 다수 EC2에 명령 실행 | 일괄 패치, 로그 수집 |
| Patch Manager | OS 패치 자동화 | Patch baseline, maintenance window |
| Session Manager | 브라우저 기반 SSH (포트 22 안 열어도 됨) | bastion 제거 |
| State Manager | 원하는 상태 유지 (configuration drift 방지) | "모든 EC2에 CloudWatch agent 설치" |
| Inventory | EC2/온프레미스 소프트웨어 목록 자동 수집 | 자산 관리, compliance |
| Compliance | Patch + Config 통합 compliance | 규제 보고서 |
| Automation | Runbook 자동 실행 | "장애 시 ASG 재시작" |
| AppConfig | Feature flag + 점진적 롤아웃 | A/B 테스트, dark launch |
| OpsCenter | 운영 이벤트 통합 워크플로 | 중앙 사고 관리 |
| Distributor | 소프트웨어 패키지 배포 | 사내 agent 배포 |
특히 SSM Automation은 시험의 핵심이다. 사고 자동 복구 시나리오의 거의 모든 답이 "EventBridge → SSM Automation Runbook"으로 끝난다.
🎯 시나리오: "RDS Read Replica의 replication lag이 60초를 넘으면 자동 복구"가 시험에 나오면 답은 다음 조합이다. ① CloudWatch Alarm (ReplicaLag > 60) ② EventBridge rule (alarm state change) ③ SSM Automation runbook(
AWS-RestartRdsInstance또는 custom) ④ SNS로 운영팀 통보. 모든 단계가 코드(JSON/YAML)로 정의 가능.
CloudWatch는 한 서비스가 아니라 10+ 서브 서비스의 묶음이다.
| 서브 서비스 | 용도 |
|---|---|
| Metrics | 메트릭 수집/저장 (custom + AWS-managed) |
| Logs | 로그 수집 (CloudWatch Logs Agent, CloudWatch Agent) |
| Alarms | 메트릭 기반 알림 |
| Dashboards | 시각화 |
| Logs Insights | 로그 쿼리 (KQL-like) |
| Synthetics | URL canary (외부 monitoring) |
| RUM | Real User Monitoring (JS SDK) |
| Evidently | A/B 테스트 + feature flag (AppConfig와 별개) |
| Container Insights | ECS/EKS/Fargate 전용 메트릭 |
| Lambda Insights | Lambda 전용 메트릭 |
| Application Insights | 자동 anomaly detection |
| Contributor Insights | top talker 분석 |
| ServiceLens | X-Ray + CloudWatch 통합 view |
이 생태계의 핵심은 **EMF (Embedded Metric Format)**이다. Lambda나 ECS 컨테이너에서 stdout으로 특정 JSON 형식의 로그를 출력하면, CloudWatch가 그것을 자동으로 metric으로 추출한다. 별도 CloudWatch API 호출 없이도 custom metric을 만들 수 있다는 뜻이다.
// EMF 형식 예시 (stdout 출력)
{
"_aws": {
"Timestamp": 1640000000000,
"CloudWatchMetrics": [{
"Namespace": "MyApp",
"Dimensions": [["Endpoint"]],
"Metrics": [{"Name": "Latency", "Unit": "Milliseconds"}]
}]
},
"Endpoint": "/api/users",
"Latency": 42
}🔍 더 깊이: EMF의 핵심 장점은 "metric과 log가 같은 데이터로 함께 저장"된다는 것이다. CloudWatch Logs Insights로 로그를 쿼리하다 "이 시점에 latency가 spike 했네" 싶으면 즉시 같은 데이터의 metric chart로 갈 수 있다. 별도 metric API 호출이 없어 비용도 절감(metric 호출당 $0.01이 아니라 logs 비용으로 통합).
AWS 분산 추적은 두 선택지가 있다.
X-Ray: AWS-native 추적 서비스. SDK 통합이 쉽고 IAM·CloudWatch와 자동 연결. 단점은 OpenTelemetry 표준이 아니라 vendor lock-in.
ADOT (AWS Distro for OpenTelemetry): OpenTelemetry 표준 구현. CNCF 표준이라 Jaeger, Tempo, Grafana 등으로 데이터 보낼 수도 있고 X-Ray로 보낼 수도 있다.
시험에서 둘을 구분하는 키워드:
💡 관련 이론: OpenTelemetry는 OpenTracing(2016)과 OpenCensus(Google, 2018)가 2019년에 CNCF에서 합쳐진 표준이다. W3C의 Trace Context 표준(traceparent header)도 통합. 이게 클라우드 vendor lock-in을 줄이는 핵심 표준이고, AWS는 X-Ray를 deprecating 하지 않으면서도 ADOT을 동시에 밀고 있다. 시험은 둘 다 알아야 한다.
EventBridge(구 CloudWatch Events)는 AWS 자동화의 글루(glue). 90+ AWS 서비스가 EventBridge로 이벤트를 송신하고, EventBridge가 그 이벤트를 rule로 매칭해 target(Lambda, SSM Automation, Step Functions 등)으로 전달한다.
[ EventBridge 흐름 ]
Source Bus Rule Target
------ --- ---- ------
EC2 state change → default → pattern match → Lambda
S3 PutObject → custom bus → schedule cron → SSM Automation
Code* events → partner bus → archive replay → Step Functions
SaaS (PagerDuty) → SNS / SQS
핵심 패턴 3가지:
{"source":["aws.ec2"],"detail":{"state":["stopped"]}})📚 사례: 한 회사가 매일 새벽 3시에 RDS 스냅샷 → cross-region 복사 → 7일 후 자동 삭제 워크플로를 구축했다. 도구 조합: ① EventBridge schedule (
cron(0 3 * * ? *)) → ② Lambda (snapshot 생성) → ③ Lambda (copy to DR region) → ④ EventBridge rule (snapshot complete) → ⑤ SSM Automation runbook (7일 후 삭제 tag). 전부 코드(CDK)로 정의되어 git에 들어간다.
AWS DevOps Guru(2020 출시)는 CloudWatch 메트릭에 머신러닝을 돌려 anomaly를 자동 검출한다. 사용자가 알람 임계값을 설정하지 않아도 "이 메트릭이 평소와 다르다"를 자동 발견.
시험에서는 "어느 도구가 자동으로 운영 이상을 검출하나"라는 키워드가 나오면 DevOps Guru. 단 비용이 높아 실무 채택률은 그리 높지 않다(인스턴스당 monthly fee).
Proton은 "내부 개발자 플랫폼(IDP)"을 위한 AWS 도구다. Platform 팀이 환경 템플릿(CloudFormation/Terraform)을 정의해 등록하고, 개발자는 셀프 서비스로 "프로젝트 생성"을 누르면 표준 환경이 자동 프로비저닝된다. 시험 비중은 낮지만, Platform Engineering 트렌드를 반영해 등장 가능.
| 도메인 | 비중 | 핵심 도구 |
|---|---|---|
| 1. SDLC 자동화 | 22% | CodePipeline, CodeBuild, CodeDeploy, CodeCommit, CodeArtifact |
| 2. 구성 관리 & IaC | 17% | CloudFormation, CDK, SAM, SSM Parameter Store, AppConfig |
| 3. 복원력 | 15% | Route 53, Multi-Region, Aurora Global, DynamoDB Global, Resilience Hub, FIS |
| 4. 모니터링 & 로깅 | 15% | CloudWatch (전 일족), X-Ray, ADOT, OpenSearch |
| 5. 인시던트 & 이벤트 대응 | 14% | EventBridge, SSM Automation, Chatbot, Incident Manager, Lambda |
| 6. 보안 & 컴플라이언스 | 17% | GuardDuty, Security Hub, Config, Inspector, Macie, Audit Manager, IAM |
이 표가 시험 직전에 머리에 떠올라야 한다.
오늘 본 그림은 단순하다. AWS DevOps는 30+ 서비스의 생태계이고, 시험은 그 중 어느 조합이 시나리오에 가장 적합한지를 묻는다. Code* 시리즈는 시작점이지 끝이 아니다. SSM Automation, EventBridge, CloudWatch 일족, X-Ray/ADOT, Inspector, Config — 이 모두가 시나리오 풀이의 필수 어휘다.
다음 글에서는 멀티 계정 전략(Organizations, Control Tower, IAM Identity Center)으로 들어간다. Professional 시험의 거의 모든 시나리오는 멀티 계정 환경이 기본 가정이라, 이 토대 없이는 다음 주제를 이해할 수 없다.