정의: 인터넷을 통해 컴퓨팅 자원(서버, 저장 공간, 데이터베이스, 네트워크, 소프트웨어 등)을 필요할 때 빌려 쓰고, 쓴 만큼만 비용을 내는 방식.
비유: 전기. 집에 발전기를 두지 않고 콘센트에 플러그를 꽂아 쓴 만큼 요금을 낸다.
클라우드도 똑같다 — 직접 서버를 사서 전산실에 두는 대신, AWS 같은 공급자의 서버를 인터넷으로 빌려 쓰고 사용량만큼 지불한다.
전통적인 방식(온프레미스, on-premises)과 비교하면 차이가 분명해진다.
비교 항목
온프레미스 (직접 보유)
클라우드 (빌려 쓰기)
서버 구입
미리 큰돈 주고 직접 구매
구매 불필요, 필요할 때 사용
비용 형태
선투자(자본비용)
사용한 만큼(가변비용)
용량 확장
새 장비 주문·설치까지 수주~수개월
몇 분 안에 클릭으로 확장
관리 책임
전력·냉방·하드웨어 모두 내 몫
물리 인프라는 공급자가 관리
미국 국립표준기술연구소(NIST)는 클라우드의 5가지 특징을 정의했다 — ① 주문형 셀프서비스(필요할 때 직접 즉시 사용), ② 광범위한 네트워크 접근, ③ 자원 풀링(여러 사용자가 자원 공유), ④ 빠른 탄력성(수요에 맞춰 자동 확장/축소), ⑤ 측정된 서비스(사용량 측정 후 과금). 이 다섯 가지가 클라우드를 단순한 "남의 서버"와 구분 짓는 기준이다.
클라우드가 왜 생겼는지는 "그 전에는 뭘 해야 했는지"를 보면 단번에 이해된다. 인터넷 서비스를 하나 만들려면 순서가 대략 이랬다.
얼마나 커질지 미리 맞힌다 — "동시에 몇 명이 올까?"를 개발 시작 전에 숫자로 정해야 했다.
장비를 주문한다 — 견적·결재·배송·랙 설치·배선·OS 설치까지 몇 주에서 몇 달.
서버 둘 공간을 마련한다 — 전기, 냉방, 무정전 전원, 소화 설비, 출입 통제. 서버 한 대를 켜려고 건물부터 손봐야 했다.
사람을 붙인다 — 새벽에 디스크가 고장 나면 누군가 나가서 갈아 끼워야 하니 24시간 당번이 필요했다.
즉 "코드를 짜기도 전에 돈과 시간이 먼저 나가는 구조"였다. 게다가 여기엔 빠져나갈 수 없는 함정이 있었다. 1번의 "미리 맞히기"는 어차피 틀린다는 것이다.
너무 많이 사면 — 평소엔 놀고 있는 장비에 돈이 묶인다. 몇 년 뒤엔 감가상각만 남는다.
너무 적게 사면 — 정작 사람이 몰리는 그 순간에 멈춘다. 더 사려 해도 도착까지 또 몇 주다.
클라우드는 이 딜레마 자체를 없앤다. 미리 맞힐 필요가 없어졌기 때문이다. 수요가 오르면 그때 늘리고, 내려가면 줄이면 된다. "6가지 이점" 중 ③ 용량 추정 불필요가 왜 그렇게 강조되는지가 여기에 있다.
대학 수강신청이나 공연 티켓 예매를 떠올려 본다. 1년 중 딱 며칠, 그것도 특정 시각 몇 분만 접속이 폭발하고 나머지는 한산하다. 온프레미스라면 그 몇 분을 위해 1년 내내 놀 장비를 사둬야 한다. 클라우드라면 그 시간대에만 서버를 늘렸다가 되돌리고 늘린 시간만큼만 낸다. 이런 "뾰족한 수요"를 가진 서비스가 클라우드로 가장 먼저 옮겨간 이유다.
⚠️ 함정: "클라우드는 무조건 더 싸다"는 시험에서 틀린 보기로 쓰이기 쉽다. 강점은 절대 가격이 아니라 ① 선투자 없이 시작 ② 안 쓰면 안 냄 ③ 수요에 맞춤이라는 비용 구조에 있다. 몇 년간 똑같은 부하로 돌아가는 워크로드라면 직접 보유가 더 쌀 수도 있다. 보기에 "항상 더 저렴" 같은 절대 표현이 보이면 의심한다.
① 수도꼭지 — 온디맨드(주문형)와 종량 과금
집집마다 우물을 파지 않는다. 열면 물이 나오고, 계량기에 찍힌 만큼 낸다. 잠그면 요금도 멈춘다. 서버도 필요하면 열고 필요 없으면 잠근다. "쓴 만큼만(pay-as-you-go)"은 이 계량기 이야기다.
② 렌터카 — 소유 대신 이용
며칠 쓰려고 차를 사지는 않는다. 보험·정비·주차 걱정은 렌터카 회사 몫이고 나는 운전만 한다. 짐이 많으면 큰 차로 바꾸고(스케일 업), 일행이 늘면 한 대 더 빌린다(스케일 아웃).
③ 호텔 연회장 — 탄력성(Elasticity)
20명이 올지 200명이 올지 모를 때, 필요하면 칸막이를 트고 사람이 빠지면 다시 닫는 방. 수요에 맞춰 자동으로 늘었다 줄었다 하는 것이 탄력성이고, 클라우드가 파는 핵심 상품이다.
여기에 하나만 덧붙이자. 아파트 한 동이 수도관 하나를 여러 세대가 나눠 쓰듯, 클라우드도 여러 고객이 같은 물리 자원을 나눠 쓴다(자원 풀링). 이 "함께 쓰기" 덕분에 단가가 내려가는 것이 규모의 경제다.
온디맨드(on-demand)는 "필요한 그 순간에, 누구 허락을 기다리지 않고, 내가 직접" 쓸 수 있다는 뜻이다. 온프레미스 시대에는 서버 한 대를 쓰려면 구매 요청서를 올리고 승인을 기다려야 했다. 클라우드에서는 화면에서 몇 번 클릭하면 몇 분 만에 서버가 생긴다. NIST가 말한 "주문형 셀프서비스"가 이 변화를 가리킨다.
퍼블릭 클라우드(Public Cloud): AWS, Azure 같은 공급자가 인터넷으로 제공하는 자원을 여러 고객이 함께 사용. 가장 일반적인 형태.
프라이빗 클라우드(Private Cloud): 한 조직이 전용으로 사용하는 클라우드. 보안·규제 요구가 강한 경우 선택.
하이브리드 클라우드(Hybrid Cloud): 퍼블릭 + 프라이빗(또는 온프레미스)을 연결해 함께 사용. 일부 데이터는 내부에, 나머지는 퍼블릭 클라우드에 두는 식.
서비스 제공 수준에 따라 IaaS / PaaS / SaaS로도 나눈다. IaaS(서버·네트워크 같은 기초 인프라 제공, 예: EC2), PaaS(앱 실행 환경까지 제공, 예: 관리형 DB), SaaS(완성된 소프트웨어 제공, 예: 웹메일). 위로 갈수록 사용자가 관리할 부분이 줄어든다.
세 모델은 우열이 아니라 상황에 따른 선택이다. 시험 문항도 "이런 상황이면 무엇을 권하겠는가" 형태로 나온다.
상황
어울리는 모델
이유
새로 시작하는 서비스, 수요가 불확실
퍼블릭
선투자 없이 바로 시작, 늘렸다 줄였다 자유
법·규제상 특정 데이터를 외부에 둘 수 없음
프라이빗(또는 하이브리드)
민감 데이터를 조직 통제 범위 안에 유지
데이터센터에 이미 큰 투자를 했고 단계적으로 옮기고 싶음
하이브리드
기존 자산을 살리며 점진적 이전
전부 직접 보유·운영하는 것은 배포 모델이 아니라 그냥 온프레미스이고, 여러 공급자를 함께 쓰는 멀티 클라우드는 하이브리드와 다른 개념이다. 보기에서 이 셋을 섞어 놓는 일이 많으니 구분해 둔다.
⚠️ 함정: "하이브리드 = 여러 클라우드 회사를 함께 쓰는 것"이라고 기억하면 틀린다. 하이브리드의 핵심은 퍼블릭 클라우드와 조직 내부 환경(프라이빗 클라우드·온프레미스)을 연결한다는 점이다. 문항에 "기존 데이터센터를 유지하면서 일부 워크로드를 AWS로" 같은 표현이 보이면 정답은 하이브리드다.
배포 모델이 "어디에 두느냐"의 분류라면, IaaS/PaaS/SaaS는 "어디까지 남이 해 주느냐"의 분류다. 이 둘을 섞어서 묻는 문항이 있다.
가장 유명한 비유는 피자다. 피자를 먹는 방법이 곧 네 단계다.
구분
피자로 치면
고객이 관리하는 것
대표 예
온프레미스
재료 사다가 반죽부터 직접
전부 다
사내 전산실 서버
IaaS (Infrastructure as a Service)
밀키트를 사서 집 오븐에 굽기
운영체제, 미들웨어, 앱, 데이터
EC2
PaaS (Platform as a Service)
배달시켜 집에서 먹기
애플리케이션, 데이터
관리형 데이터베이스, 앱 배포 플랫폼
SaaS (Software as a Service)
식당에 가서 먹기
내 데이터와 계정 정도
웹메일, 웹 오피스
아래로 갈수록(IaaS → PaaS → SaaS) 신경 쓸 일이 줄고, 대신 세부 통제권도 줄어든다. 그래서 "유연성은 크지만 관리 부담도 크다"면 IaaS, "코드만 올리면 실행 환경은 알아서"면 PaaS, "설치도 운영도 없이 로그인만 하면 끝"이면 SaaS다.
함정: 배포 모델(퍼블릭/프라이빗/하이브리드)과 서비스 모델(IaaS/PaaS/SaaS)은 다른 축이다. "퍼블릭 클라우드 위의 IaaS"도 있고 "프라이빗 클라우드 위의 PaaS"도 있다. 보기에 두 축이 섞여 있으면, 문항이 "어디에 두는가"를 묻는지 "어디까지 맡기는가"를 묻는지부터 확인한다.
CLF-C02는 계산이나 설정 문제가 아니라 개념을 알아보는 문제가 대부분이다. 문항에서 아래 키워드가 보이면 정답 후보가 거의 정해진다.
문항에 이런 표현이 보이면
답은 이쪽
"선투자 없이 시작", "초기 투자 최소화", "CapEx를 OpEx로"
자본비용 → 가변비용 전환
"수요를 예측하기 어렵다", "얼마나 필요할지 모른다"
용량 추정 불필요 / 탄력성
"AWS가 대량 구매해 단가를 낮춘다", "규모 덕분에 저렴"
대규모 규모의 경제
"몇 주 걸리던 것이 몇 분", "빠르게 실험하고 출시"
속도와 민첩성
"전력·냉방·랙 관리를 하지 않아도 됨"
데이터센터 운영 비용 절감
"해외 사용자에게 빠르게", "여러 나라에 손쉽게 확장"
몇 분 만에 전 세계 배포
"승인 없이 즉시 생성", "사용량을 측정해 청구"
주문형 셀프서비스 / 측정된 서비스
"기존 데이터센터를 유지하며 일부만 AWS로"
하이브리드 클라우드
"운영체제까지 직접 관리하고 싶다", "최대한의 통제"
IaaS(EC2)
"설치·운영 없이 로그인해서 바로 사용"
SaaS
광고 캠페인 하루 만에 가입자가 평소의 수십 배로 뛴 스타트업을 떠올려 본다. 온프레미스였다면 그날 안에 장비를 늘릴 방법이 없어 서비스가 멈췄을 것이다. 클라우드에서는 트래픽이 오르는 동안 서버 대수를 늘렸다가 캠페인이 끝나면 되돌린다. 이때 작동한 이점은 하나가 아니다 — 용량 추정 불필요, 탄력성, 속도·민첩성, 가변비용이 동시에 작동한다. 시험은 그중 "가장 직접적으로 해결한 것"을 고르게 하므로, 지문의 핵심이 비용인지 속도인지 용량 변동인지부터 짚는 습관이 중요하다.
다음 글에서는 이 클라우드가 실제로 어디에, 어떻게 펼쳐져 있는지 — AWS의 글로벌 인프라(리전, 가용 영역, 엣지 로케이션)를 본다.