클라우드를 떠나는 기업이 왜 늘고 있나요?
클라우드 리패트리에이션(Cloud Repatriation)은 퍼블릭 클라우드에 올렸던 워크로드를 프라이빗 클라우드나 자체 인프라로 되돌리는 결정입니다. 바클레이스 조사에서 기업의 83%가 일부 워크로드를 되돌릴 계획이라고 답했고 IDC 집계에서도 올해 안에 컴퓨트나 스토리지를 옮기겠다는 비율이 80% 수준으로 나왔습니다. 브로드컴 내부 분석은 수요가 일정한 정상상태 워크로드에서 현대적 프라이빗 클라우드의 총소유비용이 퍼블릭 클라우드보다 40~50% 낮다고 봤습니다. 핵심은 클라우드를 떠나는 것이 아니라 워크로드별로 제자리를 다시 정하는 것입니다. 전면 철수는 대부분 실패하고 선별 이전이 성과를 냅니다.
목차
- 청구서가 예산을 넘긴 달에 생긴 일
- 리패트리에이션은 무엇이고 무엇이 아닌가요
- 숫자로 본 전환 동향
- 어떤 워크로드가 되돌아가나요
- AI 워크로드가 계산을 바꾼 이유
- 총소유비용은 어떻게 계산하나요
- 조직은 무엇을 준비해야 하나요
- 이전 판단과 실행 4단계
- FAQ
- 같이 읽으면 좋은 것들
청구서가 예산을 넘긴 달에 생긴 일
국내 중견 제조기업의 인프라 전환 자문을 맡았을 때의 기록입니다. 이 회사는 3년 전 전사 시스템을 퍼블릭 클라우드로 옮겼습니다. 첫해 청구액은 예상 범위였고 둘째 해부터 벌어지기 시작했습니다. 셋째 해 월 청구액은 초기 예상의 2.4배가 됐습니다.
비용 구조를 뜯어보니 흥미로운 분포가 나왔습니다. 컴퓨트는 예상과 크게 다르지 않았습니다. 늘어난 것은 두 항목이었습니다. 하나는 데이터 전송 요금이었고 다른 하나는 관리형 데이터베이스였습니다. 공장 설비에서 올라오는 센서 데이터를 분석 시스템으로 옮기는 과정에서 리전 간 전송이 계속 발생했습니다. 초기에 편의상 선택한 관리형 서비스는 규모가 커지면서 자체 운영 대비 몇 배 비싸졌습니다.
팀의 첫 반응은 "다 뺍시다"였습니다. 말렸습니다. 전사 철수는 마이그레이션 비용과 운영 인력 재구성 비용이 절감액을 넘어서기 쉽습니다. 대신 워크로드를 네 묶음으로 나눠 평가했습니다. 결과적으로 데이터 레이크와 상시 가동 배치 처리만 자체 인프라로 옮겼고 나머지는 그대로 두었습니다. 이전 대상은 전체 워크로드의 30%가 안 됐지만 연간 비용의 절반 가까이를 차지하던 부분이었습니다.
1년 뒤 전체 인프라 지출은 38% 줄었습니다. 전면 철수를 했다면 나오지 않았을 숫자입니다.
리패트리에이션은 무엇이고 무엇이 아닌가요
리패트리에이션을 클라우드 실패 선언으로 읽으면 틀립니다. 워크로드 배치를 다시 최적화하는 과정입니다. 용어를 정리하면 이렇습니다.
- 전면 회귀: 퍼블릭 클라우드를 떠나 모든 것을 자체 운영으로 되돌리는 것. 실제 사례는 드물고 대부분 비용 측면에서도 불리합니다.
- 선별 이전: 비용 효율이 나쁜 워크로드만 골라 옮기는 것. 현재 논의되는 리패트리에이션의 대부분이 여기 해당합니다.
- 하이브리드 재배치: 정상상태 부하는 프라이빗에, 탄력 수요는 퍼블릭에 두는 구조. 설계 난이도는 높지만 비용과 유연성을 함께 가져갑니다.
클라우드 도입 초기의 전제도 짚어 둘 필요가 있습니다. 당시 논리는 "자본 지출을 운영 지출로 바꾸고 탄력성을 얻는다"였습니다. 이 논리는 수요 변동이 큰 워크로드에서는 지금도 맞습니다. 다만 변동이 거의 없는 워크로드까지 같은 가격 구조에 올려 둔 것이 문제였습니다. 24시간 동일한 부하로 돌아가는 데이터베이스를 종량제로 쓰면 비싼 것이 당연합니다.
숫자로 본 전환 동향
최근 조사들은 비슷한 방향을 가리킵니다.
| 지표 | 수치 | 출처 성격 |
|---|---|---|
| 일부 워크로드 회귀 계획 기업 비율 | 83% | 바클레이스 기업 설문 |
| 연내 컴퓨트·스토리지 이전 예상 비율 | 약 80% | IDC 집계 |
| 비용 관리를 최대 과제로 꼽은 조직 | 84% | 클라우드 운영 설문 |
| 적정 워크로드 이전 시 인프라 지출 감소 | 30~60% | 사례 집계 |
| 정상상태 워크로드 TCO 격차 | 프라이빗이 40~50% 낮음 | 브로드컴 내부 분석 |
개별 사례도 참고가 됩니다. 37signals는 AWS에서 자체 인프라로 옮긴 뒤 연간 130만~150만 달러를 절감했다고 밝혔고 5년 누적으로는 약 700만 달러를 제시했습니다. 가이코는 10년에 걸쳐 6억 달러 규모의 클라우드 전환을 진행했습니다. 지금은 오픈스택과 쿠버네티스 기반 프라이빗 클라우드로 일부를 되돌리고 있습니다. 비용 초과, 안정성 문제, 벤더 종속이 이유로 꼽혔습니다.
데이터 이그레스 비용도 눈에 띄는 항목입니다. 데이터 집약적 워크로드에서는 클라우드 밖으로 데이터를 꺼내는 비용만 연간 5만~50만 달러에 이르는 것으로 집계됩니다. 떠나려 할 때 비용이 발생하는 구조 자체가 종속을 만든다는 지적이 여기서 나옵니다.
어떤 워크로드가 되돌아가나요
판단 기준은 부하 패턴, 데이터 중력, 규제 요건 세 가지입니다.
부하 패턴이 일정한 워크로드는 이전 후보 1순위입니다. 상시 가동 데이터베이스, 로그 수집과 보관, 정기 배치 처리가 대표적입니다. 종량제의 이점이 없는데 종량제 가격을 내고 있는 영역입니다.
데이터 중력이 큰 워크로드도 후보인데요. 수십 테라바이트 이상의 데이터를 반복해서 읽고 쓰는 분석 파이프라인은 전송 비용이 누적됩니다. 데이터가 있는 곳으로 컴퓨트를 옮기는 편이 저렴한 구간이 분명히 존재합니다.
규제 요건이 걸린 워크로드는 비용과 무관하게 재배치 대상이 됩니다. 금융과 공공 영역에서는 데이터 소재지 요건이 강화되는 추세입니다. 주권 AI 논의가 확산되면서 국내 인프라에 두어야 할 데이터의 범위도 넓어졌습니다.
반대로 클라우드에 남겨야 할 것도 있습니다. 트래픽 변동이 큰 프런트엔드, 신규 서비스 실험 환경, 글로벌 엣지 배포, 그리고 자체 구축이 비현실적인 관리형 AI 서비스입니다. 이 영역까지 끌고 내려오면 운영 인력 부담이 절감액을 삼킵니다.
AI 워크로드가 계산을 바꾼 이유
최근 논의가 가열된 직접적 계기는 AI입니다. 학습과 추론 워크로드는 GPU 집약적이고 지연 시간에 민감하며 장시간 일정한 부하를 유지합니다. 퍼블릭 클라우드의 가격 구조에서 가장 비싸지는 조합입니다.
GPU 인스턴스를 온디맨드로 몇 달간 돌리면 같은 성능의 장비를 구매하는 비용을 넘어서는 경우가 생깁니다. 모델 학습 주기가 반복적이고 예측 가능하다면 자체 보유가 유리해집니다. 반대로 간헐적 실험이나 최신 가속기가 필요한 작업은 클라우드가 낫습니다. 하드웨어 세대 교체 위험을 넘길 수 있기 때문입니다.
여기에 전력 문제가 겹칩니다. AI 데이터센터 전력 수요가 급증하면서 클라우드 사업자의 원가도 오르고 있습니다. 가격 인하 압력이 줄어드는 환경이라는 뜻입니다. 자체 구축을 검토할 때도 전력과 냉각 비용을 빼놓으면 계산이 틀어집니다.
총소유비용은 어떻게 계산하나요
양쪽의 항목을 대칭으로 세지 않으면 비교가 틀어집니다. 퍼블릭 클라우드 청구서는 숫자가 한 장에 모여 있고 자체 인프라 비용은 여러 부서에 흩어져 있습니다.
프라이빗 쪽에서 반드시 포함해야 할 항목은 장비 감가상각, 데이터센터 상면과 전력, 네트워크 회선, 운영 인력 인건비, 소프트웨어 라이선스, 그리고 재해복구 구성입니다. 특히 인건비를 빼고 계산한 보고서가 흔합니다. 24시간 운영 체계를 갖추려면 최소 인원이 필요하고 이 비용은 규모가 작을수록 상대적으로 무겁습니다.
퍼블릭 쪽에서도 놓치는 항목이 있습니다. 데이터 전송 요금, 지원 플랜 비용, 미사용 리소스, 그리고 약정 할인을 받기 위해 묶인 선지급금입니다. 비용 가시성을 확보하는 운영 체계가 없으면 이 항목들이 보이지 않습니다.
비교 기간도 중요합니다. 1년으로 자르면 마이그레이션 비용 때문에 거의 모든 이전이 불리하게 나옵니다. 장비 수명 주기를 고려해 3~5년으로 놓고 보는 것이 일반적입니다. 전환 비용을 상각 기간에 분산해 넣어야 실제 비교가 됩니다.
조직은 무엇을 준비해야 하나요
기술보다 먼저 막히는 지점은 조직입니다. 자체 인프라 운영은 3년 전에 줄였던 역량을 다시 세우는 일이기 때문입니다.
첫째, 운영 인력입니다. 클라우드로 옮기면서 인프라 엔지니어를 줄인 조직이 많습니다. 되돌리려면 네트워크, 스토리지, 가상화, 쿠버네티스 운영을 감당할 사람이 필요합니다. 외주로 메우는 선택지도 있지만 장애 대응 책임 소재를 계약서에 명확히 적어 두지 않으면 새로운 종속이 생깁니다.
둘째, 조달과 용량 계획입니다. 클라우드에서는 몇 분이면 되던 자원 확보가 장비 발주와 입고로 바뀝니다. GPU 서버는 리드타임이 수개월에 이르기도 합니다. 분기 단위 용량 계획 프로세스가 없으면 개발 속도가 떨어집니다.
셋째, 비용 가시성 체계입니다. 역설적이지만 자체 인프라로 옮긴 뒤 비용 추적이 더 어려워지는 조직이 많습니다. 청구서라는 단일 창구가 사라지기 때문입니다. 워크로드별 원가를 계속 추적하지 않으면 2년 뒤에 같은 문제를 반대 방향으로 겪습니다.
넷째, 의사결정 기준의 문서화입니다. "어떤 조건이면 클라우드, 어떤 조건이면 자체"라는 기준을 팀이 공유하지 않으면 새 프로젝트마다 논쟁이 반복됩니다. 부하 변동성, 데이터 규모, 규제 요건, 예상 수명 네 가지를 묻는 한 장짜리 체크리스트면 충분합니다.
리패트리에이션은 인프라 프로젝트이기 전에 운영 모델 전환입니다. 이 점을 놓친 조직이 이전 1년 뒤에 다시 클라우드로 돌아간 사례도 실제로 보고됩니다.
이전 판단과 실행 4단계
1단계. 비용을 워크로드 단위로 쪼갭니다. 계정이나 부서 단위로는 판단이 서지 않습니다. 워크로드 기준으로 묶어야 합니다. 태그 체계가 없으면 이 작업부터 해야 하고 보통 여기에 한두 달이 걸립니다.
2단계. 네 칸으로 분류합니다. 부하 변동성과 데이터 중력을 두 축으로 놓고 워크로드를 배치합니다. 변동이 작고 데이터가 무거운 칸이 이전 1순위입니다. 변동이 크고 데이터가 가벼운 칸은 그대로 둡니다.
3단계. 작은 것부터 옮겨 검증합니다. 가장 비싼 워크로드는 뒤로 미루고 가장 단순한 워크로드로 시작합니다. 이전 절차와 운영 체계를 검증하는 것이 목적이고요. 첫 이전에서 배운 것이 다음 이전의 견적 정확도를 결정합니다.
4단계. 되돌아갈 길을 열어 둡니다. 컨테이너와 쿠버네티스 기반으로 구성하면 양방향 이동이 쉬워집니다. 특정 클라우드 전용 서비스에 깊이 묶이지 않도록 추상화 계층을 두는 설계가 장기적으로 협상력을 만듭니다. 이전 자체보다 이전할 수 있는 상태를 유지하는 것이 비용 통제의 본질에 가깝습니다.