https://www.youtube.com/watch?v=pp0ew8VerRw
description (markdown):
1. 이건 꼭 알아야 한다[^1]
[? 질문] DevOps(데브옵스)란 정확히 무엇이며, 왜 조직마다 정의가 조금씩 다른가[^7]
[= 답] DevOps는 단순히 개발(Development) 과 운영(Operation) 을 합친 단어를 넘어, 두 영역의 장벽을 허물고 문화(사고방식)·사례(프로세스/방법론)·도구(자동화 수단) 를 결합해 개발 생산성과 운영 안정성을 함께 최적화함으로써 더 빠르게 고객에게 가치를 전달하려는 접근이기 때문이다.[^10]
[? 질문] DevOps를 실현하기 위해 AWS에서 특히 어떤 영역(도구/서비스)을 중점적으로 봐야 하는가[^16]
[= 답] 이 세션은 DevOps를 위한 AWS 서비스 중에서도 (1) 코드 기반 인프라 구성(IaC) 과 (2) 애플리케이션 배포 자동화(CI/CD) 에 직접적으로 연관된 서비스를 중심으로 다룬다.[^16]
[? 질문] IaC(Infrastructure as Code)는 왜 필요하고, CloudFormation/CDK는 어떤 문제를 해결하는가[^22]
[= 답] 사람이 반복적으로 환경을 구성할 때 생기는 휴먼 에러, 개발/테스트에서는 없던 문제가 운영에서 터지는 환경 불일치, 변경 추적·롤백의 어려움 같은 전형적 문제를 IaC로 줄일 수 있으며, AWS 네이티브 IaC인 CloudFormation 과 이를 프로그래밍 언어로 더 생산적으로 작성하게 해주는 AWS CDK 가 이를 지원한다.[^23]
2. 큰 그림[^2]
이 콘텐츠는 “DevOps를 위한 다양한 AWS 서비스 소개”라는 주제로, DevOps의 정의(문화/사례/도구)부터 시작해 AWS에서 DevOps를 구현할 때 자주 쓰는 IaC(CloudFormation, CDK) 및 CI/CD(Cloud9, CodePipeline, CodeBuild, CodeDeploy) 를 흐름에 따라 설명한다.[^9] 또한 멀티 계정/멀티 리전 확장, 템플릿 린팅, 스택 분해(계층화) 같은 실무 관점의 모범 사례도 함께 제시한다.[^55]
- DevOps의 본질은 개발과 운영의 통합 “그 자체” 가 아니라, 이를 가능하게 하는 문화·사례·도구의 조합이며 목표는 “더 빠른 고객 가치 전달”이다.[^10]
- IaC는 인프라를 버전 관리/재현 가능/롤백 가능 하게 만들어 환경 불일치와 반복 작업의 오류를 줄이고, CloudFormation/CDK가 AWS 네이티브 방식으로 이를 제공한다.[^26]
- CI/CD 자동화는 코드 커밋부터 빌드/테스트/배포까지의 릴리즈 프로세스를 파이프라인으로 묶어 반복 가능하게 만들며, AWS Developer Tools가 이를 서비스 형태로 지원한다.[^69]
3. 하나씩 살펴보기[^6]
3.1 세션 시작: 진행 방식과 전체 구성[^1]
발표자는 AWS Builders 행사 세션에 참석한 사람들에게 인사를 하고, 자신이 AWS에서 솔루션스 아키텍트 로 근무하는 김주현이라고 소개한다.[^3] 세션 주제는 “DevOps를 위한 다양한 AWS 서비스 소개”이며, 이후 진행 흐름은 (1) DevOps가 무엇인지 정의/구성요소를 살펴보고, (2) DevOps를 위한 AWS 도구들을 설명하는 순서로 구성되어 있음을 안내한다.[^6]
또한 질문은 GoToWebinar(화면에 보이는 질문 UI)에서 Questions 창을 통해 남길 수 있으며, 기본적으로 질문은 공개 답변이지만 “비공개”로 요청하면 질문자만 답변을 받는 방식도 가능하다고 안내한다.[^4]
3.2 DevOps는 왜 사람마다 다르게 말하는가: 정의와 확장된 의미[^7]
발표자는 “DevOps가 무엇인가”를 묻는다면 같은 자리(예: 10명이 앉아 있다고 가정)에서도 10개의 답변이 조금씩 다를 수 있다 고 말한다.[^7] 그 이유는 DevOps가 실행되는 범위와 형태 에 따라 매우 다양한 모습으로 구현될 수 있기 때문이다.[^8]
그럼에도 “오피셜하게” DevOps는 소프트웨어 개발(Development) 과 운영(Operation) 의 합성어라고 정리할 수 있지만, 발표자는 즉시 “단순히 개발과 운영의 통합을 의미하는 것이 아니다”라고 선을 긋는다.[^9] DevOps는 더 넓게는 다음을 포함하는 조합으로 이해해야 한다고 설명한다.[^10]
- 문화(culture): 사고방식의 변화, 팀 간 장벽 제거, 주인의식
- 사례(practices): 자동화/단순화, 느슨한 결합, 잦은 배포, 품질 향상 기법
- 도구(tools): CI/CD, IaC, 모니터링/로깅 등 DevOps를 실제로 가능하게 만드는 수단
이 조합을 통해 개발자의 생산성 과 운영의 안정성 을 함께 최적화하면, 기업은 새로운 기능/개선된 서비스를 더 빠르게 고객에게 전달할 수 있다는 것이 DevOps의 궁극적 의미라고 제시한다.[^10]
[c DevOps의 목표는 “개발 생산성 + 운영 안정성”을 동시에 끌어올려 고객 가치 전달 속도를 높이는 것이다.][^10]
3.3 DevOps의 3요소 ① 문화: ‘사고방식’과 책임의 재정의[^11]
발표자는 DevOps를 이루는 3요소 중 첫 번째로 문화를 들고, 이는 곧 사고방식(mindset) 의 변화라고 정의한다.[^11] DevOps로 전환하려면 “사고의 방식 변화”가 필요하다는 점을 강조한다.[^12]
핵심은 기존에 쌓여 있던 개발 팀과 운영 팀 사이의 장벽을 없애는 것이다.[^13] 조직에 따라서는 원래부터 개발/운영이 분리되지 않고 한 엔지니어가 두 업무를 모두 수행할 수도 있다고 말하면서, 중요한 것은 직무 경계가 아니라 최종 고객 요구를 중심에 놓고 자신이 어떻게 문제 해결에 기여하는지 고민하는 태도라고 설명한다.[^14]
이 관점이 강화되면 사람들은 “명시된 역할/직책의 범위를 넘어” 서비스에 대한 완전한 주인의식(ownership) 을 갖게 된다고 한다.[^14] 또한 DevOps 문화는 개발팀과 운영팀만의 통합이 아니라, 경우에 따라 QA 팀, 보안 팀 등도 유기적으로 통합될 수 있다고 덧붙인다.[^15]
결론적으로 조직 구성이 어떻든, 전체 개발 및 인프라 수명주기를 ‘소수(=특정 팀/개인)의 책임’이 아니라 하나의 책임으로 간주하는 태도가 DevOps 문화라고 정리한다.[^15]
[!IMPORTANT] DevOps 문화의 요지[^15]
개발/운영/QA/보안 등 기능조직의 경계를 넘어서, 제품/서비스의 전체 수명주기를 함께 책임지는 방향으로 사고방식을 바꾸는 것.[^15]
3.4 DevOps의 3요소 ② 사례(Practices): 자동화·단순화·아키텍처/품질 전략[^18]
두 번째 요소로 발표자는 사례(practices), 즉 “DevOps 방식”을 제시한다.[^17] 이는 소프트웨어 개발과 인프라 관리 프로세스를 자동화하고 단순화하여 더 빠르게 혁신하도록 돕는 주요 방식들의 묶음이라고 설명한다.[^18]
발표자가 예로 든 DevOps 사례/검토 항목들은 다음과 같다.[^19]
- 느슨하게 결합된(loosely coupled) 아키텍처를 사용하고 있는가
- 애플리케이션 결함을 줄이기 위해 작은 단위로 자주 배포하고 있는가
- 코드 품질을 높이기 위해 사용 중인 방법이 있는가
- 유연성과 개발 속도를 높이기 위해 마이크로서비스 아키텍처를 사용하고 있는가
여기서 중요한 뉘앙스는 “DevOps를 한다”는 것이 특정 도구 도입만이 아니라, 배포 단위/빈도, 아키텍처 결합도, 품질 확보 방식 같은 일하는 방식 자체를 바꾸는 것을 포함한다는 점이다.[^19]
3.5 DevOps의 3요소 ③ 도구(Tools): 실현 수단 없이는 DevOps가 아니다[^20]
세 번째 요소는 도구(tools) 이다.[^20] 발표자는 문화와 방식을 “세팅했다” 해서 충분한 것이 아니며, 이를 실현할 도구가 필요하다고 말한다.[^20]
그 이유를 직관적인 예로 설명한다: 마이크로서비스 아키텍처를 채택해 놓고도 각 서비스를 수동 배포한다면, 그것은 DevOps라고 할 수 없다는 것이다.[^21] 따라서 배포 프로세스를 자동화할 도구가 필요하고, DevOps 도구 범주로는 다음을 열거한다.[^22]
- CI/CD(지속적 통합/배포)
- IaC(코드 기반 인프라)
- 로깅/모니터링
이후 발표자는 DevOps의 “모범 사례” 범주를 조금 더 확장해 나열한다: 지속적 통합, 지속적 전달, 마이크로서비스, IaC, 모니터링/로깅, 커뮤니케이션/협업.[^23] 그리고 최근에는 DevOps 환경에서 보안까지 고려해 DevSecOps 라는 단어도 사용한다고 언급한다.[^24]
3.6 DevOps 핵심 개념들: CI/CD, 마이크로서비스, IaC, 모니터링/로깅, 보안[^25]
발표는 DevOps에서 자주 등장하는 키워드들을 정의 형태로 정리한다.[^25]
3.6.1 CI/CD란 무엇인가[^25]
CI/CD는 Continuous Integration(지속적 통합) 과 Continuous Delivery(지속적 전달) 를 의미한다.[^25] 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하고, 빌드/테스트 과정을 거쳐 프로덕션 릴리즈까지 이어지는 각 과정들을 포함한다고 설명한다.[^25]
3.6.2 마이크로서비스 아키텍처란[^26]
마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 작은 서비스 집합으로 구축하는 방식이라고 정의한다.[^26]
3.6.3 IaC(Infrastructure as Code)란[^27]
IaC는 버전 제어, 지속적 통합 같은 코드/소프트웨어 개발 기법을 사용해 인프라를 프로비저닝하고 관리하는 방법이라고 말한다.[^27]
3.6.4 모니터링/로깅의 필요성[^28]
모니터링과 로깅은 DevOps 여부와 관계없이 중요한 요소이며, 기업은 지표와 로그를 모니터링해 애플리케이션/인프라 성능이 엔드 유저에게 어떤 영향을 미치는지 확인해야 한다고 말한다.[^28]
3.6.5 보안(DevSecOps)의 관점[^29]
견고한 DevOps 환경에서 보안은 필수이며, 설계 단계에서 보안을 포함하고, 지속적 보안 테스트 자동화, 규정 준수 모니터링을 통해 이를 확장하는 것이 중요하다고 말한다.[^29]
3.7 오늘 세션의 범위 선언: IaC + 애플리케이션 배포 자동화 중심[^16]
발표자는 오늘 다룰 AWS 서비스 범위를 명확히 제한한다. DevOps를 위한 다양한 AWS 서비스 중에서도 특히 인프라 구성 자동화(IaC) 와 애플리케이션 배포 자동화에 관련된 부분을 살펴보겠다고 한다.[^16]
3.8 IaC로 인프라 구성하기: “애플리케이션 관리 = 코드 + 인프라”[^30]
발표자는 IaC 설명에 들어가며 “애플리케이션을 관리한다”는 뜻은 비즈니스 로직을 구성하는 코드뿐 아니라 애플리케이션 밑단의 인프라 관리까지 포함한다고 말한다.[^30]
예를 들어 AWS 위에 웹 애플리케이션을 구축했다면, 화면에 보이는 VPC, 서브넷, IGW(Internet Gateway) 같은 네트워킹 구성요소들 역시 관리 대상에 포함된다는 것이다.[^31]
그 다음 AWS에서 인프라를 생성하는 방법을 “난이도/자동화 관점”으로 나열한다.[^32]
- AWS 관리 콘솔(웹 브라우저)에서 직접 생성
- AWS CLI / SDK 사용
- IaC 도구인 AWS CloudFormation 또는 AWS CDK 사용
처음 시작하는 사람에게는 콘솔이 가장 쉬운 접근이지만, 이 방식은 자동화가 어렵고, 많은 리소스를 한 번에 생성하기에도 적합하지 않다고 지적한다.[^33]
CLI/SDK는 자동 생성과 벌크 생성이 가능할 수 있으나, CLI는 같은 명령을 “똑같이 재연”하기가 쉽지 않고, SDK는 주로 AWS 서비스 액세스를 용이하게 하는 용도로 사용된다고 설명한다.[^34]
이러한 이유로 “화면 가장 아래에 있는” IaC 툴인 CloudFormation/CDK를 통해 자원을 관리하는 것이 대부분의 DevOps 시나리오에 적합하다고 결론 내린다.[^35]
3.9 “왜 IaC가 필요한가”: DevOps 팀이 겪는 3가지 문제와 해결 논리[^36]
발표자는 한 단계 더 원론적인 질문을 던진다.[^36]
[? 질문] IaC(코드 기반 인프라)는 왜 필요한가[^36]
[= 답] 반복 구성에서 생기는 휴먼 에러, 환경 불일치로 인한 운영 장애, 변경 추적/롤백 어려움 같은 DevOps 팀의 고질적 문제를 해결하기 때문이다.[^37]
그는 DevOps 팀이 흔히 겪는 문제로 “3R”을 언급하며(발음이 불명확하지만 맥락상 Repeatable/Reusable/Reliable 류의 반복·재현·신뢰성 문제를 지칭), 핵심 현상을 구체적으로 설명한다.[^37]
- 사람이 반복적으로 같은 환경을 구성하면 휴먼 에러로 가끔 다른 결과가 나온다.[^38]
- 개발 환경 테스트에서는 문제가 없었는데 프로덕션에서 예상치 못한 이슈가 발생할 수 있다.[^39]
이런 인프라 관리 문제를 IaC로 해결할 수 있으므로 IaC가 필요하다고 연결한다.[^40]
또한 IaC의 특성/장점을 다음처럼 설명한다.[^41]
- IaC는 소스코드처럼 버전 관리된다 → 환경 내 변화 추적 가능[^41]
- 버전 변경 시 “어떤 변경이 있었는지” 기록을 명확히 인지 가능[^41]
- 문제 발생 시 이전 인프라 환경으로 롤백이 비교적 쉬움[^42]
- 동일한 구성 파일/코드만 있으면 같은 모양의 붕어빵을 찍듯 동일 환경을 여러 개 만들 수 있음(비유)[^43]
- 개발 환경과 운영 환경 차이에서 오는 문제를 줄이고, 동일 환경에서 테스트하여 운영을 더 견고하게 만들 수 있음[^44]
+++ 상세 비유: 붕어빵 틀과 동일 환경 재현[^43]
발표자는 “붕어빵 틀”을 예로 든다. 틀(=동일한 구성 파일/코드)이 있으면 붕어빵을 계속 같은 모양으로 찍어낼 수 있듯이, IaC 코드가 있으면 현재 아키텍처와 똑같은 환경을 여러 개 만들어낼 수 있다는 논리다. 이를 통해 개발/테스트/운영 환경 차이로 생기는 문제를 줄이고 운영 환경을 견고하게 할 수 있다고 설명한다.[^43]
+++
3.10 AWS의 IaC 옵션: CloudFormation/CDK vs 서드파티 도구[^45]
IaC 방식에서 AWS 네이티브 옵션으로 AWS CloudFormation 과 AWS CDK가 있고, 서드파티 도구로는 Terraform, Chef, Puppet 등을 언급한다.[^45]
또한 코드 기반 인프라 구성의 일반적 프로세스를 다음과 같은 반복 사이클로 설명한다.[^46]
- 코드/인프라 템플릿 작성 → 2) 배포 → 3) 실제 환경에서 사용 → 4) 최적화를 위해 반복[^46]
3.11 AWS CloudFormation: 무엇이고 어떻게 동작하는가[^47]
3.11.1 CloudFormation의 정의와 목적[^47]
CloudFormation은 AWS 리소스를 모델링/설정하여 리소스 관리 부담을 줄이고, 사용자가 리소스 위에서 동작하는 애플리케이션에 더 집중하도록 돕는 서비스라고 정의한다.[^47]
필요한 모든 AWS 리소스(예: EC2 인스턴스, RDS 관련 값)를 템플릿에 기재하면, CloudFormation이 해당 리소스의 프로비저닝과 구성을 담당한다.[^48] 이를 통해 사용자는 리소스를 개별적으로 만들고 구성할 필요가 없고, 관련 의존성(dependency) 을 모두 파악할 필요도 줄어든다고 설명한다.[^49]
3.11.2 CloudFormation 프로비저닝의 큰 흐름(아티팩트 중심)[^50]
CloudFormation을 통해 리소스를 프로비저닝하는 큰 흐름은 다음 순서로 제시된다.[^50]
- YAML 또는 JSON으로 템플릿 작성
- 또는 매크로, AWS CDK 같은 하이레벨 언어로 코드 생성 가능[^50]
- 템플릿을 저장/업로드
- 로컬에 저장 후 콘솔에서 업로드
- S3에 저장 후 업로드
- CI/CD 파이프라인에서 템플릿 테스트 후 업로드[^51]
- 콘솔/CLI/CDK로 템플릿에서 스택(Stack) 생성
- 또는 여러 계정/리전에서 스택을 생성/업데이트/삭제할 수 있게 하는 스택셋(StackSet) 생성[^52]
- 생성된 스택을 통해 AWS 리소스가 프로비저닝됨[^53]
발표자는 위 흐름에서 언급한 것들이 CloudFormation의 핵심 아티팩트라고 말하며, 다음에서 하나씩 뜯어보겠다고 연결한다.[^54]
3.12 CloudFormation 핵심 아티팩트: 템플릿과 스택[^56]
3.12.1 템플릿과 스택의 관계[^56]
- 코드는 “템플릿”이라는 파일에 기록된다.[^56]
- “스택”은 템플릿을 통해 생성(발생)된다.[^56]
- 템플릿은 애플리케이션을 위한 리소스를 정의하며 리소스의 “desired state(의도된 상태)”를 설명한다.[^57]
- 각 리소스는 속성으로 구성되며, 의존성은 명시적으로 선언하거나 암묵적으로(자동으로) 추론될 수 있다.[^57]
- CloudFormation은 사용자의 의도를 API 호출로 변환해 리소스를 프로비저닝한다.[^58]
추가로, CloudFormation을 사용하면 500개 이상의 AWS 리소스를 생성할 수 있다고 언급한다.[^59]
3.12.2 템플릿 구조(YAML 예시)와 각 섹션 의미[^60]
발표자는 JSON보다 YAML이 읽기 쉬워 YAML 기반 예시를 준비했다고 하고, 템플릿 구조를 위에서부터 설명한다.[^60]
- (선택) 템플릿 버전: 기입은 선택사항[^61]
- Description: 템플릿 목적을 명확히 함[^62]
- 개발 시 주석을 강조하듯, Description을 상세히 적는 것이 매우 중요하다고 강조[^62]
- Parameters: 스택 생성 시 사용자에게 “질문”을 던지는 항목[^63]
- 예:
EnvironmentType같은 파라미터를 만들고 AllowedValues에 test/dev/prod를 넣으면, 스택 생성 시 사용자가 3가지 중 하나를 선택[^63]
- 예:
- Mappings: “파라미터와 비슷하지만 코드 내부에 채워진 값”[^64]
- 예: 리전별 AMI를 매핑해두면, 스택 생성 시 실행 AMI가 자동 선택됨[^64]
- 발표자는 이를 “코드가 동적으로 구동되는 형태와 유사”하다고 비유[^65]
- Conditions: 조건이 참일 때만 리소스를 생성[^66]
- 예: 파라미터가 test일 때 EC2를 2개만 배포하는 등 환경별 제어 가능[^66]
- Resources: 템플릿에서 유일하게 반드시 명시해야 하는 부분이며 실제 생성할 리소스를 기재[^67]
- Outputs: 리소스 프로비저닝 후 출력할 값(예: 웹 애플리케이션의 IP 등)[^68]
[!TIP] CloudFormation 템플릿 작성 시 Description을 “주석처럼” 상세히 남겨라[^62]
템플릿 목적이 명확해져 협업/유지보수에서 큰 차이를 만든다는 맥락으로 강조된다.[^62]
3.12.3 예제 템플릿: 리소스 참조로 구성요소 연결[^69]
발표자는 예제 템플릿을 보여주며, Description을 통해 이 템플릿이 Code Repository(CodeCommit)와 Cloud9 환경을 위한 것임을 유추할 수 있다고 말한다.[^69] Resources에는 CodeCommit과 Cloud9이 명시된 것을 확인할 수 있다고 한다.[^70]
여기서 추가로 강조하는 포인트는 리소스 간 참조(reference) 이다.[^71] Cloud9 부분에서 앞에서 생성한 CodeCommit 리포지토리의 Clone URL(HTTP 속성)을 참조하는 부분이 보인다고 설명한다.[^71]
이 방식이 의미하는 바는, 애플리케이션을 구축할 때 비즈니스 로직을 따라 리소스들을 서로 연결하듯이, CloudFormation에서도 리소스를 연결/조합할 수 있다는 점이다.[^72] 또한 CloudFormation의 다양한 내장 함수로 스택을 관리할 수 있다고 덧붙인다.[^73]
3.13 스택 업데이트와 Change Set: “바꾸지 말고 업데이트하라”[^74]
발표자는 템플릿에 리소스/속성을 정의했다면 이를 실현하기 위해 스택을 생성해 프로비저닝한다고 다시 정리한다.[^74]
그리고 스택 설정이나 리소스를 변경해야 할 때, 스택을 삭제하고 새로 만드는 대신 스택을 업데이트해야 한다고 말한다.[^75] 예로, 스택에 EC2 인스턴스가 있을 때 스택 업데이트로 인스턴스 AMI를 변경할 수 있다고 든다.[^76]
스택 업데이트 시에는 “새 파라미터 입력값” 또는 “업데이트된 템플릿” 같은 변경사항을 제출한다.[^77] CloudFormation은 제출된 변경사항을 현재 스택 상태와 비교해 변경되는 리소스만 업데이트한다.[^78]
다만 업데이트는 속성 종류에 따라 리소스를 중단시키거나, 업데이트된 리소스를 대체(replace) 할 수도 있다고 설명한다.[^79] 따라서 업데이트가 실행 중 리소스에 어떤 영향을 미치는지 파악하는 것이 도움이 된다고 말한다.[^80]
이를 위해 CloudFormation의 Change Set(체인지 셋) 을 소개한다.[^81] Change Set을 사용하면 스택 변경이 실행 중 리소스에 미칠 영향을 미리 확인할 수 있으며, 사용자가 “실행하기로 결정”할 때만 실제 변경이 반영되므로 실수로 크리티컬 리소스를 삭제하는 등의 사고를 미연에 방지할 수 있다고 설명한다.[^82]
[c 스택 변경 전 Change Set으로 영향도를 확인하면 ‘실수로 중요한 리소스를 삭제’ 같은 사고를 예방할 수 있다.][^82]
3.14 멀티 계정/멀티 리전 확장: StackSets[^83]
발표자는 AWS를 “헤비하게” 쓰면 여러 계정, 여러 리전을 쓰는 경우가 많다고 전제한다.[^83] 이때 CloudFormation을 어떻게 확장해 사용할지 고민하게 되는데, 이를 위한 기능이 StackSets(스택 셋) 이라고 설명한다.[^84]
스택 셋을 생성하면 스택 셋을 위한 스택들을 생성할 수 있고, 생성 후에도 언제든지 추가 계정/리전에 대한 스택을 추가할 수 있다고 한다.[^85]
3.15 CloudFormation 실무 팁 ① 배포 전 템플릿 검증: cfn-lint[^86]
발표자는 “템플릿 작성 후 바로 업로드”할 수 있지만, 템플릿에 에러가 있으면 리소스가 프로비저닝되지 않아 시간이 낭비된다고 말한다.[^86] 따라서 배포 전 로컬 단계에서 오류를 잡는 것이 중요하다는 흐름으로, 오픈소스 툴 cfn-lint(CFN Lint)를 소개한다.[^87]
cfn-lint를 사용하면 배포 전에 에러를 인지하고 수정할 수 있으며, 화면 예시처럼 “몇 번째 줄에 어떤 에러가 있는지” 손쉽게 확인할 수 있다고 한다.[^88]
[!TIP] cfn-lint로 “배포 전에” 템플릿 오류를 잡아라[^87]
프로비저닝 실패로 시간을 낭비하기 전에 로컬에서 템플릿 품질을 올리는 실무적 접근이다.[^87]
3.16 CloudFormation 실무 팁 ② 모범 사례: ‘CloudFormation 케이크’(계층화)와 라이프사이클 분리[^89]
발표자는 모범 사례 몇 가지를 제시한다.[^89]
처음 소규모 리소스를 프로비저닝할 때는 한 템플릿 파일에 관련 정보를 모두 명시하는 것이 효율적일 수 있다.[^90] 하지만 워크로드 규모가 커질수록 모든 리소스를 하나의 템플릿에 넣지 말고, 화면처럼 계층화된 아키텍처 빌드 방식으로 만들어야 한다고 조언한다.[^91]
이 계층적 구성 방식을 케이크에 비유해 “CloudFormation 케이크”라고도 부르며, 성격이 유사한 것끼리 묶어 층을 나누는 모습을 설명한다.[^92]
또한 리소스의 라이프사이클을 염두에 두는 것이 중요하다고 말한다.[^93] 예를 들어 네트워킹/보안은 애플리케이션 바이너리 파일이나 데이터베이스 같은 요소가 변경될 때 함께 변경될 가능성이 적다는 점을 든다.[^93]
마지막으로 이렇게 분리하면 다음 장점이 있다고 정리한다.[^94]
- 실수로 자원이 삭제되는 것을 막기 쉬움[^94]
- 필요한 부분만 업데이트되므로 변경 영향 최소화[^94]
- 리소스 “캐스팅”(비용/구성 파악) 및 트러블슈팅이 용이[^94]
3.17 CloudFormation 실무 팁 ③ Drift Detection: 수동 변경으로 생기는 불일치 잡기[^95]
IaC의 이상적인 가정은 “리소스 관련 모든 작업을 IaC로 한다”는 것이지만, 현실에서는 급하게 일부 변경을 반영하려고 수동으로 콘솔에서 수정하는 일이 생긴다고 말한다.[^95]
이런 “관리되지 않은 변경”은 실행 중인 스택 구성이 템플릿에서 드리프트(drift) 되어, 의도한 상태와 실제 리소스 상태가 불일치하게 만든다.[^96]
이 상황을 해결하기 위해 드리프트 감지(Drift Detection) 기능을 사용한다고 설명한다.[^97] 이 기능으로 전체 스택 또는 특정 리소스의 드리프트를 감지하고 “몇 분 안에” 결과를 볼 수 있으며, 그 결과를 바탕으로 템플릿을 업데이트하거나 리소스를 “규정 준수 상태”로 되돌리는 데 필요한 정보를 얻을 수 있다고 한다.[^98]
3.18 CloudFormation 실무 팁 ④ 비밀정보(패스워드) 처리: SSM Parameter Store 사용[^99]
발표자는 마지막 모범 사례로 DB 패스워드 같은 중요한 정보를 어떻게 다루는지 언급한다.[^99] 애플리케이션 로직 작성 시에도 패스워드를 하드코딩하지 않는 이유는 코드가 외부에 탈취되면 보안적으로 취약해지기 때문이라고 설명한다.[^100]
동일한 이유로 CloudFormation/IaC에서도 중요한 정보는 템플릿/코드에 직접 넣지 말고, AWS Systems Manager Parameter Store에 저장한 뒤 불러오는 방식으로 작성하는 것이 중요하다고 말한다.[^101]
[c 패스워드 같은 민감정보는 IaC 템플릿에 하드코딩하지 말고 SSM Parameter Store에 저장/참조하라.][^101]
3.19 AWS CDK 소개: “프로그래밍 언어로 IaC를 작성하고 CloudFormation으로 배포”[^102]
발표자는 다음 주제로 AWS CDK를 소개하지만, 다음 세션에서 더 자세히 다룰 예정이라 여기서는 개념만 짚고 넘어간다고 말한다.[^102]
AWS CDK는 인프라를 재사용 가능한 구성요소로 모델링하기 위한 개발 프레임워크이며, 익숙한 프로그래밍 언어로 클라우드 인프라를 “코드로 정의”하고 CloudFormation으로 배포하는 원리로 동작한다고 설명한다.[^103]
CDK가 지원하는 언어로 TypeScript, JavaScript, Python, Java, C# 을 열거하며, 이를 통해 개발뿐 아니라 인프라 선언도 동시에 수행할 수 있다고 말한다.[^104]
3.19.1 CDK의 구성요소 3가지[^105]
CDK는 3가지 구성요소로 이뤄진다고 설명한다.[^105]
- AWS CDK Framework(코어 프레임워크)
- 하나 이상의 스택이 포함된 앱을 만들고 구성[^106]
- Stacks(스택)
- 여러 리소스를 포함하며 CloudFormation 스택에 매핑되는 단위[^107]
- 서로 다른 라이프사이클의 리소스는 서로 다른 스택에 놓는 것이 좋다는 앞선 원칙을 재강조[^108]
- AWS Construct Library(컨스트럭트 라이브러리)
- AWS 특정 서비스 리소스를 생성하기 위한 구성요소 집합[^109]
- 프로젝트에 필요한 의존성만 선택해 사용할 수 있음[^110]
- 사용 편의성과 빠른 반복에 적합하도록 모범 사례와 고려사항을 반영해 만들어져 있다고 설명[^110]
또한 CDK CLI는 프로젝트 구조 초기화, 배포 상태와 배포 예정 상태의 차이점 검사, AWS 환경에 쉽게 반영하는 작업을 지원한다고 말한다.[^111]
3.19.2 CDK의 동작 흐름: init → build → synth → deploy → diff[^112]
CDK는 소스코드를 컴파일해 “어셈블리 언어 형태의 CloudFormation 템플릿”을 만들고, 이를 CloudFormation 스택으로 배포해 안전하고 반복 가능한 방식으로 리소스를 프로비저닝한다고 설명한다.[^112]
사용 흐름은 다음과 같이 단계적으로 설명된다.[^113]
cdk init로 프로젝트 시작 → 특정 언어의 프로젝트 구조 생성[^113]- 사용자는 앱을 만들고 스택 컨투어링(구성) 및 리소스 추가[^114]
- 프로젝트 빌드 (예: TypeScript면
npm run build)[^115] - 작성 코드를 CloudFormation 템플릿으로 컴파일
cdk synth를 사용하면 “Cloud Assembly”라 불리는 템플릿과 기타 파일 생성[^116]
cdk deploy로 CloudFormation 적용 → 계정에 리소스 프로비저닝[^117]- 이후 수정/반영 시 빌드+디플로이 반복, 배포 전에는
cdk diff로 변경사항 체크[^118]
3.19.3 CloudFormation vs CDK: 장단점 비교 논리[^119]
발표자는 화면에서 CDK 코드와 CloudFormation 코드 일부를 비교하며, CDK는 프로그래밍 언어의 모든 기능을 활용해 AWS 인프라를 코드로 정의하는 개발자 중심 도구로 볼 수 있다고 말한다.[^119]
CDK는 CloudFormation을 활용하므로, 안전한 배포, 자동 롤백, 드리프트 감지 등 CloudFormation이 제공하는 이점을 그대로 누릴 수 있다고 설명한다.[^120] 또한 실제로 두 방식을 애플-투-애플로 비교하면, CloudFormation으로 리소스를 작성할 때보다 CDK로 작성할 때 더 적은 소스코드로 같은 결과를 만들 수 있다고 한다.[^121]
반면 운영자 관점에서는 프로그래밍 언어 역량이 필요해 러닝 커브가 있을 수 있으므로, 이런 특징을 고려해 자신에게 적합한 툴을 선택하는 것이 중요하다고 결론낸다.[^122]
3.20 애플리케이션 배포 자동화로 전환: CI/CD 파이프라인의 전체 그림[^123]
앞에서 코드 기반 인프라 구성(IaC)을 다뤘고, 이제는 애플리케이션 배포 자동화를 살펴보겠다고 전환한다.[^123]
발표자는 화면의 다이어그램(일반적인 CI/CD 흐름)을 많은 사람이 한 번쯤 봤을 것이라고 말하며, 이 전체 프로세스를 CI/CD 파이프라인이라고 부른다고 설명한다.[^124] 이것은 지속적 통합, 지속적 전달, 지속적 배포의 레이아웃이며, 개발자가 소스코드를 리포지토리에 푸시하면 일련의 과정을 거쳐 프로덕션 환경에 변경사항이 반영된다고 말한다.[^125]
이 릴리즈 프로세스에서 DevOps의 모범 사례는 “이 모든 프로세스를 자동화하는 것”이라고 다시 한번 강조한다.[^126]
3.21 AWS Developer Tools 개요: 파이프라인 단계별 서비스 매핑[^127]
발표자는 방금 본 릴리즈 프로세스의 각 단계에 매핑되는 AWS 서비스를 소개한다.[^127] 사용자는 CI/CD를 위한 AWS 개발자 도구를 통해 프로세스를 자동화하여 소프트웨어 개발/릴리즈 주기를 가속할 수 있고, 다른 AWS 서비스와도 쉽게 연동할 수 있다고 한다.[^128]
AWS 개발자 도구는 다음을 지원한다고 설명한다.[^129]
- 애플리케이션 소스코드를 안전하게 저장하고 버전 관리
- AWS 또는 온프레미스 환경에서 애플리케이션을 자동으로 구축/테스트/배포
또한 더 넓게 보면 “처음 개발 코드를 작성하는 환경”부터 AWS 위에서 시작할 수 있다고 말하면서, 그 예로 AWS Cloud9을 소개한다.[^130]
3.22 Cloud9: 브라우저 기반 개발 환경과 협업/접근성[^131]
AWS Cloud9을 사용하면 웹브라우저에서 코드를 작성·실행·디버깅할 수 있다고 설명한다.[^131] Cloud9은 클라우드 기반 IDE로, 프로그래밍 언어를 위한 필수 도구가 사전에 패키징되어 있고 브라우저에서 실행되므로, 사무실/집 등 어디서든 인터넷만 연결되면 작업을 계속할 수 있다고 말한다.[^132]
또한 팀과 개발환경을 공유하면 코드 협업이 쉬워지는 이점이 있으며, AWS에서 애플리케이션 개발에 필요한 SDK 라이브러리/플러그인을 제공해 개발을 수월하게 한다고 설명한다.[^133] 그리고 터미널에서 AWS에 직접 액세스해 컨트롤할 수 있는 특징도 가진다고 덧붙인다.[^134]
발표자는 Cloud9에서 개발 작업을 한 뒤 코드를 저장소에 반영하면, 미리 구축된 CodePipeline이 동작하고 최종적으로 애플리케이션이 변경되는 형태로 보면 된다고 연결한다.[^135] 그리고 배포 이후에는 모니터링을 붙여 애플리케이션이 정상 동작하는지/최적화 지점이 있는지 파악할 수 있다고 말한다.[^136]
3.23 CodePipeline: 관리형 릴리즈 파이프라인 오케스트레이션[^137]
발표자는 CI/CD에서 소스-빌드-테스트-디플로이를 하나로 묶어 “CodePipeline”이라고 표시했다고 말하며, AWS CodePipeline을 정의한다.[^137]
CodePipeline은 애플리케이션 및 인프라를 업데이트하기 위한 릴리즈 파이프라인을 자동화하는 데 도움이 되는 완전 관리형 지속적 전달(Continuous Delivery) 서비스라고 설명한다.[^137] 완전 관리형이므로 인프라에 대해 사용자가 신경 쓸 필요가 없다고 강조한다.[^138]
CodePipeline을 통해 CodeBuild, CodeDeploy, 기타 도구를 사용하는 CI 또는 CD 워크플로우를 구축할 수 있으며, 사용자의 선호에 따라 AWS 서비스뿐 아니라 Jenkins 같은 타사 서비스와도 손쉽게 통합할 수 있다는 이점이 있다고 말한다.[^139]
3.23.1 CodePipeline의 스테이지 옵션: 소스/빌드/배포 트리거와 대상[^140]
파이프라인 구축 시 각 스테이지에서 선택 가능한 옵션을 설명한다.[^140]
-
소스(Source) 단계:
- CodeCommit, GitHub 같은 리포지토리에서 소스 변경 시 트리거[^141]
- S3 버킷에 아티팩트가 들어올 때 트리거 가능[^142]
- 컨테이너 워크로드라면 컨테이너 이미지 변경 시에도 트리거 가능[^142]
- 스케줄링 또는 리소스 헬스 이벤트에 따라 트리거되는 경우도 언급[^143]
-
빌드(Build) 단계: 선택사항이라고 언급하며, 공급자로 AWS CodeBuild 및 Jenkins 등을 예로 든다.[^144]
-
배포(Deploy) 단계 대상:
- EC2 인스턴스, 온프레미스 서버, Lambda, ECS Fargate 등이 가능하다고 제시한다.[^145]
발표자는 예시 화면을 통해 “소스 코드를 푸시하면 빌드가 되고, 최종적으로 프로덕션 상태에 CloudFormation으로 변경분이 반영되는” 흐름을 확인할 수 있다고 말한다.[^146]
또한 모놀리식 환경에서는 하나의 CI/CD 파이프라인(1개)으로도 충분할 수 있지만, 마이크로서비스 아키텍처에서는 서비스별로 개별 파이프라인이 생성될 것이라고 설명한다.[^147]
3.24 CI(지속적 통합)와 CodeBuild: 자동 빌드/테스트의 품질·속도 효과[^148]
발표자는 지속적 통합(Continuous Integration) 을 “자동화된 빌드 및 테스트 후 개발자가 코드 변경사항을 중앙 리포지토리에 정기적으로 병합하는 방식”으로 설명한다.[^148] 그리고 지속적 개발 사례(=CI를 가능하게 하는 개발 습관/프로세스) 가 지속적 통합의 중요한 요소라고 말한다.[^149]
그는 CI에서 협업 개발의 일반적 흐름을 상세히 풀어 말한다.[^150]
- 여러 사람이 코드 작업을 한다.[^150]
- 코드 리포지토리는 서로 다른 버전의 코드를 유지 관리하고, 팀이 코드에 접근할 수 있게 한다.[^151]
- 개발자는 리포지토리에서 코드를 체크아웃해 로컬 복사본에서 변경하거나 새 코드를 작성한다.[^152]
- 코드를 컴파일/테스트한 후, 다시 리포지토리에 커밋한다.[^152]
- 이 과정을 빈번하게 수행한다.[^152]
지속적 통합의 핵심 목표는 버그를 신속히 찾아 해결하고, 소프트웨어 품질을 개선하며, 업데이트를 검증/릴리즈하는 데 걸리는 시간을 단축하는 것이라고 정리한다.[^153]
3.24.1 CodeBuild의 역할과 특징[^154]
지속적 통합과 관련된 AWS 서비스로 AWS CodeBuild를 소개한다.[^154] CodeBuild는 소스코드를 컴파일하고 유닛 테스트를 실행하며 소프트웨어 패키지 생성 단계까지 마칠 수 있는 완전 관리형 빌드 서비스라고 설명한다.[^154]
특징으로는 다음을 강조한다.[^155]
- 빌드 볼륨에 맞게 자동 확장되어 여러 빌드를 동시에 병렬 처리 가능[^155]
- 빌드 작업이 몰릴 때 생길 수 있는 레이턴시 감소에 이점[^156]
- 빌드 속도 향상을 위한 빌드 환경 캐싱 기능 제공[^157]
- 각 빌드는 일관되고 변하지 않는 환경에서 진행되어 항상 동일한 결과를 얻을 수 있음[^158]
3.24.2 빌드 환경과 buildspec.yml: 실행 정의를 코드로 관리[^159]
CodeBuild에서 빌드를 실행하려면 “빌드 환경” 정보를 정해야 한다고 말한다.[^159] 빌드 환경은 CodeBuild가 빌드를 실행하기 위해 사용하는 운영체제, 프로그래밍 언어 런타임, 도구 조합을 의미한다.[^160]
AWS가 관리형으로 제공하는 빌드 환경 이미지가 있지만, 필요에 따라 커스텀 빌드 환경 이미지를 이용해 CodeBuild를 수행할 수도 있다고 설명한다.[^161]
또한 CodeBuild 실행을 위해서는 buildspec YAML 파일을 작성해야 한다고 말한다.[^162] buildspec은 CodeBuild가 빌드를 실행할 때 사용하는 “YAML 형식의 빌드 명령과 관련 설정 모음”이며, 코드 출처가 어디인지, 통합을 위해 어떤 명령을 실행해야 하는지 등을 작성해 buildspec 파일로 만들면 된다고 설명한다.[^163]
3.24.3 테스트 리포트(Report) 기능: 유닛테스트 결과 가시화[^164]
발표자는 앞서 buildspec에서 “리포트 위치”를 명세하는 부분을 언급하며, 유닛 테스트 보고서를 만들려면 리포트 결과 경로를 buildspec에 추가하고 CodeBuild에서 Report Group을 생성한 뒤 buildspec에 이를 붙여넣으면, 성공/실패, 수행 시간, 유닛테스트 세부 사항을 확인할 수 있다고 설명한다.[^164]
3.25 CD(지속적 배포/전달)와 CodeDeploy: 무중단, 자동 롤백, 배포 대상 다양성[^165]
발표자는 지속적 배포(Continuous Deployment) 를 “테스트를 위해 스테이징 환경에 새로운 변경 사항을 자동 배포하는 것”으로 설명한다.[^165]
일반적으로 빌드 단계까지가 CI의 영역이고, CD는 스테이징까지 가서 로컬 테스트를 넘어 통합 테스트, 부하 테스트 등을 수행한 뒤, 궁극적으로 프로덕션에 갈 아티팩트를 만드는 과정이라고 말한다.[^166]
지속적 배포에서 중요한 조건으로 다음을 든다.[^167]
- 고객 사용성에 영향을 미치지 않아야 함[^167]
- 프로덕션에서 변경 반영 시 제로 다운 패치(무중단 패치) 가 중요[^167]
- 변경을 애자일하게 반영하고 변경 실패율을 감소시키는 것이 목표[^168]
이를 위해 AWS는 AWS CodeDeploy를 제공한다고 소개한다.[^169] CodeDeploy는 테스트/스테이징/프로덕션 환경의 실제 인스턴스에 아티팩트를 배포하는 것으로 이해하면 된다고 말한다.[^169]
CodeDeploy의 특징으로는 다음을 제시한다.[^170]
- 복잡한 업데이트를 비교적 간단하게 핸들링[^170]
- 다운타임을 줄일 수 있음[^170]
- 에러 발생 시 자동 롤백 가능[^170]
- 이전 “작업본”을 다시 배포하는 형태로 롤백 수행이라고 설명[^171]
배포 대상(타겟)으로는 EC2, Lambda, Fargate, 온프레미스 서버가 될 수 있으며, 온프레미스 서버에는 에이전트를 설치하면 그 에이전트와 CodeDeploy가 통신해 배포 작업을 진행한다고 말한다.[^172]
3.25.1 appspec.yml과 라이프사이클 훅: 배포 절차를 명시적으로 정의[^173]
CodeBuild의 buildspec처럼, CodeDeploy에는 appspec 파일(appspec.yml) 이 있다고 설명한다.[^173] 이 파일은 배포가 실제로 진행되는 방식을 정의하며, 파일에 정의된 일련의 수명주기 이벤트 후크(hook) 로 각 배포를 관리한다고 한다.[^174]
발표자는 예시로 EC2 인스턴스에 변경분을 배포할 때 후크로 다음 작업을 스크립트로 정의할 수 있음을 설명한다.[^175]
- 로드 밸런서에서 인스턴스를 제거
- 의존 패키지 설치
- 웹 서버 재시작
- 테스트 수행
- 다시 로드 밸런서에 인스턴스를 추가
또한 배포 속도 및 배포 그룹을 정의할 수 있다고 말한다.[^176] 예를 들어 프로덕션 배포 시 한 번에 하나씩 진행하면, 이슈 발생 시 빠르게 롤백할 수 있다는 식으로 배포 전략을 설명한다.[^177] 그리고 “그룹”을 통해 배포 타겟을 정의할 수 있다고 덧붙인다.[^176]
3.26 end-to-end 예시: CodeCommit → CodeBuild(유닛테스트) → (카나리) CodeDeploy → 로드 테스트 → 프로덕션[^178]
발표자는 릴리즈 프로세스를 하나의 CodePipeline으로 구축했을 때의 예시를 정리해 제시한다.[^178]
- 코드 변경분이 CodeCommit에 반영된다.[^178]
- CodeBuild에서 유닛 테스트를 실행하며 빌드가 수행된다.[^179]
- 카나리 배포를 통해 스테이징 환경에 CodeDeploy로 배포된다.[^179]
- 로드 테스트를 수행한다.[^179]
- 궁극적으로 프로덕션 환경에 반영된다.[^179]
3.27 클로징: 조직마다 다르지만 목표는 같다—적합한 도구/방식 선택의 중요성[^180]
발표자는 약 40분 동안 DevOps를 위한 AWS 서비스들을 알아보았다고 마무리한다.[^180] DevOps는 조직/기업에 따라 다양한 형태로 “실험”될 수 있지만, 궁극적인 목표는 모두 같다고 재강조한다.[^181]
그 목표는 다시 한번 다음 문장으로 제시된다: 개발자의 생산성과 운영의 안정성을 모두 최적화함으로써 기업은 새로운 애플리케이션 기능 및 개선된 서비스를 더 빠르게 고객에게 전달하는 것을 목표로 한다.[^181]
이 목표를 실현하기 위해 “현재 상황에서 어떤 툴이 적합한지”, “어떤 방식을 채택하는 것이 적합한지”를 판단하는 것이 중요하다고 정리한다.[^182] 마지막으로 피드백 요청과 감사 인사를 전한다.[^183]
4. 핵심 통찰[^10]
-
DevOps는 “개발+운영의 합성어”를 넘어서 문화·사례·도구가 결합된 실행 체계이며, 목적은 속도 그 자체가 아니라 고객 가치 전달 속도를 높이기 위한 생산성/안정성의 동시 최적화다.[^10]
- 실행 시사점
- 개발/운영/QA/보안이 각자 최적화하는 구조가 아니라 “서비스 수명주기 공동 책임” 구조로 프로세스를 재설계한다.[^15]
- 실행 시사점
-
DevOps에서 “도구”는 부수적인 것이 아니라, 수동 작업을 자동화하여 DevOps의 문화/사례를 현실에서 작동하게 만드는 필수 요건으로 취급된다.[^20]
- 실행 시사점
- 마이크로서비스를 도입했다면, 서비스별 배포 자동화를 파이프라인으로 강제하지 않으면 DevOps 효과가 반감된다.[^21]
- 실행 시사점
-
IaC는 단순 편의가 아니라, 반복 구성에서의 휴먼 에러와 환경 불일치 같은 구조적 장애 요인을 제거하는 방법으로 제시된다.[^38]
- 실행 시사점
- 변경 추적/롤백 요구가 높은 인프라는 템플릿 기반으로 전환하고, 드리프트 감지로 수동 변경을 통제한다.[^97]
- 실행 시사점
-
CloudFormation은 “리소스 프로비저닝 도구”를 넘어, 스택 업데이트/Change Set/StackSets/Drift Detection 같은 운영 기능을 통해 “안전한 변경”을 돕는다는 점이 강조된다.[^82]
- 실행 시사점
- 운영 영향이 큰 스택은 업데이트 전 Change Set 검토를 프로세스에 포함한다.[^81]
- 실행 시사점
-
CDK는 CloudFormation의 안정성은 유지하면서, 프로그래밍 언어의 표현력을 활용해 더 적은 코드로 재사용 가능한 인프라 구성요소(Construct) 를 만들 수 있게 하는 “개발자 중심 IaC”로 포지셔닝된다.[^121]
- 실행 시사점
- 팀 역량(프로그래밍 언어 숙련도)에 따라 CloudFormation 템플릿 직접 작성 vs CDK를 선택한다.[^122]
- 실행 시사점
-
CI/CD 자동화는 CodePipeline이 “오케스트레이션”, CodeBuild가 “빌드/테스트”, CodeDeploy가 “배포/롤백/무중단 전략”을 담당하는 식으로 역할이 분리되어 설명된다.[^139]
- 실행 시사점
- buildspec/appspec에 절차를 선언적으로 남겨 파이프라인 실행이 사람의 기억/수작업에 의존하지 않도록 한다.[^162]
- 실행 시사점
5. 헷갈리는 용어 정리[^25]
- DevOps: 개발과 운영을 결합한 문화·철학·사례·도구의 조합으로, 생산성과 안정성을 함께 최적화해 고객 가치 전달을 가속하는 접근.[^10]
- CI/CD: 코드 변경을 중앙 저장소에 자주 병합(CI)하고, 빌드/테스트/배포를 자동화해 전달/배포(CD)까지 이어가는 방식.[^25]
- IaC (Infrastructure as Code): 인프라를 코드처럼 버전 관리하고 동일하게 재현/프로비저닝/관리하는 방법.[^27]
- CloudFormation 템플릿: YAML/JSON로 리소스의 의도된 상태를 정의한 파일.[^56]
- Stack(스택): 템플릿을 기반으로 프로비저닝되는 리소스 묶음 단위.[^56]
- Change Set(체인지 셋): 스택 업데이트 전 변경 영향도를 미리 확인하는 기능.[^81]
- StackSets(스택 셋): 여러 계정/리전으로 스택을 확장 배포/관리하는 기능.[^84]
- Drift(드리프트): 실제 리소스 상태가 템플릿의 의도된 상태와 불일치하게 된 상태.[^96]
- AWS CDK: 프로그래밍 언어로 인프라를 정의하고 CloudFormation으로 배포하는 IaC 개발 프레임워크.[^103]
- buildspec: CodeBuild에서 빌드 명령/설정을 정의하는 YAML 파일.[^162]
- appspec: CodeDeploy에서 배포 절차/훅을 정의하는 파일.[^173]
- DevSecOps: DevOps 흐름에 보안을 설계 단계부터 포함하고 자동화된 보안 테스트/준수 모니터링을 결합하는 접근.[^29]
참고(콘텐츠 정보)[^1]
- 제목: DevOps를 위한 다양한 AWS 서비스 소개 (AWS Builders Standard Edition)[^1]
- 채널: Amazon Web Services Korea[^1]
- 길이: 44분 48초[^1]
- 링크: https://www.youtube.com/watch?v=pp0ew8VerRw[^1]
[^1]: @[00:01]~ "안녕하세요" (영상 메타 및 오프닝 구간)
[^2]: @[00:46] "본 세션의 큰 흐름은 화면과 같습니다"
[^3]: @[00:08] "저는 aws 에서 솔루션스 아키텍트... 김주현 입니다"
[^4]: @[00:23]~@[00:33] 질문 방법/공개 답변/비공개 요청 안내
[^6]: @[00:46]~@[00:55] 세션 흐름(DevOps 정의 → AWS 도구)
[^7]: @[01:14]~@[01:31] 10명 가정, 답변이 다를 수 있음
[^8]: @[01:31] "실행되는 범위 및 형태... 굉장히 형태가 다양"
[^9]: @[01:41]~@[01:50] DevOps=Dev+Ops 합성어, 그러나 단순 통합은 아님
[^10]: @[01:58]~@[02:18] 문화/철학/사례/도구 조합, 생산성+안정성 최적화, 빠른 전달
[^11]: @[02:24] "세 가지 요소 중 문화는 사고방식"
[^12]: @[02:30] "사고의 방식의 변화가 필요"
[^13]: @[02:36] "개발과 운영... 두 팀간의 장벽을 없애"
[^14]: @[02:55] 역할 범위를 넘어 주인의식, 고객 요구 중심
[^15]: @[03:12]~@[03:22] QA/보안 통합 가능, 전체 수명주기 책임 문화
[^16]: @[06:57] "인프라 구성 자동화 및 애플리케이션 배포 자동화"를 살펴봄
[^17]: @[03:35] "다음 요소는 사례"
[^18]: @[03:40] 자동화/단순화 방식
[^19]: @[03:51] 느슨한 결합, 자주 배포, 품질 방법, 마이크로서비스 등 예시
[^20]: @[04:19]~@[04:32] 도구 필요, 문화/방식만으로 충분치 않음
[^21]: @[04:32]~@[04:41] 수동 배포면 DevOps 아님, 자동화 도구 필요
[^22]: @[04:47] CI/CD, IaC, 로깅/모니터링
[^23]: @[05:02] DevOps 모범 사례 나열
[^24]: @[05:16] DevSecOps 언급
[^25]: @[05:26]~@[05:46] CI/CD 정의
[^26]: @[05:46] 마이크로서비스 정의
[^27]: @[05:56] IaC 정의
[^28]: @[06:13]~@[06:21] 모니터링/로깅 중요
[^29]: @[06:34]~@[06:40] 설계부터 보안 포함, 자동 테스트/준수 모니터링
[^30]: @[07:20] 애플리케이션 관리=코드+인프라 관리
[^31]: @[07:31] VPC, 서브넷, IGW 등도 관리 대상
[^32]: @[07:54] 콘솔/CLI/SDK/CloudFormation/CDK
[^33]: @[08:17]~@[08:26] 콘솔은 쉬우나 자동화 어려움
[^34]: @[08:34]~@[08:56] CLI 재현 어려움, SDK는 접근 용이화 용도
[^35]: @[09:05] CloudFormation/CDK가 DevOps 시나리오에 적합
[^36]: @[09:25]~@[09:33] "IaC가 왜 필요할까요"
[^37]: @[09:33]~@[09:45] DevOps 팀이 겪는 문제(3R 언급)
[^38]: @[09:45]~@[09:54] 반복 구성 시 휴먼 에러로 결과가 달라짐
[^39]: @[09:54]~@[10:04] dev/test OK, prod에서 이슈 발생
[^40]: @[10:04]~@[10:13] IaC로 인프라 관리 문제 해결
[^41]: @[10:13]~@[10:23] IaC 버전 관리, 변경 추적
[^42]: @[10:23]~@[10:36] 변경 기록 인지, 롤백 용이
[^43]: @[10:36]~@[10:52] 붕어빵 틀 비유, 동일 환경 복제
[^44]: @[10:52]~@[11:07] 동일 환경 테스트로 프로덕션 견고
[^45]: @[11:07]~@[11:30] CloudFormation/CDK, Terraform/Chef/Puppet
[^46]: @[11:30]~@[11:35] IaC 프로세스(작성-배포-사용-최적화 반복)
[^47]: @[11:49]~@[12:13] CloudFormation 정의
[^48]: @[12:13]~@[12:29] 템플릿 기반 프로비저닝/구성
[^49]: @[12:29]~@[12:43] 개별 생성/의존성 파악 부담 감소
[^50]: @[12:43]~@[13:02] 템플릿 작성(YAML/JSON/매크로/CDK)
[^51]: @[13:02]~@[13:21] 업로드 경로(콘솔/S3/파이프라인 테스트 후)
[^52]: @[13:21]~@[13:41] 스택/스택셋 생성(멀티 계정/리전)
[^53]: @[13:41]~@[13:51] 스택을 통해 프로비저닝
[^54]: @[13:51]~@[13:58] 핵심 아티팩트 언급
[^55]: @[20:45]~@[24:10] 실용적 내용/모범 사례들(린트, 케이크, 드리프트, 비밀)
[^56]: @[14:05]~@[14:17] 템플릿 파일, 스택은 템플릿으로 발생
[^57]: @[14:17]~@[14:36] 리소스 정의, 속성/종속성
[^58]: @[14:36]~@[14:45] 의도를 API 호출로 변환, 프로비저닝
[^59]: @[14:45] "500개 이상의 리소스 생성"
[^60]: @[14:54]~@[15:09] YAML 기반 템플릿 구조 소개
[^61]: @[15:09]~@[15:19] 버전 선택사항
[^62]: @[15:19]~@[15:38] Description 중요(주석처럼 상세히)
[^63]: @[15:38]~@[16:03] Parameters: 사용자 선택(test/dev/prod)
[^64]: @[16:03]~@[16:21] Mappings: 리전별 AMI 자동 선택 예
[^65]: @[16:21]~@[16:28] 동적 구동 형태와 유사
[^66]: @[16:28]~@[16:46] Conditions: 조건부 리소스 생성(테스트면 EC2 2개)
[^67]: @[16:46]~@[16:58] Resources: 반드시 명시
[^68]: @[16:58]~@[17:12] Outputs: IP 등 출력
[^69]: @[17:14]~@[17:30] 예제 템플릿: CodeCommit/Cloud9 목적 유추
[^70]: @[17:30]~@[17:39] Resources에 CodeCommit/Cloud9 확인
[^71]: @[17:39]~@[17:56] 리소스 간 참조(Cloud9이 CodeCommit clone URL 참조)
[^72]: @[17:56]~@[18:06] 비즈니스 로직처럼 리소스 연결 의미
[^73]: @[18:06]~@[18:16] 내장 함수 언급
[^74]: @[18:16]~@[18:23] 템플릿 → 스택 생성 → 프로비저닝
[^75]: @[18:34]~@[18:45] 변경 시 삭제/재생성 대신 업데이트
[^76]: @[18:45]~@[18:56] 업데이트로 AMI 변경 예
[^77]: @[18:56]~@[19:05] 변경사항 제출(파라미터/업데이트 템플릿)
[^78]: @[19:05]~@[19:16] 변경 리소스만 업데이트
[^79]: @[19:16]~@[19:27] 중단/대체 가능
[^80]: @[19:27]~@[19:39] 영향 파악 중요
[^81]: @[19:39]~@[19:49] Change Set으로 영향 사전 파악
[^82]: @[19:49]~@[20:04] 실행 결정 시만 변경, 크리티컬 삭제 방지
[^83]: @[20:04]~@[20:17] 멀티 계정/멀티 리전 전제
[^84]: @[20:17]~@[20:30] StackSets 소개
[^85]: @[20:30]~@[20:45] 계정/리전 추가 스택
[^86]: @[20:58]~@[21:12] 템플릿 에러 시 시간 낭비
[^87]: @[21:18]~@[21:25] cfn-lint 소개
[^88]: @[21:25]~@[21:37] 라인별 에러 확인
[^89]: @[21:44]~@[21:48] 모범 사례 소개 시작
[^90]: @[21:48]~@[21:58] 소규모는 한 템플릿에 명시
[^91]: @[21:58]~@[22:10] 규모 커지면 계층화
[^92]: @[22:10]~@[22:21] CloudFormation 케이크 비유
[^93]: @[22:21]~@[22:37] 라이프사이클 고려(네트워크/보안은 덜 변함)
[^94]: @[22:37]~@[22:53] 분리 장점(삭제 방지/부분 업데이트/트러블슈팅 용이)
[^95]: @[22:53]~@[23:10] 이상 vs 현실(수동 변경 발생)
[^96]: @[23:10]~@[23:23] 드리프트: 의도 상태 vs 실제 불일치
[^97]: @[23:23]~@[23:28] Drift Detection 사용
[^98]: @[23:28]~@[23:37] 몇 분 내 결과, 템플릿 업데이트/준수 복구 정보
[^99]: @[23:48]~@[23:55] 패스워드 처리 모범 사례
[^100]: @[23:55]~@[24:10] 하드코딩 위험(탈취 시 취약)
[^101]: @[24:10]~@[24:24] SSM Parameter Store에 저장 후 불러오기
[^102]: @[24:24]~@[24:29] CDK 소개, 다음 세션에서 자세히
[^103]: @[24:48]~@[25:08] CDK 정의, CloudFormation으로 배포
[^104]: @[25:08]~@[25:26] 지원 언어, 개발+인프라 선언
[^105]: @[25:26]~@[25:40] CDK 3가지 구성요소
[^106]: @[25:40]~@[25:47] 코어 프레임워크로 앱 구성
[^107]: @[25:47]~@[25:56] 스택 정의, CloudFormation 매핑
[^108]: @[25:56]~@[26:07] 라이프사이클 다르면 스택 분리 권장
[^109]: @[26:07]~@[26:19] Construct Library 정의
[^110]: @[26:19]~@[26:35] 필요한 디펜던시만, 모범 사례 반영
[^111]: @[26:35]~@[26:54] CDK CLI 역할(init, diff 등)
[^112]: @[26:54]~@[27:14] 컴파일→CloudFormation 템플릿→스택 배포
[^113]: @[27:14]~@[27:22] cdk init
[^114]: @[27:22]~@[27:37] 앱/스택/리소스 추가
[^115]: @[27:37]~@[27:51] 빌드(npm run build 예)
[^116]: @[27:51]~@[28:08] cdk synth, cloud assembly 생성
[^117]: @[28:08]~@[28:20] cdk deploy로 프로비저닝
[^118]: @[28:20]~@[28:37] 수정 반복, 배포 전 cdk diff
[^119]: @[28:37]~@[28:59] CDK vs CloudFormation 코드 비교, 개발자 중심 도구
[^120]: @[28:59]~@[29:12] CloudFormation 이점(롤백/드리프트 등) 계속 누림
[^121]: @[29:12]~@[29:31] 더 적은 코드로 동일 결과
[^122]: @[29:31]~@[29:40] 운영자 러닝커브, 적합한 툴 선택
[^123]: @[29:51]~@[29:57] 배포 자동화로 전환
[^124]: @[30:06]~@[30:17] CI/CD 파이프라인 다이어그램
[^125]: @[30:17]~@[30:33] 푸시→일련 과정→프로덕션 반영
[^126]: @[30:33]~@[30:44] 릴리즈 프로세스 자동화가 모범 사례
[^127]: @[30:44]~@[30:52] 단계별 AWS 서비스 매핑
[^128]: @[30:52]~@[31:09] 개발자 도구로 주기 가속, 연동 용이
[^129]: @[31:09]~@[31:30] 안전 저장/버전 관리/자동 구축·테스트·배포
[^130]: @[31:30]~@[31:40] 개발 환경부터 AWS 위에서, Cloud9 소개
[^131]: @[31:40]~@[31:51] Cloud9 기능(작성/실행/디버깅)
[^132]: @[31:51]~@[32:11] 사전 패키징, 어디서나 작업
[^133]: @[32:11]~@[32:32] 협업, SDK/플러그인 제공
[^134]: @[32:32]~@[32:42] 터미널에서 AWS 직접 액세스
[^135]: @[32:42]~@[32:59] 저장소 반영→파이프라인 동작→애플리케이션 변경
[^136]: @[32:59]~@[33:13] 모니터링으로 정상 동작/최적화 파악
[^137]: @[33:13]~@[33:38] CodePipeline 정의(완전 관리형 CD 서비스)
[^138]: @[33:38]~@[33:45] 인프라 신경 불필요
[^139]: @[33:45]~@[34:00] CodeBuild/CodeDeploy/타사 도구 통합(Jenkins)
[^140]: @[34:16]~@[34:24] 스테이지 옵션 소개
[^141]: @[34:24]~@[34:35] 소스: CodeCommit/GitHub 변경 트리거
[^142]: @[34:35]~@[34:48] S3 아티팩트/컨테이너 이미지 변경 트리거
[^143]: @[34:48]~@[34:57] 스케줄링/헬스 이벤트 트리거
[^144]: @[34:57]~@[35:11] 빌드 단계 선택사항, 공급자(CodeBuild/Jenkins)
[^145]: @[35:11]~@[35:26] 배포 대상(EC2/온프/람다/ECS 파게이트)
[^146]: @[35:26]~@[35:50] 푸시→빌드→CloudFormation으로 반영 예시
[^147]: @[35:50]~@[36:14] 모놀리식 1개 vs 마이크로서비스별 파이프라인
[^148]: @[36:14]~@[36:25] CI 정의
[^149]: @[36:25]~@[36:30] 지속적 개발 사례가 중요
[^150]: @[36:30]~@[36:35] 여러 사람 코드 작업
[^151]: @[36:35]~@[36:46] 리포지토리 역할(버전/접근)
[^152]: @[36:46]~@[36:52] 체크아웃-변경-컴파일/테스트-커밋, 빈번
[^153]: @[37:03]~@[37:18] CI 목표(버그 신속, 품질 개선, 시간 단축)
[^154]: @[37:18]~@[37:34] CodeBuild 정의
[^155]: @[37:34]~@[37:45] 자동 확장, 병렬 빌드
[^156]: @[37:45]~@[37:53] 레이턴시 감소 이점
[^157]: @[37:53]~@[38:01] 캐싱 기능
[^158]: @[38:01]~@[38:09] 일관된 환경, 동일 결과
[^159]: @[38:09]~@[38:17] 빌드 환경 정보 정의 필요
[^160]: @[38:17]~@[38:29] 빌드 환경 구성(OS/런타임/도구)
[^161]: @[38:29]~@[38:42] 관리형 이미지 + 커스텀 이미지 가능
[^162]: @[38:42]~@[38:49] buildspec YAML 필요
[^163]: @[38:49]~@[39:12] buildspec에 명령/설정 작성
[^164]: @[39:12]~@[39:44] Report Group/결과(성공/실패/시간/세부)
[^165]: @[39:44]~@[39:52] 지속적 배포 정의(스테이징 자동 배포)
[^166]: @[39:52]~@[40:11] CI vs CD 범위(통합/부하 테스트 등)
[^167]: @[40:11]~@[40:24] 고객 영향 최소, 제로 다운 패치
[^168]: @[40:24]~@[40:37] 애자일 반영, 실패율 감소 목표
[^169]: @[40:37]~@[40:57] CodeDeploy 소개(테스트/스테이징/프로덕션 배포)
[^170]: @[40:57]~@[41:10] 단순화, 다운타임 감소, 자동 롤백
[^171]: @[41:10]~@[41:17] 이전 작업본 재배포로 롤백
[^172]: @[41:17]~@[41:32] 배포 대상 + 온프레미스 에이전트
[^173]: @[41:45]~@[41:54] appspec 파일 존재
[^174]: @[41:54]~@[42:07] 수명주기 이벤트/후크로 배포 관리
[^175]: @[42:07]~@[42:36] LB에서 제거→설치→재시작→테스트→LB 추가 예
[^176]: @[42:36]~@[42:42] 배포 속도/배포 그룹 정의
[^177]: @[42:42]~@[42:52] 프로덕션 한 번에 하나씩 배포→이슈 시 롤백 용이
[^178]: @[42:59]~@[43:12] 파이프라인 예시: CodeCommit 반영
[^179]: @[43:12]~@[43:17]~@[43:30] CodeBuild 빌드/유닛테스트, 카나리→스테이징, 로드 테스트, 프로덕션
[^180]: @[43:31]~@[43:38] 약 40분 동안 알아봄
[^181]: @[43:38]~@[43:51] 조직마다 다양하지만 목표 동일(생산성+안정성→빠른 전달)
[^182]: @[44:04] 적합한 툴/방식 판단 중요
[^183]: @[44:19]~@[44:36] 피드백 요청, 감사 인사