https://www.youtube.com/watch?v=3DINoMNtGvI

description: |-

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

[? 질문] DevOps 관점에서 AWS CDK는 왜 필요하며, 무엇을 해결하려는 도구인가[^7][^8]
[= 답] DevOps의 목표(조직 역량을 끌어올려 빠르게 서비스 개발)에 맞춰, IaC(Infrastructure as Code) 프랙티스를 “프로그래밍 가능한 추상화”로 제공해 클라우드 리소스의 생성·구성·배포를 더 쉽게, 더 빠르게, 더 표준화된 방식으로 수행하게 해준다.[^7][^25][^31]

[? 질문] CDK는 기존 방식(콘솔/CLI/CloudFormation/SAM)과 비교해 어떤 차별점을 제공하는가[^20][^24]
[= 답] CDK는 가장 추상화된 계층에서 일반 프로그래밍 언어로 인프라를 모델링하게 하여, 클래스/객체/조건문/반복문/재사용 가능한 라이브러리화 등을 통해 복사-붙여넣기를 줄이고, 온보딩·개발속도·거버넌스(보안/준수) 적용·협업 효율을 높인다.[^19][^20][^21]

[? 질문] 실무에서 CDK를 “그냥 쓰는 것”을 넘어 DevOps/MLops로 확장 적용하려면 무엇을 준비하고 어떤 프랙티스를 따라야 하는가[^43][^52]
[= 답] (1) 역할별 사일로를 줄이기 위해 한 프로젝트/코드베이스 안에서 협업 가능한 구조(“울타리”)를 만들고,[^52] (2) 공용 인프라/공통 기능을 추상화한 **자체 프레임워크(어댑테이션 레이어)**로 재사용성을 높이며,[^41][^42] (3) 환경별 config/DI, CI/CD 파이프라인, 모니터링까지 코드 기반으로 연결하고,[^44][^45] (4) 레거시 리소스 import, custom resource, 스택 간 dependency 관리(SSM Parameter Store) 같은 구현 테크닉을 적용한다.[^54][^58][^61]

2. 큰 그림[^2]

이 콘텐츠는 AWS Korea 채널의 세션으로, 프로토타이핑 엔지니어가 DevOps 관점에서 AWS CDK를 소개하고, 실제 프로젝트 경험을 바탕으로 CDK를 실무에 적용하기 위한 기술 요소와 프랙티스를 설명한다.[^3][^4] 또한 데모(타입스크립트 기반 ECS/VPC/ALB 자동 생성) 흐름을 보여준 뒤, 조직/역할 협업 구조, CI/CD, 확장 테크닉, 준비사항, 실습 아키텍처까지 이어서 안내한다.[^27][^44][^70]

• DevOps의 본질은 빠른 서비스 개발을 위한 조직 역량 향상이며, 철학·프랙티스·툴의 유기적 조합이 핵심이다.[^7] 그중 CDK는 IaC 프랙티스를 수행하게 하는 도구로 자리한다.[^8]
• CDK는 프로그래밍 언어 기반 추상화로 온보딩을 쉽게 하고, 재사용/표준화/자동화를 통해 개발·배포 프로세스를 가속한다.[^19][^20]
• 실무에서는 단순 사용을 넘어, 공용 모듈/프레임워크화, 환경별 배포, CI/CD 오케스트레이션, 의존성 관리, 레거시 연동(import) 등으로 “조직의 운영 방식”에 맞게 고도화해야 한다.[^41][^44][^60]

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

3.1 세션 목적과 진행 방식: “CDK로 시작하지만 목표는 DevOps 문화”[^5]

발표자는 인사 후, 이번 세션을 “DevOps 관점에서 CDK를 알아보는 시간”으로 소개한다.[^3] 특히 지난 2년간 고객 개발자들과 수행했던 다양한 CDK 프로젝트(프로토타이핑) 경험을 바탕으로, 필수 기술 요소와 프랙티스 요소를 함께 다루겠다고 밝힌다.[^4]
세션 중 질문은 채팅 등으로 받고, 공개 답변이 부담되면 “비공개”로 표시하라고 안내한다.[^6]

전체 구성은 다음 흐름이라고 제시한다.[^7]

• DevOps(대부업쓰로 발음되지만 맥락상 DevOps) 소개
• CDK 기본 설명
• 실무 적용에 필요한 기술 요소
• 실무 적용 프랙티스

발표자는 “오늘은 CDK로 시작하지만” 궁극적으로는 IaC 프랙티스가 조직의 베스트 프랙티스로 정착되고, 역할별 사일로가 줄어 효율적 커뮤니케이션과 건강한 개발 문화로 이어지길 바란다고 말한다.[^8]

[!IMPORTANT] 세션의 숨은 목표(발표자 의도) CDK 자체 기능 소개를 넘어, IaC를 통해 역할 간 협업 장벽(사일로)을 낮추고 조직 개발 문화를 개선하는 “울타리”를 만드는 데 초점이 있다.[^8][^52]

3.2 DevOps/클라우드 친화 개발에서 필요한 프랙티스와 IaC의 위치[^9]

발표자는 DevOps가 “빠른 속도로 서비스 개발을 위해 조직 역량을 끌어올리는 것”을 목표로 하며, 이를 위해 개발 철학·프랙티스·툴의 유기적 조합이 중요하다고 설명한다.[^7] 그리고 오늘 다룰 CDK는 이 중 “툴(도구)”에 속하지만, 결국 IaC라는 프랙티스를 위한 도구라고 위치를 잡는다.[^8]

또한 “DevOps 3(대부3로 발음)”에서 말하는 프랙티스들이 클라우드 친화 개발에서 필수적으로 챙겨야 하는 프랙티스와 유사하다고 언급한다.[^9] 특히 소프트웨어 딜리버리 관점에서 자동화, 추상화, 표준화가 중요하며, 이것들이 DevOps에서 말하는 IaC 등의 프랙티스와 맞닿아 있다고 연결한다.[^10]

