클라우드 이전 견적에서 월 VM·Database·Storage 요금만 비교하면 한 가지 질문에는 답할 수 있다.
이전이 끝난 뒤 목표 환경을 운영하는 데 매달 얼마가 드는가?
하지만 그것만으로는 다음 질문에 답할 수 없다.
현재 환경을 실제로 멈추고 목표 환경으로 전환하는 데 총 얼마가 필요한가?
클라우드 이전의 총비용은 목표 환경의 정상 운영비에 조사·설계·리팩터링·데이터 이동·이중 운영·검증·다운타임 위험·교육·기존 계약 잔여 비용·Rollback·안정화 비용을 더한 값이다.
이를 계산식으로 표현하면 다음과 같다.
Migration TCO(H)
=목표 환경 반복비용(H) + 원본 환경 잔존비용 + 일회성 전환비용 + 임시 중복비용 + 위험조정 비용
H는 12개월, 36개월처럼 비교에 사용하는 동일한 평가기간이다. 현재 환경을 유지하는 경우와 이전하는 경우 모두 같은 기간과 같은 서비스 수준으로 비교해야 한다.
클라우드 TCO 계산기가 보여주는 것은 대체로 ‘정상 상태’다
Cloud Provider가 제공하는 TCO 도구는 현재 자산을 발견하고 목표 환경의 적정 크기와 예상 운영비를 계산하는 출발점으로 유용하다. Google Cloud Migration Center도 자산 그룹의 Memory·Storage 사용량과 목표 제품을 바탕으로 비용을 비교하며 Azure Migrate는 현재 환경과 Azure 비용을 명시적으로 TCO (steady state)로 구분한다.
문제는 실제 이전 과정이 정상 상태가 아니라는 점이다.
이전 기간에는 원본 환경과 목표 환경이 동시에 존재하고 데이터를 여러 번 복사하며 새로운 보안·모니터링·배포 체계를 구축한다. Cutover에 실패하면 원래 환경으로 돌아갈 수 있어야 하고 성공한 뒤에도 일정 기간 Migration Team이 운영팀을 지원해야 한다.
AWS의 상세 Business Case 가이드도 목표 Cloud의 운영비 외에 Migration·Modernization, 자산 폐기와 계약 조기 종료, 기존 환경과 목표 환경의 Parallel Run 비용을 별도로 계산하도록 안내한다.
따라서 TCO 계산기는 목표 환경 정상 운영비의 근거로 사용하고 실제 이전 예산은 별도의 전환비용 원장으로 보완하는 편이 안전하다.
비용은 네 가지 성격으로 분리한다
같은 비용이라도 언제 발생하고 언제 끝나는지에 따라 판단이 달라진다.
| 비용 분류 | 의미 | 대표 사례 |
|---|---|---|
| One-time | 이전을 준비하고 실행하기 위해 한 번 발생하는 비용 | Assessment, Architecture 설계, Refactoring, 최초 데이터 복사, 테스트, Cutover 준비 |
| Temporary | 전환 기간에만 발생하고 원본 환경 폐기 후 사라지는 비용 | 데이터 동기화, Dual Run, 임시 회선, 중복 Monitoring, Hypercare |
| Recurring | 이전 완료 후에도 계속 발생하는 정상 운영비 | Compute, Storage, Network, 지원계약, Monitoring·Security 도구, 운영 인력 |
| Risk-adjusted / uncertain | 발생 여부나 금액이 확정되지 않은 비용 | Downtime, 일정 지연, 재전송, Rollback 실행, 예상 밖 Refactoring, 안정화 연장 |
하나의 항목이 여러 분류에 걸칠 수 있다.
예를 들어 Monitoring은 새 환경의 Dashboard와 Alert를 만드는 비용은 One-time이지만 Log 수집과 보관료는 Recurring이다. Rollback Runbook을 작성하고 시험하는 일은 One-time이지만 실제 Rollback이 발생했을 때의 추가 인력·재동기화·사업 중단은 Risk-adjusted 비용이다.
FinOps Foundation도 Workload Placement의 비용 입력을 Infrastructure Cost에 한정하지 않고 Support·Run, Modernization·Implementation·Migration Cost까지 포함하며 Parallel Run·Phased Rollout·Decommissioning 같은 Transition State의 기간과 비용을 별도로 관리하도록 정의한다.
Migration TCO에 포함해야 할 16개 비용 영역
다음 표는 AWS·Microsoft·Google의 공식 Migration Guidance에 분산된 활동을 하나의 비용 원장으로 재구성한 것이다.
| 비용 영역 | 무엇을 계산해야 하는가 | 주된 분류 |
|---|---|---|
| 1. Discovery / Assessment | 서버·DB·Storage뿐 아니라 API, DNS, 인증, 외부 연동, Batch, CI/CD, License, 담당자, 실제 사용량과 Dependency를 발견하는 시간과 도구 비용 | One-time |
| 2. Architecture Change | Landing Zone, Account·Project 구조, Network, IAM, Secret, Load Balancing, 배포 구조, 관리형 서비스 전환, IaC 설계 | One-time / Uncertain |
| 3. Refactoring | Cloud에서 동작하도록 Application Code, Runtime, Data Schema, Authentication, File 처리, Session, 외부 연동을 변경하는 개발·Review 비용 | One-time / Uncertain |
| 4. Data Transfer | 최초 Bulk Copy, 원본 Cloud의 Egress, Storage Read Operation, 추가 Bandwidth, Transfer Appliance·Tool, 임시 Storage, 암호화·검증·재시도 | One-time / Temporary |
| 5. Data Synchronization | 최초 복사 이후 발생하는 변경분을 계속 맞추는 Replication·CDC, Replication Log, Lag Monitoring, 최종 동기화와 정합성 조정 | Temporary |
| 6. Dual Run | 원본과 목표 Compute·DB·Storage, 중복 License, Monitoring, Support, 양쪽 환경 연결과 운영 인력 | Temporary |
| 7. Testing / Validation | 기능·통합·성능·보안·실패·사용자 인수 테스트, Test Data, 별도 환경, 결함 수정과 재검증 | One-time / Temporary |
| 8. DNS / Cutover | TTL 조정, 인증서, Routing, Client 설정, Change Window, Runbook, 이해관계자 공지, 현장 대기 인력 | One-time / Temporary |
| 9. Downtime / Business Disruption | 처리하지 못한 주문·거래, 직원 작업 중단, SLA Credit, 고객 지원 증가, 수작업 복구와 후속 정산 | Risk-adjusted |
| 10. Training | Migration Tool, Cloud IAM, 배포, Monitoring, 보안, 비용관리, 장애 대응과 운영 인계 교육 | One-time / Recurring |
| 11. New Tooling | Discovery, Replication, IaC, CI/CD, Artifact, Secret, CMDB, Migration Tracking, Cloud Cost Management 도구의 도입·License | One-time / Temporary / Recurring |
| 12. Monitoring / Security Rebuild | Log·Metric·Trace, Alert, Dashboard, SIEM 연동, IAM, Key, Network Control, 취약점 관리와 Compliance Evidence 재구축 | One-time / Recurring |
| 13. Contract / Commitment Remainder | 기존 Hosting·Colocation·Circuit·License·Support 계약, Cloud Commitment, 장비 잔존가치, 조기 해지 위약금과 폐기비용 | One-time / Temporary / Accounting |
| 14. Support | CSP Support Plan, Application Vendor 지원, Professional Service, Contractor, 야간·주말 Cutover, On-call·초과근무 | Temporary / Recurring |
| 15. Rollback / Exit | 원본 환경 유지, 역방향 Traffic 전환, 변경 데이터 병합, Reverse Transfer, 재배포, 임시 자원 정리와 실패한 투자 | One-time preparation / Risk-adjusted execution |
| 16. Post-migration Stabilization | Hypercare, 결함 수정, 성능·비용 조정, Alert 개선, 운영 문서 업데이트, 책임 인계, 원본 환경 폐기 확인 | Temporary / Uncertain |
Discovery는 서버 목록을 만드는 것으로 끝나지 않는다
서버와 Database 목록만으로는 어떤 순서로 옮겨야 하는지 알 수 없다. 하나의 Application이 중앙 인증, 내부 DNS, File Share, 외부 API, Batch Job이나 특정 License Server에 의존할 수 있기 때문이다.
Google의 Assessment Guidance도 Workload Inventory를 Application에 한정하지 않고 Database, Message Broker, Configuration Store, Source Repository, CI/CD, Artifact Repository, Runtime과 물리 Network·Security Appliance까지 포함한다. 또한 Inventory 자체가 자동화된 Catalog가 없을수록 상당한 노력이 필요한 작업이라고 설명한다.
Assessment 비용은 다음 산식으로 추정할 수 있다.
Assessment Cost
=자동 Discovery Tool 비용 + 담당자 Interview 시간 + Dependency 검증 시간 + 현재 비용·계약 자료 정리 + POC·Benchmark 비용
현재 환경을 잘 모를수록 Assessment를 생략할 것이 아니라 불확실성 범위를 더 크게 잡아야 한다.
Architecture Change와 Refactoring은 같은 항목이 아니다
Architecture Change는 목표 환경의 운영 구조를 바꾸는 일이다. Network, IAM, Account 구조, 배포 Pipeline, Monitoring, Secret 관리, 고가용성 구성 등이 여기에 속한다.
Refactoring은 Application 자체를 수정하는 일이다. Runtime 호환성, Local File 의존, Session, Authentication, Database 기능, 외부 연동과 배포 방식이 달라질 때 발생한다.
두 항목을 하나로 합치면 인프라 설계가 완료됐는데 Application 수정이 끝나지 않았거나, 반대로 Code 이전은 끝났지만 운영 기반이 준비되지 않은 상태를 놓치기 쉽다. AWS도 Replatform·Repurchase·Refactor 대상은 Workload별 Migration·Modernization 비용을 더 상세하게 산정하도록 구분한다.
Data Transfer와 Data Synchronization도 분리해야 한다
Data Transfer는 현재 데이터를 목표 환경으로 한 번 옮기는 작업이다. Data Synchronization은 복사가 진행되는 동안 원본에서 새로 생성되거나 수정된 데이터를 계속 따라잡는 작업이다.
대용량 데이터 이동에서는 Network Egress뿐 아니라 다음 비용이 발생할 수 있다.
원본 Storage의 Read Operation
추가 회선과 Bandwidth
Transfer Tool 또는 Appliance
임시 Staging Storage
전송 인력과 승인 절차
실패한 파일의 재시도
Checksum과 Data Integrity 검증
Google의 공식 가이드는 데이터 전송에 Network, Storage Operation, Transfer Product, 인력 비용이 포함되며 계획과 테스트에 전송 자체만큼 시간이 필요할 수도 있다고 설명한다. 또한 최초 복사 후 Data Integration 문제를 해결하고 검증한 뒤, 원본이 더 이상 Fallback으로 필요하지 않을 때 폐기하는 순서를 제시한다.
따라서 데이터 비용은 최소한 다음과 같이 나눈다.
Data Migration Cost
=Initial Bulk Transfer + Incremental Synchronization + Validation + Failed Transfer Retry + Rollback Re-synchronization Risk Dual Run 기간은 ‘한 달 정도’가 아니라 날짜로 계산한다
Dual Run은 단순히 서버 두 세트를 켜는 비용이 아니다.
원본과 목표 환경의 Compute·Database·Storage뿐 아니라 양쪽 Monitoring, Security, License, Support, Network 연결과 운영 인력이 함께 유지될 수 있다.
Microsoft의 현재 Migration Plan 예시는 Cutover 방식을 Big Bang, Phased, Blue-green으로 구분한다. Blue-green은 두 환경을 병렬 유지하므로 비용 영향은 크지만 Downtime과 Rollback 위험을 낮출 수 있고 Big Bang은 직접 비용은 낮지만 Downtime과 Rollback 난도가 높다. 이는 특정 방식을 항상 선택하라는 의미가 아니라, Cutover 방식 자체가 비용과 위험 사이의 선택임을 보여준다.
Dual Run 비용은 다음처럼 기간에 연결한다.
Dual Run Cost
=(원본 환경 월 잔존비용 + 중복 License·Monitoring·Support + 환경 간 Network·Synchronization + 추가 운영 인력) × 실제 중복 개월 수
여기서 가장 중요한 입력은 Cutover 예정일이 아니라 원본 환경 Decommission 승인일이다. Cutover 후 검증이 끝나지 않아 원본을 계속 유지하면 Dual Run도 계속된다.
총액보다 월별 현금흐름을 먼저 그린다
이전비용을 한 줄 총액으로만 기록하면 비용이 언제 겹치는지 볼 수 없다.
| 단계 | 주요 비용 |
|---|---|
| Assessment·설계 | Discovery, Architecture, POC, 교육, 외부 지원 |
| 목표 환경 구축 | 목표 Cloud 비용 시작, Tooling, Monitoring·Security 재구축 |
| Replication·Rehearsal | 원본 비용 + 목표 비용 + 데이터 동기화 + Test 환경 |
| Cutover | 야간·주말 지원, 최종 동기화, DNS·Routing 변경, 사업 중단 위험 |
| Hypercare | 원본 유지 가능성 + 목표 운영비 + Migration Team·Operations Team 병행 |
| Decommission | 계약 해지, 자산 상각·폐기, 임시 자원 정리 |
| 정상 운영 | 목표 환경의 Recurring Cost |
Azure Migrate의 Future-state Cash Flow도 한 번에 모든 서버가 사라진다고 가정하지 않고 연도별 Migration 비율에 따라 남아 있는 현재 환경 비용과 Azure 비용을 함께 계산한다. AWS 역시 Cloud 비용의 Ramp-up을 원본 환경 Ramp-down보다 먼저 시작해 테스트와 Decommissioning 시간을 확보하는 구조를 Business Case에 반영한다.
Workload가 여러 개라면 회사 전체를 하나의 이전일로 계산하지 말고 Wave마다 다음 날짜를 둔다.
Target Build Start
Replication Start Cutover Date Acceptance Date Rollback Window End Hypercare End Source Decommission Date Contract End Date 현금비용·회계비용·기회비용을 섞지 않는다
Migration TCO에는 성격이 다른 재무 항목이 들어온다.
| 재무 처리 | 예시 | 계산 시 주의점 |
|---|---|---|
| Cash Cost | CSP Invoice, Consultant, Tool License, Egress, 추가 회선, 초과근무 | 실제 지출 시점에 반영 |
| Accounting Cost | 아직 남은 장비 장부가액의 상각, 폐기 손실 | 현금 유출과 구분해 별도 표시 |
| Opportunity Cost | 기존 개발자가 Migration 때문에 Product Roadmap을 미루는 시간 | 이미 인건비를 Cash Cost로 넣었다면 중복 계산하지 않음 |
예를 들어 기존 서버의 장부가액을 전액 손실로 처리하면서 같은 금액을 다시 계약 해지 현금비용으로 더하면 이중 계산이 될 수 있다.
내부 정규직 인력도 마찬가지다. 급여는 이전 여부와 무관하게 지급되지만 Migration에 투입된 시간만큼 다른 개발이 지연될 수 있다. 이 경우 회계상 증분 현금지출과 의사결정상 기회비용을 나눠 보고하는 편이 정확하다.
Downtime과 Rollback은 임의의 예비비 비율로 대체하지 않는다
위험비용은 ‘전체 예산의 몇 퍼센트’처럼 일괄 적용하기보다 위험 사건별로 계산한다.
Risk-adjusted Cost
=발생확률 × 발생 시 재무영향
예를 들어 다음 항목을 별도로 둔다.
Cutover 시간 초과
데이터 정합성 오류
성능 기준 미달
Application Dependency 누락
DNS·Routing 오류
Rollback 후 데이터 병합
Hypercare 기간 연장
원본 계약 해지 지연
각 위험에는 Low·Base·High 영향값, 발생확률, 완화조치와 책임자를 기록한다.
다만 기대비용이 작다고 해서 높은 충격의 위험을 허용해도 된다는 뜻은 아니다. 허용 가능한 중단시간이나 데이터 손실을 초과하는 사건은 평균 비용으로 희석하지 말고 별도의 설계·승인 조건으로 남겨야 한다.
Google은 Migration Plan의 각 단계마다 Rollback 전략을 만들고 실제 작동 여부를 검증하며 단계별 최대 실행시간이 지나면 Rollback을 시작하는 기준을 정하도록 권고한다.
Cutover가 끝나도 이전 프로젝트는 끝나지 않는다
DNS가 목표 환경을 가리키고 사용자가 접속할 수 있다고 해서 곧바로 Migration Team을 해산하면 안 된다.
AWS의 Wave Planning은 Cutover 이후 Migration Team이 운영팀을 지원하고 최적화를 수행하는 Hypercare 단계를 별도로 둔다. 운영팀이 Workload를 인수하고 Cutover 문제를 해결한 뒤에야 Wave를 종료한다.
안정화 기간에는 다음 비용이 남을 수 있다.
성능 병목과 Configuration 수정
누락된 Alert·Dashboard 보완
Log Volume과 Cloud Cost 조정
권한·보안 정책 보정
사용자 문의와 데이터 정산
운영 Runbook 업데이트
On-call과 Support 확대
원본 환경 폐기 승인
남은 임시 자원과 License 정리
Google 역시 이전 후 Optimization을 반복 작업으로 설명하며 최적화에는 Resource·Time·Effort·Skill이라는 비용이 든다고 명시한다.
Post-migration Stabilization은 이전 후 언젠가 수행할 일반적인 비용 최적화와 구분해, Migration Project 자체의 Temporary Cost로 예산화하는 편이 좋다.
Migration TCO Worksheet
아래 Worksheet는 Workload 또는 Migration Wave마다 한 줄씩 복제해 사용한다.
사용 원칙
평가기간 H를 먼저 정한다.
비용은 발생 월과 종료 월을 함께 기록한다.
확정 비용과 불확실한 비용을 같은 값으로 섞지 않는다.
내부 인력은 현금비용과 기회비용 중 어떤 기준으로 계산했는지 표시한다.
모든 금액에는 견적서·계약서·사용량·작업시간 등 Evidence와 Owner를 연결한다.
Low·Base·High 중 하나만 숨기고 Base 값만 보고하지 않는다.
상세 Worksheet
| ID | 비용 영역 | 기본 분류 | 주요 산정 Driver | 재무 처리 | Low | Base | High | 발생확률 | 발생 시점·기간 | Owner / Evidence |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 목표 환경 정상 운영비 | Recurring | Compute·DB·Storage·Network·License·Support × H개월 | Cash | 확정 | |||||
| 1 | Discovery / Assessment | One-time | 자산 수, Dependency 수, Interview·분석 시간, Tool License | Cash / Opportunity | 100% | |||||
| 2 | Architecture Change | One-time / Uncertain | 설계 Work Package, Landing Zone, IAM·Network·IaC 변경량 | Cash / Opportunity | 100% 또는 별도 위험 | |||||
| 3 | Refactoring | One-time / Uncertain | 변경 Component, Story Point·Person-day, Integration 수 | Cash / Opportunity | 100% 또는 별도 위험 | |||||
| 4 | Data Transfer | One-time / Temporary | 데이터량, Egress, Read Operation, Bandwidth, Tool, 재시도 | Cash | 100% | |||||
| 5 | Data Synchronization | Temporary | Change Rate, Replication 기간, Log·Lag Monitoring | Cash | 100% | |||||
| 6 | Dual Run | Temporary | 원본 잔존비용 + 중복 Tool·License·Support × 개월 | Cash | 100% | |||||
| 7 | Testing / Validation | One-time / Temporary | Test 종류, 환경 수, 실행 횟수, 결함 수정·재검증 | Cash / Opportunity | 100% | |||||
| 8 | DNS / Cutover | One-time / Temporary | Runbook, 변경 Window, 인력, 인증서·Routing 작업 | Cash / Opportunity | 100% | |||||
| 9 | Downtime / Business Disruption | Risk-adjusted | 시간당 거래·업무 영향 × 예상 중단시간 | Cash / Opportunity | 입력 | Cutover | ||||
| 10 | Training | One-time / Recurring | 역할별 교육시간, 교육비, 실습 환경, 생산성 Ramp-up | Cash / Opportunity | 100% | |||||
| 11 | New Tooling | One-time / Temporary / Recurring | 도입비 + License × 사용자·자산·기간 | Cash | 100% | |||||
| 12 | Monitoring / Security Rebuild | One-time / Recurring | Signal Volume, 보관기간, Dashboard·Rule·Control 수 | Cash / Opportunity | 100% | |||||
| 13 | Contract / Commitment Remainder | One-time / Temporary | 잔여 계약월, 최소 사용액, 위약금, 장부가액·폐기 | Cash / Accounting | 100% | |||||
| 14 | Support | Temporary / Recurring | Support Plan, Consultant, Contractor, On-call 기간 | Cash | 100% | |||||
| 15A | Rollback 준비·시험 | One-time | Runbook, 자동화, Rehearsal, 원본 환경 보존 | Cash / Opportunity | 100% | |||||
| 15B | Rollback 실제 실행 | Risk-adjusted | 복귀 인력, Reverse Transfer, 데이터 병합, 추가 중단 | Cash / Opportunity | 입력 | Cutover | ||||
| 16 | Post-migration Stabilization | Temporary / Uncertain | Hypercare 인력·기간, 수정·Tuning, 운영 인계 | Cash / Opportunity | 100% 또는 연장 위험 |
분류별 합계
| 구분 | 계산식 | 금액 |
|---|---|---|
| One-time subtotal | 확정된 일회성 비용 합계 | |
| Temporary subtotal | 이전 기간에만 발생하는 증분 비용 합계 | |
| Recurring subtotal | 목표 환경 반복비용 × 평가기간 H | |
| Retained source subtotal | 원본 환경 Cutover 이후 잔존비용 | |
| Risk-adjusted subtotal | 각 위험의 발생확률 × 발생 시 영향 합계 | |
| Migration TCO — Cash basis | 위 현금비용 합계 | |
| Accounting impact | 자산 상각·폐기 등 비현금 비용 | 별도 보고 |
| Opportunity cost | 내부 인력 전환·Roadmap 지연 | 별도 보고 |
| Current-state baseline(H) | 이전하지 않을 경우 같은 기간의 비용 | 비교용 |
최종 계산식
Committed Migration Cash Cost = One-time + Temporary + Recurring(H) + Retained Source + Non-cancellable Contract Remainder Risk-adjusted Expected Cost = Σ(각 위험의 발생확률 × 발생 시 재무영향) Migration TCO = Committed Migration Cash Cost + Risk-adjusted Expected Cost
Accounting Impact와 Opportunity Cost는 의사결정 자료에는 함께 표시하되, Cash TCO와 한 숫자로 합칠 때 중복이 없는지 확인해야 한다.
하나의 숫자보다 세 가지 시나리오가 낫다
Migration TCO는 단일 정답보다 다음 세 가지 시나리오로 보는 편이 실용적이다.
| 시나리오 | 전제 |
|---|---|
| Low / 원활한 전환 | 계획한 기간 안에 이전, 짧은 Dual Run, 추가 Refactoring 없음 |
| Base / 가장 가능성 높은 전환 | 예상된 결함 수정과 안정화, 승인된 Buffer 포함 |
| High / 불리한 전환 | Dual Run 연장, 추가 Refactoring, 재전송 또는 일부 Rollback 발생 |
AWS도 상세 Business Case에서 최소 변화, 가장 가능성 높은 경우, 중요한 가정이 달라지는 경우를 별도 시나리오로 모델링하도록 안내한다.
각 시나리오에서 특히 민감한 입력은 다음과 같다.
Refactoring Person-day
데이터량과 Change Rate
Dual Run 개월 수
원본 환경 Decommission 날짜
Hypercare 기간
기존 계약 종료 날짜
허용 가능한 Downtime
Rollback 발생 가능성과 영향
이 값이 변했을 때 TCO가 얼마나 달라지는지를 보는 것이 단일 서버 가격을 소수점 단위로 비교하는 것보다 중요한 경우가 많다.
이전 예산을 승인하기 전에 확인할 질문
다음 질문에 답하지 못한다면 TCO는 아직 목표 환경 견적에 가깝다.
어떤 Workload와 Dependency가 이전 범위에 포함됐는가?
Workload별 Rehost·Replatform·Refactor 범위가 정해졌는가?
최초 Data Transfer와 지속적인 Data Synchronization을 분리했는가?
원본과 목표 환경이 겹치는 시작일과 종료일이 있는가?
기능·성능·보안·업무 인수 기준이 문서화됐는가?
Cutover와 Rollback Trigger의 결정권자가 정해졌는가?
원본 환경 Decommission 조건과 계약 종료일이 연결돼 있는가?
운영팀 교육과 Monitoring·Security 인계가 예산에 포함됐는가?
Hypercare 종료 조건이 있는가?
Low·Base·High 시나리오와 각 입력의 Evidence가 있는가?
클라우드 이전의 경제성은 가장 저렴한 서버 견적을 찾는 문제와 다르다.
목표 환경의 월 비용이 낮아도 Refactoring, 계약 잔여기간, 긴 Dual Run과 안정화 비용이 크면 전환 시점의 현금 부담은 커질 수 있다. 반대로 일회성 전환비가 더 들더라도 운영 복잡성이나 사업 중단 위험을 줄이는 설계가 합리적인 경우도 있다.
결론은 Vendor 이름이나 할인율보다 다음 순서로 내려야 한다.
Workload와 제약
→ 목표 운영 모델
→ 이전 전략 → 월별 전환 현금흐름 → 위험과 Rollback → 동일 기간의 TCO 비교
Migration TCO Worksheet의 역할은 클라우드 이전이 항상 비용을 절감한다고 증명하는 것이 아니다. 어떤 비용과 위험을 감수하고 언제 기존 환경을 끝낼 수 있는지를 의사결정자가 확인할 수 있게 만드는 것이다.
공식 참고자료
- https://www.finops.org/framework/capabilities/architecting-workload-placement/
- https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html
- https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html
- https://learn.microsoft.com/en-us/azure/migrate/concepts-business-case-calculation
- https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/plan-migration
- https://learn.microsoft.com/en-us/azure/migration/migrate-workload-from-aws-plan
- https://learn.microsoft.com/en-us/azure/migration/migrate-workload-from-aws-execute
- https://docs.cloud.google.com/migration-center/docs/generate-tco-report
- https://docs.cloud.google.com/architecture/migration-to-google-cloud-best-practices
- https://docs.cloud.google.com/architecture/migration-to-google-cloud-transferring-your-large-datasets
- https://docs.cloud.google.com/architecture/migration-to-google-cloud-optimizing-your-environment
- https://www.ixc.co.kr/insights/