수천 개 엑셀 취약점 목록의 배신: AI 공격 시대의 보안 관리 대전환

엑셀 시트에 쌓인 1만 개 보안 경고와 10분 만에 뚫리는 해킹 코드

지금 전 세계 보안팀과 개발팀 사이에서는 기묘한 연극이 벌어지고 있다. 보안 스캐너가 소프트웨어 소스코드와 라이브러리를 샅샅이 뒤져 취약점 식별 번호(CVE)를 수천 개씩 쏟아내면, 담당자는 이를 스프레드시트에 빼곡하게 정리해 개발팀으로 넘긴다. 개발팀은 서비스 출시 일정을 맞추느라 밤을 새우면서도 위험도 점수가 높다는 이유로 수백 개의 패치를 기계적으로 적용한다. 겉으로 보기에는 수많은 보안 허점을 고치며 안전해지는 것처럼 보인다. 하지만 실상은 다르다. 실제 서비스가 해킹당할 위험은 단 1%도 줄어들지 않았는데, 단지 점수 높은 취약점을 몇 개 지웠다는 이유로 안도하는 이른바 ‘CVE 극장(CVE Theater)‘에 빠져 있는 셈이다.

이러한 낡은 관행이 치명적인 위험으로 돌아온 결정적 계기는 생성형 인공지능(AI)의 등장이다. 과거 해커들이 공개된 소프트웨어 보안 결함을 분석해 실제 공격 코드(익스플로잇)를 짜는 데는 며칠에서 몇 주가 걸렸다. 보안팀에게는 공지가 뜨고 패치가 배포될 때까지 버틸 수 있는 시간적 완충 지대가 있었다. 하지만 이제 공격자들은 AI를 이용해 취약점 패치 공지가 뜨자마자 역설계 분석을 끝내고 10–30분 만에 공격 코드를 뽑아낸다. 게다가 단독으로는 별 위험이 없어 보이는 사소한 취약점 대여섯 개를 AI로 지능적으로 엮어 방어망을 우회하는 복합 침투 경로까지 손쉽게 설계한다.

반면 기업의 방어 방식은 10년 전과 비교해 달라진 것이 거의 없다. ‘취약점을 스캔하고, 심각도 점수를 매긴 뒤, 순서대로 개발팀에 전달해 패치한다’는 순차적 작업 방식은 완전히 마비되었다. 개발자가 작성하는 코드의 양은 AI 코딩 도구의 확산으로 전보다 서너 배 이상 폭증했고, 여기에 딸려 오는 오픈소스 라이브러리의 부피도 눈덩이처럼 불어났다. 보안팀이 엑셀 시트에 정리된 수천 개의 경고를 하나씩 검토하는 사이에, 공격자는 이미 자동화된 도구로 취약한 서버를 찾아내 장악해 버린다. 질문 자체를 완전히 바꿔야 할 시점이다. “우리 시스템에 취약점이 몇 개나 있는가?”를 세고 있을 때가 아니라, “지금 당장 외부 해커가 들어올 수 있는 진짜 문은 어디인가?”를 가려내야 한다.

취약점 점수 9.8의 허상: 실제 공격 가능성과 보안 지표 비교

취약점 관리 현장에서 가장 널리 쓰이는 공통 취약점 등급 시스템(CVSS)은 취약점 자체의 기술적 파괴력만을 따진다. 결함이 성공적으로 뚫렸을 때 시스템 권한을 얼마나 빼앗길 수 있는지를 0점에서 10점 사이의 점수로 환산할 뿐이다. 그러나 이 점수는 취약점을 둘러싼 현실의 맥락을 전혀 알려주지 않는다. 인터넷과 완전히 단절된 연구용 내부 서버의 취약점과, 전 세계 결제 트래픽을 처리하는 공개 웹서버의 취약점에 똑같이 ‘9.8점’이라는 딱지가 붙는 이유다.

결국 보안팀은 똑같이 치명적이라는 이유로 두 취약점을 같은 우선순위로 두고 씨름하게 된다. 그러나 실제로 공격 코드가 인터넷에 공개되어 활동 중인지, 해당 라이브러리의 취약한 함수가 서비스 구동 중에 실제로 호출(실행 경로 활성화)되는지를 따져보면 우선순위는 완전히 뒤바뀐다. 아래 표는 전통적인 점수 중심 관리 방식과 실제 위협 맥락 중심 관리 방식의 차이를 검증된 데이터 지표로 대조한 결과다.

