CI/CD Pipeline

1. Overview

CI/CD 파이프라인(CI/CD Pipeline)은 개발자가 코드를 푸시(Push)한 뒤 "내 컴퓨터에선 되는데 서버에선 왜 안 되지?"라며 밤을 새우던 수동 배포의 야만 시대를 끝내고, 코드 병합부터 테스트, 빌드, 배포까지의 전 과정을 핏도 눈물도 없는 기계의 컨베이어 벨트에 태워버리는 자동화 역학을 해부합니다.

학습자는 하루에 한 번 코드를 합치다 충돌 지옥(Merge Hell)에 빠지던 과거를 뜯어보고, 하루 10번씩 쪼개서 병합하는 **지속적 통합(Continuous Integration)**의 안전망을 장악합니다. 나아가 통합된 코드를 사람이 눈으로 검사하는 대신 서버가 자동화된 테스트를 돌리고 도커 이미지로 구워내는 파이프라인 구축(Pipeline Construction) 역량을 익히고, 마지막으로 사용자가 눈치채지 못하게 새 버전을 스르륵 교체하는 **무중단 배포(Blue-Green, Canary)**라는 지속적 배포(Continuous Deployment)의 궁극기를 확보합니다.

2. Scope & Boundaries

In-Scope

• CI Physics (지속적 통합): Merge Hell 방어, 린트(Lint)/유닛 테스트 자동화, 빠른 피드백 루프.
• CD Physics (지속적 배포/제공): Artifact(도커 이미지 등) 생성, Staging/Production 환경 분리, 무중단 배포.
• Deployment Strategies: Blue-Green(블루그린), Canary(카나리아), Rolling(롤링).
• Pipeline Architecture: GitHub Actions, Jenkins 등을 관통하는 뼈대(Trigger $\rightarrow$ Build $\rightarrow$ Test $\rightarrow$ Deploy).

Out-of-Scope

• 테스트 코드(TDD) 작성법: 단위 테스트를 어떻게 잘 짤 것인가 $\rightarrow$ 09-04 QA & Quality Assurance로 위임.
• GitOps와 ArgoCD: 쿠버네티스의 선언적 상태 동기화 배포 기술 $\rightarrow$ 09-05-01 IaC & GitOps로 분리.

Boundaries

• CI vs CD: CI는 "우리가 짠 코드가 쓰레기인지 아닌지 즉시 기계한테 검사받는 과정(안전망)"이고, CD는 "그 깨끗한 코드를 손 하나 까딱 안 하고 서버에 꽂아 넣는 과정(속도전)"입니다. CI가 없는데 CD만 구축하는 것은 '쓰레기 코드를 빛의 속도로 배포해서 서버를 초고속으로 터뜨리는 자살 행위'임을 명확히 긋습니다.

3. Counterexample

• 빅뱅 배포 (Big Bang Deployment): 3달 동안 개발한 기능을 한 달에 한 번 있는 '정기 배포일(새벽 2시)'에 몽땅 합쳐서 서버에 올렸습니다. DB가 뻗고 화면이 깨집니다. 누가 짠 코드 때문에 터졌는지 알 수 없어 개발팀 전원이 며칠 밤을 새우며 롤백(Rollback)합니다. 변경의 단위를 무식하게 키웠다가 폭발하는 수동 통합의 비극입니다.
• 눈먼 파이프라인: 젠킨스(Jenkins)에 배포 버튼을 만들어 자동화(CD)를 달성했다고 좋아합니다. 그런데 그 앞에 테스트 자동화(CI)가 없습니다. 개발자가 오타 낸 코드를 깃허브에 푸시하자마자, 파이프라인이 기계처럼 정확하고 빠르게 오타 난 코드를 운영 서버에 배포해 버립니다. 안전망 없는 파이프라인이 불러온 참사입니다.

4. Prerequisites

• 버전 관리와 브랜치 (Basic): Git의 커밋, 푸시, 브랜치 전략(Git Flow). (09-05 DevOps Basic)
• 컨테이너 아키텍처 (Basic): Docker 이미지 빌드 및 태깅. (09-05-02 Docker)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 병합 지옥의 탈출 (The End of Merge Hell)

