왜 AI는 여전히 보안 운영 센터(SOC)에서 기대에 미치지 못하는가

CoreProse KB-incidents에 처음 게시됨. 보안 운영 센터(SOC)는 분류(Triage), 조사(Investigation), 대응(Response)을 위해 AI를 도입해 왔지만, 평균 대응 시간(MTTR)은 여전히 높고, 분석가들은 번아웃(Burnout)을 겪고 있으며, 실제 공격은 여전히 성공하고 있습니다. 문제는 AI가 단독으로 작동하느냐가 아니라, 왜 현재의 배포 방식이 놓치는 사고를 줄이거나, 더 빠른 대응을 제공하거나, 인간의 업무 부하를 낮추는 데 거의 기여하지 못하는가 하는 점입니다. 이 글에서는 SOC 성능을 정의하는 데이터 흐름, 아키텍처(Architecture), 플레이북(Playbook), 그리고 인간의 제약 조건을 살펴보고, 탐지(Detection), 결정(Decision), 조치(Action) 사이의 루프를 실제로 완성할 수 있는 구체적인 LLM/에이전트형 AI(Agentic AI) 패턴을 제시합니다.

1. 오늘날의 SOC에서 AI가 실제로 도움을 주는 부분

현대적인 SOC AI는 주로 세 가지 워크플로우(Workflow)를 지원합니다:

• SIEM 및 EDR 경보 분류 (Alert Triage)
• 경보 후 조사 및 보강 (Post-alert Investigation and Enrichment)
• 사고 대응 오케스트레이션 및 케이스 관리 (Incident Response Orchestration and Case Management)

조사 및 상관관계 분석에서의 현재 강점
오늘날의 도구들은 이미 SIEM, EDR, ID(Identity), 이메일, 클라우드 전반의 경보를 상관관계 분석(Correlate)하여 일관된 케이스 뷰(Case View)를 제시할 수 있습니다.[1]
분석가들은 종종 다음과 같은 정보로 시작합니다:

• 병합된 사고 타임라인 (Merged Incident Timeline)
• 정규화된 자산 및 사용자 ID (Normalized Asset and User Identities)
• 강조된 "주요 이벤트" (권한 상승, 측면 이동, 위험한 로그인 등)
  많은 플랫폼은 탐지(Detection)와 조치(Action)가 축적됨에 따라 케이스의 진화 과정을 자동으로 추적합니다.[1]

💡 Callout — AI의 주요 입증된 가치
AI는 마법처럼 "모든 공격을 찾아내는 것"이 아니라, 복잡한 텔레메트리(Telemetry)를 명확한 조사 시작점으로 전환하는 데 가장 신뢰할 수 있습니다.[1][7]

반복적인 단계의 자동화
자동화 프레임워크와 결합된 AI는 일반적으로 다음 작업을 대신 수행합니다:

• 경보를 적절한 큐(Queue)로 라우팅
• 보강 정보 가져오기 (WHOIS, VT, EDR 트리, IAM 속성 등)
• 표준 점검 실행 (차단 목록, 지리적/MFA 이상 징후)
• 케이스 필드 및 알림 업데이트
  결정론적 자동화(Deterministic Automation)는 반복 가능한 작업을 처리하며, "선제적 AI(Proactive AI)"는 승인된 플레이북을 통해 분석가에게 단서를 제공하고 안내합니다.[1] 이는 커스텀 스크립팅과 수동 분류 로직을 줄여줍니다.

경보 감소(Alert reduction)에서 입증된 성과
실제로 AI와 더 스마트한 탐지(Detection)를 결합하면 다음과 같은 효과를 얻을 수 있습니다:

• 일일 경보(Alert) 수를 1,000개 이상에서 실행 가능한 결과(Actionable findings)인 한 자릿수 단위로 단축
• 일부 Elastic Security 배포 환경에서 오탐(False positives)을 약 75% 감소[3]
  이러한 규모 축소를 통해 분석가는 한 교대 근무 시간 내에 훨씬 더 많은 유의미한 신호(Signal)를 검토할 수 있습니다.

📊 강조 — 약속이 아닌 실제 수치
결합된 탐지(Detection)와 AI 분류(Triage)는 이미 일부 환경에서 오탐을 약 75% 줄이는 동시에 원시 경보(Raw alert) 볼륨을 수십 배(Orders of magnitude) 감소시켰습니다.[3]

분류(Triage) 및 오케스트레이션(Orchestration)을 위한 AI 에이전트
에이전트형 AI(Agentic AI) 설계는 이제 다음과 같은 기능을 수행하는 "Tier-0 분류(Triage)" 계층으로 작동합니다:[4]

