기업 AI Agent 54% 사고 경고

기업 AI Agent가 실험실을 벗어나 실제 시스템과 데이터에 접근하기 시작했지만, 이를 통제하는 운영 체계는 아직 같은 속도로 성숙하지 못하고 있습니다. VentureBeat Pulse Research에 따르면 107개 기업 중 54%가 이미 AI Agent 보안 사고 또는 피해 직전의 근접 사고를 경험했습니다. 보안 사고가 이미 나타나는 가운데, 같은 날 보도된 VentureBeat의 별도 Pulse Research에서는 AI compute 비용 추적과 GPU 활용률에서도 유사한 운영 격차가 확인됐습니다. 한국 기업이 AI Agent를 업무 자동화, 고객 응대, 내부 운영에 붙이기 전에 봐야 할 핵심은 “모델 성능”보다 “권한과 비용을 가진 소프트웨어를 어떻게 운영할 것인가”입니다.

1. 보안 격차: Agent는 권한을 얻었지만 ID 통제는 느립니다

VentureBeat가 2026년 6월 실시한 Pulse Research는 직원 100명 초과 기업 107곳을 대상으로 AI Agent 보안 운영 현황을 조사했습니다. 이 조사는 확률 표본이 아니며 방향성 지표로 읽어야 하지만, 응답자의 45%가 AI 구매 최종 의사결정자이고 30%가 추천자 또는 영향력 있는 관계자라는 점에서 기업 구매 현장의 인식을 보여줍니다. 특히 Agent가 단순한 챗봇을 넘어 내부 API, 문서, 업무 시스템에 접근하는 단계로 이동하고 있다는 점을 고려하면, 이 조사는 “도입 의향”보다 “운영 통제”를 봐야 한다는 신호에 가깝습니다.

가장 눈에 띄는 수치는 54%입니다. VentureBeat에 따르면 조사 대상 기업의 18%는 확인된 AI Agent 보안 사고를 겪었고, 36%는 실제 피해가 발생하기 전 차단된 근접 사고를 경험했습니다. 즉, 절반이 넘는 기업에서 Agent 운영이 이미 보안 이벤트와 연결됐다는 뜻입니다. Agent가 단순히 질문에 답하는 단계라면 사고의 파급 범위는 제한적일 수 있습니다. 그러나 Agent가 API를 호출하고, 내부 문서를 읽고, 티켓을 생성하거나 수정하며, 결제·재고·고객 데이터 같은 시스템에 접근하면 위험의 성격이 달라집니다.

VentureBeat가 지적한 구조적 약점은 identity입니다. 모든 Agent에 범위가 제한된 관리형 ID를 부여한다고 답한 기업은 32%에 그쳤습니다. 나머지는 일부 Agent가 자격증명을 공유하거나, 대체로 공유 API key와 사람 또는 service account 자격증명으로 실행된다고 답했습니다. Agent가 자격증명을 공유하면, 하나의 과도한 권한 또는 유출된 key가 여러 업무 흐름으로 번질 수 있습니다. 이는 전통적인 계정 탈취보다 복잡합니다. 공격자가 “사람 계정”만 장악하는 것이 아니라, 업무 절차를 수행하도록 설계된 Agent의 실행 경로를 이용할 수 있기 때문입니다.

격리도 충분하지 않습니다. VentureBeat에 따르면 고위험 Agent를 sandbox로 격리한다고 답한 기업은 30%에 불과했습니다. Agent가 내부 도구를 호출하는 구조에서는 sandbox가 단순 개발 편의 기능이 아니라 blast radius를 줄이는 운영 장치가 됩니다. 예를 들어 잘못된 prompt injection, 오염된 문서, 권한 설계 오류가 발생했을 때 Agent가 접근 가능한 시스템과 데이터 범위를 제한해야 합니다. 하지만 현재 기업들은 Agent에 실제 권한을 주는 속도에 비해, Agent를 독립 실행 단위로 식별하고 격리하는 속도가 늦습니다.

2. compute 격차: 인프라는 사지만 단위 경제성은 흐립니다

같은 날 보도된 VentureBeat의 다른 Pulse Research는 AI Agent 운영 리스크가 보안만의 문제가 아니라는 점을 보여줍니다. 별도 compute 조사 역시 직원 100명 초과 기업 107곳을 대상으로 했으며, 기업 AI 인프라와 inference economics를 다뤘습니다. VentureBeat는 이를 “compute gap”이라고 표현했습니다. 즉, 기업들이 AI 인프라를 빠르게 구매하고 평가하는 속도에 비해, 이미 보유한 compute의 비용과 활용률을 파악하는 능력은 뒤처져 있다는 뜻입니다.

compute 조사에서 대규모 production으로 AI를 운영한다고 답한 기업은 21%였습니다. 그런데 향후 1년 동안 AI-specialized cloud를 평가하겠다는 응답은 45%로 나타났습니다. 아직 production 성숙도가 높지 않은 상태에서도 다음 인프라 구매와 평가 계획은 빠르게 움직이고 있는 셈입니다. 이미 보유한 GPU도 충분히 활용되지 못하고 있습니다. VentureBeat에 따르면 응답 기업의 83%가 GPU utilization 50% 이하라고 답했고, AI compute 비용을 엄격히 추적할 수 있는 기업은 44%에 그쳤습니다.

이는 Agent 운영에서 직접적인 문제로 이어집니다. Agent는 사람이 직접 클릭하던 업무를 자동으로 반복 실행할 수 있습니다. 고객 응대 Agent, 내부 검색 Agent, 코드 보조 Agent, 운영 자동화 Agent가 늘어나면 호출량과 inference 비용은 빠르게 증가할 수 있습니다. 그런데 어떤 Agent가 얼마의 GPU, API, cloud 비용을 만들었는지 알 수 없다면, 기업은 “자동화가 실제로 비용을 줄였는지” 또는 “단지 비용 항목을 다른 계정으로 옮겼는지” 판단하기 어렵습니다. Agent가 성공적으로 업무를 처리하더라도, 단위 경제성이 보이지 않으면 production 확장 판단은 불안정해집니다.

영역	VentureBeat가 제시한 핵심 수치	운영 리스크
Agent 보안	54%가 확인된 보안 사고 또는 근접 사고 경험, 모든 Agent에 scoped identity를 부여한 기업은 32%	공유 자격증명과 미흡한 격리로 사고 범위가 커질 수 있음
Agent 격리	고위험 Agent를 sandbox로 격리한다고 답한 기업은 30%	prompt injection, 권한 설계 오류, 오염된 입력이 내부 시스템으로 확산될 수 있음
Compute 비용	83%가 GPU utilization 50% 이하, 44%만 AI compute 비용을 엄격히 추적	Agent 사용량 증가가 비용 폭증으로 이어져도 단위 경제성을 파악하기 어려움

3. 공급자 네이티브 도구에 만족하면서도 교체를 준비하는 모순

VentureBeat는 기업들이 현재 사용하는 Agent 보안 stack이 대체로 model provider와 hyperscaler의 기본 기능에 기대고 있다고 설명했습니다. OpenAI guardrails가 51%로 언급됐고, Google 및 Microsoft의 cloud control, Anthropic의 managed-agent control도 주요 범주로 제시됐습니다. 반면 전용 Agent 보안 전문 업체는 아직 크게 부각되지 않았습니다. 흥미로운 점은 이러한 “빌려온 stack”에 대한 만족도입니다. 만족도는 5점 척도에서 평균 4.2점으로 높게 나타났습니다.

그러나 만족도가 높다고 해서 시장이 안정됐다는 뜻은 아닙니다. VentureBeat는 기업의 Agent 보안 지출이 전체 보안 예산에서 얇은 비중에 머물고 있으며, AI-enabled attacker보다 자사 방어가 앞서 있다고 믿는 기업은 약 3분의 1에 그친다고 전했습니다. 동시에 다수 기업은 1년 내 tooling 변경을 계획하고 있습니다. 즉, 기업들은 현재 도구에 “충분히 만족한다”고 답하면서도, 그 도구만으로 앞으로의 Agent 운영을 감당하기 어렵다고 느끼는 상태입니다.

compute 인프라에서도 유사한 불안정성이 보입니다. VentureBeat의 compute 조사에 따르면 64%는 12개월 안에 infrastructure provider를 바꾸거나 추가할 계획이며, 38%는 다음 분기 안에 움직일 계획이라고 답했습니다. 선택 기준도 단순한 headline token price가 아니었습니다. 기존 stack과의 integration은 41%, total cost of ownership은 35%로 나타났고, cost per million tokens를 결정 요인으로 꼽은 비율은 8%에 그쳤습니다. 기업 구매자들은 토큰 단가보다 통합 비용과 전체 운영비를 더 중요하게 보고 있다는 의미입니다.

이 모순은 한국 기업에도 익숙한 장면입니다. 클라우드, 협업 도구, 보안 솔루션을 도입할 때도 초기에는 대형 플랫폼의 번들 기능을 쓰다가, 운영 복잡도가 커지면 전용 솔루션과 내부 governance가 필요해졌습니다. AI Agent에서도 같은 흐름이 반복될 가능성이 큽니다. 다만 차이는 속도입니다. Agent는 기존 SaaS보다 훨씬 빠르게 API, 문서, 업무 시스템을 연결합니다. 그래서 “나중에 보안팀이 정리하자”는 접근은 공유 key, 과도한 권한, 격리 부재, 비용 추적 불능이라는 기술 부채를 빠르게 쌓을 수 있습니다.

4. 한국 개발자·기업에게 주는 시사점

① Agent 도입 기준을 “데모 성공”에서 “권한 설계 통과”로 바꿔야 합니다

한국 기업이 AI Agent를 도입할 때 가장 먼저 점검해야 할 항목은 모델 벤치마크보다 identity와 permission입니다. VentureBeat 조사에서 모든 Agent에 scoped managed identity를 부여한 기업이 32%에 그쳤다는 사실은, 많은 조직이 Agent를 독립된 소프트웨어 주체로 다루지 못하고 있음을 보여줍니다. 국내 IT 조직은 Agent별 service account, API key rotation, 최소 권한, 감사 로그, 승인 workflow를 배포 체크리스트에 넣어야 합니다. 특히 금융, 제조, 커머스처럼 내부 시스템 호출이 많은 조직에서는 “사람 계정으로 Agent 실행”이나 “팀 공용 key 사용”을 임시방편으로 허용하면 사고 조사와 책임 추적이 어려워집니다.

② 비용 관측성을 보안 예산과 함께 묶어야 합니다

Agent 보안은 보안팀만의 예산 항목으로 분리하면 실제 운영 문제를 놓칠 수 있습니다. VentureBeat의 compute 조사에서 83%가 GPU utilization 50% 이하이고 44%만 AI compute 비용을 엄격히 추적한다고 답한 점은, Agent 확산이 곧 비용 불투명성으로 이어질 수 있음을 보여줍니다. 국내 기업은 Agent 프로젝트 예산을 모델 API 비용, cloud 비용, 보안 도구 비용으로만 쪼개기보다 “업무 자동화 1건당 실행 비용과 위험 통제 비용”으로 다시 계산해야 합니다. 그래야 PoC에서 production으로 넘어갈 때 어떤 Agent를 중단하고 어떤 Agent를 확장할지 판단할 수 있습니다. 특히 1년 안에 infrastructure provider를 바꾸거나 추가하려는 기업 비율이 높게 나타난 만큼, 특정 provider의 단가표만 보는 조달 방식으로는 실제 운영비를 예측하기 어렵습니다.

우리의 관점: 이번 조사에서 중요한 신호는 기업들이 AI Agent를 싫어해서가 아니라, 오히려 빠르게 쓰고 있기 때문에 격차가 벌어진다는 점입니다. 한국 기업은 올해 Agent PoC를 무작정 늘리기보다, 이미 만든 Agent에 독립 ID와 sandbox, 비용 태깅, 감사 로그를 붙이는 작업을 우선순위로 올려야 합니다. provider-native 도구는 출발점으로 유용하지만, 여러 모델·클라우드·업무 시스템을 섞는 순간 내부 표준 없이는 통제력이 약해집니다. 편집팀은 2026년 하반기 국내 AI 운영의 경쟁력이 “더 똑똑한 Agent”가 아니라 “권한과 비용이 설명 가능한 Agent”에서 갈릴 것으로 봅니다.

※ 위 시사점 섹션은 보도된 사실에 기반한 WhatsUpPick 편집팀의 독자적 분석·전망이며, 특정 제품 도입을 권유하는 것이 아닙니다.

참고 자료

• VentureBeat — The agent security gap — 107개 기업 대상 AI Agent 보안 사고, 자격증명, 격리 현황 조사.
• VentureBeat — The AI compute gap — 기업 AI 인프라 지출, GPU utilization, compute 비용 추적 역량 조사.