AI 에이전트 시스템과 MCP 구조

핵심 요약

AI 에이전트 시스템은 대형 언어 모델(LLM)이 사용자의 요청을 해석하고, 필요한 작업을 계획하며, 외부 도구를 호출해 실제 실행 결과를 만들어내는 구조다. 이 구조에서 중요한 것은 모델 자체의 언어 능력만이 아니라, 모델이 어떤 도구에 접근할 수 있고, 그 도구를 어떤 절차와 권한 체계 안에서 사용할 수 있는가이다.

AI 에이전트는 보통 사용자 인터페이스, 에이전트 오케스트레이터, LLM, 도구 연결 계층, 외부 실행 시스템으로 나누어 이해할 수 있다. 사용자는 채팅, 음성, 앱, API 등을 통해 요청을 입력하고, 오케스트레이터는 그 요청을 작업 단위로 분해한다. LLM은 의도 파악, 계획 수립, 도구 선택, 결과 해석을 담당하며, 도구 연결 계층은 LLM이 캘린더, 이메일, 데이터베이스, 파일 시스템, 브라우저, SaaS API 같은 외부 시스템을 사용할 수 있게 만든다.

MCP(Model Context Protocol)는 이 도구 연결 계층에서 중요한 역할을 하는 표준 프로토콜이다. MCP는 AI 애플리케이션과 외부 시스템을 연결하기 위한 오픈 표준이며, 특정 회사나 특정 모델에만 속한 기능으로 이해하면 부정확하다. Claude는 MCP를 적극적으로 지원하고, OpenAI도 Responses API와 Agents SDK에서 remote MCP server를 지원한다. 따라서 핵심 비교는 “OpenAI vs MCP”가 아니라 “애플리케이션 내부 함수 호출 방식(Function Calling / Tool Calling) vs 표준 프로토콜 기반 외부 도구 연결 방식(MCP)”으로 잡는 편이 정확하다.

간단히 말해, function calling은 애플리케이션이 모델에게 호출 가능한 함수 스키마를 알려주고, 모델이 호출 요청을 만들면 애플리케이션 코드가 그 함수를 실행하는 방식이다. MCP는 도구, 리소스, 프롬프트를 외부 서버 형태로 노출하고, 여러 AI 클라이언트가 같은 서버에 표준 방식으로 접속할 수 있게 하는 방식이다. 그래서 MCP는 에이전트의 두뇌가 아니라 에이전트가 외부 세계와 접속하는 인터페이스 계층이다.

문제의식

AI 에이전트를 이해할 때 흔히 발생하는 오해는 “LLM이 똑똑해지면 곧바로 모든 작업을 수행할 수 있다”는 생각이다. LLM은 텍스트를 이해하고 생성하는 능력이 뛰어나지만, 그 자체만으로는 메일을 보내거나, 데이터베이스를 조회하거나, 파일을 수정하거나, 캘린더 일정을 생성할 수 없다. 실제 작업 수행에는 외부 시스템에 대한 접근 권한, 도구 호출 방식, 실행 결과 회수, 오류 처리, 사용자 승인, 보안 통제가 필요하다.

이 때문에 AI 에이전트의 핵심은 단순히 “모델이 얼마나 똑똑한가”가 아니라 “모델이 어떤 실행 환경과 연결되어 있는가”에 있다. 동일한 LLM이라도 외부 도구가 없으면 대화형 조언자에 머무르지만, 안전하게 설계된 도구 연결 계층을 갖추면 업무 자동화 시스템, 분석 보조 시스템, 개발 에이전트, 개인 비서, 기업용 지식 에이전트로 확장될 수 있다.

MCP가 중요해진 이유도 여기에 있다. 기존에는 각 AI 앱이 특정 도구나 데이터 소스와 연결되기 위해 별도 커넥터를 직접 만들어야 했다. 예를 들어 하나의 AI 앱이 Slack, GitHub, Google Drive, Postgres, Jira, Notion과 연결되려면 각 서비스마다 별도의 통합 코드를 작성해야 했다. 다른 AI 앱이 같은 기능을 쓰려면 다시 비슷한 통합 작업을 반복해야 했다. MCP는 이런 파편화된 통합을 표준화하려는 시도다.

개념의 정의

AI 에이전트는 사용자 목표를 달성하기 위해 모델 추론, 작업 계획, 도구 사용, 실행 결과 해석을 반복하는 시스템이다. 여기서 “에이전트”라는 말은 단순 챗봇보다 넓은 의미를 갖는다. 단순 챗봇은 질문에 답하는 데 집중하지만, 에이전트는 외부 시스템을 사용해 상태를 바꾸거나 결과물을 생성한다. 예를 들어 “회의 일정을 잡아줘”라는 요청에서 에이전트는 캘린더를 조회하고, 가능한 시간을 찾고, 참석자를 초대하고, 이메일이나 메시지를 보내는 연속 작업을 수행할 수 있다.

