실시간 데이터 파이프라인: 보안 이벤트 탐지로 이해하기

실시간 데이터 파이프라인의 핵심은 데이터를 저장한 뒤 찾는 것이 아니라, 흐르는 동안 판단한다는 데 있다. 이 차이가 가장 선명하게 드러나는 사례가 보안 이벤트 탐지다. 같은 로그를 SIEM이나 로그 저장소에 적재한 뒤 검색으로 찾을 수도 있고, 수집 경로의 파이프라인에서 흐르는 동안 잡을 수도 있다. 흔히 후자가 빠르다고 하는데, 이 글은 그 말을 얼마나 빠르고, 무엇이 그 속도를 만드는가라는 질문으로 바꾸고, 세 갈래로 분해해 하나씩 푼다.

질문의 분해

요약

분해한 질문	답의 핵심
① 왜 느린가	적재·인덱싱 대기, 다음 쿼리 주기 대기, 쌓인 범위의 반복 스캔이 더해진다
② 얼마나 빠른가	수집까지는 같다. 그 뒤 사후 검색은 적재 + 주기 대기 + 스캔을, 실시간은 결과를 내보내는 간격 + 늦은 로그 허용 지연 + 판정만 기다린다. 이 간격은 우리가 설계로 정한다
③-1 위치	수집 경로에서 복제해, 도착하는 순간 한 번 보고 숫자만 갱신한다
③-2 판정 단위	로그 한 줄이 아니라 키별 집계값으로 판정한다
③-3 규모	작업자(파티션)로 나눠 받고 숫자만 누적한다. 핫 키는 2단 집계로 푼다
③-4 시간 구간	창 방식·길이·허용 지연으로 속도와 정확도를 맞춘다
③-5 판정 비용	가벼운 모델로 전수 판정하고 비싼 판단은 소수에만 쓴다. 집계가 놓치는 단일 이상도 여기서 메운다

용어

용어	뜻
키	무엇을 기준으로 묶을지. 예: 출발지 IP, 계정, 호스트
집계(어그리게이션)	같은 키의 이벤트를 건수·평균·최댓값 같은 숫자로 요약하는 것
작업자(파티션)	흐름을 키 기준으로 나눠 받는 처리 단위. 같은 키는 항상 같은 작업자로 간다
증분 집계	원본을 쌓지 않고, 이벤트가 올 때마다 숫자만 갱신하는 방식
윈도우	“여기까지 모아서 본다”는 시간 구간. 텀블링은 끊어서, 슬라이딩·홉핑은 겹쳐서 본다
워터마크·허용 지연	늦게 오는 로그를 얼마나 기다린 뒤 창을 닫을지 정하는 기준
z-score	지금 값이 평소 평균에서 표준편차 몇 배만큼 벗어났는지
섀도 모드	새 모델을 경보에 연결하지 않고 기존 판정과 나란히 돌려 결과만 비교하는 운영 방식

① 왜 느린가

SIEM이나 로그 저장소에서 검색하면 되는데, 그건 왜 느린가?

답: 저장 후 검색은 세 가지 기다림이 더해진다. 로그가 검색 가능해질 때까지(적재·인덱싱), 다음 예약 검색이 돌 때까지(쿼리 주기), 그리고 쌓인 범위를 다시 읽는 시간(스캔)이다.

같은 공격, 두 방식의 탐지 시점

사후 검색의 지연 구성

적재·인덱싱: 로그가 저장소에 들어가 검색 가능한 상태가 되기까지 시간이 걸린다.
쿼리 주기: 예약 검색은 정해진 간격으로 돈다. 공격이 주기 직후에 일어나면 다음 주기까지 기다린다.
스캔: 매번 시간 범위 안의 로그를 다시 읽는다. 수만 대 규모에서는 이 범위가 크고, 주기를 줄여 기다림을 줄이면 스캔 횟수와 비용이 그만큼 늘어난다.

② 얼마나 빠른가

흐르는 동안 판정하면 얼마나 빨라지나?

답: 두 방식은 수집 구간까지는 같고 그 뒤가 갈린다. 사후 검색은 적재 + 쿼리 주기 대기 + 스캔을 기다리고, 실시간 파이프라인은 결과를 내보내는 간격 + 늦은 로그 허용 지연 + 판정 시간만 기다린다. 그래서 실시간의 지연은 기다림이 아니라 설계로 정하는 값이다.

