요즘은 코드를 짜거나 장애 원인을 찾을 때 AI를 쓰는 일이 흔해졌습니다. 그런데 이 도구를 반기는 쪽이 개발자와 운영자만은 아닙니다. 공격자도 같은 도구로 같은 일을 하기 시작했고, 서버를 맡고 있는 입장에서는 슬슬 신경이 쓰이는 대목입니다.
대표적인 사례가 2025년 11월 Anthropic이 공개한 보고서입니다. Anthropic은 2025년 9월 중순에 탐지한 공격을 중국 국가 배후로 추정되는 그룹 GTG-1002의 소행으로 보았고, 이들이 Claude Code와 MCP 도구를 묶은 자동화 프레임워크로 약 30개 기관을 노렸다고 밝혔습니다. 정찰, 취약점 검증, 측면 이동, 데이터 탈취 같은 작업의 80~90%를 AI가 맡았고 사람은 중요한 갈림길에서만 개입했다는 설명입니다. 이 수치가 실제 자율성을 얼마나 반영하는지는 보안 업계에서 의문도 제기됐습니다. 그래도 AI가 공격 코드를 대신 써 주는 수준을 넘어 공격 과정 자체를 끌고 간 사례가 공개 보고서에 올라왔다는 점은 가볍게 넘기기 어렵습니다.
2026년 초 Malwarebytes의 기업용 부문 ThreatDown이 낸 2026 State of Malware 보고서도 비슷한 방향입니다. 사람이 손으로 하던 침입이 AI가 돌리는 기계 속도의 작업으로 옮겨 가고 있고, 올해 안에 패치가 나온 뒤 익스플로잇이 만들어지기까지의 간격이 분 단위까지 줄어들 것으로 전망합니다. 보안 업체 보고서라 강조점이 있을 수 있지만, 방향 자체는 현업에서 느끼는 체감과 크게 다르지 않습니다.
새로운 기법보다 빨라진 속도
AI가 등장했다고 전혀 새로운 해킹 기법이 생긴 것은 아닙니다. 포트 스캔, 취약점 분석, 계정 탈취, 권한 상승, 내부망 이동은 예전부터 있던 수순입니다. 달라진 것은 각 단계 사이에 끼어 있던 사람의 시간입니다. 취약점 정보를 읽고, 공개된 익스플로잇을 찾아 고치고, 실제로 먹히는지 시험하는 데 며칠씩 걸리던 일을 AI가 상당 부분 자동으로 이어 붙일 수 있게 됐습니다. 여기에 서버 여러 대를 병렬로 동시에 훑는 것도 어렵지 않으니, 공격자 한 명이 감당하는 범위가 넓어집니다.
운영하는 쪽에서 보면 이 변화는 대응할 시간이 줄어든다는 뜻으로 돌아옵니다. 패치가 나왔다고 곧바로 적용하는 환경은 드뭅니다. 서비스 영향을 따져야 하고, 테스트 서버에서 먼저 돌려 봐야 하고, 재기동 시간도 잡아야 합니다. 월 1회 정기 점검 일정에 맞춰 패치하는 곳도 많을 텐데, 공격 쪽이 그 일정을 기다려 주지는 않습니다. 모든 취약점을 같은 속도로 처리하기보다 실제로 공격에 쓰이는 것부터 빠르게 처리하는 체계가 필요해진 이유입니다.
외부에 열린 서버부터 다시 세어 보기
보안 이야기가 나오면 방화벽이나 침입 탐지부터 떠올리지만, 저는 자산 파악이 가장 밑바닥이라고 생각합니다. 서버가 몇 대인지, 어떤 포트가 인터넷에 열려 있는지를 정확히 아는 일인데, 해 보면 생각보다 잘 안 됩니다. 테스트하려고 만든 VM이 그대로 떠 있고, 프로젝트가 끝났는데 스테이징 서버가 계속 돌고 있고, 개발자가 만든 인스턴스와 보안 그룹이 운영팀 관리 목록에서 빠져 있는 경우가 흔합니다. 클라우드라면 더 그렇습니다.
공격자는 이런 사정을 봐주지 않습니다. 인터넷에서 닿으면 일단 대상입니다. 자동화된 정찰이 늘수록 운영자가 잊고 있던 서버도 목록에 올라갈 가능성이 커집니다. 그래서 외부에서 보이는 IP, 포트, 도메인, 서브도메인을 주기적으로 조사해서 실제 관리 목록과 맞춰 보는 작업이 의미가 있습니다. 특히 SSH, RDP, 데이터베이스 포트, Kubernetes API 서버, 각종 관리 콘솔은 정말 외부에서 열려 있어야 하는지 다시 따져 볼 만합니다. 관리용이라면 VPN이나 ZTNA 뒤로 돌리는 쪽이 낫습니다.
SBOM, 즉 시스템이 쓰는 소프트웨어와 라이브러리의 구성 목록도 같은 맥락입니다. 새 취약점이 공개되면 제일 먼저 필요한 답이 "우리 환경에 그게 있나"인데, 이걸 찾는 데 몇 시간씩 걸리면 패치가 아무리 빨라도 소용이 줄어듭니다.
패치는 급한 것부터 따로 빼기
패치는 패치 자체보다 그 뒤에 생길 문제가 더 부담스러운 작업입니다. OS 패치 뒤에 서비스가 안 올라오거나 라이브러리 버전이 바뀌어 애플리케이션이 깨지는 일을 한두 번쯤 겪어 보셨을 겁니다. 정기 점검 시간을 정해 두고 그때 몰아서 적용하는 방식은 이런 위험을 줄이려는 합리적인 선택입니다. 다만 실제로 공격에 쓰이고 있는 취약점까지 다음 점검일을 기다리는 것은 위험할 수 있습니다.
이때 참고할 만한 것이 CISA의 KEV(Known Exploited Vulnerabilities) 목록입니다. 실제 악용이 확인된 취약점만 모아 둔 목록입니다. CVSS 점수가 높다고 전부 똑같이 급한 것은 아니고, 점수가 중간이어도 이미 활발히 쓰이고 있다면 먼저 손봐야 합니다. 우선순위를 정할 때는 악용 여부 외에도 인터넷에 직접 노출된 시스템인지, 원격 코드 실행이나 권한 상승이 가능한지, 뚫렸을 때 서비스 피해가 얼마나 큰지, 패치 말고 쓸 수 있는 임시 방편이 있는지를 함께 보게 됩니다.
모든 서버에 당일 패치를 넣는 것은 현실적으로 어렵습니다. 그럴 때는 WAF 규칙을 추가하거나, 문제가 된 기능을 끄거나, 접근 IP를 좁히는 임시 조치로 먼저 위험을 낮추고 정식 패치를 뒤따르게 하는 방법이 있습니다. 패치를 못 넣는 상황에서도 꺼낼 카드가 미리 정해져 있는지가 중요합니다. 서버마다 SSH로 들어가 패키지를 올리고 서비스를 재기동하는 방식은 대수가 늘수록 한계가 뚜렷하니, 이미지 기반 배포나 자동화된 파이프라인으로 패치와 검증 시간을 줄이는 것도 같은 문제의 해법입니다. AI 공격에 대응한다며 새 보안 제품부터 들이기보다, 지금 패치 프로세스가 얼마나 빠르고 안정적으로 도는지부터 보는 편이 출발점으로 좋다고 생각합니다.
한 대가 뚫려도 번지지 않게
아무리 막아도 침투를 전부 막기는 어렵습니다. 그래서 침투 이후에 공격자가 할 수 있는 일을 제한하는 것이 같은 비중으로 중요합니다. 웹 애플리케이션 서버 한 대가 털렸는데 그 서버에 다른 시스템의 관리자 계정 정보가 들어 있다면, 공격자는 그걸 들고 다음 서버로 넘어갑니다. 소스 코드와 설정 파일에 박힌 비밀번호와 API 키가 대표적이고, Git 저장소뿐 아니라 환경변수, CI/CD 로그, 컨테이너 이미지에도 의외로 많이 남아 있습니다. Vault나 클라우드의 Secrets Manager 같은 별도 저장소로 옮겨 두면 한 서버의 침해가 그 서버 안에서 끝날 가능성이 커집니다.
계정 권한도 비슷합니다. 편하다는 이유로 서비스 계정에 관리자 권한을 주거나 여러 시스템에서 같은 계정을 돌려 쓰는 경우가 있는데, 계정 하나가 넘어가면 피해 범위가 한꺼번에 커집니다. 클라우드 IAM, Kubernetes ServiceAccount, DB 계정 모두 필요한 권한만 주는 것이 기본입니다. 네트워크도 마찬가지로, 웹 서버가 DB에 붙는다고 해서 다른 웹 서버나 관리망까지 자유롭게 오갈 이유는 없습니다. 역할별로 통신 범위를 나눠 두면 접근 권한이 없는 곳은 AI가 아무리 빨라도 갈 수 없습니다.
CPU 그래프가 멀쩡해도 안전한 건 아닙니다
운영자에게 모니터링은 익숙한 영역입니다. CPU, 메모리, 응답 시간에 알림을 걸어 두는 구성이 일반적입니다. 그런데 정상 계정을 탈취한 공격자가 조용히 데이터를 조회하고 있다면 이런 지표에는 거의 아무 변화도 나타나지 않습니다. 대신 평소와 다른 행동이 남습니다. 어떤 계정이 짧은 시간에 API를 수없이 호출하거나, 평소 들어오지 않던 서버에 접속하거나, 갑자기 바깥으로 큰 데이터가 나가거나, 쓰지 않던 프로세스가 뜨는 식입니다. AI를 쓴 공격은 이런 행동이 짧은 시간에 몰려서 나올 수 있습니다.
이상 여부를 판단하려면 평소 모습을 알고 있어야 합니다. 서비스별 요청량과 응답 패턴, 프로세스 실행 기록, 외부 연결, 인증 기록 같은 것들입니다. APM과 로그 모니터링을 이미 쓰고 있다면 이 정보를 함께 보는 방법을 생각해 볼 수 있습니다. 다만 메트릭, 로그, 트레이스만으로 보안 위협이 다 보이지는 않아서 인증 이벤트, 네트워크 연결 정보, OS 보안 이벤트는 따로 모아야 합니다.
탐지한 뒤의 대응도 문제입니다. 새벽에 이상 징후가 떴는데 담당자가 출근한 뒤에야 확인한다면 그 사이에 이미 일이 벌어졌을 수 있습니다. 의심스러운 세션 차단, 특정 계정 권한의 임시 제한, 침해가 의심되는 인스턴스의 격리처럼 반복되는 상황은 절차를 미리 만들어 두는 게 좋습니다. 다만 전부 자동화하는 것은 조심스럽습니다. 오탐 하나로 멀쩡한 서비스가 막힐 수 있기 때문입니다. 위험이 높고 영향 범위가 분명한 조치부터 자동화하고, 서비스에 크게 영향을 주는 조치에는 승인 단계를 두는 정도가 현실적이라고 봅니다.
우리가 쓰는 AI 에이전트와 MCP 서버
지금까지는 공격자가 AI를 쓰는 이야기였는데, 우리 쪽에서 쓰는 AI 에이전트도 관리 대상입니다. 서버 정보를 조회하고, 로그를 분석하고, 명령을 실행하는 권한을 에이전트에게 주는 사례가 늘었고, MCP(Model Context Protocol) 덕분에 외부 도구와 연결하는 것도 쉬워졌습니다. 편해진 만큼 새로운 위험도 따라옵니다.
로그를 읽을 수 있고 서버에서 명령도 실행할 수 있는 운영 자동화 에이전트를 가정해 보겠습니다. 이 에이전트가 분석하는 로그나 문서 속에 악의적인 지시문이 섞여 있으면, 에이전트가 그것을 정상적인 작업 지시로 받아들일 수 있습니다. 프롬프트 인젝션이라고 부르는 문제입니다. 웹 애플리케이션에서 SQL Injection이나 Command Injection을 신경 쓰듯, 에이전트를 운영할 때는 프롬프트 인젝션도 전제에 두어야 하고, 실제로 시스템을 바꿀 수 있는 권한까지 가진 에이전트라면 위험이 더 큽니다.
MCP 서버 구현체도 일반 서버 애플리케이션과 같은 잣대로 봐야 합니다. Endor Labs가 오픈소스 MCP 서버 구현 2,614개를 분석한 결과를 보면 82%가 경로 순회로 이어질 수 있는 파일 시스템 연산을 쓰고, 34%가 민감한 명령 관련 API를 쓰고 있었습니다. 이 수치는 위험할 수 있는 코드 패턴을 쓰는 비율이지 실제로 악용되는 취약점의 비율은 아니어서, 그 구분을 두고 읽어야 합니다. 실제 취약점 사례도 있습니다. MCP 공식 저장소에 들어 있는 mcp-server-git에서는 --repository 옵션으로 저장소를 제한해 놓아도 이후 도구 호출의 경로를 검증하지 않아 다른 저장소에 닿을 수 있는 문제(CVE-2025-68145)가 2025년 12월에 패치됐습니다.
외부에서 가져온 MCP 서버는 출처와 버전을 확인하고 어떤 권한으로 도는지 살펴보는 것이 기본입니다. 에이전트에게 주는 권한도 같은 원칙입니다. 로그 분석만 하는 에이전트라면 서버 설정을 바꾸거나 DB 테이블을 지울 권한까지 줄 이유가 없습니다. 프롬프트 인젝션을 완벽하게 막기는 어렵더라도 권한이 좁으면 실제 피해는 그만큼 작아집니다. 운영 환경에 에이전트를 쓰고 있다면 접근할 수 있는 서버와 시스템의 범위, 쓰고 있는 계정과 자격증명, 승인 없이 실행되는 작업, 실행 기록이 로그로 남는지, 문제가 생겼을 때 권한을 바로 회수할 수 있는지를 한 번 점검해 보시면 좋겠습니다.
결국은 기본기
정리하면서 느낀 것은 기본적인 운영 원칙이 여전히 중요하다는 점입니다. 외부에 열린 서버를 정확히 알고, 취약점을 빨리 확인하고, 계정과 네트워크 권한을 좁히고, 평소와 다른 움직임을 지켜보는 일입니다. 사실 AI가 나오기 전부터 계속 나오던 이야기입니다. 달라진 것은 이 기본기가 허술할 때 공격자가 그 틈을 파고드는 속도입니다.
그렇다고 전부를 한꺼번에 바꿀 필요는 없을 것 같습니다. 외부에 노출된 서버 목록을 다시 확인하고, 실제로 악용되는 취약점이 나왔을 때 정기 점검과 별개로 움직일 수 있는 절차가 있는지 점검하는 것부터 시작해도 충분합니다. 에이전트를 도입하는 중이라면 그 에이전트가 어떤 권한을 갖고 있는지도 함께 확인해 보시기 바랍니다.