“버그가 있다”는 소문 한 줄, AI에게는 익스플로잇 설계도다

“어느 기능에 버그가 있다더라.” 예전에는 확인되지 않은 소문에 가까웠습니다. 하지만 이제 AI는 그 한 문장을 단서로 취약한 코드를 찾아내고, 공격 방법까지 좁혀갈 수 있습니다.

소문이 공격의 출발점이 되는 이유

익스플로잇은 소프트웨어의 취약점을 실제 공격으로 이어주는 코드나 기법입니다. 예전에는 익스플로잇을 만들려면 상당한 전문성과 시간이 필요했습니다.

공격자는 프로그램 구조를 분석하고, 의심스러운 입력값을 수없이 넣어봐야 했습니다. 충돌이 나면 원인을 추적해 보안 장치를 우회할 방법까지 찾아야 했습니다.

AI는 이런 탐색에 드는 비용을 크게 낮춥니다. “이미지 처리 기능에서 메모리 문제가 발생한다”는 소문만 있어도 살펴볼 영역을 좁힐 수 있습니다. 관련 코드를 분석하고 비정상적인 입력값을 자동으로 만들며, 실패 결과를 토대로 다음 실험을 설계할 수도 있습니다.

소문이 정답을 건네는 건 아닙니다. 대신 넓은 코드 숲에서 어디부터 파야 하는지 짚어줍니다. AI에는 그만한 단서도 충분한 가치가 있습니다.

불완전한 정보가 오히려 위험할 수 있습니다

보안 업계에서는 그동안 취약점의 세부 내용을 감추면 위험이 줄어든다고 여겨왔습니다. 제품명이나 영향을 받는 기능만 먼저 알리고, 공격에 필요한 기술 정보는 나중에 공개하는 방식입니다.

AI 시대에는 이런 전략이 예전만큼 안전하지 않습니다. 사람에게 모호하게 들리는 설명도 AI에는 탐색 조건으로 작동하기 때문입니다.

예를 들어 “특정 파일을 열 때 문제가 생긴다”는 공지가 있다고 가정해 보겠습니다. AI는 지원하는 파일 형식과 파서 코드를 비교할 수 있습니다. 파서는 파일 내용을 읽어 프로그램이 이해할 수 있는 형태로 바꾸는 부분입니다. 공격이 자주 일어나는 경계값과 메모리 처리 코드부터 검사할 수도 있습니다.

결국 공개자가 감춘 세부 사항을 AI가 거꾸로 추론할 가능성이 생깁니다. 부분 공개는 방어자에게는 부족하면서 공격자에게는 쓸모 있는 어정쩡한 상태가 될 수 있습니다.

다만 현재 공개된 근거는 제한적입니다. 이번 조사에서는 2026년 7월 30일부터 8월 29일까지 이 현상을 구체적으로 입증할 만한 커뮤니티 사례를 확인하지 못했습니다. 따라서 “AI가 소문만으로 실제 익스플로잇을 완성했다”는 주장을 일반화하기보다는 이미 대비해야 할 현실적인 위협 모델로 보는 편이 타당합니다.

취약점 공개의 기준은 정보량이 아니라 재현 가능성입니다

앞으로는 “얼마나 자세히 공개했는가”보다 “AI가 이 정보로 얼마나 빨리 공격을 재현할 수 있는가”를 따져야 합니다.

제품명과 영향 범위만 알려도 코드가 공개된 오픈소스 프로젝트라면 위험할 수 있습니다. 수정된 코드를 먼저 배포하면 패치 전후의 차이를 비교해 취약점을 찾는 이른바 패치 디핑도 쉬워집니다. AI는 바뀐 몇 줄을 분석해 개발자가 무엇을 막으려 했는지 추론할 수 있습니다.

공개 절차도 바뀌어야 합니다. 패치 제공과 사용자 통보, 보안 제품의 탐지 규칙 배포가 더 촘촘하게 맞물려야 합니다. 단순히 “세부 정보는 90일 뒤 공개한다”는 일정만으로는 부족합니다.

공개하기 전에 AI로 공격을 재현해보는 테스트도 필요합니다. 내부 보안팀에 같은 단서만 주고 취약점을 찾아낼 수 있는지 확인하는 방식입니다. 짧은 시간 안에 재현할 수 있다면 그 공지에는 이미 공격자에게도 충분한 정보가 담겼을 가능성이 큽니다.

방어자도 AI를 같은 속도로 써야 합니다

그렇다고 취약점 정보를 무조건 숨기는 게 해답은 아닙니다. 지나치게 비공개로 처리하면 사용자와 보안 담당자의 대응이 늦어집니다. 연구자끼리 검증하기도 어려워집니다.

대신 공개와 방어 준비를 따로 떼지 말고 하나의 과정으로 묶어야 합니다. 취약점 공지를 내기 전에 패치를 마련하고, 침해 여부를 확인할 탐지 방법도 함께 제공해야 합니다. 패치를 곧바로 적용하기 어려운 조직을 위한 임시 완화책도 필요합니다.

기업 역시 외부 소문을 단순한 평판 문제로만 봐서는 안 됩니다. 특정 제품이나 기능에 버그가 있다는 말이 나오는 순간부터 실제 공격 가능성을 조사해야 합니다. 사실이 아닌 소문이라도 공격자가 해당 영역을 집중적으로 들여다보는 계기가 될 수 있기 때문입니다.

핵심은 방어 절차가 공격자의 자동화 속도보다 뒤처지지 않는 것입니다. AI가 취약점을 찾는 시간을 줄인다면 공개를 결정하고 패치를 배포하는 데 걸리는 시간도 함께 줄여야 합니다.

취약점 공개의 목적은 비밀을 오래 지키는 데 있지 않습니다. 사용자가 공격받기 전에 고칠 시간을 확보하는 데 있습니다. 이제는 보안 공지 한 줄을 쓸 때도 “사람이 무엇을 알게 될까”뿐 아니라 “AI가 여기서 무엇을 추론할까”를 함께 물어야 합니다.