CI/CD 시작하기(S3 + CloudFront)
프론트엔드는 S3와 CloudFront를 통해, 백엔드는 EC2를 통해 배포하는 것에 성공했습니다. 배포를 마치고 확인해 보니, 수정해야 할 사항들이 몇 가지 발생했습니다. 꼭 수정이 아니더라도, 새로운 기능을 추가하는 일도 발생할 수 있겠죠. 기존 코드를 수정하든 새
1. CI/CD와 Github Actions 🎯
1-1. CI/CD란? ✍️
프론트엔드는 S3와 CloudFront를 통해, 백엔드는 EC2를 통해 배포하는 것에 성공했습니다. 배포를 마치고 확인해 보니, 수정해야 할 사항들이 몇 가지 발생했습니다. 꼭 수정이 아니더라도, 새로운 기능을 추가하는 일도 발생할 수 있겠죠.
기존 코드를 수정하든 새로운 기능을 추가하든, 코드를 작성한 뒤 commit을 하고 브랜치에 merge를 한 뒤 배포를 하는 과정이 매번 반복됩니다. 그런데 저는 귀찮은 것을 너무 싫어하는 사람입니다.
Continuous Integration는 지속적인 통합, Continuous Deployment는 지속적인 배포를 의미합니다. 코드의 수정에 수반되는 반복적인 통합과 배포의 과정을 자동화하기 위해 CI/CD를 학습하게 되었습니다.

CI/CD는 일반적으로 위와 같은 과정을 거치게 됩니다.
특정 기능을 개발해서 commit을 하면, 자동으로 빌드와 테스트를 거친 뒤, 테스트에 통과한 경우 실제로 배포를 수행하게 되는 것이죠.
1-2. Github Actions를 활용한 CI/CD 흐름 ✍️
CI/CD라는 자동화 프로세스를 구축할 수 있는 툴에는 여러 가지가 있습니다. Github Actions / Jenkins / Circle CI / Travis CI 등이 있죠. 저는 이번에 Github Actions를 사용하려고 합니다.
GitHub과 하나로 통일된 환경에서 CI/CD 수행이 가능하다는 점이 가장 매력적으로 다가왔습니다.
Github Actions는, CI/CD 과정에서 빌드 / 테스트 / 배포에 대한 로직을 실행할 수 있는 일종의 컴퓨터로 생각할 수 있습니다.

개발자가 코드를 작성한 후 commit을 하고 GitHub에 push 하면, GitHub는 Push를 감지해서 Github Actions에 작성한 로직을 실행합니다. 여기서 말하는 로직은 빌드 / 테스트 / 배포에 관한 로직이겠죠. 마지막으로 서버에서는 배포된 최신 코드로 서버를 재실행합니다.
1-3. Github Actions 기본 문법 ✍️
.github/workflows/deploy.yml
프로젝트 루트에 위 경로에 맞는 폴더와 파일을 구성합니다. 이후 deploy.yml 파일에 아래의 내용을 작성합니다.
# Workflow의 이름
# Workflow : 하나의 yml 파일을 하나의 Workflow라고 부른다.
name: Github Actions 실행시켜보기
# Event : 실행되는 시점을 설정
# main이라는 브랜치에 push 될 때 아래 Workflow를 실행
on:
push:
branches:
- main
# 하나의 Workflow는 1개 이상의 Job으로 구성된다.
# 여러 Job은 기본적으로 병렬적으로 수행된다.
jobs:
# Job을 식별하기 위한 id
My-Deploy-Job:
# Github Actions를 실행시킬 서버 종류 선택
runs-on: ubuntu-latest
# Step : 특정 작업을 수행하는 가장 작은 단위
# Job은 여러 Step들로 구성되어 있다.
steps:
- name: Hello World 찍기 # Step에 이름 붙이는 기능
run: echo "Hello World" # 실행시킬 명령어 작성
- name: 여러 명령어 문장 작성하기
run: |
echo "Good"
echo "Morning"
- name: Github Actions 자체에 저장되어 있는 변수 사용해보기
run: |
echo $GITHUB_SHA
echo $GITHUB_REPOSITORY
- name: Github Actions Secret 변수 사용해보기
run: |
echo ${{ secrets.MY_NAME }}
echo ${{ secrets.MY_HOBBY }}2. 프론트엔드 프로젝트 구조에 CI/CD 적용 🎯
아래와 같은 CI/CD 흐름을 적용할 생각입니다.
Github Actions가 push를 통해 트리거 되어, 1) 빌드 파일을 S3에 전달하여 업로드하고, 2) 캐시 무효화 명령을 내리는 것까지 적용해 보겠습니다.
추가적으로, 이번 글에서는 S3와 CloudFront로 SPA를 배포하는 과정은 다루지 않겠습니다. 아래의 멋진 글을 참고해 주세요. 저도 아래 글을 읽고 배포에 성공한 바 있습니다.
reference: https://hojun-dev.tistory.com/entry/AWS-S3-CloudFront%EB%A1%9C-SPA-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0