• SIEM 경보를 유형 및 심각도별로 분류
• 자산/사용자 컨텍스트 및 이력으로 정보 보강(Enrich)
• 초기 SOAR 작업(티켓 생성, 격리, 계정 잠금 등) 제안 또는 트리거
  이러한 에이전트들은 SIEM/SOAR에 직접 연결되어 초기 작업의 상당 부분을 전방 배치(Front-loading)합니다.[4]

성숙한 로그 분석 파이프라인
텔레메트리(Telemetry) 측면에서는 AI 지원 파이프라인이 구축되어 있습니다:[7][8]

• 파싱(Parsing) 및 정규화(Normalization)
• 베이스라인(Baselines) 대비 머신러닝(ML) 기반 이상 탐지(Anomaly detection)
• 로그 설명, 쿼리 생성 및 공격자 경로 가설 설정을 위한 LLM 활용
  이제 제한 요인은 모델의 역량이 아니라 데이터 품질과 워크플로 통합(Workflow integration)입니다.[7][8]

2. 실제 SOC 운영에서의 성능 격차 증거
   이러한 발전에도 불구하고, SOC는 여전히 어려움을 겪고 있습니다.

“경고 확인(confirmed alert)” 이후의 느린 대응
많은 SOC(Security Operations Center)는 경고를 확인한 직후부터 지연이 발생한다는 사실을 발견합니다.[1] 분석가는 다음 작업을 수행해야 합니다:

• SIEM, EDR, IAM, 이메일 및 클라우드 도구로부터 추가적인 컨텍스트(Context) 추출
• 케이스(Case) 및 상태 업데이트
• 인프라, 애플리케이션 및 비즈니스 팀 간의 조율
  AI는 분석 속도는 높여주지만, 대부분의 시간이 낭비되는 지점인 도구 간의 실행 및 승인 단계는 가속화하지 못하는 경우가 많습니다.[1]

📊 Callout — 탐지 이후의 병목 현상
많은 SOC의 지연 시간은 탐지 단계가 아니라, 분석가가 위협을 이해한 후 도구 간의 조율과 케이스 유지 관리 과정에서 발생합니다.[1]

파편화된 기록 시스템
SIEM, SOAR, 티켓팅(Ticketing) 및 채팅 시스템이 동기화되지 않을 때:[1]

• 팀은 “언제 무엇이 일어났는지”를 끊임없이 재구성해야 합니다.
• 분석가들은 작업을 중복 수행하며 대응을 주저하게 됩니다.
• LLM(Large Language Model) 요약은 일관성 없는 기록을 해결하는 것이 아니라, 단지 그 기록을 설명할 뿐입니다.

경고 과부하 및 알람 피로(Alarm Fatigue)
대기업을 대상으로 한 FireEye의 조사에 따르면 다음과 같은 결과가 나타났습니다:[2]

• 37%는 월 10,000개 이상의 경고를 수신함
• 52%는 오탐(False Positives)임
• 64%는 중복된 정보임
  이러한 노이즈는 알람 피로를 유발하며, 운영자는 경고를 무시하거나 자동으로 해제해 버립니다.[2]

⚠️ Callout — 콘솔의 신뢰성을 잃을 때
높은 오탐률과 중복률은 “알람 피로”를 유발하며, 이로 인해 운영자가 경고를 더 이상 신뢰하지 않게 되어 실제 공격이 통과되는 상황이 발생합니다.[2]

인적 번아웃과 무시되는 경고
연구 보고서에 따르면:[3]

• SOC 직원의 71%가 번아웃을 겪고 있으며 압도당하는 기분을 느낍니다.
• 상당수의 경고가 무시됩니다.
• 교대 근무가 진행됨에 따라 탐지 정밀도가 떨어집니다.
  수동 처리와 인지 부하(Cognitive Load)를 획기적으로 줄이지 못한 채, 단순히 대시보드나 분류 기능만 추가하는 AI는 이 상황을 바꾸지 못합니다.

AI로 기존의 파편화를 재현함
전통적인 SOC는 고립된(Siloed) 대시보드들 사이에서 인간이 상관관계를 분석해야 하는 제약이 있었습니다.[6] 많은 “AI SOC” 설계는 단순히 동일한 사일로(Silo) 위에 LLM을 덧붙이는 방식에 불과하며, 그 결과:

• 구조적 병목 현상이 그대로 남습니다.
• 인간의 대역폭(Bandwidth)과 파편화가 여전히 성능의 한계로 작용합니다.[6][7]
  결국 AI는 줄어들지 않은 노이즈, 망가진 워크플로우, 그리고 지친 인간이라는 벽에 부딪히게 됩니다.

