AI는 보안 리스크를 정말로 증가시켰는가?

올해 들어 보안 취약점 대응에 쫓기고 있는 사람이 많지 않을까.

GitHub Advisory는 매일 늘어난다.

Dependabot의 알림은 멈추지 않는다.

고객으로부터는 대응 상황을 질문받는다.

나 자신도 특별한 근거 없이, "AI로 인해 보안 리스크가 급증하고 있는 것이 아닌가"라는 감각을 가지고 있었다.

Claude Mythos는 한정 공개 중에 취약점을 차례차례 발견했다며 화제가 되었다. Mythos도 그 필터 버전인 Fable도 미국 정부에 의해 수출 규제 틀에 포함되었다. 초고성능 모델의 악용을 우려해서라는 뜻으로도 들린다.

AI에 의한 멀웨어(Malware) 생성이나 RaaS(Ransomware as a Service)의 융성 등, AI에 의한 보안 리스크가 센세이셔널하게 세상을 떠들썩하게 만들면 불안은 높아진다. 보안 의식 향상 자체는 멋진 일이지만, 실제로 피해가 발생하지 않으면 예산이 책정되지 않는 것이 보안 업계다.

구조적으로 막혀 있는 (기분이 든다).

하지만, 정말일까?

실제로 Daily 모니터링을 통해 매일 새로운 취약성을 분류하고 있지만, 실제로 긴급 대책이 정말로 필요한 것은 거의 없다.

그래서 제대로 조사해 보기로 했다. No Measure, No Control.

• 대상: Node (npm) / Python (PyPI) / PHP (Composer)를 중심으로 한 OSS 패키지 취약성
• 기간: 2024년 1월 ~ 2026년 6월 (30개월, 2026년 6월은 15일까지)
• 데이터 소스: GitHub Advisory DB, NVD, OSV.dev, CISA KEV, PYSEC, RustSec, FriendsOfPHP, GitLab gemnasium-db, ransomware.live (모두 공개 데이터)

보안 논의에서는 흔히 다음과 같은 스토리가 이야기된다:

취약성이 증가한다 → 공격이 증가한다 → 피해가 증가한다

이 도미노는 언뜻 보면 자연스럽지만, 사실 이 세 가지는 전혀 다른 현상이다.

이번에 위협을 다음과 같은 3단계로 나누어 측정 및 분석을 수행했다.

단계	측정 대상
Disclosure	OSS 취약성 공개 건수
...

즉,

• 취약성이 공개되었는가
• 실제로 공격에 사용되었는가
• 피해가 발생했는가

를 개별적으로 추적했다.

결과는 감각과는 달랐다.

지표	2026년 vs 2024-2025 평균
OSS 전체 취약성 공개	3.9배
...

OSS 전체로는 3.9배지만, npm에 한정하면 8.8배로 증가하고 있다. 반면, 피해는 1.34배 정도로, 늘어나고는 있지만 같은 속도로 늘어나지는 않고 있다.

적어도 관측 가능한 범위 내에서는,

CVE 폭증 = 피해 폭증

은 성립하지 않는다.

나아가, 조사 기간 내의 특이점을 수학적(Pettitt, Binary seg., Bayesian MAP, CUSUM)으로 분석하면,

단계	스파이크 시기
Disclosure	2026-03
...

와 같이, 악용·피해는 발견의 하류(Downstream)에 있지 않다는 것을 알 수 있다.

여기서 "그럼 CVE는 무시해도 돼?"라는 이야기로 흐르는 것은 아니지만, 대다수의 CVE는 실제로는 악용되지 않는다는 사실은 예전부터 알려져 있다.

예를 들어,

Cyentia Institute & Kenna Security의 Prioritization to Prediction 시리즈에서는,

실제로 악용되는 취약성은 대략 2~6%라고 보고하고 있으며, FIRST.org의 EPSS도,

대부분의 CVE는 실제로는 악용되지 않는다

라는 전제 위에 구축되어 있다.

즉,

95% 정도의 CVE는 실제 피해로 이어지지 않는다

는 것은 10년 전부터 반복해서 확인된 현상이며, 이번 분석 결과는 그 기존 연구와 일치한다.

다만, 이것이

대부분의 취약성을 무시해도 된다

는 의미는 아니다.

Mandiant의 분석에 따르면, 실제로 악용되는 취약성은 공개부터 악용까지의 중앙값이 불과 5일이다. 즉,

• 악용되는 취약성은 적다
• 하지만 악용되는 것은 바로 사용된다

것이 현실이다.

만약 정말로 보안 리스크 자체가 악화되고 있다면,

• Severity: Critical/High의 비율
• RCE (Remote Code Execution)의 비율

등이 늘어나도 이상하지 않지만, 그 경향을 뒷받침하는 데이터는 관측되지 않았다.

