Azul의 2026년 AI 취약점 격차 보고서: 기업의 패치 적용이 AI 위협을 따라가지 못하는 것으로 나타나

Azul의 2026년 AI 취약점 격차 보고서에 따르면, 보안 책임자들이 AI를 활용하는 공격자들의 속도에 대해 갖는 인식과 실제 조직에서 수정 사항을 배포하는 데 걸리는 시간 사이에는 차이가 있습니다. 미국 보안 책임자 300명을 대상으로 한 설문에서 응답자의 69%는 공격자가 3일 이내에 작동하는 익스플로잇을 만들 수 있다고 답했습니다. 반면 44%는 자사 조직이 프로덕션 환경 전반에 중대한 취약점에 대한 패치를 적용하는 데 4일 이상 걸린다고 답했습니다.

보고서에서 가장 눈에 띄는 결과는 응답자들이 이러한 지연과 연관 지은 경험입니다. 응답자의 85%는 패치 적용 지연으로 인해 발생한 사고, 사고로 의심되는 사례 또는 아차 사고를 보고했습니다. 이 수치는 응답자들이 보고한 경험을 나타내며, 독립적으로 검증된 침해 발생률은 아닙니다. 또한 해당 사건의 원인이 AI였다는 점을 입증하지도 않습니다.

Azul의 의뢰로 Censuswide가 수행한 이 조사는 Java를 대규모로 배포한 조직을 대상으로 합니다. 보고서가 전하는 더 큰 메시지는 운영상의 문제입니다. 취약점을 알아내는 것은 시작에 불과합니다. 수정 사항은 테스트를 통과하고 영향을 받는 시스템에 도달해야 하며, 팀이 전체적으로 파악하지 못할 수도 있는 시스템 전반의 취약한 상태를 해소해야 합니다.

엇갈리는 두 개의 시계

이 설문은 공격자에 대한 보안 책임자들의 예상과 자사 조직의 배포 역량을 구분해 살펴봅니다.

• 69%는 AI를 활용하는 공격자가 3일 이내에 익스플로잇을 만들 수 있다고 봅니다. 이 가운데 22%는 그 시간이 24시간 미만이라고 답했습니다.
• 56%는 프로덕션 환경 전반에 중대한 패치를 3일 이내에 배포할 수 있다고 답했습니다. 이 중 13%는 24시간 미만, 43%는 1~3일이 걸린다고 했습니다.
• 44%는 더 오래 걸린다고 답했습니다. 32%는 4~6일, 12%는 그보다 더 많은 시간이 필요하다고 했습니다.

이 수치는 설문 응답의 분포이며, 특정 취약점을 두고 공격자가 각 조직과 실제로 속도 경쟁을 벌인 결과를 측정한 것은 아닙니다. 이러한 차이는 대비 태세에 대한 우려를 뒷받침하지만, 모든 기업에 정확히 3일의 취약 노출 기간이 발생한다는 뜻으로 해석해서는 안 됩니다.

하루를 기준으로 삼아도 같은 불균형이 나타납니다. 공격자가 그만큼 빠르게 움직일 것으로 예상하는 응답자는 22%인 반면, 그 시간 안에 수정 사항을 배포할 수 있다고 답한 조직은 13%였습니다. 한편 59%는 AI 기반 공격 도구로 인한 위험 노출이 커졌다고 인정하면서도 보안 태세는 바꾸지 않았습니다.

지연의 큰 부분을 차지하는 테스트

조사 대상 조직의 58%에서는 Java 런타임 업데이트 테스트로 패치 주기가 4일 이상 늘어납니다. 이 가운데 36%는 4~6일, 22%는 1주 이상이 걸린다고 답했습니다. 또 33%는 1~3일, 9%는 24시간 미만이 걸린다고 했습니다. 테스트를 생략한다고 답한 응답자는 없었습니다.

런타임 변경은 여러 애플리케이션에 영향을 줄 수 있으므로 테스트에는 실질적인 목적이 있습니다. 보안 업데이트로 중대한 서비스에 장애가 발생하면 또 다른 운영 문제가 생기기 때문입니다. 보고서는 전체 OpenJDK 분기별 릴리스에 취약점 수정 사항과 함께 보안과 무관한 변경 사항도 포함될 수 있어 업데이트 범위가 부담을 키운다고 설명합니다.

Azul은 별도로 6년이 넘는 기간에 걸쳐 OpenJDK 분기별 업데이트 26건을 평가하고, 그중 6건을 심각한 회귀 문제를 일으킨 업데이트로 분류했습니다. 23%라는 이 수치는 공급업체가 릴리스를 평가한 결과이지, 개별 고객의 애플리케이션이 얼마나 자주 손상될지에 대한 설문 추정치는 아닙니다.

패치를 더 빠르게 적용하는 데 가장 큰 걸림돌로는 응답자의 44%가 광범위한 테스트를, 40%가 영향을 받는 시스템의 복잡성이나 노후화를, 36%가 알려진 취약점에 대한 제한적인 가시성을 꼽았습니다. 공급업체의 패치 지연을 지목한 응답자는 25%였습니다. 이러한 양상은 취약점 해결 과제의 상당 부분이 기업 내부의 배포 절차에 있음을 보여줍니다.

