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

description: |-

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

[? 질문] AWS에서 클라우드 네이티브 컨테이너 워크로드를 만들 때, 어떤 서비스 조합(오케스트레이션/컴퓨팅/이미지 저장소)을 선택하고 어떤 흐름으로 구축해야 하는가[^2]
[= 답] 오케스트레이션은 Amazon ECS(AWS 네이티브) 또는 Amazon EKS(Kubernetes) 중 선택하고, 컨테이너 실행 환경(데이터 플레인)은 EC2 또는 서버리스 엔진인 AWS Fargate(또는 혼합)로 구성하며, 컨테이너 이미지는 Amazon ECR에 저장한다. 이후 ECS 클러스터 → 작업(Task) 정의 → 서비스(Service) 배포 순으로 워크로드를 구성하고, 외부 트래픽은 ALB로 받아 패스 기반 라우팅 등으로 서비스에 전달하며, 관측(메트릭/로그)은 CloudWatch 등으로 모니터링한다.[^3]

[? 질문] 인프라를 콘솔에서 클릭으로 만들지 않고 **IaC(Infrastructure as Code)**로 관리하면 구체적으로 무엇이 좋아지는가[^4]
[= 답] 인프라를 소스 코드로 관리하면 변경점이 명확히 추적(버전 관리)되고, 문제가 생기면 이전 상태로 롤백이 비교적 쉬우며, 동일한 코드로 동일 환경을 여러 개 재현(provisioning)할 수 있다.[^5]

[? 질문] AWS IaC 도구 중 AWS CDK로 컨테이너 환경을 “뚝딱” 만드는 실제 구현은 어떤 식으로 진행되는가(데모의 핵심 단계는 무엇인가)[^6]
[= 답] TypeScript 기반 CDK 프로젝트를 생성한 뒤, (1) CDK로 ECR 리포지토리를 만들고 배포한 다음, (2) 로컬에서 컨테이너 이미지를 빌드/태그하여 ECR에 푸시하고, (3) CDK의 고수준 **ECS 패턴(=Fargate + ALB 포함)**을 사용해 ECS 서비스를 코드로 정의하여 배포한다. 배포 전후로 cdk diff로 변경사항을 확인하고, 배포는 cdk deploy로 수행하며, 최종적으로 서비스 URL에서 컨테이너가 정상 제공됨을 확인한다.[^7]

2. 큰 그림[^8]

이 콘텐츠는 AWS 환경에서 컨테이너 워크로드를 구성할 때 필요한 서비스 포트폴리오(ECS/EKS, EC2/Fargate, ECR)를 먼저 정리하고, IaC 도구인 AWS CDK의 개념/구성요소/라이브러리 레벨을 설명한 뒤, 실제로 CDK로 ECR + ECS(Fargate) + ALB 기반의 간단한 컨테이너 서비스를 단계별로 구축하는 데모 과정을 따라간다.[^9] 궁극적으로 “콘솔/CLI로 일일이 만들던 인프라를 코드로 빠르고 간결하게 만들고, 변경사항을 더 쉽게 관리하는 방식”을 보여주는 것이 목적이다.[^10]

• 컨테이너 워크로드 구성의 표준 흐름은 오케스트레이션 선택(ECS/EKS) → 실행 환경 선택(EC2/Fargate/혼합) → 이미지 저장소(ECR) → 클러스터/태스크/서비스로 배포 구조를 잡는 것이다.[^3]
• AWS CDK는 익숙한 언어(TypeScript 등)로 인프라를 모델링하고, 라이브러리/CLI를 통해 배포까지 연결하는 IaC 프레임워크이며, CloudFormation과 매핑되는 스택 단위로 배포된다.[^11]
• 데모는 샘플 코드 기반으로, CDK에서 발생하는 에러(의존성 누락, 타입/스택 지정 등)를 해결해가며 cdk list/diff/deploy로 실제 리소스가 배포되고 서비스 URL에서 결과를 확인하는 흐름으로 진행된다.[^7]

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

3.1 세션 소개와 전체 진행 흐름(컨테이너 서비스 → 데모 → CDK 설명 → 구현 확인)[^13]

발표자는 AWS Innovate 행사(“AWS Innovate - 현대적 앱 특집”)에 참석한 청중에게 인사를 하고, 자신을 AWS 솔루션스 아키텍트(김주현)라고 소개한다.[^14] 오늘 세션의 제목은 “AWS IaC 툴로 클라우드 네이티브한 컨테이너 환경 뚝딱! 개발하기”이며, 큰 흐름은 다음과 같이 진행된다고 안내한다.[^15]

1. AWS가 제공하는 컨테이너 관련 서비스들을 먼저 살펴본다.[^16]
2. 컨테이너 워크로드를 빌드하는 데모 영상을 중심으로 설명하는데, 데모의 주요 서비스는 Amazon ECS와 AWS CDK이다.[^17]
3. 따라서 ECS와 CDK를 각각 설명한 후, 데모에서 구축할 워크로드(아키텍처/코드)를 확인하고, 데모 영상을 통해 단계별 구현 과정을 확인한다.[^18]

3.2 AWS 컨테이너 서비스 포트폴리오: 오케스트레이션, 실행 환경(데이터 플레인), 이미지 저장소[^19]

발표자는 “AWS 위에 컨테이너 워크로드를 구축한다”고 가정하고, 그때 필요한 선택지를 3단으로 정리한다.[^20]

3.2.1 오케스트레이션 선택: ECS vs EKS[^21]

컨테이너를 운영하려면 오케스트레이션 툴이 필요하며, AWS는 크게 두 가지 방향을 제공한다고 설명한다.[^22]

• AWS 네이티브 컨테이너 오케스트레이션: Amazon ECS[^22]
• Kubernetes 기반: Amazon EKS[^22]

즉, “어떤 서비스를 사용할지”를 먼저 결정하는 것이 출발점이라는 흐름이다.[^23]

3.2.2 컨테이너가 실제로 올라가는 실행 환경: EC2 vs Fargate(또는 혼합)[^24]

오케스트레이션을 고른 다음에는 컨테이너가 실제로 동작할 환경(워크로드가 올라가는 데이터 플레인)을 구축해야 한다고 말한다.[^25]

• 컨테이너 인스턴스(직접 노드를 운영하는 형태): Amazon EC2 선택 가능[^26]
• 서버리스 컨테이너 컴퓨팅 엔진: AWS Fargate 선택 가능[^26]
• 필요에 따라 EC2와 Fargate를 함께(혼합) 사용하는 구성도 가능하다고 언급한다.[^27]

3.2.3 컨테이너 이미지 저장소: ECR[^28]

