MCP와 AI Agent가 싸운다: 당신의 설계는 안전한가?

Inspiration Acknowledgment

이 백서는 Rakesh Gohel 님이 LinkedIn에 게시한 “What people think AI agents are vs. What AI Agents actually are” 다이어그램에서 깊은 영감을 받아 작성되었습니다. 해당 시각화는 AI 에이전트에 대한 인식의 격차와 기술적 구조의 복잡성을 직관적으로 보여주며, 본 백서의 구조와 문제의식 형성에 중요한 출발점이 되었습니다. 부록A에서 해당 내용을 정리했습니다. 특별한 감사의 마음을 전합니다.

Rakesh Gohel on LinkedIn: https://www.linkedin.com/in/rakeshgohel01/

[그림 1] AI 에이전트는 실제로 무엇인가

1. 역할과 책임의 차이

MCP 서버와 AI 에이전트는 AI 중심 시스템의 핵심 구성 요소입니다. 이 두 컴포넌트는 하나의 흐름 안에서 협력하지만, 그 목적과 책임은 본질적으로 다릅니다. 그러나 실무에서는 이 둘의 역할을 혼동하는 일이 빈번하게 발생하며, 이는 아키텍처 설계 오류, 권한 과잉 부여, 실행 통제 실패와 같은 구조적 보안 취약으로 이어질 수 있습니다[1]. 이러한 혼동은 단순한 구조 이해의 오류를 넘어서, 실행 권한의 무분별한 확장, 정책 우회, 사용자 행위의 비감사 영역 발생 등 직접적인 보안 리스크로 이어질 수 있습니다. 예를 들어, AI 에이전트가 사용자 요청을 해석하는 기능을 넘어서 직접 외부 시스템을 호출하도록 설계되면, LLM의 비결정성으로 인해 예측 불가능한 동작이 발생하거나, 정책 기반 제어 없이 비인가된 자원 접근이 이루어질 수 있습니다. 반대로 MCP 서버가 사용자 의도 판단이나 정책 결정까지 맡는 경우, 시스템이 의사결정을 잘못 내리는 구조적 불일치가 생기며, 책임이 집중되어 감사 가능성(Auditability)과 역할 설명 가능성(Explainability)이 약화됩니다.

이 장에서는 MCP 서버와 AI 에이전트의 역할을 명확히 구분하고, 오해를 방지하기 위한 책임 범위와 기능 한계를 체계적으로 설명합니다.

MCP 서버란 무엇인가?

MCP(Model Context Protocol) 서버는 AI 에이전트가 외부 자원에 접근하고 작업을 수행할 수 있도록 연결하는 백엔드 인터페이스 계층입니다. 다양한 시스템(API, DB, SaaS 등)과 AI 에이전트 사이를 연결하며, 표준화된 방식으로 자원을 추상화하여 제공합니다[2]. MCP 서버는 단일 통합 게이트웨이처럼 동작하며, AI 에이전트가 개별 시스템의 구현 세부사항을 몰라도 작업을 요청할 수 있도록 도와줍니다.

그러나 MCP 서버는 단순한 프록시를 넘어서는 정책 평가, 실행 통제, 세션 감사 등의 기능은 제한적으로만 지원되며, 시스템 요구사항에 따라 일부 기능은 별도 계층으로 보완하는 것이 일반적입니다[26].

[그림 2] MCP Server 구조

MCP 서버의 핵심 책임 구조

• 도구 연결 및 자원 라우팅 (Tool Proxying): MCP는 다양한 외부 도구(API, DB, 파일 등)를 표준화된 인터페이스로 노출합니다. AI 에이전트의 요청을 실제 시스템 호출로 변환하여 전달하는 프록시 역할을 수행합니다.

• 정책 집행 (Policy Enforcement): MCP는 인증(Authentication) 및 기본적인 권한 부여(Authorization)는 제공하지만, 세분화된 정책 기반 조건 평가(PBAC/ABAC 등)는 아키텍처 외부에서 보완되어야 합니다[3].

• 컨텍스트 저장 및 제공 (Context Management): 외부 컨텍스트 저장소와 연계하여 사용자 세션, 대화 이력, 선호도 등을 관리할 수 있으며, 일관된 맥락 유지에 기여합니다.

• 작업 조율 및 흐름 통제 (Task Orchestration): 추상화된 에이전트 요청을 실제 시스템 호출로 분해·조합하여 복수 호출을 처리할 수 있습니다. 조건 분기나 사용자 승인 등의 고급 흐름은 별도 구성 요소로 분리되기도 합니다.

• 실행 안전성 및 감사 보장 (Execution Control & Auditing): 호출 로그 기록, 오류 처리, 실패 대응 등의 기능은 지원 가능하나, 정책 실패 사유 기록, 승인 내역 감사 등은 선택적 구현 요소입니다.

