Language
검색

업계별 클라우드 지도: 패션은 AWS로 가고, 유통 대기업은 Azure로 도망친다

디올 매장 외벽과 아마존 프라임 배송 차량의 로고를 나란히 붙인 사진

·

조회수 29
업계마다 클라우드가 갈리는 진짜 기준은 무엇인가?
기술 스펙이 아니라 다섯 가지 힘이다. 경쟁 관계(누구에게 돈과 데이터를 주는가), 이미 깔린 계약(윈도·오피스·ERP), 데이터 중력과 AI 스택, 규제와 주권, 그리고 지연·전송비 같은 물리 조건이다. 패션 이커머스가 AWS로 몰리는 것과 월마트가 애저·구글로 가는 것은 같은 논리의 앞뒷면이다.

“패션은 AWS를 쓰고 테크는 애저를 쓴다”는 말은 절반만 맞다. 절반이 맞는 부분이 흥미롭고, 틀린 절반은 더 흥미롭다. 업종별로 클라우드 선택이 실제로 갈리는 것은 사실이지만, 그 원인은 업종 자체가 아니라 업종에 걸린 제약이다. 같은 옷을 파는 회사라도 잘란도와 월마트는 정반대의 선택을 했고, 이유는 옷이 아니라 아마존이다.

힘 ①. 경쟁 관계 — 누구에게 돈과 데이터를 줄 것인가

가장 노골적이고, 가장 강력한 힘이다.

미국 대형 유통은 AWS를 조직적으로 피한다. 월마트는 2018년 마이크로소프트와 5년 클라우드 계약을 맺었고 구글 클라우드도 함께 쓴다. 크로거는 구글과 마이크로소프트로 나눠 담았고, 타깃·이베이·베스트바이·L.L.빈은 구글로 갔다. 갭이 애저를 고른 2019년 보도에서 업계 관계자가 남긴 요약이 이 힘의 정의에 가깝다 — “다른 사업 영역에서 우리의 경쟁자가 되지 않을 파트너를 원한다.”

계산은 단순하다. AWS에 쓰는 클라우드 비용은 곧 아마존 리테일 부문의 실탄이 되고, 인프라 사용 패턴은 그 자체로 사업 정보다. 성수기 트래픽 곡선, 신규 리전 증설, 데이터 파이프라인의 형태는 경쟁사가 보면 안 되는 종류의 지문이다.

그런데 패션 브랜드는 반대로 움직인다. 잘란도는 2020년 AWS를 선호 클라우드 제공사로 선택했다고 공식 발표했고, 머신러닝 워크로드를 AWS에 올려 개인화·가격·공급망을 돌린다. SAP 시스템까지 온프레미스에서 AWS로 옮겼다. 나이키도 오랜 AWS 고객이다.

차이는 경쟁의 각도다. 월마트와 아마존은 같은 장바구니를 놓고 정면으로 부딪히지만, 패션 브랜드에게 아마존은 채널 중 하나이거나 아예 다른 판이다. 위협이 정면이 아니면, 남는 것은 기술 성숙도와 인력 시장이고 그 싸움에서는 AWS가 유리하다. 요컨대 “패션은 AWS”는 결과이고, 원인은 “아마존과 정면충돌하지 않는 업종은 AWS를 고를 자유가 있다”는 것이다.

힘 ②. 이미 깔린 계약 — 애저의 진짜 무기는 기술이 아니다

“테크 기업은 애저를 쓴다”는 통념은 방향이 어긋나 있다. 실리콘밸리형 테크 기업과 스타트업은 오히려 AWS와 구글 클라우드 쪽이 두텁다. 애저가 강한 곳은 이미 마이크로소프트를 쓰고 있던 전통 대기업이다.

액티브 디렉터리로 계정을 관리하고, 오피스 365로 일하고, 윈도 서버 위에 사내 시스템이 올라가 있고, 엔터프라이즈 계약(EA)으로 라이선스를 사는 회사에게 애저는 새 벤더가 아니라 기존 계약의 확장 항목이다. 구매 절차가 짧고, 아이덴티티가 이미 연결돼 있으며, 협상 테이블에 이미 앉아 있는 영업 조직이 있다.

