Why Managed Looks Expensive

한 줄 요약

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

왜 이게 필요했나

"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번을 처음에 확인하는 팀이 드문데, 나중에 가장 비싸게 값을 치릅니다.

직접 운영할 때 실제로 드는 것

관리형과 자체 운영의 요금표만 비교하면 언제나 자체 운영이 싸 보입니다. 요금표에 없는 것을 함께 세야 비교가 성립합니다.

항목	자체 운영	관리형
인스턴스·스토리지	요금표대로	요금표대로(대개 1.5~3배)
고가용성 구성	대기 노드 비용 + 구성 시간	포함(또는 스위치 하나)
백업·복구 리허설	사람이 설계·검증	포함, 시점 복구 클릭
판올림	분기마다 계획·리허설·창구	창을 고르면 끝
당직	사람이 새벽에 깬다	대개 안 깬다
모니터링·경보	구축·유지	기본 대시보드

가장 큰 항목이 마지막 셋입니다. DB 판올림 한 번에 엔지니어 이틀이 든다면, 연 4회 로 8일입니다. 인건비를 하루 60만원으로 잡으면 480만원 — 인스턴스 몇 대 값입니다.

판단을 숫자 한 줄로

자체 운영 총비용 = 인프라 + (연간 운영 시간 × 시간당 인건비) + 사고 비용 기댓값
관리형 총비용   = 인프라(비싼 값) + (남는 시간 × 그 시간에 만들 가치)

마지막 항이 핵심입니다. 관리형을 사는 것은 시간을 사는 것 이고, 그 시간에 제품을 만들 수 있으면 남는 장사입니다. 반대로 인원이 충분하고 특수한 튜닝이 필요하면 자체 운영이 맞습니다.

잠금(lock-in)을 값으로 환산하기

관리형의 진짜 대가는 요금이 아니라 떠나기 어려움 입니다. 다만 이것도 정도가 있습니다.

유형	잠금 정도	예
표준 프로토콜 그대로	낮다	관리형 PostgreSQL·Redis·Kafka
표준 + 독자 확장	중간	Aurora, ElastiCache 의 확장 기능
완전 독자 API	높다	DynamoDB, Firestore, 서버리스 함수

첫 줄은 사실상 잠금이 없습니다. 같은 프로토콜을 쓰는 다른 곳으로 덤프하고 옮기면 됩니다. 잠금이 걱정되면 표준 프로토콜 관리형부터 씁니다. 독자 API 를 쓸 때는 그 이점이 이전 비용을 넘는지 먼저 계산합니다.

현장에서 만나는 모습

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

다음에 볼 것

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