Terraform Cloud 비용 2026, HCP Terraform RUM·워크스페이스·정책 운영 기준

Terraform Cloud 비용 산정을 위한 HCP Terraform 워크스페이스와 RUM 비용 검토 장면 — Terraform Cloud 비용은 HCP Terraform의 RUM, 워크스페이스 구조, 원격 실행, 정책 운영을 같이 봐야 한다.

Terraform Cloud 비용을 검색하는 팀은 보통 “무료로 시작해도 되는지”, “RUM 과금이 얼마나 커지는지”, “GitHub Actions나 자체 CI로 돌리면 더 싼지”에서 멈춘다.

HashiCorp는 2024년 4월 22일부터 Terraform Cloud를 HCP Terraform으로 부르지만, 국내 검색자는 여전히 Terraform Cloud 비용이라는 표현으로 찾는 경우가 많다.

결론부터 말하면 비용 판단의 중심은 사용자 수보다 관리되는 리소스 수, 워크스페이스 쪼개기, 원격 실행 사용 여부, 정책과 비용 추정 기능의 운영 방식이다.

이 글은 Terraform Cloud를 단순 상태 저장소로 볼지, HCP Terraform을 플랫폼 표준으로 둘지 결정하기 위한 실무 비용 검토표다.

핵심 요약

HCP Terraform Free 조직은 공식 문서 기준 500 managed resources 제한이 있으므로 PoC와 소규모 팀에 먼저 맞다.
Essentials pay-as-you-go 예시는 managed resource 1개당 시간당 $0.0001359를 기준으로 계산하며, partial hour는 full hour로 처리된다.
1000 managed resources를 24시간 30일 유지하면 공식 예시 기준 시간당 $0.14, 월 $97.85 수준으로 계산된다.
워크스페이스, 정책, VCS, agent, cost estimation을 어떻게 쓰는지가 실제 운영비와 장애 리스크를 가른다.

이 글이 필요한 사람

Terraform state를 S3와 DynamoDB로 관리하다가 승인·감사·정책 기능 때문에 HCP Terraform을 검토하는 플랫폼팀
Free edition 500 managed resources 한도와 Essentials RUM 과금 사이에서 전환 시점을 정해야 하는 FinOps 담당자
워크스페이스가 너무 많아져 run queue, 권한, 정책 실패, 비용 추적이 뒤섞인 DevOps 리드
GitHub, GitLab, Azure DevOps 연동으로 자동 plan을 돌리되 production apply 승인을 분리해야 하는 보안팀
private network나 on-premises 자산 때문에 agent 실행 방식까지 비용에 넣어야 하는 인프라 운영팀

공식 가격표 핵심 숫자부터 본다

HashiCorp 공식 문서는 Free 조직이 remote state, remote runs, VCS 연결, private module registry, SSO, policy enforcement, run tasks 등을 포함하지만 500 managed resources로 제한된다고 설명한다.

Essentials edition의 pay-as-you-go 비용 산정 문서는 managed resource 1개당 시간당 $0.0001359라는 flat rate 예시를 제시한다.

같은 문서는 managed resource가 프로비저닝된 시점부터 destroy될 때까지 시간 단위로 계산되고, 부분 시간은 한 시간으로 처리되며, 해당 시간의 peak managed resource count가 비용 기준이라고 설명한다.

항목	공식 숫자·규칙	실무 해석	확인 위치
Free edition	500 managed resources 제한	PoC, 소규모 팀, 상태 공유 검증에는 충분하지만 production 표준화 전 한도를 먼저 본다	Plans and Features
Essentials PAYG 단가	managed resource 1개당 시간당 $0.0001359	사용자 수보다 state 안의 mode=managed 리소스 수가 비용 driver가 된다	Estimate HCP Terraform cost
1000 RUM 예시	1000 x $0.0001359 = 시간당 $0.14	작은 계정 여러 개보다 대형 workspace 한 곳의 peak가 더 중요할 수 있다	Estimate HCP Terraform cost
월 예시	$0.14 x 24 x 30 = 월 $97.85	월 예산표는 730시간 근사보다 공식 예시의 24 x 30 기준을 먼저 맞춘다	Estimate HCP Terraform cost
부분 시간	partial hour는 full hour 처리	짧은 테스트 workspace도 생성·삭제 시점과 peak hour를 기록해야 한다	Estimate HCP Terraform cost
3시간 변동 예시	1000→2000→1500 peak에서 $0.14, $0.27, $0.20	apply 중 리소스가 잠깐 늘어나는 blue-green 변경도 비용 설명 대상이다	Estimate HCP Terraform cost

