IaaS, 데이터센터를 API 호출 하나로 대체하는 인프라 소비 방식

서버 한 대를 늘리는 데 왜 어떤 조직은 며칠이 걸리고 어떤 조직은 몇 분이면 끝날까

같은 VM 한 대를 새로 만드는 일이 한쪽에서는 결재 라인과 물리적 배선 작업을 거치고, 다른 쪽에서는 API 호출 한 번으로 끝난다. 이 차이를 만드는 것이 IaaS(Infrastructure as a Service)다. 컴퓨팅·스토리지·네트워크를 API 기반으로 제공해 데이터센터 운영 자체를 소프트웨어화하는 모델로, 하이브리드·멀티클라우드 전략과 규제 대응, 대규모 확장성을 요구하는 조직에서 기반 기술로 자리 잡았다.

IaaS는 가상머신, 베어메탈, 블록·오브젝트 스토리지, 가상 네트워크 등 인프라 리소스를 온디맨드로 제공하는 클라우드 서비스 모델이다. 사용자는 OS·미들웨어·런타임까지 직접 관리하고, 공급자는 하드웨어·하이퍼바이저·물리 네트워크·시설을 관리한다. API 중심 자동화, 탄력적 확장, 사용량 기반 과금, 멀티테넌시 격리가 핵심 특성이며 보안·운영은 공유 책임 모델의 적용 대상이다.

IaaS를 이루는 핵심 축

컴퓨팅 리소스 추상화 — VM, 베어메탈, GPU·FPGA 가속 옵션을 제공한다. 워크로드 특성에 따라 vCPU·메모리·로컬 NVMe·전용 호스트 조합을 선택할 수 있고, 이미지 템플릿과 커스텀 커널, 클라우드이닛·메타데이터로 부팅 시 구성을 자동화한다.

네트워크·보안 토폴로지 — VPC·서브넷, 라우팅, NAT·게이트웨이, 로드밸런서, 보안 그룹·방화벽 정책을 제공한다. 마이크로세그멘테이션으로 동서 트래픽을 격리할 수 있고, Direct Connect·ExpressRoute 같은 프라이빗 연결로 온프레미스와 저지연·고대역 하이브리드 구성을 지원한다.

스토리지 계층화 — 블록(저지연 IOPS), 오브젝트(대규모 내구성), 파일(NFS/SMB) 스토리지를 제공한다. 성능 계층, 암호화, 스냅샷·복제, 수명주기 정책을 적용할 수 있고 백업·DR 연계로 RPO·RTO 목표 달성에 유리하다.

관리·거버넌스 — IAM, 리소스 태그, 할당량, 결제·코스트 센터, 정책 엔진으로 조직 단위 통제를 실현한다. 계정·프로젝트 구조와 표준 이미지·골든 템플릿으로 환경 일관성을 확보한다.

자동화·확장 메커니즘 — API·SDK와 Terraform·CloudFormation·ARM·OpenTofu 같은 IaC로 선언적 프로비저닝이 가능하다. 오토스케일링, 헬스체크, 롤링 업데이트로 무중단 용량 관리를 실현한다.

요청이 리소스가 되기까지: 프로비저닝 절차

⤢✕

리소스 단위 요청은 아이템포턴트하게 설계하는 것이 원칙이며, 실패 시 보상 트랜잭션(롤백)을 수행한다. 권한·쿼터·용량·정책 위반 유형을 구분해 지수 백오프 재시도 정책을 적용한다.

실무에서 IaaS가 쓰이는 자리

하이브리드 DR/BCP에서는 온프레미스 주요 시스템의 스냅샷·복제를 클라우드로 비동기 전송하고, 장애 시 재해복구 런북과 IaC로 신속히 재기동한다. 워크로드에 따라 RTO 1~~4시간, RPO 분~~시간 단위 목표 달성이 가능하다.

데이터 분석·배치 처리에서는 스팟·프리엠티블 인스턴스 조합으로 비용 효율적인 대규모 처리를 수행하고, 오토스케일링 그룹과 큐 기반 워크로드로 탄력 운영한다. 컨테이너·서버리스와 혼합 구성해 파이프라인 유연성을 강화한다.

