100만 대 AI 서비스 스캔의 충격 — Intruder 보고서가 드러낸 ‘속도와 보안의 비대칭’

2026 년 5 월 24 일, Qiita 에 정리된 한 편의 분석은 어떤 신기능 발표보다 무거운 무게로 일본·한국의 엔지니어 타임라인을 채웠다. 보안 기업 Intruder 가 약 200 만 호스트를 스캔하고, 그 가운데 100 만 대의 노출된 AI 서비스를 분석한 보고를 한 줄로 요약한 표제가 ‘사상 최악의 보안’ 이었기 때문이다. 무엇이 그렇게 나빴다는 것인가, 그리고 그것이 정말 ‘AI 특유의’ 문제인가.

도입 — 숫자의 첫 인상과 그 뒤에 있는 구조

먼저 Intruder 보고의 골격을 숫자로만 옮긴다. 200 만 + 호스트가 스캔의 모집단이다. 그 가운데 100 만 대가 AI 서비스로 분류됐다 — Ollama 의 11434 포트, n8n 의 5678 포트, Flowise 의 3000 포트 등 잘 알려진 AI 도구 포트를 외부에 열어 둔 호스트가 그렇게 많다. Ollama API 만 따로 보면, 그 100 만 가운데 약 5,000 대가 Ollama 였고, 그 가운데 31 % — 약 1,600 인스턴스 — 가 어떤 인증도 없이 외부에서 모델 추론을 호출할 수 있는 상태였다. 그 1,600 가운데 518 대는 Ollama 자체로 모델을 호스팅하는 것이 아니라 OpenAI / Google / Anthropic 의 유료 API 를 백엔드로 감싸는 프록시 — 즉 누구든 호출하면 운영자의 카드로 청구되는 구조 — 였다. 정부·금융 부문에서 운용되고 있는 n8n 또는 Flowise 인스턴스 90 여 대가 공개 인터넷에 그대로 노출되어 있다는 부수 보고가 마지막 한 줄로 따라온다.

숫자 자체의 무게는 분명하다. 그러나 무게의 실제 의미는 비교에서 나온다. Intruder 가 같은 방법으로 같은 기간에 측정한 일반 웹 애플리케이션 군 (Apache / Nginx 뒤의 익숙한 LAMP / Node 스택) 의 인증 누락률은 한 자릿수 후반대에 머문다. AI 서비스 군의 31 % 는 그 비율보다 한 자릿수 더 큰 노출률이다. 보고의 표제가 ‘사상 최악’ 이라고 쓴 것은 절댓값이 아니라 비교값에 대한 진단이다.

여기서 본 글이 풀고자 하는 질문이 정렬된다. 이 비대칭은 일시적 사고인가, 아니면 ‘AI 도구 카테고리에 구조적으로 박혀 있는 결함’ 인가. 그리고 그 결함이 구조적이라면, 그 구조를 만든 힘은 무엇이고, 그 힘에 대해 방어자는 어떤 옵션을 가지고 있는가.

본문 1 — 노출의 해부학: 어디서, 어떻게 새는가

Intruder 보고의 가장 가치 있는 부분은 노출의 패턴을 카테고리로 분리한 점이다. 세 가지로 정리된다.

첫째 카테고리는 ‘추론 엔드포인트의 직접 노출’ 이다. Ollama 의 11434 포트가 대표 예다. Ollama 의 기본 설치 가이드는 localhost 바인딩을 권장하지만, Docker 컨테이너로 띄울 때 -p 11434:11434 로 호스트의 모든 인터페이스에 바인딩되는 패턴이 너무 흔하다. 클라우드 인스턴스에서 보안 그룹이 22, 80, 443 만 막혀 있고 11434 가 열려 있는 상태는 의도된 것이 아니라 ‘안 닫은’ 것이다. 같은 패턴이 텍스트 임베딩 서버, 음성 모델 서버, 멀티모달 라우터에서도 반복된다. 보안 부재의 가장 흔한 원인은 악의가 아니라 기본값과 가이드의 거리 다.

