mimizae 님의 블로그
CI/CD란 뭘까? 본문
최근 DIVE SOPT 합동 세미나에서 GitHub Actions를 이용한 CI/CD 구축을 진행했다.
파트 리드 님께서 공유해 주신 아티클을 참고하며 따라 해보는 수준으로 진행했음에도 코드가 push 되면 자동으로 빌드가 실행되고 배포까지 연동되는 과정을 직접 경험한 것이 신기하고 재밌어서 꽤 깊은 인상으로 남았다!
그래서 이 경험을 계기로 DevOps는 어떤 개념이고, CI/CD가 각각 무엇인지, 왜 중요하고 어떤 도구를 이용해 구축할 수 있는지에 대해 학습하고자 아티클을 작성한다.
🤔 잠깐!! 합동세미나란?
합동세미나는 SOPT 내 서로 다른 파트(기획·디자인·개발 등)가 한 팀을 이루어 짧은 기간 동안 하나의 문제를 정의하고 해결해보는 협업 중심의 세미나이다.
파트 간 역할 분담과 커뮤니케이션을 통해 실제 서비스 제작 과정을 경험하며, 이후 진행되는 대규모 프로젝트를 대비하는 실전형 협업 활동이다!
CI/CD란?
CI/CD는 지속적인 통합(Continuous Integration)과 지속적인 배포(Continuos Deployment) 혹은 지속적인 제공(Continuos Delivery)의 약자로, 소프트웨어 개발과 배포를 자동화하여 코드의 안정성을 높이고 개발 속도를 가속화하는 방법론이다!!
이러한 CI/CD는 DevOps 철학을 실무에서 구현하기 위한 대표적인 기술적 실천 방법 중 하나라고도 볼 수 있다.
🤔 음? DevOps? 철학?
DevOps는 개발(Development)과 운영(Operations)을 합친 말로 소프트웨어를 더 빠르고 안정적으로 만들고 배포하기 위한
문화, 방법론, 기술의 총칭이다.
기존에는, 개발 팀과 운영 팀의 역할과 책임이 분리되어 독립적으로 작업하는 경우가 많았다.
DevOps는 이런 벽을 허물어 두 팀의 협업과 빠른 피드백 루프로 더 안정적이고 빠르게 소프트웨어를 제공하는 문화를 만들고자 한다!
💭 참고 - DevOps의 주요 원칙 👇🏻
DevOps는 몇 가지 핵심 원칙을 기반으로 이루어진다.
- 지속적인 통합(Continuous Integration, CI)
: 코드 변경 사항을 지속적으로 통합하여 버그를 조기에 발견하고, 문제가 발생하면 즉각 해결한다. - 지속적인 배포(Continuous Deployment, CD)
: 통합된 코드가 자동으로 배포 준비 상태로 유지된다. 이를 통해 릴리스 주기가 짧아지고, 더 빠른 피드백을 받을 수 있다. - 자동화 및 모니터링
: 배포 과정의 모든 단계를 자동화하고, 시스템 성능과 안정성을 모니터링하여 문제를 조기에 파악하고 해결한다. - 협업과 소통 강화
: DevOps에서는 소프트웨어 개발과 IT 운영 팀이 상호 피드백을 주고 받으면서 협력한다.
그럼, CI 그리고 CD 각각이 무엇이길래 DevOps가 이루고자 하는 바를 구현할 수 있는 것일까?
🤔 지속적인 통합, CI
CI는 지속적인 통합(Continuos Intergration)을 의미한다.
CI를 성공적으로 구현하면 개발자가 작성한 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트된 후, 공유 레포지토리에 자동으로 통합된다!
그렇기 때문에, 여러 명의 개발자가 동시에 애플리케이션 개발을 진행할 경우 발생할 수 있는 코드 충돌과 통합 오류를 조기에 발견할 수 있어 CI의 과정은 매우 중요하다.
🤔 지속적인 배포 혹은 제공, CD
CI를 통해 코드가 안정적으로 통합되었다면, 이제 다음 단계는 변경 사항을 얼마나 빠르고 안정적으로 사용자에게 전달할 수 있는가이다!
이 역할을 수행하는 것이 바로 CD이다.
CD는 지속적인 서비스 제공(Continuos Delivery) 및 또는 지속적인 배포 (Continuos Deployment)를 의미하며, 자동화 수준에 따라 두 방식으로 나뉜다.
☝🏻 지속적인 제공(Continuous Delivery)이란
지속적인 제공이란 개발자가 애플리케이션에 적용한 변경 사항이 자동 테스트를 거쳐 항상 배포 가능한 상태로 레포지토리에 준비되는 것을 의미한다.
이를 통해 운영 팀은 별도의 복잡한 준비과정 없이! 필요한 시점에 애플리케이션을 프로덕션 환경으로 배포할 수 있다.
이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해 준다!
✌🏻 지속적인 배포(Continuous Deployment)란
제공에서 한 단계 더 나아가, 모든 검증을 통과한 변경 사항을 사람의 개입 없이!! 고객이 사용 가능한 프로덕션 환경으로 자동 릴리스하는 것을 의미한다.
이는 수동 배포 작업으로 인한 운영 팀의 업무 부담을 줄이고, 애플리케이션 제공 속도를 획기적으로 향상시킬 수 있다.
이 둘을 깔끔히 정리해 보자면!
- Continuos Delivery는 프로덕션에 배포할 수 있는 상태까지는 자동화 되지만 실제 배포는 사람이 결정 (운영 팀에 전달한다고 생각)
- Continuos Deployment는 모든 검증을 통과한 변경사항은 사람 개입 X, 즉시 프로덕션에 배포 됨 (완전한 자동 배포)
💭 참고 - 내가 헷갈렸던 부분... 😅
🤯 CI도 테스트하는 거고 CD도 테스트? 이 둘의 세밀한 차이점이 뭐지? 🤯
CI는 '이 변경 사항이 기존 코드들과 함께 main 브랜치에 들어가도 안전한가?'를 묻는 역할이다.
CI가 핵심적으로 테스트하는 것들은 다음과 같다.
- 개별 개발자의 코드 변경 사항
- 다른 사람 코드와 충돌 없는지
- 빌드가 깨지지 않는지
- 최소한의 테스트를 통과하는지
결과가 통과라면 공유 레포지토리에 통합되고, 실패한다면 개발자가 직접 수정해야 한다.
반면 CD는 '이 상태로 사용자에게 나가도 되나?'를 묻는 역할이다.
CI를 통과해서 통합된 코드가 생겼다고 가정해 보자. 여기에서 CD는 이 상태의 애플리케이션을 지금 당장 배포해도 괜찮은지를 테스트한다.
여기에서 포인트는 코드가 아닌 애플리케이션 전체를 관점으로 본다는 것!
CD가 핵심적으로 테스트하는 것들은 다음과 같다.
- 통합 테스트
- E2E 테스트
- 성능 / 보안 체크
- 설정, 환경 변수 검증
👉🏻 즉, 운영 환경 배포 가능 여부를 테스트
✅ CI -> 이 코드 변경 사항이 다른 코드들과 함께 저장소에 합쳐져도 괜찮은가.
✅ CD -> 이 상태의 애플리케이션을 지금 당장 운영 환경에 배포해도 괜찮은가.
💡 정리!!! DevOps와 CI/CD의 관계
DevOps는 소프트웨어 개발 생명 주기 전반에 걸쳐 효율성과 품질을 높이는 것을 목표로 하는 문화와 철학이다.
CI/CD는 이러한 DevOps의 목표를 달성하기 위한 기술적 실행 방식이다.
즉!!!! DevOps와 CI/CD는 상호 보완적인 관계로
- CI는 개발 단계에서 코드 통합과 자동 테스트를 통해 빠른 피드백과 품질을 확보함으로써
- CD는 배포 과정을 자동화하여 변경 사항을 신속하고 안정적으로 사용자에게 전달함으로써
DevOps의 목표를 실현한다!
CI/CD 파이프라인
1️⃣ 코드 작성 및 버전 관리
개발자는 코드를 작성하고 Git과 같은 버전 관리 시스템에 변경 사항을 커밋한다.
이로써 코드 변경 이력이 관리되고, CI/CD 파이프라인이 시작된다.
2️⃣ 자동 빌드
코드가 커밋되면 CI 시스템이 자동으로 빌드를 수행한다.
이 단계에서는 코드 의존성이 설치되고, 애플리케이션이 정상적으로 컴파일되는지 확인한다.
3️⃣ 자동 테스트
빌드가 성공적으로 완료되면 단위 테스트, 통합 테스트 등의 자동 테스트가 실행된다.
테스트 과정에서 오류가 발생하면 파이프라인은 실패하고, 개발자는 문제를 수정해야 한다!
4️⃣ 배포 준비
코드가 성공적으로 통합되면 자동으로 패키징 되어 배포 가능한 상태로 유지된다.
5️⃣ 자동 배포
지속적인 배포가 설정되어 있다면, 안정화된 코드가 프로덕션 환경에 자동으로 배포된다.
수동 승인 프로세스를 추가할 수도 있으며, 다양한 CD 도구를 통해 운영 환경에 문제없이 배포된다!
💭 참고 - 파이프라인이란? 👇🏻
파이프라인이란 전체 작업을 여러 단계로 나누고, 각 단계를 정해진 순서에 따라 자동으로 실행하는 처리 흐름을 의미한다.
CI/CD 파이프라인에서는 코드 변경 사항이 발생하면 빌드, 테스트, 배포와 같은 단계가 자동으로 이어지며 수행된다.
CI/CD 파이프라인의 구축
이 CI/CD 파이프라인 즉, 소스코드 관리 → 자동 빌드 → 자동 테스트 → 자동 배포의 단계는 Jenkins, GitHub Actions, GitLab CI/CD, CircleCI, Azure DevOps 등의 자동화 도구를 사용해 구축한다!!
CI/CD 파이프라인을 구축하기 위해 사용할 수 있는 자동화 도구는 다양하다.
프로젝트의 규모, 조직 문화, 인프라 환경에 따라 선택지는 달라질 수 있지만, 전반적으로 가장 자주 언급되고 널리 사용되는 도구는 다음 세 가지로 압축된다!
- Jenkins
- GitHub Actions
- GitLab CI/CD
이 도구들은 모두 소스 코드 변경을 트리거로 빌드 → 테스트 → 배포 과정을 자동화한다는 공통점을 가지지만, 구조와 사용 방식 그리고 철학에는 분명한 차이가 있다.
📊 Jenkins vs GitHub vs Actions GitLab CI/CD
| 구분 | Jenkins 👴🏻 | GitHub Actions ⚙️ | GitLab CI/CD 🧪 |
| 형태 | 독립 실행형 CI/CD 서버 | GitHub 내장 CI/CD | GitLab 내장 CI/CD |
| 설치/운영 | 직접 서버 구축 및 관리 필요 | 별도 설치 불필요 | 별도 설치 불필요 |
| 설정 방식 | Groovy 기반 Pipeline Script | YAML (.github/workflows) | YAML (.gitlab-ci.yml) |
| Git 연동 | 플러그인 기반 | GitHub와 완전 통합 | GitLab과 완전 통합 |
| 확장성 | 매우 높음 (1,000개 이상의 플러그인) | GitHub Marketplace 기반 | GitLab 기능 내 통합 |
| 학습 난이도 | 비교적 높음 | 낮음 | 중간 |
이 중에서도 해당 아티클에서는 GitHub Actions에 대해 좀 더 알아보고자 한다!
그 이유는!!!
1. GitHub 저장소와의 긴밀한 통합
GitHub Actions는 GitHub에 기본 내장된 CI/CD 도구로, 별도의 CI/CD 서버를 구축하거나 관리할 필요가 없다.
코드 저장소, 이슈, PR. 릴리스 등 GitHub의 모든 이벤트를 자연스럽게 파이프라인 트리거로 활용할 수 있다!!
2. 이벤트 기반 파이프라인 구성
push, pull request, release 등 코드 변경 이벤트를 기준으로 빌드/테스트/배포 파이프라인을 자동 실행할 수 있어 CI/CD의 기본 개념을 이해하기에 매우 직관적이다.
3. YAML 기반의 명확한 파이프라인 정의
GitHub Actions는 YAML 파일을 통해 파이프라인을 정의한다.
on: push
jobs:
build:
steps:
- run: npm install
- run: npm test
이 방식은 파이프라인의 흐름이 한눈에 보이고, 각 단계에서 무엇을 실행하는지 명확하며, CI/CD의 동작 원리를 이해하는 데 큰 도움이 된다!
4. 즉, CI/CD 학습용으로 적합한 도구
이처럼 GitHub Actions는 진입 장벽이 낮고 설정이 단순하며 직관적이고 실제 실무에서도 널리 사용되고 있어 CI/CD를 처음 학습하거나 개념을 정리하기에 매우 적합한 도구라고 생각한다.
💭 참고 - 내가 헷갈렸던 부분...!! 😅
파이프라인을 구축하는 도구 vs 파이프라인에서 실행되는 도구
CI/CD를 처음 접했을 때는 파이프라인을 구축하는 도구와 파이프라인 안에서 실행되는 도구를 동일한 개념으로 생각했다.
GitHub Actions에서 워크플로우를 설정하고, push 이벤트를 트리거로 빌드와 테스트가 자동으로 돌아가는 것을 보며
아!! CI/CD 파이프라인은 전부 GitHub Actions 안에서 돌아가는 거구나.
라고 자연스럽게 받아들였다.
하지만!! 다른 문서들과 예제들을 찾아보면서 조금씩 의문이 생겼다. CI/CD 관련 글을 보다 보면 Docker, kubectl, Helm, Terraform 같은 도구들이 계속 등장했기 때문이다.
오잉... GitHub Actions로 CI/CD를 한다고 했는데, 왜 Docker나 kubectl이 같이 나오는 거지?
처음에는 GitHub Actions = CI/CD 도구 = 빌드·테스트·배포를 다 직접 수행하는 도구 라고 막연히 생각하고 있었기 때문에, 이 구조가 잘 이해되지 않았다.
이 혼란의 원인은 ‘파이프라인을 구축하는 도구’와 ‘파이프라인에서 실제로 실행되는 도구’를 구분하지 못했기 때문이었다!!!
✅ 파이프라인을 구축하는 도구
Jenkins, GitHub Actions, GitLab CI/CD 같은 도구들은 빌드나 배포를 직접 수행하는 도구라기보다는,
파이프라인의 흐름을 정의하고 어떤 조건에서 어떤 작업을 어떤 순서로 실행할지를 관리하는 CI/CD 오케스트레이터에 가깝다!
즉, 이 도구들의 역할은 무엇을 실행할지 결정하고 실행을 지휘하는 것이다.
✅ 파이프라인에서 실행되는 도구
반면 파이프라인 안에서 실제로 일을 하는 것은 다음과 같은 개별 도구들이다.
- 빌드: Gradle, Maven, npm
- 테스트: JUnit, Jest
- 이미지 빌드: Docker
- 배포: kubectl, Helm, Terraform
GitHub Actions는 이 도구들을 직접 대신 실행해주는 것이 아니라, 정의된 스크립트에 따라 호출(run) 해줄 뿐이다.
💭... 다시 보면 명확해지는 구조
그래서 CI/CD 파이프라인의 실제 구조는 다음과 같다.
- GitHub Actions → 파이프라인을 정의하고 실행
- Docker / kubectl 등 → 파이프라인을 따라!!!!! 실제 작업 수행
이 구조를 이해하고 나서야 GitHub Actions로 CI/CD를 한다는 말의 의미가 훨씬 명확하게 다가왔다. 😮💨
GitHub Actions
GitHub Actions는 GitHub 저장소와 완전히 통합된 CI/CD 자동화 도구로, YAML 형식의 설정 파일 하나로 빌드·테스트·배포 같은 자동화 파이프라인을 정의하고 실행할 수 있다.
즉, 코드 변경 이벤트가 발생하면 GitHub Actions가 자동으로 이벤트를 받아 정의된 작업 흐름(workflow)을 실행하는 구조!
📌 GitHub Actions에서 꼭 알아야 할 개념
GitHub Actions를 처음 접하면 .yml 파일 안에 등장하는 키워드들이 생각보다 많다... 😳
이 키워드들은 GitHub Actions가 CI/CD 파이프라인을 어떻게 구성하고 실행하는지를 설명하는 최소 단위의 개념들이다.
코드 변경(push / PR) → GitHub Actions에서 워크플로우 트리거 → CI: 빌드 + 테스트 → 통과하면 → CD: 서버(또는 클라우드)에 자동 배포
이 전체 과정을 YAML 하나로 정의한다는 점이 GitHub Actions의 핵심임을 기억하며 각 키워드를 이해해 보자!
1. Workflow
Workflow는 CI/CD 전체 파이프라인을 하나의 시나리오로 정의한 것이다.
Workflow 설정은 .github/workflows/xxx.yml 같은 YAML 파일로 구성되어야 한다.
2. Trigger (언제 실행할지, on)
Workflow가 언제 실행될지를 정의하는 부분이다. 주요 트리거 예시는 다음과 같다!!
- push
- pull_request
- release
- schedule
on:
push:
branches: ["main"]
3. Job (무엇을 할지, 실행 단위)
Job은 하나의 작업 단위를 의미한다.
하나의 workflow 안에는 여러 Job을 정의할 수 있고, Job은 서로 병렬 또는 순차로 실행될 수 있다!
- build job
- test job
- deploy job
jobs:
build:
runs-on: ubuntu-latest
4. Step (어떤 명령을 실행할지, job 안의 단계)
Step은 해당 Job에서 수행할 세부 작업을 뜻한다.
Step은 shell 명령어 실행이 될 수도 있고, 재사용 가능한 Action을 호출할 수도 있다.
steps:
- name: Check out code
uses: actions/checkout@v5
5. Runner (어디서 실행할지)
Runner는 실제로 Workflow를 실행하는 서버다. Runner는 두 가지 종류가 있다.
- GitHub-hosted runner
→ GitHub가 제공하는 서버
→ Ubuntu, Windows, macOS 등 다양한 OS 선택 가능 - Self-hosted runner
→ 직접 준비한 서버에서 실행
→ 회사 인프라나 커스텀 환경에서 사용할 수 있음
runs-on: ubuntu-latest
이 키워드들을 이해하고 나면, 단순히 GitHub Actions가 일을 한다가 아니라 GitHub Actions가 어떤 도구를 언제 실행하는지!!가 보이기 시작할 것이다.
이제 이 키워드들이 실제 코드에서 어떻게 조합되어 CI와 CD를 구성하는지를 살펴보자. 🤩
실제 활용 예시
다음 코드 예시는 합동세미나에서 실제로 사용했던 GitHub Actions 설정(yml) 파일이다!
CI, CD 코드 모두 각각의 키워드별로 알아보자.
CI 워크플로우 → Pull Request와 Push 시 빌드 검증
1️⃣ Workflow와 Trigger
name: ci
on:
pull_request:
branches: [main, develop]
push:
branches: [main, develop]
이 Workflow는 ci라는 이름으로 정의되어 있으며,
- main, develop 브랜치에 대한 push
- 동일 브랜치에 대한 pull request 생성 또는 업데이트
가 발생할 때 자동으로 실행된다.
즉, 코드 변경이 발생할 때마다 빌드가 정상적으로 되는지 검증하는 CI 목적의 워크플로우라는 의미!
2️⃣ Job (build)
jobs:
build:
runs-on: ubuntu-latest
build job은 이 CI 워크플로우의 핵심 실행 단위다.
GitHub가 제공하는 ubuntu-latest runner에서 실행된다. 또한 다음 조건을 통해 실행 여부를 제어한다.
if: github.event_name == 'pull_request'
|| (github.event_name == 'push' && !contains(github.event.head_commit.message, '[skip ci]'))
- PR에서는 항상 실행
- push의 경우 커밋 메시지에 [skip ci]가 있으면 실행하지 않음
이는 불필요한 CI 실행을 줄이기 위한 조건 처리다.
3️⃣ Step (실제 CI 작업들)
- 코드 체크아웃 → Runner에 현재 저장소 코드를 내려받는다.
uses: actions/checkout@v5
- 실행 환경 구성 → 이 단계들은 CI 환경을 로컬 개발 환경과 최대한 동일하게 맞추기 위한 준비 단계다.
- pnpm 설치
- Node.js 설정
- 의존성 설치
- 빌드 실행
pnpm run build
이 단계가 CI의 핵심이다!!!
Vite 기반 프로젝트를 실제로 빌드해 보면서 문법 오류, 타입 오류, 설정 오류 등을 조기에 검출한다!!
continue-on-error: true를 사용한 이유는 빌드 실패 시에도 이후 Step(PR 코멘트 등)를 실행하기 위함이다.
4️⃣ 빌드 결과 처리 & PR 피드백
빌드 결과에 따라 상태를 판단하고 (성공 → 🥳, 실패 → ⛔️) PR에 자동으로 코멘트를 남긴다!
마지막으로 빌드가 실패했을 경우,
run: exit 1
을 통해 Job 자체를 실패 처리하여 PR 병합 시 CI 실패가 명확히 드러나게 한다!
👇🏻 CI 코드 전문
name: ci
on:
pull_request:
branches: [main, develop]
push:
branches: [main, develop]
permissions:
contents: read
pull-requests: write
jobs:
build:
if: github.event_name == 'pull_request' || (github.event_name == 'push' && !contains(github.event.head_commit.message, '[skip ci]'))
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v5
- name: Install pnpm
uses: pnpm/action-setup@v4
with:
version: 9.12.0
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: "22.x"
cache: "pnpm"
- name: Install dependencies
run: pnpm install --frozen-lockfile
- name: Build project with Vite
id: build
run: pnpm run build
continue-on-error: true
- name: Evaluate build status
id: status
run: |
result="failed"
message="빌드 실패 ⛔️"
if [ "${{ steps.build.outcome }}" == "success" ]; then
result="success"
message="빌드 성공 🥳"
fi
echo "result=$result" >> $GITHUB_OUTPUT
echo "message=$message" >> $GITHUB_OUTPUT
- name: Add comment to PR with build status
if: github.event_name == 'pull_request'
uses: actions/github-script@v6
with:
script: |
const prNumber = context.payload.pull_request.number;
const message = `${{ steps.status.outputs.message }}`;
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: prNumber,
body: `### 빌드 결과\n${message}`
});
- name: Fail job if build failed
if: steps.build.outcome == 'failure'
run: exit 1
👇🏻 CD 코드 전문
name: git push into another repo to deploy to vercel
on:
push:
branches: [main, develop]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- name: creates output
run: sh ./build.sh
- name: Pushes to another repository
id: push_directory
uses: cpina/github-action-push-to-another-repository@main
env:
API_TOKEN_GITHUB: ${{ secrets.'토큰명' }}
with:
source-directory: "output"
destination-github-username: '본인 닉네임'
destination-repository-name: '레포지토리명'
user-email: ${{ secrets.'이메일 토큰명' }}
commit-message: ${{ github.event.commits[0].message }}
target-branch: ${{ github.ref_name }}
- name: Test get variable exported by push-to-another-repository
run: echo $DESTINATION_CLONED_DIRECTORY
솔직히 말하자면, 이 코드를 처음 작성했을 당시에는 리드 님께 받은 아티클을 복사하고 붙여넣은 수준이었다...
시간이 급박하기도 했고, 일단 돌아가니까...!!! 라는 생각으로 사용했지, 각 설정이 정확히 어떤 역할을 하는지까지는 깊게 생각하지 못했다.
하지만 CI/CD 파이프라인이 무엇이고 무엇으로 구축을 하는지 개념을 하나씩 정리하니 이 yml 파일을 제대로 이해할 수 있게 된 것 같아서 뿌듯하다...... 😳
참고 자료
DevOps 엔지니어가 알려주는 CI/CD 파이프라인 도구 선택
'FE' 카테고리의 다른 글
| pnpm이란? (0) | 2026.01.02 |
|---|---|
| 에러 핸들링을 하는 방법(Suspense와 ErrorBoundary) (0) | 2026.01.02 |
| 페이지네이션에 대해서 (0) | 2025.12.21 |
| Tanstack Query의 데이터 최신화 (0) | 2025.12.14 |
| 낙관적 업데이트 적용하기 (0) | 2025.12.05 |
