"DB를 EC2에 직접 깔까, RDS를 쓸까?" 클라우드를 배우면 이런 갈림길을 만납니다. 매니지드 서비스(관리형 서비스)는 설치·패치·백업·장애 복구 같은 운영 작업을 클라우드가 대신 해주는 서비스입니다. 나는 DB를 깔고 관리하는 게 아니라, 만들어진 DB를 받아 쓰기만 합니다. 운영의 귀찮은 부분을 위임하고 본업에 집중하게 해주는 게 핵심입니다.
직접 운영 vs 매니지드
관리형 DB를 예로, 누가 무엇을 책임지는지 보면 차이가 분명해집니다.
| 작업 | 직접 운영 (EC2에 설치) | 매니지드 (RDS 등) |
|---|---|---|
| 서버·OS 설치 | 내가 | 제공업체 |
| DB 설치·버전 패치 | 내가 | 제공업체 |
| 백업·복구 설정 | 내가 | 제공업체(자동) |
| 장애 시 복구 | 내가 새벽에 | 제공업체(자동 페일오버) |
| 스키마·쿼리 | 내가 | 내가 |
매니지드를 써도 스키마 설계와 쿼리는 여전히 내 몫입니다. 위임되는 건 "DB라는 소프트웨어를 살아 있게 유지하는 운영 노동"입니다.
시나리오로 보는 차이
새벽 3시에 DB 디스크가 가득 차 서비스가 멈춘 상황을 가정해 봅니다.
TEXT
[직접 운영]
알람 → 내가 깸 → SSH 접속 → 디스크 증설 →
DB 재시작 → 복구 확인 (30분~수 시간, 내 손)
[매니지드]
스토리지 자동 확장 설정 → 임계치 도달 시 자동 증설
장애 시 대기 인스턴스로 자동 페일오버 (사람 개입 최소)
직접 운영은 자유도가 높지만, 모든 야간 장애가 내 호출기로 옵니다. 매니지드는 이런 운영 시나리오 상당수를 제공업체가 자동화해 둡니다. 대신 OS 커널을 건드린다거나 특정 확장 기능을 마음대로 설치하는 등의 깊은 제어는 제한될 수 있습니다.
언제 무엇을 고르나
| 상황 | 추천 | 이유 |
|---|---|---|
| 운영 인력이 적은 팀 | 매니지드 | 운영 노동을 위임, 본업 집중 |
| 빠른 출시가 중요 | 매니지드 | 설정 즉시 사용 가능 |
| 특수 커널·확장 제어 필요 | 직접 운영 | 매니지드는 제어 제한 |
| 비용을 극단적으로 깎아야 함 | 경우에 따라 직접 | 매니지드는 편의 비용이 붙음 |
판단 기준은 "이 운영을 내가 직접 해서 얻는 이득이, 그 수고와 장애 위험보다 큰가?"입니다. 대부분의 일반적인 워크로드에서는 매니지드를 먼저 검토하는 편이 합리적입니다.
요점 정리
- 매니지드 서비스는 설치·패치·백업·복구 같은 운영을 클라우드가 대신해 준다.
- 관리형 DB를 써도 스키마와 쿼리는 여전히 내 책임이다.
- 편의를 얻는 대신 깊은 제어와 비용 면에서 트레이드오프가 있어, 제어가 꼭 필요할 때만 직접 운영을 택한다.
관리형 서비스와 직접 설치형의 운영 부담이 실제로 어떻게 다른지 비교해 보는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.