한 줄 정의
인프라 플랫폼은 컴퓨팅·스토리지·네트워킹 리소스를 API로 온디맨드 프로비저닝하는 동적 IaaS 계층으로, 코드형 인프라가 관리하는 ‘인프라’ 그 자체입니다.
쉽게 말하면
이 장은 클라우드 시스템을 3층 건물처럼 계층으로 나눕니다. 식당에 비유하면 이해가 쉽습니다.
손님(사용자)은 오직 접시에 나온 요리(애플리케이션)에만 관심이 있습니다. 그 요리 뒤에는 불·오븐·냉장고가 놓인 주방 라인(애플리케이션 런타임 — 서버, 클러스터, DB)이 있고, 다시 그 뒤에는 가스·전기·수도와 식자재 납품(인프라 플랫폼 — 컴퓨팅·스토리지·네트워킹)이 있습니다. 아래 계층은 오로지 위 계층을 가능하게 하려고 존재합니다.
코드형 인프라가 다루는 곳은 맨 아래, 가스·전기·수도 계층입니다. 그리고 결정적으로 이 계층은 유틸리티 회사에 전화해 며칠을 기다리는 방식이 아니라, 제어판(API)의 스위치로 필요할 때 즉시 켜고 끌 수 있어야 합니다. 이 ‘즉시성’이 바로 동적 인프라 플랫폼의 조건입니다.
왜 중요한가?
이 장은 ‘코드형 인프라’의 ‘인프라’가 정확히 무엇인지 규정합니다. 그리고 그 답의 핵심은 동적 인프라 플랫폼 입니다.
코드형 인프라는 정적 하드웨어 위에서는 성립하지 않습니다. 코드가 프로비저닝하고 변경할 대상, 즉 API로 온디맨드 조작이 가능한 플랫폼이 먼저 있어야 합니다. 예전 인프라는 하드웨어 그 자체였고, 가상화가 시스템을 하드웨어에서 분리했으며, 클라우드가 그 가상 리소스를 관리하는 API를 더하면서 비로소 코드로 다룰 수 있는 인프라가 생겼습니다.
또 하나의 목적은 벤더 중립 어휘 입니다. AWS·Azure·GCP는 같은 리소스를 다른 상품명으로 팝니다(VPC vs virtual network, S3 vs Blob Storage). 이 장이 정의하는 계층·용어를 쓰면 특정 벤더에 매이지 않고 이후 논의를 이어갈 수 있습니다.
핵심 내용
세 가지 플랫폼 계층
최신 클라우드 인프라의 구성 요소를 세 계층으로 묶으면 정리됩니다. 위 계층일수록 사용자에 가깝고, 아래 계층은 위 계층을 활성화하기 위해 존재합니다.
| 계층 | 역할 | 구성 요소 예 |
|---|---|---|
| 애플리케이션 | 조직·사용자에게 기능 제공. 나머지 전부가 이 계층을 위해 존재 | 앱 패키지, 컨테이너 인스턴스, 서버리스 코드 |
| 애플리케이션 런타임 (PaaS) | 애플리케이션에 서비스·기능 제공 | 서버, 컨테이너 클러스터, DB 클러스터, 서버리스 환경, OS |
| 인프라 플랫폼 (IaaS) | 인프라 리소스와 이를 관리하는 도구·서비스 | 컴퓨팅·스토리지·네트워킹 프리미티브 |
이 책은 인프라 플랫폼 계층의 리소스를 조합해 애플리케이션 런타임 계층을 만드는 것을 전제로 합니다.
동적 인프라 플랫폼
동적(dynamic) 인프라 플랫폼 은 API로 리소스를 온디맨드 프로비저닝·변경할 수 있는 플랫폼입니다. 이 책에서 ‘인프라 플랫폼’은 곧 동적 IaaS를 뜻한다고 봐도 됩니다.
플랫폼 유형은 퍼블릭에서 프라이빗, 상용에서 오픈소스까지 다양합니다.
| 유형 | 예 |
|---|---|
| 퍼블릭 클라우드 | AWS, Azure, GCE, Oracle Cloud, Digital Ocean 등 |
| 프라이빗 클라우드 | CloudStack, OpenStack, VMware vCloud |
| 베어메탈 클라우드 | Cobbler, FAI, Foreman |
벤더마다 같은 리소스를 다른 이름으로 패키징하므로(대부분의 퍼블릭 클라우드는 Heroku·Elastic Beanstalk 같은 호스티드 PaaS도 함께 제공), 이 책은 상품명 대신 일반 명칭(VPC → 네트워크 주소 블록)을 씁니다.
멀티 클라우드 용어
하나의 클라우드로 시작한 조직도 결국 여러 플랫폼을 함께 쓰는 멀티 클라우드로 갑니다.
| 용어 | 의미 |
|---|---|
| 하이브리드 클라우드 | 프라이빗 인프라 + 퍼블릭 클라우드를 함께 사용. 이전이 어려운 서비스(메인프레임)나 법적 데이터 호스팅 요구 때문에 선택 |
| 클라우드 애그노스틱 | 어느 퍼블릭 클라우드에서도 실행되도록 구축 — 벤더 락인 방지 목적(락인을 피하려다 특정 소프트웨어에 종속되기도 함) |
| 폴리 클라우드 | 둘 이상 퍼블릭 클라우드에 앱·서비스를 나눠 운영 — 각 플랫폼의 장점을 활용 |
인프라 리소스: 프리미티브와 복합 리소스
인프라 플랫폼의 필수 리소스는 컴퓨팅·스토리지·네트워킹 세 가지입니다. 이 기본 요소를 프리미티브(primitive) 라 부릅니다(공학의 ‘기초 요소’). 플랫폼은 프리미티브를 결합해 복합 리소스 를 만듭니다 — DBaaS, 로드 밸런싱, DNS, ID·액세스 관리(IAM), 비밀 정보 관리 등.
경계가 늘 뚜렷하지는 않습니다. 프리미티브인 오브젝트 스토리지(S3)조차 데이터를 읽고 쓰려면 컴퓨팅·네트워킹을 씁니다. 그래도 구분 자체는 리소스를 나열하고 이해하는 데 유용합니다.
컴퓨팅 리소스
컴퓨팅은 코드를 실행합니다. 본질은 물리 서버 CPU 코어의 실행 시간이지만, 플랫폼은 이를 더 쓸모 있는 형태로 제공합니다.
| 리소스 | 핵심 | 예시 |
|---|---|---|
| 가상 서버 (VM) | 하이퍼바이저 위에서 실행되는 가상 머신 인스턴스 | — |
| 물리 서버 | 온디맨드로 동적 프로비저닝하는 베어메탈 | — |
| 서버 클러스터 | 서버 풀을 그룹 단위로 프로비저닝·관리 | Auto Scaling Group, VMSS, Managed Instance Group |
| 컨테이너 (CaaS) | 표준 이미지로 컨테이너 인스턴스 실행 | Docker |
| 애플리케이션 호스팅 클러스터 | 여러 앱을 배포·관리하는 서버 풀 | ECS, EKS, AKS, GKE |
| 서버리스 함수 (FaaS) | 이벤트·스케줄에 온디맨드 실행 후 종료 | Lambda, Azure Functions, Cloud Functions |
서버리스는 코드 실행 그 이상
DynamoDB·Cosmos DB는 서버가 사용자에게 보이지 않는 서버리스 데이터베이스로, 서버를 호스팅하는 전통적 DBaaS(RDS)와 다릅니다. SageMaker 같은 특수 목적 온디맨드 실행 환경도 같은 결입니다.
스토리지 리소스
동적 플랫폼은 스토리지를 애플리케이션에 투명하게 제공합니다. 가상 서버에 물리 스토리지를 명시적으로 지정하던 기존 가상화와 다른 점입니다.
| 리소스 | 핵심 | 예시 |
|---|---|---|
| 블록 스토리지 | 로컬 디스크처럼 단일 인스턴스에 연결하는 가상 디스크 볼륨 | EBS, Azure Page Blob, Cinder, GCE PD |
| 오브젝트 스토리지 | 여러 위치에서 파일 저장·액세스. 저렴·고내구성이나 지연이 큼 | S3, Azure Block Blob, GCS, Swift |
| 네트워크 파일시스템 | NFS·SMB 등으로 여러 인스턴스가 공유 마운트 | — |
| 구조화된 데이터 (DBaaS) | 코드로 정의·관리하는 DB·문서·키값 저장소 | MySQL, Postgres, SQL Server |
| 비밀 정보 관리 | 패스워드·키 등 비밀을 전용으로 저장·관리 | — |
네트워킹 리소스
코드로 네트워킹을 온디맨드 프로비저닝·변경하는 능력은 단순한 속도 이상입니다. 프로덕션 적용 전 구성 변경을 빠르고 정확하게 테스트할 수 있고, 소프트웨어 정의 네트워킹(SDN)으로 더 세밀한 보안 구성을 만들 수 있습니다.
| 리소스 | 역할 |
|---|---|
| 네트워크 주소 블록 | 리소스를 그룹화해 라우팅 제어. 최상위는 VPC(=virtual network), 하위로 서브넷·VLAN 분할 |
| 도메인 이름 | IP 등 하위 레벨 주소와 연결 |
| 라우터 | 주소 블록 간 허용 트래픽 구성 |
| 게이트웨이 | 블록 안팎으로 트래픽 전달 |
| 프록시 | 접속을 허용하고 규칙으로 변경·라우팅 |
| API 게이트웨이 | HTTP/S 프록시 + 인증·속도 조절(rate throttling) |
| VPN | 떨어진 네트워크 블록을 하나처럼 연결 |
| 전용 연결 | 클라우드-데이터센터/오피스 간 전용 회선 |
| 방화벽 규칙 | 네트워크 위치 간 트래픽 허용·제한 |
| 비동기 메시지 | 메시지를 주고받는 큐 |
| 캐시 · CDN | 데이터를 여러 구간·지역에 분산해 지연 개선 |
| 서비스 메시 | 분산 서비스 간 연결을 동적 관리. 네트워킹을 인프라 계층에서 앱 런타임 계층으로 이동 |
제로 트러스트와 SDN
제로 트러스트 보안 모델은 네트워크 안 장치를 무조건 신뢰하는 경계 기반 모델과 달리, 모든 서비스·리소스를 가장 낮은 레벨에서 보호하고 명시적으로 필요한 최소 권한만 부여합니다. 각 구성 요소의 접근 관계를 코드로 정의해야 현실적으로 운영·감사가 가능하므로, 코드형 인프라가 제로 트러스트의 전제가 됩니다.
내 생각
-
동적 플랫폼은 IaC의 전제조건이지 부가 기능이 아닙니다. API 온디맨드 조작이 안 되는 정적 가상화 위에는 Terraform이 프로비저닝할 대상 자체가 없습니다. “클라우드 = 가상화 + 관리 API”라는 정의가 이 지점을 정확히 짚습니다.
-
프리미티브 vs 복합 리소스는 실무에서 “어디까지 직접 조립하나”의 선택입니다. DB가 필요할 때 RDS(복합/DBaaS)를 쓸지 EC2+EBS(프리미티브)로 직접 올릴지가 이 경계의 문제이고, 운영 부담과 제어권의 트레이드오프로 이어집니다.
-
애플리케이션 호스팅 클러스터(EKS·GKE)는 PaaS가 아닙니다. 이들은 앱에 대한 컴퓨팅 프로비저닝만 관리하지 완전한 PaaS(Heroku 류)가 아닙니다. 쿠버네티스를 “우리 사내 PaaS”라 부를 때 빠지기 쉬운 함정입니다.
-
서비스 메시가 네트워킹을 앱 런타임 계층으로 끌어올린다는 정의가 핵심입니다. Istio·Linkerd가 재시도·mTLS·라우팅을 사이드카로 옮기는 이유가 이 계층 이동이고, 인프라가 아니라 앱 배포와 함께 관리된다는 뜻입니다.
관련 개념
- Ch01 코드형 인프라란 — 이 인프라 플랫폼을 코드로 다루는 이유와 실행 방법
- Ch02 클라우드 시대 인프라의 원칙 — 동적 인프라를 전제로 한 다섯 가지 원칙