요즘은 바야흐로 클라우드의 시대입니다. 서버로 삼을 컴퓨터를 조립하고, 그 컴퓨터에 서버 환경을 구축하던 시대는 이제 지났습니다. 클라우드 콘솔에 로그인해 폼을 클릭하면 몇 분 안에 서버가 생깁니다. 그런데 이런 서버를 실수 없이 똑같은 설정으로 100개, 200개 만들어야 하는 상황에서는 자동화가 중요해집니다. 프로비저닝(provisioning)은 애플리케이션을 실행하는 데 필요한 컴퓨팅 자원(서버, 네트워크, 스토리지, 데이터베이스 등)을 준비하고 구성하는 과정입니다. 이 글에서는 프로비저닝의 개념, 세 가지 방식, IaC(Infrastructure as Code)의 원리, 그리고 프로비저닝과 구성 관리의 차이를 살펴봅니다.
클라우드의 등장
서버라는 것이 처음 등장했을 때는 아주 당연하게도 매우 비싸고 크고 에너지를 많이 잡아먹는 거대한 컴퓨터였다. 한 사람이나 몇 명의 사람들이 같이 이용하는 그런 서비스를 넘어 수백, 수천만명이 동시에 사용하는 서비스라는 개념을 실현하려면 인터넷도 인터넷이지만 기존처럼 소프트웨어를 소비자들의 컴퓨터로 공급하는 방식으로는 분명한 한계가 존재했다. 그렇기 때문에 하나의 컴퓨터에서 필요한 서비스를 제공하고 모든 수요가 그 컴퓨터로 향하도록 하는 구조가 탄생했고, 그 모든 수요를 감당할 만큼 엄청난 연산을 수행할 수 있는 컴퓨터가 바로 서버였다. 이러한 서버를 온프레미스(On-premise) 서버라고 부르는데, 온프레미스 서버는 기업이 자체적으로 보유한 공간에 서버 컴퓨터를 직접 설치해 운영되었다.
온프레미스 서버는 여러가지 장점을 가지고 있다. 물리적 기기 자체가 기업의 공간 안에 있기 때문에 사용 권한, 보안 정책, 데이터를 직접 관리할 수 있다. 그만큼 안전하며 시스템을 입맛대로 자유롭게 커스터마이징할 수 있다. 그러나 애초에 서버의 역할을 수행할 수 있는 컴퓨터가 흔치 않고 또 비싸기 때문에 초기 비용이 많이 들고 유지보수와 장애 대응도 직접 해야 한다. 무엇보다 결정적인 단점으로 꼽히는 것은 서비스에 대한 수요 자체가 일정하지 않다는 것이다. 수요가 일정하지 않다는 것이 무슨 뜻인지 이해하려면 실제 서비스를 통해 이해해보는 것이 직관적이다.
*Figure 1: 투자 문제를 클라우드 컴퓨팅으로 해결할 수 있다.*
서비스를 포함해 컴퓨터를 통해 어떤 작업을 하기 위해서는 CPU, GPU, 네트워크, 메모리 등 컴퓨터의 여러가지 요소를 활용해야 한다. 이를 추상적인 관점에서 바라보면 어떤 행동을 하기 위해 컴퓨터가 가진 자원을 끌어다쓰는 것이기 때문에 서비스를 제공하기 위한 컴퓨터의 여러가지 요소를 한데 묶어 컴퓨팅 자원(Computing Resource)이라 부른다. 위 그래프의 가로 축은 시간, 세로 축은 자원의 효율성(Resource Utilization), 즉 컴퓨팅 자원을 낭비하거나 부족한 일 없이 얼마나 효율적으로 잘 썼는지를 나타내는 지표다. 자원의 효율성이 낮아질수록 컴퓨팅 자원을 효율적으로 사용하지 못했다는 것이고 이는 곧 실제 수요에 비해 서버가 제공하는 컴퓨팅 자원이 더 많다는 뜻이다. 온프레미스 서버의 경우 제공할 수 있는 컴퓨팅 자원이 고정되기 때문에 그래프 상에서 수평선의 형태로 그려진다. 실제 수요가 낮으면 자원의 효율성도 낮아지고 실제 수요가 높으면 자원의 효율성도 높아진다.
이렇게 보면 자원의 효율성이 높으면 무조건 좋을 것이라 생각하기 쉽지만 그렇지 않다. 온프레미스 서버에서 제공할 수 있는 컴퓨팅 자원(자원의 효율성)의 최대치를 넘어서는 수요가 들어오게 되면,
- a) 연산이 끝나지 않아서 서비스에 악영향을 끼치거나
- b) 연산이 늦게 끝나거나 퍼포먼스가 낮아지거나
- c) 위와 같은 상황을 막기 위해 컴퓨팅 자원에 더 많이 투자해야 한다.
서비스에 악영향을 끼치는 것을 막기 위해 c)를 선택하면 그만큼 더 많은 수요가 몰리는 상황에서도 안정적으로 서비스를 제공할 수 있겠지만 그만큼 평상시 사용되지 않는 컴퓨팅 자원이 늘어나고 기업 입장에서는 그만큼 돈을 낭비하고 있는 셈이다. 예매 서비스처럼 아주 짧은 특정 시간만 수요가 집중되는 서비스라면 전체 시간 중 극히 일부를 위해 나머지 시간을 상당량의 컴퓨팅 자원을 낭비하게 되는 것이다.
프로비저닝이란
클라우드 컴퓨팅은 바로 이 문제를 해결하기 위해 등장했다. 컴퓨팅 자원을 제공하는 측과 소비하는 측을 분리하면, 더 나아가 컴퓨팅 자원을 필요할 때만 필요한 만큼 빌린다면 실수요에 맞게 유동적으로 컴퓨팅 자원을 조절해 낭비를 줄일 수 있다. NIST의 클라우드 컴퓨팅 정의에서도 "신속하게 프로비저닝되고 해제될 수 있는 공유 컴퓨팅 자원 풀"이 핵심 특성으로 명시된다(Ruparelia, 2016). 프로비저닝은 애플리케이션이 동작하는 데 필요한 컴퓨터, 운영체제, 스토리지, 네트워크, 데이터베이스 등의 인프라 자원을 할당하고 준비하는 과정이다. 그래서 일반적인 프로비저닝 작업에는 애플리케이션이 돌아갈 기반이 되는 하드웨어를 인스턴스의 개념으로 만들고, 실행 환경과 코드가 저장될 스토리지 볼륨을 만들고 연결하는 등의 과정이 들어간다. 프로비저닝은 수동, 자동화, 셀프서비스라는 세가지 방식으로 할 수 있다.
세 가지 프로비저닝 방식
수동 프로비저닝 (ClickOps)
클라우드 제공자의 콘솔에서 폼을 클릭해 자원을 생성한다. 사용자 입장에서는 시작하기 쉽지만 여러 문제가 있다. 수동으로 진행하기 때문에 같은 환경을 정확히 재현하기 어렵고, 단계를 빠뜨리거나 설정을 잘못 입력하기 쉽다. 같은 과정을 직접 수십번 반복하는 것도 비현실적이고 누가 언제 무엇을 변경했는지 추적하기도 어렵다.
자동화 프로비저닝 (IaC)
그래서 클라우드 제공자들은 코드를 통해 인프라를 정의하는 방법을 제공한다. 인프라를 코드로 정의하고 도구가 자동으로 자원을 생성하는 방식을 코드로서의 인프라, IaC(Infrastructure as Code)라고 한다. 코드는 원하는 인프라 상태를 선언적으로 기술한다. 도구가 현재 상태와 원하는 상태를 비교해 필요한 변경을 적용한다.
주요 IaC 도구는 다음과 같다.
| 도구 | 특징 |
|---|---|
| Terraform | 선언적 HCL 언어, 멀티 클라우드 지원 |
| OpenTofu | Terraform의 오픈소스 포크 (Linux Foundation) |
| Pulumi | Python, Go, TypeScript 등 범용 언어 사용 |
| AWS CloudFormation | AWS 전용, YAML/JSON 기반 |
| Ansible | 절차적 방식, 구성 관리에도 사용 |
셀프서비스 프로비저닝 (On-Demand)
셀프서비스 방법에서는 자동화 프로비저닝을 기반으로 개발자가 직접 인프라를 요청할 수 있는 플랫폼을 구축한다. 자주 사용되는 인프라를 구현하는 코드는 템플릿 형태로 제공되고 개발자는 IaC 코드를 작성하지 않고도 미리 정의된 템플릿에서 필요한 자원을 선택해 즉시 생성할 수 있다. 이 방식은 운영팀의 병목을 제거한다. 개발자가 새 스테이징 환경이 필요할 때 운영팀을 기다리지 않아도 되고, 보안 측면에서도 유리하다. 클라우드 접근 키가 플랫폼 내부에만 머물고 개발자 개개인에게 배포되지 않기 때문이다.
IaC의 핵심 원칙
원하는 최종 상태를 기술하는 선언적declarative 방식과 수행 단계를 순서대로 기술하는 절차적imperative 방식의 구분, 같은 코드를 몇 번 실행해도 결과가 같은 멱등성idempotency, 실제 인프라가 코드에 정의된 상태에서 벗어났는지 확인하는 드리프트(drift) 감지 등 IaC의 기반이 되는 핵심 원칙들은 별도의 게시글에서 자세히 다룬다. 프로비저닝 관점에서 핵심은, 이 원칙들 덕분에 같은 코드로 같은 환경을 몇 번이고 재현할 수 있다는 점이다.
프로비저닝 vs. 구성 관리
프로비저닝과 구성 관리는 다르지만 밀접하게 연관된 개념이다. 흔히 프로비저닝을 구성 관리까지 포함하는 개념으로 생각하기 쉽지만 자원을 생성하는 것까지만 프로비저닝이다. 자원이 만들어진 이후의 작업은 구성 관리의 몫이다.
| 항목 | 프로비저닝 | 구성 관리 |
|---|---|---|
| 목적 | 자원 생성 | 자원 설정 |
| 시점 | 인프라 생명주기 초기 | 프로비저닝 이후 |
| 도구 | Terraform, Pulumi | Ansible, Chef, Puppet |
| 예시 | EC2 인스턴스 생성 | 패키지 설치, 사용자 계정 생성 |
실제로는 두 작업이 겹치는 경우가 많다. Ansible은 프로비저닝과 구성 관리를 모두 처리할 수 있다. 그러나 개념적으로 분리해 생각하면 각 단계의 책임이 명확해진다.
DevOps와 프로비저닝
DevOps 관점에서 프로비저닝 자동화는 배포 파이프라인의 핵심 구성 요소다. Kim et al.(2021)은 DevOps의 핵심 목표를 계획된 작업을 프로덕션으로 빠르게 흘려보내는 것으로 정의한다. 수동 프로비저닝은 이 흐름의 병목이 된다. 프로비저닝이 자동화되면 새 스테이징 환경을 분 단위로 빠르게 만들 수 있고 그러면서도 개발, 스테이징, 프로덕션 환경이 동일한 코드로 생성되어 합의된 환경에서 서비스를 테스트할 수 있다. 또한 코드를 통해 프로비저닝이 이루어지기 때문에 모든 인프라 변경이 Git 커밋으로 기록되며, 인프라 코드가 있으면 전체 환경을 빠르게 재구성 할 수 있다. 뿐만 아니라 불필요한 자원을 코드로 관리해 자동으로 삭제할 수도 있다.
예를 들어 AWS에서는 AWS 관리 콘솔을 통해 사용자가 직접 콘솔에서 클릭하며 프로비저닝을 할 수도 있지만 AWS CLI를 통해 일반적인 CLI 프로그램을 사용하듯이 컴퓨팅 자원을 관리할 수 있게 해준다. AWS CloudFormation을 통해 자사의 컴퓨팅 자원을 IaC로 프로비저닝하고 관리할 수 있도록 하며 AWS CDK(Cloud Development Kit)를 통해 개발자들에게 익숙한 프로그래밍 언어인 TypeScript, Python 등으로 CloudFormation을 생성할 수 있게 해주기도 한다. 이 외에도 GCP(Google Cloud Platform)나 Microsoft Azure 등 다른 회사의 클라우드도 사용해야 한다면 멀티 클라우드 IaC를 지원하는 Terraform을 사용하기도 한다.
출처
- Kim, G. et al. (2021) The DevOps handbook: how to create world-class agility, reliability, & security in technology organizations. Second edition. Portland, OR: IT Revolution Press.
- Ruparelia, N.B. (2016) Cloud Computing. Cambridge, MA: The MIT Press.
- Spacelift (2025) What is Cloud Provisioning? Process, Types & Best Practices. Available at: https://spacelift.io/blog/cloud-provisioning (Accessed: 23 July 2026).
- AWS (2025) What is Infrastructure as Code? Available at: https://aws.amazon.com/what-is/iac/ (Accessed: 23 July 2026).