MCP(Model Context Protocol) - AI에 표준 연결 단자 달기

함수 호출로 도구를 연결하고 에이전트까지 만들다 보면 곧 새로운 고민이 생깁니다. "이 도구 연결을 매번, 앱마다, 모델마다 다시 짜야 하나?" 이 파편화 문제를 표준으로 풀려는 시도가 MCP(Model Context Protocol) 입니다.

이 글에서는 MCP가 왜 나왔고, 어떤 구조이며, 개발자에게 어떤 의미인지를 제가 아는 범위에서 개념 중심으로 정리합니다.

1. 왜 MCP가 나왔나 - 연결의 파편화

LLM 앱에 도구·데이터를 붙이는 일은 지금까지 제각각이었습니다.

앱마다 GitHub, Slack, DB, 파일시스템 연동을 자기 방식대로 구현합니다.
모델/프레임워크가 바뀌면 그 연동을 또 새로 짭니다.
같은 "Slack 연결"을 회사마다, 앱마다 중복 개발합니다.

이건 전형적인 M×N 문제입니다. M개의 AI 앱과 N개의 데이터/도구를 붙이려면 최악의 경우 M×N개의 커넥터가 필요합니다.

[MCP 이전]  앱마다 도구마다 개별 연동 (M × N)

  앱A ──╳──▶ GitHub
  앱A ──╳──▶ Slack
  앱B ──╳──▶ GitHub   ← 같은 연결을 또 구현
  앱B ──╳──▶ DB
      ...끝없이 중복

MCP의 목표는 이걸 M + N으로 바꾸는 것입니다. 연결 방식을 표준화해서, 도구 쪽은 표준 서버 하나만 만들고 앱 쪽은 표준 방식으로 그 서버들에 붙습니다.

2. "USB-C 같은 표준" 비유

MCP를 설명할 때 흔히 쓰는 비유가 USB-C입니다.

예전엔 기기마다 충전 단자가 제각각이라 케이블을 잔뜩 들고 다녔습니다. USB-C는 하나의 표준 단자로 이걸 정리했죠. 노트북이든 폰이든, USB-C 구멍만 있으면 어떤 USB-C 주변기기든 꽂힙니다.

MCP가 노리는 것도 같습니다.

AI 애플리케이션과 외부 도구/데이터 사이에 "표준 연결 단자"를 만든다.

한 번 MCP 서버로 만들어 둔 도구는, MCP를 지원하는 어떤 AI 앱에서든 그대로 쓸 수 있습니다. 반대로 MCP를 지원하는 앱은 새로운 도구가 나와도 연동 코드를 새로 짜지 않고 꽂기만 하면 됩니다.

[MCP 이후]  표준 단자로 통일

           ┌─▶ [MCP 서버] GitHub
AI 앱 ─MCP─┼─▶ [MCP 서버] Slack
(클라이언트)└─▶ [MCP 서버] 사내 DB

  서버는 한 번만 만들면 여러 앱이 공유

3. 클라이언트-서버 구조

MCP는 클라이언트-서버 구조입니다. 역할을 나눠 보면 이렇습니다.

호스트(Host): 사용자가 쓰는 AI 애플리케이션(예: AI IDE, 데스크톱 어시스턴트, 챗봇). LLM이 여기서 돕니다.
클라이언트(Client): 호스트 안에서 특정 MCP 서버 하나와 연결을 맡는 부분. 서버당 하나씩 붙습니다.
서버(Server): 실제 도구·데이터를 표준 형식으로 노출하는 쪽. 예) 파일시스템 서버, GitHub 서버, DB 서버.

┌───────── 호스트(AI 앱) ─────────┐
│  LLM                            │
│  ├─ 클라이언트 ──▶ MCP 서버(파일)   │
│  ├─ 클라이언트 ──▶ MCP 서버(GitHub)│
│  └─ 클라이언트 ──▶ MCP 서버(DB)     │
└─────────────────────────────────┘

호스트와 서버는 정해진 메시지 규격(프로토콜) 으로 대화합니다. 서버는 로컬 프로세스로 돌 수도, 원격에 있을 수도 있습니다. 중요한 건 양쪽이 같은 약속을 따르기 때문에 서로를 몰라도 붙는다는 점입니다.