레거시 시스템 리호스트·리플랫폼에서는 신속한 리호스트로 운영 중단을 최소화한 뒤 단계적으로 리플랫폼(예: DB 관리형 이전)을 추진한다. 표준 이미지와 Ansible 같은 구성관리로 재현 가능한 배포 체계를 구현한다.

IaaS·PaaS·SaaS를 나란히 놓고 보면

모델	성능/유연성	확장성	일관성(환경)	안정성(가용/복구)	운영 편의
IaaS	높음(세밀 튜닝 가능)	높음(오토스케일/수평 확장)	중간(조직 표준화 필요)	높음(다중 AZ/DR 설계 전제)	중간(운영 책임 존재)
PaaS	중간~높음(제한 내 튜닝)	높음(플랫폼 내장)	높음(런타임 표준화)	높음(플랫폼 내장 복구)	높음(관리 추상화)
SaaS	낮음(튜닝 제한)	높음(서비스 사업자 책임)	높음(제품 수준 표준)	중간~높음(벤더 설계 의존)	매우 높음(최소 운영)

보안·운영에서 맞바꿔야 하는 것들

네트워크 세분화와 제로트러스트는 프라이빗 서브넷 기본화, 보안 그룹 최소 권한, L7 WAF 적용을 권장하지만 규칙 복잡도 증가에 따른 운영 부담이 따른다.

이미지·구성 표준화는 CIS 하드닝 이미지와 에이전트(EDR/모니터링)를 사전 포함한 골든 이미지를 쓰지만, 업데이트 주기 관리와 호환성 이슈가 생길 수 있다.

키·비밀 관리는 KMS·HSM과 시크릿 매니저를 사용하고 디스크·스냅샷 암호화를 기본값으로 적용하지만, 암호화 오버헤드와 키 순환 운영 비용이 존재한다.

비용·거버넌스는 태그 정책, 예산·알림, 예약·세이빙 플랜, 스팟 혼용으로 TCO를 최적화하지만 예약을 과다 구매하면 유연성이 줄어든다.

이식성·벤더 종속 문제는 IaC, 표준 API, 컨테이너화로 이동성을 확보하는 방향으로 대응하지만, 추상화 레이어가 성능·기능의 최대치 활용을 제한할 수 있다.

Terraform으로 IaaS VM을 배포하는 절차

전제조건은 Terraform 1.6 이상, AWS 계정 및 자격증명(Access Key/Secret) 설정, 기본 VPC 존재다.

# provider.tf
terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-2"
}

# main.tf
resource "aws_instance" "web" {
  ami                    = "ami-0c9c942bd7bf113a2" # 예시: Amazon Linux 2 (지역별 상이)
  instance_type          = "t3.micro"
  vpc_security_group_ids = [aws_security_group.web.id]
  user_data              = file("cloud-init.sh")
  tags = {
    Name        = "demo-web"
    CostCenter  = "team-a"
    Environment = "dev"
  }
}

resource "aws_security_group" "web" {
  name        = "sg-web"
  description = "allow http/ssh"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

AMI ID는 data source로 최신화를 자동화하고, 상태 비저장 워크로드는 오토스케일링 그룹으로 전환하며, SSH 대신 SSM 세션 매니저를 쓰는 편이 운영에 유리하다.

얻는 것과 지켜야 하는 것

IaaS를 도입하면 프로비저닝 리드타임이 주·월 단위에서 분·시간 단위로, 70~~90% 이상 단축될 가능성이 있다. 초기 투자(CapEx)를 절감하고 사용량 기반 과금으로 인프라 활용도를 30~~50% 개선할 수 있으며(워크로드·계약 조건에 따라 상이), 다중 가용영역 구성으로 99.9~99.99% 애플리케이션 가용성을 달성하고 자동 복구로 MTTR을 단축할 수 있다.

다만 이 모든 이점은 표준화된 자동화와 거버넌스를 전제로 한다. IaC와 표준 템플릿, 계정 구조, 모니터링 체계를 먼저 도입하고 점진적으로 확장하는 편이, 민첩성·확장성·비용 효율을 보안·일관성·복원력과 함께 얻는 길이다.