클라우드 컴퓨팅: OS와 자원 풀링 (Resource Pooling)

핵심 인사이트 (3줄 요약)

본질: 클라우드 컴퓨팅의 핵심인 자원 풀링 (Resource Pooling)은 수천 대의 물리적 서버, 스토리지, 네트워크 자원을 운영체제(하이퍼바이저/오케스트레이터)의 추상화 계층을 통해 하나의 거대한 '가상 자원 물웅덩이(Pool)'로 녹여내는 아키텍처다.

가치: 고객(Tenant)이 필요할 때마다 물리적 서버를 발주하는 대신, 이 거대한 물웅덩이에서 필요한 만큼의 CPU와 RAM을 즉각적으로 퍼다 쓰고(On-demand), 안 쓰면 다시 웅덩이로 반납하는 멀티테넌시(Multi-tenancy)의 극한의 효율성을 창출한다.

융합: 이를 가능하게 만든 것은 운영체제의 가상 메모리 매핑 기술, 하이퍼바이저의 CPU 오버커밋(Overcommit) 알고리즘, 그리고 컨테이너 네임스페이스(Namespace)의 자원 격리 기술이 거대한 스케일(Data Center)로 융합된 결과다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념:
- NIST(미국 국립표준기술연구소)가 정의한 클라우드 컴퓨팅의 5대 필수 특성 중 하나.
- 제공자(AWS, Azure)의 컴퓨팅 자원을 한데 모아(Pool), 다수의 소비자(Tenant)에게 동적으로 할당하고 회수하는 다중 임대(Multi-tenant) 모델이다. 소비자는 자원의 정확한 물리적 위치(어느 국가, 어느 랙 서버인지)를 알지 못하고 알 필요도 없다.
필요성(문제의식):
- 과거 온프레미스(On-premise) 환경에서는 A회사의 DB 서버는 밤에 90%가 놀고 있었고, B회사의 게임 서버는 밤에 트래픽이 폭주해 뻗어버렸다.
- A서버의 남는 CPU를 뜯어서 B서버에 빌려주는 것은 물리적으로 불가능했다 (자원의 파편화 및 고립).
- 해결책: "세상의 모든 서버를 하나의 거대한 운영체제로 묶어버리자. 그리고 소프트웨어(가상화)를 이용해 찰흙처럼 CPU와 메모리를 떼어내서 필요한 사람에게 1초 만에 빌려주자!"
💡 비유:
- 온프레미스 (독립 자원): 각자 자기 집에 작은 우물을 파놓고 물(CPU)을 쓴다. 비가 안 오면 내 우물이 말라 죽고(서버 다운), 비가 많이 오면 우물이 넘쳐흘러 버려진다(자원 낭비).
- 자원 풀링 (클라우드): 수천 개의 우물을 파이프로 연결해 거대한 **초대형 저수지(Pool)**를 만들었다. 나는 파이프에 수도꼭지만 연결해서 필요한 만큼 물을 틀어 쓰고 쓴 만큼만 돈을 낸다. 내 물이 어디서 왔는지는 몰라도 된다.
등장 배경:
- VMware의 하이퍼바이저 기술을 필두로, 분산 컴퓨팅의 오버헤드를 극복하고 남는 자원을 통계적 다중화(Statistical Multiplexing)로 팔아먹기 위한 IT 대기업들의 비즈니스적 극한 최적화에서 탄생했다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 전통적 사일로(Silo) 구조 vs 자원 풀링(Pooling) 구조    │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [ 전통적 온프레미스 (Siloed Infrastructure) ]                 │
  │   웹 서버 (CPU 20% 사용)  DB 서버 (CPU 90% 사용)                │
  │   ┌────────────┐        ┌────────────┐                      │
  │   │ 🟩 낭비됨   │        │ 🟥 꽉참!   │ ◀ 병목 발생, 증설 불가! │
  │   │ 🟩 낭비됨   │        │ 🟥 꽉참!   │                      │
  │   │ 🟦 사용중   │        │ 🟥 꽉참!   │                      │
  │   └────────────┘        └────────────┘                      │
  │    (물리적 장벽으로 서로 자원 대여 절대 불가)                          │
  │                                                             │
  │  [ 클라우드 자원 풀링 (Resource Pooling) ]                     │
  │                                                             │
  │   ┌──────────────────────────────────────────────────┐      │
  │   │ 💧 거대한 하이퍼바이저 / 쿠버네티스 자원 풀 (CPU 총합 1000개)│      │
  │   │  🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦🟦   │      │
  │   └─────┬───────────────────────────────┬────────────┘      │
  │         │ (동적 할당)                     │ (동적 할당)         │
  │         ▼                               ▼                  │
  │   [ Tenant A의 가상 서버 ]          [ Tenant B의 가상 서버 ]   │
  │   (웹 서버: CPU 2개 쏙 빼감)          (DB 서버: CPU 18개 쏙 빼감) │
  │   ※ Tenant B에 트래픽이 폭주하면? 풀에서 10개를 1초만에 더 떼어줌! (탄력성) │
  └─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 자원 풀링의 핵심은 "통계적 다중화(Statistical Multiplexing)"라는 마법이다. 만약 100명의 고객이 모두 동시에 100%의 CPU를 돌린다면 클라우드 서버는 펑 터질 것이다. 하지만 구글이나 아마존은 안다. "한국의 쇼핑몰 고객이 낮에 서버를 불태울 때, 미국의 고객은 밤이라 서버가 잔다." 이 완벽한 엇박자(통계적 확률)를 믿고, 물리적인 CPU 코어가 100개뿐인데 고객들에게는 300개를 팔아치우는 **오버커밋(Overcommit)**을 수행한다. 모든 자원을 거대한 웅덩이로 뭉쳐놓았기 때문에 국지적인 폭주가 발생해도 거대한 물웅덩이의 미세한 수위 변화로 상쇄되어 버리는 것이다.

