CI/CD 파이프라인

CI/CD 입문 (빌드, 테스트, 배포)

클라우드 네이티브 시리즈의 마지막 글은 CI/CD다. CI/CD란 Continuous Integration(지속적 통합)과 Continuous Delivery·Deployment(지속적 전달·배포)의 줄임말로, 개발자가 코드를 푸시한 순간부터 운영 환경에 반영되기까지의 전 과정을 자동화하는 흐름을 가리킨다. 모놀리식 시절에는 매주 한 번 사람의 손으로 빌드·테스트·배포를 굴렸다면, MSA 시대에는 같은 작업을 하루에도 수십 번씩 자동으로 굴려야 한다. 이 자동화의 표준 도구가 GitHub Actions·GitLab CI·Jenkins·CircleCI 같은 플랫폼이며, 본 글은 GitHub Actions를 기준으로 첫 파이프라인을 굴려 보는 흐름과 배포 전략을 정리한다(출처: GitHub Actions 공식 문서). 제가 학교 프로젝트에서 처음 CI/CD를 도입했을 때 가장 인상 깊었던 게 매번 손으로 5분씩 걸리던 배포가 0클릭으로 줄어드는 순간이 아니라, 그동안 깜빡 잊고 빠뜨리던 테스트가 자동으로 항상 돌게 되었다는 사실이었다.

 

CI/CD가 자동화하는 빌드·테스트·배포 흐름

CI/CD 파이프라인은 크게 세 단계로 구성된다. 첫째 빌드(Build)는 소스 코드를 실행 가능한 산출물로 변환하는 단계다. 자바라면 .jar 파일, 컨테이너 환경이라면 도커 이미지가 빌드의 결과물이다. 둘째 테스트(Test)는 빌드된 산출물의 동작을 자동으로 검증하는 단계로, 단위 테스트·통합 테스트·정적 분석·보안 스캔이 차례로 실행된다. 셋째 배포(Deploy)는 검증을 통과한 산출물을 실제 환경(스테이징·프로덕션)에 전달하는 단계다. 이 세 단계가 한 번의 코드 푸시로 자동 트리거되고, 한 단계라도 실패하면 그 즉시 멈추는 흐름이 CI/CD의 본질이다.

CI와 CD의 경계는 종종 헷갈린다. CI는 여러 개발자가 작성한 코드를 하루에도 여러 번 통합하면서 빌드·테스트가 항상 통과하는 상태로 유지하는 활동을 가리키고, CD는 그렇게 검증된 산출물을 언제든지 배포 가능한 상태(Continuous Delivery) 또는 실제 자동 배포(Continuous Deployment)까지 확장하는 활동을 의미한다. 여기서 트렁크 기반 개발(Trunk-Based Development)이란 모든 개발자가 main 브랜치에 자주 머지하면서 짧은 수명의 브랜치만 사용하는 협업 방식을 가리키며, CI의 효과를 가장 잘 보여 주는 운영 패턴이기도 하다.

CI/CD가 정착한 조직의 가장 큰 변화는 사고 회복 시간의 단축이다. 작은 단위로 자주 배포하면 한 번의 사고가 미치는 범위가 작고, 어디서 잘못됐는지를 빠르게 좁혀 들어갈 수 있다. 반면 한 달에 한 번 배포하던 시절에는 한 번 사고가 나면 한 달치 변경 중 무엇이 원인인지 추적하느라 며칠을 쓰는 일이 흔했다. 솔직히 제 경험상 학교 프로젝트에서도 CI/CD를 도입한 주차부터 "발표 직전 몰아 넣다가 깨지는 사고"가 거의 사라졌고, 이 한 가지 변화만으로도 도입 비용은 충분히 회수된다고 말할 수 있다.

GitHub Actions로 만드는 첫 파이프라인

GitHub Actions는 GitHub 저장소 안에 .github/workflows/ 디렉터리를 만들고 그 안에 YAML 파일을 두는 것만으로 파이프라인이 동작하는 가장 가벼운 CI/CD 플랫폼이다. 다음은 파이썬 프로젝트의 가장 단순한 워크플로 예시다.

# .github/workflows/ci.yml
name: CI
on:
  push:
    branches: [main]
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install -r requirements.txt
      - run: pytest -q
      - run: ruff check .

이 한 장의 YAML로 main 브랜치에 푸시되거나 PR이 열릴 때마다 GitHub의 Ubuntu 컨테이너 위에서 의존성 설치·테스트·정적 분석이 자동 실행된다. 여기서 러너(runner)란 워크플로의 단계들을 실제로 수행해 주는 가상 머신 또는 컨테이너 환경을 가리키며, GitHub이 제공하는 호스티드 러너와 본인 인프라 위에 띄우는 자체 호스트 러너 두 종류가 있다. 작은 프로젝트라면 호스티드 러너만으로 충분하고, 보안 요건이 강한 사내 시스템이라면 자체 호스트 러너를 권장한다.

CD 단계까지 자동화하려면 같은 워크플로 또는 별도 워크플로에 배포 잡을 추가하면 된다. 다음은 컨테이너 이미지를 빌드해 레지스트리에 푸시하고 Kubernetes 클러스터에 적용하는 단순한 흐름이다.

deploy:
  needs: build-and-test
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: docker/login-action@v3
      with:
        username: ${{ secrets.REGISTRY_USER }}
        password: ${{ secrets.REGISTRY_TOKEN }}
    - run: docker build -t myorg/app:${{ github.sha }} .
    - run: docker push myorg/app:${{ github.sha }}
    - run: kubectl set image deployment/app app=myorg/app:${{ github.sha }}

needs 키로 build-and-test 잡이 통과한 경우에만 deploy 잡이 실행되도록 의존성을 걸었다. secrets는 저장소 설정에서 등록한 비밀 값을 안전하게 주입하는 표준 방법이며, 토큰 같은 민감 정보를 절대 코드 안에 평문으로 두면 안 된다는 원칙을 자연스럽게 강제한다. 제가 직접 처음 이 흐름을 굴렸을 때 가장 신기했던 건 git push 한 번으로 4분 뒤 운영 환경에 새 버전이 떠 있는 모습이었고, 그 후로는 수동 배포 명령을 적어 두는 일이 거의 사라졌다.

블루-그린·카나리·롤링 배포 전략

CD 단계에서 어떤 방식으로 새 버전을 운영 환경에 반영할지 결정하는 흐름이 배포 전략(Deployment Strategy)이다. 시험과 실무 모두에서 자주 등장하는 세 가지가 블루-그린, 카나리, 롤링이며, 각 전략의 트레이드오프를 정확히 이해하고 도구로 자동화해 두면 운영의 안전망이 한 단계 두꺼워진다(출처: AWS — Deployment Strategies).

블루-그린 배포는 운영 환경을 두 벌(블루·그린) 준비하고, 한 쪽에 새 버전을 띄운 뒤 트래픽을 통째로 전환하는 방식이다. 전환은 라우터 또는 로드밸런서 한 줄 변경으로 끝나며, 문제가 생기면 즉시 옛 버전으로 되돌릴 수 있다는 점이 강점이다. 다만 두 벌의 인프라 비용이 동시에 들고, 데이터베이스 스키마가 두 버전 사이에 호환되도록 설계되어야 한다는 제약이 있다. 카나리 배포는 새 버전을 일부 사용자(예: 5%)에게만 먼저 노출해 모니터링한 뒤, 문제가 없으면 점진적으로 100%까지 확대하는 방식이다. 여기서 카나리란 광산에서 위험 가스를 미리 감지하던 새 이름에서 유래한 표현으로, 새 버전의 안전성을 적은 위험으로 측정하는 의도를 담고 있다.

롤링 배포는 같은 워크로드의 인스턴스를 한꺼번에 교체하지 않고 일부씩 교체하면서 점진적으로 새 버전으로 갈아 끼우는 방식이다. Kubernetes Deployment의 기본 전략이 정확히 롤링이며, 추가 인프라 비용 없이 무중단 배포가 가능하다는 점이 큰 장점이다. 다만 짧은 시간 동안 두 버전이 동시에 떠 있게 되므로, API와 데이터베이스가 양쪽 버전 모두에서 호환되도록 설계해야 한다. 솔직히 이건 예상 밖이었는데, 제가 처음 카나리를 적용했을 때 가장 큰 효과는 "한 번에 큰 변경을 두려워하지 않게 됐다"는 심리적 효과였다. 5%부터 천천히 확대하는 흐름이 자리 잡으니 큰 변경도 작은 변경처럼 다룰 수 있게 되었고, 이건 단순한 기술 도구가 아니라 팀의 변경 문화 자체를 바꾸는 효과라는 점을 손끝으로 받아들였다. CI/CD는 결국 자동화 도구가 절반, 작은 단위로 자주 변경하는 문화가 나머지 절반이라는 사실을 도입 초기에 분명히 해 두는 일이 가장 단단한 출발점이 된다.

---

메타 디스크립션: CI/CD 파이프라인이 자동화하는 빌드·테스트·배포 3단계, GitHub Actions로 만드는 첫 파이프라인 예시, 그리고 블루-그린·카나리·롤링 배포 전략의 트레이드오프를 정리합니다.