리프트 앤 시프트가 실패하는 이유

한 줄 요약

있는 그대로 옮기면(lift and shift) 대개 더 비싸집니다. 온프레미스는
사 놓은 자원을 다 쓰는 구조이고, 클라우드는 쓴 만큼 내는 구조라 설계 전제가
반대이기 때문입니다.

왜 이게 필요했나

"서버 30대를 그대로 클라우드에 올렸더니 비용이 2배가 됐다" 는 사례는 아주
흔합니다. 각각을 따져 보면 이렇습니다.

• 온프레미스 서버는 피크 기준으로 샀고, 평소 CPU 사용률은 10~20% 입니다.

그 사양 그대로 인스턴스를 띄우면 놀고 있는 자원에 매달 돈을 냅니다.

• 온프레미스에서 네트워크는 공짜였습니다. 클라우드에서는 리전 밖으로

나가는 트래픽마다 요금이 붙습니다.

• 백업·복제를 위해 쓰던 스토리지가 전부 과금 대상이 됩니다.

즉 옮기기 전에 크기를 다시 재고(right-sizing), 안 쓰는 시간에는 끄고,
트래픽 경로를 다시 그려야 값이 납니다. 그 작업을 안 하면 클라우드는
그냥 비싼 데이터센터입니다.

이관 제외 기준

옮기지 않는 편이 나은 것들

| 대상 | 이유 |
| --- | --- |
| 24시간 만재로 도는 대규모 배치 | 종량제의 이점이 없다. 사서 쓰는 게 싸다 |
| 초저지연이 필요한 시스템 | 물리적으로 옆에 두어야 하는 경우가 있다 |
| 특수 하드웨어 의존 | 라이선스 동글, 특정 카드, 산업용 인터페이스 |
| 데이터 국외 이전 금지 대상 | 리전이 없으면 애초에 불가 |
| 이미 감가상각이 끝난 안정 시스템 | 잘 도는 것을 옮기는 데도 비용이 든다 |
| 대용량을 자주 내보내는 워크로드 | 이그레스 요금이 본전을 먹는다 |

마지막 줄이 자주 간과됩니다. 들어오는 트래픽은 대개 무료인데 **나가는 트래픽
(egress)** 은 비쌉니다. 대용량 파일을 계속 외부로 내보내는 서비스라면
클라우드 요금의 대부분이 여기서 나옵니다.

하이브리드가 답인 경우

전부 아니면 전무로 볼 필요가 없습니다.

• 변동이 큰 앞단만 클라우드 — 트래픽 급증을 흡수하고, 안정적인 백엔드는

온프레미스에 둡니다.

• 재해복구만 클라우드 — 평소에는 최소로 두고 유사시에만 키웁니다.

종량제의 값이 가장 잘 드러나는 용도입니다.

• 개발·테스트만 클라우드 — 필요할 때만 만들고 끝나면 지웁니다.

옮기기로 했다면 순서

1. 인벤토리 — 무엇이 무엇에 의존하는지 그린다. 이게 없으면 그다음이 없다.
2. 분류 — 그대로 옮길 것 / 다시 만들 것 / 관리형으로 바꿀 것 / 버릴 것.
버릴 것을 찾는 게 실제로 가장 값이 큽니다. 아무도 안 쓰는 서버가 늘 있습니다.
3. 크기 재산정 — 실사용 지표 기준으로. 피크 기준 사양을 그대로 쓰지 않는다.
4. 작은 것부터 — 되돌릴 수 있는 것으로 시작해 절차를 다듬는다.
5. 비용 관측 — 옮긴 첫 달부터 태그 기준으로 본다. 나중에 붙이면 못 붙인다.

현장에서 만나는 모습

• 이관 후 비용이 2배 → 크기 재산정을 안 했다.
• 이그레스 요금이 컴퓨팅보다 큼 → 트래픽 성격을 안 봤다.
• 절반쯤 옮기다 중단, 양쪽 다 관리 → 의존 관계를 그리지 않고 시작했다.

다음 코스

권한. 클라우드에서 사고가 가장 자주 나는 자리이고, 계정 없이도 정책 문서를
직접 쓰며 배울 수 있는 영역입니다.