• Why to Learn: "네 코드랑 내 코드 합치니까 에러 나는데?"라며 서로 멱살을 잡는 끔찍한 병합 지옥(Merge Hell)을 막고, 오류의 폭발 반경을 최소한으로 억제하기 위함입니다.
• What to Learn:
  • Concepts: Continuous Integration (CI), Merge Conflict, Mainline Branch, Shift-Left Testing.
  • Skills: 개발자가 코드를 모아서 한 번에 푸시하는 습관을 버리고, 하루에 10번 이상 작은 단위로 쪼개어 main 브랜치에 쑤셔 넣는(Integrate) 고빈도 커밋 전략 짜기.
• How to Learn:
  • 1단계: 빅뱅 병합: 과거엔 A가 2주 동안 회원가입을 짰고, B가 2주 동안 결제를 짰습니다. 금요일에 둘을 합치니 50군데에서 충돌(Conflict)이 납니다. 둘 중 하나가 코드를 다시 짜야 합니다.
  • 2단계: 지속적 통합(CI): 이 고통을 줄이려면? 역설적으로 더 자주 합치면 됩니다. A와 B가 2주가 아니라 '2시간'마다 코드를 합칩니다. 충돌이 나도 1줄밖에 안 납니다.
  • 3단계: 기계의 심판: 그 2시간마다 합치는 코드가 남의 코드를 망가뜨리지 않는지 누가 검사합니까? 서버(CI)가 합니다. 푸시할 때마다 테스트 코드가 자동으로 돌아가며 "너 코드 합치면 서버 터져!"라고 5분 만에 경고(피드백)를 날리는 Shift-Left의 예술을 해부합니다.
• Implement: CI 피드백 루프의 가속도 렌더링. 과거: 한 달에 한 번 병합 $\rightarrow$ 에러 발생 시 원인 파악에 3일 소요 (수천 줄 섞임). 현재 (CI): 푸시 후 3분 만에 슬랙 봇이 "빨간 맛(Build Failed)" 알람 전송 $\rightarrow$ 내가 5분 전에 짠 코드 딱 10줄만 살펴보면 됨 $\rightarrow$ 에러 복구에 3분 소요. 피드백 루프가 생산성을 압도하는 시각화.

Recommended

Core Topic 02: 기계들의 컨베이어 벨트 (Pipeline Architecture)

• Why to Learn: '코딩 $\rightarrow$ 린트 검사 $\rightarrow$ 빌드 $\rightarrow$ 테스트 $\rightarrow$ 도커 이미지 굽기'라는 지루하고 반복적인 막노동을 인간의 손에서 완전히 뺏어버리기 위함입니다.
• What to Learn:
  • Concepts: Trigger (방아쇠), Stage/Job/Step, Build Artifact, Linting, Unit/Integration Test.
  • Skills: GitHub Actions나 Jenkins를 이용해 소스가 푸시되면 순차적/병렬적으로 작업이 굴러가는 파이프라인(Pipeline) YML 설계하기.
• How to Learn:
  • 1단계: 트리거 (Trigger): 개발자가 PR(Pull Request)을 올리거나 main에 코드를 푸시하는 순간, 봇(Bot)이 이를 감지하고 방아쇠를 당깁니다.
  • 2단계: 검문소 (Stages):
    1. Lint: 띄어쓰기 엉망이네? (Fail 컷)
    2. Build: 자바 컴파일이 안 되네? (Fail 컷)
    3. Test: 덧셈 로직에서 에러 나네? (Fail 컷)
  • 3단계: 아티팩트 (Artifact): 핏도 눈물도 없는 기계의 3관문을 모두 무사히 통과한 깨끗한 코드만이 도커 이미지(Artifact)로 구워져 배포 대기열(Registry)에 올라가는 자격을 얻습니다. 사람의 감정(대충 넘어가자)이 배제된 완벽한 통제술을 뜯어봅니다.