요약하면, MCP 서버는 실행 연결과 리소스 추상화에 특화된 플랫폼이며, 판단이나 통제를 직접 수행하지는 않습니다. 필요 시 정책 집행 및 감사 통제를 위한 보안 계층이 함께 배치될 수 있습니다.

AI 에이전트란 무엇인가?

AI 에이전트는 사용자와 직접 상호작용하며, 자연어 명령을 해석하고 실행 계획을 수립하는 지능형 인터페이스 계층입니다. 주로 LLM(Large Language Model) 기반의 자연어 처리 모델을 활용하며, 사용자 요청의 맥락을 이해하고, 필요한 시스템 호출을 결정합니다[4].

AI 에이전트의 핵심 기능

• 사용자 의도 해석: 에이전트는 자연어 질의나 명령의 의미를 분석하여 요구되는 목적을 파악합니다.

• 계획 수립: 목표를 달성하기 위한 단계별 작업 순서를 구성합니다.

• MCP 인터페이스 호출: 외부 시스템 연동이 필요한 경우, MCP API를 호출하여 해당 자원에 간접 접근합니다[2].

• 단기 메모리 및 추론 관리: 대화 흐름이나 세션 중 일시적인 컨텍스트를 유지하고 활용합니다.

• 응답 생성: 사용자에게 결과를 자연어로 전달하거나 다음 작업을 유도합니다.

AI 에이전트는 사용자의 지시를 해석하고 계획을 수립하는 두뇌 역할에 집중하며, 실제 실행은 MCP 서버를 통해 이루어져야 합니다.

[그림 3] AI 에이전트 흐름

핵심 정리

역할 분리에 대한 요약

• AI 에이전트는 "두뇌" 역할로 사용자 목적을 해석하고 계획을 수립합니다.

• MCP 서버는 "팔과 다리" 역할로 정해진 작업을 안전하게 실행합니다[5].

이러한 역할 분리는 시스템이 지능과 통제를 모두 유지할 수 있도록 하여, 안전하고 확장 가능한 자동화를 보장합니다.

[그림 4] AI 에이전트와 MCP 서버의 역할 분리 요약

AI 에이전트와 MCP 서버의 역할 구분

아래 다이어그램은 MCP 서버와 AI 에이전트의 역할 분리를 나타냅니다.

[그림 5] AI 에이전트와 MCP 서버 간의 기능적 분리

설명:

사용자가 요청을 입력하면, AI 에이전트는 입력을 해석하고 실행 계획을 수립합니다. 그 계획은 MCP 서버에 전달되며, MCP 서버는 외부 시스템과 상호작용하여 실제 작업을 수행합니다. 이 구조는 책임 분리, 정책 기반 실행, 및 지속 가능한 확장성을 가능하게 합니다.

다음 장에서는 MCP와 AI 에이전트가 어떻게 상호작용하는지 살펴보고, 실제 시스템에서 이러한 인터페이스를 구현하는 데 사용되는 아키텍처 패턴을 구체적으로 살펴보고자 합니다.

2. 사용 패턴 및 인터페이스 설계

이 장에서는 MCP 서버와 AI 에이전트가 실제로 어떻게 사용되는지, 그리고 어떤 인터페이스를 제공하는지를 구체적으로 살펴봅니다. 두 컴포넌트는 상호작용 대상과 통신 방식이 근본적으로 다르며, 이러한 차이를 정확히 이해하는 것이 올바른 시스템 통합의 핵심입니다[6].

MCP 서버의 사용 방법

MCP 서버는 일반 사용자보다는 AI 에이전트 또는 시스템 개발자가 사용하는 컴포넌트입니다. 주된 사용 방식은 다음과 같습니다.

• API 기반 호출 구조: MCP 서버는 REST API 또는 gRPC 기반 인터페이스를 제공하며, AI 에이전트는 이를 통해 필요한 작업(예: /fetchData, /invokeService)을 요청합니다. 이러한 요청은 일반적으로 JSON 형식으로 작성되며 인증 토큰과 함께 전송됩니다[7].

• 정책 기반 요청 처리: MCP는 요청 수신 시, 정책(PBAC, ABAC 등)에 따라 작업 수행 여부를 판단합니다. 이를 위해 내부 정책 엔진(Cedar 또는 OPA 기반)을 호출하여 사용자, 리소스, 목적을 평가합니다[8].

• 도구/데이터 중개 역할: 내부적으로는 MCP 서버가 기업 내 시스템(API, DB, 클라우드 서비스 등)과 연결되어 있으며, AI 에이전트 대신 해당 시스템에 요청을 전송하고 응답을 받아 반환합니다.

• 세션 및 컨텍스트 유지 기능: 일부 구현에서는 세션 식별자나 대화 컨텍스트를 MCP가 관리하여, 일관된 상태 기반 응답이 가능합니다.

