🔥 RDS란 무엇인가: 관리형 DB의 의미

처음 EC2 인스턴스 하나 띄워서 그 위에 MySQL을 직접 깔아 본 적이 있다. apt install mysql-server로 설치하고, mysql_secure_installation을 돌리고, /etc/mysql/mysql.conf.d/mysqld.cnf에서 bind-address를 고치고, security group에 3306을 열고, CREATE USER로 계정을 만들고, 그제야 애플리케이션이 붙었다. 처음 한 번은 '내가 DB 운영자가 됐구나' 하는 기분이 들어서 좋았다.

다음 주에 일이 생겼다. Ubuntu 보안 패치가 떴는데 재부팅이 필요했다. 한밤에 트래픽이 적은 시간을 골라 패치하고 재부팅했더니 인스턴스가 다시 안 올라왔다. 데이터는 EBS 볼륨에 살아 있었지만, 새 인스턴스를 띄워 그 볼륨을 붙이고, MySQL을 다시 깔고, my.cnf를 다시 짜고, replica가 있었다면 자동 failover도 직접 구성해야 한다는 사실에 정신이 들었다. 내가 운영하기로 사인한 범위는 데이터베이스가 아니라 DB가 도는 OS와 디스크와 백업과 복제 전부였다.

RDS는 같은 문제에 다른 답을 준다. RDS는 AWS가 관리하는 관계형 데이터베이스 서비스다. 정의보다 실무에서 결정적인 점은, 어디까지가 자동이고 어디부터 내 책임인지의 경계다.

'관리형'이 자동으로 굴리는 일

AWS 공식 문서 'What is Amazon RDS?' 페이지에 자동 작업이 일곱 가지로 적혀 있다.

"Amazon RDS automates time-consuming administration tasks such as hardware provisioning, database setup, patching, and backups."

(Amazon RDS는 hardware provisioning, database setup, patching, backup 같은 시간 소모적인 관리 작업을 자동화한다.)

본문에는 이 일곱 작업이 다음과 같이 적혀 있다. provisioning(인프라 발급), patching(OS·DB 엔진 마이너 버전), backup(스냅샷), failure detection(헬스체크), recovery(failover), monitoring(메트릭), scaling(스토리지·인스턴스 크기 변경). 한 단어 'managed'가 가리키는 자동의 폭이 이 일곱 작업이다.

이 일곱 작업이 자동인 이유는 단순하다. 모든 워크로드에서 절차가 똑같기 때문이다. PostgreSQL 16의 마이너 패치를 직접 깔든 RDS가 깔든 결과 binary는 같다. EBS 볼륨에서 S3로 스냅샷을 떠 두든 RDS가 자동으로 떠 두든 결과 byte도 같다. 차이가 안 나는 작업을 워크로드마다 다시 짤 이유가 없으므로 AWS가 한 번 짜서 모두에게 빌려준다. 'undifferentiated heavy lifting'(차이가 안 나는 무거운 작업)이라는 표현이 이 자동의 근거로 자주 등장한다.

자동 backup의 디폴트 보존 기간 한 가지를 짚어 둔다. 콘솔에서 RDS instance를 만들면 backup retention period의 기본값이 7일이고, AWS CLI나 RDS API로 만들면 기본값이 1일이다. 같은 기능에 두 디폴트가 있는 이유는 AWS 콘솔이 운영 표준에 더 가까운 값을 자동으로 채워 주기 때문이다. 직접 IaC로 띄우는 환경에서는 이 한 가지를 빼먹는 순간 backup 보존 기간 1일로 운영을 시작한다. BackupRetentionPeriod 파라미터를 명시하는 게 표준이다. 보존 기간은 0(자동 backup 비활성)부터 35일까지 설정 가능하다.

내가 만지는 부분은 application 코드와 RDS endpoint(DNS), 위쪽 두 단계다. endpoint를 적은 connection string으로 연결하고, SQL을 던지고, 결과를 받는다. 그 아래 DB engine binary, EBS 위 storage, S3로 가는 snapshot은 AWS가 자동으로 운영한다. EC2 위 self-host에서는 이 세 가지가 모두 내 책임이었다.

엔진과 플랫폼의 분리

RDS는 플랫폼과 엔진이 분리돼 있다.

플랫폼은 한 묶음이다. 자동 backup, Multi-AZ failover, automated minor version upgrade, CloudWatch metric, 자동 패치 윈도우, IAM 통합, VPC 안 배치, KMS 암호화, parameter group 추상. 이 묶음은 어떤 엔진을 고르든 같은 방식으로 동작한다. 엔진은 그 위에 끼워 넣는 부속품이다. 2026년 4월 기준 RDS가 지원하는 엔진은 일곱 가지다.

