AWS RDS 관리형 데이터베이스 완벽 가이드

직접 데이터베이스를 설치하고 관리하는 것이 부담스러운 초급 개발자를 위한 RDS 가이드입니다. 데이터베이스 엔진 선택부터 인스턴스 생성, 보안 설정, 백업까지 실무에 필요한 모든 내용을 다룹니다.

1. RDS(Relational Database Service)란

첫 프로젝트를 맡은 김개발 씨는 고민에 빠졌습니다. 팀장님이 "데이터베이스는 RDS로 구축하세요"라고 말씀하셨는데, RDS가 정확히 무엇인지 알 수 없었습니다.

직접 MySQL을 설치하는 것과 뭐가 다를까요?

RDS는 AWS에서 제공하는 관리형 데이터베이스 서비스입니다. 마치 호텔에 묵는 것처럼, 데이터베이스 운영에 필요한 복잡한 작업들을 AWS가 대신 처리해줍니다.

개발자는 데이터베이스 사용에만 집중할 수 있습니다.

다음 코드를 살펴봅시다.

// Node.js에서 RDS MySQL 연결 예제
const mysql = require('mysql2/promise');

const connection = await mysql.createConnection({
  host: 'mydb.c9akciq32.ap-northeast-2.rds.amazonaws.com',
  user: 'admin',
  password: process.env.DB_PASSWORD,
  database: 'productdb',
  // RDS 엔드포인트로 연결 - EC2에 직접 설치한 것과 동일하게 사용
  port: 3306
});

// 일반적인 쿼리 실행
const [rows] = await connection.execute(
  'SELECT * FROM users WHERE id = ?',
  [userId]
);

김개발 씨는 이전 회사에서 데이터베이스를 직접 설치해본 경험이 있습니다. EC2 인스턴스에 MySQL을 설치하고, 설정 파일을 수정하고, 보안 패치를 적용하고, 백업 스크립트를 작성하는 일련의 과정이 꽤나 복잡했습니다.

특히 주말에 갑자기 데이터베이스 서버가 다운되어 급하게 복구했던 기억이 생생합니다. 그때 선배 개발자가 이런 말을 했습니다.

"RDS를 썼으면 이런 일은 없었을 텐데." RDS란 무엇일까요? RDS는 Relational Database Service의 약자로, AWS에서 제공하는 관리형 관계형 데이터베이스 서비스입니다. 쉽게 비유하자면, 직접 집을 관리하는 것과 호텔에 묵는 것의 차이와 같습니다.

집을 직접 관리하면 청소, 수리, 전기·수도 관리를 모두 스스로 해야 합니다. 하지만 호텔에 묵으면 직원들이 이 모든 것을 대신 처리해줍니다.

투숙객은 편안하게 쉬는 것에만 집중할 수 있습니다. RDS도 마찬가지입니다.

데이터베이스 서버 관리, 백업, 패치, 복제, 장애 복구 등 복잡한 운영 작업을 AWS가 자동으로 처리해줍니다. 왜 RDS가 필요할까요? 데이터베이스를 EC2에 직접 설치하면 많은 책임이 따릅니다.

첫째, 운영체제 패치를 직접 관리해야 합니다. 보안 취약점이 발견되면 밤낮없이 패치를 적용해야 합니다.

둘째, 백업 시스템을 직접 구축해야 합니다. 크론 작업으로 백업 스크립트를 돌리고, 백업 파일이 제대로 생성되었는지 확인하고, S3에 저장하는 일련의 과정이 필요합니다.

셋째, 장애 대응입니다. 디스크가 가득 차거나, 메모리가 부족하거나, 네트워크 문제가 생기면 직접 해결해야 합니다.

새벽 3시에 알람이 울려도 일어나서 서버를 재시작해야 합니다. RDS의 핵심 가치 RDS를 사용하면 이 모든 부담에서 벗어날 수 있습니다.

AWS가 자동 백업을 수행합니다. 매일 정해진 시간에 스냅샷을 생성하고, 트랜잭션 로그를 저장합니다.

장애가 발생해도 특정 시점으로 복구할 수 있습니다. 자동 패치도 제공됩니다.

설정한 유지보수 시간에 자동으로 패치가 적용됩니다. 보안 취약점 걱정을 덜 수 있습니다.

Multi-AZ 배포로 고가용성을 확보할 수 있습니다. 주 데이터베이스에 장애가 발생하면 자동으로 대기 데이터베이스로 전환됩니다.

서비스 중단 시간을 최소화할 수 있습니다. 코드에서의 사용법 위의 코드를 보면 일반적인 MySQL 연결과 크게 다르지 않습니다.

host 부분에 RDS 엔드포인트 주소를 입력합니다. 이 주소는 RDS 인스턴스를 생성하면 자동으로 할당됩니다.

나머지는 일반적인 MySQL 연결 방식과 동일합니다. 개발자 입장에서는 MySQL을 사용하는 것과 똑같이 코드를 작성하면 됩니다.

하지만 뒷단에서는 AWS가 안정적인 운영을 보장해줍니다. 실무에서의 활용 스타트업에서 서비스를 런칭한다고 가정해봅시다.

초기에는 트래픽이 적어서 작은 인스턴스로 시작합니다. 서비스가 성장하면서 사용자가 늘어나면 인스턴스 타입을 변경하여 스케일업할 수 있습니다.

읽기 트래픽이 많아지면 읽기 전용 복제본을 추가하여 부하를 분산시킬 수 있습니다. 이 모든 작업이 콘솔 클릭 몇 번으로 가능합니다.

직접 서버를 증설하고 복제를 설정하는 것보다 훨씬 간단합니다. 주의사항 RDS가 만능은 아닙니다.

비용이 EC2에 직접 설치하는 것보다 높습니다. 관리 편의성을 얻는 대신 추가 비용을 지불하는 것입니다.

또한 루트 접근 권한이 없습니다. 운영체제 레벨의 커스터마이징이 필요하다면 RDS는 적합하지 않습니다.

하지만 대부분의 경우 RDS의 장점이 단점을 훨씬 상회합니다. 정리 김개발 씨는 팀장님께 RDS에 대해 질문했습니다.

"아, RDS는 우리가 데이터베이스 관리에 신경 쓰지 않고 비즈니스 로직 개발에 집중할 수 있게 해주는 서비스야. 특히 우리처럼 인력이 부족한 팀에는 필수지." RDS를 사용하면 안정적인 데이터베이스 운영을 AWS에 맡기고, 여러분은 더 중요한 기능 개발에 집중할 수 있습니다.

실전 팁

💡 - RDS는 소규모 팀이나 스타트업에 특히 유용합니다

비용과 편의성을 비교하여 도입을 결정하세요
프로덕션 환경에서는 Multi-AZ 옵션을 반드시 활성화하세요

2. RDS vs 직접 설치 DB 비교

김개발 씨는 견적을 내보고 깜짝 놀랐습니다. RDS가 EC2에 직접 MySQL을 설치하는 것보다 두 배 가까이 비쌌습니다.

"이렇게 비싼데도 RDS를 써야 할까요?" 박시니어 씨가 웃으며 대답했습니다.

RDS는 비용이 높지만 운영 부담을 크게 줄여줍니다. 직접 설치는 초기 비용은 저렴하지만 인건비와 장애 리스크가 숨어 있습니다.

각 방식의 장단점을 이해하고 상황에 맞게 선택해야 합니다.

다음 코드를 살펴봅시다.

// EC2 직접 설치 - 연결 코드는 동일
const directConnection = await mysql.createConnection({
  host: 'ec2-13-124-123-456.compute.amazonaws.com',
  user: 'root',
  password: process.env.DB_PASSWORD,
  database: 'productdb',
  // 직접 관리: OS 패치, MySQL 버전 업그레이드, 백업 스크립트 모두 직접 작성
});

// RDS - 연결 코드는 동일하지만 뒷단 관리는 AWS가 담당
const rdsConnection = await mysql.createConnection({
  host: 'mydb.c9akciq32.ap-northeast-2.rds.amazonaws.com',
  user: 'admin',
  password: process.env.DB_PASSWORD,
  database: 'productdb',
  // AWS 관리: 자동 백업, 자동 패치, Multi-AZ 장애 조치
});

박시니어 씨는 과거 이야기를 꺼냈습니다. "3년 전에 우리 팀이 EC2에 PostgreSQL을 직접 설치해서 운영했었어.

처음에는 비용 절감이 좋아 보였지." 하지만 현실은 달랐습니다. 디스크 용량을 모니터링하고, 슬로우 쿼리를 분석하고, 인덱스를 최적화하고, 백업이 제대로 되는지 확인하는 일에 많은 시간을 쏟아야 했습니다.

비용 비교의 함정 직접 설치가 저렴해 보이는 이유는 겉으로 드러나는 비용만 보기 때문입니다. EC2 t3.medium 인스턴스에 MySQL을 설치하면 월 30달러 정도입니다.

같은 사양의 RDS는 60달러 정도입니다. 단순 비교하면 RDS가 두 배 비쌉니다.

하지만 숨은 비용을 고려해야 합니다. 개발자가 데이터베이스 관리에 쓰는 시간은 어떻게 계산할까요?

한 달에 10시간을 데이터베이스 관리에 쓴다면, 시급 5만원 기준으로 50만원의 인건비가 발생합니다. 게다가 장애 리스크도 있습니다.

백업을 깜빡해서 데이터를 잃어버리거나, 디스크가 가득 차서 서비스가 중단되면 그 손실은 훨씬 큽니다. 운영 부담의 차이 직접 설치하면 모든 책임이 개발자에게 있습니다.

MySQL 5.7에서 8.0으로 업그레이드해야 한다면 어떻게 해야 할까요? 먼저 테스트 환경에서 호환성을 검증해야 합니다.

그다음 서비스 중단 시간을 공지하고, 백업을 받고, 업그레이드를 진행하고, 롤백 계획도 세워야 합니다. RDS는 이 과정이 훨씬 간단합니다.

유지보수 시간을 설정하고 업그레이드 버전을 선택하면 자동으로 진행됩니다. 문제가 생기면 이전 스냅샷으로 롤백할 수 있습니다.

백업과 복구 직접 설치 환경에서 백업을 구현해봅시다. 크론 작업으로 매일 새벽 2시에 mysqldump를 실행합니다.

덤프 파일을 압축하고 S3에 업로드합니다. 오래된 백업은 삭제하는 스크립트도 작성해야 합니다.

백업이 실패했을 때 알림을 받는 모니터링도 필요합니다. RDS는 자동 백업이 기본 제공됩니다.

보관 기간을 설정하면 매일 자동으로 스냅샷을 생성합니다. 특정 시점으로 복구하는 Point-in-Time Recovery도 가능합니다.

실수로 테이블을 삭제했다면 5분 전 상태로 되돌릴 수 있습니다. 고가용성 구성 직접 설치 환경에서 고가용성을 구현하려면 어떻게 해야 할까요?

마스터-슬레이브 복제를 설정하고, 헬스 체크를 구현하고, 장애 발생 시 자동으로 슬레이브를 마스터로 승격시키는 스크립트를 작성해야 합니다. 이 모든 것이 복잡하고 에러가 발생하기 쉽습니다.

RDS의 Multi-AZ 배포는 클릭 한 번으로 활성화됩니다. 다른 가용 영역에 대기 인스턴스가 생성되고, 데이터가 자동으로 동기화됩니다.

주 인스턴스에 장애가 발생하면 1~2분 안에 자동으로 대기 인스턴스로 전환됩니다. 언제 직접 설치를 선택할까? 그렇다면 직접 설치는 언제 적합할까요?

