SIEM은 왜 아직도 쓰이나요? 한계에 도달한 로그 창고의 현실

By PLURA

A. 기술 때문이 아니라, ‘정의되지 않은 역할·컴플라이언스·관성’ 때문입니다.

SIEM(Security Information and Event Management)은
오랫동안 “보안 로그의 중심”으로 여겨져 왔습니다.

하지만 실제 SOC 현장에서는
SIEM이 약속했던 역할을 제대로 수행하지 못하고 있으며,
많은 조직에서 로그 창고(Log Dump) 수준으로만 사용되고 있습니다.

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

1️⃣ “로그를 모으면 보안이 된다”는 오래된 믿음

SIEM 도입의 출발점은 단순합니다.

“로그를 한곳에 모으면,
공격을 더 잘 볼 수 있지 않을까?”

이 기대는 직관적으로는 맞아 보입니다.
하지만 현실은 훨씬 다릅니다.

  • 로그는 자동으로 의미를 만들지 않습니다
  • 이벤트는 많지만, 맥락(Context)은 없습니다
  • 수집은 되었지만, 분석은 되지 않습니다

즉, SIEM은
“로그를 모으는 도구”일 뿐,
무엇이 공격인지 정의해 주지 못합니다.

많은 조직이 여기서 착각합니다.
로그를 중앙에 모으는 것과
공격을 이해하는 것은 전혀 다른 문제인데,
둘을 같은 것으로 생각해 버리는 것입니다.

2️⃣ ISMS·감사 대응의 ‘만능 답변’

SIEM이 현장에서 강력한 이유는
기술이 아니라 보고서입니다.

  • “로그를 수집하고 있습니까?”
  • “이벤트를 중앙에서 관리합니까?”
  • “침해 징후를 통합 모니터링합니까?”

이 질문에 대해
SIEM은 가장 간단하고 안전한 답이 됩니다.

실제 탐지 여부와 상관없이,
“SIEM 운영 중”이라는 문장은
감사 대응에서 매우 강력한 면피 수단이 됩니다.

Q9에서 IPS·NDR이,
Q11에서 SOAR가 그러했듯,
SIEM 역시 많은 조직에서 컴플라이언스 장비로 자리 잡았습니다.

즉, SIEM은
실전 탐지 도구라기보다
“우리는 체계를 갖추고 있다”는 것을 보여 주는
제도적 상징이 된 경우가 많습니다.

3️⃣ 로그는 많아지는데, 분석은 더 어려워집니다

시간이 지날수록 SIEM의 상황은 더 악화됩니다.

  • 수집 로그는 기하급수적으로 증가하고
  • 클라우드·SaaS·API 로그는 폭증하며
  • 저장 비용 때문에 원본 로그는 요약·삭제됩니다

그 결과는 역설적입니다.

  • 로그는 더 많아졌는데
  • 실제로는 더 덜 보이게 됩니다

중요한 본문 데이터는 사라지고,
남는 것은 의미 없는 이벤트 카운트뿐인 경우가 많습니다.

그래서 SIEM 운영 현장에서는
이런 말이 반복됩니다.

“로그는 많은데,
사고가 나면 정작 볼 게 없다.”

이는 단순한 과장이 아닙니다.
로그 양이 많다는 사실이
곧 분석 가능성을 의미하지는 않기 때문입니다.

오히려 너무 많은 로그는
의미 없는 잡음을 늘리고,
실제 공격 맥락을 더 찾기 어렵게 만듭니다.

4️⃣ 규칙(Rule)과 상관분석은 유지되지 않습니다

SIEM의 핵심 기능으로 알려진
상관분석(Correlation)은
이론적으로는 매우 강력해 보입니다.

하지만 현실적으로는
지속 유지가 어렵습니다.

  • 환경이 바뀔 때마다 룰 수정이 필요하고
  • 서비스 하나가 추가될 때마다 튜닝이 필요하며
  • 업무 시스템이 변경될 때마다 예외 처리가 쌓입니다

그리고 더 큰 문제는
룰이 사람에게 종속된다는 점입니다.

  • 누가 왜 이 룰을 만들었는지 잊혀지고
  • 담당자가 바뀌면 의미를 이해하기 어려워지며
  • 담당자가 퇴사하면 룰은 사실상 방치됩니다