이 조건이면 Free edition으로 시작해도 된다.

조직의 managed resources가 500개 아래이고, production apply보다 remote state와 VCS plan 검증이 먼저 필요한 경우다.

이 경우는 paid plan 검토가 빠르다.

프로젝트가 늘면서 500 managed resources를 넘기거나, 정책 set을 VCS로 관리하고, 감사 로그와 drift 대응까지 조직 표준으로 묶어야 하는 경우다.

Terraform Cloud 비용에서 RUM을 잘못 세면 예산이 틀어진다

HCP Terraform 비용 산정 문서는 Managed Resource 또는 Resources Under Management를 HCP Terraform이 관리하는 state file 안의 mode=managed 리소스로 정의한다.

null_resource와 terraform_data는 managed resource count에 포함하지 않는다고 공식 문서가 분리한다.

워크스페이스 화면의 resource count와 비용 산정용 RUM을 같은 값으로 단정하면 검토표가 흔들릴 수 있다.

검토 항목	비용에 미치는 영향	실무 확인	잘못된 판단
대형 module	count와 for_each로 리소스가 많이 펼쳐지면 RUM이 커진다	state list와 plan 결과에서 실제 managed 객체 수를 본다	module 1개라서 저렴하다고 보는 판단
임시 환경	짧은 시간도 full hour 기준으로 반영될 수 있다	preview 환경 생성·삭제 시각과 peak hour를 남긴다	일시적 테스트라 비용이 없다고 보는 판단
destroy 지연	destroy 전까지 과금 대상이 남을 수 있다	환경 종료 티켓에 terraform destroy 확인을 넣는다	서비스 종료만 하면 비용도 끝났다고 보는 판단
workspace 분리	workspace별 peak와 소유자가 보이면 비용 책임이 선명하다	app-env-component 규칙으로 owner를 붙인다	한 workspace에 모든 환경을 넣는 판단
Stacks 사용	workspace와 Stacks RUM이 함께 계산된다	반복 배포 단위와 RUM 합산을 월간 보고에 넣는다	Stacks가 별도 무료 영역이라고 보는 판단

실무 시나리오 1은 preview 환경이 많은 SaaS 개발팀이다.

PR마다 dev stack을 만들고 하루 뒤 지우는 구조라면 평균보다 peak hour와 destroy 누락이 비용 검토의 핵심이 된다.

실무 시나리오 2는 네트워크, 애플리케이션, 모니터링 구성이 한 root module에 묶인 전통 인프라팀이다.

이 팀은 RUM 자체보다 권한과 blast radius가 문제이므로 workspace를 networking-prod, app-prod, monitoring-prod로 나누는 편이 비용 설명과 승인 흐름에 유리하다.

워크스페이스 구조가 비용과 권한을 동시에 만든다

HashiCorp의 workspace 문서는 HCP Terraform workspace가 local working directory와 같은 목적을 가지지만 configuration, variables, state, run history를 HCP Terraform 안에서 관리한다고 설명한다.

또한 workspace는 role-based access의 주요 구성요소이고, 특정 workspace에 variable 관리나 run 권한을 다르게 줄 수 있다고 설명한다.

따라서 Terraform Cloud 비용 검토는 “몇 달러인가”보다 “어느 팀이 어떤 workspace 비용을 만들었는가”를 먼저 볼 때 정확해진다.

구조 선택	장점	비용 리스크	추천 조건
환경별 workspace	dev, stage, prod 비용과 승인 흐름을 분리한다	workspace 수가 늘면 정책·변수 관리가 많아진다	팀별 배포 주기와 승인 책임이 다른 조직
컴포넌트별 workspace	networking, app, monitoring 변경 blast radius가 작다	run trigger와 dependency 설계가 필요하다	공유 네트워크와 앱 배포 책임이 분리된 조직
대형 monolith workspace	초기 전환이 쉽고 전체 plan을 한 번에 본다	RUM peak와 apply 위험이 한 곳에 몰린다	PoC 또는 작은 단일 서비스
Stacks 중심 구조	반복 인프라를 scale 단위로 표준화한다	반복 구조의 RUM 합산을 놓치기 쉽다	동일 패턴을 여러 계정·지역에 펼치는 조직