지연을 항목별로 나눈 비교

항목	사후 검색	실시간 파이프라인
수집·전송	공통	공통
저장	적재·인덱싱을 기다린다	없다
기다림	다음 쿼리 주기까지	결과를 내보내는 간격까지 (텀블링 = 창 길이, 홉핑 = 홉 간격, 이벤트 단위 판정 = 거의 0)
늦은 로그	다음 쿼리에 자연히 포함된다	허용 지연만큼 더 기다린다 (③-4)
판정	쿼리 실행과 범위 스캔	숫자 몇 개 비교, 밀리초 이하

실제 차이는 이 표의 각 항을 우리 환경에서 재서 넣으면 숫자로 나온다. SIEM 적재 지연, 예약 검색 주기, 스트림 처리의 창·홉 설정과 허용 지연이다.

③ 무엇이 빠르게 만드나

그 짧은 기다림을 가능하게 하는 기술 요소는 무엇인가?

속도를 만드는 요소는 다섯 가지다. 판정하는 위치(③-1), 판정하는 단위(③-2), 규모를 감당하는 방식(③-3), 시간 구간을 자르는 방식(③-4), 그리고 판정 비용(③-5)이다.

③-1 위치: 쌓인 뒤가 아니라 흐르는 동안

어디에서 판정해야 기다림이 사라지나?

답: 수집 경로에서 같은 흐름을 복제해, 로그가 도착하는 순간 한 번만 보고 들고 있던 숫자 몇 개를 갱신한다.

반복 읽기 vs 한 번 읽고 갱신

사후 검색은 쿼리를 돌릴 때마다 범위 안의 로그를 처음부터 다시 읽고, 범위가 겹치면 같은 로그를 몇 번씩 읽는다. 실시간 파이프라인은 로그 한 건당 한 번만 일하므로, 일의 양이 쌓인 데이터의 크기가 아니라 들어오는 속도에만 비례한다. 그 속도는 작업자(파티션)를 늘려 감당한다(③-3).

SIEM에도 continuous·Live Tail 같은 실시간 기능이 있지 않나?

있다. SIEM의 실시간 규칙도 원리는 같은 스트리밍 탐지다. 우리 파이프라인은 SIEM을 대체하거나 적재량을 줄이지 않는다. SIEM은 정합성과 감사를 위해 전수를 그대로 받고, 우리는 수집 경로에서 같은 흐름을 복제해 먼저 본다. 차이는 속도와 통제권이다.

세 가지 실시간의 위치

Live Tail: tail -f처럼 들어오는 로그를 사람이 보는 화면이다. 집계나 판정이 없고, 예를 들어 Sumo Logic은 초당 약 1,000건, 조직당 동시 세션 10개 같은 제한이 있다. 탐지가 아니라 관찰 도구다.
SIEM 실시간 규칙: 적재·인덱싱을 거친 뒤 벤더가 제공하는 규칙 언어 안에서 판정한다.
우리 파이프라인: 복제본으로 먼저 판정하며 세 가지 통제권을 갖는다.
- 속도: SIEM 적재 지연보다 앞서 탐지한다.
- 우선순위: 어떤 이벤트가 중요한지를 우리 기준과 우리 모델로 분류하고 관리한다.
- 연계 자율성: 판정 결과를 우리 대응 도구, 티켓, 대시보드에 벤더 제약 없이 바로 연결한다.

③-2 판정 단위: 로그 한 줄이 아니라 키별 집계

흐르는 로그 한 줄만 보고 판정할 수 있나?

답: 로그 한 줄은 오타일 수도 있어서 그 자체로는 의미가 없다. 같은 키(예: 출발지 IP)끼리 묶어 일정 구간의 건수·평균·최댓값 같은 숫자로 접어야 패턴이 보인다. 이것이 집계(어그리게이션)다.

묶기 전 vs 묶은 후 · 같은 이벤트

로그 10줄이 표 3줄이 되는 과정

SQL의 GROUP BY ip에 WHERE로 시간 범위를 건 것과 같다. 차이는 이걸 저장된 테이블이 아니라 흐르는 로그 위에서, 창이 닫힐 때마다 한다는 것뿐이다.

세 요소: 키(무엇 기준으로), 윈도우(언제까지 모아서, ③-4), 집계 함수(어떻게 요약할지). 데이터독의 sum·max·avg, Prometheus의 sum by (...) (rate(...[5m]))가 모두 같은 구조다.
파이프라인 안의 자리: 파싱·키 분배 뒤, 판정 앞. 이벤트 여러 줄을 판정 가능한 숫자 하나로 바꾸는 단계다. 단계를 지날수록 데이터는 작아지고 의미가 생긴다.

파이프라인 단계별 데이터 모양

③-3 규모: 나눠 받고, 숫자만 누적한다

수만 대의 로그를 모두 묶어 세면 감당이 되나?

답: 키를 기준으로 흐름을 여러 작업자(파티션)에 나눠 보내고, 각 작업자는 로그를 쌓지 않고 개수·합계 같은 숫자만 누적한다(증분 집계). 그래서 들고 있는 상태가 데이터 양과 상관없이 고정된다.

쌓아두고 다시 세기 vs 흘려보내며 세기

동전 분류기로 비유하면, 구멍 크기로 10원짜리만 거르는 것이 키 분배이고, 동전을 쌓는 대신 저울 눈금(개수, 무게 합)만 더하는 것이 증분 집계다. 동전이 늘면 분류기, 즉 작업자를 나란히 늘리면 된다.

주의: 핫 키 쏠림. 같은 키는 항상 같은 작업자로 가야 집계가 맞는데, 공격은 바로 특정 키의 폭주라서 한 작업자에 일이 몰린다. 키에 번호를 붙여 여러 작업자가 나눠 센 뒤 다시 합치는 2단 집계로 푼다.

핫 키 쏠림과 2단 집계

③-4 시간 구간: 윈도우 설계

얼마 동안 모아서 판정해야 하나?

답: 윈도우는 끝없는 흐름에 “여기까지 모아서 본다”는 구간을 정하는 것이다. 창의 방식과 길이, 그리고 늦은 로그를 얼마나 기다릴지가 탐지 속도와 정확도를 함께 정한다.

텀블링: 겹치지 않게 일정 길이로 끊는다. 단순하지만 경계에 걸친 공격이 반씩 쪼개져 놓칠 수 있다. 결과는 창 길이마다 나온다.
슬라이딩·홉핑: 창을 겹쳐 민다. 홉핑은 일정 간격(홉)마다 창을 밀며 결과를 내므로 결과 간격이 홉으로 짧아진다. 경계 사각지대가 없어지는 대신 겹치는 창들의 상태를 함께 들고 있어야 한다.

창 방식·길이를 바꿔보는 시뮬레이터

텀블링에서 1분, 2분, 5분을 번갈아 눌러보면, 같은 버스트가 창 경계가 어디 떨어지느냐에 따라 잡혔다 놓쳤다 한다. 슬라이딩으로 바꾸면 경계 위치 때문에 놓치는 일은 없다.

늦게 도착하는 로그. 수만 대의 로그는 발생한 순서대로 도착하지 않는다. 창을 언제 닫을지 정하는 기준이 워터마크이고, 창 끝에서 얼마나 더 기다릴지가 허용 지연이다. 오래 기다리면 정확하지만 늦고, 빨리 닫으면 빠르지만 늦은 로그를 놓친다. ②의 지연에 허용 지연이 더해지는 이유다. 창이 닫힌 뒤 온 로그는 버리거나 따로 보정하는 규칙을 정해둔다.

발생 시각과 도착 시각, 워터마크

짧은 창과 긴 창을 함께. 짧은 창은 잡음에 흔들리고, 긴 창은 느리다. 둘 다 임계치를 넘을 때만 경보를 울리면 짧은 창은 “지금도 진행 중”을, 긴 창은 “우연이 아님”을 확인한다. SLO 알림의 multi-window 방식과 같다. 같은 시간대의 평소 값과 비교하면 출퇴근 시간 같은 정상 변동도 걸러낼 수 있다.

짧은 창과 긴 창의 동시 판정