📢 섹션 요약 비유: 은행이 실제 금고에 현금을 10억만 가지고 있으면서도, 고객들에게 100억의 대출(자원 풀링)을 해줄 수 있는 이유는 "모든 고객이 한 날 한 시에 돈을 다 찾으러 오지 않는다(뱅크런)"는 통계적 믿음 덕분입니다. 클라우드는 이 금융업의 원리를 컴퓨팅 자원에 완벽히 적용한 것입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

3대 자원 풀링 기술 스택 (Compute, Memory, Storage)

자원 풀링은 단순히 뭉치는 게 아니라, 물리 하드웨어의 멱살을 잡고 논리적으로 쪼개는 고도의 운영체제 기술이다.

자원 유형	풀링(추상화) 주체	내부 동작 메커니즘 (가상화 기술)
컴퓨팅 (CPU)	하이퍼바이저 (ESXi, KVM)	시분할 스케줄링 (Time Slicing): 물리 CPU 1개를 가상 vCPU 4개로 쪼개어 수 마이크로초 단위로 번갈아 실행. 유휴 상태면 다른 VM에 즉시 클럭을 빌려줌.
메모리 (RAM)	OS 커널 / 하이퍼바이저	KSM (메모리 중복 제거) & 벌루닝(Ballooning): 여러 VM이 띄운 동일한 OS 커널 파일을 램에 1번만 남기고 다 병합하여(COW), 램 용량 한계를 초과하여 빌려줌.
스토리지 (Disk)	분산 파일 시스템 (Ceph 등)	논리 볼륨(LVM) & 블록 가상화: 서버 1,000대에 달린 하드디스크를 하나로 묶어 거대한 SAN/NAS 풀을 만들고, 고객이 10GB를 원하면 빈 공간 10GB를 뚝 떼어 네트워크 볼륨으로 연결해 줌.

멀티테넌시(Multi-tenancy)와 격리 (Isolation)의 딜레마

