8부 39장. MCP란 무엇인가

이제 왜 갑자기 MCP가 everywhere인가

요즘 AI 도구 이야기를 조금만 따라가도 MCP라는 말을 자주 보게 된다. 새로운 코딩 도구를 설명하는 글에서도 나오고, 에이전트 제품 소개에서도 나오고, 회사 내부 문서를 AI와 연결하는 이야기에서도 빠지지 않는다. 처음 들으면 이름부터 어렵다. 하지만 핵심은 의외로 단순하다. AI가 바깥세상과 연결되는 공통 규격이 필요해졌고, MCP가 그 자리를 차지하기 시작했다는 것이다.¹

예전의 AI는 똑똑한 답변기는 될 수 있었지만, 실제로 뭔가를 읽고 찾고 실행하는 일에는 한계가 있었다. 구글 드라이브 문서를 읽고, 깃허브 이슈를 만들고, 데이터베이스를 조회하고, 캘린더에 일정을 넣으려면 도구마다 제각각 다른 연결 방식을 만들어야 했다. 새 모델이 생기고 새 도구가 늘어날수록 연결 코드는 기하급수적으로 복잡해졌다. MCP는 이런 파편화를 줄이기 위해 등장한 개방형 표준이다.²

이 장에서 기억할 것은 하나다. MCP는 AI를 더 똑똑하게 만드는 기술이라기보다, AI를 더 잘 연결되게 만드는 기술이라는 점이다. 그리고 앞으로의 AI 활용에서 이 연결성이 점점 더 중요해진다.

MCP를 한 문장으로 정의하면

MCP는 AI 애플리케이션이 외부 도구, 데이터, 서비스와 표준화된 방식으로 연결되도록 하는 프로토콜이다.¹

여기서 프로토콜이라는 말이 부담스럽다면, 이렇게 생각해도 된다. 서로 처음 만난 프로그램끼리도 "어떻게 요청하고, 무엇을 줄 수 있고, 어떤 형식으로 답할지"를 약속해 둔 공통 언어라고 말이다.

그래서 MCP가 있으면 AI는 단순히 대답만 하는 존재에서 한 걸음 더 나아간다. 필요한 도구를 찾아 쓰고, 외부 자료를 읽고, 실제 행동까지 수행하는 방향으로 확장된다. 예를 들어 "지난주 회의록 찾아서 요약하고, 핵심 할 일을 팀 문서에 정리해 줘" 같은 요청이 가능해지는 이유가 여기에 있다.⁴

왜 다들 USB-C에 비유할까

MCP를 설명할 때 가장 자주 등장하는 비유가 USB-C다.¹ 이 비유가 자주 쓰이는 데는 이유가 있다.

예전에는 기기마다 단자가 달라서 연결할 때마다 전용 케이블이 필요했다. AI 도구 연결도 비슷했다. 깃허브용 연결, 슬랙용 연결, 구글 드라이브용 연결, 사내 데이터베이스용 연결을 각각 따로 만들어야 했다. 그런데 MCP가 있으면 "AI가 외부 시스템과 연결되는 방식"이 어느 정도 공통화된다.

이 비유가 주는 중요한 메시지는 두 가지다. 하나는 한 번 배워 두면 여러 곳에 응용할 수 있다는 점이고, 다른 하나는 생태계가 커질수록 표준의 가치가 훨씬 커진다는 점이다. 특정 서비스 하나를 연결할 때는 귀찮은 정도로 끝나지만, 수십 개 도구를 연결해야 하는 순간 표준이 없는 세계는 금방 지옥이 된다.

MCP는 무엇을 표준화하는가

MCP가 표준화하는 것은 단순한 "API 호출"만이 아니다. 더 정확히 말하면, AI가 바깥 시스템과 상호작용할 때 필요한 여러 층을 함께 다룬다.

가장 중요한 것은 다음 세 가지다.

• 도구: AI가 실행할 수 있는 기능이다. 파일 검색, 이메일 발송, 일정 생성, 데이터 조회 같은 행동이 여기에 들어간다.

• 리소스: AI가 읽고 참고할 수 있는 정보다. 문서, 스키마, 로그, 설정 파일, 데이터베이스 구조 같은 것이 여기에 해당한다.

• 프롬프트 템플릿: 특정 작업을 안정적으로 수행하도록 도와주는 재사용 가능한 지시문이다.³

이 구분이 중요한 이유는, AI가 항상 "행동"만 필요한 것이 아니기 때문이다. 어떤 때는 먼저 읽어야 하고, 어떤 때는 정리된 작업 방식이 필요하다. 즉, MCP는 단순한 실행 버튼 모음이 아니라 AI가 일하는 데 필요한 작업 환경의 인터페이스에 가깝다.

구조는 생각보다 단순하다: Host, Client, Server

MCP 구조는 보통 세 덩어리로 설명한다.³

호스트(Host)는 사용자가 직접 만나는 AI 앱이다. 예를 들어 데스크톱 AI 앱, IDE, 코딩 에이전트 툴이 여기에 들어간다. 사용자는 호스트에 말을 건다.

클라이언트(Client)는 호스트 안에서 MCP 서버와 통신을 담당하는 연결 부품이다. 사용자의 요청을 MCP 형식으로 바꾸고, 서버가 돌려준 결과를 다시 호스트가 이해할 수 있게 넘긴다.

서버(Server)는 실제 기능을 제공하는 쪽이다. 깃허브 서버, 파일 시스템 서버, 데이터베이스 서버, 캘린더 서버처럼 생각하면 된다. 이 서버가 "내가 제공할 수 있는 도구와 리소스는 이것들입니다"라고 알려 주고, 실제 호출을 받아 처리한다.

쉽게 비유해 보자.

사용자가 "회의록 찾아서 요약해 줘"라고 말하면, 호스트는 이 말을 이해하고, 클라이언트는 적절한 MCP 서버에 요청을 전달한다. 그러면 문서 서버가 회의록을 꺼내 주고, 그 결과가 다시 호스트로 돌아온다. 마지막으로 모델이 그것을 읽고 자연어 요약을 만들어 사용자에게 보여 준다.

겉으로 보면 한 번에 일어난 것 같지만, 안에서는 이런 역할 분담이 조용히 돌아가고 있는 셈이다.

실제로는 어떻게 움직일까

MCP의 중요한 특징 중 하나는 AI가 먼저 서버에게 "당신은 무엇을 할 수 있나요?"라고 물어볼 수 있다는 점이다. 그리고 그 답을 바탕으로 필요한 도구를 선택한다. 이건 일반 사용자의 입장에서 보면 아주 큰 변화다. 예전에는 도구 연결을 미리 하드코딩해 둔 느낌이었다면, 이제는 AI가 연결된 기능을 더 유연하게 탐색하고 활용할 수 있다.

실제 흐름은 대체로 이렇다.³

사용자가 요청을 보낸다. 호스트는 모델에게 이 요청을 해석하게 한다. 모델은 필요한 외부 기능이 있다고 판단하면, 클라이언트를 통해 서버의 도구나 리소스를 확인한다. 그다음 적절한 도구를 호출하고, 서버는 실제 API나 시스템 작업을 수행한 뒤 결과를 돌려준다. 모델은 그 결과를 바탕으로 최종 답을 만든다.

여기서 중요한 포인트는, 모델이 직접 온갖 내부 시스템의 세부 구현을 다 아는 것이 아니라는 점이다. 모델은 "무엇을 하고 싶은지"를 판단하고, MCP는 "그 일을 연결된 시스템에서 어떻게 처리할지"를 표준화한다.

그래서 MCP는 모델의 지능을 대체하지 않는다. 대신 모델의 판단과 외부 시스템의 기능 사이를 깔끔하게 이어 주는 배선 정리에 가깝다.

API와는 무엇이 다를까

이쯤 되면 이런 질문이 생긴다. "그냥 API 쓰면 되는 것 아닌가?"

맞는 말이기도 하다. 실제로 많은 MCP 서버는 내부적으로 기존 API를 감싸는 형태로 만들어진다. 깃허브 MCP 서버는 결국 깃허브 API를 사용할 수 있고, 캘린더 MCP 서버도 결국 캘린더 API와 연결될 수 있다. 그러니까 MCP가 API를 없애는 것은 아니다. 오히려 AI가 API를 다루기 쉽게 만들어 주는 한 겹의 표준화 층이라고 보는 편이 정확하다.⁴

차이는 관점에 있다.

API는 원래 소프트웨어끼리 통신하기 위해 설계되었다. 그래서 엔드포인트, 인증 방식, 파라미터, 응답 형식이 서비스마다 다르다. 사람 개발자가 문서를 읽고 맞춰 붙이는 것이 전제다.

반면 MCP는 AI가 도구를 발견하고, 읽고, 호출하고, 결과를 다시 맥락으로 활용하는 흐름에 맞춰 설계되었다. 즉, "소프트웨어 통합"이 아니라 "AI 통합"에 더 가까운 규격이다. 그래서 요즘 에이전트 생태계에서 훨씬 자주 언급된다.

RAG와도 같은 것일까

이것도 많이 헷갈리는 부분이다. MCP와 RAG는 비슷해 보이지만 역할이 다르다.⁴

RAG는 바깥 문서를 찾아서 모델에게 읽히는 방식에 가깝다. 쉽게 말해, 찾아와서 읽게 한다가 핵심이다. 반면 MCP는 읽는 것뿐 아니라 도구를 실행하고, 외부 시스템과 상호작용하고, 결과를 다시 이어서 활용하게 만든다. 즉, 읽기 + 행동 쪽까지 포함한다.

그래서 RAG는 MCP 안에 들어갈 수도 있지만, MCP 전체가 곧 RAG는 아니다. 책의 흐름으로 말하면, RAG가 "정보를 잘 붙이는 방법"에 더 가깝다면, MCP는 "정보와 도구를 표준 방식으로 연결하는 방법"에 더 가깝다.

왜 에이전트 시대에 MCP가 중요해지는가

앞부분에서 우리는 에이전트가 단순한 챗봇보다 더 많은 일을 한다는 것을 보았다. 계획하고, 도구를 고르고, 실행하고, 다시 판단한다. 그런데 에이전트가 진짜 일을 하려면 결국 바깥 시스템과 연결되어야 한다.

문제는 이 연결이 제각각이면 에이전트를 만들수록 유지보수가 더 어려워진다는 점이다. 모델이 바뀌고, 도구가 바뀌고, 제품이 늘어날수록 연결 코드는 금방 복잡해진다. MCP는 이 혼란을 줄여 준다. 도구를 하나씩 특별 대우하는 대신, 공통 규격 속에서 다루게 해 주기 때문이다.²

그래서 MCP가 중요한 이유는 단순히 "새 기술이라서"가 아니다. 에이전트가 실제 업무에 들어오기 시작하면서, 연결의 표준화가 더 이상 있으면 좋은 옵션이 아니라 거의 필수 인프라가 되어 가기 때문이다.

공식 문서에서도 MCP는 이미 다양한 AI 앱과 개발 도구에서 지원되고 있다고 설명한다. 이런 폭넓은 지원은 기술 자체의 완성도를 넘어, 생태계의 공통 언어가 생기고 있다는 신호로 읽을 수 있다.¹

하지만 MCP가 만능은 아니다

MCP라는 단어가 많이 보인다고 해서, 이것만 깔면 AI가 갑자기 만능 비서가 되는 것은 아니다.

먼저, MCP는 에이전트 프레임워크 자체가 아니다. 어떤 도구를 언제 쓸지 판단하는 것은 여전히 모델과 오케스트레이션 로직의 몫이다. MCP는 그 판단이 외부 시스템과 만나는 접점을 표준화할 뿐이다.⁴

또한 도구가 많아질수록 새로운 문제가 생긴다. 연결 가능한 도구가 수백 개, 수천 개로 늘어나면 도구 설명 자체가 컨텍스트를 많이 차지하고, 중간 결과를 모델 맥락에 계속 넣는 비용도 커진다. 즉, 연결성이 늘어난다고 공짜로 효율이 좋아지는 것은 아니다.⁵