LLM은 에이전트 시스템의 판단 엔진에 해당한다. LLM은 사용자의 자연어 요청을 해석하고, 필요한 작업을 추론하며, 어떤 도구를 호출할지 결정한다. 다만 LLM이 직접 외부 시스템을 실행하는 것은 아니다. LLM은 보통 “어떤 도구를 어떤 인자로 호출해야 하는지”를 제안하거나 구조화된 호출 요청을 생성한다. 실제 실행은 애플리케이션 런타임, 백엔드 서버, MCP 서버, 브라우저 자동화 계층, API 클라이언트 등이 담당한다.

도구 호출(tool calling)은 LLM이 외부 기능을 사용할 수 있게 하는 일반적 메커니즘이다. 여기에는 플랫폼별 function calling, 내장 도구(built-in tools), 원격 MCP 서버, 코드 실행기, 웹 검색 도구, 파일 검색 도구 등이 포함될 수 있다.

MCP는 Model Context Protocol의 약자다. MCP는 AI 애플리케이션이 외부 시스템에 접근하기 위해 사용할 수 있는 클라이언트-서버 기반 표준 프로토콜이다. MCP 서버는 도구(tools), 리소스(resources), 프롬프트(prompts)를 제공할 수 있고, MCP 클라이언트는 이를 발견하고 호출하거나 읽어온다. MCP 공식 문서는 MCP를 AI 애플리케이션과 외부 시스템을 연결하는 오픈소스 표준으로 설명한다.

배경과 맥락

LLM 초기 활용은 주로 텍스트 생성, 요약, 번역, 질의응답에 집중되어 있었다. 이 단계에서 모델은 사용자가 입력한 컨텍스트 안에서만 답할 수 있었다. 사용자가 문서를 붙여 넣지 않으면 문서 내용을 알 수 없고, 사용자가 최신 데이터를 제공하지 않으면 최신 상황을 반영하기 어려웠다. 또한 모델이 답변을 만들어도 그 답변은 외부 시스템에 실제로 반영되지 않았다.

이 한계를 줄이기 위해 검색 증강 생성(RAG), function calling, 플러그인, 코드 실행기, 브라우저 도구, 파일 검색 도구 같은 기술이 등장했다. RAG는 모델이 외부 문서나 벡터 데이터베이스에서 관련 정보를 검색해 답변하게 하는 방식이고, function calling은 모델이 구조화된 함수 호출을 제안하게 하는 방식이다. 플러그인이나 도구 API는 모델이 특정 외부 서비스를 사용할 수 있게 만든다.

MCP는 이 흐름의 연장선에 있다. Anthropic은 2024년에 MCP를 공개하면서, AI 시스템과 데이터 소스 사이의 연결을 개별 통합이 아니라 표준 프로토콜로 처리하려는 방향을 제시했다. 이후 Claude Desktop, Claude Code, 여러 개발 도구, OpenAI Agents SDK, OpenAI Responses API 등이 MCP 또는 remote MCP server 연결을 지원하면서 MCP는 특정 제품 기능을 넘어 AI 도구 연결 생태계의 공통 인터페이스 중 하나로 자리 잡았다.

현재의 핵심 변화는 “AI가 앱 안의 기능 하나를 호출하는 단계”에서 “AI가 여러 앱과 데이터 소스를 조합하는 단계”로 이동한다는 점이다. 과거의 앱 구조가 사용자가 직접 앱을 열고 기능을 선택하는 방식이었다면, 에이전트 기반 구조에서는 사용자가 목표를 말하고 AI가 필요한 도구들을 조합한다.

기존 구조
사용자 → 앱 → 기능

에이전트 기반 구조
사용자 → AI 에이전트 → 여러 앱과 도구

AI 에이전트 시스템의 전체 구조

AI 에이전트 시스템은 단일 모델 호출이 아니라 여러 계층이 결합된 실행 구조다. 가장 단순화하면 다음과 같이 볼 수 있다.

사용자
 ↓
사용자 인터페이스
 ↓
에이전트 오케스트레이터
 ↓
LLM
 ↓
도구 연결 계층
 ↓
외부 실행 시스템

사용자 인터페이스는 사용자가 요청을 입력하는 계층이다. 채팅창, 음성 인터페이스, 모바일 앱, 웹 앱, IDE, API 콘솔 등이 여기에 해당한다. 사용자는 보통 “다음 주 회의 일정을 잡고 참석자에게 메일을 보내줘”처럼 자연어로 목표를 표현한다.

