SIEM, 도입하면 뭐하나요? 로그 수집도 분석도 안 된다면

By PLURA 2025-05-16

SIEM, 도입하면 뭐하나요? 로그 수집도 분석도 안 된다면

📉 많은 기업이 통합로그관리, SIEM 도입을 고민합니다.
하지만 그 전에 먼저 물어야 할 질문이 있습니다.

정말 로그 수집이 되고 있나요?
그리고 수집한 로그를 제대로 분석하고 있나요?

결론부터 말하면,
대부분의 기업은 로그도 충분히 수집하지 못하고, 분석할 운영 역량도 갖추지 못했습니다.

이런 상태에서 SIEM은 결국
고가의 시각화 대시보드 이상의 의미를 갖기 어렵습니다.

SIEM: Security Information and Event Management

SIEM 도입의 허상

먼저 보는 핵심 요약

이 글의 결론은 단순합니다.

SIEM의 가장 큰 문제는 솔루션 이전에 로그 수집 범위의 한계입니다.
로그가 있어도 공격을 판별할 룰과 운영 기준이 없으면 분석은 실패합니다.
그래서 SIEM의 본질은 대시보드가 아니라 운영 체계입니다.
이 한계를 넘으려면 본문 로그, Execution Chain, 행위 기반 분석까지 포함한 구조가 필요합니다.

1. 로그 수집부터 불가능한 현실 🛑

많은 조직이 SIEM을 도입하면
자동으로 모든 보안 데이터가 들어오고,
자동으로 공격이 드러날 것처럼 기대합니다.

하지만 현실은 정반대입니다.

SIEM은 어디까지나
들어온 로그를 저장하고 검색하고 상관분석하는 도구입니다.
즉, 애초에 로그가 제대로 들어오지 않으면 아무것도 시작되지 않습니다.

(1) 웹 서버 로그 수집의 한계

대부분의 웹 서버는 기본적으로 액세스 로그만 남깁니다.

보통 남는 정보는 다음 수준입니다.

IP 주소
URL
상태 코드
간략한 요청 헤더
응답 크기 정도

하지만 실제 웹 공격의 핵심은 여기에 없는 경우가 많습니다.

SQL 인젝션은 주로 Request Body 안에 들어갑니다
XSS 역시 실제 페이로드를 봐야 구분할 수 있습니다
웹셸 업로드는 업로드 본문과 응답 결과를 봐야 판단할 수 있습니다
개인정보 유출은 Response Body를 봐야 확인할 수 있습니다

즉, 요청 본문(Request Body) 과 응답 본문(Response Body) 이 빠지면
핵심 공격 정보가 애초에 로그에 존재하지 않을 수 있습니다.

예를 들어,

/login URL 반복 호출만 보면 단순 로그인 시도로 보일 수 있지만
Request Body를 보면 대량 계정 조합을 시도하는 Credential Stuffing일 수 있습니다

또,

파일 업로드 요청이 있었다는 사실만으로는 정상 업로드인지 알 수 없고
업로드 본문을 봐야 PHP 웹셸 삽입 시도인지 구분할 수 있습니다

즉, 웹 보안에서 본문 로그가 없으면
SIEM은 공격의 핵심을 보지 못한 채
껍데기만 분석하게 됩니다.

👉 웹을 통한 데이터유출 해킹 대응
👉 웹의 전체 로그 분석은 왜 중요한가?

(2) 감사 정책 없는 운영체제 로그 수집의 한계

운영체제 로그도 마찬가지입니다.

Windows, Linux 등에서 감사 정책(Auditing) 이 꺼져 있으면

사용자 로그인
프로세스 실행
권한 변경
서비스 생성
스케줄 작업 등록

같은 핵심 행위가 아예 기록되지 않습니다.

즉, 공격이 있었더라도
로그에는 아무 흔적이 없을 수 있습니다.

문제는 감사 정책을 켠 뒤에도 끝나지 않습니다.

감사 정책을 활성화하면
수십만 건, 수백만 건의 로그가 쌓이는데
이를 해석할 기준이 없으면 결국 이런 상태가 됩니다.

로그는 있다
하지만 무엇이 중요한지 모른다
정상과 이상을 구분할 수 없다
결국 보지 않게 된다

즉,

감사 로그가 없는 것도 문제지만,
감사 로그가 있어도 해석 구조가 없으면 무용지물입니다.

(3) 정보보안 제품 자체의 로그 수집 한계

웹 서버와 운영체제만의 문제가 아닙니다.
대표적인 보안 솔루션들도 각자 로그 수집 한계를 가지고 있습니다.