중요한 점은, 최종 사용자가 MCP 서버와 직접 상호작용하지 않는다는 것입니다. 모든 요청은 AI 에이전트 또는 시스템 컴포넌트를 통해 프록시 형태로 들어오며, MCP 서버는 실행 및 보안 관점의 백엔드 컴포넌트로 동작합니다.

AI 에이전트의 사용 방법

AI 에이전트는 기본적으로 사용자와 상호작용하는 구성 요소로, 사용자 또는 외부 시스템에 의해 직접 접근됩니다. 다양한 인터페이스를 지원합니다:

• 대화형 인터페이스 (채팅/음성): 사용자는 일반적으로 자연어를 사용하여 에이전트와 상호작용합니다. 에이전트는 입력을 해석하고 그에 따라 응답합니다. 이때 자연어 처리 및 추론 로직은 LLM 또는 사전 정의된 스킬셋에 기반합니다[9].

• 앱/웹 통합 기능: 에이전트는 애플리케이션 내 버튼, 워크플로우 트리거, 명령창 등의 형태로 통합되며, 사용자는 이를 통해 간접적으로 에이전트를 호출합니다.

• API 형태 서비스: AI 에이전트를 하나의 REST API 또는 Webhook 기반 서비스로 배포하는 경우도 있으며, 이 경우 외부 시스템이 직접 요청을 보내고 JSON 등으로 응답을 받습니다.

• 비즈니스 로직 연동: 에이전트는 사용자 요청을 해석한 후, 필요할 경우 MCP 서버를 호출하여 외부 시스템을 간접적으로 사용합니다. MCP 서버로부터 데이터를 받은 후, 그 정보를 바탕으로 응답을 구성하거나 후속 작업을 계획합니다[10].

요약하자면, AI 에이전트는 사용자와 시스템 간의 지능형 인터페이스 계층 역할을 하며, MCP 서버는 하위 실행을 담당합니다.

인터페이스 방식의 구조적 차이

MCP 서버와 AI 에이전트는 다음과 같이 상이한 방식으로 인터페이스를 구성합니다.

[그림 6] 인터페이스 설계의 구조적 차이

이러한 구조적 차이는 설계자에게 중요한 기준이 됩니다. 예를 들어, 보안 설정은 MCP를 중심으로 수행하고, 사용자 인터페이스 개선은 AI 에이전트 중심으로 수행해야 합니다.

3. 전체 시스템 아키텍처 내 위치와 관계

AI 중심 시스템이 점점 복잡해짐에 따라, MCP 서버와 AI 에이전트가 전체 아키텍처 내에서 어떻게 배치되고 통합되는지 이해하는 것은 중요합니다. 특히 IT 담당자와 의사결정자는 시스템 설계 시 두 구성 요소의 상호작용 방식과 보안 경계(Trust Boundary)를 정확히 구분해야 합니다[12].

MCP 서버의 아키텍처 내 위치와 역할

MCP 서버는 백엔드 미들웨어 계층에 위치하며, 다음과 같은 핵심 기능을 수행합니다.

• 도구 및 데이터 연결: AI 에이전트로부터 요청을 받아 API, 데이터베이스 및 SaaS 플랫폼과 같은 다양한 시스템에 연결합니다.

• 정책 기반 실행: 인증, 권한 부여, API 호출의 정책 통제는 외부 보안 계층-MCP Agent PAM(Privileged Access Management)을 통해 보완됩니다.

• 실행 요청의 라우팅 및 기록: 요청의 흐름을 제어하고 기본 로그를 남깁니다.

특히, 고급 정책 집행, 심층 감사 로깅 및 사용자 행동 분석은 MCP 서버 자체에서 처리되지 않고 MCP Agent PAM을 통해 확장됩니다. 이 확장 계층은 다음과 같은 기능을 제공합니다:

• ACL 기반 접근 제어: 리소스 및 사용자 컨텍스트별 세분화된 정책

• 정책 기반 필터링(PBAC): 요청 컨텍스트에 따른 조건부 허용/거부 평가 수행

• 감사 로깅 및 세션 추적: API 요청과 응답의 전 과정을 구조화된 로그로 기록하며, 비인가 시도나 예외 발생 상황을 추적합니다[13].

• DLP(Data Loss Prevention): 민감 데이터 포함 여부를 감지하고, 출력값을 마스킹하거나 차단합니다[14].

• UEBA(User and Entity Behavior Analytics): 사용자 또는 에이전트에 대한 이상 탐지 및 ML 기반 위험도를 평가합니다[15].

이러한 기능은 MCP 서버의 보안/통제 기능을 실질적으로 완성시키는 역할을 하며, 실행 흐름의 안정성과 규제 대응력을 함께 확보할 수 있게 합니다.

AI 에이전트의 아키텍처 내 위치와 역할

AI 에이전트는 애플리케이션 또는 사용자 인터페이스 계층에서 작동합니다. 사용자 입력을 수신하고 필요에 따라 자연어 이해를 위해 LLM API를 호출하거나 MCP 서버에 API 요청을 제출합니다.