③-5 판정 비용: 가벼운 판정은 넓게, 무거운 판정은 좁게

이렇게 묶어 보면, 다수에 섞인 위조 한두 개는 묻히지 않나?

답: 집계는 다수의 경향을 보는 도구라 드문 단일 이상에 약하다. 그래서 이벤트마다 가벼운 판별 모델로 점수를 매기고 그 점수를 집계한다. 비싼 판단(LLM)은 걸러진 소수에만 쓴다.

평균 vs 최댓값 vs 개별 판별 · 같은 창

잘게 나누기: 전체가 아니라 서버·계정별로 묶으면, 한 키 안에서 위조 하나가 훨씬 잘 튄다.
평균 말고 다른 통계: 최댓값, 고유 개수, 처음 보는 값. 부록의 확률 자료구조가 이것을 작은 메모리로 해낸다.
개별 판별 후 집계: 판별 모델이 이벤트마다 의심 점수를 매기고, 집계는 “의심 점수가 5분 새 얼마나 몰렸나”를 본다.

왜 이 단계에 LLM을 쓰지 않나. LLM은 판단력은 좋지만 앞단의 시간 예산과 비용에 맞지 않는다.

시간 예산과 깔때기

시간 예산: 초당 수만 건이 흐르는 앞단에서는 한 건을 판단할 시간이 아주 짧다. 수치 모델은 마이크로초 단위로 끝나지만, LLM 호출은 수백 ms 이상 걸려 흐름을 따라가지 못한다.
비용: 모든 이벤트에 LLM을 부르면 호출 비용이 이벤트 수에 그대로 비례한다.
일관성: 탐지는 같은 입력에 같은 판정을 내야 재현과 감사가 된다. 수치 모델은 결정적이고, LLM은 그렇지 않을 수 있다.
LLM의 자리: 걸러진 소수의 의심 건을 맥락과 함께 설명하고 조사하는 뒷단, 깔때기의 좁은 끝이다.

수치 모델과 LLM 사이에 학습된 판별 모델을 한 단 더 두는 방법은 다음 장에서 다룬다.

판별 모델 확장: 인코더와 결정 모델

③-5의 수치 모델이 못 보는 로그의 의미와 순서를 보려면, 학습된 판별 모델을 한 단 더 둔다. 후보는 두 부류다. 로그를 임베딩해 이상 점수를 내는 인코더, 그리고 상태와 정해진 선택지를 받아 확률이 붙은 판정을 돌려주는 결정 모델(decision model)이다. JEV가 결정 모델의 대표적인 예이고, 오픈 구현도 나오고 있다. 대체가 아니라 계층 추가다.

인코더·결정 모델을 넣은 계층 구조

무엇을, 어디에 쓰나

	인코더 (BERT 계열)	결정 모델 (예: JEV)
입력	로그 문장, 키별 창의 이벤트 시퀀스	구조화된 상태 + 정해진 선택지
출력	임베딩, 이상 점수	타입이 정해진 판정 + 확률
적용 포인트	처음 보는 로그 유형 탐지, 순서 이상(로그인 → 권한 상승 → 외부 접속), 비슷한 경보 묶기	후보 트리아지(정상/의심), 경보 유형 분류와 도구 라우팅, LLM 검토 전 정상 확정
속도	밀리초, 배치·GPU	호출당 수십~수백 ms (JEV 기준 약 70~500ms)
학습	정상 로그로 자기지도 학습, 주기적 재학습	학습 없이 질문 설계만
실행 위치	사내	모델에 따라 외부 API 또는 사내 배포

장점과 한계

인코더

장점: 로그의 의미와 순서를 본다. 추론이 결정적이라 재현과 감사가 된다. 라벨 없이 정상 로그만으로 학습하고, 데이터가 사내를 떠나지 않는다.
한계: 학습과 재학습을 우리가 운영해야 한다. 배포·구성 변경마다 정상의 모양이 바뀐다(드리프트). 임베딩 거리만으로는 설명이 약해, 어떤 이벤트가 점수를 올렸는지 함께 내보내야 한다. 전수 적용은 불가능하다.

결정 모델