발표자는 “컨테이너는 컨테이너 이미지가 실행된 상태”라고 정의를 보강한다.[^29] 컨테이너 이미지는 컨테이너 실행에 필요한 파일과 설정값 등을 묶어 놓은 것이고, 이 이미지를 저장할 공간이 필요하므로 AWS에서는 **Amazon ECR(Elastic Container Registry)**을 제공한다고 설명한다.[^30]

3.3 Amazon ECS의 아키텍처와 핵심 구성요소: 클러스터, 태스크, 서비스[^31]

이제 본격적으로 컨테이너 오케스트레이션 서비스인 Amazon ECS를 설명한다.[^32]

3.3.1 ECS의 컨트롤 플레인/데이터 플레인 개념[^33]

발표자는 ECS를 높은 수준에서 보면 “클러스터 관리자가 명령을 내리면, ECS 컨트롤 플레인이 그 명령을 받아 데이터 플레인에 전달”하는 형태라고 설명한다.[^34]
여기서 데이터 플레인은 사용자가 정의한 컨테이너가 실제 배포되는 곳이며, 앞서 말했듯 EC2 또는 Fargate 또는 혼합 형태로 구성될 수 있다고 연결한다.[^35]

3.3.2 ECS의 3가지 핵심 구성요소[^36]

ECS 구성요소는 크게 3가지라고 정리한다.[^37]

1. ECS 클러스터: 작업이 실행되는 논리적인 그룹[^38]
2. ECS 태스크(Task): ECS 환경에서 “최소 실행 단위”이며 하나 또는 여러 컨테이너 묶음[^39]
3. ECS 서비스(Service): ECS 위에서 태스크를 “어떻게 실행/유지”할지를 담당[^40]

특히 서비스의 역할을 오케스트레이션의 기본 목표와 연결한다.[^41] 사용자가 “태스크 3개를 배포하세요”처럼 원하는 상태(desired state)를 정의하면, ECS 서비스가 그 desired state(예: 3개)를 유지하기 위해 지속적으로 관리한다고 설명한다.[^42]

[!IMPORTANT] ECS 서비스가 하는 일(발표자가 강조한 오케스트레이션의 기본) 사용자가 원하는 태스크 개수(Desired state)를 정의하면, 서비스가 이를 계속 맞추도록 운영한다(예: 3개를 항상 유지).[^42]

3.4 ECS 클러스터 생성 방식: 템플릿 선택과 워커 노드(EC2 기반 예시)[^43]

발표자는 “ECS 클러스터는 작업이 실행되는 논리적 그룹”이므로, 워크로드를 구축할 때 가장 처음 하는 일이 ECS 클러스터를 구축하는 것이라고 말한다.[^44]

클러스터 구축은 화면에 보이는 “세 가지 템플릿 중 하나를 선택”해서 시작할 수 있다고 안내한다.[^45]
그중 예시로 “EC2 Linux + Networking(리눅스 OS 기반 + 네트워킹)” 같은 템플릿을 선택하면, 클러스터 안에 리눅스 기반 **워커 노드(EC2 인스턴스)**가 배포되고 컨트롤 플레인에서 들어온 명령이 클러스터에서 실행된다는 식으로 설명한다.[^46]

3.5 ECS 태스크(Task) 정의: 네트워크/스토리지/IAM/컴퓨팅/이미지/리소스 경합 등[^47]

발표자는 ECS 태스크를 “클러스터에서 최소 실행 단위”라고 다시 잡고, 태스크 안에서 무엇을 설정하는지 구체 항목을 열거한다.[^48]

• 태스크 내 설정 가능 요소: 네트워크, 스토리지, 파라미터, IAM 역할, 컴퓨팅 리소스 등[^49]
• 태스크는 “작업 정의(task definition)” 기반으로 클러스터에 배포되며, 이때:
  • 배포 타입을 EC2로 할지 / Fargate로 할지[^50]
  • 어떤 컨테이너 이미지를 사용할지[^50]
  • 필요하면 태스크에 IAM Role을 부여할지 등을 설정한다고 설명한다.[^51]

3.5.1 태스크에 IAM Role을 부여하는 이유(구체 예시: S3 접근)[^52]

발표자는 태스크에 IAM Role을 부여해야 하는 상황 예시로, “특정 태스크가 Amazon S3의 오브젝트를 액션(접근/처리)해야 한다면 그 태스크에 S3 권한을 부여하는 것이 이해가 될 것”이라고 말한다.[^53] 즉, 애플리케이션 단위 권한을 태스크 역할로 분리해 부여하는 맥락이다.[^53]

3.5.2 클러스터 자원 한계와 리소스 경합, 태스크 크기 설정의 필요성[^54]

태스크는 “하나의 클러스터 울타리 안”에 속하므로, 클러스터가 가진 자원 이상으로 CPU나 메모리를 사용할 수 없다고 설명한다.[^55] 또한 다수의 태스크가 클러스터 안에 있으면 리소스 경합이 발생할 수 있다고 한다.[^56] 그래서 워크로드가 어느 정도 성숙하면 각 태스크의 크기(리소스 설정)를 적절히 지정하는 것이 필요할 수 있다고 언급한다.[^57]

3.5.3 통합 기능(모니터링/로그 라우팅)과 태스크 정의 시점 설정, 컨테이너 수 제한[^58]

발표자는 AWS에서 제공하는 다른 관련 서비스와의 통합 설정도 태스크 정의 단계에서 수행할 수 있다고 말한다.[^59] 예로 “로그 라우터 기능인 FireLens” 등을 언급한다.[^59]
그리고 “하나의 태스크당 최대 10개 컨테이너까지 정의할 수 있다”고 구체 제한도 제시한다.[^60]

3.6 ECS 서비스(Service) 구성: 배포 형태, 배치, 배포 컨트롤, 탄력성(ELB/오토스케일링)[^61]

발표자는 클러스터를 만들고 태스크를 정의한 다음, “클러스터 위에 태스크를 실제로 배포”하려면 ECS 서비스를 구성해야 한다고 설명한다.[^62]

ECS 서비스에서 선택/설정할 수 있는 항목으로 다음을 든다.[^63]

• 배포 형태:
  • 레플리카(Replica) 형태로 배포할지[^64]
  • 각 노드마다 에이전트처럼 배포하는 데몬(Daemon) 형태로 배포할지[^64]
• 태스크 배치 전략을 선택할 수 있음[^65]
• 배포 컨트롤(배포 유형): Rolling update, Blue/Green, 또는 외부 배포 컨트롤러 등 선택 가능하다고 설명한다.[^66]
• 워크로드 탄력성 장치:
  • Elastic Load Balancer(ELB)[^67]
  • Service Auto Scaling[^67]

3.7 전체 워크로드 흐름 예시: CI/CD, ECR 저장, ALB 진입점, 패스 기반 라우팅, 모니터링/서비스 메시[^68]

앞서 설명한 것을 “하나의 흐름”으로 정리하면서, 애플리케이션 변경부터 사용자 요청 처리까지 큰 그림을 예시로 설명한다.[^69]