숫자로 드러난 두 사례가 이 구조를 잘 보여준다.

  • 코카콜라는 2024년 마이크로소프트와 5년 11억 달러 규모의 전략적 파트너십을 맺고 모든 애플리케이션을 애저로 옮기기로 했다. 애저 오픈AI 서비스와 코파일럿이 계약에 함께 묶였다.
  • 런던증권거래소그룹(LSEG)은 2022년 마이크로소프트와 10년 계약을 맺으며 최소 28억 달러 규모의 클라우드 지출을 약정했고, 마이크로소프트는 LSEG 지분 약 4%를 사들였다. 클라우드 계약이 자본 관계로까지 이어진 사례다.

여기서 읽어야 할 것은 “누가 더 좋은 가상머신을 파는가”가 아니다. 번들과 관계가 인프라 선택을 결정한다는 점이다. AI 시대에 이 구조는 더 강해졌다. 코파일럿·오픈AI 접근권 같은 것이 인프라 계약에 얹히면, 순수한 인프라 성능 비교는 의사결정에서 뒷줄로 밀린다.

힘 ③. 데이터 중력과 AI 스택 — 구글이 파고드는 틈

구글 클라우드는 3위지만 특정 업종에서는 존재감이 다르다. 분석과 AI에서 출발해 인프라로 내려가는 경로를 타기 때문이다.

LVMH가 대표적이다. 75개 메종을 거느린 이 럭셔리 그룹은 구글 클라우드와 데이터·AI 플랫폼을 함께 구축해 브랜드별로 흩어져 있던 데이터를 한 층에 모으고, 예측·생성·에이전트형 도구를 그 위에 올리고 있다. 럭셔리 산업에서 데이터 통합이 어려운 이유는 기술이 아니라 조직이다. 각 메종이 독립적으로 운영되고 브랜드 자산을 공유하기를 꺼린다. 이 문제는 “가상머신이 싸다”로 풀리지 않는다. 데이터 웨어하우스와 거버넌스가 먼저 팔리고 컴퓨트가 따라 들어간다.

미디어에서는 스포티파이가 2016년 구글 클라우드로 옮겨간 이래 대표 레퍼런스로 남아 있고, 유통에서는 앞서 본 반(反)아마존 정서가 구글 쪽으로 흘렀다. 즉 구글의 업종 지도는 “분석이 먼저 급한 곳”과 “아마존을 피해야 하는 곳”이 겹치는 자리에 그려진다.

힘 ④. 규제와 주권 — 선택지 자체를 지우는 힘

앞의 세 힘이 선호라면, 이것은 제약이다.

금융. 미국에서 캐피털원은 데이터센터를 전부 닫고 AWS로 완전히 넘어간, 대형 은행 중 거의 유일한 사례로 꼽힌다. 반면 JP모건과 웰스파고는 멀티클라우드를 택했다. 규모가 클수록 한 제공사에 집중된 리스크 자체가 감독 대상이 되고, 40년 된 메인프레임 코어를 그대로 들어 옮길 수도 없기 때문이다. 은행의 하이브리드는 취향이 아니라 감독당국·레거시·협상력이 만든 균형점이다.

공공·국방. 미 국방부의 JWCC는 2022년 12월 AWS·마이크로소프트·구글·오라클 네 곳에 최대 90억 달러 규모로 동시에 열어둔 계약이다. 2026년 6월 해군은 네 제공사 모두에게 과제를 발주했고, 여기에는 최고 등급(IL6) 처리와 에어갭 엣지 옵션이 포함된다. 여기서 멀티클라우드는 효율이 아니라 단일 실패점과 벤더 종속을 조달 단계에서 금지한 결과다.

주권. 유럽은 2026년 들어 판이 바뀌었다. AWS는 2026년 1월 15일 유럽 주권 클라우드를 정식 출시했다. 기존 리전과 물리·논리적으로 분리되고 EU 거주자만 운영하며, 독일에만 2040년까지 78억 유로를 투입한다고 밝혔다. 마이크로소프트는 주권 퍼블릭 클라우드를 2026년 중 유럽 전 리전에 정식 제공할 계획이고, 구글은 T-시스템즈(독일)·S3NS(프랑스)·민사이트(스페인)·텔레콤 이탈리아와 손잡는 파트너 방식으로 간다. EU는 2025년 10월 클라우드 주권 프레임워크로 요건 여덟 가지를 못박았다.

