🟣 손으로 배포하던 시절의 문제
앞 세 장으로 서비스를 컨테이너로 묶고 쿠버네티스로 관리하는 데까지 왔다. 그런데 새 코드를 반영하는 과정이 수동이면, 이 모든 인프라의 탄력이 사람 손에서 병목이 된다. 코드를 고치고, 테스트를 돌리고, 이미지를 빌드하고, 레지스트리에 올리고, 쿠버네티스에 배포하는 일을 매번 손으로 하면 느리고, 무엇보다 실수가 난다.
배포가 무섭고 번거로우면 사람은 배포를 미룬다. 한 번에 많은 변경을 몰아서 배포하게 되고, 그러면 문제가 생겼을 때 원인을 좁히기 어려워진다. 클라우드 네이티브가 목표한 "자주, 안정적으로 배포"의 반대로 가는 것이다. CI/CD는 이 과정 전체를 자동화해서, 배포를 두려운 이벤트에서 매일 일어나는 평범한 일로 바꾼다.
🟣 CI와 CD는 다른 것을 자동화한다
두 글자가 붙어 다니지만 자동화하는 대상이 다르다.
CI(지속적 통합)는 코드가 합쳐지는 지점을 자동화한다. 개발자가 코드를 올리면 자동으로 빌드하고 테스트를 돌린다. 목적은 문제를 최대한 일찍 잡는 것이다. 여러 사람이 각자 작업한 코드가 합쳐질 때 깨지는 것을, 합친 직후 자동 테스트로 바로 발견한다. 앞 책들에서 정리한 단위 테스트가 여기서 자동 실행되며 값을 한다.
CD(지속적 배포)는 테스트를 통과한 코드가 실제 서비스가 되는 지점을 자동화한다. 이미지를 빌드해 레지스트리에 올리고, 쿠버네티스에 새 버전을 롤아웃한다. 앞 장에서 본 디플로이먼트의 무중단 롤아웃이 이 단계에서 자동으로 일어난다.
코드 푸시 한 번이 테스트, 이미지 생성, 배포까지 자동으로 이어진다. 앞의 파랑에서 뒤의 초록까지 사람 손이 닿지 않는 것이 핵심이다. 중간 어디서 테스트가 실패하면 파이프라인이 멈추고, 문제 있는 코드는 배포까지 가지 못한다.
🟣 파이프라인을 코드로 적는다
CI/CD 도구(Jenkins, GitHub Actions 등)의 공통점은 이 과정을 설정 파일로 선언한다는 것이다. 어떤 단계를 어떤 순서로 실행할지를 코드로 적어 저장소에 함께 둔다.
# 예: 빌드 → 테스트 → 이미지 → 배포
stages:
- run: npm ci && npm run build
- run: npm test
- run: docker build -t myapp:$SHA . && docker push myapp:$SHA
- run: kubectl set image deployment/myapp myapp=myapp:$SHA이렇게 파이프라인이 코드로 남으면 두 가지가 좋아진다. 첫째, 배포 과정이 문서가 아니라 실행되는 코드라 항상 최신이고 누구나 같은 절차로 배포한다. 둘째, 파이프라인 자체를 버전 관리하고 리뷰할 수 있다. 인프라를 코드로 다룬다는 점에서, 앞 장의 쿠버네티스 선언형 설정과 같은 사고방식이다. 이 선언형 흐름이 클라우드 네이티브 전체를 관통한다.
여기서도 판단이 필요하다. 테스트를 통과하면 운영까지 자동으로 나갈지, 아니면 마지막 배포만 사람이 승인할지다. 서비스의 위험도에 따라 다르다. 되돌리기 쉬운 서비스는 완전 자동으로, 결제처럼 위험한 서비스는 자동 테스트까지만 하고 최종 배포는 사람이 버튼을 누르게 한다. 자동화의 수준을 정하는 것도 설계다.
🟣 되돌릴 수 있어야 자주 나갈 수 있다
CI/CD가 배포를 자주 하게 만드는 진짜 조건은 속도가 아니라 되돌리기다. 배포가 잘못됐을 때 즉시 이전 버전으로 돌아갈 수 있어야, 안심하고 자주 내보낼 수 있다.
컨테이너 이미지가 이걸 쉽게 만든다. 각 배포가 태그 붙은 이미지로 남아 있으니, 문제가 생기면 이전 태그로 쿠버네티스 디플로이먼트를 되돌리면 된다. 이미지는 변하지 않는 스냅샷이라 "이전 상태로 정확히 복귀"가 보장된다. 손으로 배포하던 시절에는 이전 상태가 정확히 무엇이었는지조차 모호했다. 되돌리기가 확실해지면서 배포의 두려움이 사라지고, 그래서 더 자주 배포하게 되는 선순환이 생긴다.
🟣 정리
- 배포가 수동이면 인프라의 탄력이 사람 손에서 병목이 된다. 배포가 두려우면 미루게 되고, 몰아서 배포하면 원인 추적이 어려워진다.
- CI는 코드가 합쳐지는 지점(빌드·테스트)을, CD는 서비스가 되는 지점(이미지·롤아웃)을 자동화한다. 자동화 대상이 다르다.
- 파이프라인을 코드로 선언하면 배포 절차가 항상 최신이고 리뷰 가능하다. 쿠버네티스와 같은 선언형 사고다.
- 자동화 수준은 서비스 위험도로 정한다. 되돌리기 쉬우면 완전 자동, 위험하면 최종 배포만 수동 승인.
- 자주 배포하게 만드는 진짜 조건은 되돌리기다. 태그 붙은 이미지가 정확한 복귀를 보장해 배포의 두려움을 없앤다.
클라우드 네이티브의 네 기둥을 개념에서 시작해 컨테이너의 커널 원리, 오케스트레이션, 그리고 배포 자동화까지 사슬로 밟았다. iOS 개발자로서 내가 만든 앱이 통신하는 서버가 어떻게 배포되고 규모를 키우는지, 그 빈칸을 채우려고 시작한 공부였다. 특히 컨테이너 격리가 학부에서 배운 리눅스 네임스페이스와 cgroup의 조합이라는 것을 확인한 지점에서, 흩어져 있던 CS 기본기와 실무 인프라가 하나로 이어졌다.