• Implement: GitHub Actions .yml 뼈대 렌더링. Event: on: push branches: [main]. Jobs: Lint: npm run lint Test: npm test (Lint 통과 후) Build: docker build -t myapp (Test 통과 후). 단 하나의 Job이라도 실패하면 즉각 컨베이어 벨트가 멈추고 책임자(Committer)에게 빨간불이 날아가는 파이프라인 시각화.

Practical

Core Topic 03: 배달과 배포의 미묘한 선 (The Delivery Matrix, CD)

• Why to Learn: 1종 보통 면허만 땄다고 바로 고속도로에 나갈 수 없듯이, 파이프라인의 끝에서 "버튼을 사람이 누를 것인가(Delivery), 기계가 꽂아 넣게 둘 것인가(Deployment)"의 거버넌스를 설계하기 위함입니다.
• What to Learn:
  • Concepts: Continuous Delivery (지속적 제공), Continuous Deployment (지속적 배포), Staging Environment.
  • Skills: "실제 운영 서버(Production)로 나가는 건 무조건 팀장님의 승인(Manual Approve) 버튼이 필요하다"는 Delivery 아키텍처와, "테스트를 통과하면 그 즉시 1초 만에 릴리즈한다"는 Deployment 아키텍처 분기하기.
• How to Learn:
  • 1단계: 어디로 보낼 것인가: 빌드된 아티팩트(도커 이미지)를 일단 'Staging(운영과 똑같은 가짜 서버)'에 무조건 자동 배포합니다. 기획자와 QA가 들어가서 만져보고 테스트합니다.
  • 2단계: 지속적 제공(Delivery): 테스트가 완벽해도 멈춥니다. 비즈니스적 판단(예: "내일 아침 9시 기자 간담회 직전에 오픈하자")에 따라 인간이 버튼(Deploy)을 누를 때까지 기다리는 보수적인 전략입니다.
  • 3단계: 지속적 배포(Deployment): 넷플릭스나 아마존의 방식. 인간을 못 믿습니다. 테스트 코드 커버리지가 90%를 넘고 CI를 통과했다면, 사람의 개입 없이 그 즉시 실서버에 코드가 꽂힙니다. 하루에 수천 번 배포되는 궁극의 자동화 역학을 해부합니다.
• Implement: CD 거버넌스 분기 매트릭스 도출. 금융/은행 도메인: CI $\rightarrow$ Staging 자동배포 $\rightarrow$ 3일간 통합 QA $\rightarrow$ 임원진 승인(Manual) $\rightarrow$ 금요일 자정 Production 수동 배포 (Continuous Delivery). B2C 스타트업: CI $\rightarrow$ 통과 즉시 Production으로 파이프라인 직행 (Continuous Deployment). 비즈니스 리스크에 따라 파이프라인의 끝부분을 재단하는 아키텍처 렌더링.

Advanced

Core Topic 04: 무중단 배포의 예술 (Zero-Downtime Deployment)

• Why to Learn: 서버 배포한다고 "새벽 2시부터 4시까지 점검합니다"라는 공지사항을 띄우는 아마추어 티를 벗고, 백엔드 서버가 갈아 끼워지는 그 순간에도 고객의 클릭 1번이 유실되지 않게 방어하기 위함입니다.
• What to Learn:
  • Concepts: Downtime, Rolling Update (롤링), Blue-Green (블루그린), Canary (카나리아).
  • Skills: V1 서버 100대를 V2 서버 100대로 교체할 때, 비용(서버 2배 필요)과 안정성(1% 유저에게만 먼저 노출)의 트레이드오프를 따져 최적의 배포 전략 선택하기.