아래 표로 정리하면 이해가 쉽습니다.

로그 수집 한계 비교

영역	장점	핵심 한계
웹 서버	기본 액세스 로그 확보 가능	Request/Response Body 미수집 시 핵심 공격 누락
운영체제	로그인, 프로세스, 권한 이벤트 가능	감사 정책이 꺼져 있으면 핵심 이벤트 부재
IPS	네트워크 레벨 탐지 가능	HTTPS 복호화 한계, SSH/RDP 본문 분석 불가
NDR	행위 기반 네트워크 분석 가능	암호화 트래픽 내부 본문 한계, 엔드포인트 맥락 부족
WAF	웹 공격 탐지와 차단 강점	정상 트래픽 전체 본문을 SIEM으로 전송하기엔 제약
EDR	엔드포인트 행위 추적 가능	감사 정책/수집 정책이 약하면 의미 있는 맥락 부족

[1] 침입차단시스템(IPS) 로그 수집의 한계

IPS는 주로 네트워크 트래픽을 기반으로 동작합니다.
하지만 여기에도 분명한 한계가 있습니다.

① HTTPS 복호화 문제

대규모 환경에서 HTTPS 전체를 복호화해 SIEM으로 넘기는 것은
성능과 운영 부담이 매우 큽니다.

② SSH, RDP 등 엔드투엔드 암호화 프로토콜 복호화 불가

SSH, RDP는 중간 장비에서 본문을 보기 어렵습니다.
즉, 연결은 보여도 세션 내부 명령어와 파일 전송 내용은 보이지 않습니다.

③ 결론

IPS 로그는 대체로 TCP/IP 레벨의 정보에 머뭅니다.
암호화된 트래픽의 실제 내용을 충분히 제공하지 못하는 경우가 많습니다.

👉 IPS의 진화와 보안 환경의 변화
👉 침입차단시스템(IPS) 이해하기

[2] 네트워크 탐지 및 대응(NDR) 로그 수집의 한계

NDR은 네트워크 행위를 분석하는 데 강점이 있습니다.
하지만 역시 암호화 트래픽 내부 내용을 다 보는 것은 아닙니다.

HTTPS 일부 분석은 가능할 수 있어도
WAF처럼 Request/Response 본문을 깊게 다루는 구조는 일반적이지 않습니다
SSH, RDP 같은 프로토콜 내부 맥락은 여전히 보기 어렵습니다

결국 NDR도
암호화된 세션 내부 행위까지 SIEM으로 풍부하게 전달하는 데 한계가 있습니다.

👉 NDR의 한계: 해결 불가능한 미션

[3] 웹방화벽(WAF) 로그 수집의 한계

WAF는 공격으로 판단한 요청에 대해서는
상세 이벤트를 잘 남길 수 있습니다.

하지만 문제는 정상 트래픽 전체입니다.

공격 이벤트는 남겨도
정상 트래픽의 원본 본문 전체를
전수로 SIEM에 넘기는 것은
성능과 저장 비용 측면에서 현실적 제약이 큽니다

즉, WAF는 강력한 웹 탐지 장비이지만
SIEM의 전수 데이터 소스로 쓰기에는 한계가 있습니다.

👉 웹방화벽(WAF)에 대한 이해

[4] 엔드포인트 보안(EDR) 로그 수집의 한계

EDR 역시 만능은 아닙니다.

EDR이 제대로 의미 있는 로그를 남기려면
운영체제 수준에서 다음이 함께 필요합니다.

감사 정책 활성화
프로세스/파일/레지스트리 관련 이벤트 확보
적절한 수집 정책
행위 흐름을 볼 수 있는 설정

즉,

감사 정책이 비활성화된 EDR은
핵심 맥락이 빠진 상태의 엔드포인트 로그만 제공할 수 있습니다.

1부 요약

정리하면, SIEM의 첫 번째 한계는 명확합니다.

중요한 공격은 본문과 맥락에 숨어 있는데,
실제로는 그 정보가 로그에 아예 들어오지 않는 경우가 많다는 점입니다.

로그가 없으면 탐지도 없습니다.
이것이 SIEM 한계의 출발점입니다.

2. 로그 분석? 로그가 있어도 할 수 없습니다 🤔

로그가 들어왔다고 해서
문제가 끝나는 것은 아닙니다.

오히려 더 어려운 문제는 그 다음입니다.

이 로그가 정말 공격인지,
아니면 정상 행위인지 누가 판단할 것인가?

SIEM은 흔히
“모든 로그를 모으면 공격을 자동으로 찾아주는 시스템”처럼 오해됩니다.
하지만 현실은 다릅니다.

