AI 랜섬웨어, 작은 팀이 놓친 진짜 신호

공격은 AI가 했지만, 문은 사람이 열었다.

지난주 TechCrunch가 보도한 '최초 AI 자율 랜섬웨어 공격' 사건은 제목만 보면 공상과학 소설처럼 읽힌다. 그런데 내막을 뜯어보면 이야기가 달라진다. AI 에이전트가 기술적 실행을 담당한 건 맞다. 피해자를 고른 것도, 인프라를 셋업한 것도, 탈취된 자격증명을 공급한 것도 — 전부 인간이었다. '아직 완전 자율이 아니니 괜찮다'는 결론을 내리고 싶겠지만, 그게 바로 소규모 팀이 가장 많이 하는 실수다.

단, 이 안도감에는 함정이 있다. 기술 진입 장벽이 낮아졌다는 사실은 '완전 자율화'와 완전히 별개의 위협이다.

헤드라인이 틀린 게 아니라, 우리가 잘못 읽은 거다

지금까지 정교한 랜섬웨어 공격을 운영하려면 수십 명의 전문 인력이 필요했다. 취약점 탐색, 내부 이동 경로 설계, 페이로드 배포 — 이 각각이 별개의 숙련 영역이었다. AI 에이전트는 이 역할을 대리한다. 공격자는 이제 목표물과 재료만 제공하면 된다.

그 '재료'가 탈취된 자격증명 세트다. 기술 장벽이 낮아진 건 방어 쪽이 아니라 공격 쪽이다. 소규모 팀이 이 비대칭을 실감하기 전에 먼저 맞는 경우가 생기고 있다.

AI 개발에 반대하는 진영이 꾸준히 경고해온 것 중 하나가 바로 이것이다. 공격 도구는 빠르게 AI화 되는데, 방어 인프라와 규제는 그 속도를 따라가지 못한다는 지적. 이번 사건은 그 비대칭이 이론이 아니라 실제 침해 사고로 나타난 첫 케이스다.

자격증명이 뚫리면 AI든 사람이든 무의미하다

이번 공격의 실제 침입 경로는 탈취된 자격증명이었다. 이게 핵심이다.

Verizon 2025 DBIR에 따르면 침해 사고의 54%가 자격증명 탈취에서 시작된다. 제로데이 취약점이나 정교한 AI 공격보다 훨씬 높은 수치다. 소규모 팀은 AI 보안 논쟁을 구경하는 사이, 정작 본인들 SSH 키를 3년 넘게 로테이션하지 않은 경우가 적지 않다.

문제는 규모가 작을수록 관리 루틴이 없다는 것이다. 팀원 4명이 같은 DB 비밀번호를 수년째 공유하거나, 퇴사한 직원의 API 키가 여전히 유효하거나, .env 파일을 git에 잠깐 올렸다가 지웠다고 안심하는 — 이런 상황이 바로 AI 에이전트의 입장에서 '열린 문'이다. 자격증명 하나가 유효하면 기술적 실행은 AI가 알아서 한다.

벤더 리스크 — AI 툴을 쓰는 팀이 새로 생기는 노출

LLM API를 사용한다는 건, 프롬프트와 컨텍스트 일부가 외부 벤더 인프라를 통과한다는 뜻이다.

그것만이 아니다. 2025년 PyPI에서는 유명 LLM 래퍼와 이름이 유사한 악성 패키지가 여러 건 발견됐다. claude-wrapper, anthropic-utils 류의 패키지를 무심코 pip install했다가 ANTHROPIC_API_KEY가 외부로 유출되는 케이스다. 대형 팀엔 패키지 감사 프로세스가 있지만, 소규모 팀은 requirements.txt를 한 번 만들고 수개월씩 방치하는 경우가 많다.

벤더 자체 신뢰도 문제도 있다. 사용하는 AI 서비스가 SOC 2 Type II 인증을 보유하는지, 데이터 처리 계약(DPA)이 체결되어 있는지 — 이걸 한 번도 확인하지 않고 '유명한 서비스니까 괜찮겠지'로 넘어가면, 침해 발생 시 법적 대응 근거가 없어진다. 특히 개인정보나 고객 데이터를 프롬프트에 포함하는 경우라면 더욱 그렇다.