3. 근본 원인: 데이터 품질, 플레이북(Playbooks), 그리고 인간적 요인
   눈에 보이는 문제들은 더 깊은 시스템적 문제에서 기인합니다.

플레이북(Playbooks): 잘못된 것을 가속화함
플레이북(설계도)은 탐지(Detection), 분석(Analysis), 그리고 조치(Remediation) 전반에 걸친 SOC 프로세스를 인코딩합니다.[2] 만약 플레이북이 다음과 같다면:

• 불완전하거나 구식인 경우
• 기계가 읽을 수 있는 워크플로우(Workflows)가 아닌 산문(Prose) 형태로 작성된 경우

AI 에이전트는 일관성이 없거나 결함이 있는 대응만을 가속화할 뿐입니다.[2]

💼 Callout — 산문에서 실행 가능한 플레이북으로
표준화된 기계 판독형 플레이북이 없다면, AI는 다음 단계를 추측해야만 합니다. 이는 사고(Incident) 발생 시 정확히 피해야 할 상황입니다.[2]

지저분하고 이질적인 텔레메트리(Telemetry)
많은 SOC가 노이즈가 많고 정규화(Normalization)가 제대로 되지 않은 텔레메트리를 AI에 공급합니다:[2][7]

• 취약한 정규화 및 중복 제거(Deduplication)
• 도구 간의 일관되지 않은 스키마(Schemas)

이는 다음과 같은 요소들을 저해합니다:

• 이상 징후 모델(Anomaly models)에 대한 신뢰도
• 도구 간의 신뢰할 수 있는 상관관계 분석(Cross-tool correlation)
• 예측 가능한 SOAR 및 에이전트 동작

정보 과잉(Infobesity) 대 이해의 깊이
텔레메트리 양은 계속해서 폭발적으로 증가하며, 인간의 능력을 초과하는 "정보 과잉(Infobesity)"을 초래합니다.[7] AI는 종종 다음과 같은 방향으로 최적화됩니다:

• 더 많은 소스 수집(Ingesting)
• 더 많은 상관관계 노출(Surfacing)

...자산(Assets), 신원(Identities), 그리고 행위(Actions)에 대한 정밀하고 검증된 사실을 선별하는 대신 말입니다. 이로 인해 강력한 모델조차 실제 조사 과정에서의 검색(Retrieval)과 추론(Reasoning)에서 실패하게 됩니다.[7][8]

챗봇이 아닌 구조적 계층으로서의 AI
신뢰성을 확보하기 위해서 AI는 단순한 채팅 오버레이(Chat overlay)가 아니라, SOC 아키텍처의 구조적 계층(Structural layer)이 되어야 합니다.[7][1]
단순히 덧붙여진(Bolted-on) LLM은 일반적으로 다음과 같은 문제를 가집니다:

• 권위 있는 데이터에 대한 통제된 접근 권한 부족
• 도구 전반에 걸친 케이스 무결성(Case integrity) 보장 불가
• 실제 SIEM/SOAR 상태와의 괴리(Drift)

인간의 신뢰와 피로 역학
과부하와 번아웃은 분석가들을 다음 두 가지 상태 중 하나로 몰아넣습니다:[3]

• AI를 과도하게 신뢰함 (결정을 기계적으로 승인하는 'Rubber-stamp' 방식)
• AI를 무시함 (출력값을 노이즈로 취급)

초기의 낮은 정밀도(Precision)는 신뢰를 영구적으로 손상시킬 수 있으며, 이후에 성능이 개선되더라도 결코 제대로 평가받지 못할 수도 있습니다.

⚠️ Callout — 설계 목표로서의 신뢰: 분석가가 AI가 언제 신뢰할 수 있는지 예측할 수 없다면, 모든 것을 승인하거나 혹은 모든 것을 무시하게 됩니다. 두 경로 모두 SOC의 성과를 저하시킵니다.[3]

엄격한 평가의 부족: 베스트 프랙티스 가이드(Best-practice guides)는 로그 분석 및 탐지를 위한 명확한 방법론과 지표를 강조합니다.[8] 많은 SOC가 다음과 같은 요소가 부족합니다:

• 기준 정밀도/재현율 (Baseline precision/recall)
• 과거 사고에 대한 백테스트 (Back-tests on historical incidents)
• 탐지 로직에 대한 변경 관리 (Change control for detection logic)[8]

LLM (Large Language Models)이 전문성 격차를 좁혀감에 따라, 모델의 성능이 아닌 데이터 아키텍처(Data architecture)와 오케스트레이션(Orchestration)이 제한 요인이 됩니다.[6][7]

