Day 5 - Week 12 종합 복습: 컨테이너와 IaC를 하나의 그림으로 꿰기

한 주 동안 흩어져 배운 조각들은 사실 하나의 큰 질문에 대한 서로 다른 답이다. 조각들은 ECS와 Fargate의 격리 모델, CloudFormation의 선언적 엔진, SAM의 매크로, CDK의 합성, 서버리스 아키텍처의 결합 원칙이다. 질문은 이렇다. "어떻게 하면 사람이 손으로 클릭하지 않고도, 안전하고 반복 가능하게, 컨테이너와 함수를 클라우드 위에 올려 운영할 수 있는가."

이번 복습은 개별 사실을 다시 나열하지 않는다. 그 사실들이 왜 그렇게 설계됐는지를 한 줄로 꿰어, 변형 문제에도 흔들리지 않게 만드는 것이 목표다.

DVA-C02의 컨테이너·IaC 영역은 배포(Deployment) 도메인의 큰 축이다. 단순 암기형(Fargate=awsvpc, SAM=Transform 필수)도 있지만, 변별력은 "이 증상의 근본 원인은 어느 계층인가"를 묻는 시나리오 문제에서 생긴다. ECR pull 실패가 IAM 문제인지 네트워크 문제인지, 스택 업데이트 실패를 Change Set으로 막을 수 있었는지, 멱등성 부재가 만든 중복인지를 가려야 한다. 이번 글은 Week 12의 핵심을 비교표와 "왜"로 다시 묶고, 실전 시나리오 12문항으로 마무리한다.

한 장으로 보는 Week 12: 다섯 기둥과 그 연결

Week 12는 다섯 개의 기둥으로 이뤄졌고, 그것들은 하나의 배포 파이프라인 위에서 만난다.

[개발자] 코드 + 인프라 정의(sam.yaml / cdk.py)
   |
   v
[CodeCommit/Git] → [CodeBuild]
                     - cdk synth / sam build
                     - docker build → ECR push
   |
   v
[CloudFormation / CodeDeploy]
   - ECS 서비스 롤링/블루그린 업데이트
   - Lambda 버전·별칭 전환
   |
   v
[ECS Fargate 태스크] ←── [ECR 이미지 pull]
   - taskRole로 런타임에 DynamoDB/S3/SQS 접근

이 그림에서 각 기둥이 어디에 끼는지 보면 헷갈림이 줄어든다.

• ECS/Fargate/ECR: 데이터 평면(컨테이너가 실제 도는 곳)과 이미지 공급망.
• CloudFormation: 모든 IaC의 최종 실행 엔진. SAM·CDK도 결국 여기로 귀결.
• SAM: 서버리스를 위한 CloudFormation 매크로.
• CDK: 프로그래밍 언어 → CloudFormation 합성.
• 서버리스 아키텍처 원칙: 이 위에 올라가는 함수들을 어떻게 느슨하게 결합하느냐.

이 파이프라인 전체를 관통하는 철학은 선언적 모델(declarative model) 이다. ECS 서비스는 "원하는 태스크 수"를 선언하면 조정 루프가 맞추고, CloudFormation은 "원하는 자원 상태"를 선언하면 엔진이 현재 상태와의 차이를 계산해 적용한다. 명령적 모델("이 명령을 이 순서로 실행")과 달리, 선언적 모델은 "목표 상태"만 말하고 "거기 도달하는 경로"는 시스템이 계산한다. 이 차이가 멱등성(같은 템플릿을 두 번 적용해도 결과가 같음)과 자가 치유(상태가 어긋나면 다시 맞춤)를 가능하게 한다. Week 12의 거의 모든 도구가 이 선언적 철학을 공유한다 — 그래서 한 도구의 직관이 다른 도구로 전이된다.

컨테이너 계층: 증상으로 원인 역추적하기

ECS 시나리오 문제는 "어떤 증상 → 어느 계층의 원인"을 묻는 형태가 많다. 이 매핑을 표로 정리해 두면 변형에도 대응할 수 있다.

