MCP가 죽지 않았음을 증명하는 11개 MCP 서버

공개 고지: 저는 이 목록에서 5위에 있는 PDFHaul의 창립자입니다. 원문은 PDFHaul 블로그에 게재되었으며, 전체 소스 목록과 링크가 있습니다.

AI 비서가 PDF를 압축하는 방법을 설명해 줄 수 있다는 것은 한 번 유용합니다.

파일을 찾고, 이를 압축하고, 결과를 반환하며, 프로젝트 페이지를 업데이트하고, 발표용 이미지를 만드는 것을 돕는 AI 비서는 매일 유용합니다.

이러한 차이가 바로 "MCP는 죽었다"라는 주장이 중요한 무언가를 놓치게 만드는 이유입니다.

비판은 현실적입니다. 개발자들은 설계가 미흡한 MCP 서버들을 연결하고, 에이전트의 컨텍스트(context)를 도구 설명으로 채우며, 인증 문제와 씨름했고, 왜 단순히 API를 호출하거나 명령줄 도구(CLI tool)를 사용하지 않는지 의문을 가졌습니다. Eric Holmes는 "MCP는 죽었다. CLI 만세"라는 글에서 더 나아가 주장합니다. 그는 MCP가 실제 세계적인 이점을 제공하지 않으며, 대부분의 작업은 좋은 API와 CLI를 사용할 때 더 간단하고, 디버깅하기 쉬우며, 신뢰할 수 있을 것이라고 주장합니다. 그는 조합성(composability), 확립된 인증 방식, 적은 구성 요소, 그리고 인간과 에이전트가 동일한 명령을 사용할 수 있다는 점을 근거로 제시합니다. 또한 CLI가 존재하지 않을 때 MCP가 유용할 수 있으며, 일부 사례에서는 표준 인터페이스를 선호할 수도 있음을 인정합니다.

이는 심각한 주장입니다. 만약 MCP가 단순히 추가적인 설정과 함께 CLI를 포장하는 것에 불과하다면, 그 비용을 정당화해야 합니다. 하지만 이 프로토콜이 실질적인 이점을 제공하지 않는다는 더 넓은 주장은, 단지 로컬 코딩 에이전트가 터미널에서 할 수 있는 것뿐만 아니라 여러 서비스에 걸쳐 AI 클라이언트용으로 구축된 연결로 팀들이 무엇을 할 수 있는지까지 고려해야 합니다.

모델 컨텍스트 프로토콜(Model Context Protocol), 즉 MCP는 AI 애플리케이션이 다른 시스템이 제공하는 기능을 발견하고 사용하는 공통적인 방법을 제공합니다. 이것이 모든 통합을 좋게 만드는 것은 아닙니다. 하지만 모든 비서와 모든 서비스에 대해 별도의 연결을 재구축할 필요 없이 특정 종류의 워크플로우를 가능하게 합니다.

사람들이 이미 이 기술로 무엇을 하고 있는지 살펴보십시오.

1. Azure가 클라우드 리소스를 에이전트가 사용할 수 있는 도구로 변환하는 방법

개발자가 실패하는 애플리케이션을 조사한다고 상상해 보세요. 그들은 리소스를 확인하고, 원격 측정(telemetry)을 검사하며, 관련 서비스 문서를 찾아야 합니다. 연결된 도구 없이는 어시스턴트가 명령어를 제안할 수 있지만, 개발자는 채팅, 터미널, 포털, 문서 사이를 계속 이동해야 합니다.

Azure MCP Server는 Azure 작업을 호환되는 AI 클라이언트에 노출합니다. Microsoft는 스토리지 계정 목록화 및 KQL 쿼리 실행과 같은 예시 문서를 제공합니다. 지원되는 Visual Studio 워크플로우에서 이 도구는 리소스 탐색, 진단 실행, 배포 작업에 도움을 줄 수도 있습니다. 접근은 여전히 Azure 자격 증명 및 권한에 연결되어 있습니다.

이것이 에이전트가 검토되지 않은 프로덕션 변경을 해야 한다는 의미는 아닙니다. 이것은 에이전트가 개발자가 통제권을 유지하는 동안 동일한 관련 클라우드 컨텍스트로 작업할 수 있다는 것을 의미합니다.