엔진	첫 RDS 지원	라이선스	비고
MySQL	2009-10-27	open source	RDS의 첫 엔진
Oracle	2011-05-23	commercial	License Included / BYOL
SQL Server	2012-05	commercial	License Included / BYOL
PostgreSQL	2013-11	open source
Aurora	2015-07 GA	AWS proprietary	MySQL·PostgreSQL 호환, 분산 스토리지
MariaDB	2015-10	open source	MySQL fork
Db2	2023-11-27	commercial (IBM)	BYOL, 가장 최근 합류

Aurora는 RDS DB 엔진의 한 종류로 분류되지만, 스토리지가 다른 6개 엔진과 결정적으로 다르다. 3개 가용영역(AZ)에 각 2개씩 총 6개 복제로 분산된 스토리지를 쓴다.

엔진과 플랫폼이 분리되면 운영 구조가 거의 안 바뀐다. PostgreSQL 인스턴스를 MySQL로 바꾸려면 데이터 마이그레이션이 필요하지만, parameter group 다루는 콘솔 위치, snapshot 만드는 API, Multi-AZ 켜는 옵션, CloudWatch에서 보는 메트릭 이름은 일곱 엔진 모두 동일하다. 한 번 RDS를 익히면 일곱 엔진 모두에 같은 운영 절차가 통한다.

자동과 비자동의 경계

자동의 폭이 일곱 작업이라고 적었지만, 비자동 쪽도 같은 폭으로 길다. 이 경계가 운영자가 사인하는 영역이다.

내 몫에 남는 항목은 다음과 같다. 데이터 모델링은 RDS가 정하지 않는다. 어떤 테이블을 만들지, 어떤 컬럼을 NULL 허용으로 둘지는 내 결정이다. 인덱스도 어떤 컬럼에 걸지, 복합 인덱스 컬럼 순서를 어떻게 짤지가 모두 내 책임이다. 쿼리 튜닝에서는 EXPLAIN ANALYZE를 읽고 plan을 보는 단계가 내 몫이고, RDS는 Performance Insights라는 관측 도구를 빌려줄 뿐이다. 마이그레이션도 스키마 변경, 컬럼 추가, 인덱스 재구성을 내가 짠다. RDS는 자동 minor 패치는 해 주지만 내 데이터 자체에 대한 변경은 절대 자동으로 안 한다.

RDS는 내 데이터에 손대지 않는다. EBS 위에 byte를 그대로 두고, 엔진 binary를 패치하고, 그 binary가 byte를 어떻게 해석할지는 내 SQL이 결정한다. 이 점이 'managed'와 'serverless'의 차이이기도 하다. RDS는 managed지만 schema·index·query는 내 책임 영역에 그대로 남아 있다. DynamoDB 같은 managed NoSQL이 'no schema design needed'라고 광고하는 논리와는 다르다.

운영자가 사인하는 항목 하나가 더 있다. 변경 윈도우 결정이다. 자동 minor version upgrade가 활성화돼 있으면(콘솔 디폴트 ON) RDS가 자동으로 패치를 깐다. 다만 언제 깔지는 내가 지정한 maintenance window 안에서만 일어난다. 토요일 새벽 3시처럼 트래픽이 적은 시간대를 선언해 둬야 하는 결정이고, 그걸 기본값(임의 시간대)으로 두면 평일 한낮에 30초짜리 connection blip이 들어올 수 있다. 비자동인 게 문제가 아니라, 자동의 시각을 내가 들고 있어야 한다.

'관리형'이 감추는 비용

managed는 운영 부담을 줄이지만 청구서가 사라지는 건 아니다. 오히려 AWS는 RDS 청구를 EC2 청구보다 더 잘게 나누고, 비용 항목도 다섯 가지로 잡는다.

첫째는 DB instance hour다. db.t·db.m·db.r·db.x 4개 family 안에서 인스턴스 크기를 고르고, 시간당 단가가 붙는다. AWS는 2019-04-25부터 RDS 비용을 1초 단위로 계산한다. 다만 인스턴스를 생성·복원·시작하면 AWS가 최소 10분을 하한으로 둔다. 정상 운영 중인 인스턴스에는 floor가 안 걸리지만, 자동화 스크립트로 잠깐 띄웠다 끄는 패턴에서는 10분 floor가 빈번히 등장한다.

둘째는 storage GB-월이다. gp3는 General Purpose SSD로 운영 표준에 가깝고, io2 Block Express는 sub-millisecond 지연이 필요한 OLTP용이다. 2026-04-30부터 magnetic storage(legacy)는 deprecation 상태로 들어가서 신규 RDS instance를 magnetic으로 만들 수 없고, 기존 magnetic 볼륨은 2026-04-29 이후 AWS가 자동으로 gp3로 이전한다. 오늘은 RDS 스토리지를 gp3와 io2 가운데서 고른다. 단가는 gp3가 io2의 약 3분의 1 수준이지만, io2는 IOPS 256,000까지 올라가고 durability가 99.999%라는 점에서 차이가 난다.

