MCP는 결국 USB-C였다 — Model Context Protocol 실전 가이드

작년 11월에 MCP 스펙이 처음 공개됐을 때, 회사 슬랙에 내가 한 줄을 남겼다.

"USB-C 다."

그게 사실 모든 평가다. 6개월간 어댑터를 직접 짜고 다시 짜고 또 다시 짜면서, 그 한 줄에서 멀어진 적이 없다. 다만 왜 그게 의미 있는지에 대해선 더 할 말이 생겼다.

MCP 가 풀려고 한 문제

LLM 에이전트에게 외부 도구를 쓰게 하는 건 2023년부터 가능했다. OpenAI 의 function calling, Anthropic 의 tool use, LangChain 의 tool 추상화. 다 같은 형식이었다 — 모델이 JSON 을 토하면 우리가 알아서 실행한다.

문제는 모델마다, 도구마다, 클라이언트마다 그 추상화가 미묘하게 달랐다는 거다. 에이전트가 GitHub 도구를 쓸 수 있도록 짠 어댑터를 그대로 Slack 에이전트에 못 가져다 썼다. JIRA 어댑터는 또 다른 코드. 같은 GitHub 어댑터도 OpenAI 모델용과 Claude 용이 미묘하게 달랐다.

우리가 짠 코드의 60% 가 어댑터의 어댑터 였다. 진짜 로직은 40%.

MCP 가 한 일은 단순하다. 모델 ↔ 도구 사이에 공용 프로토콜 을 끼워 넣었다.

이전:                          MCP 이후:

[모델 A] ──── [도구 X 어댑터]    [모델 A] ──┐
[모델 A] ──── [도구 Y 어댑터]              ├── [MCP 클라이언트]
[모델 B] ──── [도구 X 어댑터']             │       │
[모델 B] ──── [도구 Y 어댑터']   [모델 B] ──┘       │
                                                  ▼
N 모델 × M 도구 = N×M 어댑터    [MCP 서버: 도구 X]
                                [MCP 서버: 도구 Y]

                                N + M

USB-C 비유가 맞는 이유다. 옛날엔 휴대폰마다 충전 케이블이 달랐다. 지금은 케이블 한 가닥이면 된다.

한 줄 정의

MCP (Model Context Protocol) 는 LLM 클라이언트(모델·에이전트 호스트) 와 외부 도구·데이터 소스 사이의 통신을 표준화하는 오픈 프로토콜 이다. 어떤 도구 서버든 이 프로토콜을 따르면, 어떤 모델이든 추가 어댑터 없이 그 도구를 쓸 수 있다.

세 단어가 결정적이다 — 오픈, 프로토콜, 추가 어댑터 없이.

6개월간 우리를 문 함정들

함정 1 — "도구 한 개" 라는 단위

처음에 우리는 기능 하나 마다 도구를 만들었다. create_issue, comment_on_issue, assign_issue, close_issue. 30개쯤 만들었더니 모델이 어떤 도구를 골라야 하는지 헤매기 시작했다.

해결책은 큰 단위 도구 + 그 도구의 입력 스키마로 세부 동작 을 표현하는 것. manage_issue 하나에 action: "create" | "comment" | "assign" | "close". 도구 30개가 1개로 줄었고, 모델 정확도가 눈에 띄게 올라갔다.

함정 2 — 권한 모델이 비어 있다

MCP 스펙은 프로토콜 만 정의한다. 누가 어떤 도구를 쓸 수 있는가 는 정의하지 않는다. 이건 의도된 것 — 프로토콜의 책임이 아니다. 하지만 그 책임을 어디선가 풀지 않으면 사고가 난다.

CollabOps 에서 우리는 그걸 실행 레이어 위에서 푼다. MCP 서버는 도구를 노출만 한다. 권한은 우리 그래프 위의 역할(role) 과 경계(scope) 가 정의한다. → Execution Layer 란 무엇인가

함정 3 — Tool description 의 길이

긴 description 을 쓰면 모델이 컨텍스트 토큰 을 거기에 다 쓴다. 50개 도구를 노출하면 시스템 프롬프트가 8K 토큰을 먹는다. 그러면 실제 작업 컨텍스트가 들어갈 자리가 없다.

우리는 description 을 두 개의 레이어 로 짠다. 짧은 한 줄 (모델이 도구 선택 시 본다) + 긴 상세 (모델이 그 도구를 호출하기로 결정한 후 에만 본다). MCP spec 에 명시된 패턴은 아니지만, 클라이언트에서 그 동작을 흉내 낼 수 있다.

DevOps 에이전트에 MCP 가 결정적인 이유

이 셋 때문이다.

1. 도구 다양성 — DevOps 에이전트는 git, CI, JIRA, Slack, Datadog, PagerDuty, Kubernetes 등을 한 워크플로우 안에서 쓴다. 어댑터를 N×M 으로 짜는 건 운영이 안 된다.
2. 고객사마다 다른 도구 조합 — 우리 고객은 GitHub 을 쓰는 곳도, GitLab 을 쓰는 곳도, 사내 자체 git 을 쓰는 곳도 있다. MCP 서버 단에서 고객사별 도구 묶음 을 갈아끼울 수 있다.
3. 온프레미스 격리 — MCP 서버는 고객사 내부에 깔린다. 모델이 우리 클라우드에서 돌아도, 도구 호출은 고객 내부에서 끝난다. 데이터가 외부로 나가지 않는다. → 폐쇄망에서 CI/CD 만들기

세 번째가 특히 우리에겐 결정적이었다. 공공·금융 고객사는 데이터 경계 를 인증서 수준에서 검증한다. MCP 가 없었으면 우리가 자체적으로 비슷한 격리 프로토콜을 만들었을 거고, 그건 표준이 아니라 우리만의 방언이 됐을 거다.

흔한 오해 두 개

"MCP 는 또 다른 LLM 프레임워크다." 아니다. 프레임워크는 코드 다. MCP 는 프로토콜 이다. 프레임워크 없이도 쓸 수 있다.

"MCP 가 LangChain 을 대체한다." 다른 층이다. LangChain 은 에이전트 호스트 단에서 작동한다. MCP 는 호스트 ↔ 도구 사이의 와이어 프로토콜이다. 둘이 같이 쓸 수도 있다.

MCP 도입이 가장 빨리 이득이 되는 건 도구 어댑터 코드가 점점 무거워지는 걸 이미 느끼는 LLM 에이전트 팀이다. 엔터프라이즈 / 온프레미스 환경에 에이전트를 넣으려는 쪽에도 크다. 데이터 경계 안에서 도구 호출을 끝낼 수 있다 는 게 보안 검토 통과의 결정적 카드가 된다.

반대로 LLM 을 처음 쓰는 단계의 팀이라면 서두를 필요 없다. tool use 의 일반적인 형태 를 먼저 익히고 나서 MCP 로 넘어오는 게 더 자연스럽다.