이 표의 핵심 분기는 "시작 시점이냐 런타임이냐" 다. executionRole은 컨테이너가 뜨기 전에 ECS 인프라가 쓰는 권한(ECR pull, 로그 그룹 생성, 비밀 주입)이고, taskRole은 컨테이너가 뜬 뒤에 앱 코드가 쓰는 권한(DynamoDB·S3·SQS 호출)이다. "비밀을 환경 변수로 주입"은 시작 시점이라 executionRole, "앱이 런타임에 Secrets Manager를 직접 호출"은 taskRole — 같은 Secrets Manager라도 시점이 다르면 역할이 갈린다.

⚠️ 함정: "Secrets Manager 접근 실패"라는 같은 문구라도 두 갈래다. 태스크 정의의 secrets 블록으로 환경 변수에 주입하려다 실패하면 → 주입은 시작 시점이라 executionRole 문제. 앱이 런타임에 SDK로 getSecretValue를 직접 호출하다 실패하면 → taskRole 문제. 시험은 이 미묘한 차이를 묻는다. "주입(injection)이냐 직접 호출(runtime call)이냐"를 먼저 가른다.

Fargate가 awsvpc만 강제하는 게 IP 고갈 사고의 근원이다. awsvpc는 태스크마다 진짜 ENI와 사설 IP를 하나씩 준다. 태스크 100개면 IP 100개를 서브넷에서 가져간다. /24 서브넷(약 251개 가용 IP)에 다른 자원까지 있으면 빠르게 고갈된다. EC2 시작 유형에선 한 인스턴스의 ENI 한도(인스턴스 타입별)에도 걸린다. 그래서 "Fargate 태스크 확장 중 갑자기 시작 실패 + IP/ENI 부족" 시나리오의 답은 "더 큰 CIDR 서브넷 추가" 또는 "여러 서브넷 분산"이다. 격리를 위해 태스크마다 ENI를 주는 설계의 대가가 IP 소비라는 점을 이해하면 따로 외울 필요가 없다.

IaC 계층: 안전한 변경을 만드는 장치들

CloudFormation 시나리오는 "변경을 어떻게 안전하게 하느냐"와 "삭제/보호를 어떻게 다루느냐"에 집중된다. 헷갈리기 쉬운 개념 쌍을 "무엇을 보호하느냐"로 가른다.

분기점은 세 가지다.

1. Change Set은 "업데이트 전 미리보기", Drift는 "배포 후 실제 차이 감지"다. 시점이 반대다.
2. DeletionPolicy는 자원 단위, Termination Protection은 스택 단위다. 보호 대상의 크기가 다르다.
3. Nested Stack은 한 계정 모듈화, Stack Set은 Organizations로 다중 계정·리전 배포다. 범위가 다르다.

!ImportValue는 같은 리전 안의 스택끼리 Export한 값만 가져올 수 있다 — cross-region·cross-account 참조가 안 된다. 또 한 스택이 Export한 값을 다른 스택이 Import 중이면, 그 Export 값을 바꾸거나 Export한 스택을 지울 수 없다(의존 잠금). "다른 리전의 값을 ImportValue로 가져온다"는 선택지는 함정이고, 그런 경우엔 SSM Parameter Store나 다른 메커니즘을 써야 한다.

SAM과 CDK: 같은 종착지의 두 지름길

SAM과 CDK는 "CloudFormation을 직접 쓰기엔 장황하다"는 같은 불만에서 출발해, 다른 방식으로 푼다. 다시 짚는다.

둘의 공통 진실은 "종착지가 CloudFormation" 이라는 것이다. SAM은 YAML 압축을 풀고, CDK는 코드를 합성한다. 차이는 입력의 표현력이다 — SAM은 정형화된 서버리스 패턴을 짧게, CDK는 반복·조건·타입·테스트가 필요한 복잡한 인프라를 코드로.