이 프랙티스를 제대로 수행하려면 다음 조건/전략이 필요하다고 나열한다.[^11]

• 서비스들이 마이크로서비스화되어야 함
• 각 마이크로서비스는 독립 DB를 유지해야 함
• 서버 운영을 최소화하기 위해 서버리스 우선 전략을 취해야 함
• 그 과정에서 보안 요소도 함께 챙겨야 함

이런 변화로 인해 역할별 협업이 더 중요해졌고, CDK 프로젝트를 “하나의 울타리”로 구성하면 DevOps/ML 담당자 등이 한 공간에서 협업하며 사일로를 최소화할 수 있다고 주장한다.[^12][^13]

+++ “웹 애플리케이션 개발 방식 변화” 예시(발표자가 든 변화상) 과거에는 서버 베이스(발표 표현상 “3-tier 형태”)로 모든 작업이 시작되었다면, 최근에는 서버리스를 통해 더 가볍게 핵심에 집중하는 형태로 바뀌고 있다고 설명한다.[^14]
이에 따라 조각조각 존재하는 클라우드 리소스를 효율적으로 모델링하고 배포해야 하며, 그 구현 수단으로 CDK를 제시한다.[^15] +++

3.3 IaC란 무엇이며, AWS의 IaC 도구 스펙트럼에서 CDK 위치[^16]

발표자는 DevOps의 큰 축을 IaC로도 볼 수 있다고 하면서, IaC를 “인프라 리소스의 생성·구성·배포를 코드로 작성하는 프랙티스”로 정의한다.[^16]

IaC는 하루아침에 생긴 게 아니라, 인프라 관리 방식이 다음처럼 고도화되어 왔다고 설명한다.[^17]

• 매뉴얼 관리(콘솔)
• 스크립트 방식(예: CLI)
• 선언적 방식(예: CloudFormation)
• 자동 생성/추상화, 프로그래밍 가능한 방식(오늘의 CDK)

AWS는 다양한 형태의 IaC/프로비저닝 도구를 제공한다고 정리한다.[^18]

• 매뉴얼: 웹 콘솔[^18]
• 스크립트: CLI/SDK 계열[^18]
• 선언적: CloudFormation (YAML/JSON 지원, 성숙하고 널리 사용)[^18]
• 확장 선언적: SAM(CloudFormation 확장판, 서버리스 리소스를 더 짧게 선언해 자동 생성/가속)[^19]
• 추상화/프로그래밍: CDK(프로그래밍 언어로 모델링/배포)[^20]

이어서 “이들 관계”를 AWS API 관점에서 설명한다.[^21]

• AWS 서비스를 쓰려면 근본적으로 AWS HTTP API를 사용해야 하며, 서비스별로 문서에 표기되어 있다.[^21]
• 하지만 HTTP API를 그대로 쓰는 건 쉽지 않아, 한 축으로 웹 콘솔/CLI/SDK 방식이 존재한다.[^22]
• 다른 축으로는 CloudFormation이 있고, SAM과 CDK는 이 CloudFormation 기반 배포 세계관에 연결된다고 정리한다.[^23]

3.4 CDK 기본: 왜 쓰고, 무엇이 좋은가(온보딩/속도/거버넌스/컨텍스트 스위칭 감소)[^24]

발표자는 “클라우드 애플리케이션을 구성하고 배포하는 것은 쉽지 않다”는 문제의식에서 출발해, CDK가 이런 까다로운 프로세스를 쉽게 도와준다고 말한다.[^24]
그 차별화 포인트는 프로그래밍 언어의 익숙함과 표현 능력을 활용한다는 점이라고 설명한다.[^25]

CDK의 이점을 네 가지로 정리한다.[^19][^26]

1. 손쉬운 클라우드 온보딩: 리소스를 추상화한 클래스를 제공하므로, 객체 선언만으로 베스트 프랙티스 방식으로 배포가 가능하다고 설명한다.[^19] 그래서 초기부터 네트워크/VPC 같은 깊은 지식이 부족해도 시작할 수 있다고 덧붙인다.[^19]
2. 더 빠른 개발 프로세스: 프로그래밍 언어 표현력으로 코드 복사를 지양하고, 객체/조건문 등을 사용해 생산성을 높인다고 말한다.[^20]
3. 사용자 지정 및 재사용(거버넌스): 조직의 보안 규정 준수/거버넌스 요구사항을 라이브러리·프레임워크 형태로 구현해 재사용·공유할 수 있다고 설명한다.[^20]
4. 컨텍스트 스위칭 감소: 모든 게 프로그래밍으로 가능해 하나의 IDE에서 개발/인프라 구성/모델 개발까지 처리할 수 있다고 말한다.[^20]

또한 CDK가 여러 언어를 지원함을 강조하며, “프로그래밍 언어를 지원한다는 것은 기존 소프트웨어 엔지니어링에서 제공했던 것들을 다 지원한다는 뜻”이라고 풀어 말한다.[^26] 그 예로 IDE의 자동완성, 인라인 문서, 재사용 강한 클래스 라이브러리 제작 등을 든다.[^26]

3.5 20줄 남짓 코드로 VPC~ECS까지: 타입스크립트 예시와 데모 전개[^27]

발표자는 타입스크립트로 작성된 “20줄 남짓” 코드 예시를 보여주며, 이 코드가 한 번에 관리하는 리소스를 열거한다.[^27]

• VPC
• 퍼블릭/프라이빗 서브넷
• 인터넷 게이트웨이
• NAT 게이트웨이
• 애플리케이션 로드 밸런서(ALB)
• ECS 클러스터/서비스/태스크

이어서 “동영상(데모)으로 과정”을 보여주겠다고 하며 실제 작업 흐름을 단계별로 시연한다.[^28]

(1) 프로젝트 생성과 IDE 준비[^28]

