MCP 가이드: AI가 외부 도구와 데이터를 연결하는 표준 이해하기
AI
마지막 업데이트

MCP 가이드: AI가 외부 도구와 데이터를 연결하는 표준 이해하기

AI agent, 코딩 어시스턴트, tool-using LLM을 공부하다 보면 MCP라는 말을 자주 만나게 됩니다. 처음 보면 또 하나의 약어처럼 느껴지지만, 실제로는 꽤 중요한 질문과 연결됩니다. 모델은 어떻게 파일, 문서, API, 데이터베이스, 앱 상태 같은 바깥 세계와 안전하고 일관된 방식으로 연결될까?

LLM은 텍스트를 생성하는 데 강하지만, 우리의 로컬 파일이나 사내 위키, 외부 서비스 상태를 자동으로 아는 것은 아닙니다. 최근 사내에서 코딩 어시스턴트를 세팅하면서 느낀 건, GitHub repo 연동 하나, Jira 연동 하나, 사내 문서 검색 하나를 각각 다른 방식으로 붙이니까 유지보수가 금방 지옥이 됐다는 점입니다. MCP를 도입하고 나서야 “서버 하나 추가 = 설정 파일 한 줄 추가”로 줄었습니다. 실제 일을 하게 하려면 바깥 세계와 연결되는 인터페이스가 필요합니다. MCP는 바로 그 연결을 더 표준화된 방식으로 다루려는 접근입니다.

이 글에서는 아래를 정리합니다.

  • MCP가 정확히 무엇인지
  • 왜 AI 애플리케이션에서 점점 중요해지는지
  • host, client, server가 어떻게 역할을 나누는지
  • tools, resources, prompts가 각각 무엇인지
  • agent, RAG, 일반 API 호출과는 무엇이 다른지

핵심만 먼저 말하면 이렇습니다. MCP는 모델이 외부 도구와 데이터에 접근할 때 사용하는 공통 연결 규약에 가깝고, 복잡한 AI 앱의 연결층을 덜 제각각으로 만들기 위해 쓰입니다.

MCP란 무엇인가

MCP는 Model Context Protocol의 줄임말입니다. 이름 그대로 보면 “모델에게 컨텍스트를 제공하는 프로토콜”인데, 실제로는 컨텍스트뿐 아니라 외부 도구와 프롬프트까지 포함하는 더 넓은 연결 규약으로 이해하는 편이 좋습니다.

쉽게 말하면 MCP는 AI 애플리케이션이 아래 같은 외부 요소와 연결될 때 쓸 수 있는 표준화된 인터페이스입니다.

  • 로컬 파일
  • 데이터베이스 스키마나 레코드
  • 사내 문서 저장소
  • 검색, 계산, 조회 같은 도구
  • 재사용 가능한 프롬프트 템플릿

공식 문서에서도 MCP를 “AI 앱을 외부 시스템에 연결하는 오픈 표준”으로 설명합니다. 종종 USB-C 비유가 함께 나오는데, 핵심은 비유 자체보다 연결 방법을 제각각 만들지 말고 가능한 한 공통 규약으로 맞추자는 생각입니다.

왜 MCP가 중요한가

초기 프로토타입 단계에서는 모델 하나에 프롬프트를 넣고 응답을 받는 것만으로도 충분할 수 있습니다. 하지만 실제 제품은 금방 아래 요구가 생깁니다.

  • 프로젝트 파일을 읽어야 한다
  • 여러 문서 저장소를 검색해야 한다
  • 사내 시스템에서 최신 상태를 조회해야 한다
  • 특정 툴을 호출해 작업을 실행해야 한다
  • 어떤 데이터가 노출되는지 권한을 분리해야 한다

이걸 전부 제품마다 각자 다른 방식으로 붙이면 곧 문제가 생깁니다.

  • 도구마다 연결 방식이 다르다
  • 권한 범위를 통일하기 어렵다
  • 모델이 무엇을 볼 수 있는지 추적하기 어렵다
  • 새 도구를 붙일 때마다 구현이 중복된다
  • 클라이언트 앱을 바꾸면 통합 비용이 다시 생긴다

MCP가 주목받는 이유는 이런 혼란을 줄이기 위해서입니다. 즉, 모델과 외부 세계 사이의 연결층을 좀 더 공통된 방식으로 표현하고 관리하려는 시도라고 볼 수 있습니다.

MCP의 기본 구조: host, client, server

MCP를 이해할 때 가장 먼저 잡아야 하는 그림은 host-client-server 구조입니다.

1. Host

host는 사용자가 직접 상호작용하는 AI 애플리케이션입니다. 예를 들면 IDE, 데스크톱 AI 앱, 코딩 도구 같은 것이 여기에 해당할 수 있습니다.

host는 전체 경험을 관리합니다.

  • 사용자 요청을 받는다
  • 어떤 MCP 서버와 연결할지 관리한다
  • 권한과 승인 흐름을 통제한다
  • 여러 소스에서 들어온 컨텍스트를 합친다

2. Client

client는 host 안에서 특정 MCP 서버와 통신하는 연결 단위입니다. 공식 아키텍처 설명에서는 host가 서버마다 하나의 client 연결을 만든다고 이해하면 가장 쉽습니다.

즉, client는 아래 역할을 합니다.

  • 서버와 세션을 맺는다
  • 어떤 기능을 지원하는지 협상한다
  • 요청과 응답을 주고받는다
  • 알림과 변경 사항을 처리한다

사용자 입장에서는 host만 보이지만, 내부적으로는 host가 여러 client를 통해 여러 서버에 연결될 수 있습니다.

3. Server

server는 실제 컨텍스트나 기능을 제공하는 쪽입니다. 예를 들면 파일 시스템 서버, GitHub 서버, 문서 검색 서버, 데이터 조회 서버처럼 생각할 수 있습니다.

server는 보통 아래를 제공합니다.

  • 읽을 수 있는 데이터
  • 호출할 수 있는 도구
  • 재사용 가능한 프롬프트

즉, host가 “무엇을 하고 싶은가”를 조율하는 쪽이라면, server는 “무엇을 보여 줄 수 있고 무엇을 실행할 수 있는가”를 제공하는 쪽입니다.

MCP의 핵심 primitives: tools, resources, prompts

MCP를 이해하는 가장 좋은 방법은 이 세 가지 primitive를 구분하는 것입니다.

1. Tools

tools는 모델이 실행할 수 있는 기능입니다.

예를 들면:

  • 현재 날씨 조회
  • 데이터베이스 검색
  • 파일 생성
  • 이슈 등록
  • 외부 API 호출

공식 문서 기준으로 tools는 model-controlled에 가깝게 설명됩니다. 즉, 모델이 문맥과 사용자 요청을 보고 어떤 도구를 호출할지 선택할 수 있는 형태입니다. 다만 실제 제품에서는 승인 UI나 human-in-the-loop가 매우 중요합니다.

쉽게 말하면 tools는 모델이 세상에 행동하는 손에 가깝습니다.

2. Resources

resources는 모델이 읽을 수 있는 데이터입니다.

예를 들면:

  • 파일 내용
  • 데이터베이스 스키마
  • 문서 본문
  • 애플리케이션 상태 정보

resources는 보통 application-driven 또는 host-driven 성격이 강합니다. 즉, 어떤 리소스를 언제 포함할지는 host 애플리케이션이 결정하는 경우가 많습니다.

쉽게 말하면 resources는 모델이 참고할 수 있는 읽기 전용 컨텍스트 창고에 가깝습니다.

3. Prompts

prompts는 재사용 가능한 프롬프트 템플릿입니다.

예를 들면:

  • 코드 리뷰 요청용 템플릿
  • 장애 분석 시작 템플릿
  • 특정 형식으로 문서를 요약하는 템플릿

공식 개념 설명에서는 prompts를 user-controlled 성격으로 소개합니다. 즉, 사용자가 선택해서 불러 쓰는 템플릿에 가깝습니다.

쉽게 말하면 prompts는 반복되는 작업을 정형화하는 인터랙션 템플릿입니다.

MCP는 그냥 API 호출과 무엇이 다를까

이 부분에서 가장 많이 헷갈립니다. API 호출 자체는 오래전부터 있었고, MCP도 결국 네트워크나 프로세스 통신을 이용합니다. 그래서 “그럼 그냥 API 아니야?”라는 질문이 자연스럽습니다.

완전히 틀린 말은 아니지만, MCP는 보통 단일 API 호출 그 자체보다 모델 친화적인 연결 계층에 더 가깝습니다.

일반 API 통합이 보통 다루는 문제:

  • 특정 서비스에 요청 보내기
  • 응답 받기
  • 인증 처리하기

MCP가 추가로 정리해 주는 문제:

  • 어떤 도구와 리소스가 있는지 발견하기
  • 각 도구가 어떤 입력 스키마를 기대하는지 설명하기
  • 어떤 프롬프트 템플릿이 있는지 노출하기
  • 모델과 애플리케이션이 컨텍스트를 주고받는 방식을 표준화하기

즉, API가 부품이라면 MCP는 그 부품들을 모델이 쓰기 좋은 형태로 연결하는 공통 규약에 더 가깝습니다.

MCP와 RAG의 차이

RAG와 MCP를 헷갈리는 경우도 많습니다. 둘 다 모델에 바깥 정보를 붙인다는 점에서는 비슷해 보이기 때문입니다.

하지만 초점이 다릅니다.

  • RAG는 관련 문서를 검색해 답변 근거로 붙이는 패턴입니다
  • MCP는 모델과 외부 컨텍스트 또는 기능을 연결하는 프로토콜입니다

즉, RAG는 “어떻게 문서를 검색해 붙일 것인가”에 가까운 설계이고, MCP는 “외부 문서나 도구를 AI 앱에 어떤 방식으로 연결할 것인가”에 가까운 설계입니다.

어떤 시스템에서는 RAG용 검색 리소스나 검색 도구가 MCP 서버를 통해 제공될 수도 있습니다. 그래서 둘은 경쟁 개념이라기보다 서로 다른 레이어의 개념이라고 보는 편이 맞습니다. 이 흐름은 RAG 가이드와 임베딩 가이드를 같이 보면 더 분명해집니다.

MCP와 agent의 차이

agent는 보통 목표를 이해하고, 필요한 도구를 선택하고, 결과를 보고 다음 행동을 결정하는 시스템을 뜻합니다.

반면 MCP는 agent가 바깥 세계와 연결될 때 사용할 수 있는 연결 규약입니다.

아주 단순하게 나누면 이렇게 볼 수 있습니다.

  • agent는 “다음에 무엇을 할까”를 다룬다
  • MCP는 “무엇에 접근할 수 있고 어떻게 연결할까”를 다룬다

그래서 agent를 만들 때 MCP가 유용할 수는 있지만, MCP가 곧 agent는 아닙니다. 계획, 메모리, 검증, 워크플로 설계는 여전히 별도의 문제입니다. 관련 흐름은 AI Agent 가이드와 AI 워크플로 오케스트레이션 가이드에서 이어집니다.

실제로 언제 MCP가 특히 유용할까

MCP는 아래처럼 연결 대상이 늘어날수록 가치가 커집니다.

  • 코딩 도구가 여러 프로젝트 파일과 도구를 함께 써야 할 때
  • 사내 문서, 이슈 트래커, 데이터 소스를 동시에 붙여야 할 때
  • 로컬 서버와 원격 서버를 혼합해 써야 할 때
  • 권한과 승인 경계를 분리하고 싶을 때
  • 한 AI 앱이 여러 외부 기능을 통합해야 할 때

반대로 아주 작은 실험에서는 과할 수도 있습니다. 실제로 처음 MCP를 도입할 때는 서버 하나 만드는 데도 시간이 좀 걸렸습니다. 하지만 세 번째 서버부터는 15분이면 끝났고, 그때부터 투자 대비 효율이 확실히 느껴졌습니다. 단일 API 한 개만 호출하는 짧은 데모라면 굳이 MCP까지 끌어오지 않아도 됩니다. 하지만 연결 대상이 많아질수록 공통 규약의 가치가 커집니다.

보안과 신뢰는 자동으로 해결되지 않는다

MCP를 도입한다고 보안이 자동으로 해결되지는 않습니다. 오히려 연결점이 많아지는 만큼 경계가 더 중요해집니다.

실무에서 특히 신경 써야 하는 부분은 아래와 같습니다.

  • 어떤 서버를 신뢰할지
  • 어떤 도구를 모델에 노출할지
  • 승인 없는 실행을 어디까지 허용할지
  • 어떤 리소스가 사용자 데이터나 민감 정보를 포함하는지
  • 실행 결과를 사용자에게 어떻게 보여 줄지

공식 도구 설명에서도 human-in-the-loop와 승인 UI의 중요성을 강조합니다. 즉, MCP는 연결을 더 구조적으로 만들 수는 있어도, 권한 설계와 안전장치를 대신해 주지는 않습니다.

자주 생기는 오해

1. MCP는 그냥 최신 유행어일 뿐이다

유행 요소가 전혀 없다고 할 수는 없지만, 실제 문제는 꽤 현실적입니다. AI 앱이 외부 데이터와 도구를 많이 붙이기 시작하면 연결층을 표준화하려는 수요는 자연스럽게 커집니다.

2. MCP만 넣으면 agent가 똑똑해진다

그렇지 않습니다. MCP는 연결을 정리해 주는 계층이지, 계획 능력이나 추론 품질을 자동으로 보장하지는 않습니다.

3. MCP는 대형 기업만 필요하다

작은 프로젝트에서는 과할 수 있지만, 파일, 문서, 툴이 몇 개만 늘어나도 공통 연결 계층의 가치가 금방 생깁니다.

FAQ

Q. MCP는 로컬에서만 쓰나요?

아닙니다. 개념적으로는 로컬 프로세스와도 연결될 수 있고, 원격 서비스와도 연결될 수 있습니다. 중요한 것은 위치보다 연결 규약과 권한 경계입니다.

Q. MCP를 쓰면 RAG가 필요 없나요?

그렇지 않습니다. RAG는 여전히 문서 검색과 grounding 패턴으로 중요합니다. MCP는 그런 기능을 노출하고 연결하는 더 바깥쪽 프로토콜 레이어에 가깝습니다.

Q. 입문자는 언제 MCP를 공부하는 게 좋나요?

LLM 기본 동작, 프롬프트, RAG, tool calling 개념을 먼저 익힌 뒤 보면 훨씬 잘 들어옵니다. 배경이 없으면 왜 이 연결층이 필요한지 체감이 약할 수 있습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.

광고

관련 글

이 카테고리의 다른 글