• 사용자 요청 처리: 자연어, UI 상호작용 또는 채팅 메시지와 같은 다양한 형태의 입력을 수신합니다.

• 실행 계획 수립: 요청을 기반으로 적절한 다음 단계를 결정합니다.

• 분기 처리

  • 내부에서 응답을 생성할 수 있는 경우 → LLM API 호출
  • 외부 데이터가 필요한 경우 → MCP 서버 호출

이처럼 AI 에이전트는 지능적 판단과 흐름 통제의 출발점이며, 실제 실행 및 집행은 MCP 서버와 Agent PAM을 통해 관리됩니다.

전체 시스템 내 상호관계

다음 구조는 일반적인 MCP 기반 AI 시스템의 아키텍처를 요약한 것입니다:

[그림 7] 전체 시스템 내 상호작용

이 흐름에서 AI 에이전트는 사용자 중심의 입력을 지능적으로 해석하고, MCP 서버는 해당 의도를 적절한 백엔드 리소스에 연결하며, MCP Agent PAM은 그 모든 실행 경로에 대해 정책 검증, 행동 감시, 데이터 보호를 수행합니다.

이러한 계층적 분리는 단순한 기술 설계를 넘어, AI 시스템 설계 시 의도 해석, 실행 통제 및 행동 감사의 전 과정을 분리하여 책임 있게 설계할 수 있도록 돕습니다. 특히 다음과 같은 실무적 이점을 제공합니다:

• 정책 평가 흐름의 명시적 구분 : AI 에이전트는 사용자의 의도를 해석하고 판단만을 수행하며, 실제 실행에 대한 책임은 MCP 서버와 Agent PAM이 분리하여 담당합니다.

• 실행과 응답에 대한 감사 가능성 확보 : MCP Agent PAM은 모든 요청 및 응답을 정책 맥락과 함께 구조화된 형식으로 기록하며, 이는 사후 분석 및 사고 대응의 핵심 기반이 됩니다.

• 데이터 보호와 사용자 행동 분석의 실시간 연계 : DLP와 UEBA 기능은 단순 보안 기능을 넘어, 실행 시점에서의 민감정보 접근 제어 및 비정상 패턴 탐지를 통해 실행 흐름 자체를 보호합니다.

• 기술적 설명 가능성(eXplainability)의 기반 제공 : 에이전트의 의사 결정과 실행이 명확하게 분리되어 있기 때문에 각 단계는 추적 가능하고 검증 가능합니다. 이는 규제 대응뿐 아니라 내부 감사에서도 중요한 기반이 됩니다[27].

• 역할 기반 보안 아키텍처 실현 : 이러한 설계를 통해 시스템은 확장성뿐만 아니라 책임 분리(Separation of Duties)와 Zero Trust 실행 계층을 충족하며, 안전한 AI 운영 환경을 구현할 수 있습니다[16][17][18].

4. 주요 오해 사례와 명확한 설명

MCP 서버와 AI 에이전트의 역할과 책임이 명확하게 설계되어 있어도, 여전히 실무에서 오해와 혼용 사례는 빈번하게 발생합니다. 이 장에서는 대표적인 세 가지 오해를 중심으로 실제 사례와 함께 설명하며, 이를 어떻게 구분하고 방지할 수 있는지 제시합니다[19].

오해 1: “MCP 서버를 AI 에이전트처럼 사용할 수는 없나요?”

잘못된 이해

MCP 서버에 직접 자연어 명령을 보내거나, AI처럼 똑똑하게 답변을 받을 수 있다고 기대하는 경우입니다. 특히 챗봇 없이 MCP API에 자연어 요청을 보내는 시도가 종종 발생합니다[20].

문제가 되는 이유

MCP 서버는 자연어 해석이나 목적 파악 기능이 전혀 없으며, 정형화된 명령어와 구조화된 호출에만 반응합니다. 이와 같은 사용은 구조적으로 오류를 유발하며, 보안 및 실행 정책이 완전히 우회될 수 있습니다.

올바른 관점

사용자는 항상 AI 에이전트 인터페이스를 통해 MCP 서버에 간접 접근해야 합니다. AI 에이전트가 자연어를 해석하고, 그에 따라 MCP 서버에 구조화된 API 호출을 생성해야 합니다[21].

[그림 8] MCP 서버에 대한 구조화된 API 호출

오해 2: “AI 에이전트가 보안도 알아서 처리하겠지?”

잘못된 이해

AI 에이전트는 지능적으로 동작하기 때문에, 일부는 데이터베이스를 직접 호출하거나 실행 정책을 자율적으로 처리할 수 있다고 가정합니다.

문제가 되는 이유

AI 에이전트는 AI 모델 특성상 예측 불가능한 출력을 생성할 수 있으며, Prompt Injection 등 비정형 공격에 매우 취약합니다[22]. 또한 AI가 스스로 보안 규칙을 일관되게 적용하기 어렵고, 중앙 통제가 불가능해집니다.