sam local이 왜 Docker를 요구하는지가 미묘하다. Lambda 함수는 AWS의 특정 런타임 환경(Amazon Linux 기반, 정해진 라이브러리 버전)에서 돈다. 로컬 머신은 그 환경과 다르므로, 내 노트북에서 그냥 함수를 실행하면 "로컬에선 되는데 Lambda에선 안 되는" 환경 불일치가 생긴다. sam local은 AWS가 제공하는 Lambda 런타임을 본뜬 Docker 이미지 안에서 함수를 실행해, 실제 Lambda 환경을 로컬에서 흉내 낸다 — 이것이 컨테이너의 본질적 가치("어디서나 같은 환경")를 테스트에 적용한 것이다. 그래서 Docker가 없으면 sam local이 동작하지 않는다.

서버리스 결합: 동기 호출이라는 원죄

Week 12의 아키텍처 원칙 중 시험에서 비중이 큰 것은 "Lambda를 Lambda가 동기로 직접 호출하지 않는다"는 원칙이다. 이걸 "비용 2배"로만 외우면 변형에 약하므로, 한 번 더 근본을 묶는다.

동기 직접 호출의 네 가지 죄: 이중 과금(둘 다 실행 시간 과금), 오류 전파(B 장애가 A로), 타임아웃 누적(A의 한도 안에 B가 끝나야), 확장 결합(처리량 1:1). 해법은 비동기 매개를 끼우는 것이고, 그 매개의 선택은 시나리오로 갈린다.

• 작업을 나눠 한 곳이 처리 → SQS(큐, 1:1, 버퍼·재시도·DLQ)
• 한 사건을 여러 곳이 동시에 수신 → SNS(펍/섭, 1:N, 팬아웃)
• 이벤트 내용으로 라우팅 / 스케줄 / SaaS 통합 → EventBridge
• 순서·복잡한 분기·인간 승인 → Step Functions

SQS 표준 큐는 at-least-once 전달이라 중복이 정상이고, 소비자가 멱등해야 한다(중복은 두 장군 문제 때문에 분산 시스템에서 불가피). "정확히 한 번 처리 + 엄격한 순서"가 꼭 필요하면 FIFO 큐지만 처리량이 낮다(초당 300, 배치 3,000). 시험에서 "순서·중복 방지 필수"면 FIFO, "고처리량 우선 + 앱이 멱등성 처리"면 표준 큐다. "표준 큐가 순서를 보장한다"는 선택지는 틀린 함정이다.

정리

Week 12를 한 문장으로 묶으면 "컨테이너와 함수를 선언적 IaC로 안전하게 배포하고, 그것들을 느슨한 비동기 결합으로 엮는다"이다.

• ECS는 조정 루프로 원하는 상태를 유지하고, Fargate는 Firecracker로 서버리스 격리를 만든다. executionRole/taskRole은 시작 시점과 런타임으로 권한을 가른다.
• CloudFormation은 위상 정렬로 자원 순서를 풀고 Change Set으로 변경을 미리 보여준다. SAM과 CDK는 각각 매크로 확장과 코드 합성으로 CloudFormation에 귀결된다.
• 서버리스 아키텍처는 동기 직접 호출이라는 원죄를 큐로 풀고, at-least-once가 만드는 중복을 멱등성으로 흡수한다.
• 시나리오 문제는 이 사슬 위 어느 지점에서 "증상의 근본 원인은 어느 계층인가"를 묻는 형태가 많다. 시점(시작 vs 런타임), 보호 대상(자원 vs 스택), 결합 모델(1:1 vs 1:N)을 가르는 감각이 필요하다.

이로써 Week 12 컨테이너·IaC 단원을 마친다. 다음 주에는 관찰성과 문제 해결(CloudWatch, X-Ray, CloudTrail)로 넘어가, 배포한 시스템을 어떻게 들여다보고 고치는지를 다룬다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

Fargate 태스크 50개를 /28 서브넷(가용 IP 약 11개) 하나에 배치하려 했더니 일부 태스크가 시작되지 않고 IP/네트워크 관련 오류가 난다. 근본 원인과 해결로 옳은 것은?

