AI도 데이터도 결국 어딘가에서 돌아가야 합니다. 그리고 그 ‘어딘가’가 점점 클라우드로 수렴하고 있습니다. 이 글에서는 클라우드의 기본 정의와 특성, 종류, 그리고 실제 어떻게 활용되는지를 차근차근 정리해보겠습니다.
요즘 “우리도 클라우드로 가야 한다”는 말은 회의실에서 너무 익숙합니다. 그런데 막상 “클라우드가 정확히 뭐야?”라는 질문에 한 문장으로 답하라고 하면 의외로 막힙니다. AWS, Azure, GCP 같은 이름은 들어봤지만, 그게 IaaS인지 PaaS인지, 퍼블릭인지 하이브리드인지로 가면 점점 흐릿해지죠.
1편인 이 글에서는 가장 기초적인 네 가지 질문을 다룹니다. 클라우드란 정확히 무엇인지, 왜 쓰고 어떤 한계가 있는지, 어떤 종류로 나뉘는지, 실제로 어떻게 활용되고 있는지. 마이그레이션과 멀티클라우드처럼 실제 도입 단계의 이야기는 다음 편에서 이어집니다.
1. 클라우드란 무엇인가
클라우드(cloud)는 내 컴퓨터나 우리 회사 서버가 아니라, 인터넷 너머에 있는 누군가의 컴퓨터를 빌려 쓰는 것입니다. 그 ‘누군가’는 보통 AWS, Azure, GCP 같은 거대한 데이터센터를 운영하는 회사들이고, 우리는 필요한 만큼의 서버·저장 공간·소프트웨어를 인터넷으로 빌려서 씁니다.
과거에는 회사가 서비스를 운영하려면
- 직접 서버실을 만들고
- 서버 장비를 사고
- 항온항습기와 비상발전기를 갖추고
- 인력을 두고 24시간 관리해야 했습니다.
이런 방식을 온프레미스(on-premise)라고 합니다. 클라우드는 이 모든 일을 외부 사업자가 대신해주고, 우리는 ‘필요한 만큼만 꺼내 쓰고, 쓴 만큼만 비용을 내는’ 모델로 바꿉니다.
쉽게 비유하면 이렇습니다.
- 온프레미스는 발전소를 직접 짓는 것과 비슷합니다. 안정적이고 통제권이 완전히 내 손에 있지만, 짓는 데 돈이 많이 들고 한 번 지으면 용량을 바꾸기 어렵습니다.
- 클라우드는 한국전력에서 전기를 끌어 쓰는 것에 가깝습니다. 발전소가 어디에 있는지 신경 쓸 필요 없고, 쓴 만큼만 요금을 내며, 갑자기 전기를 더 써야 하면 더 쓰면 됩니다.
(1) 클라우드의 5가지 본질적 특성
이 정도로 두면 정의가 다소 막연합니다. 다행히 미국 표준기술연구소가 클라우드 컴퓨팅에 대한 공식 정의(NIST SP 800-145)를 정리해 두었고, 업계는 사실상 이 정의를 표준으로 받아들이고 있습니다. 핵심은 다섯 가지 본질적 특성입니다.
| 특성 | 의미 | 일상 비유 |
|---|---|---|
| 온디맨드 셀프서비스 (On-demand self-service) | 사람의 개입 없이, 사용자가 직접 필요할 때 자원을 만들어 쓸 수 있어야 함 | 자판기에서 음료를 뽑듯, 콘솔 화면에서 서버를 클릭 몇 번으로 띄움 |
| 광범위한 네트워크 접근 (Broad network access) | PC·노트북·모바일 등 어떤 기기에서도 인터넷으로 접근 가능해야 함 | 넷플릭스를 TV에서도, 폰에서도, 노트북에서도 같은 계정으로 보는 것 |
| 리소스 풀링 (Resource pooling) | 거대한 자원 풀을 여러 고객이 나눠 쓰되, 서로의 사용은 보이지 않아야 함 | 호텔 객실처럼 같은 건물을 여러 손님이 나눠 쓰지만 서로의 방은 볼 수 없음 |
| 빠른 탄력성 (Rapid elasticity) | 수요에 따라 자원을 즉시 늘리거나 줄일 수 있어야 함 | 트래픽이 몰리는 이벤트 당일에만 서버 10대를 더 붙였다가 다음 날 반납 |
| 측정된 서비스 (Measured service) | 사용량이 자동으로 측정되어, 쓴 만큼만 청구할 수 있어야 함 | 전기·수도 요금처럼 미터기를 보고 과금 |
이 다섯 가지를 모두 충족할 때 비로소 ‘진짜 클라우드’라고 부를 수 있습니다. 단순히 외부 데이터센터에 서버를 두는 것은 호스팅이지, 클라우드가 아닙니다. 정리하자면, 클라우드는 ‘쓴 만큼 내고, 필요할 때 즉시 늘리거나 줄일 수 있고, 어디서나 접근 가능한, 공유된 컴퓨팅 자원’입니다.
2. 클라우드의 장점과 단점
클라우드는 분명히 강력한 도구지만, 동시에 분명한 상충 관계가 있기에 이 양면을 같이 봐야 합니다.
| 축 | 장점 | 단점 |
|---|---|---|
| 비용 구조 | 자본지출(CapEx)이 운영비용(OpEx)으로 바뀌어 초기 투자 부담이 가벼움 | ‘쓴 만큼 낸다’는 말은 ‘많이 쓰면 많이 낸다’와 같음. 안정적인 워크로드는 자체 서버가 더 쌀 수 있음 |
| 확장성 | 트래픽이 몰리면 즉시 늘리고, 한가하면 줄일 수 있음 (블랙프라이데이·수능 성적 발표일에 강력) | 자유롭게 자원을 띄울 수 있다는 건 누구나 비용을 늘릴 수 있다는 뜻으로, ‘월말 청구서 쇼크’가 흔함 |
| 민첩성·접근성 | 클릭 몇 번이면 미국·일본·유럽 리전에 동시 배포 가능, 신규 서비스 출시 속도가 빨라짐 | 인터넷이 끊기면 모든 것이 멈춰 미션 크리티컬 시스템(장애가 발생하면 안 되는 시스템)에서는 결코 가벼운 리스크가 아님 |
| 운영 책임 | 하드웨어 고장, OS 패치, 데이터센터 운영을 사업자에게 위임할 수 있어 관리 부담 감소 | 책임 경계가 흐려지면 사고 시 회색지대가 생김 |
| 유연성·선택권 | 필요한 서비스를 자유롭게 조합할 수 있고, 사업자가 신기능을 빠르게 제공 | 한 클라우드의 고유 서비스에 깊이 들어갈수록 벤더 종속(lock-in)이 심해지며 이전 비용이 커짐 |
(1) 장점: 왜 다들 클라우드로 가는가
클라우드의 매력은 보통 다음 네 가지로 요약됩니다.
- 초기 투자 부담 감소: 서버를 사두는 자본지출(CapEx)이 매월 사용료를 내는 운영비용(OpEx)으로 바뀝니다. 회계 관점에서도, 자금 운용 관점에서도 부담이 가벼워집니다.
- 확장성과 탄력성: 트래픽이 갑자기 몰려도 자원을 즉시 늘릴 수 있고, 한가한 시간엔 줄일 수 있습니다. 블랙프라이데이나 수능 성적 발표일처럼 트래픽 피크가 명확한 서비스에서 특히 강력합니다.
- 민첩성과 글로벌 접근성: 새로운 아이디어를 검증할 때 서버를 며칠 만에 준비하던 시대는 지났습니다. 클릭 몇 번이면 미국·일본·유럽에 동시에 서비스를 배포할 수 있습니다.
- 관리 부담 감소: 하드웨어 고장, 운영체제 패치, 데이터센터 화재 대비 같은 업무를 클라우드 사업자에게 상당 부분 넘길 수 있습니다.
(2) 단점: 그러나 공짜는 아닙니다
같은 특성이 뒤집어지면 단점이 됩니다.
- 벤더 종속(lock-in): 한 클라우드의 고유 서비스에 깊이 들어갈수록 다른 곳으로 옮기기 어려워집니다. 데이터를 빼내는 비용(egress fee), 다시 짜야 할 코드, 재교육해야 할 인력까지 따지면 이전이 결코 가볍지 않습니다.
- 장기적으로 더 비쌀 수도 있음: ‘쓴 만큼만 낸다’는 말은 ‘많이 쓰면 많이 낸다’와 같은 말입니다. 워크로드가 안정적이고 트래픽 변동이 작은 시스템은 자체 서버가 더 쌀 수 있습니다.
- 보안·컴플라이언스 책임 분담의 모호함: 클라우드 사업자가 인프라 보안을 책임지더라도, 그 위에 올린 애플리케이션과 데이터의 보안은 여전히 고객 책임입니다. 이 경계를 잘못 이해하면 사고가 났을 때 “누가 책임지는가”가 흐려집니다.
- 네트워크 의존성: 인터넷이 끊기면 모든 게 멈춥니다. 미션 크리티컬 시스템에서는 결코 가벼운 리스크가 아닙니다.
- 비용 통제의 어려움: 누구나 자원을 띄울 수 있다는 자유는 누구나 비용을 늘릴 수 있다는 뜻이기도 합니다. ‘월말에 청구서 보고 놀라는’ 일이 흔합니다.
실제 한국 기업 설문에서도 퍼블릭 클라우드 도입을 망설이는 이유로 ‘외부 저장에 대한 보안 우려’(44%)와 ‘비용 부담’(38%)이 가장 많이 꼽힙니다. 보안과 비용은 도입을 가속하는 동시에 발목을 잡는 양면적인 이슈입니다.
(3) 한 가지 더: 진짜 가치는 비용 절감이 아닙니다
흥미로운 점은, 클라우드 도입 효과를 ‘비용 절감’으로만 좁히면 오히려 가치를 놓치기 쉽다는 점입니다. 단순 비용 비교만 따져보면 클라우드가 더 비싸다는 결론이 나오는 경우도 많습니다. 클라우드의 진짜 가치는 ‘이전에는 시도조차 못 했던 일을 시도할 수 있게 된다’는 데에 있습니다.
새로운 서비스를 일주일 안에 출시해보고 빠르게 접거나, 글로벌 시장에 동시에 뿌려보거나, 대규모 AI 모델을 짧은 기간 학습시키는 것 같은 일들 말이죠. 이 ‘민첩성과 혁신 역량’이라는 관점은 다음 편에서 도입 전략을 다룰 때 다시 돌아오게 됩니다.
핵심은, 클라우드는 만능 솔루션이 아니라 트레이드오프가 분명한 도구라는 점입니다. 비용·민첩성·통제권 사이에서 무엇을 우선할지를 정해야, 그 도구가 의미 있어집니다.
3. 클라우드의 종류
클라우드를 분류할 때는 보통 두 가지 축을 함께 봅니다. ‘무엇을 빌리는가’라는 서비스 모델과 ‘어디에 두는가’라는 배포 모델입니다.
(1) 서비스 모델: 무엇을 빌리는가
내가 빌리는 것이 인프라인지, 개발 환경인지, 완성된 앱인지에 따라 세 가지로 나뉩니다.
[클라우드 서비스 모델 3계층]
┌──────────────────────────────────┐
│ SaaS (소프트웨어) │ ← 완성된 앱을 그대로 사용
│ 예: Gmail, Notion, Slack │
├──────────────────────────────────┤
│ PaaS (플랫폼) │ ← 개발·실행 환경까지 빌림
│ 예: Heroku, App Engine │
├──────────────────────────────────┤
│ IaaS (인프라) │ ← 서버·스토리지·네트워크만 빌림
│ 예: AWS EC2, Azure VM │
└──────────────────────────────────┘
이 다이어그램의 핵심은 위로 올라갈수록 사용자가 직접 챙겨야 할 부분이 줄어든다는 점입니다. 각각을 좀 더 풀어보면 다음과 같습니다.
| 모델 | 무엇을 빌리는가 | 사용자가 할 일 | 대표 예시 |
|---|---|---|---|
| IaaS (Infrastructure as a Service) | 가상 서버, 스토리지, 네트워크 같은 ‘날것의 인프라’ | OS 설치, 런타임 구성, 앱 배포·운영까지 모두 사용자 몫 | AWS EC2, Azure Virtual Machines |
| PaaS (Platform as a Service) | OS·런타임·데이터베이스·배포 도구까지 갖춰진 개발·실행 환경 | 코드만 올리면 됨. 인프라·플랫폼 운영은 사업자가 처리 | Heroku, Google App Engine |
| SaaS (Software as a Service) | 이미 완성된 소프트웨어 그 자체 | 회원가입 후 그냥 사용. 설치·운영·업데이트 모두 사업자가 처리 | Gmail, Notion, Slack |
재료를 사서 직접 만드는 것이 IaaS, 밀키트를 사서 데우는 것이 PaaS, 이미 구워진 피자를 배달시키는 것이 SaaS에 해당합니다. 모두 결과적으로 피자를 먹지만, 어느 단계까지 직접 챙길지가 다릅니다.
흥미롭게도 한국에서는 전체 2,712개 클라우드 기업 중 SaaS 기업이 1,894개로 약 70%를 차지하고 있을 만큼 SaaS 중심으로 시장이 형성되어 있습니다. 진입장벽이 낮은 SaaS에 기업이 몰리는 반면, 자본 집약적인 IaaS·PaaS 영역은 글로벌 빅3와 국내 대형 사업자가 주도하는 구조입니다.
(2) 배포 모델: 어디에 두는가
같은 IaaS라도 그것을 ‘누가 쓰는 환경에’ 두느냐에 따라 또 나뉩니다. NIST는 네 가지 배포 모델을 정의합니다.
배포 모델 설명 주로 누가 쓰는가 퍼블릭 클라우드 AWS·Azure·GCP처럼 누구나 인터넷으로 접근해 쓰는 형태 스타트업, 일반 기업, 대부분의 SaaS 사용자 프라이빗 클라우드 한 조직만 전용으로 쓰는 클라우드 환경 금융, 공공, 의료 등 보안·규제가 엄격한 곳 커뮤니티 클라우드 비슷한 규제·미션을 공유하는 여러 조직이 함께 쓰는 형태 정부 부처 간 공동 인프라, 동일 산업 내 공동망 등 하이브리드 클라우드 퍼블릭과 프라이빗(또는 커뮤니티)을 함께 묶어 쓰는 형태 민감 데이터는 내부에, 일반 워크로드는 퍼블릭에 두려는 기업 멀티 클라우드 (NIST 정의 외) 두 개 이상의 퍼블릭 클라우드를 동시에 쓰는 형태 벤더 종속을 피하거나, 워크로드별로 최적 사업자를 고르려는 기업
여기서 멀티클라우드는 NIST의 원래 4분류에는 들어 있지 않지만, 실제 시장에서 점점 흔해지면서 별도 카테고리처럼 다뤄지고 있습니다. 한국에서도 퍼블릭 클라우드를 도입한 기업의 58%가 두 개 이상의 서비스를 함께 쓰는 멀티 클라우드 전략을 채택하고 있다는 조사 결과가 있습니다. 이 부분은 단독으로 다룰 만큼 묵직한 주제라 다음 편에서 본격적으로 풀어보겠습니다.
이 절의 핵심은, 클라우드를 본다는 건 결국 두 질문에 답하는 일이라는 점입니다. 얼마나 깊은 층까지 빌릴 것인가(서비스 모델), 그리고 그것을 누구의 환경에 둘 것인가(배포 모델). 이 두 축이 교차하는 지점에 우리가 쓰는 모든 클라우드의 모양이 결정됩니다.
4. 클라우드는 어떻게 활용되는가
추상적인 정의에서 한 발 내려와, 실제로 누가 어떤 클라우드를 어떻게 쓰고 있는지 살펴보겠습니다.
(1) 글로벌 빅3와 국내 사업자
전 세계 클라우드 인프라 시장은 사실상 세 회사가 장악하고 있습니다. 2025년 3분기 기준, AWS·Azure·Google Cloud 세 회사가 전 세계 클라우드 인프라 지출의 63%를 차지하며, 점유율은 각각 29%, 20%, 13%로 집계됩니다.
세 회사의 강점은 확연히 다릅니다.
| 사업자 | 핵심 강점 | 주요 사용 영역 |
|---|---|---|
| AWS (Amazon Web Services) | 가장 넓은 서비스 포트폴리오, 가장 큰 글로벌 인프라, 가장 풍부한 생태계 | 스타트업~대기업 전반의 ‘기본값’, 글로벌 확장 |
| Azure (Microsoft) | 마이크로소프트 제품군과의 통합, 하이브리드 클라우드 강점 | 윈도·오피스365·AD를 쓰는 대기업, 엔터프라이즈 환경 |
| GCP (Google Cloud Platform) | 데이터 분석·AI/ML, 컨테이너·쿠버네티스 친화 | 데이터·머신러닝 중심 서비스, 분석 워크로드 |
정리하자면, AWS는 ‘넓은 보편성’, Azure는 ‘기업 IT와의 결합’, GCP는 ‘데이터와 AI’에 강점이 있다고 이해할 수 있습니다.
국내 시장도 이 빅3가 주도하지만, 공공·금융처럼 데이터 주권이 중요한 영역에서는 네이버클라우드, KT클라우드, NHN클라우드 같은 국내 사업자도 의미 있는 입지를 갖고 있습니다. 특히 공공기관이 민간 클라우드를 도입할 때 거치는 클라우드 보안 인증(CSAP) 같은 제도적 환경 때문에, 글로벌 빅3가 다 가져가지 못하는 영역이 분명히 존재합니다.
(2) 대표적인 활용 시나리오
클라우드가 실제로 어떤 일에 쓰이는지를 단순화하면, 보통 다음과 같은 패턴으로 정리됩니다.
- 웹·모바일 앱 호스팅: 가장 일반적인 활용입니다. 트래픽 변동이 큰 서비스를 자체 서버로 운영하는 건 사실상 비효율적이라, 신규 서비스는 거의 기본값으로 클라우드 위에서 시작합니다.
- 데이터 분석·AI/ML: 대규모 데이터를 모으고 학습시키는 일은 자체 GPU 클러스터로 감당하기 어렵습니다. 필요한 시점에 GPU를 ‘빌려서’ 쓸 수 있는 클라우드는 AI 시대의 사실상 표준 인프라가 되었습니다. 실제 생성형 AI 전용 클라우드 서비스는 2025년 2분기에 전년 대비 140~180% 성장했습니다.
- 백업·재해 복구(DR): 본 시스템과 다른 지역의 클라우드에 백업을 두면, 자체 데이터센터 화재나 정전 같은 사고에 훨씬 강해집니다.
- 협업 도구: Google Workspace, Microsoft 365, Slack, Notion처럼 우리가 이미 매일 쓰는 SaaS도 모두 클라우드의 한 형태입니다. 사용자는 그것이 클라우드라는 사실조차 의식하지 못합니다.
(3) 한국 기업의 도입 현황
한국 기업의 클라우드 채택은 이미 일반 흐름이 됐습니다. 삼성SDS의 2025년 조사에 따르면 국내 중견·대기업의 66%가 이미 퍼블릭 클라우드를 도입했고, 산업별로는 리테일(73%)·서비스(71%)·제조(65%)가 높고 금융은 55%로 상대적으로 낮습니다. 보안 규제가 강한 산업일수록 도입이 늦어지는 경향이 그대로 드러납니다.
공공 부문은 도입률이 45%로 더 낮고, 단일 클라우드만 쓰는 비율이 51%에 달합니다. 민감 정보와 복잡한 의사결정 구조, 한정된 예산이라는 공공 특유의 조건이 도입 속도를 늦추는 요인으로 작용하고 있습니다.
이 절의 핵심은, 클라우드는 이미 ‘도입할까 말까’의 단계가 아니라 ‘어떻게 잘 도입할까’의 단계로 넘어왔다는 점입니다. 산업과 규모에 따라 속도와 형태가 다를 뿐, 방향 자체는 분명해졌습니다.
5. 대표 클라우드 서비스 둘러보기
이 섹션에서는 신규 서비스를 클라우드 위에 올린다고 가정하고, 그때 마주치게 되는 여섯 가지 카테고리를 둘러봅니다. 컴퓨팅, 스토리지, 데이터베이스, 서버리스, AI/ML, 컨테이너입니다.
으로 들어가기 전에, 여섯 카테고리와 빅3의 대표 서비스를 한 장에 정리하면 다음과 같습니다.
| 카테고리 | 답하는 질문 | AWS | Azure | GCP |
|---|---|---|---|---|
| 컴퓨팅 | 일단 서버가 한 대 필요하다 | EC2 | Virtual Machines | Compute Engine |
| 스토리지 | 이미지·동영상은 어디에 두지 | S3 | Blob Storage | Cloud Storage |
| 데이터베이스 | DB 운영을 직접 할 시간이 없다 | RDS, Aurora | SQL Database | Cloud SQL |
| 서버리스 | 잠깐만 돌리면 되는데 서버를 띄워야 하나 | Lambda | Functions | Cloud Run functions |
| AI/ML | LLM을 직접 학습시킬 수는 없다 | Bedrock | Azure OpenAI Service | Vertex AI |
| 컨테이너·쿠버네티스 | K8s 컨트롤 플레인을 직접 운영하기 부담스럽다 | EKS | AKS | GKE |
(1) 컴퓨팅: “일단 서버가 한 대 필요하다”
가장 먼저 만나는 카테고리는 컴퓨팅(compute)입니다. CPU와 메모리, 즉 ‘작업을 처리하는 기계’ 자체를 빌리는 영역으로, 클라우드의 출발점에 해당합니다. 신규 서비스를 띄우려면 결국 어딘가에 코드를 올리고 실행해야 하는데, 그 ‘어딘가’를 가장 자유롭게 정할 수 있는 방법이 바로 가상 서버를 빌리는 것입니다.
빅3의 대표 서비스를 보면 다음과 같습니다.
| 사업자 | 서비스 | 이 사업자만의 차이 |
|---|---|---|
| AWS | Amazon EC2 (Elastic Compute Cloud) | – 인스턴스 유형이 1,000개 이상으로 가장 다양 – Intel·AMD·Arm 프로세서를 모두 지원한 첫 빅3 사업자 |
| Microsoft Azure | Azure Virtual Machines | – Windows 서버·SQL Server·Active Directory와 통합이 자연스러움 – 기존 마이크로소프트 환경을 그대로 옮기기 좋음 |
| Google Cloud | Google Compute Engine (GCE) | – 사전 정의된 머신 유형 외에 사용자 정의 vCPU·메모리 조합을 자유롭게 만들 수 있음 |
이 중 가장 널리 쓰이는 EC2의 예를 들어보겠습니다. 콘솔에서 ‘인스턴스 시작’을 누르고 운영체제와 인스턴스 유형을 고르면, 몇 분 안에 가상 서버가 만들어지고 SSH로 접속할 수 있는 IP가 발급됩니다. 그 위에 OS·런타임·애플리케이션을 직접 올리고 운영하면 됩니다. 인스턴스를 끄거나 종료한 시점부터 과금이 멈춥니다.
EC2의 특징은 ‘인스턴스 유형(instance type)’으로 작업 성격에 맞춰 기계를 골라 쓸 수 있다는 점입니다. AWS 공식 문서는 다음과 같이 분류합니다.
- 범용 (general purpose, t·m 시리즈): CPU·메모리·네트워크가 균형 잡힘. 웹 서버, 작은 데이터베이스, 개발 환경
- 컴퓨트 최적화 (compute optimized, c 시리즈): 고성능 프로세서가 강점. 배치 처리, 미디어 인코딩, 게임 서버
- 메모리 최적화 (memory optimized, r·x 시리즈): 메모리 용량이 큼. 인메모리 데이터베이스, 대규모 분석
- 스토리지 최적화 (storage optimized, i·d 시리즈): 디스크 입출력이 강점. 데이터 웨어하우스, 분산 파일 시스템
- 가속 컴퓨팅 (accelerated computing, p·g 시리즈): GPU·FPGA가 붙음. 머신러닝 학습, 그래픽 렌더링
요금 모델도 사용 패턴에 맞춰 선택할 수 있습니다. 시간 단위로 빌리는 온디맨드(on-demand), 1년·3년 약정으로 최대 72%까지 할인받는 예약 인스턴스(reserved instance), 남는 자원을 최대 90% 싸게 빌리되 언제든 회수될 수 있는 스팟 인스턴스(spot instance)가 있습니다. 안정적인 서비스는 예약, 트래픽이 폭발하는 이벤트는 온디맨드, 백그라운드 배치 작업은 스팟으로 섞어 쓰는 패턴이 일반적입니다.
핵심은, 컴퓨팅 서비스가 ‘하드웨어를 사고 OS만 깐 단계까지’를 빌려주는 IaaS의 출발점이라는 점입니다. 자유도가 가장 크지만, OS 패치·보안 설정·애플리케이션 운영 모두 사용자가 책임집니다.
(2) 스토리지: “이미지·동영상은 어디에 두지?”
서버 다음으로 자주 만나는 카테고리는 스토리지(storage)입니다. 사용자 프로필 이미지, 상품 사진, 동영상, 백업 파일, 분석용 원시 데이터처럼 ‘오랫동안 보관할 데이터’를 두는 곳입니다. EC2 인스턴스 안에 파일을 둘 수도 있지만, 인스턴스가 사라지면 파일도 같이 사라지고, 여러 서버가 같은 파일을 공유하기도 어렵습니다. 그래서 ‘서버 바깥에서 파일을 안전하게 보관하는 별도의 저장소’가 필요합니다.
빅3의 대표 서비스는 다음과 같습니다.
| 사업자 | 서비스 | 이 사업자만의 차이 |
|---|---|---|
| AWS | Amazon S3 (Simple Storage Service) | – 2006년 출시된 객체 스토리지의 대표 격 – 99.999999999%(11 nines) 내구성을 설계 목표로 함 |
| Microsoft Azure | Azure Blob Storage | – 핫·쿨·콜드·아카이브 4단계 접근 계층 제공 – Active Directory 권한 모델과 통합 |
| Google Cloud | Google Cloud Storage | – 단일 API로 모든 스토리지 클래스 통합 – 리전 자동 전환과 BigQuery 직접 연동이 강점 |
S3로 자세히 보겠습니다. S3는 ‘버킷(bucket)’이라는 컨테이너 안에 ‘객체(object)’라는 단위로 파일을 넣는 구조입니다. 일반 파일 시스템과 달리 디렉터리 트리가 깊어져도 성능이 떨어지지 않고, 사실상 무제한으로 확장됩니다. 객체 하나에는 고유한 키와 메타데이터가 붙고, HTTP API로 접근합니다. 사용자가 직접 디스크 용량을 미리 정할 필요도, 부족할 때 늘리는 작업을 할 필요도 없습니다.
S3에서 가장 인상적인 숫자는 ‘11 nines’ 내구성입니다. 1,000만 개의 객체를 저장하면 평균 10,000년에 한 번 객체 하나를 잃을 확률이라는 뜻입니다. 어떻게 이런 수치가 나올까요? S3는 데이터를 한 리전 안의 최소 3개 가용 영역(Availability Zone)에 자동 복제합니다. 데이터센터 한 곳이 화재로 통째로 사라져도 다른 두 곳에 사본이 남아 있는 구조입니다.
같은 버킷 안의 데이터라도 접근 빈도에 따라 스토리지 클래스를 다르게 둘 수 있습니다. 자주 꺼내 쓰는 데이터는 S3 Standard, 가끔만 꺼내는 데이터는 S3 Standard-IA(Infrequent Access), 거의 꺼내지 않는 장기 보관 데이터는 S3 Glacier 계열에 둡니다. Glacier는 꺼내는 데 분~시간 단위가 걸리는 대신 보관 비용이 가장 쌉니다. 같은 데이터의 ‘활동 단계’에 맞춰 자동으로 클래스를 옮기는 ‘수명 주기(lifecycle) 정책’도 설정할 수 있습니다.
S3가 실제로 쓰이는 모습은 단순한 ‘파일 보관’보다 훨씬 넓습니다. 이미지·동영상 호스팅, 백업·재해 복구, 정적 웹사이트 호스팅, 그리고 가장 큰 영역인 데이터 레이크(여러 형식의 원시 데이터를 한곳에 모아두고 분석에 쓰는 저장소)까지 포함합니다.
스토리지 서비스는 ‘파일을 안전하게 두는 일’보다 ‘쓴 만큼만 비용을 내면서 사실상 무제한으로 둘 수 있게 하는 일’에 가깝습니다. 자체 NAS·SAN 장비를 사서 운영하던 시절과 가장 크게 달라진 지점입니다.
(3) 데이터베이스: “DB 운영을 직접 할 시간이 없다”
서버에 직접 MySQL이나 PostgreSQL을 깔고 운영하는 일은 만만치 않습니다. 백업·복구, 보안 패치, 이중화, 장애 조치, 모니터링까지 모두 사람이 챙겨야 합니다. 관리형 데이터베이스(managed database)는 이 운영 작업을 사업자가 대신 처리해주는 서비스입니다. 사용자는 SQL 쿼리를 보내고 데이터 모델을 설계하는 일에 집중하면 됩니다.
빅3의 대표 서비스는 다음과 같습니다.
| 사업자 | 서비스 | 이 사업자만의 차이 |
|---|---|---|
| AWS | Amazon RDS | MySQL·PostgreSQL·MariaDB·Oracle·SQL Server·Db2 6종을 관리형으로 제공 |
| AWS | Amazon Aurora | AWS가 자체 설계한 분산 스토리지 기반의 클라우드 네이티브 DB, MySQL·PostgreSQL과 호환 |
| Microsoft Azure | Azure SQL Database | SQL Server 기반. 마이크로소프트 데이터 도구와 통합이 자연스러움 |
| Google Cloud | Cloud SQL | MySQL·PostgreSQL·SQL Server 관리형. BigQuery와 결합한 분석 워크로드에 강점 |
여기서 헷갈리기 쉬운 게 RDS와 Aurora의 관계입니다. RDS는 MySQL·PostgreSQL·SQL Server 같은 기존 DB 엔진을 관리형 EC2 인스턴스 위에서 EBS 스토리지와 함께 돌리는 형태입니다. DB 엔진 자체는 그대로지만, 백업·패치·이중화 설정을 사업자가 대신 해줍니다.
반면 Aurora는 같은 SQL 인터페이스를 쓰지만 스토리지 계층을 통째로 새로 설계한 클라우드 네이티브 DB입니다. 데이터를 3개 가용 영역에 6중 복제로 분산 저장하고, 클러스터당 최대 15개의 읽기 복제본을 둘 수 있습니다. AWS는 MySQL 대비 최대 5배, PostgreSQL 대비 최대 3배 처리량이 나온다고 밝히고 있습니다. 즉 RDS가 ‘기존 DB를 운영만 위임한 형태’라면, Aurora는 ‘DB 자체를 클라우드 환경에 맞춰 다시 설계한 형태’입니다.
작동 방식은 콘솔에서 DB 엔진과 인스턴스 크기, 스토리지 용량을 고르면 사업자가 인프라를 띄우고 DB를 설치한 뒤 접속 엔드포인트를 돌려줍니다. 이후 자동 백업, 장애 시 자동 페일오버, 보안 패치, 모니터링이 기본으로 켜집니다.
핵심은, 관리형 DB가 ‘DB 운영자가 챙겨야 하던 일 중 인프라·고가용성·백업처럼 표준화 가능한 부분을 사업자가 가져간다’는 점입니다. 단, 쿼리 튜닝과 데이터 모델 설계는 여전히 사용자 책임입니다.
(4) 서버리스: “이 작업, 잠깐만 돌리면 되는데 서버를 띄워야 하나?”
지금까지 본 컴퓨팅·스토리지·DB는 ‘무언가를 빌려서 운영하는’ 모델입니다. 서버리스(serverless)는 한 단계 더 추상화해서 ‘서버 자체를 의식하지 않게’ 만든 모델입니다. 서버가 사라진 게 아니라, 사업자가 통째로 가려서 사용자가 신경 쓰지 않게 한 것입니다.
빅3의 대표 서비스는 다음과 같습니다.
| 사업자 | 서비스 | 이 사업자만의 차이 |
|---|---|---|
| AWS | AWS Lambda | 2014년 11월 발표된 FaaS의 시초. 다른 200여 개 AWS 서비스가 직접 트리거로 연결됨 |
| Microsoft Azure | Azure Functions | Visual Studio·.NET 환경과 통합이 자연스러움 |
| Google Cloud | Cloud Run functions | 컨테이너 이미지로도 함수를 실행할 수 있어 Cloud Run과 한 줄로 이어짐 |
Lambda를 예로 보겠습니다. 사용자가 함수 코드를 업로드하고 트리거(예: ‘S3에 파일이 올라오면 실행’, ‘API Gateway로 요청이 오면 실행’)를 지정하면, AWS가 Firecracker라는 마이크로 VM 위에서 코드를 실행합니다. 함수가 호출될 때만 실행 환경이 만들어지고, 끝나면 사라집니다.
기존 컴퓨팅과의 결정적 차이는 두 가지입니다.
- 요청이 없을 때는 서버가 0개: EC2는 인스턴스를 띄워놓는 동안 계속 과금되지만, Lambda는 호출이 없으면 비용이 0입니다.
- 밀리초 단위 과금: 함수 실행 시간(요청 횟수 + 실행 시간)만큼만 청구됩니다. 트래픽이 0인 시간에는 0원입니다.
이 모델 덕분에 Lambda는 수만 개 동시 실행으로 수 초 안에 자동 확장됩니다. 트래픽 예측이 어려운 워크로드에 특히 강합니다. 자주 보이는 활용 패턴은 다음과 같습니다.
- 사용자가 이미지를 S3에 업로드 → Lambda가 자동으로 썸네일 생성 → 다시 S3에 저장
- DynamoDB의 데이터가 변경 → Lambda가 검색 인덱스 업데이트
- API Gateway로 HTTP 요청 도착 → Lambda가 처리 → DB 조회 → 응답 (가벼운 백엔드)
서버리스의 단점도 분명합니다. 함수가 한동안 호출되지 않다가 다시 호출될 때 실행 환경을 새로 만드는 동안 발생하는 지연인 콜드 스타트(cold start)입니다. 자바·.NET 같은 무거운 런타임에서는 수 초가 걸릴 수 있습니다. AWS는 SnapStart, 프로비저닝된 동시성 같은 기능으로 이 지연을 줄이고 있습니다. 또한 함수 한 번 실행이 최대 15분으로 제한되기 때문에, 길게 도는 배치 작업이나 항상 켜져 있어야 하는 시스템에는 적합하지 않습니다.
핵심은, 서버리스가 ‘서버 운영을 사업자에게 완전히 위임하는 대가로 실행 환경의 통제권 일부를 포기한다’는 트레이드오프라는 점입니다. 짧고 이벤트 기반의 작업에는 강력하지만, 항상 켜져 있는 무거운 시스템에는 EC2 같은 일반 컴퓨팅이 더 맞습니다.
(5) AI/ML: “LLM을 직접 학습시킬 수는 없으니, API로 빌려 쓰자”
생성형 AI가 주류가 된 지금, 빅3는 모두 파운데이션 모델을 API로 제공하는 관리형 AI 서비스를 운영하고 있습니다. 사용자가 모델을 직접 학습시키지 않고, 이미 훈련된 모델에 프롬프트를 보내고 응답을 받는 형태입니다. 한 회사가 처음부터 LLM을 만들기에는 비용이 너무 크기 때문에, 대부분의 기업은 빌려 쓰는 길을 택합니다.
빅3의 대표 서비스는 다음과 같습니다.
| 사업자 | 서비스 | 어떤 모델을 쓸 수 있는가 |
|---|---|---|
| AWS | Amazon Bedrock | Anthropic Claude, Meta Llama, Mistral, AI21, Cohere, Amazon Nova에 더해 2026년 4월부터 OpenAI GPT-5.5·GPT-5.4까지 단일 API로 제공 |
| Microsoft Azure | Azure OpenAI Service | – OpenAI의 GPT 계열, DALL·E, o 시리즈 등을 Azure 환경에서 제공 – Microsoft 365 Copilot·GitHub Copilot 등 마이크로소프트 생태계와 결합이 가장 깊음 |
| Google Cloud | Vertex AI | Google의 Gemini 계열과 Model Garden을 통한 다른 회사 모델까지 통합 제공 |
세 서비스의 포지셔닝 차이는 다음과 같습니다.
Bedrock은 여러 회사 모델을 한 API로 묶어놓은 ‘모델 마트’ 형태로, 2026년 4월 OpenAI 모델까지 합류하면서 사실상 주요 프런티어 모델 대부분을 한 자리에서 쓸 수 있게 됐습니다.
Azure OpenAI는 7년 가까이 이어진 OpenAI 독점 호스팅이 2026년 4월 27일에 끝났지만, 여전히 OpenAI의 primary cloud partner이고 Microsoft 365 Copilot·GitHub Copilot처럼 마이크로소프트 생태계와 결합한 워크플로에서는 가장 자연스럽습니다.
Vertex AI는 Google의 Gemini를 중심으로 BigQuery 같은 데이터 도구와 한 줄로 이어지는 워크플로에 강점이 있습니다.
작동 방식은 비슷합니다. 사용자가 API 키를 받아 HTTP 요청에 프롬프트를 실어 보내면, 사업자 인프라에서 모델이 추론을 수행하고 응답을 돌려줍니다. 모델을 직접 학습시키지 않아도 되고, GPU도 빌리지 않아도 됩니다. 입력·출력 토큰 수만큼 과금되는 모델이 일반적입니다.
이런 관리형 AI 서비스 위에서 자주 보이는 워크플로는 다음과 같습니다.
- RAG (검색 증강 생성, Retrieval-Augmented Generation): 자체 문서를 벡터 DB에 인덱싱한 뒤, 질의가 오면 관련 문서를 찾아 프롬프트에 넣어 모델에 전달하는 패턴. 사내 매뉴얼 기반 챗봇이 대표적
- 챗봇·고객 응대 자동화: FAQ와 상품 정보를 임베딩해 두고 고객 질의에 답변
- 문서 요약·번역·분류: 긴 보고서를 요약하거나 다국어 콘텐츠를 자동 생성
핵심은, AI/ML 서비스가 ‘훈련된 모델을 빌려 쓰는 도구’라는 점입니다. 클라우드가 GPU·데이터·운영을 통째로 추상화해 주기 때문에, 한 회사의 작은 팀이 LLM 기반 기능을 며칠 만에 붙여볼 수 있게 됐습니다.
(6) 컨테이너·쿠버네티스: “마이크로서비스를 운영하려면 K8s가 필요한데…”
마지막은 컨테이너 오케스트레이션 서비스입니다. 컨테이너(Docker)는 애플리케이션과 그 실행 환경을 묶어 패키징하는 기술이고, 쿠버네티스(Kubernetes, K8s)는 컨테이너를 여러 서버에 걸쳐 자동 배포·복구·확장하는 오케스트레이션 도구입니다.
그런데 쿠버네티스 자체를 운영하는 일이 만만치 않습니다. 컨트롤 플레인(K8s 클러스터를 관리하는 두뇌)을 직접 띄우고, 업그레이드하고, 장애에 대응해야 하기 때문입니다. 빅3의 관리형 쿠버네티스 서비스는 이 컨트롤 플레인을 사업자가 대신 운영해주는 모델입니다.
빅3의 대표 서비스는 다음과 같습니다.
| 사업자 | 서비스 | 이 사업자만의 차이 |
|---|---|---|
| AWS | Amazon EKS (Elastic Kubernetes Service) | – AWS의 IAM·VPC와 깊이 통합 – 클러스터당 시간당 0.10달러의 컨트롤 플레인 비용 별도 |
| Microsoft Azure | Azure Kubernetes Service (AKS) | – Microsoft Entra ID(구 Azure AD)와 통합이 자연스러움 – 마이크로소프트 환경 조직에 친숙 |
| Google Cloud | Google Kubernetes Engine (GKE) | – 쿠버네티스를 처음 만든 Google이 운영 – 노드까지 자동 관리하는 Autopilot 모드 같은 자동화 기능이 강함 |
EKS를 따라가 보겠습니다. EKS는 사용자가 직접 운영하기 까다로운 쿠버네티스 컨트롤 플레인을 AWS가 대신 운영해주는 서비스입니다. 사용자는 컨트롤 플레인은 신경 쓰지 않고, 컨테이너가 실제로 실행되는 워커 노드(데이터 플레인)와 그 위에 올라갈 워크로드 정의(Pod, Deployment, Service 등)에만 집중합니다. 컨트롤 플레인은 EKS가 여러 가용 영역에 걸쳐 자동으로 복제·관리합니다.
핵심은, 관리형 쿠버네티스가 ‘컨트롤 플레인 운영이라는 가장 어려운 부분을 사업자가 가져가고 사용자는 워크로드 정의에만 집중하게 만든다’는 점입니다. 마이크로서비스 아키텍처를 본격적으로 운영하는 조직에는 거의 표준 선택지로 자리잡았습니다.
핵심은 클라우드를 ‘남의 컴퓨터’가 아니라‘쓴 만큼 내고 즉시 늘렸다 줄일 수 있는, 공유된 컴퓨팅 자원’으로 이해하는 것입니다. 그리고 그 위에 IaaS·PaaS·SaaS라는 ‘얼마나 깊이 빌릴까’의 축과, 퍼블릭·프라이빗·하이브리드·멀티 클라우드라는 ‘어디에 둘까’의 축이 겹치며 우리가 쓰는 모든 클라우드 형태가 만들어집니다.
여기까지는 무엇이 클라우드인가라는 이야기였습니다. 실제 기업이 클라우드로 옮겨갈 때 부딪히는 질문은 좀 더 까다롭습니다. 무엇을 먼저 옮길지, 어떤 방식으로 옮길지, 한 사업자에 다 맡길지 여러 곳을 섞어 쓸지 같은 의사결정이 따라옵니다. 다음 글에서는 이 실제 도입 단계의 이야기 클라우드 마이그레이션 전략과 멀티클라우드를 다뤄보겠습니다.
클라우드 시리즈