CI/CD 기초 1편: 개념과 GitHub Actions

CI/CD가 뭔가요?

쉽게 말하면 코드를 GitHub에 올린 다음, 사람이 반복하던 검사와 배포를 자동화하는 것이다.

코드 작성
  ↓
GitHub에 Push
  ↓
자동 테스트와 빌드                 ← CI
  ↓
통과한 프로그램을 서버에 배포     ← CD
  ↓
실제 서비스 동작 확인

1. CI(Continuous Integration)

한국어로는 지속적 통합이다. 여러 사람이 작성한 코드나 새로 작성한 코드가 기존 프로젝트와 잘 합쳐지는지 자동으로 검사한다.

현재 프로젝트인 Pi-monitor를 예로 들면 다음 작업이 CI에 해당한다.

Frontend

npm ci
npm test
npm run build

Backend

./mvnw test
./mvnw package

잘못된 코드를 GitHub에 올렸을 때 프론트엔드 테스트, Vue 빌드, Java 컴파일 또는 백엔드 테스트가 실패할 수 있다. CI가 없으면 사람이 매번 직접 명령을 실행해야 한다.

cd frontend
npm test
npm run build

cd ../backend
./mvnw test

CI를 구성하면 GitHub가 별도의 실행 환경에서 이 명령들을 자동으로 실행한다.

2. CD(Continuous Delivery 또는 Deployment)

CD에는 두 가지 의미가 있다.

Continuous Delivery: 배포 가능한 상태까지 자동으로 준비하고 실제 배포는 사람이 승인한다.
Continuous Deployment: 테스트가 통과하면 실제 서버 배포까지 자동으로 진행한다.

배포 시스템을 처음 구성한다면 사람이 마지막으로 승인하는 Continuous Delivery 방식이 안전하다.

Continuous Delivery 예시

main에 Push
→ 테스트 및 빌드
→ 배포 준비 완료
→ 사람이 Deploy 버튼 클릭

Continuous Deployment 예시

main에 Push
→ 테스트 및 빌드 통과
→ 라즈베리파이 자동 업데이트
→ 컨테이너 재시작

3. GitHub Actions

GitHub Actions는 GitHub에서 CI/CD 작업을 실행해 주는 기능이다. 저장소에 다음과 같은 Workflow 파일을 만든다.

.github/
└── workflows/
    └── ci.yml

ci.yml에는 언제, 어떤 운영체제에서, 어떤 명령을 실행할지 정의한다.

name: CI

on:
  push:
  pull_request:

jobs:
  frontend:
    runs-on: ubuntu-latest

    steps:
      - name: 소스 코드 가져오기
        uses: actions/checkout@v4

      - name: Node.js 설치
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
          cache-dependency-path: frontend/package-lock.json

      - name: 패키지 설치
        working-directory: frontend
        run: npm ci

      - name: 테스트
        working-directory: frontend
        run: npm test

      - name: 빌드
        working-directory: frontend
        run: npm run build

이 파일을 Push하면 GitHub가 Ubuntu 가상 환경을 만들고 위 명령을 실행한다.

4. 알아두면 좋은 용어

용어	의미
Workflow	CI/CD 전체 작업을 정의한 파일
Trigger	작업을 시작시키는 사건. 예: Push, Pull Request
Job	테스트, 빌드처럼 하나로 묶인 작업
Step	Job 안에서 실행하는 개별 명령
Runner	실제 명령을 실행하는 컴퓨터
Artifact	빌드해서 만들어진 결과물
Secret	비밀번호, 토큰 같은 비공개 값
Deploy	완성된 프로그램을 실제 서버에 반영하는 작업
Rollback	문제가 생겼을 때 이전 버전으로 복구하는 작업

5. 내 프로젝트로 보는 CI/CD

GitHub Push
  │
  ├─ Frontend CI
  │    ├─ npm ci
  │    ├─ npm test
  │    └─ npm run build
  │
  ├─ Backend CI
  │    ├─ Maven test
  │    └─ Spring Boot package
  │
  └─ 모든 검사 통과
       │
       ├─ Vercel이 프론트엔드 자동 배포
       └─ Raspberry Pi에 백엔드 배포

프론트엔드는 Vercel과 GitHub 저장소가 연결되어 있어 기본적인 CD를 사용하고 있다. main에 Push하면 Vercel이 자동으로 빌드하고 배포한다.

반면 라즈베리파이 백엔드는 다음 명령으로 수동 배포 중이므로 이 부분을 자동화해야 한다.

git pull
./scripts/pi-compose.sh up -d --build

6. 추천 학습 순서

GitHub Actions로 프론트엔드 테스트와 빌드 자동화
백엔드 테스트와 빌드 추가
Pull Request에서 CI가 통과해야 Merge하도록 설정
Vercel 자동 배포 과정 이해
라즈베리파이 자동 배포 테스트

7. 라즈베리파이 CD 방법

SSH로 배포

GitHub Actions가 라즈베리파이에 SSH로 접속해 배포 명령을 실행한다.

GitHub Actions
→ SSH 접속
→ git pull
→ Docker 이미지 빌드
→ 컨테이너 교체
→ 상태 확인

다만 라즈베리파이를 외부에서 SSH로 접근할 수 있어야 한다.

Self-hosted Runner 사용

라즈베리파이에 GitHub Actions Runner를 설치하면 GitHub가 보낸 작업을 라즈베리파이가 직접 실행한다. 외부 SSH 포트를 열 필요는 없지만, 공개 저장소나 신뢰할 수 없는 PR의 코드가 실행되지 않도록 주의해야 한다.

이미지 기반 배포

GitHub Actions가 Docker 이미지를 빌드해 Container Registry에 올리고, 라즈베리파이는 완성된 이미지만 내려받는다.

GitHub Actions
→ Docker 이미지 빌드
→ GitHub Container Registry에 Push
→ Raspberry Pi가 이미지 Pull
→ 컨테이너 교체

가장 체계적인 방식이며, 다음 글에서 Docker 기반 CI/CD 흐름을 더 자세히 살펴본다.