사고 보고와 인벤토리 공백은 구분해서 살펴봐야

응답자의 55%는 패치 적용 지연으로 발생한 것으로 확인된 사고를, 53%는 아차 사고를 보고했습니다. 여러 항목을 선택할 수 있었으므로 두 수치는 서로 겹치며, 합산해서는 안 됩니다. 전체 응답자의 85%라는 대표 수치에는 사고로 의심되는 사례도 포함됩니다.

이 설문만으로는 이러한 사건이 모두 Java 취약점과 관련됐다고 단정할 수 없습니다. 참가자들은 Java를 대규모로 사용하는 조직에 속해 있지만, 조사에는 소프트웨어 패치 전반에 관한 질문과 Java 런타임에만 초점을 맞춘 질문이 모두 포함됐습니다.

인벤토리 파악도 또 다른 어려움입니다. 자사 프로덕션 Java 런타임 환경의 90% 이상에 최신 보안 패치가 적용돼 있다고 답한 응답자는 19%에 그쳤습니다. 이는 81%가 그 기준에 미치지 못한다는 뜻이지, 81%의 조직에 최신 런타임이 전혀 없다는 뜻은 아닙니다. 약 5분의 1은 자사 런타임 환경의 절반 이하에만 최신 패치가 적용돼 있다고 답했습니다.

이와 별도로 51%는 임베디드, 레거시, 비관리형 인스턴스를 포함한 중요 Java 런타임에 대한 가시성이 부분적이거나 제한적이라고 인정했습니다. 패키징된 애플리케이션이나 컨테이너 내부에서 취약한 런타임을 찾는 일은 중앙에서 관리하는 설치 환경을 식별하는 것보다 어려울 수 있습니다. 배포 절차가 도달하지 못하는 시스템의 취약한 상태는 패치로 해소할 수 없습니다.

Azul의 기술이 논의에 더하는 점

Azul의 보안 업데이트 제공 방식은 이미 안정화된 OpenJDK 기준 버전을 바탕으로, 일부 릴리스에 보안 수정 사항만 포함합니다. Azul은 분기별 업데이트와 특정 대상을 위한 월별 업데이트, 정기 일정 외 업데이트를 제공해 긴급 수정 사항을 배포할 때 기업이 평가해야 하는 무관한 변경 사항의 양을 줄이는 것을 목표로 합니다.

이는 변경 관리의 필요성을 없애는 것보다 범위가 좁은 기술적 개입입니다. 코드 변경을 제한하면 검증 범위를 줄일 수 있지만, 애플리케이션별 점검, 배포 책임, 롤백 준비도 여전히 중요합니다. Azul은 이 보고서의 후원사이며, 보고서에서 측정한 문제를 해결하는 제품을 판매합니다.

Azul의 Java 인벤토리 및 취약점 도구는 작업 흐름의 다른 측면을 다룹니다. 런타임, 버전, 노출 현황을 파악해 새 취약점 공개 내용을 영향을 받는 시스템과 연결할 수 있도록 합니다. 이 보고서는 조사 대상 조직이 해당 제품을 도입하면 얼마나 개선될지 보여 주는 통제된 비교 결과를 제시하지 않습니다.

Azul의 공동 창업자이자 CEO인 Scott Sellers는 “우리 연구에 따르면 보안 책임자들은 위협을 이해하고 있습니다. 더 이상 격차는 인식이 아니라 실행입니다”라고 말했습니다.

패치 의지를 측정 가능한 프로세스로 전환하기

향후 1년 동안 32%는 노출을 줄이기 위한 핵심 전략으로 더 빠르고 빈번한 패치를 꼽았으며, 26%는 소프트웨어 및 런타임 인벤토리 개선을 선호했습니다. 또 다른 17%는 더 빠른 패치 대신 탐지와 대응을 우선시했습니다.

이 연구는 취약점 공개부터 해결까지 전체 과정을 추적할 것을 제안합니다. 영향을 받는 시스템은 무엇인지, 담당자는 누구인지, 어떤 테스트가 필요한지, 수정 사항이 실제로 프로덕션 환경에 적용되었는지를 확인해야 합니다. 관련 시스템 전반에 걸쳐 완료 여부를 검증할 수 있을 때에만 기한 설정이 유용합니다.

미국 조사 결과는 2026년 8월 3~7일, 직원이 1,000명 이상이고 프로덕션 환경에서 Java/JVM을 상당 규모로 사용하는 조직의 보안 책임자를 대상으로 실시한 현장 조사에서 나왔습니다. 이는 정해진 모집단에서 수집한 자기 보고 응답이며, 전체 기업을 전수 조사한 결과나 익스플로잇 개발을 직접 측정한 결과는 아닙니다.

전체 2026년 AI 취약점 격차 보고서에서 조사 결과와 방법론을 자세히 확인할 수 있습니다. 이 보고서가 가장 분명하게 시사하는 점은 패치 속도와 런타임 가시성을 함께 개선해야 한다는 것입니다. 조직이 영향을 받는 모든 배포 환경을 파악하거나 업데이트가 해당 환경에 적용되었는지 확인할 수 없다면, 신속한 수정의 가치는 제한적입니다.