첫째, 매우 특수한 커스터마이징이 필요한 경우입니다. 운영체제 레벨의 튜닝이나 특정 플러그인 설치가 필요하다면 직접 설치가 유리합니다.

둘째, 비용이 절대적으로 중요한 경우입니다. 초기 스타트업이나 개인 프로젝트에서는 직접 설치로 시작할 수 있습니다.

다만 성장하면서 RDS로 마이그레이션하는 것을 고려해야 합니다. 셋째, 숙련된 DBA가 있는 경우입니다.

데이터베이스 관리 전문가가 있다면 직접 설치로 더 세밀한 최적화가 가능합니다. 실무 결정 기준 박시니어 씨는 이렇게 조언했습니다.

"우리 팀처럼 백엔드 개발자 3명이 전부라면 RDS가 답이야. DBA 채용하는 것보다 훨씬 저렴하고, 우리는 비즈니스 로직 개발에 집중할 수 있어." 실제로 많은 스타트업이 초기에는 비용 때문에 직접 설치를 선택했다가, 운영 부담을 견디지 못하고 RDS로 전환합니다.

정리 김개발 씨는 고개를 끄덕였습니다. "그러니까 단순히 서버 비용만 비교하면 안 되는 거네요.

시간과 안정성까지 고려해야 하는군요." 비용은 중요하지만, 그것이 전부는 아닙니다. 여러분의 팀 규모, 전문성, 서비스 요구사항을 종합적으로 고려하여 선택하세요.

실전 팁

💡 - 팀 규모가 작다면 RDS가 유리합니다

초기 단계에서는 직접 설치로 시작해도 괜찮지만, 성장을 고려하세요
숨은 비용(인건비, 장애 리스크)을 반드시 계산하세요

3. 데이터베이스 엔진 선택 (MySQL, PostgreSQL 등)

RDS를 사용하기로 결정한 김개발 씨는 또 다른 선택의 기로에 섰습니다. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 중에서 무엇을 선택해야 할까요?

각 데이터베이스마다 특징이 다르다는데, 어떤 기준으로 선택해야 할지 막막했습니다.

RDS는 6가지 데이터베이스 엔진을 지원합니다. MySQL과 PostgreSQL이 가장 널리 쓰이며, 각각 단순함과 고급 기능이라는 강점이 있습니다.

프로젝트 요구사항과 팀의 경험을 고려하여 선택해야 합니다.

다음 코드를 살펴봅시다.

// MySQL 연결 - 가장 대중적, 빠른 읽기 성능
const mysqlConn = await mysql.createConnection({
  host: 'mysql-instance.rds.amazonaws.com',
  user: 'admin',
  password: process.env.DB_PASSWORD,
  database: 'ecommerce',
  // 간단한 웹 서비스, 읽기 중심 워크로드에 적합
});

// PostgreSQL 연결 - 고급 기능, JSONB, 복잡한 쿼리
const { Client } = require('pg');
const pgConn = new Client({
  host: 'postgres-instance.rds.amazonaws.com',
  user: 'admin',
  password: process.env.DB_PASSWORD,
  database: 'analytics',
  // 복잡한 분석, JSON 데이터, 트랜잭션 무결성 중요한 경우
  port: 5432
});
await pgConn.connect();

박시니어 씨가 화이트보드에 표를 그리며 설명을 시작했습니다. "데이터베이스 엔진을 선택하는 것은 프로젝트의 방향을 결정하는 중요한 결정이야." 한번 선택하면 나중에 바꾸기 어렵습니다.

스키마, 쿼리, ORM 설정 등 많은 부분이 데이터베이스 엔진과 연결되어 있기 때문입니다. MySQL - 대중적이고 검증된 선택 MySQL은 세계에서 가장 널리 쓰이는 오픈소스 데이터베이스입니다.

가장 큰 장점은 단순함입니다. 설치, 설정, 사용이 직관적입니다.

웹 개발자라면 누구나 한 번쯤 MySQL을 사용해봤을 것입니다. 그만큼 레퍼런스와 커뮤니티가 방대합니다.

읽기 성능이 뛰어납니다. 간단한 SELECT 쿼리가 많은 웹 서비스에 적합합니다.

WordPress, Drupal 같은 CMS도 MySQL을 기본으로 사용합니다. 복제와 샤딩이 성숙했습니다.

대규모 트래픽을 처리하는 많은 기업이 MySQL을 사용합니다. Facebook, YouTube, Twitter도 MySQL을 대규모로 운영한 경험이 있습니다.

PostgreSQL - 강력한 기능의 선택 PostgreSQL은 "세계에서 가장 진보된 오픈소스 데이터베이스"라고 불립니다. SQL 표준 준수가 뛰어납니다.

복잡한 조인, 서브쿼리, 윈도우 함수 등을 정확하게 지원합니다. 트랜잭션 무결성도 MySQL보다 엄격합니다.

고급 데이터 타입을 지원합니다. JSONB 타입으로 NoSQL처럼 JSON 데이터를 효율적으로 저장하고 쿼리할 수 있습니다.

배열, UUID, IP 주소 같은 특수한 타입도 기본 제공합니다. 확장성이 뛰어납니다.

PostGIS 확장으로 지리 정보를 처리할 수 있고, Full-Text Search로 검색 엔진을 구현할 수 있습니다. 언제 MySQL을 선택할까? 김개발 씨의 프로젝트는 전자상거래 웹사이트입니다.

상품 목록 조회, 장바구니 관리, 주문 내역 조회 같은 기능이 주를 이룹니다. 복잡한 분석 쿼리보다는 빠른 읽기 성능이 중요합니다.

팀원들이 모두 MySQL에 익숙합니다. 이런 경우 MySQL이 적합합니다.

검증된 안정성, 빠른 성능, 풍부한 레퍼런스를 활용할 수 있습니다. 또한 WordPress나 Laravel을 사용한다면 MySQL이 자연스러운 선택입니다.

프레임워크가 MySQL에 최적화되어 있기 때문입니다. 언제 PostgreSQL을 선택할까? 반면 데이터 분석 플랫폼을 개발한다고 가정해봅시다.

사용자 행동 데이터를 JSON으로 저장하고, 복잡한 집계 쿼리를 실행하고, 데이터 무결성이 절대적으로 중요합니다. 이런 경우 PostgreSQL이 더 적합합니다.

JSONB 타입으로 유연하게 데이터를 저장하면서도 인덱싱과 쿼리가 가능합니다. **CTE(Common Table Expressions)**와 윈도우 함수로 복잡한 분석을 SQL로 처리할 수 있습니다.

Django나 Rails를 사용한다면 PostgreSQL을 고려하세요. 이 프레임워크들은 PostgreSQL의 고급 기능을 잘 활용합니다.

MariaDB는 어떨까? MariaDB는 MySQL의 포크 버전입니다. MySQL 창시자가 만든 데이터베이스로, MySQL과 거의 호환되면서도 일부 개선된 기능을 제공합니다.

MySQL에서 MariaDB로 전환이 쉽습니다. 하지만 커뮤니티 크기는 MySQL이 더 큽니다.

특별한 이유가 없다면 MySQL을 선택하는 것이 안전합니다. 상용 데이터베이스는? Oracle과 SQL Server도 RDS에서 지원합니다.

기존에 온프레미스에서 Oracle을 사용하던 기업이 클라우드로 전환할 때 선택합니다. 하지만 라이선스 비용이 매우 비쌉니다.

새로운 프로젝트라면 오픈소스 데이터베이스(MySQL, PostgreSQL)를 선택하는 것이 합리적입니다. Aurora는 뭐가 다를까? AWS Aurora는 MySQL 및 PostgreSQL과 호환되는 AWS 자체 엔진입니다.

5배 빠른 성능과 자동 스케일링을 제공합니다. 하지만 비용이 일반 RDS보다 높고, AWS 종속성이 강해집니다.

초기에는 일반 RDS로 시작하고, 성능이 병목이 되면 Aurora로 마이그레이션하는 것을 추천합니다. 실무 결정 프로세스 박시니어 씨는 이렇게 정리했습니다.

"일반적인 웹 서비스라면 MySQL, 복잡한 데이터 처리와 분석이 필요하면 PostgreSQL을 선택해. 잘 모르겠으면 MySQL로 시작해도 괜찮아." 실제로 대부분의 웹 서비스는 MySQL로 충분합니다.

정말 PostgreSQL의 고급 기능이 필요한 경우가 아니라면 단순함을 선택하는 것이 현명합니다. 정리 김개발 씨는 자신의 프로젝트를 다시 살펴봤습니다.

일반적인 CRUD 중심의 웹 서비스이고, 팀원들이 MySQL에 익숙하니 MySQL을 선택하기로 했습니다. 데이터베이스 엔진 선택에 정답은 없습니다.

프로젝트 요구사항, 팀의 경험, 미래 확장성을 모두 고려하여 결정하세요.

실전 팁

💡 - 일반 웹 서비스라면 MySQL, 분석 중심이라면 PostgreSQL

팀이 이미 익숙한 데이터베이스가 있다면 그것을 우선 고려하세요
Aurora는 성능이 중요해지면 나중에 고려해도 늦지 않습니다

4. RDS 인스턴스 생성 실습

이론은 충분했습니다. 김개발 씨는 이제 직접 RDS 인스턴스를 생성해보기로 했습니다.

AWS 콘솔에 로그인했지만 설정 옵션이 너무 많아서 어디서부터 시작해야 할지 막막했습니다. "일단 따라 해보면서 배우자!"

RDS 인스턴스 생성은 엔진 선택, 템플릿 설정, 인스턴스 스펙, 스토리지, 네트워크 설정으로 구성됩니다. 처음에는 복잡해 보이지만 단계별로 진행하면 10분이면 완료됩니다.

다음 코드를 살펴봅시다.

// AWS SDK로 RDS 인스턴스 생성 (선택적)
const AWS = require('aws-sdk');
const rds = new AWS.RDS({ region: 'ap-northeast-2' });

const params = {
  DBInstanceIdentifier: 'my-app-database',
  DBInstanceClass: 'db.t3.micro', // 프리티어
  Engine: 'mysql',
  MasterUsername: 'admin',
  MasterUserPassword: process.env.MASTER_PASSWORD,
  AllocatedStorage: 20, // 20GB
  BackupRetentionPeriod: 7, // 7일 백업 보관
  PubliclyAccessible: false, // 퍼블릭 접근 차단
  VpcSecurityGroupIds: ['sg-0123456789abcdef0'],
  MultiAZ: false // 개발 환경
};

// 인스턴스 생성 (보통은 콘솔에서 생성)
await rds.createDBInstance(params).promise();

김개발 씨는 AWS 콘솔의 RDS 대시보드를 열었습니다. 오른쪽 상단의 "데이터베이스 생성" 버튼을 클릭하니 긴 설정 페이지가 나타났습니다.

박시니어 씨가 옆에서 말했습니다. "처음엔 복잡해 보이지만, 실제로 중요한 설정은 몇 개 안 돼.

하나씩 살펴보자." 1단계: 데이터베이스 생성 방식 선택 첫 번째 선택지는 "표준 생성"과 "손쉬운 생성"입니다. "손쉬운 생성"은 AWS가 권장하는 기본값으로 자동 설정됩니다.

빠르게 시작하기에는 좋지만 세부 제어가 어렵습니다. 표준 생성을 선택하면 모든 옵션을 직접 설정할 수 있습니다.

김개발 씨는 배우는 목적도 있으니 "표준 생성"을 선택했습니다. 2단계: 엔진 옵션 엔진 타입에서 MySQL을 선택했습니다.

버전은 MySQL 8.0.35를 선택했습니다. 최신 버전이 항상 좋은 것은 아닙니다.

