https://www.youtube.com/watch?v=E1wHAlJUk2w
1. 이건 꼭 알아야 한다[^1]
[? 질문] DevOps(데브옵스)란 정확히 무엇이며, 왜 필요한가[^4]
[= 답] DevOps는 단순히 **개발(Development)**과 **운영(Operation)**을 합친 용어를 넘어, 개발자 생산성과 운영 안정성을 함께 최적화해 개선된 서비스를 더 빠르게 고객에게 전달하기 위한 **사고방식(문화)·실천 방식(프로세스)·도구(툴체인)**의 결합이다.[^5]
[? 질문] CI/CD(지속적 통합/지속적 전달·배포)를 AWS에서는 어떤 구성 요소로 구현할 수 있는가[^6]
[= 답] AWS는 소스 저장(CodeCommit 등), 빌드/테스트(CodeBuild), 배포(CodeDeploy), 파이프라인 오케스트레이션(CodePipeline) 같은 관리형 개발자 도구를 제공하며, GitHub·Jenkins 등 서드파티와도 통합해 조직의 거버넌스/정책에 맞는 파이프라인을 구성할 수 있다.[^7]
[? 질문] 파이프라인을 설계할 때 조직이 반드시 결정해야 하는 지점(거버넌스)은 무엇인가[^8]
[= 답] 코드 커밋 이후 수행할 절차(빌드 자동 실행/피어 리뷰 등), 테스트 종류와 강도(유닛·보안·UI·부하·커버리지 기준), 컨테이너 이미지 처리, 스테이징/프로덕션 승격 및 승인, 배포 전략(점진/그룹/롤백), 장애 시 빠른 롤백 체계 등을 단계별로 정책화해야 한다.[^9]
2. 큰 그림[^10]
이 콘텐츠는 “AWS에서 DevOps를 시작할 때 CI/CD를 어떤 개념으로 이해하고, 어떤 도구 조합으로 구현할지”를 소개하는 세션이다.[^10] DevOps의 정의를 “개발+운영” 이상의 관점(문화/실천/도구)으로 확장해 설명하고, 일반적인 CI/CD 파이프라인 단계(소스→빌드→테스트→배포→모니터링/롤백)를 조직 거버넌스 관점에서 어떻게 결정·구성할지 다룬다.[^11]
- DevOps는 문화(사고방식), 실천 방식(프로세스/프랙티스), **도구(툴)**의 3요소가 함께 갖춰져야 한다.[^12]
- CI/CD 파이프라인은 소스 커밋 이후의 빌드·테스트·스테이징·프로덕션 반영과, 장애 시 빠른 롤백까지 포함하는 “일련의 자동화된 흐름”으로 설계해야 한다.[^13]
- AWS의 관리형 개발자 도구(CodeCommit/CodeBuild/CodeDeploy/CodePipeline, 그리고 개발환경 Cloud9)는 다른 AWS 서비스 및 GitHub/Jenkins 같은 도구와 통합되어, 인프라 운영 부담을 줄이면서 파이프라인을 구성하도록 돕는다.[^14]
3. 하나씩 살펴보기[^15]
3.1 세션 목적, Q&A 방식, 목차 안내[^2]
발표자는 AWS에서 솔루션 아키텍트로 공부(또는 업무) 중인 이지영이라고 소개하며, 이번 시간에는 “DevOps가 무엇이고 AWS에서 어떻게 구성할 수 있는지”를 소개하겠다고 말한다.[^2] 강연 중 질문 방법으로 GoToWebinar의 Questions 창을 사용하며, 질문 내역이 표시되고 기본적으로 공개 답변이지만 “비공개”로 요청하면 개인 답변도 가능하다고 안내한다.[^3]
이어 오늘 다룰 목차를 제시한다:
- DevOps가 무엇인지, 왜 필요한지[^4]
- AWS에서 DevOps/CI/CD를 어떻게 구성하는지, AWS 개발자 도구 및 서드파티 도구까지 함께 검토[^4]
3.2 DevOps 정의가 단일 문장으로 딱 떨어지기 어려운 이유[^4]
발표자는 “DevOps(또는 CI/CD)”라는 용어를 많이 들어봤을 텐데, “DevOps가 실제로 무엇인가”라고 물으면 하나로 딱 정의하기 어려운 단어라고 설명한다.[^4] 그 이유는 DevOps가 적용되는 범위나 형태에 따라 매우 다양해질 수 있기 때문이라고 말한다.[^4]
그럼에도 “오피셜하게”는 DevOps가 **소프트웨어 개발(Development)**과 **운영(Operation)**의 합성어임을 먼저 제시한다.[^5] 다만 여기서 끝나지 않고, DevOps가 단순히 “개발과 운영을 통합”하는 의미만이 아니라, 이 둘을 결합한 개발 환경과 사람의 조합 등 더 큰 의미를 지닐 수 있다고 확장한다.[^5]
3.3 DevOps의 목표: 개발자 생산성과 운영 안정성의 동시 최적화[^5]
발표자는 DevOps를 통해 달성하려는 방향을 명확히 제시한다.[^5]
- DevOps를 통해 개발자의 생산성과 운영의 안정성을 “모두” 최적화한다.[^5]
- 그 결과로 애플리케이션 기능이 개선된 서비스를 더 빠른 속도로 고객에게 전달하는 것이 가능해진다.[^5]
즉, 속도(빠른 전달)만 강조하는 것이 아니라 안정성(운영의 안정성)도 함께 최적화한다는 점을 반복해서 강조하는 흐름이다.[^5]
3.4 DevOps를 이루는 3가지 요소: 문화/실천 방식/도구[^6]
발표자는 DevOps를 구성하는 핵심 요소를 3가지로 나눠 설명한다.[^6]
(1) 문화(Culture) = 사고의 방식 변화[^6]
첫 번째 요소는 “문화”, 즉 사고의 방식이라고 말한다.[^6] DevOps로 전환하기 위해서는 사고방식의 변화가 필요하며, 간단히 말하면 기존에 별도로 존재하던 “개발”과 “운영” 사이의 장벽을 없애는 것이라고 설명한다.[^6]
특히 스타트업의 경우 개발팀과 운영팀이 분리돼 있지 않고, 한 명의 엔지니어가 두 역할을 모두 수행하는 경우도 있다고 든다.[^6] 그리고 최근에는 역할/직책 범위를 넘어 개발팀·운영팀뿐 아니라 QA(QA팀)나 보안팀도 긴밀하게 협업해야 하는 상황이 많아지며, 이런 배경에서 DevOps의 “컬쳐”가 더 부각된다고 연결한다.[^6]
발표자는 이 “컬쳐”를 “전체 개발 및 인프라의 수명주기(lifecycle)를 관리할 수 있도록 하는 것”으로도 표현한다.[^6]
(2) 실천 방식(Practice) = 프로세스의 자동화·단순화와 아키텍처/배포 습관[^6]
두 번째 요소는 DevOps의 “방식”, 즉 **프랙티스(실천 방식)**다.[^6] 비즈니스 성격에 따라 소프트웨어 개발과 인프라 관리 프로세스를 자동화/단순화해 더 빠르게 혁신하도록 지원하는 다양한 프랙티스가 있다고 설명한다.[^6]
발표자가 예로 든 프랙티스/검토 항목들은 다음처럼 “구체적 행동/선택지”로 제시된다.[^6]
- 느슨하게 결합된 아키텍처를 사용하는지[^6]
- 애플리케이션 결함을 줄이기 위해 작은 단위로 자주 배포하는지[^6]
- 코드 품질을 높이기 위해 사용하는 방법이 있는지[^6]
- 워크로드 유연성과 개발 속도 향상을 위해 매니지드 서비스/아키텍처를 사용하는지[^6]
즉, DevOps는 도구만의 문제가 아니라, 어떤 구조와 배포 습관을 택하느냐의 문제로 이어진다고 전개한다.[^6]
(3) 도구(Tool) = 문화/방식을 실현하는 CI/CD·IaC·모니터링 툴체인[^7]
세 번째 요소는 이를 “실현할 수 있는 도구”다.[^7] 문화와 방식이 있어도 충분하지 않고, 실제로 구현할 툴이 필요하다고 말한다.[^7] DevOps 도구에는 다음 범주가 전반적으로 포함된다고 정리한다.[^7]
- 지속적 통합/배포(CI/CD) 파이프라인 구축 도구[^7]
- 인프라를 코드로 관리하는 IaC(Infrastructure as Code) 도구[^7]
- 모니터링 도구[^7]
[!IMPORTANT] DevOps는 “개발+운영”만이 아니라 3요소의 조합[^6]
문화(사고방식 변화)와 실천 방식(프랙티스), 이를 구현하는 도구(파이프라인/IaC/모니터링)가 함께 갖춰져야 DevOps를 현실에서 작동시킬 수 있다는 구조로 설명한다.[^6]
3.5 조직/서비스 성장에 따라 달라지는 개발·배포 환경: 모놀리식에서 마이크로서비스로[^8]
발표자는 “거창하게 말한 것 같지만”이라는 전환 후, 초기 스타트업이 흔히 출발하는 형태로 단순한 3티어 아키텍처, 그리고 “전체 서비스를 제공하는 모놀리식 애플리케이션”을 언급한다.[^8]
이 경우 현실적으로 개발자 수가 적기 때문에, 그럼에도 “일관된 소스 관리”와 “배포 자동화”를 위한 환경 구성이 필요하다고 문제를 제기한다.[^8] 모놀리식은 배포 영향도가 크기 때문에 여러 사람이 함께 검증해야 하는 제약이 생길 수 있으며, 코드를 변경하고 즉시 운영에 반영하기가 어렵더라도 “적절한 코드 관리를 위한 저장소”와 “배포를 위한 파이프라인”은 구축돼야 한다는 흐름으로 결론을 낸다.[^8]
서비스가 성장하면 기능이 많아지고 개발 조직이 커지며, 서비스가 쪼개지고 조직 구조도 계속 변화한다.[^9] 이에 따라 개발 환경도 함께 변하며, 결국 마이크로서비스 아키텍처로 나뉘게 된다고 말한다.[^9] 다양한 형식으로 애플리케이션을 나누고 이를 관리하기 위한 각각의 파이프라인을 구축할 수 있다고 설명한다.[^9]
여기서 “모든 파이프라인이 통일될 필요는 없지만”, 회사가 요구하는 CI/CD 및 DevOps 원칙이 잘 반영되는 개발 도구/환경이 필요하다고 덧붙인다.[^9]
3.6 도구 도입 시 검토 기준(선정 포인트): 자동화/배포전략/IaC/비용/운영환경관리[^9]
발표자는 도구(툴) 도입 시 주로 무엇을 검토하는지 항목을 나열한다.[^9]
- 릴리즈를 자동화할 수 있는가[^9]
- 다양한 배포 전략을 가져갈 수 있는가[^9]
- 반복 가능한 인프라 변경을 함께 반영할 수 있는가(IaC/환경관리 관점)[^9]
- 구입에 따른 라이선스 비용[^9]
- DevOps 운영 환경 관리의 용이성[^9]
이 검토 기준을 바탕으로 “AWS 개발 도구”와 “많이 사용하는 서드파티 도구”를 함께 살펴보겠다고 다음 파트로 넘어간다.[^9]
3.7 CI/CD 파이프라인 단계별로 조직이 결정해야 할 요구사항(거버넌스)과 예시[^10]
발표자는 화면에 흔히 보이는 파이프라인 다이어그램(소스→빌드→테스트→스테이지→프로덕션→모니터링)을 상정하고, 단계별로 필요한 “요구사항”이 있으며 회사는 이를 IT 거버넌스 차원에서 결정해야 한다고 말한다.[^10]
(1) 소스(Source) 단계: 커밋 이후 무엇을 할 것인가[^10]
소스 관리를 어떻게 할지, 코드 커밋 후 후속 작업을 무엇으로 할지 결정해야 한다고 한다.[^10] 예시로:
- 커밋 시 바로 빌드를 호출할지[^10]
- 피어 리뷰를 진행할지[^10]
이때 소스 단계 설계는 “컬쳐와 함께 병합된 형태”로 지정해야 한다고 언급한다.[^10] 즉, 단순 기능 선택이 아니라 협업/검토 문화가 반영되어야 한다는 의미로 연결된다.[^10]
(2) 빌드(Build) 단계: 테스트/보안/커버리지 정책[^10]
컴파일 이후 어떤 테스트(유닛 테스트, 보안 테스트)를 자동화할지 선택해야 한다고 한다.[^10] 회사 정책에 따라:
- 코드 커버리지를 확인하고[^10]
- 커버리지가 낮으면 반영되지 않도록 정책을 만들 수도 있다[^10]
또한 컨테이너 기반 운영이 많아졌다는 흐름에서, 컨테이너 환경이라면:
- 컨테이너 이미지 생성/패키징[^10]
- (이미지 관련) 작업들이 요구될 수 있음[^10]
(3) 테스트(Test) 단계: 테스트 환경 자동 구성, 부하·UI·취약점 테스트[^11]
테스트 단계에서는 테스트 환경을 자동화해 환경 구성을 하고, 코드 기반으로 부하 테스트를 해볼 수 있다고 말한다.[^11] 온프레미스 환경에서는 VM웨어/하이퍼V 같은 환경에서 VM을 자동 생성해 배포하고, 그 환경에서 코드가 적절히 수행되는지 거버넌스 관점에서 시험할 수 있다고 예시를 든다.[^11]
또한 UI 테스트 자동화 예시를 든다.[^11] 브라우저에서 어디를 클릭했을 때 어떤 화면이 보여야 하는지, 어떤 값이 리스폰스로 들어오는지 등을 테스트 환경에 포함할 수 있다는 식으로 구체화한다.[^11]
여기에 OWASP Top 10 수준의 취약성 테스트도 포함할 수 있다고 언급한다.[^11]
테스트 후 stage 환경으로 넘어가 정상 동작을 확인하는 것도 가능하고, 조직 구성에 따라 이 단계에서 QA팀이 검증 작업을 할 수도 있다고 설명한다.[^11]
(4) 프로덕션 배포 이후: 모니터링과 “빠른 롤백”의 중요성[^11]
완료되면 프로덕션 환경으로 배포되고 신규 코드 에러 확인을 위해 모니터링을 한다.[^11] 그리고 여기서 중요한 강조가 나온다:
- CI/CD는 배포로 끝이 아니라, 배포 후 이슈가 발생했을 때 빠르게 롤백할 수 있는 기능/체계가 가장 중요하다[^11]
- 이를 위한 기능들이 잘 갖춰져 있어야 한다[^11]
이 전체 과정은 조직 프로세스뿐 아니라 “개발 도구와 함께” 구축되어 지속적으로 통합·배포되도록 구성돼야 한다고 정리한다.[^11]
[!WARNING] 배포 후 장애 시 “빠른 롤백”이 핵심 요구사항[^11]
“코드를 배포했는데 이슈가 발생했을 때 가장 중요한 건 빠르게 롤백할 수 있는 기능”이라고 직접 강조한다.[^11]
3.8 자동화의 효과: 빠르고 지속 가능한 개발 환경(특히 스타트업에 중요)[^11]
발표자는 개발자가 소스코드를 리포지토리에 push/commit하면 일련의 과정을 거쳐 프로덕션에 변경 사항이 반영되는 “릴리즈 프로세스”를 설명하며, 이를 자동화하면 빠르고 지속 가능한 애플리케이션 개발 환경을 갖출 수 있다고 말한다.[^11] 이 점은 스타트업에서 중요한 요소라고 덧붙인다.[^11]
그리고 이 과정이 AWS 개발자 도구로 단계 매핑될 수 있다고 하며, AWS 개발자 도구를 통해 프로세스를 자동화해서 소프트웨어 개발 및 릴리즈 주기를 가속화할 수 있다고 말한다.[^12] 특히 다른 AWS 서비스와 쉽게 연동하여 작업을 시작할 수 있는 점을 “AWS 개발 도구 선택의 큰 메리트”로 제시한다.[^12]
3.9 AWS 개발자 도구 개요: CodeCommit/CodeBuild/CodeDeploy/CodePipeline + 서드파티 연동[^12]
발표자는 AWS 개발자 도구가 애플리케이션 소스코드를 안전하게 저장하고 버전 관리하며, 다양한 릴리즈 요구사항(자동 구축·테스트·배포)을 지원한다고 설명한다.[^12]
이후 구성 요소별로 상세로 넘어간다.[^12]
3.10 소스 저장소: GitHub vs AWS CodeCommit, 그리고 “퍼블릭 레포 보안 사고” 경고[^13]
소스 코드를 저장하는 데 가장 많이 쓰는 도구로 “여러분이 가장 많이 알고 지금도 대부분 쓰고 있을” GitHub를 먼저 언급한다.[^13] 그 다음 AWS CodeCommit을 “완전 관리형, 안전한 기반의 레포지토리”로 소개한다.[^13]
발표자가 강조한 비교 포인트는 “기본 공개 범위/기본 보안”이다.[^13]
- GitHub는 (과거) 무료 버전에서 퍼블릭 모드 제공 때문에 보안 사고가 자주 발생했다고 언급한다.[^13]
- 반면 CodeCommit은 “계정 안에서 기본값이 세팅”되어 외부에 코드가 노출되지 않아 안전하게 관리될 수 있다는 장점을 이야기한다.[^13]
- 또한 CodeCommit은 Git 기반이어서 Git 커맨드를 활용해 코드를 관리할 수 있다고 말한다.[^13]
“우리 회사에 당장 레포지토리가 필요할까?”에 대한 답변 방식[^13]
발표자는 “스타트업 회사에서도 당장 소스 코드 레포지토리가 필요할까?”라는 질문을 던지고, 답은 “여러분이 가진 파일 탐색기를 보면 알 수 있다”고 말한다.[^13] 만약 탐색기 폴더에 최종, 최종_진짜, 오리지날 같은 이름으로 소스가 저장되어 있다면, 개인이든 조직이든 Git 기반 레포지토리 도입을 강력 추천한다고 한다.[^13]
또한 2명 이상의 개발자가 있는 조직이라면 협업 환경을 위해 레포지토리는 반드시 도입하라고 권장한다.[^13] 이유는 여러 개발자가 같은 소스 파일을 변경하는 상황에서, 레포지토리 기반으로 관리하면 “커밋을 통해 변경 추적이 용이”하여 조기에 문제를 해결할 수 있기 때문이라고 설명한다.[^13]
다양한 Git 기반 서비스 + 퍼블릭 레포 토큰/키 유출 위험 강조[^14]
발표자는 Git 기반 레포지토리로 “대동단결”된 것 같다고 표현하며, GitHub가 가장 많이 쓰이는 서비스 중 하나라고 다시 언급한다.[^14] 그리고 “무심결에 레포를 만들면 퍼블릭으로 오픈되어 있을 수 있다”고 경고한다.[^14]
그 결과 개발자가 토큰 값이나 액세스 키 같은 민감 정보를 무심코 커밋해 노출할 수 있고, 실제로 “퍼블릭 레포에 올라간 액세스 키를 가지고 타겟팅되는 해킹 사고”가 많기 때문에 보안에 유념해야 한다고 강조한다.[^14]
이런 맥락에서, GitHub가 프리 에디션을 제공하는 동안에도 비공개(private) 레포를 무료로 제공하는 서비스가 많이 쓰였고(표현상 “카이(Private) 모드 무료”), 최근에는 GitLab이 망분리 환경에서 자체 GitHub 같은 환경을 구성하려는 회사들이 많이 도입하고 있다고 덧붙인다.[^14]
3.11 빌드(컴파일) 필요 언어 vs 불필요 언어, 그리고 빌드 서비스 선택지[^15]
발표자는 언어 특성에 따라 빌드 서비스 필요 여부가 달라진다고 말한다.[^15]
- 인터프리터 언어(예: PHP, ASP 등)는 빌드 서비스를 따로 운영하지 않을 수도 있다[^15]
- 반면 Java, .NET처럼 컴파일이 필요한 언어는 빌드 서비스가 필요할 수 있다[^15]
여기서 질문을 던진다: “소스 코드가 변경된 후 빌드를 어디서 해야 하느냐?”[^15]
온프레미스 환경에서는 Jenkins 서버를 운영해왔고, 운영관리 없는 환경을 원하면 GitHub Actions 같은 것을 사용할 수도 있다고 말한다.[^15] 다만 GitHub Actions도 구성에 따라 빌드 서버 형태가 달라질 수 있다고 여지를 둔다.[^15]
또한 소스가 커밋된 후 빌드 서버를 통해 “전체를 빌드해서 문제를 확인”해야 하는 필요성을 설명한다.[^15] 예시로 어떤 라이브러리 인터페이스가 변경되면 여러 프로젝트가 있어도 전체 빌드를 돌려 빠르게 문제를 파악하는 것이 좋다는 흐름을 제시한다.[^15]
3.12 AWS CodeBuild: 완전 관리형 빌드 서비스의 기능(확장/병렬/캐시/불변환경)과 빌드 환경 정의[^16]
CodeBuild가 하는 일(정의)[^16]
AWS의 CodeBuild를 “완전 관리형 빌드 서비스”로 소개하며 다음 작업을 수행할 수 있다고 설명한다.[^16]
- 소스 코드 컴파일[^16]
- 유닛 테스트 시행[^16]
- 소프트웨어 패키지 생성 단계까지 수행[^16]
자동 확장과 대규모 병렬 빌드[^16]
CodeBuild는 빌드 볼륨에 맞게 자동 확장하고, 여러 빌드를 동시에 병렬로 수행할 수 있으며 “1000개 가능”이라고 언급한다.[^16] 이런 특징은 빌드 작업이 몰릴 때 발생할 수 있는 “대기 시간/병목”을 줄인다고 설명한다.[^16]
캐시 기능과 불변(일관) 빌드 환경[^16]
빌드 속도 향상을 위해 빌드 환경을 캐시하는 기능을 제공한다고 말한다.[^16] 또한 빌드는 “일관되고 불변하는 환경”에서 진행되기 때문에 항상 동일한 결과를 얻을 수 있다고 설명한다.[^16] 이 점이 빌드 서버를 별도로 관리해야 하는 이유이기도 하다고 덧붙인다.[^16]
빌드 환경 이미지: 관리형 이미지 vs 커스텀 컨테이너[^17]
CodeBuild로 빌드를 실행할 때 빌드 환경 정보를 정의해야 한다고 말한다.[^17] 운영체제, 프로그래밍 언어 런타임, 도구 조합이 포함된 “관리형으로 제공되는 빌드 환경 이미지”가 있으며, 커스터마이징이 필요하면 컨테이너 형식으로 빌드 환경을 매칭할 수도 있다고 설명한다.[^17]
3.13 CodeBuild의 buildspec.yml: 무엇이며, 테스트 리포트(성공/실패/시간/세부) 구성[^18]
발표자는 CodeBuild를 실행하기 위해 buildspec 파일을 작성해야 한다고 말한다.[^18] buildspec은 CodeBuild가 빌드를 실행하는 데 사용하는 “YAML 형식의 설정 파일”이며, 어떤 명령을 실행하고 무엇을 통합할지 등을 작성해 buildspec 파일로 구성한다고 설명한다.[^18]
컨테이너 기반 패스(배포)에서의 활용[^18]
최근 많은 회사가 컨테이너 기반으로 패스(배포)를 하고 있으며, 이때 배포할 컨테이너 이미지를 빌드하는 작업도 CodeBuild로 할 수 있다고 말한다.[^18]
리포트 위치 명세 → CodeBuild Report에서 결과 확인[^19]
buildspec 파일에 “리포트 위치”를 명세할 수 있다고 설명한다.[^19] 테스트 보고서를 만들기 위해 테스트 결과 경로를 buildspec에 추가하고, CodeBuild 리포트에서 리포트 그룹을 생성한 뒤 ARN을 buildspec에 붙여 넣으면, 화면에서 다음을 확인할 수 있다고 말한다.[^19]
- 성공/실패[^19]
- 수행 시간[^19]
- 유닛 테스트 세부 현황[^19]
3.14 AWS CodeDeploy: 배포 전략과 자동 롤백, 대상(EC2/온프레미스/ECS 등), appspec과 라이프사이클 훅[^20]
다음은 빌드 후 다양한 배포 전략이 필요할 때 사용하는 CodeDeploy 소개다.[^20]
CodeDeploy가 하는 일과 가치[^20]
CodeDeploy를 통해 테스트/스테이징/프로덕션 환경의 실제 인스턴스(또는 타겟)에 애플리케이션 아티팩트를 배포한다고 설명한다.[^20] 그리고 복잡한 업데이트 작업을 “비교적 간단하게” 한다고 말한다.[^20]
배포 서비스에서 중요한 것 2가지: 배포 전략 준수 + 장애 시 자동 롤백[^20]
배포 서비스에서 중요한 것은:
- 회사에서 정의한 배포 전략 기반으로 배포가 가능한지[^20]
- 에러 발생 시 자동으로 롤백 가능한 기능이 제공되는지[^20]
CodeDeploy는 문제 발생 시 이전 버전으로 되돌릴 수 있다고 설명한다.[^20]
배포 타겟: EC2, 온프레미스 서버, (언급) ECS/Fargate 등[^20]
배포 타겟은 EC2, 온프레미스 서버 등이 될 수 있고, 온프레미스 서버에서는 에이전트를 설치해 CodeDeploy와 통신하며 작업을 진행할 수 있다고 말한다.[^20]
(뒤의 CodePipeline 배포 타겟 설명에서는 ECS/Fargate 등도 포함해 언급된다.)[^21]
CodeDeploy 구성 개념: Application / Deployment Group / Deployment / appspec[^21]
CodeDeploy 사용 시 appspec 파일을 생성해야 한다고 말하면서, 개념을 먼저 정리한다.[^21]
- Application: 인스턴스 그룹에 배포할 소프트웨어/구성(정의로 제시)[^21]
- 배포 대상은 EC2나 온프레미스 서버가 될 수 있음[^21]
- 배포 대상 “전체”를 Deployment Group이라고 부른다고 설명[^21]
- 실제 배포 진행 방식을 정의하는 것이 appspec 파일(및 그 구성)이라는 취지로 연결[^21]
- 구성이 완료되면 “Deployments”를 클릭해 소스 코드가 배포될 수 있다고 말함[^21]
appspec의 수명주기 이벤트 훅과 예시(로드밸런서 등록/해제, 패키지 설치, 서비스 시작, 테스트)[^22]
appspec 파일에는 배포가 실제로 진행되는 방식이 정의돼 있으며, 파일에 정의된 일련의 수명주기 이벤트 훅으로 배포를 관리할 수 있다고 설명한다.[^22]
화면의 appspec 예시 설명에서는 다음과 같은 흐름을 스크립트로 실현한다고 말한다.[^22]
- (EC2 인스턴스 변경분 배포 시) 로드밸런서에서 인스턴스를 제거[^22]
- 의존(디펜던시) 패키지 설치[^22]
- 웹 브라우저(또는 웹 서버/서비스) 시작[^22]
- 테스트 진행[^22]
- 로드밸런서에 인스턴스를 다시 추가[^22]
즉, 트래픽에서 빼고 업데이트한 후 다시 붙이는 형태의 안전한 배포 절차를 appspec 훅/스크립트로 제어할 수 있다는 예시다.[^22]
배포 속도/배포 그룹 정의, 그리고 전략적 선택[^23]
CodeDeploy는 배포 속도 및 배포 그룹을 정의할 수 있다고 말한다.[^23] 프로덕션 배포에서 한 번에 하나씩 배포하면 이슈 발생 시 영향을 최소화하는 전략을 취할 수 있고, 그룹을 통해 배포 타겟도 정의할 수 있다고 설명한다.[^23]
또한 온프레미스의 경우 에이전트를 설치하지만, 이 경우(표현상) AB 테스트 같은 기능은 지원되지 않는다는 취지의 언급이 나온다.[^23]
3.15 AWS CodePipeline: 소스-빌드-테스트-배포를 묶는 관리형 파이프라인 오케스트레이션[^24]
발표자는 앞서 파이프라인에서 소스/빌드/테스트/디플로이를 하나로 묶어 “CodePipeline”으로 표시했다고 상기시킨다.[^24]
CodePipeline 정의와 장점: 완전 관리형, 인프라 신경 불필요[^24]
CodePipeline은 애플리케이션 및 인프라 업데이트를 위한 릴리즈 파이프라인을 자동화하는 데 도움이 되는 “완전 관리형 지속적 전달 서비스”라고 설명한다.[^24] 완전 관리형이므로 인프라에 대한 신경을 덜 수 있다고 말한다.[^24]
또한 CodePipeline으로 CodeCommit/CodeBuild/CodeDeploy 등 AWS 도구를 사용해 CI/CD 워크플로우를 관리할 수 있고, 사용자 선호에 따라 GitHub 같은 타사 서비스와도 쉽게 통합할 수 있다고 설명한다.[^24]
3.16 CodePipeline 구성 요소 3가지: Source 트리거 / (선택) Build / Deploy 타겟[^25]
발표자는 CodePipeline 구성 설명을 3가지로 나눈다.[^25]
(1) Source Stage 트리거 옵션 다양[^25]
소스 스테이지는 CodeCommit이나 GitHub 같은 레포에서 소스가 변경되면 파이프라인이 트리거될 수 있다고 설명한다.[^25] 추가로 다음 트리거도 언급한다.[^25]
- S3 버킷에 아티팩트가 들어올 때[^25]
- 컨테이너 워크로드라면 컨테이너 이미지가 변경될 때[^25]
- 스케줄 이벤트 등 특정 조건에 따라 트리거할 수도 있음[^25]
(2) Build Stage는 선택 사항, 공급자는 CodeBuild 또는 Jenkins[^25]
빌드 스테이지를 파이프라인에 붙이는 것은 선택이며, 공급자로 CodeBuild 또는 Jenkins를 선택할 수 있다고 말한다.[^25]
(3) Deploy Target: EC2/온프레미스/ECS/Fargate 등[^26]
배포 타겟은 EC2 인스턴스, 온프레미스 서버, 또는 ECS/Fargate 같은 환경으로 배포 가능하다고 말한다.[^26]
3.17 CodePipeline 간단 워크플로 예시 + 승인 절차 포함 가능[^26]
CodePipeline을 도입하면 소스→빌드→배포 같은 간단한 워크플로를 만들 수 있다고 말한다.[^26] 예시로:
- GitHub(또는 CodeCommit)에서 소스 가져오기[^26]
- CodeBuild 또는 Jenkins로 빌드[^26]
- 빌드 완료 후(예시로) ECS로 배포[^26]
그리고 파이프라인 안에서 승인 절차가 필요하면 승인 단계도 넣어 진행할 수 있다고 말한다.[^26]
3.18 시나리오 1: Jenkins를 붙인 파이프라인(운영 오버헤드 존재)[^27]
발표자는 Jenkins를 사용하는 시나리오를 더 세부적으로 설명한다.[^27] DevOps 운영자가 EC2 인스턴스에 Jenkins 서버를 미리 설치·구성해야 하며, Jenkins에서 언제 빌드할지 트리거 구성도 미리 해둬야 한다는 전제가 있다고 말한다.[^27]
이 환경에서 파이프라인을 구성하면:
- 개발자가 커밋[^27]
- 소스 아티팩트를 복사하도록 소스 프로바이더 구성[^27]
- Jenkins가 작업을 폴링/가져와 빌드 스테이지로 넘어감[^27]
- 빌드 시작, 소스코드 가져오기[^27]
- Jenkins 빌드 완료 후 결과를 S3에 저장하고 상태를 CodePipeline에 업데이트[^28]
- 다음 단계로 넘어가 CodeDeploy를 통해 타겟 배포[^28]
이 설명을 통해 Jenkins 기반 구성은 가능하지만 Jenkins 서버 자체를 운영/관리해야 하는 오버헤드가 있음을 자연스럽게 강조하는 구조다.[^28]
3.19 시나리오 2: AWS 개발자 도구로 동일 파이프라인 구성(관리 부담 감소)[^29]
앞 시나리오에서 Jenkins 서버를 EC2에 설치하고 관리해야 하는 부담을 언급한 뒤, AWS 개발자 도구로 같은 파이프라인을 구성한 예시를 제시한다.[^29]
흐름은 다음처럼 설명된다.[^29]
- 코드가 커밋되면 CodeCommit 또는 GitHub 커밋을 트리거로 파이프라인 시작[^29]
- 빌드 서비스가 자동 호출되도록 구성[^29]
- CodeBuild는 완전 관리형 빌드 서버이므로 EC2 관리나 운영 오버헤드 없이 AWS가 제공하는 빌드 서버로 빌드를 수행[^29]
- 결과를 S3에 저장할 수도 있으나, CodePipeline을 통해 바로 디플로이 스테이지로 넘길 수도 있음[^29]
- 이후 CodeDeploy 단계 진행[^29]
- 배포는 조직의 절차/전략에 맞게 EC2 또는 ECS 등으로 다양하게 배포 가능[^30]
3.20 서드파티 예시: GitHub Actions로 Maven(Java) 빌드 및 배포 흐름[^30]
발표자는 GitHub Actions를 사용한 테스트도 소개한다.[^30] 흐름은:
- GitHub 레포지토리를 생성[^30]
- 레포에 코드를 커밋[^30]
- GitHub Actions에서 스텝을 통해 워크플로를 지정[^30]
- 예시로 Java를 Maven으로 빌드하고, 이후 배포(디플로이)를 진행하는 방식으로 구성[^30]
- 이 과정에서 커버리지 등 워크플로/빌드/디플로이 관련 절차를 함께 진행하는 것으로 보면 된다고 말한다.[^30]
3.21 CI(지속적 통합)와 CD(지속적 전달/배포) 정의를 다시 정리[^31]
발표자는 지금까지 AWS 개발자 도구를 통해 CI/CD를 어떻게 구성할지 “간단히 살펴봤다”고 정리하고, 이후 핸즈온에서 직접 진행할 예정이라고 말한다.[^31]
그 다음 개념 정의로 들어간다.[^31]
지속적 통합(CI)의 의미[^31]
지속적 통합은 자동화된 빌드와 테스트가 수행된 후, 개발자의 코드 변경 사항을 중앙 레포지토리에 정기적으로 병합하는 방식을 의미한다고 정의한다.[^31] 또한 지속적 통합은 지속적 전달(또는 배포)의 중요한 요소라고 말한다.[^31]
지속적 통합 사례에서 필요한 조건으로는:
- 여러 사람이 코드 작업 가능[^31]
- 레포지토리가 서로 다른 버전의 코드를 유지/관리[^31]
- 팀이 코드에 액세스할 수 있어야 함[^31]
개발자 작업 흐름도 상세히 서술한다: 레포에서 코드를 체크아웃해 로컬 복사본에서 코드를 변경/작성 → 컴파일/테스트 → 레포에 다시 커밋, 이런 작업이 빈번하게 수행될 수 있다고 말한다.[^31]
CI의 핵심 목표는:
- 버그를 신속하게 찾아 해결[^32]
- 소프트웨어 품질 개선[^32]
- 새로운 소프트웨어 업데이트 검증에 걸리는 시간 단축[^32]
3.22 릴리즈 프로세스 예시(엔드투엔드): 커밋→유닛→빌드→카나리→스테이징→통합/부하→프로덕션[^32]
발표자는 릴리즈 프로세스를 하나의 CodePipeline으로 구축할 때의 예시를 정리해 보여준다고 말한다.[^32] 흐름 예시는 다음과 같다.[^32]
- 코드 변경분이 CodeCommit(또는 레포)에 반영
- 유닛 테스트 실행
- CodeBuild를 통해 빌드
- 카나리 배포를 통해 (표현상) 페이징/스테이징 계열 환경으로 CodeDeploy
- 추가 테스트 수행
- 궁극적으로 프로덕션 환경에 반영
이 설명은 앞서 단계별로 얘기했던 소스-빌드-테스트-스테이지-프로덕션 흐름을 “하나의 파이프라인 예시”로 다시 연결하는 역할을 한다.[^32]
3.23 지속적 배포의 포인트: 스테이징 자동 배포, 고객 영향 최소화(제로 다운타임), 변경 실패율 감소[^33]
발표자는 지속적 배포를 “테스트를 위해 스테이징 환경에 새로운 변경 사항을 자동 배포”할 수 있는 것으로 설명한다.[^33] 일반적으로 빌드까지가 CI 영역이고, CD는 스테이징 환경까지 가서 로컬 테스트를 넘어 다른 시스템과의 통합 테스트, 부하 테스트 등을 거쳐 최종적으로 프로덕션 아티팩트를 만드는 과정으로 볼 수 있다고 말한다.[^33]
지속적 배포의 포인트로 다음을 제시한다.[^33]
- 고객 사용에 영향을 미치지 않는 것이 포인트[^33]
- 프로덕션에서 변경 반영은 제로 다운타임으로 이뤄지는 것이 중요[^33]
- 변경을 애자일하게 반영하고, 변경 실패율을 감소시키는 것이 지속적 배포의 목표[^33]
3.24 개발 환경 도구: AWS Cloud9(웹 IDE) 장점과 핸즈온에서의 활용 흐름[^34]
끝으로 발표자는 오늘 핸즈온에서 활용할 도구로 AWS Cloud9을 소개한다.[^34] Cloud9은 클라우드 기반 통합 개발 환경(IDE)이라고 정의한다.[^34]
Cloud9의 장점을 구체적으로 설명한다.[^34]
- 웹브라우저에서 코드 작성, 실행, 디버깅 가능[^34]
- 사무실/집 등 어디서든 인터넷만 연결되면 작업 가능[^34]
- 필요한 SDK/라이브러리/플러그인을 Cloud9 환경에 미리 구성해두면 다른 장소에서도 개발을 수월하게 진행 가능[^34]
- 개발환경을 “통일”하기 때문에 협업도 쉽게 할 수 있다는 취지의 설명을 덧붙임[^34]
핸즈온 앱에서의 흐름도 연결한다:
- Cloud9에서 코드를 작성하고 커밋하면 저장소(CodeCommit)에 반영[^35]
- CodeCommit 커밋을 트리거로 CodePipeline이 자동 동작[^35]
- 최종적으로 애플리케이션이 자동 배포되는 부분까지 핸즈온에서 커버한다고 말한다.[^35]
3.25 마무리: DevOps는 조직마다 형태는 달라도 목표는 같다(생산성+안정성→빠른 전달)[^36]
발표자는 지금까지 DevOps를 위해 AWS에서 제공하는 서비스(도구)를 알아봤다고 정리한다.[^36] DevOps는 조직/기업에 따라 다양한 형태로 실현될 수 있지만, “궁극적인 목표는 모두 같다”고 말한다.[^36]
그 궁극적 목표를 다시 한번 문장으로 제시한다:
- 개발자의 생산성과 운영 안정성을 모두 최적화하여, 스타트업에서 새로운 애플리케이션 기능 개선 서비스를 더 빠르게 고객에게 전달하는 것[^36]
이를 실현하기 위해 “현재 상황에서 어떤 툴이 적합한지, 어떤 방식을 채택하는 것이 적합한지”를 항상 고민하는 것이 중요하다고 말한다.[^36]
또한 AWS 개발도구뿐 아니라 GitHub Actions도 함께 소개한 이유를, 스타트업이 빌드 서비스 등을 구성할 때 범위를 줄이면서도 빠르게 도입하는 목표가 있기 때문이라고 설명한다.[^36]
마지막으로 긴 시간 경청에 감사 인사를 하고, 세션 피드백을 남겨달라고 요청한 뒤, 약 10분 쉬고 핸즈온 랩을 진행하겠다고 안내하며 종료한다.[^37]
4. 핵심 통찰[^38]
- DevOps는 “조직 구조(장벽 제거) + 개발/운영 전 수명주기 관리”의 문제로 정의되며, 도구만으로는 완성되지 않는다.[^6]
- CI/CD 파이프라인 설계의 출발점은 기술 스택이 아니라 **거버넌스(정책 결정)**이며, 커밋 이후의 절차·테스트 강도·승인·배포 전략·롤백을 단계별로 명확히 해야 한다.[^10]
- [h 배포 이후 장애를 대비한 “빠른 롤백”은 파이프라인의 필수 요건]이며, 배포 성공 자체보다 실패 시 피해를 최소화하는 체계가 중요하다고 강조한다.[^11]
- 모놀리식이든 마이크로서비스든 규모와 무관하게 “저장소 + 파이프라인”은 필요하며, 성장에 따라 파이프라인은 분화될 수 있지만 조직 원칙은 일관되게 반영되어야 한다.[^9]
- 관리형 서비스(CodeBuild/CodePipeline 등)는 Jenkins 같은 자체 운영 대비 인프라 운영 부담을 줄여 “빠르게 도입하고 지속 운영”하는 데 유리한 선택지로 제시된다.[^24]
- 소스 저장소는 협업의 기반일 뿐 아니라 보안 사고의 주요 표면이 될 수 있어, 퍼블릭 레포 기본 설정/토큰·키 커밋 같은 실수를 구조적으로 방지해야 한다는 경고가 강조된다.[^14]
- 실행 관점 체크리스트(콘텐츠의 논지를 행동으로 옮긴 형태)
- 커밋 시점에 무엇을 강제할지(빌드 자동 실행 vs 리뷰 필수)를 정책으로 정한다.[^10]
- 커버리지 기준, 보안/취약점 테스트(OWASP 등), UI/부하 테스트를 어디 단계에 둘지 결정한다.[^11]
- 스테이징→프로덕션 승격 시 승인 단계가 필요한지 정의한다.[^26]
- 배포 전략(점진/그룹/카나리 등)과 장애 시 자동 롤백 체계를 배포 도구 선택 기준으로 삼는다.[^20]
- 퍼블릭 레포 설정 및 비밀정보(토큰/키) 커밋 방지를 개발 표준으로 만든다.[^14]
5. 헷갈리는 용어 정리[^39]
- DevOps: 개발(Development)과 운영(Operation)을 결합해, 개발 생산성과 운영 안정성을 함께 최적화하고 더 빠르게 고객에게 전달하기 위한 문화/실천 방식/도구의 결합.[^5]
- CI(지속적 통합): 자동 빌드·테스트 이후 개발자의 변경 사항을 중앙 레포지토리에 정기적으로 병합하는 방식. 목표는 버그의 빠른 발견/해결, 품질 개선, 검증 시간 단축.[^31]
- CD(지속적 전달/배포): 빌드 이후 변경 사항을 스테이징(및 그 이후)으로 자동 배포하고 통합/부하 테스트를 거쳐 프로덕션 반영까지 이어지게 하는 접근. 고객 영향 최소화(제로 다운타임)와 변경 실패율 감소가 포인트.[^33]
- CodeCommit: AWS의 Git 기반(관리형) 소스 저장소 서비스. 계정 기본 설정으로 외부 노출을 줄여 안전하게 관리 가능하다는 취지로 소개.[^13]
- CodeBuild: 소스 컴파일, 유닛 테스트, 패키징을 수행하는 AWS의 완전 관리형 빌드 서비스. 자동 확장, 병렬 빌드(언급상 1000개), 캐시, 불변 환경을 강조.[^16]
- buildspec: CodeBuild가 빌드를 실행할 때 사용하는 YAML 설정 파일(명령/설정/리포트 경로 등 정의).[^18]
- CodeDeploy: 정의된 배포 전략에 따라 EC2/온프레미스 등 타겟에 배포하고, 문제 시 롤백을 지원하는 배포 서비스.[^20]
- appspec: CodeDeploy에서 배포의 실제 진행 방식(수명주기 이벤트 훅/스크립트)을 정의하는 파일.[^22]
- CodePipeline: 소스-빌드-테스트-배포를 연결해 릴리즈 파이프라인을 자동화하는 AWS의 완전 관리형 지속적 전달 서비스.[^24]
- Cloud9: 웹브라우저 기반 클라우드 IDE. 어디서나 동일한 개발 환경으로 코드 작성/실행/디버깅이 가능하다는 점을 장점으로 설명.[^34]
- OWASP Top 10: 웹 애플리케이션 주요 취약점 분류/가이드로, 테스트 단계에서 취약성 테스트 예시로 언급.[^11]
- 카나리 배포: 일부 트래픽/환경에서 먼저 변경을 적용해 위험을 줄이는 배포 전략으로, 릴리즈 프로세스 예시에 포함.[^32]
참고(콘텐츠 정보)[^40]
- 제목: AWS에서 DevOps - CI/CD 시작하기[^40]
- 채널: Amazon Web Services Korea[^40]
- 길이: 37분 15초[^40]
- 링크: https://www.youtube.com/watch?v=E1wHAlJUk2w[^40]
[^1]: @[00:59] “데브옵스…CI/CD…용어를 많이 들어오…”부터 전체 주제를 소개하며 DevOps/CI/CD를 설명하는 세션 전개.
[^2]: @[00:08] “이번 시간에는 데브옵스가 무엇이고 AWS에서는 어떻게 구성할 수 있는지 소개…”
[^3]: @[00:19] “질문하는 방법… Questions 창… 기본적으로 모든 질문은 공개… 비공개라고…”
[^4]: @[01:05] “데브옵스가 실제로 무엇인가… 정의하기 어려운…” + @[00:47] 목차에서 “무엇이고 왜 필요한지”
[^5]: @[01:26] “DevOps… Development와 Operation의 합성어… 단순히 통합 의미 아님… 생산성과 안정성 최적화… 더 빠르게 전달”
[^6]: @[02:06] “데브옵스를 이루는 3가지 요소… 문화(사고방식)… 장벽 제거… QA/보안… 수명주기 관리”
[^7]: @[03:59] “CI/CD 파이프라인… IaC… 모니터링… 도구 포함”
[^8]: @[04:32] “초기… 간단한 3티어… 모놀리식… 일관된 소스 관리 및 배포 자동화 필요”
[^9]: @[05:37] “서비스 성장… 마이크로서비스… 각각 파이프라인… 도구 도입 검토(자동화/배포전략/IaC/라이선스/운영환경)”
[^10]: @[07:04] “파이프라인 단계별 요구사항… IT 거버넌스 차원에서 결정… 커밋 시 빌드/피어리뷰…”
[^11]: @[08:32] “테스트 환경 자동화… 부하 테스트… UI 테스트… OWASP Top10… 스테이지… QA 검증… 프로덕션… 모니터링… 빠른 롤백”
[^12]: @[11:02] “AWS 개발자 도구… 프로세스 자동화… 다른 AWS 서비스와 쉽게 연동…” + @[11:28] “소스코드 저장/버전관리/자동 구축·테스트·배포…”
[^13]: @[12:01] “CodeCommit… 완전 관리형… GitHub 퍼블릭 모드 보안 사고… CodeCommit 기본값… Git 커맨드” + @[12:45] 레포 필요성(탐색기 예시)
[^14]: @[14:02] “무심결에 퍼블릭 오픈… 토큰/액세스 키 커밋… 해킹 타겟… GitLab 망분리…”
[^15]: @[15:14] “인터프리터 언어는 빌드 서비스 없을 수도… Java/.NET 컴파일 필요… Jenkins… GitHub Actions… 전체 빌드로 문제 파악”
[^16]: @[16:41] “CodeBuild… 완전 관리형 빌드 서비스… 자동 확장… 병렬 1000개… 캐시… 불변 환경”
[^17]: @[17:28] “빌드 환경 정보 정의… 관리형 이미지… 커스텀 필요 시 컨테이너로 매칭”
[^18]: @[18:33] “CodeBuild 실행 위해 buildspec 작성… YAML 형식… 명령/설정…” + @[19:03] 컨테이너 이미지 빌드 작업도 활용
[^19]: @[19:30] “buildspec에 리포트 위치 명세… 리포트 그룹… 성공/실패/수행 시간/유닛테스트 세부”
[^20]: @[20:01] “CodeDeploy… 테스트/스테이지/프로덕션 배포… 배포 전략… 에러 시 자동 롤백… 타겟 EC2/온프레미스… 에이전트”
[^21]: @[21:22] “애플리케이션/배포 대상/디플로이먼트 그룹… deployments 클릭…”
[^22]: @[22:32] “appspec… 수명주기 이벤트 훅… 로드밸런서에서 제거→패키지 설치→시작→테스트→다시 추가”
[^23]: @[23:12] “배포 속도/배포 그룹… 한 번에 하나씩… 온프레미스는 AB 테스트(언급상) 제한”
[^24]: @[24:22] “CodePipeline… 완전 관리형 지속적 전달… 인프라 신경 불필요… 타사(GitHub 등) 통합”
[^25]: @[25:08] “CodePipeline 3가지… 소스 변경 트리거(레포/S3/컨테이너 이미지/스케줄)… 빌드 공급자(CodeBuild/Jenkins)”
[^26]: @[26:05] “배포 타겟 EC2/온프레미스/ECS… 간단 워크플로… 승인 절차 포함 가능”
[^27]: @[26:57] “Jenkins 시나리오… EC2에 Jenkins 설치/구성… 트리거…”
[^28]: @[28:02] “Jenkins 빌드 완료… 결과 S3 저장… CodePipeline 업데이트… CodeDeploy로 배포”
[^29]: @[29:08] “AWS 개발 도구로 동일 파이프라인… 커밋 트리거… CodeBuild 완전 관리형… 오버헤드 감소… 디플로이로 전달”
[^30]: @[30:08] “GitHub Actions… 레포 생성→커밋→워크플로 지정… Maven 빌드→디플로이… 커버리지 등”
[^31]: @[31:22] “지속적 통합 정의… 중앙 레포 정기 병합… 여러 사람… 버전 관리… 체크아웃/로컬 변경/컴파일/테스트/커밋 빈번”
[^32]: @[32:09] “CI 목표… 버그 신속 해결/품질 개선/검증 시간 단축” + @[32:36] “커밋→유닛→CodeBuild→카나리→스테이징→프로덕션”
[^33]: @[33:00] “지속적 배포… 스테이징 자동 배포… 통합/부하 테스트… 고객 영향 최소… 제로 다운타임… 변경 실패율 감소”
[^34]: @[34:05] “Cloud9… 클라우드 기반 IDE… 웹에서 작성/실행/디버깅… 어디서나… SDK/라이브러리/플러그인… 환경 통일”
[^35]: @[35:10] “Cloud9에서 커밋→CodeCommit 반영→CodePipeline 자동 동작→애플리케이션 자동 배포까지 핸즈온 커버”
[^36]: @[35:37] “DevOps는 조직마다 다양… 궁극 목표 동일… 생산성+안정성 최적화→더 빠르게 고객 전달… 어떤 툴/방식 적합한지 고민… GitHub Actions 소개 이유(빠른 도입/범위 줄이기)”
[^37]: @[36:50] “감사… 피드백… 10분 쉬고 핸즈온”
[^38]: @[02:06]~@[03:59] DevOps 3요소와 도구 필요성 전개 + @[07:04] 거버넌스 강조 + @[10:07] 롤백 강조.
[^39]: @[01:26]~@[03:59], @[31:22]~@[33:55] 각 용어가 직접 정의/설명되는 구간 전반.
[^40]: 사용자가 제공한 메타데이터(제목/채널/길이/링크).