MCP와 function calling 비교는 AI 에이전트를 만들 때 자주 나오는 질문입니다. 둘 다 도구 호출과 관련 있지만, 같은 역할을 하는 기술은 아닙니다.
핵심은 function calling은 모델이 어떤 도구를 호출할지 표현하는 방식이고, MCP는 외부 도구를 연결하는 표준 프로토콜이라는 점입니다. 서로 경쟁한다기보다 다른 층에서 만납니다.
MCP와 function calling을 나누는 기준
function calling은 모델 입출력의 약속에 가깝다
OpenAI의 function calling 문서는 모델이 애플리케이션 코드에서 정의한 함수 호출에 맞는 구조화된 인자를 생성할 수 있다고 설명합니다. 즉 모델이 ‘이 함수가 필요하다’고 말할 수 있게 하는 인터페이스입니다.
{
"name": "get_weather",
"arguments": {
"city": "Seoul"
}
}여기서 실제 날씨 API를 호출하고 결과를 다시 모델에게 주는 일은 애플리케이션이 맡습니다. function calling은 모델이 도구 호출 의도를 구조화해서 내보내는 방법에 가깝습니다.
MCP는 도구를 어디서 어떻게 가져올지의 문제다
Model Context Protocol의 공식 소개는 MCP를 AI 앱이 외부 데이터 소스와 도구에 연결하기 위한 표준 방식으로 설명합니다. MCP는 특정 함수 하나를 호출하는 형식보다 더 넓은 연결 규격입니다.
예를 들어 파일 시스템, GitHub, Notion, 사내 DB 같은 기능을 MCP server로 노출하고, AI 앱은 MCP client로 연결할 수 있습니다. 이때 server는 tools, resources, prompts 같은 기능을 제공할 수 있습니다.
둘은 서로 대체 관계가 아니다
function calling이 있으면 MCP가 필요 없고, MCP가 있으면 function calling이 필요 없는 식으로 보면 헷갈립니다. function calling은 모델이 도구 호출을 선택하고 인자를 만드는 층에 가깝고, MCP는 그 도구들이 앱 밖에서 어떻게 제공되고 발견되는지의 층에 가깝습니다.
실제 시스템에서는 모델이 function/tool calling으로 어떤 작업을 선택하고, 애플리케이션이 MCP server에 연결된 도구를 실행하는 구조가 될 수 있습니다.
설계할 때 먼저 물어볼 질문
- 모델에게 어떤 함수 인자 형식을 만들게 할 것인가?
- 도구 구현은 앱 내부 코드에 둘 것인가, 외부 서버로 분리할 것인가?
- 도구 목록과 권한을 누가 관리할 것인가?
- 도구 실행 로그와 실패 처리를 어디서 볼 것인가?
- 사용자 승인이나 보안 검토가 필요한 도구는 무엇인가?
보안 경계는 더 중요해진다
MCP를 쓰면 도구를 붙이는 방식은 표준화될 수 있지만, 모든 도구를 안전하게 만들어주지는 않습니다. 파일 읽기, 명령 실행, 외부 API 호출 같은 기능은 권한, 감사 로그, 사용자 승인 흐름이 필요합니다.
이 기준은 Tool calling은 어디까지 맡겨야 안전할까 글에서 다룬 승인과 실패 처리 문제와도 이어집니다.
예제로 보는 책임 분리
사내 문서 검색 도구를 붙인다고 가정해 보겠습니다. function calling만 보면 모델이 search_docs라는 함수를 고르고 검색어를 만드는 일이 핵심입니다. MCP까지 보면 그 검색 도구가 어떤 서버에서 제공되고, 어떤 리소스와 권한을 노출하는지가 함께 설계 대상이 됩니다.
사용자 질문
-> 모델: 어떤 도구가 필요한지 판단
-> function/tool calling: search_docs(query) 형태로 호출 의도 생성
-> 애플리케이션: MCP server의 tool 실행
-> MCP server: 문서 검색 결과 반환
-> 모델: 결과를 근거로 답변 생성이 흐름에서 function calling은 모델과 애플리케이션 사이의 호출 의도 표현에 가깝고, MCP는 애플리케이션과 외부 도구 서버 사이의 연결 규격에 가깝습니다.
운영에서 더 중요한 질문
- 이 도구를 모든 사용자에게 열어도 되는가?
- 도구 결과를 모델에게 그대로 넘겨도 되는가, 필터링이 필요한가?
- 도구 호출 실패 시 재시도할지, 사용자에게 확인을 받을지 정했는가?
- 도구가 파일, 결제, 배포처럼 외부 상태를 바꿀 수 있는가?
- 도구 호출 로그와 입력값을 나중에 감사할 수 있는가?
잘못된 설계 예시
MCP server를 붙였다는 이유만으로 위험한 도구를 모두 모델에게 열어두면 문제가 생깁니다. 예를 들어 파일 삭제, 배포, 결제 요청처럼 되돌리기 어려운 작업은 도구가 표준 프로토콜로 연결되어 있더라도 별도의 승인 흐름이 필요합니다.
반대로 모든 도구를 애플리케이션 내부 함수로만 묶어두면 도구 재사용과 관리가 어려워질 수 있습니다. 여러 클라이언트가 같은 도구를 써야 한다면 MCP server로 분리하는 편이 운영상 더 자연스러울 수 있습니다.
정리
MCP와 function calling은 같은 층의 단어가 아닙니다. function calling은 모델이 도구 호출을 표현하는 방식이고, MCP는 AI 앱이 외부 도구와 데이터에 연결되는 표준 프로토콜입니다. 둘을 구분하면 AI 에이전트 구조에서 모델, 앱, 도구 서버의 책임을 더 명확하게 나눌 수 있습니다.