루트에서 .github/workflows/deploy.yml를 생성하고 아래의 코드를 작성합니다.
name: Deploy To S3
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
# 1️⃣ 레포지토리 체크아웃
- name: Checkout Repository
uses: actions/checkout@v4
# 2️⃣ AWS Credentials 설정
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-region: ap-northeast-2
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
# 3️⃣ 프로젝트 빌드 (client 폴더 기준)
- name: Build Project
run: |
yarn install
yarn build
working-directory: ./client
# 4️⃣ S3에 업로드 (dist 폴더 기준)
- name: Upload to S3
run: |
aws s3 sync ./dist/ s3://{s3 버킷 이름 입력} --delete
working-directory: ./client
# 5️⃣ CloudFront 캐시 무효화
- name: Invalidate CloudFront Cache
run: |
aws cloudfront create-invalidation --distribution-id {CloudFront ID 입력} --paths "/*"그다음 IAM에서 권한을 설정한 후, Access Key와 Access Secret Key를 발급받습니다.




위 과정을 거친 뒤(액세스 키 만들기 포함) Access Key와 Access Secret Key를 아래 화면에서 등록합니다. 본인의 프로젝트 레포지토리-설정으로 들어가면 확인할 수 있습니다.

이제 client 폴더에서 다음 명령어를 입력합니다.
git add .
git commit -m "프론트엔드 CI/CD 성공"
git push origin mainyml 파일은 루트에 있으니 루트에서 위와 같은 명령어를 실행해야 합니다. 주의하시길 바랍니다.

귀찮음 해결!
다음에는 백엔드(NestJS) 프로젝트에 CI/CD를 적용해 보도록 하겠습니다. 배울 것이 너무 많은 게 개발의 단점이지만, 동시에 개발의 장점이기도 한 것 같습니다.
More to read
프론트엔드와 백엔드 사이
HTTP 상태 코드는 프론트엔드에서 백엔드로 보냈던 요청의 수행 결과를 의미하는 일종의 약속이며, API를 구성하는 핵심 요소 중 하나입니다. 상태 코드와 관련하여, 백엔드는 잘 모르는 프론트엔드의 슬픈 사정이 있습니다.아래는 요청이 실패했음에도, 백엔드에서 상태 코드
JWT토큰 관리 방식 톺아보기
0. 들어가며 🎯 서비스에 접근하려는 사용자가 누구인지 확인하는 과정을 사용자 인증이라고 합니다. 인증된 사용자에게 주어진 권한을 확인하는 작업은 인가라고 부릅니다. 이번 글에서는 인가는 다루지 않습니다. 사용자 인증에는 많은 방식이 있지만, 오늘은 세션 인증 방
A2AA2A / MCP 멀티 에이전트 오케스트레이션
0. 들어가며 ✍️ Google for Developers에, 레스토랑 공급망 시나리오로 엮은 6대 프로토콜(MCP, A2A, UCP, AP2, A2UI, AG-UI)에 대한 가이드가 게시된 이후, MCP와 A2A부터 구현해 보는 것이 좋을 것 같다는 생각이 들었습니