AI 에이전트 이해하기: 구축, 작동 방식 및 경계 설정

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

일부 사람들은 LLM과 AI 에이전트를 혼동하는 듯합니다. 이제 이 논란은 확실히 정리해 보죠. 물론 챗봇을 “확장”해 도구를 실행하도록 한 뒤 AI 에이전트라고 부르는 경우도 있지만, 고급 자동화에 에이전트를 활용하려 한다면 이는 아직 미성숙한 접근 방식입니다. 물론 여러분도 에이전트를 활용하고자 할 것입니다. 하이브리드 멀티클라우드의 복잡성으로 인해 가중되는 운영 피로를 해소하는 데 있어, 이것이 가장 가치 있는 활용 사례 중 하나라는 점을 잘 알고 있기 때문입니다 to address the growing operational fatigue caused by hybrid, multicloud complexity.

AI 에이전트는 목표를 해석하고, 컨텍스트를 유지하며, 도구를 호출해 작업을 수행하는 소프트웨어 단위(애플리케이션)로 경계가 명확한 시스템이어야 합니다. 필요한 작업을 추론하기 위해 대규모 언어 모델(LLM)을 사용할 수 있지만, LLM은 전체 메커니즘을 구성하는 하나의 요소일 뿐입니다. 에이전트 자체가 바로 시스템입니다.

실질적으로 AI 에이전트는 명시적으로 주어지거나 추론된 작업을 받아 정해진 맥락의 범위 내에서 이를 평가하고, 어떻게 행동할지 결정합니다. 이러한 행동에는 도구 호출, 시스템 조회 또는 워크플로 트리거 등이 포함될 수 있습니다.

에이전트의 가치를 활용하기 위해 반드시 수많은 에이전트가 필요한 것은 아닙니다. 명확한 범위가 설정되고 긴밀한 도구 체인과 연동된 단일 에이전트만으로도 지금 당장 유용한 작업을 수행할 수 있습니다. 요약을 자동화하고, 보고서를 생성하고, 티켓을 분류하거나, 알림을 적절한 대기열로 전달할 수도 있습니다. 정해진 범위와 정책을 준수하기만 한다면 이미 충분한 가치가 있습니다.

에이전틱 AI를 구현하지 않고도 AI 에이전트를 사용할 수 있습니다. 하지만 에이전트들이 협업하기 시작하면, 아키텍처가 아직 준비되지 않았더라도 이미 에이전틱 AI를 구현하고 있는 것입니다.

Based on 최근 연구 결과에 따르면이미 에이전틱 행동을 다루고 있거나(응답자의 9%) 앞으로 다루게 될 것(응답자의 79%)이라고 봅니다. 에이전틱 AI에는 여러 에이전트(에이전틱 AI와 쉽게 구분하기 위해 여기서는 ‘미니언’이라고 부르겠습니다)가 공유 도구, 맥락에 따른 목표, MCP와 같은 정책 적용 계층과 상호작용하는 통제된 실행 중심의 프레임워크가 필요합니다.

에이전트란 무엇인가요?

An 에이전트는 명확히 정의된 제약 조건 내에서 자율적 또는 반자율적으로 작동하는 소프트웨어 구성 요소입니다. 작업을 해석하고, 컨텍스트를 관리하며, 도구를 호출하고, 사용자나 더 큰 시스템을 대신해 의사 결정을 내립니다. MCP 기반 아키텍처에서 에이전트는 작업, 상태 및 정책 간의 상호작용을 규정하는 구조화된 프로토콜을 따릅니다.

에이전트는 추론하고, 작업을 위임하고, 행동할 수 있지만 주어진 샌드박스 내에서만 가능합니다. 에이전트가 임의로 시스템 호출을 수행하거나 도구 접근 권한을 만들어 내는 일은 없습니다. 모든 작업은 보안 설정과 모니터링이 가능하고 필요시 권한을 철회할 수 있는, 명시적으로 선언된 인터페이스를 통해 이루어져야 합니다.

에이전트는 최소한 다음을 갖습니다:

1. 컨텍스트 핸들러 – 상태, 목표, 메모리(단기 또는 영구)를 추적합니다
2. 추론 엔진 – 일반적으로 작업을 해석하고 실행 계획을 수립하는 LLM 또는 기호 기반 플래너
3. 도구 인터페이스 – 의도를 작업에 매핑하고 에이전트가 호출할 수 있는 작업을 제어합니다
4. 보안 경계 – 에이전트에 허용된 작업과 그 적용 범위를 강제합니다
5. 전송 계층 – 일반적으로 MCP, HTTP 또는 이벤트 버스를 사용하여 메시지와 컨텍스트를 전달합니다

LLM은 생각합니다. 에이전트는 행동합니다. 플랫폼은 통제합니다.

에이전트 구축 모델

널리 사용되는 모델은 두 가지인데, 그중 하나는 함정입니다.

오늘날 AI 에이전트를 구축하는 방식에는 크게 두 가지가 있습니다. 하나는 LLM 중심 접근 방식이고, 다른 하나는 애플리케이션 한정 접근 방식입니다. LLM 중심 접근 방식은 챗봇에는 적합하지만, 더 본격적인 자동화 활용 사례에는 적합하지 않습니다.

