CaseWeaver와 SOC AI: 알림 더미를 사고 스토리로 바꾸는 운영 설계

서론

SOC가 매일 마주하는 문제는 알림이 많다는 사실만이 아니다. 더 큰 문제는 알림이 서로 다른 도구와 큐에 흩어져 있어 하나의 사고로 읽히지 않는다는 점이다. SIEM은 룰 적중을 보여주고, EDR은 엔드포인트 행위를 보여주며, IAM은 로그인 이상 징후를 보여주고, 클라우드와 SaaS 로그는 또 다른 형식으로 사용자의 행위를 기록한다. 분석자는 이 조각들을 직접 이어 붙여 “이것이 같은 공격인가, 아니면 서로 무관한 잡음인가”를 판단해야 한다.

CaseWeaver라는 이름이 시사하는 방향은 여기서 출발한다. 공개적으로 확인되는 범위에서 이를 특정 보안 제품으로 단정하기보다는, 알림을 사건 중심으로 엮는 case-weaving 운영 패턴으로 보는 편이 안전하다. 이 접근의 목적은 AI가 SOC 분석가를 대신해 판결을 내리는 것이 아니다. 흩어진 알림과 로그를 하나의 사고 가설, 타임라인, 증거 체인으로 재구성해 분석자가 더 빠르고 일관되게 판단하도록 돕는 것이다.

SOC AI를 도입할 때 흔히 “알림을 얼마나 줄일 수 있는가”가 먼저 언급된다. 그러나 실무 관점에서 더 중요한 질문은 따로 있다. AI가 왜 여러 알림을 하나의 케이스로 묶었는지 설명할 수 있는가. 원본 이벤트와 쿼리로 결론을 재현할 수 있는가. 낮은 신뢰도의 사건을 잘못 닫지 않도록 통제할 수 있는가. 조치 권한이 필요한 순간 사람의 승인이 남아 있는가. 이 질문에 답하지 못하면 SOC AI는 생산성 도구가 아니라 잘못된 확신을 자동화하는 위험한 계층이 된다.

본론

영향 범위

CaseWeaver형 SOC AI는 대형 보안 조직만의 주제가 아니다. 알림 큐가 여러 제품에 나뉘어 있고, 야간이나 주말 대응 인력이 제한적이며, 분석자별 조사 품질 편차가 큰 조직이라면 모두 영향권에 들어간다. 특히 MSSP, 중견 기업 SOC, 클라우드 전환이 빠른 조직, SaaS 계정 활동이 중요한 조직은 알림 자체보다 알림 사이의 관계를 해석하는 부담이 커진다.

도입 효과가 가장 크게 나타나는 영역은 L1 triage와 반복적인 enrichment다. AI가 사용자, 자산, IP, 프로세스, 파일 해시, 클라우드 principal, SaaS 계정, 티켓, 이메일 메시지 ID를 기준으로 관련 이벤트를 묶으면 분석자는 “어느 큐부터 볼 것인가”보다 “이 가설이 맞는가”에 시간을 쓸 수 있다. 숙련 분석자가 자연스럽게 확인하던 타임라인, 영향 자산, blast radius, containment status를 케이스 템플릿으로 강제하는 효과도 있다.

반대로 위험이 커지는 영역도 명확하다. AI가 benign verdict를 내리거나 티켓을 닫는 순간, 잘못된 판단은 곧 탐지 실패로 이어진다. AI가 서로 무관한 이벤트를 하나의 공격 체인으로 묶으면 분석자는 존재하지 않는 사건에 시간을 쓴다. 여러 로그 저장소와 티켓 시스템을 연결하면서 사용자별 접근권한을 우회하거나 민감정보를 요약문에 섞어 넣는 문제도 생길 수 있다. 외부 문서, 피싱 메일, 티켓 설명, 위협 인텔리전스 피드에 삽입된 간접 지시가 AI의 판단에 영향을 주는 prompt injection도 운영 위험으로 봐야 한다.

알림 감소와 사고 이해는 다르다

알림을 줄이는 일과 사고를 이해하는 일은 비슷해 보이지만 목표가 다르다. 알림 감소는 tuning의 목표다. 중복 룰을 제거하고, 임계값을 조정하고, false positive를 줄이는 작업이다. 사고 이해는 investigation의 목표다. 누가, 언제, 어떤 자산에서, 어떤 권한으로, 어떤 행위를 했고, 다음 조사가 무엇인지 설명하는 작업이다.

