https://www.youtube.com/watch?v=hOJbhfF0DYQ

description: |

1. 이건 꼭 알아야 한다[^1]

[? 질문] AWS에서 인프라를 **코드 기반(Infrastructure as Code)**으로 구축할 때, 왜 AWS CDK를 쓰는가(기존 방식 대비 무엇이 달라지는가)[^2]
[= 답] AWS CDK는 **익숙한 프로그래밍 언어(TypeScript/Python/Java 등)**로 AWS 리소스를 **객체지향 추상화(Construct)**로 정의하고, 이를 **CloudFormation 템플릿으로 합성(synth)**해 안전하고 반복 가능한 방식으로 배포하게 해 주며, 콘솔 수동 작업/스크립트/순수 CloudFormation 템플릿의 한계를 보완한다.[^2]

[? 질문] CDK로 “짧은 URL(비틀리 유사)” 같은 서버리스 앱을 얼마나 빠르게 만들고 검증할 수 있는가[^3]
[= 답] DynamoDB 테이블 + Lambda 함수 + API Gateway를 CDK로 연결해 REST API를 만들고, cdk diff로 변경점을 확인한 뒤 cdk deploy로 배포하여 곧바로 curl로 동작 검증(짧은 URL 생성 및 리다이렉트)을 수행할 수 있음을 데모로 보여준다.[^3]

[? 질문] CDK 기반으로 **테스트(부하 발생)**와 **모니터링(대시보드/알람)**까지 코드로 묶어 운영 수준의 자신감을 어떻게 확보하는가[^4]
[= 답] 별도 “트래픽 스택”을 만들어 ECS Fargate로 부하를 발생시키고, CloudWatch Dashboard/Alarm을 CDK로 생성해 DynamoDB·Lambda·API Gateway의 지표를 시각화/경보 이메일로 받으며, 테스트가 끝나면 cdk destroy로 테스트 스택만 선택 삭제하거나 전체 삭제까지 수행해 환경을 깔끔히 정리한다.[^4]

2. 큰 그림[^5]

이 콘텐츠는 AWS 솔루션즈 아키텍트가 **AWS Cloud Development Kit(AWS CDK)**를 소개하고, 가상의 요구사항(짧은 URL 서비스)을 예로 들어 서버리스 애플리케이션을 코드로 구축→배포→테스트→모니터링→정리하는 전 과정을 데모로 설명하는 웨비나이다.[^5] 또한 인프라 구성 방식이 콘솔 수동 작업에서 스크립트, CloudFormation, 그리고 CDK로 진화해 온 배경과 이유를 단계적으로 짚는다.[^6]

• AWS CDK의 본질: 익숙한 언어로 인프라를 객체지향적으로 모델링하고, 결과를 CloudFormation으로 배포해 반복 가능성과 안전성을 얻는다.[^2]
• 빠른 구현 + 검증 루프: DynamoDB/Lambda/API Gateway를 연결해 REST API를 만들고, cdk diff·cdk deploy·curl로 즉시 확인한다.[^3]
• 테스트/관측성까지 코드화: Fargate 기반 트래픽 스택으로 부하를 만들고, CloudWatch 대시보드/알람을 구성해 병목/한계(예: 프로비저닝 용량 초과)를 가시화하고 경보를 받는다.[^4]

3. 하나씩 살펴보기[^7]

3.1 오프닝: 발표자 소개, 질문 방법, 진행 순서[^7]

발표자는 자신을 AWS의 솔루션즈 아키텍트로 소개하고, 오늘 주제가 **“AWS CDK를 이용한 코드 기반 인프라 구축”**임을 밝힌다.[^7]
웨비나 중 질문은 우측 패널(질문창)에 남기면 담당자가 확인 후 답변하는 방식으로 안내한다.[^8]

이어서 강연의 전체 흐름을 다음 3단계로 예고한다.[^9]

1. AWS CDK 소개[^9]
2. 가상의 시나리오로 CDK를 사용해 앱을 빠르게 개발하고 테스트 및 모니터링하는 방법을 데모로 확인[^9]
3. 데모 경험을 요약하며 마무리[^9]

3.2 AWS CDK 정의: “익숙한 언어로 클라우드 리소스를 모델링/프로비저닝”[^10]

발표자는 AWS CDK를 다음과 같이 정의한다.[^10]

