이 사이트의 실습은 자바스크립트를 켜야 움직입니다. 아래는 같은 내용을 글로 적은 것입니다.
공부 › 아키텍처와 운영 › 배포와 운영
CI/CD 파이프라인
코드를 올리면 기계가 대신 확인하고 배포한다
코드를 고쳐서 운영 서버에 반영하기까지는 빌드, 테스트, 포장, 배포라는 단계가 있습니다. 이 단계를 사람이 손으로 하면 빠뜨리거나 사람마다 다르게 합니다.
개념 모형 · 개념 모형(실제 도구로 확인하지 않음)
이 실습에 나오는 개념
- CI/CD
- CI(지속적 통합)는 코드 변경을 자주 합치고, 합칠 때마다 자동으로 빌드와 테스트를 실행해 문제를 일찍 발견하는 것이다. CD(지속적 전달·배포)는 검증된 코드를 자동화된 절차로 배포 가능한 상태로 만들거나 운영 환경까지 배포하는 것이다. 사람이 수동으로 하던 빌드·테스트·배포를 자동화해 실수를 줄이고 배포 주기를 짧게 한다.
- 단위 테스트와 통합 테스트
- 단위 테스트는 메서드나 클래스 하나의 동작을 다른 부분과 분리해 검증하는 테스트로, 빠르게 실행되고 실패 원인을 찾기 쉽다. 통합 테스트는 여러 구성 요소(스프링 컨테이너, 데이터베이스 등)를 실제로 연결해 함께 동작하는지 검증하는 테스트로, 실제에 가깝지만 느리다. 단위 테스트를 많이, 통합 테스트를 핵심 흐름 위주로 두는 것이 일반적이다.
- 코드 리뷰와 Pull Request
- Pull Request(PR)는 작업한 브랜치의 변경을 기준 브랜치에 합쳐 달라고 요청하는 것이다. 코드 리뷰는 합치기 전에 다른 개발자가 변경 내용을 검토하는 과정으로, 결함을 일찍 발견하고 코드의 일관성을 유지하며 팀 안에서 지식을 공유하는 효과가 있다.
- 헬스 체크(Liveness, Readiness)
- 서버가 정상인지 주기적으로 확인하는 것이다. Liveness는 프로세스가 살아 있는지를 확인해 문제가 있으면 재시작하게 한다. Readiness는 요청을 받을 준비가 되었는지를 확인해 준비되지 않은 서버로는 트래픽을 보내지 않게 한다. 서버가 시작 중이거나 종료 중일 때 요청이 들어가는 것을 막는다.
- 롤링, 블루-그린, 카나리 배포
- 서비스 중단 없이 새 버전을 배포하는 방식들이다. 롤링은 서버를 일부씩 차례로 새 버전으로 교체한다. 블루-그린은 새 버전 환경을 통째로 따로 준비한 뒤 트래픽을 한 번에 전환한다. 카나리는 일부 사용자에게만 새 버전을 먼저 적용해 문제가 없는지 확인한 뒤 점차 확대한다.
이렇게 바꿔 보세요
- 처음 설정으로 — 손으로 배포. 테스트를 건너뛰어 운영에서 장애가 납니다.
- CI를 두면 — 같은 변경이 테스트 단계에서 막힙니다.
- 내 PC에서만 되는 코드 — 깨끗한 환경에서 돌려야 드러납니다.
- 테스트가 못 잡는 문제, CI만 — 사람이 배포하고 사람이 되돌립니다.
- 테스트가 못 잡는 문제, CI/CD — 배포 뒤 헬스 체크에서 걸려 자동으로 되돌립니다.
- 문제가 없을 때 — 사람이 할 일이 얼마나 남는지 비교해 보세요.
처음 설정으로 실행하면
- 개발자가 자기 PC에서 빌드합니다.
- 급해서 테스트를 돌리지 않았습니다. 테스트를 돌릴지 말지가 사람의 기억과 성의에 달려 있습니다.
- 빌드한 파일을 운영 서버에 복사하고 재시작합니다. 어떤 코드가 올라갔는지는 그 개발자만 압니다.
- 기존 기능이 망가진 채 운영에 올라갔습니다. 사용자 신고로 알게 됩니다. 개발자가 원인을 찾고, 이전 파일을 찾아 다시 올려야 합니다.
실행 결과
- 손으로 하면 확인 단계를 건너뛸 수 있고, 건너뛴 것을 아무도 모릅니다. 문제는 가장 비싼 곳인 운영에서 발견됩니다.
- 파이프라인이 걸러 주는 것은 테스트와 점검으로 확인할 수 있는 문제까지입니다. 테스트가 없는 기능의 버그는 CI가 있어도 통과합니다.
코드
# 개발자가 자기 PC에서 직접 입력
./gradlew build -x test # 급해서 테스트는 건너뜀
scp build/libs/app.jar prod-server:/app/
ssh prod-server "systemctl restart app"
# 누가, 언제, 어떤 코드를 올렸는지 기록이 남지 않는다
이 모형의 전제
개념을 설명하기 위한 모델이며 실제 CI/CD 도구를 실행해 확인한 결과는 아닙니다. "손으로"에서 테스트를 건너뛴 것은 흔한 사고를 가정한 것이고, 손으로 해도 테스트를 돌리면 같은 문제를 잡을 수 있습니다. 헬스 체크 실패 시의 자동 되돌리기는 파이프라인과 배포 도구에 그렇게 구성했을 때의 동작입니다. 코드의 워크플로는 구조를 보여 주기 위한 예시로, 인증과 캐시 같은 실제에 필요한 단계는 뺐습니다.
앞 실습: 게이트웨이와 점진적 전환 · 다음 실습: 배포 전략