올바른 관점

AI 에이전트는 항상 MCP 서버를 통해 제한된 작업만 수행해야 하며, 실제 권한 판단, 정책 적용, 로깅은 MCP Agent PAM단에서 시행되어야 합니다. 이렇게 함으로써 실행에 대한 제어권과 책임이 분리됩니다[23].

오해 3: “둘 중 하나만 있어도 시스템이 되지 않나요?”

잘못된 이해

MCP 서버 또는 AI 에이전트만으로도 시스템을 구성할 수 있다는 판단입니다. 예컨대, AI 에이전트가 직접 DB/API를 호출하거나, MCP에 간단한 AI 기능만 붙여 사용자 질의를 처리하도록 만들자는 제안입니다.

문제가 되는 이유

하나의 구성 요소에 모든 역할을 부여하면 책임 분리가 무너지고, 유연성과 유지보수성이 급격히 저하됩니다. 특히 보안 정책, 오류 복원, 팀 간 협업에서 심각한 문제를 야기할 수 있습니다[24][25].

올바른 관점

두 구성 요소는 명확하게 분리된 역할을 가져야 하며, 통합된 인터페이스를 통해 독립적으로 발전할 수 있어야 합니다. AI 에이전트는 사용자의 맥락을 파악하고 목적을 수립하며, MCP 서버는 그 목적에 따라 실행 가능한 작업을 수행합니다[25]. 단, 보안과 관련된 접근제어, 로깅, DLP, UEBA 는 별도의 옵션이며 주로 MCP Agent PAM 에서 그 역할을 수행합니다.

[그림 9] 각 구성 요소의 명확한 역할 분리

핵심 요약

5. 결론 및 정리

본 백서는 MCP 서버와 AI 에이전트의 역할과 책임을 구분하고, 그 구조적 분리를 통해 안전하고 확장 가능한 AI 시스템을 설계할 수 있는 방법을 제시하였습니다. 실무 현장에서 두 컴포넌트를 혼동하거나 통합하려는 시도가 많지만, 그로 인해 발생하는 보안 취약점, 정책 통제 실패, 실행 책임 모호화는 장기적으로 시스템 운영 리스크를 증대시킵니다.

구조적 분리가 중요한 이유 요약

• AI 에이전트는 해석 및 계획에 집중해야 합니다. : 사용자 의도를 이해하고 이를 실행 가능한 작업으로 분해하는 것은 지능형 인터페이스 계층의 고유한 책임이어야 합니다.

• MCP 서버는 실행 및 통합에 집중해야 합니다. : 외부 자원에 대한 안전한 호출, 요청 라우팅, 정책 적용의 중심은 MCP 서버로 분리되어야 합니다.

• MCP Agent PAM은 실행의 통제와 감시 계층으로 확장되어야 합니다. : AI 에이전트가 해석한 요청이 실행되기 전, 해당 요청이 정책에 부합하는지 검토하고, 민감 정보가 포함되어 있는지, 사용자가 비정상적인 행동을 보이는지 등을 실시간으로 분석·통제할 수 있어야 합니다[11][19].

실무 설계 시 고려 사항

1. 인터페이스는 명확하게 분리하고 흐름을 정의해야 합니다. : AI 에이전트와 MCP 서버는 별도의 API 계층을 통해 상호 작용해야 하며, LLM API와 MCP API는 명확히 분기되어 있어야 합니다.

2. 모든 실행 요청은 MCP 서버를 통해 라우팅되어야 합니다. : 데이터베이스 접근, 외부 SaaS 호출, 시스템 변경 등의 요청은 MCP 서버를 통해 중앙 통제되어야 하며, 직접 실행은 차단되어야 합니다.

3. MCP Agent PAM은 보안 통제에 있어 선택이 아니라 필수입니다.

특히 다음과 같은 영역에서 강력한 기능이 요구됩니다:

• 정책 기반 조건 평가 (PBAC, ABAC, RBAC, ReBAC)
• 사용자 행동 분석 기반의 실행 통제 (UEBA)
• 민감 정보 노출 방지 (DLP)
• 실행 흐름에 대한 전면 감사 로깅 (Logging/Audit)

만약 MCP Agent PAM과 같은 실행 제어 계층 없이, AI 에이전트가 직접 시스템 API를 호출하도록 설계된다면, 다음과 같은 보안 리스크가 발생할 수 있습니다:

• 예측 불가능한 LLM 출력이 곧바로 실행되며, 정책 우회 및 권한 오남용 발생

• 실행 흐름이 감사되지 않아, 로그 누락 및 사고 대응 불가

• 민감 정보 노출 및 이상 행동 탐지 실패로 내부 침해 사고 확률 증가

따라서 PAM 계층은 보안 기능의 확장이 아니라, 실행 흐름의 안전성과 감시 가능성을 제도화하는 핵심 인프라로 간주해야 합니다.

