MCP 프로토콜과 개발자 인프라

2024년 11월 25일, 앤트로픽이 조용히 깃허브에 스펙 문서 하나를 올렸다. 처음엔 개발자 커뮤니티조차 크게 주목하지 않았던 이 프로토콜은 반년 만에 AI 업계 전체의 표준 어휘가 됐다. 이름은 '모델 컨텍스트 프로토콜(Model Context Protocol)', 줄여서 MCP.

MCP가 풀려던 문제는 단순하지만 고질적이었다. LLM 기반 어시스턴트가 회사 내부 데이터베이스, 깃허브 저장소, 슬랙 채널, 로컬 파일시스템 같은 외부 시스템에 접근하려면 그때그때 커스텀 연동 코드를 짜야 했다. 어시스턴트가 N개, 연동 대상이 M개면 필요한 통합 코드는 N×M개— 이른바 'N×M 문제'다. MCP는 이걸 각 데이터 소스가 표준화된 'MCP 서버'를 하나씩 만들고, 어시스턴트는 그 서버에 붙기만 하면 되는 구조로 바꿨다. 앤트로픽은 이를 "AI를 위한 USB-C"에 비유했는데, 실제로 포트 규격을 통일해 아무 기기나 아무 케이블에 꽂히게 만든 발상과 닮았다.

기술적으로는 JSON-RPC 2.0을 뼈대로 하며, 세 가지 핵심 개념으로 구성된다. '도구(tools)'는 모델이 호출해 실행할 수 있는 함수, '리소스(resources)'는 모델이 읽어올 수 있는 데이터, '프롬프트(prompts)'는 재사용 가능한 상호작용 템플릿이다. 로컬 프로세스와는 표준입출력(stdio)으로, 원격 서버와는 HTTP 기반 트랜스포트로 통신한다.

초기엔 클로드 데스크톱 앱과 클로드 코드 CLI에만 붙어 있었지만, 2025년 3월 오픈AI가 에이전츠 SDK와 챗GPT 데스크톱 앱에 MCP 지원을 발표하면서 판도가 바뀌었다. 경쟁사 프로토콜이 아니라 업계 공용 인프라로 자리잡은 셈이다. 곧이어 구글 딥마인드도 제미나이 생태계에 지원을 추가했고, 마이크로소프트는 코파일럿 스튜디오와 VS Code에 통합했다. 커뮤니티가 만든 서버는 파일시스템, 깃, 포스트그레스, 브레이브 서치, 구글 드라이브, 스트라이프 등 수천 종에 달하며, 공식 저장소(modelcontextprotocol/servers)와 서드파티 레지스트리 사이트들이 이를 색인한다.

물론 논쟁도 있다. 서버 하나가 임의 코드 실행 권한을 갖는 구조라 보안 감사 없이 아무 MCP 서버나 설치하면 프롬프트 인젝션이나 데이터 유출 통로가 될 수 있다는 지적이 꾸준히 나온다. 2025년 상반기 실제로 악성 MCP 서버가 API 키를 탈취하는 사례가 보고되면서, 서버 서명·샌드박싱·권한 스코프 제한 같은 보완 논의가 이어지고 있다. 그럼에도 개발자 인프라 표준으로서의 위치는 확고해졌다는 평가가 우세하며, 이후 등장한 '에이전트 간 통신(A2A)' 같은 인접 표준들도 MCP를 보완하는 층으로 설계되고 있다.

"AI한테 우리 회사 데이터베이스 좀 보여주고 싶은데, 매번 새로 코드 짜야 해?" — 개발자들이 오랫동안 겪던 이 불편함을 해결하려고 나온 게 MCP(모델 컨텍스트 프로토콜)다. 2024년 11월 앤트로픽이 처음 공개했다.

비유하자면 이렇다. 예전 노트북마다 충전 단자가 제각각이라 기기 바꿀 때마다 새 충전기를 사야 했던 시절 기억나는가? USB-C가 나오면서 그 문제가 한 번에 해결됐다. MCP도 똑같다. AI 어시스턴트와 외부 데이터(파일, 깃허브, 슬랙, 데이터베이스 등) 사이에 '공통 규격'을 만들어서, 이제는 매번 새로 연동 코드를 짤 필요 없이 표준화된 '서버'만 붙이면 끝나게 됐다.

