칼럼 | AI 에이전트가 데이터 삭제하면 책임은 누구에게 있나

지난해 개발 플랫폼 기업 리플릿(Replit)에서는 코드 변경이 제한된 기간 동안 내부 AI 코딩 에이전트가 한 기업의 운영 중인 프로덕션 데이터베이스를 삭제하는 사고가 발생했다. 해당 에이전트는 “이것은 내 치명적인 실패였다”며 “몇 달에 걸친 작업을 몇 초 만에 파괴했다”고 태연하게 인정했다. 이후 롤백을 통해 데이터는 복구됐지만, 에이전트는 해당 삭제가 영구적인 것으로 인식했으며 스스로 작업을 되돌릴 수 있는 기능도 갖추지 못한 상태였다.

CIO 입장에서 이는 단순한 기술적 오류가 아니다. 기업 책임 체계가 완전히 붕괴된 사례다. 이처럼 큰 피해가 발생하면 책임 공방은 대개 도입을 요청한 사업 부서, 쓰기 권한을 부여한 엔지니어, 이를 승인한 보안팀 사이에서 반복된다.

문제는 소프트웨어 자체에 책임을 물을 수 없다는 점이다. 맥킨지에 따르면 기업의 88%가 AI를 도입한 상황이지만, 사고 발생 시 그 책임을 누가 져야 하는지 명확한 기준을 갖춘 조직은 여전히 드물다. 보안 데이터 관리 기업 루브릭 제로 랩스(Rubrik Zero Labs)의 보고서 역시 비슷한 점을 지적한다. IT 및 보안 리더의 86%는 향후 1년 내 AI 에이전트가 조직의 기존 보안 가드레일을 넘어설 것으로 보고 있다.

IT 주도의 에이전트 리스크 관리 필요

AI 에이전트를 핵심 인프라가 아닌 단순 실험으로 취급하는 조직일수록 리스크가 커진다. 이 접근 방식은 기술 부족이 아니라 운영 성숙도의 한계로 인해 확장 단계에서 실패하게 된다. MIT 조사에 따르면 생성형 AI 파일럿 프로젝트의 95%는 측정 가능한 비즈니스 성과를 내지 못했으며, 이는 적절한 관리 체계 없이 기존 프로세스에 억지로 적용된 경우가 많기 때문이다.

현장에서 만난 여러 IT 리더들도 동일한 문제를 지적한다. 데이터 분석이나 고객 서비스에 에이전트를 실험적으로 도입한 뒤 문제가 발생하면, 가장 먼저 부딪히는 장애물은 대응을 누가 주도할지 결정하는 일이다. 이러한 혼란은 에이전트의 본질에 대한 오해에서 비롯된다. 기존 SaaS API가 특정 기능만 수행하도록 설계되고 지속적인 재인증을 요구하는 반면, AI 에이전트는 부분적이거나 완전한 자율성을 갖는다.

특히 MCP(Model Context Protocol)를 활용하면 에이전트는 단일 기능이 아닌 SaaS 플랫폼 전체와 상호작용할 수 있다. 한 번 인증으로 전체 시스템에 접근 권한을 갖게 되는 구조다. 즉, 특정 기능 단위에서 플랫폼 전체 자율성으로 전환되면서 기존 거버넌스 규칙은 더 이상 유효하지 않게 됐다.

공동 책임 프레임워크

필자가 일하고 있는 루브릭은 AI CoE(Center of Excellence)를 중심으로 공동 책임 모델을 운영하고 있다. 이를 위해 AI 전략 전반을 관리하는 역할과 책임 매트릭스를 구축했다. CTO를 비롯해 법무 총괄, CFO 등이 주요 의사결정을 담당하며, CISO와 전략 조직 리더들이 이를 지원한다. 이후 IT, 정보보안, 법무 부문의 아키텍트와 협업 리더들이 실제 학습, 도구 승인, 실행을 맡는다.

이 접근 방식은 세 가지 핵심 축에 기반한다. 클로드와 같은 외부 AI 도구의 안전한 도입과 거버넌스, 내부 AI 역량 구축, 그리고 핵심 제품에 AI를 통합하는 전략이다. CoE 체계 아래에서 기업은 기존 엔터프라이즈 기술과 동일한 원칙을 적용하되, 각 부서의 책임 범위를 명확히 설정한다.

IT는 아키텍처 설계와 배포 표준을 책임진다. 정보보안 조직은 프롬프트 인젝션 위험과 취약점을 지속적으로 점검한다. 법무 부서는 데이터 처리와 자동화 의사결정에 대한 가드레일을 정의한다. 마지막으로 사업 부서는 AI를 활용해 운영 혁신을 추진하는 사용자 역할을 맡는다. CoE는 이러한 구조를 지원하며, 표준을 따르지 않을 경우 조직 간 불일치로 인한 리스크가 발생하지 않도록 관리한다.

실질적인 거버넌스 구축

기업은 빠르게 움직여야 하지만 무모해서는 안 된다. 강력한 거버넌스와 복구 가능성을 전제로 한다면, 에이전트에 실행 권한을 부여하는 결정 자체를 두려워할 필요는 없다. 실제로 조직 내에서 에이전트 도입 필요성이 제기되면, 초기 요청부터 기술·보안 검증을 거쳐 모니터링이 가능한 운영 환경으로 이어지는 명확한 절차를 마련해야 한다.

이 같은 필요성은 내부 AI 도입 과정에서도 확인됐다. 다양한 도구를 도입하는 과정에서 각기 다른 이용 조건과 규제가 얽히면서 관리가 혼란스러워졌고, 통합적인 보안 체계를 마련하기 어려운 상황에 직면했다. 이에 에이전트 클라우드 프레임워크를 도입해 전체 가시성과 대응 체계를 확보하고, 에이전트 수준에서 보안을 자동으로 적용하도록 했다.

예를 들어 루브릭 내부 테스트 환경에서 클로드 코드 활용을 확대하는 과정에서 기존 통제 체계로는 대응하기 어려운 보안 문제가 발견됐다. 이를 해결하기 위해 에이전트 환경에서 외부 코드 저장소나 커뮤니티, 기타 공개 플랫폼으로 데이터가 전송되는 것을 차단하는 정책 경계를 설정했다.

복구 시간, 새로운 핵심 과제로 부상

AI 에이전트로 인한 장애의 운영 리스크도 점점 커지고 있다. 루브릭 제로 랩스 보고서에 따르면, 약 90%에 가까운 리더들이 에이전트 기반 위협 증가로 인해 복구 목표를 달성하는 데 어려움을 겪을 것으로 우려하고 있다. 또한 88%는 시스템 중단 없이 에이전트의 작업을 되돌릴 수 없다고 답했다. 에이전트 장애가 보안이나 데이터 무결성 문제와 결합될 경우, 별도의 프레임워크 없이는 복구 자체가 불가능해질 수 있다.

실제 운영에서는 이상 징후 탐지가 사용자 단계에서 시작되는 경우가 많다. 예를 들어 ‘PTO 에이전트’는 캘린더와 HR 시스템을 연동해 휴가 일정의 일치 여부를 확인하는 역할을 한다. 하지만 이미 승인된 일정임에도 다시 등록을 요청하는 알림이 슬랙으로 전달되는 사례가 발생하기도 한다. 이는 비교적 경미한 ‘환각’ 사례지만, 동시에 대응 프로세스를 점검하는 계기가 된다.

이 경우 문제는 IT 헬프데스크로 전달되고, 자동으로 AI 운영팀과 사업 부서 책임자에게 공유된다. 현재는 이러한 오류를 수동으로 분석하고 수정한 뒤 재배포하는 방식으로 대응하고 있지만, 향후에는 인간 개입을 포함한 자동화된 트리아지 체계를 구축하는 것이 목표다.

AI 에이전트, 혁신에서 운영 단계로

AI 거버넌스를 체계적으로 구축한 조직은 전체 AI 효율성 향상의 약 27%를 이러한 가드레일을 통해 확보하고 있다. 반면 많은 실패 사례는 도입을 서두르는 과정에서 두 가지 핵심 요소를 간과한 데서 비롯된다.

첫째, 에이전트를 ‘독립된 디지털 신원’으로 관리해야 한다. 대부분의 비정상적 행동은 권한 설정 실패에서 발생한다. 에이전트가 최소 권한 원칙에 따라 기업의 인증 시스템에 통합되고, 명확한 감사 추적 체계를 갖추지 못했다면 네트워크에 연결되어서는 안 된다. 에이전트는 직원처럼 관리돼야 한다. 시스템 내에서 담당자가 지정돼야 하며, 필요 시 즉시 권한을 회수할 수 있는 신원 체계를 갖춰야 한다.

둘째, 아키텍처 수준에서 ‘되돌릴 수 있는 구조’를 확보해야 한다. 기존 시스템은 ‘되돌리기’ 기능과 버전 관리에 의존해 왔다. 그러나 AI 에이전트는 실시간 운영 환경에서 작동하기 때문에 이러한 기능이 눈에 보이지 않거나 제한적으로 작동한다. 따라서 파일럿 단계를 넘어가기 전에 반드시 검토해야 할 질문은 명확하다. 해당 에이전트가 비인가 변경을 일으켰을 때, 서비스 중단 없이 이를 정밀하게 되돌릴 수 있는가다. 이를 위해서는 의도 기반, 맥락 중심의 AI 거버넌스 엔진을 통해 지속적인 통제가 이뤄져야 한다.

기업은 안전한 에이전트 운영을 위한 전략을 반드시 마련해야 한다. 도입은 단계적으로 진행하는 것이 바람직하다. 핵심 기능부터 IT 주도의 통제를 적용하고, 경험이 축적되면서 점진적으로 확장해야 한다. 지금 운영 책임 체계를 확립한 조직만이 AI를 안정적으로 확장할 수 있다. 반대로 거버넌스 없이 분산된 도입을 이어가는 기업은 장애가 발생할 때마다 ‘책임은 누구에게 있는가’라는 문제를 반복하게 될 것이다.
dl-ciokorea@foundryco.com