TTESays

[Claude Mythos 이후 #2] Claude Mythos가 드러낸 보안 부채: 발견된 취약점은 왜 닫히지 않는가

Donghwi Shin, Jin Kwak

Published: 08:30, 06 May 2026 (Updated: 20:18, 06 May 2026)

💡

Editor Pick
- Claude Mythos 이후 취약점 관리는 발견보다 검증과 조치의 문제
- AI가 만든 결과가 실제 조치 가능한 항목으로 전환되지 못하면 검증 부채와 보안 부채 적립
- MTTR, Backlog, KEV, EPSS, 오탐률, 재검증률은 Mythos 시대의 보안 운영 능력을 보여주는 핵심 지표

취약점은 발견되는 순간 사라지지 않는다

Claude Mythos가 보여준 장면은 강렬했다. AI는 복잡한 소프트웨어에서 취약점을 찾아낼 수 있고, 경우에 따라 Exploitable 여부를 추론할 수 있다. 이 장면은 보안 업계가 오랫동안 논의해 온 질문에 하나의 답을 제시했다. 이제 AI를 활용한 취약점 탐지는 가능성의 영역이 아닌 운영의 영역으로 바라봐야 하는 상황으로 전개되어야 한다는 것이다.

취약점은 발견되면 그대로 사라지는 것은 아니다. 보고서에 기록된 취약점은 시스템 안에 남아 있다. 누군가가 소유자를 지정해야 하고, 재현 가능성을 확인해야 하며, Exploit 가능성을 검토해야 한다. 이후 업무 영향도를 따지고, 패치 일정을 정하고, 서비스 중단 가능성을 검토하며, 배포 뒤 실제로 위험이 제거됐는지 확인해야 한다. 이 과정을 거쳐야 시스탬안에 있는 취약점이 사라진다.

하지만, 이 과정이 느려지면 취약점은 보안 부채가 된다. 기술 부채가 개발 속도를 늦추듯, 보안 부채는 조직의 방어 속도를 늦춘다. 처음에는 하나의 예외처럼 보이지만, 시간이 지나면 미조치 취약점 목록이 된다. 목록이 길어지면 우선순위 판단이 어려워지며, 판단이 어려워지면 위험도 높은 취약점도 조치 대기열 속에 묻힌다.

Mythos는 앞서 설명한 흐름을 더 크게 만든다. AI가 더 많은 취약점을 더 빨리 찾을수록, 조직은 더 많은 결정을 더 빨리 내려야 한다. 그러나 많은 조직의 조치 체계는 여전히 인간의 회의, 부서 간 조율, 배포 일정, 예외 승인에 묶여 있다. 발견의 속도는 AI의 속도로 바뀌는데 조치의 속도는 조직의 속도에 머무른다. 바로 여기서 보안 부채가 생기고 쌓여간다.

brown wooden i love you letter — Photo by Brett Jordan / Unsplash

보안 부채 앞에는 검증 부채가 있다.

AI 시대의 취약점 관리를 말할 때 흔히 놓치는 단계가 있다. 바로 검증이다. 취약점이 많아지는 것만 문제가 아니다. 그 취약점이 실제 취약점인지 확인해야 하는 부담도 함께 늘어난다. 모델은 코드 안의 약한 지점을 찾아낼 수 있지만, 그 결과가 실제 운영 환경에서 Exploit 가능한지, 단순한 이론적 취약점인지, 이미 보안 통제로 막혀 있는지 판단하는 일은 별도의 과정이다.

검증되지 않은 결과는 개발팀에 부담이 될 수밖에 없다. 개발자는 모델이 제시한 내용을 그대로 고칠 수 없다. 취약점은 재현 가능한지, 공격자가 도달할 수 있는 코드 경로인지, 입력 조건이 현실적인지, 패치가 기능을 깨뜨리지 않는지 확인해야 한다. 이 과정이 없으면 보안팀은 취약점을 많이 찾았다고 말할 수 있지만, 개발팀은 오탐을 처리하느라 시간을 허비할 수 밖에 없다.

따라서 Mythos 이후의 보안 조직은 보안 부채와 함께 검증 부채를 떠안는다. 검증 부채는 모델이 만든 잠재 취약점 목록을 실제 조치 가능한 항목으로 전환하지 못할 때 발생한다. 발견이 많아질수록 검증 부채도 늘어난다. 검증 부채가 늘어나면 조치 속도는 더 느려지고, 조치 속도가 느려지면 보안 부채는 더욱 늘어난다. 즉, 발견과 조치의 ‘시간 비대칭성(Time Asymmetry)’이 더욱 심각해 질 수 있다는 것이다.

이 구조를 이해하지 못하면 AI 취약점 탐지는 잘못된 성과 지표를 만든다. 발견 건수가 많다는 사실은 중요하지만, 그것만으로 충분하지 않다. 보다 중요한 것은 검증 완료율, 오탐률, 재현 단계의 품질, 조치 비율, 패치 후 재검증 비율 등이다. 조직은 이제 “얼마나 많이 찾았는가?”가 아니라 “얼마나 많이 신뢰할 수 있는 결과로 바꾸었는지”를 측정해야 한다.

MTTR은 조직의 실제 속도를 보여준다.

취약점 처리 능력을 측정하는 대표적인 지표로, 취약점을 처음 발견한 뒤 조치하고 검증 완료하기까지 소요되는 평균 시간을 의미하는 MTTR(Mean Time to Remediate)을 꼽을 수 있다. MTTR은 조직의 실제 처리 속도를 보여주는 것으로, 보안팀이 취약점을 얼마나 빨리 찾는지보다 조직 전체가 그 취약점을 얼마나 빠르고 정확하게 조치했는지를 의미한다.

High 또는 Critical 등급 취약점이라 하더라도 조치는 곧바로 이뤄지지 않는다. 패치는 테스트가 필요하고, 운영 시스템은 변경 관리 절차를 거쳐야 한다. 하지만 금융, 통신, 제조, 공공 분야에서는 패치 하나가 서비스 중단이나 업무 장애를 유발할 수 있다. 그래서 조치 지연은 상황에 따라 때로 불가피하게 받아들여지기도 한다. 그러나 Mythos 이후에는 같은 지연도 다른 의미를 갖는다. AI가 취약점 분석 시간을 줄이고 Exploit 가능성을 더 빠르게 확인한다면, 수십 일의 조치 기간은 공격자에게 열린 시간이 된다.

MTTR이 긴 조직이라고 해서 꼭 취약점을 모르는 조직이라고 할 수는 없다. 일반적으로는 오히려 취약점을 알고도 처리하지 못하는 조직이라 할 수 있다. 이 차이는 중요하다. 과거에는 보안 실패를 “몰랐다”는 말로 설명할 수 있었다. 그러나 AI 기반 점검이 확산되면 더 많은 조직이 더 많은 취약점을 알게 된다. 이러한 상황에서 실패는 무지가 아닌 지연으로 발생한다고 봐야 한다.

Backlog는 보안팀의 문제가 아니라 조직의 문제다.

취약점 Backlog는 일정 기간이 지나도 조치되지 않은 취약점의 규모를 보여준다. 쌓여 있는 취약점 Backlog가 보안팀의 게으름만을 의미하지 않는다. 오히려 이것은 조직의 처리 능력과 의사결정 구조의 문제를 보여준다고 보는 것이 적절하다. 취약점이 Backlog에 남는 이유는 다양하다. 담당 시스템이 불명확할 수 있고, 벤더 패치가 없을 수 있으며, 패치가 업무 애플리케이션과 충돌할 수 있다. 또는 사업 부서가 변경 일정을 승인하지 않을 수도 있다.

그러나 이유가 무엇이든 Backlog에 남아 있는 취약점은 공격자에게 열려 있는 공격 기회라는 것은 분명하다. 공격자는 조직의 내부 사정을 고려하지 않는다. 공격자는 패치가 어려운지, 업무 영향도가 큰지, 예외 승인을 받았는지 관심을 가질 필요도 알 필요도 가 없다. 남아 있는 취약점이 있고, 접근 가능 경로가 있으며, Exploitable하다면 그것으로 충분하다.

Claude Mythos 이후 Backlog의 의미는 더 무거워진다. 과거에는 Backlog 안의 취약점이 사용 가능한 Exploit으로 개발되기까지 취약점마다 상이하지만, 시간이 필요했다. 그러나 AI가 취약점 분석과 Exploit 개발을 돕는다면, Exploit 개발 시간은 짧아지며 Backlog에 있는 취약점들을 보다 빠르게 공격 가능한 목록으로 바뀔 수 있다. 그러므로 취약점 Backlog 관리는 단순한 티켓 관리가 아닌 공격자가 볼 수 있는 미래의 공격 표면을 줄이는 일이다.

KEV와 EPSS는 우선순위 판단을 바꾼다.

모든 취약점을 같은 속도로 고칠 수는 없다. 그러므로 조직은 우선순위를 정해야 한다. 과거에는 CVSS 점수가 중요한 기준이었다. CVSS는 취약점의 기술적 심각도를 보여주는 출발점으로 여전히 유용하다. 그러나 CVSS만으로는 충분하지 않다. 심각도가 높아도 실제 공격에 거의 쓰이지 않는 취약점이 있고, 점수는 다소 낮아도 공격자가 활발히 악용하는 취약점이 있다.

현실 세계에서 사용 가능성을 고려한다면 CISA KEV와 EPSS 같은 지표가 중요해진다. KEV는 실제로 악용된 취약점을 우선순위 판단에 반영하게 해준다. EPSS는 특정 CVE가 가까운 미래에 악용될 가능성을 확률적으로 보여준다. 이 지표들은 조직이 “점수가 높은 취약점”이 아닌 “공격자가 실제 사용할 가능성이 높은 취약점”을 먼저 검토할 수 있도록 도와준다.

Exploit Prediction Scoring System (EPSS) Special Interest Group (SIG)

FIRST — Forum of Incident Response and Security Teams

Mythos 시대의 취약점 관리는 앞서 설명한 방식으로 변화해야 한다. AI가 더 많은 취약점을 찾아낼수록, 모든 결과를 동일하게 다루는 방식은 실패한다. 조직은 발견된 취약점을 검증하고, Exploit 가능성을 확인하고, 외부 노출 여부와 자산 중요도를 반영하고, KEV와 EPSS 변화에 따라 우선순위를 다시 조정해야 한다. 그리고 추가로 취약점 관리는 정적 목록 관리가 아니라 동적 위험 관리가 되어야 한다. 자산 규모와 구조, 변경과 변화 그리고 서비스 상황과 취약점의 상황, 모든 것이 연결되는 관계성을 고려하여 지속적으로 재평가하는 방식으로 관리해야 한다.

조치 가능한 결과가 보안의 기준이 된다.

AI 취약점 탐지의 성패는 AI를 통해 식별한 취약점을 기반으로 조직이 조치 가능한 상황을 만들 수 있는가에 달려 있다. 조치 가능한 결과란 단순히 “취약점이 있다”는 문장이 아니다. 개발자가 어디를 봐야 하는지 알 수 있어야 하고, 재현 단계가 있어야 하며, 영향도가 설명되어야 한다. 가능하다면 패치 방향과 보안 통제 방안도 함께 제시되어야 한다. 그래야 보안팀의 발견이 개발팀의 조치로 이어진다.

이 지점에서 보안 운영의 성과 지표도 바뀌어야 한다. 취약점 식별 건수를 확인하는 방식만으로 충분하지 않다. 검증 완료율, 오탐률, 조치 가능 결과 비율, 패치 적용률, 재검증 완료율을 함께 봐야 한다. AI가 만들어낸 결과가 실제 위험 감소로 이어졌는지 확인해야 한다는 것이다.

Claude Mythos는 취약점 발견의 가능성을 보여주었다. 그러나 조직의 안전은 가능성으로 만들어지지 않는다. 안전은 검증된 결과와 실제 조치가 이어질 때 만들어진다. 발견된 취약점이 조치되지 않아 Backlog에서 사라지지 않는다면, 취약점은 여전히 시스템 안에 있다. 조치되지 않은 취약점이 쌓인다면, 부채가 쌓이며 더 큰 위협으로 다가올 것이다.

결론: 보안 부채는 자동화될 수 있다.

AI는 보안을 자동화할 수 있다. 그러나 더 많은 취약점을 찾지만 검증하지 못하고, 검증한 취약점을 조치하지 못하고, 조치한 취약점을 재검증하지 못하면 조직은 더 안전해지지 않는다. 오히려 더 많은 위협을 알고도 남겨두는 상태로 보안 부채가 증가하며 더욱 안전하지 않은 상태가 된다.

Claude Mythos 이후 취약점 관리는 탐지의 문제가 아닌 시간과 품질의 문제가 된다. 얼마나 ‘빨리 찾았는가’ 보다, 얼마나 ‘빨리 검증했는가’가 중요하다. 얼마나 ‘많이 발견했는가’보다, 얼마나 ‘많이 조치했는가’가 중요하다. 얼마나 ‘많은 보고서를 만들었는가’보다, 얼마나 ‘많은 위험을 실제로 줄였는가’가 중요하다.

보안 부채는 보이지 않는 곳에서 쌓인다. Mythos는 그 부채를 더 잘 보이게 만든다. 그러나 보이게 만드는 것만으로는 충분하지 않다. 조직은 그 부채를 실질적으로 줄일 수 있는 시스템을 갖춰야 한다.