에이전트 오케스트레이터는 요청을 실행 가능한 작업 흐름으로 바꾸는 계층이다. 오케스트레이터는 작업 계획, 작업 분해, 도구 선택, 상태 관리, 오류 처리, 반복 실행 루프를 담당한다. 실제 시스템에서는 이 역할이 별도의 오케스트레이션 프레임워크, Agents SDK, 애플리케이션 서버, 워크플로 엔진, 혹은 모델 호출 로직 안에 섞여 구현될 수 있다.

LLM은 요청의 의미를 해석하고 다음 행동을 결정하는 계층이다. 사용자의 목표를 이해하고, 필요한 정보를 질문하거나, 어떤 도구를 호출할지 선택하고, 도구 결과를 받아 최종 응답으로 정리한다. LLM은 작업의 의미론적 판단을 담당하지만, 실행 권한 자체를 가져서는 안 된다. 안전한 에이전트 설계에서는 LLM의 판단과 실제 실행 사이에 권한 검사, 사용자 승인, 정책 필터, 로깅 체계가 들어간다.

도구 연결 계층은 LLM과 외부 시스템 사이의 중간 계층이다. 여기에는 function calling, built-in tools, MCP, 브라우저 자동화, API wrapper, 코드 실행 환경 등이 포함된다. 이 계층은 모델이 외부 시스템을 사용할 수 있도록 스키마, 인증, 호출 방식, 입력 검증, 결과 반환 형식을 제공한다.

외부 실행 시스템은 실제 상태가 변하는 곳이다. 데이터베이스, SaaS, 파일 시스템, 이메일 서버, 캘린더, Git 저장소, 배포 시스템, 결제 시스템, 브라우저, 사내 API 등이 여기에 해당한다.

에이전트 오케스트레이터의 역할

에이전트 오케스트레이터는 AI 에이전트를 단순 질의응답 시스템과 구분하게 만드는 핵심 계층이다. 사용자의 목표는 대체로 추상적이고, 외부 시스템은 구체적 API 호출을 요구한다. 오케스트레이터는 이 둘 사이를 이어준다.

예를 들어 사용자가 다음과 같이 요청한다고 하자.

“다음 주 화요일 오후에 30분짜리 회의를 잡고, 참석자들에게 초대 메일도 보내줘.”

에이전트 내부에서는 다음과 같은 작업 분해가 필요하다.

1. 사용자의 캘린더 접근 권한 확인
2. 참석자 목록 확인
3. 다음 주 화요일의 시간대 계산
4. 가능한 시간 조회
5. 충돌이 적은 시간 후보 선택
6. 회의 생성
7. 참석자 초대
8. 이메일 또는 메시지 작성
9. 전송 전 사용자 승인 요청
10. 실행 결과 보고

이 과정에서 LLM은 자연어 이해와 판단을 담당하지만, 실제 캘린더 조회나 메일 전송은 외부 도구가 수행한다. 오케스트레이터는 어느 시점에 모델을 다시 호출할지, 어느 시점에 도구를 실행할지, 어떤 오류를 사용자에게 되물어야 할지, 어떤 작업은 승인 없이는 실행하지 말아야 할지를 관리한다.

따라서 좋은 에이전트 시스템은 “모델에게 모든 것을 맡기는 구조”가 아니라 “모델의 판단 능력을 제한된 실행 루프 안에 배치하는 구조”다. 이 구조가 없으면 에이전트는 환각, 잘못된 도구 선택, 권한 초과, 데이터 유출, 반복 실행 오류에 취약해진다.

LLM과 도구 사용의 관계

LLM은 외부 도구를 직접 실행하는 실행 주체라기보다, 도구 사용 결정을 생성하는 판단 주체에 가깝다. OpenAI function calling 흐름을 예로 들면, 애플리케이션은 먼저 모델에게 사용 가능한 함수 목록과 입력 스키마를 제공한다. 모델은 사용자 요청을 보고 특정 함수를 어떤 인자로 호출해야 하는지 구조화된 형태로 응답한다. 애플리케이션은 그 호출을 받아 실제 코드를 실행하고, 실행 결과를 다시 모델에게 전달한다. 모델은 그 결과를 해석해 사용자에게 최종 답변을 제공한다.

이 흐름을 단순화하면 다음과 같다.

1. 애플리케이션이 모델에게 사용 가능한 도구 목록 제공
2. 모델이 사용자 요청을 해석하고 도구 호출 제안
3. 애플리케이션이 도구 호출을 실제 코드로 실행
4. 실행 결과를 모델에게 다시 전달
5. 모델이 결과를 해석해 최종 응답 생성

