최근 기업에서 AI 에이전트 활용이 늘고 있습니다. 거대 언어 모델(LLM)이나 도메인 특화 소형 언어 모델(SLM) 기반의 챗봇을 넘어 다양한 기능을 수행하는 AI 에이전트를 활용하는 시대가 온 것이죠. 쓰임이 늘면서 자연스럽게 요즘 멀티 AI 에이전트 운영을 위한 아키텍처 설계와 함께 보안 강화 방안에 대한 관심이 커지고 있습니다. 이 중 이번 포스팅에서는 Google Agent Development Kit(ADK), SDP, Model Armor을 활용한 AI 에이전트 보안 강화에 대해 알아보겠습니다. 결론부터 말하자면 AI 에이전트에 대한 명확한 이해를 바탕으로 다계층 보안 전략을 수립해야 프롬프트 인젝션, RAG 과정에서 민감한 정보가 컨텍스트에 포함되어 유출되는 문제, AI 에이전트 자격 증명 탈취 등의 보안 위협에 효과적으로 대응할 수 있습니다.
ADK를 활용한 계층별 인증
AI 에이전트 보안의 출발점은 인증입니다. AI 에이전트라 해서 특별한 인증 기술이 쓰이는 것은 아닙니다. 최소 권한의 원칙에 따라 세션 인증을 구현하면 됩니다. 언뜻 보면 복잡해 보일 수 있지만 ADK 같은 적절한 도구를 활용하면 생각보다 쉽게 접근할 수 있습니다. ADK로 세션 기반 인증을 어떻게 구현할 수 있는지 알아보겠습니다.
ADK는 세션 기반 인증을 적용할 수 있는 유연한 프레임워크를 제공합니다. 개발자는 ADK의 여러 요소를 활용해 AI 에이전트 환경에 맞는 인증 체계를 설계할 수 있습니다. ADK로 구현한 세션 기반 인증 워크플로우는 애플리케이션 계층과 RAG 계층으로 나누어 볼 수 있습니다. 그 과정을 따라가 보자면 먼저 사용자 신원을 먼저 확인합니다. 인증 프로세스는 사용자가 애플리케이션에 로그인하면서 시작됩니다. 애플리케이션은 OAuth 2.0/OIDC 같은 표준 프로토콜로 사용자 로그인을 처리합니다. 로그인이 성공하면 애플리케이션은 사용자 신원을 나타내는 인증 토큰을 받습니다. 동시에 세션 ID가 발급됩니다. 사용자의 신분을 증명하는 인증 토큰은 안전한 중앙 금고에 두고 AI 에이전트는 임시 번호표라 할 수 있는 세션 ID를 이용해 다른 AI 에이전트나 도구와 소통하는 방식이라고 이해할 수 있습니다.
예를 들어 보겠습니다. 사용자 로그인을 성공적으로 한 다음에 채팅 창에 “내 항공권 목록을 보여줘”라고 질문하면 AI 에이전트는 도구를 사용해야 한다고 판단합니다. 이때 AI 에이전트는 도구에 세션 ID를 전달합니다. 도구는 전달받은 세션 ID로 Secret Manager에서 해당 사용자의 인증 토큰을 조회합니다. 그런 다음에 도구는 이 토큰을 요청 헤더에 첨부해 데이터베이스의 게이트키퍼 역할을 하는 백엔드 검색 서비스(retrieval service)를 호출합니다. 이처럼 ADK는 AI 에이전트가 세션 ID만 가지고 도구와 소통하게 하고 데이터에 접근하는 순간만 키 보관함인 Secret Manager에서 토큰을 불러와 사용하는 메커니즘으로 인증을 수행합니다.
이 아키텍처의 보안상 이점은 AI 에이전트와 LLM이 사용자 인증 토큰을 절대 보거나 데이터베이스에 직접 접근할 수 없다는 것입니다. ADK는 AuthScheme, AuthCredential 같은 표준화된 인터페이스를 제공하는데 이를 통해 ‘세션 ↔ 인증 자격 ↔ 도구 호출’을 하나의 안전한 흐름으로 설계할 수 있습니다.
SDP와 Model Armor를 활용한 다계층 방어
AI 에이전트가 사용자가 요청한 작업을 수행할 때 세션 ID를 활용하는 것만으로는 충분한 보안 강화를 할 수 없습니다. 다양한 도구를 활용한 다계층 방어로 AI 에이전트에 맞는 보안 체계를 마련해야 합니다. 구글 클라우드 환경에서는 ADK와 함께 Sensitive Data Protection(SDP, 구 Cloud DLP), Model Armor로 다계층 보안 강화를 할 수 있습니다.
먼저 SDP의 역할을 알아보겠습니다. SDP 민감 데이터를 발견, 분류, 보호하는 완전 관리형 서비스입니다. AI 에이전트 환경에서SDP는 두 단계에 걸쳐 맡은 역할을 수행합니다. 첫 번째는 사전(Pre-RAG) 단계입니다. 문서 수집 및 정제 파이프라인에서 SDP를 사용하여 민감정보를 마스킹하거나 가명화한 후 인덱싱합니다. 이는 데이터베이스에서 검색한 데이터가 LLM에 전달되기 전에 비식별화되어, 모델이 원시 민감 데이터에 노출될 위험을 줄입니다. 두 번째는 실행 단계입니다. SDP는 AI 에이전트가 생성한 최종 응답이 사용자에게 전송되기 전에 스캔할 수 있습니다. 이는 추가적인 데이터 손실 방지(DLP) 계층으로 작동하여, AI 에이전트가 추론하거나 구성했을 수 있는 민감 정보를 실수로 유출하지 않도록 보장합니다.
Model Armor는 들어오는 프롬프트와 나가는 LLM 응답을 모두 스크리닝하는 실시간 LLM 방화벽 역할을 합니다. 이 서비스는 모델에 구애받지 않으며 REST API를 통해 모든 LLM과 함께 사용할 수 있습니다. Model Armor에서 주목할 핵심 기능은 모델의 행동을 조작하려는 시도를 사전에 식별하고 차단하는 프롬프트 인젝션 및 탈옥(Jailbreak) 탐지입니다. 이외에도 프롬프트와 응답 모두에서 악성 링크를 스캔하고 무력화하는 악성 URL 탐지, 그리고 구성 가능한 임계값을 기반으로 유해 콘텐츠를 필터링하는 기능도 제공합니다.
한편, Model Armor는 SDP와 긴밀한 통합이 가능합니다. Model Armor는 기존 SDP 검사 템플릿(inspection templates)을 활용할 수 있습니다. 즉, 조직이 SDP에서 한 번만 민감 데이터 패턴을 정의하면 Model Armor가 모든 AI 트래픽에 대해 이러한 규칙을 실시간으로 자동 적용합니다. 이처럼 Model Armor와 통합으로 SDP는 정적 스캔 도구에서 동적 실시간 도구가 되어 프롬프트와 응답 모두에서 개인정보 유출을 방지합니다.
AI 에이전트 환경에 제로 트러스트 철학 반영하기
눈치 빠른 분은 느낌이 왔을 것입니다. ADK, SDP, Model Armor의 조합은 AI 에이전트 환경을 위한 제로 트러스트(Zero Trust) 보안 철학을 구현하는 하나의 방법으로 볼 수 있습니다. 실제로 구글의 여러 도구를 함께 활용하면 “절대 신뢰하지 말고, 항상 검증하라”는 제로 트러스트 원칙이 AI 아키텍처의 모든 단계에 적용할 수 있습니다. 먼저 애플리케이션 계층이 사용자를 인증합니다. 그런 다음에ADK 인증 도구 패턴이 AI 에이전트가 인증된 사용자를 대신하여 행동하는지 검증합니다. 이 과정에서 AI 에이전트 자체는 신뢰하지 않습니다. Model Armor는 사용자의 프롬프트가 악의적일 수 있다고 가정하고 검사하고 SDP는 RAG 데이터가 LLM에 도달하기 전에 민감 정보를 포함할 수 있다고 가정하고 검사합니다. 마지막으로 Model Armor와 SDP는 LLM의 응답이 유해하거나 민감한 콘텐츠를 포함할 수 있다고 가정하고 다시 검사합니다.
AI 에이전트가 조직의 일하는 방식을 바꾸고 사용자와 AI 간 협업의 시대를 앞당기려면 AI 워크로의 특성을 반영한 보안 체계가 필요합니다. 이번 포스팅에서 소개한 방법은 여러 옵션 중 하나입니다. 우리 조직의 Agentic AI 전략에 맞는 구글 기술 기반의 보안 전략 수립이 필요하다면 메가존소프트가 도움을 드리겠습니다.
