티스토리 뷰

반응형

✅ 압박면접 대응 시리즈 25편: CI/CD 파이프라인 구조와 GitHub Actions 실무 자동화 전략

압박면접에서 “CI/CD를 구성해본 적 있나요?”라는 질문은 단순히 빌드 자동화 경험을 묻는 게 아닙니다.
면접관은 이렇게 생각합니다.

“이 지원자는 코드를 배포 가능한 상태로 유지할 줄 아는가?”
“품질, 속도, 안정성 사이의 균형을 이해하는가?”

이번 편에서는 CI/CD의 기본 개념, GitHub Actions 파이프라인 설계,
그리고 실무에서 실제로 적용된 자동화 사례를 공유합니다.


📌 1. CI/CD란 무엇인가?

용어 의미 핵심 목표

CI (Continuous Integration) 코드 변경 시 자동 빌드·테스트 품질 확보, 코드 통합 자동화
CD (Continuous Deployment/Delivery) CI 이후 자동 배포 배포 속도 향상, 운영 안정성 확보

📌 한 줄 요약:

“CI는 품질을, CD는 속도를 책임진다.”


📌 2. CI/CD의 전체 흐름

graph TD
A[개발자 커밋] --> B[GitHub Actions 빌드 트리거]
B --> C[의존성 설치 & 테스트]
C --> D[Docker 이미지 빌드]
D --> E[테스트 환경 배포]
E --> F[승인 후 프로덕션 반영]

📌 핵심 포인트:

  • 테스트 실패 시 배포 중단
  • 승인(review) 절차로 안전한 운영 환경 확보

📌 3. GitHub Actions 기본 구조

반응형
name: CI/CD Pipeline

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Build Docker image
        run: docker build -t myapp:latest .

      - name: Deploy to server
        run: |
          docker stop myapp || true
          docker rm myapp || true
          docker run -d -p 3000:3000 myapp:latest

📌 면접 포인트:

“GitHub Actions를 사용해 코드 푸시 → 테스트 → 이미지 빌드 → 배포까지
완전 자동화된 파이프라인을 구성했습니다.”


📌 4. 주요 단계별 설명

✅ ① 코드 Checkout

- uses: actions/checkout@v4

GitHub 저장소의 코드를 가져오는 기본 단계입니다.


✅ ② 빌드 & 테스트

- run: npm ci
- run: npm test

테스트 실패 시 배포 중단 → 품질 보증


✅ ③ Docker 이미지 빌드 & Push

- name: Build and push image
  run: |
    docker build -t ghcr.io/org/app:${{ github.sha }} .
    docker push ghcr.io/org/app:${{ github.sha }}

CI 단계에서 이미지를 빌드하면, 배포 환경은 항상 동일한 이미지를 사용하게 됩니다.


✅ ④ CD (배포) 단계

- name: Deploy via SSH
  uses: appleboy/ssh-action@v0.1.10
  with:
    host: ${{ secrets.SERVER_IP }}
    username: ubuntu
    key: ${{ secrets.SSH_KEY }}
    script: |
      docker pull ghcr.io/org/app:${{ github.sha }}
      docker stop app || true
      docker rm app || true
      docker run -d -p 3000:3000 ghcr.io/org/app:${{ github.sha }}

📌 보안 포인트:

GitHub Secrets에 서버 접근 키(SSH_KEY)와 환경변수를 저장해
코드 노출 없이 배포 자동화를 구현.


📌 5. 실무 적용 사례

상황:
배포 과정이 수동으로 진행되어 인적 실수(버전 혼동, 환경 누락)가 잦음

해결 과정:

  1. GitHub Actions + Docker 기반 CI/CD 구축
  2. main 브랜치 병합 시 자동 빌드 및 배포
  3. Blue-Green 구조로 다운타임 없이 전환

📈 결과:

  • 배포 시간 30분 → 3분
  • QA 승인 후 자동 배포로 릴리즈 일관성 확보
  • 운영자 개입률 0%

📌 6. 압박면접 예상 질문 & 답변 포인트

  • Q. CI/CD의 가장 큰 장점은?
    → “사람이 아닌 시스템이 품질과 일관성을 보장합니다.”
  • Q. GitHub Actions과 Jenkins 차이는?
    → “GitHub Actions는 코드 중심 파이프라인에 강하고,
    Jenkins는 온프레미스 환경과 복잡한 워크플로우에 유리합니다.”
  • Q. 배포 중 실패했을 때 복구는 어떻게 하나요?
    → “Blue-Green 구조로 트래픽을 즉시 이전하거나,
    이전 이미지 태그로 즉시 롤백했습니다.”

📌 7. 면접에서 활용할 한 줄 정리

“GitHub Actions 기반 CI/CD 파이프라인을 구축해
테스트 자동화, 이미지 빌드, 무중단 배포를 구현했습니다.
배포 시간은 90% 단축되고, 운영자가 직접 개입하지 않아도 안전하게 서비스가 릴리즈되었습니다.”



압박면접,CI/CD,GitHubActions,자동배포,BlueGreen,Docker,DevOps,파이프라인,테스트자동화,무중단배포


 

※ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2026/04   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30
글 보관함
반응형