AI 사이버 보안의 거품은 실재하며, 발표 자료와 실제 배포 사이의 격차 또한 실재한다
요약
현재 AI 사이버 보안 시장에서 발생하는 'AI 워싱' 현상과 실제 기술력 사이의 심각한 격차를 비판합니다. 벤더들의 과장된 마케팅과 달리 실제 운영 환경에서의 낮은 정확도와 오탐 문제를 지적하며 실무적 관점의 검증을 강조합니다.
핵심 포인트
- AI 기반 보안 도구의 과장된 마케팅(AI-washing) 경계
- 발표 자료와 실제 운영 환경 간의 기술적 격차 존재
- 높은 오탐률로 인한 실무자의 업무 부담 가중
- 도입 시 실제 환경 데이터를 활용한 검증 필요성
r/cybersecurity의 누군가가 "AI 사이버 보안" 열풍 때문에 미칠 것 같은 사람이 또 있는지 묻는 글을 올려 765개의 추천을 받았습니다. 네, 그렇습니다. 대답은 '예'입니다. 제가 대화하는 모든 실무자는 똑같은 이야기를 하고 있으며, 우리가 벌거벗은 임금님인 척하는 것을 멈출 수 있도록 현재 일어나고 있는 일을 공개적으로 말할 가치가 있습니다.
영업 방식은 이렇습니다. 벤더 X는 "AI 기반 (AI-powered)" 플랫폼을 보유하고 있습니다. 이 플랫폼은 경보 (alerts)를 분류하고, 분석가의 업무량을 90% 줄이며, 위협을 자율적으로 조사하고, 사고를 봉쇄하며, SOC 분석가의 직업을 구시대의 유물로 만듭니다. 발표 자료 (deck)는 화려합니다. 데모 (demo)는 매끄럽습니다. 가격은 6자릿수(십만 달러 단위)이며 계속 올라갑니다.
그러고 나서 그것을 배포 (deploy)합니다.
실제 운영 환경에서 나타나는 현상
최근 한 실무자의 보고서에 따르면, LLM (Large Language Model) 기반 분류 도구를 348개의 알려진 오탐 (false positives)과 1개의 합성 정탐 (synthetic true positive)을 대상으로 테스트했습니다. 그 도구의 정확도는 71%였습니다. 명백한 오탐을 악성으로 분류했고, 심어놓은 사고를 완전히 놓쳤습니다. 이것이 바로 아무도 슬라이드에 넣지 않는 부분입니다.
Microsoft와 Omdia의 State of the SOC 2026 보고서에 따르면 경보의 46%가 오탐입니다. 2025 SANS 탐지 및 대응 (detection and response) 설문조사에 따르면 팀의 73%가 오탐을 가장 큰 탐지 과제로 꼽았습니다. SOC 팀은 하루에 약 11,000개의 경보를 검토하며, 그중 분석가당 조사가 필요한 것은 22개뿐입니다. AI는 이를 해결해야 합니다. 일부 더 나은 도구들 (Radiant, Cortex XSIAM, Sentinel)은 노이즈를 의미 있게 줄여줍니다. 하지만 대부분은 그렇지 못합니다. 그리고 벤더가 미팅 자리에서 약속했던 것을 실현하는 도구는 거의 없습니다.
Help Net Security는 2026년 3월에 다음과 같이 직설적인 기사를 게재했습니다: "AI SOC 벤더들은 실제 운영 배포가 아직 도달하지 못한 미래를 팔고 있다." 이것이 헤드라인입니다. 이것이 실상입니다.
AI 워싱 (AI-washing) 세금
지금 일어나고 있는 현상에는 이름이 있습니다. 바로 AI 워싱 (AI-washing)입니다. 벤더(Vendor)가 정규 표현식 엔진 (Regex engine), 상관관계 규칙 (Correlation rule), 또는 절반만 학습된 분류기 (Classifier)를 가져다가 상자에 "AI 기반 (Powered by AI)"라고 붙여놓고 가격을 세 배로 올리는 것입니다. 한 보안 분석가는 "AI 기반" 보안 도구의 80%가 오해의 소지가 있다고 추정했습니다. IT 리더의 77%가 AI 기반 보안 제품을 사용한다고 보고했지만, AI가 어떻게 결과를 개선하는지 이해하고 있다고 답한 비율은 66%에 불과했습니다. 이 11%포인트의 격차가 바로 이 문제의 핵심을 보여주는 통계입니다.
AI 보안 도구에 대한 CISO(정보보호최고책임자)의 열정은 운영자(Operator)의 열정을 훨씬 앞지릅니다. 수표를 쓰는 사람들은 흥분해 있지만, 새벽 2시에 콘솔을 돌리는 사람들은 그렇지 않습니다. 이러한 괴리는 현재 시장 전체를 지탱하는 하중과 같으며, 왜 수많은 배포 사례들이 이사회 보고용 슬라이드에서는 훌륭해 보이지만 실제 대기열 (Queue)에서는 비참해 보이는지를 설명해 줍니다.
매번 의심해봐야 할 것들
만약 당신이 벤더의 피칭 (Pitch)을 듣고 있는 테이블 맞은편에 앉아 있는 실무자라면, 다음의 체크리스트를 확인하십시오.
- AI를 당신의 지난 30일간의 경고 (Alert) 데이터에 실행해 보라고 요청하십시오. 선별된 데모 세트가 아니라, 당신의 노이즈, 당신의 환경, 당신의 특이사항이 포함된 실제 데이터여야 합니다.
- 분석가가 AI의 결정을 어떻게 검토하고 무효화 (Override)할 수 있는지 물으십시오. 만약 답변이 모호하다면, 감사 추적 (Audit trail)이 존재하지 않는 것이며 규제 기관에 그 결과를 방어할 수 없다는 뜻입니다.
- 규칙 기반 (Rules-based) 또는 시그니처 기반 (Signature-based) 시스템이 놓쳤을 위협 유형 중 AI가 잡아낸 것이 무엇인지 물으십시오. "고도화된 위협 (Advanced threats)"이나 "새로운 공격 (Novel attacks)" 같은 말이 아니라, 구체적인 사례, 명칭, TTPs, CVE를 요구하십시오.
- 실패 모드 (Failure mode)가 어떤 모습인지 물으십시오. 모델이 틀렸을 때 어떻게 알 수 있습니까? 영향 범위 (Blast radius)는 어디까지입니까? 누가 호출 (Page)을 받고 대응해야 합니까?
- 모델이 당신의 데이터로 재학습 (Retrain)되는지, 그 결과로 생성된 가중치 (Weights)의 소유권은 누구에게 있는지, 그리고 모델이 무엇을 학습했는지 감사 (Audit)할 수 있는지 물으십시오.
실제 AI 역량을 갖춘 벤더는 이러한 질문에 구체적으로 답변합니다. 허상을 파는 벤더는 그렇지 못합니다. NIST (미국 국립표준기술연구소)는 공식적으로 다음과 같이 언급한 바 있습니다. "AI 알고리즘을 보호하는 데에는 아직 해결되지 않은 이론적인 문제들이 존재한다." 이와 다르게 주장하는 사람은 무엇인가를 팔고 있는 것입니다.
분석가의 신뢰 문제
가장 나를 괴롭히는 부분입니다. AI가 생성한 경고 요약(AI-generated alert summaries)은 실질적인 인지적 실패 모드(cognitive failure mode)를 만들어냅니다. 분석가들은 증거 기반 분석(evidence-weighted analysis)을 수행하는 대신, 신뢰도 가중치가 부여된 AI 출력값(confidence-weighted AI output)에 의존하기 시작합니다. 모델은 그럴듯하게 들리는 문단을 작성하고 심각도(severity)를 '높음'으로 표시하며, 분석가는 원시 텔레메트리(raw telemetry)가 더 지루한 일이 일어나고 있음을 시사할 때조차 모델의 의견을 따릅니다.
그 반대의 경우도 발생합니다. 모델이 높은 신뢰도로 '정상(benign)'이라고 말하면, 분석가는 5분만 더 조사했어야 할 사항에 대한 조사를 중단합니다. 두 가지 실패 모드 모두 분석가가 직접 로그를 읽었을 때보다 더 나쁜 결과를 초래합니다. 도구는 판단력을 증폭(amplify)하기로 되어 있었으나
에이전트형 AI (Agentic AI)는 벤더들이 판매하고 있는 차세대 물결입니다. 분류(triage), 조사(investigate), 봉쇄(contain), 그리고 엔드 투 엔드(end-to-end) 복구(remediate)를 수행하는 에이전트들 말입니다. 이 중 일부는 실재하겠지만, 대부분은 적어도 한 번, 아마도 두 번의 제품 주기(product cycle) 동안은 실재하지 않을 것입니다. 에이전트는 복합적인 방식으로 실패합니다. 상류(upstream)에서의 잘못된 추론(inference) 하나가 하류(downstream)에서의 잘못된 동작이 되고, 이는 새벽 4시에 고립된 운영 호스트(production host)가 되는 결과로 이어집니다.
에이전트 방식의 이야기는 결국 작동하겠지만, 처음에는 좁은 영역(특정 경고 유형, 엄격한 가드레일(guardrails)이 있는 특정 봉쇄 조치)에서 먼저 작동한 다음 확장될 것입니다. 지금 당장 완전 자율형 'SOC-in-a-box'를 판매하는 사람은 2026년 버전의 제품을 2030년 버전이라며 팔고 있는 것입니다.
그동안 무엇을 해야 할까요. 매력적이지 않은 기초(unsexy foundations)에 투자하십시오. 텔레메트리(telemetry) 품질, ID 제어(identity controls), 자산 인벤토리(asset inventory), 노출 관리(exposure management), 복구 가능성(recoverability) 같은 것들 말입니다. AI는 여러분이 이미 가지고 있는 기초가 무엇이든 그 위에 곱해지는 승수(multiplier)입니다. 만약 기초가 부실하다면, AI는 잘못된 데이터를 바탕으로 더 빠르게 잘못된 결정을 내릴 것입니다.
이 상황을 지켜보고 있는 분석가라면
여러분의 직업은 향후 24개월 내에 사라지지 않습니다. 직업이 사라질 것이라고 말하는 사람들은 무언가를 팔고 있거나, 무언가를 팔고 있는 사람의 말을 반복하고 있는 것입니다. 변하는 것은 여러분이 업무의 어느 부분에 시간을 쓰느냐 하는 것입니다. 컨텍스트(context)를 파악하기 위해 탭을 전환하는 일은 줄어들 것입니다. 대신 탐지(detection)를 설계하고, AI의 출력을 튜닝(tuning)하며, 모델이 확신에 차서 틀렸을 때 제동을 거는 인간의 역할을 더 많이 하게 될 것입니다.
이러한 환경에서 복리로 쌓이는 기술은 도구가 말하는 것을 보기 전에 가공되지 않은 텔레메트리(raw telemetry)를 읽고 자신만의 의견을 형성하는 능력입니다. 이를 할 수 있는 분석가는 가치가 낮아지는 것이 아니라 더 높아질 것입니다. 반면 AI의 출력을 단순히 승인(rubber-stamp)하는 법을 배우는 분석가는, 똑같이 AI 출력을 승인하는 더 저렴한 분석가로 대체될 것입니다.
PCAP 파일을 읽는 법을 배우십시오. 도움 없이 인증 로그(auth logs)를 읽는 법을 배우십시오. 탐지 규칙을 작성하는 법을 배우십시오. 그것들이 지속 가능한 기술(durable skills)입니다. '이달의 AI 도구'는 일회용 기술일 뿐입니다.
요점 (the takeaway)
r/cybersecurity의 게시글이 열광하는 것은 틀린 것이 아니었습니다. 2026년의 AI 사이버 보안 시장은 2017년의 ICO(Initial Coin Offering)를 무색하게 만들 정도로 과장(hype)과 현실 사이의 비율이 극단적입니다. 하지만 마케팅 이면에는 실무자들이 활용해야 할 실제적이고, 좁지만 유용한 애플리케이션들이 존재합니다. 핵심은 무엇이 무엇인지 구별해내는 능력이며, 이를 위한 유일한 방법은 슬라이드 덱(slide deck)을 신뢰하는 대신 증거를 요구하고 직접 테스트를 수행하는 것입니다.
여러분의 스택에 있는 AI 도구 중 어떤 것이 제 역할을 다하고 있고, 어떤 것이 비싼 자동 완성(autocomplete) 기능에 불과한지 파악하려 한다면, 저는 tools.thesoundmethod.me에서 도구 비교 글을 작성해 오고 있습니다. 동일한 평가 프레임워크(evaluation framework)를 사용하며, 데이터가 가장 깨끗한 개발(dev) 측면부터 먼저 적용했습니다. 사이버 보안 비교는 다음 순서로 진행될 예정입니다.
그리고 만약 여러분이 신뢰할 수 있는 에이전트 워크플로우(agent workflows)를 구축하기 위한 엔지니어링 플레이북(engineering playbook)을 원한다면(SOC-in-a-box 벤더들이 여전히 파악 중인 바로 그 종류 말입니다), 제가 정리 중인 Claude Code 쿡북(cookbooks)은 프로덕션(production) 환경에서 견고하게 작동하는 패턴들을 다룹니다. 사전 액세스(early access)를 원하시면 메시지를 보내주세요.
회의적으로 접근하십시오. 로그(logs)를 읽으십시오. 슬라이드 덱을 믿지 마십시오.
저는 벤더의 슬라이드 덱이 아니라, 직접 도구들을 실행하며 작성한 '실제 사용 기반 도구 분석(from-real-use tool teardowns)' 목록을 tools.thesoundmethod.me에서 계속 업데이트하고 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기