이 구조에서 중요한 점은 “모델이 실행한다”와 “모델이 실행 요청을 생성한다”를 구분하는 것이다. 실제 실행을 어느 계층이 담당하는지에 따라 보안, 권한, 로깅, 오류 처리 방식이 달라진다. 민감한 작업에서는 모델의 도구 호출 요청을 곧바로 실행하지 않고, 사용자 승인이나 정책 검사를 거치는 것이 일반적으로 안전하다.

Function Calling / Tool Calling과 MCP의 차이

초안에서 가장 크게 다듬어야 할 부분은 “OpenAI Tools vs MCP”라는 비교 구도다. 이 구도는 입문적으로는 이해를 돕지만, 최신 구조를 설명하기에는 부정확하다. OpenAI도 function calling, built-in tools, tool search, remote MCP servers를 함께 지원하고, Claude 역시 자체 tool use와 MCP 연결을 함께 사용한다. 따라서 비교축은 회사가 아니라 연결 방식이어야 한다.

아래 표가 더 정확한 구분이다.

항목	Function Calling / Tool Calling	MCP
본질	모델이 호출할 함수 또는 도구 스키마를 애플리케이션에 등록하는 방식	AI 앱과 외부 시스템을 연결하는 표준 클라이언트-서버 프로토콜
실행 위치	보통 애플리케이션 코드나 백엔드가 실행 담당	MCP 서버가 도구, 리소스, 프롬프트를 제공하고 클라이언트가 호출
연결 범위	특정 앱 내부 함수, 백엔드 API, 제한된 서비스 연동에 적합	로컬·원격 서버, 데이터베이스, 파일 시스템, SaaS, 개발 도구 등으로 확장 가능
표준성	플랫폼별 구현 차이 존재	오픈 프로토콜 기반
재사용성	해당 애플리케이션에 묶이는 경우가 많음	여러 MCP 호스트와 클라이언트가 같은 서버를 공유 가능
적합한 경우	앱 안에서 제한된 기능을 명확하게 호출할 때	여러 AI 클라이언트가 같은 외부 도구·데이터 서버를 재사용해야 할 때

Function calling은 앱 내부에서 정의한 함수를 모델이 호출할 수 있게 하는 방식이다. 예를 들어 send_email, get_weather, query_database 같은 함수를 애플리케이션에 등록하면, 모델은 사용자 요청에 따라 그 함수 호출을 제안한다. 이 방식은 구현이 비교적 단순하고 특정 서비스에 맞춘 제어가 쉽다.

MCP는 외부 도구와 데이터를 서버 형태로 노출한다. AI 애플리케이션은 MCP 클라이언트를 통해 MCP 서버에 접속하고, 서버가 제공하는 도구, 리소스, 프롬프트를 발견한다. 도구 목록은 동적으로 바뀔 수 있고, 하나의 AI 애플리케이션은 여러 MCP 서버에 동시에 연결될 수 있다. 이 때문에 MCP는 단일 앱 내부 기능 호출보다 더 넓은 통합 생태계를 지향한다.

간단히 요약하면 다음과 같다.

Function Calling = 앱 내부에 등록한 함수를 모델이 호출하도록 하는 방식
MCP = 외부 도구·데이터·워크플로를 표준 서버로 노출하는 방식

MCP의 구조

MCP는 클라이언트-서버 구조를 갖는다. MCP 호스트는 Claude Code, Claude Desktop, IDE, ChatGPT 계열 앱, 사내 AI 앱처럼 사용자가 실제로 상호작용하는 AI 애플리케이션이다. MCP 클라이언트는 호스트 내부에서 MCP 서버와의 연결을 유지하는 구성요소다. MCP 서버는 외부 시스템과 연결된 도구, 리소스, 프롬프트를 제공하는 프로그램이다.

AI 애플리케이션(MCP Host)
 ├─ MCP Client → MCP Server A → GitHub / Git / 파일 시스템
 ├─ MCP Client → MCP Server B → Slack / Jira / Notion
 └─ MCP Client → MCP Server C → 데이터베이스 / 사내 API

MCP 서버는 로컬에서 실행될 수도 있고 원격 서버로 운영될 수도 있다. 로컬 MCP 서버는 사용자의 컴퓨터에서 파일 시스템이나 개발 도구와 연결되는 데 적합하다. 원격 MCP 서버는 SaaS, 클라우드 서비스, 사내 API, 데이터 플랫폼과 연결되는 데 적합하다.

MCP의 핵심 구성요소는 세 가지다.

