DSPM 도입 비용

DSPM 도입 비용을 검색하는 팀은 보통 데이터가 어디 있는지보다 누가 고칠지 몰라서 멈춰 있습니다.

민감 데이터가 S3, 데이터 웨어하우스, SaaS, 개발 백업에 흩어져 있으면 단순 스캔 도구 가격만으로 예산을 설명하기 어렵습니다.

이 글은 DSPM을 새 보안 유행어로 다루지 않고 데이터 발견, 분류, 권한 위험, 교정 운영의 비용 항목으로 나눕니다.

공개 단가는 Amazon Macie와 Google Sensitive Data Protection처럼 스캔량을 가격표로 제시한 서비스의 숫자를 기준선으로 사용합니다.

핵심 요약

DSPM 도입 비용은 플랫폼 라이선스보다 데이터 저장소 수, 스캔 GB, SaaS 커넥터, 권한 교정 owner, 감사 리포트 범위에서 커집니다.
Amazon Macie 공개 예시는 S3 bucket 월 $0.10, object 100K개당 $0.01, 민감 데이터 스캔 GB당 $1.00 구조를 보여줍니다.
Google Sensitive Data Protection은 저장 데이터 검사에서 1GB 무료 후 1GB~50TB 구간 US$1.00/GB 기준을 제시합니다.
전사 DSPM은 바로 사기보다 2주 파일럿으로 민감 데이터 위치, 공개 노출, 과도 권한, 교정 ticket 처리량을 먼저 재야 합니다.

이 글이 필요한 사람

클라우드 데이터 유출 위험을 줄이려는 보안 책임자.
DLP, CNAPP, CSPM, SIEM 견적 사이에서 DSPM 범위를 정해야 하는 구매 담당자.
개발·분석 조직이 만든 shadow data를 실제로 찾아야 하는 플랫폼팀.
개인정보, 결제정보, 고객 계약서가 어느 저장소에 남아 있는지 감사를 받아야 하는 보안 운영팀.
스캔 비용보다 교정 backlog가 더 클 수 있다는 점을 예산 문서에 넣어야 하는 FinOps 담당자.

DSPM은 무엇을 사는 비용인가

IBM은 DSPM을 여러 클라우드 환경과 서비스에서 민감한 데이터를 식별하고 취약성과 규정 미준수 위험을 평가하는 기술로 설명합니다.

핵심은 서버나 네트워크보다 데이터를 먼저 보고, 데이터가 어디에 있으며 누가 접근할 수 있는지를 계속 확인하는 방식입니다.

Wiz는 DSPM과 CSPM을 나누어 CSPM은 인프라 상자를 보고 DSPM은 그 안의 데이터를 본다고 설명합니다.

이 구분은 견적서에서도 그대로 중요합니다.

비용 항목	무엇을 세는가	예산을 키우는 조건	보류할 조건
데이터 발견	저장소, table, bucket, SaaS repository	계정·리전·SaaS가 많고 owner가 불명확합니다.	단일 클라우드의 몇 개 bucket만 확인합니다.
민감 정보 분류	PII, payment data, secret, 계약서, 로그 field	정규식만으로 안 되고 문맥 분류가 필요합니다.	이미 DLP 정책과 분류 체계가 안정적입니다.
권한 위험 분석	public exposure, 과도 권한, 외부 공유, dormant user	IAM과 데이터 권한이 따로 움직입니다.	권한 체계가 단순하고 감사 로그가 충분합니다.
교정 운영	ticket, owner, exception, SLA, evidence	발견 후 고치는 사람이 없습니다.	월 1회 수동 점검으로 충분합니다.

DSPM 도입 비용은 네 줄 중 어느 줄을 제품으로 해결하고 어느 줄을 내부 운영으로 남길지 정하는 과정입니다.

제품 가격이 낮아도 교정 owner가 없으면 발견된 위험은 backlog로 쌓이고, 그 backlog가 다음 분기 인력 비용이 됩니다.

공식 가격표로 보는 스캔 비용 기준선

많은 DSPM 전문 벤더는 공개 가격표 대신 견적 문의 방식을 씁니다.