장점: 학습 없이 질문 설계만으로 바로 적용한다. 출력이 정해진 타입과 확률이라 경보·에스컬레이션 정책과 자동화에 그대로 연결된다. 라벨이 없는 새 공격 유형에도 질문을 바꿔 대응한다. 범용 LLM보다 빠르고 저렴하다.
한계: 정밀도와 확률 보정이 도메인마다 달라 직접 검증해야 한다. 질문 문구와 입력 구성에 결과가 민감하다. 새로 나온 부류라 근거가 대부분 탐색적 단계다. 외부 API형을 쓰면 보안 로그 반출과 벤더 의존이 더해진다.

판정 정확도: 아직은 도메인마다 검증이 필요하다

결정 모델의 정확도는 공개된 사례마다 편차가 크다. 아래는 모두 JEV 기준이고, 대부분 출시 직후의 탐색적 연구다.

사례	결과	시사점
분석 지표 이상 탐지 (Amplitude)	의미 있는 이상은 모두 잡았지만 정밀도가 낮았다. 791건 판정 연구에서는 정답 라벨보다 프런티어 모델과 6~8%p 더 자주 일치했다	재현율은 높고 오탐은 많다. 정답보다 다른 모델을 닮는다
수도망 SCADA 원인 판별 (HydroJEV)	규칙 트리로 확인된 정상 판정만 받아들였을 때, macro-F1 손실 없이 LLM 검토량을 35~38% 줄였다. 숨겨진 공격에는 여전히 LLM 검토가 필요했다	확신 정상을 걸러내는 데 강하고, 교묘한 공격 판정은 맡기기 어렵다
센서 기반 행동 인식	지도 학습 분류기에 크게 뒤졌고, 확률 보정도 안정적이지 않았다	수치 신호 위주 입력에서는 약하다
영상 이상 탐지 (캡션 기반)	평균 정밀도 약 76%로, 비교한 Qwen 기반 방식(약 48~58%)보다 높았다	텍스트로 옮긴 상태에서는 범용 LLM의 확률보다 낫다

왜 단일 판단 게이트로 쓰지 않나

단일 게이트 vs 트리아지

우리 도메인에서의 정밀도·보정이 검증되지 않았다. 위 사례처럼 오탐이 많거나 확률이 어긋나면, 단일 게이트에서는 그 오차가 그대로 경보 폭주나 미탐이 된다.
놓친 공격을 다시 볼 기회가 없다. 게이트 하나가 정상이라고 하면 아무도 다시 보지 않는다. 숨겨진 공격일수록 놓치기 쉽다는 사례와 정확히 걹친다.
공격자가 노릴 지점이 하나가 된다. 입력이 텍스트로 된 상태라, 로그에 판정을 흔드는 문자열을 섞는 식의 우회는 그 한 곳만 뚫으면 된다. 수치 모델·규칙과 겹쳐 두면 하나를 속여도 다른 층이 잡는다.
재현과 감사가 어렵다. 외부 모델은 버전이 바뀌면 같은 입력의 판정도 바뀔 수 있다. 연구들도 버전을 고정해 평가했다. 차단 근거가 벤더의 버전에 묶이면 사후 감사가 흔들린다.
처리량과 장애. 호출당 수십~수백 ms라 전수 판정이 안 되고, 외부 API가 멈추면 게이트 전체가 멈춘다.

그래서 결정 모델은 통과·차단을 정하는 문지기가 아니라 분류원으로 쓴다. 확신 정상은 규칙으로 한 번 더 확인한 뒤 종료하고, 불확실한 건 LLM이나 사람에게, 의심은 경보로 보낸다. 최종 차단은 결정 모델 단독으로 정하지 않는다.

운영 원칙

0단은 전수 그대로, SIEM 전수 적재도 그대로 둔다.
결정 모델에는 원본 로그 대신 요약 상태(키, 창별 지표, 이벤트 유형 시퀀스)를 넣는다. 입력이 작고 구조적일수록 판정이 안정되고, 외부형을 쓸 때 반출 범위도 작아진다.
결정 모델의 “확신 정상”은 규칙으로 한 번 더 확인된 것만 종료한다.
새 모델은 섀도 모드로 기존 판정과 나란히 돌려 오탐·미탐을 비교한 뒤 경보에 연결한다.
가능하면 모든 단계를 사내에서 돌리고, 외부 모델을 쓸 때는 반출 경계를 한 곳으로 제한한다.