첫째, 도구(tools)는 모델이 호출할 수 있는 실행 가능한 함수다. 예를 들어 searchFlights, query_database, send_email, create_ticket, run_test 같은 작업이 도구로 노출될 수 있다. 도구는 입력 스키마와 설명을 갖고, 모델은 이 설명을 바탕으로 어떤 도구를 호출할지 판단한다.

둘째, 리소스(resources)는 모델이 참고할 수 있는 데이터나 컨텍스트다. 파일 내용, 데이터베이스 레코드, API 응답, 문서, 캘린더 일정, 코드베이스 정보 등이 리소스가 될 수 있다. 도구가 “행동”에 가깝다면, 리소스는 “읽을 수 있는 정보”에 가깝다.

셋째, 프롬프트(prompts)는 재사용 가능한 상호작용 템플릿이다. 특정 워크플로를 시작하거나, 반복되는 업무 지시 형식을 표준화하거나, 도구와 리소스를 함께 사용하는 절차를 제공할 수 있다.

MCP 구조를 도식화하면 다음과 같다.

MCP Server
 ├─ tools
 │   ├─ search
 │   ├─ query_database
 │   ├─ send_email
 │   └─ create_ticket
 ├─ resources
 │   ├─ file://...
 │   ├─ database://...
 │   └─ api://...
 └─ prompts
     ├─ summarize_issue
     ├─ analyze_incident
     └─ draft_report

MCP는 내부적으로 JSON-RPC 기반의 데이터 계층과 전송 계층을 구분한다. 데이터 계층은 생명주기 관리, 기능 협상, tools/resources/prompts 같은 핵심 primitive를 다룬다. 전송 계층은 stdio나 Streamable HTTP 같은 통신 방식, 메시지 프레이밍, 인증 등을 담당한다. 이 분리는 MCP가 로컬 개발 환경과 원격 서버 환경을 모두 다룰 수 있게 한다.

OpenAI 구조에서 MCP의 위치

OpenAI 구조를 설명할 때는 “OpenAI = function calling”으로 단순화하지 않는 편이 좋다. OpenAI의 현재 도구 체계는 function calling만이 아니라 built-in tools, file search, web search, code interpreter, computer use, tool search, remote MCP servers 등을 포함한다. Responses API는 여러 도구 호출을 하나의 에이전트적 루프 안에서 처리하는 방향으로 설계되어 있다.

단순화한 OpenAI 기반 에이전트 구조는 다음과 같이 표현할 수 있다.

User
 ↓
Application / Responses API
 ↓
LLM
 ↓
Tools
 ├─ Built-in tools
 ├─ Function calling
 ├─ File search / Web search / Code interpreter
 └─ Remote MCP servers
 ↓
External systems

Function calling을 사용할 때는 애플리케이션이 함수 정의와 JSON 스키마를 제공하고, 모델이 호출 요청을 생성한다. Remote MCP server를 사용할 때는 Responses API의 도구 체계 안에서 MCP 서버를 연결하고, 모델이 MCP 서버가 제공하는 도구를 사용할 수 있다. 이 관점에서 MCP는 OpenAI와 대립하는 기술이 아니라 OpenAI 도구 체계 안에서도 사용할 수 있는 연결 방식이다.

Claude 구조에서 MCP의 위치

Claude는 MCP와 밀접하게 연결되어 소개되어 왔기 때문에 “Claude = MCP”처럼 이해되기 쉽다. 실제로 Claude Desktop, Claude Code, Anthropic 문서는 MCP 서버를 통해 외부 도구, 데이터베이스, API에 연결하는 흐름을 적극적으로 설명한다. Claude Code는 MCP 서버를 연결하면 이슈 트래커, 모니터링 대시보드, 데이터베이스, Figma, Slack, GitHub 같은 외부 시스템을 읽고 작업할 수 있다고 설명한다.

단순화한 Claude + MCP 구조는 다음과 같다.

User
 ↓
Claude / Claude Code / Claude Desktop
 ↓
MCP Client
 ↓
MCP Server
 ↓
External tools, APIs, databases, files

이 구조는 Claude가 MCP 생태계의 중요한 클라이언트라는 점을 보여준다. 그러나 MCP가 Claude 전용이라는 뜻은 아니다. MCP는 특정 모델 회사의 독점 기능이 아니라, 여러 AI 애플리케이션이 외부 시스템에 연결하기 위한 표준 인터페이스로 확장되고 있다.

실제 AI 에이전트 예시

사용자가 다음과 같이 요청한다고 하자.

“이번 달 매출 보고서를 만들어서 팀에 공유해줘.”

잘 설계된 에이전트는 이 요청을 다음과 같이 분해할 수 있다.

