# SIEM 비용 문제의 근원과 보안 데이터 레이크가 실제로 해결하는 것

현장에서 보안 아키텍처를 논의하다 보면 대화가 결국 한 지점으로 수렴하는 경우가 많다. "로그는 쌓이는데 SIEM 라이선스 비용이 감당이 안 된다"는 이야기다. 매일 테라바이트 단위로 쏟아지는 텔레메트리를 전부 넣자니 예산이 버텨주지 않고, 줄이자니 랜섬웨어 사후 조사에 필요한 기록이 남지 않는다.

이 딜레마는 사실 기술 문제이기 전에 아키텍처 문제다. SIEM이 설계된 시대와 지금의 데이터 규모가 근본적으로 달라졌기 때문이다.

## SIEM이 비싼 이유: 스키마 온 라이트의 구조적 한계

SIEM은 데이터가 들어오는 시점에 구조를 확정하는 스키마 온 라이트(Schema-on-Write) 방식으로 동작한다. 로그가 유입될 때마다 실시간으로 파싱하고, 필드를 매핑하고, 인덱스를 생성해야 하기 때문에 처리량이 늘어날수록 컴퓨팅 비용이 거의 선형으로 따라온다. GB/Day 기준의 라이선스 구조가 이 방식과 맞물리면, 데이터가 많을수록 비용이 폭발하는 구조가 된다.

결국 많은 조직이 SIEM에 넣는 데이터를 스스로 제한하게 된다. 방화벽 플로우 로그는 잘라내고, DNS 쿼리는 샘플링하고, 엔드포인트 프로세스 이벤트는 중요도 기준으로 걸러낸다. 비용을 줄인 건 맞지만, 나중에 침해 사고를 조사할 때 필요한 흔적을 함께 지운 셈이기도 하다.

## 보안 데이터 레이크가 다르게 접근하는 방식

보안 데이터 레이크(SDL)는 이 문제를 다른 지점에서 공략한다. 데이터를 원형 그대로 저장해두고, 구조 부여는 조회 시점으로 미루는 스키마 온 리드(Schema-on-Read) 방식이다. Delta Lake나 Apache Iceberg 같은 개방형 테이블 포맷을 클라우드 오브젝트 스토리지(S3, GCS 등) 위에 얹으면, 스토리지 비용은 대폭 낮추면서도 스키마 진화(Schema Evolution)나 타임 트래블 쿼리 같은 분석 기능을 쓸 수 있는 레이크하우스 환경을 구성할 수 있다.

아래 표는 두 접근법의 핵심 차이를 정리한 것이다.

| 비교 항목 | 전통적 SIEM | 보안 데이터 레이크 (SDL) |
| --- | --- | --- |
| 데이터 구조 부여 방식 | 스키마 온 라이트 | 스키마 온 리드 |
| 포맷 생태계 | 벤더 종속적 | 개방형 (Iceberg, Delta Lake 등) |
| 비용 구조 | 유입량(GB/Day) 기반 | 스토리지/컴퓨팅 분리 과금 |
| 보존 기간 | 30~90일 내외 | 12개월 이상 가능 |
| 주요 데이터 경로 | Hot Path 중심 (전체의 10~20%) | Warm/Cold Path 중심 (80~90%) |
| 핵심 유스케이스 | 실시간 탐지, 컴플라이언스 보고 | 위협 헌팅, 포렌식, AI/ML 학습 |

단, 이 구분이 SIEM을 대체한다는 의미는 아니다. 두 방식은 서로 다른 역할을 맡는 게 맞다.

## 데이터 늪에 빠지지 않으려면

SDL을 도입할 때 가장 흔한 실수는 "일단 다 저장하면 되겠지"라는 접근이다. 실제로는 메타데이터 관리와 거버넌스 체계 없이 구축한 데이터 레이크가 데이터 늪(Data Swamp)으로 전락하는 경우가 적지 않다. 원하는 데이터를 찾을 수 없고, 쿼리 비용이 예측 불가능해지고, 결국 아무도 쓰지 않는 스토리지 더미가 된다.

파싱 단계에서 100% 완벽을 추구하는 것도 현실적으로 무리다. 실무에서는 95% 정확도를 목표로 하고, 파싱에 실패한 나머지를 데드 레터 큐(Dead Letter Queue, DLQ)로 분리해두는 전략이 유용하다. 역설적으로 이 실패 데이터가 새로운 공격 패턴의 조기 신호가 되는 경우가 있기 때문에, 그냥 버리는 것보다 격리해두는 편이 낫다.

## 수집과 저장 사이: 텔레메트리 파이프라인의 역할