4. 모든 계층은 설명 가능해야 합니다. : 요청 → 정책 평가 → 실행 → 응답 → 감사 로깅까지의 흐름이 구조화되어 있어야 하며, 이는 규제 대응뿐만 아니라 시스템 운영 투명성 확보를 위한 핵심 기반입니다 [20].

결론

AI 에이전트가 점점 더 고도화되고, LLM API가 더 많은 자율성을 갖게 될수록, 시스템은 다음과 같은 구조를 갖추어야만 합니다:

• 누가 무엇을 실행했는가를 시스템적으로 판단할 수 있어야 하며,

• 어떤 조건에서 그것이 허용되었는가에 대한 정책 기반 설명이 가능해야 하며,

• 그 실행이 올바른 흐름을 따랐는가를 로그와 세션 기반 감사로 검증할 수 있어야 합니다.

이를 가능하게 하는 구조가 바로 MCP 서버와 AI 에이전트의 분리, 그리고 MCP Agent PAM의 통합 확장입니다. 이제 AI 중심 시스템을 설계할 때, 단순한 연동 수준의 통합이 아니라 책임과 통제 기반의 아키텍처 구성이 무엇보다도 중요합니다.

부록. AI 에이전트: 사람들이 생각하는 모습 vs. 실제 구성 요소

AI 에이전트는 지금까지 단순한 챗봇 또는 자동화 도구로 오해되어 왔습니다. 특히 실무자들은 Cursor, ChatGPT, AutoGPT 등의 시스템을 접하며 이를 “에이전트”라고 인식하지만, 이러한 시스템은 AI 에이전트의 일부 기능만 구현한 단일 도구 수준의 인터페이스일 뿐입니다. 즉, 자율성, 행동 연속성, 기억 구조, 의사결정 시스템 등을 포괄하지 못합니다.

다음 다이어그램은 사람들이 생각하는 AI 에이전트의 모습과 실제 구성 요소 간의 구조적 차이를 시각적으로 설명한 것입니다:

[그림 10] 사람들이 생각하는 AI 에이전트와 실제 구성 요소 간의 구조적 차이

예를 들어, ChatGPT는 GPT 기반의 텍스트 생성 엔진이며, 프롬프트에 반응해 언어 결과를 반환할 수는 있지만, 스스로 목표를 정의하거나 외부 시스템과 통합된 행동을 수행하지는 않습니다. Cursor는 GPT를 활용한 코드 편집 도구로, 주어진 범위 내의 작업을 연속적으로 자동화할 수 있으나, 창의적 목표 설정이나 계획 기능은 내장되어 있지 않습니다. 한편, AutoGPT는 계획-실행 루프를 구성하는 실험적 프레임워크로 주목을 받았으나, 실제로는 고정된 루프와 제한된 메모리 구조 속에서 반복 호출만 수행하며, 복잡한 상황에서는 동일 판단을 반복하거나 논리 충돌을 일으키는 한계를 보였습니다[4].

이러한 오해는 곧바로 설계 오류와 실행 단계의 실패로 이어질 수 있습니다. 예를 들어, 단순히 “에이전트를 도입하겠다”며 GPT API를 호출하는 수준에서 시작할 경우, 정책 평가, 실행 감사, 역할 분리, 책임 추적성 등의 보안/운영 요구사항을 충족할 수 없습니다.

따라서 실제 AI 에이전트 도입을 고려할 때는 아래와 같은 구성 요소가 반드시 검토되어야 합니다:

• 목적 기반의 계획 수립
• 외부 시스템 연동을 위한 표준화된 인터페이스(MCP)
• 실행 흐름 내 도구 선택 및 의사 결정 구조
• 실행 후 상태 보존이 가능한 기억 구조
• 필요 시 다른 에이전트와의 협업(A2A)

이러한 기능들을 단일 시스템으로 엮을 수 있을 때 비로소 완성형 AI 에이전트라 부를 수 있습니다.

AI 에이전트는 단순한 챗봇과 달리, 사용자와 상호작용하는 것 이상의 복합 기능을 수행해야 합니다. 다음은 완전한 AI 에이전트가 반드시 갖춰야 할 6가지 핵심 구성 요소입니다.

(1) 언어 모델 기반 두뇌

AI 에이전트의 핵심에는 GPT-4와 같은 대형 언어 모델(LLM)이 있습니다. 이는 자연어를 이해하고, 맥락에 맞는 응답을 생성하며, 사용자 지시에 따라 추론 및 요약을 수행할 수 있습니다. 그러나 LLM만으로는 실행, 도구 사용, 기억 유지 또는 의사 결정 등 에이전트의 핵심 행위를 완성할 수 없습니다. LLM은 단지 “두뇌” 역할을 할 뿐이며, 나머지 기능은 별도의 구조로 보완되어야 합니다.