• How to Learn:
  • 1단계: 롤링 (Rolling): 서버 100대가 있습니다. 5대 죽이고 새 버전(V2) 5대 띄우고, 또 5대 죽이고 5대 띄우는 걸 20번 반복합니다. 돈(추가 서버)은 안 들지만, 배포 도중에 V1 유저와 V2 유저가 섞여서 구/신버전 DB 꼬임 현상이 터질 수 있습니다.
  • 2단계: 블루-그린 (Blue-Green): 깔끔합니다. 똑같은 서버 100대(Green)를 옆에 새로 다 띄워놓고 완벽히 준비(웜업)를 끝냅니다. 그리고 트래픽(로드밸런서 라우터) 스위치를 딸깍! 1초 만에 V1에서 V2로 방향을 틀어버립니다. 서버 비용이 2배로 들지만, 문제 발생 시 스위치만 다시 V1(Blue)으로 내리면 되는 궁극의 롤백 속도를 자랑합니다.
  • 3단계: 카나리아 (Canary): 구글이 씁니다. V2 서버를 단 1대만 띄웁니다. 전체 트래픽 중 '딱 1%의 유저'만 V2로 몰래 보냅니다. 3시간 관찰해 보니 결제 에러율이 안 오릅니다. 그러면 점진적으로 10%, 50%, 100%로 트래픽을 넘깁니다. 유저를 마루타(실험쥐)로 삼아 안전을 담보하는 잔혹하고도 완벽한 전략을 뜯어봅니다.
• Implement: 배포 전략별 트레이드오프 렌더링. 가난한 스타트업: 돈이 없음 $\rightarrow$ 순차적으로 갈아 끼우는 Rolling Update 적용. 초거대 이커머스: 트래픽 무중단과 즉각 롤백이 생명 $\rightarrow$ 인프라 2배 띄우는 Blue-Green 적용. 추천 알고리즘 변경: 신버전이 진짜 매출이 오를지 모르겠음 $\rightarrow$ A/B 테스트 성격이 강한 Canary 적용 (5% 유저만 신버전).

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Evolution (CI/CD)
• [P5] SFIA - Release and Deployment (RELM)

Secondary

• [Continuous Delivery] Jez Humble, David Farley - CI/CD Pipeline, Deployment pipelines
• [Accelerate] Nicole Forsgren - State of DevOps, DORA metrics (Deployment frequency)

Industry

• [MartinFowler.com] - Continuous Integration, BlueGreenDeployment, CanaryRelease
• [GitHub Actions Documentation] - CI/CD Concepts

9. Final Checklist

Primary

• 수 주일 동안 각자의 브랜치에서 개발한 코드를 한 번에 병합하려 할 때 발생하는 병합 지옥(Merge Hell)의 물리적 참상을 설명하고, CI(지속적 통합)가 이를 어떻게 방어하는지 논증할 수 있는가?
• 누군가 코드를 푸시(Push)했을 때 발동되는 파이프라인에서 Linting(문법 검사) $\rightarrow$ Build(컴파일) $\rightarrow$ Test(테스트) 과정을 순차적/병렬적으로 배치하여 부서진 코드가 실서버로 나가는 것을 막는 검문소를 설계할 수 있는가?

Secondary

• 'Continuous Delivery(지속적 제공)'와 'Continuous Deployment(지속적 배포)'의 차이를 설명하고, 은행 앱과 스타트업 웹사이트 중 각각 어느 거버넌스를 채택하는 것이 비즈니스 리스크 측면에서 타당한지 분기할 수 있는가?
• 무중단 배포를 달성하기 위해, 기존 서버를 한 대씩 죽이고 살리는 롤링(Rolling) 배포 전략이 가진 구/신버전 혼재의 문제점과 이를 비용을 태워 해결한 블루-그린(Blue-Green) 배포의 트레이드오프를 렌더링할 수 있는가?

Industry

• 카나리아(Canary) 배포 전략을 통해 신버전(V2) 서버에 전체 트래픽의 단 1%만 흘려보낸 뒤, 에러율(500 Http Status)이나 지연 시간 메트릭을 관찰하며 안전하게 100%까지 라우팅 가중치를 조절하는 릴리즈 파이프라인을 구축할 수 있는가?
• 단순히 도커 이미지를 구워 배포하는 파이프라인을 넘어, 인프라 자체가 코드로 관리되는 환경에서 "파이프라인이 코드를 밀어 넣는 방식(Push)"과 "클러스터가 깃을 감시하다 알아서 당겨오는 방식(Pull/GitOps)"의 아키텍처적 권력 역전을 논증할 수 있는가?