CI/CD 도구는 GitHub Actions, Jenkins, GitLab CI, CircleCI 등 다양하다.
하지만 그중에서 GitHub Actions을 선택했다.
그이유는
1. GitHub 레포와 바로 통합: 추가 서버 설치나 별도 세팅 없이, push 이벤트만으로 실행 가능
2.YAML 기반 선언형 설정:.github/workflows/*.yml만 작성하면 자동 실행
3.AWS와의 연동 편의성:aws-actions/configure-aws-credentials,amazon-ecr-login액션 제공
4.비용 효율성: 기본 무료 크레딧 제공, 학습/개발 단계에서 부담 없음
CI/CD 도구 정리
| 구분 | GitHub Actions | Jenkins | GitLab CI/CD | CircleCI |
|---|---|---|---|---|
| 설치/운영 방식 | SaaS (GitHub에 내장) | 자체 서버 설치 필요 | GitLab 내장 (SaaS/온프레미스 모두 지원) | SaaS 중심 |
| 학습 난이도 | 낮음 (YAML 선언형, GitHub 연동 직관적) | 높음 (플러그인, 서버 관리 필요) | 중간 (GitHub Actions와 유사, GitLab UI 활용) | 낮음 (UI 친화적, 설정 간단) |
| AWS 연동 | ✅ AWS 공식 액션 지원 (configure-aws-credentials, amazon-ecr-login) | 가능 (플러그인/스크립트 직접 설정) | 가능 (Runner 환경 구성 필요) | 가능 (Orb/스크립트 활용) |
| 비용 | GitHub 기본 무료 크레딧 제공 (추가 사용 시 과금) | 서버 운영/유지보수 비용 발생 | SaaS 플랜 or 자체 호스팅 선택 가능 | 무료 플랜 제한적, 유료 요금제 필요 |
| 장점 | - GitHub Repo와 완벽 통합 - Marketplace 액션 풍부 - 초기 설정이 간단 | - 오픈소스, 커스터마이징 자유도 높음 - 대규모 기업/레거시 환경에 적합 | - GitLab 하나로 Repo+CI/CD 통합 관리 - 코드 리뷰/이슈 관리와 자연스럽게 연결 | - 빠른 설정, 클라우드 친화적 - 다양한 언어/환경 기본 지원 |
| 단점 | - GitHub 기반 프로젝트에만 최적 - 워크플로우 복잡해지면 관리 어려움 | - 학습 곡선 높음 - 서버 리소스 및 유지보수 부담 | - GitHub 프로젝트라면 이중 관리 필요 - GitLab 환경 종속성 | - 무료 사용량 제한 - GitHub Actions 대비 커뮤니티 자료 적음 |
| AI 면접 서비스 적합성 | ✅가장 적합: GitHub 기반 레포 관리 + AWS 배포와 자연스럽게 연계 | 가능하나 서버 운영 비용/관리 부담 큼 | GitHub 대신 GitLab을 쓴다면 고려 가능 | 간단한 PoC/스타트업 초기엔 적합하지만 AWS 연동은 GitHub Actions보다 불편 |
구축 과정
GitHub Actions 워크플로우 생성
.github/workflows/*.yml경로에 워크플로우 파일 작성- 특정 브랜치(
develop) 또는 디렉토리(backend/**) 변경 시 트리거되도록 설정
name: Build and Push to ECR
on:
push:
branches: [ "develop" ] # ← develop 브랜치에서만 작동
workflow_dispatch:
env:
AWS_REGION: ap-northeast-2
IMAGE_TAG: latest
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
- name: ✅ Checkout source code
uses: actions/checkout@v3
- name: 🐳 Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: 🔐 Login to Amazon ECR
uses: aws-actions/amazon-ecr-login@v1
- name: 🏗️ Build Docker image
run: |
docker build -t ${{ secrets.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} .
- name: 🏷️ Tag Docker image with ECR URI
run: |
docker tag ${{ secrets.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }} \
${{ secrets.ECR_REGISTRY }}/${{ secrets.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }}
- name: 📤 Push Docker image to Amazon ECR
run: |
docker push ${{ secrets.ECR_REGISTRY }}/${{ secrets.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }}github secrets 설정
- AWS ID key
- AWS secrets key
- ECR 주소
- ECR 이름
Dockerfile 예시
# Dockerfile.backend
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY backend/ ./backend/
WORKDIR /app/backend
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]
흐름
[개발자가 GitHub에 코드 push]
↓
[GitHub Actions가 자동 실행됨]
↓
[1. 의존성 설치 & 테스트 실행 (CI)]
↓
[2. Docker 이미지 빌드]
↓
[3. AWS ECR에 푸시 (CI/CD 연결점)]
↓
[4. AWS ECS Fargate로 배포 (CD)]
↓
[5. 사용자 또는 개발 서버에서 서비스 확인]상세 과정
1. ECR 레포 생성
2. GitHub Secrets 설정
- 레포 → Settings → Secrets and variables → Actions
New repository secretclick- 아래 사진과 같이 4개 생성
3. yaml 파일 작성
- .github/workflows 경로에 생성된 yaml 파일 작성
- ecr-push-backend.yml
name: Build & Push Django Backend
on:
push:
paths:
- "backend/**"
- "Dockerfile.backend"
- "requirements.txt"
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v2
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ${{ secrets.AWS_REGION }}
- name: Login to ECR
id: login-ecr
uses: aws-actions/amazon-ecr-login@v1
- name: Build & Push Django image
env:
ECR_REPOSITORY: ${{ secrets.ECR_REPOSITORY }}
IMAGE_TAG: backend-${{ github.sha }}
run: |
docker build -f Dockerfile.backend -t $ECR_REPOSITORY:$IMAGE_TAG .
docker push $ECR_REPOSITORY:$IMAGE_TAG
4. Dockerfile 작성
# Dockerfile.backend
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY backend/ ./backend/
WORKDIR /app/backend
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]5. 적용
-
Github에 Push
-
시간 지나면 완료
-
ECR에서도 확인 가능
느낀 점 & 주의할 점
느낀 점
1.GitHub Actions는 진입장벽이 낮다: Jenkins처럼 서버 관리가 필요 없고, YAML만 작성하면 된다.
2.AWS 공식 액션이 있어 연동이 매우 편하다: 인증, ECR 로그인 등 수동 스크립트보다 훨씬 간단했다.
3.자동화는 곧 신뢰성: 매번 같은 과정으로 빌드/배포되니, 환경차이로 인한 문제를 줄일 수 있었다.
주의할 점
1.Secrets 관리: 키 유출 방지를 위해 GitHub Secrets에 반드시 저장해야 한다.
2.빌드 속도: 매번 의존성 설치를 하면 느려진다 → 캐싱(actions/cache) 고려 필요
3.브랜치 전략: develop, main 브랜치 전략을 확실히 정리해야 자동 배포 시 혼란이 없다.
4.ECS 배포 자동화까지 가려면 CodeDeploy/Blue-Green 전략 등 추가 구성이 필요하다.
마무리
이번 과정을 통해 CI/CD의 핵심은 단순 반복작업을 신뢰성 있게 자동화하는 것임을 다시 느꼈다.
GitHub Actions는 배우기 쉽고, AWS와도 자연스럽게 연결되므로 초기 프로젝트나 스타트업 환경에서 사용할만 하다고 느꼈다.
