[AWS 배포] : Github Actions release.yml 필요성

사실 GitHub Actions의 release.yml이 AWS 배포의 핵심이라고 보면 된다. 지금까지는 개발자가 직접 Docker를 빌드하고 AWS에 올렸다면, release.yml을 만들면 git push만 해도 자동으로 AWS까지 배포된다.

내가 ERP 프로젝트라면 이런 구조로 만든다.

개발자
   │
   ├── git push
   │
   ▼
GitHub
   │
   ▼
GitHub Actions (release.yml)
   │
   ├── 테스트
   ├── Docker Build
   ├── Docker Push(ECR)
   ├── Migration
   ├── ECS Deploy
   ├── Health Check
   └── Slack/Discord 알림

---

1. release.yml이 하는 일

예를 들어 main 브랜치에 머지되면

git push origin main

이 한 줄 때문에

1. 코드 다운로드

↓

2. Python 설치

↓

3. Node 설치

↓

4. 테스트 실행

↓

5. Docker 이미지 생성

↓

6. AWS ECR 업로드

↓

7. ECS 새 버전 생성

↓

8. Migration 실행

↓

9. ECS 교체

↓

10. Health Check

↓

11. 완료 알림

전부 자동이다.

---

2. 왜 필요한가?

예전 방식은

docker build

docker push

ecs update-service

migration

health check

전부 사람이 한다.

그러다

• migration 빼먹음
• docker 안올림
• backend만 올림
• frontend 안올림

같은 실수가 엄청 많다.

---

GitHub Actions는

Push

↓

자동

↓

항상 같은 절차

로 진행된다.

그래서 사람이 실수할 일이 거의 없다.

---

3. release.yml 내부 구조

보통 이렇게 나눈다.

.github/

    workflows/

        ci.yml
        release.yml

---

ci.yml

PR이 올라오면

테스트만

한다.

pytest

eslint

typescript

lint

build

여기서 실패하면

Merge가 안된다.

---

release.yml

main에 Merge되면

실제 AWS 배포

를 담당한다.

---

4. release.yml 순서

내가 가장 추천하는 순서는

Checkout

↓

Backend Build

↓

Frontend Build

↓

Docker Image 생성

↓

ECR Push

↓

Migration

↓

Deploy

↓

Health Check

↓

Notification

이다.

---

5. Docker Build

예를 들어

Backend

docker build \
-t backend:commitSHA

Frontend

docker build \
-t frontend:commitSHA

를 만든다.

---

6. ECR 업로드

AWS에는 Docker Registry가 있다.

ECR

예를 들어

erp/backend

erp/frontend

라는 저장소를 만든다.

그러면

backend

↓

ECR

로 올라간다.

---

7. 왜 latest를 안쓰는가?

많은 사람들이

latest

만 쓴다.

하지만

latest

는 위험하다.

대신

backend

a8f7c3

frontend

a8f7c3

처럼 Git Commit SHA를 사용한다.

예를 들면

backend

2b4fd31

frontend

2b4fd31

이렇게.

그러면

2b4fd31

이 무엇인지

Git에서 바로 찾을 수 있다.

---

8. ECS Deploy

새 이미지가 올라가면

GitHub Actions가

ECS Update Service

를 호출한다.

그러면

기존 Task

↓

새 Task 생성

↓

Health Check

↓

정상

↓

기존 종료

가 자동으로 된다.

서비스가 거의 끊기지 않는다.

---

9. Migration

여기가 제일 중요하다.

많은 회사가

docker run

python manage.py migrate

를 서버에서 직접 실행한다.

그런데 ECS에서는

Migration Task

를 하나 따로 만든다.

Task

↓

python manage.py migrate

↓

성공

↓

Deploy

순서이다.

실패하면

Deploy 안함

이 된다.

---

10. Health Check

배포가 끝나도 끝난 것이 아니다.

자동으로

GET /health/live

↓

200

GET /health/ready

↓

200

GET /login

↓

200

를 확인한다.

실패하면

Rollback

한다.

---

11. Slack 알림

예를 들어

ERP Production

Version

2b4fd31

Deploy Success

Time

2m 11s

같은 메시지가 자동으로 온다.

실패하면

Deploy Failed

Migration Error

가 바로 온다.

---

12. 우리 ERP 프로젝트에서 추천하는 release.yml

현재 구성하려는 ERP(Django + React + Docker + ECS)라면 다음과 같은 흐름이 가장 안정적이다.

main Merge
      │
      ▼
GitHub Actions
      │
      ├─ 코드 Checkout
      ├─ Python/Node 의존성 설치
      ├─ pytest + eslint + build
      ├─ Backend Docker Build
      ├─ Frontend Docker Build
      ├─ ECR Push
      ├─ ECS Migration Task 실행
      ├─ ECS Service 업데이트
      ├─ Health Check
      ├─ 실패 시 자동 Rollback
      └─ Slack/Discord 알림

이 구성을 해두면 개발자는 대부분의 경우 코드만 main에 머지하면 배포가 끝나는 수준의 자동화가 가능하다.

---

내가 추천하는 다음 단계는 GitHub Actions → AWS(ECR, ECS, OIDC)까지 실제 사용할 수 있는 release.yml을 처음부터 끝까지 작성하고, 각 단계가 어떤 역할을 하는지 상세히 설명하는 것이다. 이렇게 만들어두면 그대로 네 ERP 프로젝트에 적용할 수 있다.

이 부분은 AWS로 처음 넘어가는 사람들이 가장 헷갈리는 부분이야.

"현재는 Docker Compose로는 잘 돌아가는데, 왜 ECS에서는 추가 작업이 필요한가?"

결론부터 말하면,

Docker Compose는 "한 대의 서버"를 관리하는 도구이고, ECS는 "AWS가 여러 서버를 관리하는 플랫폼"이기 때문에 사용하는 방식이 완전히 다르다.