이 조건이면 workspace를 쪼갠다.

팀별 승인자, variable 접근 권한, production 변경 창구, RUM 예산 owner가 서로 다르면 workspace를 나눠야 비용과 권한이 같이 보인다.

이 경우는 보류한다.

아직 module 경계가 불안정하고 shared resource dependency가 정리되지 않았다면 workspace 분리보다 state 구조와 owner부터 정리한다.

원격 실행, local mode, agent를 비용표에 따로 둔다

HCP Terraform remote operations 문서는 원격 실행이 disposable virtual machines에서 Terraform runs를 수행한다고 설명한다.

같은 문서는 remote execution이 Sentinel policy enforcement, cost estimation, notifications, version control integration 같은 고급 기능을 가능하게 한다고 설명한다.

반대로 execution mode를 Local로 바꾸면 workspace는 remote backend처럼 동작하지만 remote execution에 의존하는 기능은 꺼질 수 있다.

private 또는 on-premises 인프라를 다루면 HCP Terraform agents를 검토해야 하며, agent는 private network에서 outbound 연결로 변경을 처리하는 방식이다.

실행 방식	비용 관점	보안 관점	운영 판단
Remote	플랫폼 기능을 쓰는 표준 비용으로 본다	변수와 state를 중앙에서 통제한다	조직 표준 배포와 승인 흐름에 맞다
Local	별도 CI worker 비용과 운영 부담을 더해야 한다	비밀값과 실행 로그가 CI 쪽으로 퍼질 수 있다	단순 state backend만 필요할 때 제한적으로 쓴다
Agent	agent 수와 실행 환경 운영비를 같이 본다	public ingress 없이 private 환경을 제어한다	on-premises, protected enclave, enterprise network에 맞다
Self-hosted Enterprise	SaaS 구독과 별도로 인프라·업그레이드 비용이 생긴다	데이터 위치와 통제권이 높다	강한 규제와 자체 운영 역량이 있을 때만 본다

비용만 보면 local execution이 싸 보일 수 있다.

하지만 CI runner, secret 관리, 로그 보존, 승인 UI, 정책 실패 처리, state 접근 감사까지 더하면 remote 표준화가 더 낮은 총비용이 되는 경우가 많다.

agent는 private network 때문에 필요한 선택지이지 비용 절감 만능 카드가 아니다.

agent host 운영, network egress, 작업 실패 재시도, 권한 위임 기준을 예산표에 같이 넣어야 한다.

비용 추정과 정책은 옵션이 아니라 변경 통제 장치다

HCP Terraform cost estimation 문서는 비용 추정 기능이 기본으로 꺼져 있으며 조직 Settings에서 Cost Estimation을 열고 전체 workspace에 대해 enable해야 한다고 설명한다.

활성화되면 plan과 apply 사이에 비용 추정 단계가 보이고, 총 monthly cost와 monthly delta 및 추정되지 않은 리소스를 확인할 수 있다.

공식 문서는 비용 추정이 AWS, GCP, Azure의 주요 리소스를 지원하지만 예측 불가능한 사용량 기반 항목이나 미지원 리소스는 빠질 수 있다고 경고한다.

policy enforcement 문서는 Free edition이 최대 5개 정책을 담는 policy set 1개를 포함한다고 설명한다.

Standard와 Premium edition에서는 policy set을 VCS repository에 연결하거나 version을 만들어 관리할 수 있다고 설명한다.

통제 장치	공식 기준	운영 기준	실패 시 비용 영향
Cost estimation	Settings > Cost Estimation에서 enable	월 증가분과 unestimated resource를 PR 승인 전에 본다	예상보다 큰 cloud bill이 apply 뒤에 발견된다
Sentinel 정책	cost delta를 tfrun import로 검사 가능	$100 초과 월 증가분은 승인 흐름으로 보낸다	작은 리소스 변경이 반복되어 예산을 넘긴다
OPA·Terraform policy	workspace policy enforcement에서 결과 확인	보안 태그, region, owner label 누락을 막는다	비용 owner 없는 리소스가 계속 생긴다
Manual apply	plan confirm 단계에서 사람이 승인	prod workspace는 auto apply를 기본 금지한다	잘못된 merge가 곧바로 production 비용과 장애를 만든다
Workspace lock	run 시작을 일시적으로 막는다	대형 migration 기간에는 lock과 window를 기록한다	동시 변경으로 state와 예산 설명이 꼬인다

