오늘은 GitHub 배포 정책 중에서 CI/CD 정책에 대해서 작성해보도록 하겠습니다. 우선 CI/CD에 대해서 설명을 해보도록 하겠습니다!!
1. 들어가며
최근 프로젝트에서는 코드 변경이 있을 때마다 서버에 수동으로 배포하는 과정이 반복되었습니다. 이 과정은 단순하지만 인적 오류가 발생하기 쉽고, 배포 속도 또한 느렸습니다.
이를 개선하기 위해 GitHub Actions 기반 CI/CD 자동 배포 파이프라인을 구축했습니다. 이 글에서는 그 과정과 주요 설정 방법을 공유합니다.
2. CI/CD란 무엇인가?
CI/CD(Continuous Integration / Continuous Deployment) 는
개발자가 작성한 코드를 자동으로 빌드, 테스트, 배포하는 일련의 자동화 프로세스입니다.
- CI (지속적 통합)
코드 변경 시 자동으로 테스트 및 빌드가 수행되어 문제를 조기에 발견함. - CD (지속적 배포)
테스트를 통과한 코드가 자동으로 서버나 클라우드 환경(GCP, AWS 등)에 배포됨.
이 두 단계를 통해 개발자는 “코드 작성에만 집중”할 수 있고,
운영 환경은 항상 최신 상태를 유지하게 됩니다.
3. 사용한 도구와 환경
구성 요소 사용 기술
| 소스 관리 | GitHub |
| CI/CD 도구 | GitHub Actions |
| 배포 환경 | Google Cloud Run |
| 컨테이너 빌드 | Docker |
| 프레임워크 | Django (Python 3.12) |
4. 파이프라인 구조
자동화 파이프라인은 다음 두 단계로 구성됩니다.
- Build & Test 단계 (CI)
- develop 브랜치에서 변경 발생 시,
Django 앱을 빌드하고 기본 테스트(python manage.py check) 수행. - 문제가 없으면 Docker 이미지를 생성.
- develop 브랜치에서 변경 발생 시,
- Deploy 단계 (CD)
- main 브랜치로 병합되면,
GitHub Actions가 GCP 서비스 계정 키(GCP_SA_KEY)를 이용해 Cloud Run에 자동 배포.
- main 브랜치로 병합되면,
아래의 방향성을 가져갑니다.
Develop branch → GitHub Actions (Build/Test)
↓
Docker Build
↓
Main branch merge → GCP Cloud Run Deploy
5. 주요 설정 파일
name: PDFmask CI/CD Pipeline
on:
push:
branches:
- main
jobs:
build:
name: Build & Test Django App
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: '3.12'
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run tests
run: python manage.py check
deploy:
name: Deploy to GCP (CD)
runs-on: ubuntu-latest
needs: build
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Authenticate to Google Cloud
uses: google-github-actions/auth@v1
with:
credentials_json: ${{ secrets.GCP_SA_KEY }}
- name: Deploy to Cloud Run
uses: google-github-actions/deploy-cloudrun@v1
with:
service: pdfmask-service
region: asia-northeast3
image: gcr.io/${{ secrets.GCP_PROJECT_ID }}/pdfmask:latest
6. 시뮬레이션
실제 프로젝트에서의 브랜치 구조와 CI/CD 흐름
보통 하나의 프로젝트는 다음과 같은 브랜치 구조로 운영됩니다.
Main (배포용) → Develop (테스트용) → Feature (기능 개발용) → 기타 개인 작업 브랜치
1. Feature 브랜치 – 기능 개발 단계
새로운 기능이나 수정 사항을 구현할 때는 개인 브랜치에서 개발을 진행합니다.
구현이 완료되면 로컬 서버에서 테스트를 수행하기 위해 해당 기능을 feature 브랜치에 merge 합니다.
이 단계에서는 실험적인 수정도 자유롭게 가능합니다.
2. Develop 브랜치 – 통합 테스트 단계
feature에서 기능이 정상적으로 동작하면 develop 브랜치로 병합하여 코드를 최신화합니다.
develop은 실제 서비스용은 아니지만,
GCP 테스트 인스턴스에 임시로 배포하여 실환경과 유사한 조건에서 문제를 검증합니다.
이를 통해 사용자 환경에서 발생할 수 있는 오류를 사전에 점검합니다.
3. Main 브랜치 – 실제 배포 단계
develop에서 기능 검증이 완료되면 main 브랜치에 병합합니다.
main 브랜치에 코드가 반영되면 자동으로 Docker 이미지를 생성하고 GCP에 배포되어,
즉시 서비스에서 새로운 기능이 사용 가능해집니다.
이 과정을 통해 개발자는 수동 배포 과정에서 발생하는 시간 낭비를 줄이고,
코드 품질 개선과 기능 개발에 더 집중할 수 있는 환경을 구축하게 됩니다.

이렇게 실제로 로컬에서 돌리다가 GCP 테스트 인스턴스에서 테스트 했을 때 문제가 발생했던 내용입니다. 이걸 바로 Main에 배포하게 되면 문제가 발생하기 때문에 Develop 브랜치에서 오류를 찾아 문제를 해결 후 코드 검토를 받고 Main에 올릴 수 있게 됩니다!!
물론 작업 과정은 프로젝트 하는 팀원에 따라 달라질 수 있습니다. 하지만 CI/CD는 개발자의 수동 배포 과정을 줄이고 코드 품질 개선과 기능 개발에 더 집중한다는 공통점만 알고 있으시면 될 것 같습니다!
틀린 내용이나 궁금한 사항이 있으시다면 적어주시면 감사하겠습니다!
'Backend & Infra > GitHub' 카테고리의 다른 글
| [GIT] GitHub로 개인 홈페이지 만들기! (0) | 2026.03.02 |
|---|---|
| VSCode, WSL <-> 윈도우, Git & 줄 바꿈 문자 (CRLF/LF) 문제 해결 (0) | 2025.11.26 |
| [Git] 커밋 메시지 규칙 - 2 (0) | 2025.02.28 |
| [Git] Unity GitHub 참고사항 (0) | 2024.09.09 |
| [Git] 커밋 메시지 규칙 (0) | 2024.09.03 |