Gartner 하이프 사이클로 본 SIEM과 SOAR – 왜 둘 다 한계가 있는가?
📊 Gartner 하이프 사이클로 본 SIEM과 SOAR
왜 둘 다 한계가 있는가, 그리고 왜 지금은 통합 재설계가 필요한가
📊 Gartner는 하이프 사이클을 통해 기술이 시장에서 어떻게 기대를 받고, 실망을 겪고, 다시 현실적 가치로 재정의되는지를 5단계로 설명합니다. 핵심은 단순합니다. “성숙한 기술”이 곧 “문제를 해결한 기술”을 의미하지는 않는다는 점입니다.
최근 보안 운영 관점에서 보면, SOAR는 한때 “완전한 자동 대응”의 상징처럼 기대를 받았지만, 실제 현장에서는 독립 플랫폼으로서 한계가 드러나며 기대가 크게 조정되었습니다. 반면 SIEM은 오랫동안 주류 도구로 자리 잡았지만, 많은 조직에서 여전히 “로그는 많은데 사고가 나면 볼 것이 없는 시스템”으로 남아 있습니다.
핵심은 이렇습니다.
SOAR는 자동화의 약속을 과하게 했고,
SIEM은 로그 수집의 상징이 되었지만,
둘 다 현재 보안 운영의 핵심 문제를 단독으로 해결하지는 못합니다.
먼저 보는 핵심 요약
이 글의 결론은 세 가지입니다
- SOAR의 한계는 자동화 자체가 아니라, 탐지 품질과 운영 복잡성에 의존한다는 점입니다.
- SIEM의 한계는 로그 저장소로는 성숙했지만, 공격 맥락을 실시간으로 이해하는 구조까지는 되지 못했다는 점입니다.
- 그래서 지금 필요한 것은 SIEM과 SOAR를 각각 더 강화하는 것이 아니라, 로그 수집–탐지–분석–대응을 하나의 흐름으로 다시 설계하는 것입니다.
1️⃣ Gartner 하이프 사이클은 무엇을 보여주는가
Gartner 하이프 사이클은 기술을 다섯 단계로 설명합니다.
- 기술 촉발 (Innovation Trigger)
- 과도한 기대의 정점 (Peak of Inflated Expectations)
- 환멸의 골짜기 (Trough of Disillusionment)
- 계몽의 경사 (Slope of Enlightenment)
- 생산성의 정상 (Plateau of Productivity)
중요한 것은 이 프레임이
“이 기술이 좋은가 나쁜가”를 말하는 것이 아니라,
시장이 그 기술을 어떻게 소비하고 있는가를 보여준다는 점입니다.
그래서 어떤 기술이 생산성의 정상에 있다고 해서
모든 문제가 해결됐다는 뜻은 아닙니다.
반대로 환멸의 골짜기에 있다고 해서
기술적 가치가 전혀 없다는 뜻도 아닙니다.
문제는 언제나 실전에서 어떤 문제를 실제로 해결하느냐입니다.
2️⃣ SOAR가 보여준 한계: 자동화의 실패가 아니라, 기대의 실패
SOAR는 등장 당시 매우 강한 약속을 했습니다.
- 사람 없는 자동 대응
- 플레이북 기반 자율 SOC
- 복잡한 보안 운영의 자동화 허브
하지만 실제 현장에서는 대부분의 SOAR가
자동 차단 엔진이 아니라
조사 자동화, 티켓 연계, 정보 보강(enrichment) 도구 수준으로 축소되었습니다. 이는 2024년 이후 공개적으로 “standalone SOAR”의 미래가 약화되고 있다는 논의로도 이어졌습니다. Dark Reading은 Gartner가 SOAR를 “obsolete before plateau”로 봤다고 전하며, 그 이유를 독립 플랫폼 기능이 다른 보안 제품과 서비스에 흡수되고 있기 때문이라고 설명했습니다.
이 말은 곧 이런 뜻입니다.
SOAR의 핵심 기능인 자동화 자체가 사라진 것이 아니라,
독립형 SOAR 플랫폼이라는 카테고리의 설득력이 약해지고 있다는 뜻입니다.
왜 이런 일이 생겼을까요?
SOAR의 구조적 한계
- SOAR는 스스로 탐지하지 못합니다
- 대부분 SIEM 또는 외부 알림 품질에 의존합니다
- 플레이북은 정교하지만, 입력 데이터가 부정확하면 자동화도 부정확해집니다
- 자동 차단은 늘 오탐과 가용성 침해 위험을 동반합니다
결국 실제 현장에서는
계정 잠금, 서버 격리, 네트워크 차단 같은
강한 자동 대응은 거의 꺼지고,
알림 전달·평판 조회·자산 조회·티켓 생성 같은
보조 자동화만 남는 경우가 많습니다.
즉, SOAR의 진짜 문제는
자동화가 불필요해서가 아닙니다.
정확한 탐지와 충분한 맥락 없이 자동화만 먼저 붙였기 때문입니다.
3️⃣ SIEM이 보여준 한계: 주류가 되었지만, 여전히 “로그 창고”에 머무는 경우가 많다
SIEM은 훨씬 오래됐고, 훨씬 널리 쓰입니다.
이 점에서 SIEM은 분명 “주류 채택”에 가까운 기술입니다.
하지만 그 채택이 곧 실질적인 해결력을 의미하지는 않습니다. Gartner도 하이프 사이클을 기술의 채택과 성숙 흐름으로 설명할 뿐, 특정 단계가 자동으로 비즈니스 문제 해결을 보장한다고 말하지는 않습니다.
실제 현장에서 SIEM은 자주 이런 상태가 됩니다.
- 로그는 많이 모입니다
- 저장 비용은 계속 올라갑니다
- 룰은 늘어납니다
- 대시보드는 많아집니다
- 그런데 사고가 나면 정작 필요한 맥락은 부족합니다
왜일까요?
SIEM의 구조적 한계
첫째, 로그 수집 범위의 한계입니다.
웹 보안에서 정말 중요한 Request/Response Body,
OS 감사 로그의 세부 항목,
행위 중심 EDR 로그,
암호화 트래픽 내부 맥락 등은
애초에 충분히 수집되지 않거나,
비용과 저장 구조 때문에 요약되어 사라지는 경우가 많습니다.
둘째, 탐지 로직 의존성입니다.
SIEM은 결국 사람이 설계한 룰과 상관분석에 크게 의존합니다.
무엇을 공격으로 볼지 정의되지 않으면,
로그는 아무리 많아도 의미를 만들지 못합니다.
셋째, 운영 인력과 프로세스의 한계입니다.
룰은 튜닝이 필요하고,
환경은 계속 바뀌며,
담당자가 바뀌면 룰의 의미와 예외 처리 맥락도 함께 사라집니다.
그 결과 SIEM은 쉽게 “비싼 대시보드”로 남습니다.
즉, SIEM의 한계는
기술이 오래돼서가 아니라,
수집 범위, 해석 기준, 운영 지속성
이 세 가지가 함께 맞물려야만 비로소 가치가 나오기 때문입니다.
4️⃣ 왜 “성숙했다”는 말이 오히려 위험할 수 있는가
여기서 가장 중요한 오해가 하나 있습니다.
성숙 기술 = 해결된 기술
이 등식은 현장에서는 거의 맞지 않습니다.
SIEM은 성숙했고, 널리 깔려 있습니다.
하지만 실제로는 많은 조직에서 여전히:
- 어떤 로그를 남겨야 하는지 합의가 부족하고
- 어떤 룰이 유효한지 검증이 부족하며
- 어떤 알림이 진짜 공격인지 판단하기 어렵습니다
SOAR도 마찬가지입니다.
- 자동화 기능은 존재하지만
- 탐지 품질이 낮으면 자동화는 오히려 위험하고
- 결국 강한 자동 대응은 꺼진 채 운영됩니다
즉, 두 기술 모두
“도입 여부”보다는
어떤 데이터, 어떤 탐지, 어떤 운영 구조 위에 얹혀 있는가가 더 중요합니다.
5️⃣ 한눈에 보는 SIEM vs SOAR vs XDR
| 구분 | SIEM | SOAR | 통합 XDR 접근 |
|---|---|---|---|
| 핵심 역할 | 로그 수집·검색·상관분석 | 워크플로우 자동화·대응 오케스트레이션 | 수집–탐지–분석–대응 통합 |
| 강점 | 중앙 로그 저장, 규정 대응, 검색 | 반복 작업 자동화, 조사 보조 | 데이터와 대응 흐름의 일체화 |
| 구조적 한계 | 로그 범위 부족, 룰 의존성, 대시보드화 | 탐지 품질 의존, 자동 차단 한계, 운영 복잡성 | 초기 설계와 데이터 품질이 중요 |
| 현장 실패 패턴 | 로그만 많고 맥락은 부족 | 플레이북만 많고 강한 대응은 비활성 | 통합은 되었지만 데이터 품질이 낮으면 효과 제한 |
| 진짜 관건 | 무엇을 남길 것인가 | 무엇을 자동화할 것인가 | 무엇을 한 흐름으로 볼 것인가 |
이 표의 핵심은
“SIEM이 나쁘고 SOAR가 실패했다”가 아닙니다.
분리된 도구를 나중에 억지로 연결하는 방식만으로는
현재의 보안 운영 복잡성을 이기기 어렵다는 뜻입니다.
6️⃣ 실제 현장에서 자주 벌어지는 실패 패턴
패턴 1. SIEM은 있는데, 본문 로그가 없다
WAF 이벤트나 요약 로그는 남아도
실제 요청 본문과 응답 흐름이 없어서
공격 의도를 끝까지 추적하지 못합니다.
결국 알림은 많지만, 정탐 확신은 낮아집니다.
패턴 2. SOAR는 있는데, 플레이북만 많다
SIEM에서 들어온 알림이 부정확하면
SOAR는 평판 조회, 사용자 조회, 티켓 생성까지만 하고
실제 차단은 사람이 다시 판단해야 합니다.
자동화는 존재하지만, 결정적 대응은 수동으로 남습니다.
패턴 3. 둘 다 있는데, SOC는 더 바빠진다
SIEM은 데이터와 룰을 늘리고,
SOAR는 예외 처리와 플레이북을 늘립니다.
그런데 둘을 함께 운영할 인력과 맥락 체계는 그대로라면
결국 운영 복잡성만 늘어납니다.
7️⃣ 그래서 지금 필요한 것은 “통합적 재설계”입니다
이 글의 핵심은
SIEM과 SOAR를 버리자는 것이 아닙니다.
핵심은 이것입니다.
로그 수집–탐지–분석–대응을
서로 다른 제품의 책임으로 흩어 놓은 상태로는
현재 공격 흐름을 따라가기 어렵다
그래서 필요한 것은
기술 이름을 바꾸는 것이 아니라
보안 운영의 데이터 흐름 자체를 다시 설계하는 것입니다.
그 출발점은 세 가지입니다.
1. 로그 수집 품질을 먼저 높여야 합니다
- 웹 Request/Response Body
- OS 감사 로그
- EDR 행위 로그
- 계정·권한·프로세스 맥락
- 실제 공격 흐름에 필요한 원본 데이터
2. 탐지 로직은 “많은 룰”보다 “정탐 중심”으로 가야 합니다
- OWASP 기반 웹 탐지
- MITRE ATT&CK 기반 행위 탐지
- 알림 수보다 정탐 신뢰도를 높이는 방향
- 단일 이벤트보다 체인 기반 탐지
3. 운영 체계는 “자동화”보다 “판단 가능한 맥락”을 우선해야 합니다
- 오탐/정탐 판별 기준
- 룰 튜닝 책임과 절차
- 예외 관리 이력
- 자동 대응이 가능한 시나리오와 불가능한 시나리오 구분
이 세 가지가 없으면
SIEM은 저장소가 되고,
SOAR는 심부름 도구가 되며,
SOC는 계속 번아웃으로 갑니다.
8️⃣ 실무에서 바로 점검할 3가지 질문
체크 1. 우리 SIEM에는 “정말 필요한 원본 맥락”이 들어오고 있는가?
단순 이벤트 수집이 아니라
실제 공격 해석에 필요한 로그가 들어오는지 확인해야 합니다.
체크 2. 우리 SOAR 플레이북 중 실제로 자동 차단까지 가는 비율은 어느 정도인가?
대부분이 조회·티켓·알림 수준에 머무른다면,
자동화 전략을 다시 정의해야 합니다.
체크 3. 우리 SOC는 알림을 많이 보는가, 아니면 공격 흐름을 실제로 이해하는가?
알림 수가 아니라
판단 가능한 맥락과 대응 속도를 기준으로 봐야 합니다.
9️⃣ PLURA-XDR을 대안으로 보는 이유
이 지점에서 PLURA-XDR의 의미는
“SIEM 기능도 있고 SOAR 기능도 있다”는 데 있지 않습니다.
더 중요한 것은
처음부터 수집–탐지–분석–대응을 하나의 데이터 흐름으로 설계했다는 점입니다.
즉,
- 웹 로그와 본문 로그
- 시스템 및 행위 로그
- 탐지 룰과 시나리오
- 분석 결과와 대응 조치
를 서로 분리된 제품 사이에서 넘겨받는 것이 아니라,
처음부터 같은 맥락 안에서 처리하는 접근입니다.
이런 통합 구조는
두 가지를 바꿉니다.
첫째, 오탐이 줄어들기 쉬운 구조를 만듭니다.
맥락이 풍부할수록 단일 이벤트 오해가 줄어듭니다.
둘째, 자동 대응의 질을 높이기 쉬운 구조를 만듭니다.
탐지와 분석이 더 풍부한 데이터 위에서 이뤄질수록
자동화도 더 위험하지 않게 설계할 수 있습니다.
즉, 중요한 것은
SOAR를 더 붙이느냐, SIEM을 더 고도화하느냐가 아니라,
탐지와 대응이 같은 맥락 위에서 이어질 수 있는가입니다.
결론
Gartner 하이프 사이클은 기술을 이해하는 좋은 프레임입니다.
하지만 보안 운영에서는 단계보다 더 중요한 질문이 있습니다.
- 이 기술이 실제 SOC 문제를 해결하는가?
- 로그를 더 잘 모으는가?
- 맥락을 더 잘 보여 주는가?
- 자동화를 더 안전하게 만드는가?
SOAR는 자동화의 미래를 약속했지만,
탐지 품질과 운영 복잡성의 한계를 벗어나지 못했습니다.
SIEM은 주류가 되었지만,
여전히 많은 조직에서 로그 창고 이상의 역할을 하지 못합니다.
그래서 지금 필요한 것은
둘 중 하나를 더 믿는 일이 아닙니다.
로그 수집–탐지–분석–대응을
처음부터 하나의 흐름으로 다시 설계하는 것
바로 그것이
지금 보안 운영이 다시 출발해야 할 지점입니다.
📖 함께 읽기
- 생각지도 못한 일을 해내는 PLURA
- 지금 해킹 공격이 진행 중인지 확인하려면? PLURA
- SOAR 도입하면 뭐하나요? 자동 대응도 못하는데
- SIEM, 도입하면 뭐하나요? 로그 수집도 분석도 안 된다면