그래서 예산 초안은 공개 단가가 있는 민감 데이터 발견 서비스로 스캔량의 하한을 먼저 계산하는 편이 안전합니다.

공식 출처	공개 숫자	어떤 비용인가	DSPM 예산 해석
Amazon Macie	S3 bucket 월 $0.10	bucket inventory와 monitoring 기준선입니다.	계정과 bucket이 많으면 탐색 비용이 먼저 생깁니다.
Amazon Macie	object 100K개당 $0.01	automated discovery 대상 object monitoring입니다.	작은 파일이 많은 data lake는 object 수를 따로 셉니다.
Amazon Macie	자동 발견 150GB 예시 월 $151.50	15 buckets, 10,000,000 objects, 150GB 검사 예시입니다.	스캔 GB가 커질 때 월 비용이 어떻게 움직이는지 보여줍니다.
Amazon Macie	targeted 200GB 추가 예시 월 $351.50	자동 발견 150GB에 targeted job 200GB를 더한 예시입니다.	전수 스캔을 자주 돌리면 단가보다 스캔 범위가 예산을 밀어 올립니다.
Google Sensitive Data Protection	저장 데이터 검사 1GB 무료 후 US$1.00/GB	1GB~50TB 구간 storage inspection입니다.	초기 baseline scan의 단가 기준으로 쓸 수 있습니다.
Google Sensitive Data Protection	hybrid inspection 1GB 초과 US$3.00/GB	외부 source 데이터를 검사하는 사용량 기준입니다.	멀티클라우드나 온프레미스 연결은 더 비싼 축으로 봅니다.
Google Sensitive Data Protection	content transformation 1GB 초과 US$2.00/GB	비식별 처리까지 하는 경우의 별도 비용입니다.	분류만 할지 masking까지 할지 예산을 나눕니다.

이 숫자는 DSPM 전문 제품의 최종 견적이 아닙니다.

다만 데이터 스캔량이 100GB인지 10TB인지 모르는 상태에서 연간 견적을 승인하지 않게 만드는 기준선입니다.

Microsoft Purview 가격 페이지도 자산, request, processing unit, GB, text message처럼 기능별 과금 단위를 분리해 보여줍니다.

DSPM 견적서에는 이런 단위를 벤더별로 같은 표에 맞춰 넣어야 합니다.

DSPM 도입 비용을 세 줄로 나누기

첫 줄은 기술 사용량입니다.

여기에는 bucket 수, object 수, 검사 GB, 데이터베이스 table 수, SaaS repository 수가 들어갑니다.

두 번째 줄은 운영 사용량입니다.

여기에는 ticket 수, 예외 승인 수, owner 지정률, 교정 SLA, 감사 증거 보관 기간이 들어갑니다.

세 번째 줄은 조직 변경 비용입니다.

여기에는 data owner 지정, 접근권한 정책 변경, 개발팀 스캔 예외 처리, 보안팀 triage 시간이 들어갑니다.

줄	예산 항목	측정 방법	실패 신호
기술 사용량	스캔 GB와 connector 범위	파일럿에서 2주간 검사량을 기록합니다.	vendor demo 화면만 보고 전사 스캔을 약속합니다.
운영 사용량	교정 ticket과 예외 승인	critical finding 10개를 실제 owner에게 배정합니다.	발견은 많은데 닫힌 ticket이 없습니다.
조직 변경	data owner와 접근 정책	부서별 권한 회수 동의와 일정표를 만듭니다.	보안팀만 책임지고 데이터 조직이 빠집니다.

이 조건이면 데이터 저장소가 많아도 owner와 분류 체계가 이미 있으면 플랫폼 비용만 크게 잡아도 됩니다.

이 경우는 shadow data가 많고 owner가 없으면 제품보다 1차 정리 인력과 정책 변경 비용을 먼저 잡아야 합니다.

DLP, CNAPP, CSPM과 겹치는 비용을 정리한다

DSPM은 DLP를 대체하지 않습니다.

DLP는 데이터 반출 행위를 막는 쪽에 가깝고, DSPM은 민감 데이터의 위치와 접근 위험을 먼저 찾는 쪽에 가깝습니다.

