관리형이 비싸 보이는 이유

한 줄 요약

관리형 서비스의 값은 요금표를 직접 비교하면 항상 비싸 보입니다. 빠져 있는
항목이 있기 때문입니다 — 우리 시간, 그리고 우리가 못 하게 될 일.

왜 이게 필요했나

"RDS 가 EC2 에 직접 깐 것보다 두 배" 라는 비교가 회의에서 자주 나옵니다.
숫자는 맞습니다. 그런데 그 비교표에는 이런 줄이 없습니다.

| 빠진 항목 | 직접 운영이면 |
| --- | --- |
| 패치 계획·적용 | 분기마다 며칠, 야간 작업 |
| 백업 설정·검증 | 초기 구축 + 복구 리허설 |
| 이중화 구성 | 복제 설정·페일오버 테스트 |
| 모니터링 | 지표 수집·알림 규칙 작성 |
| 장애 대응 | 새벽 호출. 빈도는 낮지만 0이 아니다 |
| 버전 업그레이드 | 몇 년에 한 번, 매번 큰 작업 |

이걸 사람의 시간으로 환산하면 대개 요금 차액을 넘습니다. 특히 팀이 작을수록
그렇습니다 — 3명짜리 팀에서 한 명이 DB 운영에 20% 를 쓰면, 그건 인건비의
6~7% 이고 웬만한 관리형 요금 차액보다 큽니다.

관리형 선택의 예외

그런데 항상 관리형이 답은 아니다

반대 방향의 계산도 해야 합니다.

• 규모가 아주 크면 직접 운영의 단위 비용이 훨씬 낮아집니다. 수백 대

규모에서는 전담 인력을 두는 편이 쌉니다.

• 부하가 특이하면 관리형의 기본 설정이 안 맞습니다. 튜닝 여지가 없어

돈으로만 해결하게 되고, 그게 더 비쌉니다.

• 이미 잘 하고 있으면 굳이 옮길 이유가 없습니다. 잘 도는 것을 바꾸는 데도

비용이 듭니다.

판단을 숫자로 만드는 방법

세 줄만 적어 보면 대개 결론이 납니다.

1. 월 요금 차액                      = ( 관리형 − 직접 ) 원2. 직접 운영에 드는 월 인시(person-hours)3. 인시 × 시간당 비용                 = 숨은 비용 원2+3 이 1 보다 크면 관리형이 싸다.

여기에 한 줄을 더 얹으면 정확해집니다 — 그 시간에 하지 못한 일의 값.
DB 를 돌보느라 못 만든 기능이 있다면 그게 진짜 비용입니다.

관리형으로 옮길 때 확인할 목록

1. 필요한 버전과 확장이 지원되는가
2. 연결 수·성능 한도가 우리 부하를 견디는가
3. 백업 보존과 복구 시간(RTO) 이 요건에 맞는가
4. 로그와 지표를 우리가 필요한 만큼 볼 수 있는가
5. 유지보수 창을 우리가 정할 수 있는가
6. 나갈 때 데이터를 어떻게 꺼내는가

6번을 처음에 확인하는 팀이 드문데, 나중에 가장 비싸게 값을 치릅니다.

현장에서 만나는 모습

• 요금만 비교해 직접 운영 → 6개월 뒤 담당자가 퇴사하며 아무도 모르는 상태.
• 관리형으로 옮겼는데 연결 수 한도에 걸림 → 사전 확인 누락.
• 관리형 비용이 커져 되돌리려니 데이터 내보내기가 막막함 → 6번을 안 봤다.

다음에 볼 것

마지막으로, 클라우드로 옮기지 말아야 할 것을 이야기합니다.