거대한 웅덩이를 같이 쓰다 보면 필연적으로 보안과 성능의 간섭 문제가 터진다. 이를 **"시끄러운 이웃 (Noisy Neighbor) 문제"**라고 한다. 옆방(Tenant A)에서 채굴 프로그램을 돌리며 디스크 I/O를 100% 독식하면, 내 방(Tenant B)의 DB 서버가 영문도 모른 채 렉이 걸려 죽어버리는 현상이다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 자원 풀링 환경에서의 "시끄러운 이웃" 차단 아키텍처        │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [ ☁️ 공유 자원 풀 (Shared Pool) ]                                  │
  │   CPU 총 100코어 / RAM 512GB / Network 100Gbps                    │
  │                                                                   │
  │  ┌────────────┐               [ OS Cgroups / 하이퍼바이저 통제망 ]  │
  │  │ 해커 (VM 1) │ ──(코인 채굴!)──▶ 🚨 CPU 90코어 점유 시도!            │
  │  └────────────┘                  │ (QoS 제한 발동: Throttling!)   │
  │                                  ▼                              │
  │                           ⛔ CPU 할당량 상한선(Quota) 초과로 칼같이 쳐냄 │
  │                                                                   │
  │  ┌────────────┐                                                 │
  │  │ 고객 (VM 2) │ ──(일반 쇼핑몰)─▶ 🟢 격리된 나의 CPU 10코어를 안정적으로 사용│
  │  └────────────┘                 (옆집이 아무리 시끄러워도 철저한 방음벽 보장)│
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 진정한 풀링 기술은 "얼마나 잘 합치느냐"가 아니라 "합쳐놓고 얼마나 칼같이 잘 막아주느냐(격리)"에 달렸다. 하이퍼바이저나 리눅스 Cgroups(Control Groups)는 웅덩이에 파이프를 꽂은 사용자마다 **정밀한 유량 조절 밸브(QoS, Quality of Service)**를 달아둔다. Tenant A가 약속된 IOPS(초당 입출력)나 대역폭을 넘어서면, 하드웨어 타이머와 스케줄러가 즉각 개입하여 패킷을 드롭(Drop)시키거나 CPU 선점을 박탈(Throttling)하여, Tenant B가 물리적으로 완전히 독립된 서버를 쓰는 것과 동일한 수준의 착각(격리 환상)을 유지시켜 준다.

📢 섹션 요약 비유: 수영장(풀)에서 다 같이 물놀이를 할 때, 한 명의 거대한 뚱보(해커)가 배치기를 해서 엄청난 파도를 만들어 다른 사람들을 물먹이는 것(Noisy Neighbor)을 막기 위해, 수영장 바닥에 보이지 않는 칸막이(Cgroups/QoS)를 쳐서 파도가 절대 옆 레인으로 넘어가지 않게 방어하는 건축술입니다.

Ⅲ. 융합 비교 및 다각도 분석

자원 풀링의 3가지 레벨 비교 (IaaS vs PaaS vs SaaS)

풀링(추상화)의 깊이가 어디까지 들어가느냐에 따라 클라우드의 성격이 바뀐다.

클라우드 서비스	누가 자원 풀을 통제하는가?	소비자가 체감하는 풀링의 단위 (무엇을 빌려 쓰는가?)	대표 모델
IaaS	클라우드 제공자 (OS/Hypervisor 레벨)	가상 하드웨어 조각 (VM). 소비자가 직접 OS를 깔고, 그 위에 풀링 된 vCPU, RAM 덩어리를 받아옴.	AWS EC2
PaaS	클라우드 제공자 (컨테이너/런타임 레벨)	실행 환경 조각 (Container). OS 관리는 버리고, "파이썬 코드를 돌릴 수 있는 메모리 1GB짜리 구역 하나 줘"라고 요청.	AWS Elastic Beanstalk
SaaS	클라우드 제공자 (애플리케이션 레벨)	소프트웨어의 논리적 계정 (Account). 서버나 CPU는 아예 안 보이고, 하나의 큰 앱 안에서 내 계정용 데이터 풀만 분리해 줌.	Google Workspace

과목 융합 관점

컴퓨터 구조 (SR-IOV 및 하드웨어 오프로딩): 자원을 소프트웨어(하이퍼바이저)로 잘게 쪼개어 풀링하면 필연적으로 문맥 교환과 에뮬레이션 오버헤드(지연)가 30% 가까이 발생한다. 이를 극복하기 위해 물리적 랜카드(NIC) 하나를 칩셋 하드웨어 레벨에서 100개의 가상 랜카드(VF)로 쪼개어 VM들에게 직접 꽂아주는 SR-IOV (Single Root I/O Virtualization) 기술이 등장했다. "소프트웨어로 모으고, 하드웨어로 찢어준다"는 가장 기괴하고도 완벽한 융합이다.
클라우드 컴퓨팅 (SDN / SDS): 풀링의 철학은 CPU를 넘어 네트워크와 스토리지로 번졌다. 거대한 물리 라우터/스위치 장비들을 걷어내고, 소프트웨어(API)로 방화벽과 서브넷(VPC)을 1초 만에 뚝딱 만들어내는 **SDN(Software Defined Networking)**과 SDS(Software Defined Storage) 기술이 결합해야만 비로소 완전한 데이터센터(SDDC) 단위의 자원 풀링이 완성된다.
📢 섹션 요약 비유: IaaS는 빈 찰흙 덩어리(CPU/RAM)를 빌려줘서 고객이 알아서 빚게 하고, PaaS는 이미 빚어진 그릇(런타임)을 빌려줘서 요리만 담게 하며, SaaS는 아예 요리가 꽉 찬 뷔페 그릇(완성된 앱)을 내어주는 클라우드 진화의 3단계입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오 및 트러블슈팅

시나리오 — AWS EC2 스틸 타임 (Steal Time)에 의한 서버 멈춤: 온프레미스에서 구동하던 DB를 AWS t3.medium 인스턴스(범용 버스트 가능)로 마이그레이션했다. 갑자기 이벤트 날 DB가 뻗었다. top 명령어로 확인해 보니 유저 연산(us)이나 커널(sy)은 낮은데, st (Steal Time) 수치가 80%를 찍고 있었다.
- 원인 분석: 클라우드의 뼈아픈 진실, '오버커밋'의 희생양이 된 것이다. Steal Time은 내 가상 OS가 CPU를 쓰고 싶어서 발버둥 치는데, 하이퍼바이저가 내게 CPU를 주지 않고 옆방의 다른 VM(시끄러운 이웃)에게 주느라 "내가 도둑맞은 시간"을 뜻한다. 버스트(Burst) 인스턴스는 평소에 크레딧을 모아뒀다 쓸 때만 CPU 100%를 보장해 주는 값싼 공유 풀(Pool) 상품이다.
- 아키텍트 판단 (인스턴스 고립화 및 전용 호스트): DB 같이 일관된 하드코어 I/O와 연산이 필요한 워크로드는 절대 쪼개파는(T 시리즈) 공유 풀에 두면 안 된다. 아키텍트는 즉각 인스턴스 타입을 물리적 코어가 할당되는 전용 인스턴스(C, M 시리즈)로 올리거나, 아예 물리 서버 1대를 나 혼자 독점하는 **Dedicated Host (전용 호스트)**로 아키텍처를 변경하여 자원 풀링의 간섭(Interference)으로부터 시스템을 물리적으로 격리(Isolation)시켜야 한다.
시나리오 — 쿠버네티스(K8s) 자원 오버커밋(Overcommit)에 의한 OOM 연쇄 파동: 클러스터 노드(램 64GB)에 램 10GB를 쓰겠다고 선언(Request)한 컨테이너를 10개(총 100GB) 쑤셔 넣었다. "어차피 애들이 10GB를 항상 다 쓰는 건 아니니 풀링 오버커밋으로 돈을 아끼자"는 아키텍트의 도박이었다. 그런데 특정 시간에 트래픽이 몰리자 노드가 멈추고 컨테이너가 줄줄이 죽어 나갔다.
- 원인 분석: CPU는 모자라면(Throttling) 그냥 앱이 좀 느려질 뿐 죽지는 않는다. (압축성 자원, Compressible). 그러나 메모리는 1바이트라도 모자라는 순간 OS의 OOM Killer가 튀어나와 컨테이너를 학살해버린다. (비압축성 자원, Incompressible). 무리한 메모리 오버커밋은 폭탄 돌리기와 같다.
- 아키텍트 판단 (QoS Limits 하드 리미트 설정): 1원칙: "CPU는 오버커밋(풀링) 해도 되지만, 메모리는 절대 보수적으로 잡아라." 쿠버네티스의 파드 매니페스트에 메모리 limits를 엄격하게 걸어, 특정 컨테이너가 누수를 일으키더라도 자기 몫만 터지고 다른 컨테이너(자원 풀 전체)를 침범하지 못하게 하드 리미트를 설정해야 한다.

  ┌───────────────────────────────────────────────────────────────────┐
  │                 클라우드 자원 풀링 환경 생존을 위한 아키텍트 결정 트리      │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [ 서비스 워크로드에 맞는 클라우드 인스턴스를 설계한다 ]                   │
  │                │                                                  │
  │                ▼                                                  │
  │      서비스가 나노초(ns) 단위의 지터(Jitter)조차 허용하지 않는가? (HFT 등)  │
  │          ├─ 예 ─────▶ [ Bare-Metal (베어메탈) 인스턴스 선택 ]       │
  │          │             하이퍼바이저(풀링) 자체를 아예 걷어낸 물리 서버 독점│
  │          └─ 아니오                                                │
  │                │                                                  │
  │                ▼                                                  │
  │      데이터베이스(DB)처럼 일관되고 지속적인 100% CPU/I/O 성능이 필요한가?   │
  │          ├─ 예 ─────▶ [ Compute Optimized (M, C 계열) 선택 ]     │
  │          │             vCPU가 물리 코어와 1:1로 고정 할당되어 이웃 간섭 0 │
  │          └─ 아니오 (웹 서버, 마이크로서비스 등 부하가 널뛰기하는 일반 앱)   │
  │                │                                                  │
  │                ▼                                                  │
  │            [ Burstable (버스트/공유) 인스턴스 선택 (T 계열) ]            │
  │            자원 풀링의 혜택(초저가)을 누리되, 크레딧 모니터링 알람 연동 필수!  │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "클라우드는 마법이 아니다. 누군가의 컴퓨터일 뿐이다." 자원 풀링은 자본주의의 극치다. 싼 인스턴스는 여러 명을 좁은 방(물리 코어)에 몰아넣고(Overcommit), 비싼 인스턴스는 방을 넓게 독점(Pinning)하게 해준다. 아키텍트는 맹목적으로 클라우드의 유연성을 믿지 말고, 내 앱이 "옆방의 소음에 취약한지(민감도)"를 파악하여 가격과 격리(Isolation) 수준 사이에서 완벽한 타협점을 찾아내는 것이 핵심이다.

안티패턴

클라우드를 온프레미스처럼 (Lift & Shift) 방치: 서버실에 있던 100코어짜리 모놀리식(Monolithic) 앱을 코드 한 줄 안 고치고 그대로 100코어짜리 클라우드 거대 VM(EC2)으로 이사만 시켜놓고 방치하는 행위. 클라우드의 진정한 힘은 '자원 풀링의 탄력성'에 있다. 거대한 앱을 2코어짜리 50개의 마이크로서비스(컨테이너)로 쪼개어 쿠버네티스 자원 풀에 던져놔야, 부하가 올 때만 50개에서 200개로 1분 만에 자동 스케일 아웃(Auto-scaling) 하며 클라우드 비용 절감과 무한 확장의 진짜 단물을 빨아먹을 수 있다.
📢 섹션 요약 비유: 렌터카 서비스(자원 풀링)를 가입해 놓고, 매일 타지도 않는 커다란 리무진을 우리 집 마당에 한 달 내내 빌려 세워두는(Lift & Shift) 멍청한 짓입니다. 렌터카의 진짜 장점은 평소엔 경차를 타고, 짐이 많을 때만 1시간 동안 트럭을 빌려 타며 비용을 극강으로 아끼는 탄력성에 있습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	레거시 온프레미스 사일로 환경	클라우드 OS 자원 풀링 환경	개선 효과
정량 (자원 활용률)	평균 서버 CPU 사용률 10~15%	통계적 다중화로 평균 70~80% 유지	물리적 하드웨어 구매/유지보수 비용(TCO) 80% 삭감
정량 (프로비저닝 속도)	새 서버 발주 및 배송까지 수 개월 대기	API 호출 한 번에 1분 내 가상 머신 1천 대 생성	타임 투 마켓(Time to Market)의 압도적 단축
정성 (자원 유연성)	트래픽 폭주 시 물리적 증설 외엔 답 없음	남는 노드의 자원을 실시간(Live)으로 이주 할당	오토스케일링(Auto Scaling) 기반의 서비스 생존력 폭발

미래 전망