사용하는 라이브러리나 프레임워크가 지원하는 버전을 확인해야 합니다. 3단계: 템플릿 세 가지 템플릿이 있습니다: 프로덕션, 개발/테스트, 프리 티어.

프로덕션은 Multi-AZ가 기본 활성화되어 비용이 높습니다. 개발/테스트는 단일 AZ로 비용을 절감합니다.

프리 티어는 12개월 동안 무료로 사용할 수 있는 최소 스펙입니다. 김개발 씨는 일단 학습 목적이니 "프리 티어"를 선택했습니다.

db.t3.micro 인스턴스와 20GB 스토리지가 자동으로 선택됩니다. 4단계: 설정 DB 인스턴스 식별자를 입력합니다.

이것은 AWS 내에서 고유한 이름입니다. 김개발 씨는 "my-ecommerce-db"라고 입력했습니다.

나중에 이 이름으로 인스턴스를 찾게 됩니다. 마스터 사용자 이름은 기본값인 "admin"을 사용했습니다.

마스터 암호는 강력한 비밀번호를 입력해야 합니다. 최소 8자 이상, 영문, 숫자, 특수문자를 포함해야 합니다.

주의: 이 비밀번호는 나중에 확인할 수 없습니다. 안전한 곳에 저장하세요.

5단계: 인스턴스 구성 프리 티어를 선택했으므로 db.t3.micro가 자동 선택되었습니다. 만약 프로덕션 환경이라면 db.t3.medium 이상을 선택하는 것이 안전합니다.

나중에 인스턴스 타입을 변경할 수 있지만, 짧은 다운타임이 발생합니다. 6단계: 스토리지 스토리지 타입은 **범용 SSD(gp3)**가 기본입니다.

할당된 스토리지는 20GB로 시작합니다. "스토리지 자동 조정 활성화"를 체크하면 디스크가 부족해질 때 자동으로 확장됩니다.

이 옵션은 꼭 활성화하세요. 디스크 부족으로 서비스가 중단되는 것을 방지할 수 있습니다.

7단계: 연결 VPC를 선택합니다. 기본 VPC를 사용해도 되지만, 프로덕션에서는 별도의 VPC를 만드는 것이 좋습니다.

"퍼블릭 액세스"는 "아니요"를 선택했습니다. 인터넷에서 직접 접근할 수 없게 만듭니다.

나중에 EC2 인스턴스나 Lambda에서 VPC 내부에서만 접근하도록 구성합니다. 보안 그룹은 새로 생성하거나 기존 것을 선택합니다.

나중에 3306 포트(MySQL)를 허용하는 규칙을 추가해야 합니다. 8단계: 추가 구성 데이터베이스 옵션에서 초기 데이터베이스 이름을 입력합니다.

김개발 씨는 "ecommerce"라고 입력했습니다. 이 데이터베이스가 자동으로 생성됩니다.

나중에 이 이름으로 연결하게 됩니다. 백업은 자동 백업을 활성화합니다.

백업 보관 기간은 7일로 설정했습니다. 백업 시간은 트래픽이 적은 시간대(새벽 3시)로 설정합니다.

모니터링에서 "Enhanced Monitoring"을 활성화하면 더 자세한 메트릭을 볼 수 있지만 추가 비용이 발생합니다. 일단은 비활성화했습니다.

로그 내보내기에서 슬로우 쿼리 로그를 활성화하면 CloudWatch에서 느린 쿼리를 모니터링할 수 있습니다. 9단계: 생성 완료 모든 설정을 확인하고 "데이터베이스 생성" 버튼을 클릭합니다.

몇 분 후 RDS 인스턴스가 생성됩니다. 상태가 "사용 가능"으로 바뀌면 연결할 수 있습니다.

인스턴스를 클릭하면 엔드포인트 주소를 확인할 수 있습니다. 이 주소가 바로 애플리케이션에서 사용할 호스트명입니다.

연결 테스트 김개발 씨는 로컬에서 MySQL 클라이언트로 연결을 시도했습니다. 하지만 연결이 되지 않았습니다.

"퍼블릭 액세스"를 "아니요"로 설정했기 때문입니다. 이것은 정상입니다.

보안을 위해 VPC 내부에서만 접근하도록 설정한 것입니다. 테스트를 위해 같은 VPC의 EC2 인스턴스에서 연결하거나, 임시로 "퍼블릭 액세스"를 "예"로 변경할 수 있습니다.

하지만 프로덕션에서는 절대 퍼블릭 액세스를 허용하면 안 됩니다. 비용 확인 프리 티어를 선택했으므로 12개월 동안 무료입니다.

하지만 프리 티어 한도를 초과하면 비용이 청구됩니다. db.t3.micro 750시간/월, 스토리지 20GB, 백업 20GB까지 무료입니다.

인스턴스를 여러 개 만들거나, 24시간 이상 켜두면 한도를 초과할 수 있으니 주의하세요. 정리 김개발 씨는 성공적으로 첫 RDS 인스턴스를 생성했습니다.

박시니어 씨가 말했습니다. "잘했어!

이제 보안 그룹 설정만 하면 애플리케이션에서 연결할 수 있어." RDS 인스턴스 생성은 처음엔 복잡해 보이지만, 몇 번 해보면 금방 익숙해집니다. 중요한 설정을 이해하고, 프로덕션에서는 보안과 백업을 꼭 신경 쓰세요.

실전 팁

💡 - 프리 티어로 시작해서 실습한 후 삭제하면 비용이 발생하지 않습니다

퍼블릭 액세스는 개발 중에만 임시로 허용하고, 프로덕션에서는 반드시 차단하세요
엔드포인트 주소와 마스터 비밀번호는 안전하게 보관하세요

5. 보안 그룹으로 DB 접근 제어

RDS 인스턴스는 생성했지만 아직 연결할 수 없습니다. 김개발 씨는 MySQL 클라이언트로 접속을 시도했지만 타임아웃 에러만 발생했습니다.

"보안 그룹 설정을 확인해봤어?" 박시니어 씨의 한마디에 김개발 씨는 보안 그룹 탭을 열었습니다.

보안 그룹은 RDS 인스턴스의 방화벽 역할을 합니다. 어떤 IP와 포트에서 접근할 수 있는지 규칙으로 정의합니다.

올바른 보안 그룹 설정 없이는 데이터베이스에 연결할 수 없습니다.

다음 코드를 살펴봅시다.

// Node.js에서 RDS 연결 - 보안 그룹이 올바르게 설정되어야 작동
const mysql = require('mysql2/promise');

const connection = await mysql.createConnection({
  host: 'my-ecommerce-db.c9akciq32.ap-northeast-2.rds.amazonaws.com',
  user: 'admin',
  password: process.env.DB_PASSWORD,
  database: 'ecommerce',
  port: 3306,
  // 이 코드가 실행되는 서버의 IP가 보안 그룹에 허용되어야 함
  connectTimeout: 10000
});

// 보안 그룹 규칙 예시 (AWS SDK로 생성)
// Inbound Rule: MySQL/Aurora (3306) from EC2 Security Group (sg-xxx)
console.log('연결 성공!');
await connection.end();

박시니어 씨가 설명을 시작했습니다. "보안 그룹을 이해하지 못하면 RDS를 제대로 쓸 수 없어.

이건 정말 중요해." AWS의 모든 리소스는 보안 그룹으로 보호됩니다. RDS도 예외가 아닙니다.

보안 그룹이란? 보안 그룹은 가상 방화벽입니다. 일반적인 방화벽처럼 어떤 트래픽을 허용하고 차단할지 규칙으로 정의합니다.

RDS 인스턴스에 할당된 보안 그룹은 누가 데이터베이스에 접근할 수 있는지 결정합니다. 비유하자면, 아파트 출입구의 경비실과 같습니다.

등록된 사람만 출입할 수 있고, 낯선 사람은 차단됩니다. 인바운드 규칙과 아웃바운드 규칙 보안 그룹에는 두 종류의 규칙이 있습니다.

인바운드 규칙은 외부에서 들어오는 트래픽을 제어합니다. RDS의 경우 데이터베이스로 들어오는 연결을 의미합니다.

아웃바운드 규칙은 나가는 트래픽을 제어합니다. 보통 아웃바운드는 모든 트래픽을 허용합니다.

RDS 보안 설정에서 중요한 것은 인바운드 규칙입니다. 기본 보안 그룹의 문제 김개발 씨가 생성한 RDS 인스턴스의 보안 그룹을 확인했습니다.

인바운드 규칙이 비어 있었습니다. 즉, 어떤 외부 연결도 허용하지 않는 상태입니다.

당연히 연결이 안 되는 것입니다. 올바른 인바운드 규칙 추가 박시니어 씨가 시연했습니다.

"보안 그룹 탭에서 인바운드 규칙 편집을 클릭해." "규칙 추가" 버튼을 누르면 세 가지를 설정해야 합니다: 유형, 소스, 설명. 유형은 "MySQL/Aurora"를 선택합니다.

자동으로 포트 3306이 설정됩니다. PostgreSQL이라면 5432 포트를 사용합니다.

소스가 가장 중요합니다. 어디서 오는 연결을 허용할지 정의합니다.

소스 설정 옵션들 첫 번째 옵션은 "내 IP"입니다. 현재 사용 중인 컴퓨터의 IP 주소만 허용합니다.

개발 중에 로컬에서 접속할 때 유용합니다. 하지만 IP가 바뀌면 다시 설정해야 합니다.

두 번째는 "Anywhere-IPv4" (0.0.0.0/0)입니다. 인터넷의 모든 IP에서 접속을 허용합니다.

절대 프로덕션에서 사용하면 안 됩니다. 누구나 데이터베이스에 접속을 시도할 수 있게 되어 보안 위험이 큽니다. 세 번째는 보안 그룹으로 지정하는 것입니다.

특정 보안 그룹에 속한 리소스만 허용합니다. 이것이 가장 안전하고 권장되는 방법입니다.

EC2 보안 그룹으로 제한하기 실무에서는 애플리케이션 서버(EC2)에서만 RDS에 접근하도록 설정합니다. 먼저 EC2 인스턴스의 보안 그룹 ID를 확인합니다.

예를 들어 "sg-0a1b2c3d4e5f6g7h8"이라고 합시다. RDS 보안 그룹의 인바운드 규칙에서 소스를 이 보안 그룹 ID로 설정합니다.

이렇게 하면 해당 보안 그룹에 속한 EC2 인스턴스만 RDS에 연결할 수 있습니다. IP 주소가 바뀌어도 상관없습니다.

EC2가 어떤 IP를 가지든, 같은 보안 그룹에 속하면 연결됩니다. Lambda에서 접근하기 Lambda 함수에서 RDS에 연결하려면 어떻게 해야 할까요?

Lambda 함수를 VPC에 연결해야 합니다. Lambda 설정에서 VPC, 서브넷, 보안 그룹을 지정합니다.

그리고 RDS 보안 그룹에서 Lambda의 보안 그룹을 허용하면 됩니다. 주의할 점은 Lambda가 VPC에 연결되면 인터넷 접근이 차단된다는 것입니다.

NAT Gateway를 설정해야 외부 API를 호출할 수 있습니다. 개발 환경에서의 접근 개발 중에는 로컬 컴퓨터에서 RDS에 연결해야 할 때가 있습니다.

가장 안전한 방법은 SSH 터널링입니다. EC2 인스턴스를 경유하여 RDS에 연결하는 방식입니다.

EC2에 SSH로 접속한 후, 포트 포워딩으로 RDS에 연결합니다. 또 다른 방법은 AWS Systems Manager Session Manager를 사용하는 것입니다.

