MCP와 Tool의 차이, 한 번에 끝내기

2026-01-31

“Tool은 ‘기능’, MCP는 ‘연결 표준’… 에이전트 개발이 갑자기 쉬워지는 이유”

에이전트(Agentic AI)를 만들다 보면 거의 100% 이런 질문을 하게 됩니다.
“우리는 이미 tool calling(함수 호출)을 쓰고 있는데, MCP(Model Context Protocol)는 도대체 뭐가 다른 거지?”

결론부터 말하면 이렇습니다.

Tool(툴): 에이전트가 실행할 수 있는 개별 기능(예: send_email, search_docs)
Tool calling (툴/함수 호출): 모델이 “이 기능을 써야겠다” 판단하면, 호스트 앱이 그 함수를 실행하고 결과를 다시 모델에 넣는 호출 방식
MCP: 여러 툴/데이터/프롬프트를 “어떻게 발견하고, 어떻게 연결하고, 어떻게 안전하게 주고받을지”를 표준화한 연결 프로토콜(규격)

즉, Tool은 ‘무엇을 할 수 있나’이고, MCP는 ‘그걸 어디서/어떻게/표준 방식으로 가져다 쓰나’에 가깝습니다.

1) Tool이란 무엇인가? “에이전트의 손과 발”

Tool은 정말 말 그대로 기능 단위입니다.
예를 들어:

get_weather(city)
query_crm(sql)
create_jira_ticket(title, body)
read_file(path)

모델은 스스로 코드를 실행할 수 없기 때문에, “외부 세계에서 뭔가를 하려면” 반드시 이런 도구(함수/API)가 필요합니다.

2) Tool calling이란? “모델이 호출하고, 앱이 실행한다”

OpenAI 문서에서 tool calling(함수 호출)은 대략 이런 5단계 흐름으로 설명됩니다.

앱이 모델에게 “이런 tools를 쓸 수 있어”라고 정의를 전달
모델이 “그럼 이 tool을 호출할게”라고 tool call을 반환
앱(호스트)이 실제 코드를 실행
실행 결과를 다시 모델에게 전달
모델이 최종 답변(또는 추가 tool call)

여기서 핵심은: tool call은 ‘의사결정’이고, 실행은 항상 앱이 한다는 점입니다.
그래서 tool calling만으로도 충분히 훌륭한 에이전트를 만들 수 있어요. 단, 규모가 커지면 문제가 생깁니다.

3) MCP란? “도구·데이터·프롬프트를 표준 규격으로 연결하는 프로토콜”

MCP는 Anthropic이 중심이 되어 제안한 오픈 표준으로, LLM 애플리케이션이 외부 시스템(도구/데이터)에 연결되는 방식을 표준화합니다.

MCP 공식 문서는 MCP를 크게 두 레이어로 나눕니다.

Data layer: JSON-RPC 기반의 메시지/라이프사이클/기본 프리미티브(툴, 리소스, 프롬프트 등)
Transport layer: 실제 통신(연결/프레이밍/권한 부여 등)

그리고 MCP는 아키텍처 관점에서 Host–Client–Server 구조를 강조합니다.
이 구조 덕분에, 어떤 앱(IDE, 데스크톱 에이전트, 워크플로우 런타임)이든 MCP client만 붙이면 동일한 MCP 서버들을 재사용할 수 있게 됩니다.

4) MCP가 Tool과 “결정적으로 다른 지점” 3가지

차이 1) Tool은 “기능 하나”, MCP는 “그 기능들을 유통·연결하는 규격”

Tool은 개별 함수입니다.
MCP는 그 함수들을 서버가 노출(expose)하고, 클라이언트가 발견(discover)하고, 표준 방식으로 호출(call)하게 만드는 규격입니다.

비유하면

Tool = 전동드릴(도구)

Tool calling = 전동드릴 사용법(버튼 누르면 돌아감)

MCP = 콘센트/플러그 규격(어디서든 꽂아 쓰게 해줌)

차이 2) MCP는 Tools뿐 아니라 Resources/Prompts까지 “같은 표준으로” 다룬다

MCP 서버는 보통 세 가지를 제공합니다: Tools / Resources / Prompts.

Resources: 모델이 참고할 데이터(문서, DB 레코드, 파일 등)
Prompts: 서버가 제공하는 프롬프트 템플릿(업무 템플릿/가드레일 포함 가능)

즉 MCP는 “함수 호출 표준”에 그치지 않고, 맥락(Context) 자체를 배포하는 표준에 더 가깝습니다.

차이 3) MCP는 “포터블(이식 가능)한 툴 생태계”를 만든다

tool calling만 쓰면, 대개 툴 정의/스키마/인증/에러 처리 방식이 앱마다 달라져 재사용이 어렵습니다. MCP는 이 지점을 표준화해 “한 번 만든 서버를 여러 호스트/클라이언트에서 쓰는” 방향을 지향합니다.

5) 한 장으로 정리: MCP vs Tool(Calling)

구분	Tool	Tool calling	MCP
한 줄 정의	기능(함수/API)	모델이 툴 호출을 “요청”하는 흐름	툴/데이터/프롬프트를 표준으로 “연결”하는 프로토콜
범위	1개 기능	1개 앱 내부 흐름	여러 앱·여러 서버 생태계
핵심 가치	“할 수 있는 일”	“모델↔앱 실행 루프”	“발견/연결/재사용/운영 표준화”
표준화 대상	기능 자체	호출 절차(플랫폼별)	메시지/라이프사이클/전송/프리미티브

6) 언제 MCP를 쓰고, 언제 tool calling만으로 충분할까?

tool calling만으로 충분한 경우

툴이 5개 이하이고
에이전트가 1~2개 앱에서만 돌아가고
통합이 “내 서비스 내부”에서 끝나는 경우

이때는 MCP 서버까지 분리하는 게 오히려 과합니다. (관리 포인트가 늘어남)

MCP가 빛나는 경우

여러 에이전트/여러 클라이언트(IDE, 데스크톱, 봇)가 같은 도구/데이터를 공유해야 하고
툴이 계속 늘어나며
인증/권한/감사 로그 같은 운영 요구가 커지는 경우

즉 “조직 단위 에이전트 플랫폼”으로 가는 순간 MCP의 효용이 확 커집니다.

7) 결론

MCP와 tool의 관계는 경쟁이 아니라 레이어가 다릅니다.

Tool은 기능이고,
Tool calling은 그 기능을 실행하는 대화 루프이며,
MCP는 그 기능(그리고 데이터/프롬프트)을 여러 앱에서 재사용 가능하게 만드는 표준 연결 방식입니다.