경쟁 분석에서 3,042 다운로드로 Docker MCP 서버 구축

출처: Dev.to

경쟁 분석에서 3,042+ 다운로드까지: Docker MCP 서버 구축

MCP 서버를 구축하고 싶다면 npm을 검색해 보세요. 11개의 기존 Docker 패키지를 발견했고, 이 니치가 비어 있지 않다는 것을 알게 되었습니다. 오히려 파편화되어 있습니다. 이것이 바로 기회입니다.

경쟁 분석을 시작해 Docker MCP 서버를 50개의 도구와 주간 3,042건 이상의 다운로드로 공개하고, MCP 생태계에 대해 어떤 것을 알게 되었는지 공유합니다.

Docker MCP 서버를 조사하기 시작했을 때 저는 2~3개의 경쟁자를 기대했습니다. 하지만 11개 이상을 발견했습니다. 레퍼런스 구현(ckreiling/mcp-server-docker, GitHub 별 721개, PyPI 주간 다운로드 8K) 은 12개월 동안 업데이트되지 않았고 GPL-3.0을 사용했습니다. Docker 공식 패키지(docker/hub-mcp, 별 152개)는 로컬 컨테이너 관리가 아니라 레지스트리 API 문제를 해결합니다.

시장 전체는 약 10K건의 주간 다운로드를 기록하고 있습니다. 이는 실제 수요를 보여줍니다. 하지만 패키지는 라이선스, 기능 세트, 유지보수 수준이 다양한 상태로 분산되어 있었습니다.

발견한 간극: “에이전트 운영”을 위한 서버가 없었습니다. 모든 Docker MCP 서버는 Docker API 위에 일반적인 CRUD 래퍼였으며, 건강 검사, 자동 재시작, 로그 스트리밍, Compose 라이프사이클 관리와 같은 에이전트가 자율적으로 컨테이너를 실행할 때 필요한 기능이 누락되어 있었습니다.

가장 큰 설계 결정은 도구 수량이었습니다. MCP 생태계는 도구가 많을수록 기능이 많아지지만(context 오버헤드도 커짐) tension이 존재합니다. 상위 서버들의 특징을 살펴보았습니다:

• Playwright MCP: 집중된, 특정 도구
• Context7: 좁은 범위, 심도 깊은 실행
• Notion MCP: 포괄적이지만 잘 정리됨

처음 25개의 도구를 5개 카테고리에 걸쳐 시작했고, 실제 사용을 반영해 50개로 확대했습니다.

컨테이너 관리 (10개 도구): list, inspect, start, stop, restart, remove, stats, prune, resource limits, update. 기본 기능과 라이프사이클 관리가 포함되어 에이전트가 중지된 컨테이너를 정리하고 CPU/메모리 한계를 설정할 수 있습니다.

Compose 작업 (5개 도구): up, down, ps, logs, exec. docker‑compose up만 하는 것이 아니라 전체 Compose 라이프사이클을 지원합니다.

이미지 관리 (5개 도구): list, pull, remove, build, inspect. 에이전트는 컨테이너가 아니라 이미지를 관리해야 합니다.

건강 및 모니터링 (9개 도구): health check, container logs, resource usage, event stream, network inspect, fleet status, fleet stats, log search, thresholds check. 여기서 Nova가 차별화되는 점은 에이전트가 컨테이너가 단순히 실행 중이라는 것이 아니라 실제로 건강한지 여부를 알 수 있다는 것입니다. 모니터링 도구들은 실 Docker API 호출을 이용하는 전용 모듈로 구현되었습니다.

레지스트리 작업 (3개 도구): registry_login (Docker Hub/ECR/ACR/GCR 인증), registry_search (Docker Hub 검색), registry_push (이미지를 레지스트리에 푸시). 배포를 관리하는 에이전트는 개인 레지스트리에서 이미지를 풀하고 푸시해야 합니다.

보안 스캔 (2개 도구): scan_image (Trivy 기반 CVE 스캔으로 심각도 필터링), vulnerability_report (수정된 권고 사항을 포함한 상세 보고서). 프로덕션 에이전트 워크플로에서는 컨테이너 보안을 포기할 수 없습니다.

컨텍스트 관리 (3개 도구): list_contexts, use_context, inspect_context. 다중 호스트 Docker 컨텍스트 전환을 통해 인프라를 다양한 환경에서 관리할 수 있습니다.

시스템 및 정리 (4개 도구): disk usage, version, info, prune containers. 정리와 진단 기능입니다.

파일 전송 (2개 도구): 컨테이너에 복사/전송, 파일 목록. 에이전트는 컨테이너에 exec을 하지 않고 호스트와 컨테이너 간 파일을 이동할 수 있습니다.

exec, 로그, 네트워크 및 볼륨 (7개 도구): 컨테이너에 exec, 로그 스트리밍, 네트워크 검사, 볼륨 관리. 컨테이너 작업을 지원하는 인프라 기능입니다.

각 도구는 세 가지 원칙을 기반으로 설계되었습니다:

• 합리적인 기본값. 에이전트는 —rm을 매번 지정할 필요가 없습니다. 도구가 대신 처리합니다.
• 구조화된 출력. 모든 도구는 일관된 필드 이름을 가진 JSON을 반환합니다. docker ps 출력을 파싱하지 않습니다.
• 오류 복구. 도구는 스택 트레이스 대신 실행 가능한 오류 메시지를 반환합니다. ‘컨테이너를 찾을 수 없음’은 ‘Error: 404.‘보다 유용합니다.

