본문 바로가기
AI 인공지능

AI가 사람 없이 혼자 해킹했다 — 60분 만에 DB가 털렸다

by 요즘IT 2026. 5. 31.

올해 5월, 보안 연구팀이 꽤 불편한 걸 공개했어요.

해커가 서버에 침입했는데, 그 이후 과정을 사람이 아닌 AI 에이전트가 전부 진행했거든요.

명령 내리는 사람 없이. 판단하는 사람 없이. 그냥 AI가 혼자서, 끝까지.

어? 이상하죠? 저도 처음 봤을 때 "이게 진짜야?" 싶었거든요.

근데 진짜예요.


무슨 일이 있었냐면

Sysdig 위협 연구팀이 분석한 사례예요.

공격 대상은 Marimo라는 오픈소스 노트북 툴이에요. 주피터 노트북처럼 코드 실행하는 환경인데, 인터넷에 노출된 상태였어요.

여기서 취약점 하나가 터졌어요.

CVE-2026-39987 — CVSS 점수 9.3점이에요. 10점 만점에 9.3이면, 사실상 "그냥 뚫린다"는 얘기예요.

문제는 어이없을 만큼 단순한 버그였거든요.


/terminal/ws — 인증을 빼먹은 엔드포인트

Marimo에는 WebSocket 엔드포인트가 여러 개 있어요.

대부분은 인증 검사를 해요. 근데 /terminal/ws 얘만 안 해요.

형제 엔드포인트들은 다 체크하는데, 얘만 쏙 빠져있는 거예요.

결과는요?

인증 없이 요청 하나만 보내면 **서버 쉘(PTY)**이 떨어져요. 그냥 "들어와" 하는 거예요.

WebSocket authentication bypass diagram
WebSocket authentication bypass diagram


여기서 반전이 있어요

이제까지는 그냥 취약점 얘기예요. "서버 뚫렸다" — 흔한 보안 뉴스죠.

근데 이 사건이 다른 이유는 그 다음이에요.

쉘 하나 딴 다음부터, AI 에이전트가 혼자 판단하면서 움직였거든요.

순서를 보면요.

1단계 — 서버에서 클라우드 자격증명 2개 탈취
2단계 — Cloudflare Workers로 출발지 IP 분산(추적 방해)
3단계 — AWS Secrets Manager에서 SSH 개인키 꺼내옴
4단계 — 내부 서버에 SSH 세션 8개 동시 오픈
5단계 — 내부 PostgreSQL DB 스키마 + 데이터 전부 덤프

이걸 60분 안에 끝냈어요.

각 단계에서 명령어 결과를 보고, 실패하면 다른 방법 시도하고, 다음 단계 뭐 할지 판단하고.

그걸 사람이 한 게 아니에요. AI가 한 거예요.


60분이 왜 문제냐면

솔직히 저도 처음엔 "60분이면 SOC팀이 잡겠지" 싶었어요.

근데 이게 포인트예요.

보안 팀이 알람 받고, 확인하고, 대응 시작하는 데 보통 얼마나 걸릴까요.

업계 평균이 수십 분에서 몇 시간 사이예요.

DB 덤프는 2분도 안 걸렸어요.

알람이 울리기도 전에 이미 데이터가 나갔다는 얘기예요.

패치가 침입을 막는 건 맞아요. 근데 패치가 속도를 막진 못해요.

이게 이번 사건이 불편한 진짜 이유예요.


AI 에이전트 공격, 뭐가 다른가요

기존 해킹 자동화랑 헷갈릴 수 있어요.

스크립트도 자동으로 돌아가잖아요. 그냥 자동화 아니냐고요?

다르거든요.

기존 스크립트는 미리 짜놓은 순서대로 실행해요. 중간에 뭔가 달라지면 그냥 멈추거나 실패해요.

AI 에이전트는 출력 결과를 해석하고, 다음 행동을 스스로 결정해요. 실패하면 다른 경로 찾고, 맥락을 기억하면서 움직여요.

한마디로, 스크립트는 레시피를 따르는 것이고, AI 에이전트는 요리사가 직접 판단하는 것이에요.


그래서 지금 뭘 해야 하냐면

당장 Marimo 쓰고 있다면요.

/terminal/ws 엔드포인트 접근 차단이 1순위예요. 인터넷에 직접 노출된 상태면 특히요.

그리고 좀 더 넓은 얘기를 하면,

자격증명 격리가 진짜 중요해요. 서버 하나 뚫렸을 때 거기서 클라우드 키, SSH 키, DB 비밀번호까지 다 꺼낼 수 있으면 안 되거든요.


이번 사건도 결국 서버 하나에 크리덴셜이 너무 많이 모여 있던 게 피해를 키운 거예요.

근데 솔직히 이게 어렵거든요.

권한 분리하면 개발자는 테스트할 때마다 승인 기다려야 하고, DBA는 DB마다 계정 따로, 환경마다 따로 관리해야 해요. 제대로 하려면 Vault나 AWS Secrets Manager 같은 툴도 도입해야 하고, 배포 파이프라인도 뜯어고쳐야 해요.

그래서 현실에서는 "일단 admin 계정 하나 만들어서 다 같이 쓰자"로 흘러가는 거예요.

그 편함이, 이번 사건처럼 터질 때 줄줄이 새는 이유가 돼요.

완벽한 분리가 어렵다면 최소한 이것만은요. 서비스 계정은 사람 계정이랑 분리하고, 서버에 직접 크리덴셜 파일 두지 않기 — 이 두 가지만 지켜도 피해 범위가 확 줄어요.

서버별 권한을 최소화한 자격증명 격리 구조도
서버별 권한을 최소화한 자격증명 격리 구조도

그리고 탐지 타이밍도 다시 생각해봐야 해요.

"이상한 거 탐지하면 알람 보내기"가 아니라, "이상한 게 감지되면 자동으로 격리"로 가야 해요.

AI가 2분 만에 DB 덤프를 뜨는 시대에, 사람이 알람 보고 달려오는 구조로는 버티기 어려워요.


마무리하면서

솔직히 이 사건 읽으면서 좀 멍했어요.

"AI가 해킹 도구로 쓰인다"는 얘기는 많이 들었는데, 진짜로 AI가 혼자 판단하면서 공격 체인을 완성한 사례는 처음 봤거든요.

AI가 개발을 도와주는 시대라고 다들 얘기하잖아요.

근데 이제 공격 쪽도 똑같이 쓰이고 있는 거예요.

결국 핵심은 하나예요.

패치는 침입을 막지만, 속도는 막지 못한다.

방어도 그 속도에 맞게 자동화돼야 해요.