AWS RDS와 GitHub Actions 트리거 완전 정리

AWS 클라우드 환경에서 데이터베이스를 어떻게 운영할지, CI/CD 파이프라인은 어떤 조건으로 실행할지 — 실무에서 자주 마주치는 두 가지 주제를 정리했다.

---

1. AWS RDS란?

RDS(Relational Database Service)는 AWS가 제공하는 관리형 관계형 데이터베이스 서비스다. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Amazon Aurora를 지원하며, 데이터베이스 운영에 필요한 인프라 관리를 AWS가 대신 처리해준다.

---

2. RDS vs EC2 직접 운영 — 무엇이 다른가?

EC2에 DB를 직접 설치하면 애플리케이션 서버처럼 우리가 OS까지 직접 관리해야 한다. RDS는 이 운영 레이어를 AWS에 위임하는 구조다.

항목	RDS	EC2 직접 운영
OS 접근	불가	가능 (root)
패치·업그레이드	AWS 자동화	직접 수행
백업	자동 설정	cron·스크립트 직접 구성
HA(고가용성) 구성	Multi-AZ 옵션 선택	Replication + HAProxy 등 직접 구성
비용	상대적으로 높음	인스턴스 비용만 (운영 인건비 별도)
커스터마이징	제한적	완전 자유

---

3. RDS의 주요 이점

자동 백업과 특정 시점 복구 (PITR)

백업이 기본으로 활성화되며, 최대 35일 보존 기간 설정이 가능하다. 특정 시점 복구(Point-in-Time Recovery)를 통해 장애 발생 전 시점으로 되돌릴 수 있다.

Multi-AZ 고가용성

Multi-AZ를 선택하면 예비 인스턴스가 다른 가용 영역(AZ)에 자동으로 유지된다. 주 인스턴스에 장애가 발생하면 DNS 페일오버가 약 1~2분 내에 이루어져 서비스 중단을 최소화한다.

Read Replica

읽기 전용 복제본을 수 클릭으로 추가할 수 있다. 조회 트래픽이 많은 서비스에서 읽기 부하를 분산시키는 데 효과적이다.

보안·인프라 기능 통합 관리

스토리지 자동 확장(Auto Scaling), 저장 데이터 암호화, IAM 인증, VPC 통합이 관리형으로 제공되어 별도 설정 없이 보안 기준을 충족하기 쉽다.

---

4. RDS가 적합하지 않은 상황

RDS가 항상 정답은 아니다. 다음 상황에서는 EC2 직접 운영이나 다른 선택지를 고려할 필요가 있다.

OS 레벨 접근이 필요할 때
커스텀 스토리지 엔진, 특수 플러그인, pg_cron 같은 확장 기능을 직접 컴파일·설치해야 한다면 RDS의 OS 접근 제한이 걸린다.

지원하지 않는 DB 엔진을 사용할 때
RDS는 지원 엔진이 정해져 있다. Redis, Cassandra, MongoDB 같은 비지원 DB는 ElastiCache, DocumentDB 등 별도 서비스를 써야 한다.

비용이 우선순위일 때
트래픽이 예측 가능하고 내부에 DBA 역량이 충분하다면, EC2 직접 운영이 총 비용 측면에서 유리할 수 있다.

초저지연 고성능 워크로드
RDS 관리 레이어의 오버헤드가 극한 성능을 요구하는 환경에서 병목이 될 수 있다.

---

5. GitHub Actions 워크플로우 트리거

GitHub Actions의 워크플로우는 on: 키 하위에서 트리거를 정의한다. 크게 이벤트 기반, 스케줄 기반, 수동 실행 세 범주로 나뉜다.

---

push / pull_request — 가장 기본적인 트리거

push는 커밋이 원격 브랜치에 올라갈 때, pull_request는 PR 생성·업데이트·병합 시 발동한다. branches 필터와 조합해 특정 브랜치에만 반응하도록 좁힐 수 있다.

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

적합한 시나리오: PR이 열릴 때마다 자동으로 단위·통합 테스트를 실행하고, main 브랜치에 병합될 때 스테이징 배포를 트리거하는 기본 CI/CD 구조.

---

workflow_dispatch — 수동 실행

Actions 탭에서 직접 실행하거나 API로 호출할 수 있다. inputs를 정의하면 실행 시 파라미터를 넘길 수 있다.

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Deploy target'
        required: true
        default: 'staging'

적합한 시나리오: 특정 환경(staging/prod)을 선택해 수동 배포하거나, 긴급 롤백이 필요할 때 즉시 트리거하는 용도.

---

schedule — 정기 실행

cron 표현식으로 정기 실행 시점을 지정한다. GitHub Actions의 cron은 UTC 기준이며, 러너 가용 상황에 따라 수 분 지연될 수 있다.

on:
  schedule:
    - cron: '0 2 * * *'  # 매일 새벽 2시 (UTC)

적합한 시나리오: 야간 전체 회귀 테스트(nightly build), 주기적인 의존성 취약점 스캔, 정기 데이터 동기화 작업.

---

release — GitHub Release 게시 시

GitHub Release가 게시될 때 발동한다. types: [published]로 좁히면 정식 릴리즈 시점에만 반응한다.

on:
  release:
    types: [published]

적합한 시나리오: Docker 이미지에 버전 태그를 붙여 ECR에 푸시하거나, npm·GitHub Packages에 패키지를 배포하는 릴리즈 자동화.

---

workflow_call — 재사용 가능한 워크플로우

다른 워크플로우에서 현재 워크플로우를 모듈처럼 호출할 수 있게 한다.

# 재사용 가능한 공통 워크플로우 정의
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string

적합한 시나리오: 공통 테스트 워크플로우를 하나 정의해두고 여러 레포에서 호출하는 방식. 모노레포나 멀티 레포 환경에서 중복 없이 워크플로우를 관리할 때 유용하다.

---

pull_request_target — 포크 PR 대응

pull_request와 달리 포크된 외부 PR에서도 시크릿에 접근할 수 있다.

적합한 시나리오: 외부 기여자의 PR에 자동 라벨을 붙이거나 봇 코멘트를 다는 작업. 단, 시크릿이 노출될 수 있으므로 신뢰할 수 없는 코드를 직접 실행하는 스텝은 반드시 분리해야 한다.

---

6. 트리거 조합 전략 — 실전 구성 예시

일반적인 백엔드 프로젝트에서의 기본 골격은 다음과 같다.

트리거	역할
pull_request	단위·통합 테스트 자동 실행
push (main)	스테이징 자동 배포
release	프로덕션 배포
schedule	야간 보안 스캔·회귀 테스트
workflow_dispatch	긴급 재배포·롤백 경로

이 다섯 가지 트리거를 조합하면 코드 변경부터 프로덕션 배포까지 자동화된 안정적인 CI/CD 파이프라인을 구성할 수 있다.

---

정리하면, RDS는 운영 부담을 줄이고 싶을 때 강력한 선택지지만 커스터마이징 제약을 고려해야 하고, GitHub Actions 트리거는 상황에 맞는 조합을 선택하는 것이 핵심이다.