AI 에이전트의 긴 여정, 안전벨트는 준비됐나
[바이라인네트워크 기획 시리즈 / AI 에이전트 플랫폼③]
기업의 AI 에이전트 도입은 짧다면 짧고, 길다면 긴 여정이다. 그리고 완주하기 힘든 여정이기도 하다. 출발선을 긋는 것부터 힘들고, 목표 지점을 잡는 것도 힘들다. AI 에이전트 여정에 존재하는 어려움은 무엇이고, 어떻게 여정을 계획해야 하며, 또 어떻게 여정을 진행할 것인가. 많은 질문이 시중을 뒤엎고 있다. 현재 AI 에이전트 프로젝트에서 발견되는 공통의 문제점과 그 해결 방안, 기술적 논쟁을 분석하고, 현재와 앞으로 AI 사업자의 시장 경쟁 양상을 전망해본다.
[1편 AI 에이전트, 긴 여행의 시작…출발선은 어디인가 바로가기]
[2편 기업 AI 에이전트의 성공은 어떻게 이뤄질까 바로가기]
AI 에이전트를 기업 업무에 도입하는 여정은 이제 막 시작됐다. 기업은 AI 에이전트를 만들고 데이터와 업무 시스템을 연결하는 일부터 어려움을 겪고 있다. 그러나 기술과 데이터를 준비하는 것만으로는 충분하지 않다. 출발 단계에서부터 함께 설계해야 할 것이 있다. 바로 ‘보안’이다.
기업이 AI의 편리함과 생산성에 주목하는 사이, 그 이면에서는 AI의 판단과 행동을 어디까지 통제할 수 있는지에 관한 문제가 커지고 있다. AI 에이전트가 사람을 대신해 업무를 수행하고 자율적으로 행동하는 범위가 넓어질수록 보안의 중요성은 점점 커진다.
AI 에이전트가 통제를 벗어났을 때 어떤 문제가 발생하는지는 최근 글로벌 AI 개발사들의 사례로 확인할 수 있다. 지난 7월 오픈AI는 내부 사이버보안 평가 과정에서 AI 모델이 격리된 시험 환경의 통제를 우회하고 외부 시스템에 침투한 사고를 공개했다. AI 모델은 주어진 보안 평가 과제를 해결하는 과정에서 인프라의 취약점을 찾아 인터넷에 접속했고, 오픈AI 내부 연구 인프라와 허깅페이스의 실제 시스템까지 침해했다.
앤트로픽에서도 비슷한 문제가 발생했다. 앤트로픽은 지난 7월 자사 AI 모델 클로드가 보안 평가 과정에서 외부 기관 3곳의 실제 시스템에 무단 접근한 사례를 공개했다. 시험 환경에 인터넷 접근이 허용된 설정 오류가 있었고, AI는 실제 시스템을 가상 시험 환경의 일부로 잘못 판단해 공격을 수행했다. 앤트로픽은 이후 9월 별도의 무단 접근 사례 1건을 추가로 확인했다.
두 회사의 사고는 일반 이용자에게 제공하는 AI 서비스가 아니라 일부 보안 장치를 비활성화한 시험 과정에서 발생했다. 사고의 원인과 경위에도 차이가 있다. 하지만 AI가 주어진 목표를 수행하는 과정에서 사람이 의도하지 않은 행동까지 감행할 수 있다는 점을 분명히 보여줬다.
일시 : 2026년 11월 19일 오후1시 ~ 오후 5시
장소 : 서울시 서초구 강남대로 499, 동일빌딩 3층 스페이스쉐어 주피터홀
◈ [Elastic 웨비나] AI 시대의 Observability 전략: 데이터 가시성과 비용 효율을 함께 확보하는 방법
일시 : 11월 11일 (수) 14:00 ~ 15:30
장소 : 온라인(bylineplus.com)
이는 기업이 AI 에이전트를 업무에 도입할 때도 고려해야 할 문제다. 기존 생성형 AI가 주로 사람의 질문에 답변하고 콘텐츠를 생성했다면, AI 에이전트는 목표를 달성하기 위해 작업을 계획하고 도구를 선택한다. 기업의 데이터베이스(DB)에 접근하거나 다른 에이전트에 업무를 맡기고, 외부 시스템을 직접 조작할 수도 있다.
특히 여러 AI 에이전트가 협업하는 오케스트레이션 환경에서는 통제해야 할 대상도 늘어난다. 하나의 에이전트에 부여한 권한과 판단이 다른 에이전트의 행동으로 이어질 수 있기 때문이다.
기업은 AI 에이전트를 실제 업무에 적용하기 위해 데이터와 시스템을 정비하고 운영 플랫폼을 구축해야 한다. 이 과정에서 보안과 거버넌스 역시 처음부터 설계해야 한다. AI 에이전트를 만든 뒤 보안 솔루션을 추가하는 방식만으로는 복잡한 업무 수행 과정에서 발생하는 위험을 모두 통제하기 어렵다.
그렇다면 AI 에이전트 오케스트레이션을 할 때 무엇을 보호하고, 어디에서 통제해야 할까.
모델부터 업무 시스템까지, 보안도 여러 겹으로
AI 에이전트 오케스트레이션의 보안은 특정한 제품이나 기술 하나로는 해결하기 어렵다. AI 에이전트는 하나의 업무를 수행하면서 기업 데이터에 접근하고 다른 에이전트와 정보를 주고받는다. 외부 도구를 이용해 실제 명령을 실행하기도 한다. 그만큼 보안 위협이 발생할 수 있는 지점도 다양하다.
따라서 보안도 여러 영역에 걸쳐 적용해야 한다는 게 주요 보안 기업들의 공통된 진단이다. ▲AI 모델 자체의 안전성 검증부터 ▲프롬프트의 입력·출력 검사 ▲에이전트의 신원과 데이터 접근권한 관리 ▲네트워크와 외부 도구 연결 통제 ▲실제 행동에 대한 감시와 차단까지 필요하다. 동시에 각각의 보안장치가 기업의 정책에 따라 유기적으로 작동하도록 설계하는 것도 중요하다.
우선 AI 모델 자체의 안전성을 검증하는 작업이 필요하다. 모델이 악성 지시나 조작된 정보에 얼마나 취약한지, 허용되지 않은 행동을 수행할 가능성이 있는지 사전에 시험하는 것이다. 공격자의 관점에서 AI를 시험하는 ‘레드티밍’이 여기에 해당한다.
AI 모델을 실제 서비스에 적용한 뒤에는 입력과 출력 과정의 안전장치가 필요하다. 이용자가 입력한 프롬프트와 첨부파일에 개인정보나 기업 기밀이 포함돼 있는지 확인해야 한다. AI가 생성한 답변에도 민감정보가 노출되지 않도록 검사해야 한다. 이러한 입력·출력 검사는 AI가 정해진 보안 정책을 벗어나지 않도록 하는 ‘가드레일(Guardrail)’의 한 형태다.
가드레일은 이용자의 PC와 AI 서비스가 연결되는 구간이나 AI 게이트웨이 등에서 적용할 수 있다. AI 게이트웨이는 기업의 AI 이용 요청을 모아 보안 정책과 접근 기준을 적용하는 통로다.
그러나 AI 에이전트는 질문과 답변만 주고받지 않는다. 주어진 목표를 수행하기 위해 외부 데이터를 검색하고, 애플리케이션 프로그래밍 인터페이스(API)를 통해 업무 시스템을 호출한다. 특히 모델 컨텍스트 프로토콜(MCP)을 통해 AI가 기업 시스템과 외부 도구를 이용하면서 연결 과정의 보안도 중요해지고 있다.
따라서 에이전트가 어떤 도구를 사용할 수 있는지 관리하고 허용되지 않은 네트워크 연결과 API 호출을 제한해야 한다. 실제 명령이 실행되기 전에도 위험성을 확인하는 장치가 필요하다.
안랩은 AI 에이전트가 등장하면서 기업 보안의 보호 범위가 달라지고 있다고 진단했다. 이승경 안랩 인공지능개발실장은 “보안의 범위도 부적절한 입력이나 출력의 탐지·차단을 넘어, AI 에이전트가 목표를 달성하기 위해 수행하는 전체 업무 과정의 안전성을 확보하는 방향으로 확대되어야 한다”고 설명했다.
기존 보안체계에서도 인증과 접근통제, 데이터 보호, 네트워크 보안은 서로 다른 역할을 맡는다. AI 에이전트 환경 역시 이들 기술을 없애고 새로운 기술 하나로 대체하는 것이 아니다. 기존 보안체계를 기반으로 AI 모델의 판단과 자율적인 행동을 보호할 통제 기능을 추가해야 한다.
국내 AI 보안기업 에임인텔리전스도 AI 에이전트 보안이 기존 보안과 완전히 다른 원칙을 요구하는 것은 아니라고 봤다. 이한울 에임인텔리전스 부문장(보안 기술 총괄)은 “기존 기업 보안에서 활용해 온 최소 권한과 제로트러스트 등의 원칙이 AI 에이전트에도 적용된다”고 설명했다. 그는 “에이전트는 사람이 수행하던 일을 훨씬 빠르게 처리하고 여러 작업을 동시에 실행할 수 있어 관리가 더 복잡해진다”고 짚었다.
결국 기업은 모델 검증부터 데이터 접근, 사용자와 AI 사이의 정보 입·출력, 네트워크와 외부 도구 연결, 실제 업무 실행에 이르기까지 각 단계에 맞는 보안체계를 갖춰야 한다.
문제는 이러한 보안장치를 어디에 적용해야 하는지부터 확인해야 한다는 점이다. 기업 내부에서 어떤 AI 에이전트가 사용되고 있으며 어떤 시스템과 연결돼 있는지 알아야 보안 정책도 적용할 수 있다.
어떤 AI가 일하고 있는지 알아야
기업은 일반적으로 업무용 PC와 서버, 소프트웨어 등 정보기술(IT) 자산의 사용 현황을 관리한다. 어떤 시스템이 운영되고 있으며 누가 사용하는지 파악해야 보안 정책을 적용하고 취약점도 점검할 수 있기 때문이다.
AI 에이전트도 마찬가지다. 그러나 AI는 직원이 외부 서비스를 개인적으로 이용하거나 업무에 필요한 에이전트를 직접 개발하는 경우도 있어 기존 IT 자산보다 사용 현황을 파악하기 어려울 수 있다.
보안 담당자의 승인 없이 AI 서비스와 도구를 사용하는 ‘섀도우 AI(Shadow AI)’가 대표적이다. 직원이 개인 계정으로 외부 AI 서비스를 사용하거나 직접 만든 에이전트를 업무에 활용하면 보안 담당자는 해당 에이전트의 존재 자체를 모를 수 있다. 에이전트가 어떤 기업 데이터에 접근하고 있는지, 어떤 MCP 서버나 외부 도구와 연결돼 있는지도 파악하기 어렵다.
관리하지 못하는 AI 서비스와 에이전트가 늘어날수록 보안의 사각지대도 커진다. 무엇을 사용하고 있는지 모르기 때문에 접근권한을 제한하거나 보안 정책을 적용하기조차 어려운 것이다.
에임인텔리전스는 최근 만난 기업들이 공통적으로 겪는 문제로 섀도우 AI를 꼽았다. 이한울 부문장은 “AI들의 정책을 적용하기 전에 우리 회사 안에 어떤 AI가 있는지부터 확인을 해야 되는데 그것부터가 미비한 게 가장 큰 문제”라고 설명했다.
실제로 기업 고객들은 어떤 AI 에이전트가 사용되고 있는지 찾아내고, 각 에이전트가 어떤 시스템과 연결돼 있는지 확인하는 기능부터 요구하고 있다. 이런 이유로 보안업체들은 자산 식별을 AI 에이전트 보안의 출발점으로 꼽는다. 에이전트가 사용하는 모델과 외부 도구, 메모리, MCP 연결 관계 등을 파악해야 이후의 보안 정책을 적용할 수 있기 때문이다.
안랩은 기업 내부의 AI 사용 현황을 파악하는 관리체계가 우선 필요하다고 강조한다. 이승경 실장은 “기업이 어떤 AI 서비스와 에이전트를 사용하고 있으며, 각각 어떤 업무에 활용하고 있는지 확인해야 한다”며 “사용 목적과 담당 조직, 연결된 데이터와 업무 시스템, 부여된 권한 등을 파악해야 업무별 위험과 영향도를 평가할 수 있다”고 했다.
AI 자산을 식별하는 작업은 최초 도입 시점에만 필요한 것은 아니다. 새로운 에이전트가 추가되거나 기존 에이전트에 외부 도구가 연결되면 관리 대상도 달라진다. 사용하지 않는 에이전트가 남아 있거나 담당자가 바뀌었는데도 기존 접근권한이 유지되는 문제도 점검해야 한다.
결국 AI 에이전트 역시 기업이 관리해야 할 새로운 IT 자산인 셈이다. 어떤 에이전트가 있는지 파악했다면 다음은 에이전트가 무슨 일을 수행하고 어디까지 접근할 수 있는지를 관리해야 한다. 이때부터 각 에이전트의 신원과 권한을 관리하는 문제가 본격적으로 등장한다.
어떤 에이전트에게 어디까지 ‘권한’을 줄 것인가
기업은 일반적으로 직원에게 계정을 발급하고 담당 업무에 필요한 시스템 접근권한을 부여한다. 인사 담당자는 인사 시스템에 접근할 수 있지만 재무 시스템의 모든 자료를 조회하거나 변경할 권한까지 갖지는 않는다. AI 에이전트도 마찬가지다. 에이전트마다 신원을 구분하고 담당 업무에 필요한 최소한의 권한을 부여해야 한다는 원칙은 같다.
문제는 AI 에이전트가 사람을 대신해 업무를 수행하거나 다른 에이전트에 작업을 위임하는 과정에서 발생한다. 상위 에이전트가 여러 하위 에이전트에 일을 나눠준다고 해서 자신의 모든 권한과 인증정보를 넘겨줘서는 안 된다. 각 에이전트가 맡은 업무에 필요한 권한만 사용하도록 해야 한다.
이한울 부문장은 “상위 에이전트가 하위 에이전트랑 당연히 같은 권한을 가져서도 안 되고 같은 인증 체계를 가지고 있어서도 안 된다”고 강조했다.
안랩도 에이전트의 신원·권한 관리와 전체 업무 수행 과정의 추적·통제를 핵심적인 보안 과제로 꼽았다. AI 에이전트가 정상적인 계정과 허용된 도구를 사용하더라도 잘못된 판단이나 외부의 악성 지시에 따라 의도하지 않은 작업을 수행할 수 있다는 설명이다.
이승경 안랩 실장은 “개별 접근이나 도구 실행이 허용된 범위 안에서 이루어지더라도, 일련의 업무 수행 과정에서는 보안 문제가 발생할 수 있다”고 지적했다.
예를 들어 고객정보를 조회할 권한이 있는 에이전트가 업무와 관계없는 고객정보를 대량으로 수집하거나 외부로 전송할 수 있다. 데이터를 조회할 권한이 있다고 해서 모든 업무에서 해당 정보를 사용하도록 허용할 수는 없다는 의미다. 따라서 데이터 조회와 수정·삭제, 외부 전송 권한을 구분해야 한다. 최초 권한을 부여하는 것뿐 아니라 실제 데이터에 접근하거나 도구를 실행하는 시점에도 허용된 작업인지 확인해야 한다.
권한 관리에서 중요한 게 또 하나 있다. 바로 에이전트가 접근하는 데이터다. 데이터에도 기존의 접근권한과 보호 정책이 유지돼야 한다. 여기서 중요한 것이 ‘데이터 거버넌스’다. 데이터 거버넌스는 기업이 보유한 데이터의 접근권한과 변경 이력, 이용 기준 등을 일관되게 관리하는 체계다.
고동현 파수AI 상무는 “기업이 AI 에이전트를 활용하기 위해 암호화된 문서를 풀어 별도의 AI 플랫폼에 넣는 과정에서 기존 보안 정책이 다 무너질 수 있다”고 지적했다. 그는 “이 데이터가 갖고 있는 권한의 속성 자체가 무너지기 시작하는 것”이라며 “AI 환경에서도 기존 데이터의 접근권한을 유지해야 한다”고 강조했다.
만약 마케팅 부서의 AI 에이전트가 보고서를 작성하기 위해 재무 부서의 매출 자료를 요청한다고 가정해보자. 이 경우 마케팅 에이전트가 재무 시스템 전체에 직접 접근하도록 허용하는 대신 재무 에이전트에 필요한 자료만 요청하도록 해야 한다. 요청자의 신원과 권한을 확인하고 허용된 정보만 전달하는 방식이다.
고동현 상무는 “데이터를 제공하는 쪽에서 원래의 접근권한을 확인하고 필요한 정보만 넘겨주는 구조가 적절하다”며 “에이전트 플랫폼마다 데이터 권한을 새롭게 설정하면 기존 기업의 보안 정책과 맞지 않을 수 있다”고 설명했다.
개인정보 보호에도 역시 같은 원칙을 적용해야 한다. 에이전트가 고객정보에 접근할 수 있더라도 다른 에이전트에 해당 정보를 모두 전달할 필요는 없다. 업무 목적에 필요한 정보만 사용하고 개인정보를 가리거나 외부 전송을 제한해야 한다.
AI 에이전트가 기존 문서를 요약하거나 여러 데이터를 결합해 새로운 자료를 만들었을 때도 보호가 필요하다. 원본 문서만 보호하고 AI가 생성한 결과물의 접근권한을 관리하지 않는다면 민감정보가 다른 경로로 노출될 수 있다. 이처럼 기업은 누가 AI에 업무를 지시했는지, 해당 에이전트가 어떤 권한을 갖고 있는지, 그 권한으로 어떤 데이터를 사용할 수 있는지까지 연결해 관리해야 한다.
그러나 권한을 적절하게 부여했다고 해서 에이전트가 모든 업무를 안전하게 수행한다고 보장할 수는 없다. AI는 허용된 도구와 데이터를 사용하면서도 업무 목적에서 벗어난 행동을 할 수 있다. 이에 실제 에이전트의 행동을 기록으로 점검하고 통제하는 보안이 필요하다.
무슨 일을 하는지 알아야 통제할 수 있다
AI 에이전트는 주어진 목표를 달성하기 위해 스스로 작업 순서를 바꾸거나 새로운 도구를 선택한다. 이 과정에서 어떤 행동을 할지 사람이 모두 예측하는 것은 불가능하다.
외부 문서나 웹페이지에 숨겨진 악성 지시를 정상 명령으로 받아들이는 ‘프롬프트 인젝션’ 공격도 위험 요소다. 악성 지시가 다른 에이전트로 전달되거나 외부 도구 실행으로 이어지면 정보 유출이나 시스템 오작동 등 실제 피해가 발생할 수 있다.
이 때문에 AI 에이전트 보안에서는 업무가 실행되는 순간의 통제가 중요하다. 에이전트가 정해진 규칙을 벗어나지 않도록 제한하는 가드레일도 입력과 출력 검사에서 실제 행동을 검증하는 방향으로 확대되고 있다.
실제 행동을 통제하려면 AI 에이전트가 어떤 과정을 거쳐 해당 작업을 수행했는지 확인할 수 있어야 한다. 여기서 중요한 기술이 관찰가능성을 뜻하는 ‘옵저버빌리티(Observability)’다. AI 에이전트가 어떤 입력을 받았고 어떤 데이터를 검색했으며 어떤 도구를 호출했는지 전체 업무 과정을 연결해 기록하는 것이다.
단순히 실행한 명령만 기록해서는 부족하다. 예를 들어 한 에이전트가 문서를 검색하고 다른 에이전트에 분석을 맡긴 뒤 외부 애플리케이션 프로그래밍 인터페이스(API)를 호출했다고 가정해보자. 각각의 작업이 허용된 행동인지 확인하는 동시에 처음 어떤 업무를 지시받았고 왜 외부 API까지 호출했는지 파악해야 한다.
이처럼 전체 작업 흐름을 파악하면 사전에 정한 규칙으로 차단하는 정적인 보안과 업무 맥락에 따라 위험을 판단하는 동적인 보안을 함께 적용할 수 있다. 에임인텔리전스는 에이전트의 현재 작업뿐 아니라 이전 행동과 접근한 자산까지 고려해야 위험한 행동을 판단할 수 있다고 조언한다.
안랩 역시 개별 행동뿐 아니라 전체 업무 수행 과정의 통제가 필요하다고 강조했다. 안랩은 자체 AI 기반 모의침투 기술을 개발하는 과정에서 에이전트가 같은 목표를 수행하면서도 서로 다른 공격 경로와 도구를 선택하는 특성을 발견했다. 모든 행동을 미리 예측하기 어려운 만큼, 허용된 공격 대상과 실행 범위를 제한하고 위험한 행동을 중단할 수 있는 장치가 필요하다는 설명이다.
사전 보안 검증과 실제 운영 단계의 통제도 연결돼야 한다. 기업들은 레드티밍으로 확인한 공격 유형과 취약점을 가드레일 등 방어 기술에 반영하고 있다. 시험에서 확인한 공격 방식이 실제 업무 환경에서도 차단되도록 하기 위해서다.
다만 기술적 통제만으로 모든 상황에 대응하기는 어렵다. 금전 거래나 중요정보 삭제처럼 업무에 미치는 영향이 큰 작업에는 사람의 판단과 승인이 필요할 수 있다. 그렇다고 모든 행동을 사람이 일일이 승인하도록 하는 것이 해결책은 아니다. 수많은 에이전트가 빠르게 업무를 수행하면서 승인 요청을 보내면 사람이 모든 내용을 검토하는데 한계가 있기 때문이다.
이한울 에임인텔리전스 부문장은 “너무 많은 의사결정이 필요한 경우, 오히려 사람이 취약점이 되기도 한다”고 짚었다. 사람의 최종 승인이 필요하더라도 어떤 작업을 언제 누구에게 확인받을 것인지 정하지 않으면 형식적인 절차로 전락할 수 있다는 것이다.
따라서 기업은 업무의 중요도와 데이터의 민감도, 잘못된 실행 결과의 복구 가능성에 따라 에이전트의 자율 실행 범위를 구분해야 한다. 일반적인 정보 조회와 분석에는 비교적 높은 자율성을 부여할 수 있지만 금전 거래와 중요정보 삭제, 핵심 시스템 설정 변경에는 별도의 제한과 승인 절차가 필요하다.
결국 중요한 것은 AI 에이전트가 어디까지 스스로 판단하고 행동할 수 있는지 기업이 정책으로 정하는 것이다. 실제 업무 과정을 추적하고 위험한 행동을 중단할 수 있어야 사람이 모든 작업을 일일이 확인하지 않고도 업무를 맡길 수 있다.
보안 내재화는 아직 출발선, 하지만 빠져선 안 돼
AI 에이전트를 안전하게 운영하려면 모델과 데이터, 접근권한, 실제 실행 과정에 걸친 보안체계를 갖춰야 한다. 그러나 기업 현장에서는 AI 에이전트 도입 자체가 아직 초기 단계에 머물러 있다. 보안 역시 전사적인 관리체계를 갖추기보다 당장 필요한 기능을 적용하는 수준에서 출발하는 경우가 많다.
물론 기업 입장에서 AI를 도입할 때 모델의 성능에 먼저 주목하는 것은 자연스럽다다. AI가 얼마나 정확하게 답변하고 어떤 업무를 자동화할 수 있는지부터 확인해야 하기 때문이다. 하지만 그러다 보면 에이전트에 어떤 권한을 부여하고 실제 행동을 어디까지 허용할 것인지는 뒤늦게 검토할 수 있다.
이러한 상황은 기업들의 AI 보안 수요에서도 나타난다. 안랩에 따르면, 최근 고객사들의 요구는 생성형 AI 서비스의 안전한 활용과 데이터 보호에 상대적으로 집중돼 있다. 민감정보 유출 방지와 악성 프롬프트 탐지, AI 서비스 이용 현황 파악 등이 대표적이다. 여러 에이전트의 업무 수행 과정을 통합적으로 관리하는 단계까지 나아간 기업은 아직 많지 않다는 설명이다.
에임인텔리전스도 비슷한 흐름이라는 분석이다. 최근 만난 고객들이 가장 먼저 요구하는 기능이 기업 내부에서 사용 중인 AI와 에이전트를 식별하는 섀도우AI 탐지 기능이라는 설명이다.
데이터와 접근권한을 정비하는 과제도 남아 있다. 파수AI는 기업의 데이터가 여러 시스템에 흩어져 있고 관리 방식도 제각각이어서 기존 데이터의 보안 정책을 AI 환경에서도 일관되게 유지하는 일이 중요하다고 짚었다.
즉, 기업들은 AI 에이전트의 자율적인 행동을 통제하기에 앞서 사용 현황을 파악하고 데이터와 권한을 정비하는 단계부터 해결해야 하는 상황이다.
그렇다고 보안을 AI 에이전트 도입 이후의 과제로 미뤄둘 수는 없다. 에이전트는 도입 초기부터 기업의 데이터와 업무 시스템에 접근한다. 이후 다른 에이전트와 협업하고 외부 도구를 사용하기 시작하면 관리해야 할 권한과 데이터 흐름도 복잡해진다.
따라서 기업은 AI 에이전트에 어떤 업무를 맡길지 정하는 단계부터 접근할 수 있는 데이터와 시스템, 자율적으로 실행할 수 있는 작업의 범위를 함께 정의해야 한다. 예상하지 못한 행동이 발생했을 때 업무를 중단하고 원인을 추적하는 절차도 필요하다. 이는 앞선 2편에서 짚은 설계 단계의 거버넌스 문제와도 연결된다. AI 에이전트 플랫폼을 구축할 때 데이터와 시스템을 연결하는 것뿐 아니라 각 에이전트가 허용된 범위에서 업무를 수행하도록 관리할 기준을 마련해야 한다는 의미다.
AI 에이전트의 개발과 운영을 위한 플랫폼이 기업의 여러 업무를 연결하는 기반이라면, 보안과 거버넌스는 그 업무가 안전하게 이뤄지도록 관리하는 체계다. AI 에이전트를 얼마나 빨리 만들고 연결하느냐도 중요하지만, 실제로 무슨 일을 하는지 확인하고 통제할 수 있어야 중요한 업무도 맡길 수 있다. AI 에이전트 도입이라는 긴 여정에서 보안은 마지막에 점검할 과제가 아니다. 출발선부터 갖춰야 할 기본 조건이다.
다음 편에서 계속…
글. 바이라인네트워크
<곽중희 기자>god8889@byline.network
◈ [웨비나] AI 클론을 만들어 주 100시간 노동에서 해방됐습니다
일시 : 2026년 11월 4일 (수) 14:00 ~ 15:00
장소 : 온라인(bylineplus.com)