원시 데이터를 그대로 SDL에 밀어 넣으면 저장 비용이 SDL 도입 효과를 상쇄한다. 수집 단계와 저장 단계 사이에 보안 텔레메트리 파이프라인을 두는 이유가 여기 있다.

파이프라인이 하는 일은 크게 세 가지다. 첫째, 보안 가치가 낮은 정상 트래픽을 사전에 걸러내는 필터링이다. 잘 설계된 필터링 규칙은 최종 저장 비용을 실질적으로 절반 이상 줄여준다. 둘째, Geo-IP 매핑이나 위협 인텔리전스 피드를 로그와 실시간으로 결합하는 보강(Enrichment)이다. 저장 시점이 아니라 수집 시점에 컨텍스트를 붙여두면 이후 분석 속도가 달라진다. 셋째, Apache Kafka 같은 메시지 큐를 사용한 비동기 버퍼링이다. 수집과 처리를 분리해두면 로그가 급증하는 구간에서 파이프라인이 무너지지 않는다.

## 벤더 간 데이터 통합: OCSF와 OpenTelemetry

팔로알토 방화벽 로그와 크라우드스트라이크 EDR 로그는 필드 이름부터 구조까지 다 다르다. 여러 벤더의 텔레메트리를 하나의 레이크에 모으면 통합 분석이 사실상 불가능해진다.

OCSF(Open Cybersecurity Schema Framework)는 이 문제를 표준화 레이어로 해결한다. 서로 다른 소스의 로그를 `user.name`, `auth_protocol` 같은 공통 필드 체계로 매핑해두면, 나중에 분석 도구를 교체하거나 소스를 추가해도 파이프라인을 처음부터 다시 짤 필요가 없다. OpenTelemetry와 함께 파이프라인의 기반으로 삼으면 특정 벤더에 종속되지 않는 데이터 아키텍처를 만들 수 있다.

## SIEM과 SDL을 같이 쓰는 방법

SIEM을 완전히 걷어내는 건 대부분의 조직에서 현실적이지 않다. 실시간 탐지와 컴플라이언스 보고는 여전히 SIEM이 더 잘하는 영역이기 때문이다. 실용적인 접근은 두 시스템을 역할에 따라 분리하는 하이브리드 아키텍처다.

전체 텔레메트리의 10~20% 정도, 즉 즉각적인 탐지와 대응이 필요한 핵심 이벤트는 SIEM으로 라우팅한다. 방화벽 플로우 로그나 DNS 쿼리처럼 실시간 경보보다 장기 분석 가치가 더 큰 나머지 80~90%는 SDL로 보낸다. 이렇게 경로를 나누면 SIEM 라이선스 부담을 줄이면서도 두 시스템의 장점을 함께 유지할 수 있다. 텔레메트리 파이프라인이 라우팅 로직을 담당하게 하면, 어떤 데이터를 어느 경로로 보낼지를 코드로 관리할 수 있어 운영 복잡도도 낮아진다.

## 장기 데이터 보존이 복구 속도를 결정한다

랜섬웨어 감염 이후 어제 백업본을 복원하면 끝이라고 생각하기 쉽지만, 실제 침해 조사에서는 그게 거의 통하지 않는다. 공격자들은 감염 수개월 전부터 환경에 잠복하는 경우가 많다. 백업 시점이 이미 오염된 상태라면, 복원 이후에도 같은 문제가 반복된다.

RTO(복구 시간 목표)를 실질적으로 단축하려면 감염 이전으로 충분히 거슬러 올라가는 텔레메트리가 있어야 한다. SDL이 12개월 이상의 데이터를 저비용으로 보존할 수 있다는 점은 이 맥락에서 단순한 스토리지 이점 이상의 의미가 있다. 수개월 전의 프로세스 이벤트와 네트워크 플로우를 조회해서 최초 진입점과 정확한 감염 시점을 찾을 수 있는 것이 SDL의 포렌식 가치다.

---

SDL과 텔레메트리 파이프라인의 조합은 보안 가시성을 유지하면서 비용 구조를 현실적으로 관리할 수 있는 방향이다. 하지만 기술 선택보다 먼저 해야 할 게 있다. 조직에서 어떤 데이터를 왜 보존해야 하는지에 대한 명확한 기준이다. 그 기준 없이 SDL을 도입하면 앞서 말한 데이터 늪이 된다.

현재 운영 중인 환경에서 어떤 로그가 SIEM에 들어가고 어떤 게 걸러지고 있는지, 그 판단 기준이 어디서 왔는지를 한번 검토해보는 것이 좋은 출발점이 될 것이다.

For the site tree, see the [root Markdown](https://slashpage.com/blogger.md).