MCP 이해하기 - AI 가 회사 시스템과 대화하는 표준

AI 챗봇을 업무에 써 본 회사들이 공통적으로 부딪히는 벽이 있습니다. 챗봇이 세상 지식은 잘 아는데, 정작 우리 회사 일은 하나도 모른다는 것입니다. "이번 달 신규 문의가 몇 건이었지?"라는 질문의 답은 사내 시스템 어딘가에 분명히 있는데, AI 는 그 시스템에 손을 댈 수 없으니 일반론만 늘어놓습니다.

그래서 AI 와 사내 시스템을 연결하는 작업이 필요해지는데, 이게 지금까지는 시스템마다 전부 별도 개발이었습니다. 이 연결 방식을 표준화하겠다고 나온 것이 MCP(Model Context Protocol)입니다. 요즘 AI 도입 논의에 빠짐없이 등장하는 이 용어를, 개발자가 아닌 분도 판단에 쓸 수 있는 수준으로 정리했습니다.

문제의 본질 - 연결의 수가 곱셈으로 늘어난다

회사에서 쓰고 싶은 AI 가 두세 종류이고, 연결하고 싶은 시스템이 다섯 개라고 해 봅시다. ERP, 그룹웨어, 고객관리, 회계, 파일 서버. 표준이 없던 시절에는 이 조합 하나하나가 별도의 연동 개발이었습니다. AI 세 개 × 시스템 다섯 개면 열다섯 개의 다리를 놓아야 하고, 내년에 더 좋은 AI 모델로 갈아타면 그 다리를 다시 놓아야 합니다.

휴대폰 충전기가 제조사마다 달랐던 시절을 떠올리면 정확합니다. 그 문제를 USB-C 라는 규격 하나가 정리했듯이, AI 와 시스템 사이의 연결 규격을 하나로 정하자는 것이 MCP 의 발상입니다. 실제로 MCP 공식 문서가 스스로를 "AI 의 USB-C"라고 소개합니다.

MCP 는 무엇을 정해 놓았나

MCP 는 2024년 말 앤스로픽(클로드를 만드는 회사)이 공개한 개방형 표준입니다. 구조는 단순합니다. 시스템 쪽에 'MCP 서버'라는 창구를 하나 세워 두면, 규격을 따르는 AI 는 어느 회사 모델이든 그 창구를 통해 시스템과 대화할 수 있습니다.

창구가 제공하는 것은 크게 두 가지입니다. 하나는 읽기 - "이번 달 문의 목록을 보여 줘" 같은 조회. 다른 하나는 실행 - "이 문의에 답장 초안을 등록해 줘" 같은 동작입니다. 어떤 데이터를 보여 주고 어떤 동작을 허용할지는 창구를 만드는 쪽, 그러니까 회사가 정합니다. AI 에게 전권을 주는 게 아니라, 회사가 열어 준 문으로만 드나들게 하는 구조입니다.

이 구조의 실익은 "한 번 만들면 재사용된다"에 있습니다. MCP 서버를 한 번 세워 두면 AI 모델을 바꿔도, 새 AI 도구를 추가해도 그 창구를 그대로 씁니다. 열다섯 개의 다리가 다섯 개의 창구로 줄어드는 셈입니다.

그림이 잘 안 그려진다면 이런 장면을 떠올리면 됩니다. 문의 관리 시스템에 MCP 서버를 세워 둔 회사의 직원이 AI 에게 "지난주 들어온 문의 중에 아직 답 안 한 것만 추려서 급한 순서로 정리해 줘"라고 말합니다. AI 는 MCP 창구로 문의 목록을 조회하고, 답변 여부를 확인하고, 정리한 결과를 내놓습니다. 예전 같으면 담당자가 시스템에 로그인해 화면을 뒤지던 10분짜리 일이, 말 한마디로 끝나는 것입니다. 핵심은 이 대화에 쓰인 AI 가 무엇이든 - 클로드든 ChatGPT 든 - 같은 창구가 그대로 일한다는 점입니다.

유행어 단계는 지났다

새 기술 용어를 들으면 "이거 2년 뒤에도 남아 있을까"부터 따져 보게 됩니다. 합리적인 의심이고, MCP 는 그 검증 구간을 통과했다고 보는 편이 맞습니다.

공개 이후 주요 AI 업체들이 자사 제품에 이 표준을 채택했고, 공개 레지스트리에 등록된 MCP 서버가 수천 개 규모로 쌓였습니다. 올해 나온 한 업계 조사에서는 응답 기업의 40% 이상이 MCP 서버를 제한적으로든 전면적으로든 운영 환경에 도입했다고 답했습니다. 표준 자체도 계속 다듬어지고 있어서, 2026년 7월에는 대규모 서비스 인프라에 얹기 쉽게 만드는 방향의 큰 개정판이 나왔습니다. 표류하다 사라지는 규격이 아니라, 산업이 실제로 올라타서 손보고 있는 규격이라는 뜻입니다.

좋아 보이는데, 위험은 없나

있습니다. MCP 서버를 세우는 일은 시스템에 문을 하나 새로 내는 일이라, 문단속 설계가 본체만큼 중요합니다.

권한이 첫 번째입니다. 기존 시스템에서 영업팀이 볼 수 없는 데이터는 AI 를 거쳐도 볼 수 없어야 합니다. 이 상속을 설계하지 않으면 챗봇이 권한 체계를 우회하는 뒷문이 됩니다.

AI 특유의 사고도 있습니다. AI 가 외부 문서를 읽다가 그 문서 안에 심어진 지시문을 따라 버리는, 프롬프트 인젝션이라 불리는 공격 유형입니다. 그래서 돌이킬 수 없는 동작 - 삭제, 발송, 결제 - 에는 사람의 승인 단계를 끼워 넣는 것이 현재의 표준적인 설계입니다.

기록도 필요합니다. AI 가 언제 무엇을 조회하고 실행했는지 남는 감사 로그가 없으면, 문제가 생겼을 때 원인을 추적할 수 없습니다.

그래서 무엇부터 준비해야 하나

MCP 는 창구의 규격일 뿐, 창구 뒤의 물건이 엉망이면 소용이 없습니다. 같은 고객이 시스템마다 다른 이름으로 등록돼 있다면, AI 는 그 혼란을 성실하게 답변으로 되돌려 줄 것입니다. 데이터 정리가 먼저이고, 시스템에서 데이터를 꺼낼 통로(API)가 그다음이고, MCP 는 그 위에 얹는 마지막 층입니다. 이 순서는 레거시 시스템에 AI 붙이기에서 다룬 순서와 정확히 같습니다.

도입을 검토하는 단계라면, 개발사에 이렇게 물어보시면 됩니다. "우리 시스템에 MCP 서버를 세운다면 어떤 데이터와 동작을 노출하실 건가요, 그리고 권한과 승인은 어떻게 처리되나요." 이 질문에 구체적인 답이 나오는지가, 유행어를 파는 곳과 설계를 하는 곳을 가르는 기준입니다.