SIEM은 결국
사용자가 정의한 룰과 기준으로만 움직입니다.

(1) SIEM에서 웹로그에 대한 공격 쿼리 검색이 가능할까요?

예를 들어, SIEM에서
SQL 인젝션, XSS, 웹셸 같은 공격을 찾으려면
우선 악성 페이로드가 들어 있는 필드가 수집되어야 합니다.

즉, Request Body가 있어야 합니다.

그런데 Request Body가 수집되었다고 해도
문제가 자동으로 해결되지는 않습니다.

예를 들어 select * from 문자열이 들어 있다고 해서
그 자체만으로 무조건 공격이라고 단정할 수는 없습니다.

정상 API 호출, 테스트 쿼리, 내부 개발 요청일 수도 있기 때문입니다.

즉, 결국 사용자가 직접 정의해야 합니다.

어떤 문자열 조합이 위험한가
어떤 헤더나 사용자 행태와 결합되면 공격인가
어떤 User-Agent나 내부 경로는 예외인가

결국,

SIEM은 공격을 “자동 이해”하지 않습니다.
사람이 공격 패턴을 정의해야만 이상 징후로 인식합니다.

👉 우리는 왜 GET/POST 로그를 분석하는가?

(2) BPFDoor 같은 고도화된 위협 식별?

BPFDoor 같은 커널 수준 백도어는
단순 유저 모드 이벤트 로그만으로는 탐지하기 매우 어렵습니다.

예를 들어,

프로세스 이름만 보고는 부족하고
메모리, 커널 훅, eBPF 프로그램 등
더 깊은 관찰이 필요할 수 있습니다

가령 어떤 포렌식 도구가
“BPFDoor 의심 이벤트”를 SIEM으로 보낸다고 해도,
SIEM이 그것을 자동으로 “이건 BPFDoor다”라고 이해하지는 않습니다.

사용자가 미리 정의해야 합니다.

어떤 필드 조합이 BPFDoor 의심인지
어떤 행위 흐름이 비정상인지
어떤 경보 정책을 걸어야 하는지

즉, 고도화된 위협일수록
SIEM의 한계는 더 분명해집니다.

데이터가 들어와도,
그것을 위협으로 해석하는 것은 결국 사용자와 운영 체계의 몫입니다.

(3) DLL 인젝션 탐지?

DLL 인젝션도 비슷합니다.

단순 프로세스 실행 로그만으로는
어떤 DLL이, 어느 프로세스에, 어떤 경로에서 로드되었는지
정확히 보기 어렵습니다.

이를 제대로 보려면

ETW
Sysmon의 특수 이벤트
모듈 로드 관련 상세 추적

같은 고급 수집이 필요합니다.

그런데 데이터가 있다고 해도
다시 같은 문제가 남습니다.

어떤 DLL은 정상인가
어떤 경로는 비정상인가
어떤 서명은 신뢰 가능한가
어떤 조합이면 이상으로 볼 것인가

이 역시 결국 사용자가 룰을 정의해야만
SIEM이 탐지할 수 있습니다.

(4) 크리덴셜 스터핑(Credential Stuffing) 대응?

크리덴셜 스터핑은
실무에서 SIEM 한계를 보여주는 대표 사례입니다.

기본 로그인 실패 로그만으로는
이것이 단순 사용자 실수인지,
대량 계정 재사용 공격인지 구분하기 어렵습니다.

정확히 보려면 최소한 다음이 필요합니다.

Request Body 기반 사용자 ID 정보
같은 IP에서 몇 개 계정을 시도했는지
같은 계정에 대해 얼마나 반복됐는지
시간 간격과 분산 패턴
정상 사용자 행태와의 차이

즉, 크리덴셜 스터핑을 제대로 잡으려면
단순 로그인 실패 횟수만이 아니라
본문 로그 + 시나리오 룰 + 행태 분석이 함께 필요합니다.

그렇지 않으면 SIEM은
그저 “로그인 실패가 반복되었네” 정도로만 인식할 가능성이 큽니다.

👉 2025년 1월 GS리테일 해킹

2부 요약

결국 SIEM의 두 번째 한계도 분명합니다.

로그가 있어도,
공격을 공격으로 정의하는 룰과 기준이 없으면
SIEM은 자동으로 답을 주지 못합니다.

즉, SIEM은 마법 상자가 아닙니다.
수집된 데이터를 정제·검색·상관분석할 뿐,
어떤 로그가 באמת 악성인지 주도적으로 판단해주지는 않습니다.

3. SIEM의 본질은 대시보드가 아니다 📊

