TCO 계산기가 보여주는 것은 정상 상태다
클라우드 이전 견적에서 월 VM·Database·Storage 요금만 비교하면 한 가지 질문에는 답할 수 있습니다. 이전이 끝난 뒤 목표 환경을 운영하는 데 매달 얼마가 드는가입니다. 하지만 그것만으로는 다음 질문에 답할 수 없습니다. 현재 환경을 실제로 멈추고 목표 환경으로 전환하는 데 총 얼마가 필요한가입니다.
클라우드 이전의 총비용은 목표 환경의 정상 운영비에 조사·설계·Refactoring·데이터 이동·Dual Run·검증·Downtime 위험·교육·기존 계약 잔여 비용·Rollback·안정화 비용을 더한 값입니다. 계산식으로 표현하면 이렇습니다. Migration TCO(H) = 목표 환경 반복비용(H) + 원본 환경 잔존비용 + 일회성 전환비용 + 임시 중복비용 + 위험조정 비용. H는 12개월, 36개월처럼 비교에 사용하는 동일한 평가기간입니다. 현재 환경을 유지하는 경우와 이전하는 경우 모두 같은 기간과 같은 서비스 수준으로 비교해야 합니다.
Cloud Provider가 제공하는 TCO 도구는 현재 자산을 발견하고 목표 환경의 적정 크기와 예상 운영비를 계산하는 출발점으로 유용합니다. Google Cloud Migration Center도 자산 그룹의 Memory·Storage 사용량과 목표 제품을 바탕으로 비용을 비교하며,[13] Azure Migrate는 현재 환경과 Azure 비용을 명시적으로 TCO (steady state)로 구분합니다.[9]
문제는 실제 이전 과정이 정상 상태가 아니라는 점입니다. 이전 기간에는 원본 환경과 목표 환경이 동시에 존재하고 데이터를 여러 번 복사하며 새로운 보안·모니터링·배포 체계를 구축합니다. Cutover에 실패하면 원래 환경으로 돌아갈 수 있어야 하고 성공한 뒤에도 일정 기간 Migration Team이 운영팀을 지원해야 합니다.
AWS의 상세 Business Case 가이드도 목표 Cloud의 운영비 외에 Migration·Modernization, 자산 폐기와 계약 조기 종료, 기존 환경과 목표 환경의 Parallel Run 비용을 별도로 계산하도록 안내합니다.[7] 따라서 TCO 계산기는 목표 환경 정상 운영비의 근거로 사용하고 실제 이전 예산은 별도의 전환비용 원장으로 보완하는 편이 안전합니다.
비용은 네 가지 성격으로 분리한다
같은 비용이라도 언제 발생하고 언제 끝나는지에 따라 판단이 달라집니다. 하나의 항목이 여러 분류에 걸칠 수 있습니다. 예를 들어 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의 기간과 비용을 별도로 관리하도록 정의합니다.[6]
비용 분류 | 의미 | 대표 사례 |
|---|---|---|
| One-time | 이전을 준비하고 실행하기 위해 한 번 발생하는 비용 | Assessment, Architecture 설계, Refactoring, 최초 데이터 복사, 테스트, Cutover 준비 |
| Temporary | 전환 기간에만 발생하고 원본 환경 폐기 후 사라지는 비용 | 데이터 동기화, Dual Run, 임시 회선, 중복 Monitoring, Hypercare |
| Recurring | 이전 완료 후에도 계속 발생하는 정상 운영비 | Compute, Storage, Network, 지원계약, Monitoring·Security 도구, 운영 인력 |
| Risk-adjusted / uncertain | 발생 여부나 금액이 확정되지 않은 비용 | Downtime, 일정 지연, 재전송, Rollback 실행, 예상 밖 Refactoring, 안정화 연장 |
의존 관계를 확인하고 전환을 검증 — 함께 움직여야 할 시스템을 묶고 리허설과 되돌릴 조건을 갖춘 뒤 실제 전환을 수행합니다.
Migration TCO에 포함해야 할 16개 비용 영역
아래 표는 AWS·Microsoft·Google의 공식 Migration Guidance에 분산된 활동을 하나의 비용 원장으로 재구성한 것입니다.[7][10][14] 각 영역은 뒤의 Worksheet에서 한 줄씩 다시 등장합니다.
비용 영역 | 무엇을 계산해야 하는가 | 주된 분류 |
|---|---|---|
| 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가 없을수록 상당한 노력이 필요한 작업이라고 설명합니다.[14]
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 비용을 더 상세하게 산정하도록 구분합니다.[7]
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으로 필요하지 않을 때 폐기하는 순서를 제시합니다.[15]
따라서 데이터 비용은 최소한 다음과 같이 나눕니다. 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으로 구분합니다.[11] Blue-green은 두 환경을 병렬 유지하므로 비용 영향은 크지만 Downtime과 Rollback 위험을 낮출 수 있고, Big Bang은 직접 비용은 낮지만 Downtime과 Rollback 난도가 높습니다. 이는 특정 방식을 항상 선택하라는 의미가 아니라 Cutover 방식 자체가 비용과 위험 사이의 선택임을 보여 줍니다.
Dual Run 비용은 다음처럼 기간에 연결합니다. Dual Run Cost = (원본 환경 월 잔존비용 + 중복 License·Monitoring·Support + 환경 간 Network·Synchronization + 추가 운영 인력) × 실제 중복 개월 수. 여기서 가장 중요한 입력은 Cutover 예정일이 아니라 원본 환경 Decommission 승인일입니다. Cutover 후 검증이 끝나지 않아 원본을 계속 유지하면 Dual Run도 계속됩니다.
총액보다 월별 현금흐름을 먼저 그린다
이전비용을 한 줄 총액으로만 기록하면 비용이 언제 겹치는지 볼 수 없습니다. 단계별로 어떤 비용이 겹치는지는 아래 표와 같습니다.
Azure Migrate의 Future-state Cash Flow도 한 번에 모든 서버가 사라진다고 가정하지 않고 연도별 Migration 비율에 따라 남아 있는 현재 환경 비용과 Azure 비용을 함께 계산합니다.[9] AWS 역시 Cloud 비용의 Ramp-up을 원본 환경 Ramp-down보다 먼저 시작해 테스트와 Decommissioning 시간을 확보하는 구조를 Business Case에 반영합니다.[7]
Workload가 여러 개라면 회사 전체를 하나의 이전일로 계산하지 말고 Wave마다 날짜를 둡니다. Target Build Start, Replication Start, Cutover Date, Acceptance Date가 앞 네 날짜입니다. 나머지는 Rollback Window End, Hypercare End, Source Decommission Date, Contract End Date의 여덟 날짜입니다.[8]
단계 | 주요 비용 |
|---|---|
| Assessment·설계 | Discovery, Architecture, POC, 교육, 외부 지원 |
| 목표 환경 구축 | 목표 Cloud 비용 시작, Tooling, Monitoring·Security 재구축 |
| Replication·Rehearsal | 원본 비용 + 목표 비용 + 데이터 동기화 + Test 환경 |
| Cutover | 야간·주말 지원, 최종 동기화, DNS·Routing 변경, 사업 중단 위험 |
| Hypercare | 원본 유지 가능성 + 목표 운영비 + Migration Team·Operations Team 병행 |
| Decommission | 계약 해지, 자산 상각·폐기, 임시 자원 정리 |
| 정상 운영 | 목표 환경의 Recurring Cost |
현금비용·회계비용·기회비용을 섞지 않는다
Migration TCO에는 성격이 다른 재무 항목이 들어옵니다. 예를 들어 기존 서버의 장부가액을 전액 손실로 처리하면서 같은 금액을 다시 계약 해지 현금비용으로 더하면 이중 계산이 될 수 있습니다.
내부 정규직 인력도 마찬가지입니다. 급여는 이전 여부와 무관하게 지급되지만 Migration에 투입된 시간만큼 다른 개발이 지연될 수 있습니다. 이 경우 회계상 증분 현금지출과 의사결정상 기회비용을 나눠 보고하는 편이 정확합니다.
- Cash Cost
- CSP Invoice, Consultant, Tool License, Egress, 추가 회선, 초과근무처럼 실제로 지출되는 비용입니다. 실제 지출 시점에 반영합니다.
- Accounting Cost
- 아직 남은 장비 장부가액의 상각, 폐기 손실처럼 현금 유출이 없는 비용입니다. 현금 유출과 구분해 별도로 표시합니다.
- Opportunity Cost
- 기존 개발자가 Migration 때문에 Product Roadmap을 미루는 시간입니다. 이미 인건비를 Cash Cost로 넣었다면 중복 계산하지 않습니다.
비용의 원인에서 지속 관리까지 — 지출을 업무와 자원 단위로 나누고 영향도를 확인한 조치와 예산 가드레일을 운영에 연결합니다.
Downtime과 Rollback은 예비비 비율로 대체하지 않는다
위험비용은 '전체 예산의 몇 퍼센트'처럼 일괄 적용하기보다 위험 사건별로 계산합니다. Risk-adjusted Cost = 발생확률 × 발생 시 재무영향.
예를 들어 Cutover 시간 초과, 데이터 정합성 오류, 성능 기준 미달, Application Dependency 누락, DNS·Routing 오류, Rollback 후 데이터 병합, Hypercare 기간 연장, 원본 계약 해지 지연을 별도 항목으로 둡니다. 각 위험에는 Low·Base·High 영향값, 발생확률, 완화조치와 책임자를 기록합니다.
다만 기대비용이 작다고 해서 높은 충격의 위험을 허용해도 된다는 뜻은 아닙니다. 허용 가능한 중단시간이나 데이터 손실을 초과하는 사건은 평균 비용으로 희석하지 말고 별도의 설계·승인 조건으로 남겨야 합니다.[5] Google은 Migration Plan의 각 단계마다 Rollback 전략을 만들고 실제 작동 여부를 검증하며, 단계별 최대 실행시간이 지나면 Rollback을 시작하는 조건을 정하도록 권고합니다.[14]
Cutover가 끝나도 이전 프로젝트는 끝나지 않는다
DNS가 목표 환경을 가리키고 사용자가 접속할 수 있다고 해서 곧바로 Migration Team을 해산하면 안 됩니다. AWS의 Wave Planning은 Cutover 이후 Migration Team이 운영팀을 지원하고 최적화를 수행하는 Hypercare 단계를 별도로 둡니다. 운영팀이 Workload를 인수하고 Cutover 문제를 해결한 뒤에야 Wave를 종료합니다.[8]
안정화 기간에는 성능 병목과 Configuration 수정, 누락된 Alert·Dashboard 보완, Log Volume과 Cloud Cost 조정, 권한·보안 정책 보정 비용이 남을 수 있습니다. 사용자 문의와 데이터 정산, 운영 Runbook 업데이트, On-call과 Support 확대, 원본 환경 폐기 승인, 남은 임시 자원과 License 정리도 이 기간의 비용입니다.
Google 역시 이전 후 Optimization을 반복 작업으로 설명하며 최적화에는 Resource·Time·Effort·Skill이라는 비용이 든다고 명시합니다.[16] Post-migration Stabilization은 이전 후 언젠가 수행할 일반적인 비용 최적화와 구분해, Migration Project 자체의 Temporary Cost로 예산화하는 편이 좋습니다.
Migration TCO Worksheet
아래 Worksheet는 Workload 또는 Migration Wave마다 한 줄씩 복제해 사용합니다. 각 행에는 Low·Base·High 금액과 발생 시점·기간, Owner와 Evidence 칸을 둡니다.
사용 원칙은 여섯 가지입니다. 평가기간 H를 먼저 정합니다. 비용은 발생 월과 종료 월을 함께 기록합니다. 확정 비용과 불확실한 비용을 같은 값으로 섞지 않습니다. 내부 인력은 현금비용과 기회비용 중 어떤 기준으로 계산했는지 표시합니다. 모든 금액에는 견적서·계약서·사용량·작업시간 등 Evidence와 Owner를 연결합니다. Low·Base·High 중 하나만 숨기고 Base 값만 보고하지 않습니다.
ID | 비용 영역 | 기본 분류 | 주요 산정 Driver | 재무 처리 | 발생확률·시점 |
|---|---|---|---|---|---|
| 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% 또는 연장 위험 |
분류별 합계와 최종 계산식
Worksheet의 행을 채웠으면 분류별로 합산합니다. 합계 항목은 아래 아홉 가지입니다.
최종 계산식은 세 줄입니다. 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와 한 숫자로 합칠 때 중복이 없는지 확인해야 합니다.
- 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)
- 이전하지 않을 경우 같은 기간에 드는 비용입니다. 비교용으로 둡니다.
하나의 숫자보다 세 가지 시나리오가 낫다
Migration TCO는 단일 정답보다 Low·Base·High 세 가지 시나리오로 보는 편이 실용적입니다. AWS도 상세 Business Case에서 최소 변화, 가장 가능성 높은 경우, 중요한 가정이 달라지는 경우를 별도 시나리오로 모델링하도록 안내합니다.[7]
각 시나리오에서 특히 민감한 입력은 Refactoring Person-day, 데이터량과 Change Rate, Dual Run 개월 수, 원본 환경 Decommission 날짜입니다. Hypercare 기간, 기존 계약 종료 날짜, 허용 가능한 Downtime, Rollback 발생 가능성과 영향도 결과를 크게 움직입니다. 이 값이 변했을 때 TCO가 얼마나 달라지는지를 보는 것이 단일 서버 가격을 소수점 단위로 비교하는 것보다 중요한 경우가 많습니다.
- Low / 원활한 전환
- 계획한 기간 안에 이전하고 Dual Run이 짧으며 추가 Refactoring이 없는 경우입니다.
- Base / 가장 가능성 높은 전환
- 예상된 결함 수정과 안정화, 승인된 Buffer를 포함한 경우입니다.
- High / 불리한 전환
- Dual Run 연장, 추가 Refactoring, 재전송 또는 일부 Rollback이 발생한 경우입니다.
이전 예산을 승인하기 전에 확인할 질문
다음 질문에 답하지 못한다면 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의 역할은 클라우드 이전이 항상 비용을 절감한다고 증명하는 것이 아닙니다. 어떤 비용과 위험을 감수하고 언제 기존 환경을 끝낼 수 있는지를 의사결정자가 확인할 수 있게 하는 것입니다.