1. 보고서 범위 확인: 이번 달, 매출, 팀 공유
2. 데이터 소스 확인: CRM, 결제 DB, 회계 시스템, 스프레드시트
3. 권한 확인: 사용자가 해당 데이터에 접근할 수 있는지 확인
4. 데이터 조회: 매출, 환불, 신규 고객, 반복 구매, 지역별 매출
5. 분석 실행: 전월 대비 변화, 주요 원인, 이상치 탐지
6. 시각화 생성: 표, 그래프, 요약 지표
7. 문서 작성: 보고서 초안 생성
8. 사용자 검토 요청: 민감 정보와 수치 확인
9. 공유 실행: 이메일, Slack, Notion, Google Drive 등으로 배포

이때 LLM은 보고서의 구조를 설계하고, 어떤 데이터를 가져올지 판단하고, 분석 결과를 문장으로 해석한다. 데이터 조회는 MCP 서버나 function calling으로 연결된 API가 수행한다. 그래프 생성은 코드 실행 도구가 담당할 수 있다. 문서 저장은 파일 시스템 또는 문서 서비스 API가 담당한다. 공유는 이메일 또는 메시징 도구가 담당한다.

이 예시는 에이전트가 단일 도구 호출이 아니라 여러 도구 호출의 조합으로 작동한다는 점을 보여준다.

User
 ↓
Agent Orchestrator
 ↓
LLM
 ↓
Tool Layer
 ├─ MCP Server: CRM / DB
 ├─ Code Interpreter: 분석 / 그래프
 ├─ File Tool: 보고서 저장
 └─ Email / Slack Tool: 공유
 ↓
Final Report

MCP가 중요한 이유

MCP의 가장 큰 의미는 도구 연결을 재사용 가능한 표준 인터페이스로 바꾸려는 데 있다. AI 앱이 많아지고 외부 시스템이 많아질수록, 각 앱과 각 도구를 일대일로 연결하는 방식은 유지보수 비용이 커진다. MCP는 MCP 서버라는 공통 접점을 만들어 여러 AI 클라이언트가 같은 외부 시스템에 접근할 수 있게 한다.

MCP는 개발자에게 통합 비용을 줄여준다. 하나의 MCP 서버를 만들면 여러 AI 클라이언트가 이를 사용할 수 있기 때문이다. 기업 입장에서는 데이터베이스, 문서 저장소, 업무 도구를 표준 인터페이스로 노출할 수 있다. 사용자 입장에서는 AI가 복사·붙여넣기 없이 실제 업무 시스템과 연결되어 더 유용한 작업을 수행할 수 있다.

또한 MCP는 도구와 리소스의 발견(discovery)을 동적으로 처리할 수 있다. AI 애플리케이션은 연결된 MCP 서버에서 사용할 수 있는 도구 목록을 조회하고, 도구 설명과 입력 스키마를 바탕으로 적절한 호출을 구성한다. 서버의 도구 목록이 바뀌면 클라이언트가 이를 갱신할 수 있다. 이 점은 고정된 함수 목록을 애플리케이션 내부에 직접 등록하는 방식과 구분된다.

보안과 거버넌스

MCP와 AI 에이전트의 도구 사용은 강력하지만, 동시에 보안 위험을 키운다. 에이전트가 외부 도구를 사용할 수 있다는 것은 모델의 출력이 실제 시스템 상태를 바꿀 수 있다는 뜻이다. 파일 삭제, 이메일 전송, 데이터베이스 수정, 코드 실행, 배포, 결제 같은 작업이 연결되면 잘못된 호출의 비용이 커진다.

가장 중요한 위험은 프롬프트 인젝션(prompt injection)과 도구 오용이다. 예를 들어 외부 문서나 웹페이지, 이메일, 이슈 트래커 안에 악의적 지시가 들어 있고, 모델이 이를 신뢰하면 의도하지 않은 도구 호출을 수행할 수 있다. 도구 설명 자체가 악의적으로 설계되거나, 도구 출력이 다음 모델 호출에 영향을 주는 방식으로 조작될 수도 있다.

따라서 안전한 에이전트 시스템에는 다음 원칙이 필요하다.

첫째, 최소 권한 원칙을 적용해야 한다. 에이전트가 필요하지 않은 데이터와 기능에 접근하지 못하게 해야 한다. 읽기 전용 작업과 쓰기 작업을 분리하고, 민감한 쓰기 작업에는 별도 승인을 요구하는 편이 안전하다.

둘째, 사용자 승인 절차가 필요하다. 이메일 전송, 파일 삭제, 데이터 수정, 외부 공개, 결제, 배포처럼 되돌리기 어렵거나 민감한 작업은 실행 전에 사용자에게 입력값과 예상 결과를 보여줘야 한다.