1. LLM 중심 에이전트(모놀리식)

이는 오늘날 대부분의 프레임워크에서 기본적으로 채택하는 방식입니다. LangChain, AutoGen, CrewAI 등이 이에 해당합니다. 에이전트는 본질적으로 도구와 선택적 메모리가 주입된 채팅 프롬프트를 단일 LLM 세션으로 감싼 형태입니다.

• 빠르게 프로토타입 제작 가능
• 시연하기 쉬움
• 확장 시 안전하지 않음

제한 사항:

• 영구 아키텍처 없음
• 기본 제공되는 정책 적용 기능 없음
• 모델이 도구 호출을 환각하거나 제약 조건을 잊기 쉬움
• 확장하지 않는 한 토큰 로그 외에는 관측 가능성이 전혀 없음

요약하자면, 루트 권한은 있지만 감독은 받지 않는 똑똑한 인턴과 같습니다. 문제가 생기기 전까지는 아주 잘 작동합니다.

2. 애플리케이션 종속형 에이전트(모듈형)

프로덕션 환경에서는 이 모델을 사용하는 것이 좋습니다.

여기서 에이전트는 프레임워크를 기반으로 구축된 완전한 소프트웨어 서비스로, LLM을 활용하지만 실행 처리를 LLM에 의존하지는 않습니다.

• 상태는 외부에 저장됩니다(Redis, 벡터 DB, 정책 엔진).
• 도구 사용은 명시적으로 이루어지며 제어 계층(MCP 서버, 게이트웨이 프록시)에서 관리됩니다.
• 보안과 관측 가능성은 나중에 덧붙이는 요소가 아니라 최우선으로 고려해야 할 핵심 요소입니다
• 에이전트는 프롬프트가 아니라 배포된 서비스입니다

이 접근 방식을 사용하면 버전 관리, 액세스 로그, 도구 수준의 거버넌스, 런타임 격리를 확보할 수 있습니다. 이를 통해 에이전트를 단순한 장난감이 아닌 인프라로 전환할 수 있습니다.

에이전트는 페르소나가 아닙니다

사람들은 에이전트를 지능을 갖춘 인격체처럼 설계할 때 본능적으로 인간 중심의 액세스 모델, 즉 역할 기반 액세스 제어(RBAC), 로그인 토큰, 사용자 속성, ID 범위를 사용하려 합니다. 이러한 모델은 세션 내내 일관된 인간의 ID를 다룰 때는 적합합니다. 하지만 에이전트는 그렇게 작동하지 않습니다. 에이전트는 사용자가 아니라 실행 주체입니다. 그리고 이 차이가 모든 것을 바꿉니다.

에이전트는 작업을 수행하면서 역할을 바꿉니다. 하나의 에이전트가 데이터 검색자 역할을 하다가 계획 수립자로, 이어서 자동화 트리거로 전환할 수 있으며, 이러한 역할 전환은 동일한 세션에서 하나의 작업 범위 안에 이루어지는 경우가 많습니다. 에이전트는 로그인한 뒤 고정 토큰을 받아 한 가지 역할에만 머무르지 않습니다.

바로 이 지점에서 기존의 액세스 제어 방식이 한계를 드러냅니다. RBAC는 정적인 역할을 전제로 하고, 속성 기반 액세스 제어(ABAC)는 고정된 속성을 전제로 합니다. 세션 토큰은 일관된 권한 범위를 전제로 합니다. 하지만 에이전트가 동적으로 작동하는 환경에서는 이러한 전제가 어느 것도 성립하지 않습니다. 에이전트형 시스템에서 ID는 개인이 아니라 기능을 기준으로 합니다.

따라서 에이전트를 거버넌스하려면 신원 기반 정책에서 실행 기반 정책으로 전환해야 합니다. 모든 도구 호출은 에이전트의 현재 작업 역할, 컨텍스트 상태, 허용된 범위를 기준으로 실시간 검증되어야 합니다. 정책은 인증 계층이 아니라 도구 계층에 존재합니다. 이러한 정책을 시행하는 데 필요한 메타데이터는 로그인 세션이 아니라 컨텍스트 블록에 담깁니다. 이러한 패러다임 전환을 “페이로드 내 정책”이라고 부르는 이유는 정책이 말 그대로 페이로드 안에 있기 때문입니다.

에이전트는 에이전트답게 다루십시오. 소프트웨어처럼 통제하십시오. 그리고 절대 잊지 마십시오. LLM은 생각하고, 에이전트는 행동하며, 플랫폼은 통제합니다. 이 역할들을 혼동하면, 관리자 권한은 있지만 자신의 지난 실수는 기억하지 못하는 인격체를 만들게 됩니다.

LLM은 생각합니다. 에이전트는 행동합니다. 플랫폼은 통제합니다.

이 원칙을 지키면 확장성과 보안성을 갖추고 현실의 변수에도 흔들리지 않는 에이전트 인프라를 구축할 수 있습니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물