왜 이게 중요할까? 첫째, 개발 시간이 확 줄었다. AI 서비스 N개랑 데이터 소스 M개를 다 따로 연결하려면 원래 N×M개의 코드가 필요했는데, MCP를 쓰면 각자 한 개씩만 만들면 된다. 둘째, 생태계가 폭발적으로 커졌다. 처음엔 클로드 앱에서만 쓰였지만, 2025년 3월 오픈AI(챗GPT를 만든 회사)가 지원을 발표했고, 구글도 뒤따랐다. 지금은 수천 개의 MCP 서버가 커뮤니티에서 공유되고 있다 — 깃허브 저장소 관리, 구글 드라이브 파일 읽기, 결제 시스템 연동까지 종류도 다양하다.

다만 주의할 점도 있다. MCP 서버는 AI에게 실제로 어떤 동작(파일 삭제, 데이터 전송 등)을 실행할 권한을 줄 수 있어서, 출처가 불분명한 서버를 함부로 설치하면 보안 사고로 이어질 수 있다. 실제로 악성 서버가 API 키를 훔쳐가는 사건도 있었다. 그래서 신뢰할 수 있는 곳에서 만든 서버인지 확인하는 습관이 중요하다는 지적이 나온다.

결국 MCP는 AI가 "혼자 대답만 하는 챗봇"에서 "실제로 여러 시스템을 오가며 일을 처리하는 비서"로 진화하는 과정에서 나온 배관 같은 기술이다. 화려하진 않지만, 지금 AI 업계가 돌아가는 방식 밑바닥을 떠받치고 있다.

여러분 집에 게임기, 노트북, 스마트폰이 있는데 전부 충전기 모양이 달랐던 적 있나요? 그럼 기기마다 충전기를 따로 챙겨야 해서 정말 번거롭겠죠. 요즘은 USB-C라는 똑같은 모양의 단자로 통일되면서 그런 불편함이 많이 사라졌어요.

'MCP'라는 기술은 컴퓨터 세계에서 비슷한 일을 했어요. AI 로봇 비서(챗봇 같은 것)가 회사의 파일이나 사진, 채팅 기록 같은 걸 보려면 예전엔 그때그때 새로운 '연결 방법'을 만들어야 했어요. 마치 장난감마다 다른 배터리를 써야 하는 것처럼요. 그런데 2024년 11월, '앤트로픽'이라는 AI 회사가 MCP라는 공통 규칙을 만들었어요. 이제는 AI 비서와 여러 데이터 창고들이 똑같은 연결 방식을 쓸 수 있게 된 거예요.

이 규칙이 나오고 몇 달 뒤인 2025년 3월엔, 챗GPT를 만든 오픈AI라는 회사도 "우리도 이 방식을 쓸게요!"라고 발표했어요. 원래는 서로 다른 회사끼리 경쟁만 할 것 같은데, MCP만큼은 다 같이 쓰는 '공용 규칙'이 된 거죠. 마치 전 세계 사람들이 다 같은 도로 신호등 색깔을 쓰기로 약속한 것과 비슷해요.

덕분에 지금은 수천 개의 'MCP 연결 도구'가 만들어졌어요. AI 비서가 구글 드라이브 파일을 읽거나, 깃허브(프로그래머들이 코드를 저장하는 곳)를 확인하거나, 회사 데이터베이스를 살펴보는 일이 훨씬 쉬워졌답니다.

다만 조심할 것도 있어요. 아무 연결 도구나 함부로 설치하면 나쁜 사람이 만든 가짜 도구일 수도 있거든요. 낯선 사람이 주는 케이블을 아무 데나 꽂으면 안 되듯이, MCP 도구도 믿을 만한 곳에서 만든 것만 써야 안전해요.

MCP 프로토콜과 개발자 인프라

문서 정보