1. 개발자가 애플리케이션 코드를 작성하고 변경이 생기면 Git을 통해 AWS CodeCommit 등에 업로드된다.[^70]
2. 미리 구축한 파이프라인에 따라 CodePipeline이 진행되며, CodeBuild로 빌드 작업을 하고 CodeDeploy로 배포된다고 말한다.[^71]
3. 컨테이너라이징된 이미지는 Amazon ECR에 저장된다.[^72]
4. 엔드유저 트래픽은 AWS ALB 같은 엔트리 포인트로 들어오고, 패스 기반 라우팅을 통해 특정 서비스로 전달된 뒤 결과가 다시 사용자에게 리턴되는 형태라고 설명한다.[^73]
5. 서비스(컨테이너 애플리케이션)는 ECS 클러스터에서 Fargate 및/또는 컨테이너 인스턴스(EC2) 위에 올라가며, 이 ECS 및 여러 자원을 AWS IaC 툴로 프로비저닝할 수 있다고 연결한다.[^74]
6. 서비스 간 트래픽 모니터링/관리는 AWS App Mesh를 통해 할 수 있다고 언급한다.[^75]
7. 인프라 및 애플리케이션에서 발생하는 메트릭/로그 값은 Amazon CloudWatch로 라우팅하여 모니터링을 수행할 수 있다고 정리한다.[^76]

[!NOTE] 발표자가 제시한 “운영에 필요한 주변 요소” 단순 배포뿐 아니라 트래픽 진입점(ALB), 서비스 간 트래픽 관리(App Mesh), 관측(CloudWatch)까지 이어지는 운영 구성을 염두에 둔다.[^73]

3.8 IaC 일반론: IaC의 정의와 장점, AWS 네이티브/서드파티 옵션[^77]

컨테이너 서비스 설명 후, 이제 IaC 도구인 AWS CDK 설명으로 넘어가기 전에 “원론적인 이야기”로 IaC의 장점을 먼저 짚는다.[^78]

3.8.1 IaC의 의미(정의)[^79]

발표자는 IaC를 “코드로 인프라 구성요소를 생성, 구성, 배치하기 위한 코드 작성 방식”이라고 정의한다.[^80]

3.8.2 IaC로 인프라를 소스 코드로 관리할 때의 이점[^81]

소스 코드로 인프라를 관리하면 얻는 이점으로 다음을 든다.[^82]

• 버전이 변경되었을 때 정확한 변경분을 파악할 수 있음[^82]
• 새 버전에 문제가 생기면 이전 인프라 환경으로 롤백이 비교적 쉬움[^83]
• 같은 코드와 컴파일/구성 파일만 있으면 동일한 환경을 여러 개 만들 수 있음[^84]

3.8.3 AWS 네이티브 IaC와 서드파티 IaC 예시[^85]

IaC 방식에서 AWS 네이티브 옵션으로 AWS CloudFormation과 AWS CDK가 있고, 서드파티로는 Terraform, Pulumi 등이 있다고 소개한다.[^86] 본 세션은 다양한 IaC 중 AWS CDK에 초점을 맞춘다고 명확히 한다.[^87]

3.9 AWS CDK 개념: 무엇이며, 어떤 언어를 지원하고, 무엇이 핵심 구성요소인가[^88]

발표자는 AWS CDK를 “익숙한 프로그래밍 언어로 클라우드 인프라를 모델링하고 프로비저닝할 수 있는 오픈소스 소프트웨어 개발 프레임워크”라고 설명한다.[^89] 앞서 언급한 IaC의 장점들이 CDK 특징으로 귀결된다고도 말한다.[^90]

3.9.1 CDK는 ‘익숙한 언어’로 작성 + 개발 편의(자동완성 등)[^91]

화면 예시로 TypeScript로 작성한 인프라 코드가 나오며, 자동완성 및 인라인 지원 도구 등 “서포트 툴”이 있어 가이드를 따라 쉽게 시작할 수 있다고 설명한다.[^92]

CDK 지원 언어로는 다음을 나열한다.[^93]

• TypeScript[^93]
• JavaScript[^93]
• Python[^93]
• Java[^93]
• C#(시샵)[^93]

또한 이런 언어로 “코드 작성뿐 아니라 인프라 선언”을 동시에 수행할 수 있다고 말한다.[^94]

3.9.2 CDK 주요 컴포넌트 3가지: 프레임워크, 라이브러리, CLI[^95]

AWS CDK의 주요 컴포넌트는 3가지라고 정리한다.[^96]

1. 프로젝트 시작 시 제공되는 코어 프레임워크[^96]
2. 코드로 프로비저닝하는 인프라 관련 라이브러리[^97]
3. CDK 애플리케이션과 상호작용하는 AWS CDK CLI[^98]

3.10 CDK의 단위 체계: Construct, Stack, App, Environment(배포 범위/라이프사이클 분리)[^99]

발표자는 CDK 프레임워크를 사용해 “하나 이상의 스택이 포함된 애플리케이션”을 만들고 구성할 수 있다고 말한다.[^100]

• Construct(컨스트럭트): CDK 애플리케이션의 빌딩 블록(가장 작은 단위)[^101]
• Stack(스택): Construct들이 모여 프로비저닝되는 “배포 최소 단위”[^102]
  • 스택은 여러 리소스를 포함하며 CloudFormation 원시안과 매핑되는 단위라고 설명한다.[^103]
• 인프라를 프로비저닝할 때, 서로 다른 라이프사이클을 가진 리소스들은 서로 다른 스택에 두는 것이 모범 사례라는 취지로 말한다.[^104]
• 여러 스택이 번들로 묶여 CDK App이 되고, Environment는 실제 프로비저닝되는 위치(계정/리전 맥락)를 의미한다고 설명한다.[^105]

[!TIP] 스택 분리 원칙(발표자의 운영 관점 포인트) 라이프사이클이 다른 리소스는 스택을 분리해 배포/변경 단위를 나누는 것이 바람직하다는 관점을 제시한다.[^104]

3.11 CDK 라이브러리 레벨: L1(Cfn*), L2, L3(패턴) + 예시(ECS Fargate + ALB 번들)[^106]

다음 구성요소로 “AWS Construct Library”를 소개한다. 이는 AWS의 특정 서비스를 생성하기 위해 만들어진 라이브러리이며, 필요한 디펜던시만 설치해 쓸 수 있다고 말한다.[^107]

Construct Library는 3가지 레벨로 나뉜다고 설명한다.[^108]

3.11.1 레벨 1(L1): CloudFormation과 거의 동일한 저수준(Cfn*)[^109]

• CloudFormation을 직접 작성하는 것과 거의 똑같은 저수준 Construct[^110]
• 이름 앞에 Cfn이 붙는 특징을 가진다고 언급한다.[^111]

3.11.2 레벨 2(L2): 더 추상화된 고수준 + 정제된 API + 부가 속성/메서드[^112]

레벨 2는 더 추상화된 고수준 Construct이며, 잘 정제된 API로 L1 대비 간결하게 쓸 수 있다고 한다.[^113]
예로 S3 버킷 클래스는 버킷에 라이프사이클 규칙을 적용하는 등 추가 속성/메서드를 포함한다고 설명한다.[^114]

3.11.3 레벨 3(L3) 패턴(Pattern): 여러 리소스를 묶은 아키텍처 번들[^115]

“패턴”이라 불리는 레벨 3 Construct는 여러 리소스로 구성된 아키텍처를 담고 있다고 말한다.[^116]
예시로 ECS 클러스터(Fargate) + ALB가 포함된 번들을 언급한다.[^117] 화면의 CDK docs에 있는 ECS Fargate 관련 모듈이 방금 설명한 내용을 담고 있다고 연결한다.[^118]

또한 Construct Library는 사용 편의성과 빠른 반복에 적합하도록, 모범사례 및 다양한 고객 사례 기반으로 만들어졌다는 취지로 설명한다.[^119]

3.12 CDK CLI로 하는 일: init, install, build, list, synth, diff, deploy(변경 검수 후 배포)[^120]

발표자는 마지막 주요 컴포넌트인 AWS CDK CLI가 CDK 애플리케이션과 상호작용할 때 사용된다고 말하며, 실제 작업 흐름을 비교적 구체적으로 나열한다.[^121]

• 프로젝트 시작: cdk init으로 새 프로젝트 생성[^122]
• (TypeScript 예시) 필요한 Construct 라이브러리는 npm install로 설치[^123]
• 코드 작성 후 npm run build로 빌드[^124]
• cdk list로 현재 스택 리스트 확인[^125]
• cdk synth로 CloudFormation 템플릿과 어떻게 매핑되는지 확인[^126]
• 배포: cdk deploy로 프로비저닝[^127]
• 변경 반영 시: 코드를 수정한 뒤 cdk diff로 기존 스택과 현재 상태의 변경사항을 확인(검수)하고[^128]
• 검수 후 다시 cdk deploy로 변경을 프로모션(반영)한다고 설명한다.[^129]

[!IMPORTANT] 발표자가 제시한 “CDK 배포 전 체크” 습관 인프라를 바로 배포하기보다 cdk diff로 변경사항을 확인하고, 검수 후 cdk deploy로 반영하는 흐름을 권장한다.[^128]

3.13 데모에서 구축할 아키텍처/코드 감 잡기: ‘ECS 패턴’은 Fargate+ALB를 포함한다[^130]

발표자는 이제 “실제로 구축한 아키텍처”를 살펴보자고 전환한다.[^131]
방금 배운 내용을 적용해 보면, 어떤 구성요소가 “패턴”인지 추정할 수 있다고 말한다.[^132]

• “ECS 뒤에 pattern이 붙으니 레벨 3 Construct(패턴)일 것”이라고 추정할 수 있다고 설명[^133]
• 패턴 설명을 통해 “해당 패턴이 ALB와 Fargate로 구성”되어 있음을 짐작할 수 있다고 말한다.[^134]
• 그리고 클러스터 정보, ECS 태스크에 어떤 이미지를 매핑할지 등을 작성하는 “간단한 코드”로 파악될 것이라고 덧붙인다.[^135]

또한 데모는 AWS 샘플 코드를 기반으로 만들어졌다고 말한다.[^136] 이 샘플 코드는 CDK 기반으로 ECS 컨테이너 워크로드를 구축할 때 필요한 “대부분 사례”를 담고 있다고 소개한다.[^137]

3.14 데모 Step-by-step ①: CDK 프로젝트 생성과 기본 명령(설명 파일, watch, diff, deploy)[^138]

데모는 다음과 같이 시작한다.[^139]

1. 빈 디렉터리를 만들고, cdk init으로 TypeScript를 사용하는 새 프로젝트를 생성한다.[^140]
2. 프로젝트 생성 시 나오는 설명 중, cdk.json 파일이 CDK 애플리케이션이 어떻게 실행되는지 설명하는 파일이라고 짚는다.[^141]
3. 컴파일 변환 과정을 보기 위해 npm run build --watch 같은 빌드 watch 명령을 사용한다는 흐름을 언급한다.[^142]
4. cdk synth로 CloudFormation 템플릿과의 싱크(매핑)를 확인하고, cdk diff로 배포 시작점과 현재 상태의 차이를 파악할 수 있다고 말한다.[^143]
5. 리소스 프로비저닝은 cdk deploy로 한다고 재확인한다.[^144]

이후 비주얼 스튜디오를 열고, cdk.json을 확인한 다음 엔트리 포인트의 빈 폴더로 이동해 프로젝트 구조를 살펴본다.[^145] 해당 파일에서 CDK 애플리케이션/스택의 이름과 위치를 확인할 수 있다고 설명한다.[^146] 그리고 lib 폴더로 이동하면 “스택을 정의하는 코드를 여기 작성하라”는 안내가 있다고 말한다.[^147]

3.15 데모 Step-by-step ②: CDK로 ECR 리포지토리 생성(의존성 추가 → 배포 → 콘솔에서 확인)[^148]

발표자는 먼저 “컨테이너 이미지 저장소인 Amazon ECR을 CDK로 생성”하겠다고 한다.[^149]

1. 예제(샘플) 코드를 복사/붙여넣기 한다.[^150]
2. 그러면 코드에서 빨간 밑줄(에러)이 뜨는데, 이는 프로젝트에 **ECR Construct 라이브러리(디펜던시)**가 없기 때문이라고 설명한다.[^151]
3. 따라서 package.json에 해당 패키지 이름을 추가하고, CDK 패키지 버전과 같은 숫자(버전)를 맞춰 작성한다.[^152]
4. 터미널에서 npm install로 패키지를 설치한다.[^153]
5. 설치 후 import 구문으로 ECR을 명시하면 빨간 밑줄이 사라진다고 안내한다.[^154]
6. ECR 리포지토리 이름을 지정하는 작업을 하고, 자동완성 서포트 툴을 참고해 데모 레포 이름으로 지정한다.[^155]

다음으로 배포를 진행한다.[^156]

• cdk list로 배포할 스택 리스트를 확인한 뒤[^157]
• cdk deploy로 해당 스택을 배포한다.[^158]
• 배포 후 AWS CloudFormation 및 ECR 콘솔에서 리포지토리가 실제로 배포된 것을 확인할 수 있다고 말한다.[^159]

3.16 데모 Step-by-step ③: 컨테이너 이미지 빌드/태그 후 ECR로 푸시(“푸시 커맨드” 절차)[^160]

이제 “원격에 있는 코드(샘플)”를 복사하고, 그 안의 파일을 컨테이너라이징하는 작업을 수행한다고 말한다.[^161]
이어서 “push command”를 클릭(또는 수행)하여 컨테이너 이미지를 푸시하는 절차를 진행한다.[^162]

발표자가 묘사한 푸시 절차는 다음 흐름이다.[^163]

• ECR 리포지토리 URI(또는 리포지토리 정보)를 기준으로[^164]
• 코드가 있는 위치에서 컨테이너 이미지를 빌드하고[^165]
• 태그 작업을 수행한 후[^165]
• 데모 레포(ECR)에 해당 이미지를 푸시한다.[^166]

3.17 데모 Step-by-step ④: 레벨 3 패턴으로 ECS(Fargate+ALB) 구축, 에러 4개 해결(스택 타입/의존성/import/코드 제거)[^167]

다음 단계는 “레벨 3 Construct 전체 라이브러리(=패턴)”를 사용해 ECS 환경을 구축하는 것이다.[^168]
마찬가지로 샘플 코드를 복사해 붙여넣는다.[^169]

그러자 “총 4개의 에러 코드”가 보인다고 말하면서, 이를 해결하는 과정을 보여준다.[^170]

1. 배포 타깃이 “해당 스택”이므로(타입/대상 문제), 스택을 (표현상) “dc로 변경”한다고 말한다(스택 관련 타입/대상 조정 맥락).[^171]
2. ECS 패턴도 ECR 때처럼 디펜던시를 추가해야 하므로, 의존성 추가 작업으로 에러를 제거하겠다고 한다.[^172]
3. 설치 후 모듈을 import하면 에러가 없어진다고 한다.[^173]
4. ECS 모듈도 import한다고 명시한다.[^174]

그리고 데모 요구사항에 맞춰 불필요한 코드 일부를 제거한다.[^175]

• 데모에서는 클러스터명을 별도 지정하지 않으므로 “클러스터 코드 부분”을 제거[^176]
• 로드밸런서 헬스체크가 루트 경로에서 수행되므로 관련 코드도 제거[^177]

마지막으로, 태스크에 매핑되는 컨테이너 이미지는 앞서 ECR에 올린 이미지를 사용할 것이므로, 위에 명시한 리포지토리를 매핑해 준다고 설명한다.[^178]

3.18 데모 Step-by-step ⑤: cdk diff로 변경 확인 → cdk deploy → URL/콘솔/CFN 템플릿 비교로 결과 확인[^179]

모든 코드가 완성되면 배포 전 단계로 돌아가, “배포 전 시점과 현재 상태의 차이”를 cdk diff로 확인한다.[^180]
이후 cdk deploy를 통해 리소스를 프로비저닝한다.[^181]

배포가 진행되면 CloudFormation도 업데이트 상태로 변경된다고 언급하고,[^182] 몇 분 후 리소스가 완전히 배포되면 출력(Outputs)에서 결과물을 확인할 수 있다고 말한다.[^183]

3.18.1 서비스 URL 접속으로 애플리케이션 동작 확인(Flask 이미지)[^184]

서비스 URL로 들어가면, 앞서 빌드한 Flask의 이미지가 컨테이너로 올라간 것을 확인할 수 있다고 말한다.[^185]

3.18.2 ECS 콘솔에서 Fargate 형태로 서비스 프로비저닝 확인[^186]

ECS 클러스터로 가보면 Fargate 형태로 서비스가 프로비저닝된 것을 확인할 수 있다고 한다.[^187]

3.18.3 CloudFormation 템플릿 길이 비교: (매우 긴 코드) vs CDK 25줄[^188]

발표자는 CloudFormation 템플릿을 직접 보면 “굉장히 긴 코드”인데, CDK에서는 “25줄”로 완성된 것을 확인할 수 있다고 비교 포인트를 제시한다.[^189]
이는 CDK의 추상화(특히 패턴 사용)가 얼마나 간결한 선언으로 많은 리소스를 만들어주는지 강조하려는 맥락으로 읽힌다.[^189]

3.19 데모 결론: 10분 작업으로 ECR + Fargate + ALB 포함 ECS 클러스터를 CDK로 만들었다[^190]

발표자는 “10분간의 작업”을 통해 다음을 했다고 정리한다.[^191]

• Amazon ECR에 컨테이너 이미지를 저장했고[^192]
• AWS Fargate 기반으로 태스크 및 ALB가 포함된 **ECS 클러스터(워크로드)**를 생성했다.[^193]

또한 AWS 관리 콘솔이나 CLI로 작업하는 것보다 훨씬 간결하고, 변경사항도 손쉽게 캐치할 수 있다는 점을 파악했을 것이라고 말한다.[^194]

3.20 다음 단계 제안: CI/CD 파이프라인 구축과 메트릭/로그 모니터링 메커니즘 필요[^195]

간단한 컨테이너 워크로드를 구축했다면, 다음으로는 애플리케이션 코드가 변경될 때 이를 손쉽게 반영할 수 있는 CI/CD 파이프라인을 구축해야 할 것이라고 말한다.[^196]
또한 인프라 환경이 정상 운영 중인지 확인하기 위해 메트릭과 로그를 확인하는 메커니즘도 필요하다고 강조한다.[^197]
이 내용은 데모 시작점에 언급했던 샘플 코드를 통해 확인하면 좋겠다고 안내한다.[^198]

3.21 마무리: 행사 안내, 기술 백서(QR), 교육 자료, 피드백 요청[^199]

발표자는 세션 소감을 묻고,[^200] AWS Innovate 행사에 현대적 애플리케이션과 연관된 다양한 세션들이 준비되어 있다고 안내한다.[^201]
세션뿐 아니라 새롭게 만들어진 기술 백서도 준비되어 있으니 오른쪽 QR 코드를 확인해 달라고 하고,[^202] 오늘 주제와 관련된 다양한 교육들도 준비되어 있으니 참고하라고 말한다.[^203]
또한 AWS는 피드백 기반으로 더 나은 세미나를 준비하므로, 좋았던 점/아쉬운 점 의견을 달라고 요청하며 발표를 끝맺는다.[^204]

4. 핵심 통찰[^205]

1. [h 컨테이너 워크로드 구축은 “오케스트레이션 선택 → 실행 환경 선택 → 이미지 저장소 → 클러스터/태스크/서비스 배포”의 계층적 결정 구조로 이해하면 빠르다.] 이를 먼저 정리하면, 어떤 단계에서 어떤 AWS 서비스를 다루는지 혼동이 줄어든다.[^3]

   • 실행 시사점
     • ECS/EKS, EC2/Fargate 선택을 “운영 책임 범위(노드 관리 유무)” 관점에서 먼저 갈라놓고 설계한다.[^26]

2. [h ECS에서 서비스(Service)는 단순 배포 설정이 아니라 “원하는 상태(desired state)를 지속 유지”하는 오케스트레이션의 핵심 메커니즘이다.] 태스크 수 유지 같은 운영 자동화가 서비스 개념에 담겨 있다.[^42]

   • 실행 시사점
     • 태스크 수, 배포 방식(롤링/블루그린), 오토스케일 정책을 서비스 레벨에서 표준화한다.[^66]

3. [h IaC의 가치는 “재현성 + 변경 추적 + 롤백 용이성”으로 요약되는 운영 안정성에 있다.] 동일 코드를 여러 환경에 적용할 수 있고 문제가 생기면 되돌리기 쉬워진다는 논리를 제시한다.[^82]

   • 실행 시사점
     • cdk diff를 배포 게이트로 두고, 변경 검수 후 cdk deploy하는 프로세스를 팀 규칙으로 만든다.[^128]

4. [h CDK의 생산성은 레벨 3 ‘패턴(architecture bundle)’에서 크게 체감된다.] Fargate+ALB 같은 구성이 적은 코드(발표 예: 25줄)로도 가능하다는 비교를 통해, 추상화의 효용을 강조한다.[^189]

   • 실행 시사점
     • 처음에는 패턴으로 빠르게 만들고, 커스터마이징이 늘면 L2/L1로 점진적으로 내려가는 전략을 고려한다.[^108]

5. [m 컨테이너 배포가 끝이 아니라, 다음 단계로 CI/CD와 관측(메트릭/로그) 체계를 붙여야 ‘운영 가능한’ 워크로드가 된다.] 발표는 구축 후의 자연스러운 확장 과제로 파이프라인과 모니터링 메커니즘을 제안한다.[^196]

   • 실행 시사점
     • 샘플 코드(레퍼런스)를 기준으로 파이프라인/로깅/모니터링까지 한 번에 템플릿화한다.[^198]

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

IaC(Infrastructure as Code): 코드로 인프라 구성요소를 생성/구성/배치하고, 버전관리·롤백·재현성을 확보하는 방식.[^80]
ECS(Elastic Container Service): AWS 네이티브 컨테이너 오케스트레이션 서비스로, 클러스터/태스크/서비스 단위로 워크로드를 운영.[^37]
EKS(Elastic Kubernetes Service): Kubernetes 기반의 AWS 관리형 오케스트레이션 서비스.[^22]
Fargate: 서버리스 컨테이너 컴퓨팅 엔진(노드 관리 부담을 줄이고 태스크 단위 실행).[^^26]
ECR(Elastic Container Registry): 컨테이너 이미지를 저장하는 AWS 관리형 레지스트리.[^30]
Task(태스크): ECS에서 최소 실행 단위(하나 이상 컨테이너 묶음)로 네트워크/스토리지/IAM/리소스 등을 정의.[^49]
Service(서비스): ECS에서 태스크를 배포하고 desired state를 유지하는 운영 단위(레플리카/데몬, 배포 방식, 오토스케일 등 설정).[^^63]
Construct / Stack / App: CDK의 구성 단위. Construct는 최소 블록, Stack은 배포 최소 단위(CloudFormation과 매핑), App은 스택 묶음.[^103]
L1/L2/L3(패턴): CDK 라이브러리 추상화 레벨. L1은 Cfn* 저수준, L2는 고수준, L3는 여러 리소스를 묶은 아키텍처 패턴.[^108]

---

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

• 제목: AWS IaC 툴로 클라우드 네이티브한 컨테이너 환경 뚝딱!개발하기 - 김주영, AWS | AWS Innovate - 현대적 앱 특집[^208]
• 채널: Amazon Web Services Korea[^208]
• 길이: 29분 4초[^208]
• 링크: https://www.youtube.com/watch?v=uqNkjAI9vkk[^208]