이 조건이면 비용 추정을 반드시 켠다.

개발자가 직접 cloud resource를 추가하고, production apply 전에 월 증가분을 리뷰해야 하며, 예산 owner가 workspace별로 나뉘어 있는 경우다.

이 경우는 숫자를 과신하지 않는다.

사용량 기반 DB, 네트워크 전송, managed service 부가 기능처럼 추정되지 않는 항목이 많으면 cost estimation은 승인 보조 신호로만 둔다.

VCS와 권한은 비용 폭주를 막는 보안 장치다

VCS 연결 문서는 GitHub, GitLab, Bitbucket, Azure DevOps 같은 provider와 연결하면 commit과 pull request에 맞춰 run과 speculative plan을 시작할 수 있다고 설명한다.

동시에 HCP Terraform의 VCS 사용자 권한이 실제 repository 접근 수준을 결정할 수 있으므로, 지정 계정의 권한이 비용과 보안 posture에 영향을 준다고 경고한다.

권한 문서는 organization, project, workspace scope의 permission이 additive로 계산되며, least privilege 원칙을 권장한다.

또한 repository main branch에 merge할 수 있는 사람이 workspace run을 간접적으로 queue할 수 있다고 설명한다.

권한 지점	비용 위험	보안 위험	실무 조치
VCS merge 권한	불필요한 리소스가 main merge와 함께 생성된다	비인가 변경이 plan 흐름으로 들어온다	prod branch protection과 reviewer를 비용 owner와 맞춘다
Workspace admin	execution mode와 variable 변경으로 비용 기준이 바뀐다	sensitive variable 접근과 apply 권한이 집중된다	admin은 최소 인원으로 두고 변경 로그를 검토한다
Project 권한	여러 workspace 비용을 한 팀이 보지 못한다	팀 경계가 흐려져 책임자가 사라진다	project별 FinOps owner를 둔다
Auto apply	작은 PR이 곧바로 비용 증가로 이어진다	보안 정책 실패 전 실행 위험이 커진다	prod는 manual apply와 policy 결과 확인을 기본값으로 둔다
외부 연동	bot이나 run task가 과도한 실행을 유발한다	외부 시스템 권한 위임이 커진다	권한 위임 조건과 유효 시간을 점검한다

실무 시나리오 3은 VCS 접근 권한과 HCP Terraform 권한이 따로 관리되는 조직이다.

플랫폼팀은 workspace apply 권한만 보지 말고 main branch merge 권한자 목록까지 월간 비용 리뷰에 붙여야 한다.

실무 시나리오 4는 Slack이나 ChatOps로 apply를 요청하는 조직이다.

이 경우 bot 권한은 사용자 권한보다 넓게 동작할 수 있으므로, 승인자와 실행 권한을 분리하고 prod workspace에서는 사람이 최종 apply를 확인해야 한다.

도입 전 비용 산정 순서

현재 Terraform state를 모두 모아 workspace 후보와 owner를 적는다.
각 state에서 mode=managed 리소스 수를 산출하고 Free edition의 500 managed resources 한도와 비교한다.
preview, dev, stage, prod 환경의 생성·삭제 주기와 peak hour 가능성을 기록한다.
HCP Terraform Usage report에서 projects, workspaces, Stacks, applies, RUM, concurrency, agents 제한을 확인한다.
Plan & Cost Estimation을 켜야 하는 workspace와 아직 Local mode가 맞는 workspace를 분리한다.
production workspace는 manual apply, policy set, cost delta 기준을 먼저 정한다.
private network 접근이 필요한 workspace는 agent host 비용과 운영 owner를 별도 줄로 잡는다.
월간 리뷰에서는 RUM 증가, destroyed resource 누락, policy failure, unestimated resources를 같이 본다.

첫 달에는 예산 정확도보다 누가 어떤 workspace 비용을 만들었는지 보는 것이 더 중요하다.