4. 리소스·툴·프롬프트 - 서버가 제공하는 것

MCP 서버가 호스트에 노출하는 것은 크게 세 종류입니다. 이 구분이 MCP 이해의 핵심입니다.

구분	무엇	성격	예시
리소스(Resources)	읽을 수 있는 데이터·컨텍스트	대체로 읽기 전용	파일 내용, DB 레코드, 문서
툴(Tools)	실행할 수 있는 함수·행동	행동/부작용 가능	검색 실행, 이슈 생성, API 호출
프롬프트(Prompts)	재사용 가능한 프롬프트 템플릿	미리 정의된 상호작용	"이 코드 리뷰해줘" 템플릿

각각을 조금 더 보면.

리소스는 LLM에게 줄 맥락입니다. 함수 호출로 치면 "읽어올 데이터"에 가깝습니다. 어떤 데이터가 있는지 목록을 제공하고, 호스트가 필요한 것을 골라 가져갑니다.
툴은 앞서 다룬 함수 호출과 같은 개념입니다. 서버가 "이런 함수를 부를 수 있다"고 스키마로 노출하고, LLM이 필요할 때 호출을 요청하면 서버가 실행합니다.
프롬프트는 자주 쓰는 상호작용을 템플릿으로 미리 정의해 두는 것입니다. 사용자가 슬래시 명령처럼 꺼내 쓸 수 있는 형태를 떠올리면 됩니다.

정리: MCP는 함수 호출을 없애는 게 아니라 표준 포장지로 감싸는 것입니다. 툴은 함수 호출, 리소스는 컨텍스트 주입(RAG의 데이터 소스와도 잘 맞습니다), 프롬프트는 재사용 템플릿을 표준화한 것입니다.

5. 개발자에게 주는 의미

MCP가 실무 개발자에게 왜 반가운지 정리합니다.

한 번 만들면 여러 곳에서: 사내 시스템을 MCP 서버로 한 번 노출하면, MCP를 지원하는 여러 AI 앱에서 재사용됩니다. 앱마다 커넥터를 새로 짤 필요가 줄어듭니다.
관심사 분리: "도구를 어떻게 제공할지(서버)" 와 "AI가 어떻게 쓸지(호스트)" 가 프로토콜로 깔끔히 나뉩니다. 팀이 서버만 잘 만들면 됩니다.
모델·앱 종속 완화: 표준을 따르면 특정 프레임워크나 모델에 덜 묶입니다.
생태계: 이미 만들어진 MCP 서버들을 가져다 꽂아 쓸 수 있어, 바퀴를 다시 발명하지 않아도 됩니다.

주의할 점도 있습니다(개념 수준에서).

보안·권한: 외부 서버를 꽂는다는 건 데이터 접근을 여는 것입니다. 신뢰할 수 있는 서버인지, 어떤 권한을 주는지 반드시 통제해야 합니다. 출처가 불분명한 서버는 함부로 연결하지 않습니다.
여전히 표준일 뿐: MCP는 연결 방식을 정할 뿐, 좋은 도구 설계와 검증은 여전히 개발자 몫입니다. 앞선 함수 호출의 주의점(인자 검증, 부작용 통제)은 그대로 유효합니다.

[개발자 관점 요약]
  내 시스템 ──(MCP 서버로 노출)──▶ 표준 인터페이스
                                    │
        여러 AI 앱이 표준 방식으로 꽂아 사용
        + 권한/보안은 내가 통제

마무리

MCP는 거창한 새 AI 기술이 아니라 "AI 앱과 도구/데이터를 잇는 방식을 표준화한 프로토콜" 입니다. USB-C가 케이블을 정리했듯, 파편화된 연동을 하나의 규격으로 모으려는 시도입니다.

핵심만 다시.

문제는 연결의 파편화(M×N), MCP의 답은 표준화(M+N).
구조는 호스트–클라이언트–서버, 서버가 리소스·툴·프롬프트를 노출한다.
개발자에겐 재사용·관심사 분리·생태계가 이점, 대신 보안·권한 통제는 필수.

함수 호출과 에이전트가 "AI가 도구를 쓰는 법"이었다면, MCP는 그 도구들을 어떻게 표준적으로 꽂을지에 대한 답입니다.