Flexera 2026 State of the Cloud Report 표지 비주얼 Flexera 2026 State of the Cloud Report 표지 비주얼 — 출처: Flexera (CC BY 4.0)

클라우드를 두 개 이상 쓰고 있다면, 그렇게 하기로 결정한 적이 있는지 한번 떠올려 보세요. 대부분은 없습니다. AWS로 시작한 회사가 GCP를 쓰는 팀을 인수했거나, 데이터 조직이 BigQuery가 좋다고 해서 따로 파거나, 몇 년 전 누군가 만들어 둔 Azure 계정이 아직 돌아가고 있거나. 정신을 차려 보면 클라우드가 셋입니다.

이게 예외적인 사고가 아니라 다수의 상태라는 게 올해 조사의 요지입니다.

대부분은 전략이 아니라 사고로 온다

Flexera가 2025년 겨울에 클라우드 의사결정자 753명을 조사한 2026 State of the Cloud Report를 보면, 하이브리드 클라우드를 운영하는 조직이 73% — 1년 전보다 3%포인트 올랐습니다. 사설 클라우드 없이 공용 클라우드만 여러 개 쓰는 조직은 14%로 따로 잡히고요.

Flexera 2026 조사 기준 클라우드 운영 현황 지표 Flexera 2026 조사 기준 클라우드 운영 현황 지표 — 출처: Flexera 공식 수치 기반 자가 렌더

주목할 건 비율이 아니라 이유입니다. 보고서는 이렇게 적습니다.

많은 조직이 설계가 아니라 우연으로 복잡한 클라우드 환경에 도달한다

인수·합병으로 다른 클라우드를 쓰던 조직이 붙고, 애플리케이션 팀이 각자 고르고, 물려받은 아키텍처가 남습니다. 규모가 클수록 심해져서 직원 5,000명 이하는 69%가 하이브리드인 반면 5,000명 초과는 78%입니다. 월 클라우드 지출로 잘라도 같은 방향으로 갈립니다 — 50만 달러(약 7억 원) 이하는 68%, 초과는 79%.

그래서 “멀티클라우드를 할 것인가”는 대개 이미 지난 질문입니다. 남은 질문은 이미 여러 개인 상태를 어떻게 굴릴 것인가고요. 실제로 낭비되는 클라우드 지출은 29%로 5년 만에 반등했고, 보고서는 그 원인으로 AI와 새 서비스가 더한 비용 복잡도를 꼽습니다.

표준화는 통일이 아니라 층 나누기

여기서 흔한 오해가 하나 있습니다. 표준화를 “하나로 합치는 것”으로 이해하는 겁니다. 클라우드를 하나로 줄이거나, 세 클라우드에서 똑같이 되는 기능만 쓰거나.

둘 다 실패합니다. 앞은 대개 불가능하고(인수한 시스템을 다 옮길 수 없습니다), 뒤는 최소공통분모의 함정입니다 — 세 클라우드에서 공통으로 되는 것만 쓰면 각 클라우드를 쓰는 이유였던 강점을 전부 버리게 됩니다. BigQuery를 쓰려고 GCP를 뒀는데 BigQuery를 안 쓰면 GCP를 둘 이유가 없습니다.

서로 다른 클라우드 위에 공통 제어 층이 얹히는 3D 콘셉트 씬 서로 다른 클라우드 위에 공통 제어 층이 얹히는 3D 콘셉트 씬 — 출처: 개념 컷 — agy 자가 생성

실제로 작동하는 접근은 층을 나누는 것입니다. 클라우드마다 다른 채로 두되, 그 위에 공통 층을 얹고 팀은 그 층하고만 대화합니다. 아래는 달라도 위는 하나인 구조죠.

층 무엇을 통일하나 대표 도구 성숙도
프로비저닝 자원을 어떻게 만드나 Terraform · OpenTofu · Pulumi · Crossplane CNCF 졸업
런타임 워크로드가 어디서 도나 Kubernetes 사실상 표준
신원 워크로드가 누구인가 SPIFFE · SPIRE CNCF 졸업
정책 무엇이 허용되나 Kyverno · OPA/Gatekeeper 졸업·인큐베이팅
관측 무슨 일이 벌어지나 OpenTelemetry CNCF 졸업

다섯 층이 전부 오픈소스이고 특정 클라우드 소유가 아니라는 점이 핵심입니다. 어느 하이퍼스케일러의 관리 도구를 표준으로 삼으면, 그 순간 표준화가 곧 종속이 됩니다.

