---
term: 'Infrastructure as a Service (IaaS)'
seoTitle: 'IaaS란? 개념, 책임 범위, PaaS·BaaS와의 차이'
headline: 'Infrastructure as a Service(IaaS)란?'
slug: infrastructure-as-a-service
category: cloud-architecture
shortDefinition: 'IaaS는 가상 머신, 스토리지, 네트워킹 같은 기본 컴퓨팅 리소스를 주문형으로 빌려 쓰고 사용한 만큼 과금하는 클라우드 모델입니다.'
relatedTerms:
  - paas-vs-baas
  - baas-vs-custom-backend
  - multi-tenant-cloud-hosting
  - cloud-vendor-lock-in
  - iaas-paas-baas-faas
contrastsWith:
  - paas-vs-baas
faq:
  - question: 'IaaS를 쉽게 설명하면 무엇입니까?'
    answer: '컴퓨터를 사는 대신 빌리는 것입니다. IaaS 제공업체가 데이터 센터, 물리 서버, 네트워킹을 소유하고, 사용자는 가상 머신, 스토리지, 네트워크를 시간 단위로 빌려 운영체제부터 그 위를 전부 관리합니다. 자본 지출이 운영 지출로 바뀌고, 프로비저닝은 구매 절차 대신 몇 분이면 끝납니다.'
  - question: 'IaaS에서 제공업체와 고객은 각각 무엇을 관리합니까?'
    answer: '제공업체는 물리 계층을 운영합니다. 데이터 센터, 서버, 스토리지 하드웨어, 네트워킹, 그리고 이를 임대 단위로 쪼개는 가상화입니다. 사용자는 하이퍼바이저 위의 전부를 운영합니다. 운영체제, 패치, 런타임, 미들웨어, 애플리케이션, 데이터입니다. 공동 책임 모델에 따라 제공업체는 클라우드를 보호하고, 사용자는 그 안에 넣은 것을 보호합니다.'
  - question: 'IaaS는 가상화와 같은 말입니까?'
    answer: '아닙니다. 가상화는 기반 기술이고, IaaS는 그 위에 세워진 비즈니스 모델입니다. 하이퍼바이저가 물리 머신을 가상 머신으로 쪼개고, IaaS는 이를 셀프서비스, 사용량 측정, 인터넷을 통한 종량제 제공으로 감쌉니다. 가상화는 자기 지하실에서도 돌릴 수 있습니다. 누군가 그것을 서비스로 빌려줄 때 IaaS가 됩니다.'
  - question: 'IaaS와 PaaS의 차이는 무엇입니까?'
    answer: '관리 경계선입니다. IaaS는 원시 인프라를 넘겨주며 OS부터 그 위는 전부 사용자의 일입니다. 최대 제어권, 최대 운영 부담입니다. PaaS는 OS, 런타임, 미들웨어까지 관리하므로 사용자는 애플리케이션 코드와 데이터만 가져옵니다. 제어권과 커스텀 스택이 필요하면 IaaS를, 운영 부담을 줄이고 더 빨리 출시하려면 PaaS를 선택하는 것이 좋습니다.'
  - question: 'IaaS의 주요 이점은 무엇입니까?'
    answer: '수요에 따라 확장되는 탄력적 용량, 몇 분 만의 프로비저닝, 선행 하드웨어 구매에서 종량제로의 전환, 데이터 센터를 짓지 않고도 확보하는 지리적 범위, 그리고 이중화와 재해 복구를 위한 내장 옵션입니다. 공통된 맥락은 인프라 결정이 되돌릴 수 있는 것이 된다는 점이며, 물리 하드웨어는 결코 그렇지 못했습니다.'
  - question: 'IaaS의 단점은 무엇입니까?'
    answer: '벤더가 건너뛰는 솔직한 목록입니다. 사용하지 않는 리소스가 유휴 상태로 돌 때 올라가는 요금, 데이터를 밖으로 옮길 때의 이그레스 비용, 클라우드 침해의 가장 큰 원인인 보안 설정 오류, 채용하거나 키워야 하는 운영 기술 인력, 그리고 독점적인 인접 서비스를 통한 벤더 종속입니다. IaaS는 하드웨어를 없애 주지만 운영은 없애 주지 않습니다.'
  - question: 'IaaS를 사용하지 말아야 할 때는 언제입니까?'
    answer: '더 높은 추상화가 이미 제공하는 것을 다시 만들기만 하게 될 때입니다. 사용자, 데이터, 스토리지, API로 이루어진 표준 애플리케이션 백엔드를 임대 VM 위에 손으로 조립하는 것은 PaaS나 BaaS가 몇 분 만에 제공하는 것을 몇 주에 걸쳐 차별화 없이 설정하는 일입니다. IaaS는 커스텀 스택, 레거시 마이그레이션, 규정 준수에 따른 제어에서 제값을 합니다. 표준 워크로드에서는 대개 비싼 길입니다.'
  - question: 'IaaS는 퍼블릭, 프라이빗, 하이브리드 중 무엇입니까?'
    answer: '세 가지 배포 형태가 모두 존재합니다. 퍼블릭 IaaS는 여러 고객을 공유 하드웨어에 모아 두는 표준적이고 가장 저렴한 형태입니다. 프라이빗 IaaS는 제어나 규정 준수를 위해 한 조직에 인프라를 전용으로 할당합니다. 하이브리드는 둘을 섞어 민감한 워크로드는 프라이빗에 두고 퍼블릭 용량으로 버스트합니다. 서비스 모델은 같고, 테넌시만 다릅니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'The NIST Definition of Cloud Computing (SP 800-145)'
    url: 'https://csrc.nist.gov/pubs/sp/800/145/final'
  - name: 'Infrastructure as a service (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Infrastructure_as_a_service'
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'Back4app documentation'
    url: 'https://www.back4app.com/docs'