참고(결정 모델 사례, JEV 기준): Jev-IDS · HydroJEV · Amplitude의 결정 모델 분석 · 보정 한계(HAR) · 영상 이상 탐지 비교

부록: 앞단에 쓰는 가벼운 모델과 자료구조

앞단의 도구들은 모두 이벤트당 몇 번의 연산과 작은 고정 메모리로 돈다.

도구	답하는 질문	키당 들고 있는 상태	대가
EWMA + z-score	평소보다 얼마나 벗어났나	숫자 2개(평균, 분산)	천천히 늘리는 공격에 기준선이 따라 올라감
Isolation Forest	지표들의 조합이 이상한가	학습된 나무 묶음	피처 설계 의존, 설명력 약함, 주기적 재학습
Bloom Filter	처음 보는 값인가	비트 배열	“봤을 수도”는 틀릴 수 있음
Count-Min Sketch	얼마나 자주 봤나	카운터 표	실제보다 크게 셀 수 있음
HyperLogLog	고유한 값이 몇 개인가	약 12KB 버킷	1% 안팎 오차

EWMA와 z-score

EWMA와 ±3σ 띠 · 분당 건수 예시

새 값이 올 때마다 평균을 조금씩만 갱신해서, 창 없이도 최근을 더 중시하는 평균을 만든다.

\mu_t = \alpha x_t + (1-\alpha)\mu_{t-1}, \qquad z = \frac{x_t - \mu}{\sigma}

분당 로그인 실패가 평소 3 ± 1건인 서버에서 12건이 오면 z = 9다. α가 크면 짧은 창처럼 민감하고 작으면 긴 창처럼 둔하다. ③-4의 “얼마 동안 모아서 보느냐”가 α 선택으로 바뀐다. 이벤트마다 갱신하므로 결과를 기다리는 간격이 거의 없다.

Isolation Forest

정상점 vs 이상점 · 고립까지 필요한 분할 횟수

무작위로 자를 때 몇 번 만에 혼자 남는지가 이상 점수다. 나무 수십~수백 그루의 평균 깊이를 쓴다.

강점은 여러 지표를 함께 본다는 것이다. 로그인 실패 수, 고유 목적지 IP 수, 외부 전송량, 새 프로세스 수가 각각은 평범해도 조합이 이상한 경우를 잡는다. 라벨 없이, 대부분이 정상인 데이터로 학습하고 이상치가 조금 섞여 있어도 된다.

Bloom Filter, Count-Min Sketch, HyperLogLog

Bloom Filter · Count-Min Sketch · HyperLogLog 동작 원리

정확도를 조금 내주고 메모리를 극단적으로 아끼는 확률 자료구조다.

Bloom Filter: “봤을 수도 있음” 또는 “확실히 처음 봄”으로 답하는데, 뒤쪽은 틀리지 않는다. 한 번도 안 보던 프로세스나 명령어를 확실하게 잡는다.
Count-Min Sketch: 카운터 표 여러 줄에 해시마다 1씩 더하고, 조회 땐 그 칸들의 최솟값을 쓴다. 극히 드문 값을 의심하는 데 쓴다.
HyperLogLog: 해시 앞자리에 0이 10개 연속 나왔다면 대략 2¹⁰가지는 봤다고 추정하는 원리다. 동전 앞면이 10번 연속 나왔다면 꽤 많이 던졌겠다는 것과 같다. 서버별 5분간 고유 목적지 IP 급증은 포트 스캔이나 내부 확산 신호다.

세 구조 모두 합칠 수 있다. 작업자 수십 대가 각자 만든 결과를 더하면 전체 결과가 되며, ③-3에서 작업자를 나란히 늘리고 핫 키를 2단 집계로 나눌 수 있는 이유다.

함께 쓰면

이벤트가 들어오면 Bloom Filter로 처음 본 값인지, Count-Min Sketch로 얼마나 드문지 확인한다.
서버별로 HyperLogLog(고유 개수)와 EWMA(평소 대비 편차)를 갱신한다.
모은 지표를 Isolation Forest에 넣어 조합이 이상한지 점수를 매긴다.
점수가 높은 소수만 다음 계층(인코더·결정 모델, 그다음 LLM)으로 넘기고, 판정 결과는 우리 대응 도구로 연결한다. SIEM은 이와 별개로 전수를 그대로 받는다.

