- MCP는 AI 모델이 브라우저, GNOME 데스크톱 앱 및 외부 서비스와 상호 작용하기 위한 통합 표준 역할을 합니다.
- MCP 서버는 클라우드플레어, 깃허브, 피그마, 도커, 스트라이프 등과 같은 서비스를 위한 프로덕션 환경용 서버와 퍼펫티어, AT-SPI2와 같은 리눅스 전용 서버 등 다양한 형태로 준비되어 있습니다.
- GNOME 환경에서 자체 MCP 서버를 개발하고 배포하려면 모듈식 아키텍처, 우수한 보안 관행 및 철저한 테스트가 필요합니다.
- Claude Desktop이나 KoboldCpp와 같은 클라이언트는 동일한 MCP 서버 환경을 공유할 수 있어 Linux 워크플로에 유연성을 제공합니다.
고급 AI 비서와 Linux 데스크톱 환경을 사용해 본 경험이 있다면, 모델 컨텍스트 프로토콜(MCP) 과 GNOME과의 통합을 이미 접해 보셨을 가능성이 높습니다 . 점점 더 많은 도구, 서버 및 플랫폼이 MCP를 채택하여 모델이 애플리케이션, 브라우저, API 및 데스크톱 시스템과 표준화되고 안전한 방식으로 통신할 수 있도록 하고 있습니다.
이 글에서는 Linux GNOME 환경에서 MCP 서버 지원이 어떻게 작동하는지 자세히 살펴보겠습니다 . Puppeteer를 사용한 브라우저 자동화, AT-SPI2를 통한 네이티브 애플리케이션과의 상호 작용, Cloudflare, GitHub, Figma, Docker, Stripe와 같은 플랫폼과의 통합까지 다룹니다. 또한 MCP 서버를 직접 설정하고, 테스트하고, 배포하는 방법과 Windows, ChatGPT, Claude 등의 도구가 이 새로운 생태계에서 어떤 역할을 하는지도 살펴보겠습니다.
MCP란 무엇이며 GNOME 데스크톱에서 왜 그렇게 중요한가요?
모델 컨텍스트 프로토콜( MCP)은 모델 언어와 도구를 통합하는 데 있어 일종의 "USB-C" 와 같은 역할을 하게 되었습니다 . 각 애플리케이션(CRM, 데이터베이스, 배포 대시보드 등)마다 별도의 커넥터를 만드는 대신, MCP는 LLM(로컬 라이프사이클)이 일관된 방식으로 도구와 리소스를 제공하는 서버와 통신할 수 있도록 하는 개방형 표준을 정의합니다.
실제로 MCP 서버는 잘 정의된 스키마(일반적으로 JSON 및 JSON 스키마 사용)에 따라 도구(액션)와 리소스(접근 가능한 데이터)를 제공하는 서비스입니다 . AI 모델은 이러한 도구를 검색하고, 어떤 매개변수를 허용하는지 쿼리하고, 개발자가 각 경우에 대해 새로운 프로토콜을 만들 필요 없이 안전하게 호출할 수 있습니다.
GNOME 및 기타 Linux 데스크톱 환경에서 MCP는 모델이 X11, Wayland, AT-SPI2 접근성, Puppeteer로 제어되는 브라우저, GTK/Qt/Electron 애플리케이션 등과 같은 그래픽 생태계를 이해하는 특수 서버 에 연결할 수 있도록 해주기 때문에 매우 적합합니다 . 이 모든 것을 사용자가 환경을 변경하거나 임시방편적인 통합에 의존할 필요 없이 이용할 수 있습니다.
아키텍처 관점에서 MCP는 클라이언트(AI 비서 또는 이를 사용하는 앱)와 서버(실제 세계와 상호 작용하는 구성 요소)를 명확하게 분리합니다. 이러한 분리를 통해 동일한 MCP 서버와 도구 계약을 유지하는 한, 모든 통합 작업을 다시 수행할 필요 없이 모델, IDE 또는 클라우드 공급자를 변경할 수 있습니다 .
Windows 환경에서의 MCP 지원, 웹사이트 및 데스크톱 사용 관련 질문
MCP를 사용해 보려는 사람들이 요즘 가장 많이 묻는 질문 중 하나는 Windows, 특히 Node.js 기반 서버에서 MCP를 얼마나 쉽게 작동시킬 수 있는지 에 대한 것입니다 . 많은 사용자가 수동 설치, Node 경로 설정, PowerShell 보안 구성 또는 AI 클라이언트 구성 파일 문제로 어려움을 겪었습니다.
이 골칫거리를 해결하기 위해 누군가 클로드에게 무언가를 생성해달라고 부탁하기로 했습니다. MCP 서버의 설치 및 업데이트를 관리할 수 있는 PowerShell 스크립트그 결과물은 (공개 gist에 호스팅된) 스크립트이며, 이를 다운로드할 수 있습니다. mcp-install.ps1아이디어는 아주 간단합니다. 패키지가 나타나면 mcp-get.com Node.js 아이콘으로 식별되는 이 스크립트는 Node.js를 다운로드하고 설치하여 사용할 수 있도록 준비합니다.
Windows에서 일반적인 작업 흐름은 PowerShell을 열고 다음과 같은 명령을 실행하는 것입니다. ./mcp-install.ps1 @modelcontextprotocol/server-everything이 명령은 샘플 서버를 배포하여 전체 MCP 파이프라인이 클라이언트(예: Claude Desktop)에서 올바르게 작동하는지 확인합니다. 제공되는 스크린샷은 예상되는 진행 상황을 보여주며 모든 설정이 올바르게 구성되었는지 확인하는 데 도움이 됩니다.
흥미로운 점은 대본이 기존 파일을 덮어쓰지 않습니다. claude_desktop_config.json대신 MCP 패키지 진입점을 확인하고 구성을 점진적으로 업데이트하십시오. MCP 서버가 이미 설치되어 있는 경우 이전 설정을 유지하면서 업데이트하기만 하면 됩니다. 이렇게 하면 사용자 지정 구성이나 다른 서버로의 경로가 손실될 위험을 줄일 수 있습니다.
PowerShell 구버전이 설치된 Windows 시스템에서는 먼저 PowerShell을 실행해야 할 수도 있습니다. Set-ExecutionPolicy Bypass -Scope Process 스크립트 실행을 허용합니다. 이는 PowerShell이 보안상의 이유로 인터넷에서 다운로드한 .ps1 파일의 실행을 차단할 때 흔히 사용되는 해결 방법입니다.
이와 동시에 점점 더 자주 제기되는 또 다른 질문은 바로 이것입니다. Claude나 ChatGPT의 웹 버전이 MCP를 완벽하게 지원하게 될까요? 아키텍처 관점에서 보면 이를 막는 것은 아무것도 없습니다. MCP 서버는 이미 존재하고, 일반적으로 HTTP 또는 STDIO를 사용하며, 프로토콜 자체도 잘 문서화되어 있습니다. 제공업체들이 웹 버전 구현을 주저하는 이유는 대개 보안, 권한, 리소스 제한, 사용자 경험(UX), 그리고 거버넌스 문제 때문입니다. 웹에서 MCP를 노출한다는 것은 클라우드 기반 모델이 웹 브라우저를 통해 외부의 잠재적으로 민감한 시스템과 통신할 수 있도록 허용하는 것을 의미합니다.
많은 사람들이 웹을 통해 ChatGPT나 Claude를 실행하고, GitHub, Figma, Jira, Docker 등 자신이 사용하는 모든 MCP 도구를 연결 하여 터미널을 열지 않고도 복잡한 명령어를 실행할 수 있는 미래를 꿈꿉니다. 이러한 비전은 기술적으로 실현 가능하며, 실제로 이미 몇 가지 단계가 진행되고 있지만, 정교한 권한 정책, 잘 구현된 OAuth 시스템, 그리고 AI가 현재 어떤 작업을 수행할 수 있는지 명확하게 설명하는 사용자 경험이 필요합니다.
리눅스 생태계에서 가장 강력한 MCP 서버 중 하나는 Puppeteer입니다. Puppeteer는 X11과 Wayland를 기본적으로 지원하는 실제 웹 브라우저를 자동화합니다 . 이 서버를 통해 언어 모델은 마치 사람처럼 웹 페이지와 상호 작용할 수 있습니다. 즉, URL을 열고, 요소를 클릭하고, 양식을 작성하고, JavaScript를 실행하고, 스크린샷을 캡처하고, 콘솔 로그를 읽을 수 있습니다.
이 구현에는 Linux(X11, Wayland 또는 XWayland)에서 디스플레이 서버를 관리하기 위한 특정 계층이 포함되어 있습니다 . 문서에 설명된 포크 버전은 그래픽 환경을 자동으로 감지하고 GNOME, KDE 및 기타 데스크톱 환경에서 브라우저를 원활하게 실행하는 데 필요한 변수를 Puppeteer가 동적으로 구성하는 기능을 추가합니다.
이 브라우저 기반 MCP 서버의 주요 기능은 다음과 같습니다. X11/Wayland 자동 감지변수의 동적 구성은 다음과 같습니다. DISPLAY y XAUTHORITYXWayland 호환성 메커니즘 지원 및 특수한 환경에서 서버가 충돌하는 것을 방지하기 위한 강력한 오류 처리 기능을 갖춘 일련의 대체 루틴이 포함되어 있습니다.
리소스 측면에서 이 서버는 두 가지 매우 유용한 유형의 URI를 제공합니다. 한편으로는, 콘솔 로그는 다음을 통해 접근할 수 있습니다. console://logs반면에 참조된 스크린샷은 다음과 같습니다. screenshot://<name>이를 통해 모델은 엔드투엔드 흐름을 자동화하거나 복잡한 웹 애플리케이션을 검사할 때 유용한 시각적 및 디버깅 컨텍스트를 얻을 수 있습니다.
제공되는 기능은 페이지 탐색, 클릭, 폼 제출, 사용자 지정 스크립트 실행 , 콘솔 읽기 및 스크린샷 관리와 같은 대부분의 일반적인 QA 및 스크래핑 작업을 지원합니다. GNOME 환경에서 작업하는 경우, 이 MCP 레이어는 디스플레이 서버의 복잡한 부분을 완전히 추상화하여 모델이 고급 언어로 통신할 수 있도록 합니다.
AT-SPI2를 통한 Linux 데스크톱 애플리케이션용 MCP 지원
브라우저 외에도 네이티브 Linux 데스크톱 애플리케이션과의 접근성 상호 작용을 처리하는 매우 흥미로운 MCP 서버가 하나 더 있습니다 . 이 서버는 GNOME 및 기타 최신 데스크톱 환경의 접근성 표준인 AT-SPI2(보조 기술 서비스 제공자 인터페이스)를 사용하여 인터페이스의 일종의 "의미 트리"를 제공합니다.
이 서버는 일부 크롬 확장 프로그램이 참조 기능을 제공할 때 제공하는 것과 유사한 기능을 제공합니다. ref_1, ref_2하지만 적용되었습니다 GTK 윈도우, Qt, Electron 및 정보를 공개하는 모든 앱에 접근할 수 있습니다.이 도구는 역할(버튼, 텍스트, 링크, 메뉴 등), 상태(포커스됨, 활성화됨, 표시됨, 편집 가능함)를 감지하고 인터페이스 요소에 대한 자연어 검색을 제공할 수 있습니다.
이 제품의 가장 뛰어난 기능 중 하나는 다음과 같은 기능입니다. desktop_snapshot접근성 트리를 캡처합니다. 의미론적 참조를 포함하여, desktop_find "저장 버튼" 또는 "검색 필드"와 같은 설명을 기반으로 항목을 찾으려면, desktop_click 참조 또는 좌표를 사용하여 클릭하려면, desktop_type 텍스트를 작성하다 desktop_key 키보드 단축키를 보내려면 desktop_capabilities 각 환경에서 어떤 유형의 자동화 기능을 사용할 수 있는지 확인합니다.
GNOME에서 이 모든 기능이 제대로 작동하려면 데스크톱 접근성을 활성화 해야 합니다 . 일반적으로 설정 → 접근성에서 활성화할 수 있습니다. KDE에도 시스템 패널에 유사한 옵션이 있습니다. 대부분의 최신 데스크톱 환경은 기본적으로 접근성을 활성화하지만, 경우에 따라 AT-SPI2 데몬이 제대로 시작되도록 세션을 다시 시작해야 할 수도 있습니다.
그래픽 플랫폼 호환성과 관련하여 이 MCP 서버는 다음을 지원합니다. X11, 웨일랜드 및 XWayland기능표를 보면 AT-SPI 감지, 참조 기반 클릭, 텍스트 쓰기, 그리고 다음과 같은 도구 사용 등이 포함되어 있음을 알 수 있습니다. ydotool 세 가지 환경 모두에서 완벽하게 지원됩니다. xdotool X11 및 XWayland 환경에서는 최대 성능으로 작동하지만, 순수 Wayland 세션에서는 사용되지 않습니다.
문제 해결 섹션에서는 "AT-SPI2를 사용할 수 없습니다" 또는 "AT-SPI2 레지스트리가 실행되지 않습니다 "와 같은 일반적인 오류를 언급하는데, 이는 대개 접근성이 활성화되지 않았거나 서비스가 제대로 시작되지 않았기 때문입니다. 또한 Wayland에서 발생하는 "입력 백엔드를 사용할 수 없습니다" 메시지에 대해서도 설명하는데, 이는 일반적으로 적절한 입력 시뮬레이션 도구를 설치하고 구성하여 해결할 수 있습니다. 더불어, 일부 오래된 애플리케이션이나 통합이 제대로 되지 않은 애플리케이션은 접근성 트리를 노출하지 않을 수 있으므로 일부 요소가 스냅샷에 나타나지 않을 수 있다는 점도 언급합니다.
MCP는 프런트엔드 팀을 위한 통합 표준입니다.
데스크톱 환경을 넘어, MCP는 디자인(Figma), 버전 관리(GitHub, GitLab), 배포(Vercel, Netlify, Cloudflare), 관찰 가능성(Sentry, Chromatic), 작업 관리(Linear, Jira, Notion, Atlassian 등)와 같은 핵심 프런트엔드 워크플로우 도구를 통합하는 데 있어 가장 적합한 플랫폼으로 자리매김하고 있습니다.
MCP는 설계 사양, 저장소, 배포 파이프라인, 모니터링 및 작업 관리를 AI 비서, 코드 편집기 및 CI/CD 시스템 모두가 이해할 수 있는 단일 채널로 연결할 수 있도록 해주기 때문에 종종 "에이전트 및 도구 통합을 위한 USB-C "와 같다고 설명됩니다. 각 도구 쌍에 대한 사용자 지정 어댑터 레이어가 필요하지 않습니다.
이미 OAuth 및 세분화된 권한 설정을 지원하는 다양한 원격 MCP 서버 목록이 상당히 포괄적으로 마련되어 있습니다 . 예를 들어, Cloudflare는 Workers, Pages, KeyV 또는 R2와 통합되는 관리형 MCP 서버 카탈로그를 제공하고 있으며, Notion은 문서, 작업 및 사양을 읽고 쓸 수 있는 서버(공식 또는 커뮤니티 소유)를 제공합니다. 또한 GitHub와 GitLab은 이슈 관리, 풀/병합 요청, 코드 검토 워크플로 자동화를 위한 자체 MCP 서버를 운영하고 있습니다.
다른 플랫폼으로는 배포, 환경, 도메인 및 프로젝트를 제어하는 MCP 템플릿과 서버 , 그리고 프런트엔드 애플리케이션용으로 설계된 데이터베이스 및 기타 플랫폼 기능에 대한 읽기 전용 액세스를 제공하는 Supabase가 있습니다. 작업 관리 영역에서는 Linear와 Atlassian(Jira/Confluence)이 사용자가 각 사용자의 권한을 알고 있는 상태에서 이슈를 생성하고, 상태를 업데이트하고, 스프린트를 보고, 페이지를 요약할 수 있는 원격 MCP를 제공합니다.
관찰 가능성 영역에서 Sentry는 오류 검사, 문제에 대한 실시간 컨텍스트 제공, 심지어 패치 제안 생성까지 가능한 MCP 서버(호스팅 버전 및 오픈 소스 버전 제공)를 제공합니다. Stripe는 결제 API 및 문서와의 상호 작용을 지원하고, Chromatic/Storybook은 시각적 테스트 및 인터페이스 검토 도구를 제공하며, Grep MCP와 같은 프로젝트는 정규 표현식과 시맨틱을 결합하여 공개 GitHub 저장소에서 대규모 코드 검색을 가능하게 합니다.
이 모든 점을 고려할 때, MCP는 2025년 이후 현대 프런트엔드 팀에게 매우 실용적인 선택지가 될 것입니다 . 마치 전기 테이프로 덕지덕지 붙인 듯한 스크립트를 관리하는 대신, 적절한 MCP 서버(Figma, GitHub/GitLab, Vercel/Netlify/Cloudflare, Sentry/Chromatic 등)를 선택하고 AI 어시스턴트가 에디터나 CI 시스템 내에서 디자인 → 코딩 → 배포 → 모니터링 흐름을 조율하도록 맡기면 됩니다.
실용 가이드: MCP 서버의 구조 및 개발 방법
GNOME에서 MCP 지원을 한 단계 더 발전시키려면 결국에는 자체 MCP 서버를 구축 해야 할 것입니다. 미리 만들어진 서버를 사용하는 것과는 달리, 처음부터 서버를 구축하면 백엔드 아키텍처, 도구 관리, 프로토콜의 메시지 모델을 이해하게 되어 AI가 시스템과 상호 작용하는 방식을 완벽하게 제어할 수 있게 됩니다.
MCP 서버의 일반적인 아키텍처는 모듈식이며, 보통 메인 서버 애플리케이션 , 도구 및 리소스 모듈, 통신 처리기, 통합 지점의 네 가지 블록으로 나뉩니다. 애플리케이션은 HTTP/STDIO 소켓 또는 엔드포인트를 열고, 동시 연결을 관리하고, 클라이언트를 인증하고, 데이터 흐름을 조정하는 역할을 담당합니다.
툴 모듈은 데이터베이스 쿼리, 계산 수행, 배포 트리거, 자동화 플레이북 실행 등과 같은 특정 작업을 캡슐화하는 코드 조각입니다. 각 툴은 고유한 이름, 명확한 설명, 매개변수 체계 및 응답 체계를 가지며, 유효성 검사를 위해 JSON 스키마 로 정의되는 경우가 많습니다 . 서버는 이러한 툴에 대한 기록을 유지하고, MCP 메시지가 도착하면 해당 요청을 적절한 기능으로 전달합니다.
통신 처리기는 MCP 형식으로 수신되는 메시지를 구문 분석하고, 스키마를 준수하는지 확인한 후, 각 요청을 적절한 도구 또는 리소스로 라우팅합니다. 또한 클라이언트가 예상하는 필드(결과, 오류, 메타데이터 등)를 채워 응답을 구성합니다 . 마지막으로, 통합 지점은 어시스턴트와 앱이 연결할 수 있도록 하는 외부 인터페이스입니다. 여기에는 HTTP 엔드포인트, WebSocket, STDIO 전송 방식 등 구현에서 정의하는 다양한 방식이 포함됩니다.
상호 작용 흐름은 간단합니다. 클라이언트가 서버에 MCP 요청을 보내면 핸들러가 이를 해석하고, 서버는 지정된 도구를 실행한 다음, 핸들러가 응답을 패키징하여 반환합니다. 이러한 계층형 설계 덕분에 애플리케이션의 핵심 로직을 건드리지 않고도 전송 계층을 교체하거나 새로운 도구를 추가할 수 있습니다.
실제로 MCP 서버를 개발하려면 일반적으로 다음 단계를 시작합니다. 네트워크 지원이 뛰어난 프로그래밍 언어 Python이나 Node.js 같은 언어를 사용할 수 있습니다. Python에서는 Flask나 FastAPI 같은 프레임워크가 흔히 사용되고, Node.js에서는 Express가 아주 적합합니다. 프로젝트는 도구별로 폴더를 만들어 구조화하는 것이 좋습니다./tools), 핸들러(/handlers) 및 메인 파일(server.py o server.js), 종속 파일 외에도 (requirements.txt o package.json).
환경적인 측면에서 가장 건강한 방법은 함께 일하는 것입니다. 가상 환경 또는 격리된 환경: venv 파이썬으로, 또는 간단히 말해서 프로젝트 node_modules Node.js 환경에서 Git을 사용한 버전 관리와 좋은 .gitignore README 파일에 설치 과정을 문서화하면 다른 개발자들이 자신의 컴퓨터에 MCP 서버를 더 쉽게 복제할 수 있습니다.
MCP 서버의 도구, 리소스, 테스트 및 배포
언어 모델이 도구를 안정적으로 사용하려면 도구를 잘 정의하는 것이 중요합니다. 각 도구는 명확하게 정의된 단일 작업 (원자성 원칙)을 수행해야 하며, 설명적인 이름, 명확한 설명, 상세한 입력/출력 스키마를 갖춰야 합니다. 이를 통해 서버는 자신의 기능을 알리고 클라이언트(모델)는 무엇을 요청할 수 있고 무엇을 받을 수 있는지 이해할 수 있습니다.
코드에서는 일반적으로 툴바 (예를 들어 파이썬에서는 도구 이름과 함수를 매핑하는 딕셔너리)를 관리합니다 . 새 툴바를 추가하려면 유효성 검사를 포함한 함수를 작성하고, 문서화한 다음 해당 툴바에 추가해야 합니다. 반면에 리소스는 이러한 도구가 상호 작용하는 데이터 또는 서비스입니다. 예를 들어 데이터베이스, 외부 API, 파일 시스템, 큐 등이 있습니다.
테스트 단계에는 수동 테스트(MCP Inspector, Postman 또는 cURL 사용)와 자동화 테스트가 모두 포함됩니다. 일반적으로 샘플 MCP 메시지를 서버 엔드포인트로 전송하여 검증합니다. 답변은 예상 형식에 부합합니다.오류 코드, 데이터 구조 및 필수 필드를 포함합니다. 파이썬에서는, pytest 이는 단위 테스트 및 통합 테스트를 용이하게 합니다. Node.js에서는 다음과 같은 프레임워크가 사용됩니다. mocha o jest 그들은 그러한 기능을 수행합니다.
디버깅을 위해서는 잘 설계된 로깅 시스템이 필수적입니다. 다음과 같은 라이브러리들이 있습니다. logging 파이썬에서 또는 winston Node.js에서 디버거를 사용하면 요청이 도착했을 때 발생하는 일, 실행되는 도구, 입력되는 매개변수 및 출력되는 내용을 기록할 수 있습니다. 개발 환경에서는 그래픽 디버거(VS Code, PyCharm, WebStorm)를 사용하여 중단점을 설정하고 변수를 자세히 검사할 수 있습니다.
MCP 서버가 로컬에서 실행되면 다음 단계는 배포입니다. 많은 사람들이 자동 확장, 고가용성 및 내장 TLS 인증서 관리 기능을 제공하는 Docker 컨테이너나 Google Cloud Run, AWS ECS 또는 Azure App Service 와 같은 플랫폼을 선택합니다 . 모든 민감한 구성 정보(API 키, 자격 증명 등)는 환경 변수로 옮기고 코드에서 비밀 정보를 분리하는 것이 중요합니다.
보안은 API 키 또는 OAuth와 같은 인증 메커니즘에 의존하여 신뢰할 수 있는 클라이언트만 접근할 수 있도록 제한합니다. 또한 서버가 트래픽 급증을 처리할 수 있도록 리소스 제한 및 수평 확장 정책을 정의하는 것이 좋습니다 . CloudWatch 또는 Google Operations와 같은 도구를 사용하여 모니터링하고 상태 확인 엔드포인트를 노출하면 장애를 훨씬 쉽게 감지할 수 있습니다.
유지 관리 측면에서는 종속성 및 운영 체제를 정기적으로 업데이트하고 , 보안 패치를 적용하며, 서비스 중단을 방지하기 위해 블루/그린 배포 또는 롤링 배포 전략을 사용하는 것이 좋습니다 . 이러한 사항은 GNOME 자동화를 위한 MCP 서버뿐만 아니라 Stripe 또는 GitHub를 통합하는 서버에도 동일하게 적용됩니다.
Docker 및 AI 제어 Linux 샌드박스용 MCP 서버
MCP를 활용하여 무엇을 할 수 있는지 보여주는 또 다른 매우 명확한 예는 다음과 같습니다. Docker Engine을 사용하여 AI로 제어되는 Linux 샌드박스를 생성하는 서버이러한 유형의 서버는 Gemini-cli 또는 Claude와 같은 도구가 명령을 실행하고, 코드를 컴파일하고, 파일을 편집하고, 심지어 편집기를 열 수 있는 격리된 컨테이너를 생성합니다. vim사용자는 일어나는 모든 일을 볼 수 있습니다.
일반적인 시연에서 사용자는 AI에게 C 프로그램을 작성하고 컴파일한 후 컨테이너 내에서 실행하도록 요청하고 터미널 편집기를 사용하도록 지시합니다. MCP 서버는 중간자 역할을 하여 컨테이너를 생성하고, 필요한 도구를 제공하고, 명령을 전달하고, 출력을 캡처합니다 . 이 모든 과정은 투명하게 진행되므로 샌드박스 내부에서 모델이 무엇을 하는지 정확히 알 수 있습니다.
이 접근 방식은 호스트 시스템을 안전하게 유지하기 때문에 실험, 교육 또는 잠재적으로 위험한 개발 작업에 매우 유용합니다 . 이 특정 서버의 소스 코드는 GitHub에서 확인할 수 있으므로, 이를 연구하고 필요에 맞게 수정하거나 개선 사항에 기여할 수 있습니다. 이는 MCP가 AI와 컨테이너를 매우 유연하게 연결하는 방법을 보여주는 완벽한 예입니다.
GNOME 환경에서 이러한 유형의 서버는 매우 유용합니다. 데스크톱 MCP 클라이언트를 사용하여 AI에게 Docker 샌드박스 환경 설정을 요청하고, 컨테이너가 백그라운드에서 작업을 수행하는 동안 그래픽 애플리케이션 작업을 계속할 수 있습니다 . 데스크톱과 샌드박스 환경의 분리는 자동화의 강력한 기능을 유지하면서도 안심하고 사용할 수 있도록 해줍니다.
또한, 이러한 유형의 서버를 브라우저 또는 데스크톱 자동화 서버(Puppeteer 또는 AT-SPI2를 통해)와 결합하면 매우 고급 워크플로우를 구현할 수 있습니다 . 예를 들어 Docker에서 앱을 실행하고, MCP로 제어되는 브라우저를 실행하여 엔드투엔드 테스트를 수행하는 동시에 모델이 데스크톱 대화 상자 및 창과 상호 작용할 수 있도록 할 수 있습니다.
대체 클라이언트에서의 MCP: KoboldCpp의 예시
모든 MCP 지원이 Claude Desktop과 같은 상용 클라이언트에만 국한된 것은 아닙니다. KoboldCpp와 같은 도구는 최근 버전에서 네이티브 MCP 지원을 통합하여 다른 클라이언트에서 사용하는 것과 동일한 서버에 연결할 수 있는 데스크톱 대안을 제공하고 있습니다.
KoboldCpp 버전 1.106에서는 파일에 선언된 모든 서버에 연결할 수 있는 "MCP 브리지"가 추가되었습니다. mcp.json Claude Desktop과 동일한 형식을 사용합니다. 이 브리지는 HTTP 기반 MCP 서버와 STDIO를 전송 프로토콜로 사용하는 서버 모두와 통신할 수 있으며, 자동으로 메시지를 전달합니다. 도구에 대한 호출 AI가 올바른 서버로 실행하기로 결정한 것입니다.
KoboldCpp 사용자 인터페이스에서 연결된 모든 MCP 서버에서 사용 가능한 도구 목록을 보고 , 모델이 사용할 도구를 활성화 또는 비활성화할 수 있으며, 도구 호출에 대한 승인 시스템을 활성화하여 AI가 특정 민감한 작업을 수행하기 전에 승인을 받도록 할 수도 있습니다.
이는 MCP가 특정 벤더에 종속되지 않음을 보여줍니다. 프로토콜을 구현하는 모든 클라이언트는 동일한 서버 생태계를 활용할 수 있습니다 . 실제로 GNOME 환경에 맞게 MCP 서버 세트를 이미 구성해 놓은 경우, 모든 통합 작업을 다시 수행할 필요 없이 다양한 클라이언트(Claude, KoboldCpp, MCP 플러그인이 있는 에디터 등)를 테스트할 수 있습니다.
KoboldCpp 커뮤니티에서 해당 부분을 확인할 수 있는 스크린샷을 공유했습니다. 여러 개의 툴 서버가 작동 중입니다. 동시에, 사용자가 설정을 거의 건드리지 않고도 MCP 브리지가 다양한 기능을 어떻게 조율하는지 보여줍니다. mcp.json.
궁극적으로 이러한 발전은 MCP가 특정 제품의 독점적인 추가 기능이 아니라 에이전트 및 도구를 위한 범용 표준 이라는 개념을 강화합니다 . 이는 GNOME 및 Linux 사용자뿐만 아니라 Windows 또는 macOS 사용자에게도 유익합니다.
위에서 언급한 모든 것을 종합해 볼 때, GNOME 환경에서 MCP 서버 지원의 전망은 매우 밝습니다. X11/Wayland를 지원하는 브라우저 및 데스크톱 자동화 기능, 최신 개발팀의 핵심 도구 대부분을 위한 원격 서버, 자체 서버 구축 및 배포에 대한 자세한 가이드, 그리고 프로토콜을 이해하는 다양한 클라이언트들이 존재합니다. 여기에 우수한 보안 관행, 데스크톱 접근성 확보, 그리고 어떤 서버를 활성화할지에 대한 명확한 전략을 결합한다면, AI가 단순한 챗봇을 넘어 GNOME 애플리케이션, Docker 컨테이너, 클라우드 플랫폼 사이를 원활하게 탐색할 수 있는 운영자로 발전하는 워크플로우를 구축할 수 있습니다.
