SOAR는 왜 아직도 쓰이나요? 이미 한계에 도달한 자동화의 현실

By PLURA

A. 기술 때문이 아니라, ‘기대·제도·책임 구조’ 때문입니다.

SOAR(Security Orchestration, Automation and Response)는
등장 당시 “사람 없는 자동 대응 보안”을 약속했습니다.

하지만 실제 SOC 현장에서는
자동 차단이 거의 사용되지 않고,
대부분 조사 보조 도구로만 운영되고 있습니다.

그럼에도 SOAR가 여전히 도입·유지되는 이유는
효과 때문이 아니라, 버리지 못하는 구조에 있습니다.

1️⃣ “자동 대응”이라는 기대가 만든 관성

SOAR는 이름부터가 문제였습니다.

  • Orchestration
  • Automation
  • Response

이 세 단어는
마치 사람의 판단을 대체할 것처럼 들립니다.

하지만 현실은 다릅니다.

  • SOAR에는 자체 판단 능력이 없습니다
  • 위협의 진위 여부를 결정하지 못합니다
  • 사람이 만든 Playbook을 그대로 실행할 뿐입니다

그럼에도 SOAR는
“이미 도입한 자동화 플랫폼”이라는 이유로
계속 유지됩니다.

“우리는 이미 자동화 체계를 갖췄다”
라는 조직적 자기 합리화가 작동하기 때문입니다.

즉, SOAR는
실제 효과보다도
도입했다는 사실 자체가 주는 심리적 안정감으로 유지되는 경우가 많습니다.

2️⃣ ISMS·감사 대응용 ‘자동화 증빙’

SOAR가 현장에서 가장 많이 쓰이는 이유 중 하나는
감사 대응입니다.

  • “자동 대응 체계가 있습니까?”
  • “침해 사고 시 절차는 자동화돼 있습니까?”

이 질문에 대해
SOAR는 아주 좋은 답변이 됩니다.

실제로 대응을 자동으로 하느냐와 무관하게,
“SOAR를 운영 중”이라는 문장은
보고서에 쓰기 좋은 문구이기 때문입니다.

Q9에서 IPS·NDR이
‘보험 장비’로 남는 것과
정확히 같은 구조입니다.

즉, 현장 실효성보다
증빙과 설명 가능성이 먼저 작동하는 것입니다.

3️⃣ 자동 차단은 위험해서 쓰지 못합니다

SOAR가 한계에 도달한 결정적 이유는
자동 차단(Active Response)을 감당할 수 없기 때문입니다.

  • 탐지의 출발점은 대부분 확률적 알림
  • 오탐 가능성이 항상 존재
  • 자동 차단은 곧 가용성 침해

그래서 실제 SOC에서는:

  • 계정 잠금 ❌
  • 서버 격리 ❌
  • 네트워크 차단 ❌

대신:

  • 로그 수집
  • 사용자·자산 정보 조회
  • 평판 조회
  • 티켓 생성
  • 알림 전달

같은 조사 자동화(Enrichment)만 사용됩니다.

즉, SOAR는
‘Response’가 아니라
‘자동 심부름 도구’로 축소됩니다.

이 표현이 거칠게 들릴 수 있지만,
현장에서는 오히려 가장 정확한 설명에 가깝습니다.

자동 대응을 약속했지만
실제로는 사람이 더 빨리 판단할 수 있도록
자료를 모아주는 역할에 머무르는 경우가 대부분이기 때문입니다.

4️⃣ SOAR는 문제를 해결하지 못하고 구조를 복잡하게 만듭니다

SOAR 자체에는 데이터가 없습니다.

그래서 SOAR가 의미를 가지려면 반드시:

  • SIEM (로그 집합소)
  • TI (위협 인텔리전스)
  • EDR / AD / CMDB
  • 메일 / 티켓 / 자산 관리 시스템

같은 외부 시스템이 필요합니다.

그 결과 구조는 다음과 같이 확장됩니다.

NDR/보안 장비 도입 → 오탐 증가 →
SIEM 도입 → SOAR 도입 →
여전히 사람 판단 필요

SOAR는 문제를 줄이기보다
운영 복잡성과 비용을 증폭시키는 역할을 하게 됩니다.