CNAPP와 CSPM도 겹치지만 시작점이 다릅니다.

CNAPP는 cloud workload와 posture를 넓게 보고, DSPM은 데이터가 노출될 수 있는 경로와 권한 맥락을 더 세밀하게 봅니다.

기존 투자	겹치는 부분	DSPM이 추가로 물어야 할 질문	중복 구매 방지 기준
DLP	민감 정보 탐지와 정책 위반	데이터가 저장된 위치와 owner를 알고 있는가?	반출 차단만으로 저장 위치 파악이 안 되면 DSPM 검토.
CNAPP	클라우드 설정 위험과 워크로드 노출	노출된 storage 안에 실제 민감 데이터가 있는가?	data context 없이 위험 점수가 같으면 DSPM 검토.
CSPM	public bucket, encryption, network exposure	민감하지 않은 bucket과 주민번호 table을 구분하는가?	정책 위반만 나열되면 DSPM 검토.
SIEM	로그 수집과 경보 분석	경보가 실제 고객 데이터 노출과 연결되는가?	로그량만 늘고 데이터 owner가 없으면 DSPM 검토.

기존 CNAPP에 DSPM 기능이 일부 포함되어 있으면 새 제품보다 기능 범위 확장을 먼저 문의합니다.

기존 DLP가 endpoint와 SaaS 반출만 보고 있다면 저장소 discovery와 permission graph는 별도 요구로 남깁니다.

2주 파일럿으로 비용을 검증하는 순서

클라우드 계정, storage bucket, 데이터베이스, SaaS repository 목록을 한 장으로 모읍니다.
PII, payment data, access key, 계약서, 로그 field 같은 민감 정보 기준을 10개 이하로 줄입니다.
처음에는 metadata discovery와 권한 위험 확인만 켜고 전수 content scan은 보류합니다.
상위 위험 저장소 20개만 골라 제한된 GB 범위로 민감 데이터 scan을 실행합니다.
finding마다 data owner, system owner, 보안 owner를 따로 지정합니다.
critical finding 10개를 실제 ticket으로 만들어 5영업일 안에 닫히는지 봅니다.
false positive와 exception 사유를 기록해 다음 스캔 정책에서 줄입니다.
공식 공개 단가와 벤더 견적 단위를 같은 표에 넣고 12개월 총액으로 환산합니다.

파일럿의 목표는 멋진 dashboard가 아니라 월 스캔량, 교정 속도, 중복 tool 범위를 숫자로 얻는 것입니다.

2주 안에 owner 배정이 안 되는 finding이 많다면 전사 구매 전에 조직 책임 구조를 고쳐야 합니다.

실무 시나리오로 보는 구매 판단

실무 시나리오 1: S3 data lake에 고객 파일이 많은 조직

이 조직은 Amazon Macie 같은 기본 발견 서비스로 bucket과 object 수, 150GB 수준 자동 발견 비용을 먼저 재야 합니다.

그 다음 DSPM 전문 제품이 필요한지는 cross-account 권한, 외부 공유, data owner mapping, ticket 연동이 실제로 필요한지로 판단합니다.

실무 시나리오 2: SaaS와 데이터 웨어하우스가 섞인 분석 조직

이 조직은 S3 단가만으로는 부족합니다.

Google Sensitive Data Protection의 hybrid inspection처럼 외부 source 검사 단가가 더 높은 축을 따로 놓고 connector 견적을 받아야 합니다.

실무 시나리오 3: 이미 DLP와 CNAPP가 있는 금융·커머스 조직

이 조직은 새 DSPM을 바로 사기보다 기존 DLP가 반출을 보고 CNAPP가 노출을 보는 사이의 빈칸을 찾습니다.

빈칸이 민감 데이터 위치, data owner, 권한 경로라면 DSPM 파일럿이 맞고, 단순 policy tuning이면 기존 tool 개선이 먼저입니다.

운영 리스크를 비용표에 넣는 법

CrowdStrike 설명처럼 DSPM은 데이터 위치, 보안 상태, 접근자를 계속 감시하는 역할을 합니다.

하지만 계속 감시한다는 말은 계속 판단할 사람이 필요하다는 뜻입니다.

Finding triage: critical, high, medium 기준을 정하지 않으면 alert fatigue가 생깁니다.
Owner mapping: 데이터 owner가 없으면 보안팀 ticket이 닫히지 않습니다.
Exception policy: 연구·개발용 복제 데이터는 만료일이 없으면 shadow data가 됩니다.
Connector 운영: SaaS 권한 변경과 cloud 계정 추가가 tool 범위 밖으로 빠질 수 있습니다.
Evidence 보관: 감사 때 보여줄 before, after, 승인, 삭제 증거가 필요합니다.
비식별 처리: masking이나 치환 처리를 함께 하면 scan 비용과 작업 시간이 늘어납니다.

이 조건이면 DSPM license보다 운영 리스크 예산이 더 큽니다.

보안팀 1명이 300개 finding을 보고 있는데 데이터 owner가 0명인 구조라면 제품 추가 구매가 문제를 해결하지 못합니다.

실무 스켈레톤: 예산 범위 파일

아래 YAML은 실제 배포 설정이 아니라 DSPM 견적을 같은 기준으로 비교하기 위한 범위 파일입니다.

공식 콘솔과 벤더 견적서의 단위가 다르면 이 파일의 항목명을 먼저 맞춘 뒤 금액을 입력합니다.

# dspm-cost-scope.yaml
# 목적: DSPM 견적을 민감 데이터 위치, 스캔량, 권한 위험, 교정 책임으로 나눠 비교한다.
# 실제 단가는 공식 가격표와 벤더 견적서를 확인한 뒤 원화 환산과 부가세를 별도로 더한다.

estate:
  cloud_accounts: 18
  object_storage_tb: 42
  warehouse_tb: 12
  pii_tables: 160
  saas_repositories: 9

scan_plan:
  phase_1_inventory: "metadata and access review only"
  phase_2_sensitive_scan_gb: 500
  phase_3_continuous_sampling: "high risk buckets and production tables"

cost_inputs:
  amazon_macie_bucket_month_usd: 0.10
  amazon_macie_object_unit_usd_per_100k: 0.01
  amazon_macie_scan_usd_per_gb: 1.00
  google_storage_inspection_usd_per_gb_1gb_to_50tb: 1.00
  google_hybrid_inspection_usd_per_gb_over_1gb: 3.00

approval_gate:
  buy_now_if: "민감 데이터가 멀티클라우드와 SaaS에 흩어지고 과도한 권한 교정 owner가 없다"
  defer_if: "S3 한두 곳만 점검하면 되고 Macie 같은 기본 스캔으로 충분하다"
  require_pilot_if: "데이터베이스, 오브젝트 스토리지, SaaS, 분석 파이프라인을 동시에 연결해야 한다"

아래 계산 예시는 공개 단가가 있는 스캔 비용의 하한을 보는 용도입니다.

전문 DSPM 제품의 플랫폼 구독료, connector 비용, 구축비, 교육비는 별도 항목으로 더해야 합니다.

# dspm_scan_budget.py
# 공식 공개 단가를 입력해 스캔량이 월 예산에 미치는 영향을 먼저 본다.
# 벤더 플랫폼 라이선스, 커넥터 비용, 컨설팅 비용은 별도 행으로 더한다.

def macie_monthly(bucket_count: int, object_count: int, scanned_gb: int) -> float:
    bucket_cost = bucket_count * 0.10
    object_cost = (object_count / 100000) * 0.01
    scan_cost = max(scanned_gb - 1, 0) * 1.00
    return bucket_cost + object_cost + scan_cost


def google_storage_scan(scanned_gb: int) -> float:
    billable = max(scanned_gb - 1, 0)
    return billable * 1.00

scenarios = {
    "macie_15_buckets_150gb": macie_monthly(15, 10_000_000, 150),
    "macie_targeted_500gb": macie_monthly(15, 10_000_000, 650),
    "google_storage_500gb": google_storage_scan(500),
}

for name, usd in scenarios.items():
    print(name, round(usd, 2))