4. 성능 격차를 해소하거나 — 혹은 만들어내는 — AI 아키텍처 (AI Architectures)
   아키텍처는 AI가 복잡성을 줄일지, 아니면 배가시킬지를 결정합니다.

참조 설계: AI 트리아지 에이전트 (AI triage agents)
전형적인 SOC 에이전트 아키텍처는 다음을 관리합니다:[4]

• 자동화된 SIEM 경보 트리아지 (Automated SIEM alert triage)
• 위협 인텔리전스(Threat intel), CMDB, IAM으로부터의 컨텍스트 보강 (Context enrichment)
• 인시던트 자격 검증 (실제인가? 심각도는? 유형은?)
• SOAR 기반 대응 조치

주요 실패 모드:[4]

• 오분류 (Misclassification) → 실제 공격이 낮은 등급으로 강등됨
• 컨텍스트 누락 (Missing context) → 과도하게 노이즈가 많거나 보수적인 트리아지
• 안전하지 않은 오케스트레이션 (Unsafe orchestration) → 잘못된 자산/사용자에게 영향을 미침

💡 Callout — 실패 지점을 매핑하고 완화하십시오
오분류, 컨텍스트 누락, 또는 안전하지 않은 조치가 어디에서 발생할 수 있는지, 그리고 각각이 어떻게 제한되는지를 명시적으로 알고 있어야 합니다.[4][7]

모델 간 책임 분할
로그 파이프라인은 다음과 같을 때 가장 견고합니다:[8]

• 전통적인 ML (Machine Learning)이 구조화된 이상 탐지 (Structured anomaly detection)를 처리할 때
• 규칙(Rules)이 알려진 악성 시그니처 및 패턴을 다룰 때
• LLM이 설명, 쿼리 생성, 측면 이동 가설(Lateral-movement hypotheses)을 다룰 때
  이는 단일 파운데이션 모델 (Foundation model)에 대한 과도한 의존을 방지하고 평가를 단순화합니다.[8]

정규화된 텔레메트리 및 SOAR 상의 오케스트레이터
현대적인 설계는 LLM 오케스트레이터를 다음 상위에 배치합니다:[6]

• 정규화된 텔레메트리/데이터 계층 (Normalized telemetry/data layer)
• 실행을 위한 SOAR 플랫폼
  오케스트레이터는 가공되지 않은 탐지 결과(Raw detections)를 권장 워크플로로 전환합니다.[6]
  하지만 기반 데이터가 불완전하거나 일관되지 않다면, 이는 단지 사각지대를 자동화할 뿐입니다.[6][1]

에이전틱 AI (Agentic AI): 기회와 공격 표면
에이전틱 AI는 대응 속도를 획기적으로 높일 수 있지만, 동시에 다음과 같은 문제를 일으킬 수 있습니다:[5]

보안 및 신뢰성 리스크 증가
그 자체로 고가치 타겟이 됨. SOC 에이전트가 침해당한다는 것은 방어 자동화 구조(defense automation fabric) 자체가 침해됨을 의미합니다.[5]

⚠️ Callout — 에이전트를 핵심 관리자(crown-jewel admins)처럼 취급하십시오. 최상위 관리자 계정처럼 SOC 에이전트를 인벤토리화하고, 강화(harden)하며, 모니터링하십시오. 그리고 공격자가 에이전트를 목표로 삼을 것이라고 가정하십시오.[5]

에이전트 동작을 위한 가드레일 (Guardrails)
대부분의 팀은 에이전틱 동작(agentic behavior)을 관리하는 방법을 여전히 학습 중입니다.[5] 가드레일에는 다음 사항이 포함되어야 합니다:

• 최소 권한 원칙(Least-privilege), 범위가 제한된 도구 액세스
• 파괴적인 작업(격리, 권한 취소, 대량 차단)에 대한 인간의 승인
• 에이전트 활동 자체에 대한 전체 로깅 및 이상 탐지(anomaly detection) 포함[5][4]

프로토콜, 상태 머신(state machines), 그리고 신뢰할 수 있는 단일 출처(source of truth)로서의 케이스
"프로토콜을 통한 자율성"으로의 이동은 다음 사항과 일치합니다:[7]

• 구조화된 도구/함수 호출 (Structured tool/function calling)
• 명시적인 의존성 및 전제 조건
• 공식적인 사고 상태 머신 (탐지(DETECTED) → 분류(TRIAGED) → 봉쇄(CONTAINED) → 제거(ERADICATED))
  케이스 관리(case management)를 단일 신뢰 출처(single source of truth)로 취급하고 에이전트가 이를 동기화하도록 만드는 아키텍처는, 더 신뢰할 수 있는 타임라인과 감사 가능한(auditable) 결정을 생성합니다.[1][4]

5. SOC에서의 AI 성능 측정: 지표, 벤치마크 및 실패 모드
   명확한 지표가 없다면, AI는 고통을 제거하는 대신 단순히 고통의 위치를 옮길 뿐일 수 있습니다.

탐지 및 분류(triage) 지표
Elastic의 템플릿을 따라 다음을 추적하십시오:[3]

• 원시 경보(Raw alert) 볼륨
• 조치 가능한 결과(Actionable findings) 수
• 오탐률(False-positive rate) 및 감소율
  AI 배포는 다음 항목에서 명확한 차이(deltas)를 보여주어야 합니다:
• 일일 경보 수
• 오탐률
• 사고당 분석가 소요 시간[3]

📊 Callout — 도입 전/후의 증거를 요구하십시오. 만약 벤더가 경보 볼륨과 오탐에 대한 도입 전/후 지표를 보여줄 수 없다면, 그들은 당신의 방어 핵심부에 블랙박스를 믿으라고 요구하는 것입니다.[3][8]

노이즈 감소 기준선 (Noise reduction baselines)
일반적인 기준선(오탐 52%, 중복 경보 64%[2])을 고려할 때, AI 솔루션은 최소한 선도적인 노이즈 감소 성능과 일치해야 합니다.

그렇지 않으면, 실질적인 신호 대 잡음비(Signal-to-Noise Ratio)의 이득 없이 복잡성만 증가하게 됩니다.[2] 지연 시간(Latency) 및 작업량 실험 로그 분석 방법론을 차용하여:[8]

• 경보(Alert) 도착부터 분류(Triage) 결정까지의 시간 측정
• AI 도입 전후의 사고당 분석가 소요 시간 비교
• 라벨링된 과거 사고에 대한 정밀도(Precision)/재현율(Recall) 평가

운영 및 인적 지표 운영 마찰(Operational friction) 지표에는 다음이 포함됩니다:[7]

• 사고당 열린 도구의 수
• 사고당 컨텍스트 스위칭(Context switches) 횟수
• L1/L2/L3 간의 에스컬레이션(Escalation) 비율

인적 지표는 다음을 핵심 신호(First-class signals)로 취급해야 합니다:[3]

• 번아웃(Burnout) 설문 점수
• 초과 근무 시간
• 무시된 경보의 비율
  ...스트레스 상황에서의 인적 오류는 주요 실패 벡터(Failure vector)이기 때문입니다.

데이터 및 오케스트레이션(Orchestration) 품질 KPI 아키텍처가 제한 요소라면 다음을 추적하십시오:[6]

• 완전한 자동 첨부 컨텍스트(자산, 사용자, 최근 활동)가 포함된 경보의 비율[6][1]
• 사후 분석(Postmortem) 시 타임라인 재구성 오류율
• 데이터 누락으로 인해 AI의 권고가 차단된 사고의 비율

에이전트(Agent)를 위한 안전 및 거버넌스 에이전트형 AI(Agentic AI)의 경우 다음을 모니터링하십시오:[4][5]

• 인간의 승인이 필요한 작업의 수 및 유형
• 범위를 벗어난 작업 시도의 빈도
• 에이전트 설정 오류 또는 악용 시도와 관련된 사고

⚡ 콜아웃 — 실시간 신호로서의 거버넌스
에이전트 안전은 일회성 체크리스트가 아니라 지속적인 모니터링 과제입니다. 에이전트의 지표를 핵심 침입 탐지 시스템(IDS) 신호처럼 취급하십시오.[5][4]

6. 구현 청사진: AI 보조(AI-Assisted)에서 AI 증강(AI-Augmented) SOC로
   “우리는 AI 위젯을 가지고 있다”에서 진정으로 AI가 증강된 SOC로 전환하려면 단계적이고 엔지니어링 중심적인 계획이 필요합니다.

1단계: AI 보조 조사(AI-assisted investigation) 보조에서 자율성(Autonomy)으로 가는 경로를 따라,[7] 조언만 제공하는 AI로 시작하십시오:

• 사고 및 로그 요약
• 도구 간 검색 및 상관관계 분석(Correlation)
• 스크립트, 페이로드(Payload), 복잡한 로그 설명
• 탐지 및 헌팅(Hunting) 쿼리 자동 생성[7][8]

💼 콜아웃 — 저위험 영역에서 시작하십시오
LLM을 먼저 사용하십시오. 위험이 낮은 곳에서...