셋째, 도구 입력과 출력을 검증해야 한다. LLM이 만든 인자는 신뢰할 수 없는 입력으로 취급해야 하며, SQL injection, command injection, path traversal, 권한 없는 리소스 접근 가능성을 검증해야 한다. 도구 출력 역시 다음 모델 호출의 컨텍스트가 될 수 있으므로 악의적 지시가 포함될 수 있다고 보아야 한다.

넷째, 로깅과 감사 가능성이 필요하다. 어떤 모델이 어떤 요청에서 어떤 도구를 어떤 인자로 호출했고, 결과가 무엇이었는지 기록해야 한다. 에이전트가 실제 업무 시스템과 연결될수록 추적 가능성은 선택 사항이 아니라 운영 조건이 된다.

다섯째, 신뢰할 수 없는 MCP 서버를 무분별하게 연결하지 않아야 한다. MCP 서버는 외부 시스템에 대한 접근점을 제공하므로, 서버의 출처, 코드, 권한 범위, 업데이트 정책, 인증 방식, 로그 처리 방식을 확인해야 한다.

주요 쟁점과 반론

첫 번째 쟁점은 MCP가 기존 API 통합을 완전히 대체할 수 있는가이다. MCP는 여러 AI 애플리케이션이 공통 방식으로 도구와 데이터에 접근하게 해주는 장점이 있지만, 모든 통합을 자동으로 해결하지는 않는다. 실제 서비스 연동에는 인증, 권한, 데이터 모델, 오류 처리, rate limit, 감사 로그, 서비스별 정책 문제가 남아 있다. MCP는 통합의 형식을 표준화하지만, 비즈니스 로직과 보안 정책을 대신 설계해주지는 않는다.

두 번째 쟁점은 function calling과 MCP의 관계다. 둘은 경쟁 관계로만 볼 수 없다. Function calling은 앱 내부의 명확한 함수 호출에 적합하고, MCP는 여러 클라이언트가 재사용할 수 있는 외부 도구 서버에 적합하다. 실제 시스템에서는 두 방식을 함께 사용할 수 있다. 예를 들어 애플리케이션 내부의 작은 유틸리티는 function calling으로 처리하고, 조직 전체가 공유하는 데이터베이스나 업무 도구는 MCP 서버로 노출할 수 있다.

세 번째 쟁점은 에이전트의 자율성이다. 도구 연결이 많아질수록 에이전트가 더 많은 작업을 수행할 수 있지만, 모든 작업을 자동 승인하는 구조는 위험하다. 에이전트의 유용성은 자율성에서 나오지만, 신뢰성은 제약과 승인 구조에서 나온다. 좋은 시스템은 모든 것을 막는 구조도, 모든 것을 자동 실행하는 구조도 아니다. 작업의 위험도에 따라 자동 실행, 사용자 확인, 관리자 승인, 실행 금지를 구분해야 한다.

네 번째 쟁점은 모델 지능과 도구 연결 능력의 우선순위다. 매우 강력한 모델도 도구 접근이 없으면 실제 업무 시스템을 바꿀 수 없다. 반대로 도구가 많아도 모델이 도구의 의미를 제대로 이해하지 못하면 잘못된 호출이 증가한다. 따라서 에이전트 품질은 모델 성능, 도구 설계, 스키마 명확성, 권한 통제, 실행 루프 설계가 결합된 결과다.

오해와 한계

MCP를 “Claude 전용 기능”으로 이해하는 것은 현재 구조와 맞지 않는다. Claude가 MCP를 적극적으로 지원하고 MCP 공개의 출발점이 Anthropic이었다는 점은 맞지만, MCP 자체는 AI 애플리케이션과 외부 시스템을 연결하기 위한 오픈 표준으로 확장되고 있다. OpenAI도 remote MCP server를 지원하므로, MCP를 특정 회사의 폐쇄 기능으로 설명하면 부정확해진다.

MCP를 “AI 에이전트의 두뇌”로 이해하는 것도 적절하지 않다. 에이전트의 판단은 LLM과 오케스트레이터가 담당하고, MCP는 외부 도구와 데이터를 표준 방식으로 연결하는 인터페이스다. MCP 서버가 도구를 제공하더라도, 어떤 도구를 언제 호출할지, 결과를 어떻게 해석할지는 에이전트 시스템 전체의 설계에 달려 있다.