SSH 키 없이도 안전하게 터널링할 수 있습니다. 임시로 "내 IP"를 허용하는 방법도 있지만, 작업이 끝나면 반드시 규칙을 삭제해야 합니다.

포트 변경하기 기본 포트(3306)를 사용하지 않고 싶다면 RDS 생성 시 포트를 변경할 수 있습니다. 예를 들어 33060으로 변경하면 보안 그룹에서도 33060 포트를 허용해야 합니다.

포트를 변경하면 자동화된 공격 시도를 어느 정도 방어할 수 있습니다. 규칙 우선순위 보안 그룹은 허용 규칙만 가지고 있습니다.

명시적인 거부 규칙은 없습니다. 허용되지 않은 모든 트래픽은 자동으로 차단됩니다.

여러 규칙이 있으면 하나라도 매칭되면 허용됩니다. 실수 사례 김개발 씨는 과거에 실수한 경험을 떠올렸습니다.

개발 중에 "Anywhere"로 열어놓고 삭제하는 것을 잊어버렸습니다. 다행히 큰 문제는 없었지만, 보안 스캔에서 경고가 발생했습니다.

또 다른 흔한 실수는 EC2 보안 그룹이 아니라 EC2의 IP를 직접 입력하는 것입니다. IP는 재시작할 때마다 바뀔 수 있으므로 보안 그룹 ID를 사용해야 합니다.

정리 박시니어 씨가 요약했습니다. "보안 그룹은 최소 권한 원칙을 따라야 해.

필요한 소스에서만, 필요한 포트만 허용하는 거야." 김개발 씨는 EC2 보안 그룹을 소스로 설정하고, MySQL 포트를 허용하는 규칙을 추가했습니다. 이제 애플리케이션에서 정상적으로 RDS에 연결할 수 있습니다.

보안은 타협할 수 없는 영역입니다. 편리함보다 안전함을 우선시하세요.

실전 팁

💡 - 프로덕션에서는 절대 "Anywhere"를 허용하지 마세요

EC2 보안 그룹을 소스로 지정하는 것이 가장 안전합니다
개발 중에는 SSH 터널링을 사용하세요

6. RDS 백업 및 복원 기본

어느 금요일 오후, 김개발 씨는 실수로 중요한 데이터가 담긴 테이블을 삭제했습니다. 얼굴이 하얗게 질렸습니다.

"백업은 있겠지?" 박시니어 씨가 침착하게 물었습니다. 다행히 RDS 자동 백업이 활성화되어 있었습니다.

RDS는 자동 백업과 수동 스냅샷 두 가지 백업 방식을 제공합니다. 자동 백업은 매일 전체 백업을 수행하고, 특정 시점으로 복원할 수 있습니다.

데이터 손실을 방지하는 필수 기능입니다.

다음 코드를 살펴봅시다.

// Node.js에서 백업 전 데이터 확인
const [rows] = await connection.execute(
  'SELECT COUNT(*) as total FROM products'
);
console.log(`백업 전 상품 수: ${rows[0].total}`);

// 실수로 데이터 삭제 (실제로 하지 마세요!)
// await connection.execute('DELETE FROM products');

// AWS SDK로 특정 시점 복원 (Point-in-Time Recovery)
const rds = new AWS.RDS({ region: 'ap-northeast-2' });
const restoreParams = {
  SourceDBInstanceIdentifier: 'my-ecommerce-db',
  TargetDBInstanceIdentifier: 'my-ecommerce-db-restored',
  RestoreTime: new Date('2025-01-15T14:30:00Z'), // 삭제 직전 시점
  UseLatestRestorableTime: false
};

await rds.restoreDBInstanceToPointInTime(restoreParams).promise();
console.log('복원 진행 중...');

박시니어 씨는 RDS 콘솔의 "유지 관리 및 백업" 탭을 열었습니다. 자동 백업이 활성화되어 있고, 7일간의 백업이 보관되어 있었습니다.

"다행이네. 오늘 오후 2시 30분으로 되돌리면 돼." 자동 백업의 작동 원리 RDS 자동 백업은 두 가지 요소로 구성됩니다.

첫째, 일일 전체 백업입니다. 설정한 백업 시간(예: 새벽 3시)에 데이터베이스 전체의 스냅샷을 생성합니다.

이것은 S3에 자동으로 저장됩니다. 둘째, 트랜잭션 로그 백업입니다.

5분마다 트랜잭션 로그가 백업됩니다. 이 로그를 이용하면 5분 단위로 특정 시점으로 복원할 수 있습니다.

비유하자면, 전체 백업은 영화의 전체 녹화본이고, 트랜잭션 로그는 실시간 녹화입니다. 둘을 조합하면 정확한 시점으로 되돌릴 수 있습니다.

백업 보관 기간 설정 RDS 생성 시 백업 보관 기간을 설정합니다. 최소 1일부터 최대 35일까지 가능합니다.

기본값은 7일입니다. 보관 기간이 길수록 더 오래된 시점으로 복원할 수 있지만, 스토리지 비용이 증가합니다.

김개발 씨의 경우 7일로 설정했으므로, 최대 일주일 전 시점까지 복원할 수 있습니다. 백업 시간 선택 백업은 I/O를 많이 사용하므로 성능에 영향을 줍니다.

따라서 트래픽이 적은 시간대를 선택해야 합니다. 대부분의 서비스는 새벽 2~4시에 백업을 수행합니다.

사용자가 거의 없는 시간이기 때문입니다. 백업 시간은 30분 단위로 지정할 수 있습니다.

예를 들어 "03:00-03:30" 사이에 백업이 시작됩니다. Point-in-Time Recovery (PITR) 김개발 씨가 실수로 테이블을 삭제한 시각은 오후 2시 35분이었습니다.

박시니어 씨는 오후 2시 30분 시점으로 복원하기로 했습니다. RDS 콘솔에서 "작업 > 특정 시점으로 복원"을 선택했습니다.

복원 시 주의사항이 있습니다. 기존 인스턴스를 덮어쓰는 것이 아니라, 새로운 인스턴스를 생성합니다.

복원된 인스턴스는 별도의 엔드포인트를 가집니다. 복원 프로세스 복원 설정에서 복원할 시점을 입력합니다.

"최신 복원 가능 시점 사용" 또는 "사용자 지정 시간"을 선택할 수 있습니다. 김개발 씨는 "2025-01-15 14:30:00"을 입력했습니다.

새 인스턴스 식별자를 입력합니다. 예를 들어 "my-ecommerce-db-restored"로 지정했습니다.

나머지 설정(인스턴스 타입, VPC, 보안 그룹)은 원본과 동일하게 설정됩니다. "인스턴스 복원" 버튼을 클릭하면 복원이 시작됩니다.

인스턴스 크기에 따라 10분에서 1시간 정도 걸립니다. 복원 후 검증 복원된 인스턴스가 "사용 가능" 상태가 되면 연결하여 데이터를 확인합니다.

김개발 씨는 복원된 데이터베이스에 연결하여 삭제된 테이블이 있는지 확인했습니다. 다행히 2시 30분 시점의 데이터가 모두 살아있었습니다.

데이터를 확인한 후, 애플리케이션의 데이터베이스 엔드포인트를 복원된 인스턴스로 변경했습니다. 서비스가 정상화되었습니다.

수동 스냅샷 자동 백업 외에 수동 스냅샷을 만들 수도 있습니다. 중요한 배포 전에 수동 스냅샷을 생성하는 것이 좋습니다.

예를 들어 대규모 데이터 마이그레이션을 수행하기 전에 스냅샷을 만들어두면, 문제가 생겼을 때 빠르게 되돌릴 수 있습니다. 수동 스냅샷은 보관 기간 제한이 없습니다.

명시적으로 삭제하지 않는 한 영구 보관됩니다. 단, 스토리지 비용은 계속 청구됩니다.

스냅샷에서 복원하기 스냅샷에서 복원하는 것은 PITR보다 간단합니다. RDS 콘솔에서 "스냅샷" 메뉴로 이동합니다.

복원할 스냅샷을 선택하고 "작업 > 스냅샷 복원"을 클릭합니다. 새 인스턴스 설정을 입력하고 복원합니다.

스냅샷 복원은 특정 시점이 아니라 스냅샷이 생성된 시각의 상태로 복원됩니다. 자동 백업 vs 수동 스냅샷 두 방식의 차이를 정리하면 다음과 같습니다.

자동 백업은 매일 자동으로 수행되고, 특정 시점 복원이 가능하지만, 보관 기간이 제한됩니다(최대 35일). RDS 인스턴스를 삭제하면 자동 백업도 함께 삭제됩니다.

수동 스냅샷은 수동으로 생성하고, 특정 시점이 아니라 스냅샷 시각으로만 복원되지만, 영구 보관됩니다. RDS 인스턴스를 삭제해도 스냅샷은 남아있습니다.

백업 비용 자동 백업 스토리지는 프로비저닝된 스토리지 크기까지 무료입니다. 예를 들어 RDS 스토리지가 100GB라면, 백업 100GB까지는 무료입니다.

초과분에 대해서만 비용이 청구됩니다. 수동 스냅샷은 모든 용량에 대해 비용이 청구됩니다.

불필요한 스냅샷은 정기적으로 삭제하는 것이 좋습니다. 교차 리전 백업 재해 복구를 위해 다른 리전에 백업을 복사할 수 있습니다.

예를 들어 서울 리전의 스냅샷을 도쿄 리전에 복사하면, 서울 리전 전체에 장애가 발생해도 도쿄에서 복원할 수 있습니다. 이것은 대규모 서비스에서 사용하는 고급 전략입니다.

소규모 서비스에서는 단일 리전의 Multi-AZ만으로도 충분합니다. 백업 모니터링 백업이 제대로 수행되는지 모니터링해야 합니다.

CloudWatch에서 "OldestBackupCreationTime" 메트릭을 확인하면 백업이 정상적으로 생성되고 있는지 알 수 있습니다. 백업이 실패하면 알림을 받도록 설정하세요.

정리 박시니어 씨가 말했습니다. "오늘 배운 교훈은 뭐야?" 김개발 씨는 대답했습니다.

"백업은 선택이 아니라 필수라는 거요. 그리고 복원 절차를 미리 알아둬야 한다는 것도요." 실제로 복원을 해본 경험은 매우 중요합니다.

재난이 발생했을 때 당황하지 않고 침착하게 대응할 수 있습니다. 여러분도 테스트 환경에서 백업과 복원을 실습해보세요.

그것이 진짜 위기에서 여러분을 구해줄 것입니다.

실전 팁

💡 - 자동 백업은 반드시 활성화하세요 (최소 7일 보관)

중요한 작업 전에는 수동 스냅샷을 생성하세요
복원 절차를 미리 연습해보는 것이 중요합니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#RDS#Database#MySQL#PostgreSQL#AWS,RDS,Database

AWS RDS 관리형 데이터베이스 완벽 가이드