둘째 카테고리는 ‘추론 프록시의 노출’ 이다. 보고의 518 대 — 외부 유료 API 를 감싸는 Ollama 프록시 — 가 가장 충격적인 사례다. 이 패턴은 보통 사내 도구로 시작한다. 팀 누군가가 “회사 OpenAI 키를 직접 노출하지 말고, 사내 LLM 게이트웨이를 두자” 는 아이디어로 OpenAI 호환 API 를 노출하는 Ollama 프록시를 띄운다. 사내에서만 쓰던 것이 클라우드 위에서 돌게 되고, 클라우드의 기본 보안 그룹이 0.0.0.0/0 으로 열리면, 그 게이트웨이는 외부의 누구라도 자유롭게 호출할 수 있는 상태가 된다. 이때 운영자는 호출당 청구를 지불하지만 누가 호출하는지 알 수 없다. Intruder 보고의 한 줄 — 일본어 번역에 따르면 — “課金が走るのは運営者、しかし呼び出し主は不明” (청구는 운영자에게 가지만 호출자는 알 수 없다) 가 이 카테고리의 본질을 요약한다.

셋째 카테고리는 ‘워크플로 플랫폼의 노출’ 이다. n8n, Flowise, Dify 같은 도구가 여기 속한다. 이 도구들은 LLM 호출을 일종의 비주얼 워크플로로 묶어 두기 때문에, 노출되면 단지 모델 추론만 새는 것이 아니라 비즈니스 로직과 인증 자격증명 까지 함께 새어 나온다. 보고의 정부·금융 부문 90 여 대 노출 사례가 이 카테고리에 속한다. n8n 의 5678 포트나 Flowise 의 3000 포트가 열려 있는 정부 기관의 인스턴스에서, 외부 공격자는 워크플로 안에 박혀 있는 데이터베이스 비밀번호, 사내 API 토큰, 챗봇의 시스템 프롬프트, 이전 대화의 개인정보까지 한 화면에서 볼 수 있다. 노출의 폭발 반경이 단순 추론 노출보다 훨씬 크다.

세 카테고리의 공통 특징을 정리하면 — 셋 다 ‘개발자 도구의 기본 UX 가 외부 노출 시나리오를 가정하지 않고 설계됐다’ 는 점이다. 로컬에서 빠르게 띄워서 가볍게 실험하는 것이 1 차 사용자 가정이고, 프로덕션 배포는 사용자가 알아서 보안을 추가하는 것이 전제다. 그 전제가 깨지는 지점에 100 만 대의 노출이 있다.

본문 2 — ‘속도와 보안의 비대칭’ 이 왜 AI 에서 더 클까

여기서 본 글의 두 번째 질문으로 들어간다. 위의 노출 패턴은 사실 LAMP 시대의 phpMyAdmin 노출, 컨테이너 시대의 etcd 노출, 빅데이터 시대의 Elasticsearch 노출과 형상이 같다. 그런데 왜 AI 도구 카테고리에서 그 비율이 한 자릿수 더 크게 나타나는가. 구조적 원인을 세 가지로 정리한다.

첫째, ‘배포의 시간상수’ 가 다르다. 전통적 웹 애플리케이션의 배포는 보통 몇 주 ~ 몇 달 단위의 프로젝트로 잡힌다. 그 기간 안에 인프라 팀이 보안 검토, 네트워크 설정, IAM 정책을 정렬한다. AI 도구의 배포는 종종 ‘반나절 ~ 며칠’ 단위로 끝난다. 누군가가 GitHub README 를 보고 docker run 한 줄로 띄우고, 그 결과를 데모로 보여 주고, 그것이 정식 서비스로 굳어진다. 그 며칠 안에 보안 검토가 들어갈 자리가 없다. Intruder 보고의 사례 가운데 다수가 ‘실험으로 시작해서 굳어진 것’ 이라는 점이 이 시간상수의 결과다.

둘째, ‘사용자의 기술적 자가 진단 능력의 분포’ 가 다르다. AI 도구의 운영자는 데이터 사이언티스트, 머신 러닝 엔지니어, 또는 도구를 갓 배운 백엔드 엔지니어인 경우가 많다. 전통적 웹 운영자 풀에 비해, 클라우드 네트워크 보안 — 보안 그룹, IAM, 비밀 관리 — 에 대한 깊이가 평균적으로 얕다. 이것은 비난이 아니라 분포의 사실이다. AI 도구가 새로운 사용자 카테고리를 끌어들이고 있고, 그 사용자 카테고리의 보안 디폴트 감각이 LAMP 운영자의 그것과 다르다는 것이 핵심이다.

셋째, ‘공격 경제학의 비대칭’ 이 있다. 전통적 웹 노출은 데이터 도난, 사이트 변조, 봇넷 추가 같은 비교적 측정 가능한 피해로 이어진다. AI 도구 노출은 그것에 더해 ‘추론 비용의 외부화’ 라는 새 공격 모드를 만든다. 누군가가 노출된 Ollama 프록시를 발견하면, 자기 ChatGPT 비용을 회피하기 위해 그 프록시를 통해 OpenAI API 를 호출한다. 운영자는 모르는 사이에 한 달에 수천 달러를 부담한다. 공격자의 이득은 추출된 데이터의 가치가 아니라 회피된 추론 비용이고, 그 비용은 매우 매끄럽게 현금화된다. 공격 ROI 가 명확하다는 사실 자체가 새로운 종류의 압력이다.

세 구조적 원인이 합쳐지면, AI 도구의 노출 비율이 전통 웹의 그것보다 한 자릿수 큰 것은 일시적 현상이 아니라 카테고리의 본질이라는 결론이 나온다. Intruder 의 표제가 ‘사상 최악’ 이라고 쓴 것은 과장이 아니라 ‘카테고리가 가진 비대칭의 첫 번째 큰 측정’ 이다.

여기에 보고의 마지막 한 줄 — “もう始まっている” (이미 시작됐다) — 의 무게가 얹힌다. Google 의 Threat Intelligence Group 이 같은 5 월 발표한 보고에 따르면, 공격자들이 LLM 을 이용해 제로데이 탐색과 익스플로잇 자동 생성을 실제로 시작한 흔적이 잡힌다. 노출된 인스턴스를 자동으로 찾고, 그 인스턴스의 모델을 이용해 다음 익스플로잇을 만들고, 그 익스플로잇을 다음 노출된 인스턴스에 적용하는 자기 강화 루프가 이론에서 실측으로 옮겨 가고 있다는 것이다. 100 만 대의 노출이라는 거대한 표면이 그 루프의 연료가 된다.

본문 3 — 방어자의 옵션: 단기 조치와 구조적 변화

이 진단의 무게 위에서 방어자가 즉시 할 수 있는 것과 중기적으로 해야 하는 것을 분리한다.

즉시 — 다음 24 ~ 72 시간 단위 — 의 조치는 단순하다. 모든 AI 도구의 기본 포트 (11434, 5678, 3000 외 운영 중인 포트) 의 외부 노출을 점검한다. shodan 검색이나 사내 자산 스캐너로 자기 자산의 노출 상태를 자기가 먼저 확인하는 것이 첫 단계다. 노출이 발견되면 보안 그룹 / 방화벽 / 리버스 프록시 인증 가운데 가장 빠른 방법으로 막는다. 그 다음 단계는 — Intruder 의 권고에 따르면 — 노출된 인스턴스의 추론 로그와 청구서를 점검해, 외부 호출이 이미 일어났는지를 확인하는 것이다. 추론 비용의 외부화는 청구서의 평소 패턴과 다른 모양으로 나타나기 때문에 비교적 명확히 잡힌다.

중기 — 분기 단위 — 의 조치는 도구의 선택과 운영 패턴에 들어간다. 세 가지로 정리한다.

첫째, ‘AI 도구는 게이트웨이 뒤에 둔다’ 는 새 표준의 채택이다. Ollama, n8n, Flowise 의 직접 노출을 허용하지 않고, 모든 호출이 인증·감사·요청 한도 제어가 적용되는 게이트웨이 (예: Litellm, Portkey, 자사 빌드 게이트웨이) 를 거치게 한다. 이는 클라우드 시대 초기에 ‘데이터베이스를 인터넷에 직접 노출하지 않는다’ 가 표준이 된 것과 같은 종류의 위생 표준이다.

둘째, ‘추론 비용의 이상 탐지’ 의 일상화다. AWS / GCP / Azure 의 비용 알람이 새로운 종류의 보안 알람으로 격상된다. 모델 호출량의 시간당 / 일당 분포가 평소 평균에서 표준편차 3 ~ 5 배를 넘으면 자동 차단되고 운영자에게 알림이 가는 구조다. 추론 비용의 외부화 공격에 대한 가장 빠른 신호가 청구서의 모양 변화이기 때문이다.

셋째, ‘AI 도구 운영자의 보안 자격증명’ 의 확립이다. 데이터 사이언티스트 / ML 엔지니어가 프로덕션 추론 인프라를 운영하기 전에 받아야 하는 최소 보안 교육이 표준화된다. 보안 그룹, IAM, 비밀 관리, 추론 로그 보존 정책의 네 가지가 핵심이다. 이는 DevOps 가 운영 엔지니어의 표준 자격이 된 과정과 같은 종류의 직무 확장이다.

세 조치가 같이 가야 한다. 게이트웨이만 두면 게이트웨이가 노출되고, 비용 알람만 있으면 알람 도착 시점에 이미 큰 피해가 발생하고, 교육만 있으면 도구가 추월한다. 단기 조치 + 게이트웨이 + 비용 알람 + 운영자 자격증명의 네 가지가 같은 시기에 정렬되어야 카테고리의 구조적 비대칭이 완화된다.

결론 — ‘이미 시작됐다’ 는 경고를 어떻게 받아 안을 것인가

Intruder 보고가 던지는 진짜 메시지는 100 만 대의 노출이라는 숫자 자체가 아니다. ‘AI 도구 카테고리는 보안 디폴트가 깨진 상태로 빠른 속도로 확장됐고, 그 깨진 디폴트의 청구서가 이미 도착하고 있다’ 는 진단이 진짜 메시지다. 이 진단은 도구 제작자, 운영자, 그리고 그 사이의 보안 커뮤니티에 각각 다른 무게로 작용한다.

도구 제작자에게는 ‘개발자 친화적 기본값과 프로덕션 안전 기본값의 분리’ 라는 숙제가 떨어진다. Ollama 가 localhost 바인딩을 권장한다는 사실은 충분하지 않다. --bind 0.0.0.0 옵션을 명시적으로 켜야만 외부 바인딩이 가능하도록 동작 자체가 바뀌어야 한다. n8n 과 Flowise 의 첫 부트 시 인증 마법사가 강제되어야 한다. 이 변화는 도구의 학습 곡선을 약간 올리지만, 카테고리의 신뢰도를 회복하는 유일한 길이다.

운영자에게는 — 이미 위에서 정리한 네 가지 조치를 즉시 실행하는 것 외에 — 자기가 운영하는 AI 도구의 노출 위험을 자기가 측정 가능하게 만드는 책임이 더해진다. ‘shodan 에서 자기 자산을 검색해 보기’ 는 한 시간이면 끝나는 작업이지만, 그것을 정기 작업으로 만드는 운영팀은 매우 드물다.

보안 커뮤니티에는 — 가장 중요한 — 카테고리별 위생 표준을 만드는 일이 떨어진다. OWASP 의 Top 10 이 웹 카테고리에 한 일을, AI 도구 카테고리에서 다시 해야 한다. OWASP 의 LLM Top 10 이 이미 시작됐지만, 그것은 모델 사용의 표준이지 도구 운영의 표준이 아니다. Intruder 가 보여 준 노출의 카테고리화 (추론 엔드포인트, 추론 프록시, 워크플로 플랫폼) 가 그 새 표준의 출발점이 되어야 한다.

마지막으로 — 가장 어려운 — 질문 하나를 독자에게 던지면서 글을 닫는다. 우리가 운영 중인 AI 도구 인스턴스의 노출 상태를 우리는 정말 알고 있는가. Intruder 의 100 만 대 가운데 한 대가 우리의 것일 가능성은 정확히 얼마인가. 그 답을 모른다면, 다음 24 시간 안에 답을 만드는 것이 이 보고에 대한 가장 정직한 응답이다.

출처: