MCP 서버 완전 가이드 2026 — AI 에이전트 프로토콜·A2A 차이와 구축 기준

MCP와 A2A, AI 에이전트 시대의 TCP/IP가 될 수 있을까?

2026년 AI 업계에서 가장 활발하게 논의되는 주제 중 하나가 바로 에이전트 간 통신 프로토콜입니다. Anthropic이 만든 MCP(Model Context Protocol)와 Google이 주도한 A2A(Agent-to-Agent Protocol)가 대표적인데, 이 두 프로토콜이 AI 에이전트 생태계의 사실상 표준으로 자리잡고 있습니다.

왜 갑자기 프로토콜이 중요해졌을까요? AI 에이전트가 단독으로 작동하던 시대는 지났습니다. 이제는 여러 에이전트가 협업하고, 외부 도구와 데이터를 실시간으로 연동해야 하는 멀티에이전트 환경이 기본이 됐기 때문입니다.

MCP는 정확히 어떤 역할을 할까?

MCP는 한마디로 에이전트가 외부 도구와 대화하는 방식을 표준화한 프로토콜입니다. Anthropic이 개발했고, 2025년 12월에 Linux Foundation의 Agentic AI Foundation(AAIF)에 기증됐습니다.

쉽게 비유하면, USB가 다양한 기기를 하나의 규격으로 연결해주는 것처럼 MCP는 AI 에이전트가 데이터베이스, API, 파일시스템 등 외부 리소스에 접근하는 방식을 통일합니다.

현재 MCP의 위상을 숫자로 보면:

• Python/TypeScript SDK 월간 다운로드 9,700만 회 이상
• Anthropic, OpenAI, Google, Microsoft, Amazon 등 모든 주요 AI 기업 채택
• 수천 개의 MCP 서버가 이미 커뮤니티에서 운영 중

A2A는 MCP와 뭐가 다를까?

여기서 중요한 구분이 필요합니다. MCP가 에이전트↔도구 간 통신이라면, A2A는 에이전트↔에이전트 간 통신을 담당합니다.

A2A는 Google이 2025년 4월에 발표했고, 같은 해 6월 Linux Foundation에 기증했습니다. 핵심 개념은 Agent Card인데, 각 에이전트가 자신의 역할, 능력, 인증 정보를 담은 카드를 공개하면, 다른 에이전트가 이를 탐색하고 적합한 에이전트에게 작업을 위임하는 구조입니다.

기업 AI 전환에 MCP와 A2A가 왜 중요할까?

기업에서 AI를 도입할 때 가장 흔한 문제가 사일로(silo) 현상입니다. 마케팅팀은 마케팅 AI 도구를, 개발팀은 코딩 AI를, 고객지원팀은 챗봇을 각각 사용하는데, 이 에이전트들이 서로 소통하지 못하면 전체적인 효율은 기대만큼 올라가지 않습니다.

MCP + A2A 조합이면 이 문제를 구조적으로 해결할 수 있습니다:

1. MCP로 각 에이전트가 사내 데이터베이스, CRM, ERP 등에 표준화된 방식으로 접근
2. A2A로 마케팅 에이전트가 데이터 분석 에이전트에게 리포트를 요청하고, 그 결과를 고객지원 에이전트가 활용

나무숲(TreeSoop) 팀이 기업 AI 시스템을 구축할 때도 이런 프로토콜 기반 설계를 적극 활용하고 있습니다. 특히 MCP 서버를 통해 기존 사내 시스템과 AI 에이전트를 연결하는 패턴은 실무에서 검증된 접근법입니다.

실제 도입 시 고려해야 할 점은?

프로토콜 표준이 정해졌다고 해서 바로 적용할 수 있는 건 아닙니다. 몇 가지 실무적 고려사항을 짚어보면:

• 보안: A2A의 Agent Card에 인증/권한 정보가 포함되지만, 사내 민감 데이터에 대한 접근 제어는 별도로 설계해야 합니다
• 모니터링: 멀티에이전트 환경에서는 어떤 에이전트가 어떤 작업을 수행했는지 추적하는 옵저버빌리티가 필수입니다
• 폴백 전략: 에이전트 간 통신이 실패했을 때의 대응 로직을 미리 설계해두어야 합니다
• 점진적 도입: 한 번에 모든 시스템을 에이전트화하기보다, 특정 워크플로우부터 파일럿으로 시작하는 게 현실적입니다

MCP 서버를 직접 만들어야 하는 경우는 언제인가

먼저 만들지 않아도 되는 경우가 훨씬 많습니다. 이미 공개된 서버가 수천 개이고, 파일시스템·깃·DB·브라우저처럼 흔한 대상은 대부분 누군가 만들어 뒀습니다. 검색부터 해보는 게 순서입니다.

직접 만들 이유가 생기는 건 대체로 세 경우입니다.

첫째, 대상이 국내 환경 전용일 때. 한글 문서, 국내 전자결재, 특정 SaaS의 한국 리전 API처럼 글로벌 커뮤니티가 만들 유인이 없는 대상입니다.

둘째, 기존 서버의 응답이 너무 클 때. MCP 서버는 대체로 "가능한 한 많이 돌려주는" 방향으로 설계됩니다. 그런데 그 응답이 전부 모델 컨텍스트로 들어가므로, 큰 응답은 그대로 토큰 비용이 됩니다.

셋째, 사내 시스템에 붙일 때. 인증·권한이 얽혀 있으면 범용 서버로는 안 되고, 조직 정책을 아는 쪽이 만들어야 합니다.

나무숲이 만든 세 가지

1. hwp-mcp — 한글 문서를 읽고 쓰는 MCP 서버

hwp-mcp는 Claude·Cursor 같은 MCP 호환 도구에서 `.hwp`/`.hwpx`를 읽고, 텍스트를 수정하고, 템플릿을 채우고, 새 문서를 만들 수 있게 하는 서버입니다. MIT 라이선스이고 npm에 `hwp-mcp`로 배포돼 있습니다.

여기서 분명히 해둘 것이 있습니다. 포맷 처리 엔진은 우리가 만들지 않았습니다. 한글 포맷(HWP 5.0 바이너리, HWPX/OWPML)을 Rust와 WebAssembly로 구현한 rhwp가 그 일을 하고, 우리가 만든 건 그 위에 얹은 에이전트 어댑터 계층입니다.

어댑터가 한 일은 이렇습니다.

• `read_hwp`, `fill_hwp_template`, `replace_hwp_text` 같은 에이전트 친화적 도구 시그니처 — LLM이 자연어 지시로 호출할 수 있는 형태
• 본문·표·이미지·머리말·꼬리말·각주·수식을 한 번에 뽑는 시나리오 중심 순회 로직
• 표 셀 병합 자동 처리, 각주·수식 자동 합본 같은 편의 계층
• `.hwpx` 쓰기를 가능하게 하는 ZIP 레벨 변형 계층
• npm 한 줄 설치 + Node.js WASM 부트스트랩

WebAssembly 엔진을 쓴 덕분에 한컴오피스 설치 없이 macOS·Windows·Linux에서 모두 동작합니다. 기존 HWP 자동화가 대부분 한컴오피스 COM API 기반이라 윈도우 전용이었던 것과 갈리는 지점입니다.

설치는 한 줄입니다.

```bash

claude mcp add hwp-mcp -- npx -y hwp-mcp

```

2. playwright-optimizer — MCP 서버가 아니라 훅 플러그인

브라우저 자동화용 Playwright MCP를 쓰다 보면 응답 크기가 문제가 됩니다. 페이지 하나의 접근성 트리가 3만 7천 자를 넘습니다. 몇 단계만 오가도 컨텍스트가 포화됩니다.

처음에는 MCP 서버를 감싸는 미들웨어를 떠올렸습니다. 실제로 만든 것은 다릅니다. claude-native-plugin의 playwright-optimizer는 MCP 서버가 아니라 Claude Code의 훅(PostToolUse) 플러그인입니다. 응답이 주 모델에 닿기 직전에 가로채, 저비용 모델이 요약한 뒤 넘깁니다.

이 구분이 실무에서 중요합니다. 문제가 "도구가 없다"가 아니라 "도구의 출력이 너무 크다"라면, 새 MCP 서버를 만드는 게 아니라 기존 서버 뒤에 계층을 하나 두는 게 맞습니다. 자세한 구조와 절감 실측치는 Playwright MCP 토큰 최적화에 정리했습니다.

3. 뉴스 수집 MCP — 사내 파이프라인용

일일 AI 뉴스를 모아 정리하고 배포하는 시스템에도 MCP를 썼습니다. 구축 사례는 MCP로 만든 AI 뉴스 수집·배포 시스템에 별도로 적었습니다. 사내 파이프라인이 대상이라 공개 서버로는 대체가 안 되는 경우였습니다.

만들면서 배운 다섯 가지

1. 응답 크기가 곧 비용이다

MCP 서버를 만들 때 가장 흔한 실수가 "일단 다 돌려주기"입니다. REST API를 설계하던 감각으로 만들면 그렇게 됩니다. 그런데 MCP 응답은 전부 모델 컨텍스트로 들어갑니다. 반환 필드 하나를 줄이는 게 곧 토큰을 줄이는 일입니다.

2. 참조값은 절대 잃으면 안 된다

응답을 줄이더라도 요소 참조값(`ref=` 류)은 보존해야 합니다. 이게 있어야 모델이 다음 액션에서 대상을 정확히 지목합니다. 요약하다 참조를 날리면 절감은 되는데 동작이 깨집니다.

3. 도구 시그니처는 LLM이 읽는 문서다

함수명과 파라미터 이름이 곧 LLM이 언제 이 도구를 쓸지 판단하는 근거입니다. `getData(type, opt)`보다 `read_hwp(path)`·`fill_hwp_template(path, fields)`처럼 동작과 대상이 이름에 드러나야 오호출이 줄어듭니다.

4. 원자적 도구보다 시나리오 도구가 낫다

"본문 읽기", "표 읽기", "각주 읽기"를 따로 만들면 모델이 세 번 호출합니다. 왕복마다 컨텍스트가 쌓입니다. 실제 사용 시나리오 단위로 묶어 한 번에 돌려주는 편이 총 토큰이 적습니다.

5. 배포 방식이 채택률을 가른다

기술이 좋아도 설치가 복잡하면 아무도 안 씁니다. npm 한 줄, `claude mcp add` 한 줄로 끝나야 합니다. 설치 문턱이 곧 사용자 수입니다.

MCP 서버와 훅 플러그인, 무엇을 선택할까

134~167 단어 자립형 답변: MCP 서버를 직접 만들어야 할까?

MCP(Model Context Protocol) 서버는 AI 에이전트가 외부 도구·데이터에 접근하도록 표준 인터페이스를 제공하는 프로그램입니다. 공개된 서버가 수천 개이므로 파일시스템·깃·DB·브라우저처럼 흔한 대상은 검색해서 쓰는 편이 먼저입니다. 직접 만들 이유가 생기는 건 세 경우입니다. 대상이 국내 환경 전용이라 글로벌 커뮤니티가 만들 유인이 없을 때, 사내 인증·권한이 얽혀 범용 서버로 대체할 수 없을 때, 그리고 필요한 도구는 있으나 응답이 지나치게 커서 컨텍스트를 포화시킬 때입니다. 다만 세 번째 경우는 새 서버를 만드는 것이 아니라 기존 서버 뒤에 요약 계층이나 훅 플러그인을 두는 편이 적절합니다. 구현 시에는 응답 크기를 줄이되 요소 참조값을 보존하고, 도구 이름에 동작과 대상을 드러내며, 원자적 도구보다 실제 사용 시나리오 단위로 묶어 호출 왕복을 줄이는 것이 토큰 비용을 낮춥니다.

자주 묻는 질문

Q. MCP 서버를 만들려면 어떤 언어를 써야 하나요?

공식 SDK가 Python과 TypeScript로 제공되므로 둘 중 익숙한 쪽이면 됩니다. hwp-mcp는 TypeScript로 만들었고, 포맷 처리는 WebAssembly로 컴파일된 Rust 엔진에 위임했습니다.

Q. 사내 전용 서버도 공개해야 하나요?

아닙니다. MCP 서버는 로컬 프로세스로 뜨므로 배포 없이 내부에서만 쓸 수 있습니다. 사내 인증이 걸린 대상이라면 공개하지 않는 편이 맞습니다.

Q. 응답을 줄이면 모델이 필요한 정보를 놓치지 않나요?

줄이는 대상은 장식·중복 정보이고, 참조값과 상태 변화는 남겨야 합니다. 요약 후에도 다음 액션을 정확히 지목할 수 있는지가 판단 기준입니다.

Q. 기존 MCP 서버가 마음에 안 들면 포크해야 하나요?

포크는 유지보수 부담이 따라옵니다. 출력만 문제라면 뒤에 계층을 두는 편이 낫고, 도구 구성 자체가 안 맞을 때만 별도 서버를 고려하세요.

Q. 한글 문서 MCP는 hwp-mcp만 있나요?

아닙니다. 다른 구현도 공개돼 있고 접근 방식이 다릅니다. hwp-mcp는 WebAssembly 엔진 기반이라 한컴오피스 설치 없이 macOS에서도 동작한다는 점이 선택 기준이 될 수 있습니다.

Q. MCP와 A2A 중 무엇을 먼저 봐야 하나요?

도구 연동이 목적이면 MCP입니다. A2A는 에이전트끼리 협업시키는 단계에서 필요합니다. 차이는 MCP와 A2A 프로토콜 정리에 정리했습니다.

마무리

MCP와 A2A는 AI 에이전트 생태계가 파편화된 도구들의 모음에서 유기적으로 연결된 시스템으로 진화하는 데 핵심적인 역할을 하고 있습니다. 두 프로토콜 모두 Linux Foundation에 기증되면서 오픈 표준으로서의 지위도 확보했죠.

기업 AI 전환을 준비하고 있다면, 개별 AI 도구 선택보다 에이전트들이 어떻게 소통할 것인지를 먼저 설계하는 것이 장기적으로 훨씬 효과적입니다.

그리고 막상 만드는 단계에 들어가면 판단은 훨씬 단순해집니다. 공개된 서버가 있으면 쓰고, 출력만 문제면 뒤에 계층을 두고, 정말 없는 능력일 때만 직접 만듭니다. 만들기로 했다면 응답 크기를 줄이되 참조값은 남기고, 도구 이름에 동작과 대상을 드러내고, 실제 시나리오 단위로 묶는 것 — 이 세 가지가 토큰 비용을 가릅니다.

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 위 사례들도 고객사 프로젝트나 사내 업무에서 필요해 만들어 쓰다가 공개한 것입니다. 진행 방식은 AI-Native 개발 방식에서 확인하실 수 있습니다.

---

참고 자료

• MCP vs A2A 완벽 가이드
• AI Agent Protocol Ecosystem Map 2026

관련 서비스가 필요하시면 나무숲(TreeSoop)의 AI 에이전트 개발 서비스을 확인해보세요.

---

*글쓴이: 남대현 | TreeSoop CEO, POSTECH 컴퓨터공학 AI/MR/HCI 석사*

AI 전환 전략부터 프로덕션 배포까지 50+ 프로젝트를 리드했습니다.

AI 관련 프로젝트가 필요하시면 카카오톡으로 문의하세요.