[Github Actions] CI/CD 기본 개념

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.

---

CI / CD 개념

CI/CD는 Continuous Integration(지속적 통합)과 Continuous Deployment(지속적 배포)를 뜻한다.

이 개념은 개발자가 더 효율적으로 코드를 작성하고, 빠르고 안정적으로 사용자에게 소프트웨어를 제공하는 것을 목표로 한다.

한마디로 CI/CD는 테스트(Test), 통합(Merge), 배포(Deploy)의 과정을 자동화하는 걸 의미한다.

 

서비스를 운영하다보면 새로운 기능을 추가하는 일이 많아진다.

새로운 기능에 대한 코드를 작성한 뒤에 Commit을 하고, 브랜치에 Merge를 하고 배포를 한다.

배포를 할 때 직접 컴퓨터 서버(ex. AWS EC2)에 접속해서 새로운 코드를 다운받아 실행시켜주어야 한다. 

이 과정을 코드의 수정이 일어날 때마다 반복하기란 너무 귀찮은 일이다. 그래서 이런 반복적인 과정을 자동화시키기 위해 CI/CD를 도입한다.

 

CI(Continuous Integration)

• 코드를 올리면 자동으로 빌드하고, 테스트해서 문제가 있는지 바로 확인해주는 단계

 

CD(Continuous Deployment)

• 테스트 통과하면 운영 서버까지 완전 자동 배포

 

 

GitHub Actions는 자동화된 워크플로우를 지원하는 도구로, 저장소의 빌드, 테스트, 배포 등의 작업을 자동화할 수 있다.

CI/CD 과정은 일반적으로 다음과 같은 과정으로 일어난다.

https://www.performetriks.com/post/load-test-in-a-cicd-environment

 

즉, GitHub Actions는 CI/CD 과정에서 빌드, 테스트, 배포에 대한 로직을 실행시키는 서버(컴퓨터)의 역할을 한다.

1. 코드 작성 후 Github에 Commit & Push
2. Push를 감지해서 Github Actions에 작성한 로직이 실행
   빌드(Build) -> 테스트(Test)-> 서버로 배포(Deploy)
3. 서버에서 배포된 최신 코드로 서버를 재실행

 

개발자가 코드를 작성 후 커밋 & 푸시를 하는 순간 GitHub Actions는 빌드 및 테스트를 하고 EC2에 배포까지 자동화 할 수 있다.

물론 테스트 코드에서 오류가 난다면 배포가 중단된다.(서비스가 중단되는 것은 아니다.)

 

CI / CD 테스트와 배포 전략

CI / CD 테스트

CI 테스트

• CI 테스트는 개발자가 코드를 올렸을 때, 코드가 제대로 작동하는지 빠르게 확인하는 자동 테스트를 뜻한다.
• 즉, 테스트 코드가 문제없을때 CI 테스트는 통과하게 된다.
• CI 테스트가 실행되는 시점은 Git Push, PR 등 코드 변경 직후이다.

 

CD 테스트

• CD 테스트는 배포된 애플리케이션이 실제로 잘 작동하는지 확인하는 자동 테스트를 뜻한다.
• 개발할 때는 잘 작동되었으나 실제 프로덕션 환경에서 문제가 없는지 확인하는 과정이다.
• 보통 헬스체크(/actuator/health, /ping 같은 URL)를 통해서 점검한다.
• 시점은 배포 직전, 배포 중, 배포 직후가 될 수 있다.

 

 

배포 전략

롤링 배포

기존 인스턴스를 하나씩 새로운 버전으로 교체하면서 순차적으로 배포하는 방식

ex) 서버 10대 중에서 1번 서버부터 새 버전으로 교체 → 정상 확인 후 2번 서버 교체 → 반복

 

작동 방식

• 전체 서버 중 일부만 먼저 새로운 버전으로 교체
• 교체 완료된 서버부터 트래픽을 받게 함
• 나머지 서버들도 순차적으로 교체

 

장점

 

• 서비스 중단 없음
• 서버 자원이 추가로 필요하지 않음

 

 

단점

• 장애 발생 시 복구가 어려움 (이미 일부 서버가 새 버전으로 바뀌었기 때문에)
• 새 버전과 구 버전이 동시에 떠 있으므로 하위 호환성에 민감

 

블루-그린 배포

운영 중인 “Blue” 환경과 새 버전을 가진 “Green” 환경, 두 개의 환경을 만들어 배포 후 트래픽을 스위칭하는 방식

ex) 현재는 Blue 서버에만 트래픽이 흐르고 있음 → Green에 배포 후 검증 → Green으로 스위칭

 

작동 방식

• 기존 서비스는 Blue 환경
• Green 환경에 새 버전 배포 후 테스트
• 문제가 없으면 트래픽을 Blue → Green으로 전환
• 문제가 생기면 다시 Blue로 전환 (Rollback이 매우 빠름)

 

장점

• 빠른 롤백 가능
• 사용자에게는 무중단 배포로 인식됨

 

단점

• 환경을 두 개 유지해야 하므로 인프라 비용이 증가
• DB 스키마 변경 등은 신중하게 설계 필요 (두 버전 간 충돌 가능성)

 

카나리 배포

일부 사용자에게만 새 버전을 먼저 배포하고, 이상이 없을 경우 점진적으로 전체로 확대하는 방식

ex) 유저 1000명 중 10명에게만 새 버전 배포 → 에러율 모니터링 → 점진적 확대

 

작동 방식

• 사용자 1%에게만 새 버전 노출
• 문제 없으면 10% → 30% → 100% 점진적 확대

 

장점

• 새 버전의 이상 여부를 소규모 사용자로 먼저 확인 가능
• 실시간으로 모니터링하면서 문제 감지 가능

 

단점

• 트래픽 라우팅을 정교하게 제어할 수 있는 인프라가 필요 (예: 서비스 메시, Istio, Nginx 등)
• 사용자마다 경험이 달라질 수 있음