cta:
  title: '인프라를 통째로 건너뛰기'
  text: 'Back4app은 원시 VM보다 네 단 위에 있습니다. 데이터베이스, 인증, 스토리지, API가 미리 구축된 관리형으로 제공되고, 커스텀 로직에는 Cloud Code가 있습니다. IaaS에서 몇 주를 들여 조립했을 것을 몇 분 만에, 무료로 얻을 수 있습니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-27'
translationKey: infrastructure-as-a-service
---

**IaaS는 가상 머신, 스토리지, 네트워킹 같은 기본 컴퓨팅 리소스를 주문형으로 빌려 쓰고 사용한 만큼 과금하는 클라우드 모델입니다.** [NIST 정의](https://csrc.nist.gov/pubs/sp/800/145/final)는 그 경계를 정확히 긋습니다. 제공업체가 물리 인프라를 제어하고, 사용자는 운영체제, 스토리지, 배포된 애플리케이션을 제어합니다. 클라우드 사다리의 맨 아래 단이며, 서버를 사는 대신 빌리는 것으로 바꾸는 단입니다.

## 핵심 요약

| 질문 | 답 |
| --- | --- |
| 무엇인가 | 주문형 가상 머신, 스토리지, 네트워크. 하드웨어를 공공요금처럼 쓰는 것 |
| 여전히 하는 일 | 운영체제부터 그 위 전부: 패치, 보안, 확장, 운영 |
| 해결하는 문제 | 물리 하드웨어의 구매, 랙 장착, 감가상각 |
| 과금 모델 | 리소스-시간 단위. 유연하지만 유휴 낭비에는 가차 없음 |
| 솔직한 단서 | IaaS는 하드웨어를 없애 주지만 운영은 없애 주지 않음 |

## IaaS 사용의 모습

IaaS의 대표적인 경험은 몇 분 만에 머신을 받는 것입니다. 그리고 그 뒤에는 머신이 늘 필요로 해 온 모든 일이 따라옵니다:

```bash
# 1분째: 머신을 빌립니다
$ cloud compute create --size medium --image ubuntu-24.04
   ✓ vm-7f3a running — 203.0.113.40

# 2분째부터: 나머지는 여전히 전부 사용자 몫입니다
$ ssh admin@203.0.113.40
$ apt update && apt upgrade          # 패치: 사용자 몫
$ apt install nginx postgresql       # 스택: 사용자 몫
$ ufw allow 443 && configure-tls…    # 보안: 사용자 몫
$ crontab -e                         # 백업, 로테이션, 모니터링: 사용자 몫
```

하드웨어는 몇 분 만에, 운영은 영원히. 이 거래가 모델의 전부입니다. 대비를 위해, 같은 "백엔드 띄우기" 목표를 사다리 맨 위에서 수행하면 다음과 같습니다. 인프라는 아예 드러나지 않습니다:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const note = new Parse.Object('Note');
note.set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched, no firewall rules
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final note = ParseObject('Note')
  ..set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
var note = Note()
note.text = "Shipped without touching a VM"
note.save { result in
  if case .success = result { print("saved — zero infrastructure managed") }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val note = ParseObject("Note").apply {
  put("text", "Shipped without touching a VM")
}
note.saveInBackground { e ->
  if (e == null) Log.d("Note", "saved — zero infrastructure managed")
}
```

## 누가 무엇을 관리하는가

```mermaid
flowchart LR
  accTitle: IaaS의 책임 분담
  accDescr: 제공업체는 데이터 센터, 물리 서버, 스토리지, 네트워킹, 가상화를 관리하고, 고객은 그 위의 운영체제, 런타임, 애플리케이션, 데이터를 관리합니다.
  subgraph P["제공업체가 운영"]
    p1["데이터 센터 · 물리 서버<br/>스토리지 · 네트워크 · 가상화"]
  end
  subgraph Y["사용자가 운영"]
    y1["OS · 패치 · 런타임<br/>미들웨어 · 앱 · 데이터"]
  end
  P --> Y
```

이 분담은 곧 보안 모델이기도 합니다. 제공업체는 *클라우드 자체*를 보호하고, 사용자는 그 *안*에 있는 모든 것을 보호합니다. 고객 쪽의 설정 오류, 즉 공개된 스토리지 버킷, 느슨한 방화벽 규칙, 패치되지 않은 시스템이 클라우드 침해의 가장 큰 원인입니다. 그래서 "사용자가 운영" 상자는 흔히 생각하는 것보다 훨씬 더 진지하게 다루어야 합니다.

## IaaS vs. PaaS vs. BaaS vs. 온프레미스

| 차원 | 온프레미스 | IaaS | PaaS | BaaS |
| --- | --- | --- | --- | --- |
| 구매/임대 대상 | 하드웨어 | 가상 인프라 | 관리형 플랫폼 | 관리형 백엔드 |
| 관리 대상 | 전부 | OS부터 그 위 | 앱 + 데이터 | 커스텀 로직 + 데이터 |
| 프로비저닝 시간 | 수 주–수 개월 | 몇 분 | 몇 분 | 몇 분, 백엔드 포함 |
| 비용 형태 | 자본 지출 | 리소스-시간당 | 인스턴스/등급당 | 무료 등급 + 요금제 |
| 제어권 | 전체 | 높음 | 중간 | 의도적으로 낮음 |
| 운영 부담 | 전체 | 높음 | 낮음 | 최소 |

"IaaS vs." 논의마다 되풀이되는 명확화 한 가지: [서버리스 모델](https://martinfowler.com/articles/serverless.html)은 같은 종류의 네 번째 열이 아닙니다. *관리 계층*이 아니라 *컴퓨팅 단위*(호출 단위)를 추상화하므로, 서버리스 플랫폼 자체가 그 아래에서는 IaaS 위에서 돌아갈 수 있습니다.

## 일반적인 사용 사례

- **리프트 앤 시프트 마이그레이션.** 기존 서버 애플리케이션이 거의 그대로 임대 VM으로 옮겨 갑니다. 스택은 같고, 하드웨어 교체 주기는 더 이상 없습니다.
- **커스텀 및 레거시 스택.** 관리형 플랫폼이 허용하지 않는 특이한 런타임, 라이선스 소프트웨어, OS 수준 튜닝.
- **규정 준수에 따른 제어.** 애플리케이션 아래에서 정확히 무엇이 실행되는지 알고 직접 설정해야 하는 규제 체계.
- **고성능 및 특수 워크로드.** GPU 플릿, 대규모 데이터 처리, 그리고 하드웨어 형태의 요구사항이 있는 모든 것.
- **재해 복구와 버스트 용량.** 유휴 하드웨어로 직접 보유하기에는 비용 부담이 너무 큰 대기 환경과 트래픽 급증 대비 여유 용량.

## IaaS 위에 구축해야 할까? 결정 매트릭스

| IaaS를 선택할 때 | 더 높은 단을 선택할 때 |
| --- | --- |
| OS 수준 제어나 커스텀 스택이 필요함 | 백엔드 요구가 표준적임(사용자, 데이터, 파일, API) |
| 역량 있는 운영 팀이 이미 있음 | 팀이 개발자로만 구성됨 |
| 기존 서버 워크로드를 그대로 이전함 | 처음부터 새로 만듦 |
| 규정 준수가 인프라 제어를 요구함 | 출시 속도가 다른 모든 고려사항을 압도함 |
| 지속적인 규모에서 원시 단가가 결정적임 | 워크로드가 작거나, 급증하거나, 탐색 단계임 |

기억해 둘 만한 패턴이 있습니다. IaaS는 기존 시스템을 *옮기는* 데는 거의 틀리지 않고, 표준적인 시스템을 *시작하는* 데는 거의 맞지 않습니다. VM 위에 손으로 조립하는 새 앱 백엔드는 몇 주짜리 작업이지만, 더 높은 단은 점심 전에 끝내 줍니다.

## 한계와 트레이드오프

- **운영은 여전히 사용자 몫입니다.** 패치, 보안 강화, 확장, 백업, 모니터링. 런북은 그대로 살아남고, 그 아래의 하드웨어만 바뀌었습니다.
- **요금 충격은 사용자가 물려받는 역량 문제입니다.** 유휴 인스턴스, 과대 VM, 잊힌 스토리지는 24시간 과금됩니다. 비용 관리는 지속적인 규율이 됩니다.
- **이그레스는 출구 통행료입니다.** 데이터는 무료로 들어오고 비용을 치르며 나갑니다. 데이터가 쌓일수록 조용히 [클라우드 벤더 종속](https://en.wikipedia.org/wiki/Vendor_lock-in)으로 누적되는 메커니즘입니다.
- **보안 설정 오류가 가장 흔한 실패 모드입니다.** 공동 책임 가운데 제공업체 쪽은 훌륭하게 관리됩니다. 침해는 압도적으로 고객 쪽에서 일어납니다.
- **기술 인력 세금.** 인프라를 잘 운영하려면 인프라를 잘 운영하는 사람이 필요합니다. 종량제 요금 페이지에는 적혀 있지 않은 채용 요건입니다.

## Back4app에서의 IaaS

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. IaaS와 비교하면 거래의 정반대 끝에 있습니다. OS 접근도, 인프라 제어도 없지만 런북도 없습니다. 위 다이어그램의 "사용자가 운영" 상자 전체가 플랫폼의 일이기 때문입니다. 특수 워크로드 하나에 원시 인프라가 필요한 팀은 BaaS 백엔드 옆에서 그것을 운영할 수 있고, 표준 앱 백엔드를 만드는 팀은 맨 아래 단을 통째로 건너뛸 수 있습니다. 그리고 스택이 오픈소스이므로, 나중에 사다리를 내려가는 일, 즉 직접 제어하는 IaaS 위에 플랫폼을 셀프 호스팅하는 일도 재작성이 아니라 실제 선택지로 남아 있습니다.