# AWS RDS 관리형 데이터베이스 완벽 가이드 직접 데이터베이스를 설치하고 관리하는 것이 부담스러운 초급 개발자를 위한 RDS 가이드입니다. 데이터베이스 엔진 선택부터 인스턴스 생성, 보안 설정, 백업까지 실무에 필요한 모든 내용을 다룹니다. --- ## 목차 1. [RDS(Relational Database Service)란](#rds(relational-database-service)란) 2. [RDS vs 직접 설치 DB 비교](#rds-vs-직접-설치-db-비교) 3. [데이터베이스 엔진 선택 (MySQL, PostgreSQL 등)](#데이터베이스-엔진-선택-(mysql,-postgresql-등)) 4. [RDS 인스턴스 생성 실습](#rds-인스턴스-생성-실습) 5. [보안 그룹으로 DB 접근 제어](#보안-그룹으로-db-접근-제어) 6. [RDS 백업 및 복원 기본](#rds-백업-및-복원-기본) --- ## 1. RDS(Relational Database Service)란 첫 프로젝트를 맡은 김개발 씨는 고민에 빠졌습니다. 팀장님이 "데이터베이스는 RDS로 구축하세요"라고 말씀하셨는데, RDS가 정확히 무엇인지 알 수 없었습니다. 직접 MySQL을 설치하는 것과 뭐가 다를까요? RDS는 AWS에서 제공하는 **관리형 데이터베이스 서비스**입니다. 마치 호텔에 묵는 것처럼, 데이터베이스 운영에 필요한 복잡한 작업들을 AWS가 대신 처리해줍니다. 개발자는 데이터베이스 사용에만 집중할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 RDS MySQL 연결 예제 const mysql = require('mysql2/promise'); const connection = await mysql.createConnection({ host: 'mydb.c9akciq32.ap-northeast-2.rds.amazonaws.com', user: 'admin', password: process.env.DB_PASSWORD, database: 'productdb', // RDS 엔드포인트로 연결 - EC2에 직접 설치한 것과 동일하게 사용 port: 3306 }); // 일반적인 쿼리 실행 const [rows] = await connection.execute( 'SELECT * FROM users WHERE id = ?', [userId] ); ``` 김개발 씨는 이전 회사에서 데이터베이스를 직접 설치해본 경험이 있습니다. EC2 인스턴스에 MySQL을 설치하고, 설정 파일을 수정하고, 보안 패치를 적용하고, 백업 스크립트를 작성하는 일련의 과정이 꽤나 복잡했습니다. 특히 주말에 갑자기 데이터베이스 서버가 다운되어 급하게 복구했던 기억이 생생합니다. 그때 선배 개발자가 이런 말을 했습니다. "RDS를 썼으면 이런 일은 없었을 텐데." **RDS란 무엇일까요?** RDS는 Relational Database Service의 약자로, AWS에서 제공하는 **관리형 관계형 데이터베이스 서비스**입니다. 쉽게 비유하자면, 직접 집을 관리하는 것과 호텔에 묵는 것의 차이와 같습니다. 집을 직접 관리하면 청소, 수리, 전기·수도 관리를 모두 스스로 해야 합니다. 하지만 호텔에 묵으면 직원들이 이 모든 것을 대신 처리해줍니다. 투숙객은 편안하게 쉬는 것에만 집중할 수 있습니다. RDS도 마찬가지입니다. 데이터베이스 서버 관리, 백업, 패치, 복제, 장애 복구 등 복잡한 운영 작업을 AWS가 자동으로 처리해줍니다. **왜 RDS가 필요할까요?** 데이터베이스를 EC2에 직접 설치하면 많은 책임이 따릅니다. 첫째, **운영체제 패치**를 직접 관리해야 합니다. 보안 취약점이 발견되면 밤낮없이 패치를 적용해야 합니다. 둘째, **백업 시스템**을 직접 구축해야 합니다. 크론 작업으로 백업 스크립트를 돌리고, 백업 파일이 제대로 생성되었는지 확인하고, S3에 저장하는 일련의 과정이 필요합니다. 셋째, **장애 대응**입니다. 디스크가 가득 차거나, 메모리가 부족하거나, 네트워크 문제가 생기면 직접 해결해야 합니다. 새벽 3시에 알람이 울려도 일어나서 서버를 재시작해야 합니다. **RDS의 핵심 가치** RDS를 사용하면 이 모든 부담에서 벗어날 수 있습니다. AWS가 **자동 백업**을 수행합니다. 매일 정해진 시간에 스냅샷을 생성하고, 트랜잭션 로그를 저장합니다. 장애가 발생해도 특정 시점으로 복구할 수 있습니다. **자동 패치**도 제공됩니다. 설정한 유지보수 시간에 자동으로 패치가 적용됩니다. 보안 취약점 걱정을 덜 수 있습니다. **Multi-AZ 배포**로 고가용성을 확보할 수 있습니다. 주 데이터베이스에 장애가 발생하면 자동으로 대기 데이터베이스로 전환됩니다. 서비스 중단 시간을 최소화할 수 있습니다. **코드에서의 사용법** 위의 코드를 보면 일반적인 MySQL 연결과 크게 다르지 않습니다. host 부분에 RDS 엔드포인트 주소를 입력합니다. 이 주소는 RDS 인스턴스를 생성하면 자동으로 할당됩니다. 나머지는 일반적인 MySQL 연결 방식과 동일합니다. 개발자 입장에서는 MySQL을 사용하는 것과 똑같이 코드를 작성하면 됩니다. 하지만 뒷단에서는 AWS가 안정적인 운영을 보장해줍니다. **실무에서의 활용** 스타트업에서 서비스를 런칭한다고 가정해봅시다. 초기에는 트래픽이 적어서 작은 인스턴스로 시작합니다. 서비스가 성장하면서 사용자가 늘어나면 인스턴스 타입을 변경하여 **스케일업**할 수 있습니다. 읽기 트래픽이 많아지면 **읽기 전용 복제본**을 추가하여 부하를 분산시킬 수 있습니다. 이 모든 작업이 콘솔 클릭 몇 번으로 가능합니다. 직접 서버를 증설하고 복제를 설정하는 것보다 훨씬 간단합니다. **주의사항** RDS가 만능은 아닙니다. 비용이 EC2에 직접 설치하는 것보다 높습니다. 관리 편의성을 얻는 대신 추가 비용을 지불하는 것입니다. 또한 **루트 접근 권한**이 없습니다. 운영체제 레벨의 커스터마이징이 필요하다면 RDS는 적합하지 않습니다. 하지만 대부분의 경우 RDS의 장점이 단점을 훨씬 상회합니다. **정리** 김개발 씨는 팀장님께 RDS에 대해 질문했습니다. "아, RDS는 우리가 데이터베이스 관리에 신경 쓰지 않고 비즈니스 로직 개발에 집중할 수 있게 해주는 서비스야. 특히 우리처럼 인력이 부족한 팀에는 필수지." RDS를 사용하면 안정적인 데이터베이스 운영을 AWS에 맡기고, 여러분은 더 중요한 기능 개발에 집중할 수 있습니다. **실전 팁** 💡 - RDS는 소규모 팀이나 스타트업에 특히 유용합니다 - 비용과 편의성을 비교하여 도입을 결정하세요 - 프로덕션 환경에서는 Multi-AZ 옵션을 반드시 활성화하세요 --- ## 2. RDS vs 직접 설치 DB 비교 김개발 씨는 견적을 내보고 깜짝 놀랐습니다. RDS가 EC2에 직접 MySQL을 설치하는 것보다 두 배 가까이 비쌌습니다. "이렇게 비싼데도 RDS를 써야 할까요?" 박시니어 씨가 웃으며 대답했습니다. RDS는 비용이 높지만 **운영 부담을 크게 줄여줍니다**. 직접 설치는 초기 비용은 저렴하지만 **인건비와 장애 리스크**가 숨어 있습니다. 각 방식의 장단점을 이해하고 상황에 맞게 선택해야 합니다. 다음 코드를 살펴봅시다. ```javascript // EC2 직접 설치 - 연결 코드는 동일 const directConnection = await mysql.createConnection({ host: 'ec2-13-124-123-456.compute.amazonaws.com', user: 'root', password: process.env.DB_PASSWORD, database: 'productdb', // 직접 관리: OS 패치, MySQL 버전 업그레이드, 백업 스크립트 모두 직접 작성 }); // RDS - 연결 코드는 동일하지만 뒷단 관리는 AWS가 담당 const rdsConnection = await mysql.createConnection({ host: 'mydb.c9akciq32.ap-northeast-2.rds.amazonaws.com', user: 'admin', password: process.env.DB_PASSWORD, database: 'productdb', // AWS 관리: 자동 백업, 자동 패치, Multi-AZ 장애 조치 }); ``` 박시니어 씨는 과거 이야기를 꺼냈습니다. "3년 전에 우리 팀이 EC2에 PostgreSQL을 직접 설치해서 운영했었어. 처음에는 비용 절감이 좋아 보였지." 하지만 현실은 달랐습니다. 디스크 용량을 모니터링하고, 슬로우 쿼리를 분석하고, 인덱스를 최적화하고, 백업이 제대로 되는지 확인하는 일에 많은 시간을 쏟아야 했습니다. **비용 비교의 함정** 직접 설치가 저렴해 보이는 이유는 **겉으로 드러나는 비용**만 보기 때문입니다. EC2 t3.medium 인스턴스에 MySQL을 설치하면 월 30달러 정도입니다. 같은 사양의 RDS는 60달러 정도입니다. 단순 비교하면 RDS가 두 배 비쌉니다. 하지만 **숨은 비용**을 고려해야 합니다. 개발자가 데이터베이스 관리에 쓰는 시간은 어떻게 계산할까요? 한 달에 10시간을 데이터베이스 관리에 쓴다면, 시급 5만원 기준으로 50만원의 인건비가 발생합니다. 게다가 **장애 리스크**도 있습니다. 백업을 깜빡해서 데이터를 잃어버리거나, 디스크가 가득 차서 서비스가 중단되면 그 손실은 훨씬 큽니다. **운영 부담의 차이** 직접 설치하면 모든 책임이 개발자에게 있습니다. MySQL 5.7에서 8.0으로 업그레이드해야 한다면 어떻게 해야 할까요? 먼저 테스트 환경에서 호환성을 검증해야 합니다. 그다음 서비스 중단 시간을 공지하고, 백업을 받고, 업그레이드를 진행하고, 롤백 계획도 세워야 합니다. RDS는 이 과정이 훨씬 간단합니다. 유지보수 시간을 설정하고 업그레이드 버전을 선택하면 자동으로 진행됩니다. 문제가 생기면 이전 스냅샷으로 롤백할 수 있습니다. **백업과 복구** 직접 설치 환경에서 백업을 구현해봅시다. 크론 작업으로 매일 새벽 2시에 mysqldump를 실행합니다. 덤프 파일을 압축하고 S3에 업로드합니다. 오래된 백업은 삭제하는 스크립트도 작성해야 합니다. 백업이 실패했을 때 알림을 받는 모니터링도 필요합니다. RDS는 **자동 백업**이 기본 제공됩니다. 보관 기간을 설정하면 매일 자동으로 스냅샷을 생성합니다. 특정 시점으로 복구하는 **Point-in-Time Recovery**도 가능합니다. 실수로 테이블을 삭제했다면 5분 전 상태로 되돌릴 수 있습니다. **고가용성 구성** 직접 설치 환경에서 고가용성을 구현하려면 어떻게 해야 할까요? 마스터-슬레이브 복제를 설정하고, 헬스 체크를 구현하고, 장애 발생 시 자동으로 슬레이브를 마스터로 승격시키는 스크립트를 작성해야 합니다. 이 모든 것이 복잡하고 에러가 발생하기 쉽습니다. RDS의 **Multi-AZ 배포**는 클릭 한 번으로 활성화됩니다. 다른 가용 영역에 대기 인스턴스가 생성되고, 데이터가 자동으로 동기화됩니다. 주 인스턴스에 장애가 발생하면 1~2분 안에 자동으로 대기 인스턴스로 전환됩니다. **언제 직접 설치를 선택할까?** 그렇다면 직접 설치는 언제 적합할까요? 첫째, **매우 특수한 커스터마이징**이 필요한 경우입니다. 운영체제 레벨의 튜닝이나 특정 플러그인 설치가 필요하다면 직접 설치가 유리합니다. 둘째, **비용이 절대적으로 중요한 경우**입니다. 초기 스타트업이나 개인 프로젝트에서는 직접 설치로 시작할 수 있습니다. 다만 성장하면서 RDS로 마이그레이션하는 것을 고려해야 합니다. 셋째, **숙련된 DBA가 있는 경우**입니다. 데이터베이스 관리 전문가가 있다면 직접 설치로 더 세밀한 최적화가 가능합니다. **실무 결정 기준** 박시니어 씨는 이렇게 조언했습니다. "우리 팀처럼 백엔드 개발자 3명이 전부라면 RDS가 답이야. DBA 채용하는 것보다 훨씬 저렴하고, 우리는 비즈니스 로직 개발에 집중할 수 있어." 실제로 많은 스타트업이 초기에는 비용 때문에 직접 설치를 선택했다가, 운영 부담을 견디지 못하고 RDS로 전환합니다. **정리** 김개발 씨는 고개를 끄덕였습니다. "그러니까 단순히 서버 비용만 비교하면 안 되는 거네요. 시간과 안정성까지 고려해야 하는군요." 비용은 중요하지만, 그것이 전부는 아닙니다. 여러분의 팀 규모, 전문성, 서비스 요구사항을 종합적으로 고려하여 선택하세요. **실전 팁** 💡 - 팀 규모가 작다면 RDS가 유리합니다 - 초기 단계에서는 직접 설치로 시작해도 괜찮지만, 성장을 고려하세요 - 숨은 비용(인건비, 장애 리스크)을 반드시 계산하세요 --- ## 3. 데이터베이스 엔진 선택 (MySQL, PostgreSQL 등) RDS를 사용하기로 결정한 김개발 씨는 또 다른 선택의 기로에 섰습니다. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 중에서 무엇을 선택해야 할까요? 각 데이터베이스마다 특징이 다르다는데, 어떤 기준으로 선택해야 할지 막막했습니다. RDS는 **6가지 데이터베이스 엔진**을 지원합니다. MySQL과 PostgreSQL이 가장 널리 쓰이며, 각각 단순함과 고급 기능이라는 강점이 있습니다. 프로젝트 요구사항과 팀의 경험을 고려하여 선택해야 합니다. 다음 코드를 살펴봅시다. ```javascript // MySQL 연결 - 가장 대중적, 빠른 읽기 성능 const mysqlConn = await mysql.createConnection({ host: 'mysql-instance.rds.amazonaws.com', user: 'admin', password: process.env.DB_PASSWORD, database: 'ecommerce', // 간단한 웹 서비스, 읽기 중심 워크로드에 적합 }); // PostgreSQL 연결 - 고급 기능, JSONB, 복잡한 쿼리 const { Client } = require('pg'); const pgConn = new Client({ host: 'postgres-instance.rds.amazonaws.com', user: 'admin', password: process.env.DB_PASSWORD, database: 'analytics', // 복잡한 분석, JSON 데이터, 트랜잭션 무결성 중요한 경우 port: 5432 }); await pgConn.connect(); ``` 박시니어 씨가 화이트보드에 표를 그리며 설명을 시작했습니다. "데이터베이스 엔진을 선택하는 것은 프로젝트의 방향을 결정하는 중요한 결정이야." 한번 선택하면 나중에 바꾸기 어렵습니다. 스키마, 쿼리, ORM 설정 등 많은 부분이 데이터베이스 엔진과 연결되어 있기 때문입니다. **MySQL - 대중적이고 검증된 선택** MySQL은 세계에서 가장 널리 쓰이는 오픈소스 데이터베이스입니다. 가장 큰 장점은 **단순함**입니다. 설치, 설정, 사용이 직관적입니다. 웹 개발자라면 누구나 한 번쯤 MySQL을 사용해봤을 것입니다. 그만큼 레퍼런스와 커뮤니티가 방대합니다. **읽기 성능**이 뛰어납니다. 간단한 SELECT 쿼리가 많은 웹 서비스에 적합합니다. WordPress, Drupal 같은 CMS도 MySQL을 기본으로 사용합니다. 복제와 샤딩이 성숙했습니다. 대규모 트래픽을 처리하는 많은 기업이 MySQL을 사용합니다. Facebook, YouTube, Twitter도 MySQL을 대규모로 운영한 경험이 있습니다. **PostgreSQL - 강력한 기능의 선택** PostgreSQL은 "세계에서 가장 진보된 오픈소스 데이터베이스"라고 불립니다. **SQL 표준 준수**가 뛰어납니다. 복잡한 조인, 서브쿼리, 윈도우 함수 등을 정확하게 지원합니다. **트랜잭션 무결성**도 MySQL보다 엄격합니다. **고급 데이터 타입**을 지원합니다. JSONB 타입으로 NoSQL처럼 JSON 데이터를 효율적으로 저장하고 쿼리할 수 있습니다. 배열, UUID, IP 주소 같은 특수한 타입도 기본 제공합니다. **확장성**이 뛰어납니다. PostGIS 확장으로 지리 정보를 처리할 수 있고, Full-Text Search로 검색 엔진을 구현할 수 있습니다. **언제 MySQL을 선택할까?** 김개발 씨의 프로젝트는 전자상거래 웹사이트입니다. 상품 목록 조회, 장바구니 관리, 주문 내역 조회 같은 기능이 주를 이룹니다. 복잡한 분석 쿼리보다는 **빠른 읽기 성능**이 중요합니다. 팀원들이 모두 MySQL에 익숙합니다. 이런 경우 MySQL이 적합합니다. 검증된 안정성, 빠른 성능, 풍부한 레퍼런스를 활용할 수 있습니다. 또한 **WordPress나 Laravel**을 사용한다면 MySQL이 자연스러운 선택입니다. 프레임워크가 MySQL에 최적화되어 있기 때문입니다. **언제 PostgreSQL을 선택할까?** 반면 데이터 분석 플랫폼을 개발한다고 가정해봅시다. 사용자 행동 데이터를 JSON으로 저장하고, 복잡한 집계 쿼리를 실행하고, 데이터 무결성이 절대적으로 중요합니다. 이런 경우 PostgreSQL이 더 적합합니다. **JSONB 타입**으로 유연하게 데이터를 저장하면서도 인덱싱과 쿼리가 가능합니다. **CTE(Common Table Expressions)**와 **윈도우 함수**로 복잡한 분석을 SQL로 처리할 수 있습니다. **Django나 Rails**를 사용한다면 PostgreSQL을 고려하세요. 이 프레임워크들은 PostgreSQL의 고급 기능을 잘 활용합니다. **MariaDB는 어떨까?** MariaDB는 MySQL의 포크 버전입니다. MySQL 창시자가 만든 데이터베이스로, MySQL과 거의 호환되면서도 일부 개선된 기능을 제공합니다. MySQL에서 MariaDB로 전환이 쉽습니다. 하지만 **커뮤니티 크기**는 MySQL이 더 큽니다. 특별한 이유가 없다면 MySQL을 선택하는 것이 안전합니다. **상용 데이터베이스는?** Oracle과 SQL Server도 RDS에서 지원합니다. 기존에 온프레미스에서 Oracle을 사용하던 기업이 클라우드로 전환할 때 선택합니다. 하지만 **라이선스 비용**이 매우 비쌉니다. 새로운 프로젝트라면 오픈소스 데이터베이스(MySQL, PostgreSQL)를 선택하는 것이 합리적입니다. **Aurora는 뭐가 다를까?** AWS Aurora는 MySQL 및 PostgreSQL과 호환되는 AWS 자체 엔진입니다. **5배 빠른 성능**과 자동 스케일링을 제공합니다. 하지만 비용이 일반 RDS보다 높고, AWS 종속성이 강해집니다. 초기에는 일반 RDS로 시작하고, 성능이 병목이 되면 Aurora로 마이그레이션하는 것을 추천합니다. **실무 결정 프로세스** 박시니어 씨는 이렇게 정리했습니다. "일반적인 웹 서비스라면 MySQL, 복잡한 데이터 처리와 분석이 필요하면 PostgreSQL을 선택해. 잘 모르겠으면 MySQL로 시작해도 괜찮아." 실제로 대부분의 웹 서비스는 MySQL로 충분합니다. 정말 PostgreSQL의 고급 기능이 필요한 경우가 아니라면 단순함을 선택하는 것이 현명합니다. **정리** 김개발 씨는 자신의 프로젝트를 다시 살펴봤습니다. 일반적인 CRUD 중심의 웹 서비스이고, 팀원들이 MySQL에 익숙하니 MySQL을 선택하기로 했습니다. 데이터베이스 엔진 선택에 정답은 없습니다. 프로젝트 요구사항, 팀의 경험, 미래 확장성을 모두 고려하여 결정하세요. **실전 팁** 💡 - 일반 웹 서비스라면 MySQL, 분석 중심이라면 PostgreSQL - 팀이 이미 익숙한 데이터베이스가 있다면 그것을 우선 고려하세요 - Aurora는 성능이 중요해지면 나중에 고려해도 늦지 않습니다 --- ## 4. RDS 인스턴스 생성 실습 이론은 충분했습니다. 김개발 씨는 이제 직접 RDS 인스턴스를 생성해보기로 했습니다. AWS 콘솔에 로그인했지만 설정 옵션이 너무 많아서 어디서부터 시작해야 할지 막막했습니다. "일단 따라 해보면서 배우자!" RDS 인스턴스 생성은 **엔진 선택, 템플릿 설정, 인스턴스 스펙, 스토리지, 네트워크 설정**으로 구성됩니다. 처음에는 복잡해 보이지만 단계별로 진행하면 10분이면 완료됩니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK로 RDS 인스턴스 생성 (선택적) const AWS = require('aws-sdk'); const rds = new AWS.RDS({ region: 'ap-northeast-2' }); const params = { DBInstanceIdentifier: 'my-app-database', DBInstanceClass: 'db.t3.micro', // 프리티어 Engine: 'mysql', MasterUsername: 'admin', MasterUserPassword: process.env.MASTER_PASSWORD, AllocatedStorage: 20, // 20GB BackupRetentionPeriod: 7, // 7일 백업 보관 PubliclyAccessible: false, // 퍼블릭 접근 차단 VpcSecurityGroupIds: ['sg-0123456789abcdef0'], MultiAZ: false // 개발 환경 }; // 인스턴스 생성 (보통은 콘솔에서 생성) await rds.createDBInstance(params).promise(); ``` 김개발 씨는 AWS 콘솔의 RDS 대시보드를 열었습니다. 오른쪽 상단의 "데이터베이스 생성" 버튼을 클릭하니 긴 설정 페이지가 나타났습니다. 박시니어 씨가 옆에서 말했습니다. "처음엔 복잡해 보이지만, 실제로 중요한 설정은 몇 개 안 돼. 하나씩 살펴보자." **1단계: 데이터베이스 생성 방식 선택** 첫 번째 선택지는 "표준 생성"과 "손쉬운 생성"입니다. "손쉬운 생성"은 AWS가 권장하는 기본값으로 자동 설정됩니다. 빠르게 시작하기에는 좋지만 세부 제어가 어렵습니다. **표준 생성**을 선택하면 모든 옵션을 직접 설정할 수 있습니다. 김개발 씨는 배우는 목적도 있으니 "표준 생성"을 선택했습니다. **2단계: 엔진 옵션** 엔진 타입에서 MySQL을 선택했습니다. 버전은 **MySQL 8.0.35**를 선택했습니다. 최신 버전이 항상 좋은 것은 아닙니다. 사용하는 라이브러리나 프레임워크가 지원하는 버전을 확인해야 합니다. **3단계: 템플릿** 세 가지 템플릿이 있습니다: 프로덕션, 개발/테스트, 프리 티어. **프로덕션**은 Multi-AZ가 기본 활성화되어 비용이 높습니다. **개발/테스트**는 단일 AZ로 비용을 절감합니다. **프리 티어**는 12개월 동안 무료로 사용할 수 있는 최소 스펙입니다. 김개발 씨는 일단 학습 목적이니 "프리 티어"를 선택했습니다. db.t3.micro 인스턴스와 20GB 스토리지가 자동으로 선택됩니다. **4단계: 설정** DB 인스턴스 식별자를 입력합니다. 이것은 **AWS 내에서 고유한 이름**입니다. 김개발 씨는 "my-ecommerce-db"라고 입력했습니다. 나중에 이 이름으로 인스턴스를 찾게 됩니다. 마스터 사용자 이름은 기본값인 "admin"을 사용했습니다. 마스터 암호는 강력한 비밀번호를 입력해야 합니다. 최소 8자 이상, 영문, 숫자, 특수문자를 포함해야 합니다. **주의**: 이 비밀번호는 나중에 확인할 수 없습니다. 안전한 곳에 저장하세요. **5단계: 인스턴스 구성** 프리 티어를 선택했으므로 db.t3.micro가 자동 선택되었습니다. 만약 프로덕션 환경이라면 **db.t3.medium** 이상을 선택하는 것이 안전합니다. 나중에 인스턴스 타입을 변경할 수 있지만, 짧은 다운타임이 발생합니다. **6단계: 스토리지** 스토리지 타입은 **범용 SSD(gp3)**가 기본입니다. 할당된 스토리지는 20GB로 시작합니다. "스토리지 자동 조정 활성화"를 체크하면 디스크가 부족해질 때 자동으로 확장됩니다. 이 옵션은 꼭 활성화하세요. 디스크 부족으로 서비스가 중단되는 것을 방지할 수 있습니다. **7단계: 연결** VPC를 선택합니다. 기본 VPC를 사용해도 되지만, 프로덕션에서는 **별도의 VPC**를 만드는 것이 좋습니다. "퍼블릭 액세스"는 "아니요"를 선택했습니다. 인터넷에서 직접 접근할 수 없게 만듭니다. 나중에 EC2 인스턴스나 Lambda에서 VPC 내부에서만 접근하도록 구성합니다. 보안 그룹은 새로 생성하거나 기존 것을 선택합니다. 나중에 3306 포트(MySQL)를 허용하는 규칙을 추가해야 합니다. **8단계: 추가 구성** 데이터베이스 옵션에서 **초기 데이터베이스 이름**을 입력합니다. 김개발 씨는 "ecommerce"라고 입력했습니다. 이 데이터베이스가 자동으로 생성됩니다. 나중에 이 이름으로 연결하게 됩니다. **백업**은 자동 백업을 활성화합니다. 백업 보관 기간은 7일로 설정했습니다. 백업 시간은 트래픽이 적은 시간대(새벽 3시)로 설정합니다. **모니터링**에서 "Enhanced Monitoring"을 활성화하면 더 자세한 메트릭을 볼 수 있지만 추가 비용이 발생합니다. 일단은 비활성화했습니다. **로그 내보내기**에서 슬로우 쿼리 로그를 활성화하면 CloudWatch에서 느린 쿼리를 모니터링할 수 있습니다. **9단계: 생성 완료** 모든 설정을 확인하고 "데이터베이스 생성" 버튼을 클릭합니다. 몇 분 후 RDS 인스턴스가 생성됩니다. 상태가 "사용 가능"으로 바뀌면 연결할 수 있습니다. 인스턴스를 클릭하면 **엔드포인트 주소**를 확인할 수 있습니다. 이 주소가 바로 애플리케이션에서 사용할 호스트명입니다. **연결 테스트** 김개발 씨는 로컬에서 MySQL 클라이언트로 연결을 시도했습니다. 하지만 연결이 되지 않았습니다. "퍼블릭 액세스"를 "아니요"로 설정했기 때문입니다. 이것은 정상입니다. 보안을 위해 VPC 내부에서만 접근하도록 설정한 것입니다. 테스트를 위해 같은 VPC의 EC2 인스턴스에서 연결하거나, 임시로 "퍼블릭 액세스"를 "예"로 변경할 수 있습니다. 하지만 프로덕션에서는 절대 퍼블릭 액세스를 허용하면 안 됩니다. **비용 확인** 프리 티어를 선택했으므로 12개월 동안 무료입니다. 하지만 프리 티어 한도를 초과하면 비용이 청구됩니다. db.t3.micro 750시간/월, 스토리지 20GB, 백업 20GB까지 무료입니다. 인스턴스를 여러 개 만들거나, 24시간 이상 켜두면 한도를 초과할 수 있으니 주의하세요. **정리** 김개발 씨는 성공적으로 첫 RDS 인스턴스를 생성했습니다. 박시니어 씨가 말했습니다. "잘했어! 이제 보안 그룹 설정만 하면 애플리케이션에서 연결할 수 있어." RDS 인스턴스 생성은 처음엔 복잡해 보이지만, 몇 번 해보면 금방 익숙해집니다. 중요한 설정을 이해하고, 프로덕션에서는 보안과 백업을 꼭 신경 쓰세요. **실전 팁** 💡 - 프리 티어로 시작해서 실습한 후 삭제하면 비용이 발생하지 않습니다 - 퍼블릭 액세스는 개발 중에만 임시로 허용하고, 프로덕션에서는 반드시 차단하세요 - 엔드포인트 주소와 마스터 비밀번호는 안전하게 보관하세요 --- ## 5. 보안 그룹으로 DB 접근 제어 RDS 인스턴스는 생성했지만 아직 연결할 수 없습니다. 김개발 씨는 MySQL 클라이언트로 접속을 시도했지만 타임아웃 에러만 발생했습니다. "보안 그룹 설정을 확인해봤어?" 박시니어 씨의 한마디에 김개발 씨는 보안 그룹 탭을 열었습니다. **보안 그룹**은 RDS 인스턴스의 방화벽 역할을 합니다. 어떤 IP와 포트에서 접근할 수 있는지 규칙으로 정의합니다. 올바른 보안 그룹 설정 없이는 데이터베이스에 연결할 수 없습니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 RDS 연결 - 보안 그룹이 올바르게 설정되어야 작동 const mysql = require('mysql2/promise'); const connection = await mysql.createConnection({ host: 'my-ecommerce-db.c9akciq32.ap-northeast-2.rds.amazonaws.com', user: 'admin', password: process.env.DB_PASSWORD, database: 'ecommerce', port: 3306, // 이 코드가 실행되는 서버의 IP가 보안 그룹에 허용되어야 함 connectTimeout: 10000 }); // 보안 그룹 규칙 예시 (AWS SDK로 생성) // Inbound Rule: MySQL/Aurora (3306) from EC2 Security Group (sg-xxx) console.log('연결 성공!'); await connection.end(); ``` 박시니어 씨가 설명을 시작했습니다. "보안 그룹을 이해하지 못하면 RDS를 제대로 쓸 수 없어. 이건 정말 중요해." AWS의 모든 리소스는 보안 그룹으로 보호됩니다. RDS도 예외가 아닙니다. **보안 그룹이란?** 보안 그룹은 **가상 방화벽**입니다. 일반적인 방화벽처럼 어떤 트래픽을 허용하고 차단할지 규칙으로 정의합니다. RDS 인스턴스에 할당된 보안 그룹은 누가 데이터베이스에 접근할 수 있는지 결정합니다. 비유하자면, 아파트 출입구의 경비실과 같습니다. 등록된 사람만 출입할 수 있고, 낯선 사람은 차단됩니다. **인바운드 규칙과 아웃바운드 규칙** 보안 그룹에는 두 종류의 규칙이 있습니다. **인바운드 규칙**은 외부에서 들어오는 트래픽을 제어합니다. RDS의 경우 데이터베이스로 들어오는 연결을 의미합니다. **아웃바운드 규칙**은 나가는 트래픽을 제어합니다. 보통 아웃바운드는 모든 트래픽을 허용합니다. RDS 보안 설정에서 중요한 것은 **인바운드 규칙**입니다. **기본 보안 그룹의 문제** 김개발 씨가 생성한 RDS 인스턴스의 보안 그룹을 확인했습니다. 인바운드 규칙이 비어 있었습니다. 즉, 어떤 외부 연결도 허용하지 않는 상태입니다. 당연히 연결이 안 되는 것입니다. **올바른 인바운드 규칙 추가** 박시니어 씨가 시연했습니다. "보안 그룹 탭에서 인바운드 규칙 편집을 클릭해." "규칙 추가" 버튼을 누르면 세 가지를 설정해야 합니다: 유형, 소스, 설명. **유형**은 "MySQL/Aurora"를 선택합니다. 자동으로 포트 3306이 설정됩니다. PostgreSQL이라면 5432 포트를 사용합니다. **소스**가 가장 중요합니다. 어디서 오는 연결을 허용할지 정의합니다. **소스 설정 옵션들** 첫 번째 옵션은 "내 IP"입니다. 현재 사용 중인 컴퓨터의 IP 주소만 허용합니다. 개발 중에 로컬에서 접속할 때 유용합니다. 하지만 IP가 바뀌면 다시 설정해야 합니다. 두 번째는 "Anywhere-IPv4" (0.0.0.0/0)입니다. 인터넷의 모든 IP에서 접속을 허용합니다. **절대 프로덕션에서 사용하면 안 됩니다.** 누구나 데이터베이스에 접속을 시도할 수 있게 되어 보안 위험이 큽니다. 세 번째는 **보안 그룹으로 지정**하는 것입니다. 특정 보안 그룹에 속한 리소스만 허용합니다. 이것이 가장 안전하고 권장되는 방법입니다. **EC2 보안 그룹으로 제한하기** 실무에서는 애플리케이션 서버(EC2)에서만 RDS에 접근하도록 설정합니다. 먼저 EC2 인스턴스의 보안 그룹 ID를 확인합니다. 예를 들어 "sg-0a1b2c3d4e5f6g7h8"이라고 합시다. RDS 보안 그룹의 인바운드 규칙에서 소스를 이 보안 그룹 ID로 설정합니다. 이렇게 하면 해당 보안 그룹에 속한 EC2 인스턴스만 RDS에 연결할 수 있습니다. IP 주소가 바뀌어도 상관없습니다. EC2가 어떤 IP를 가지든, 같은 보안 그룹에 속하면 연결됩니다. **Lambda에서 접근하기** Lambda 함수에서 RDS에 연결하려면 어떻게 해야 할까요? Lambda 함수를 **VPC에 연결**해야 합니다. Lambda 설정에서 VPC, 서브넷, 보안 그룹을 지정합니다. 그리고 RDS 보안 그룹에서 Lambda의 보안 그룹을 허용하면 됩니다. 주의할 점은 Lambda가 VPC에 연결되면 인터넷 접근이 차단된다는 것입니다. NAT Gateway를 설정해야 외부 API를 호출할 수 있습니다. **개발 환경에서의 접근** 개발 중에는 로컬 컴퓨터에서 RDS에 연결해야 할 때가 있습니다. 가장 안전한 방법은 **SSH 터널링**입니다. EC2 인스턴스를 경유하여 RDS에 연결하는 방식입니다. EC2에 SSH로 접속한 후, 포트 포워딩으로 RDS에 연결합니다. 또 다른 방법은 **AWS Systems Manager Session Manager**를 사용하는 것입니다. SSH 키 없이도 안전하게 터널링할 수 있습니다. 임시로 "내 IP"를 허용하는 방법도 있지만, 작업이 끝나면 반드시 규칙을 삭제해야 합니다. **포트 변경하기** 기본 포트(3306)를 사용하지 않고 싶다면 RDS 생성 시 포트를 변경할 수 있습니다. 예를 들어 33060으로 변경하면 보안 그룹에서도 33060 포트를 허용해야 합니다. 포트를 변경하면 자동화된 공격 시도를 어느 정도 방어할 수 있습니다. **규칙 우선순위** 보안 그룹은 **허용 규칙만** 가지고 있습니다. 명시적인 거부 규칙은 없습니다. 허용되지 않은 모든 트래픽은 자동으로 차단됩니다. 여러 규칙이 있으면 하나라도 매칭되면 허용됩니다. **실수 사례** 김개발 씨는 과거에 실수한 경험을 떠올렸습니다. 개발 중에 "Anywhere"로 열어놓고 삭제하는 것을 잊어버렸습니다. 다행히 큰 문제는 없었지만, 보안 스캔에서 경고가 발생했습니다. 또 다른 흔한 실수는 EC2 보안 그룹이 아니라 EC2의 IP를 직접 입력하는 것입니다. IP는 재시작할 때마다 바뀔 수 있으므로 보안 그룹 ID를 사용해야 합니다. **정리** 박시니어 씨가 요약했습니다. "보안 그룹은 최소 권한 원칙을 따라야 해. 필요한 소스에서만, 필요한 포트만 허용하는 거야." 김개발 씨는 EC2 보안 그룹을 소스로 설정하고, MySQL 포트를 허용하는 규칙을 추가했습니다. 이제 애플리케이션에서 정상적으로 RDS에 연결할 수 있습니다. 보안은 타협할 수 없는 영역입니다. 편리함보다 안전함을 우선시하세요. **실전 팁** 💡 - 프로덕션에서는 절대 "Anywhere"를 허용하지 마세요 - EC2 보안 그룹을 소스로 지정하는 것이 가장 안전합니다 - 개발 중에는 SSH 터널링을 사용하세요 --- ## 6. RDS 백업 및 복원 기본 어느 금요일 오후, 김개발 씨는 실수로 중요한 데이터가 담긴 테이블을 삭제했습니다. 얼굴이 하얗게 질렸습니다. "백업은 있겠지?" 박시니어 씨가 침착하게 물었습니다. 다행히 RDS 자동 백업이 활성화되어 있었습니다. RDS는 **자동 백업**과 **수동 스냅샷** 두 가지 백업 방식을 제공합니다. 자동 백업은 매일 전체 백업을 수행하고, 특정 시점으로 복원할 수 있습니다. 데이터 손실을 방지하는 필수 기능입니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 백업 전 데이터 확인 const [rows] = await connection.execute( 'SELECT COUNT(*) as total FROM products' ); console.log(`백업 전 상품 수: ${rows[0].total}`); // 실수로 데이터 삭제 (실제로 하지 마세요!) // await connection.execute('DELETE FROM products'); // AWS SDK로 특정 시점 복원 (Point-in-Time Recovery) const rds = new AWS.RDS({ region: 'ap-northeast-2' }); const restoreParams = { SourceDBInstanceIdentifier: 'my-ecommerce-db', TargetDBInstanceIdentifier: 'my-ecommerce-db-restored', RestoreTime: new Date('2025-01-15T14:30:00Z'), // 삭제 직전 시점 UseLatestRestorableTime: false }; await rds.restoreDBInstanceToPointInTime(restoreParams).promise(); console.log('복원 진행 중...'); ``` 박시니어 씨는 RDS 콘솔의 "유지 관리 및 백업" 탭을 열었습니다. 자동 백업이 활성화되어 있고, 7일간의 백업이 보관되어 있었습니다. "다행이네. 오늘 오후 2시 30분으로 되돌리면 돼." **자동 백업의 작동 원리** RDS 자동 백업은 두 가지 요소로 구성됩니다. 첫째, **일일 전체 백업**입니다. 설정한 백업 시간(예: 새벽 3시)에 데이터베이스 전체의 스냅샷을 생성합니다. 이것은 S3에 자동으로 저장됩니다. 둘째, **트랜잭션 로그 백업**입니다. 5분마다 트랜잭션 로그가 백업됩니다. 이 로그를 이용하면 5분 단위로 특정 시점으로 복원할 수 있습니다. 비유하자면, 전체 백업은 영화의 전체 녹화본이고, 트랜잭션 로그는 실시간 녹화입니다. 둘을 조합하면 정확한 시점으로 되돌릴 수 있습니다. **백업 보관 기간 설정** RDS 생성 시 백업 보관 기간을 설정합니다. 최소 1일부터 최대 35일까지 가능합니다. 기본값은 7일입니다. 보관 기간이 길수록 더 오래된 시점으로 복원할 수 있지만, 스토리지 비용이 증가합니다. 김개발 씨의 경우 7일로 설정했으므로, 최대 일주일 전 시점까지 복원할 수 있습니다. **백업 시간 선택** 백업은 I/O를 많이 사용하므로 성능에 영향을 줍니다. 따라서 **트래픽이 적은 시간대**를 선택해야 합니다. 대부분의 서비스는 새벽 2~4시에 백업을 수행합니다. 사용자가 거의 없는 시간이기 때문입니다. 백업 시간은 30분 단위로 지정할 수 있습니다. 예를 들어 "03:00-03:30" 사이에 백업이 시작됩니다. **Point-in-Time Recovery (PITR)** 김개발 씨가 실수로 테이블을 삭제한 시각은 오후 2시 35분이었습니다. 박시니어 씨는 오후 2시 30분 시점으로 복원하기로 했습니다. RDS 콘솔에서 "작업 > 특정 시점으로 복원"을 선택했습니다. **복원 시 주의사항**이 있습니다. 기존 인스턴스를 덮어쓰는 것이 아니라, **새로운 인스턴스를 생성**합니다. 복원된 인스턴스는 별도의 엔드포인트를 가집니다. **복원 프로세스** 복원 설정에서 복원할 시점을 입력합니다. "최신 복원 가능 시점 사용" 또는 "사용자 지정 시간"을 선택할 수 있습니다. 김개발 씨는 "2025-01-15 14:30:00"을 입력했습니다. 새 인스턴스 식별자를 입력합니다. 예를 들어 "my-ecommerce-db-restored"로 지정했습니다. 나머지 설정(인스턴스 타입, VPC, 보안 그룹)은 원본과 동일하게 설정됩니다. "인스턴스 복원" 버튼을 클릭하면 복원이 시작됩니다. 인스턴스 크기에 따라 10분에서 1시간 정도 걸립니다. **복원 후 검증** 복원된 인스턴스가 "사용 가능" 상태가 되면 연결하여 데이터를 확인합니다. 김개발 씨는 복원된 데이터베이스에 연결하여 삭제된 테이블이 있는지 확인했습니다. 다행히 2시 30분 시점의 데이터가 모두 살아있었습니다. 데이터를 확인한 후, 애플리케이션의 데이터베이스 엔드포인트를 복원된 인스턴스로 변경했습니다. 서비스가 정상화되었습니다. **수동 스냅샷** 자동 백업 외에 **수동 스냅샷**을 만들 수도 있습니다. 중요한 배포 전에 수동 스냅샷을 생성하는 것이 좋습니다. 예를 들어 대규모 데이터 마이그레이션을 수행하기 전에 스냅샷을 만들어두면, 문제가 생겼을 때 빠르게 되돌릴 수 있습니다. 수동 스냅샷은 **보관 기간 제한이 없습니다**. 명시적으로 삭제하지 않는 한 영구 보관됩니다. 단, 스토리지 비용은 계속 청구됩니다. **스냅샷에서 복원하기** 스냅샷에서 복원하는 것은 PITR보다 간단합니다. RDS 콘솔에서 "스냅샷" 메뉴로 이동합니다. 복원할 스냅샷을 선택하고 "작업 > 스냅샷 복원"을 클릭합니다. 새 인스턴스 설정을 입력하고 복원합니다. 스냅샷 복원은 **특정 시점**이 아니라 스냅샷이 생성된 시각의 상태로 복원됩니다. **자동 백업 vs 수동 스냅샷** 두 방식의 차이를 정리하면 다음과 같습니다. **자동 백업**은 매일 자동으로 수행되고, 특정 시점 복원이 가능하지만, 보관 기간이 제한됩니다(최대 35일). RDS 인스턴스를 삭제하면 자동 백업도 함께 삭제됩니다. **수동 스냅샷**은 수동으로 생성하고, 특정 시점이 아니라 스냅샷 시각으로만 복원되지만, 영구 보관됩니다. RDS 인스턴스를 삭제해도 스냅샷은 남아있습니다. **백업 비용** 자동 백업 스토리지는 프로비저닝된 스토리지 크기까지 무료입니다. 예를 들어 RDS 스토리지가 100GB라면, 백업 100GB까지는 무료입니다. 초과분에 대해서만 비용이 청구됩니다. 수동 스냅샷은 모든 용량에 대해 비용이 청구됩니다. 불필요한 스냅샷은 정기적으로 삭제하는 것이 좋습니다. **교차 리전 백업** 재해 복구를 위해 다른 리전에 백업을 복사할 수 있습니다. 예를 들어 서울 리전의 스냅샷을 도쿄 리전에 복사하면, 서울 리전 전체에 장애가 발생해도 도쿄에서 복원할 수 있습니다. 이것은 대규모 서비스에서 사용하는 고급 전략입니다. 소규모 서비스에서는 단일 리전의 Multi-AZ만으로도 충분합니다. **백업 모니터링** 백업이 제대로 수행되는지 모니터링해야 합니다. CloudWatch에서 "OldestBackupCreationTime" 메트릭을 확인하면 백업이 정상적으로 생성되고 있는지 알 수 있습니다. 백업이 실패하면 알림을 받도록 설정하세요. **정리** 박시니어 씨가 말했습니다. "오늘 배운 교훈은 뭐야?" 김개발 씨는 대답했습니다. "백업은 선택이 아니라 필수라는 거요. 그리고 복원 절차를 미리 알아둬야 한다는 것도요." 실제로 복원을 해본 경험은 매우 중요합니다. 재난이 발생했을 때 당황하지 않고 침착하게 대응할 수 있습니다. 여러분도 테스트 환경에서 백업과 복원을 실습해보세요. 그것이 진짜 위기에서 여러분을 구해줄 것입니다. **실전 팁** 💡 - 자동 백업은 반드시 활성화하세요 (최소 7일 보관) - 중요한 작업 전에는 수동 스냅샷을 생성하세요 - 복원 절차를 미리 연습해보는 것이 중요합니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS,RDS,Database

언어: JavaScript

태그: AWS, RDS, Database, MySQL, PostgreSQL, AWS,RDS,Database

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS RDS 관리형 데이터베이스 완벽 가이드

목차

1. RDS(Relational Database Service)란

2. RDS vs 직접 설치 DB 비교

3. 데이터베이스 엔진 선택 (MySQL, PostgreSQL 등)

4. RDS 인스턴스 생성 실습

5. 보안 그룹으로 DB 접근 제어

6. RDS 백업 및 복원 기본

댓글 (0)

함께 보면 좋은 카드 뉴스

VPC 네트워크의 기초 - CIDR과 서브넷 설계 완벽 가이드

AWS 리소스 정리와 비용 관리 완벽 가이드

AWS Certificate Manager로 HTTPS 인증서 발급 완벽 가이드

Route 53으로 도메인 연결 완벽 가이드

AWS Auto Scaling 완벽 가이드