두 번째 달부터는 RUM 증가율, workspace owner 누락, cost delta warning 반복 항목을 개선 backlog로 넘긴다.

운영 리스크와 보류 기준

Terraform Cloud 비용이 아깝다는 이유로 local state나 임시 CI runner에 남는 secret을 방치하면 보안 사고 비용이 구독료보다 커질 수 있다.

반대로 모든 workspace를 HCP Terraform으로 올리면서 권한과 정책을 정하지 않으면 비용만 중앙화되고 책임은 흐려진다.

다음 조건 중 2개 이상이면 유료 전환을 보류하고 구조부터 정리한다.

managed resources 수를 workspace별로 집계하지 못한다.
production apply 승인자와 비용 owner가 다르다.
VCS main branch 권한자와 HCP Terraform workspace 권한자가 서로 관리되지 않는다.
cost estimation 결과의 unestimated resources를 해석할 사람이 없다.
agent가 필요한 private environment인데 agent host 운영 책임자가 없다.
destroy 완료 확인 없이 preview 환경을 반복 생성한다.

다음 조건이면 유료 전환이나 계약 검토를 진행한다.

500 managed resources 한도를 넘거나 곧 넘을 가능성이 높다.
RUM, workspace, policy failure, apply 승인 기록을 감사 근거로 남겨야 한다.
prod 변경에 cost delta 기준을 붙여 예산 owner가 승인해야 한다.
여러 팀이 같은 Terraform state를 만져 owner와 권한을 분리해야 한다.
private network를 다뤄야 해서 HCP Terraform agent 구조가 필요하다.

검토용 정책·비용 skeleton

아래 파일은 실제 배포용이 아니라 FinOps와 플랫폼팀이 같은 용어로 비용을 검토하기 위한 skeleton이다.

# hcp-terraform-cost-governance.yaml
# 목적: Terraform Cloud 비용을 사용자 수가 아니라 RUM, 워크스페이스, 정책, 실행 방식으로 관리한다.
# 실제 계약 조건과 plan 기능은 HashiCorp 공식 문서와 조직 계약서를 기준으로 재확인한다.

organization:
  name: example-infra
  cost_owner: platform-finops
  security_owner: cloud-security
  review_cycle: monthly

rum_controls:
  free_edition_limit: 500
  essentials_payg_rate_per_resource_hour_usd: 0.0001359
  partial_hour_rule: bill_partial_hour_as_full_hour
  peak_hour_rule: use_peak_managed_resources_in_each_hour
  exclusions_to_check:
    - null_resource
    - terraform_data

workspace_policy:
  naming: app-env-component
  split_rule:
    - networking-prod
    - app-prod
    - monitoring-prod
  execution_mode_default: remote
  local_mode_exception_requires:
    - owner
    - reason
    - rollback_plan

approval_gates:
  monthly_delta_warning_usd: 100
  production_auto_apply: false
  friday_change_freeze: true
  private_network_requires_agent_review: true

monthly_review:
  collect:
    - usage_report_projects_workspaces_stacks_applies
    - managed_resource_peak_by_workspace
    - run_queue_delay
    - policy_failures
    - cost_estimate_delta
  decisions:
    - merge_or_split_workspaces
    - move_local_runs_back_to_remote
    - retire_destroyed_resources
    - adjust_policy_enforcement_level

cost estimation을 켠 workspace는 월 증가분 기준을 정책으로 묶어야 승인 기준이 흔들리지 않는다.

# cost-delta-guard.sentinel
# 목적: HCP Terraform 비용 추정 결과의 월 증가분이 내부 기준을 넘으면 승인 흐름을 강제한다.
# 공식 문서의 tfrun cost_estimate 예시를 조직 기준에 맞춰 변형한 검토용 skeleton이다.

import "tfrun"
import "decimal"

monthly_delta_limit = decimal.new(100)
delta_monthly_cost = decimal.new(tfrun.cost_estimate.delta_monthly_cost)

main = rule {
  delta_monthly_cost.less_than_or_equals(monthly_delta_limit)
}

Usage report를 내려받을 수 있다면 workspace별 peak managed resources를 월간 검토표로 만드는 작은 스크립트부터 시작한다.

