이번 글에서 먼저 봐야 할 것은 모델 성능이 아니라 접근 경로입니다. 2026년 허깅페이스(Hugging Face), 버셀(Vercel), 몰트북(Moltbook)에서 공개된 사건은 AI 서비스의 데이터 처리 파이프라인, 외부 계정 연결, 데이터베이스 접근 통제가 실제 침입 지점이 될 수 있다는 사실을 보여줬습니다.
인공지능(Artificial Intelligence, AI)은 수상한 접속을 탐지하고 악성코드를 분석하는 방어 기술로 활용됩니다. 동시에 외부 데이터와 코드를 자동으로 처리하고, 이메일·문서·코드 저장소 같은 업무 시스템에 접근하면서 조직이 관리해야 할 범위도 넓어졌습니다.
기업이 판단해야 할 것은 AI 도입 여부만이 아닙니다. 어떤 입력에 코드 실행을 허용하는지, 외부 도구에 어떤 계정 권한을 주는지, 사고가 발생하면 어느 지점에서 접근을 차단할 수 있는지를 설명해야 합니다.
SYSTEM SUMMARY
AI 보안은 네 개의 연결을 관리하는 문제입니다.
외부 데이터·파일 → 코드가 실행되는 처리 환경 → OAuth·API 키·서비스 계정 → 클라우드·문서·데이터베이스·업무 시스템
몰트북 조사
약 150만 개
위즈가 노출을 확인한 API 인증 토큰
앤트로픽 분석
80~90%
사이버 첩보 작전에서 AI가 수행한 것으로 추정된 전술 작업 비중
버라이즌 DBIR
31%
취약점 악용으로 시작된 것으로 분류된 침해 사고 비중
AI 보안은 기존 사이버 보안과 무엇이 다른가
AI 시스템도 서버, 데이터베이스, 계정과 응용 프로그램으로 구성됩니다. 인증 실패, 과도한 권한, 노출된 비밀정보처럼 오래된 보안 문제가 사라진 것은 아닙니다.
달라진 부분은 연결의 밀도입니다. 일반 업무용 소프트웨어는 정해진 화면과 기능을 통해 입력을 받는 경우가 많지만, AI 서비스는 데이터셋, 문서, 모델 파일, 프롬프트와 사용자 정의 코드를 대량으로 받아 처리합니다. 에이전트가 연결되면 입력은 답변 생성에 그치지 않고 파일 읽기, 데이터베이스 조회, 코드 실행과 메시지 전송으로 이어질 수 있습니다.
모델이 직접 해킹되지 않아도 피해가 발생하는 이유가 여기에 있습니다. 공격자는 가장 비싼 모델을 정면으로 공격하기보다 모델 주변에 연결된 처리 서버, 외부 도구, 인증 토큰과 클라우드 계정을 먼저 노릴 수 있습니다.
데이터셋은 왜 소프트웨어 공급망으로 봐야 하나
허깅페이스가 2026년 7월 공개한 사고는 AI 플랫폼의 데이터 처리 과정이 어떤 공격 표면을 만드는지 보여줍니다. 회사 발표에 따르면 악성 데이터셋은 원격 코드 실행(Remote Code Execution, RCE)이 가능한 로더와 데이터셋 설정의 템플릿 주입 취약점을 이용해 처리 서버에서 코드를 실행했습니다.
공격자는 이후 서버 노드 수준의 접근 권한을 확보하고 클라우드와 클러스터 자격 증명을 수집해 여러 내부 클러스터로 이동했습니다. 허깅페이스는 제한된 내부 데이터셋과 일부 서비스 자격 증명에 무단 접근이 있었다고 밝혔습니다.
다만 공개 모델과 사용자용 데이터셋, 스페이스 또는 배포 소프트웨어가 변조됐다는 증거는 발견되지 않았습니다. 고객이나 파트너 데이터가 영향을 받았는지는 발표 당시 계속 조사 중이었으므로 피해 범위를 확정해서 표현해서는 안 됩니다.
놓치기 쉬운 지점
AI 플랫폼에서 데이터셋은 읽기만 하는 파일이 아닐 수 있습니다. 로더, 전처리 스크립트, 평가 도구와 실행 환경을 동반한다면 외부 소프트웨어 구성요소와 같은 수준으로 검증해야 합니다.
따라서 데이터 수집 파이프라인을 단순한 콘텐츠 등록 기능으로 다루기 어렵습니다. 데이터가 들어오는 순간부터 검증, 전처리, 학습, 평가와 배포까지 어느 단계에서 코드가 실행되는지 확인해야 합니다. 실행이 필요하더라도 내부 네트워크와 자격 증명에 접근할 수 없는 격리 환경에서 처리하는 편이 안전합니다.
작은 AI 도구가 회사 계정의 입구가 되는 이유
외부 AI 서비스는 업무를 편리하게 만들기 위해 이메일, 문서, 캘린더와 코드 저장소에 연결됩니다. 이때 흔히 사용되는 방식이 개방형 권한 부여(Open Authorization, OAuth)입니다. 사용자는 비밀번호를 서비스에 직접 제공하지 않고, 특정 범위의 접근 권한을 토큰 형태로 허용합니다.
문제는 연결한 서비스가 침해됐을 때입니다. 버셀은 2026년 4월 직원이 사용하던 Context.ai의 침해가 해당 직원의 구글 워크스페이스(Google Workspace) 계정으로 이어졌다고 밝혔습니다. 공격자는 이어서 직원의 버셀 계정에 접근하고 내부 환경으로 이동해 민감 정보로 지정되지 않은 일부 환경변수를 확인하고 복호화했습니다.
처음부터 버셀의 핵심 서비스가 직접 뚫린 사건은 아니었습니다. 직원이 연결한 외부 AI 도구와 그 도구에 부여된 권한이 조직 내부로 이동하는 통로가 됐습니다.
이런 상태를 그림자 AI(Shadow AI) 문제로 볼 수 있습니다. 직원이 어떤 서비스를 이용하는지만 모르는 것이 아닙니다. 해당 도구가 어떤 계정에 연결됐고, 어떤 문서를 읽을 수 있으며, 접근 토큰이 언제 만료되는지 조직이 파악하지 못하는 상태까지 포함합니다.
빠르게 만든 AI 서비스가 반복하는 오래된 보안 실패
AI를 이용한 개발이 곧바로 새로운 종류의 취약점을 만든다고 단정할 수는 없습니다. 실제 사고에서는 오래전부터 알려진 인증, 데이터베이스 권한과 비밀정보 관리 실패가 다시 나타나는 경우가 많습니다.
보안기업 위즈가 2026년 2월 조사한 AI 에이전트 소셜 네트워크 몰트북 사례가 대표적입니다. 클라이언트 측 자바스크립트에 데이터베이스 접근 키가 노출됐고, 접근 통제가 제대로 설정되지 않아 인증받지 않은 이용자도 운영 데이터베이스를 읽고 수정할 수 있었습니다.
위즈는 약 150만 개의 응용 프로그램 인터페이스(Application Programming Interface, API) 인증 토큰과 3만5천 개의 이메일 주소, 에이전트 간 비공개 메시지가 노출됐다고 보고했습니다. 일부 메시지에는 외부 서비스의 API 키가 평문으로 포함돼 있었습니다.
몰트북 창업자는 AI를 활용해 직접 코드를 작성하지 않고 서비스를 만들었다고 공개했습니다. 위즈는 이 사례를 바이브 코딩(vibe coding) 과정에서 기본 보안 검토가 빠질 수 있는 위험과 연결했습니다. 문제는 AI로 코드를 만들었다는 사실보다, 생성된 코드와 설정을 사람이 충분히 검토하지 않은 채 운영 환경에 배포했다는 데 있습니다.
| 사례 | 처음 열린 경로 | 확산 조건 | 먼저 확인할 통제 |
|---|---|---|---|
| 허깅페이스 | 악성 데이터셋과 코드 실행 경로 | 처리 노드의 클라우드·클러스터 자격 증명 | 격리 실행, 네트워크 제한, 단기 자격 증명 |
| 버셀 | 외부 AI 도구의 OAuth 연결 | 업무 계정과 내부 서비스 간 연속 로그인 | OAuth 앱 목록, 권한 범위, 토큰 회수 절차 |
| 몰트북 | 노출된 데이터베이스 접근 키 | 인증·행 단위 접근 통제 부재 | 비밀정보 검사, 기본 차단 설정, 배포 전 보안 검토 |
| 앤트로픽이 공개한 공격 | 사람이 선정한 공격 대상과 자동화 프레임워크 | 정찰·취약점 분석·자격 증명 수집 자동화 | 빠른 패치, 행동 기반 탐지, 상시 대응 체계 |
공격자가 AI를 쓰면 무엇이 빨라지는가
AI가 완전히 독립적인 해커가 됐다고 표현하기는 이릅니다. 현재 확인된 사례에서도 사람은 공격 대상을 고르고 중요 단계의 진행 여부를 승인했습니다. AI는 존재하지 않는 자격 증명을 만들어내거나 공개 정보를 비밀정보로 오인하기도 했습니다.
다만 공격에 필요한 노동량과 처리 속도는 달라지고 있습니다. 앤트로픽은 2025년 11월 공개한 자체 조사에서 공격자가 클로드 코드(Claude Code)를 이용해 사이버 첩보 활동을 수행한 사례를 설명했습니다.
공격자는 복잡한 침입 과정을 작은 작업으로 나누고 각 요청의 전체 목적이 드러나지 않도록 구성했습니다. 대규모 언어 모델(Large Language Model, LLM)은 정찰, 취약점 분석, 공격 코드 작성, 자격 증명 수집과 탈취 데이터 분류에 활용됐습니다. 앤트로픽은 전술 작업의 약 80~90%가 AI에 의해 처리됐다고 추정했으며, 이 수치는 회사 자체 조사 결과입니다.
버라이즌의 2026년 DBIR도 같은 방향을 가리킵니다. 보고서는 3만1천 건이 넘는 보안 사고를 분석했으며, 확인된 침해 사고의 31%에서 취약점 악용이 초기 접근 경로로 나타났다고 밝혔습니다. 생성형 AI는 공격자가 이미 알려진 취약점을 찾고 시험하는 속도를 높여 방어 조직의 대응 시간을 수개월에서 수시간으로 줄이는 요인으로 지목됐습니다.
새로운 해킹 기법만 찾다 보면 이 변화를 놓칠 수 있습니다. 당장 더 현실적인 위험은 이미 알려진 공격 절차가 더 적은 인원과 더 짧은 시간으로 반복되는 것입니다.
한국 기업은 AI 보안을 어디서부터 점검해야 하나
첫 단계는 금지 정책이 아니라 현황 파악입니다. 회사가 공식 구매한 AI 서비스뿐 아니라 직원이 개인 계정으로 연결한 회의 기록, 문서 요약, 코딩, 검색, 디자인 도구까지 확인해야 합니다.
그다음에는 사람 계정과 서비스 계정, API 키와 에이전트 토큰을 나누어 관리해야 합니다. 사람이 아닌 계정은 비밀번호 변경을 요구받지 않고 오랫동안 유지되기 쉬우며, 자동화 때문에 예상보다 넓은 권한을 갖는 경우가 있습니다.
AI SECURITY CHECKLIST
- AI 서비스 목록: 부서별로 어떤 AI 도구를 사용하고 있는지 확인했습니까?
- 계정 연결: 각 도구가 이메일, 문서, 캘린더, 코드 저장소 중 어디에 연결돼 있습니까?
- 최소 권한: 읽기만 필요한 도구에 수정·삭제·발송 권한까지 부여하지 않았습니까?
- 토큰 수명: API 키, 서비스 계정과 에이전트 토큰의 소유자·용도·만료일이 기록돼 있습니까?
- 외부 입력 격리: 데이터셋과 모델 파일을 운영망과 분리된 샌드박스에서 처리합니까?
- 행동 기록: 에이전트가 어떤 도구를 호출하고 어떤 데이터를 외부로 보냈는지 추적할 수 있습니까?
- 사람 승인: 데이터 삭제, 외부 발송, 결제, 배포와 권한 변경 전에 사람의 승인을 받습니까?
- 사고 대응: 외부 AI 공급업체가 침해됐을 때 연결 해제, 토큰 회수와 비밀정보 교체 순서가 정해져 있습니까?
외부 데이터와 모델을 처리하는 환경에는 샌드박스, 네트워크 차단과 단기 자격 증명을 적용해야 합니다. 코드가 실행되더라도 내부 시스템으로 이동할 수 있는 경로를 최소화하기 위해서입니다.
외부 AI 공급업체를 평가할 때는 기능 목록만 보지 않아야 합니다. OAuth 권한 범위, 데이터 보관 기간, 다중 인증(Multi-Factor Authentication, MFA) 지원, 침해 사고 통지 기준, 로그 제공 범위와 퇴사자·계약 종료 시 계정 회수 방법을 함께 확인할 필요가 있습니다.
다음에 볼 지표
AI 도구의 개수보다 고위험 OAuth 연결 수, 90일 이상 유지된 비인간 계정 비율, 외부 입력의 격리 처리율, 에이전트 도구 호출의 기록 범위, 심각 경보가 담당자에게 전달되기까지 걸린 시간을 확인해야 합니다.
최근 사고들의 공통점은 AI 자체가 갑자기 통제 불가능해졌다는 데 있지 않습니다. 검증되지 않은 입력, 과도한 권한, 노출된 비밀정보, 느슨한 데이터베이스 설정과 늦은 대응이 서로 연결됐습니다.
AI는 이 오래된 문제를 더 넓은 범위와 더 빠른 속도로 이어 붙입니다. 따라서 AI 보안은 모델을 잠그는 기술만을 뜻하지 않습니다. AI가 무엇을 읽을 수 있는지, 어떤 도구를 사용할 수 있는지, 누구의 권한으로 행동하며 어느 조건에서 멈춰야 하는지를 정하는 운영 체계에 가깝습니다.
AI 기업과 도입 조직의 공격 표면은 모델 밖에 넓게 분포합니다. 데이터셋 처리 서버, 외부 AI 도구의 OAuth 권한, API 키, 서비스 계정과 에이전트의 도구 호출을 하나의 연결 구조로 관리해야 합니다. 지금 확인할 것은 어떤 데이터를 쓸 수 있는지, 각 계정이 어디까지 움직일 수 있는지, 사고가 발생하면 몇 분 안에 차단할 수 있는지입니다.
FAQ
자주 묻는 질문
Q. AI 보안은 기존 사이버 보안과 완전히 다른 분야인가요?
완전히 별개의 분야는 아닙니다. 인증, 최소 권한, 비밀정보 관리와 패치 같은 기본 원칙은 그대로 적용됩니다. 다만 데이터셋, 프롬프트, 모델 파일과 에이전트 행동처럼 입력이 내부 실행으로 이어지는 경로를 추가로 관리해야 합니다.
Q. 데이터셋을 업로드하는 것만으로도 공격이 발생할 수 있나요?
데이터셋이 단순 텍스트 파일이고 실행 기능이 없다면 위험 범위는 제한적입니다. 그러나 사용자 정의 로더, 전처리 스크립트나 템플릿이 실행되는 구조라면 악성 코드가 처리 환경에서 작동할 수 있습니다. 외부 데이터의 형식뿐 아니라 어떤 코드가 함께 실행되는지 확인해야 합니다.
Q. 직원의 외부 AI 도구 사용을 모두 차단해야 하나요?
일괄 차단만으로는 개인 계정 사용을 지하화할 수 있습니다. 먼저 사용 현황과 연결 권한을 파악하고, 허용 서비스와 금지 데이터 유형을 구분하는 접근이 현실적입니다. 고위험 OAuth 권한과 외부 발송 기능은 별도 승인을 받도록 설계할 수 있습니다.
Q. AI 에이전트에는 어떤 권한을 부여해야 하나요?
업무 수행에 필요한 최소 범위만 부여해야 합니다. 읽기 작업에 수정 권한을 주지 않고, 데이터 삭제·외부 발송·결제·배포 같은 고위험 행동은 사람이 승인하도록 분리하는 방식이 적합합니다. 모든 도구 호출과 결과를 기록할 수 있어야 사후 조사도 가능합니다.
TERMINOLOGY
본문에 나오는 주요 보안 용어
| 용어 | 뜻 | 실무자가 이해할 포인트 |
|---|---|---|
| RCE | 외부 공격자가 대상 서버에서 코드를 실행할 수 있는 상태 | 외부 파일을 처리할 때 코드 실행 여부와 실행 환경의 격리가 중요합니다. |
| OAuth | 외부 서비스에 계정의 일부 접근 권한을 위임하는 방식 | 앱이 침해되면 허용된 이메일·문서·캘린더 권한이 공격 통로가 될 수 있습니다. |
| 그림자 AI | 조직의 공식 승인과 관리 밖에서 사용되는 AI 서비스 | 사용 여부뿐 아니라 연결 계정, 입력 데이터와 보유 토큰까지 파악해야 합니다. |
| API 키 | 프로그램이 외부 서비스에 접근할 때 사용하는 인증 정보 | 소스코드나 브라우저에 노출하지 않고, 용도별 분리와 만료·교체 절차를 적용해야 합니다. |
| 샌드박스 | 코드가 다른 시스템에 영향을 주지 않도록 격리한 실행 환경 | 파일·네트워크·클라우드 자격 증명 접근을 작업에 필요한 수준으로 제한해야 합니다. |
| 최소 권한 | 업무에 필요한 가장 작은 범위의 접근 권한만 부여하는 원칙 | AI 에이전트에는 기능, 데이터 범위와 실행 시간을 각각 제한하는 편이 안전합니다. |
References
- [1] Hugging Face | Security incident disclosure — July 2026
- [2] Vercel | Vercel April 2026 security incident
- [3] Wiz Research | Hacking Moltbook: The AI Social Network Any Human Can Control
- [4] Anthropic | Disrupting the first reported AI-orchestrated cyber espionage campaign
- [5] Verizon | 2026 Data Breach Investigations Report
- [6] Reuters | AI-related data breaches surging, Verizon report says
- [7] NIST | Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
- [8] OWASP GenAI Security Project | Securing Agentic Applications Guide 1.0
댓글
댓글 쓰기