다만 냉정하게 볼 부분이 있다. 미국 클라우드법(CLOUD Act)의 역외 효력을 무력화하는 법은 2026년 현재도 없다. 유럽에 데이터를 두고 유럽인이 운영해도 모회사가 미국 기업이라는 사실은 남는다. 유럽 공공·의료 조직 일부가 여전히 자국 사업자나 온프레미스를 고집하는 이유다.

헬스케어. 세 클라우드 모두 BAA(HIPAA 위탁계약)를 지원하므로 규제가 벤더를 고르지는 않는다. 대신 갈리는 것은 워크로드의 성격이다. 대규모 유전체·시뮬레이션은 AWS(모더나가 팬데믹 기간 급격히 확장한 것이 대표적)로, 연구·연합학습형 데이터 플랫폼은 구글(메이오클리닉)로, 병원 행정과 기존 마이크로소프트 자산이 큰 곳은 애저로 기운다.

힘 ⑤. 물리 — 지연, 현장, 전송비

마지막 힘은 협상으로 바꿀 수 없다.

제조. 폭스바겐의 인더스트리얼 클라우드는 AWS 위에 있다. 전 세계 공장의 기계·설비 데이터를 한 플랫폼에 모으는 구조로 출발했고, 2026년 기준 3개 대륙 43개 공장을 연결한 디지털 생산 플랫폼과 1,200개의 AI 시스템으로 확장되며 계약이 5년 연장됐다. 공장 데이터는 양이 크고, 대부분은 밀리초 단위로 현장에서 판단해야 한다. 그래서 제조업의 정답은 늘 엣지 + 중앙 클라우드이고, 이 조합에서 클라우드는 “공장을 대체하는 곳”이 아니라 “공장이 만든 데이터를 모아 학습시키는 곳”이다.

미디어·게임. 넷플릭스는 AWS의 대표 고객이면서도 실제 영상 전송은 자체 CDN(오픈 커넥트)으로 처리한다. 스트리밍 비용의 급소가 컴퓨트가 아니라 전송량이기 때문이다. 게임도 같다. 엑스박스 클라우드 게이밍은 애저에서, 아마존 루나는 AWS에서 돌아간다. 이때 클라우드 선택은 인프라 결정이 아니라 모회사 결정이다.

한 장으로 본 업계별 지도

업종 우세한 선택 지배적 이유
패션·D2C 커머스 AWS ML 개인화·트래픽 급변, 아마존과 정면 경쟁 아님
대형 유통 애저·구글 경쟁사에 비용과 데이터를 주지 않는다
럭셔리·소비재 구글·애저 흩어진 브랜드 데이터 통합, 기존 MS 계약
금융 멀티·하이브리드 감독 규제, 메인프레임, 집중 리스크
제조·자동차 AWS + 엣지 공장 IoT 데이터량과 현장 지연
헬스케어·제약 3사 혼재 워크로드 성격(유전체/연구/행정)이 가른다
미디어·게임 AWS + 자체 CDN 전송비, 스파이크, 모회사 관계
공공·국방 4사 분할 조달 규정과 인증, 주권 요구

하이브리드는 하나의 전략이 아니다

“하이브리드로 쓴다”는 말에는 성격이 전혀 다른 세 가지가 섞여 있다.

첫째, 워크로드 분할형. 코어는 온프레미스, 프런트와 분석은 퍼블릭에 두는 방식이다. 은행·제조가 대부분 여기 속하고, 가장 방어하기 쉬운 형태다.

둘째, 협상 카드형. 두 번째 클라우드를 실제로 쓰기보다 가격 협상용으로 남겨두는 구성이다. 갱신 때 실질적인 할인을 만들어내지만, 팀 하나가 두 벌의 운영 지식을 유지해야 한다는 비용이 조용히 쌓인다.

셋째, 어쩌다 멀티클라우드. 인수합병과 사업부별 자율 구매의 결과다. 전략처럼 보이지만 사실은 청구서 여러 장이다. 대부분의 “멀티클라우드 기업”이 실제로는 이쪽이라는 점을 인정하는 편이 낫다.

멀티클라우드의 실제 비용은 대개 이그레스(외부 전송) 요금과 인력에서 나온다. 다만 이 마찰을 줄이려는 움직임도 시작됐다. AWS와 구글 클라우드가 멀티클라우드 네트워킹 제품을 함께 내놨고, 2026년에는 애저까지 포함하는 방향으로 이야기가 나온다. 벤더가 마찰을 줄이는 순간 “하이브리드가 어려워서 못 한다”는 변명은 줄어들고, 대신 왜 나눠야 하는지를 설명해야 하는 쪽으로 논점이 옮겨간다.

되돌아오는 흐름도 함께 봐야 한다

클라우드가 늘 정답이었다면 리패트리에이션이라는 단어는 없었을 것이다. 37시그널즈는 2023년 퍼블릭 클라우드를 떠나 자체 하드웨어로 돌아간 과정을 공개했고, 연 130만~150만 달러, 5년 700만 달러 수준의 절감을 주장한다. 바클레이스 CIO 설문에서는 응답자의 86%가 일부 워크로드를 퍼블릭에서 프라이빗·온프레미스로 되돌릴 계획이라고 답했다.

두 숫자 모두 조심해서 읽어야 한다. 37시그널즈는 트래픽이 예측 가능하고 팀이 인프라를 직접 운영할 능력이 있는 회사이고, 설문의 “일부 워크로드”는 전면 철수가 아니다. 되돌아오는 것은 대체로 예측 가능하고 상시 최대 부하로 도는 워크로드다. 반대로 계절성이 크고 실험이 잦은 워크로드는 여전히 퍼블릭이 유리하다. 업종별로 보면 리패트리에이션 논의가 활발한 곳은 트래픽이 평탄한 SaaS·미디어 백엔드이고, 유통·이커머스처럼 피크가 열 배씩 튀는 곳에서는 거의 나오지 않는다.

한국의 지도는 조금 다르다

국내에서는 두 가지가 추가로 작동한다.

첫째, 공공은 사실상 국내 사업자의 영역이다. CSAP(클라우드 보안인증) 요건 때문에 네이버클라우드·NHN클라우드·KT클라우드가 공공 사업을 나눠 갖는 구조가 굳어졌다. 이 체계는 개편 중이다. 2026년 중 가이드라인 개정을 마치고 2027년 7월 본격 시행하는 일정이 제시돼 있어, 그 이후 공공 시장의 문턱이 어떻게 바뀌는지가 관전 포인트다.

둘째, 금융의 망분리 규제가 풀리는 중이다. 금융당국은 2026년 1월 금융회사가 내부 업무망에서 SaaS를 이용할 수 있도록 망분리 예외를 명시하는 전자금융감독규정 시행세칙 개정안을 사전예고했다. 지금까지 국내 금융권이 하이브리드를 택한 이유는 아키텍처 취향이 아니라 망분리라는 단일 규정이었다. 이 조건이 완화되면 국내 금융의 클라우드 지도는 몇 년에 걸쳐 다시 그려질 가능성이 있다.

민간 시장은 여전히 AWS가 크게 앞선다. 다소 오래된 자료이지만 2023년 부가통신사업 실태조사에서 클라우드를 쓰는 국내 기업의 AWS 이용 비중이 60.2%, 네이버클라우드가 20.5%였다(복수응답 기준). 게임·커머스·스타트업의 AWS 쏠림과 대기업 그룹사의 자체 IT 계열사 구조가 겹친 결과다.

그래서, 무엇을 물어야 하나

업종 이름표를 보고 클라우드를 고르는 것은 순서가 틀렸다. 다섯 가지 힘 중 내 조직에 실제로 걸려 있는 것을 찾는 것이 먼저다.

  1. 우리 매출을 위협하는 회사가 그 클라우드의 주인인가? 그렇다면 기술 비교는 의미가 줄어든다.
  2. 이미 어떤 계약에 묶여 있나? 아이덴티티·오피스·ERP·데이터베이스 라이선스는 이미 절반의 답이다.
  3. 가장 무거운 데이터가 지금 어디에 있나? 데이터는 옮기는 비용이 가장 비싸고, 컴퓨트는 데이터를 따라간다.
  4. 우리를 감독하는 규정이 선택지를 지우는가? 지운다면 남은 선택지 안에서만 비교하면 된다.
  5. 밀리초와 전송량 중 무엇이 급소인가? 전자는 엣지, 후자는 CDN 설계의 문제이지 클라우드 브랜드의 문제가 아니다.