#!/usr/bin/env python3
# hcp_terraform_cost_review.py
# 목적: Usage report에서 내려받은 workspace별 RUM snapshot을 월간 검토표로 정리한다.
# 입력 CSV는 workspace,peak_managed_resources,hours,owner,environment 컬럼을 가진다고 가정한다.

import csv
from decimal import Decimal

RATE = Decimal("0.0001359")
REVIEW_THRESHOLD_USD = Decimal("50")

with open("hcp_terraform_usage.csv", newline="", encoding="utf-8") as f:
    rows = list(csv.DictReader(f))

for row in rows:
    peak = Decimal(row["peak_managed_resources"])
    hours = Decimal(row["hours"])
    estimate = (peak * RATE * hours).quantize(Decimal("0.01"))
    if estimate >= REVIEW_THRESHOLD_USD or row["environment"] == "prod":
        print(row["workspace"], row["owner"], row["environment"], f"${estimate}", "review")

자주 묻는 질문

Terraform Cloud 비용과 HCP Terraform 비용은 같은 의미인가요?

공식 명칭은 HCP Terraform이지만, 기존 Terraform Cloud 검색 의도는 같은 hosted Terraform workflow 비용 검토로 이해하면 된다.

Free edition 500 managed resources면 어디까지 가능한가요?

소규모 PoC와 팀 단위 state 공유에는 충분할 수 있지만, production workspace가 늘거나 Stacks까지 쓰면 RUM 한도와 권한 기준을 먼저 다시 계산해야 한다.

Essentials 비용은 사용자 수로 계산하나요?

공식 비용 예시는 managed resource를 시간당 계산하므로, 사용자 수보다 state 안의 mode=managed 리소스 수와 peak hour가 먼저다.

Cost estimation을 켜면 실제 cloud bill과 같아지나요?

아니요, 공식 문서도 일부 리소스와 사용량 기반 항목은 추정되지 않을 수 있다고 설명하므로 승인 보조 신호로 두는 편이 안전하다.

Local execution으로 바꾸면 비용이 줄어드나요?

HCP Terraform 기능 비용만 보면 줄어 보일 수 있지만 CI worker, secret 관리, 로그 보존, 정책 누락 리스크를 더하면 총비용이 커질 수 있다.

HCP Terraform agent는 언제 검토하나요?

private network, on-premises, protected enclave처럼 SaaS runner가 직접 접근하면 안 되는 환경에서 outbound 방식으로 실행해야 할 때 검토한다.

출처와 확인일

HashiCorp Developer — What is HCP Terraform? (확인일: 2026-07-27)
HashiCorp Developer — Plans and Features - HCP Terraform (확인일: 2026-07-27)
HashiCorp Developer — Estimate HCP Terraform cost (확인일: 2026-07-27)
HashiCorp Developer — HCP Terraform workspaces (확인일: 2026-07-27)
HashiCorp Developer — Workspace settings in HCP Terraform (확인일: 2026-07-27)
HashiCorp Developer — Remote operations in HCP Terraform (확인일: 2026-07-27)
HashiCorp Developer — Manage and view runs in HCP Terraform (확인일: 2026-07-27)
HashiCorp Developer — Cost estimation overview for HCP Terraform (확인일: 2026-07-27)
HashiCorp Developer — HCP Terraform policy enforcement overview (확인일: 2026-07-27)
HashiCorp Developer — Permission model in HCP Terraform (확인일: 2026-07-27)
HashiCorp Developer — Connect to VCS providers (확인일: 2026-07-27)
HashiCorp Developer — HCP Terraform agents (확인일: 2026-07-27)

위 출처는 2026-07-27 기준으로 확인했으며, HCP Terraform plan, RUM 단가, Free edition 한도, policy 기능, agent 조건은 제품 업데이트와 계약 조건에 따라 바뀔 수 있다.

이 글은 일반적인 인프라 비용·보안 운영 검토 자료이며, 실제 구매와 계약 판단은 HashiCorp 공식 문서, 조직 계약 조건, 보안 책임자 검토를 기준으로 최종 확인해야 한다.

Tech in Depth tnals1569@gmail.com

피드백 보내기

이글루 홈캠 vs 파인뷰 홈캠 비교: 화각, 보안, 가격까지 완벽 분석하기

- 8월 29, 2025

글 읽기

이 블로그 검색