쉽게 말해, MCP는 도구 연결의 질서를 잡아 주지만, 어떤 도구를 얼마나 열어 둘지, 언제 호출할지, 중간 결과를 어떻게 다룰지는 여전히 설계의 문제다. 표준이 생겼다고 설계가 사라지는 것은 아니다.

보안 이야기를 빼면 MCP를 반만 이해한 것이다

AI가 회사 문서, 메일, 데이터베이스, 캘린더에 연결된다고 생각해 보자. 편리함은 엄청나지만, 동시에 위험도 커진다. 그래서 MCP를 이야기할 때 보안을 빼놓으면 안 된다.

중요한 쟁점은 대체로 이렇다.⁶

• 권한 통제: AI가 어떤 도구를 어디까지 쓸 수 있는가

• 사용자 동의: 실제 행동을 실행하기 전에 누가 승인하는가

• 감사 추적: 무엇을 읽었고, 무엇을 실행했는지 나중에 확인할 수 있는가

특히 기업 환경에서는 "연결된다"보다 "안전하게 연결된다"가 더 중요하다. 캘린더 읽기는 허용하지만 수정은 금지할 수도 있고, 데이터베이스도 조회 전용만 열어 둘 수 있다. 결국 MCP는 연결을 쉽게 만들지만, 무엇을 허용할지 결정하는 책임까지 대신 지지는 않는다.

그래서 좋은 MCP 환경은 단순히 서버를 많이 붙여 둔 환경이 아니라, 권한과 로깅과 승인 흐름까지 설계된 환경이다. 이 감각이 없으면, 똑똑한 AI를 들여놓는 것이 아니라 출입증 없는 인턴에게 회사 열쇠를 쥐여 주는 꼴이 된다.

실무자는 MCP를 어떻게 이해하면 좋을까

실무 관점에서는 이렇게 이해하면 된다.

첫째, MCP는 AI를 외부 시스템에 연결하는 공통 소켓이다. 그래서 새로운 도구가 나와도 연결 방식이 덜 제각각이 된다.

둘째, MCP는 에이전트의 행동 반경을 넓힌다. 답변만 하던 AI가 문서를 읽고, 검색하고, 수정하고, 실행할 수 있는 토대가 된다.

셋째, MCP는 도입보다 운영이 더 중요하다. 어떤 서버를 붙일지, 어떤 권한을 줄지, 어떤 로그를 남길지까지 함께 생각해야 한다.

이 세 줄만 잡고 있어도 MCP를 둘러싼 요란한 말들에 휘둘리지 않는다. 결국 중요한 것은 이름이 아니라, 이 표준이 AI를 채팅창 안에서 꺼내 실제 도구 세계로 데리고 나가는 연결 방식이라는 점이다.

이 장의 핵심 정리

MCP는 AI와 외부 도구를 연결하는 새로운 유행어가 아니다. 에이전트 시대에 필요한 표준 연결 언어에 가깝다. AI가 실제 일을 하려면 파일도 읽어야 하고, 데이터도 찾아야 하고, 도구도 실행해야 한다. 그런데 그 연결이 전부 제각각이면 확장도 어렵고 유지도 어렵다. MCP는 바로 그 문제를 풀기 위해 등장했다.¹²

그래서 요즘 MCP가 자주 언급되는 이유는 단순하다. 이제 사람들은 "모델이 얼마나 똑똑한가"만 묻지 않는다. 그 모델이 무엇과 연결되고, 어떤 일을 실제로 해낼 수 있는가를 묻기 시작했기 때문이다.

다음 장에서는 한 걸음 더 나아가, AI에 도구를 연결한다는 것이 실제로 무슨 의미인지를 다룬다. MCP를 이해했다면, 이제부터는 연결이 가져오는 능력의 변화와 설계의 감각을 더 구체적으로 볼 차례다.

참고

¹What is the Model Context Protocol (MCP)?

²Introducing the Model Context Protocol

³Get started with .NET AI and the Model Context Protocol

⁴Model Context Protocol (MCP) 가이드

⁵Code execution with MCP: building more efficient AI agents

⁶Model Context Protocol (MCP) Companion Guide