셋째는 provisioned IOPS다. AWS는 gp3에서 baseline IOPS 3,000을 넘긴 만큼만 추가 IOPS 비용을 붙이고, io2는 잡은 모든 IOPS에 비용을 붙인다. 셀프 호스트에서는 EBS 볼륨에 직접 IOPS를 사면 됐는데, RDS에서는 storage type에 따라 청구 방식이 다르다.

넷째는 backup storage다. AWS는 자동 backup이 차지한 S3 공간에서도 DB 크기를 넘긴 부분만 GB-월로 청구한다. 35일 보존을 잡고 매일 큰 데이터 변경이 있으면 backup이 DB 크기의 몇 배까지 부풀고, 그 차이가 청구서에 그대로 들어온다. 보존을 7일 default 그대로 두는 결정이 흔히 silent 비용 절감인 이유다.

다섯째는 data transfer out(DTO)이다. 같은 AZ 안에서는 무료, 같은 리전 다른 AZ는 GB당 $0.01–0.02, 인터넷으로 나가면 첫 100GB 무료 후 $0.09/GB. RDS endpoint를 다른 AZ의 EC2에서 부르는 패턴이 자주 보이는데, 그게 DTO 청구의 주된 진입점이다.

다섯 항목을 하나씩 놓고 비교하면 셀프 호스트와 RDS가 어디서 비용을 나누는지 바로 집어낼 수 있다. EC2 위 MySQL에서는 인스턴스 시간과 EBS 스토리지가 청구의 대부분을 차지하고, backup 비용은 내가 S3에 직접 쓴 바이트 수에 가격표를 곱해서 계산한다. RDS는 같은 다섯 항목이 모두 RDS 라인 안에 따로 들어간다. 청구서를 처음 받았을 때 'managed라는 단어가 더 비싸 보이는' 이유는, 사실 EC2에서도 같은 다섯 항목이 흩어져 있었지만 RDS 라인 한 줄에 모두 모아 보여주기 때문이기도 하다.

답이 아닌 경우

모든 RDBMS 워크로드가 RDS로 가는 게 옳지는 않다. 답이 아닌 경우는 세 가지다.

첫째, 단일 인스턴스 사이드 프로젝트다. 트래픽이 적고 데이터가 1GB 안쪽이면 RDS의 가장 작은 db.t4g.micro도 매월 약 $13 인스턴스 비용이 먼저 붙는다. 같은 워크로드를 EC2 t4g.nano + EBS gp3 위에 직접 깔면 인스턴스 비용 자체가 절반 이하로 줄어든다. 이 규모에서는 백업 복구, 패치, 장애 전환 같은 작업을 매일 처리하지 않으니 자동화에 돈을 더 얹을 이유도 약하다. 관리형의 가치는 반복되는 작업에 비례한다.

둘째, PostgreSQL/MySQL의 가장 최신 마이너 버전을 즉시 써야 하는 워크로드. RDS는 stable 마이너 버전을 골라 검증한 뒤에 deploy하기 때문에, 업스트림이 어제 내놓은 마이너 버전도 RDS 팀은 보통 몇 주 뒤에 반영한다. 보안 CVE 한 줄 때문에 패치 timeline을 직접 들고 있어야 하는 환경이라면 self-host 또는 RDS Custom 쪽을 고른다.

셋째, OS 레벨 권한이 필요한 환경. 어떤 Oracle 워크로드는 OS 안에서 직접 patch를 깔거나 file system 옵션을 손대야 한다. RDS는 OS root 권한을 안 주기 때문에 그런 워크로드는 RDS Custom(2021-10-26 출시) 쪽으로 가거나, EC2 위 self-host로 돌아가야 한다. RDS Custom은 자동의 폭이 표준 RDS보다 좁고, OS·DB 패치 결정을 사용자가 들고 있다.

RDS 콘솔에서 먼저 확인할 항목

비용과 운영 책임을 끝까지 나눠 보고 나면 나는 RDS 콘솔에서 비용 항목과 책임 경계부터 확인한다. 자동 backup 옵션, parameter group 화면, maintenance window 설정은 모두 같은 일곱 자동 작업의 다른 인터페이스다. 청구서의 다섯 항목은 EC2에서도 어디선가 청구되던 비용이고, 다만 RDS는 그걸 한 라인에 모아 보여줄 뿐이다.

다음에 RDS 인스턴스를 띄울 때는 세 가지부터 짚는다. 일곱 자동 작업, 다섯 청구 항목, 그리고 내 책임 영역(데이터 모델·인덱스·쿼리·maintenance window). 이 세 가지가 RDS의 의미다.