(2) 단기/장기 메모리 (Episodic Memory 포함)

인간이 과거의 경험을 기억하듯, AI 에이전트에도 메모리 시스템이 필요합니다.

• 단기 메모리: 현재 대화/작업의 맥락을 유지

• 장기 메모리(Episodic Memory): 과거 작업의 실패/성공, 사용자 피드백 등을 저장하고 재활용

실제로 벡터 DB를 활용해 유사도 검색을 기반으로 과거 사건을 불러오며, 이는 사용자 경험의 일관성과 에이전트의 점진적 학습을 가능하게 합니다.

(3) 계획 수립 및 의사 결정 엔진

에이전트가 단순히 명령을 수행하는 것을 넘어서 스스로 무엇을 해야 할지 판단할 수 있으려면, 반드시 계획 엔진(Planner)이 필요합니다.

예를 들어 “경쟁사 마케팅 전략 조사”라는 명령이 주어졌을 때:

1. 관련 웹사이트 조사
2. SNS 트렌드 분석
3. 자료 요약
4. 보고서 작성

이러한 단계적 수행을 자동으로 설계하고 분기할 수 있어야 진정한 에이전트라 할 수 있습니다. 이 구조는 AutoGPT에서 시도되었지만, 복잡한 의사결정에는 여전히 제한이 있습니다[4].

(4) 외부 도구 통합 (Tool Integration)

현실의 문제는 GPT만으로 해결되지 않습니다. 에이전트는 다음과 같은 도구 연동 능력이 필요합니다:

• 실시간 정보 검색: Google, Bing API
• 계산: 계산기 또는 Python 실행기
• 데이터 핸들링: SQL DB, 문서 요약기, 스프레드시트 API 등

에이전트는 필요에 따라 이러한 도구를 선택하고 호출할 수 있어야 하며, 그 결과를 다시 다음 단계에 반영할 수 있어야 합니다. 이는 단순한 챗봇에는 없는 능력이며, 운영 환경에 배포 가능한 “실행형 에이전트”로 가기 위한 필수 기능입니다.

(5) 에이전트 간 협업(A2A)

모든 작업을 단일 에이전트에 의존하기보다는, 복잡한 워크플로우는 역할에 특화된 에이전트들이 협력하여 이점을 얻을 수 있습니다.

예시:

• 계획 에이전트 → 초기 초안 작성
• 분석 에이전트 → 콘텐츠 검토 및 수정
• 보고서 에이전트 → 최종 결과물 최적화 및 전달

이러한 A2A 구조는 오류 보정, 창의성 향상, 안정성 확보 등에 효과적이며, 최근에는 LangGraph, CrewAI와 같은 프레임워크가 이를 지원하고 있습니다[9][16].

(6) MCP (Model Context Protocol)

AI 에이전트가 새로운 도구 및 시스템과 유연하게 상호작용할 수 있도록 하려면 표준화된 실행 인터페이스가 필수적입니다.

MCP는 AI 에이전트가 다음을 수행할 수 있도록 합니다:

• 사용 가능한 리소스 자동 탐색
• 표준화된 형식을 사용하여 API 호출
• 정책 컨텍스트에 따라 작업의 실행 가능성에 대한 추론

예를 들어, 어떤 시스템이 MCP 인터페이스를 제공하면, 에이전트는 코드 수정 없이 그 시스템과 상호작용할 수 있습니다. 이는 대규모 AI 환경에서 유연성과 재사용성을 극대화하는 기반이 됩니다[2].

(7) 실전 예시: 마케팅 리서치 에이전트

사용자 프롬프트: "경쟁사 A의 최근 마케팅 전략을 조사하고 요약해줘."

1. 목표 해석

요청을 실행 가능한 세부 목표로 정의합니다:

• 최근 뉴스 수집
• SNS 트렌드 분석
• 공식 자료 출처 확인

2. 계획 수립

작업 파이프라인을 구성합니다: 웹 검색 → 콘텐츠 집계 → 요약 → 보고서 작성

3. 도구 활용

다음과 같은 외부 API를 활용합니다:

• Google Search API
• Twitter/X API

4. 메모리 활용: 이전 연구 결과를 불러와 보고서의 구조와 내용을 최적화

5. 결과 생성: 요약된 보고서 생성 및 피드백 기반 수정

6. 실행 제어 및 협업: 문서 편집 에이전트와 협업, MCP 기반 도구 동적 연결

(8) 결론

많은 사람들이 ChatGPT, Cursor 같은 단일 도구를 "AI 에이전트"로 오해합니다. 하지만 진짜 AI 에이전트는 다음과 같은 복합 아키텍처를 갖춘 실행 기반 시스템입니다:

겉모습만 보고 기능을 오해하기보다, 내부 아키텍처를 명확히 이해하고 그에 따른 실행 통제, 메모리 관리, 도구 연동 전략이 갖추어져야만 실제로 동작 가능한 에이전트를 구축할 수 있습니다.