[^1]: @[00:12]~@[01:19] 발표자 소개와 세션 주제/흐름 안내 전반. [^2]: @[01:19] "aws 컨테이너 서비스 포트폴리오를 살펴볼까요" [^3]: @[01:39]~@[09:50] ECS/EKS, EC2/Fargate, ECR, ALB 라우팅, App Mesh, CloudWatch까지 전체 흐름 설명. [^4]: @[10:14] "iac 툴을 통해 자원에 관리하는 것이 어떤 잇점이 있을까요" [^5]: @[10:31]~@[10:54] 변경 추적, 롤백, 동일 환경 재현성. [^6]: @[00:43]~@[01:06] 데모 주요 서비스(ECS, CDK) 예고. [^7]: @[18:07]~@[26:46] CDK 프로젝트 생성→ECR 생성→이미지 푸시→ECS 패턴 배포→URL 확인. [^8]: @[00:33]~@[01:06] 세션 흐름/구성 안내. [^9]: @[01:27]~@[09:50] 컨테이너 서비스 설명 + @[10:09]~@[16:47] CDK 설명 + @[17:00] 이후 데모. [^10]: @[27:18]~@[27:44] CDK의 간결함/변경 캐치 장점 언급. [^11]: @[11:20]~@[13:17] CDK 정의, 언어, 구성요소, 스택-클라우드포메이션 매핑. [^12]: @[00:33] 이후 전체 전개 순서. [^13]: @[00:22]~@[01:19] 세션 주제와 진행 순서. [^14]: @[00:16] "aws ... 솔루션스 아키텍트 ... 김주현" [^15]: @[00:22] 세션 제목 소개. [^16]: @[00:37] "먼저 ... 컨테이너 관련 서비스들" [^17]: @[00:43]~@[00:58] 데모와 주요 서비스(ECS, CDK). [^18]: @[01:06]~@[01:19] 워크로드/데모 구현 과정 안내. [^19]: @[01:19]~@[02:55] 컨테이너 포트폴리오(오케스트레이션/실행환경/ECR). [^20]: @[01:27] "aws 위에 컨테이너 워크로드" [^21]: @[01:39]~@[01:55] ECS/EKS 소개. [^22]: @[01:39]~@[01:55] "아마존 ... ECS ... 아마존 EKS" [^23]: @[01:55] "어떤 서비스를 사용할 것인지 선택" [^24]: @[02:01]~@[02:25] EC2/Fargate/혼합. [^25]: @[02:01] "컨테이너가 동작하는 환경을 구축" [^26]: @[02:01]~@[02:15] EC2, Fargate 설명. [^27]: @[02:15]~@[02:25] 혼합 구성 가능. [^28]: @[02:25]~@[02:55] 이미지와 ECR. [^29]: @[02:25] "컨테이너는 ... 이미지가 실행된 상태" [^30]: @[02:31]~@[02:46] 이미지 정의 + @[02:46]~@[02:55] ECR 소개. [^31]: @[02:55]~@[04:40] ECS 아키텍처와 구성요소. [^32]: @[02:55] "아마존 ECS ... 살펴보겠습니다" [^33]: @[03:04]~@[03:35] 컨트롤/데이터 플레인. [^34]: @[03:11]~@[03:21] 명령 전달 구조. [^35]: @[03:21]~@[03:40] 데이터 플레인(EC2/Fargate/혼합). [^36]: @[03:40]~@[04:13] 3요소 소개. [^37]: @[03:40] "구성 요소로는 크게 3가지" [^38]: @[03:45]~@[03:51] 클러스터 정의. [^39]: @[03:51]~@[04:04] 태스크 정의. [^40]: @[04:04]~@[04:13] 서비스 정의. [^41]: @[04:13]~@[04:21] 서비스가 지속적으로 관리. [^42]: @[04:28]~@[04:40] desired state(예: 3개) 유지 예시. [^43]: @[04:45]~@[05:35] 클러스터 구축 템플릿과 워커 노드. [^44]: @[04:53]~@[05:02] 클러스터 구축이 첫 작업. [^45]: @[05:02]~@[05:11] 3가지 템플릿. [^46]: @[05:11]~@[05:35] EC2 Linux+Networking 예시 설명. [^47]: @[05:35]~@[07:24] 태스크 정의 상세. [^48]: @[05:35]~@[05:52] 태스크 최소 실행 단위. [^49]: @[05:41]~@[05:52] 태스크 내 구성요소 나열. [^50]: @[05:58]~@[06:10] EC2/Fargate, 이미지 설정. [^51]: @[06:10]~@[06:17] IAM Role 부여 가능. [^52]: @[06:17]~@[06:31] S3 접근 예시. [^53]: @[06:17]~@[06:31] "S3 ... 권한 부여" [^54]: @[06:31]~@[07:02] 리소스 한계/경합/태스크 크기. [^55]: @[06:31]~@[06:43] 클러스터 자원 이상 사용 불가. [^56]: @[06:43]~@[06:51] 리소스 경합. [^57]: @[06:51]~@[07:02] 태스크 크기 설정 필요. [^58]: @[07:02]~@[07:24] 통합 설정, 컨테이너 수 제한. [^59]: @[07:02]~@[07:16] FireLens 등 통합 언급. [^60]: @[07:16]~@[07:24] 태스크당 최대 10 컨테이너. [^61]: @[07:24]~@[08:15] 서비스 설정(배포 형태/배치/배포유형/탄력성). [^62]: @[07:24]~@[07:37] 서비스 구성 필요. [^63]: @[07:37]~@[08:15] 서비스 설정 항목들. [^64]: @[07:37]~@[07:50] 레플리카 vs 데몬. [^65]: @[07:50] 작업 배치 선택. [^66]: @[07:50]~@[08:02] 롤링/블루그린/외부 컨트롤러. [^67]: @[08:02]~@[08:15] ELB, 오토스케일링. [^68]: @[08:15]~@[09:50] 전체 흐름 정리. [^69]: @[08:15] "하나의 흐름으로 정리" [^70]: @[08:21]~@[08:32] Git, CodeCommit. [^71]: @[08:32]~@[08:43] CodePipeline, CodeBuild, CodeDeploy. [^72]: @[08:43]~@[08:50] ECR 저장. [^73]: @[08:58]~@[09:16] ALB 엔트리/패스 기반 라우팅. [^74]: @[09:16]~@[09:28] ECS에서 Fargate/인스턴스 + IaC 프로비저닝. [^75]: @[09:28]~@[09:42] App Mesh 언급. [^76]: @[09:42]~@[09:50] CloudWatch 모니터링. [^77]: @[09:55]~@[11:11] IaC 정의/장점/도구 분류. [^78]: @[10:09]~@[10:14] 원론적 이야기 예고. [^79]: @[10:20] IaC 정의 도입. [^80]: @[10:20]~@[10:31] "인프라 ... 생성 구성 및 배치 ... 코드" [^81]: @[10:31]~@[10:54] IaC 장점. [^82]: @[10:31]~@[10:46] 변경분 파악. [^83]: @[10:31]~@[10:46] 롤백 용이. [^84]: @[10:46]~@[10:54] 동일 환경 복제. [^85]: @[10:54]~@[11:11] 도구 나열. [^86]: @[10:54]~@[11:11] CloudFormation/CDK, Terraform/Pulumi. [^87]: @[11:11]~@[11:20] "본 세션에서는 ... aws cdk" [^88]: @[11:20]~@[12:07] CDK 정의/언어/편의. [^89]: @[11:20]~@[11:31] CDK 정의. [^90]: @[11:31]~@[11:41] IaC 특징과 연결. [^91]: @[11:41]~@[11:56] TypeScript 예시, 자동완성/인라인. [^92]: @[11:41]~@[11:56] "자동완성 ... 인라인 ... 쉽게 시작" [^93]: @[11:56]~@[12:07] 지원 언어 나열. [^94]: @[12:07]~@[12:17] 코드 작성+인프라 선언. [^95]: @[12:17]~@[12:45] CDK 컴포넌트 3가지. [^96]: @[12:19]~@[12:34] 코어 프레임워크/라이브러리. [^97]: @[12:23]~@[12:34] 라이브러리 설명. [^98]: @[12:34]~@[12:45] CLI. [^99]: @[12:45]~@[13:43] Construct/Stack/App/Environment. [^100]: @[12:45]~@[12:53] "하나 이상의 스택" [^101]: @[12:53]~@[13:01] Construct 정의. [^102]: @[13:01]~@[13:08] Stack 배포 최소 단위. [^103]: @[13:08]~@[13:17] CloudFormation과 매핑. [^104]: @[13:17]~@[13:30] 라이프사이클 다른 리소스는 다른 스택. [^105]: @[13:30]~@[13:43] App/Environment 설명. [^106]: @[13:47]~@[15:24] Construct Library 레벨과 패턴 예시. [^107]: @[13:47]~@[14:00] Construct Library 설명/디펜던시 설치. [^108]: @[14:00]~@[14:04] "3가지 레벨" [^109]: @[14:04]~@[14:18] L1 설명. [^110]: @[14:04]~@[14:12] "저수준" [^111]: @[14:12]~@[14:18] Cfn 접두. [^112]: @[14:18]~@[14:43] L2 설명 + S3 예. [^113]: @[14:18]~@[14:31] 고수준/간결. [^114]: @[14:31]~@[14:43] S3 라이프사이클 규칙 예시. [^115]: @[14:43]~@[15:01] L3 패턴 설명 + ECS Fargate/ALB. [^116]: @[14:43]~@[14:52] "여러 개 리소스 ... 아키텍처" [^117]: @[14:52]~@[15:01] Fargate+ALB 번들 예. [^118]: @[15:01]~@[15:10] 문서 예시 연결. [^119]: @[15:10]~@[15:24] 모범사례/고객사례 기반. [^120]: @[15:24]~@[16:47] CLI 작업 흐름. [^121]: @[15:24]~@[15:31] CLI 소개. [^122]: @[15:31]~@[15:41] cdk init. [^123]: @[15:41]~@[15:50] npm install. [^124]: @[15:50]~@[16:06] npm run build. [^125]: @[16:06] cdk list. [^126]: @[16:06]~@[16:15] cdk synth. [^127]: @[16:15]~@[16:27] cdk deploy. [^128]: @[16:33]~@[16:47] cdk diff. [^129]: @[16:47]~@[17:00] 검수 후 deploy. [^130]: @[17:08]~@[17:47] 패턴/구성 짐작. [^131]: @[17:08] "실제로 ... 아키텍처" [^132]: @[17:16]~@[17:25] 패턴 추정. [^133]: @[17:16]~@[17:25] "pattern ... 레벨" [^134]: @[17:25]~@[17:34] "alb 와 빠게이트" [^135]: @[17:34]~@[17:47] 클러스터/이미지 매핑 코드. [^136]: @[17:47]~@[18:07] 샘플 코드 기반. [^137]: @[17:53]~@[18:07] "대부분 사례" [^138]: @[18:07]~@[19:24] 프로젝트 생성/구조 확인. [^139]: @[18:07] 데모 시작. [^140]: @[18:07]~@[18:17] 빈 디렉토리 + init. [^141]: @[18:17]~@[18:28] cdk.json 설명. [^142]: @[18:28]~@[18:36] build watch 언급. [^143]: @[18:36]~@[18:47] synth/diff. [^144]: @[18:47]~@[18:54] deploy. [^145]: @[18:54]~@[19:08] 비주얼 스튜디오/엔트리 포인트. [^146]: @[19:08]~@[19:17] 앱/스택 이름 위치. [^147]: @[19:17]~@[19:24] lib 폴더에 작성 안내. [^148]: @[19:24]~@[21:14] ECR 생성/의존성/배포. [^149]: @[19:24]~@[19:30] "ECR을 ... 생성" [^150]: @[19:30]~@[19:36] 복사/붙여넣기. [^151]: @[19:36]~@[19:45] 빨간불=라이브러리 없음. [^152]: @[19:51]~@[20:01] package.json에 버전 맞춰 추가. [^153]: @[20:01]~@[20:22] npm install. [^154]: @[20:22]~@[20:29] import 후 해결. [^155]: @[20:29]~@[20:36] repo 이름 지정. [^156]: @[20:52] 이후 배포 단계. [^157]: @[20:52]~@[21:04] cdk list. [^158]: @[21:04]~@[21:14] cdk deploy. [^159]: @[21:14]~@[21:28] CFN/ECR에서 확인. [^160]: @[21:28]~@[22:51] 이미지 빌드/푸시. [^161]: @[21:28] "원격 ... 컨테이너라이징" [^162]: @[21:57]~@[22:05] "푸쉬 커맨드 ... 절차" [^163]: @[22:05]~@[22:27] 빌드/태그 + @[22:27]~@[22:51] 푸시. [^164]: @[22:05]~@[22:11] ECR 리포지토리 정보. [^165]: @[22:11]~@[22:27] 빌드/태그. [^166]: @[22:27]~@[22:51] 데모 레포에 푸시. [^167]: @[22:51]~@[24:57] ECS 패턴 코드/에러 해결/정리/이미지 매핑. [^168]: @[22:51]~@[22:57] "레벨 ... 사용해서 ECS 환경 구축" [^169]: @[22:57]~@[23:09] 샘플 코드 붙여넣기. [^170]: @[23:09]~@[23:16] "총 4개의 에러" [^171]: @[23:16]~@[23:22] 스택 관련 수정 언급. [^172]: @[23:22]~@[24:02] 의존성 추가로 에러 제거. [^173]: @[24:02]~@[24:08] import 후 에러 제거. [^174]: @[24:08]~@[24:15] ECS 모델 import. [^175]: @[24:15]~@[24:38] 불필요 코드 제거. [^176]: @[24:15]~@[24:24] 클러스터명 지정 안 함 → 코드 제거. [^177]: @[24:24]~@[24:38] 헬스체크/루트 경로 관련 코드 제거. [^178]: @[24:38]~@[24:57] ECR 리포지토리 매핑. [^179]: @[25:00]~@[27:11] diff/deploy/결과 확인/비교. [^180]: @[25:00]~@[25:24] cdk diff. [^181]: @[25:24]~@[25:52] cdk deploy. [^182]: @[25:52]~@[26:04] CFN 업데이트 상태. [^183]: @[26:04]~@[26:24] Outputs에서 확인. [^184]: @[26:24]~@[26:46] URL 접속 확인. [^185]: @[26:24]~@[26:24] "플라스크 ... 컨테이너" (서비스 결과 확인) [^186]: @[26:46]~@[27:03] ECS에서 확인. [^187]: @[26:46]~@[27:03] "Fargate 형태 ... 확인" [^188]: @[27:03]~@[27:18] CFN 긴 코드 vs CDK 25줄. [^189]: @[27:03]~@[27:18] 템플릿 길이 비교 발언. [^190]: @[27:18]~@[27:44] 10분 작업 정리 및 CDK 장점. [^191]: @[27:18] "10분간의 작업" [^192]: @[27:18]~@[27:24] ECR 이미지 저장. [^193]: @[27:24]~@[27:33] Fargate 태스크 + ALB 포함 ECS 클러스터 생성. [^194]: @[27:33]~@[27:44] 콘솔/CLI 대비 간결 + 변경 캐치. [^195]: @[27:44]~@[28:15] 다음 단계 제안. [^196]: @[27:44]~@[27:56] CI/CD 파이프라인 필요. [^197]: @[27:56]~@[28:07] 메트릭/로그 메커니즘 필요. [^198]: @[28:07]~@[28:15] 샘플 코드로 확인 권장. [^199]: @[28:15]~@[28:58] 마무리 안내/피드백. [^200]: @[28:15]~@[28:18] 소감 질문. [^201]: @[28:18]~@[28:26] 다양한 세션 안내. [^202]: @[28:26]~@[28:36] 기술 백서/QR. [^203]: @[28:36]~@[28:45] 교육 자료 안내. [^204]: @[28:45]~@[28:58] 피드백 요청/마무리. [^205]: @[01:19]~@[27:44] 전반 논지에서 도출. [^206]: @[01:39]~@[16:47] 용어들이 집중적으로 정의/설명되는 구간. [^207]: 사용자 제공 메타데이터(제목/채널/길이/링크) + 영상 전반. [^208]: 사용자 메시지에 포함된 콘텐츠 메타데이터(제목, 채널, 길이, 링크).