AI 에이전트의 미래를 엿보다: MCP(Model Context Protocol)

작성자:관리자 마지막 수정일:

USB-C를 처음 봤을 때 느꼈던 낯섦, 그리고 불가피함

2015년 애플이 맥북에 USB-C 단자 하나만 달고 나왔을 때, 개발자 커뮤니티는 “젠더 값을 또 써야 하네”라며 하루 종일 불평했습니다. 그런데 10년이 지난 지금, USB-C가 없는 노트북을 상상하기조차 어렵습니다. 한 번 표준이 자리 잡으면 ‘선택’은 곧 ‘필수’로 바뀝니다.

mcp overview
(출처: What is Model Context Protocol (MCP)?)

AI 산업에서도 비슷한 일이 벌어지고 있습니다. 2024년 11월, 앤트로픽이 MCP(Model Context Protocol)를 공개했고, 2025년 3월 27일 샘 올트먼이 “GPT 기반 모든 에이전트 SDK에 MCP를 기본 지원하겠다”고 발표했습니다. 양대 LLM 기업이 같은 규격을 택했다는 점은 ‘표준 탄생’의 전형적 징후입니다.

15년 동안 백엔드에서 수많은 프로토콜의 흥망성쇠를 지켜본 제 경험상, 새로운 규격이 진짜 표준이 되려면 두 가지가 필요합니다.

  1. 사용 편리성—개발자가 “더 쉽다”고 느끼는지,
  2. 경제 논리—플레이어가 “그래야 돈이 된다”고 확신하는지.

MCP는 이미 첫 번째 조건을 충족했고, 두 번째 조건 역시 커서(Cursor)·구글·AWS·스트라이프 등 주요 기업이 서서히 증명하고 있습니다.

개발자 관점에서 체감하는 MCP의 가치

1. API 세상이 충분히 편했는데, 왜 또 다른 프로토콜이 필요할까요?

“REST API도 있고 GraphQL도 있고 함수 호출(schema-based calling)도 있는데, 무엇이 부족합니까?”라는 질문을 자주 받습니다. 핵심은 AI 모델 관점에서 연결 비용이 여전히 크다는 점입니다.

  • API 스펙 잦은 변경
    SaaS 하나에 엔드포인트가 수십 개씩 존재하고 버전이 바뀔 때마다 문서 역시 달라집니다. LLM이 ‘세상의 모든 API’를 기억하기엔 변화의 속도가 너무 빠릅니다.
  • 도구(tool) 정의의 불일치
    GPT 플러그인이나 클로드의 기능 호출을 만들 때마다 JSON 스키마를 직접 정의해야 했습니다. 서버 개발자는 호스트마다 이름만 살짝 다른 함수를 중복 작성해야 했고, 클라이언트 역시 매번 설정을 복사해야 했습니다.
  • 세션형 작업의 제약
    여러 API를 순차 호출하며 파라미터를 넘기려면 별도 오케스트레이션 레이어가 필요했습니다. 이는 곧 학습 곡선과 유지비로 이어졌습니다.

MCP는 ‘도구 = JSON-Schema + 호출 방식 + 권한 요구 사항’이라는 틀을 하나의 압축된 패키지로 선언하도록 강제합니다. 호스트(예: Claude)가 서버(예: 노션)에게 “가능한 도구 목록을 보여 달라”고 요청하면, 서버는 표준 응답으로 JSON 리스트를 반환하고 끝납니다. 네트워크 경로, 인증 흐름, 버전 관리가 한 번에 해결되지요.

2. 노코드에 가까운 ‘코드 한 줄’ 개통식

제가 직접 경험한 사례를 공유하겠습니다. 클로드 데스크톱 앱 설정 파일에 MCP 서버를 한 개 붙이는 과정이었습니다.

npm install -g @suekou/mcp-notion-server

claude_desktop_config.json에 환경변수와 실행 명령 추가

{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "@suekou/mcp-notion-server"],
      "env": { "NOTION_API_TOKEN": "..." }
    }
  }
}

그다음 클로드에게 “사내 협업 AI 에이전트 리서치 페이지 하나 만들어 줘”라고 말했더니,

  • ‘글감/초안’ 데이터베이스를 검색
  • 새 페이지를 생성하고 목차·요구 기능·레퍼런스 링크를 자동 삽입
  • 작업 로그와 URL을 요약해 반환

모든 과정이 단일 세션에서 끝났습니다. REST 시절 같았으면 데이터베이스 ID를 변수로 저장하고, 페이지 API를 호출하고, ACL을 체크하는 등 단계별로 컨트롤러를 작성해야 했겠지요.

3. 기업이 마주한 두 갈래 전략