부록: 마이크로배치였다면?

같은 파이프라인을 마이크로배치로 짠다면 골격은 그대로고, 판정하는 타이밍만 계단식으로 바뀐다. 이벤트가 도착해도 다음 배치(트리거)가 돌 때까지 기다렸다가 묶어서 처리하기 때문이다.

이벤트 단위 스트리밍 vs 마이크로배치

그대로인 것

키 분배, 윈도우, 집계, 워터마크, 핫 키 문제, 계층형 판별까지 문서의 골격은 그대로다. 마이크로배치도 상태를 이어서 들고 가는 증분 처리라, 매 배치는 새로 들어온 분량만 읽고 기존 집계값에 더한다. ①의 사후 검색처럼 쌓인 범위를 반복 스캔하는 구조와는 여전히 다르다.

바뀌는 것

항목	이벤트 단위 스트리밍	마이크로배치
② 지연	수집 + 내보내기 간격 + 허용 지연 + 판정	수집 + 트리거 간격 + 배치 처리 시간 + 허용 지연
③-1 판정 시점	도착 즉시	다음 배치에서
③-4 결과 간격	창·홉 설정대로	트리거 간격보다 짧아질 수 없다
③-5 학습 모델	이벤트마다 호출, 묶어 보내는 설계가 따로 필요	배치 추론이 자연스럽고 GPU 효율이 좋다

Spark는 예시로 적합한가

적합하다. Spark Structured Streaming의 기본 실행 방식이 마이크로배치라 대표적인 예다. 다만 최근 변화는 알고 쓰는 게 좋다. 오픈소스인 Apache Spark 4.1(2025년 12월)에 Real-Time Mode가 들어와 밀리초 수준 지연이 가능해졌다. 다만 오픈소스에서의 지원은 projection·필터·UDF 같은 상태 없는 처리 중심이고, 상태 있는 처리까지 포함한 저지연은 Databricks에서 2026년 3월 GA로 발표됐다. 윈도우 집계처럼 상태가 핵심인 이 파이프라인을 오픈소스 Spark로 짠다면 마이크로배치 쪽으로 보는 게 맞다.

이 파이프라인에서 채택하지 않을 만한 이유

지연 하한이 트리거 간격에 묶인다. 이 파이프라인의 존재 이유는 SIEM 적재보다 앞서 탐지하는 것이다. 트리거가 초 단위면 그 차이가 줄고, 특히 0단의 이벤트 단위 신호(처음 보는 프로세스, EWMA 이탈)처럼 바로 울릴 수 있는 경보까지 배치 경계를 기다리게 된다.
폭주할 때 밀린다. 배치 처리 시간이 트리거 간격을 넘으면 다음 배치가 밀리며 지연이 쌓인다. 공격은 곧 특정 키의 폭주(③-3)라서, 경보가 가장 필요한 순간에 가장 느려지는 문제가 더 커진다.
수집 경로에 붙이기에 무겁다. 드라이버·익스큐터 클러스터, 체크포인트 저장소, 셔플을 상시 운영해야 한다. 앞단의 가벼운 탐지기로는 운영 부담이 크다.
저지연 모드의 범위. 오픈소스 Real-Time Mode는 상태 없는 처리 중심이라, 윈도우 집계 같은 상태 처리를 저지연으로 돌리려면 특정 플랫폼에 묶인다.

그래도 맞는 경우

몇 초에서 수십 초의 지연이 허용되는 탐지, 인코더처럼 배치 추론이 유리한 1단 이후의 계층, 그리고 이미 Spark를 운영 중이라 별도 엔진을 들이기 어려운 경우다. 계층별로 엔진을 나눌 수도 있다. 0단은 이벤트 단위 스트리밍으로, 1단 이후는 마이크로배치로.

참고: Databricks, Real-Time Mode GA 발표 · Databricks, Real-Time Mode 아키텍처

도식의 수치와 로그 예시는 설명용입니다. 실제 값은 운영 환경에서 측정해 채워 넣을 예정입니다.