CLI(Command Line Interface) 역시 여기서 가치가 있습니다. 실제로 Microsoft의 Azure 도구링은 MCP와 함께 CLI를 사용합니다. 실질적인 선택은 어떤 인터페이스가 특정 에이전트와 사용자에게 작업을 신뢰성 있게 완료하도록 돕는지입니다.

2. Microsoft Learn을 통해 어시스턴트는 문서로 돌아갈 경로를 얻는다

어시스턴트는 자신이 잘못 기억하는 Microsoft 기능에 대해 자신감 있는 목소리를 낼 수 있습니다. 이는 제품 문서가 변경될 때 특히 좌절감을 줄 수 있습니다.

Microsoft Learn MCP Server는 호환되는 클라이언트가 Microsoft의 공식 기술 문서를 검색하고, 기사를 가져오고, 코드 샘플을 검색할 수 있게 합니다. 이것은 공개적으로 사용 가능한 원격 서버입니다.

이것은 MCP 가치의 조용한 예시입니다. 극적인 자율 에이전트가 필요하지 않습니다. 개발자가 질문하면, 어시스턴트는 관련 문서를 확인하고, 답변은 개발자가 검사할 수 있는 출처에 근거할 수 있습니다.

이 기능은 소박합니다. 그것이 바로 중요한 이유입니다. 최신 정보에 대한 더 나은 접근성은 종종 또 다른 인상적인 데모보다 더 유용하기 때문입니다.

3. Notion은 어시스턴트를 사람들이 이미 정리한 작업과 연결한다

팀의 프로젝트 지식은 한 번의 프롬프트에 존재하지 않습니다. 그것은 브리프(briefs), 의사결정 기록(decision logs), 작업 목록(tasks), 메모, 그리고 데이터베이스 전반에 걸쳐 존재합니다. 그러한 자료에 접근할 수 없는 어시스턴트는 팀이 결정한 내용을 무시하는 세련된 답변을 생성할 수 있습니다.

Notion MCP는 승인된 MCP 클라이언트가 접근 가능한 Notion 콘텐츠를 검색하고, 읽고, 생성하며, 업데이트할 수 있도록 하는 호스팅 서버입니다. Notion은 클라이언트가 페이지를 검색하고, 그 결과로부터 페이지를 생성하며, 속성을 업데이트하는 워크플로우를 설명합니다. 이 연결은 OAuth를 사용하며 작업 공간(workspace) 접근 제어의 적용을 받습니다.

프로젝트 인수인계를 생각해 봅시다. 사용자가 다섯 개의 페이지를 채팅에 복사하는 대신, 승인된 어시스턴트에게 현재 브리프와 결정을 찾아내고, 인수인계 페이지를 초안 작성하여 올바른 작업 공간에 배치하도록 요청할 수 있습니다. 여기서 가치는 어시스턴트의 추론을 팀의 실제 정보 및 행동과 연결하는 데서 나옵니다.

개발자가 Notion API를 직접 사용하여 코드를 작성할 수 있을까요? 물론입니다. Notion 자체 MCP 서버는 자신의 API를 사용합니다. MCP의 가치는 그러한 기능을 표준 인터페이스를 통해 호환 가능한 클라이언트에게 제공하고, 사용자가 승인할 수 있는 연결을 갖추게 하는 데 있습니다.

4. Higgsfield가 보여주듯, MCP는 검색뿐 아니라 창조에 관한 것이다

많은 논의들이 MCP를 어시스턴트가 정보를 찾아보는 방식이라고 취급합니다. 크리에이티브 도구들은 이야기의 다른 절반을 보여줍니다. 즉, 어시스턴트는 출력을 생성하는 데도 도움을 줄 수 있다는 것입니다.

Higgsfield의 MCP 제공 서비스는 지원되는 AI 클라이언트를 이미지 및 비디오 생성 워크플로우에 연결합니다. 그 예시로는 광고를 다양한 종횡비(aspect ratios)로 조정하거나, 크리에이티브 프롬프트를 생성된 시각 자료로 변환하는 것이 있습니다.

흥미로운 부분은 생성 주변의 워크플로우입니다. 사람이 목표를 설명하고, 대화 속에서 방향을 다듬고, 크리에이티브 기능을 호출하며, 돌아온 것을 검사하고, 반복할 수 있습니다. 어시스턴트는 더 이상 사람이 다른 곳에 붙여넣어야 하는 프롬프트를 작성하는 것으로 제한되지 않습니다.

그것이 모든 이미지가 좋거나 모든 생성이 즉각적이라는 것을 보장하지는 않습니다. 이는 무엇을 만들지 결정하는 것과 그것을 만들 수 있는 도구를 호출하는 것 사이에 개입(handoff) 과정을 제거합니다.

5. PDFHaul은 문서 작업을 대화 내에서 사용 가능하게 만듭니다

PDF 파일은 자체적인 개입 과정을 생성합니다. 사람들은 파일을 가지고 있고 결과를 원합니다. 문서를 병합하거나, 특정 페이지를 분리하거나, 스캔본에 대해 OCR(광학 문자 인식)을 수행하거나, 표를 추출하거나, 보고서를 Word로 변환하는 식입니다. 일반 어시스턴트는 이러한 작업을 어떻게 수행할 수 있는지 설명해 줄 수 있습니다. 이를 실행하려면 문서 작업 기능에 접근해야 합니다.

PDFHaul MCP 서버는 병합(merge), 분리(split), 압축(compression), OCR, 변환(conversion), 표 추출(table extraction), 정확 일치 중복 페이지 제거 등 23개의 PDF 도구를 호환 가능한 클라이언트에 노출합니다. 또한 파일 목록 보기 및 임시 다운로드 URL 검색과 같은 파일 작업도 노출합니다. 사용자는 PDFHaul API 키를 사용하여 이를 연결합니다.

예를 들어, 사용자는 어시스턴트에게 PDF에서 표를 스프레드시트로 추출하거나, 내용을 다루기 전에 스캔된 PDF를 검색 가능하게 만들도록 요청할 수 있습니다. 어시스턴트는 일련의 지침에 멈추는 대신 관련 PDFHaul 작업을 호출할 수 있습니다.

저희가 이것을 구축한 이유는 문서 작업이 종종 더 큰 업무 흐름의 한 단계이기 때문입니다. 사람들은

개발자가 버그가 계속 발생하는 이유를 묻는 상황을 상상해 보세요. 적절한 접근 권한이 있다면, 어시스턴트는 이슈 기록과 관련 풀 리퀘스트(pull requests)를 검토하여 수정 사항을 제안할 수 있습니다. 또한 발견된 내용을 바탕으로 후속 이슈를 열도록 도움을 줄 수도 있습니다. 이는 단순히 붙여넣은 오류 메시지 하나만 보고 자신 있게 패치(patch)를 생성하는 것보다 훨씬 유용합니다. 개발자는 여전히 증거를 검사하고, 코드를 검토하며, 무엇을 병합할지 결정해야 합니다.

이 예시는 커맨드 라인도 같은 일을 할 수 있다는 익숙한 주장을 테스트하기도 합니다. GitHub CLI는 터미널에서 개발자에게 매우 유용합니다. MCP 연결은 정의된 GitHub 기능을 구성 가능한 툴셋(toolsets)을 가진 호환 가능한 어시스턴트에게 가져다줄 수 있습니다. 최적의 인터페이스는 에이전트, 사용자, 그리고 사용 가능한 권한에 따라 달라집니다. 중요한 점은 MCP가 프로젝트 컨텍스트와 프로젝트 액션(actions)을 공통 계약(common contract)을 통해 접근 가능하게 만든다는 것입니다.

7. Figma는 스크린샷이 놓치는 디자인 세부 정보를 어시스턴트에게 제공합니다

스크린샷은 코딩 어시스턴트에게 화면이 어떻게 보이는지 알려줍니다. 하지만 컴포넌트, 변수, 레이아웃, 그리고 그것을 생성한 디자인 시스템에 대한 전체 이야기를 거의 전달하지 못합니다. 이러한 세부 정보가 없으면, 생성된 코드는 실제 디자인에서 벗어나면서도 유사하게 보일 수 있습니다. 그러면 사람이 간격(spacing), 명명 규칙(naming), 반응형 동작(responsive behavior), 컴포넌트 선택 등을 다시 설명해야 합니다.

