MDR 서비스 비용 2026, 보안관제 외주 전 견적·SLA·운영 기준

MDR 서비스 비용 산정을 위한 SOC 회의와 견적 비교 장면 — MDR 견적은 엔드포인트 단가보다 탐지 범위, 대응 SLA, 내부 운영 부담을 함께 봐야 한다.

MDR 서비스 비용을 검색하는 팀은 보통 보안관제 인력을 직접 뽑을지, 외부 MDR 업체를 붙일지, 기존 EDR 계약에 대응 서비스를 얹을지 사이에서 멈춘다.

견적서에는 월 구독료가 보이지만 실제 예산은 탐지 범위, 로그량, 사고 대응 SLA, 내부 담당자 시간, 온보딩 난이도에서 갈린다.

결론부터 말하면 MDR은 싼 관제 대행이 아니라 탐지와 대응 책임의 일부를 계약으로 나누는 서비스다.

따라서 구매팀은 단가표를 먼저 비교하지 말고 보안팀과 운영팀이 어떤 경보를 누가 닫을지부터 정해야 한다.

이 글은 MDR 제품 홍보가 아니라 보안관제 외주 전 견적, SLA, 내부 운영 기준을 맞추는 실무 가이드다.

핵심 요약

MDR 서비스 비용은 엔드포인트 수, 로그량, 24x7 대응 범위, 온보딩, 내부 remediation 시간이 합쳐진 값이다.
견적 비교 전에는 EDR, XDR, SIEM, 클라우드, ID, 이메일 중 어떤 신호를 MDR 범위로 넣을지 확정해야 한다.
SLA는 알림 속도보다 확인된 사고의 escalaton, containment 권고, 증거 패키지 품질을 기준으로 봐야 한다.
내부 SOC가 없으면 MDR이 유리하지만, 패치·계정잠금·서버격리 실행 책임까지 외주화되는 것은 아니다.

이 글이 필요한 사람

EDR은 있지만 야간과 주말 보안 경보를 볼 사람이 없는 보안팀
SOC를 직접 만들기 전 MDR 서비스 비용과 내부 인력 비용을 비교해야 하는 CISO
MDR, MSSP, SIEM 관제, XDR 서비스를 같은 견적처럼 받아 혼란스러운 구매 담당자
랜섬웨어, 계정 탈취, 클라우드 침해 대응 SLA를 계약 문장으로 고정해야 하는 운영팀
감사 대응을 위해 사고 대응 기록, case closure, 증거 패키지 기준이 필요한 컴플라이언스 담당자

MDR 서비스 비용은 보안관제 월정액보다 넓다

Microsoft Learn의 Defender Experts 문서는 전문가가 경보를 조사하고 대응 권고를 제공하는 관리형 탐지와 대응 흐름을 설명한다.

IBM과 Google Mandiant 설명도 공통적으로 탐지, 조사, 위협 헌팅, 사고 대응 지원을 MDR의 핵심 범위로 둔다.

이 말은 MDR이 단순 모니터링 화면 대행과 다르다는 뜻이다.

업체가 경보를 보고 티켓을 던지는 수준인지, 실제 침해 가능성을 조사해 containment 권고까지 닫는지에 따라 비용과 가치가 달라진다.

비용 묶음	견적서에 보이는 항목	숨어 있는 비용	확인 질문
기본 구독료	엔드포인트, 사용자, 서버, 클라우드 계정 단가	범위 밖 자산과 신규 계정 추가 비용	계약 중 자산 증가분 단가가 고정되는가
로그와 통합	EDR, XDR, SIEM, 클라우드 connector	로그 보존, 파서 튜닝, 중복 경보 정리	일일 ingest와 retention이 비용에 어떤 영향을 주는가
대응 SLA	24x7, severity별 응답 시간	전화 escalation, 한국어 지원, on-call 부담	확인된 사고와 단순 경보의 SLA가 다른가
온보딩	초기 구축, playbook 작성, tuning 기간	기존 에이전트 정리와 권한 승인	첫 30일 false positive 조정이 포함되는가
내부 인력	견적서에는 잘 안 보임	패치, 계정잠금, 서버격리, 법무 보고 시간	내부 owner가 월 몇 시간을 써야 하는가

이 조건이면 MDR 비용을 긍정적으로 검토할 만하다.

알림은 매일 쌓이고 야간 대응이 비어 있으며, 사고가 나면 내부팀이 원인 분석보다 경보 분류에 시간을 쓰는 경우다.

이 경우는 보류가 맞다.

자산 목록이 없고 EDR 배포율도 낮으며, 관리자 권한과 클라우드 로그 접근 권한을 누가 열어 줄지 정하지 못한 경우다.

MDR, MSSP, SIEM 관제, 내부 SOC를 분리해서 본다

MDR 서비스 비용 비교에서 흔한 실수는 서로 다른 서비스를 같은 열에 놓는 것이다.

전통 MSSP는 장비와 로그 관제 중심일 수 있고, SIEM 관제는 규칙과 이벤트 운영에 무게가 있다.

MDR은 탐지와 대응을 더 앞에 두지만, 실제 containment 실행 권한은 계약과 고객 환경에 따라 달라진다.

선택지	강한 지점	약한 지점	맞는 상황
내부 SOC	자산 맥락과 업무 우선순위 이해가 깊다	24x7 인력과 교육 비용이 크다	대형 조직, 규제 강한 산업, 장기 보안 투자 가능
MDR	전문가 탐지, 위협 헌팅, 대응 권고를 빠르게 붙인다	내부 remediation 실행은 여전히 고객 책임이다	중견 조직, 빠른 보안 성숙도 보강, 야간 공백 해소
MSSP 관제	방화벽, SIEM, 네트워크 장비 운영 경험이 많다	엔드포인트·ID·클라우드 침해 조사 깊이가 다를 수 있다	레거시 보안장비와 로그 운영 중심
SIEM 자체 운영	로그 소유권과 규칙 제어가 높다	룰 튜닝과 분석 인력 부담이 크다	보안 엔지니어와 탐지 엔지니어가 있는 팀
EDR 단독	엔드포인트 가시성을 빠르게 확보한다	경보를 사람이 해석하고 닫아야 한다	소규모 파일럿이나 내부 보안팀이 이미 있는 조직

구매팀은 제안서에 적힌 “24x7 monitoring”이라는 단어만 보면 안 된다.

질문은 더 구체적이어야 한다.

확인된 침해 의심 건에서 업체가 어떤 증거를 모으고, 어떤 containment를 권고하고, 내부팀이 몇 분 안에 어떤 결정을 내려야 하는지 물어야 한다.

견적 비교 전 범위를 고정한다

MDR 비용은 범위가 흔들리면 비교가 불가능하다.

A 업체는 엔드포인트 500대만 보고, B 업체는 클라우드 계정과 ID 로그까지 보며, C 업체는 SIEM 운영을 별도 과금하면 월 비용 숫자는 의미가 약해진다.

먼저 보호 대상과 신호 원천을 고정해야 한다.

범위 항목	포함하면 비용이 오르는 이유	빼면 생기는 위험	추천 기준
Endpoint	EDR 라이선스, 에이전트 배포, 경보 튜닝 필요	랜섬웨어와 악성 프로세스 탐지가 늦다	업무 PC와 중요 서버는 기본 포함
Identity	로그 통합과 계정 이상행위 분석 필요	계정 탈취와 MFA 우회 신호를 놓친다	SSO와 관리자 계정은 포함
Cloud	클라우드 감사 로그와 권한 분석이 필요	키 유출, 보안그룹 변경, workload 침해가 늦다	운영 계정과 prod project는 포함
Email	피싱 triage와 사용자 신고 흐름 필요	초기 침투 경로를 따로 조사해야 한다	사용자 수가 많으면 포함 검토
SIEM	로그량, 저장 기간, 규칙 튜닝 비용이 커진다	장기 상관분석과 감사 증거가 약하다	규제와 사고조사 필요성이 크면 포함

이 조건이면 endpoint 중심 MDR부터 시작해도 된다.

주요 침해 경로가 사용자 PC와 서버이고, 클라우드 로그 운영은 아직 성숙하지 않은 경우다.

반대로 SaaS와 클라우드가 핵심 매출 시스템이면 endpoint만 보는 MDR은 부족하다.

SLA는 알림 시간이 아니라 대응 품질로 쓴다

MDR 제안서에는 응답 시간이 자주 나온다.

하지만 “경보 접수 후 몇 분”이라는 숫자만으로는 부족하다.

CISA의 Incident Response Plan 기본 자료처럼 사고 대응은 탐지, 분석, containment, communication, 복구, 사후 검토가 이어지는 절차다.

SLA도 이 절차에 맞게 써야 한다.

SLA 항목	좋은 계약 문장	위험한 계약 문장	검증 방법
Triage	severity 기준과 false positive 처리 기준을 명시	모든 alert를 동일하게 접수한다고만 표현	샘플 case report를 요청
Escalation	전화, 티켓, 메신저, 담당자 fallback 지정	포털 알림만 제공	야간 테스트 연락망을 점검
Containment	계정잠금, host isolation, firewall block 권고 범위 명시	고객 책임이라고만 표현	실제 권고 예시와 승인 흐름 확인
Evidence	로그, 타임라인, IoC, 영향 자산, 조치 권고 포함	간단한 알림 제목만 제공	감사 제출 가능한 보고서 샘플 확인
Review	월간 tuning, 탐지 공백, 반복 경보 개선 포함	월간 통계만 제공	개선 action item owner 확인

이 경우는 비싼 MDR이어도 값어치가 낮다.

경보를 빨리 보내지만 내부팀이 무엇을 격리하고 어떤 계정을 잠가야 하는지 다시 분석해야 하는 경우다.

반대로 응답 시간이 조금 길어 보여도 조사 깊이, containment 권고, 증거 패키지가 좋으면 운영 비용이 줄어들 수 있다.

보안 프레임워크는 비용 기준을 세우는 데 쓴다

NIST Cybersecurity Framework는 식별, 보호, 탐지, 대응, 복구 관점으로 보안 활동을 정리한다.

CIS Controls v8은 자산 관리, 계정 관리, 감사 로그, 악성코드 방어, 사고 대응 같은 통제 항목을 제공한다.

MITRE ATT&CK은 공격 기법을 공통 언어로 정리해 MDR 탐지 범위와 threat hunting 질문을 맞추는 데 쓸 수 있다.

이 문서들을 견적서에 그대로 붙이라는 뜻은 아니다.

MDR 계약 범위를 프레임워크 언어로 바꾸면 빠진 비용이 보인다.

프레임워크 관점	MDR 비용 질문	운영팀 질문	빠지면 생기는 공백
Identify	자산과 계정 범위를 어디까지 보나	CMDB와 cloud inventory가 연결되나	보호 대상 밖 자산이 침해된다
Protect	차단 권고와 정책 개선까지 포함되나	계정잠금과 패치 owner가 있나	탐지만 하고 같은 사고가 반복된다
Detect	ATT&CK 기법별 탐지 공백을 보여주나	로그 품질과 보존 기간은 충분한가	침해 초기 신호를 놓친다
Respond	S1/S2 escalation과 증거 패키지가 있나	누가 containment를 승인하나	야간에 결정자가 없어 지연된다
Recover	복구 후 사후 보고와 개선안이 나오나	백업·재발방지 티켓이 닫히나	사고가 비용만 남기고 학습되지 않는다

CISA KEV는 MDR의 취약점 대응 우선순위와도 연결된다.

KEV 등재 취약점이 노출 자산에서 탐지되면 단순 취약점 티켓보다 사고 가능성 관점으로 올려야 한다.

내부 인력 비용을 반드시 더한다

MDR 서비스 비용에서 가장 자주 빠지는 값은 내부 인력 시간이다.

외부 전문가가 조사해도 서버 격리, 계정 정지, 방화벽 변경, 패치 적용, 고객 공지, 법무 보고는 내부 결정이 필요하다.

그래서 MDR을 샀는데도 보안팀이 편해지지 않는 조직이 생긴다.

내부 역할	월간 반복 업무	사고 때 업무	예산에 반영할 값
보안 리드	case review, playbook 승인, vendor meeting	severity 판단, containment 승인	월 8~24시간
플랫폼팀	agent 배포, 로그 connector, 권한 유지	서버 격리, 키 교체, 네트워크 차단	월 10~40시간
IT 운영	endpoint 배포율, 사용자 예외 처리	기기 격리, 계정 잠금, 재이미징	월 8~30시간
개발팀	취약 코드, secret, dependency 수정	hotfix, 배포, rollback	사고 빈도별 별도 산정
컴플라이언스	증거 보관, 감사 대응, 정책 업데이트	보고서 검토, 고객·기관 대응	월 4~16시간

이 조건이면 MDR이 내부 인력 비용을 줄인다.

경보 분류와 초기 조사에 쓰던 시간이 많고, 내부팀은 조치 실행과 시스템 맥락 판단에 집중할 수 있는 경우다.

이 조건이면 MDR을 사도 비용이 줄지 않는다.

조치 권한이 모두 수동 승인이고, 내부 owner가 불명확하며, 매 사건마다 vendor에게 환경 설명부터 다시 해야 하는 경우다.

실무 시나리오 1: 300명 SaaS 회사의 야간 보안 공백

직원 300명, 엔드포인트 500대, 클라우드 production 계정 5개인 SaaS 회사를 가정하자.

EDR은 이미 배포됐지만 보안담당자는 2명이고 야간 알림은 다음 날 오전에 본다.

이 조건이면 MDR은 직접 SOC 채용보다 현실적인 중간 단계가 된다.

견적 비교 기준은 엔드포인트 단가보다 야간 severity 1 escalation, cloud identity 로그 포함 여부, 월간 case review 품질이다.

보안팀은 vendor에게 host isolation 권고까지 맡기고, 실제 격리 명령은 내부 on-call이 승인하는 구조가 안전하다.

실무 시나리오 2: 제조사와 레거시 서버 환경

제조사는 공장망, 레거시 Windows, 오래된 서버, OT 장비가 섞이는 경우가 많다.

이 경우 endpoint agent를 모든 곳에 설치할 수 없고, 네트워크 sensor나 로그 수집 방식이 더 중요해질 수 있다.

MDR 서비스 비용은 단가보다 커버리지 공백에서 갈린다.

레거시 장비가 범위 밖이면 싼 견적처럼 보여도 실제 침해 경로를 보지 못한다.

이 조건이면 OT 보안 범위, 현장 대응, 벤더 접근 계정, 보완 통제 보고서를 별도 항목으로 견적에 넣어야 한다.

실무 시나리오 3: 클라우드 네이티브 서비스와 Kubernetes

Kubernetes와 managed cloud를 쓰는 팀은 endpoint만 봐서는 부족하다.

컨테이너 이미지, IAM role, Kubernetes audit log, secret scanning, cloud storage 권한이 사고 신호가 된다.

이 조건이면 MDR 범위에 cloud detection과 identity triage를 넣어야 한다.

반대로 cloud log ingest 비용이 너무 커지면 모든 로그를 무조건 보내기보다 production 계정, 관리자 활동, 공개 서비스 변경 이벤트부터 시작한다.

월간 리뷰에서는 탐지 공백, 중복 경보, playbook 변경, 최근 KEV와 실제 자산 노출 여부를 같이 본다.

실무 스켈레톤: MDR 비용 모델 YAML

아래 YAML은 견적서를 받기 전에 내부 범위와 비용 동인을 고정하기 위한 출발점이다.

# mdr-cost-model.yaml
# 목적: MDR 서비스 비용을 엔드포인트 단가가 아니라 범위, SLA, 로그, 내부 인력까지 합쳐 본다.
# 실제 가격은 벤더 견적서와 계약 조건을 확인해야 한다.

company_profile:
  employees: 320
  endpoints: 480
  cloud_accounts: 6
  critical_services:
    - customer-api
    - payment-console
    - identity-provider
  compliance:
    - privacy
    - financial-audit

coverage_scope:
  included:
    - endpoint_detection_and_response
    - identity_alert_triage
    - cloud_alert_triage
    - incident_escalation
    - monthly_threat_review
  excluded_or_extra:
    - full_siem_operation
    - digital_forensics_retainer
    - malware_reverse_engineering
    - onsite_response
    - ot_network_monitoring

cost_drivers:
  endpoint_count:
    basis: managed_endpoint_or_user
    owner: it-operations
  telemetry_volume:
    basis: daily_ingest_gb_and_retention_days
    owner: security-engineering
  response_sla:
    basis: severity_1_response_minutes_and_24x7_coverage
    owner: security-lead
  onboarding:
    basis: connector_count_playbook_count_tuning_period
    owner: platform-team
  internal_staff:
    basis: vendor_management_escalation_and_remediation_hours
    owner: ciso

acceptance_metrics:
  - confirmed_incident_escalation_time
  - false_positive_reduction_after_tuning
  - containment_action_owner_defined
  - monthly_case_review_delivered
  - evidence_package_ready_for_audit

핵심은 endpoint count 하나가 아니라 telemetry volume, response SLA, onboarding, internal staff를 같은 파일에 두는 것이다.

이 파일을 RFP나 vendor Q&A 앞부분에 붙이면 업체별 견적을 같은 기준으로 비교할 수 있다.

대응 SLA 정책 JSON 예시

아래 JSON은 실제 API 설정이 아니라 보안팀과 운영팀의 사고 대응 약속을 기계가 읽을 수 있는 형태로 정리한 예시다.

{
  "mdr_escalation_policy": {
    "severity_1": {
      "examples": ["active ransomware", "identity compromise", "public service takeover"],
      "vendor_response_target": "contract_defined_minutes",
      "internal_owner": "security-lead-on-call",
      "required_actions": ["call", "ticket", "containment recommendation", "evidence bundle"]
    },
    "severity_2": {
      "examples": ["suspicious lateral movement", "credential abuse", "critical endpoint detection"],
      "vendor_response_target": "contract_defined_hours",
      "internal_owner": "platform-on-call",
      "required_actions": ["case summary", "affected assets", "recommended containment"]
    },
    "monthly_review": {
      "required": ["case count", "false positive themes", "coverage gaps", "playbook changes"]
    }
  }
}

SLA 문서는 법적 계약 문장만으로 끝나면 현장에서 쓰이지 않는다.

severity별 예시, 내부 owner, required actions가 있어야 야간 사고 때 결정이 빨라진다.

견적 비교 점수 스크립트 예시

아래 Python 예시는 실제 가격을 예측하는 도구가 아니라 견적의 운영 가치를 비교하기 위한 검증용 스켈레톤이다.

#!/usr/bin/env python3
# mdr_quote_compare.py
# 목적: MDR 견적을 단가가 아니라 운영 적합성 점수로 비교한다.
# 실제 계약 판단에는 법무, 개인정보, 보안 책임자 검토가 필요하다.

from dataclasses import dataclass

@dataclass
class MdrQuote:
    name: str
    monthly_cost: int
    coverage_score: int
    sla_score: int
    integration_score: int
    evidence_score: int
    internal_hours_per_month: int

    def value_score(self) -> float:
        quality = self.coverage_score + self.sla_score + self.integration_score + self.evidence_score
        labor_penalty = self.internal_hours_per_month * 0.7
        cost_penalty = self.monthly_cost / 1_000_000
        return quality - labor_penalty - cost_penalty

quotes = [
    MdrQuote("vendor-a", 8500000, 22, 20, 16, 18, 18),
    MdrQuote("vendor-b", 6200000, 16, 14, 10, 11, 32),
]

for quote in sorted(quotes, key=lambda q: q.value_score(), reverse=True):
    print(quote.name, round(quote.value_score(), 1))

월 비용이 낮아도 내부 시간이 많이 들고 증거 품질이 낮으면 총비용은 올라간다.

반대로 월 구독료가 높아도 false positive가 줄고 case report가 감사에 바로 쓰이면 실무 비용은 낮아질 수 있다.

도입 전 체크리스트

보호 대상 자산을 endpoint, server, cloud account, identity, email, SIEM 로그로 나눈다.
현재 EDR 배포율과 agent health를 확인하고 누락 자산을 정리한다.
severity 1과 severity 2의 내부 승인자, 연락망, 야간 escalation 경로를 정한다.
vendor가 제공할 case report 샘플, 증거 항목, containment 권고 예시를 받는다.
월간 review에서 반복 경보, false positive, 탐지 공백, playbook 변경 항목을 요구한다.
클라우드와 ID 로그는 production, 관리자 활동, 공개 서비스 변경 이벤트부터 우선 포함한다.
법무와 개인정보 담당자에게 로그 전송 지역, 보존 기간, 재위탁, 사고 보고 범위를 확인한다.
사고 대응 모의훈련을 한 번 실행해 전화 escalation과 내부 조치 속도를 측정한다.
견적 비교표에는 월 구독료와 별도로 내부 인력 시간을 반드시 넣는다.

솔루션 비교 시 피해야 할 견적 함정

MDR 서비스 비용이 낮아 보이는 견적은 대개 범위가 좁거나 대응 책임이 약하다.

함정	겉으로 보이는 장점	실제 확인할 것	판단
엔드포인트 단가만 낮음	월 비용이 작아 보임	서버, 클라우드, ID, 로그 보존이 별도인지 확인	범위 밖 사고 비용을 더한다
24x7 문구만 강조	야간 대응이 되는 것처럼 보임	전화 escalation과 severity 기준 확인	알림 전송과 사고 대응을 구분한다
무제한 분석 표현	추가 비용이 없어 보임	forensic, malware analysis, onsite, retainer 범위 확인	계약 제외 항목을 문서화한다
SIEM 포함처럼 표현	통합 관제가 되는 것처럼 보임	ingest GB, parser tuning, retention, rule engineering 확인	로그 비용을 따로 산정한다
AI 탐지 강조	고급 탐지처럼 보임	ATT&CK 매핑, analyst review, false positive tuning 확인	모델보다 운영 결과를 본다