서론: 반복적인 배포 작업, 이제는 안녕!

안녕하세요, 개발자 여러분! 프론트엔드 개발을 하다 보면 코드 작성만큼이나 많은 시간을 할애하는 작업이 있습니다. 바로 빌드(Build), 테스트(Test), 배포(Deploy) 과정이죠. 기능 하나를 수정하고 npm run build를 실행하고, 빌드된 파일을 FTP로 서버에 올리거나, 클라우드 스토리지에 업로드하는 과정을 수동으로 반복하고 있지는 않으신가요? 이러한 반복적인 작업은 실수를 유발하고, 소중한 개발 시간을 앗아갑니다.

이 지루한 과정을 자동화하여 우리를 칼퇴의 길로 인도해 줄 구원자, 바로 GitHub Actions입니다! GitHub Actions는 GitHub 저장소(Repository) 내에서 소프트웨어 개발 워크플로우를 자동화할 수 있게 해주는 강력한 도구입니다. 이 글에서는 GitHub Actions를 이용하여 프론트엔드 프로젝트의 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인을 구축하는 방법을 A to Z로 알아보겠습니다.

1. GitHub Actions, 도대체 뭔가요?

GitHub Actions는 특정 이벤트(Event)가 발생했을 때, 미리 정의된 일련의 작업(Job)들을 자동으로 실행해주는 CI/CD 플랫폼입니다. 예를 들면 다음과 같은 시나리오가 가능합니다.

• main 브랜치에 push가 되면 자동으로 테스트 코드를 실행한다.
• pull request가 생성되면 코드를 빌드하여 오류가 없는지 확인한다.
• 새로운 release가 생성되면 빌드된 결과물을 실제 운영 서버에 배포한다.

이 모든 과정이 GitHub 내에서 네이티브하게 이루어지기 때문에 Jenkins, Travis CI, CircleCI 같은 별도의 CI/CD 도구를 구축하고 연동하는 복잡함이 크게 줄어듭니다.

2. GitHub Actions의 핵심 개념

워크플로우를 작성하기 전에 몇 가지 핵심 개념을 알아야 합니다.

• Workflow: 하나 이상의 Job으로 구성된 자동화된 프로세스입니다. .github/workflows/ 디렉토리 안에 .yml 또는 .yaml 확장자로 정의됩니다.
• Event: 워크플로우 실행을 유발하는 특정 활동입니다. push, pull_request, schedule 등 다양한 이벤트를 사용할 수 있습니다.
• Job: 하나의 Runner에서 실행되는 여러 Step들의 집합입니다. 여러 Job을 병렬 또는 순차적으로 실행할 수 있습니다.
• Step: Job 안에서 실행되는 개별적인 작업 단위입니다. 셸 명령어를 실행하거나(run), 미리 만들어진 Action을 사용할 수 있습니다(uses).
• Action: 워크플로우를 구성하는 가장 작은 빌딩 블록입니다. GitHub 커뮤니티가 만들어 놓은 수많은 Action들이 마켓플레이스에 공개되어 있어, 복잡한 작업을 간단하게 가져다 쓸 수 있습니다. (actions/checkout, actions/setup-node 등)
• Runner: 워크플로우가 실행되는 서버입니다. GitHub에서 제공하는 가상 머신(Ubuntu, Windows, macOS)을 사용하거나, 직접 서버를 구성하여 Self-hosted Runner로 사용할 수 있습니다.

3. 실전! React 프로젝트 배포 자동화하기 (feat. AWS S3)

이제 이론은 충분합니다! 간단한 React 프로젝트를 빌드하여 AWS S3 정적 웹 호스팅으로 배포하는 워크플로우를 직접 만들어 보겠습니다.

3-1. 워크플로우 파일 생성

먼저, 프로젝트의 루트 디렉토리에 .github/workflows/deploy.yml 파일을 생성합니다.

# .github/workflows/deploy.yml

name: Deploy to AWS S3 # 워크플로우의 이름

on:
  push:
    branches:
      - main # main 브랜치에 push 될 때 실행

jobs:
  build-and-deploy:
    name: Build and Deploy
    runs-on: ubuntu-latest # 실행될 Runner 환경

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3 # 1. 코드를 Runner로 체크아웃

      - name: Set up Node.js
        uses: actions/setup-node@v3 # 2. Node.js 환경 설정
        with:
          node-version: '18' # Node.js 버전 지정

      - name: Install dependencies
        run: npm install # 3. 의존성 설치

      - name: Build project
        run: npm run build # 4. 프로젝트 빌드

      - name: Deploy to S3
        uses: jakejarvis/[email protected] # 5. S3에 빌드 결과물 업로드
        with:
          args: --acl public-read --follow-symlinks --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: 'ap-northeast-2'
          SOURCE_DIR: 'build' # 빌드 결과물이 있는 디렉토리

3-2. AWS 자격 증명 설정 (Secrets)

워크플로우 파일에 AWS Access Key 같은 민감한 정보를 직접 하드코딩하는 것은 매우 위험합니다. GitHub에서는 이런 민감 정보를 안전하게 저장하기 위해 Secrets 기능을 제공합니다.

1. GitHub 저장소의 Settings 탭으로 이동합니다.
2. 왼쪽 메뉴에서 Secrets and variables > Actions를 선택합니다.
3. New repository secret 버튼을 클릭하여 아래의 값들을 추가합니다.
   • AWS_S3_BUCKET: 배포할 S3 버킷 이름
   • AWS_ACCESS_KEY_ID: AWS IAM 사용자의 Access Key ID
   • AWS_SECRET_ACCESS_KEY: 해당 사용자의 Secret Access Key

이제 워크플로우 파일의 ${{ secrets.SECRET_NAME }} 구문을 통해 안전하게 민감 정보에 접근할 수 있습니다.

4. 마무리하며

이제 main 브랜치에 코드를 push 할 때마다 GitHub Actions가 자동으로 프로젝트를 빌드하고 S3에 배포해 줄 것입니다. 더 이상 수동으로 빌드 명령어를 치고 파일을 업로드할 필요가 없습니다. 개발자는 오직 코드에만 집중할 수 있게 된 것이죠!

오늘 우리는 GitHub Actions를 이용해 프론트엔드 배포 자동화의 첫걸음을 내디뎠습니다. 이 워크플로우를 확장하면 테스트 자동화, Slack 알림 연동, Docker 이미지 빌드 및 배포 등 무궁무진한 자동화를 구현할 수 있습니다. 여러분의 프로젝트에 숨어있는 반복적인 작업들을 찾아 GitHub Actions로 자동화해보는 것은 어떨까요? 여러분의 개발 경험이 한층 더 쾌적해질 것이라 확신합니다!