왜 지금 다시 이 질문인가
"자체 서버에 MySQL을 설치할 것인가, RDS를 쓸 것인가"는 클라우드 시대 초반부터 있었던 논쟁이다. 그런데 2026년 현재에도 이 질문은 유효하다. 팀마다 결론이 다르고, 같은 팀도 워크로드에 따라 혼용한다.
이 논쟁이 계속되는 이유는 단순히 비용의 문제가 아니다. 운영 역량, 규정 요건, 확장 방식, 클라우드 종속 수준 등 조직마다 제약이 다르기 때문이다. 이 편은 그 트레이드오프를 구체적으로 정리한다.
매니지드 서비스가 처리해 주는 것
매니지드 데이터베이스 서비스(DBaaS)의 핵심 가치는 운영 부담의 이전이다. 공급자가 처리하는 영역을 구체적으로 살펴보자.
자동 패치와 버전 유지
자체 운영에서 MySQL 버전 업그레이드는 상당한 작업이다. 복제 토폴로지를 정리하고, 하위 호환성을 검증하고, 롤백 플랜을 짜야 한다. 매니지드 서비스는 minor version 패치를 유지보수 윈도우에 자동으로 적용한다. major version 업그레이드는 사용자가 트리거하지만, 공급자가 프리체크 도구와 가이드를 제공한다.
AWS RDS의 경우 auto minor version upgrade 설정을 켜두면 5.7.x → 5.7.latest 같은 minor 업그레이드가 자동으로 진행된다. major는 RDS 콘솔에서 수동 승인 후 진행된다.
자동 백업과 스냅샷
RDS는 기본적으로 1~35일 보존 기간의 자동 스냅샷을 제공한다. 스냅샷에서 특정 시점으로 복구(PITR)도 지원한다. 자체 운영에서 xtrabackup을 스케줄링하고 원격 스토리지에 올리고 보존 정책을 관리하는 작업을 공급자가 대신한다.
고가용성과 페일오버
Multi-AZ를 활성화하면 동기 복제 standby가 자동 구성된다. 주 인스턴스 장애 시 1~2분 내 페일오버가 자동으로 진행된다. 이 메커니즘을 자체 구축하려면 Orchestrator/Pacemaker 같은 HA 솔루션을 설치·설정·검증해야 한다.
스토리지 자동 확장
RDS는 디스크 사용량이 임계값(기본 10%)을 넘으면 스토리지를 자동으로 늘린다. 자체 운영에서는 파티션을 모니터링하다가 디스크가 꽉 차기 전에 수동으로 확장해야 한다.
사용자가 여전히 소유하는 것
매니지드 서비스가 인프라를 처리하더라도, 데이터베이스 운영의 절반은 여전히 사용자 몫이다.
쿼리 성능과 인덱스
공급자는 쿼리가 느린 것을 막아주지 않는다. slow query log를 직접 분석하고, 실행계획을 읽고, 인덱스를 추가·제거해야 한다. RDS Performance Insights 같은 도구가 도움을 주지만, 의사결정은 사용자가 한다.
파라미터 그룹 튜닝
RDS는 파라미터 그룹을 통해 일부 DB 설정을 조정할 수 있다. 그러나 노출된 파라미터는 제한적이다. innodb_flush_method 같은 파라미터는 고정값이다. OS 레벨 설정(swappiness, I/O 스케줄러)은 접근 불가다.
비용 최적화
인스턴스 타입 선택, 스토리지 타입(gp3 vs io1), Reserved Instance 구매 타이밍은 모두 사용자 책임이다. 공급자는 고비용 구성을 막아주지 않는다.
스키마 변경과 접근 제어
Online DDL 전략, 점진적 마이그레이션 계획, 사용자 권한 분리 등은 공급자가 대신하지 않는다.
주요 매니지드 DB 서비스 비교
| 서비스 | 공급자 | 주요 엔진 | 특징 |
|---|---|---|---|
| Amazon RDS | AWS | MySQL, PostgreSQL, MariaDB, Oracle, SQL Server | 가장 넓은 엔진 지원 |
| Amazon Aurora | AWS | MySQL 호환, PostgreSQL 호환 | 클라우드 네이티브 스토리지, 고성능 |
| Google Cloud SQL | GCP | MySQL, PostgreSQL, SQL Server | GCP 생태계 통합 |
| Azure Database | Azure | MySQL, PostgreSQL, MariaDB | Azure AD 통합, Hyperscale |
| Neon | 독립 | PostgreSQL | 서버리스, scale-to-zero, branching |
| PlanetScale | 독립 | MySQL (Vitess) | sharding 내재화, 브랜치 기반 스키마 변경 |
| Supabase | 독립 | PostgreSQL | BaaS, 실시간, Auth 통합 |
비용 현실: 숫자로 보는 비교
2026년 기준 실제 비용 분석을 보면 단순 인프라 비용만으로 판단하면 안 된다는 점이 분명해진다.
시나리오: PostgreSQL, 4 vCPU, 16GB RAM, 500GB SSD, Multi-AZ, 미국 동부
| 항목 | RDS Multi-AZ | EC2 자체 운영 (인프라만) | EC2 자체 운영 (엔지니어링 포함) |
|---|---|---|---|
| 월 비용 | ~$744 | ~$332 | ~$832+ |
| 운영 인력 | 낮음 | 높음 | — |
| 장애 대응 | 자동 페일오버 | 수동 또는 HA 도구 필요 | — |
| 확장성 | 콘솔 클릭 | LVM 확장·재부팅 가능성 | — |
엔지니어링 포함 비용은 DB 운영에 소요되는 SRE/DBA 시간을 월 비용으로 환산한 추정치.
자체 운영이 저렴해 보이는 이유는 운영 인력 비용을 숨기기 때문이다. 실제로 패치, 백업 검증, 페일오버 테스트, 용량 계획에 드는 시간을 더하면 대규모 팀이 아닌 경우 자체 운영이 더 비싸지는 경우가 많다.
반대로 수백 노드를 운영하는 대형 조직이나 특수 요건이 있는 경우에는 자체 운영이 경제적일 수 있다.
매니지드 서비스의 실제 제약
익스텐션 제약
PostgreSQL의 timescaledb, citus, pg_cron 같은 확장은 모든 매니지드 서비스에서 지원하지 않는다. AWS RDS for PostgreSQL은 지원 익스텐션 목록을 공식 문서로 제공하며, 목록에 없는 것은 설치 불가다. Aurora PostgreSQL도 별도 목록을 유지한다.
OS 접근 불가
perf, strace, tcpdump 같은 OS 레벨 진단 도구를 사용할 수 없다. DB 엔진 내부 지표(SHOW ENGINE INNODB STATUS, pg_stat_*)와 공급자 제공 모니터링만 사용 가능하다.
일부 파라미터 고정
InnoDB의 innodb_flush_method는 RDS에서 변경 불가다(공급자가 최적값으로 고정). huge_pages, 일부 innodb_* 파라미터도 제한된다.
규정 준수 및 데이터 주권
데이터가 공급자 인프라에 올라간다는 점에서 일부 산업·지역 규정(금융, 의료, 공공)에서 매니지드 클라우드 서비스 사용이 제한될 수 있다. 퍼블릭 클라우드를 허용하더라도 특정 리전에만 데이터를 저장해야 하는 데이터 주권 요건이 있을 수 있다.
언제 무엇을 선택할 것인가
매니지드 서비스가 유리한 경우
- 운영 인력이 적고 DB 전문가가 없는 팀
- 빠른 스타트업, 예측 불가한 트래픽 증가
- 표준 엔진(MySQL, PostgreSQL)을 제약 없이 사용하는 경우
- HA와 백업을 확실히 보장해야 하지만 직접 구축할 시간이 없는 경우
- 클라우드 네이티브 기능(IAM 통합, VPC 격리, CloudWatch 연동)이 필요한 경우
자체 운영이 유리한 경우
- 매우 많은 수의 인스턴스를 운영하고 원가 압박이 강한 경우
- 특수 익스텐션이 필요하거나 OS 레벨 튜닝이 필수인 경우
- 특정 파라미터 조합 또는 커스텀 패치가 필요한 경우
- 온프레미스에 이미 운영 중이고 클라우드 마이그레이션 비용이 큰 경우
- 데이터 주권·규정으로 퍼블릭 클라우드 사용이 제한된 경우
하이브리드 전략
2026년 현재 많은 팀이 단일 모델을 고집하지 않는다. 고객 대면 서비스 DB는 매니지드로 안정성을 보장하고, 분석·스테이징·대용량 데이터 파이프라인 DB는 자체 운영으로 비용을 통제하는 혼합 전략이 현실적이다.
의사결정 체크리스트
매니지드 서비스 도입을 검토할 때 아래 질문에 답해보면 결정이 명확해진다.
- [ ] 우리 팀에 DB 엔진을 전담 운영할 인력이 있는가?
- [ ] 필요한 모든 익스텐션이 해당 서비스에서 지원되는가?
- [ ] 월 비용을 비교할 때 엔지니어링 인건비를 포함했는가?
- [ ] 데이터 주권·규정 요건이 특정 클라우드를 제한하는가?
- [ ] OS 레벨 접근이 필수인 튜닝 요건이 있는가?
- [ ] 공급자 락인을 감수할 수 있는 비즈니스 판단이 서 있는가?
References
- AWS Documentation, "Amazon Relational Database Service (RDS)": https://aws.amazon.com/rds/
- selfhost.dev, "Managed vs Self Hosted Database: A 2026 Guide": https://selfhost.dev/blog/managed-vs-self-hosted-database-5-reasons/
- sshploy, "Self-Hosting vs Managed Databases: A Practical Cost & Control Comparison": https://sshploy.com/guides/self-hosting-vs-managed-databases
- UpCloud, "Self-Hosted vs. Managed Databases in 2026: Key Insights": https://upcloud.com/global/blog/self-hosted-vs-managed-databases-2026-guide/
- EnterpriseDB, "What Is Database as a Service (DBaaS)?": https://www.enterprisedb.com/blog/what-database-service-dbaas-tutorial-how-use-managed-database-service-postgresql
- AWS Blogs, "Choose the right Amazon RDS deployment option": https://aws.amazon.com/blogs/database/choose-the-right-amazon-rds-deployment-option-single-az-instance-multi-az-instance-or-multi-az-database-cluster/
- Percona Blog, "AWS Aurora MySQL – HA, DR, and Durability Explained in Simple Terms": https://www.percona.com/blog/aws-aurora-mysql-ha-dr-and-durability-explained-in-simple-terms/