• AtaskRole에 EC2 ENI 생성 권한이 없어 IP를 못 받음 — taskRole에 ec2:CreateNetworkInterface 추가
• Bawsvpc 모드가 태스크마다 ENI/사설 IP를 소비해 서브넷 IP가 고갈됨 — 더 큰 CIDR 서브넷 추가 또는 여러 서브넷 분산
• CexecutionRole의 ECR pull 권한 부족으로 일부 태스크만 시작 실패 — executionRole에 ECR 권한 추가
• D태스크 정의 리비전이 오래돼 네트워크 설정이 누락됨 — 새 리비전을 등록해 재배포

문제 2

태스크 정의의 secrets 블록으로 Secrets Manager의 DB 비밀번호를 환경 변수에 주입하도록 설정했는데, 태스크가 시작조차 못 하고 비밀을 가져오지 못한다. 권한을 어디에 줘야 하나?

• AtaskRole에 secretsmanager:GetSecretValue를 부여해 앱이 비밀을 읽게 한다
• BexecutionRole에 secretsmanager:GetSecretValue
• CFargate에는 없는 EC2 인스턴스 프로파일에 secretsmanager:GetSecretValue를 추가한다
• D권한이 아니라 Secrets Manager VPC 엔드포인트 부재로 인한 네트워크 도달성 문제다

문제 3

사설 서브넷의 Fargate 태스크가 ECR에서 이미지를 pull하지 못한다. executionRole에는 ECR 권한이 충분하다. 다음으로 의심할 원인은?

• A태스크 정의 리비전이 불변이라 이미지 태그가 옛 다이제스트를 가리켜 pull 실패
• B사설 서브넷에 NAT 게이트웨이나 ECR/S3용 VPC 엔드포인트가 없어 ECR에 도달하지 못함
• CECR 수명 주기 정책이 해당 이미지를 만료 삭제해 pull할 대상이 없음
• DtaskRole에 ECR 읽기 권한이 빠져 런타임에 이미지를 못 가져옴

문제 4

CloudFormation으로 운영 중인 스택을 업데이트하려는데, RDS 인스턴스가 의도치 않게 교체(replacement)되어 데이터가 날아갈까 걱정된다. 적용 전에 어떤 자원이 어떻게 바뀌는지 확인하려면?

• A바로 update-stack을 실행하고 롤백 트리거에 의존해 문제 시 자동 복구한다
• BChange Set을 생성해 추가·수정·삭제·교체될 자원 목록을 검토한 뒤 적용
• CDrift Detection을 실행해 적용 후 바뀔 자원을 미리 감지한다
• D스택을 삭제하고 다시 생성해 깨끗한 상태에서 원하는 구성을 만든다

문제 5

스택을 삭제하더라도 그 안의 S3 버킷(중요 데이터 보관)만은 삭제되지 않고 남기를 원한다. 어떻게 설정하나?

• A스택에 Termination Protection을 켜서 스택 삭제 시 버킷이 보존되게 한다
• B해당 S3 버킷 자원에 DeletionPolicy: Retain 설정
• CStack Policy로 S3 버킷 자원을 Deny 대상에 넣어 삭제로부터 보호한다
• DDrift Detection을 켜서 버킷이 삭제되려 하면 차이를 감지해 막는다

문제 6

한 SAM 템플릿을 배포하려는데 Transform 선언이 빠져 일반 CloudFormation으로 처리되며 AWS::Serverless::Function을 알 수 없는 자원 타입이라 거부한다. 무엇이 필요한가?

• AParameters 섹션을 추가해 Serverless 자원 타입을 파라미터로 선언한다
• B템플릿 최상위에 Transform: AWS::Serverless-2016-10-31 선언
• CGlobals 섹션을 추가해 함수 공통 속성을 정의하면 타입이 인식된다
• DOutputs 섹션에 함수 ARN을 내보내면 자원 타입이 등록된다

문제 7