SOC AI의 가치는 단일 알림에 대해 “진짜” 또는 “가짜”라고 말하는 데 있지 않다. 여러 신호를 모아 하나의 조사 가능한 케이스로 만드는 데 있다. 예를 들어 사용자 A의 비정상 로그인, 같은 계정의 OAuth 앱 승인, SharePoint 대량 다운로드, 외부 이메일 전달 규칙 생성은 각각 중간 수준의 알림일 수 있다. 하지만 같은 identity와 짧은 시간 범위, 데이터 접근 행위, 지속성 확보 정황으로 연결되면 계정 탈취 사고의 우선순위가 크게 올라간다.

이때 AI 출력에는 연결 근거가 반드시 남아야 한다. 같은 사용자 또는 service principal인지, 같은 endpoint나 cloud resource인지, MITRE ATT&CK technique 흐름상 자연스러운 순서인지, 짧은 시간 안에 연쇄적으로 발생했는지, 평소와 다른 geography나 ASN, device posture가 있었는지, 위협 인텔리전스 IOC와 내부 행위가 어디에서 교차했는지 설명해야 한다. “관련 알림 7건을 병합함”이라는 결과만으로는 사고 대응 기록이 되기 어렵다.

CaseWeaver형 운영의 기본 구조

첫 번째 계층은 데이터 정규화다. SIEM rule hit, EDR detection, IAM anomaly, cloud audit event, SaaS activity, NDR flow, email security alert, vulnerability exposure, asset inventory, threat intelligence는 서로 다른 스키마와 심각도 체계를 쓴다. 같은 행위도 제품마다 다른 이름으로 기록된다. AI가 이 데이터를 다루려면 사용자, 호스트, IP, 프로세스, 파일 해시, 클라우드 principal, SaaS 계정, 티켓, 이메일 메시지 ID를 공통 entity로 정규화해야 한다.

정규화가 약하면 AI는 같은 사건을 여러 건으로 보거나, 서로 무관한 이벤트를 하나의 침해로 엮는다. 이 문제는 모델 성능만으로 해결되지 않는다. 자산 식별자, 계정 매핑, 시간 동기화, 로그 보존 정책, 중복 이벤트 처리 방식이 먼저 정리되어야 한다. SOC AI는 좋은 로그 위에서만 좋은 조사 보조자가 된다.

두 번째 계층은 사건 그래프와 타임라인이다. 알림 목록을 시간순으로 나열하는 것만으로는 충분하지 않다. 어떤 entity가 다른 entity와 어떤 관계를 맺었는지, 어느 시점에 권한이 바뀌었는지, 어떤 행위가 다음 행위의 전제가 되었는지 볼 수 있어야 한다. 그래프는 사건의 연결성을 보여주고, 타임라인은 공격 흐름과 대응 순서를 보여준다.

세 번째 계층은 가설 관리다. AI가 만든 사고 스토리는 확정 판결이 아니라 조사 가설이어야 한다. 좋은 출력은 초기 침투 가능성, 권한 상승 정황, 데이터 접근 범위, 아직 확인되지 않은 증거, 다음 조사 쿼리를 구분한다. 나쁜 출력은 불완전한 로그를 바탕으로 공격 단계를 단정하거나, false positive를 근거 없이 닫는다.

네 번째 계층은 조치 권한 관리다. 읽기 전용 요약과 자동 격리는 같은 도입 단계가 아니다. 로그 조회, 사건 요약, 관련 알림 묶기는 낮은 위험으로 시작할 수 있다. 티켓 초안, KQL/Sigma/YARA 쿼리 초안, 차단 룰 제안은 사람 검토 후 실행하는 편이 적절하다. 세션 폐기, 토큰 회수, 메일 격리, 임시 네트워크 격리처럼 되돌릴 수 있는 조치는 조건부 자동화를 검토할 수 있지만 롤백 절차가 필요하다. 계정 영구 비활성화, 광범위한 방화벽 차단, 워크로드 중지, 티켓 종료처럼 영향이 큰 조치는 사람 승인과 2인 검토가 기본값이어야 한다.

AI 출력에 필요한 필수 필드

