CI/CD(지속적 통합/지속적 배포)

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

CI/CD(지속적 통합/지속적 배포)

각자 작업한 기능이 충돌을 일으키거나, 테스트를 안 거치고 배포했다가 에러가 터지면
“누가 dev 서버에 배포했어? 난 되는 거 같은데?” 하는 상황이 생길 수밖에 없다.
이런 잡다한 문제들을 자동화된 파이프라인으로 최대한 줄여주고,
“코드 작성 후→테스트→배포” 흐름을 지속적으로(Continuous) 이어주려는 개념이 바로 CI/CD 이다.

• CI(Continuous Integration): 여러 개발자가 코드를 자주(지속적으로) 통합(빌드·테스트)하는 것
• CD(Continuous Delivery & Deployment): 빌드가 끝난 애플리케이션을 원하는 환경(스테이징, 프로덕션 등)에 배포하는 것

CI/CD가 있으면, “테스트를 통과하지 않은 코드는 합쳐지지 않는다” 같은 룰을 파이프라인에서 자동으로 적용할 수 있다.
이 때문에 일일이 “이거 테스트 했어요?”라고 물어보지 않아도, 자동화 툴이 코드에 문제를 발견하면 머지를 막아주거나 알림을 준다.

CI/CD 파이프라인이란?

코드를 작성한 후 실제로 서버에 배포하기까지 거치는 과정을 한 줄로 이어놓은 걸 흔히 파이프라인이라고 부른다.

1. 빌드(Compile/Build)
2. 테스트
3. 머지(Merge)
4. 배포(Deployment)

이 과정을 통합 테스트나 코드 스캔(정적 분석) 같은 작업과 함께 자동화하여 진행하면, “개발자가 코드를 푸시하자마자, 빌드·테스트·배포가 쭉 이어지는 상태”를 만들 수 있다.

즉, 한 번 푸시로 모든 게 끝나게 된다.

1) 빌드

가장 대표적으로는 웹팩(webpack)처럼 자바스크립트 등을 번들링해주는 툴이 있다.
프론트엔드 프로젝트는 Vue, React 같은 프레임워크를 쓴다면 “npm run build” 과정을 거칠 거고,
백엔드 역시 Gradle, Maven, npm 등 다양한 빌드 툴을 사용해 컴파일 or 패키징을 진행한다.

이 빌드 과정에서 환경변수를 주입하거나, 환경별 설정파일을 분리해서 관리하는 방법도 흔히 사용된다.

2) 테스트

이 파트에서는 단위테스트, 통합테스트, 엔드 투 엔드(E2E) 테스트 등이 포함된다.

• 단위테스트(Unit Test): 함수나 클래스 같은 작은 단위가 제대로 동작하는지 검증
• 통합테스트(Integration Test): 여러 모듈이 합쳐졌을 때 제대로 동작하는지 확인
• E2E 테스트: 실제 사용자가 서비스에 들어온 것처럼 시나리오를 돌려보는 방식

이밖에 보안 취약점 스캔 같은 코드 검사도 파이프라인 중간에 넣을 수 있다.

대표적인 테스트 프레임워크로는 JavaScript 계열에선 Mocha, Jest 등을 많이 쓰고, Java는 JUnit, Python은 pytest 등이 있다.

3) 머지(Merge)

Git을 쓴다면 Pull Request를 통해 코드 리뷰를 거쳐 머지하는 게 보통이다.
여러 개발자가 동시에 작업하다 보면 충돌(Conflict)은 필연적으로 발생하기 마련인데,
이럴 때는 “조금씩 자주” 머지를 해주면 충돌을 크게 줄일 수 있다.

한 달 동안 몰아서 코딩 후에 한꺼번에 머지하는 것보단, 이슈 단위로 나눠서 머지하는 게 훨씬 관리하기 좋고 실수를 줄여줄 수 있다.

4) 배포(Deployment)

빌드·테스트가 끝난 코드를 실제로 운영(프로덕션) 서버, 혹은 QA용 서버, 관리자 페이지 등 필요한 곳에 배포하는 단계를 의미

CI/CD 툴을 사용하면 특정 브랜치에 머지된 코드를 자동으로 특정 서버에 배포하는 식으로 설정 가능하다.

예를 들면

• main 브랜치에 머지 → 프로덕션 서버에 자동 배포
• develop 브랜치에 머지 → 스테이징 서버(QA용)로 자동 배포

이런 식으로 레퍼지토리 브랜치와 서버 환경을 1:1 연결해두면 배포 담당자가 여러 단계를 일일이 체크하지 않아도 자동화된 프로세스로 배포를 진행할 수 있다.

CI/CD 파이프라인의 장점

1. 자동화된 테스트 강제 : 테스트를 통과하지 못하면 배포 단계로 넘어갈 수 없으니, 자연스럽게 품질이 보장된다.
2. 빠른 피드백 : 코드에 문제가 있으면 바로 CI 단계에서 빌드나 테스트가 깨지면서 알려주니까, 수정 시간을 단축할 수 있다.
3. 투명한 이력 관리 : 누가 언제 어떤 코드를 빌드·배포했는지 기록이 자동으로 남아서, 문제 발생 시 빠르게 추적 가능하다.
4. 지속적인 코드 통합 : 여러 명의 개발자가 매일 소규모 단위로 통합하기 때문에, 코드 충돌이 크게 쌓이지 않음

CI/CD 툴과 서비스

• GitHub Actions : GitHub에서 제공하는 CI/CD 서비스. 설정 파일(yaml)만 잘 만들어두면 다양한 플랫폼에서 테스트와 빌드를 진행하고, 성공 시 배포까지 자동화할 수 있다.
• Jenkins : 오래된 전통(?)이 있는 오픈소스 CI/CD 서버. 플러그인이 풍부하고 확장성이 높지만, 직접 서버 구축·관리 필요
• CircleCI : 설정이 간단하고, GitHub와의 연동이 편리. 컨테이너 기반으로 빠르게 빌드·테스트를 돌릴 수 있다
• Heroku : 아주 간단한 규모의 프로젝트라면, Git에 푸시만 해도 자동 배포가 되게끔 설정할 수 있어. GitHub Actions와도 연동이 쉬움

참고하기

🪄 GitHub Actions**를 사용하여 ci-cd를 구축

cloud 카테고리 내 다른 글 보러가기