개발팀 번아웃과 보안 구멍: 전통적 방식이 현장에 미치는 3대 타격

점수 매기기 중심의 취약점 관리가 한계에 부딪히면서, 기업 현장에서는 심각한 부작용이 잇따르고 있다. 개발 부서와 보안 부서의 갈등은 최고조에 달했고, 돈과 시간을 쏟아붓고도 침해 사고를 막지 못하는 역설이 반복된다.

1. 개발 생산성 저하와 막대한 운영 비용 낭비

보안팀이 매주 넘겨주는 수백 쪽 분량의 취약점 보고서는 개발팀의 일정을 완전히 마비시킨다. 개발자들은 새로운 비즈니스 기능을 개발하는 대신, 프로젝트 구석 어딘가에 포함된 오픈소스 라이브러리의 버전을 올리는 작업에 매달린다. 그러나 라이브러리 버전을 올리면 기존 코드와의 충돌이 발생해 서비스 장애로 이어지는 경우가 허다하다. 미국 기업 기준 소프트웨어 엔지니어 1명이 실제 서비스에 영향을 주지 않는 허수 취약점 패치에 쏟는 시간은 연간 수백 시간에 달하며, 이는 고스란히 기업의 개발 지연과 인건비 손실로 직결된다.

2. 치명적 공격 지점의 방치와 대응 지연

모든 경고를 똑같이 긴급한 상태로 분류하면, 정작 가장 먼저 막아야 할 진짜 구멍이 시야에서 사라진다. 실제로 해커가 악용하고 있는 인터넷 노출 취약점이 스프레드시트 300번째 줄에 묻혀 있는 사이, 개발팀은 외부에 노출되지도 않은 내부 백오피스 도구의 취약점을 고치느라 2주를 허비하는 참사가 일어난다. 취약점이 발견되고 공격이 들어오는 사이의 방어 골든타임이 AI로 인해 몇 시간 단위로 줄어든 상황에서, 이러한 늑장 대응은 치명적인 데이터 유출로 이어진다.

3. 소프트웨어 결함 뒤에 숨은 위험천만한 설정 오류 방치

기존의 취약점 도구는 코드의 결함(CVE)만 쳐다볼 뿐, 시스템이 어떻게 조립되어 있는지는 보지 못한다. 취약점 번호가 하나도 없는 완벽한 소프트웨어라도, 관리자 권한이 무제한으로 열려 있거나 기본 비밀번호를 그대로 사용하고 있다면 해커에게는 활짝 열린 대문이나 다름없다. 실제로 일어나는 대규모 클라우드 침해 사고의 대다수는 복잡한 코드 취약점이 아니라 과도한 접근 권한과 잘못된 네트워크 설정 같은 기본 설정 오류에서 시작된다. 소프트웨어 결함 찾기에만 매몰되어 설정 검증을 소홀히 하는 구조는 밑 빠진 독에 물을 붓는 격이다.

깨끗한 뼈대와 실시간 런타임 분석: 선도 기업의 2단계 방어 체계

보안을 잘하는 기업들은 취약점이 발견된 뒤에 허겁지겁 고치는 사후 처리 방식을 버렸다. 대신 취약점 자체가 운영 환경으로 들어오지 못하게 입구를 걸어 잠그고, 실제 운영 중인 환경을 실시간으로 감시하는 2단계 완충 장치를 운영한다.

첫 번째 완충 장치는 소프트웨어의 기초 뼈대를 단단하게 굳히는 일이다. 집을 지을 때 불량 벽돌을 쓰지 않는 것처럼, 애플리케이션을 만들 때 사용하는 컨테이너 기반 이미지와 언어 라이브러리를 사전에 검증된 안전한 상태로 정제해 제공한다. 여기에 보안 기술 구현 가이드(STIG) 같은 표준 점검 체계를 결합해 설정 오류를 자동으로 고쳐낸다. 개발자가 코드를 작성하는 단계에서는 정적 분석(SAST)과 AI 지원 코드 검사를 통해 위험한 함수 사용을 미리 차단한다. 취약점이 애초에 배포 파이프라인 안으로 굴러 들어오지 못하도록 바닥을 청소하는 작업이다.

두 번째 완충 장치는 ‘운영 환경(Production)을 유일한 진실의 원천’으로 삼는 것이다. 저장소에 담겨 있는 코드 상태와 실제 클라우드 서버에서 돌아가는 코드 상태는 완전히 다르다. 배포 과정에서 이미지가 바뀌고, 설정이 달라지며, 새로운 취약점이 수시로 등장한다. 따라서 배포 전 검사 결과만 믿고 안심해서는 안 된다.

선도적인 IT 기업들은 컨테이너가 실행 중인 실제 런타임 환경에서 네트워크 트래픽이 취약한 모듈로 닿을 수 있는지, 취약한 바이너리가 메모리에 적재되어 구동 중인지를 실시간으로 추적한다. 아무리 위험 점수가 높은 취약점이라도 해당 패키지가 운영 환경에서 호출되지 않는다면 조치 순위를 낮춘다. 반대로 점수가 낮더라도 외부에 노출되어 있고 호출 경로가 열려 있다면 즉시 격리 조치에 들어간다. 한정된 보안 인력을 가장 위험한 1%의 핵심 급소에 집중시키는 전략이다.

무의미한 엑셀 작업을 멈추고 시스템을 방어하는 3단계 방어선

AI가 공격 속도를 기하급수적으로 끌어올리는 현실에서 기업이 당장 취해야 할 행동 지침은 명확하다. 관행적인 보고서 작성을 멈추고, 즉각적인 위험 완충 체계를 구축해야 한다.

1차 방어선: 즉각적인 법적·운영 리스크 스크리닝

보안팀은 개발팀으로 보내는 엑셀 목록 전송을 중단하고 선별 기준을 재정립해야 한다. 지금 즉시 모든 취약점 목록에 ‘외부 인터넷 노출 여부’와 ‘공지된 익스플로잇 존재 여부(CISA KEV 목록 등 참조)‘라는 두 가지 필터를 적용하라. 이 두 가지 조건에 해당하지 않는 취약점은 아무리 기본 점수가 높아도 개발팀 조치 티켓에서 제외한다.

동시에 사내에서 사용 중인 기본 컨테이너 이미지와 오픈소스 패키지 중 불필요하게 권한이 높거나 오래 방치된 항목을 걷어내는 정리 작업을 시작해야 한다. 이것만으로도 개발팀에 쏟아지는 불필요한 보안 티켓의 80% 이상을 즉시 덜어낼 수 있으며, 개발팀은 남겨진 치명적 위험 20%를 당일 안에 막을 수 있는 여유를 얻게 된다.

2차 방어선: 코드 실행 경로 추적 및 보안 설정 자동화

운영 환경에서 코드가 실제로 어떻게 돌아가는지 감시할 수 있는 관측 체계를 갖추어야 한다. 컨테이너가 배포된 후 취약점이 포함된 특정 함수가 실제로 호출되는지 확인하는 런타임 분석 도구를 도입한다. 호출되지 않는 비활성 코드는 패치 순위를 뒤로 미루고, 실제 실행되는 경로만 우선적으로 가로막는 임시 방화벽 규칙을 적용한다.

이와 함께 소프트웨어 구성 점검 도구를 도입해 운영체제와 클라우드 설정이 안전한 기준(STIG)을 따르고 있는지 자동 점검 체계를 만든다. 취약점을 패치하는 것은 코드를 다시 빌드하고 배포해야 하므로 시간이 걸리지만, 과도하게 열린 포트를 닫거나 관리자 권한을 회수하는 설정 변경은 몇 분 만에 끝낼 수 있다. 공격자가 취약점을 뚫고 들어오더라도 내부에서 다른 시스템으로 넘어가지 못하도록 발을 묶어버리는 안전망을 까는 것이다.

3차 방어선: AI 기반 자동 대응과 개발 파이프라인 내재화

궁극적으로는 취약점의 발견과 조치가 사람이 개입하는 수작업 없이 파이프라인 안에서 저절로 이루어지는 구조를 만들어야 한다. 개발자가 코드를 저장소에 올리는 순간, 사내 보안 규칙을 위반한 코드는 AI 스캐너가 실시간으로 감지해 자동으로 수정된 코드 풀 리퀘스트(PR)를 제시하도록 만든다.

운영 환경에서 제로데이 취약점이 새로 발표되더라도, 런타임 통제 시스템이 해당 취약점과 연결된 외부 네트워크 인입선을 스스로 차단하고 안전한 최신 기본 이미지로 컨테이너를 재배포하는 자율 방어 체계를 갖추어야 한다. 공격자가 AI로 공격을 자동화하고 있다면, 방어자 역시 방어의 모든 연결 고리를 자동화해야만 승산이 있다. 엑셀을 버리고 시스템의 실제 맥락을 통제하는 기업만이 AI 시대의 보안 전쟁에서 살아남을 수 있다.