AI 도입 전략2026.08.11읽는 시간 12분
MCP란? 5분 정리: LLM 도구 연결 표준
LLM에 사내 도구를 붙이는 개방형 표준 — API·RAG와의 차이부터 도입 4단계와 검토 시점 판단 기준까지.
—VIEWS
—LIKES
—SAVES
LLM에 사내 도구를 붙이는 개방형 표준 — API·RAG와의 차이부터 도입 4단계와 검토 시점 판단 기준까지.
사내에 ChatGPT나 Claude를 도입한 회사에서 반복되는 질문이 있습니다. "요약은 잘하는데 왜 우리 ERP 숫자는 못 읽나요?", "결국 사람이 복사해서 붙여넣어야 하는 것 아닌가요?", "도구마다 연동을 새로 만들어야 하나요?" 세 질문 모두 모델 성능이 아니라 연결 방식 문제입니다.
MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)는 이 지점을 겨냥한 개방형 표준입니다. 이 글에서는 MCP가 무엇을 표준화하는지, API·RAG와 어디가 다른지, 도입이 어떤 단계로 진행되는지를 정리했습니다. 우리 회사가 지금 검토할 시점인지 가리는 기준도 함께 담았습니다.
MCP는 LLM 애플리케이션이 외부 데이터·도구·시스템에 접근하는 방식을 통일한 개방형 프로토콜입니다. Anthropic이 2024년 11월 공개했고, 2025년 12월 리눅스 재단 산하 Agentic AI Foundation으로 이관되면서 OpenAI·구글·마이크로소프트·AWS 등이 지원 진영에 합류했습니다. 특정 벤더의 사양이 아니라 업계 공통 규격으로 자리를 옮긴 셈입니다.
비유하자면 AI용 USB-C에 가깝습니다. 마우스와 모니터와 저장장치를 저마다 다른 단자로 연결하던 시절에는 기기를 하나 늘릴 때마다 케이블을 새로 사야 했습니다. 단자가 통일되자 그 비용이 사라졌습니다. MCP도 같은 일을 합니다. AI 애플리케이션이 어떤 도구를 쓸 수 있는지 발견하고 호출하는 절차를 한 가지 방식으로 정리합니다.
MCP 서버가 클라이언트에 노출하는 것은 세 가지입니다.
구성 요소 | 내용 | 업무 예시 |
|---|---|---|
tools | 모델이 호출해 실제 작업을 수행하는 기능 | 티켓 생성, 재고 조회, 메일 발송 |
resources | 모델이 읽어 맥락으로 삼는 데이터 | 계약서 원문, 제품 사양서, 정책 문서 |
prompts | 반복 작업을 위해 미리 정의한 지시문 | 주간 보고 초안 템플릿, 이슈 분류 기준 |
메시지 형식은 JSON-RPC 2.0을 따릅니다. 어떤 도구를 노출하고 어떻게 호출할지가 문서가 아니라 규격으로 정해져 있습니다. 그래서 한 번 만든 MCP 서버는 클라이언트를 바꿔가며 재사용합니다.
가장 헷갈리는 지점입니다. 셋은 층이 다르고 서로를 대체하지 않습니다. MCP는 기존 API 위에 얹히는 연결 규격이고 RAG는 그 연결로 가져온 데이터를 답변에 쓰는 방식입니다.
구분 | 핵심 역할 | AI 관점에서의 차이 |
|---|---|---|
API | 시스템끼리 데이터를 주고받는 약속 | 사람이 문서를 읽고 연동 코드를 짜야 합니다. 모델이 스스로 발견하지는 못합니다 |
플러그인 | 특정 앱에 기능을 얹는 확장 | 그 플랫폼 안에서만 동작해 다른 도구로 옮기기 어렵습니다 |
RAG | 외부 지식을 검색해 답변 근거로 사용 | 읽기 중심입니다. 문서를 찾아 인용하되 시스템을 바꾸지는 않습니다 |
MCP | 도구·데이터·지시문을 노출하는 연결 규격 | 발견과 호출 절차가 표준화되어 읽기와 실행을 함께 다룹니다 |
차이를 한 문장으로 좁히면 이렇습니다. RAG는 "지난달 계약 조건이 어떻게 되나요"에 답합니다. MCP는 거기서 한 걸음 더 나가 "그 조건대로 갱신 티켓을 만들고 담당자 캘린더에 검토 일정을 잡는" 동작까지 연결합니다. 검색 증강 생성 자체의 구조가 궁금하다면 RAG란? 검색 증강 생성 5분 정리를 먼저 보시면 이 구분이 선명해집니다.
한 가지 짚어둘 게 있습니다. MCP를 붙인다고 기존 API가 사라지지는 않습니다. MCP 서버 내부에서 실제 동작을 수행하는 것은 결국 사내 API와 데이터베이스입니다. MCP는 그 위에 "AI가 이해할 수 있는 목록과 호출 규칙"을 한 겹 씌우는 일에 가깝습니다.
세 가지 이유가 겹쳤습니다.
첫째, 표준이 업계 공통 자산이 됐습니다. 리눅스 재단 이관 이후 주요 모델 제공사와 클라우드 벤더가 같은 규격을 지원합니다. 덕분에 벤더 한 곳에 묶이지 않고 연결 자산을 쌓습니다. 개별 연동과 공통 규격의 차이를 더 넓게 보려면 AI 통합 표준이란? 도구 연결 기준 5분 정리에 정리해 두었습니다.
둘째, 연결 자산이 재사용됩니다. 부서마다 SaaS와 데이터베이스가 다르면 AI 과제는 매번 새 연동 프로젝트가 됩니다. 업무 도메인 단위로 MCP 서버를 설계하면 영업팀 챗봇과 CS팀 에이전트가 같은 CRM 서버를 공유합니다. 두 번째 과제부터 착수 비용이 눈에 띄게 떨어집니다.
셋째, 에이전트가 데모에서 멈추는 원인을 정면으로 다룹니다. AI 에이전트는 조회하고 판단하고 실행합니다. 실행 가능한 도구 목록이 정리돼 있지 않으면 마지막 단계에서 반드시 막힙니다.
다만 속도 차이는 분명히 알고 시작해야 합니다. Stacklok과 리눅스 재단 AAIF가 2026년 미국·영국 기업 소프트웨어 엔지니어 100명을 대상으로 한 조사에서 41%가 어떤 형태로든 MCP를 프로덕션에 올렸다고 답했습니다. 그런데 전사 거버넌스를 갖춘 운영은 5%에 그쳤습니다. 시스코의 「State of AI Security 2026」에서도 에이전틱 AI를 안전하게 운영할 준비가 됐다고 답한 조직은 29%였습니다. 기술이 없어서 멈추는 게 아니라 권한과 감사 기준이 없어서 멈춥니다.
전사 도입이 아니라 반복 빈도가 높고 실패해도 되돌릴 수 있는 업무 하나를 고릅니다. 견적서 초안 작성, 문의 티켓 분류, 재고 조회처럼 하루에도 여러 번 일어나면서 되돌리기 쉬운 일이 좋은 후보입니다.
같은 업무 안에서도 조회는 자동으로 열고 생성·수정·삭제는 사람 승인 뒤에 실행하도록 나눕니다. 이 경계는 코드가 아니라 정책 문서로 먼저 정해야 합니다. 시스템 층위별로 무엇을 어디까지 열지는 AI 시스템 연동이란? 읽기·실행·기록에서 더 자세히 다뤘습니다.
MCP 서버가 관리자 권한 하나로 모든 데이터를 보게 만들면 편하지만 위험합니다. 호출한 사용자의 권한을 그대로 물려받도록 설계해야 기존 접근 통제가 무력화되지 않습니다. 2026년 초 조사에서 인터넷에 노출된 MCP 서버 약 7,000대 중 절반가량이 인증 통제 없이 돌아갔습니다. 사고 대부분은 프로토콜 결함이 아니라 이 설정 공백에서 나옵니다.
누가 언제 어떤 도구를 호출했고 결과가 무엇이었는지 기록합니다. 성공률, 사람 개입 비율, 건당 처리 시간 세 가지만 모아도 확산 여부를 숫자로 판단할 수 있습니다.
다음 여섯 항목 중 3개 이상 해당하면 검토를 시작할 때입니다.
같은 데이터를 매일 복사해 옮깁니다
사람이 같은 화면에서 같은 값을 옮겨 적는 일이 하루에도 반복됩니다.
LLM 답변 이후가 수작업으로 끊깁니다
초안은 AI가 만들지만 등록·전송·승인은 사람이 처리합니다.
부서마다 연동을 새로 만들고 있습니다
AI 과제가 늘 때마다 연동 프로젝트가 처음부터 다시 시작됩니다.
고위험 작업이 문서로 구분돼 있습니다
AI가 실행하면 안 되는 작업의 목록과 기준이 이미 정리돼 있습니다.
사용자별 권한 체계가 잡혀 있습니다
기존 시스템에서 누가 무엇을 볼 수 있는지가 계정 단위로 관리됩니다.
호출 로그를 검토할 담당자가 있습니다
성공·실패 기록을 남기고 주기적으로 확인할 사람이 지정돼 있습니다.
앞의 세 항목은 필요를 가리키고 뒤의 세 항목은 준비 상태를 가리킵니다. 앞쪽만 해당한다면 연결보다 권한과 로그 정비가 먼저입니다.
범위에 따라 크게 달라지지만 첫 도입은 대체로 다음 구간에서 움직입니다.
단계 | 기간 | 산출물 |
|---|---|---|
업무 진단과 대상 선정 | 1~2주 | 후보 업무 목록, 위험도 분류, 권한 정책 초안 |
MCP 서버 1개 구축과 파일럿 | 3~6주 | 도구 목록, 승인 흐름, 호출 로그, 성공률 지표 |
2차 업무 확장 | 2~4주 | 기존 서버 재사용, 신규 도구 추가 |
비용에서 가장 큰 변수는 서버 개발이 아니라 대상 시스템의 상태입니다. API가 없거나 권한 체계가 부서마다 다른 레거시가 섞이면 준비 기간이 배로 늘어납니다. 반대로 두 번째 업무부터는 앞서 만든 서버를 그대로 쓰기 때문에 비용 곡선이 꺾입니다.
도구부터 늘립니다
서버를 여러 개 붙여놓고 어떤 업무를 끝낼지는 정하지 않은 경우입니다. 도구 목록이 길어질수록 모델이 잘못된 도구를 고를 확률도 함께 올라갑니다.
읽기와 실행을 한꺼번에 엽니다
조회만 열었어도 충분했을 과제에 삭제·전송 권한까지 함께 부여했다가 사고 뒤에 전체를 닫는 사례가 반복됩니다.
권한을 서비스 계정 하나로 처리합니다
편의를 위해 관리자 계정을 물리면 기존 접근 통제가 통째로 우회됩니다.
로그 없이 파일럿을 끝냅니다
체감은 좋았다는 보고만 남고 확산 근거가 없어 두 번째 과제가 착수되지 않습니다.
네 패턴 모두 기술이 아니라 사전 합의의 문제입니다. 그래서 서버 개발보다 정책 정의를 먼저 놓아야 합니다.
세 조건에 모두 해당한다면 순서를 바꾸는 편이 낫습니다. 사내 데이터가 어디에 무엇이 있는지 정리되지 않았고, 자동화할 업무가 정해지지 않았으며, 권한과 보안을 책임질 담당자가 없는 경우입니다.
이때는 사내 문서 검색이나 요약처럼 읽기 중심이면서 되돌리기 쉬운 과제부터 시작하는 편이 위험 대비 학습량이 큽니다. 실행 권한이 없으니 사고 반경이 좁고 그 과정에서 데이터 위치와 품질이 자연스럽게 드러납니다. 모델이 애초에 어떻게 답을 만드는지 이해가 필요하다면 LLM이란? 5분 정리가 출발점입니다.
여기까지 읽고 "우리는 필요를 가리키는 항목만 해당하는데"라는 판단이 섰다면, 그 자체가 좋은 출발점입니다. 어떤 업무를 먼저 열고 어떤 권한을 닫아둘지 정리하면 첫 파일럿의 범위와 검증 지표를 2주 안에 문서로 확정할 수 있습니다.
무료 AX 진단에서는 업무 흐름과 데이터 접근성, 권한 체계, 자동화 후보를 함께 점검하고 RAG·MCP·에이전트 중 무엇부터 착수할지 순서를 제안합니다. 첫 미팅에서는 반복 업무 목록과 현재 권한 구조를 확인하고 되돌리기 쉬운 과제부터 후보를 좁힙니다. 전체 도입 로드맵이 궁금하다면 AX 컨설팅이란? 도입 4단계·비용 총정리를 함께 보시면 됩니다.
무료 AX 진단을 신청하세요.
Anthropic이 2024년 11월 처음 공개했지만 2025년 12월 리눅스 재단 산하 Agentic AI Foundation으로 이관됐습니다. OpenAI·구글·마이크로소프트·AWS 등이 지원 진영에 있어 지금은 특정 벤더의 사양이 아니라 업계 공통 규격에 가깝습니다. 모델을 바꿔도 연결 자산을 그대로 쓸 수 있다는 뜻입니다.
RELATED · 함께 읽으면 좋은 글
AI와 업무 도구가 따로 노는 원인은 모델이 아니라 연결 방식입니다. AI 통합 표준의 뜻과 개별 연결과의 차이, 붙이기 전 정할 4가지를 5분에 정리했습니다.
RAG(검색 증강 생성)가 무엇인지, 기존 LLM과 어떻게 다른지 5분 만에 정리했습니다. 작동 4단계와 도입 체크리스트, 잘 맞는 업무까지 짚습니다.
LLM이 정확히 뭔지, ChatGPT·검색엔진과 어떻게 다른지 5분 만에 정리했습니다. 기업이 어떤 업무부터, 어떤 4단계로 적용하면 되는지 체크리스트와 함께 짚습니다.