• CDK 프로젝트 디렉토리를 만들고[^28]
• cdk init(발표 발음상 “cdk 이닛”)으로 프로젝트를 생성하며[^28]
• 언어는 TypeScript를 선택해 셋업한다.[^28]
• 준비가 되면 VS Code를 열어 작업한다.[^28]

(2) 문서 참고 → 모듈 추가 → 설치[^29]

• AWS 문서(“CDK 문서”)를 참고하고[^29]
• ECS “패턴 모듈”(발표 발음상 “ecs 패턴 모듈”)을 사용할 예정이라며, 관련 모듈을 복사해 package.json에 디펜던시로 추가한다.[^29]
• npm install로 설치한다.[^29]

(3) 스택 코드 작성/수정 포인트[^30]

발표자는 스택에서 작업하며,

• 라이브러리 임포트[^30]
• ECS 패턴 샘플 코드를 복사해 사용[^30]
• ECS 라이브러리도 임포트[^30]
• 배포 타겟이 “해당 스택”이므로 키워드를 this로 바꿔줌[^30]
• 클러스터명을 명시하지 않으면 자동 생성됨[^30]
• 헬스체크 경로는 기본 루트 경로를 쓰므로 커스텀하지 않아도 됨[^30] 이라고 설명하며 코딩이 끝났다고 말한다.[^30]

(4) 배포 전 확인 → 배포 실행 → CloudFormation에서 이벤트 확인[^31]

• cdk list로 스택이 보이고 코드에 문제가 없는지 확인한다.[^31]
• cdk deploy로 배포한다.[^31]
• 프로파일을 지정하면 멀티 어카운트/멀티 리전 타게팅이 가능하다고 언급한다.[^31]
• 배포 과정이 “무려 39개 스텝”으로 이루어지며, 이런 작업들이 내부적으로 자동 처리된다고 강조한다.[^31]
• 배포는 CloudFormation을 통해 이뤄지므로 CloudFormation 콘솔에서 스택 배포/이벤트 로그를 확인한다.[^31]

(5) 배포 결과 확인: ALB 주소 접속, ECS/타겟그룹/로드밸런서 관계 확인[^32]

• 배포가 완료되면 로드 밸런서 주소를 복사해 브라우저에 붙여 넣고 서비스가 올라온 것을 확인한다.[^32]
• ECS 콘솔에서 클러스터/서비스/태스크(1개 구동)를 확인하고[^32]
• 서비스가 80포트로 타겟 그룹에 연결된 것, 타겟 그룹이 로드 밸런서와 연결된 것을 순서대로 확인한다.[^32]
• “VPC까지 CDK로 한 번에 생성”되었음을 다시 확인한다.[^32]

3.6 CDK가 동작하는 방식: 코드 → CLI 컴파일/합성 → CloudFormation 템플릿 → 배포[^33]

데모 뒤 발표자는 이 흐름이 어떻게 동작하는지 구조적으로 설명한다.[^33]

• 소스(컨셉트/construct를 이용한 코드)를 작성하고[^33]
• CLI로 컴파일(합성)하면 결과가 CloudFormation 템플릿(YAML/JSON 형태로 표현됨)로 떨어지고[^33]
• 최종적으로 CloudFormation을 통해 배포된다고 설명한다.[^33]

CDK 구성 요소를 “프레임워크(construct library) + CLI”로 보고, 이를 하나씩 소개하겠다고 한다.[^34]

3.7 CDK 프레임워크 구성 요소: Construct / Stack / App / Environment[^35]

CDK 프레임워크(발표 표현상 “코드 프레임워크”)의 기본 빌딩 블록을 다음처럼 정의한다.[^35]

• Construct: 최소 빌딩 블록[^35]
• Stack: 배포 최소 단위[^35]
• App: 스택의 모음[^35]
• Environment: 배포 타게팅의 계정(Account)과 리전(Region)[^35]

또한 construct library는 사전 구현되어 있고, 문서에서 라이브러리 및 디펜던시 명시를 확인할 수 있다고 말한다.[^36]

3.8 CDK “레벨” 개념(L1/L2/L3)과 의미[^37]

발표자는 CDK에서 “레벨”을 지정한다며 다음처럼 설명한다.[^37]

• L1: CloudFormation 리소스를 자동 생성한 것. 리소스 앞에 Cfn 프리픽스 사용.[^37]
• L2: AWS Construct. AWS 서비스 하나하나를 추상화해 매핑한 레벨.[^37]
• L3 이상: 여러 AWS 서비스를 합성해 특정 목적에 맞게 만든 더 고수준 추상화 라이브러리.[^37]

3.9 CDK CLI 주요 명령과 사용 흐름(list/diff/synth/deploy)[^38]

발표자는 데모에서 본 것처럼 CLI로 프로젝트를 만들고, 디펜던시 설치 후 코딩하며, 다양한 명령을 쓴다고 정리한다.[^38]

• cdk init로 프로젝트 생성[^38]
• cdk list로 스택 확인[^38]
• cdk diff로 “내가 코딩한 것 vs 배포된 것” 비교 가능[^38]
• cdk synth로 CloudFormation 템플릿(YAML 형태)을 확인 가능[^38]
• cdk deploy로 최종 배포[^38]

3.10 CDK 생태계 확장: Terraform, Kubernetes(eks)까지 이어지는 흐름[^39]

발표자는 CDK가 초기엔 “외로운 느낌”이었지만 이제는 에코시스템이 갖춰지고 있다고 말한다.[^39] 예로,

• Terraform도 CDK를 지원하기 시작했고[^39]
• Kubernetes 쪽(발표에서 “쿠버네 tx”로 언급되는 매니페스트 구성의 어려움)을 CDK로 구현하는 흐름이 가능해졌다고 설명한다.[^39]

3.11 프로토타이핑 고객 사례: 다양한 산업/서비스에서 CDK 적용[^40]

발표자는 자신이 참여한 프로토타이핑 고객 케이스를 “모두 CDK로 개발·배포된 사례”로 소개한다.[^40]

• 현대백화점: 무인 스마트 스토어 “언커먼 스페이스” 같은 도전적/혁신 프로젝트에 CDK 활용[^40]
• 현대건설: 제조업 쪽 스마트 서비스 개발에 CDK 활용[^40]
• 아모레퍼시픽: 클라우드 네이티브 AI 서비스 개발의 기반으로 CDK 활용[^40]
• 스타트업(발표 발음상 “비…레이션”): 무인 로봇 바리스타에서 IoT/데이터 분석 서비스 기반으로 CDK 활용[^40]

3.12 “우리만의 프레임워크 만들기”: 프로젝트 구조 리팩토링과 역할별 디렉토리 분리[^41]

여기서부터 발표자는 CDK를 “고도화”해 쓰는 방식, 즉 우리만의 프레임워크를 만드는 것을 설명한다.[^41]

CDK로 프로젝트를 생성하면 기본 구조가 만들어지는데, 이를 DevOps/MLops/DevSecOps 등 상황에 맞게 디렉토리 구조를 리팩토링한다고 말한다.[^41] 그리고 역할별로 디렉토리를 만든다고 설명한다.[^41]

• (예) Ops/플랫폼/DevSecOps 담당: 인프라 폴더에 인프라 로직 구성[^41]
• 애플리케이션(Dev) 담당: 컨테이너 기반 또는 서버리스 기반 로직을 코드 폴더에 구현[^41]
• ML 담당: 모델 파일/웨이트/파라미터 및 inference 관련 파일을 모델 폴더에 부여[^41]
• config 폴더: 배포 타겟 환경 구성[^41]
• scripts 폴더: 자동화 스크립트 사전 제공[^41]

특히 “특정 서비스에 종속된 인프라”와 “추상화된 공용 인프라”를 구별해 구현하는 것이 매우 중요하다고 강조하며, 다음 섹션에서 자세히 짚겠다고 한다.[^42]

3.13 공용 모듈을 직접 앱에 넣지 말고: 어댑테이션 레이어로 ‘커스터마이징 프레임워크’ 구축[^43]

발표자는 일반적으로 CDK 애플리케이션을 개발할 때(웹 앱, ML 개발, 데이터 분석 등) CDK 라이브러리를 직접 사용해 구현한다고 말한다.[^43] 그러다 보면 “공용으로 추상화할 수 있는 모듈들이 툭툭 나오게” 되는데, 이런 것들을 애플리케이션 코드에 그대로 두지 말고 **중간에 어댑테이션 레이어(Adaptation Layer)**를 넣어 “우리만의 커스터마이징된 프레임워크”를 만들라고 제안한다.[^43]

그 프레임워크에는 공통 코드베이스를 구현하고, 공용화 가능한 요소들을 그곳에 모아 둔다고 설명한다.[^43] 또한 공통 요소는 역할/도메인별로도 정리될 수 있다고 말한다.[^44]

• (예) 보안/계정/권한(발표 중 “유저/롤…관리”) 같은 공통 기능[^44]
• DevOps 레벨의 CI/CD 기본 기능, 모니터링 등 공통 기능[^44]

이렇게 공통화를 해두면 애플리케이션 개발자는 소프트웨어 코드에, ML 담당자는 모델에 더 집중할 수 있고, 애플리케이션 특화 리소스를 빠르게 개발하면서 전체 개발을 가속할 수 있다고 결론낸다.[^44]

[!TIP] “CDK 고도화”의 핵심 패턴 직접 구성(CDK 라이브러리) → 공용 요소 발견 → 어댑테이션 레이어로 프레임워크화 → 조직 표준/거버넌스/재사용성 강화.[^43][^44]

3.14 DevOps 적용: 환경(config), DI, CI/CD(CodePipeline), 모니터링까지 코드로 연결[^45]

발표자는 “DevOps 수행에서 환경(배포 타겟)을 빼놓을 수 없다”고 하며, CDK 프로젝트에 config 파일을 배포 타겟별로 둔다고 설명한다.[^45] 이 config에는 배포할 계정/리전 같은 타겟 정보가 정의된다.[^45]

또한 타겟마다 성능/비용 이유로 리소스 사이즈가 달라져야 하는데, 그런 요소를 config의 dependency injection 형태로 주입한다고 말한다.[^46]

이어 CI/CD 파이프라인에 CDK 프로젝트를 올리는 흐름을 제시한다.[^47]

• CodePipeline이 전체 CI 파이프라인 오케스트레이션[^47]
• 코드 커밋/변경 발생 시 CodeBuild가 빌드[^47]
• 빌드된 CDK 결과물은 CloudFormation “artifact”가 되고[^47]
• CloudFormation을 통해 타겟에 순차 배포[^47]
• 배포 후 운영은 CloudWatch 대시보드/알람으로 모니터링 가능[^48]
• Cross-region / cross-account도 가능하며, 모든 게 코드 기반이므로 동일 코드를 다른 리전/계정으로 배포할 수 있다고 설명한다.[^49]

3.15 MLOps 적용: 한 코드베이스로 소스코드+인프라+모델을 묶어 멀티타겟 배포[^50]

발표자는 이제 ML 적용 케이스를 설명한다.[^50] 역할별 산출물이 하나의 CDK 프로젝트 구조로 묶여 들어오는 흐름을 제시한다.[^50]

• 소프트웨어 개발 담당: 코드 폴더에 비즈니스 로직 및 테스트 코드 구현[^50]
• 인프라 담당: 인프라/스택을 인프라 폴더에 구현[^50]
• ML 담당: 모델 웨이트/파라미터 및 inference 파일을 모델 폴더에 배치[^50]
• config 파일: 환경별 요소를 다르게 구성해 설정[^50]

이를 통해 “원 소스 코드, 멀티 컴파일(표현상), 멀티 타겟 배포”가 가능하도록 만든다고 말한다.[^51]

발표자는 본인이 AWS 샘플(“샘플 쓰기술”) 쪽에서 관리하는 예제 프로젝트를 참고하면 도움이 된다고 언급하며, 파이토치 모델을 서빙하는 MLops/DevOps 예제라고 소개한다.[^51] 또한 해당 샘플은 “멀티 아키텍처”로 구현되어 있다고 덧붙인다.[^51]

3.16 가장 중요 포인트: 역할들이 멀리 떨어져 생기는 사일로를 CDK ‘울타리’로 감싸기[^52]

발표자는 DevOps/DevSecOps/MLOps 설명 후 “가장 중요한 것”을 강조한다.[^52]

• 소프트웨어 개발 담당, 머신러닝 담당, 운영 담당이 서로 멀리 떨어져 있다는 점[^52]
• 즉 **사일로(silo)**가 된다는 점[^52]

그래서 가장 중요한 포인트는 각각의 담당자들을 “한 울타리 안에 감싸서 모아 놓는 것”이라고 말한다.[^52]
각 영역의 전문가라도 접점의 디테일을 함께 해결하지 못하면 프로젝트 성과가 크게 달라지며,[^53] 지금까지 설명한 CDK가 그 울타리가 되어 한 곳에서 개발하도록 돕는다고 정리한다.[^53]

3.17 구현 디테일(1): 자주 쓰는 패턴을 합성한 ‘Solutions Constructs’[^54]

CDK construct를 쓰다 보면 자주 사용하는 패턴(API Gateway+Lambda, DynamoDB+Lambda 등)이 반복적으로 발생한다고 말한다.[^54] 이런 패턴을 쉽게 쓰도록 Solutions Constructs가 제공된다고 소개한다.[^54]

• 예로 API Gateway + Lambda, DynamoDB + Lambda 조합 등을 “하나의 컴파운드 construct”로 제공한다는 설명이다.[^54]
• 문서 링크를 통해 다양한 construct를 확인할 수 있고, Lambda+S3, SNS+SQS 등 다양한 패턴을 합성 제공한다고 말한다.[^55]
• 이를 통해 개발 속도를 더 높일 수 있다고 결론낸다.[^55]

3.18 구현 디테일(2): 바깥 리소스 가져오기(from* 메서드), 레거시 CloudFormation 템플릿 임포트[^56]

CDK로 개발하다 보면 콘솔/테라폼 등 “바깥에서 이미 만들어진 리소스”를 CDK 안에서 가져와야 하는 상황이 “무조건 발생”한다고 말한다.[^56]
이를 위해 문서에 from으로 시작하는 메서드들이 제공되며, ARN이나 이름 등을 인자로 주면 lookup을 통해 리소스를 찾아 통합할 수 있다고 설명한다.[^56][^57]

또한 레거시로 CloudFormation으로 구성해 둔 경우, CDK가 기존 배포된 CloudFormation 템플릿을 임포트할 수 있는 기능도 제공한다고 말한다.[^57] 예시로,

• 기존 CloudFormation 파일을 불러오고[^57]
• 파일 내 특정 리소스를 가져오는 메서드를 사용하며[^57]
• 이후 CDK로 보강하고, 예컨대 해당 버킷 참조를 추가하는 식으로 확장할 수 있다고 설명한다.[^57]

3.19 구현 디테일(3): 배포 산출물(Output)을 파일로 떨궈 휴먼에러 없이 인터페이스 전달[^58]

CDK로 개발하면 배포된 리소스들의 출력값(예: ARN, VPC ID 등)이 생기는데,[^58] 이를 다른 담당자나 다른 모듈에서 다시 쓰는 일이 발생한다고 말한다.[^58]
이때 수동으로 적어 전달하지 말고, CDK 배포 시 옵션을 통해 특정 JSON 파일로 출력되게 할 수 있다고 설명한다.[^58] 그러면 특정 담당자/서비스 모듈에 전달해 휴먼 에러 없이 더 빠르게 인터페이스를 맞출 수 있다는 주장이다.[^58]

3.20 구현 디테일(4): CDK/CloudFormation의 API 커버리지 한계를 ‘Custom Resource’로 보완[^59]

발표자는 AWS 서비스가 100이라고 하면 HTTP API/SDK(보토3, boto3) 레벨에서 80 정도 지원한다고 비유하며,[^59] CDK/CloudFormation으로 개발할 때는 “boto3만큼의 API 셋을 제공하지 못하는 부족한 부분”이 있다고 말한다.[^59]

이를 채우는 방법이 Custom Resource라고 설명한다.[^60]

• CDK 배포 시점에 Lambda를 트리거할 수 있고[^60]
• Lambda 내부에서 boto3/SDK를 사용해 CDK/CloudFormation으로 부족한 부분을 보완 구현할 수 있다는 흐름이다.[^60]

3.21 구현 디테일(5): 마이크로서비스에서 스택 디펜던시(거미줄) 문제와 SSM Parameter Store로 간접 결합[^61]

마이크로서비스를 CDK로 구현할 때 배포 최소 단위인 스택을 잘게 쪼개게 되는데, 이때 디펜던시 관리가 매우 중요하다고 말한다.[^61]

아무 생각 없이 스택을 만들면 거미줄처럼 엉키는 상황이 생긴다고 설명한다.[^62]

• 스택 간 의존성이 관리되지 않아
• 특정 스택 배포 시 다른 스택이 줄줄이 타게 되고[^62]
• 삭제도 다른 참조 때문에 어려워진다고 말한다.[^62]

해결책으로 SSM Parameter Store를 활용해 직접 결합이 아닌 간접 결합으로 관리하라고 제안한다.[^63]

• 각 스택이 서로를 직접 참조하지 않고[^63]
• Parameter Store에 주소/ARN/Name 등을 저장해 읽도록 하여[^63]
• 각 스택이 독립 배포 가능하도록 구현하는 것이 더 좋은 베스트 프랙티스라고 결론낸다.[^63]

