“클라우드로 옮기면 비용도 줄고 민첩해진다.”
한동안 디지털 트랜스포메이션의 단골 문구였습니다. 그런데 막상 대규모 마이그레이션을 끝낸 기업들의 얘기를 들어보면 분위기가 사뭇 다릅니다.
- 예상을 넘어선 비용
- 기약 없이 늘어진 일정
- 그리고 “옮기긴 했는데 뭐가 좋아진 건지 모르겠다”는 자조 섞인 회고까지 따라붙습니다.
한 맥킨지 분석에 따르면 기업들은 매년 계획 대비 평균 14% 더 많은 마이그레이션 비용을 쓰고, 38%는 일정이 한 분기 이상 지연됐다고 합니다.
문제는 클라우드 자체가 아니라, 클라우드를 어떻게 다루느냐입니다. 즉, 무엇을 어떤 방식으로 옮길지, 어떤 기반 위에 올릴지, 어떻게 비용을 통제할지에 대한 판단입니다.
이 글에서 답해보려는 질문은 다음과 같습니다.
- 모든 워크로드를 클라우드로 옮기는 게 정답인가
- 옮긴다면 어떤 방식이 적합한가 (6R)
- 그리고 클라우드 위에서 가치가 새는 것을 막으려면 어떤 기반이 필요한가
1. 클라우드는 “얼마나 옮기느냐”가 아니라 “어디서 가치가 나오느냐”의 문제
대규모 클라우드 마이그레이션이 기대에 못 미치는 이유는 대부분 “일단 다 옮기고 보자”는 식으로 접근했기 때문입니다. 그런데 클라우드가 만드는 진짜 가치는 데이터센터를 저렴한 인프라로 갈아 끼우는 데 있지 않습니다. 비즈니스의 민첩성, 혁신 속도, 복원력이 올라가는 데서 나옵니다.
클라우드 마이그레이션은 ‘이사’가 아니라 ‘리모델링’에 가깝습니다. 짐만 옮긴다고 집이 좋아지지 않습니다. 어떤 방을 어떻게 바꿀지 정해야 진짜 변화가 시작됩니다.
비즈니스와 기술을 동시에 재설계한다는 것
클라우드 이관은 사업과 고객에게 가치있는 일이 되어야 합니다. “가치 중심으로 옮기자”라는 말은 우선순위로 정한 비즈니스 도메인부터 손대고, 그 도메인 안에서 비즈니스와 기반 기술을 같이 재설계한다는 것입니다.
한 보험사의 고객 온보딩 사례가 이 ‘동시 재설계’의 모습을 잘 보여줍니다. 이 회사가 택한 방식은 두 팀을 따로 일하게 하지 않고, 같은 사용자 여정 지도를 보며 함께 의사결정을 내리도록 한 것이었습니다.
[동시 재설계: 두 팀이 함께 일한 방식]
┌──────────────┐ ┌──────────────┐
│ 프로세스 재설계 │ │ 플랫폼 현대화 │
│ 팀 │ │ 팀 │
└──────┬───────┘ └──────┬───────┘
│ 같은 회의실 │
│ 같은 여정지도 │
▼ ▼
┌────────────────────────────┐
│ "이 단계에서 신원 확인을 │
│ 실시간으로 하고 싶다" │
└────────────┬───────────────┘
│ (요구가 설계로 흘러감)
▼
┌────────────────────────────┐
│ 마이크로서비스가 그 요구에 │
│ 맞춰 설계됨 │
└────────────────────────────┘
이 다이어그램의 핵심은 비즈니스 요구가 플랫폼 설계 단계에서 살아 있었다는 점입니다. 두 팀이 분리되어 일했다면 “실시간 신원 확인”이라는 요구는 플랫폼이 다 만들어진 뒤에야 떠올랐을 것이고, 그때는 이미 늦습니다. 결과적으로 온보딩 경험과 플랫폼이 함께 새로 태어났습니다.
반대로 두 팀을 분리해 운영했다면 어떻게 됐을까요. 익숙한 실패 시나리오가 펼쳐집니다.
[순차 진행: 흔한 실패 시나리오]
1단계: 플랫폼 먼저 옮기기
┌────────────────────────┐
│ 기존 프로세스 그대로 │
│ 클라우드에 올림 │
└───────────┬────────────┘
│ (플랫폼이 그 모양 그대로 자리잡음)
▼
2단계: 나중에 경험 바꾸기 시도
┌────────────────────────┐
│ "고객 경험 바꿔보자" │
│ → 플랫폼이 안 받아줌 │
└───────────┬────────────┘
│
▼
┌────────────────────────┐
│ "옮기긴 했는데 │
│ 뭐가 좋아졌는지 모르겠다" │
└────────────────────────┘
핵심은 순서가 어긋나면 결국 같은 일을 두 번 해야 한다는 점입니다. 1단계에서 옮긴 플랫폼을 2단계에서 다시 뜯어고쳐야 하기 때문입니다. 동시 재설계가 협업의 문제가 아니라 비용의 문제이기도 한 이유가 여기에 있습니다.
다시 말해, 비즈니스 도메인과 기반 기술의 동시 재설계는 단순한 협업의 문제가 아니라 순서의 문제입니다. 둘 중 하나가 먼저 자리잡으면 다른 하나는 그 모양을 따를 수밖에 없습니다.
[동시 재설계가 '순서 문제'인 이유]
비즈니스 ──┐
├─▶ 함께 자리잡음 ─▶ 서로 맞물려 작동 ✓
기술 ──┘
비즈니스 먼저 자리잡음 ─▶ 기술이 따라가야 함 (제약 발생) △
기술 먼저 자리잡음 ─▶ 비즈니스가 따라가야 함 (가치 못 냄) ✗
클라우드 마이그레이션은 기술 결정이 먼저 떨어지는 경향이 있어 자연스럽게 세 번째로 흘러갑니다. 우선순위 도메인을 정하는 일은 이 흐름을 첫 번째 경로(동시 재설계)로 되돌리기 위해 어디서부터 함께 시작할지 정하는 작업입니다.
정리하자면, 클라우드 마이그레이션의 첫 질문은 “얼마나 옮길까”가 아니라 “어디서 가치가 나오는가, 그리고 그 가치를 위해 비즈니스와 기술을 어떻게 같이 바꿀까“입니다.
2. 마이그레이션의 6가지 유형: 6R
도메인을 정했다면, 다음 질문은 “이 안의 애플리케이션을 어떻게 처리할 것인가”로 넘어갑니다. 같은 도메인 안에 있어도 시스템마다 사정이 다릅니다. 어떤 건 이미 수명이 다해 정리할 때가 됐고, 어떤 건 멀쩡히 잘 돌아가서 굳이 손댈 이유가 없습니다. 그 사이에 ‘어떻게든 클라우드로 옮겨야 하는’ 다양한 시스템이 놓여 있습니다.
이 판단을 정리한 의사결정 도구가 6R입니다. 옮길지 말지, 옮긴다면 얼마나 많이 손볼지를 결정하는 여섯 가지 선택지인데, 모두 영문 단어가 R로 시작해서 붙은 이름입니다. 정리해보면 결국 양 끝(폐기/유지) 과 사이의 네 가지 옮기는 방식으로 나뉩니다.
이 프레임워크가 어떻게 만들어졌는지를 짚어두면 6R을 이해하는 데 도움이 됩니다. 원형은 2010~2011년 가트너가 제시한 5R(Rehost·Refactor·Revise·Rebuild·Replace)이었습니다. 클라우드 마이그레이션이 본격화되기 시작한 시점에 ‘어떻게 옮길까’의 옵션을 분류한 첫 시도였습니다. 이후 AWS가 2016년에 ‘Retire(폐기)’를, 2017년에 ‘Retain(유지)’을 추가하면서 7R로 확장했습니다. 옮기지 않는 선택(폐기·유지)이 명시적으로 들어왔다는 게 핵심 변화입니다. 즉, 6R/7R은 누가 만든 고유 모델이 아니라 클라우드 마이그레이션 업계가 10여 년에 걸쳐 다듬어온 공통 어휘라고 보면 됩니다.
1) 양 끝: 옮기지 않는 두 선택
가장 먼저 짚어야 할 건, 모든 시스템을 클라우드로 옮길 필요는 없다는 점입니다. 양 끝에 자리한 두 옵션이 그 점을 말해줍니다.
- 폐기 (Retire): 1~2년 안에 사용 종료가 예정된 시스템, 또는 다른 시스템에 기능이 흡수되어 자리를 잃은 시스템에 적용합니다. 짐을 옮기기 전에 버릴 짐부터 가려내는 단계입니다. 마이그레이션 범위가 줄어드는 만큼 비용도 줄고, 옮긴 뒤 운영 부담도 가벼워집니다.
- 유지 (Retain): 옮기지 않고 그대로 두는 선택입니다. 규제 때문에 온프레미스에 둬야 하는 시스템, 곧 폐기 예정이라 옮길 가치가 없는 시스템, 또는 기술적으로 마이그레이션 준비가 덜 된 시스템이 여기에 해당합니다. ‘일단 두고 본다’는 결정을 내리는 것도 6R의 일부라는 점을 짚어둘 만합니다.
이 두 선택은 흔히 “마이그레이션 전략”을 말할 때 잊히지만, 무엇을 옮기지 않을지를 먼저 정하는 일이 옮길 대상의 우선순위를 가른다는 점에서 출발점이 됩니다.
2) 사이의 네 가지 ‘이관’: 얼마나 손볼 것인가
옮기기로 결정한 시스템도 손보는 깊이에 따라 비용·기간·기대 효과가 크게 달라집니다. 네 가지 방식을 변경 강도가 낮은 순서대로 보면 다음과 같습니다.
| 옵션 | 손보는 깊이 | 비유 | 적합한 상황 |
|---|---|---|---|
| 리호스팅 (Rehost) | |||
| 리프트 앤 시프트 (Lift and Shift) | ★ | 가구를 그대로 새 집으로 옮기는 이사 | 데이터센터 계약 만료처럼 빠르게 자리를 옮겨야 할 때 |
| 리플랫포밍 (Replatform) | ★★ | 가구는 그대로 두되 보일러·전기는 새 집 사양으로 교체 | 앱 코어는 유지하되 DB나 메시지 큐 정도는 클라우드 매니지드 서비스로 바꾸고 싶을 때 |
| 리팩터링 / 리아키텍팅 (Refactor) | ★★★★ | 골조만 남기고 내부를 다시 설계해 인테리어부터 새로 | 모놀리식을 쪼개고, 컨테이너·서버리스로 옮겨야 새 비즈니스 요구를 받을 수 있을 때 |
| 교체 (Repurchase) | (대체) | 살던 집을 처분하고 가구 딸린 새 집으로 이주 | 자체 개발 시스템 대신 시장의 SaaS로 갈아타는 것이 더 합리적일 때 |
(1) 리호스팅 (Rehost): 가장 흔한, 그리고 가장 자주 실망스러운 선택
리호스팅은 코드와 아키텍처는 그대로 둔 채 실행 환경만 클라우드로 바꾸는 방식입니다.
문제는 클라우드에서 얻을 수 있는 이득 대부분이 리호스트의 사정거리 밖에 있다는 점입니다. 클라우드의 진짜 무기는 클라우드 내 관리형 서비스, 자동 스케일링, 마이크로서비스 같은 클라우드 네이티브 역량인데, 코드를 안 바꾼 앱은 이 역량을 거의 활용하지 못합니다.
결과적으로 데이터센터의 서버 한 대를 클라우드의 가상머신 한 대로 바꾼 셈이 됩니다. 임대료(클라우드 사용료)는 꼬박꼬박 나가지만, 집 자체는 예전 그대로인 셈이죠.
그래도 이 옵션이 의미가 있는 경우가 있습니다. 데이터센터 계약 만료가 임박했거나, IDC 임대료가 갑자기 오르거나, 회사 분할로 인해 시스템을 빨리 분리해야 하는 상황입니다. 이때는 “일단 리호스팅으로 옮긴 뒤 운영하면서 점진적으로 리팩터링한다”는 전략이 자주 쓰입니다. 출발점으로는 정당하지만 종착점으로는 부족한 선택, 정도로 이해해도 좋지 않을까 합니다.
(2) 리플랫포밍 (Replatform): 가성비가 좋은 절충안
리플랫포밍은 코드 대부분을 건드리지 않으면서 인프라 구성요소만 클라우드 내 관리형 서비스로 바꾸는 방식입니다. 가장 흔한 시나리오는 다음과 같습니다.
- 자체 운영하던 PostgreSQL/Oracle DB를 AWS RDS, Azure Database, GCP Cloud SQL 같은 매니지드 DB로 이관
- 자체 운영하던 Kafka·RabbitMQ를 Amazon MSK·Azure Service Bus 같은 매니지드 메시징으로 이관
- 정적 자산을 S3 + CloudFront 같은 오브젝트 스토리지 + CDN 조합으로 이관
백업·고가용성·패치 관리·확장성처럼 운영 인력이 직접 매달려야 했던 영역이 매니지드 서비스의 SLA 안으로 들어갑니다. 운영 및 보수에 할애되던 인프라 관리 시간을 절약시켜 조직이 실질적인 비즈니스 기능 개선을 할 수 있도록 할 수 있습니다.
코드 변경은 보통 DB 드라이버 버전, 연결 설정, 일부 SQL 호환성 정도여서 리팩터링에 비해 훨씬 가볍습니다. 이래서 많은 기업이 리호스팅을 1단계로, 리플랫포밍을 2단계로 잡습니다. 일단 옮겨놓고 안정화한 뒤, 운영 부담이 큰 컴포넌트부터 차례로 매니지드 서비스로 갈아끼우는 식입니다.
(3) 리팩터링 / 리아키텍팅 (Refactor): 가장 무겁지만 효과의 최대치가 가장 높은 선택
리팩터링은 모놀리식(monolithic) 애플리케이션을 마이크로서비스로 쪼개고, 컨테이너·서버리스를 활용하는 본격적인 재설계입니다.
리팩터링이 가장 빛을 발하는 영역은 트래픽 변동이 큰 시스템입니다. 한국 이커머스의 새벽 배송 결제 시스템을 떠올려보면 이해가 쉽습니다. 평소에는 한가하다가 자정 직후 1~2시간 동안 평소 수십 배의 트래픽이 몰립니다. 모놀리식 시스템을 그대로 클라우드에 올려서는 이 피크를 못 견딥니다. 결제·재고·정산을 마이크로서비스로 쪼개고, 트래픽에 따라 자동으로 늘어나는 컨테이너 환경으로 다시 짜야 비로소 클라우드의 탄력성을 누릴 수 있습니다.
카카오뱅크의 모놀리식 → MSA 전환 여정이 이 변화의 실제 모습을 잘 보여줍니다. 카카오뱅크는 모놀리식으로 출발했지만, 서비스가 커지면서 하루 3천만 트래픽을 받는 홈 화면 같은 핵심 기능을 마이크로서비스로 떼어내는 작업을 단계적으로 진행하고 있습니다. 이 과정에서 Consul 기반 서비스 디스커버리, Envoy 사이드카 기반 서비스 메시, API Gateway의 동적 라우팅 같은 인프라 요소가 함께 들어갔습니다. 즉, 리팩터링은 단순히 “코드를 나누는 일”이 아니라 나뉜 서비스들이 안정적으로 통신하도록 떠받치는 인프라까지 새로 깔아야 하는 일입니다.
이게 리팩터링이 시간적으로나 인력적으로나 비싼 이유입니다. 코드만 바꾸면 끝이 아니라, 서비스 디스커버리·로드밸런싱·서킷 브레이커·관측성(observability)·CI/CD 파이프라인까지 같이 새로 만들어야 합니다. 그래서 보통 새 비즈니스 요구사항이 명확하고, 그 요구사항이 기존 아키텍처로는 불가능할 때 정당화됩니다.
(4) 교체 (Repurchase): “직접 만들지 않는다”는 선택
교체는 자체 개발한 시스템을 시장의 SaaS로 대체하는 방식입니다. 인사·급여 시스템을 워크데이로, 메일 서버를 구글 워크스페이스나 마이크로소프트 365로, CRM을 세일즈포스로 갈아끼우는 사례가 모두 여기에 해당합니다.
인사 시스템을 직접 개발·운영하려면 매년 법령 개정 때마다 코드를 고쳐야 하고, 보안 취약점을 패치해야 하고, 데이터센터에 서버를 더 사야 합니다. 워크데이를 쓰면 이 모든 부담이 SaaS 제공자 쪽으로 넘어갑니다. 우리 회사는 “이 영역이 우리 비즈니스의 차별화 요소인가”라는 질문에 답이 ‘아니오’인 시스템부터 교체 후보로 잡으면 됩니다.
다만 교체에는 함정도 있습니다. 첫째, 기존 데이터의 마이그레이션이 만만치 않습니다. 둘째, SaaS의 표준 기능에 우리 비즈니스를 맞춰야 하기 때문에 세부 커스터마이징이 어렵습니다. 셋째, 벤더 종속의 위험이 새로 생깁니다. 가격 인상이나 서비스 변경 때 협상력이 약해집니다. 그래서 교체는 “우리만의 차별화가 필요 없는 영역”에 한정해서 쓰는 것이 안전합니다.
3) 도메인 단위로 한꺼번에 본다는 원칙
여기까지가 옵션 하나하나의 이야기입니다. 그런데 더 강조해야 할 원칙이 따로 있습니다. “애플리케이션 하나씩 따로 보지 말라”는 것입니다. 비즈니스 도메인 안에 묶인 시스템들은 서로 데이터를 주고받기 때문에, 한 시스템만 잘 옮기는 것으로는 효과가 나지 않습니다.
도입부에서 언급한 보험사 고객 온보딩 사례를 6R 관점으로 다시 보면 이 원칙이 분명해집니다. 만약 이 보험사가 고객용 모바일 온보딩 앱만 클라우드 네이티브로 새로 짓고(리팩터링), 그 뒤에서 신원 확인을 처리하는 코어 시스템은 그대로 두는(유지) 방식을 택했다면 어땠을까요. 새 앱은 빠르게 응답할 준비가 되어 있어도, 코어가 옛 처리 속도로 답을 돌려주는 순간 전체 경험은 옛날 그대로입니다. 그래서 이 회사는 온보딩 프로세스의 모든 시스템을 한 번에 평가하고, 각각에 맞는 R을 골라 동시에 손봤습니다. 이것이 “비즈니스 도메인과 기반 기술의 동시 재설계”의 실제 모습입니다.
선도 기업들이 흔히 쓰는 방식도 비슷합니다. 단일 옵션을 고집하는 대신 도메인 안에서 R을 섞어 씁니다. 보조 시스템은 리호스팅으로 빨리 옮겨 데이터센터 비용을 떨어뜨리고, 핵심 시스템은 리팩터링으로 본격적으로 다시 짓는 식입니다.
3. 마이그레이션을 떠받치는 기반: 클라우드 파운데이션과 FinOps
“우리는 6R 다 따져보고 잘 옮겼는데, 왜 비용은 줄고 속도는 빨라지지 않았지?”라는 질문이 나오는 지점이 있습니다. 이때 짚어야 할 것이 클라우드 파운데이션과 FinOps입니다. 이 둘은 한 편의 글에서 깊이 다루기엔 큰 주제라, 여기서는 “이런 게 있다” 정도로만 짚어둡니다.
1) 클라우드 파운데이션
클라우드 파운데이션은 클라우드를 어떻게 쓰고, 보안하고, 운영할지를 코드로 정의해둔 설계 결정의 묶음으로 이해할 수 있습니다. 견고한 파운데이션 없이 마이그레이션을 시작한 조직은 도중에 멈춰서거나, 옮긴 뒤 운영 비용이 도리어 늘어나는 경우가 많습니다.
파운데이션은 보통 세 층으로 정리됩니다.
[클라우드 파운데이션 3계층]
애플리케이션 패턴 (Application patterns)
- 표준화된 앱 구성·배포 자동화 (예: SQL DB, 정적 웹사이트, 3계층 웹앱)
▲
│
격리 영역 (Isolation zones, 또는 랜딩 영역)
- 애플리케이션이 실제로 운영되는 클라우드 환경
- IAM, 네트워크 격리, 변경 제어가 적용되는 단위
▲
│
기본 클라우드 역량 (Base capabilities)
- 네트워크, 방화벽, 아이덴티티, 모니터링, 보안 적용
- 한 번 만들면 모든 격리 영역이 공유
핵심은 아래 층이 위 층을 떠받치는 구조라는 점입니다. 기본 역량을 한 번 잘 세팅해두면 위에서 격리 영역을 여러 개 만들 때 똑같은 작업을 반복하지 않아도 됩니다. 그 위에 애플리케이션 패턴이 올라가면, 새로운 앱을 배포할 때도 매번 보안·컴플라이언스를 처음부터 따지는 게 아니라 “이건 SQL DB 패턴” 식으로 표준화된 템플릿을 가져다 씁니다. 한 대형 은행은 단 10개의 애플리케이션 패턴만으로 전체 유스케이스의 95%를 커버했다는 사례도 있습니다.
(1) 격리 영역이 무엇이고 왜 필요한가
격리 영역은 여러 애플리케이션을 서로 분리해 운영하는 클라우드 환경입니다. AWS의 ‘랜딩 존(Landing Zone)’, Azure의 ‘구독(Subscription)+관리 그룹(Management Group)’, GCP의 ‘프로젝트+폴더’ 같은 개념이 모두 격리 영역의 다른 이름이라고 보면 됩니다. 격리 영역마다 별도의 IAM 권한 체계, 네트워크 경계, 변경 제어 규칙을 가질 수 있습니다.
격리 영역이 하나뿐이면, A 앱을 위한 설정 변경이 B 앱에 의도치 않게 영향을 줄 수 있습니다. 예컨대 A 앱의 보안 정책 강화를 위해 모든 외부 접근을 막아버리면, 같은 영역 안의 B 앱이 외부 결제 게이트웨이와 통신하지 못하는 사고가 생깁니다. 반대로 앱마다 격리 영역을 따로 두면 같은 작업을 수십 번 반복해야 합니다. 새 보안 패치 하나를 적용하기 위해 50개 격리 영역에 동일한 변경을 일일이 배포해야 하는 식이죠.
그래서 둘 사이의 균형, 즉 장애에 대비할 만큼은 분리하되 너무 많이 만들지는 않는 적정 수를 잡는 것이 중요한 설계 결정입니다. 한국 금융권에서는 망분리 규제 때문에 격리 영역 설계가 더 까다롭습니다. 내부 업무망과 외부 업무망 사이의 경계가 격리 영역 경계와 자연스럽게 맞물려야 하기 때문입니다.
(3) 애플리케이션 패턴이 무엇이고 왜 필요한가
애플리케이션 패턴은 유사한 요구사항을 가진 앱들을 표준화된 템플릿으로 묶어둔 ‘배포 레시피’ 입니다. 코드형 인프라(IaC), 보안 코드(Security as Code), 정책 코드(Policy as Code)로 구현됩니다.
예를 들어 ‘3계층 웹앱 패턴’은 보통 이런 모양입니다. 로드밸런서 + 웹 서버 + 애플리케이션 서버 + DB로 구성되고, 각 계층 사이에 보안 그룹과 방화벽 규칙이 자동으로 붙고, 로그가 중앙 모니터링으로 흘러가고, 백업 정책이 자동 적용됩니다. 새로운 웹앱을 배포할 때 개발팀이 이 패턴을 가져다 쓰면, 보안·컴플라이언스 검토를 처음부터 받을 필요가 없습니다. 패턴 자체가 이미 검증을 통과한 상태이기 때문입니다.
이 방식의 강점은 개발팀의 자유도와 거버넌스의 강제력을 동시에 확보할 수 있다는 것입니다. 패턴 안에서는 마음껏 빠르게 만들 수 있고, 패턴 밖으로 나가는 결정은 별도 승인을 받게 됩니다. 이 파운데이션을 잘 만들면 마이그레이션 속도가 최대 8배까지 빨라지고, 장기적으로 비용을 50%까지 절감할 수 있다는 분석도 있습니다.
(4) 클라우드 서비스 제공자(CSP) 선정의 원칙: 팀 자율성 vs. 엔터프라이즈 표준화
파운데이션 얘기에 한 가지 덧붙여야 할 게 있습니다. 클라우드 서비스 제공자(CSP, Cloud Service Provider)를 누가 선정하느냐의 문제입니다. 클라우드 마이그레이션 초기에 흔히 나오는 의견이 “애자일 팀이 자율적으로 자기 클라우드를 고르도록 하자”는 것입니다. 듣기에는 합리적이지만 현실에서는 자주 실패합니다.
팀 단위 자율 선정은 곧 조직 전체의 파편화로 이어집니다. A팀은 AWS, B팀은 Azure, C팀은 GCP를 골랐다고 가정해보겠습니다. 처음에는 각 팀이 빠르게 움직일 수 있지만, 시간이 지나면 다음과 같은 문제들이 쌓입니다.
- CSP 간 데이터 이동이 어려움: 한 팀이 만든 데이터를 다른 팀이 활용하려면 클라우드 간 네트워크 비용과 지연이 발생합니다.
- 공통 운영의 불가능: 모니터링, 보안, 비용 관리를 CSP마다 따로 구축해야 합니다.
- 인력 채용의 어려움: AWS·Azure·GCP를 모두 깊이 다룰 수 있는 엔지니어는 시장에 흔하지 않습니다.
그래서 엔터프라이즈 아키텍처 팀이 어떤 서비스를 표준화할지 미리 정해두는 일이 중요합니다. “전사 표준 데이터베이스 서비스는 AWS RDS PostgreSQL이다”, “전사 표준 메시징은 Azure Service Bus다”처럼요. 표준화된 서비스 안에서는 팀이 자유롭게 움직이고, 표준 밖으로 나가려면 별도 승인을 받게 하는 것이 현실적인 절충안입니다. 자율성과 일관성 중 하나를 완전히 포기하지 않는 길입니다.
2) FinOps
FinOps는 클라우드 지출을 관리하는 운영 방식입니다. ‘Finance’와 ‘DevOps’의 합성어인데, FinOps Foundation은 이를 “기술의 비즈니스 가치를 극대화하고, 적시에 데이터 기반 의사결정을 가능하게 하며, 엔지니어링·재무·비즈니스 팀 간 협업을 통해 재무적 책임 의식을 만들어내는 운영 프레임워크이자 문화적 실천”으로 정의합니다. 핵심은 ‘비용 절감 도구’가 아니라 ‘부서 간 협업을 통한 의사결정 방식’이라는 점입니다.
(1) 왜 FinOps가 필요한가: 기존 IT 비용 관리와의 차이
기존 온프레미스 IT는 비용 구조가 단순했습니다. 서버를 사면 그 값이 자본 지출(CAPEX)로 잡히고, 한 번 사면 정해진 기간 동안 정해진 비용이 들어갔습니다. 클라우드는 이 구조를 통째로 뒤집었습니다. 사용한 만큼 지불하는 변동비(OPEX) 모델이기 때문에, 이번 달 청구서가 지난 달의 두 배일 수 있습니다.
이 변화가 만들어낸 새로운 문제는 비용을 결정하는 사람과 비용을 책임지는 사람이 분리된 것입니다. 클라우드에서는 개발자가 코드 한 줄로 새 서버를 띄울 수 있는데, 그 결정의 청구서는 한 달 뒤 재무팀이 받습니다. 재무팀은 “왜 이 비용이 나왔는지” 모르고, 개발팀은 “내가 띄운 게 얼마인지” 모릅니다. 이 단절을 메우자는 게 FinOps의 출발점입니다.
(2) FinOps의 6가지 원칙
FinOps Foundation은 6가지 핵심 원칙을 제시합니다.
| 원칙 | 의미 |
|---|---|
| 팀이 협업한다 | 엔지니어링·재무·비즈니스가 한 테이블에서 결정 |
| 비즈니스 가치가 기술 결정을 이끈다 | 비용 절감 자체가 아니라 ‘비용 대비 효과’ 관점 |
| 모두가 자기 사용량에 책임진다 | 개발팀이 자기가 띄운 자원의 비용을 본다 |
| FinOps 데이터는 접근 가능하고 적시에 정확해야 한다 | 청구서를 한 달 뒤가 아니라 거의 실시간으로 본다 |
| FinOps는 중앙에서 지원한다 | 협상·자동화·표준화는 중앙 팀이 맡는다 |
| 클라우드의 변동 비용 모델을 활용한다 | 작은 조정을 자주 한다, 한 번에 큰 결정을 내리지 않는다 |
이 중에서 기업들이 가장 어려워하는 부분이 “개발팀이 자기 사용량에 책임진다”입니다. 대부분의 IT 조직은 전통적으로 개발팀과 인프라팀이 분리돼 있고, 비용은 인프라팀이 묶어서 보는 구조가 흔하기 때문입니다. FinOps를 제대로 적용하려면 “이 마이크로서비스의 이번 달 클라우드 비용은 얼마”를 개발팀이 자기 KPI로 받아야 합니다. 이게 단순한 도구 도입을 넘어 조직 문화의 변화라는 얘기를 듣는 이유입니다.
(3) FinOps의 3대 단계: Inform → Optimize → Operate
FinOps Foundation은 FinOps의 라이프사이클을 ‘Inform → Optimize → Operate’의 3단계로 정의합니다. 각 단계가 ‘무엇을 하는가’를 나타냅니다.
[FinOps 3단계 라이프사이클]
① Inform (가시화) ──▶ ② Optimize (최적화) ──▶ ③ Operate (운영화)
- 누가 얼마 쓰는지 - 사용량·요금제 조정 - 자동화된 정책으로 운영
보이게 한다 으로 비용을 줄인다 반복 가능한 체계로 만든다
- 태깅·할당 체계 구축 - Reserved Instance, - 이상 탐지·예측·자동 회수
- 대시보드로 추적 Savings Plan 활용 - 거버넌스 자동 적용
가시화가 안 된 상태에서 최적화를 시도하면 “무엇을 줄여야 할지” 모르고, 최적화 없이 운영화로 가면 “무엇을 자동화해야 할지” 모릅니다. 그래서 1단계 가시화부터 차근차근 쌓아 올린 뒤 다음 단계로 넘어가는 것이 일반적인 권장 흐름입니다.
참고로 FinOps Foundation은 이 라이프사이클과는 별개로 ‘Crawl → Walk → Run’이라는 성숙도 모델을 함께 제시합니다. 라이프사이클이 ‘무엇을 하는가’라면, 성숙도 모델은 ‘얼마나 잘 하는가’를 나타냅니다. 두 개념은 자주 혼동되는데, Crawl 단계의 조직도 이미 Inform·Optimize·Operate를 다 하고 있고, 다만 그 깊이와 자동화 수준이 다를 뿐입니다.
잘 운영된 FinOps는 클라우드 지출을 최대 20%까지 절감할 수 있다고 알려져 있습니다. 핵심은 자동화된 대시보드로 사용량을 추적하고 리소스를 재배분하는 일과, 전사 차원에서 클라우드 지출을 모니터링하는 재무 규율을 함께 갖추는 것입니다.
핵심은 클라우드 마이그레이션이 “얼마나 많이 옮기느냐”가 아니라 “어디서 가치가 나오느냐”의 문제라는 점입니다. 가치가 명확한 도메인을 골라 비즈니스와 기술을 함께 재설계하고, 6R 중 적절한 조합을 골라 옮기고, 그 위에 견고한 파운데이션과 FinOps 역량을 얹는 것. 이것이 마이그레이션을 “이사”가 아니라 “리모델링”으로 만드는 길입니다.
그런데 현실의 클라우드는 한 번 더 복잡합니다. 한 회사가 보통 두 개 이상의 클라우드를 함께 쓰기 때문입니다. 다음 글에서는 멀티클라우드와 메타클라우드를 다뤄보겠습니다. 여러 클라우드에 흩어진 자원을 어떻게 다룰 것인가, 그리고 그 복잡성을 풀어주는 추상화 레이어로서 메타클라우드가 어디까지 답이 될 수 있는가 하는 이야기입니다.