AI 에이전트 100개가 혼자서 기업 100곳을 뚫었다

처음 이 연구를 접했을 때 숫자보다 구조가 먼저 눈에 들어왔다. AI 에이전트 100개가 기업 100곳을 대상으로 침투 테스트를 벌였고, 그 과정에 사람이 거의 끼지 않았다. 테스트 대상 기업에는 금융, 의료, 제조, 기술 스타트업이 고루 포함돼 있었고, 어느 업종이라도 예외가 없었다. 알고 나니 보안에 대해 갖고 있던 생각이 조금 달라졌다.

에이전트가 움직이는 구조

여기서 말하는 에이전트는 LLM을 기반으로 자율적으로 판단하고 행동하는 소프트웨어 단위다. LLM은 대형 언어 모델로, 텍스트를 이해하고 명령을 실행하는 AI 시스템이다. 사람이 매번 지시하지 않아도 목표를 주면 스스로 단계를 만들어 실행한다. 예컨대 “이 IP 대역의 외부 서비스에서 인증 우회 경로를 찾아라”라는 목표 하나를 받으면, 어떤 도구를 쓸지, 어떤 순서로 시도할지, 실패했을 때 어떤 대안으로 넘어갈지를 모두 스스로 결정한다. 이번 실험에서는 에이전트 100개가 각자 역할을 나눠 동시에 움직였다.

역할은 크게 세 단계로 나뉜다. 정찰 에이전트가 대상 기업의 외부 노출 면을 먼저 훑는다. 공격 표면이란 외부에서 접근 가능한 서비스, 포트, 도메인의 집합이다. 정찰 단계에서는 공개된 DNS 레코드, Shodan 같은 인터넷 스캔 데이터베이스, 깃허브에 실수로 올라간 설정 파일까지 자동으로 수집해 공격 표면 지도를 완성한다. 그 결과를 취약점 탐색 에이전트가 넘겨받아 알려진 취약점 목록과 대조해 우선순위를 매기고, 침투 에이전트는 그 순위를 따라 실제 접근을 시도한다.

100개가 병렬로 돌기 때문에 한 에이전트가 막히면 다른 에이전트가 다른 경로를 동시에 시도한다. 예를 들어 VPN 게이트웨이 쪽 경로가 탐지로 막히는 순간, 나머지 에이전트들은 웹 애플리케이션이나 API 엔드포인트 쪽을 이미 두드리고 있다. 사람 레드팀이 순차적으로 시도하는 방식과 근본적으로 다르다. 레드팀은 공격자 역할을 맡아 시스템의 취약점을 찾는 보안 전문가 그룹을 말한다. 이 구조는 일리노이 대학교 연구팀이 공개한 자율 취약점 공격 논문에서 처음 체계적으로 정리됐고, 특히 최근 공개된 취약점을 대상으로 할수록 자동화 에이전트의 성과가 두드러졌다.

뚫리는 데 걸린 시간

사람 레드팀이 초기 정찰부터 첫 침투까지 평균 수일이 걸린다는 건 업계에 알려진 수치다. AI 에이전트 팀은 같은 과정을 수 시간 안에 마쳤다. 단순히 빠른 게 아니라 성공률 자체도 달랐다. 공개된 취약점이 있는 환경에서 에이전트가 15분 안에 초기 접근 권한을 확보한 사례도 있었다. Wired가 이 흐름을 취재한 기사에서도 자동화 에이전트의 성공률이 전통적 방식 대비 현저히 높다는 점이 반복적으로 언급된다.

차이가 가장 크게 벌어진 단계는 취약점 탐색이었다. 사람은 알려진 CVE 목록을 검토하고 환경에 맞게 우선순위를 정하는 데 시간이 든다. CVE는 공개된 보안 취약점에 번호를 붙여 관리하는 목록이다. 에이전트는 이 작업을 병렬로 처리하면서 특정 소프트웨어 버전과 해당 CVE를 자동으로 연결해 익스플로잇 코드까지 즉시 대입하는 방식으로 탐색 범위를 더 넓게 가져갔다. 패치가 이제 막 공개된 취약점일수록 기업 측에서 아직 업데이트를 적용하지 못한 경우가 많아 에이전트 쪽 성공률이 더 높게 나왔다.

속도 차이는 기업 규모와 무관했다. 보안 투자가 적은 중소기업과 대기업 모두에서 비슷한 패턴이 확인됐다. 보안팀이 20명 이상인 조직도 에이전트가 초기 거점을 확보하는 시간은 크게 줄지 않았다. 투자 규모가 시간 격차를 줄이지 못한다는 점이 이 실험에서 나온 불편한 부분이다. 더 정확히는, 사람 중심의 방어 구조가 자동화된 공격 속도 자체를 따라잡기 어려운 본질적인 한계를 드러낸 것이다.

뚫린 기업의 공통점

침투에 성공한 사례를 들여다보면 반복적으로 나오는 취약점 유형이 있다. 가장 많이 나온 건 잘못 설정된 클라우드 권한이었다. 퍼블릭 클라우드 환경에서 IAM 정책이 지나치게 넓게 열려 있는 경우가 여러 기업에서 공통으로 발견됐다. IAM은 클라우드 서비스에서 누가 무엇을 할 수 있는지 정의하는 접근 제어 체계다. 구체적으로는 특정 S3 버킷이 인증 없이 공개 읽기 상태였거나, 람다 함수에 연결된 실행 역할이 계정 전체에 관리자 권한을 갖고 있는 경우가 침투 경로로 쓰였다.

두 번째는 패치가 밀린 외부 노출 서비스였다. 웹 애플리케이션, VPN 게이트웨이, 원격 접속 도구 같은 외부 연결 지점에 업데이트가 쌓여 있는 경우가 많았다. 실제로 6개월 이상 패치가 적용되지 않은 SSL VPN 제품이 침투 경로로 쓰인 사례가 복수로 나왔으며, 에이전트는 버전 정보를 읽는 즉시 대응하는 익스플로잇을 자동으로 선택해 실행했다. CISA가 정기적으로 발행하는 취약점 권고문에서도 동일한 유형이 반복해서 언급된다.

세 번째는 인증 관련 약점이었다. 멀티팩터 인증이 적용되지 않은 관리자 계정이나 기본 자격증명을 그대로 쓰는 서비스가 침투 경로가 됐다. 네트워크 장비, 모니터링 콘솔, 내부 대시보드처럼 외부에서 보면 중요해 보이지 않는 서비스에서도 초기 설치 당시의 기본 패스워드가 그대로 남아 있었다. 이 세 가지는 특별히 새로운 취약점이 아니다. 알려진 문제가 실제 기업 환경에서 계속 남아 있다는 사실 자체가 이 실험이 보여주는 핵심이다.

방어가 느려지는 구조

공격이 자동화되면 방어도 자동화하면 된다고 생각하기 쉽다. 그런데 구조를 보면 그렇게 단순하지 않다. 현재 대부분의 기업 보안 대응은 사람이 경보를 확인하고 판단하고 조치하는 흐름 위에 서 있다. SIEM이나 EDR 같은 자동화 도구를 도입해도 최종 판단과 격리, 차단 명령은 사람 손을 거치는 경우가 대부분이다. 이 흐름은 속도보다 판단 정확도를 위해 설계된 구조다.

AI 에이전트가 초당 수백 개의 요청을 여러 경로로 동시에 보내면 경보가 한꺼번에 터진다. 보안 운영 센터 담당자가 처리할 수 있는 경보 수에는 물리적인 한계가 있다. 실제로 대규모 공격 시뮬레이션에서는 30분 만에 수천 건의 경보가 쌓여 담당자가 트리아지 자체를 포기한 사례가 보고된다. 경보가 너무 많으면 중요한 경보가 묻히거나 팀이 경보 피로에 빠진다. 경보 피로는 반복된 알림에 둔감해져 실제 위협을 놓치게 되는 상태를 말한다.

자동화된 방어 도구를 도입해도 격차가 쉽게 좁혀지지 않는 이유가 있다. 공격 에이전트는 탐지 패턴을 학습하면서 다음 시도를 조정할 수 있다. 정상 트래픽으로 위장하거나 시도 간격을 조금씩 늘려 임계치 기반 탐지를 우회하는 방식으로 매번 다른 패턴을 만들어낸다. 방어 시스템이 패턴 업데이트를 반영하는 속도보다 공격 패턴이 바뀌는 속도가 더 빠를 수 있다. 사람이 개입할 시간이 줄어드는 만큼 오탐을 걸러내는 판단력도 함께 빠져나가는 셈이다.

이 실험이 가리키는 방향은 결국 하나다. 보안 대응 구조 자체가 사람 중심에서 벗어나야 한다는 것이다. 공격 탐지부터 차단 실행까지 자동화된 루프를 갖추지 못하면 속도 격차는 계속 벌어진다. 그 전환이 얼마나 빠르게 일어날 수 있는지는 아직 불확실하다. 다만 공격 쪽의 자동화가 방어 쪽보다 먼저, 더 빠르게 진행되고 있다는 건 이 실험이 확인한 가장 불편한 사실이다.