[!WARNING] 스택 의존성 방치의 결과 배포 시 “연쇄 타격”, 삭제 어려움, 변경 영향 범위 확대로 운영 리스크가 커진다.[^62]

3.22 CDK 개발을 시작하기 전 준비사항: 계정/IAM/CLI/Node.js/CDK CLI[^64]

발표자는 CDK로 개발을 시작하려면 준비해야 할 사항을 짚는다.[^64]

1. AWS 계정(루트/메인 계정)과 IAM User 생성[^64]
   • IAM User에는 리소스 배포 권한이 필요하다고 언급한다.[^64]
2. 개발자 PC에 AWS CLI 설치 후 aws configure로 크리덴셜 설정[^64]
3. Node.js 설치 필수
   • CDK CLI가 Node.js 기반으로 개발되었기 때문에, 어떤 언어로 개발하든 Node는 설치되어 있어야 한다고 강조한다.[^65]
4. CDK CLI 설치[^65]

설치 가이드는 링크에서 자세히 확인할 수 있다고 안내한다.[^65]

그 아래는 개발자 편의에 맞춘 옵션으로 선택하면 된다고 말한다.[^66]

• 선호 언어: TypeScript/Java/Python 등[^66]
• IDE: TypeScript면 VS Code/Cloud9/WebStorm 등[^66]
• 이번 실습은 TypeScript + VS Code 기반으로 진행 예정이라고 못 박는다.[^66]

3.23 CDK 프로젝트 생성~삭제까지 기본 워크플로우(init → 의존성 → 코딩 → list/deploy → destroy)[^67]

발표자는 데모에서 봤던 것처럼 CDK 프로젝트를 만드는 절차를 다시 정리한다.[^67]

• 폴더를 만들고 들어가서 cdk init[^67]
• 언어 선택[^67]
• 사용할 리소스(construct) 디펜던시를 package.json에 기술하고 설치[^67]
• 코딩 후 cdk list, cdk deploy 실행[^67]
• 작업이 끝나 프로젝트가 더 필요 없으면 cdk destroy로 리소스를 삭제해 비용을 절약한다고 안내한다.[^67]

3.24 기능 추가(학습) 접근법: 콘솔로 서비스 탐색 → CDK 문서/예제 → 모듈 추가 후 코딩[^68]

“CDK 프로젝트에 신규 기능을 부여하는 과정”을 설명하며, 먼저 서비스를 탐색하라고 말한다.[^68]

• 웹 콘솔에서 클릭하며 해당 서비스(Lambda, S3 등)의 파라미터가 무엇인지 익힌다.[^68]
• 이후 CDK API 문서를 참조하면 디펜던시 모듈과 작은 예제 코드를 볼 수 있다고 말한다.[^68]
• 복잡한 구현이라면 GitHub의 “examples plus”처럼 언어별 샘플을 참고할 수 있다고 안내한다.[^69]

서비스 탐색이 되면 구현 레벨로 들어간다고 정리한다.[^69]

• 디펜던시 모듈 확인 → 패키지 파일에 기술 → 설치 → 임포트 → 코딩[^69]
• 결국 파라미터로 클래스를 객체화하기만 하면 리소스 배포 준비가 완료된다고 설명한다.[^69]

3.25 실습 아키텍처 소개: ECS(VPC/ALB/Cluster/Service/Task) + CI/CD + 모니터링 대시보드[^70]

발표자는 오후 실습을 간단히 소개하며, 실습 아키텍처가 미리 준비되어 있다고 말한다.[^70] GitHub/AWS Samples 형태의 리소스도 준비되어 있다고 언급한다.[^70]

아키텍처 상세는 다음 구성으로 설명한다.[^71]

• CDK로 ECS 인프라를 배포: VPC, ALB, ECS Cluster/Service/Task[^71]
• “한 번 배포하고 끝”이 아니라 반복적으로 관리해야 하므로 CI/CD 파이프라인도 함께 구성[^72]
• 운영 단계에서 정상 동작을 확인하기 위한 모니터링 대시보드도 함께 구성하는 실습[^72]

3.26 DevOps 엔지니어의 현실 시나리오: 여러 프로젝트 동시 지원과 CDK의 재사용/객체화 가치[^73]

발표자는 DevOps 엔지니어가 보통 한 서비스만 하는 게 아니라, 여러 서비스/프로젝트를 순차적 또는 동시에 지원하게 되는 상황을 예로 든다.[^73] 몸은 하나인데 여러 프로젝트를 지원해야 하므로 효율적인 커뮤니케이션과 배포 관리가 필요하고, 이때 CDK가 필요하다고 말한다.[^73]

또한 공통적으로 관리해야 할 것들은 공통으로 관리해야 한다며,[^74]

• DevOps 엔지니어/플랫폼 팀이 매니지먼트·거버넌스를 잡고[^74]
• 인프라/CI/CD/모니터링/보안(발표 중 “섹슈얼리티”) 등을 총체적으로 관리하며[^74]
• 신규 서비스 착수 시 CDK로 인프라 리소스/대시보드/ECS 등을 빠르게 만든다고 설명한다.[^74]

요구사항이 계속 발생하는 상황에서 코드 카피 없이 CDK의 객체 생성을 통해 손쉽게 제공할 수 있고, 그것을 실습에서 다룰 예정이라고 말한다.[^75]

3.27 실습 사전 준비와 마무리[^76]

실습을 위해 사전에 환경 설정을 해두면 좋다고 하며 링크를 통해 확인하라고 안내한다.[^76]
구체적으로는 각종 CLI와 CDK 설치가 되어 있어야 하고,[^76] 실습은 TypeScript로 진행하며 VS Code로 코딩하지만 상황에 따라 Cloud9을 준비해도 된다고 말한다.[^76]
끝으로 세션을 마무리하며 의견을 남겨 달라고 하고 감사 인사를 전한다.[^77]