Figma의 MCP 서버는 지원되는 개발 클라이언트에게 구조화된 디자인 컨텍스트를 노출합니다. 이 문서에는 컴포넌트, 변수, 레이아웃 정보와, 지원되는 설정에서는 Code Connect 매핑과 같은 디자인 요소에 대한 접근 방법이 설명되어 있습니다. 그 목적은 에이전트가 디자인 팀이 실제로 사용했던 컨텍스트로 디자인을 구현하도록 돕는 것입니다. 하나의 툴 호출(tool call)만으로 모든 목업(mockup)을 프로덕션 코드(production code)로 바꿀 것이라는 약속은 아닙니다.

제품 팀은 선택된 프레임을 코딩 에이전트에게 전달하고, 기존 컴포넌트를 사용하여 화면을 구축하도록 요청할 수 있습니다. 이 에이전트는 작업하는 동안 디자인 컨텍스트를 검사할 수 있으며, 개발자는 결과를 디자인과 비교하고 동작을 테스트할 수 있습니다. 이는 시각적 결정과 구현 결정 사이의 간극을 줄여줍니다. 이러한 통합은 디자인 파일이 평면적인 이미지보다 더 많은 구조를 가지고 있기 때문에 특히 유용합니다.

8. Atlassian은 이슈와 결정을 동일한 태스크로 가져옵니다

제품 변경 사항은 종종 Jira에서 시작하여 Confluence에서 설명되고, 리포지토리에서 끝납니다. 코드를 작업하는 어시스턴트는 마지막 지침만 볼 수 있어 승인 기준이나 프로젝트 페이지에 묻힌 결정을 놓칠 수 있습니다. 이로 인해 기술적으로 건전한 변경 사항이 잘못된 문제를 해결할 수 있습니다.

Atlassian의 Rovo MCP Server는 호환되는 AI 도구를 위한 클라우드 기반 연결입니다. Atlassian은 Jira 및 Confluence 컨텍스트에 대한 액세스를 문서화하며, 현재 가이드는 지원되는 구성에서 다른 Atlassian 데이터도 다룹니다. 그 제어에는 조직의 액세스 정책이 포함됩니다. 팀은 호환되는 어시스턴트에게 연결된 사용자가 볼 수 있는 범위에 따라 작업 항목 및 지원 문서를 조회할 수 있는 능력을 부여할 수 있습니다.

“보고서 내보내기(export the report)”와 같은 모호한 구문으로 된 기능 요청을 고려해 봅시다. 이슈는 필드를 지정할 수 있고, Confluence의 결정은 특정 형식이 선택된 이유를 기록합니다. 이러한 출처를 구현 전에 읽으면 답변의 품질이 달라집니다. 그 후, 권한 있는 에이전트가 수행한 내용을 작업 항목에 업데이트할 수 있습니다. 유용성은 Jira가 API를 가지고 있다는 것이 아닙니다. 어시스턴트가 필요할 때 원래 컨텍스트에서 작업을 접할 수 있다는 것입니다.

9. Google Maps는 대화를 실제 장소와 경로에 기반합니다

모든 유용한 도구 호출이 소프트웨어 개발에 관한 것은 아닙니다. 주변 장소를 묻는 일반 비서에게 요청하면 오래된 지식에 의존하거나 추적 가능한 장소 없이 답변을 생성할 수 있습니다. 이 문제는 특히 경로(route)의 경우 더욱 명확한데, 거리와 소요 시간은 실제 출발지와 목적지에 따라 달라지기 때문입니다.

Google Maps Platform의 Maps Grounding Lite는 장소 검색, 날씨 조회 및 경로 정보에 대한 도구를 갖춘 MCP 서버를 제공합니다. 이 서버는 결과와 함께 장소 식별자(place identifiers), 좌표(coordinates), 그리고 Google 지도 링크를 반환할 수 있습니다. 이는 비서가 해당 영역을 위해 구축된 서비스를 통해 실제 세계의 맥락(real-world context)을 검색하는 구체적인 예시입니다. 하지만 모든 추천이 정확한 것은 아니며, 사용자는 여전히 반환된 장소와 경로 세부 정보를 검토해야 합니다.