똑똑한 AI, 그런데 왜 이렇게 답답할까?
요즘 AI는 정말 말빨이 좋습니다. 글도 잘 쓰고, 번역도 하고, 코딩도 도와주고, 심지어 농담도 합니다. 그런데 막상 일을 시켜 보면 어느 순간 벽에 부딪힙니다.
예를 들어 이렇게 말해 보죠.
"오늘 서울 날씨 보고, 우산이 필요하면 내 일정표에 메모 남겨줘."
사람은 이 말을 들으면 자연스럽게 두 가지를 합니다. 먼저 날씨를 확인하고, 그다음 일정표를 열어서 메모를 남깁니다. 그런데 AI는 기본적으로 날씨 앱도 모르고, 당신의 일정표에도 바로 접근하지 못합니다. 똑똑한 척은 할 수 있어도, 실제로 확인하고 행동하는 일은 별개의 문제인 셈입니다.
이 지점이 중요합니다. 많은 사람이 AI를 '엄청 똑똑한 답변 기계'로 생각하지만, 현실에서 더 중요한 건 '정답처럼 보이는 말'이 아니라 '진짜 데이터에 접근하고, 필요한 작업을 수행하는 능력'입니다.
즉, AI에게는 머리만 있는 것이 아니라 손과 발도 필요합니다. 그리고 그 손발을 외부 도구와 시스템에 연결해 주는 공통 규칙이 바로 MCP(Model Context Protocol)입니다.
MCP를 한 문장으로 설명하면
MCP는 AI가 외부 도구, 데이터, 서비스와 표준화된 방식으로 연결되도록 만든 공통 언어입니다.
조금 더 쉽게 말하면, AI에게 이렇게 말해 주는 약속입니다.
"파일을 읽고 싶으면 이런 형식으로 요청해." "데이터베이스를 조회하고 싶으면 이렇게 물어봐." "캘린더에 일정을 추가하고 싶으면 이 규칙대로 말해."
예전에는 AI 앱마다, 도구마다, 서비스마다 연결 방식이 제각각이었습니다. 어떤 건 플러그인처럼 붙였고, 어떤 건 전용 API를 따로 짰고, 어떤 건 아예 사람 손으로 복사해서 붙여넣어야 했습니다. 그러니 연결은 복잡해지고, 유지보수는 괴로워지고, 새 도구 하나 붙일 때마다 작은 공사가 벌어졌습니다.
MCP는 이 혼잡한 세상에 "이제 연결 규격 좀 통일합시다"라고 등장한 표준입니다.
왜 다들 'AI의 USB-C'라고 부를까?
MCP를 이해하는 가장 쉬운 비유는 USB-C입니다.
예전 전자기기를 떠올려 보면, 기기마다 단자가 달랐습니다. 어떤 건 5핀, 어떤 건 8핀, 어떤 건 동그란 충전기, 어떤 건 전용 케이블이었죠. 서랍을 열면 선이 한 뭉치로 나와 "도대체 누구 거냐…" 싶은 상황이 자주 벌어졌습니다.
그런데 USB-C가 등장하면서 많은 것이 단순해졌습니다. 충전도, 데이터 전송도, 주변기기 연결도 하나의 표준 포트로 정리되기 시작했죠.
MCP가 AI 세계에서 하는 일도 이와 비슷합니다.
AI가 깃허브를 쓰려면 깃허브용 전용 연결, 슬랙을 쓰려면 슬랙용 전용 연결, 데이터베이스를 쓰려면 또 다른 전용 연결을 각각 따로 만들던 세상에서, MCP는 "AI와 도구가 만나는 방식"을 공통 규격으로 정리해 줍니다.
그래서 한 번 MCP를 지원하면, 다양한 AI 앱과 다양한 도구가 훨씬 쉽게 연결될 수 있습니다. 마치 "이 포트만 맞으면 일단 꽂아 보자"가 되는 셈입니다.
이 비유가 강력한 이유는, MCP가 단순히 기능 하나를 추가하는 기술이 아니라 생태계 전체의 연결 비용을 낮추는 표준이기 때문입니다.
MCP가 나오기 전, 무엇이 그렇게 불편했을까?
MCP가 왜 주목받는지 알려면, MCP 이전의 세상을 먼저 봐야 합니다.
예를 들어 AI 앱이 세 종류 있고, 연결하고 싶은 외부 도구가 열 종류 있다고 해 봅시다. 그러면 예전 방식에서는 각 AI와 각 도구 사이를 일일이 이어 줘야 했습니다. 세 개의 AI와 열 개의 도구라면 최대 서른 개의 연결을 따로 관리해야 하는 셈입니다.
이걸 흔히 N×M 문제라고 부릅니다. 이름은 무섭지만 뜻은 간단합니다.
AI가 많아질수록, 도구가 많아질수록, 연결 지옥도 함께 커진다는 뜻입니다.
개발자 입장에서는 아주 괴로운 구조입니다. 같은 기능을 비슷하게 여러 번 만들게 되고, 어떤 AI에서는 되는데 다른 AI에서는 안 되고, 보안 정책도 제각각이 되고, 문서도 산으로 갑니다.
사용자 입장에서도 불편합니다. 분명 AI는 똑똑한데, 내가 쓰는 앱에서는 파일 읽기가 되고 다른 앱에서는 안 되고, 어떤 환경에서는 깃허브가 되고 어떤 환경에서는 검색만 되고, 경험이 들쭉날쭉해집니다.
MCP는 이 문제를 각자 따로 연결하는 방식에서 공통 규칙으로 연결하는 방식으로 바꿔 줍니다. 그러면 문제의 구조가 N×M에서 N+M에 가까워집니다.
쉽게 말해, AI는 MCP를 이해하면 되고, 도구도 MCP를 이해하면 되고, 둘은 표준 규칙 위에서 만납니다.
개별 소개팅 대신 단체 입주 설명회가 열린 느낌입니다. 훨씬 효율적이죠.
AI는 왜 외부 연결이 꼭 필요할까?
여기서 한 가지 오해를 풀어야 합니다. 많은 사람은 AI가 이미 모든 걸 아는 것처럼 느낍니다. 하지만 실제로는 그렇지 않습니다.
AI는 기본적으로 학습된 내용을 바탕으로 다음에 올 말을 예측하는 시스템입니다. 즉, 아주 넓은 지식을 갖고 있을 수는 있어도, 지금 이 순간의 최신 정보나 당신 회사 내부 자료, 당신 로컬 폴더 안의 파일까지 자동으로 알고 있는 것은 아닙니다.
그래서 AI 단독 사용에는 몇 가지 한계가 있습니다.
최신 정보를 모를 수 있습니다. 예를 들어 오늘 주가, 오늘 날씨, 방금 바뀐 정책 문서를 모를 수 있습니다.
개인 또는 회사 내부 정보를 모릅니다. 내 캘린더, 사내 위키, 고객 DB, 로컬 파일은 학습 데이터에 들어 있지 않습니다.
행동을 직접 수행하지 못합니다. 이메일 보내기, 이슈 등록하기, 파일 수정하기 같은 일은 외부 도구가 필요합니다.
이런 한계를 그대로 두면 AI는 멋진 말을 하는 해설자에 가깝습니다. 하지만 MCP 같은 연결 표준이 들어오면 이야기가 달라집니다.
그때부터 AI는 읽을 수 있고, 찾을 수 있고, 실행할 수 있게 됩니다.
즉, 설명만 하던 존재가 실제 업무 흐름 안으로 들어오기 시작하는 것입니다.
MCP는 정확히 무엇을 연결할까?
MCP는 주로 세 가지를 다룹니다.
도구
도구는 AI가 실행할 수 있는 기능입니다.
예를 들어 파일 저장, 웹 검색, 데이터베이스 조회, 메시지 전송, 일정 생성 같은 것들이 여기에 들어갑니다. AI가 "이 작업은 내가 혼자 못 하니까 도구를 써야겠네"라고 판단했을 때 호출하는 손과 발 같은 존재입니다.
리소스
리소스는 AI가 읽고 참고할 수 있는 정보입니다.
문서, 파일 내용, 데이터베이스 스키마, 설정값, API 응답 같은 것이 여기에 해당합니다. 쉽게 말해, 행동하기 전에 주변 상황을 이해할 때 필요한 재료입니다.
프롬프트
프롬프트는 반복해서 쓸 수 있는 지시문 템플릿입니다.
예를 들어 "이 코드를 리뷰해 줘", "이 문서를 회의록 스타일로 요약해 줘", "이슈를 재현 단계 중심으로 정리해 줘" 같은 틀이 미리 준비되어 있으면, 사용자나 앱이 더 일관되게 AI를 활용할 수 있습니다.
지금은 낯설어 보여도 어렵지 않습니다.
도구는 '행동', 리소스는 '정보', 프롬프트는 '사용 설명서'라고 기억하면 됩니다.
실제로는 어떤 일이 벌어질까?
예를 들어 당신이 AI에게 이렇게 말한다고 해 보겠습니다.
"내 프로젝트 폴더에서 README를 읽고, 해야 할 일을 정리해서 GitHub 이슈 초안을 만들어 줘."
이 요청은 사람에게는 자연스럽지만, AI에게는 생각보다 복합적인 작업입니다.
먼저 프로젝트 폴더에 접근해 README를 읽어야 합니다. 그다음 내용을 요약하고 해야 할 일을 뽑아야 합니다. 마지막으로 GitHub에 연결해 이슈 초안을 작성해야 하죠.
MCP가 없으면 이 모든 연결을 각 서비스별로 제각각 붙여야 할 가능성이 큽니다. 하지만 MCP가 있으면 파일 시스템 서버, GitHub 서버 같은 식으로 연결된 도구와 데이터에 표준 방식으로 접근할 수 있습니다.
사용자는 그냥 자연어로 말합니다. AI는 필요한 도구를 고릅니다. 연결된 서버가 실제 데이터를 가져오거나 작업을 수행합니다. 그리고 AI가 그 결과를 사람이 이해하기 쉬운 말로 다시 정리해 줍니다.
중요한 점은 사용자가 매번 "파일 API를 먼저 호출하고, 그다음 JSON을 파싱하고, 이어서 GitHub REST 엔드포인트를…" 같은 말을 할 필요가 없다는 것입니다.
이제는 "해 줘"라고 말하면, 그 뒤의 연결 구조를 표준화된 방식으로 다룰 수 있게 된 것입니다.
사용자에게 MCP는 왜 신나는가?
사용자 입장에서 MCP의 매력은 아주 현실적입니다.
첫째, 복사-붙여넣기 노동이 줄어듭니다. 문서를 열고, 내용을 복사하고, AI 창에 붙여넣고, 다시 결과를 복사해서 다른 앱에 옮기는 일이 줄어듭니다.
둘째, AI가 더 정확해집니다. 모르는 내용을 그럴듯하게 지어내기보다, 실제 파일과 실제 데이터, 실제 시스템을 보고 답할 수 있기 때문입니다.
셋째, AI가 진짜 일을 하기 시작합니다. 조회만 하는 것이 아니라 생성, 수정, 등록, 전송 같은 행동으로 이어질 수 있습니다.
한마디로, MCP가 들어오면 AI는 "말 잘하는 동료"에서 "도구를 쓸 줄 아는 신입" 정도로 진화합니다. 아직 완벽한 베테랑은 아니지만, 적어도 시킬 수 있는 일이 급격히 늘어납니다.
만드는 사람에게 MCP는 왜 반가운가?
개발자나 도구 제작자 입장에서도 MCP는 꽤 반가운 존재입니다.
예전에는 AI마다 붙이는 방법이 달라서, 같은 도구를 여러 방식으로 포장해야 했습니다. 어떤 플랫폼은 자기 방식의 함수 호출을 요구하고, 어떤 앱은 별도 플러그인 구조를 쓰고, 어떤 곳은 문서를 읽고 직접 어댑터를 만들어야 했죠.
그런데 MCP가 자리 잡으면 생각이 단순해집니다.
"우리 기능을 MCP 서버로 제공하자."
이렇게 해 두면 MCP를 이해하는 여러 호스트와 클라이언트가 그 기능을 재사용할 수 있습니다. 한 번 잘 만들어 두면 다양한 AI 앱에서 활용될 가능성이 열립니다.
이 점이 중요한 이유는, AI 시대의 경쟁이 단지 "누가 더 좋은 모델을 갖고 있나"에서 끝나지 않기 때문입니다. 앞으로는 "누가 더 좋은 도구 생태계를 갖고 있나", "누가 더 다양한 실제 업무 시스템과 연결되어 있나"가 훨씬 중요해집니다.
MCP는 그 생태계를 키우기 좋은 공용 도로 같은 역할을 합니다.
MCP는 RAG나 함수 호출과 뭐가 다를까?
처음 듣는 사람은 이런 질문을 자주 합니다.
"외부 정보를 쓰는 거면 RAG랑 비슷한 거 아냐?" "도구 실행이면 함수 호출이랑 같은 거 아냐?"
비슷한 부분은 있지만, 초점이 다릅니다.
RAG는 주로 문서를 찾아서 답변 품질을 높이는 방식에 가깝습니다. 즉, 검색해서 읽고 대답하는 데 강합니다.
함수 호출은 모델이 외부 기능을 실행하게 하는 좋은 출발점이었지만, 대개 특정 벤더나 특정 방식에 묶이기 쉽습니다.
반면 MCP는 더 넓은 관점에서 AI와 외부 세계가 상호작용하는 방식을 표준화하려는 시도입니다.
단순히 문서를 검색하는 것만이 아니라, 도구를 발견하고, 데이터를 읽고, 작업을 실행하고, 재사용 가능한 프롬프트까지 공유하는 구조를 제공합니다.
즉, RAG나 함수 호출이 '부분 기술'이라면, MCP는 그 위를 아우르는 '연결 규칙'에 더 가깝습니다.
왜 하필 지금 MCP가 커졌을까?
좋은 아이디어는 많지만, 모두가 열광하는 기술은 드뭅니다. 그런데 MCP는 유난히 빠르게 퍼졌습니다. 이유는 간단합니다. 시대가 딱 이 문제를 원하고 있었기 때문입니다.
AI 업계는 이제 단순한 채팅을 넘어서 에이전트, 즉 일을 수행하는 AI로 이동하고 있습니다. 에이전트가 되려면 외부 세계와 연결되어야 합니다. 파일도 읽어야 하고, 서비스도 호출해야 하고, 실시간 정보도 가져와야 합니다.
그런데 그 연결 방식이 계속 제각각이면 생태계가 커질수록 혼란도 커집니다. 결국 모두가 비슷한 고민을 하게 됩니다.
"이제 연결 방식도 표준이 필요하지 않나?"
MCP는 바로 그 질문에 등장한 답입니다.
게다가 특정 한 회사 전용의 닫힌 규격이 아니라, 여러 주체가 활용할 수 있는 개방형 표준이라는 점도 컸습니다. 도구를 만드는 쪽도, AI 앱을 만드는 쪽도, 기업에서 내부 시스템을 연결하려는 쪽도 모두 이해관계가 맞아떨어졌습니다.
쉽게 말해, 시장이 "이쯤 되면 통일 좀 하자"라고 말하던 순간에 등장한 규격이었습니다.
하지만 만능 열쇠는 아니다
여기서 너무 환상만 품으면 안 됩니다. MCP가 대단한 것은 맞지만, 자동으로 모든 걸 해결해 주는 마법 지팡이는 아닙니다.
표준이 생겼다고 해서 보안 문제가 사라지는 것은 아닙니다. 오히려 AI가 더 많은 도구와 데이터에 접근할 수 있게 되는 만큼, 권한 관리와 승인 절차는 더 중요해집니다.
예를 들어 읽기만 가능한 도구와, 실제로 수정까지 가능한 도구는 위험도가 다릅니다. 일정 조회와 일정 삭제는 전혀 다른 문제입니다. 회사 문서를 읽는 것과 고객 정보를 외부로 보내는 것은 더더욱 다르죠.
또한 도구 설명이 부정확하거나, 신뢰할 수 없는 서버를 무심코 붙이면 예상치 못한 행동이 일어날 수도 있습니다.
그래서 MCP를 이해할 때는 두 가지를 같이 봐야 합니다.
하나는 엄청난 확장성이고, 다른 하나는 엄격한 통제의 필요성입니다.
이 둘이 함께 가야 진짜 실전 기술이 됩니다.
이 장에서 꼭 가져가야 할 핵심
이쯤에서 한 문장으로 다시 정리해 봅시다.
MCP는 AI가 외부 데이터와 도구를 표준 방식으로 연결해, 더 정확하게 이해하고 실제 행동까지 할 수 있게 만드는 프로토콜입니다.
그리고 왜 'AI의 USB-C'라고 불리는지도 이제 감이 올 것입니다.
USB-C가 기기 연결의 혼란을 줄였듯, MCP는 AI와 도구 연결의 혼란을 줄입니다.
USB-C가 "일단 규격만 맞으면 꽂아 쓸 수 있게" 만들었듯, MCP는 "일단 MCP만 맞으면 여러 AI와 도구가 더 쉽게 만날 수 있게" 만듭니다.
그래서 MCP는 단순한 개발자 유행어가 아닙니다. AI가 진짜 업무 도구가 되기 위해 반드시 필요한 연결 인프라에 가깝습니다.
다음 장으로 가기 전에
이제 큰 그림은 잡았습니다.
AI는 혼자서는 똑똑하지만 답답합니다. MCP가 붙으면 외부 세계와 연결됩니다. 그래서 AI는 설명을 넘어 행동으로 나아갑니다.
다음 장에서는 이 세계의 등장인물들을 본격적으로 소개할 차례입니다.
누가 전체를 관리하는지, 누가 중간에서 통역하는지, 누가 실제 도구와 데이터를 내어주는지, 그리고 Tools, Resources, Prompts라는 세 가지 마법 도구가 각각 무엇을 하는지 말이죠.
이제부터는 "MCP가 왜 중요한가"를 넘어서, "MCP가 실제로 누구와 어떻게 움직이는가"를 보게 될 것입니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.