(1) 예쁜 차트 ≠ 로그 분석

많은 SIEM 업체는
“AI 대시보드”, “위험 점수 기반 시각화”, “실시간 보안 현황”을 강조합니다.

하지만 예쁜 시각화가
공격을 자동으로 탐지해주지는 않습니다.

결국 중요한 것은 두 가지입니다.

로그 품질: 무엇이 얼마나 상세하게 수집되는가
분석 역량: 수집된 로그를 실제 공격 흐름으로 해석할 수 있는가

이 두 가지가 없으면
대시보드는 그저 화려한 그래프일 뿐입니다.

(2) SIEM ≠ 만능 보안 솔루션

SIEM은 어디까지나
수집된 로그를 보관하고, 검색하고, 분석하는 도구입니다.

즉,

무엇을 수집할지
무엇을 남길지
무엇을 공격으로 볼지
어떤 룰을 유지할지

가 먼저 정의되지 않으면
SIEM은 공허한 통계 화면에 머뭅니다.

특히 많은 조직이
“SIEM만 잘 구축하면 모든 공격을 자동으로 막을 수 있다”고 오해합니다.

하지만 실제로는
로그 수집 범위와 분석 룰 설계가 선행되지 않으면
아무리 고가의 SIEM도 무용지물이 됩니다.

(3) SIEM + AI ≠ 만능 보안 솔루션

일각에서는
“모든 로그를 AI에 넣으면 공격을 자동으로 찾을 것”이라고 기대합니다.

하지만 AI도 결국 같은 문제를 가집니다.

무엇을 우선 분석할지
어떤 데이터를 중요하게 볼지
무엇을 이상으로 정의할지

를 사람이 정해줘야 합니다.

즉,

가비지 인, 가비지 아웃입니다.

데이터가 부족하거나 엉망이면
AI도 제대로 된 결과를 내놓기 어렵습니다.

결국 SIEM에 AI를 붙여도
로그 품질, 탐지 기준, 운영자의 해석이 뒷받침되지 않으면
결과는 크게 달라지지 않습니다.

4. PLURA-XDR은 이 문제를 어떻게 다르게 접근하는가?

여기서 중요한 질문이 생깁니다.

그렇다면 PLURA-XDR은 SIEM의 로그 수집·분석 한계를 어떻게 줄이려는가?

핵심은 세 가지입니다.

(1) 본문 로그 기반 가시성 확보

PLURA-XDR은
단순 URL/상태코드 수준이 아니라
Request/Response Body 기반 웹 로그를 활용할 수 있습니다.

이것은 큰 차이를 만듭니다.

예를 들어:

SQL 인젝션 실제 페이로드 확인
웹셸 업로드 내용 확인
데이터 유출 응답 패턴 식별
Credential Stuffing의 계정 조합 식별

즉, 애초에 탐지 가능한 데이터 범위가 넓어집니다.

(2) Execution Chain 기반 행위 분석

PLURA-XDR은 단일 이벤트보다
행위 흐름(Execution Chain) 을 중요하게 봅니다.

예를 들면:

Parent Process
Child Process
CommandLine
계정 행위
후속 파일/네트워크 행위

를 함께 연결해 봅니다.

이렇게 되면
단순 “PowerShell 실행”과
“문서 → PowerShell → 외부 연결 → 추가 실행”은
전혀 다른 의미로 해석됩니다.

즉, 단일 이벤트보다
맥락이 풍부한 고신뢰도 이벤트를 만들 수 있습니다.

(3) 수집–탐지–분석–대응의 같은 맥락 유지

전통적인 SIEM 구조에서는

로그 수집
이벤트 생성
분석
대응

이 서로 다른 도구와 팀 사이에서 끊어지기 쉽습니다.

반면 PLURA-XDR은
수집–탐지–분석–대응을 하나의 흐름 안에서 연결하려는 구조를 가집니다.

이것은 다음에 유리합니다.

오탐 감소
자동 대응 신뢰도 향상
운영자의 판단 부담 감소
SOAR형 자동화의 현실적 적용

즉,

SIEM의 한계를 넘으려면
더 많은 로그를 쌓는 것보다
더 많은 맥락을 연결하는 구조가 필요합니다.

5. SIEM 도입 전, 그 전에 할 일이 있다 ✅

1) 로그 수집 환경부터 제대로 갖추세요

웹 본문 로그(Request/Response Body)
OS 감사 로그
DB 감사 로그
EDR 행위 로그

를 필요한 범위만큼 수집할 수 있는 체계를 먼저 갖춰야 합니다.