4. 핵심 통찰[^78]

1. DevOps에서 CDK는 “목표”가 아니라 IaC 프랙티스를 쉽게 실행하게 하는 도구로 설명되며, 도구 선택은 조직의 프랙티스 정착과 연결돼야 한다.[^7][^8]
   • 실행: 조직에서 IaC 표준(구조/모듈/리뷰/배포 정책)을 먼저 정의하고 CDK로 구현 규칙을 라이브러리화한다.[^20][^43]
2. CDK의 차별점은 인프라를 “선언”을 넘어 **프로그래밍(추상화/재사용/표현력)**으로 다루게 해 속도와 표준화를 동시에 노린다는 데 있다.[^25][^20]
   • 실행: 반복 패턴은 L3 construct 또는 사내 프레임워크로 승격하고, 프로젝트 간 재사용을 전제로 설계한다.[^37][^43]
3. 실무 고도화의 핵심은 “공용/특화 분리”다. 공용 인프라를 직접 앱에 섞지 말고 어댑테이션 레이어로 분리해 거버넌스와 재사용성을 확보한다.[^42][^43]
4. CI/CD는 단순 배포 자동화를 넘어, config/DI로 환경 차이를 흡수하고 멀티 계정/리전 배포까지 확장되는 운영 모델로 제시된다.[^46][^49]
5. 스택을 잘게 나눌수록 의존성은 폭발한다. SSM Parameter Store 같은 간접 결합으로 독립 배포/삭제 가능성을 유지해야 한다.[^62][^63]
6. CDK/CloudFormation의 기능 공백은 현실적으로 존재하며, **Custom Resource(Lambda+SDK)**로 메우는 “확장 포인트”를 운영 관점에서 준비해야 한다.[^59][^60]
7. 가장 반복되는 문제는 기술이 아니라 사람/조직 구조(사일로)이며, 발표자는 CDK 프로젝트를 협업 “울타리”로 삼아 접점 문제를 해결하려 한다.[^52][^53]

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

DevOps: 빠른 서비스 개발을 위해 조직 역량을 끌어올리는 것을 목표로 하며 철학·프랙티스·툴 조합이 중요하다는 발표자 정의의 배경 개념.[^7]
IaC (Infrastructure as Code): 인프라 리소스의 생성/구성/배포를 코드로 작성하는 프랙티스.[^16]
CDK (AWS Cloud Development Kit): 프로그래밍 언어로 클라우드 리소스를 추상화(construct)해 모델링하고, 최종적으로 CloudFormation 템플릿으로 합성해 배포하는 도구/프레임워크.[^20][^33]
Construct: CDK의 최소 빌딩 블록.[^35]
Stack: CDK 배포의 최소 단위.[^35]
App: Stack의 모음.[^35]
Environment: 배포 대상 계정/리전 정보.[^35]
L1/L2/L3(레벨): L1은 Cfn 리소스 직접 매핑, L2는 서비스 추상화 construct, L3는 여러 서비스를 합성한 고수준 패턴 construct.[^37]
Solutions Constructs: API Gateway+Lambda 등 자주 쓰는 조합을 합성한 컴파운드 construct 모음.[^54][^55]
Custom Resource: CDK/CloudFormation이 직접 지원하지 못하는 동작을 배포 시점 Lambda 실행(SDK 사용)으로 보완하는 확장 방식.[^60]
SSM Parameter Store: 스택 간 직접 참조를 줄이고 간접 결합으로 의존성을 관리하기 위한 저장소로 활용된다고 소개됨.[^63]

---

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

• 제목: AWS 프로토타이핑 엔지니어가 들려주는 AWS CDK로 시작하는 DevOps [AWS Builders Standard Edition][^1]
• 채널: Amazon Web Services Korea[^1]
• 길이: 36분 24초[^1]
• 링크: https://www.youtube.com/watch?v=3DINoMNtGvI[^1]