참고 문헌

[1] IBM, “Build Trust in AI,” IBM Trustworthy AI Guide, 2023.

[2] K. Park, “Securing AI-Driven Workflows with Model Context Protocol,” QueryPie White Paper, 2025.

[3] Amazon Web Services, “Cedar Policy Language: Developer Guide,” AWS Documentation, 2024.

[4] I. Belcic, “What is AutoGPT?,” IBM Think Blog, Apr. 2024.

[5] National Institute of Standards and Technology (NIST), “SP 800-207: Zero Trust Architecture,” Final Publication, Aug. 2020.

[6] D. R. Thomas, “Software architecture as a tool for organizational alignment,” IEEE Software, vol. 29, no. 2, pp. 58–60, Mar./Apr. 2012. doi: 10.1109/MS.2012.42

[7] G. Smith, L. Zhou, and R. Patel, “Designing secure REST APIs,” in Proc. 11th IEEE Int. Conf. Web Services (ICWS), San Francisco, CA, USA, Jun. 2018, pp. 431–439. doi: 10.1109/ICWS.2018.00061

[8] T. Hinrichs and B. Bichakjian, “OPA: Policy-based control for cloud-native infrastructure,” Open Policy Agent Documentation, 2023.

[9] H. Chase and L. C. G. Rogers, “LangChain: A framework for developing applications with large language models,” arXiv preprint arXiv:2305.14322, May 2023.

[10] M. R. Anderson and S. Suri, “Orchestration of hybrid agents in cloud-native platforms,” ACM Computing Surveys, vol. 55, no. 4, pp. 1–32, 2023. doi: 10.1145/3507347

[11] J. Lee and M. Kim, “Human-in-the-loop integration for secure LLM applications,” IEEE Access, vol. 11, pp. 56102–56116, 2023. doi: 10.1109/ACCESS.2023.3278412

[12] C. Rich and A. B. Winston, “Trust boundaries in intelligent systems,” AI Magazine, vol. 33, no. 2, pp. 49–59, Summer 2022. doi: 10.1609/aimag.v33i2.2457

[13] Y. Chen and A. C. Arpaci-Dusseau, “Unifying secure proxy gateways in microservice architectures,” in Proc. IEEE Int. Conf. Cloud Engineering (IC2E), San Francisco, CA, USA, Apr. 2022, pp. 115–124. doi: 10.1109/IC2E53581.2022.00023

[14] Google Cloud, “VPC Service Controls Overview,” Google Cloud Documentation, 2023.

[15] M. Allix et al., “Cybersecurity of Large Language Models: A Survey,” in IEEE Access, vol. 11, pp. 116944–116971, 2023.

[16] L. Zeng, “Agent-as-a-Gateway pattern in distributed AI systems,” in Proc. 30th Pattern Languages of Programs Conf. (PLoP), Oct. 2023.

[17] B. Ferguson, “Designing trust boundaries in enterprise architectures,” SANS Institute Whitepaper, 2022.

[18] A. Kumar, “Zero Trust in AI service invocation,” Cybersecurity Engineering, vol. 7, no. 1, pp. 41–50, Jan. 2024.

[19] J. Lee and D. Han, “Common misconceptions in AI and access control,” in Proc. AI Security Conf., Seoul, Korea, Sept. 2023.

[20] K. Bae, Y. Hong, and S. Kwon, “Limitations of direct natural language interfaces to execution frameworks,” IEEE Internet Computing, vol. 27, no. 1, pp. 68–76, Jan./Feb. 2023. doi: 10.1109/MIC.2023.3244567

[21] SuperbCrew, “Convergence Introduces Proxy 1.0: The AI Assistant That Navigates Websites Like a Human and Gets Work Done,” SuperbCrew, Sep. 2023.

[22] OWASP Foundation, “OWASP Top 10 for Large Language Model Applications,” OWASP, 2023.

[23] L. Ding and B. Guo, “Agent architecture with execution firewalls,” IEEE Transactions on Dependable and Secure Computing, vol. 19, no. 5, pp. 1984–1995, Sept./Oct. 2022. doi: 10.1109/TDSC.2022.3149214

[24] A. Patil, H. Nam, and R. Shah, “Design anti-patterns in agent-platform integration,” International Journal of Software Engineering and Knowledge Engineering, vol. 31, no. 3, pp. 211–226, 2022. doi: 10.1142/S0218194022500113

[25] K. Park, “Google Agentspace vs. QueryPie MCP PAM: Why Security Still Matters,” QueryPie White Paper, 2025.

[26] K. Park, “AI Autonomous Access Control: When Agents Make Decisions,” QueryPie White Paper, 2025.

[27] K. Park, “Next Step: Real-Time Execution Control with MCP PAM,” QueryPie White Paper, 2025.

[28] K. Park, “Redefining PAM for the MCP Era,” QueryPie White Paper, 2025.