결국 대부분의 SIEM은:

  • 기본 제공 룰만 남고
  • 실제 공격 탐지에는 거의 기여하지 못하며
  • 잦은 오탐 때문에 무시되는 상태로 가게 됩니다

그 결과 SIEM은 점점
“아무도 손대지 않는 시스템”이 됩니다.

존재는 하지만,
신뢰하지는 않는 시스템.
바로 이것이 많은 현장의 현실입니다.

5️⃣ SIEM은 문제의 원인이 아니라, 결과물입니다

SIEM이 반복적으로 실패하는 가장 근본적인 이유는
사실 SIEM 자체에만 있지 않습니다.

더 근본적인 문제는
그 이전 단계가 비어 있다는 점입니다.

  • 무엇을 로그로 남길지 정의되지 않았고
  • 어떤 행위가 공격인지 합의되지 않았으며
  • 어떤 우선순위로 분석할지 정리되지 않았고
  • 탐지 이후 어떻게 대응할지도 준비되지 않았습니다

즉, SIEM은
정의되지 않은 보안 전략의 결과물일 뿐입니다.

전략 없이 SIEM을 먼저 도입하면
결과는 거의 항상 비슷합니다.

“로그는 많은데,
분석도 대응도 못 한다.”

그래서 SIEM은
문제의 출발점이라기보다
이미 방향을 잃은 보안 운영이
마지막에 도달하는 하나의 결과처럼 보이기도 합니다.

6️⃣ 그래서 필요한 것은 ‘로그 저장’이 아니라 ‘로그 해석 구조’입니다

SIEM의 한계를 보면
문제는 로그 부족이 아니라
로그를 이해할 구조의 부재라는 점이 더 분명해집니다.

실제 SOC에서 필요한 것은
단순 저장소가 아닙니다.

필요한 것은 다음과 같은 질문에
빠르게 답할 수 있는 구조입니다.

  • 이 이벤트가 왜 중요한가?
  • 이 계정과 단말, 서버는 어떤 관계인가?
  • 직전과 이후에 어떤 행위가 있었는가?
  • 이것이 단순 이상인가, 실제 침해 흐름인가?

즉, 로그는
많이 쌓이는 것보다
실시간으로 해석되고 연결되는 것이 더 중요합니다.

이 지점에서 PLURA-XDR은
로그를 단순히 저장소에 쌓아 두는 접근보다,
호스트·계정·애플리케이션 로그를 실시간으로 연결 분석하여
공격 흐름과 행위의 맥락을 더 빠르게 보여 주는 방식에 가깝습니다.

중요한 것은
“얼마나 많이 저장했는가”가 아니라,
무엇이 실제 공격이었는지를 얼마나 빨리 이해할 수 있는가입니다.

정리하면

SIEM이 아직도 사용되는 이유는
효과적이어서가 아니라,
버리지 못하는 관성과 제도 때문입니다.

  • 로그 수집이 요구되었고
  • 감사에 필요했고
  • 대안이 명확하지 않았으며
  • 이미 많은 비용을 지불했기 때문입니다.

하지만 로그의 목적은
보관이 아니라, 설명과 대응입니다.

로그를 모으는 시스템이 아니라,
로그를 이해하는 구조가 필요합니다.

SIEM이 그 역할을 하지 못한다면,
그 위치와 역할을 다시 정의해야 할 시점입니다.

그리고 그 재정의의 출발점은
더 많은 로그 적재가 아니라,
실시간으로 공격 흐름을 이해할 수 있는 분석 구조와
행위를 실제로 통제할 수 있는 운영 방식이어야 합니다.

함께 읽을 글

SIEM이 왜 반복적으로 기대에 미치지 못하는지에 대한
보다 구체적인 분석은 아래 글을 참고해 주세요.

📚 SIEM, 도입하면 뭐하나요? 로그 수집도 분석도 안 된다면
https://blog.plura.io/ko/column/why_siem_always_fails/

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

📚 Q11. SOAR는 왜 아직도 쓰이나요? 이미 한계에 도달한 자동화의 현실
https://blog.plura.io/ko/qna/q11-goodbye-soar/

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

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

Tags