주문 완료 이벤트 하나가 발생하면 재고·이메일·분석 세 시스템이 동시에 각자 처리해야 하고, 각 소비자는 일시적 폭주를 버틸 버퍼와 실패 격리가 필요하다. 가장 적합한 구성은?

• ASQS 큐 하나에 재고·이메일·분석 세 소비자를 붙여 같은 메시지를 셋 다 받게 한다
• BSNS 토픽 → 세 개의 SQS 구독(각 SQS에 소비자 + DLQ)으로 팬아웃
• C주문 Lambda가 재고·이메일·분석 시스템을 순차로 동기 호출하고 실패 시 재시도한다
• DEventBridge 스케줄 규칙으로 주기적으로 세 시스템에 주문 이벤트를 전달한다

문제 8

SQS 표준 큐를 소비하는 결제 처리 Lambda가 같은 메시지를 가끔 두 번 처리해 이중 결제가 발생한다. 올바른 근본 대응은?

• ASQS를 신뢰할 수 없으니 SNS로 교체
• B표준 큐는 at-least-once라 중복이 정상이므로, 멱등성 키 + DynamoDB 조건부 쓰기(attribute_not_exists)로 소비자를 멱등하게 만들거나 FIFO 큐 사용
• CLambda 동시성을 1로 제한
• D메시지 크기를 줄임

문제 9

API Gateway 뒤 Lambda A가 무거운 후처리를 Lambda B에 넘긴다. 현재 A가 B를 동기 호출하는데 비용이 높고, B가 느려지면 API 응답이 타임아웃난다. 개선안은?

• AB의 메모리·타임아웃을 늘려 더 빨리 끝나게 하고 동기 호출 구조는 유지한다
• BA가 SQS에 작업을 넣고 즉시 응답, B가 큐를 비동기로 소비
• CA와 B를 하나의 큰 Lambda로 합쳐 호출 간 오버헤드와 이중 과금을 없앤다
• DA가 B를 비동기로 트리거한 뒤 결과가 나올 때까지 1초 간격으로 상태를 폴링한다

문제 10

CDK로 작성한 인프라를 새 AWS 계정의 ap-northeast-2 리전에 처음 배포하려 하자 자산 업로드용 버킷이 없다는 류의 오류가 난다. 먼저 무엇을 해야 하나?

• Acdk synth를 다시 실행해 자산 버킷 정의가 포함된 템플릿을 재생성한다
• B해당 계정·리전에 cdk bootstrap 1회 실행해 배포용 S3·ECR·IAM 발판을 구성
• Ccdk destroy로 잔여 스택을 정리한 뒤 깨끗한 상태에서 다시 deploy한다
• DCloudFormation 콘솔에서 자산용 S3 버킷 스택을 수동 생성한 뒤 deploy한다

문제 11

ap-northeast-2의 네트워크 스택이 Export한 VPC ID를, us-east-1의 다른 스택에서 !ImportValue로 가져오려 했더니 동작하지 않는다. 이유는?

• A!ImportValue 구문에 Export 이름을 잘못 적은 문법 오류 때문
• B!ImportValue는 같은 리전 내 스택 간 Export/Import만 지원하며 cross-region 참조가 불가능하기 때문
• CVPC ID는 Export 대상에서 제외되는 자원 타입이라 애초에 Import할 수 없어서
• D가져오는 스택의 실행 역할에 us-east-1 자원 접근 권한이 없어서

문제 12

같은 CloudFormation 템플릿을 동일 환경에 두 번 연속 적용했는데, 두 번째 적용에서 아무 변경도 발생하지 않고 자원이 그대로다. 이 동작의 근거는?

• ACloudFormation이 동일 템플릿을 캐싱해 두 번째 적용을 건너뛰는 버그 때문
• BCloudFormation은 선언적 모델이라 "원하는 상태"와 현재 상태가 같으면 변경할 게 없어 멱등하게 동작함
• C두 번째 적용 시 Change Set이 빈 변경 집합을 만들어 업데이트를 차단했기 때문
• DTermination Protection이 켜져 있어 두 번째 적용의 변경이 막혔기 때문