• AWS CDK는 오픈 소스 소프트웨어 개발 프레임워크이며[^10]
• 익숙한 프로그래밍 언어(TypeScript, Python, JavaScript, Java, C# 등)를 사용해[^11]
• 클라우드 애플리케이션 리소스를 **모델링(modeling)**하고 **프로비저닝(provisioning)**할 수 있다.[^10]
• 즉, 애플리케이션 코드만이 아니라 인프라 선언까지 같은 개발 언어/워크플로에서 함께 수행하도록 돕는다.[^11]

3.3 인프라 구성 방식의 4단계 진화: 콘솔 → 스크립트 → CloudFormation → CDK[^12]

발표자는 “지금까지 클라우드 인프라를 어떻게 구성해 왔는가”를 4단계 진화로 설명한다.[^12]

3.3.1 1단계: 관리 콘솔에서 수동으로 한땀한땀 구성[^13]

• AWS를 처음 배울 때 가장 흔히 접하는 직관적 방식은 관리 콘솔에서 수동 생성이다.[^13]
• 그러나 이 방식은 수십~수백 개 리소스를 반복적으로 구성해야 하는 상황에서 매우 불편해진다.[^14]

3.3.2 2단계: 명령형(스크립트) 인프라 구성(AWS CLI/SDK)[^15]

• AWS 서비스 대부분이 API 기반으로 동작하므로, AWS CLI 또는 AWS SDK로 스크립트를 작성해 운영/관리를 할 수 있다.[^15]
• 하지만 이런 스크립트 접근에는 다음 문제가 생길 수 있다고 지적한다.[^16]
  • 리소스 생성 중 오류 발생 시 재시도/롤백 처리가 번거롭다.[^16]
  • 여러 사람이 동시에 같은 스크립트를 실행하면 **경합(충돌)**이 발생할 수 있다.[^16]

3.3.3 3단계: 선언형 IaC(CloudFormation 템플릿)[^17]

• 세 번째 단계는 인프라를 코드로 선언해 관리하는 방식이며, AWS에서는 CloudFormation이 대표적이다.[^17]
• CloudFormation은 **스택(Stack)**을 통해 안전하고 반복 가능한 방식으로 리소스를 프로비저닝할 수 있다.[^17]
• 그러나 CloudFormation을 직접 다루려면 서비스별로 YAML/JSON 템플릿 문법과 옵션을 학습해야 하고[^18] 내장 함수로 리소스를 참조할 수는 있지만, 리소스 간 의존관계를 맞추며 기술하는 것이 쉽지 않을 수 있다고 말한다.[^19]

3.3.4 4단계: AWS CDK 등장(고수준 객체지향 추상화 + CloudFormation 배포)[^20]

여기서 CDK의 포지셔닝이 나온다.[^20]

• AWS CDK는 주요 AWS 리소스를 “명령어로 정의하는” 형태의 **높은 수준의 객체지향 추상화(Construct)**를 제공한다.[^20]
• 객체지향 언어를 지원하므로, 루프/조건문 같은 코드 논리를 자연스럽게 표현하면서 인프라를 정의할 수 있다.[^21]
• 작성한 CDK 코드는 컴파일/합성되어(발표에서는 “어셈블리 언어 형태”라고 비유) CloudFormation 템플릿을 만들고, 이를 CloudFormation 스택으로 배포하여 안전하고 반복 가능한 방식으로 프로비저닝한다.[^22]
• 결과적으로 CDK는 개발자가 매일 쓰는 익숙한 환경과 팀 워크플로에서 인프라를 정리할 수 있게 해 사용 편의성과 생산성을 극대화한다고 강조한다.[^23]

[!IMPORTANT] CDK의 배포 메커니즘 요지
CDK로 작성 → CloudFormation 템플릿 생성(synth) → CloudFormation 스택으로 배포(deploy)라는 “안전한 반복 배포” 경로를 따른다.[^22]

3.4 CDK의 구성요소와 CLI 명령(bootstrap/diff/deploy/destroy 등)[^24]

발표자는 CDK가 크게 3가지 메인 구성요소로 이뤄진다고 설명한다.[^24]

• 개발자는 스택(Stack) 단위로 인프라를 정의/관리한다.[^24]
• 언어별로 제공되는 AWS **Construct Library(생성자 라이브러리)**를 활용해 리소스를 생성한다.[^25]
• 생성된 스택은 AWS CDK CLI 명령으로 관리한다.[^26]

이어 CLI 명령들을 소개한다.[^27]

• cdk bootstrap: CDK가 템플릿/자산(assets)을 배포하기 위해 사용하는 스테이징용 S3 버킷 등을 계정/리전에 먼저 생성하는 초기화 작업이다.[^27]
• 프로젝트 초기화(예: cdk init)와 변경사항 확인(cdk diff), 배포(cdk deploy), 삭제(cdk destroy) 등을 수행할 수 있다고 나열한다.[^28]

3.5 데모 1부 시나리오: “다음 주까지 짧은 URL 생성 앱 필요”[^29]

데모는 가상의 요구사항으로 시작한다.[^29]

• “다음주까지 마케팅 이메일 캠페인을 위한 짧은 URL 생성 애플리케이션이 필요”하다는 지시를 받았고[^29]
• 자신은 DevOps 엔지니어이며, CDK로 비틀리(bitly) 같은 기능을 단숨에 만들자고 제안한다.[^30]

3.5.1 서버리스 아키텍처 설명(요청 흐름 2가지)[^31]

아키텍처 다이어그램을 언어로 풀어 설명한다.[^31]

1. 긴 URL → 짧은 URL 생성 흐름[^31]

   • 사용자가 쿼리 스트링 파라미터로 target URL을 넣어 API Gateway를 호출한다.[^31]
   • Lambda가 해당 URL을 DynamoDB에 저장하고[^31]
   • 8자리 UUID 코드를 포함한 짧은 URL을 반환한다.[^31]

2. 짧은 URL 호출 → 원본 URL로 리다이렉트 흐름[^32]

   • 사용자가 짧은 URL을 호출하면 경로 파라미터의 ID 값을 읽고[^32]
   • 원래 URL로 리다이렉트하도록 Lambda 코드를 작성해야 한다.[^32]

3.5.2 완성 동작을 먼저 확인(비틀리처럼 동작)[^33]

발표자는 데모가 목표로 하는 동작을 먼저 보여준다.[^33]

• .../ 엔드포인트에 targetUrl=amazon.com 같은 쿼리 스트링을 주면 짧은 링크가 생성되고[^33]
• 그 링크를 브라우저 주소창에 붙여 호출하면 amazon.com으로 리다이렉트되는 것을 확인한다.[^34]

3.6 데모 환경 준비: Cloud9 + 테스트용 VPC 구성(콘솔 작업 포함)[^35]

발표자는 오늘 데모를 싱가폴 리전의 Cloud9 환경에서 진행하고, 테스트를 위해 VPC 환경을 만든다고 말한다.[^35]

3.6.1 VPC 생성(위자드)과 Elastic IP 할당[^36]

• VPC를 만들기 전 Elastic IP를 하나 할당받는다.[^36]
• VPC 위자드에서 퍼블릭/프라이빗 서브넷이 공존하는 형태로 생성하며[^37]
• VPC 이름은 “cdk test”로 두고, 앞서 할당받은 Elastic IP를 입력한 뒤 생성한다고 설명한다.[^37]

3.6.2 Cloud9 환경 생성 및 시인성 설정(테마/폰트)[^38]

• Cloud9에서 “Create environment”로 환경을 만들고 이름을 “cdk env”로 둔 뒤 기본값으로 생성한다.[^38]
• 환경이 활성화되면 테마를 어둡게 바꾸고 폰트 크기(에디터/터미널)를 조절하는 과정을 보여준다.[^39]

3.7 프로젝트 초기화: CDK 설치, Python 프로젝트 생성, 가상환경, 의존성 설치[^40]

3.7.1 CDK CLI 설치(NPM 글로벌 설치)[^40]

• npm install -g aws-cdk로 CDK CLI를 설치한다.[^40]

3.7.2 프로젝트 디렉터리 생성 및 CDK 초기화(Python)[^41]

• 프로젝트는 url-short 같은 이름으로 폴더를 만들고 이동한다.[^41]
• cdk init을 Python 템플릿으로 수행해 기본 파일들이 자동 생성되는 것을 확인한다.[^42]

3.7.3 Python 가상환경 진입 및 requirements 설치[^43]

• 개발 안정성을 위해 가상환경에 진입한다(예: source .venv/bin/activate).[^43]
• requirements.txt(발표에서는 해당 파이썬 파일/정의 파일)에서 DynamoDB, EC2, Lambda, API Gateway, CloudWatch 등 필요한 라이브러리를 명시하고 저장한다.[^44]
• pip install -r requirements.txt로 의존성을 설치한다.[^45]

3.7.4 Bootstrap 수행(자산 배포용 S3 등 생성)[^46]

• CDK로 만든 결과물을 배포하려면 먼저 부트스트랩이 필요하다고 설명한다.[^46]
• cdk bootstrap aws://계정/리전 형태로 실행하면 CloudFormation 스택이 생성되며 S3 버킷 등이 자동 생성되는 것을 확인할 수 있다고 말한다.[^46]

3.8 스택 코드 구조 파악: app.py → stack 파일로 연결, 정의로 이동(F3)[^47]

발표자는 프로젝트 시작점인 app.py를 열어 구조를 살펴본다.[^47]

• “url short stack”이 특정 폴더 아래 url_short_stack.py 같은 파일로 정의돼 있음을 확인한다.[^47]
• 에디터에서 F3(정의로 이동)를 이용해 클래스 정의로 이동하는 방법을 보여주며, 이제부터 리소스를 하나씩 추가해 나가면 된다고 안내한다.[^48]

3.9 DynamoDB 테이블 생성(첫 리소스) 및 배포 확인[^49]

첫 번째로 DynamoDB 테이블을 만든다.[^49]

• 스택 코드에서 aws_dynamodb를 import한다.[^49]
• 테이블을 정의하는데, 예시로 “mapping”이라는 이름의 테이블을 만들고[^50]
• 파티션 키는 id(String 타입)로 둔다.[^50]

정의 후 cdk deploy를 수행하면 DynamoDB 테이블이 생성되는 것을 확인할 수 있고, 이는 CloudFormation 스택을 통해 생성됨을 함께 보여준다.[^51] DynamoDB 콘솔에서도 테이블이 생성 중/생성됨을 확인한다.[^51]

3.10 Lambda 함수 코드 작성: 쿼리 스트링이면 생성, 패스 파라미터면 리다이렉트[^52]

다음으로 Lambda 함수 코드를 작성한다.[^52]

• lambda 디렉터리를 만들고 handler.py 파일을 만든다.[^52]
• 발표자는 미리 준비해 둔 코드를 넣었다고 말하며, Lambda 핸들러 구조를 설명한다.[^53]
  • 메인 함수는 event와 context 두 파라미터를 받는다.[^53]
  • event: 호출 시 전달된 파라미터/요청 정보[^54]
  • context: 실행 동안의 런타임 정보[^54]

Lambda의 분기 로직은 다음처럼 설명된다.[^55]

• 쿼리 스트링에 targetUrl(발표에서는 “타겟 URL”)이 있으면 짧은 URL 생성 로직 수행[^55]
• 패스 파라미터에 ID 값이 있으면 DynamoDB에서 원본 URL을 찾아 302 리다이렉트 수행[^56]
• 둘 다 아니면 API 사용법/안내 내용을 출력하도록 응답을 구성[^55]

DynamoDB 연동 방식도 코드 설명으로 포함된다.[^57]

• 테이블을 읽기 위해 테이블 이름을 환경변수에서 가져오는 구조가 있고[^57]
• target URL이 들어오면 8자리 UUID(또는 8자리 ID)를 만든 뒤 DynamoDB에 아이템을 등록한다.[^58]
• 등록된 ID를 기반으로 리다이렉트 가능한 짧은 URL을 반환한다.[^58]

리다이렉트 함수에서는[^59]

• 경로의 ID로 DynamoDB를 조회해 원본 URL을 찾고[^59]
• 없으면 에러 반환, 있으면 HTTP 302로 해당 URL로 이동한다.[^59]

3.11 스택에 Lambda 리소스 프로비저닝: 런타임/핸들러/코드경로/권한/환경변수[^60]

Lambda 코드를 만들었으니 이를 CDK 스택에 리소스로 선언한다.[^60]

• 스택 파일로 돌아가 aws_lambda를 import한다.[^60]
• Lambda 함수 리소스를 생성하면서:
  • 함수 이름(예: backend) 설정[^61]
  • 런타임은 Python 3.7로 지정[^61]
  • 핸들러는 handler.py 안의 main 함수로 연결[^61]
  • 코드 위치는 lambda 디렉터리 소스를 사용하도록 지정[^61]

또한 Lambda가 DynamoDB에 읽기/쓰기를 해야 하므로 권한 부여가 필요하다고 말한다.[^62]

• grant_read_write_data 같은 방식으로 테이블 접근 권한을 함수에 부여한다.[^62]

그리고 코드에서 참조하던 환경변수(테이블 이름)를 Lambda에 주입한다.[^63]

• TABLE_NAME 같은 키로 테이블 이름을 Lambda 환경변수로 넘겨준다.[^63]

3.12 API Gateway 생성 및 Lambda 연결: REST API를 간단히 완성[^64]

Lambda를 호출할 엔드포인트를 만들기 위해 API Gateway를 추가한다.[^64]

• 스택에서 API Gateway 모듈을 import하고[^64]
• REST API를 정의하면서 위에서 만든 Lambda를 통합(integration)으로 연결해 호출되도록 구성한다.[^65]
• 이 과정으로 REST API 정의를 비교적 간단하게 마칠 수 있다고 설명한다.[^65]

배포 전에는 cdk diff로 기존 설정과 현재 설정의 변경사항을 확인한다.[^66] diff 결과로 Lambda, API Gateway 등 다양한 리소스가 새로 추가되는 것을 확인한다.[^66]

이후 cdk deploy로 배포하며, 변경 사항 적용을 승인(y)하면 CloudFormation에서 스택이 업데이트되는 것을 확인한다.[^67] 배포가 끝나면 API Gateway 엔드포인트 URL이 출력된다.[^68]

3.13 동작 테스트: curl로 짧은 URL 생성 및 리다이렉트 확인[^69]

배포된 엔드포인트를 테스트한다.[^69]

• 터미널에서 curl로 API를 호출하고, 쿼리 스트링 파라미터로 target URL에 amazon.com URL을 넣는다.[^69]
• 호출 결과로 짧은 URL(또는 응답)이 나오고[^70]
• 그 결과 URL을 열어 불필요한 부분을 제거하고 실행하면 amazon.com으로 정상 리다이렉트 되는 것을 확인한다.[^70]

3.14 데모 2부 목표: 성능 테스트 + 모니터링 대시보드/알람 구성[^71]

데모 2부는 “성공적인 마케팅을 위해 성능을 보장할 수 있는지”를 증명하라는 요구로 시작한다.[^71]
이를 위해 부하 테스트 도구와 모니터링 대시보드를 만드는 방법을 살펴본다고 한다.[^71]

3.14.1 2부 아키텍처: 트래픽 스택(ECS Fargate) + CloudWatch 대시보드[^72]

발표자가 제시한 구성은 다음과 같다.[^72]

• “트래픽 스택”을 만들어 API를 지속 호출하는 트래픽을 발생시킨다.[^72]
• 트래픽 스택은 Docker 기반이며 서버리스 컨테이너 실행 방식으로 ECS Fargate를 사용한다.[^72]
• API Gateway / Lambda / DynamoDB에서 나오는 메트릭을 수집해 CloudWatch Dashboard로 만든다.[^72]

3.15 부하 발생 스크립트 작성: 1초마다 API 호출(ping.sh) + 실행권한[^73]

먼저 URL이 정상 동작하는지 curl -i로 호출해 302 리다이렉트를 확인한다.[^73]

그 다음 대량 부하를 위해 “ping” 도구를 만든다.[^74]

• mkdir ping 폴더를 만들고 이동한다.[^74]
• ping.sh 스크립트를 만든다.[^74]
• 스크립트는 1초마다 지정한 URL을 호출하는 역할을 한다.[^75]
• 여러 개의 스크립트(또는 컨테이너)가 병렬 실행되면 더 큰 트래픽이 발생한다는 식으로 부하 증가 원리를 설명한다.[^75]
• 실행 권한을 부여하고, URL 값을 넣어 실행 테스트를 수행해 정상 동작을 확인한다.[^76]

3.16 Docker 이미지화: Dockerfile 작성 → build → run으로 동작 확인[^77]

스크립트를 컨테이너로 여러 개 띄우기 위해 Docker 이미지로 만든다.[^77]

• Docker 이미지 빌드를 위해 Dockerfile을 정의한다.[^77]
• Dockerfile은 셸 스크립트가 실행되도록 구성한다.[^78]
• docker build로 “ping” 이미지를 만든다.[^79]
• 이미지 생성 후 docker run으로 URL을 인자로 주고 정상적으로 실행되는지 테스트한다.[^80]

여기까지로 “이 이미지를 여러 개 실행하면 부하 테스트가 가능”하다는 기반을 마련한다.[^81]

3.17 트래픽 스택 코드 작성: 특정 VPC에 ECS 클러스터 + Fargate 태스크/서비스(DesiredCount로 TPS 조절)[^82]

이제 CDK로 트래픽 스택을 만든다.[^82]

• 루트로 돌아와 트래픽 관련 코드를 추가하고, traffic.py 같은 파일을 생성해 미리 준비된 코드를 붙여넣는다.[^82]
• 코드의 핵심 구성은:
  • 특정 VPC 안에 ECS 클러스터 생성[^83]
  • 그 안에 Fargate 태스크 정의[^83]
  • 태스크는 앞서 만든 ping Docker 이미지를 사용[^83]
  • Fargate 서비스의 desiredCount로 태스크 수를 늘려 TPS(초당 요청 수)를 올린다는 설명[^84]
    • “컨테이너 하나가 1초에 1번 호출”을 하므로, 태스크 수를 N으로 하면 대략 N TPS가 된다는 식의 직관을 제공한다.[^84]

또한 환경변수 기반으로 계정/리전/VPC ID 등을 바꿔 여러 환경(dev/stage/prod)에 재배포 가능하도록 설계하는 것이 중요하다고 강조한다.[^85]

• os import로 환경변수를 읽어오고[^86]
• 배포 환경에 따라 account, region, VPC ID 등을 선언/주입해 구성한다.[^85]
• 실제 데모에서는 기존에 만든 VPC의 ID를 복사해 코드의 VPC ID 값에 붙여넣어 교체한다.[^87]

3.18 app.py에 두 번째 스택(트래픽 스택) 추가: 스택이 2개가 되면 배포 대상 지정 필요[^88]

트래픽 스택 클래스를 만든 뒤, 시작점인 app.py로 가서 스택을 추가한다.[^88]

• 트래픽 스택을 import하고[^88]
• 별도의 CloudFormation 스택 이름을 “test-ping” 같은 이름으로 지정해 배포 대상으로 등록한다.[^88]

배포를 시도하면 에러가 나는데, 처음에는 import 누락(예: aws_ec2) 때문임을 보여준다.[^89] import를 추가하고 저장하면 에러가 사라진다.[^89]

다시 배포하면 또 에러가 나는데, 이번에는 스택이 2개가 되었기 때문에 “어떤 스택을 배포할지” 지정해야 한다는 점을 보여준다.[^90]

• 두 스택을 모두 배포하려면 와일드카드(*)를 사용해 전체 배포를 진행한다.[^91]
• 변경사항을 확인하고 y로 승인하면 배포가 진행된다.[^91]

배포 과정에서 환경변수 변경(계정/리전 정보 등)으로 인해 한 번 더 확인/배포가 진행되는 장면도 언급된다.[^92]

3.19 트래픽 발생 확인: ECS 태스크 수(10개)와 DynamoDB 메트릭 상승 확인[^93]

배포가 완료되면 ECS 콘솔에서 클러스터를 확인한다.[^93]

• 클러스터 안에 태스크가 desiredCount에 맞게(예: 10개) 실행 중인 것을 확인한다.[^93]
• 각 태스크가 실제로 동작 중임을 확인한다.[^93]

DynamoDB 메트릭에서도 실제로 read/write 관련 지표가 올라가고 있음을 확인한다.[^94]

3.20 CloudWatch 대시보드/알람을 CDK로 추가: “cdk-watchful” 활용[^95]

발표자는 CloudWatch 대시보드를 “직접 다 만들어도 되지만”, CDK와 함께 쓰기 좋은 도구로 cdk-watchful을 소개하며 이를 이용해 대시보드를 추가하는 방법을 보여준다.[^95]

• 패키지 설치: pip install cdk-watchful 같은 방식으로 설치한다.[^96]
• 코드에서 from cdk_watchful import Watchful 형태로 import한다.[^97]
• 스택 하단에 Watchful을 구성하는 코드(테이블, Lambda, API 등 대상 리소스 연결)를 추가해 모니터링 대시보드를 만든다고 설명한다.[^98]
• 알람 이메일 수신 주소를 특정 메일로 설정해 두었다고 언급한다.[^99]
• 수집 대상은 “API, Lambda, DynamoDB 테이블” 등 핵심 컴포넌트가 된다고 말한다.[^100]

변경사항을 배포한다.[^101]
스택이 2개이므로 이번에는 변경된 “url short” 스택만 지정해 배포한다는 식으로 진행한다.[^101]

배포가 완료되면 CloudWatch에 “monitoring”이라는 이름이 들어간 대시보드가 생성되고, 대시보드로 접근 가능한 URL도 출력된다고 한다.[^102]

3.21 대시보드 확인: DynamoDB/Lambda/API Gateway 메트릭과 (예시) 지표 계산 설명[^103]

출력된 URL로 CloudWatch 대시보드에 들어가 확인한다.[^103]

• “monitoring” 대시보드가 생성된 것을 확인한다.[^103]
• DynamoDB의 지표(예: read capacity 관련)가 표시되고[^104]
• Lambda와 API Gateway에 대한 다양한 메트릭도 볼 수 있다고 한다.[^105]
• 발표자는 “직접 대시보드를 구성하지 않아도 이렇게 간단히 만들 수 있다”고 강조한다.[^105]

또한 화면에 표시된 값(예: “280”과 같은 숫자)을 예로 들며, 어떤 값에 60초를 곱하면 300에 가깝게 되는 식의 계산을 언급하며 지표 해석의 예를 든다.[^106]

이메일 구독(알람 수신)을 설정하는 흐름도 함께 보여주며, 구독 신청이 되었음을 말한다.[^107]

3.22 부하 증가 실험: TPS 10 → 15로 늘리고 알람 발생(이메일 수신) 확인[^108]

이제 더 많은 부하를 줘서 프로비저닝된 값(예: 5)보다 더 많은 트래픽이 발생하도록 만든다.[^108]

• 트래픽 스택에서 TPS(=태스크 수)를 10에서 15로 바꾸고 test-ping 스택을 배포한다.[^108]
• ECS 콘솔에서 태스크가 10개에서 15개로 늘어난 것을 확인한다.[^109]
• 대시보드에서도 트래픽 증가에 따라 지표가 더 올라가는 것을 확인한다.[^110]
• 증가 폭을 “기존 대비 0.5배 증가” 같은 표현으로 설명한다.[^111]

DynamoDB에 대해 “프로비저닝된 것보다 더 많은 요청이 발생”하는 상황을 관찰하고[^112] 이 조건이 임계치를 넘으면 알람이 발생하도록 되어 있음을 말한다.[^113]

곧 이메일함을 새로고침해 알람 메일이 도착한 것을 확인한다.[^114]
메일 내용은 “최근 5분(300초) 동안의 read 요청(또는 소비량)이 프로비저닝된 값보다 훨씬 많다”는 취지로 경고를 전달한다는 식으로 설명된다.[^115]
다시 CloudWatch 화면으로 돌아가 데이터가 많이 들어오는 것을 확인한다.[^116]

[!TIP] 테스트 스택으로 운영 스택을 건드리지 않고 부하를 만든다
실제 서비스 스택(url-short)은 유지한 채, 부하 발생용 스택(test-ping)을 분리해 만들면 테스트가 끝났을 때 해당 스택만 제거해 비용/리스크를 줄일 수 있다.[^117]

3.23 정리(삭제) 1: 테스트 트래픽 스택만 cdk destroy로 제거[^118]

테스트가 끝났으므로 트래픽 스택을 제거한다.[^118]

• cdk destroy로 “test-ping” 스택을 삭제한다.[^118]
• 그러면 테스트 트래픽이 사라져, 앞서 알람을 유발하던 과부하 상황이 해소된다고 설명한다.[^119]

이 과정에서 “기존 배포 리소스는 유지하면서 테스트 스택만 별도로 구성/삭제”하는 패턴을 다시 강조한다.[^120]
트래픽 스택 리소스 삭제 완료 메시지를 확인하고[^121] 대시보드(모니터링)는 url-short 스택에 남아 있으므로 계속 존재하는 것도 확인한다.[^122]

트래픽이 줄어드는 모습, 더 이상 트래픽이 들어오지 않는 상태를 관찰할 수 있다고 말한다.[^123]

또한 VPC ID, account/region 같은 환경변수 값을 바꿔 개발/스테이징/프로덕션 등 다양한 환경에 맞춰 재배포할 수 있다는 점을 다시 언급한다.[^124]

3.24 정리(삭제) 2: 전체 스택 삭제(cdk destroy), CDK Toolkit(bootstrap) 정리 주의사항[^125]

모든 테스트와 서비스 배포를 마쳤으니 관련 소스를 모두 삭제한다.[^125]

• 터미널에서 cdk destroy를 수행해 전체 스택 삭제를 진행한다.[^125]
• CDK는 “모든 스택을 삭제할 건지”를 묻고, y를 누르면 url-short과 test-ping 등 스택들이 삭제되는 것을 확인한다.[^126]
• CloudFormation 콘솔에서도 스택이 삭제되는 과정을 확인할 수 있다고 한다.[^127]

이어서 CDK Toolkit(bootstrap으로 만든 리소스)도 필요 없으면 제거할 수 있다고 말한다.[^128]
중요한 주의사항을 덧붙인다.[^129]

• bootstrap으로 만든 S3 버킷에는 샘플/템플릿 파일들이 들어있어서, 버킷 안 파일을 지우지 않으면 스택이 정상 삭제되지 않을 수 있다고 설명한다.[^129]
• 따라서 S3의 해당 파일을 모두 삭제한 뒤, CDK Toolkit 스택 자체 삭제를 요청해 제거할 수 있다고 안내한다.[^130]

3.25 VPC/Cloud9 등 주변 리소스 정리: NAT Gateway → Elastic IP 반납 → VPC 삭제[^131]

데모에서 만든 네트워크 및 개발환경도 삭제한다.[^131]

• VPC에 배포된 NAT Gateway를 먼저 삭제한다.[^131]
• NAT Gateway가 삭제되면 Elastic IP를 해제(반납)할 수 있다.[^132]
• NAT Gateway 삭제가 진행되는 동안 Cloud9 환경도 삭제한다.[^133]
  • Cloud9 대시보드에서 “cdk env” 같은 환경을 선택 후 삭제(confirm 문자열 입력)하는 절차를 수행한다.[^134]
  • Cloud9 환경도 스택으로 배포된 것이므로 삭제 상태로 변하는 것을 확인한다.[^135]
  • 삭제되면 브라우저 세션이 끊겨 접속이 안 되는 것도 확인한다.[^136]
• 이후 Elastic IP 반납과 VPC 삭제까지 수행해 “모든 리소스 삭제”를 완료한다.[^137]

3.26 마무리: 데모에서 무엇을 했는지(발표자 정리) + 추가 자료 안내[^138]

발표자는 데모를 정리한다.[^138]

• 짧은 시간 안에 서버리스 앱을 만들고 테스트/모니터링 환경까지 구성했다.[^138]
• CDK로 DynamoDB 테이블을 만들고 Lambda + API Gateway를 연결해 REST API를 빠르게 만들었다.[^139]
• amazon.com으로 가는 짧은 링크를 만들어 테스트했다.[^140]
• 테스트를 위해 1초마다 요청하는 스크립트를 만들고 Docker 이미지로 만든 뒤, (컨테이너 레지스트리에 등록했다는 언급 포함) ECS/Fargate로 10개 태스크(그리고 확장해 15개 태스크)를 만들어 성능을 측정했다.[^141]
• 이때 cdk-watchful을 이용해 API Gateway/Lambda/DynamoDB 메트릭을 측정할 대시보드를 만들고 테스트했다.[^142]
• 리소스 삭제는 cdk destroy로 트래픽 스택을 먼저 지우고, 이후 url-short 스택도 삭제했다고 정리한다.[^143]
• 결론적으로 AWS CDK를 이용하면 익숙한 개발 언어로 클라우드 서비스를 만들 수 있고, 다양한 스테이지(환경)에 걸쳐 재배포할 수 있다고 말한다.[^144]

마지막으로 CDK에 대한 추가 정보를 얻을 링크들이 있으며, 하단 링크에는 오늘 데모 전 과정 실습 문서가 포함된다고 안내한다.[^145]
참석 감사와 함께, 피드백 요청 및 발표자료/녹화영상 참고, 질문 지속 접수로 마무리한다.[^146]

4. 핵심 통찰[^147]

1. [h CDK는 “새 배포 엔진”이 아니라, 코드로 CloudFormation을 생성해 배포 안정성을 가져오는 개발 프레임워크다.] CDK의 핵심 가치는 익숙한 언어/추상화로 생산성을 높이되, 배포는 CloudFormation의 반복 가능성과 안전성에 기대는 구조라는 점이다.[^22]
2. [h 콘솔/스크립트/순수 템플릿의 페인 포인트(반복, 경합, 의존성 표현)를 CDK가 개발자 친화적으로 완화한다.] 콘솔은 반복에 취약하고, 스크립트는 경합·재시도·오류처리가 부담이며, 템플릿은 학습/의존성 기술 난이도가 있다는 문제 제기가 CDK 도입의 맥락을 만든다.[^14]
3. [h “서비스 스택”과 “테스트 스택” 분리는 운영 안전성과 비용 통제를 동시에 준다.] 트래픽 발생용 스택을 별도(test-ping)로 만들어 부하 테스트 후 그 스택만 destroy하는 패턴을 통해 운영 리소스에 대한 불필요한 변경/비용을 줄인다.[^120]
4. [h 관측성(대시보드/알람)은 데모의 ‘부가 기능’이 아니라 성능 보장을 증명하는 핵심 산출물이다.] 요구사항이 “성공적인 마케팅을 위해 성능 보장”으로 주어졌고, 이를 증명하기 위해 모니터링/알람을 코드로 만든다.[^71]
5. [m 프로비저닝 용량(예: DynamoDB)의 한계는 부하를 ‘일부러’ 넘겨봐야 알람/대응 체계를 검증할 수 있다.] TPS를 10에서 15로 올려 임계 초과를 만들고 이메일 알람 수신까지 확인한다.[^108]

실행 관점에서의 행동 항목:

• CDK 프로젝트에서는 배포 전 cdk diff를 습관화해 변경점을 눈으로 확인한다.[^66]
• 부하 테스트는 운영 스택에 붙이지 말고 별도 스택으로 분리해 만들고 테스트 후 삭제한다.[^118]
• bootstrap(S3 등) 삭제 시 버킷 내 파일을 먼저 비우지 않으면 스택 삭제가 막힐 수 있으므로 정리 순서를 문서화한다.[^129]

5. 헷갈리는 용어 정리[^148]

AWS CDK: 익숙한 개발 언어로 AWS 리소스를 모델링/프로비저닝하는 오픈소스 프레임워크이며, 결과물을 CloudFormation으로 배포한다.[^10]
CloudFormation 스택(Stack): CloudFormation이 리소스를 안전하고 반복 가능하게 생성/업데이트/삭제하는 배포 단위.[^17]
Bootstrap: CDK가 배포 과정에서 사용할 S3 버킷 등 “사전 준비 리소스”를 계정/리전에 생성하는 초기화 단계(cdk bootstrap).[^27]
cdk diff: 현재 코드 변경으로 CloudFormation 템플릿/스택이 어떻게 바뀌는지 배포 전 비교하는 명령.[^66]
cdk deploy: CDK가 합성한 CloudFormation 스택을 실제 AWS에 배포/업데이트하는 명령.[^67]
cdk destroy: 배포된 스택(리소스)을 삭제하는 명령.[^118]
API Gateway: 외부 요청을 받아 Lambda 등을 호출하는 REST API 엔드포인트 역할의 서비스.[^64]
AWS Lambda: 이벤트 기반으로 실행되는 서버리스 함수 컴퓨팅.[^53]
Amazon DynamoDB: 키-값/문서 기반 NoSQL DB로, 데모에서는 id 파티션 키로 URL 매핑을 저장.[^50]
ECS Fargate: 서버 관리 없이 컨테이너 태스크를 실행하는 방식. 데모에서는 트래픽 발생 컨테이너를 여러 개(DesiredCount) 띄워 TPS를 만든다.[^72]
CloudWatch Dashboard/Alarm: 서비스 메트릭을 시각화하고 임계 초과 시 알림(이메일 등)을 보내는 모니터링 기능.[^72]
cdk-watchful: CDK에서 CloudWatch 대시보드/알람 구성을 쉽게 추가하도록 돕는 도구(패키지)로 소개됨.[^95]

---

참고(콘텐츠 정보)[^149]

• 제목: [AWS Builders] AWS Cloud Development Kit을 이용한 Code 기반의 인프라 구축 - 김현수, AWS 솔루션즈 아키텍트[^149]
• 채널: Amazon Web Services Korea[^149]
• 길이: 40분 20초[^149]
• 링크: https://www.youtube.com/watch?v=hOJbhfF0DYQ[^149]

[^1]: @[00:32]~@[03:32] 전반 흐름(소개→CDK 개념/진화→데모→요약)의 문제의식과 답을 발표자가 전개함. [^2]: @[00:59] "aws cdk 는 익숙한 프로그래밍 언어를 사용하여... 모델링 및 프로비저닝" / @[02:53]~@[03:32] CDK 등장 배경과 CloudFormation으로 합성/배포 설명. [^3]: @[04:39]~@[06:16] 가상 시나리오 및 완성 동작 예시 / @[12:14]~@[18:58] DynamoDB+Lambda+API Gateway 생성/배포/테스트. [^4]: @[19:03]~@[33:59] 성능 테스트(트래픽 스택, Fargate) 및 CloudWatch 대시보드/알람, 스택 분리 삭제. [^5]: @[00:32] 강연 순서(소개→시나리오 데모→요약) / @[04:39] 데모 진입. [^6]: @[01:22]~@[03:45] 콘솔→스크립트→CloudFormation→CDK 진화 과정 설명. [^7]: @[00:02]~@[00:49] 인사, 발표 주제, 진행 안내. [^8]: @[00:17]~@[00:28] 질문 남기는 방법 안내. [^9]: @[00:32]~@[00:49] 강연 순서 3단계 제시. [^10]: @[00:59]~@[01:10] AWS CDK 정의(오픈소스 프레임워크, 모델링/프로비저닝). [^11]: @[01:11]~@[01:17] 지원 언어와 개발+인프라 선언 동시 수행. [^12]: @[01:22] "4단계에 걸친 진화 과정" 예고. [^13]: @[01:30]~@[01:37] 콘솔 수동 구성 단계. [^14]: @[01:43] 수십~수백 리소스 반복 구성의 불편. [^15]: @[01:50]~@[02:05] CLI/SDK 스크립트 운영. [^16]: @[02:08]~@[02:17] 재시도/경합 문제. [^17]: @[02:21]~@[02:34] CloudFormation 스택으로 반복 가능 프로비저닝. [^18]: @[02:34]~@[02:43] YAML/JSON 템플릿 학습 부담. [^19]: @[02:43]~@[02:53] 내장 함수는 있으나 의존관계 기술 난이도. [^20]: @[02:53]~@[03:05] CDK 등장, 고수준 객체지향 추상화. [^21]: @[03:05]~@[03:16] 루프/조건문 등 코드 논리 표현. [^22]: @[03:17]~@[03:32] CDK→CloudFormation 템플릿 생성→스택 배포. [^23]: @[03:32]~@[03:38] 익숙한 환경/워크플로에서 인프라 정리, 생산성. [^24]: @[03:45]~@[03:55] 메인 구성요소(스택 등). [^25]: @[03:55]~@[04:00] 생성자 라이브러리 제공. [^26]: @[04:00]~@[04:06] CLI로 스택 관리. [^27]: @[04:08]~@[04:23] bootstrap 설명(S3 버킷 등). [^28]: @[04:23]~@[04:29] diff/deploy/destroy 등 명령 나열. [^29]: @[04:39]~@[04:59] 가상의 요구사항 제시. [^30]: @[04:59]~@[05:15] DevOps 엔지니어로서 bitly 같은 앱을 CDK로 만들자 제안. [^31]: @[05:15]~@[05:32] 긴 URL 저장 및 짧은 URL 반환 흐름. [^32]: @[05:32]~@[05:39] 짧은 URL 호출 시 리다이렉트 흐름. [^33]: @[05:50]~@[06:10] targetUrl로 호출해 short link 생성 시연. [^34]: @[06:10]~@[06:16] short link 호출 시 amazon.com 리다이렉트. [^35]: @[06:22]~@[06:33] Cloud9/싱가폴, 테스트용 VPC 필요. [^36]: @[06:33]~@[06:40] Elastic IP 할당. [^37]: @[06:47]~@[07:09] VPC 위자드, 퍼블릭/프라이빗 서브넷, 이름 cdk test, EIP 입력. [^38]: @[07:16]~@[07:32] Cloud9 환경 생성(이름 cdk env). [^39]: @[07:48]~@[08:55] 테마/폰트 설정. [^40]: @[09:05]~@[09:18] npm으로 aws-cdk 설치. [^41]: @[09:23]~@[09:38] 디렉터리 생성/이동. [^42]: @[09:38]~@[09:49] Python으로 cdk init 및 파일 생성 확인. [^43]: @[10:00]~@[10:16] 가상환경 진입. [^44]: @[10:19]~@[10:39] 필요한 패키지 정의(다이나모DB/EC2/람다/API GW/CloudWatch 등). [^45]: @[10:45]~@[10:56] pip install로 설치. [^46]: @[11:01]~@[11:13] bootstrap 필요 및 실행, CloudFormation 스택으로 S3 생성. [^47]: @[11:31]~@[11:54] app.py에서 스택 파일 구조 확인. [^48]: @[11:54]~@[12:08] F3로 정의 이동, 리소스 추가 방식. [^49]: @[12:14]~@[12:24] dynamodb import 및 생성 시작. [^50]: @[12:30]~@[12:45] 테이블 이름, 파티션 키 id string. [^51]: @[12:45]~@[13:02] cdk deploy로 생성, CloudFormation 통해 생성, 콘솔 확인. [^52]: @[13:11]~@[13:30] lambda 폴더/handler.py 생성. [^53]: @[13:35]~@[13:46] 람다 함수 구조 설명. [^54]: @[13:46]~@[13:55] event/context 설명. [^55]: @[13:57]~@[14:18] 쿼리스트링/패스파라미터 분기, 사용법 출력. [^56]: @[15:03]~@[15:13] 302 리다이렉트 동작. [^57]: @[14:21]~@[14:29] DynamoDB 테이블 값 읽기/환경변수. [^58]: @[14:29]~@[14:51] 8자리 ID 생성 및 DynamoDB 등록, short URL 반환. [^59]: @[14:51]~@[15:13] DynamoDB 조회 후 없으면 에러/있으면 302. [^60]: @[15:20]~@[15:37] 스택으로 돌아가 lambda import/리소스 선언. [^61]: @[15:37]~@[15:58] 함수 이름, Python3.7, 핸들러/코드 경로 지정. [^62]: @[16:00]~@[16:20] grant_read_write_data로 테이블 접근 권한. [^63]: @[16:22]~@[16:35] 환경변수로 테이블 이름 전달. [^64]: @[16:51]~@[17:03] API Gateway 필요 및 import. [^65]: @[17:07]~@[17:18] Lambda 연결, REST API 정의. [^66]: @[17:22]~@[17:33] cdk diff로 변경사항 확인. [^67]: @[17:42]~@[17:58] cdk deploy, 승인 후 업데이트. [^68]: @[18:01]~@[18:12] 배포 완료 후 API endpoint 확인. [^69]: @[18:18]~@[18:26] curl 호출과 query string 설정. [^70]: @[18:34]~@[18:58] 결과 확인 및 리다이렉트 검증. [^71]: @[19:03]~@[19:18] 성능 보장 요구, 테스트/모니터링 대시보드 만들기. [^72]: @[19:26]~@[19:41] 트래픽 스택(Fargate) + CloudWatch 대시보드 구성. [^73]: @[19:58]~@[20:12] curl -i로 302 확인. [^74]: @[20:12]~@[20:29] ping 폴더/스크립트 생성. [^75]: @[20:29]~@[20:40] 1초마다 호출, 여러 개 실행 시 부하 증가. [^76]: @[20:43]~@[21:08] 실행권한 부여 및 동작 테스트. [^77]: @[21:08]~@[21:25] Docker 이미지화 작업 시작, Dockerfile 정의. [^78]: @[21:25]~@[21:32] 셸 스크립트 실행 구성. [^79]: @[21:38]~@[21:47] docker build로 ping 이미지 생성. [^80]: @[21:55]~@[22:18] docker run으로 동작 확인. [^81]: @[22:20]~@[22:26] 여러 개 띄우면 더 많은 부하 가능. [^82]: @[22:31]~@[23:07] traffic.py 생성 및 코드 붙여넣기. [^83]: @[23:07]~@[23:23] VPC 내 ECS 클러스터, Fargate 태스크, ping 이미지 사용. [^84]: @[23:23]~@[23:38] desiredCount로 TPS 조절 설명. [^85]: @[24:07]~@[24:31] 환경변수로 account/region/vpc id 등 재배포 가능하게 설계 강조. [^86]: @[23:51]~@[23:59] os import로 환경변수 사용. [^87]: @[24:48]~@[24:59] VPC ID 복사/붙여넣기 교체. [^88]: @[25:30]~@[25:56] app.py에 트래픽 스택 import/추가, 스택 이름 test-ping. [^89]: @[26:10]~@[26:20] import 누락(ec2)으로 에러, 추가 후 해결. [^90]: @[26:34]~@[26:45] 스택 2개라 배포 대상 지정 필요. [^91]: @[26:49]~@[27:01] *로 두 스택 모두 배포, 승인 후 진행. [^92]: @[27:15]~@[27:28] 환경변수 변경으로 업데이트/재배포 흐름 언급. [^93]: @[27:34]~@[27:47] ECS 클러스터 태스크 10개 확인. [^94]: @[27:53]~@[27:59] DynamoDB 메트릭 상승 확인. [^95]: @[28:08]~@[28:25] CloudWatch 대시보드 추가, cdk-watchful 소개. [^96]: @[28:25]~@[28:32] pip로 cdk-watchful 설치. [^97]: @[28:32]~@[28:39] Watchful import. [^98]: @[28:48]~@[29:16] 대상 리소스(테이블/함수/API 등) 모니터링 코드 추가. [^99]: @[29:16]~@[29:20] 알람 이메일 수신 주소 설정 언급. [^100]: @[29:20]~@[29:28] 수집 대상(예: API/함수/테이블) 언급. [^101]: @[29:28]~@[29:44] 스택 지정해 배포(url-short만). [^102]: @[29:44]~@[29:58] 대시보드 생성 및 접근 URL 출력. [^103]: @[30:01]~@[30:17] 대시보드 접속/생성 확인. [^104]: @[30:17]~@[30:25] DynamoDB 지표 표시 확인. [^105]: @[30:25]~@[30:34] Lambda/API GW 메트릭 확인, 쉽게 대시보드 생성 강조. [^106]: @[30:41]~@[30:54] 280×60=300 언급 등 지표 해석 예. [^107]: @[30:54]~@[31:03] 이메일 구독 설정/신청 확인. [^108]: @[31:09]~@[31:29] TPS 15로 변경, test-ping 배포 계획. [^109]: @[31:29]~@[31:49] ECS 태스크 15개로 증가 확인. [^110]: @[31:49]~@[31:55] 대시보드 지표 증가 확인. [^111]: @[31:59]~@[32:04] 0.5배 증가 표현. [^112]: @[32:04]~@[32:13] 프로비저닝보다 많은 요청 발생 관찰. [^113]: @[32:21]~@[32:26] 임계 초과 시 알람 발생 설명. [^114]: @[32:35]~@[32:48] 이메일 수신함 갱신, 알람 메일 도착 확인. [^115]: @[32:48]~@[33:02] 5분(300초) 동안 프로비저닝보다 많이 들어왔다는 경고 내용. [^116]: @[33:08]~@[33:19] CloudWatch 화면에서 데이터 유입 확인. [^117]: @[33:46]~@[33:59] 테스트 스택 별도 구성/제거 패턴 설명. [^118]: @[33:19]~@[33:33] cdk destroy로 test-ping 삭제. [^119]: @[33:34]~@[33:46] 트래픽 중단, 문제 해결 설명. [^120]: @[33:46]~@[33:59] 테스트 스택만 제거해 테스트 작업 분리 강조. [^121]: @[34:05] 리소스 삭제 완료 확인. [^122]: @[34:13]~@[34:20] 대시보드는 url-short 스택에 남아있음 확인. [^123]: @[34:20]~@[34:29] 트래픽 감소/없음 관찰. [^124]: @[34:37]~@[34:52] 환경 값 변경으로 다양한 환경 재배포 가능. [^125]: @[35:00]~@[35:15] 전체 소스/스택 삭제 시작. [^126]: @[35:26]~@[35:36] 모든 스택 삭제 확인(y). [^127]: @[35:40]~@[35:49] CloudFormation에서 삭제 과정 확인. [^128]: @[35:49]~@[35:58] CDK Toolkit도 필요 없으면 삭제 가능. [^129]: @[35:58]~@[36:10] bootstrap S3 버킷 파일 미삭제 시 스택 삭제 불가 주의. [^130]: @[36:10]~@[36:21] S3 파일 삭제 후 toolkit 스택 삭제. [^131]: @[36:31]~@[36:40] VPC NAT Gateway 삭제. [^132]: @[36:40]~@[36:45] NAT 삭제 후 Elastic IP 해제 가능. [^133]: @[36:46]~@[37:04] NAT 삭제 중 Cloud9 삭제 진행. [^134]: @[37:04]~@[37:16] Cloud9 환경 선택 후 delete 절차. [^135]: @[37:17]~@[37:26] Cloud9도 스택으로 배포되어 삭제 상태 확인. [^136]: @[37:26]~@[37:35] 삭제로 브라우저 접속 불가. [^137]: @[37:35]~@[37:58] EIP 반납, VPC 삭제까지 마무리. [^138]: @[38:10]~@[38:21] 강의 요약: 서버리스 앱 + 테스트/모니터링 구성. [^139]: @[38:21]~@[38:30] DynamoDB, Lambda, API GW로 REST API 생성. [^140]: @[38:30]~@[38:36] 짧은 링크 생성/테스트. [^141]: @[38:36]~@[38:58] 1초마다 요청 스크립트, Docker 이미지, (레지스트리 언급), ECS/Fargate 태스크 10/15로 측정. [^142]: @[38:58]~@[39:07] cdk-watchful로 API GW/Lambda/DynamoDB 지표 대시보드 구성. [^143]: @[39:10]~@[39:20] cdk destroy로 트래픽 스택 삭제 및 url-short 스택 삭제. [^144]: @[39:21]~@[39:35] 익숙한 언어로 만들고 다양한 스테이지 재배포 가능. [^145]: @[39:35]~@[39:45] 추가 정보 링크 및 실습 문서 안내. [^146]: @[39:49]~@[40:18] 감사, 피드백 요청, 발표자료/녹화영상 안내, 질문 요청. [^147]: @[01:22]~@[03:32] 진화/배포 구조 / @[33:46]~@[34:52] 스택 분리/재배포 / @[31:09]~@[33:02] 알람 검증 근거. [^148]: @[00:59]~@[04:29] 용어(bootstrap/diff/deploy/destroy)와 서비스 구성요소 설명 구간 전반. [^149]: 사용자가 제공한 메타데이터(제목/채널/길이/링크).