a. MCP 서버 공급자
AWS·구글·슬랙·스트라이프 등은 자사 API를 MCP 도구 세트로 포장해 공개하고 있습니다. 글로벌 LLM이 ‘플러그인 설치’만으로 곧바로 활용할 수 있으니, 트래픽을 늘리는 가장 빠른 길입니다. 이때 ‘LLM 친화적 도구 UX’를 잘 설계하는 것이 관건입니다.

b. MCP 서버 사용자(에이전트 플랫폼)
오픈AI·퍼플렉시티·IDE 기업(제트브레인, 마이크로소프트) 등은 “우리 에이전트가 남이 만든 MCP 서버를 마음껏 활용하도록 하겠다”는 전략을 취합니다. 다만 보안을 위해 샌드박스와 사용 제한 정책이 필수입니다. 예컨대 결제를 수행하는 스트라이프 도구를 사용할 때, 에이전트가 실수로 0 원 쿠폰을 무한 발행하지 못하도록 막아야 합니다.

두 전략은 충돌하지 않습니다. 한 기업이 공급자이면서 동시에 사용자일 수 있습니다. 구글이 제공하는 캘린더 MCP 서버를 구글의 에이전트 ‘Gemini’가 쓰는 식이지요.

4. 자주 생기는 오해 바로잡기
  1. “MCP면 보안이 자동으로 해결된다?”
    그렇지 않습니다. MCP는 ‘어떤 자격 증명을 쓰라’고 강제하지 않습니다. OAuth·JWT·API Key 등 기존 체계를 그대로 사용하며, 단지 “이 도구를 호출하려면 auth 파라미터가 필요하다”고 명시할 뿐입니다.
  2. “이제 플러그인·함수 호출은 폐기되는 건가요?”
    아닙니다. GPT-4o의 함수 호출이나 클로드의 오리지널 ‘tool use’ 체계는 여전히 유효합니다. MCP는 상위이자 브리징 레이어로, 과거 REST가 완전히 사라지지 않은 것처럼 오래 공존할 것입니다.
  3. “AI가 알아서 프로그래밍하는 시대가 곧 온다?”
    절반은 맞고 절반은 아닙니다. 도구가 많아질수록 LLM이 ‘어떤 함수를 호출해야 하는지’ 판단하는 난이도는 오히려 높아집니다. 오픈AI가 ‘tool_choice’에 ‘required(사람이 강제 지정)’ 옵션을 두는 이유도 여기 있습니다.

작은 혁신들의 총합이 가져올 임계점

지난 18개월간 AI 커뮤니티는 ‘모델 성능’보다 ‘에이전트 실행력’에 더 큰 가치를 부여해 왔습니다. 이제 인사 담당자는 “지원자에게 합격 메일 보내고 캘린더 블록 잡아 줘”를 요구하지요. MCP는 이러한 흐름을 뒷받침하는 단일 커넥터입니다.

저는 세 가지 변화를 예상합니다.

  1. AI-First 워크플로
    기획부터 코드 커밋·배포까지 대화 한 번으로 끝내는 팀이 머지않아 등장할 것입니다.
  2. 도구 마켓의 장벽 붕괴
    스타트업도 MCP 서버 하나만 내면 전 세계 LLM을 즉시 고객으로 맞을 수 있습니다.
  3. 개발자 역할의 진화
    앞으로는 ‘LLM이 혼동 없이 사용할 도구 UX’를 설계하는 능력이 REST API 디자인 이상의 경쟁력이 될 것입니다.

물론 해결 과제도 분명합니다.

  • 권한 위임 범위를 얼마나 세밀하게 노출할지,
  • 악성 MCP 서버를 어떻게 검증할지,
  • 무분별한 도구 호출로 인한 비용 폭주를 어떻게 방지할지 등이 남아 있습니다.

그럼에도 USB-C가 5년 만에 모든 포트를 통일했던 전례는 “편익이 리스크를 압도하면 표준은 빠르게 확산된다”는 사실을 보여 줍니다. 지금이야말로 AI 에이전트 생태계에서 작은 실험을 시작하기에 최적의 시점입니다. 노션이든 깃허브든, 혹은 귀사의 사내툴이든 MCP 스키마를 한 번 정의해 보시기 바랍니다. 의외로 ‘설정 한 줄’이 팀의 생산성을 단숨에 바꿔 놓을지도 모릅니다.

마지막으로 질문 하나를 드립니다.

“여러분이 매일 반복하시는 업무 중, AI에게 가장 먼저 맡길 ‘MCP 도구’는 무엇인가요?”

그 답을 찾으시는 순간, 이미 포스트-USB-C 시대의 첫걸음을 내디디신 겁니다.

관련 글 보기