AI 시대의 취약점 공격, 이제는 공격 대상이 된 이후를 고민해야 한다

AI가 취약점 탐색과 공격의 비용을 낮추면서, 이제 질문은 "공격받을 것인가"가 아니라 "공격받은 뒤 얼마나 빨리 알아채고, 피해를 막고, 회복할 수 있는가"로 바뀌고 있다. 이 글은 공격 방식의 변화에서 출발해 오픈소스 관리, 보안 검증의 개방, 그리고 보안 평가와 책임의 기준까지 차례로 살펴본다.
1. 누구나 공격 대상이 되는 시대
가. AI가 낮춘 공격 비용
인터넷에 연결된 시스템을 노린 무차별 스캐닝과 자동화 공격은 예전에도 있었다. 달라진 점은 AI가 그 이후 과정까지 자동화하기 시작했다는 것이다. 취약점을 분석하고, 공격 코드를 생성·수정하고, 다양한 실행 환경에서 공격이 통하는지 검증하는 일까지 사람 대신 AI가 처리할 수 있게 되었다.
그 결과 공격의 속도와 범위, 효율이 함께 달라지고 있다. 실제로 최근 공개된 PHP2Shell 취약점을 분석한 연구자들은 과거 전문가가 수개월 걸려 하던 공격 코드 개발을 AI가 며칠로 단축했다고 밝혔다. 그동안 실제 공격으로 연결하기 어렵다고 여겨진 오래된 유형의 버그도 이제는 공격 가능한 대상이 되었다.
나. 대상을 고르는 방식이 바뀌었다
주목할 점은 공격 횟수가 늘어난다는 사실 자체가 아니다. 공격자가 대상을 고르는 방식과, 침투에 성공한 뒤 그 시스템을 활용하는 방식이 달라지고 있다는 점이다.
기존에는 공격자가 특정 기업이나 서비스를 정하고, 그 대상이 가진 정보와 자산의 가치를 따진 뒤 공격하는 방식이 일반적이었다. 그러나 최근 늘어나는 기회주의적 자동화 공격은 이 순서를 따르지 않는다. 인터넷에 노출된 시스템을 폭넓게 탐색해 침투 가능한 곳부터 확보하고, 그다음에 활용 방법을 판단한다.
돈이 되는 사이트를 먼저 찾아 공격하는 것이 아니라, 공격 가능한 사이트를 먼저 확보한 뒤 그 가치를 판단한다.
다. 작은 사이트도 예외가 아니다
이 변화는 소규모 웹사이트나 서비스를 운영하는 관리자에게도 중요한 의미가 있다. 과거에는 사이트가 작고, 중요한 정보가 없으며, 외부에 알려지지 않았다는 이유로 공격 가능성을 낮게 보기도 했다. 하지만 자동화된 대량 공격에서는 인지도나 규모보다 취약점이 있는지, 외부에서 접근할 수 있는지가 더 중요한 기준이 된다.
공격자는 그 사이트가 누구의 것인지 몰라도 공격할 수 있고, 침투에 성공한 뒤에야 활용 가치를 따진다. 이때 침해된 사이트는 데이터 유출이나 서비스 장애에서 끝나지 않을 수 있다.
중요한 정보가 없는 사이트라도 서버 자원과 네트워크 접근 권한 자체가 공격자에게는 가치가 된다. 
시스템의 규모가 작거나 보유 정보의 가치가 낮다는 사실은 더 이상 공격 대상에서 빠질 이유가 되지 못한다. AI가 대상 탐색과 침투 판단의 비용을 낮출수록 이 문제는 더 커진다.

2. 알려진 취약점 확인만으로는 부족하다
가. SBOM과 알려진 취약점 관리의 한계
현대의 웹 서비스는 수많은 오픈소스 구성 요소 위에서 동작한다. 자체 개발한 소프트웨어라도 그 아래에는 운영체제, 런타임, 프레임워크, 라이브러리가 겹겹이 놓여 있다.
지금까지는 SBOM(소프트웨어 구성 명세서)으로 구성 요소를 식별하고, 이를 알려진 취약점 정보와 대조해 위험을 확인하는 방식이 중요한 관리 수단이었다. 
이 과정은 여전히 필요나 구성 요소 목록과 알려진 취약점을 확인했다고 해서 서비스가 안전하다고 결론 내릴 수는 없다. 
같은 소프트웨어라도 어떤 환경과 설정에서, 어떤 입력을 받아 실행되는지에 따라 실제 공격 가능성과 피해 범위가 달라지기 때문이다.
나. PHP2Shell이 보여준 것
2026년 10월 공개된 PHP2Shell(CVE-2026-109618, CVE-2026-109619)은 이 문제를 잘 보여준다. 
기존 웹 보안은 실행 파일 업로드나 애플리케이션 입력값 조작을 통한 명령 실행에 주로 관심을 기울여 왔다. 
반면 PHP2Shell은 애플리케이션이 아니라 PHP 엔진 자체의 요청 처리와 메모리 관리 과정에서 발생한 취약점이다.
• 별도의 인증 없이 악의적으로 구성된 HTTP 요청을 통해 PHP 워커의 메모리에 접근하거나, 실행 환경과 공격 경로에 따라 서버에서 임의의 코드를 실행할 수 있다.
• 애플리케이션 코드가 실행되기 전에 동작하므로, 코드가 안전하고 업로드를 제한해도 막을 수 없으며 애플리케이션 로그에도 거의 남지 않을 수 있다.
핵심은 특정 웹 애플리케이션 하나의 문제가 아니라는 점이다. 수많은 서비스가 공통으로 의존하는 실행 환경 자체가 공격의 출발점이 될 수 있다. 또한 구성 요소를 정확히 파악하고 있더라도, 아직 알려지지 않은 취약점이나 실제 실행 과정에서 생기는 위험까지 미리 알 수는 없다.
이 사례는 공개 시점의 문제도 드러냈다. 취약점 정보가 조율된 공개 이전에 유출되었고, 공식 공개 4일 전인 10월 17일에는 이미 악용 시도가 관측되었다. 실제 침해 성공 여부와 별개로, 방어자가 취약점을 인지하기 전에 공격이 시작될 수 있다는 것이 현실로 확인된 셈이다.
다. 취약점이 없다는 전제에서 벗어나기
모든 오픈소스의 모든 실행 경로를 검증하거나, 앞으로 발견될 취약점을 미리 제거하는 것은 현실적으로 불가능하다. AI 기반 취약점 탐색을 도입해도 모든 취약점을 찾는다고 보장할 수 없다. 
따라서 보안 전략은 취약점이 존재하지 않는다는 전제에서 출발할 수 없다.
구성 요소와 버전을 관리하는 데서 더 나아가, 다음을 지속적으로 확인해야 한다.
1. 실제 실행 환경에서 취약점이 악용될 수 있는가
2. 외부에서 접근 가능한 공격 경로가 존재하는가
3. 침투가 일어나면 어떤 행위가 나타나는가
4. 침해가 다른 시스템으로 확산될 수 있는가
취약점이 공개된 뒤에야 대응을 시작해서는 공격 속도를 따라가기 어렵다. 취약점 관리, 외부 공격 표면 관리, 실행 환경 행위 모니터링, 확산 방지, 신속한 대응과 복구를 하나로 이어진 관리 과정으로 묶어야 한다.
이제 "우리 시스템에 알려진 취약점이 있는가?"라는 질문만으로는 충분하지 않다. 앞으로 물어야 할 질문은 이것이다.
취약점이 공개되거나 우리가 인지하기 전에도 공격받을 수 있다고 가정할 때, 우리는 얼마나 빨리 탐지하고, 피해를 어디까지 제한하며, 정상 상태로 복구할 수 있는가?
사이버 복원력(Cyber Resilience)도 사고 이후의 복구 계획에 머물러서는 안 된다. 실제 공격 상황에서 예방, 탐지, 대응, 복구가 얼마나 효과적으로 작동하는지 검증할 수 있는 운영 역량이어야 한다.
3. 숨기는 보안에서 검증받는 보안으로
가. 감추는 것만으로는 막기 어렵다
여기서 말하는 보안 플랫폼은 보안 솔루션 벤더의 제품뿐 아니라, 기업이 서비스를 제공하기 위해 운영하는 플랫폼의 보안 설계 전반을 가리킨다. 많은 기업은 이 기술 구조를 감추는 것을 보안의 기본으로 여겨 왔다.
그러나 AI가 취약점 탐색과 공격을 자동화할수록, 기술 정보를 감추는 것만으로 공격 가능성을 제한하기는 점점 어려워진다. 시스템의 보안은 설계가 공개되어도 유지되어야 한다는 케르크호프스 원칙은 이미 오래전부터 이 점을 지적해 왔다.
물론 정보 은닉이 무의미하다는 뜻은 아니다. 다층 방어의 한 겹으로서는 여전히 공격자의 비용을 높인다. 문제는 은닉에만 의존하는 것이다. 취약점을 완전히 없앨 수 없다면, 이를 발견하고 검증하는 주체를 기업 내부로만 한정할 이유가 있는지 다시 생각해야 한다.
나. 검증 과정을 개방한다는 것
대안은 보안 설계를 검증 가능한 수준으로 공개하고, 외부 연구자와 기업이 함께 취약점을 찾아 고치는 구조다. 버그 바운티, 취약점 공개 정책(VDP), 조율된 취약점 공개(CVD)는 이미 그 방법을 제시하고 있다. PHP2Shell도 AI를 활용한 외부 연구 기업을 비롯해 여러 연구팀이 각각 독립적으로 발견해 보고한 사례다.
다만 두 가지는 분명히 구분해야 한다.
• 발견된 취약점을 보호 조치 없이 즉시 공개하는 것은 또 다른 위험을 만든다. PHP2Shell에서 보듯 조율된 공개 과정에서도 정보가 먼저 유출될 수 있으므로, 패치 준비와 고객 보호 절차가 함께 설계되어야 한다.
• 플랫폼의 보안 설계와 기술 정보를 공개하는 것과, 고객의 네트워크 구성이나 보안 정책·운영 정보를 공개하는 것은 전혀 다른 문제다.
정해진 범위 안에서 외부 연구자가 취약점을 찾고 검증하도록 허용하고, 발견된 문제는 수정과 고객 보호 조치를 거쳐 조율된 방식으로 공개하는 체계를 갖춘다면, 기업은 내부 역량만으로는 얻기 어려운 다양한 관점의 검증을 받을 수 있다. 보안 플랫폼을 무조건 공개하자는 것이 아니다. 검증 과정을 열고, 발견된 문제를 빠르게 해결하며, 그 결과를 공유하는 구조로 가자는 것이다.
다. 신뢰의 기준이 바뀐다
이 과정에서 보안 경쟁력의 의미도 달라진다. 취약점이 없다고 주장하는 기업보다, 취약점을 적극적으로 찾아내고 신속하게 고치며 그 결과를 투명하게 공유하는 기업이 더 큰 신뢰를 얻게 된다.
앞으로의 보안 플랫폼은 얼마나 많은 기술을 숨기고 있는가가 아니라, 얼마나 많은 검증을 견뎌냈고 발견된 문제에 얼마나 빨리 대응하는가로 평가받게 될 것이다. AI가 공격의 진입장벽을 낮추는 시대라면, 방어 역시 소수 전문가에게만 의존하지 않고 집단적으로 검증하고 대응하는 구조로 발전해야 한다.
4. 사고 발생 여부가 아닌, 조직의 보안 역량으로 평가해야 한다
가. 사고가 나면 담당자부터 찾는 관행
기업에서 해킹이나 데이터 유출 사고가 발생하면, 원인과 대응 과정을 충분히 검토하기도 전에 시스템 담당자나 운영자의 책임부터 거론되는 경우가 많다. AI로 취약점 탐색과 공격이 빠르게 자동화되는 지금, 외부 공격으로 시스템이 침해되었다는 사실만으로 관리자에게 책임을 묻는 것이 합리적인지 따져 볼 필요가 있다.
현실적으로 많은 기업에서는 소수의 인력이 수많은 시스템과 보안 솔루션을 운영한다. 운영체제와 오픈소스 취약점 관리, 보안 정책 설정, 신규 시스템 도입, 네트워크 관리, 이상 행위 탐지, 사고 대응까지 몇 명이 감당하는 경우도 적지 않다. 이런 상황에서 사고가 났다는 이유만으로 관리 소홀이나 역량 부족을 원인으로 단정하기는 어렵다.
나. 책임과 권한은 함께 배분되어야 한다
더 근본적인 문제는 기업의 보안 위험 전체를 소수의 담당자가 떠안도록 설계된 조직 구조에 있다. 보안 인력과 예산, 도입할 기술과 솔루션, 감수할 위험의 수준을 결정하는 권한은 현장 담당자에게 있지 않다. 그런데도 사고가 나면 책임은 의사결정 권한이 제한된 운영자에게 집중되곤 한다.
이는 담당자 개인의 문제가 아니라, 기업이 보안의 책임과 권한을 어떻게 배분하는가의 문제다. 
NIST 사이버보안 프레임워크(CSF) 2.0이 거버넌스(Govern)를 별도 기능으로 두어 보안을 경영진의 책임으로 다루는 것도 같은 흐름이다.
물론 담당자의 관리 책임이 사라져야 한다는 뜻은 아니다. 필수 보안 조치를 수행하지 않았거나, 알려진 중대한 위험을 정당한 사유 없이 방치했다면 그 책임은 검토되어야 한다. 
그러나 합리적인 예방 조치를 했는데도 새로운 취약점이나 예측하기 어려운 공격 기법으로 침해가 발생했다면, 결과만으로 책임을 판단해서는 안 된다.

이 지점에서 한국과 실리콘밸리의 접근은 뚜렷하게 다르다. 국내에서는 사고가 나면 원인 분석보다 담당자 문책과 징계가 먼저 거론되는 경우가 많고, 그 결과 현장에는 문제를 드러내기보다 감추려는 압력이 생긴다. 반면 실리콘밸리의 많은 기업은 구글 SRE 등을 통해 확산된 "비난 없는 사후 분석(blameless postmortem)"을 사고 대응의 기본 절차로 삼는다. 누가 실수했는지가 아니라 어떤 구조가 그 실수를 가능하게 했는지를 묻고, 그 분석을 조직 전체가 공유한다.
미국에서도 보안 책임자의 개인 책임이 쟁점이 된 적은 있다. 미국 증권거래위원회(SEC)는 2023년 SolarWinds와 CISO를 제소했지만, 법원은 2024년 대부분의 청구를 기각했고 SEC는 2025년 11월 남은 소송까지 취하했다. 이 사건의 쟁점도 침해 사고 자체가 아니라, 회사가 보안 수준을 대외에 사실과 다르게 설명했는지였다. 책임의 근거를 "사고가 났는가"가 아니라 "알면서 숨기거나 잘못 설명했는가"에 두는 것이다. 사고를 숨기지 않고 드러낼수록 보호받는 구조여야 조직은 더 빨리 배우고 회복한다.

다. 무엇으로 평가할 것인가
어떤 공격도 허용하지 않겠다는 목표는 유지하되, 모든 공격을 사전에 차단할 수 있다는 전제에서는 벗어나야 한다. 예방의 효과뿐 아니라 사고 이후의 대응 역량이 평가 기준이 되어야 하며, 이는 측정 가능한 지표로 관리할 수 있다.

평가 영역 / 핵심 질문 / 지표 예시
예방 / 알려진 위험을 얼마나 빨리 줄이는가 / 중대 취약점 패치 적용 소요 시간, 외부 노출 자산 파악률
탐지 / 공격을 얼마나 빨리 인지하는가 / 평균 탐지 시간(MTTD)
대응 / 피해 확산을 얼마나 효과적으로 막는가 / 평균 대응 시간, 침해 범위(영향받은 시스템 수)
복구 /  정상 업무로 얼마나 빠르고 안전하게 돌아오는가 / 평균 복구 시간(MTTR), 복구 훈련 성공률

이런 대응 능력이 특정 담당자의 개인기에 의존해서도 안 된다. 기업은 적절한 인력과 권한을 제공하고, 반복 업무를 자동화하며, 사고 시 조직 전체가 협력하는 대응 체계를 갖춰야 한다. 사고 분석 역시 개인을 비난하기보다 원인 구조를 찾는 "비난 없는 사후 분석(blameless postmortem)" 방식이 재발 방지에 더 효과적이다.
사고가 났을 때 "누가 막지 못했는가"를 먼저 묻기보다, 조직이 어떤 위험을 알고 있었고, 이를 관리하기 위해 어떤 결정을 내렸으며, 사고 이후 얼마나 효과적으로 대응했는지를 평가해야 한다. 사고가 없었다는 결과만으로 보안 수준을 높게 평가하거나, 사고가 났다는 이유만으로 관리 실패를 단정하는 기준에서 벗어날 때다.

맺음말
AI는 공격자가 대상을 탐색하고 취약점을 분석하며 침투를 시도하는 데 필요한 시간과 비용을 낮추고 있다. 그 결과 규모나 인지도, 보유 정보의 가치와 관계없이 인터넷에 노출된 모든 시스템이 공격 대상이 될 수 있다. 방어자가 취약점을 인지하기 전에 공격이 시작될 수 있고, 합리적인 보안 조치를 수행해도 모든 침해를 사전에 막는다고 보장하기는 어렵다.
그렇다고 예방의 중요성이 낮아지는 것은 아니다. 예방과 탐지, 대응과 복구가 하나의 연속된 과정으로 작동하고, 실제 공격 상황에서 그 효과가 검증되어야 한다. 검증은 외부 연구자에게까지 넓게 열고, 책임과 권한은 조직 전체가 나누며, 보안 역량은 사고 발생 여부가 아니라 예방·대응·복구와 지속적인 개선 능력으로 평가해야 한다.
결국 AI 시대에 필요한 것은 모든 공격을 막을 수 있다는 확신이 아니라, 공격이 발생하더라도 조직이 흔들리지 않고 대응하며 회복할 수 있다는 검증 가능한 신뢰이다. 이것이 우리가 공격 대상이 된 이후까지 고민해야 하는 이유다.


참고 자료
• PHP2Shell: One Upload, Full Server — Varonis https://www.varonis.com/blog/php2shell
• Actions you can take to protect against the PHP2Shell vulnerability — SD Times https://sdtimes.com/?p=61609
• Calif Research — PHP2Shell: 최초 발견 연구진의 기술 분석과 AI 활용 과정 https://calif.io/php2shell/
• Flow Ninja — PHP2Shell: 영향받는 플랫폼과 대응 방안 https://www.flowninja.com/blog/php2shell
• NCSC-NL — PHP2Shell Operational Information: 실제 제품 영향 범위와 패치 현황 https://github.com/NCSC-NL/php2shell
• NIST — Cybersecurity Framework 2.0 FAQ: Govern 기능과 조직의 사이버보안 책임 https://www.nist.gov/cyberframework/faqs
• SolarWinds and CISO cleared as SEC dismisses lawsuit (American Banker) https://www.americanbanker.com/news/solarwinds-and-ciso-cleared-as-sec-dismisses-lawsuit
• Judge dismisses most of SEC case against SolarWinds and its CISO (National Law Review) https://natlawreview.com/article/judge-dismisses-most-sec-case-against-solarwinds-and-its-ciso