TypeScript + MIT 라이선스로 구현했습니다. 이유는 다음과 같습니다:

• npm 생태계. MCP 서버는 npx를 통해 소비됩니다. TypeScript가 JavaScript로 컴파일되고 npm이 배포를 담당합니다. 파이썬도 가능하지만 MCP 툴링 생태계는 TypeScript에 편중되어 있습니다.
• 타입 안전성. 50개의 도구는 50개의 입력 스키마와 50개의 출력 포맷을 의미합니다. TypeScript 타입 시스템은 런타임이 아닌 컴파일 시 불일치를 잡습니다.
• MIT > GPL. 기존 레퍼런스 구현은 GPL-3.0을 사용합니다. 이는 많은 엔터프라이즈 에이전트에게 장애물이 됩니다. MIT는 마찰을 완전히 제거합니다.

아키텍처는 간단했습니다:

src/ tools/ # One file per tool category container.ts # 10 container management tools compose.ts # 5 Compose operations image.ts # 5 image management tools health.ts # 3 health/monitoring tools monitoring.ts # 6 fleet monitoring tools registry.ts # 3 registry operation tools security.ts # 2 security scanning tools context.ts # 3 Docker context tools system.ts # 2 system tools transfer.ts # 2 file transfer tools exec.ts # 1 exec tool logs.ts # 2 log tools network.ts # 2 network tools volume.ts # 4 volume tools server.ts # MCP server setup docker.ts # Docker API client wrapper

Docker 클라이언트 래퍼는 가장 중요한 부분이었습니다. 모든 Docker API 호출을 일관된 인터페이스로 정규화하고, 적절한 오류 처리와 타임아웃 관리를 제공하며, 구조화된 출력을 반환합니다. 모든 도구는 이 래퍼를 통해 동작합니다.

테스트: 78개의 테스트 케이스와 7개 테스트 스위트를覆蓋하여 도구 실행, 오류 처리 및 엣지 케이스를 검증합니다. TypeScript 빌드가 정상적으로 완료됩니다.

출판 과정은 기대보다 매끄럽습니다:

npm publish —access public (슈퍼노바123 스코프와 함께) 패키지가 초단위로 npm에 표시됩니다 npx @supernova123/docker-mcp-server가 즉시 작동합니다

패키지는 postInstallInstructions를 포함해 설정 문서에 링크됩니다. 모든 npm MCP 서버는 이를 가져야 합니다.

진실은 첫 주에 다운로드가 전혀 없었습니다. 이는 독립적인 MCP 서버의 일반적 상황이며, 공식 CoinGecko 패키지도 npm 트래픽이 없습니다. 암호화폐 MCP 니치는 npm에서 발견될 수 없는 구조적 특성을 가지고 있습니다.

하지만 3주 동안 일어난 일은 다음과 같습니다:

• 주간 3,042건의 다운로드. 모두 npm 키워드 검색과 npx 자동 설정에서 비롯되었습니다. 외부 리퍼러 트래픽은 전혀 없었습니다. 다운로드는 제가 구축한 채널이 아니라 개발자가 npm에서 ‘docker mcp’를 검색하면서 발생합니다.
• Glama는 서버가 품질 B 등급을 받은 Glama MCP 디렉터리에 나타났습니다. 첫 30일 동안 프로필 조회 11건, 검색 인상 1건이 있었습니다. 이것이 Glama가 설계한 대로 작동하는 discovery surface(발견 표면)입니다.
• GitHub 레포가 공개되었습니다. Friendlygeorge/docker-mcp-server에 적절한 토픽(mcp, docker, container, compose, devops, ai-agent, model-context-protocol)이 부여되었습니다. GitHub 토픽은 계정 없이도 배포 채널 역할을 합니다.
• 지식 베이스 페이지. 전체 문서는 friendlygeorge.github.io/tools/docker-mcp-server.html에서 확인할 수 있습니다.
• README 최적화. 배지, 비교표, npx를 선으로 Quick Start, 보안 섹션, 문제 해결 섹션 포함.
• 4개 레포에 7개의 오픈 PR가 있습니다. modelcontextprotocol/registry(3건), docker/mcp-registry, punkpeye/awesome-mcp-servers(88K 별), rohitg00/awesome-devops-mcp-servers. CI는 모두 정상이고 유지자 검토를 대기 중입니다. 전환 창이 열리고 있습니다.

MCP 서버를 구축한다면 다음과 같이 하길 권합니다:

• 경쟁 분석을 먼저 시작하세요. 코드를 쓰기 전에 npm, Glama, GitHub을 검색합니다. 니치가 파편화되어 있을 수도 있고(기회), 포화 상태일 수도 있습니다(전환 신호).
• 인간을 위한 것이 아니라 에이전트를 위한 설계. 에이전트는 구조화된 출력, 합리적인 기본값, 오류 복구가 필요합니다. 인간은 좋은 README가 필요합니다. 둘을 모두 고려해 설계하세요.
• 처음 25개 도구로 시작해 50개까지 확장합니다. 충분히 유용하지만 과도한 컨텍스트 오버헤드가 성능을 해치지 않도록 합니다. 가상의 기능이 아닌 실제 사용량을 기반으로 도구를 추가합니다. 파일 전송, 리소스 제한, 레지스트리 작업, 보안 스캔은 그 예시입니다.