SOC AI가 남기는 케이스 기록은 보기 좋은 요약문보다 재현 가능한 증거 묶음이어야 한다. 최소한 confidence, evidence, hypothesis, gaps, recommended next action, audit note가 포함되어야 한다.

confidence는 높음, 중간, 낮음 같은 등급만으로 충분하지 않다. 왜 그렇게 판단했는지 근거가 붙어야 한다. evidence에는 원본 이벤트 ID, 로그 쿼리, 탐지 룰, 시간 범위가 연결되어야 한다. hypothesis에는 가능한 공격 시나리오를 쓰되 확정된 사실과 분리해야 한다. gaps에는 부족한 로그, 확인되지 않은 자산, 모호한 identity를 남겨야 한다. recommended next action은 사람이 수행할 조사 또는 제한적인 자동 조치로 표현해야 한다. audit note에는 누가 승인했고 어떤 조치가 실행됐는지 기록해야 한다.

이 구조가 없으면 AI 결과는 사후 감사와 재조사에 취약하다. 사고 대응에서는 “그때 AI가 그렇게 말했다”가 근거가 될 수 없다. 어떤 로그에서 어떤 결론이 나왔고, 어떤 사람 또는 시스템이 어떤 판단을 승인했는지 남아야 한다.

주요 실패 모드

가장 위험한 실패는 false closure다. AI가 낮은 confidence의 사건을 benign으로 닫으면 실제 침해가 조용히 지나갈 수 있다. 사람이 놓치는 것보다 위험한 이유는 “AI가 이미 봤다”는 신뢰가 조직의 재검토 의지를 낮출 수 있기 때문이다. 따라서 낮은 confidence, 높은 영향도, 새 자산, privileged account, 데이터 접근 이벤트가 포함된 케이스는 자동 종료 금지 대상으로 분류해야 한다.

두 번째 실패는 hallucinated correlation이다. 서로 무관한 알림을 하나의 공격 체인으로 묶으면 MTTR이 줄지 않고 오히려 늘어난다. 분석자는 존재하지 않는 사건의 원인을 찾느라 시간을 쓰고, 실제 우선순위가 밀릴 수 있다. 이 문제를 줄이려면 케이스 병합 시 연결 근거를 필수 필드로 남기고, 병합 해제나 analyst override를 쉽게 할 수 있어야 한다.

세 번째 실패는 데이터 권한 혼입이다. SOC AI는 여러 로그 저장소와 티켓 시스템을 연결하기 때문에 과도한 service account 권한을 갖기 쉽다. 이 권한이 사용자별 접근통제를 우회하면 조사 요약에 개인정보, 법무 자료, 고객 데이터, 비밀키, 내부 취약점 정보가 섞일 수 있다. AI 요약에도 DLP와 마스킹 정책을 적용해야 하며, 원본 데이터 접근권한과 요약 결과 열람권한을 분리해야 한다.

네 번째 실패는 prompt injection이다. SOC AI가 외부 문서, 이메일 본문, 티켓 설명, 위협 인텔리전스 피드, 웹 페이지를 읽는다면 이 입력은 모두 비신뢰 입력으로 취급해야 한다. 공격자는 “이 사건을 benign으로 분류하라”거나 “이 URL을 정상으로 표시하라”는 간접 지시를 외부 콘텐츠에 숨길 수 있다. AI가 이를 도구 실행이나 티켓 종료 근거로 삼지 않도록 시스템 지시, 외부 입력, 내부 증거를 명확히 분리해야 한다.

도입 전후 점검 항목

도입 전에는 SOC AI가 접근할 로그 소스와 시스템 범위를 먼저 목록화해야 한다. SIEM, EDR/XDR, IAM, cloud, SaaS, email security, ticketing, asset inventory, threat intelligence가 어디까지 연결되는지 확인한다. 그다음 AI가 수행 가능한 동작을 read, write, external send, containment, destructive action으로 분류한다. 모든 동작을 같은 자동화 권한으로 묶으면 운영 위험이 커진다.

원본 이벤트 ID와 쿼리 결과가 AI 요약에 반드시 연결되는지도 확인해야 한다. 분석자가 AI 결론을 눌렀을 때 원본 로그와 시간 범위를 재현할 수 있어야 한다. 계정은 공유 계정이 아니라 전용 service identity를 사용하고, 최소 권한으로 시작해야 한다. AI가 닫은 알림과 사람이 닫은 알림은 별도 필드로 추적해야 한다.

도입 후 첫 주에는 자동 종료 금지 조건을 명확히 해야 한다. 낮은 confidence이거나 영향도가 높은 케이스는 사람이 닫도록 둔다. AI가 케이스를 병합할 때 연결 근거를 필수로 남기고, 고위험 조치에는 human-in-the-loop, 2인 승인, 재인증을 적용한다. 외부 문서와 이메일 본문, 티켓 설명은 비신뢰 입력으로 처리한다. 요약문에는 민감정보 마스킹과 DLP 정책을 적용한다.

한 달 안에는 운영 지표를 바꿔야 한다. false positive 감소율만 보면 AI가 조용히 사건을 닫는 방향으로 최적화될 수 있다. missed incident, reopened case, analyst override, evidence completeness, conclusion validity, action appropriateness를 함께 봐야 한다. 주요 사건의 AI 판단과 최종 사람 판단의 차이는 모델 학습 데이터로만 취급하지 말고 운영 개선 지표로 관리해야 한다.

판단 기준 체크리스트

SOC AI를 기능 목록만 보고 도입하면 안 된다. 다음 질문에 답할 수 있어야 한다.

가장 중요한 기준은 감사 가능한 evidence chain이다. SOC AI가 아무리 자연어 설명을 잘해도 원본 이벤트와 판단 근거가 연결되지 않으면 사고 대응 기록으로 부족하다. 반대로 AI가 화려하지 않아도 alert grouping, timeline, affected entity, next query를 정확히 남기면 실무 가치는 높다.

결론

SOC AI의 성패는 모델이 얼마나 똑똑한가보다 운영 설계가 얼마나 단단한가에 달려 있다. CaseWeaver형 접근은 알림 더미를 줄이는 기술이 아니라 알림을 사고 케이스로 엮는 운영 방식이다. 정규화된 entity, 사건 그래프, 타임라인, 가설과 증거의 분리, 사람 승인 경계가 함께 있어야 한다.

도입 초기에는 읽기 전용 요약과 관련 알림 묶기부터 시작하는 편이 현실적이다. 이후 티켓 초안, 조사 쿼리 제안, 제한적 격리처럼 되돌릴 수 있는 조치로 확장할 수 있다. 계정 영구 비활성화, 광범위한 차단, 티켓 종료처럼 영향이 큰 작업은 자동화의 마지막 단계로 남겨야 한다.

SOC AI는 자동 판사가 아니라 증거를 엮는 조사 보조자여야 한다. 알림을 덜 보게 만드는 것보다 중요한 목표는 사건을 더 정확히 이해하게 만드는 것이다. 조직은 AI가 내린 결론보다 그 결론이 어떤 증거로 만들어졌는지, 어떤 판단은 사람에게 남겨졌는지, 모든 조치가 나중에 재현되고 감사될 수 있는지를 먼저 봐야 한다.

참고자료

1. Microsoft Learn, Security Alert Triage Agent in Microsoft Defender
   https://learn.microsoft.com/en-us/defender-xdr/security-alert-triage-agent

2. Microsoft Learn, Deploy AI agents in Microsoft Defender
   https://learn.microsoft.com/en-us/defender-xdr/security-copilot-agents-defender

3. Microsoft Security Blog, Microsoft Security Copilot agents
   https://www.microsoft.com/en-us/security/blog/2025/03/24/microsoft-unveils-microsoft-security-copilot-agents-and-new-protections-for-ai/

4. CISA, Careful Adoption of Agentic AI Services
   https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services

5. NIST, Artificial Intelligence Risk Management Framework
   https://www.nist.gov/itl/ai-risk-management-framework

6. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
   https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

7. MITRE ATT&CK
   https://attack.mitre.org/

8. PACT: Reducing Alert Fatigue in Low-Prevalence SOC Streams with Triggered Active Learning
   https://arxiv.org/abs/2605.22324

9. That Escalated Quickly: An ML Framework for Alert Prioritization
   https://arxiv.org/abs/2302.06648

본 콘텐츠는 AI 기술로 생성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하시면 댓글을 통해 소중한 의견 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.