보안팀의 가장 어려운 판단은 "패치해야 한다"가 아니라 "무엇을 먼저, 얼마나 빨리 패치해야 하는가"입니다. 모든 시스템을 즉시 업데이트할 수는 없습니다. 테스트, 장애 위험, 운영 중단, 레거시 의존성이 있기 때문입니다.
문제는 그동안 조직이 암묵적으로 기대하던 '며칠의 여유'가 사라지고 있다는 점입니다. 최근 보도에서는 AI가 공개된 패치를 분석해 약 30분 만에 동작 가능한 익스플로잇으로 전환할 수 있다는 사례가 소개됐고, 이 변화가 기존 90일 공개 관행에도 압박을 준다고 지적했습니다.1 핵심은 AI가 해커에게 마법을 준다는 이야기가 아닙니다. 공개, 우선순위 판단, 실제 노출 사이의 시간이 급격히 압축되고 있다는 이야기입니다.
진짜 변화는 '익스플로잇 난이도'보다 '익스플로잇 지연시간'이다
패치는 방어 수단이지만 동시에 힌트입니다. 공격자는 취약한 버전과 수정된 버전을 비교해 어떤 함수가 바뀌었는지, 어떤 검증 로직이 추가됐는지, 어떤 입력이 위험했는지 추론할 수 있습니다. 이른바 패치 디핑입니다.
이 작업은 원래 고급 역공학자의 시간이 필요했습니다. 하지만 LLM은 코드 이해, 주석화, 차이 요약, 후보 입력 생성 같은 반복 작업을 빠르게 줄입니다. PwnGPT 연구는 CTF의 바이너리 익스플로잇 과제에서 LLM을 분석·생성·검증 모듈로 나누자, 단순 프롬프트 대비 해결률이 크게 높아졌다고 보고했습니다. 예컨대 OpenAI o1-preview 기준 완료율은 26.3%에서 57.9%로 상승했습니다.2
이 수치는 현실 공격을 그대로 대변하지는 않습니다. CTF와 운영 환경은 다르고, 실제 익스플로잇은 안정성·환경 차이·탐지 회피까지 고려해야 합니다. 그래도 방향은 분명합니다. AI는 "불가능하던 공격"을 갑자기 가능하게 만든다기보다, 가능했지만 오래 걸리던 분석을 더 짧은 시간 안에 반복 가능하게 만듭니다.
실무적으로는 패치가 배포된 순간부터 리스크 시계가 돈다는 뜻입니다. 특히 인터넷에 노출된 서비스, 인증 전 접근 가능한 취약점, 이미 널리 알려진 버그 패턴은 '다음 정기 점검'까지 기다릴 수 있는 항목이 아닙니다.
모든 패치가 긴급은 아니다: 먼저 볼 신호들
AI 시대의 취약점 관리는 "모두 긴급"이 되면 실패합니다. 운영팀은 결국 병목이고, 무차별 긴급 패치는 장애를 부릅니다. 필요한 것은 더 빠른 패치가 아니라 더 빠른 분류입니다.
우선순위 판단에는 다음 신호가 중요합니다.
패치 설명이 구체적인가: RCE, 인증 우회, 권한 상승처럼 영향이 명확한가
공격 표면이 열려 있는가: 인터넷 노출, VPN 전 접근, 공개 API인가
인증이 필요한가: 인증 전 취약점은 훨씬 빠르게 악용될 수 있다
자산이 중요한가: 도메인 컨트롤러, CI/CD, 원격관리 도구, 파일전송 시스템인가
기존 익스플로잇 패턴과 닮았는가: deserialization, path traversal, command injection 등 반복 가능한 유형인가
탐지나 임시 완화가 가능한가: WAF/IPS 룰, 설정 변경, 기능 비활성화로 시간을 벌 수 있는가
Google Threat Intelligence Group도 공격자들이 AI를 취약점 연구와 익스플로잇 개발의 보조 도구로 활용하고 있으며, 일부 위협 행위자는 반복적인 CVE 분석과 PoC 검증을 대규모로 수행했다고 설명했습니다.3 이는 방어팀도 "패치 목록을 받는 날"에 단순 CVSS 정렬만 해서는 부족하다는 뜻입니다.
CVSS는 출발점일 뿐입니다. 실제 우선순위는 "우리 환경에서 지금 도달 가능한가"로 결정해야 합니다.
90일 공개 창은 끝난 것이 아니라, 의미가 바뀌었다
90일 공개 관행은 취약점을 발견한 연구자가 벤더에게 고칠 시간을 주고, 일정 시점 이후 공개하는 책임 있는 공개 모델의 기준점으로 쓰여 왔습니다. 하지만 AI가 패치 이후 익스플로잇 생성 시간을 단축한다면, 문제는 공개 전 90일보다 공개 후 첫 24~72시간으로 이동합니다.
그렇다고 90일 모델이 무의미해졌다고 단정하긴 어렵습니다. 여전히 벤더가 수정하고, 생태계가 업데이트를 준비하고, 연구자가 무기화 세부사항을 제한하는 과정은 필요합니다. 다만 조직 입장에서는 "패치가 나왔으니 한 달 안에 처리"라는 전통적 SLA가 더 이상 안전한 기본값이 아닙니다.
현실적인 새 기준은 자산군별로 달라야 합니다.
인터넷 노출 시스템과 인증 전 RCE는 당일 또는 24시간 내 대응 대상입니다. 패치가 어렵다면 임시 차단, 기능 비활성화, 가상 패치가 함께 가야 합니다.
내부의 고권한 시스템, 예컨대 AD, 백업, 관리 콘솔, CI 서버는 72시간 안에 우선 처리해야 합니다. 외부 노출은 없어도 침해 후 횡이동의 발판이 되기 때문입니다.
일반 워크로드와 낮은 중요도의 내부 앱은 기존 주기 패치가 가능하지만, KEV 등 실제 악용 신호가 붙으면 즉시 상위 등급으로 올려야 합니다.
방어 AI는 '익스플로잇 작성'보다 '시간 단축'에 써야 한다
공격자가 AI로 시간을 줄인다면, 방어팀도 같은 목표를 가져야 합니다. 다만 방향은 달라야 합니다. 익스플로잇을 만드는 것이 아니라 판단과 배포 준비 시간을 줄이는 쪽입니다.
예를 들어 AI는 신규 패치 노트를 요약하고, 변경된 컴포넌트가 우리 자산 어디에 있는지 매핑하며, 장애 가능성이 큰 의존성을 정리할 수 있습니다. 탐지팀은 공개된 취약점 설명을 바탕으로 로그 질의, EDR 탐지 가설, WAF 룰 후보를 더 빨리 만들 수 있습니다. 경영진 보고도 "CVSS 9.8이라 위험합니다"가 아니라 "인터넷 노출 자산 12대 중 3대가 영향권이고, 임시 완화는 오늘 적용 가능합니다"로 바뀌어야 합니다.
다만 한계도 분명합니다. LLM 기반 역공학 연구들은 가능성을 보이지만, 환각·재현성·저수준 의미 이해 부족 같은 문제가 계속 지적됩니다.4 따라서 방어 AI도 자동 결정권자가 아니라 검토 속도를 높이는 보조자로 둬야 합니다. 로그, 자산 데이터, 변경 이력과 연결하고 사람이 승인하는 구조가 안전합니다.
이 변화에 가장 민감해야 할 조직은 인터넷 노출 서비스가 많거나, 패치 테스트에 오래 걸리는 금융·제조·공공·SaaS 운영 조직입니다. 앞으로의 질문은 "패치를 얼마나 빨리 설치했나"만이 아닙니다. "패치가 공개된 뒤 몇 시간 안에 우리 노출을 알고, 임시 방어를 걸고, 최우선 자산을 업데이트할 수 있는가"가 핵심 지표가 됩니다.
패치는 더 이상 월간 IT 작업이 아닙니다. 유통기한이 빠르게 줄어드는 위험입니다.
참고
2PwnGPT: Automatic Exploit Generation Based on Large Language Models - ACL Anthology
4SoK: Potentials and Challenges of Large Language Models for Reverse Engineering
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.