2026-05-18

1. AWS RDS를 활용하는 주요 이점과 EC2에 직접 데이터베이스를 설치하여 운영하는 것과 비교했을 때의 차별점에 대해 설명해주세요. 그리고 RDS를 사용하는 것이 적합하지 않을 수 있는 상황도 함께 언급해주세요.

AWS RDS(Relational Database Service)란

AWS에서 제공하는 관리형 관계형 데이터베이스 서비스이다.
개발자는 데이터 저장 및 애플리케이션 개발에 집중하고, 데이터베이스 운영 및 관리 작업은 AWS가 대신 수행한다.

지원하는 데이터베이스 종류:

PostgreSQL
MySQL
MariaDB
Oracle
SQL Server 등

즉, 직접 DB 서버를 설치하고 관리하는 방식이 아니라 AWS가 관리해주는 데이터베이스 서비스라고 볼 수 있다.

RDS의 주요 이점

1) 운영 자동화

RDS는 데이터베이스 운영에 필요한 반복 작업을 자동화한다.

예:

패치 및 버전 업데이트
모니터링
장애 복구
유지보수 작업

직접 EC2에 DB를 설치하면 개발자가 이러한 작업을 직접 수행해야 하지만, RDS는 AWS가 대부분 자동 처리해준다.

즉:

개발자는 서버 관리보다 애플리케이션 개발에 더 집중할 수 있다.

2) 자동 백업 및 복구

RDS는 자동 백업 기능을 제공하며, 특정 시점(Point-In-Time Recovery)으로 복구할 수 있다.

반면 EC2에 직접 설치하는 경우:

백업 스크립트 작성
백업 스케줄링
복구 관리

등을 직접 구성해야 한다.

따라서 운영 부담 측면에서 RDS가 훨씬 편리하다.

3) 고가용성(Multi-AZ)

RDS는 Multi-AZ 기능을 통해 장애 발생 시 자동으로 대기 인스턴스로 전환(Failover)할 수 있다.

즉:

서버 장애 대응 자동화
다운타임 최소화
안정성 향상

이 가능하다.

4) 확장성

서비스 규모가 커질 경우:

CPU
메모리
스토리지

등을 비교적 쉽게 확장할 수 있다.

즉, 트래픽 증가에 유연하게 대응할 수 있다.

5) AWS 서비스와의 연동

RDS는 AWS IAM, CloudWatch, 보안 그룹 등과 쉽게 연동된다.

따라서:

접근 제어
모니터링
보안 관리

를 통합적으로 운영할 수 있다.

EC2에 직접 데이터베이스를 설치하는 방식과의 차이점

EC2 직접 설치 방식

EC2는 단순한 가상 서버이므로:

DB 설치
환경 설정
보안 구성
백업
장애 대응

등을 모두 직접 관리해야 한다.

즉:

자유도는 높지만 운영 부담도 매우 크다.

핵심 차이점 비교

항목	RDS	EC2 직접 설치
운영 관리	AWS 자동 관리	직접 관리
백업	자동 제공	직접 구성
장애 대응	자동 Failover	수동 대응
유지보수	편리함	운영 부담 큼
자유도	제한적	높음
운영 난이도	낮음	높음

RDS가 적합하지 않을 수 있는 상황

1) 매우 세부적인 DB 설정이 필요한 경우

RDS는 관리형 서비스이므로 일부 고급 설정에 제한이 존재한다.

예:

커널 수준 설정
특수 플러그인 사용
저수준 튜닝

따라서 완전한 제어가 필요한 환경에서는 제약이 될 수 있다.

2) 비용 최적화가 중요한 소규모 프로젝트

작은 프로젝트에서는 EC2에 직접 DB를 설치하는 것이 비용 측면에서 더 저렴할 수 있다.

즉:

편의성과 자동화를 얻는 대신 추가 비용이 발생할 수 있다.

3) 완전한 서버 제어가 필요한 환경

기업 정책 또는 특수한 인프라 환경에서는:

커스텀 네트워크
특정 보안 정책
특수 운영 방식

등 때문에 직접 설치 방식을 선택하기도 한다.

정리

RDS는 데이터베이스 운영 자동화와 관리 편의성을 제공하는 AWS의 관리형 서비스이다.
반면 EC2 직접 설치 방식은 자유도는 높지만 운영 부담이 크다.
일반적인 웹 서비스에서는 RDS가 효율적이지만, 세부 튜닝이나 완전한 서버 제어가 필요한 환경에서는 EC2 직접 설치 방식이 더 적합할 수 있다.

2. GitHub Actions 워크플로우에서 사용할 수 있는 다양한 트리거(Trigger) 유형을 설명하고, 각 트리거 유형이 적합한 CI/CD 시나리오에 대해 설명하세요.

GitHub Actions의 Trigger란

Trigger는 GitHub Actions 워크플로우를 언제 실행할지 결정하는 이벤트 조건이다.

즉:

특정 이벤트가 발생하면 자동으로 CI/CD 작업을 수행한다.

주요 Trigger 유형과 활용 사례

1) push

특정 브랜치에 코드가 push될 때 실행된다.

on:
  push:
    branches:
      - main

사용 사례

코드 push 시 자동 빌드
테스트 자동 실행
자동 배포

즉, 가장 기본적인 CI 자동화 방식이다.

2) pull_request

PR(Pull Request)이 생성되거나 수정될 때 실행된다.

on:
  pull_request:
    branches:
      - main

사용 사례

PR 코드 검증
테스트 자동 수행
병합 전 품질 확인

즉:

main 브랜치 병합 전에 코드 안정성을 검증하는 용도로 사용된다.

3) workflow_dispatch

사용자가 직접 버튼을 눌러 수동 실행할 수 있는 트리거이다.

on:
  workflow_dispatch:

사용 사례

운영 배포
특정 환경 테스트
관리자 승인 후 실행

즉:

자동 실행이 아니라 사람이 직접 실행 시점을 제어할 수 있다.

4) schedule

정해진 시간에 주기적으로 실행된다.

on:
  schedule:
    - cron: '0 0 * * *'

사용 사례

배치 작업
로그 정리
정기 테스트
데이터 백업

즉:

시간 기반 자동화 작업에 적합하다.

5) release

GitHub Release 생성 시 실행된다.

on:
  release:
    types: [published]

사용 사례

릴리즈 자동 배포
패키지 업로드
운영 서버 반영

즉:

공식 버전 배포 자동화에 사용된다.

6) workflow_run

다른 워크플로우 실행 완료 후 연계 실행된다.

사용 사례

Build Workflow 실행
테스트 성공
Deploy Workflow 실행

즉:

여러 단계로 구성된 CI/CD 파이프라인 구성에 사용된다.

CI/CD 관점에서의 의미

CI(Continuous Integration)

주로 사용하는 Trigger:

push
pull_request

목적:

코드 통합 자동화
테스트 자동화
품질 검증

CD(Continuous Deployment / Delivery)

주로 사용하는 Trigger:

workflow_dispatch
release
workflow_run

목적:

자동 배포
운영 반영 자동화

정리

GitHub Actions의 Trigger는 워크플로우 실행 시점을 결정하는 이벤트 조건이다.
push와 pull_request는 주로 CI 과정에서 사용되며, workflow_dispatch, release, schedule 등은 배포 및 운영 자동화에 자주 활용된다.
적절한 Trigger 선택은 안정적이고 효율적인 CI/CD 파이프라인 구성에 매우 중요하다.