생태계 (Ecosystem)	Crit+High 2024	2025	2026	RCE 점유율 2024	2025	2026
npm	44%	49%	50%	8%	11%	8%
...

즉, 위험한 취약성(Vulnerability)만 대량으로 발생하게 된 것이 아니라, **"더 많은 취약성이 전반적으로 발견되고 공개되게 되었다"**는 것이 사실이다.

여기서 다시 AI 이야기로 돌아가자. 이번 조사에서 AI로 인해 무언가가 변했다거나, 그 인과관계를 증명하는 데이터는 존재하지 않는다. 하지만 강력한 가설로서,

AI가 취약성 발견 능력을 향상시키고 있다는 것 자체는 거의 틀림없다

정도만큼은 말할 수 있을지도 모른다.

예를 들어,

• Google Project Naptime
• Google Big Sleep
• DARPA AI Cyber Challenge
• XBOW

등, 2024~2025년에는 AI에 의한 취약성 발견 능력을 보여주는 사례가 급증하고 있다. 특히 Big Sleep은 실제 미지의 취약성 발견을 보고했다. 즉,

AI → 취약성 발견

은 이미 현실이 되었다. 반면,

AI → 피해 급증

을 보여주는 동일한 수준의 증거는 아직 발견되지 않았다.

흥미롭게도, 2026년 Q1의 OSS 취약성 공개 수의 스파이크(Spike)는 2025년 후반의 LLM 능력 향상과 시간적으로 일치한다. 다만, 이는 인과관계를 나타내는 것이 아니라 유력한 가설이며, 증명된 결론은 아니다.

덧붙여, Claude Mythos(4월), Fable(6월) 등의 이용에 규제가 걸릴 정도의 초고성능 모델은 CVE 공개 수가 급증한 후에 등장했으며, 또한 4월에서 5월 사이에는 CVE 공개 수가 감소하고 있다는 점 등으로 미루어 볼 때, Opus 클래스의 모델이 취약성 발견에 이미 충분한 능력을 갖추고 있어 향후 CVE 공개 수가 다시 크게 점프하지 않을 수도 있다. 앞으로는 높은 수준을 유지할 것으로 예상되지만, 현시점에서는 아직 뭐라고 단정 지을 수 없다.

AI에 의한 공격 증가의 상징처럼, AI 랜섬웨어(Ransomware)가 자주 거론된다. 하지만 현실은 현시점에서 그렇게 비관적으로 될 상황은 아니다.

• FuncSec
• GLOBAL GROUP
• AiLock
• PromptLock

과 같이 AI를 전면에 내세운 랜섬웨어 그룹들을 추적했다.

AI를 전면에 내세운 랜섬웨어 캠페인은 실제로는 12개월 정도면 수렴하였고, 피해 측면에서도 전체의 불과 15% 정도였다. AI가 멀웨어(Malware)를 생성하는 PromptLock의 경우, 토픽으로서는 선정적이지만 피해 건수는 0으로, PoC(Proof of Concept) 단계인 것으로 보인다.

화제성은 크지만, 데이터상으로는 AI 범죄 조직이 랜섬웨어 시장을 석권하고 있다는 상황은 현시점에서 확인되지 않는다.

본 기사에서 자세히 다루지는 않지만, RaaS(Ransomware as a Service)가 융성하고 있다는 데이터도 없다.

여기서 중요한 것은, AI 랜섬웨어가 맹위를 떨치고 있다는 사실이 없다고 해서 AI 위협이 거짓이라는 뜻은 아니라는 점이다. 오히려 반대로, "아직" 위협이 되지 않았을 뿐이다.

PromptLock은 피해 건수는 0이지만, 역사적으로는 흥미로운 존재다. PromptLock은,

AI가 공격 코드 그 자체를 생성한 첫 번째 사례

이기 때문이다.

현재 Disclosure(공개)와 Victimization(피해 발생) 사이에는 거대한 격차가 있다. 그 격차를 지탱하고 있는 것이,

• Exploit(익스플로잇) 개발
• Weaponization(무기화)
• 공격 운용

이라는 인간의 작업이다. 향후 AI가 이 파이프라인을 고정밀도로 자동화하게 된다면,

CVE 증가 ≠ 피해 증가

라는 구조가 변화할 가능성은 있다.

(개인적으로는, 이것을 자동화할 수 없는 기술적 과제가 무엇인지 궁금하다.)

2026-Q1에 CVE 공개 수가 스파이크했다. 하지만 공개되는 CVE 중 실제로 악용되는 것은 극히 적다는 사실은 여전하며, AI가 리스크를 가속화하고 있다는 사실도 존재하지 않는다. 발견 능력이 무기화를 크게 앞서고 있으며, 굳이 말하자면 긍정적인 상황이라고 할 수도 있다.

하지만 실무자로서 나는 지쳐 있다.

그 이유는 간단하다. 조사(Investigation)가 필요한 취약성이 늘어났기 때문이며, 기존의 규칙(Severity 기반의 SLA 등)에 따르면 방치하는 것이 계약 위반에 해당하기 때문이다.

선의의 AI 이용이 드러낸 것은 취약한 규칙이었을지도 모른다.

이 Critical(심각)한 취약한 규칙의 변경에 시간이 걸린다는 점을 고려하면, 역시 보안 업계는 막다른 길에 다다랐다.

Severity(심각도) 기반의 SLA(Service Level Agreement)는 문제가 없어 보일 수도 있지만, 지금은 매우 위험하다. 새로운 계약에서는 맺어서는 안 되며, 기존 계약에 있다면 재검토할 필요가 있다.

OSS(Open Source Software) 취약성이 약 4배(Node 계열 시스템이라면 약 9배)가 된 세상에서,

• Critical: 24시간 이내
• High: 72시간 이내

와 같이, 언뜻 합리적으로 보이는 운용을 수행할 경우 어떤 일이 벌어지느냐 하면,

• 현장은 대량의 알림에 파묻힌다
• 고객은 대량의 보고를 받는다

그리고,

• 정말로 위험한 취약성이 파묻힌다
• 개발 팀이 패치 작업에 쫓긴다

결국, 아무도 이득을 보지 못한다.

CVE 대응은 '건수'가 아니라 '도달 가능성(Reachability)'과 '악용 가능성(Exploitability)'으로 보아야 하며, Severity뿐만 아니라 적어도 다음 관점에서 우선순위를 결정해야 한다:

• 해당 취약성이 실제로 사용 중인 코드 경로(Code Path)에 도달 가능한가
• 외부 공개 면(Attack Surface)에 있는가
• 인증 없이 악용할 수 있는가
• 실제로 악용이 확인되었는가
• KEV나 EPSS 등의 지표에서 우선순위가 높은가
• 대상 시스템의 중요도가 높은가
• 잠정적인 회피책(Mitigation)이 있는가
• 패치 적용에 따른 업무 영향이 어느 정도인가

'CVSS가 높으니까 위험하다'가 아니라, '자신의 환경에서 정말로 위험한가'가 중요하다.

물론 Critical/High를 무시해도 된다는 뜻은 아니지만, Severity는 출발점일 뿐이며 대응 우선순위를 결정하는 최종 판단은 아니다.

운용 보수 계약에 보안 조항을 넣는다면, 단순한 CVE 대응 SLA보다 트리아지(Triage) 프로세스를 명시하는 것이 좋다.

예를 들어,

• 신규 CVE를 정기적으로 확인한다
• 대상 시스템에 대한 영향 유무를 평가한다
• 악용 실적, 도달 가능성, 외부 공개 면, 업무 영향으로 우선순위를 결정한다
• 긴급 대응이 필요한 것은 개별적으로 합의한다
• 통상 대응은 정기 릴리스 사이클에 포함시킨다
• 대응 불가능하거나 즉시 대응이 불합리한 경우에는 회피책, 모니터링, 리스크 수용(Risk Acceptance)을 선택지에 포함한다

등과 같은 형태다.

즉, 계약에서 보증해야 하는 것은 '모든 CVE에 일정 시간 내에 패치를 적용하는 것'이 아니라, 'CVE를 평가하고 실질적인 리스크에 따라 대응 판단을 내리는 프로세스'이다.

AI에 의해 보안의 세계가 변하고 있을 가능성은 있다. 특히 취약성을 찾아내는 속도는 빨라졌을지도 모른다.

하지만 현시점에서 관측할 수 있는 데이터로는, CVE의 증가가 곧바로 공격이나 피해의 증가로 연동된다고는 말할 수 없으며, 공개되는 CVE의 상당수가 실제 피해로 이어지지 않는다는 사실에는 변화가 없다.

그러므로 기업도, 개발·운용 팀도,

CVE가 늘어났다 → 전부 즉시 대응해야 한다

라는 사고방식에서 벗어날 필요가 있다. CVE 대응은 필요하지만, Severity만으로 SLA화하면 현장도 고객도 대량의 노이즈에 휩쓸리게 된다.

AI 시대의 보안 운용에서 정말로 필요한 것은 위기감을 부추기는 것이 아니라, 리스크를 분해하고 우선순위를 매겨 지속 가능한 대응 프로세스를 만드는 것이다.

본 기사의 바탕이 된 조사 리포트는 재현을 위한 데이터·스크립트 등을 동봉하여 GitHub에 공개하고 있다. Preprint(사전 출판) 상태이며 영어로만 되어 있지만, 관심이 있다면 확인해 보길 바란다.