이 다섯 질문에 답하고 나면 대개 선택지는 하나나 둘로 좁혀진다. 그때부터가 실제 비교의 시작이다.

⚠️ 이 글의 사례와 수치는 각 기업·기관의 공개 발표와 2026년 9월 기준 보도를 정리한 것이다. 클라우드 점유율은 집계 기관마다 기준이 달라 편차가 크고(2026년 2분기 기준 대략 AWS 28%·애저 20%·구글 15% 선), 계약 규모와 사용 범위는 공개되지 않은 부분이 많다. 리패트리에이션 관련 수치는 자가 보고와 설문에 기반하므로 일반화에 주의가 필요하다. 특정 기업이 한 클라우드를 쓴다는 사실이 다른 클라우드를 전혀 쓰지 않는다는 뜻은 아니다.

자주 묻는 질문

패션 브랜드는 정말 AWS를 많이 쓰나요?

패션 이커머스 쪽에서는 AWS 사례가 눈에 띄게 많습니다. 잘란도는 2020년 AWS를 선호 클라우드 제공사로 발표하고 머신러닝 워크로드와 SAP까지 옮겼고, 나이키도 오랜 AWS 고객으로 알려져 있습니다. 다만 이것을 “패션이라서”로 설명하기는 어렵습니다. 아마존과 정면으로 경쟁하지 않는 업종은 AWS를 고를 자유가 있다는 점, 그리고 개인화·수요예측 같은 ML 서비스가 일찍부터 갖춰져 있었다는 점이 실제 이유에 가깝습니다.

테크 기업은 애저를 쓴다는 말은 맞나요?

방향이 조금 어긋난 통념입니다. 스타트업과 인터넷 기업은 오히려 AWS와 구글 클라우드 비중이 높습니다. 애저가 강한 쪽은 액티브 디렉터리·오피스 365·윈도 서버를 이미 쓰고 있던 전통 대기업과 금융·제조·공공입니다. 새 벤더를 들이는 것이 아니라 기존 계약을 확장하는 형태라 구매와 인증 절차가 짧기 때문입니다.

멀티클라우드를 쓰면 벤더 종속을 피할 수 있나요?

부분적으로만 그렇습니다. 실제로 두 클라우드에서 같은 서비스를 동시에 돌릴 수 있는 조직은 드물고, 대부분은 워크로드를 나눠 담거나 협상용으로 두 번째 계약을 유지합니다. 종속을 줄이는 대신 이그레스 요금, 두 벌의 운영 지식, 보안 정책 이중화라는 비용이 생깁니다. 가장 현실적인 접근은 전체를 이식 가능하게 만드는 것이 아니라, 옮길 가능성이 실제로 있는 부분만 표준 기술로 짜두는 것입니다.

국내 금융권이 하이브리드를 쓰는 이유는 무엇인가요?

규제가 가장 큰 이유였습니다. 망분리 규정 때문에 내부망 업무를 퍼블릭 클라우드나 SaaS로 옮기기 어려웠고, 그래서 채널·분석은 클라우드, 코어는 내부라는 구성이 굳어졌습니다. 2026년 1월 금융당국이 내부망 SaaS 이용을 망분리 예외로 명시하는 시행세칙 개정안을 사전예고하면서 이 전제가 흔들리기 시작했습니다. 다만 규정이 풀린다고 코어 시스템이 곧바로 이동하지는 않습니다.

유럽 주권 클라우드는 실제로 안전한가요?

데이터의 물리적 위치, 운영 인력의 국적, 관리 체계 측면에서는 분명한 진전입니다. AWS는 2026년 1월 유럽 주권 클라우드를 정식 출시했고 마이크로소프트와 구글도 각자의 방식으로 대응하고 있습니다. 다만 미국 클라우드법의 역외 효력을 없애는 법적 장치는 아직 없습니다. 따라서 “미국 정부의 접근 가능성”을 위험 목록에서 완전히 지워야 하는 조직이라면 주권 클라우드만으로는 충분하지 않을 수 있습니다.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *