AI 에이전트가 기업 운영 방식을 재편하고 있습니다. 에이전트는 데이터를 분석하고, API를 호출하며, 워크플로우를 트리거하고, 사용자 대신 행동합니다. 종종 사람의 개입 없이도 말이죠. IDC는 2028년까지 13억 개의 AI 에이전트가 실제 운영 환경에 투입될 것으로 전망하고 있으며, Capgemini의 연구에 따르면 기업 5곳 중 4곳이 향후 3년 내에 에이전트를 통합할 계획이라고 합니다.
개발 경쟁은 이미 시작되었습니다. 하지만 대부분의 조직이 아직 답을 내놓지 못한 더 어려운 질문이 있습니다. 바로 **"어떻게 AI 에이전트를 대규모로 안전하게 운영할 것인가?"**입니다.
데모 수준의 에이전트를 배포하는 것은 기본입니다. 하지만 동일한 에이전트를 적절한 ID, 액세스 제어, 거버넌스 및 런타임 보호 기능을 갖춘 '프로덕션급'으로 만드는 것은 완전히 다른 차원의 엔지니어링 및 운영 과제입니다.
왜 에이전트 기반 AI가 보안 방정식의 판도를 바꾸는가
전통적인 소프트웨어는 결정론적 로직을 실행합니다. 반면 AI 에이전트는 추론하고 계획하며, 명시적으로 프로그래밍되지 않은 시스템을 넘나들며 동적으로 행동합니다. 에이전트가 기업용 API 및 데이터와 연결되는 순간, 단순한 챗봇을 넘어 '디지털 직원'으로서의 기능을 수행하게 됩니다.
이러한 변화는 보안에 직접적인 영향을 미칩니다:
- 에이전트는 자율적으로 비즈니스 프로세스를 트리거하고 민감한 데이터에 접근할 수 있습니다.
- 새로운 도구와 MCP(Model Context Protocol) 서버가 연결됨에 따라 에이전트의 기능이 계속 확장됩니다.
- 에이전트는 비결정적으로 행동하므로 기존의 정적인 정책 제어만으로는 불충분합니다.
- 침해되거나 잘못 설정된 에이전트는 광범위한 피해(Blast Radius)를 입힐 수 있습니다.
대부분의 조직은 거버넌스 인프라를 제대로 갖추지 못한 채 이러한 환경에 에이전트를 배포하고 있습니다. 그 결과, 에이전트가 무분별하게 늘어나고 책임 소재가 불분명해지며 관리되지 않는 리스크가 증가하고 있습니다. 이는 보안 및 컴플라이언스 팀이 가장 우려하는 상황입니다.
에이전트 보안 운영을 위한 3대 핵심 프레임워크
기업 규모에서 AI 에이전트를 보호하려면 구조화된 접근 방식이 필요합니다. 다음의 3대 프레임워크는 실질적인 토대를 제공합니다: 관리(Manage), 거버넌스(Govern), 보호(Protect).
제1요소: 관리(Manage) — 에이전트 레지스트리 구축 및 ID 적용
첫 번째 요소는 '가시성'에 초점을 맞춥니다. 볼 수 없는 것은 보안을 유지할 수 없고, 식별할 수 없는 것은 제어할 수 없습니다.
환경 내의 모든 에이전트는 고유하고 관리되는 ID(IDentity)를 가져야 합니다. 이는 인간 계정, 서비스 주체(Service Principals), 워크로드 ID와 구별되는 '최우선 ID 유형'이어야 합니다. ID가 없다면 에이전트는 추적, 감사, 제어가 불가능한 익명의 자동화 도구에 불과합니다.
에이전트 ID가 구축되면 조직은 다음과 같은 이점을 얻습니다:
- 추적성(Traceability): 각 에이전트가 언제, 어떤 맥락에서 무엇에 접근했는지에 대한 전체 기록.
- 감사 가능성(Auditability): 보안 및 컴플라이언스 팀이 요구하는 깨끗한 감사 추적(Audit Trail).
- 세분화된 제어(Granular Control): 정책에 따라 액세스를 제한, 차단 또는 취소할 수 있는 능력.
운영상의 목표는 에이전트 레지스트리를 구축하는 것입니다. 이는 마이크로소프트 플랫폼 이외의 환경에서 구축된 에이전트를 포함하여 조직 전체의 모든 에이전트를 중앙에서 파악할 수 있는 플릿(Fleet) 뷰를 의미합니다. 운영자는 이 레지스트리에서 직접 에이전트 메타데이터를 검사하고, 소유권을 확인하며, 구성을 검토하고, 에이전트를 차단할 수 있어야 합니다.
이러한 플릿 관리 기능이야말로 통제되지 않는 에이전트 확산과 기업급 배포를 구분 짓는 핵심 요소입니다.
제2요소: 거버넌스(Govern) — 에이전트 수명 주기 관리 자동화
두 번째 요소는 에이전트 수가 수백, 수천 개로 늘어날 때 직면하는 운영상의 현실을 다룹니다. 수동 거버넌스는 확장성이 없습니다.
수명 주기 거버넌스를 대규모로 작동시키기 위한 세 가지 기본 원칙은 다음과 같습니다.
- 모든 에이전트에 스폰서(Sponsor) 지정: 각 에이전트에는 생성부터 폐기까지의 활동 및 액세스 결정을 책임질 지정된 소유자(개인 또는 팀)가 있어야 합니다. 책임지는 사람이 없는 '고아 에이전트'는 위험성이 매우 높습니다. 스폰서십은 책임 소재를 명확히 하여 사고 발생 시 대응을 원활하게 합니다.
- 수명 주기 정책 자동화: 에이전트는 관리 주체가 바뀌거나 팀 간에 이동하며, 결국 은퇴하게 됩니다. 생성 시 부여된 권한이 6개월 후에는 부적절할 수 있습니다. 생성, 인계, 액세스 검토, 폐기를 포함하는 수명 주기 정책은 대규모 환경에서 효과를 유지하기 위해 자동화되어야 합니다. 목표는 일상적인 인간의 개입을 제거하면서도 모든 행동이 기록되고 감사 가능하도록 만드는 것입니다.
- 적시성(JIT) 및 기간 한정 액세스 강제: 에이전트는 영구적인 권한을 가져서는 안 됩니다. 액세스는 의도적으로 범위를 지정하고, 시간을 제한하며, 더 이상 필요하지 않을 때 제거되어야 합니다. 이는 에이전트가 원래 목적을 넘어 점진적으로 리소스에 대한 액세스 권한을 쌓아가는 '권한 누적' 리스크를 직접적으로 해결합니다.
전체 수명 주기 흐름은 생성(스폰서 지정, 액세스 요청 및 승인)부터 활성 운영(주기적 액세스 검토), 폐기(ID 삭제, 액세스 만료)까지 이어집니다. 모든 단계에서 감사 기록이 생성되어야 합니다.
제3요소: 보호(Protect) — 런타임 환경에서의 에이전트 보안
세 번째 요소는 에이전트가 활성화되어 기업 리소스에 접근하는 실제 프로덕션 런타임 보안을 다룹니다. 이곳은 리스크가 가장 동적으로 발생하는 지점이며, 다층 방어(Defense-in-depth) 접근 방식이 필수적입니다.
에이전트는 가치를 제공하기 위해 파일 저장소, API, 캘린더, MCP 서버 및 타사 SaaS 시스템에 접근해야 합니다. 이러한 각 연결점은 프롬프트 인젝션(Prompt Injection), 데이터 유출 또는 악성 콘텐츠 노출의 통로가 될 수 있습니다.
런타임 보호 스택을 구성하는 세 가지 메커니즘은 다음과 같습니다.
- 에이전트용 조건부 액세스 정책: 인간 ID에 사용되는 것과 동일한 조건부 액세스 프레임워크를 에이전트에도 적용하여, ID와 운영 맥락에 기반한 정책을 강제할 수 있습니다. 이를 통해 전체 에이전트 플릿에 대한 광범위한 기본 보호를 설정하고, 영향력이 크거나 민감한 시나리오에는 더 엄격한 제어를 적용할 수 있습니다. 액세스 결정은 일회성 검토가 아니라 지속적이고 자동으로 이루어집니다.
- 위험 신호 탐지 및 자동 대응: 갑작스러운 액세스 급증, 반복적인 리소스 접근 실패, 익숙하지 않은 시스템으로의 접근 시도와 같은 위험한 행동은 자동 대응을 트리거하는 신호가 됩니다. 정책에 따라 수동 개입 없이 에이전트를 차단하고 피해 범위를 제한하며 보안 운영팀에 조사를 알릴 수 있습니다.
- 네트워크 계층 제어: ID 및 액세스 제어만으로는 충분하지 않습니다. 특히 외부 시스템이나 사용자 입력과 상호 작용하는 에이전트의 경우, 콘텐츠 검사, 위협 인텔리전스 기반 URL 필터링, 파일 수준의 네트워크 필터링 등의 추가 보호 계층이 필요합니다. 단일 제어 지점에만 의존해서는 안 됩니다.
에이전트 블루프린트와 ID 계층 구조의 이해
기업 에이전트 거버넌스에서 가장 중요한 아키텍처 개념 중 하나는 '에이전트 블루프린트(Blueprint)'와 '에이전트 ID(Identity)'의 구분입니다.
에이전트 블루프린트는 특정 에이전트 클래스에 대한 보안, 인증 및 거버넌스 특성을 정의하는 재사용 가능하고 테넌트 범위가 지정된 템플릿입니다. 이는 에이전트가 수행할 수 있는 작업, 접근할 수 있는 리소스, 동작을 규제하는 정책 등 운영 경계를 설정합니다.
에이전트 ID는 블루프린트에서 파생된 특정 인스턴스입니다. 하나의 블루프린트에서 여러 개의 ID를 생성할 수 있으며, 각 ID는 템플릿에 정의된 거버넌스 제약 조건을 상속받습니다.
이 부모-자식 모델은 각 역할에 구체적인 이점을 제공합니다:
- 개발자: 구축하는 모든 에이전트에 대해 예측 가능하고 일관된 ID 모델을 가질 수 있습니다.
- IT 및 보안 팀: 개별 인스턴스별 오버헤드 없이 클래스 수준의 감사 추적 및 수명 주기 제어가 가능합니다.
- 최종 사용자 및 고객: 모든 에이전트 인스턴스가 설계 시 설정된 경계 내에서 작동함을 신뢰할 수 있습니다.
인증, 권한 부여, 실행 경계와 같은 거버넌스 의도는 한 번 정의되면 해당 블루프린트에서 파생된 전체 에이전트 제품군에 일관되게 적용됩니다.
MCP 도구 거버넌스: 에이전트 상호 운용성 관리
최신 에이전트는 고립되어 작동하지 않습니다. MCP(Model Context Protocol)와 같은 프로토콜을 통해 외부 도구 및 서비스에 연결되어 SharePoint 문서 검색, 이메일 전송, 회의 예약, 다른 에이전트와의 협업 등의 작업을 수행합니다.
이러한 연결성은 강력합니다. 단 한 번의 자연어 명령으로 에이전트는 여러 MCP 서버를 동시에 호출하여 파일을 검색하고, 공유 링크를 생성하고, 이메일로 보내고, 캘린더 이벤트를 만들 수 있습니다.
하지만 이 강력함은 곧 거버넌스의 관리 대상이 됩니다. 사용 가능한 모든 MCP 도구가 모든 에이전트에 적절한 것은 아니며, 모든 도구가 검토 없이 프로덕션 환경에서 사용하기에 안전한 것도 아닙니다.
올바른 접근 방식은 도구 액세스를 데이터 액세스처럼 취급하는 것입니다. 즉, 의도적이고, 검토되었으며, 에이전트의 ID와 연결되어야 합니다. 특정 MCP 서버에 대한 액세스는 공식적으로 요청되고 IT 또는 보안 팀의 승인을 받아야 하며, 개발자가 빌드 타임에 임의로 결정하는 것이 아니라 에이전트 온보딩 프로세스의 일부로 문서화되어야 합니다.
프로덕션용 에이전트 보안을 위한 5가지 실천 수칙
위의 프레임워크는 현재 에이전트를 구축하고 운영하는 팀을 위한 구체적인 실천 수칙으로 요약됩니다.
- 처음부터 ID를 내장하십시오 (Build identity in, not on). 기존 에이전트 플릿에 거버넌스를 나중에 덧씌우는 것은 빌드 프로세스 초기부터 ID를 통합하는 것보다 훨씬 어렵습니다. 모든 새로운 에이전트는 출시 전 ID, 스폰서, 정의된 액세스 범위를 갖추어야 합니다.
- 개별 에이전트가 아닌 전체 플릿을 설계하십시오 (Design for the fleet, not the agent). 하나의 에이전트를 위해 수립한 관행과 템플릿은 수백 개로 확장 가능해야 합니다. 재사용 가능한 블루프린트, 자동화된 수명 주기 정책, 표준화된 온보딩 패턴은 에이전트 수가 늘어날수록 가치가 커지는 투자입니다.
- 배포 전 위협 모델링을 수행하십시오 (Threat-model before you deploy). 각 프로덕션 에이전트에 대해 어떤 데이터에 접근할 수 있는지, 어떤 행동을 할 수 있는지, 악의적인 프롬프트가 입력되면 어떤 일이 벌어지는지, 침해 시 피해 범위(Blast Radius)는 어느 정도인지 검토하십시오. 위협 모델링은 기능 중심 개발에서 놓치기 쉬운 리스크를 찾아냅니다.
- 기능과 함께 거버넌스도 자동화하십시오 (Automate governance alongside capability). AI 개발의 본능은 에이전트가 하는 일을 자동화하는 것입니다. 동일한 본능을 에이전트 거버넌스 방식에도 적용하십시오. 수명 주기 정책, 액세스 검토, 위험 신호 대응, 감사 로그 생성 등 모든 과정이 수동 개입 없이 실행되어야 합니다.
- 에이전트에 제로 트러스트를 명시적으로 적용하십시오 (Apply zero trust to agents explicitly). 최소 권한, 지속적인 검증, 침해 가정 원칙은 인간 및 워크로드와 마찬가지로 에이전트에도 동일하게 적용됩니다. 권한이 누적되거나 지속적인 정책 집행 없이 운영되는 에이전트는 진화하는 위협 환경에서 큰 리스크가 됩니다.
Microsoft Marketplace를 통한 거버넌스된 에이전트 배포
이 포스트에서 설명한 거버넌스 아키텍처(Entra 에이전트 ID, 블루프린트, 수명 주기 정책, 제로 트러스트 제어)는 Microsoft Marketplace를 통해 에이전트를 배포하는 소프트웨어 개발사(ISV)에도 동일하게 적용됩니다. 이러한 구조는 타사 에이전트가 이를 구매하는 기업 고객에게 신뢰받고 관리될 수 있는지 여부를 결정하는 척도가 됩니다.
Agent 365가 정식 출시됨에 따라, 기업 고객은 Marketplace에서 구매한 에이전트를 포함하여 Microsoft 365 테넌트 내의 모든 에이전트를 관리할 수 있는 제어 평면을 갖게 되었습니다. 등록된 Entra 에이전트 ID 없이 도착한 소프트웨어 개발사의 에이전트는 고객의 레지스트리에서 '관리되지 않음'으로 표시되며, 사용 승인 전 수동 수정이 필요하게 됩니다. 이는 도입을 지연시키는 마찰 요인이 됩니다.
소프트웨어 개발사의 에이전트가 Agent 365가 활성화된 테넌트에서 기업 IT 및 보안 검토를 통과하려면 첫날부터 다음 세 가지가 갖춰져야 합니다.
- 등록된 Entra 에이전트 ID: 고객이 에이전트에 자체 조건부 액세스 및 수명 주기 정책을 적용할 수 있게 합니다.
- 잘 정의된 에이전트 블루프린트: 고객의 IT 및 보안 팀에 에이전트가 허용된 작업, 접근 리소스, 거버넌스 특성을 알려줍니다.
- 선언되고 범위가 지정된 MCP 도구 액세스: 고객 관리자가 에이전트 가동 전 도구 권한을 검토하고 승인할 수 있게 합니다.
이러한 요소들을 갖추고 출시되는 에이전트는 처음부터 기업 운영을 고려해 구축되었다는 강력한 신뢰 신호를 보냅니다. 이러한 신뢰 신호는 점차 구매 검토를 통과하는 에이전트와 그렇지 못한 에이전트를 가르는 기준이 될 것입니다.
경쟁 우위를 확보하기 위한 보안 전략
안전하고 거버넌스가 갖춰진 에이전트 인프라를 구축하는 조직은 단순히 리스크를 줄이는 데 그치지 않고, 도입 속도를 가속화합니다. 보안 및 운영 팀이 환경 내의 에이전트를 신뢰할 수 있을 때, 배포를 늦추는 내부 마찰이 줄어듭니다. 거버넌스가 가능하고 감사가 쉬운 에이전트 솔루션을 제공하는 파트너와 소프트웨어 기업은 고객 환경에 관리되지 않는 에이전트를 공급하는 경쟁사보다 지속적인 차별화 우위를 확보하게 됩니다.
에이전트 기반 AI 분야에서 승리하는 기업은 단순히 에이전트만 만드는 것이 아닙니다. 그들은 에이전트를 둘러싼 플랫폼, 관행 및 거버넌스 인프라를 함께 구축하고 있습니다. 이것이 바로 기업 고객이 점점 더 요구하는 사항이며, 매력적인 데모와 프로덕션급 솔루션을 구분하는 기준입니다.
ID, 최소 권한, 감사 가능성, 다층 방어라는 원칙은 변하지 않았습니다. 변한 것은 이제 이러한 원칙이 기업 내의 새로운 주체인 AI 에이전트에 적용되어야 한다는 사실입니다.
'소프트웨어 개발사를 위한 보안 시리즈'의 지난 세션 및 향후 세션 보기: Security for SDC Series: Securing the Agentic Era