IaaS (Infrastructure as a Service) - 서버/스토리지/네트워크 가상화
핵심 인사이트 (3줄 요약)
- 본질: IaaS (Infrastructure as a Service)는 CPU, 메모리, 스토리지, 네트워크 방화벽 등 데이터센터의 거대한 쇳덩어리(물리적 하드웨어)들을 하이퍼바이저(Hypervisor) 기반의 가상화 기술로 쪼개어, 인터넷을 통해 1분 만에 임대해 주는 클라우드 컴퓨팅의 가장 밑바닥 기초 공사 모델이다.
- 가치: 수천만 원짜리 서버를 주문하고 조립하느라 3주를 허비하던 기존 온프레미스의 병목을 박살 내고, 1시간에 100원이라는 충격적인 종량제(Pay-as-you-go)와, 트래픽 폭주 시 클릭 한 번에 서버를 100대로 무한 복제하는 오토스케일링(Auto-Scaling)의 축복을 인류에게 최초로 선사했다.
- 융합: IaaS는 빈 깡통(빈 서버)을 빌려줄 뿐 OS 관리와 보안 패치는 사용자가 짊어져야 하는 고통(Shared Responsibility)이 따르지만, 테라폼(Terraform) 같은 코드 기반 인프라(IaC) 도구 및 쿠버네티스(K8s)와 융합되면서 인프라를 마우스 클릭이 아닌 '코드 파일 텍스트'로 순식간에 찍어내는 데브옵스(DevOps) 혁명의 절대적 토대가 되었다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: IaaS (Infrastructure as a Service)는 클라우드 서비스 제공자(CSP, 예: AWS, Azure, GCP)가 물리적 서버, 네트워크 스위치, 디스크 스토리지를 보유하고 이를 가상화하여, 고객이 운영체제(OS)를 자유롭게 설치하고 애플리케이션을 구동할 수 있는 '빈 가상 머신(VM)' 형태의 컴퓨팅 자원을 온디맨드(On-demand)로 대여해 주는 서비스 모델이다.
-
필요성: 2000년대 초반, 스타트업이 게임이나 쇼핑몰을 만들려면 은행에서 빚을 내어 용산 전자상가에서 서버 랙(Rack)과 라우터를 사 와야 했다. 샀다고 끝이 아니다. IDC 센터에 월세를 내고 서버를 꽂은 뒤 에어컨을 빵빵하게 틀고 24시간 보안 요원을 고용해야 했다(막대한 CAPEX 고정 자본 지출). 게임 오픈 날 10만 명이 몰리면 서버가 터져 망했고, 10명만 오면 비싸게 산 서버가 99% 놀아서 망했다. 서버를 사는 행위 자체가 거대한 리시크(Risk)의 덩어리였다. 이때 아마존(AWS)이 2006년 EC2 (Elastic Compute Cloud)를 들고나와 선언했다. "서버 사지 마라! 클릭 한 번 하면 리눅스 깔린 컴퓨터 1대를 화면에 띄워줄게. 1시간 쓰고 버리면 100원만 받을게!" 수백만 원의 초기 비용을 0원으로 깎아버리고 실패의 리스크를 소멸시킨 IaaS의 등장은 실리콘밸리 벤처 붐을 터뜨린 진짜 방아쇠였다.
-
등장 배경 및 기술적 패러다임 전환: IaaS가 가능했던 가장 큰 기술적 뒷배는 **가상화(Virtualization)**의 성숙이다. 클라우드 벤더의 데이터센터에는 일반인은 살 수 없는 거대한 집채만 한 괴물 물리 서버들이 깔려 있다. 여기에 KVM이나 Xen 같은 하이퍼바이저를 씌워서, 괴물 서버 1대를 100개의 작은 가상 컴퓨터(VM)로 갈기갈기 찢어버렸다(자원 풀링 및 멀티 테넌시). 고객 A와 고객 B는 사실 동일한 CPU 칩셋을 나눠 쓰고 있지만 철저한 논리적 격리(Isolation) 덕분에 자신만 독점하고 있다고 착각하게 만든다. 물리적 쇳덩어리가 소프트웨어 코드 블록(Software-Defined)으로 치환되는 순간, 하드웨어 산업은 죽고 클라우드 서비스 산업의 우주가 열린 것이다.
이 다이어그램은 낡은 하드웨어 조립 방식의 한계와, 가상화(Hypervisor)가 어떻게 IaaS의 마법을 부리는지를 명확히 대조한다.
┌───────────────────────────────────────────────────────────────┐
│ 서버 할당 방식: 전통적 전산실(On-Premise) vs 클라우드 IaaS │
├───────────────────────────────────────────────────────────────┤
│ │
│ [A. 과거 온프레미스 (Hardware-Defined) - 느리고 비싼 지옥] │
│ │
│ 1. 사장님 결재 (1주) ──▶ 2. 델(Dell) 서버 주문 및 배송 (2주) │
│ ──▶ 3. IDC 센터에 랙(Rack) 나사 조립 및 랜선 꽂기 노가다 (1주) │
│ ──▶ 4. 윈도우 OS CD 넣고 설치 ──▶ 드디어 개발 시작! (총 1달 소요 💥) │
│ │
│ [B. 클라우드 IaaS (Software-Defined) - 마우스 클릭의 마법] │
│ │
│ [ 🧑💻 개발자가 AWS 콘솔 웹사이트 접속 (주문형 셀프서비스) ] │
│ 👉 "난 CPU 4코어, 메모리 16GB, Ubuntu 리눅스 빈 깡통 하나 줘!" 클릭. │
│ │
│ [ ☁️ 클라우드 데이터센터 내부 (Hypervisor 가상화 엔진 작동) ] │
│ 거대한 물리 서버(CPU 100코어)에서 0.1초 만에 CPU 4개를 논리적으로 뚝 떼어냄.│
│ 미리 구워둔 Ubuntu 리눅스 복사본(AMI)을 그 공간에 팍! 덮어씌움. │
│ │
│ [ 1분 후... 🚀 ] │
│ "고객님, IP 주소 192.168.0.1 빈 서버 켜졌습니다. 1시간에 50원입니다." │
└───────────────────────────────────────────────────────────────┘
[다이어그램 해설] 이 메커니즘의 핵심은 **'소프트웨어 정의 인프라(SDI, Software-Defined Infrastructure)'**로의 권력 이동이다. 과거에는 네트워크 선을 나누려면 진짜 스위치 장비에 가서 선을 잘라야 했다. IaaS 환경에서는 하드웨어를 사람이 만지지 않는다. 거대한 물리 자원 풀(Pool) 위에 올라간 컨트롤 플레인(Control Plane) 소프트웨어가, 사용자의 API 호출(클릭)을 받는 즉시 가상의 랜선(VPC)을 긋고 가상의 하드디스크(EBS) 볼륨을 떼어내서 가상의 컴퓨터(EC2)에 조립해 준다. 이 모든 뚝딱거림이 1분 안에 끝난다. 더 무서운 것은 폐기(Termination)다. 쇼핑몰 타임 세일이 끝나면 "서버 삭제" 버튼 하나로 이 가상 컴퓨터를 허공에 폭파시켜 버린다. 썼던 디스크와 CPU는 다시 클라우드 거대 풀(Pool)로 반환되어 다른 회사(넷플릭스 등)에게 재임대된다. 이것이 바로 IaaS가 창조한 극단적인 '자원 회전율'과 '규모의 경제'다.
- 📢 섹션 요약 비유: IaaS가 없던 시절은 장사를 하려면 무조건 내 돈 1억을 들여 1년 내내 비싼 임대료를 내며 상가 건물을 직접 계약해야 했습니다(온프레미스). IaaS는 거대한 백화점(클라우드 센터) 측이 매대에 선 하나만 찍 그어주고(가상화), "너 오늘 점심시간 1시간만 여기서 떡볶이 팔고, 1시간치 자릿세 천 원만 내고 흔적 없이 나가도 돼!"라고 허락해 주는 기적의 팝업 스토어 경제학입니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
IaaS 인프라 3대 핵심 컴포넌트 아키텍처 (AWS 기준)
IaaS는 단순히 컴퓨터 본체 하나만 달랑 주는 것이 아니다. 데이터센터의 모든 부품을 가상화하여 제공한다.
| 인프라 컴포넌트 | 가상화 개념 및 역할 | 대표 클라우드 서비스 (AWS) | 물리적 비유 |
|---|---|---|---|
| Compute (컴퓨팅) | 거대한 CPU/RAM 풀에서 나만의 사양(예: 8코어 32GB)만큼 논리적으로 격리해 떼어낸 가상 머신(Virtual Machine) 인스턴스 | Amazon EC2 (Elastic Compute Cloud) | 컴퓨터 본체와 두뇌 |
| Storage (스토리지) | 컴퓨터 본체와 분리되어 네트워크로 꽂히는 영구 저장 하드디스크. 서버(EC2)가 터져도 데이터는 디스크(EBS)에 살아남음 | Amazon EBS (블록 저장소) Amazon S3 (객체 저장소) | 외장 하드디스크 및 무한 창고 |
| Network (네트워크) | 다른 회사의 해커가 내 서버로 핑을 때리지 못하게 10.0.0.0 대역의 가짜 울타리를 치는 가상 프라이빗 클라우드(VPC) 및 방화벽 설정 | Amazon VPC Security Group, ELB (로드밸런서) | 건물 담벼락과 출입문 경비원 |
딥다이브: 공동 책임 모델 (Shared Responsibility Model)의 냉혹한 현실
"아마존(AWS) 썼는데 해킹당해서 비트코인 채굴기로 쓰였어요! 아마존 고소할 겁니다!" IaaS 초보자들이 가장 많이 저지르는 치명적 착각이다. 아마존은 당신의 코드를 지켜주지 않는다.
┌──────────────────────────────────────────────────────────────────┐
│ IaaS의 헌법: 공동 책임 모델 (Shared Responsibility Model) │
├──────────────────────────────────────────────────────────────────┤
│ │
│ [ 🚨 사용자(Customer)의 절대 책임 구역 - "클라우드 ☁️ 안에서의 보안" ] │
│ │
│ - 고객의 소스 코드 버그 (SQL 인젝션 방어) │
│ - 🔓 운영체제(Linux/Windows) 커널 패치 및 백신 설치 ◀ (가장 많이 털림) │
│ - 데이터베이스 비밀번호 암호화 및 S3 버킷 공개 설정 통제 │
│ - 방화벽(Security Group)에서 포트 22번 전 세계 개방하는 바보짓 막기 │
│ │
│ ───────────────────── 넘을 수 없는 통제의 벽 (Hypervisor) ────────────────│
│ │
│ [ 🛡️ 클라우드 벤더(AWS/GCP)의 절대 책임 구역 - "클라우드 ☁️ 자체의 보안" ] │
│ │
│ - 하이퍼바이저 펌웨어 업데이트 (다른 VM이 내 VM 훔쳐보는 것 방어) │
│ - 데이터센터 물리적 보안 (테러리스트가 서버실에 C4 폭탄 던지는 것 막기) │
│ - 발전기 전원 이중화 (정전 나도 서버 안 꺼지게 UPS 디젤 돌리기) │
│ - 네트워크 케이블 및 물리적 라우터 유지 보수 │
└──────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 이 모델은 IaaS의 본질인 "자유에는 책임이 따른다"는 뼈아픈 진리를 보여준다. IaaS는 당신에게 '최고 관리자 권한(Root Access)'을 100% 넘겨준다. 아마존은 물리적 데이터센터 건물을 완벽히 무장시키고, 철창을 친 빈 방(빈 가상 머신)을 당신에게 내어줄 뿐이다. 그 빈 방 안에서 당신이 리눅스 비밀번호를 1234로 설정하든, 방화벽 문을 활짝 열어두어 해커가 들어와 비트코인을 채굴하든 아마존은 약관에 따라 1달러도 배상하지 않는다. "OS 패치가 너무 귀찮고 방화벽 룰 짜는 게 무섭다"면, 운영체제 통제권을 아마존에게 아예 반납해 버리고 코드만 올리는 **PaaS (184번 문서)**나 아예 완제품인 SaaS로 도망가는 것이 유일한 해법이다.
- 📢 섹션 요약 비유: 건물주(AWS)가 튼튼한 콘크리트 상가(IaaS)를 지어서 세입자(나)에게 빌려주었습니다. 지진이 나서 건물이 무너지면 건물주 책임입니다. 하지만 세입자인 내가 귀찮다고 상가 철문을 활짝 열어놓고 퇴근해서 도둑이 들어와 내 금고를 털어갔다면(OS 해킹), 건물주는 1원도 보상해주지 않습니다. 문단속(OS 보안 패치와 방화벽)은 100% 셋방살이 주인의 책임입니다.
Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)
IaaS vs PaaS vs SaaS 트레이드오프 (Trade-off) 매트릭스
인프라 아키텍트는 자유(Control)와 귀찮음(Management) 사이에서 외줄 타기를 해야 한다.
| 비교 항목 | IaaS (Infrastructure / 예: AWS EC2) | PaaS (Platform / 예: Heroku, RDS) | SaaS (Software / 예: Google Docs) |
|---|---|---|---|
| 제공 자원 | 깡통 서버 (OS만 깔려 있거나 아예 비어있음) | 런타임 환경 (Tomcat, Java, DB가 다 깔려있음) | 완제품 앱 (코딩 불필요, 바로 실행) |
| 운영체제(OS) 패치 | 사용자가 새벽에 직접 해야 함 (지옥) | 클라우드 제공자가 몰래 해줌 (천국) | 알 필요 없음 |
| 제어권 (자유도) | 최상 (내 맘대로 이상한 커스텀 모듈 설치 가능) | 중간 (정해진 언어나 환경 제약 존재) | 최하 (버튼 색깔 정도만 변경 가능) |
| 벤더 종속 (Lock-in) | 낮음 (도커로 싸서 GCP로 이사 가기 쉬움) | 높음 (벤더 특화 API 의존 시 탈출 어려움) | 높음 (데이터 포맷 종속) |
| 주요 고객 | 인프라 튜닝이 필수인 대기업, 데브옵스 엔지니어 | 백엔드 코드만 짜고 싶은 개발자, 스타트업 | 회계/인사 업무를 하는 일반 회사원 |
이 매트릭스에서 알 수 있듯, IaaS는 '가장 로우 레벨(Low-level)'이다. 개발자가 직접 Nginx를 깔고 로드밸런서를 세팅해야 하는 피곤함이 있다. 하지만 이 '귀찮음'은 곧 '자유'를 의미한다. 만약 아마존(AWS) 서버비가 너무 비싸져서 구글(GCP)로 이사를 하고 싶다면? IaaS 위에서 도커(Docker) 컨테이너로 앱을 말아두었다면 1시간 만에 짐을 싸서 구글 깡통 서버로 완벽히 도망칠 수 있다(멀티 클라우드 전략). 반면 PaaS에 너무 푹 절여지면 그 클라우드의 노예(Lock-in)가 되어 영원히 비싼 요금을 내야 하는 인질이 된다.
Infrastructure as Code (IaC)와의 파괴적 융합 혁명
IaaS가 아무리 마우스 클릭으로 서버를 띄울 수 있다 한들, 서버 1,000대를 띄우려면 마우스를 1,000번 클릭해야 한다. 인간의 손가락은 클라우드의 확장성을 따라가지 못한다. 그래서 **테라폼(Terraform)**이나 AWS CloudFormation 같은 IaC(코드로 인프라 정의) 도구가 등장했다.
개발자가 resource "aws_instance" { count = 1000 } 이라고 텍스트 코드 딱 한 줄을 짜서 실행 엔터를 친다. 아마존 IaaS API가 이 텍스트를 읽고 허공에서 0.1초 만에 서버 1,000대와 방화벽을 펑펑 터뜨리며 찍어낸다. 물리적 쇳덩어리(서버)가 깃허브(Git)에 올릴 수 있는 '알파벳 텍스트(코드)'로 완벽하게 변이한 이 융합(IaaS + IaC)이야말로 현대 데브옵스(DevOps) 문화를 창조한 빅뱅이다.
- 📢 섹션 요약 비유: IaaS는 내 맘대로 찰흙을 빚어 어떤 성이든 만들 수 있지만 손이 많이 가는 '레고 블록'입니다. PaaS는 다 조립된 채로 문만 달면 되는 '조립식 주택'이죠. 처음엔 조립식 주택이 편하지만, 창문 위치를 내 맘대로 뜯어고치는 진짜 대저택을 지으려면 결국 바닥부터 내 맘대로 튜닝할 수 있는 레고 블록(IaaS)의 자유도가 반드시 필요해집니다.
Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)
실무 시나리오 및 설계 안티패턴
-
시나리오 — 스타트업의 트래픽 폭주 스파이크(Spike) 생존기: 예능 프로그램에 우리 스타트업의 앱이 노출되어 평소 100명이던 동접자가 3분 뒤 10만 명으로 폭주할 예정이다. 온프레미스였다면 서버가 터지고 9시 뉴스를 탔겠지만, 클라우드 아키텍트는 미소를 짓는다.
- 의사결정: IaaS의 핵심 엔진인 **오토 스케일링(Auto-Scaling)**을 세팅해 두었다. 서버 CPU 사용률이 70%를 넘는 순간 클라우드가 알람을 울린다. 아마존 IaaS가 미리 구워둔 우리 앱의 '디스크 복사본(AMI)'을 이용해 빈 깡통 서버 50대를 허공에서 1분 만에 펑펑 찍어내어 트래픽 방어막(Scale-Out)을 전개한다. 방송이 끝나고 새벽이 되어 트래픽이 빠지면, 냉혹하게 50대의 서버를 삭제(Scale-In)시켜 버린다. 불탄 서버 50대의 2시간 치 대여 요금 단돈 10만 원만 내고, 회사의 명운이 걸린 10만 명의 결제 트래픽을 완벽하게 다 받아낸 승리다.
-
안티패턴 — '리프트 앤 시프트 (Lift and Shift)'의 요금 폭탄 악몽: 낡은 전산실(온프레미스)을 버리고 클라우드로 이사하라는 회장님 지시에, 개발팀은 아무런 생각 없이 기존 통짜(Monolithic) 자바 서버 코드를 그대로 복사해서 AWS IaaS 빈 깡통(EC2)에 밀어 넣고 24시간 365일 내내 켜두었다.
- 결과: 클라우드(IaaS)는 무조건 서버를 켜둔 '초(Seconds)' 단위로 요금이 청구되는 무자비한 미터기 택시다. 트래픽이 적은 밤에도 서버를 켜두어야 하는 레거시 코드를 그대로 클라우드에 올리면, 기존 사내 전산실 유지비보다 클라우드 청구서 요금이 3배 넘게 폭등하는 요금 폭탄(Bill Shock) 대참사가 발생한다.
- 해결책: IaaS로 껍데기만 옮기는 이사를 '리프트 앤 시프트'라 하며, 이는 실패의 지름길이다. 진정한 클라우드의 축복(비용 절감)을 누리려면 낡은 코드를 잘게 쪼개어(마이크로서비스) 필요할 때만 서버가 복제되었다가 지워지는 클라우드 네이티브(Cloud Native) 구조로 애플리케이션 코드를 뼛속부터 다시 짜는 대수술(Refactoring)이 반드시 선행되어야 한다.
엔터프라이즈 IaaS 마이그레이션 의사결정 트리
단순히 싸서 클라우드로 가는 것이 아니다. 통제권과 유지보수의 저울질이다.
┌───────────────────────────────────────────────────────────────────┐
│ 기업 IT 인프라 마이그레이션(클라우드 전환) 의사결정 트리 │
├───────────────────────────────────────────────────────────────────┤
│ │
│ [기존 사내 전산실(IDC) 장비 노후화로 차세대 인프라 전환 요건 발생] │
│ │ │
│ ▼ │
│ 서비스 트래픽이 1년 내내 널뛰기 없이 항상 똑같이 일정한가? (예: 사내 결재망) │
│ ├─ 예 ──▶ [ 온프레미스 유지 또는 코로케이션(Colocation) 권장 ] │
│ │ - IaaS의 최고 장점인 '탄력성'을 쓸 일이 없다면, 3년 감가상각 │
│ │ 고려 시 직접 하드웨어를 사서 돌리는 것이 비용적으로 3배 싸다.│
│ │ │
│ └─ 아니오 (이벤트마다 트래픽이 요동치고 글로벌 확장이 수시로 일어남) │
│ │ │
│ ▼ │
│ 회사에 리눅스 OS 패치, 보안 방화벽 룰, DB 백업을 24시간 책임질 인력이 있는가?│
│ ├─ 아니오 ──▶ [ PaaS (플랫폼 대여) 혹은 SaaS 로 즉각 선회! ] │
│ │ - IaaS를 빌리면 보안이 다 털린다. 플랫폼에 100% 외주 줘라.│
│ │ │
│ └─ 예 (빵빵한 클라우드 아키텍트와 데브옵스 보안 엔지니어 보유함) │
│ │ │
│ ▼ │
│ [ IaaS (Infrastructure as a Service) 깡통 인프라 전격 도입 확정! ] │
│ - AWS EC2/VPC 환경 위에 쿠버네티스(K8s) 클러스터를 올려 극강의 자유도 세팅.│
│ - 무한대의 오토스케일링(Scale-out) 연동으로 트래픽 폭주 스파이크 100% 방어. │
│ │
│ 판단 포인트: "클라우드(IaaS)는 마법이 아니라 '남의 컴퓨터를 분 단위로 비싸게 빌려 │
│ 쓰는 렌터카'다. 치고 빠지는 기술(스케일링)이 없으면 파산뿐이다." │
└───────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 이 의사결정 트리는 "무조건 클라우드로 가야 한다"는 맹신을 부순다. 항상 100% 돌아가는 고정 트래픽의 DB 서버를 IaaS 렌트 요금으로 돌리면 온프레미스 구매 비용보다 압도적으로 비싸진다. 클라우드 벤더들도 바보가 아니라 서버 마진을 남겨야 하기 때문이다. IaaS의 진가는 **'필요 없을 때 부숴버릴 수 있는 파괴의 미학'**에 있다. 트래픽이 요동치는 구간만 IaaS의 오토스케일링으로 빨아들이고, 고정 트래픽 뼈대나 무거운 DB는 사내망 물리 서버에 남겨두는 하이브리드 클라우드(Hybrid Cloud) 아키텍처가 통신비(Egress Fee)를 잡고 보안을 사수하는 현대 엔터프라이즈 아키텍트들의 궁극적 정답이다.
- 📢 섹션 요약 비유: 매일 출퇴근하는 사람이라면 차를 사는 것(온프레미스)이 택시비보다 훨씬 쌉니다. 하지만 1년에 한두 번 가족 10명이 단체 여행을 가야 할 때는 10인승 버스를 사는 것은 미친 짓이죠. 그때만 10인승 버스를 하루 렌트(IaaS 오토스케일링)하는 것이 완벽한 경제학입니다. IaaS는 매일 타는 데 쓰는 게 아니라, 갑자기 큰 버스가 필요할 때 1분 만에 버스를 대령해 주는 요술 램프입니다.
Ⅴ. 기대효과 및 결론
정량/정성 기대효과
| 구분 | 레거시 물리 전산실 (On-Premise) | IaaS 클라우드 인프라 도입 시 | 개선 효과 |
|---|---|---|---|
| 정량 (초기 지출) | 피크 트래픽 기준 장비 구매 (100% CAPEX 고정비) | 빈 깡통 빌린 초(s) 단위 결제 (100% OPEX 운영비) | 실패 리스크 제로화 및 인프라 초기 자본(CAPEX) 완전 소멸 |
| 정량 (리드타임) | 하드웨어 발주 및 배송 2~4주 소요 대기 | API 및 콘솔 클릭으로 1분 만에 VM 할당 (Provisioning) | 타임 투 마켓 (Time-to-Market) 및 확장성 99% 극단적 단축 |
| 정성 (운영/재해) | 화재 발생 시 서버와 하드디스크 전소(파산 확정) | 디스크 분리(EBS) 및 타 대륙(Region) 버튼 1초 복제 | 벼락같은 재난에도 살아남는 글로벌 재해 복구(DR) 체계 즉각 완성 |
미래 전망
- 베어메탈 (Bare-Metal) 클라우드의 역습: IaaS는 하이퍼바이저(가상화 프로그램)가 자원을 쪼개주는 방식이라 필연적으로 5%의 성능 손실(가상화 오버헤드)이 발생한다. 최근 AI 딥러닝 연산이나 초고속 금융 거래처럼 1ms의 딜레이도 빡치는 고객들을 위해, 가상화를 아예 걷어내고 물리적인 CPU와 쇳덩어리 서버 한 대를 통째로 독점 렌트해 주는 '베어메탈 IaaS' 인스턴스가 다시 인기를 끌고 있다. (돌고 도는 아키텍처의 역사)
- DPU/스마트닉 (SmartNIC) 하드웨어 오프로딩: 아마존(AWS)은 가상화를 처리하느라 메인 CPU가 피곤해하는 현상을 없애기 위해, AWS Nitro System이라는 특수 칩(DPU)을 서버에 박아 넣었다. 메인 CPU는 오직 사용자의 코드만 돌리고, 네트워크 패킷 쪼개기와 디스크 암호화 같은 가상화 잡일은 전부 이 특수 칩(Nitro)에 떠넘겨버림(Offloading)으로써 IaaS의 가상화 성능 손실을 0%에 수렴하게 만든 극강의 하드웨어 진화를 이룩했다.
참고 표준
- NIST SP 800-145: 클라우드를 IaaS, PaaS, SaaS 3단계 계급으로 명확히 쪼개버린 미국 표준 기술 연구소의 바이블 문서.
- OVAL (Open Virtualization Format) / AMI (Amazon Machine Image): 내가 튜닝한 깡통 리눅스 서버(IaaS)를 찰칵 사진 찍어서 도장처럼 수천 대 찍어내게 해주는 가상 머신 이미지 스냅샷 표준 규격.
세상에 공짜 점심은 없고, 영원히 고장 나지 않는 하드웨어도 없다. IaaS는 "하드웨어는 언젠가 반드시 부서진다"는 절망적인 팩트 앞에서 아키텍트들이 내놓은 가장 유연한 도피처다. 서버가 죽으면 고치는 것이 아니라, 가차 없이 그 서버를 폭파해 버리고 옆에 똑같은 새 깡통 서버를 1분 만에 복제해 띄우면 된다(Disposable Infrastructure). 영원히 죽지 않는 불사조(온프레미스)를 꿈꾸며 돈을 쏟아붓는 대신, 파리가 목숨을 다하면 수천 마리의 새끼 파리를 까고 죽듯 끊임없이 쪼개지고 복제되는 찰흙(IaaS)의 철학을 수용한 것이다. 통제권(Control)의 달콤함 이면에 숨겨진 OS 관리의 십자가를 묵묵히 짊어지고 나갈 데브옵스 군단이 준비되었다면, IaaS는 당신의 기업을 전 세계 어디로든 확장시켜 줄 가장 위대한 무한 동력 엔진이 될 것이다.
- 📢 섹션 요약 비유: 옛날엔 게임 저장을 하려면 꼭 내 컴퓨터 하드디스크가 멀쩡해야 했습니다(온프레미스). IaaS는 컴퓨터 본체는 클라우드 회사가 빌려주고, 내 세이브 파일은 인터넷 구름(스토리지)에 둥둥 떠 있는 상태입니다. 빌린 컴퓨터 본체가 벼락을 맞아 터져도 슬퍼할 필요가 1도 없습니다. 즉시 새 컴퓨터 본체를 렌트한 뒤 구름 속 세이브 파일을 쏙 끼워 넣으면, 하던 게임을 1초 만에 그대로 이어서 할 수 있는 무적의 부활 시스템입니다.
📌 관련 개념 맵 (Knowledge Graph)
| 개념 명칭 | 관계 및 시너지 설명 |
|---|---|
| 가상화 (Hypervisor) | 물리적 쇳덩어리(서버 1대)를 가위로 쪼개 수백 대의 작은 가짜 컴퓨터(VM) 인스턴스로 만들어내는 IaaS 생태계의 절대적 심장 마법이다. |
| PaaS (184번 문서) | IaaS는 빈 깡통이라 내가 OS를 관리해야 하지만, PaaS는 "인프라는 우리가 숨길 테니 넌 코드만 올려"라며 책임을 대신 져주는 한 단계 위 진화 모델이다. |
| 오토 스케일링 (Auto-Scaling) | 트래픽이 폭주하면 IaaS의 API를 때려 1대였던 가상 서버를 100대로 찍어내고, 끝나면 지워버리는 클라우드의 최고 존엄 무기다. |
| VPC (Virtual Private Cloud) | IaaS의 네트워크 가상화. 남의 회사 서버와 내 서버가 같은 물리 장비에 있어도, 절대 서로 해킹할 수 없게 IP 주소에 논리적 유리 장벽을 쳐버리는 철통 보안망이다. |
| IaC (테라폼, 앤서블) | 마우스 클릭으로 IaaS 서버 100대를 띄우는 건 하수다. count=100이라는 텍스트 코드로 치면 클라우드가 허공에서 인프라를 지어주는 데브옵스의 혁명이다. |
👶 어린이를 위한 3줄 비유 설명
- 옛날에 레고 성을 만들려면, 아빠한테 한 달 동안 조르고 졸라서 비싼 레고 세트를 몽땅 사 와야 했어요. (돈도 비싸고 버리기도 아까움)
- **IaaS (아이아스)**는 동네에 생긴 엄청 큰 '레고 대여점'이에요!
- 내가 딱 1시간만 성을 만들고 싶으면, 인터넷 버튼만 띡 누르면 레고 조각이 눈앞에 쏟아져요! 신나게 성을 짓고 놀다가 1시간 뒤에 "반납!" 하고 100원만 내면 끝나는 기적의 놀이터랍니다!