서버리스 (Serverless)와 기능 기반 풀링: 자원 풀링의 궁극적 진화 형태다. 가상 머신(VM)이나 컨테이너조차 고객에게 보여주지 않는다. 구글이나 AWS가 초거대 자원 풀을 숨겨놓고, 고객은 그냥 소스 코드(Function)만 올려두면 트래픽이 0일 땐 자원 할당 0(요금 0원), 트래픽이 1억 명일 땐 0.1초 만에 서버 수만 대 분량의 CPU 풀을 순간적으로 끌어와 연산을 쳐내고 다시 0으로 사라지는(Scale to Zero) AWS Lambda의 마법이 기본이 되고 있다.
가속기(GPU/NPU) 자원 풀링: 지금까지는 CPU와 RAM만 풀링했다면, AI 시대가 열리며 1장에 5천만 원이 넘는 엔비디아 GPU를 쪼개 쓰는 기술(MIG, Multi-Instance GPU)이 대세가 되었다. 무거운 AI 모델 학습 시에는 GPU 8개를 묶어서 하나처럼 쓰고, 가벼운 추론(Inference) 시에는 물리 GPU 1개를 7개의 가상 GPU(vGPU)로 완벽히 쪼개서 각기 다른 7명의 고객에게 격리해 빌려주는 초정밀 하드웨어 풀링 시대가 도래했다.

참고 표준

NIST SP 800-145: 미국 정부가 정의한 클라우드 컴퓨팅의 5대 필수 특성(On-demand, Broad network access, Resource pooling, Rapid elasticity, Measured service)의 세계적 기준.
OpenStack / Kubernetes: 하드웨어를 논리적 웅덩이로 묶고 API로 제어하기 위한 오픈소스 IaaS(가상머신) 및 PaaS(컨테이너)의 양대 산업 표준 오케스트레이션 프레임워크.

클라우드 컴퓨팅의 자원 풀링은 인류가 발명한 가장 위대한 "통계학적 사기극이자 마법"이다. 10만 대의 컴퓨터가 각자의 자아(OS)를 버리고 거대한 하나의 하이브 마인드(Hive Mind)로 녹아들어, 그 위에 떠 있는 수백만 개의 작은 애플리케이션들에게 "너 혼자 이 무한한 우주를 다 쓰고 있어"라는 달콤한 환상을 심어준다. 물리적 한계라는 차가운 철판을 소프트웨어 가상화라는 부드러운 찰흙으로 빚어낸 이 자원 풀링의 뼈대 위에서, 오늘날 구글, 넷플릭스, 우버의 눈부신 문명이 탄생할 수 있었다.

📢 섹션 요약 비유: 수만 개의 작은 모래성(개별 서버)을 짓고 각자 놀던 시대가 끝나고, 모든 모래를 거대한 산(자원 풀링)으로 모아놓은 뒤, 아이들(고객)이 파내는 만큼만 실시간으로 조각(컨테이너)을 내어주는 거대하고 무한한 클라우드 놀이터의 완성입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
가상화 (Hypervisor)	물리적 하드웨어(CPU/RAM)의 권한을 탈취하여 여러 개의 논리적 조각으로 쪼개주는 자원 풀링의 1등 공신이자 기본 칼(Knife)이다.
컨테이너 (Container / Namespace)	무거운 가상 머신(VM) 대신, 커널 하나를 공유하며 투명 파티션만 쳐서 풀링의 집적도(Density)를 100배로 튀긴 차세대 기술이다.
멀티테넌시 (Multi-tenancy)	하나의 아파트(자원 풀)에 수많은 세입자(고객)가 입주해도 서로 데이터가 섞이거나 옆집 소음이 안 들리게 방어하는 비즈니스/기술적 과제다.
오버커밋 (Overcommit)	물리적 자원은 100인데, 고객 100명에게 각각 5씩 (총 500) 빌려주면서 "동시에 안 쓰겠지"라는 확률에 배팅하는 클라우드 수익 창출의 핵심이다.
서버리스 (Serverless)	자원 풀링이 극한에 달하여, 고객 눈에 서버(인프라)라는 껍데기조차 보이지 않고 순수하게 '함수 연산' 단위로만 자원을 빌려 쓰는 최종 진화형이다.

👶 어린이를 위한 3줄 비유 설명

옛날에는 집마다 개인 우물(서버)을 파서 물을 마셨어요. 어떤 집은 우물이 말라서 죽고, 어떤 집은 물이 남아돌아서 버렸죠.
그래서 마을 사람들이 돈을 모아 거대한 '하나의 호수(자원 풀링)'를 만들었어요. 그리고 집마다 수도꼭지(클라우드 접속)만 연결했죠.
이제 물이 많이 필요한 공장(대기업)은 수도꼭지를 콸콸 틀고, 물이 조금 필요한 아이(개인)는 찔끔만 틀어서 자기가 쓴 물 양(초 단위 요금)만큼만 돈을 내는 마법의 마을이 된 거예요!