보안 사고 83%에 AI가 있었어요 | 클라우드 AI 도입 전 점검할 것
글로벌 보안 조사에서 최근 1년간 발생한 침해 사고의 83%에 AI가 관련됐고, 그중 30%는 내부 정보 유출로 이어졌어요. 클라우드 AI에 코드와 로그를 붙여넣는 일이 늘어나는 지금, 자체 SaaS 4종을 운영해온 개발사 관점에서 기업이 짚어야 할 지점을 정리했어요.
핵심 요약 — 글로벌 보안 조사에서 응답 기업의 65%가 최근 1년 사이 보안 침해 사고를 최소 한 차례 겪었고, 그 사고의 83%에 AI가 어떤 형태로든 관련돼 있었어요. 공격자가 AI를 무기로 쓴 경우(AI 기반 공격 41%·LLM 직접 공격 33%)와 조직 내부에서 승인되지 않은 AI를 쓰거나 정보가 샌 경우(각 30%)가 함께 섞여 있었고요. 자체 SaaS 4종을 직접 운영해온 개발사 관점에서, 클라우드 AI를 쓰기 전에 기업이 점검할 지점을 정리했어요.
📰 2026년 9월 7일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.
“우리 회사는 아직 AI 때문에 사고 난 적 없는데요.” 이렇게 말하는 회사일수록 오히려 확인이 안 됐을 가능성이 커요. 직원이 오류 로그 하나를 클라우드 AI에 붙여넣는 순간은 보안팀 눈에 잘 띄지 않거든요.
1. 보안 사고 10건 중 8건에 AI가 있었어요
보안 기업 기가몬(Gigamon)이 6개국 보안·IT 의사결정권자 1,000여 명을 대상으로 진행한 ‘2026 하이브리드 클라우드 보안 보고서’에 따르면, 응답 기업의 65%가 최근 1년 사이 최소 한 차례 이상 보안 침해 사고를 겪었어요. 3년 전과 비교하면 40% 늘어난 수치예요. 더 눈에 띄는 건 그 사고들의 83%에 AI가 관련돼 있었다는 점이에요.
2. 공격자의 무기가 된 AI
같은 조사에서 AI 기반 공격이 41%, LLM(거대 언어모델) 직접 공격이 33%로 나타났어요. AI 기반 공격은 피싱 문구나 악성코드를 AI가 대신 써주는 방식이고, LLM 직접 공격은 프롬프트(AI에게 주는 지시문)를 조작해 AI가 원래 하면 안 되는 답을 하게 만들거나, 코드 자동완성부터 오픈AI(OpenAI) Codex처럼 커밋까지 자율 실행하는 에이전트가 조작된 명령을 그대로 따르게 만드는 방식이에요. 둘 다 몇 년 전에는 없던 공격 경로예요.
3. 내부에서 새는 정보 — 승인되지 않은 AI 사용
승인되지 않은 AI 사용과 내부 정보 유출도 각각 30%씩 나왔어요. 실제 사례도 여럿 확인돼요. 한 기업 엔지니어는 시스템 오류를 빨리 고치려고 기밀 소스코드를 생성형 AI에 그대로 입력했다가 AI가 그 코드를 학습해버렸고, 다른 직원은 음성 앱으로 녹음한 중요 회의 녹취록을 회의록 작성용으로 통째로 생성형 AI에 넣었어요. 더 심각한 건 인증정보예요. 정보 탈취형 악성코드에 감염된 기기에서 나온 ChatGPT 로그인 정보가 10만 건 넘게(101,134건) 다크웹에서 거래된 사례도 확인됐어요. 셋 다 공격이 아니라 업무를 편하게 하려던 행동에서 시작됐다는 공통점이 있어요.
4. 클라우드 AI를 향한 신뢰가 낮아진 진짜 이유
같은 조사에서 응답자의 70%가 퍼블릭 클라우드 환경에서 AI를 운영하는 데 신중한 입장을 보였어요. 전년도 54%보다 크게 오른 수치예요. AI 자체가 갑자기 위험해진 게 아니라, 스스로 판단하고 움직이는 AI 에이전트 도입이 빠르게 늘면서 그 AI가 어디까지 접근하고 무엇을 했는지 회사가 실시간으로 파악하기 어려워진 게 진짜 이유예요. 통제 범위 밖에서 벌어지는 일이 늘어난 만큼, 신뢰도 함께 낮아진 셈이에요.
5. 직접 운영하는 입장에서 보는 통제 지점 4가지
저희도 자체 SaaS 4종을 직접 운영하면서 매일 코드와 로그를 다루는 입장이라, 위 통계가 남 얘기 같지 않았어요. 실무에서는 아래 네 가지부터 점검해요.
- 권한 분리: 코드·로그 접근 권한을 업무 단위로 쪼개서, 한 계정이 뚫려도 피해 범위가 전체로 안 번지게 해요.
- 반출 전 검토 규칙: 클라우드 AI에 무엇을 넣어도 되는지 문서로 미리 정해요. 이 규칙을 실제 필터 시스템으로 구현해본 실험은 로컬 LLM으로 민감정보 걸러본 사례에서 자세히 다룬 적 있어요.
- 사용 로그 남기기: 누가 언제 무엇을 AI에 넣었는지 기록이 있어야 사고가 났을 때 범위를 좁힐 수 있어요.
- 에이전트 권한 최소화: 자율적으로 움직이는 AI 에이전트일수록 처음부터 접근 범위를 좁게 설계해요.
6. 운영해본 개발사의 관점 — 자체 도입과 외주, 무엇이 다를까요
이런 통제 지점을 문서로 정리하는 일과, 그 문서를 실제 시스템(권한 분리·접근 로그·API 게이트웨이)으로 구현하는 일은 성격이 달라요. 규칙을 세우는 단계라면 내부 논의로 충분하지만, 그 규칙을 코드와 로그가 쌓이는 사내 파이프라인에 실제로 심는 작업이라면 개발 역량이 필요해요. 저희는 개발을 외주로 맡길 때도 이런 보안·개인정보 요건이 계약서에 들어가야 한다고 보고, 실제로 개발 외주 보안·개인정보 요건, 계약 전에 정할 7가지로 따로 정리해둔 적이 있어요.
AI 도입 범위와 접근 권한 설계부터 함께 정리하고 싶다면 운영해본 개발사와 상담받기 →
7. 자주 묻는 질문
보안 침해 사고에 AI가 관련됐다는 게 정확히 무슨 뜻인가요?
공격자가 AI를 공격 도구로 쓴 경우와, 조직 내부에서 승인되지 않은 AI를 쓰거나 그 과정에서 정보가 새어나간 경우를 모두 포함해요. 이번 조사에서는 이 네 유형이 침해 사고의 상당 부분을 차지했어요.
직원이 실수로 ChatGPT에 회사 정보를 입력하면 어떻게 되나요?
입력한 내용이 어디까지 저장·활용되는지는 서비스 약관에 따라 달라요. 실제로 정보 탈취형 악성코드에 감염된 기기에서 나온 ChatGPT 인증정보 로그 10만 건 이상이 다크웹에서 발견된 사례가 있었어요. 입력하기 전에 지우는 것이 가장 확실한 방법이에요.
AI 에이전트 도입은 늦추는 게 안전한가요?
늦추기보다 범위를 먼저 정하는 편이 현실적이에요. 자율적으로 파일을 열람하고 명령을 실행하는 에이전트일수록 접근 권한을 처음부터 좁게 설계해야 나중에 통제하기 쉬워요.
AI 자체 도입과 외주 개발 중 어떤 선택이 맞나요?
사용 규칙을 세우는 단계라면 내부에서 문서로 먼저 정리하는 게 순서예요. 그 규칙을 접근 권한 분리나 사용 로그 감사 같은 실제 시스템으로 구현하는 단계라면, 처음부터 서버와 체계를 직접 갖추기보다 외주로 붙이는 편이 더 빨라요.
8. 마무리
AI가 사고를 일으킨다기보다, AI가 다루는 범위가 넓어진 만큼 회사가 미처 못 챙긴 지점이 그대로 사고로 드러나는 쪽에 가까워요. 권한을 나누고, 반출 전에 한 번 더 보고, 기록을 남기는 것 — 거창한 도구보다 이 세 가지를 먼저 갖추는 회사가 실제로 사고를 줄여요.
저희는 10년 넘게 자체 SaaS 4종을 직접 운영하면서 이런 판단을 내부에서 늘 내려왔어요. 롯데·캐논 같은 곳과 진행한 프로젝트에서도 데이터를 다루는 범위를 계약 전에 정해두는 쪽이 항상 더 안전했고요. AI 도입이든 개발 외주든 회사 데이터가 어디까지 열리는지부터 정하고 시작하고 싶다면 프로젝트 상담받기 →에서 이야기 나눠요.
관련해서 함께 보면 좋은 글이에요.