이것이 많은 조직에서
SOAR가 “도입은 했지만, 적극 사용하지 않는 이유”입니다.

겉으로 보면 자동화가 늘어난 것 같지만,
실제로는 연동 포인트와 유지보수 항목,
Playbook 관리 부담,
오탐 예외 처리 규칙이 계속 쌓이면서
운영자는 더 복잡한 환경을 떠안게 됩니다.

5️⃣ Gartner 하이프 사이클이 보여준 결론

Gartner 하이프 사이클에서
SOAR는 이미 기대의 정점(Peak)을 지나
현실 조정 국면에 들어섰습니다.

이는 기술이 나쁘다는 의미가 아니라,
약속했던 역할을 수행하지 못했다는 의미입니다.

  • 사람 없는 자동 대응 ❌
  • 완전한 자율 SOC ❌

이제 SOAR는
“없어도 안 되고, 있어도 해결되지 않는”
애매한 위치에 놓여 있습니다.

즉, SOAR는
보안의 중심 엔진이 되지 못했고,
현실에서는 보조 자동화 계층으로 재정의되고 있습니다.

6️⃣ 그래서 중요한 것은 ‘자동화 그 자체’가 아니라 ‘판단 가능한 맥락’입니다

SOAR의 한계를 보면
문제는 자동화 부족이 아니라
판단 가능한 데이터와 맥락의 부족이라는 점이 더 분명해집니다.

사람이 실제로 대응하려면
단순 알림이 아니라 다음이 필요합니다.

  • 이 행위가 왜 이상한지
  • 어떤 계정과 자산이 연결되는지
  • 직전과 이후에 어떤 행위가 있었는지
  • 실제 침해 흐름인지, 단순 오탐인지

즉, 중요한 것은
Playbook 수를 늘리는 것이 아니라
사람이 빠르게 판단할 수 있는 실시간 맥락을 제공하는 것입니다.

이 지점에서 PLURA-XDR은
SOAR처럼 여러 시스템 위에 또 하나의 자동화 층을 덧붙이기보다,
호스트·계정·애플리케이션 로그를 실시간으로 연결 분석하여
판단에 필요한 맥락 자체를 더 빨리 제공하는 접근에 가깝습니다.

보안 자동화의 핵심은
사람을 없애는 것이 아니라,
사람이 더 정확하고 빠르게 결정할 수 있게 만드는 것이어야 합니다.

정리하면

SOAR가 아직도 사용되는 이유는
효과적이어서가 아니라,
버리지 못하는 기대와 구조 때문입니다.

  • 자동화를 기대했고
  • 감사에 필요했고
  • 대안이 마땅치 않았으며
  • 이미 돈을 썼기 때문입니다.

하지만 보안에서 가장 위험한 상태는
“잘 작동하지 않는 자동화”입니다.

사람을 대체하기 위해 존재하는 것이 아니라,
사람이 판단할 수 있는 시간을 벌기 위해 존재해야 합니다.

자동 대응을 못 하는 자동화라면,
그 역할과 위치를 다시 정의해야 할 시점입니다.

그리고 그 재정의의 출발점은
더 많은 Playbook이 아니라,
실시간으로 맥락을 보여 주는 분석과
실행 주체를 정확히 통제할 수 있는 구조여야 합니다.

함께 읽을 글

SOAR와 SIEM이 왜 기대만큼 작동하지 못하는지에 대한
보다 구조적인 분석은 아래 글에서 확인할 수 있습니다.

📚 Gartner 하이프 사이클로 본 SIEM과 SOAR – 왜 둘 다 한계가 있는가?
https://blog.plura.io/ko/column/hypecycle_siem_soar/

📚 SOAR 도입하면 뭐하나요? 자동 대응도 못하는데
https://blog.plura.io/ko/column/why_soar_always_fails/

📚 Q18. 로그가 많아지면 보안은 정말 더 좋아질까요?
https://blog.plura.io/ko/qna/q18-log-size/

📚 Q19. 로그 분석 기반 대응은 사후 대응 아닌가요?
https://blog.plura.io/ko/qna/q19-log-analysis-response/

Tags