규제 공백 — 피해를 입어도 책임을 묻기 어렵다

AI가 공격의 실행자가 됐을 때, 법적 책임은 어디로 가는가. 지금 당장은 명확한 답이 없다.

한국은 2026년 1월 '인공지능 기본법'이 시행됐지만, AI 기반 사이버 공격에 대한 민사·형사 책임 조항은 아직 정비 중이다. EU AI Act는 고위험 AI 시스템 제공자의 책임을 규정하지만, 악용된 AI의 경우는 해석이 갈린다. 피해자가 소송을 제기해도 '누구를 상대로'라는 질문 앞에서 막히는 구조다.

더 현실적인 문제는 사이버 보험이다. AI가 실행한 랜섬웨어 공격을 당했을 때, 가입한 보험 약관이 이를 커버하는지 아무도 확인하지 않은 팀이 많다. 일부 보험사는 이미 'AI-assisted attack'을 면책 사유로 추가하고 있다. 공격을 당한 뒤 약관을 열어보면 이미 늦다.

우리 팀 같은 규모에서 실제로 벌어지는 시나리오

crontab으로 매시간 돌아가는 봇들, MySQL 커넥션 정보를 담은 .env 파일들, 서버 접근용 SSH 키들. 이 각각이 공격자 입장에서는 하나의 '문'이다.

시나리오를 구체적으로 그려보면 이렇다. 공격자가 어느 오픈소스 패키지에 심어둔 스니퍼가 ANTHROPIC_API_KEY와 함께 DB 커넥션 문자열을 탈취한다. 이 자격증명을 AI 에이전트에게 건네면, 에이전트는 내부 이동 경로를 탐색하고 스토리지를 암호화한다. 공격자가 직접 콘솔을 볼 필요도 없다. 이 시나리오에서 인간이 한 일은 패키지 하나를 PyPI에 올린 것뿐이다.

과장이 아니다. Midnight Blizzard(러시아 SVR 연계 그룹)가 2023년 Microsoft 침해에서 사용한 방식이 이 패턴의 전신이다. 당시엔 AI가 없었지만, 구조는 동일하다. 자격증명 획득 → 내부 이동 → 데이터 탈취.

이번 주 안에 실행할 수 있는 것들

추상적인 '보안 강화'가 아니라 실제로 손을 댈 수 있는 작업들이다.

첫째, 자격증명 감사. 서버에서 grep -r "password\|secret\|api_key" /opt/ --include="*.py" --include="*.env" -l 을 돌려보면 예상보다 많은 평문 키가 나온다. 발견된 것들은 즉시 환경변수 또는 secrets manager로 이관하고, 90일 로테이션 일정을 캘린더에 넣어라. 가장 빠른 리스크 감소다.

둘째, 퇴사자·미사용 계정 정리. 팀원이 바뀔 때마다 접근 권한을 재검토하는 루틴이 필요하다. 클라우드 콘솔, DB 유저, SSH 키, API 키 전부 포함해서. 한 달 전 퇴사한 사람의 API 키가 아직 유효한 팀은 생각보다 흔하다.

셋째, 패키지 의존성 고정. pip install할 때 버전을 ==으로 고정하고, 분기마다 pip-audit 또는 safety check를 돌려라. 악성 패키지는 이름을 유명 패키지와 유사하게 짓는다. 오타 한 글자 차이다.

넷째, 사이버 보험 약관 확인. AI-assisted attack, 클라우드 인프라 침해가 커버되는지 반드시 확인하고, 빠져 있다면 갱신 시점에 추가 협의해라.

마지막으로 인시던트 대응 플레이북 — 한 페이지짜리라도 만들어두는 것. 공격이 시작된 후 처음 1시간에 무엇을 해야 하는지 아무도 모르는 팀이 가장 피해가 크다. AI가 공격을 실행하는 속도는 사람이 대응을 논의하는 속도보다 훨씬 빠르다. 그 간격이 피해 규모를 결정한다.

원문: AI News & Artificial Intelligence | TechCrunch