Function calling을 “낡은 방식”으로 보는 것도 단순화다. 특정 애플리케이션 내부에서 제한된 함수를 호출해야 하는 경우 function calling은 여전히 단순하고 강력하다. MCP는 재사용성과 표준화가 필요한 경우 강점을 갖지만, 작은 기능 하나를 위해 항상 MCP 서버를 만드는 것이 최선은 아니다.

AI 에이전트가 외부 도구를 연결하면 곧바로 완전 자동화가 가능하다는 생각도 조심해야 한다. 실제 자동화에는 권한, 인증, 예외 처리, 데이터 품질, 업무 규칙, 사용자 승인, 법적 책임, 보안 감사가 필요하다. 특히 기업 환경에서는 “도구가 연결되어 있다”는 사실보다 “누가, 어떤 조건에서, 어떤 범위까지 실행할 수 있는가”가 더 중요하다.

정리

AI 에이전트 시스템의 핵심은 LLM이 외부 도구를 사용해 실제 작업을 수행하도록 만드는 전체 루프에 있다. 이 루프는 사용자 요청, 작업 계획, 모델 추론, 도구 호출, 실행 결과 회수, 결과 해석, 사용자 승인, 로깅으로 구성된다. 따라서 에이전트는 단순한 챗봇이 아니라 모델과 실행 시스템을 연결한 작업 수행 구조다.

MCP는 이 구조에서 도구 연결 계층을 표준화하는 역할을 한다. MCP 서버는 도구, 리소스, 프롬프트를 제공하고, MCP 클라이언트는 이를 발견하고 호출한다. 이 방식은 여러 AI 애플리케이션이 같은 외부 도구와 데이터 소스를 재사용할 수 있게 한다.

가장 중요한 개념 구분은 “OpenAI vs MCP”가 아니라 “Function Calling / Tool Calling vs MCP”다. OpenAI와 Claude는 모두 LLM이 도구를 사용하는 구조를 갖고 있으며, 두 생태계 모두 MCP와 연결될 수 있다. Function calling은 앱 내부 함수 호출 방식이고, MCP는 외부 도구·데이터·워크플로를 표준 서버로 노출하는 방식이다.

결론적으로, AI 에이전트의 본질은 “LLM + Tool System + Execution Loop”다. 모델은 판단을 담당하고, 도구는 실행을 담당하며, 오케스트레이터는 전체 절차와 상태를 관리한다. MCP는 이 중에서도 에이전트가 외부 세계와 접속하는 인터페이스를 표준화하는 기술이다.

참고자료

• 사용자 제공 초안, 「붙여넣은 마크다운(1).md」, 2026년 5월 5일 제공.
• Model Context Protocol, “What is the Model Context Protocol (MCP)?”, Model Context Protocol Documentation, 확인일 2026년 5월 5일. https://modelcontextprotocol.io/docs/getting-started/intro
• Model Context Protocol, “Architecture overview”, Model Context Protocol Documentation, 확인일 2026년 5월 5일. https://modelcontextprotocol.io/docs/learn/architecture
• Model Context Protocol, “Understanding MCP servers”, Model Context Protocol Documentation, 확인일 2026년 5월 5일. https://modelcontextprotocol.io/docs/learn/server-concepts
• Model Context Protocol, “Security Best Practices”, Model Context Protocol Documentation, 확인일 2026년 5월 5일. https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
• Anthropic, “Introducing the Model Context Protocol”, Anthropic News, 2024년 11월 25일. https://www.anthropic.com/news/model-context-protocol
• Anthropic, “Donating the Model Context Protocol and establishing the Agentic AI Foundation”, Anthropic News, 2025년 12월 9일. https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
• Anthropic, “Connect Claude Code to tools via MCP”, Claude Code Documentation, 확인일 2026년 5월 5일. https://code.claude.com/docs/en/mcp
• OpenAI, “Using tools”, OpenAI API Documentation, 확인일 2026년 5월 5일. https://developers.openai.com/api/docs/guides/tools
• OpenAI, “Function calling”, OpenAI API Documentation, 확인일 2026년 5월 5일. https://developers.openai.com/api/docs/guides/function-calling
• OpenAI, “MCP and Connectors”, OpenAI API Documentation, 확인일 2026년 5월 5일. https://developers.openai.com/api/docs/guides/tools-connectors-mcp
• OpenAI, “Migrate to the Responses API”, OpenAI API Documentation, 확인일 2026년 5월 5일. https://developers.openai.com/api/docs/guides/migrate-to-responses
• OpenAI, “Model context protocol (MCP)”, OpenAI Agents SDK Documentation, 확인일 2026년 5월 5일. https://openai.github.io/openai-agents-python/mcp/
• Brandon Radosevich and John Halloran, “MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits”, arXiv, 2025. https://arxiv.org/abs/2504.03767