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

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

[? 질문] 왜 요즘 DevOps가 크게 화두가 되었는가[^2]
[= 답] 전통적 개발/배포 모델(여러 팀이 하나의 배포 파이프라인 공유)에서는 개발 규모가 커질수록 변화 파악이 어려워지고 릴리즈 주기가 길어져 운영에서 신규 버전 배포·버그 수정이 점점 어려워졌기 때문이다.[^3]

[? 질문] 마이크로서비스/사일로로 나눈 뒤에는 무엇이 새 문제로 등장하는가[^4]
[= 답] 서비스가 2~3개에서 많게는 100개 가까운 마이크로서비스로 나뉘면 팀은 민첩해지지만, 그만큼 파이프라인/품질/보안/안정성을 통합적으로 관리할 방식이 필요해진다.[^5]

[? 질문] CI/CD 자동화는 왜 필요한가(무엇을 가져오는가)[^6]
[= 답] 자동화된 파이프라인은 코드 변경을 감지해 빌드·테스트·배포를 수행하고, 빠른 피드백으로 실패를 앞당겨(“빨리 실패”) 품질과 안정성을 높이며, 사람 개입으로 생기는 취약성과 부채를 줄여 작고 빈번한 릴리즈를 가능하게 한다.[^7]

---

2. 큰 그림[^8]

이 콘텐츠는 AWS 개발자 부트캠프에서 DevOps와 CI/CD를 “왜 필요한가”에서 출발해 “어떻게 구성하는가(AWS 도구 관점)”까지 연결해 설명한다.[^9] 전통적 배포 모델의 한계를 짚고, 마이크로서비스 시대의 운영/품질 문제를 해결하는 방향으로 DevOps를 문화·실천·도구의 통합으로 정의한 뒤, CI(통합)와 CD(전달/배포)의 개념 및 AWS Code 시리즈(CodeCommit/CodeBuild/CodeDeploy/CodePipeline)의 역할을 흐름대로 소개한다.[^10]

• DevOps는 특정 직무명이 아니라 오너십 기반의 문화와 실천, 그리고 이를 뒷받침하는 도구의 통합이다.[^11]
• CI/CD는 소스가 운영에 전달되는 전 과정을 자동화해, 더 자주 배포하고 더 빨리 실패할수록 소프트웨어가 더 안정적이 되는 방향을 만든다.[^12]
• AWS는 저장소(CodeCommit), 빌드(CodeBuild), 배포(CodeDeploy), 파이프라인 통합/시각화(CodePipeline)으로 이어지는 구성(및 서드파티 연동)을 통해 자동화와 표준화를 지원한다.[^13]

---

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

3.1 도입: 오늘의 주제는 DevOps와 CI/CD[^15]

발표자는 AWS 솔루션즈 아키텍트로서 오늘 다룰 큰 축을 DevOps와 DevOps의 대표 영역 중 하나인 CI/CD라고 소개한다.[^16] DevOps라는 용어가 “요즘 너무 많이 들리고 직감적으로도 많이 노출”되는 상황을 전제하면서, 왜 이것이 화두가 되었는지부터 설명을 시작한다.[^2]

3.2 DevOps가 화두가 된 배경: 전통적 배포 모델의 한계[^17]

발표자는 과거 “전통적인 애플리케이션 모델”을 먼저 제시한다.[^3] 이 모델에서는:

• 하나의 배포 파이프라인을 여러 팀이 공유해 사용했다.[^3]
• 대형 프로젝트가 하나의 리포지토리 또는 파이프라인으로 빌드·배포되었다.[^3]
• 적게는 10명, 많게는 100명 정도의 개발자가 같은 프로젝트에 참여하는 환경이었다.[^3]

이 구조에서 문제가 누적된다.[^18]

1. 개발 중인 피처가 무엇인지 파악이 어려워진다[^18]
   여러 팀/여러 사람이 같은 흐름을 공유하다 보니 “현재 개발 중인 개발 피처가 어떤 건지 알기도 어렵”다고 말한다.[^18]

2. 개발과 릴리즈 사이 주기가 길어진다[^18]
   공유 파이프라인과 대규모 협업은 결과적으로 “개발과 릴리즈 사이의 주기가 많이 길어지게” 만든다.[^18]

3. 운영에서 신규 버전 릴리즈와 버그 수정이 어려워진다[^19]
   릴리즈가 길어지면 운영에서 새 버전을 내는 것도, 발견된 버그를 고치는 것도 점점 어려워진다고 연결한다.[^19]

4. 결과적으로 “차세대 프로젝트/대규모 업데이트”로 혁신이 늦어지는 현상[^20]
   발표자는 이런 상황이 익숙한 단어로 귀결된다고 말한다. 즉 “차세대 프로젝트”, “대규모 업데이트” 같은 이름으로 개발·배포 규모가 커지고, 혁신이 늦춰지는 문제가 생긴다는 것이다.[^20]

3.3 해결 시도: 사일로 분리와 마이크로서비스 — 자유는 늘고, 관리 과제는 커진다[^21]

이 문제를 해결하기 위해 많은 회사가 “사일로 형태로 서비스를 나누”기 시작했다고 말한다.[^22] 그 결과:

• 하나의 서비스가 적게는 2~3개, 많게는 100개 가까운 마이크로서비스로 나뉘어 개발·운영된다.[^5]

발표자는 이 환경이 개발자에게 주는 “자유”를 강조한다.[^23]

• 소규모 팀이 빠르게 개발할 수 있다.[^23]
• 다른 사일로에 직접적인 영향을 덜 받으면서 운영에 릴리즈할 수 있다.[^23]

그런데 서비스가 쪼개지고 파이프라인이 많아지면 새로운 질문이 등장한다.[^24]

[? 질문] 서비스가 많아졌을 때, “이 많은 파이프라인은 어떻게/누가 관리해야 하는가”[^24]
[= 답] 사일로마다 별도 운영 이력이 필요해지는 식은 바람직하지 않고, 파이프라인뿐 아니라 코드 품질·보안·안정성까지 통합된 관리가 필요하다.[^25]

여기서 발표자는 “모든 사일로마다 별도의 운영 이력이 필요하다면 그건 좀 잘못된 형태”라고 말하며, 파이프라인 관리만이 아니라 여러 품질 속성을 함께 표준화/통합하는 필요로 확장한다.[^25]

3.4 DevOps의 정의: 직무가 아니라 “문화·실천 방향·도구 통합”[^26]

발표자는 최근 다양한 개발 문화가 교류·도입되고 있고, 단지 파이프라인 관리가 아니라 혁신 속도를 앞당기고 시장을 선도하기 위해 다음을 동시에 노린다고 말한다.[^27]

• 개발팀의 생산성 확보[^27]
• 제품의 퀄리티 향상[^27]

그 맥락에서 DevOps를 이렇게 정리한다.[^11]

• DevOps는 단순히 직무를 의미하기보다, 목적(혁신/생산성/품질)을 위한 문화이자 실천 방향이며
• 이를 위한 도구들을 통합한 것이라고 설명하고 싶다고 말한다.[^11]

3.5 DevOps의 출발점: 개인/조직의 오너십과 수명주기 책임[^28]

발표자는 “시작”을 문제 해결을 위한 개인과 조직의 오너십으로 둔다.[^29] 조직 형태가 어떻든 다음 관점을 가져야 한다고 말한다.[^30]

• 전체 개발 및 인프라의 수명주기를
• “스스로 책임영역으로 고려”해야 한다.[^30]

또한 단순히 일정에 맞춰 코드를 작성하고, 리뷰하고, 릴리즈하는 수준에서 끝나지 않는다고 말한다.[^31] 필요한 조직과 “자주 소통”하며, 개발팀 생산성과 서비스 품질을 “모두 함께” 고려해야 한다는 식으로 확장한다.[^31]

3.6 변화는 ‘무조건’이 아니라 ‘계산’의 대상: 기술 부채와 점진적 개선[^32]

발표자는 균형점도 제시한다.[^33]

• 적극적인 변화와 혁신만이 정답은 아니다.[^33]
• 이미 잘 구성된 애플리케이션에 불필요한 변화를 가할 필요는 없다.[^33]

하지만 동시에, 변화가 “비싸고 두려워서” 계산하지 않으면 기술 부채가 나중에 더 큰 부채가 되어 돌아온다고 경고한다.[^34] 그래서 “전체 애플리케이션의 변화를 한 번에” 하기보다, 크리티컬 포인트부터 차근차근 개선하면 오히려 나중에 더 많은 것을 개선할 수 있다고 말한다.[^35]

3.6.1 예시 1: 평문 DB 연결정보 → 시크릿 관리로 전환(보안 변화의 시작)[^36]

당장 리포지토리에 플레인 텍스트로 저장된 DB 연결 정보를 시크릿 매니지먼트 관점에서 “개선”하는 것만으로도, 보안 측면에서 큰 변화의 시작이 될 수 있다고 예를 든다.[^36]

3.6.2 예시 2: 서비스 간 통신에 서킷 브레이커 적용(안정성 변화)[^37]

서비스가 잘 나뉘어 있다면, 서비스 간 통신 구간에 서킷 브레이커를 두어 장애 전파를 막는 형태로 개선하면 전체 서비스 안정성에 “매우 큰 변화”를 가져올 수도 있다고 말한다.[^37]

3.6.3 CI/CD도 같은 ‘개선 포인트’다: 자동화된 배포 파이프라인[^38]

발표자는 “오늘 설명드릴 지속적 통합과 배포도 마찬가지”라고 연결한다.[^39] 자동화된 배포 파이프라인은 작성한 코드를 자동 테스트하고 릴리즈해준다고 설명한다.[^39]

3.7 도구의 발달: 파이프라인을 ‘직접 개발’하지 말고 활용하라[^40]

발표자는 자동화된 파이프라인을 직접 만들려면 비용/난이도가 크다고 말한다.[^41]

• 소스코드 변화를 탐지하고[^41]
• 자동 빌드를 수행하고[^41]
• 테스트/운영 환경에 각각 릴리즈하는 도구를 직접 개발하는 것은 “매우 어렵고 비싼 일”이라는 것이다.[^41]

하지만 “지금은 도구의 발달”로 애플리케이션 개발에 집중할 수 있으니 도구를 최대한 활용하라고 권한다.[^42] 이어서 CI/CD 전달 과정(파이프라인)을 자세히 설명하겠다고 예고한다.[^43]

3.8 자동화된 배포 프로세스의 효과: 측정된 수치 비교의 의미(2019 DORA 리포트 언급)[^44]

화면 자료로 “2019년도 DORA에서 발표한 리포트”를 언급한다.[^45] 자료가 몇 년 되었지만 핵심은 “자동화된 배포 프로세스에 대해서 실제 측정된 수치 비교”라는 점이라고 강조한다.[^45]

이 지점에서 발표자는 릴리즈 기간이 늘어질 때의 실무적 함의를 설명한다.[^46]

• 릴리즈가 늦어지는 것 자체뿐 아니라, 릴리즈까지 시간이 길어지면 더 많은 변경이 그 사이에 끼어들 수 있다.[^46]
• 예로 “새로운 개발자가 자신의 소스 코드를 또 묻고… 이번에 배포할래요” 같은 식으로 변경이 추가된다고 말한다.[^47]
• 개발자는 완벽하지 않기 때문에, 더 많은 개발자와 더 많은 코드가 개입할수록 장애 확률이 더 높아진다는 의미도 된다고 말한다.[^48]

결론은 다음 문장으로 요약된다.[^12]

• “더 자주 배포하고”
• “과정에서 더 빨리 실패할수록”
• “더 안정적인 소프트웨어”가 된다는 것이다.[^12]

3.9 CI/CD의 개념 정의: CI(통합)와 CD(전달/배포) 구분[^49]

발표자는 CI/CD 파이프라인을 “소스 코드가 운영 환경에 전달되는 전체 파이프라인을 자동화한 형태”로 정의한다.[^50]

3.9.1 CI(Continuous Integration): 피처를 하나의 브랜치로 통합하는 과정[^51]

CI, 즉 “자동화된 통합”은 각각 작성된 피처가 “하나의 브랜치로 통합되는 과정”이라고 설명한다.[^51]

3.9.2 CD(Continuous Delivery/Deployment): 빌드하여 실행 환경에 배포해 서비스하는 과정[^52]

CD는 통합된 소스 코드를 빌드하고 실행 환경에 배포해 서비스하는 것을 의미한다.[^53] 또한 CD가 두 의미(Delivery와 Deployment)를 함께 가리킨다고 정리한다.[^54]

• Continuous Delivery(지속적 전달): “누군가의 수동 승인”이 배포 과정에 반드시 포함되어야 하는 경우[^55]
• Continuous Deployment(지속적 배포): 모든 과정이 자동화된 형태[^56]

3.10 지속적 통합 환경에서 일어나는 일: 자동 병합, 리뷰/테스트, 빠른 피드백[^57]

지속적 통합 환경을 갖추면 개발자의 소스코드는 자동화 과정을 거쳐 중앙 리포지토리에 병합된다고 말한다.[^58] 이 과정에서:

• 필요한 리뷰와 테스트를 거친다.[^58]
• 결과는 개발자에게 자연스럽게 피드백된다.[^58]

발표자는 “때로는 소스코드가 빌드되기도 전에 실패할 수도” 있다고 말하며, 이처럼 빠른 시점의 피드백이 최소 품질을 보장하는 안전장치가 되어 개발자에게 더 안전한 환경을 제공한다고 설명한다.[^59]

3.11 코드 레벨 테스트와 정적 분석: 빠르고 반복 가능, 의도 전달, 보안/세이프티 강화[^60]

발표자는 코드 레벨에서 수행되는 테스트의 특성을 다음과 같이 말한다.[^61]

• 매우 빠르고 반복적으로 실행될 수 있다.[^61]
• 따라서 이 단계 테스트를 “반드시 거치는 것”을 추천한다.[^61]

또한 테스트 코드가 잘 작성되면, 코드를 작성한 사람의 “의도를 주석보다 더 정확히 이해”할 수도 있다고 말한다.[^62]

정적 분석 도구 예시로 SonarQube를 들며, 새로 작성된 메서드를 직접 읽는 것보다 시큐리티/세이프티한 코드 작성을 “보장받을 수 있다”는 식으로 설명한다.[^63]

마지막으로 코드 레벨 테스트의 가장 큰 장점을 “실패 지점이 매우 앞에 있다”는 것으로 정리한다.[^64] 운영에 릴리즈된 뒤 버그가 발견되는 것보다, 코드 레벨 테스트에서 문제가 발견되면:

• 적시에 고치기 쉽고[^65]
• 서비스 품질에 영향을 미치지 않게 할 수 있다고 말한다.[^65]

3.12 코드 리뷰: 기능이 아니라 문화, ‘지적’이 아닌 ‘토론’으로 설계하기[^66]

발표자는 코드 리뷰를 다룰 때, 이미 하고 있는 사람도 있고 익숙하지 않은 사람도 있을 것이라며 청중 상황을 가정한다.[^67] 그리고 코드 리뷰는 기능적(펑션)이라기보다 문화적 요소에 가깝다고 규정한다.[^68]

한국 문화 맥락에서는 코드 리뷰가 “누군가의 코드를 지적하는 것처럼” 느껴져 잘 안 하게 되고 활성화가 잘 안 될 수 있다고 말한다.[^69] 표현이 다소 거칠 수 있지만 “악플다는 것처럼” 느껴질 수도 있다고도 덧붙인다.[^70]

반면 미국에서는 코드 리뷰가 토론 문화에 가깝다고 설명한다.[^71] 여기서 발표자는 “미국 문화가 반드시 좋다”는 뜻이 아니라, “그들이 어떤 도구로 이것을 사용하고 있었는지 제거해 볼 필요가 있다”는 취지라고 단서를 단다.[^72] (즉, 문화의 우열이 아니라 ‘운영 방식/도구로서의 코드 리뷰’를 학습하자는 방향이다.)[^72]

코드 리뷰의 효과를 두 갈래로 제시한다.[^73]

1. 품질 검토 측면[^73]
2. 내가 개발하지 않는 부분의 변화 인지(가시성) 측면[^73]

구체 예시를 든다.[^74]

• 내가 결제 부분을 작업 중인데, 코드 리뷰 과정에서 인증 부분 소스 변경이 발생했음을 알게 된다.[^74]
• 그러면 인증 쪽 코드를 보고 결제 코딩 시 코드 스타일을 어떻게 적용할지 참고하거나, 어떤 변화가 생기는지 더 미리 캐치업할 수 있다는 장점이 있다고 말한다.[^75]

또한 코드 리뷰 과정은 프로젝트/서비스의 오너십에도 도움이 된다고 말한다.[^76] 코드를 작성한 사람뿐 아니라 리뷰 참여자도 서비스에 대한 오너십을 갖게 된다는 것이다.[^76]

실천 팁도 제안한다.[^77]

[!TIP] 코드 리뷰 참여가 부담되면 “이모지”로 시작하기
직접적으로 댓글을 달기 어렵다면, 이모지를 통해서라도 리뷰에 참여해보라고 추천한다.[^77]

3.13 CI 도구(코드 저장소): AWS CodeCommit 소개와 VCS 연상[^78]

지속적 통합을 위한 도구는 다양하지만, AWS에서는 CodeCommit이라는 “깃 기반 리포지터리 서비스”를 제공한다고 말한다.[^79] 브랜치 전략을 통해 개발과 통합 기능을 제공하며, GitHub/GitLab/Bitbucket 같은 버전 컨트롤 서비스와 같은 역할이라고 이해하면 된다고 설명한다.[^80]

3.14 빌드 단계: 표준화된 아티팩트 생성과 AWS CodeBuild의 성격(서버리스, 격리 컨테이너, 연동성)[^81]

통합된 코드는 배포 파이프라인을 타면서, 정해진 빌드/테스트 과정을 수행해 “표준화된 빌드 아티팩트”가 생성된다고 말한다.[^82]

언어별 빌드 차이도 짚는다.[^83]

• 컴파일/패키징이 필요한 .NET/Java 계열은 이 단계에서 빌드가 수행된다.[^83]
• Python 같은 인터프리터 언어는 별도 컴파일 과정이 없을 수 있다고 덧붙인다.[^84]

이때 AWS CodeBuild를 “다양한 환경에 맞는 빌드 아티팩트를 제작할 수 있는 서비스”로 소개한다.[^85] 이해를 돕기 위해 “보통 젠킨스 역할”이라고 비유한다.[^86] 다만 Jenkins는 탄력적 운영이 어려운 반면, CodeBuild는 서버리스여서 요청에 따라 볼륨이 늘었다 줄었다 하는 가변성을 가진다고 비교한다.[^87]

추가 특징으로:

• 매 빌드마다 격리된 컨테이너에서 빌드가 수행된다.[^88]
• CodeCommit뿐 아니라 GitHub/Bitbucket 같은 다양한 VCS와도 손쉽게 결합 가능하다고 말한다.[^89]

3.14.1 빌드 설정을 “코드로 관리” (buildspec 등)하는 방식[^90]

발표자는 CodeBuild 설정이 화면처럼 “코드 형태로 관리 가능”하다고 말한다.[^91] 구체적으로 코드에 담을 수 있는 설정 예를 다음처럼 나열한다.[^92]

• 빌드 단계에서 어떤 변수를 사용할지[^92]
• 빌드 시 어떤 명령어를 수행할지[^92]
• 빌드 후 어떤 테스트를 수행할지[^92]
• 리포트를 어떻게 받을지[^92]
• 결과물은 어디에 저장할지[^92]

샘플 코드가 더 확장된 형태로 제시되며, 필요한 설정을 변수화해 “리드 환경에서 읽어올 수 있도록” 구성할 수 있다고 말한다.[^93]

또한 설정을 통해 리포트를 만들고, 이를 AWS 콘솔에서 시각화해 보여줄 수 있다고 설명한다.[^94] 나아가 서비스에서 코드 품질 검수가 필요하다면, 이 결과물을 “코드 품질 검수 결과로 제출”할 수도 있다고 말한다.[^95]

발표자는 GitHub Actions나 Jenkins를 많이 사용할 텐데, CodeBuild도 “써드파티 도구들과 같은 역할”로 이해하면 된다고 정리한다.[^96]

3.15 배포 단계: AWS CodeDeploy와 롤백, 훅, 다양한 배포 전략(무중단 포함)[^97]

이제 “빌드를 실제 환경에 전달하고 배포하는 일”이 남았다고 전환한다.[^98] 과거에는 무중단 배포를 위해 다양한 스크립트와 스킬이 필요했지만, AWS CodeDeploy는 이러한 설정들을 기본적으로 내포하고 필요한 형태로 설정해서 사용할 수 있다고 말한다.[^99]

배포를 “새 버전 설치로 끝나는 것”이 아니라, 장애를 인지하고 롤백할 수 있도록 구성되어야 한다고 강조한다.[^100] CodeDeploy는 “정해진 규칙에서 오류가 발생할 경우 자동으로 현재 배포를 롤백”하도록 구성할 수 있다고 말한다.[^101]

CodeDeploy도 마찬가지로 설정을 코드 형태로 저장/관리할 수 있다고 말한다.[^102] 또한 다양한 **훅(hook)**을 지원하며, 이를 스크립트로 설정해 애플리케이션에 맞는 배포 구성을 할 수 있다고 설명한다.[^103]

무중단 배포를 위한 “다양한 배포 방식”도 열거한다.[^104]

• 한번에 하나씩 배포[^104]
• 절반씩 배포[^104]
• 한 번에 다 배포[^104]
• 블루/그린 같은 형태[^104]

이런 방식들을 “별도의 작업 없이 손쉽게 설정으로 구성”할 수 있다고 말한다.[^105]

3.16 잘 구성된 CI/CD 파이프라인으로 얻는 것: IaC 동기화, 시각화, 자동화된 검증 도구화[^106]

발표자는 “이렇게 구성된 CI/CD 파이프라인을 통해서 어떤 것들을 얻을 수 있는지”를 다시 짚는다.[^107]

1. 애플리케이션뿐 아니라 인프라 설정도 코드로 관리[^108]
   요즘에는 인프라 설정도 코드 형태로 관리한다고 말하며, CDK 또는 IaC 같은 도구를 언급한다.[^108] 이를 파이프라인에 녹여 애플리케이션과 인프라 설정을 동기화해 자동화할 수 있다고 설명한다.[^109]

2. 파이프라인의 직관적 시각화와 이해도 향상[^110]
   잘 구성된 파이프라인은 직관적으로 시각화되며, 모르는 사람이 와서 파이프라인을 “보는 것만으로도 전체 애플리케이션을 이해”하는 데 도움이 될 수 있다고 말한다.[^111]

3. 배포를 “업무”가 아니라 자동화된 검증 도구로 활용[^112]
   궁극적으로 배포를 기존 업무가 아니라 자동화된 검증 도구로 이용할 수 있게 된다고 말한다.[^112]

파이프라인을 단계별로 잘 구성하면 앞서 장점을 “가정”할 수 있다고 하면서, 설계 시 고려사항도 말한다.[^113]

• 애플리케이션에 맞게 병렬 구성을 하거나[^113]
• 단계별 의존성을 고려해야 한다.[^113]

또한 파이프라인 실행 트리거도 다양하게 구성할 수 있다고 말한다.[^114]

• 소스 코드 변경 시 트리거[^114]
• 정해진 주기에 빌드를 수행하는 것이 적합한 서비스도 있으며, 이 경우 스케줄 기반 트리거가 좋은 수단이 될 수 있다고 말한다.[^115]

3.17 단계별로 다시 짚는 CI/CD 흐름: 개발→리뷰/의존성/빌드→테스트/정적분석→통합테스트/배포→오류 발견/수정/재배포[^116]

발표자는 파이프라인을 단계별로 다시 짚는다.[^117]

3.17.1 개발 단계: 짧고 빠르게 반복, 커밋 순간 파이프라인 시작[^118]

개발 단계에서는 실행 주기가 “짧고 빠르게 반복”되어야 하며, 코드를 작성하고 커밋하는 순간 파이프라인이 시작된다고 말한다.[^119]

3.17.2 리뷰/의존성 확인/빌드: 놓친 것 재검토, 의존 패키지 버전 점검[^120]

커밋된 코드는 리뷰하고, 의존성 확인을 거쳐 빌드 단계에 도달한다.[^121] 이 과정에서 놓친 것이 없는지 검토하고, 의존 패키지의 버전 같은 것을 한 번 더 살펴봐야 한다고 말한다.[^122]

3.17.3 자동화 테스트/정적 분석 기반으로 “정형화된 결과물” 획득[^123]

자동화된 테스트, 정적 분석 결과 등을 토대로 정형화된 과정을 거쳐 결과물을 얻는 단계라고 정리한다.[^124]

3.17.4 그래도 오류는 난다: 단계별 배포/통합 테스트로 빨리 발견하고 재배포[^125]

아무리 철저히 검증해도 오류는 발생할 수밖에 없다고 말한다.[^126] 그래서 각 단계별 배포 과정과 통합 테스트 과정으로 오류를 발견하고 빠르게 수정 후 재배포하는 단계가 필요하다고 설명한다.[^127]

여기서 발표자는 “오류를 발견하는 것이 매우 중요”하다고 강조한다.[^128] 그리고 역설적으로, “치명적인 오류를 운영 배포 전에 발견하기만 한다면” 이 긴 과정이 모두 의미 있어진다고 말한다.[^129]

3.18 AWS CodePipeline: Code 시리즈 통합과 서드파티 연동, 파편화 해소의 시작[^130]

발표자는 AWS CodePipeline을 CodeCommit/CodeBuild/CodeDeploy를 통합한 “파이프라인 서비스”로 소개한다.[^131] 그리고 Code 시리즈 외에도 “다양한 서드파티 도구들과도 통합”된다는 장점이 있다고 말한다.[^132]

특히 파이프라인이 시각화되지 않고 “파편화”되어 있다면, 이것들을 통합하는 것만으로도 큰 변화의 시작이 될 수 있다고 말한다.[^133]

3.19 예시 아키텍처: GitHub → 아티팩트(S3) → Jenkins 빌드 → CodeDeploy 배포[^134]

발표자는 CodePipeline과 다양한 서드파티를 통합한 예제를 보여준다.[^135]

• 왼쪽에 “시각화된 파이프라인”이 있고[^135]
• GitHub에서 변경점이 발견되면 통합 과정을 거쳐 소스 아티팩트 저장소와 S3에 업로드된다.[^136]
• 새로운 빌드 잡이 생기면 Jenkins가 소스 저장소/아티팩트에 접근해 소스를 가져오고 빌드를 수행한다.[^137]
• 빌드 완료 결과가 보고되면 CodeDeploy를 통해 애플리케이션을 타겟에 배포한다.[^138]

그리고 “당연히 Code 시리즈만으로도 통합 구성 가능”하지만, 그 경우 앞선 예시보다 조금 더 단순하게 구성된다고 말한다.[^139]

3.20 이벤트 기반 동작과 트리거: 스테이지 이벤트가 파이프라인을 움직인다[^140]

발표자는 AWS 시리즈 서비스들이 모두 이벤트 기반으로 동작한다고 말한다.[^141] 그래서 파이프라인의 트리거는 “각 스테이지에서 발생되는 이벤트”라는 식으로 정리한다.[^141]

또한 CI/CD 파이프라인 외에도 AWS가 개발자를 위한 다양한 도구를 제공하며, 배포 과정과 관련해서는 CodePipeline으로 통합 관리할 수 있다고 말한다.[^142]

3.21 마무리: 자동화는 작고 빈번한 릴리즈에 필수, 사람 개입은 취약성과 부채를 만든다[^143]

발표자는 결론적으로 자동화 작업이 “작고 빈번한 릴리즈 과정에 매우 필수적”이라고 말한다.[^144] 그리고 사람 개입이 있는 모든 단계는 취약성을 가질 수밖에 없으며, 이 과정에서의 “타협”은 여러 업무에 더 큰 부채를 만든다고 경고한다.[^145]

마지막으로 자동화된 릴리즈를 통해 업무를 간편하게 하고, 그 과정에서 수집한 지식을 활용해 프로세스를 지속적으로 발전시키라고 권하며 마친다.[^146]

---

4. 핵심 통찰[^147]

1. DevOps는 “도구 도입”보다 먼저 오너십과 문화의 문제로 정의된다.[^29]

   • 개발·인프라 수명주기를 책임 영역으로 보고, 소통과 품질/생산성을 함께 본다는 관점이 핵심 전제다.[^31]

2. 전통적 “공유 파이프라인” 구조는 규모가 커질수록 변경 파악이 어려워지고 릴리즈가 길어져, 운영에서 버그 수정/신규 릴리즈가 어려워지는 구조적 한계를 드러낸다.[^18]

3. 마이크로서비스로 쪼개면 민첩성은 늘지만, 파이프라인·보안·품질·안정성의 통합 관리가 새 과제가 된다.[^25]

4. CI/CD의 실무적 가치는 “더 자주 배포” 그 자체보다, 실패를 앞당겨(빠른 피드백) 장애 확률과 영향 범위를 줄이는 데 있다.[^12]

5. 테스트/정적 분석/코드 리뷰는 단절된 체크리스트가 아니라, 파이프라인에서 자동화/문화로 결합될 때 효과가 커진다.[^58]

   • 실행 가능한 시사점:
     • 코드 레벨 테스트를 빠르고 반복 가능한 안전장치로 두기[^61]
     • 정적 분석(예: SonarQube)로 보안/세이프티 기준을 자동화하기[^63]
     • 코드 리뷰를 ‘지적’이 아니라 ‘토론/가시성/오너십’ 도구로 재설계하기[^71]
     • 리뷰 참여 장벽을 낮추기 위해 이모지부터 시작하기[^77]

6. AWS Code 시리즈는 저장소-빌드-배포-파이프라인을 각각 제공하면서, 특히 CodeBuild의 서버리스/격리 컨테이너, CodeDeploy의 훅/자동 롤백, CodePipeline의 시각화·통합으로 “직접 만들기 비싼 파이프라인”을 서비스로 대체한다는 메시지를 준다.[^87]

---

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

• DevOps: 단순 직무가 아니라, 혁신 속도·생산성·품질을 위해 오너십 기반으로 개발/운영을 함께 바라보는 문화·실천 방향·도구 통합.[^11]
• CI(Continuous Integration): 각자 개발한 피처를 하나의 브랜치로 통합하는 자동화된 과정.[^51]
• CD(Continuous Delivery/Deployment): 통합된 소스를 빌드해 실행 환경에 배포하는 과정(Delivery/Deployment를 함께 지칭).[^53]
• Continuous Delivery(지속적 전달): 배포 과정에 수동 승인이 반드시 포함되는 형태.[^55]
• Continuous Deployment(지속적 배포): 배포의 전 과정이 완전 자동화된 형태.[^56]
• 서킷 브레이커(Circuit Breaker): 서비스 간 통신에서 장애 전파를 막기 위한 패턴/장치로, 안정성 개선 예시로 언급됨.[^37]
• IaC(Infrastructure as Code) / CDK: 인프라 설정을 코드로 관리해 파이프라인에 포함시키고 애플리케이션과 인프라 설정을 동기화하는 흐름에서 언급됨.[^108]
• CodeCommit: AWS의 Git 기반 리포지터리 서비스.[^79]
• CodeBuild: 서버리스 빌드 서비스(격리 컨테이너 기반, VCS 연동, 설정을 코드로 관리).[^87]
• CodeDeploy: 배포 서비스(훅 지원, 다양한 배포 전략, 오류 시 자동 롤백).[^101]
• CodePipeline: Code 시리즈 및 서드파티를 통합/시각화하는 파이프라인 서비스.[^131]
• SonarQube: 정적 분석 도구 예시(보안/세이프티한 코드 작성을 돕는 맥락).[^63]

---

---

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

• 제목: AWS에서 DevOps, CICD 시작하기 (AWS 개발자 부트캠프)[^149]
• 채널: Amazon Web Services Korea[^149]
• 길이: 22분 22초[^149]
• 링크: https://www.youtube.com/watch?v=Dofh_X0ta2g[^149]

---

[^1]: @[00:11] “오늘 다루게 될 주제는 크게 … devops … cicd입니다.” [^2]: @[00:21] “우선 DevOps라는 말은 요즘 너무 많이 들으시고… 왜 DevOps가 … 화두가 될까요” [^3]: @[00:31] “전통적인 애플리케이션 모델에서는 하나의 배포 파이프라인을 여러 팀들이 공유…” [^4]: @[01:21] “이에 많은 회사가 사일로 형태로 서비스를 나누게 되었습니다” [^5]: @[01:26] “적게는 두 세개 많게는 100개에 가까운 마이크로 서비스로 나뉘어서…” [^6]: @[04:37] “오늘 설명드릴 지속적 통합과 배포도 마찬가지입니다” [^7]: @[06:40] “더 자주 배포… 더 빨리 실패할수록 더 안정적인 소프트웨어”, @[21:59] “사람이 개입하는 모든 단계는 취약성…” [^8]: @[00:11] DevOps와 CI/CD를 주제로 삼는다는 구성 고지. [^9]: @[02:42] “문화이자 실천 방향… 도구들을 통합”, @[05:22] “지속적 통합과 배포 전달 과정… 자세히” [^10]: @[06:52] CI/CD 정의, @[07:01] CI, @[07:14] CD, @[11:25]~@[19:52] AWS 도구 흐름 [^11]: @[02:42] “DevOps는 … 문화이자 실천 방향 그리고 … 도구들을 통합한 것” [^12]: @[06:40] “더 자주 배포하고… 더 빨리 실패할수록 더 안정적인 소프트웨어” [^13]: @[11:25] CodeCommit, @[12:31] CodeBuild, @[14:55] CodeDeploy, @[19:42] CodePipeline [^14]: @[00:21]~@[22:11] 전체 전개를 시간 순서로 재구성. [^15]: @[00:11] 주제 소개. [^16]: @[00:03] 발표자 소개, @[00:11] DevOps와 CI/CD 주제. [^17]: @[00:31] 전통적 모델 설명 시작. [^18]: @[00:52] “피처… 알기 어렵고… 릴리즈 사이 주기 길어” [^19]: @[01:00] “운영 상황에서 새로운 버전을 릴리즈… 버그를 고치는 것도 어려운…” [^20]: @[01:12] “차세대 프로젝트… 대규모 업데이트… 혁신이 늦춰지는 문제” [^21]: @[01:21] 사일로 분리로 전환. [^22]: @[01:21] “사일로 형태로 서비스를 나누게 되었습니다” [^23]: @[01:34] “개발자들에게는 더 많은 자유…” [^24]: @[01:49] “이 많은 파이프라인은 어떻게 누가 관리해야 할지” [^25]: @[01:58]~@[02:06] “사일로마다 별도의 운영 이력… 잘못된 형태… 코드퀄리티 보안 이슈 안정성… 통합…” [^26]: @[02:21] 개발 문화 도입 언급. [^27]: @[02:26] “혁신의 속도… 생산성… 퀄리티…” [^28]: @[02:58] 오너십으로 전환. [^29]: @[02:58] “시작은 … 오너십입니다” [^30]: @[03:04] “전체 개발 및 인프라의 수명주기를… 스스로 책임영역” [^31]: @[03:15] “자주 소통… 생산성과 서비스 품질…” [^32]: @[03:32] 변화에 대한 균형 관점. [^33]: @[03:32] “적극적인 변화와 혁신만이 정답은 아닙니다” [^34]: @[03:43] “변화 자체가 비싸고 두려워서 계산하지 않으면… 기술 부채…” [^35]: @[03:54] “한 번에 … 하지 말고 크리티컬 포인트…” [^36]: @[04:06] “플레인 텍스트로 저장된… DB 연결 정보… 시크리트…” [^37]: @[04:23] “통신구간에 서킷브레이커… 장애 전파…” [^38]: @[04:37] CI/CD도 같은 개선 포인트. [^39]: @[04:43] “자동화된 배포 파이프라인… 자동으로 테스트하고 릴리즈” [^40]: @[04:53] 도구 활용로 전환. [^41]: @[05:01] “도구를 직접 개발… 매우 어렵고 비싼 일” [^42]: @[05:15] “도구의 발달… 애플리케이션 개발에만 집중” [^43]: @[05:22] “이어서… 조금 더 자세히…” [^44]: @[05:38] DORA 리포트 소개. [^45]: @[05:43] “핵심은 … 실제 측정된 수치 비교” [^46]: @[06:02] “릴리즈 기간… 더 많은 변화가…” [^47]: @[06:16]~@[06:21] “새로운 개발자… 소스 코드를 추가…” [^48]: @[06:26]~@[06:30] “더 많은 개발자… 장애 확률…” [^49]: @[06:52] CI/CD 정의 파트. [^50]: @[06:52] “전체 파이프라인을 자동화…” [^51]: @[07:01] “CI… 하나의 브랜치로 통합…” [^52]: @[07:14] CD 설명 시작. [^53]: @[07:14] “통합된 소스 코드를 빌드… 배포…” [^54]: @[07:27] “CD가 … 딜리버리… 디플로이먼트…” [^55]: @[07:35] “지속적 전달… 수동승인… 포함” [^56]: @[07:47] “지속적 배포… 모든 과정 자동화” [^57]: @[07:59] 지속적 통합 환경 설명. [^58]: @[07:59]~@[08:07] “중앙 리포지토리에 병합… 리뷰와 테스트… 피드백” [^59]: @[08:18]~@[08:22] “빌드되기도 전에 실패… 안전장치…” [^60]: @[08:37] 코드 레벨 테스트 추천. [^61]: @[08:37] “매우 빠르고 반복… 반드시… 추천” [^62]: @[08:47]~@[08:55] “의도를 주석보다 더 정확히…” [^63]: @[08:59]~@[09:06] “소나큐브 같은 정적 분석… 시큐리티 세이프티…” [^64]: @[09:12] “실패 지점이 매우 앞” [^65]: @[09:18]~@[09:22] “적시에 고쳐지기 쉽고… 품질 영향…” [^66]: @[09:35] 코드 리뷰 파트 시작. [^67]: @[09:40] “코드리뷰… 익숙… 익숙하지 않은…” [^68]: @[09:47] “문화적인 부분” [^69]: @[09:53]~@[09:59] “지적… 느끼기 쉽다… 활성화…” [^70]: @[10:03]~@[10:09] “악플… 느껴질 수도” [^71]: @[10:09]~@[10:15] “미국에서는… 토론문화” [^72]: @[10:15]~@[10:22] “미국 문화가 반드시 좋다… 의미 아님… 어떤 도구로…” [^73]: @[10:22]~@[10:31] “품질… 변화 인지…” [^74]: @[10:31]~@[10:43] 결제/인증 예시 제시 [^75]: @[10:43]~@[10:54] “코드 스타일… 변화… 미리 캐치업…” [^76]: @[11:00]~@[11:07] “오너십… 도움이” [^77]: @[11:16] “이모지를 통해서 리뷰… 추천” [^78]: @[11:25] CI 도구 소개 전환. [^79]: @[11:25] “코드 커밋… 깃 기반…” [^80]: @[11:38]~@[11:45] 브랜치 전략, GitHub/GitLab/Bitbucket 유사 설명 [^81]: @[12:04] 빌드/아티팩트 단계. [^82]: @[12:04]~@[12:12] “표준화된 빌드 아티팩트” [^83]: @[12:12]~@[12:18] .NET/Java 빌드 수행 [^84]: @[12:18] Python 등 컴파일 없음 언급 [^85]: @[12:31] “코드 빌드… 아티팩트 제작” [^86]: @[12:38] “젠킨스 역할” [^87]: @[12:38]~@[12:51] “서버리스… 볼륨 늘었다 줄었다” [^88]: @[12:54] “격리된 컨테이너” [^89]: @[13:00] VCS와 결합 장점 [^90]: @[13:15] 설정을 코드로 관리. [^91]: @[13:15]~@[13:22] “코드 형태로 관리” [^92]: @[13:22]~@[13:32] 변수/명령/테스트/리포트/저장소 설정 나열 [^93]: @[13:59]~@[14:11] “설정 변수화… 환경에서 읽어오도록” [^94]: @[14:11]~@[14:22] “리포트… 콘솔 시각화” [^95]: @[14:22] “코드 품질 검수 결과로 제출” [^96]: @[14:36]~@[14:39] “깃허브 액션… 젠킨스… 같은 역할” [^97]: @[14:50] 배포(CodeDeploy) 파트. [^98]: @[14:47]~@[14:50] “이제… 배포… 남았는데요” [^99]: @[14:55]~@[15:12] “과거… 스크립트… 코드 디플로이… 내포” [^100]: @[15:12] “롤백… 같이 구성이” [^101]: @[15:12]~@[15:35] “오류… 자동으로… 롤백” [^102]: @[15:35]~@[15:41] “코드 형태로 설정 저장…” [^103]: @[15:41]~@[15:47] “다양한 훅… 스크립트…” [^104]: @[16:01]~@[16:10] “한번에 하나씩… 절반씩… 한 번에 다… 블루그린…” [^105]: @[16:10]~@[16:16] “손쉽게 설정…” [^106]: @[16:23] 파이프라인으로 얻는 것 정리. [^107]: @[16:23] “어떤 것들을 얻을 수 있는지…” [^108]: @[16:31]~@[16:40] “인프라 설정도 코드… cdk 또는 IAC” [^109]: @[16:40]~@[16:55] “파이프라인에 녹여… 동기화… 자동화” [^110]: @[16:55] 시각화 효과. [^111]: @[16:55]~@[17:10] “파이프라인… 보는 것만으로도… 이해” [^112]: @[17:10]~@[17:23] “배포를… 자동화된 검증 도구로…” [^113]: @[17:23]~@[17:44] 병렬 구성/의존성 고려 [^114]: @[17:44]~@[17:51] 트리거 구성 [^115]: @[17:51]~@[18:01] “스케줄 기반…” [^116]: @[18:12] 단계별 재정리 예고. [^117]: @[18:12] “단계별로… 짚어보겠습니다” [^118]: @[18:17] 개발 단계 시작. [^119]: @[18:20]~@[18:26] “짧고 빠르게… 커밋… 파이프라인 시작” [^120]: @[18:36] 리뷰/의존성/빌드. [^121]: @[18:36]~@[18:44] “리뷰… 의존성 확인… 빌드…” [^122]: @[18:44]~@[18:53] “놓친게 없는지… 의존 패키지 버전…” [^123]: @[18:53] 자동화 테스트/정적 분석. [^124]: @[18:53]~@[19:06] “정형화된 결과물…” [^125]: @[19:06] 오류 발견/수정/재배포. [^126]: @[19:06]~@[19:14] “오류는 발생…” [^127]: @[19:14]~@[19:24] “배포 과정과 통합 테스트… 수정… 재배포” [^128]: @[19:24]~@[19:29] “오류를 발견하는 것이 매우 중요” [^129]: @[19:29]~@[19:42] “치명적인 오류를 운영 배포 전에 발견… 의미” [^130]: @[19:42] CodePipeline 소개. [^131]: @[19:42]~@[19:52] “코드 파이프라인… 통합한 파이프라인” [^132]: @[19:52] “서드파티 도구들과도 통합” [^133]: @[20:00] “파편화… 통합… 큰 변화의 시작” [^134]: @[20:14] 예제 소개. [^135]: @[20:24]~@[20:30] “시각화된 파이프라인” [^136]: @[20:30]~@[20:41] “깃허브… s3 업로드” [^137]: @[20:41]~@[20:56] “젠킨스… 빌드 수행” [^138]: @[20:56]~@[21:08] “코드 디플로이… 배포” [^139]: @[21:08]~@[21:19] “코드 시리즈만으로도… 단순” [^140]: @[21:19] 이벤트 기반 설명. [^141]: @[21:19]~@[21:35] “이벤트 기반… 트리거… 이벤트” [^142]: @[21:35]~@[21:53] “다양한 개발자 도구… 코드 파이프라인…” [^143]: @[21:53] 결론 파트. [^144]: @[21:53] “자동화 작업은… 필수” [^145]: @[21:59]~@[22:11] “사람이 개입… 취약성… 타협… 더 큰 부채” [^146]: @[22:11] “자동화된 릴리즈… 지식 활용… 프로세스… 발전” [^147]: @[02:58]~@[22:11] 전 구간에서 반복되는 주장들을 종합. [^148]: @[06:52]~@[21:35] 용어들이 집중적으로 정의/언급되는 구간. [^149]: 사용자가 제공한 메타데이터(제목/채널/길이/링크).