[^1]: 제공된 메타데이터(제목/채널/길이/링크) 및 영상 오프닝 발화 맥락. [^2]: @[00:41] "전체적으로 오늘 세션은 다음과 같이 구성되어 있습니다..." [^3]: @[00:10] "오늘 세션에서는 DevOps 관점에서 CDK를 알아볼 텐데요" [^4]: @[00:14] "지난 2년간 ... 다양한 CDK 프로젝트 경험을 바탕으로 ..." [^5]: @[00:45] "DevOps로 시작해서 CDK 기본 설명하고..." [^6]: @[00:30] "세션의 중 질문은... 비공개라고 명시..." [^7]: @[01:10] "DevOps라는 것은... 조직 역량을 끌어올리는 것을 목표..." [^8]: @[01:31] "IaC라는 프랙티스를 위한 도구... 사일로 없애고..." [^9]: @[02:03] "DevOps 3에서는 다양한 프랙티스를 얘기..." [^10]: @[02:19] "자동화 추상화 표준화..." [^11]: @[02:35] "마이크로... 독립 DB... 서버리스 우선... 보안..." [^12]: @[03:05] "CDK 프로젝트를 구성하여... 하나의 울타리..." [^13]: @[03:50] "사일로를 취소할 수 있습니다" [^14]: @[03:18] "종전에는 ... 서버 베이스... 이제는 서버리스..." [^15]: @[03:35] "리소스들을 효율적으로 모델링하고 배포... CDK..." [^16]: @[04:00] "IaC는 ... 생성 구성 및 배포를 코드로 작성..." [^17]: @[04:12] "매뉴얼... 스크립트... 선언적... 자동 생성... 발전..." [^18]: @[04:37] "웹 콘솔... CLI... CloudFormation... YAML/JSON..." [^19]: @[04:56] "SAM... 서버리스 리소스 추상... 짧은 선언..." [^20]: @[05:10] "CDK는 가장 추상화된 방식... 프로그래밍 언어..." [^21]: @[05:25] "AWS 서비스를 사용하기 위해... HTTP API..." [^22]: @[05:43] "HTTP API 그대로... 쉽지... 웹 콘솔 CLI SDK..." [^23]: @[05:50] "CloudFormation... SAM과 CDK..." [^24]: @[06:06] "CDK는 왜 사용할까요... 쉬운 작업이 아닙니다" [^25]: @[06:26] "프로그래밍 언어의 익숙함과 표현 능력..." [^26]: @[07:42] "지원하는 언어... 자동 완성... 인라인... 재사용..." [^27]: @[08:13] "20줄 남짓... VPC... ALB... ECS..." [^28]: @[08:49] "프로젝트 디렉토리 생성... cdk init... TypeScript..." [^29]: @[09:23] "CDK 문서를 참조... 패턴 모듈... package.json... npm install" [^30]: @[10:00] "임포트... 샘플 코드 카피... this... 클러스터 자동... 헬스체크" [^31]: @[11:02] "cdk list... cdk deploy... 프로파일... 39개의 스텝..." [^32]: @[12:19] "로드 밸런서 주소... ECS 클러스터/서비스/태스크... 타겟그룹..." [^33]: @[14:01] "코딩... CLI... CloudFormation 템플릿... 배포" [^34]: @[14:23] "구성 요소... construct library... CLI" [^35]: @[14:33] "construct... stack... app... environment..." [^36]: @[14:57] "construct library... 문서... 디펜던시..." [^37]: @[15:11] "레벨... L1 Cfn... L2 AWS Construct... L3 합성..." [^38]: @[15:50] "cdk init... list... diff... synth... deploy..." [^39]: @[16:18] "에코시스템... Terraform도... Kubernetes도..." [^40]: @[16:56] "프로토타이핑 고객 케이스... 현대백화점... 현대건설... 아모레... 스타트업..." [^41]: @[17:55] "우리만의 프레임워크... 디렉토리 리팩토링... 역할별 폴더..." [^42]: @[19:15] "종속 인프라와 공용 인프라 분리... 매우 중요" [^43]: @[19:30] "직접 사용... 공용 모듈... 어댑테이션 레이어... 프레임워크..." [^44]: @[20:09] "공통 요소... 롤/유저... CI/CD 기본... 모니터링..." [^45]: @[21:01] "환경... config... 배포 타겟..." [^46]: @[21:22] "성능/비용... 사이즈... dependency injection" [^47]: @[21:37] "CodePipeline... CodeBuild... CloudFormation... 순차 배포" [^48]: @[22:06] "CloudWatch 대시보드... 모니터링... 알람" [^49]: @[22:18] "크로스 리전 어카운트... 코드로 다른 계정/리전에 배포" [^50]: @[22:32] "ML에 적용... 코드/인프라/모델... config..." [^51]: @[23:19] "샘플 프로젝트... 파이토치 모델 서빙... 멀티 아키텍처" [^52]: @[23:51] "가장 중요한 것은... 각 롤이 멀리 떨어져... 사일로..." [^53]: @[24:13] "접점 디테일... 성과 달라짐... CDK가 울타리..." [^54]: @[24:38] "자주 사용하는 패턴... 솔루션스 컨스트럭트..." [^55]: @[25:18] "람다+s3... sns+sqs... 합성... 개발 속도" [^56]: @[25:47] "바깥 리소스... from 메서드... lookup..." [^57]: @[26:24] "기존 CloudFormation 템플릿 임포트... 파일에서 리소스 가져오기..." [^58]: @[27:01] "아웃풋... JSON 파일로 떨굼... 휴먼 에러 없이..." [^59]: @[27:38] "서비스 100... SDK 80... CDK/CloudFormation 부족..." [^60]: @[28:05] "커스텀 리소스... 배포 시점 Lambda... boto3로 보완" [^61]: @[28:22] "마이크로서비스... 스택 쪼개기... 디펜던시 관리 중요" [^62]: @[28:35] "거미줄... 배포 시 다른 스택 타게 됨... 삭제 어려움" [^63]: @[29:04] "SSM Parameter Store... 간접 결합... 독립 배포" [^64]: @[29:37] "AWS account... IAM user... AWS CLI... aws configure" [^65]: @[30:06] "Node.js 필수... CDK CLI Node 기반..." [^66]: @[30:39] "언어 선택... IDE 선택... 실습은 TypeScript+VS Code" [^67]: @[31:09] "cdk init... 디펜던시... list/deploy... destroy..." [^68]: @[31:50] "서비스 탐색... 콘솔로 파라미터 숙지... CDK 문서" [^69]: @[32:19] "GitHub 샘플... 디펜던시 확인... 설치... 임포트... 코딩" [^70]: @[33:05] "실습 아키텍처... 미리 준비... AWS samples..." [^71]: @[33:17] "VPC... 로드밸런서... ECS... CDK 배포" [^72]: @[33:34] "CI/CD 파이프라인... 모니터링 대시보드" [^73]: @[34:10] "여러 프로젝트를 동시에 지원... 커뮤니케이션/배포 관리... CDK 필요" [^74]: @[35:01] "플랫폼/DevOps 팀... 거버넌스... 인프라/CI/CD/모니터링/보안..." [^75]: @[35:30] "코드 카피 없이... 객체 생성... 손쉽게 제공... 실습" [^76]: @[35:47] "사전 환경 설정... CLI/CDK 설치... TypeScript... VS Code/Cloud9" [^77]: @[36:12] "세션은 여기까지... 의견 남겨주세요... 감사합니다" [^78]: @[01:10]~@[29:30] 발표 전개 전반(DevOps 목적→CDK 가치→실무 프랙티스/테크닉)에서 도출. [^79]: @[04:00]~@[29:30] 용어가 직접 정의/설명되는 구간들. [^80]: 영상 링크/메타 및 전반 맥락.