1층 프로비저닝 — 무엇으로 만들 것인가

가장 먼저 손대는 층이고, 최근 3년간 지형이 가장 많이 흔들린 층이기도 합니다.

2023년 8월 HashiCorp가 Terraform 라이선스를 오픈소스(MPL 2.0)에서 BSL로 바꾸면서 커뮤니티가 마지막 MPL 버전을 포크했고, 그게 OpenTofu가 됐습니다. 지금은 Linux Foundation 산하이고 2025년 4월 CNCF에 합류했습니다. HashiCorp는 2024년 12월 IBM에 64억 달러(약 9조 원)로 인수돼 Terraform은 이제 IBM 제품이고요.

네 갈래를 어떻게 고르나

도구 성격 고르는 이유 유의점
Terraform 선언형 IaC, 최대 생태계 프로바이더·모듈이 가장 많다 BSL 라이선스, IBM 제품
OpenTofu Terraform 포크, MPL 2.0 라이선스 자유, 설정 호환 채택률은 아직 낮음
Pulumi 범용 언어로 작성 개발자 경험, 로직 표현력 팀이 언어를 통일해야 함
Crossplane Kubernetes 네이티브 제어 평면 셀프서비스·지속 조정 K8s 운영 역량이 전제

OpenTofu로 넘어가는 비용은 생각보다 작습니다 — terraform 바이너리를 tofu 로 바꾸는 정도이고, 첫 apply 때 상태 파일의 버전 표시만 바뀝니다.

대신 얻는 게 하나 있는데 상태 파일 암호화가 v1.7부터 들어갔습니다. AES-GCM으로 클라이언트에서 암호화하고 키는 AWS KMS·GCP KMS·Azure Key Vault·OpenBao·패스프레이즈 중에 고릅니다. 상태 파일에는 비밀번호·토큰이 평문으로 남는 일이 흔해서, 상태 파일이 여러 벌 흩어지는 멀티클라우드에서는 이게 꽤 큽니다.

CNCF의 Crossplane 졸업 발표 CNCF의 Crossplane 졸업 발표 — 출처: CNCF

Crossplane은 결이 다릅니다. IaC 도구가 아니라 제어 평면을 만드는 도구예요. Kubernetes가 파드를 계속 지켜보며 원하는 상태로 되돌리듯, 클라우드 자원에 같은 방식을 적용합니다. 한 번 만들고 끝이 아니라 계속 조정한다는 게 차이고, 그래서 누가 콘솔에서 손으로 바꿔도 원상복구됩니다.

2025년 10월 CNCF를 졸업했고, 발표 기준 기여자 3,000명·450개 조직으로 CNCF 프로젝트 중 상위 10%입니다. 릴리스는 100회를 넘겼고 v2.0은 애플리케이션 제어 평면까지 범위를 넓혔습니다. Nike·Autodesk·NASA Science Cloud·IBM·Akamai가 사내 플랫폼에 쓰고 있고요.

넷은 배타적이지 않습니다. 실제로는 OpenTofu로 기반을 선언하고, Crossplane으로 K8s 쪽 자원을 다루고, 승인·컴플라이언스만 한 곳으로 모으는 조합을 흔히 씁니다.

2층 런타임 — 어디서 도는가

이 층은 논쟁이 거의 끝났습니다. Kubernetes가 사실상 표준이고, 세 하이퍼스케일러가 전부 관리형으로 제공합니다.

Kubernetes 공식 로고 Kubernetes 공식 로고 — 출처: Kubernetes

다만 “Kubernetes를 쓰면 이식성이 생긴다”는 건 절반만 맞습니다. 파드 명세는 어디서나 같지만 그 아래는 다릅니다. 로드밸런서 어노테이션, 스토리지 클래스, 네트워크 플러그인, IAM 연동 방식이 클라우드마다 갈립니다. 매니페스트를 그대로 옮기면 대개 안 뜹니다.

그래서 이 층의 표준화는 차이를 없애는 게 아니라 차이를 한곳에 가두는 것입니다. 클라우드별 차이를 값(values)으로 뽑아 한 파일에 모으고, 애플리케이션 매니페스트는 그 값을 참조만 하게 만듭니다. 개발자는 차이를 보지 않고, 플랫폼 팀은 차이를 한 파일에서 관리합니다.

3층 신원 — 누구인지 어떻게 증명하나

멀티클라우드에서 가장 조용히 새는 곳입니다. AWS는 IAM 역할, GCP는 서비스 계정, Azure는 관리 ID로 워크로드를 식별하는데 서로 말이 안 통합니다. 그래서 실무에서는 장기 액세스 키를 발급해 반대편 클라우드 시크릿에 넣어 두는 임시방편이 자주 쓰이고, 그 키는 대개 만료되지 않은 채 잊힙니다.

SPIFFE가 이 문제의 표준이고 SPIRE가 그 구현입니다. 둘 다 CNCF 졸업 프로젝트고요. 워크로드마다 암호학적으로 검증 가능한 신원(SVID)을 발급하는데, 짧은 수명의 X.509 인증서나 JWT 형태이고 자동으로 갱신되며 디스크에 저장되지 않습니다. 훔칠 장기 키 자체가 없어지는 구조입니다.

멀티클라우드에서 중요한 건 SPIRE 페더레이션입니다. 클라우드마다 신뢰 도메인을 따로 두고 신뢰 번들(공개키 묶음)만 교환하면, 관리 체계는 분리한 채로 상대 쪽이 발급한 신원을 검증할 수 있습니다. 하나로 합치지 않고 서로 인정하게 만드는 방식이죠. Istio가 서비스 신원에 SPIFFE를 쓰고 AWS App Mesh도 SPIRE 연동을 제공합니다.

4층 정책 — 무엇이 허용되나

클라우드가 셋이면 가드레일도 셋입니다. AWS SCP, Azure Policy, GCP 조직 정책이 각각 다른 문법으로 각각의 콘솔에 삽니다. “퍼블릭 버킷 금지”를 세 번 쓰고 세 번 관리하다 보면 하나는 반드시 어긋납니다.

정책을 코드로 옮기면 이게 정리됩니다. Kubernetes 층에서는 Kyverno(CNCF 인큐베이팅)와 OPA/Gatekeeper(CNCF 졸업)가 양대 선택지입니다. Kyverno는 정책을 Kubernetes 매니페스트로 쓰기 때문에 새 언어를 배울 필요가 없고, OPA는 Rego라는 전용 언어를 쓰는 대신 Kubernetes 밖(API 게이트웨이, CI 파이프라인)까지 같은 엔진으로 덮을 수 있습니다.

핵심은 어느 쪽을 고르냐가 아니라 정책이 Git에 살고 배포 전에 검사된다는 점입니다. 콘솔에 사람이 설정해 둔 규칙은 리뷰도 이력도 없지만, 코드로 옮기면 둘 다 생깁니다.

5층 관측 — 무슨 일이 벌어지는지 보이나

계측을 클라우드마다 다르게 하면 클라우드를 옮길 때 애플리케이션 코드를 다시 씁니다. 이 층의 표준은 OpenTelemetry로 정리됐습니다.

CNCF의 OpenTelemetry 졸업 발표 CNCF의 OpenTelemetry 졸업 발표 — 출처: CNCF

2026년 5월 21일 CNCF를 졸업했고, 발표문은 이걸 “사실상의 관측 표준”이라고 못 박습니다. 기여자 12,000명·2,800개 기업으로 CNCF에서도 손꼽히는 규모고요. 발표문이 밝힌 효용이 정확히 멀티클라우드가 필요로 하는 것입니다 — 코드를 다시 쓰지 않고 분석 도구를 바꿀 수 있다는 것.

계측은 OpenTelemetry로 한 번만 하고, 백엔드는 클라우드마다 다른 걸 써도 되고 나중에 갈아타도 됩니다. 최근에는 GenAI 관련 표준 규약도 들어가서 LLM 호출의 토큰·지연·비용을 같은 방식으로 계측할 수 있게 됐습니다.

표준화하면 안 되는 것

표준화는 공짜가 아닙니다. 층을 하나 더 얹는다는 건 배울 것과 운영할 것이 하나 더 생긴다는 뜻이고, 아래 것들은 표준화 대상이 아니라 그냥 두는 게 맞습니다.

대상 왜 두는가
각 클라우드의 강점 서비스 BigQuery·Bedrock 같은 걸 안 쓸 거면 그 클라우드를 둘 이유가 없다
데이터가 무거운 워크로드 옮기는 비용이 표준화 이득을 넘긴다. 데이터는 중력이 있다
팀이 하나뿐인 소규모 조직 층을 관리할 사람이 없으면 층이 부채가 된다
이미 안정적으로 도는 레거시 건드릴 이유가 없으면 건드리지 않는다

특히 조직 규모를 넘어서는 표준화는 자해입니다. Flexera 조사에서도 CCoE를 둔 조직이 71%, FinOps 전담팀이 63%로 나오는데, 이건 뒤집어 말하면 표준화에는 그걸 굴릴 사람이 붙는다는 뜻입니다. 도구만 깔고 사람을 안 붙이면 얼마 못 가 아무도 안 쓰는 층 하나가 남습니다.

2027년 1월 12일 — 규제가 계산을 바꾼다

지금까지 멀티클라우드를 실질적으로 막아 온 건 기술이 아니라 이탈 비용이었습니다. 데이터를 내보낼 때 물리는 이그레스 요금이 대표적이죠. 대략 GB당 0.05~0.09달러라 100TB만 옮겨도 수천 달러가 나갑니다. 쌓을수록 나가기 어려워지는 구조라, 요금 자체가 잠금장치 역할을 해 왔습니다.

멀티클라우드 표준화 지형이 굳어진 3년 연표 멀티클라우드 표준화 지형이 굳어진 3년 연표 — 출처: 공식 발표 기반 자가 렌더

이 계산이 바뀌고 있습니다. AWS·Azure·Google은 2024년에 완전 이탈 시 이그레스 요금을 면제했고, EU 데이터법(Data Act)은 2027년 1월 12일부터 EU 고객 대상 전환 수수료를 전면 금지합니다. 그때까지는 원가 보전 수준만 허용되고요.

한국 기업에 바로 적용되는 규제는 아니지만, 글로벌 사업자가 EU 기준으로 요금 체계를 다시 짜면 그 영향은 대개 밖으로 번집니다. 이탈 비용이 낮아진다는 건 클라우드를 바꿀 수 있다는 협상 카드가 실제로 생긴다는 뜻이고, 그 카드를 쓰려면 앞의 다섯 층이 미리 서 있어야 합니다. 종속은 계약이 아니라 아키텍처로 생기니까요.

어디서부터 손대나

다섯 층을 한 번에 세우려는 시도는 거의 실패합니다. 순서가 있습니다.

단계 하는 일 넘어갈 신호
0 지금 뭐가 어디서 도는지 목록화 목록이 실제와 맞는다
1 관측 통일 (OpenTelemetry) 클라우드 구분 없이 한 화면에서 추적된다
2 프로비저닝 통일 (IaC) 콘솔에서 손으로 만드는 자원이 없다
3 정책을 코드로 위반이 배포 전에 걸린다
4 신원 통일 (SPIFFE) 장기 액세스 키가 남아 있지 않다
5 제어 평면 (Crossplane) 개발자가 셀프서비스로 자원을 받는다

관측을 먼저 두는 데는 이유가 있습니다. 0단계 목록은 거의 항상 틀리고, 틀렸다는 걸 알려주는 게 관측입니다. 아무도 모르는 계정에서 도는 워크로드는 문서가 아니라 텔레메트리로 발견됩니다. 그리고 관측은 다른 층과 달리 기존 것을 바꾸지 않고 얹을 수 있어서 되돌리기도 쉽습니다.

반대로 5단계 제어 평면은 마지막입니다. 앞 네 층이 없는 상태에서 셀프서비스를 열면, 통제되지 않은 자원 생성을 자동화하는 셈이 됩니다.

정리

멀티클라우드는 대개 선택의 결과가 아니라 시간이 쌓인 결과입니다. Flexera 조사가 짚은 대로 설계가 아니라 우연으로 도달한 상태고, 그래서 “왜 이렇게 됐나”를 따지는 것보다 “이 상태로 어떻게 굴릴까”가 실질적인 질문입니다.

답은 클라우드를 통일하는 게 아니라 층을 나누는 것입니다. 아래는 다른 채로 두고 위에 공통 층을 얹어, 팀이 그 층하고만 대화하게 만드는 것. 다섯 층 모두 특정 클라우드가 소유하지 않은 오픈소스로 이미 표준이 정리됐고, 마지막 한 축이던 OpenTelemetry가 올해 5월 졸업하면서 지형이 굳었습니다.

그리고 2027년 1월이면 나가는 비용이 규제로 깎입니다. 그때 실제로 움직일 수 있는 조직과 못 움직이는 조직을 가르는 건 계약서가 아니라, 그전에 층을 세워 뒀는지입니다.

참고 출처