단, 전수 수집은 비용과 성능 부담이 크므로
우선순위를 정하고 점진적으로 확장해야 합니다.

2) 분석 기준과 탐지 룰을 직접 설계하세요

OWASP Top 10
MITRE ATT&CK
내부 업무 시나리오
조직별 예외 정책

을 기반으로
공격 탐지 기준을 명확히 해야 합니다.

SIEM은 자동으로 공격 정의를 만들어주지 않습니다.
운영자가 기준을 설계해야 합니다.

3) 실무자의 이해와 교육이 필수입니다

아무리 좋은 SIEM이라도
운영자가 로그와 룰을 이해하지 못하면 의미가 없습니다.

그래서 필요한 것은

인력 양성
교육
보안팀·개발팀·운영팀 협업 체계
지속적 룰 튜닝

입니다.

4) 현실적인 운영 비용을 계산해야 합니다

SIEM의 실제 비용은
솔루션 구매비로 끝나지 않습니다.

로그 스토리지 비용
라이선스 비용
대역폭 비용
분석 인력 비용
룰 유지 비용
예외 처리 비용

이 모두가 장기적으로 누적됩니다.

즉, SIEM은 구축비보다
운영비(TCO) 가 더 중요한 솔루션입니다.

6. SIEM 도입 전 체크리스트 📋

항목	핵심 질문	체크
로그 수집 범위	Request/Response Body 등 핵심 공격 정보를 남길 수 있는가? OS/DB 감사 로그는 활성화되어 있는가?	□
감사 정책	로그인, 프로세스 실행, 권한 변경 같은 이벤트가 모두 기록되는가?	□
공격 탐지 룰	OWASP, MITRE ATT&CK, 내부 시나리오 기반 룰이 준비되어 있는가?	□
운영 인력 & 조직	SIEM을 다룰 전문 인력이 있는가? 팀 간 협업 프로세스가 있는가?	□
자동화·인프라	대량 로그 전송·저장을 위한 인프라가 준비되어 있는가? 유지·보수 계획이 있는가?	□
총소유비용(TCO)	라이선스, 스토리지, 인력, 유지보수까지 장기 비용을 계산했는가?	□

이 항목을 충분히 검토하고 실행 계획을 세운 뒤에야
SIEM이 비싼 대시보드로 끝나지 않고
실질적 보안 효과를 낼 수 있습니다.

7. 준비 없이 SIEM을 도입한 조직의 전형적 패턴

실무에서 자주 보는 패턴은 대체로 이렇습니다.

“통합로그관리 필요”라는 이유로 SIEM부터 도입
웹/OS/EDR 로그는 부분적으로만 수집
Request Body, Response Body, 감사 정책은 빠져 있음
기본 룰만 넣고 운영 인력은 부족
알림은 많아지는데 정탐 확신은 낮음
몇 달 후 “SIEM은 비싼 대시보드”라는 불만이 나옴

즉,

SIEM 실패의 본질은 제품보다 준비 부족에 있습니다.

✍️ 최종 정리

SIEM은 도입 자체가 목적이 아니라, 운영이 핵심입니다.
로그를 수집할 수 없다면, SIEM은 전혀 의미가 없습니다.
로그를 분석할 역량이 없다면, SIEM은 더더욱 무용지물에 가깝습니다.
따라서 SIEM 도입 전에 로그 수집 체계, 분석 룰, 인력 준비, 운영 비용을 먼저 갖춰야 합니다.

로그가 없으면 탐지도 없습니다.
룰이 없으면 분석도 없습니다.
결국 대시보드는 그저 그림일 뿐입니다.

그리고 바로 이 지점에서
PLURA-XDR 같은 통합 접근이 의미를 갖습니다.

본문 로그
Execution Chain
행위 기반 분석
수집–탐지–분석–대응의 같은 맥락 유지

이런 구조가 있어야
SIEM이 단순 대시보드가 아니라
실제 공격을 해석할 수 있는 보안 운영 체계로 바뀔 수 있습니다.

📖 함께 읽기

📖 SIEM & SOAR 도입 실패 사례

🌟 PLURA-XDR의 차별점

🌟 PLURA-XDR의 서비스

실제 운영 환경에서 SIEM은 생각보다 매우 복잡합니다.
그러나 로그 수집과 분석 체계를 제대로 준비한다면,
SIEM은 강력한 보안 인텔리전스를 제공하는 도구가 될 수 있습니다.

하지만 직접 SIEM을 구축·운영하기에는
비용, 운영, 전문성 부담이 크기 때문에,
PLURA-XDR 와 같은 통합 플랫폼을 활용하는 방안도 함께 검토할 필요가 있습니다.