요약 (TL;DR) — 우리는 7개의 해양 MCP 서버를 출시한 후에야 처음에 했어야 했던 생태계 스캔을 실행했습니다. 좋은 소식은, 이 틈새 시장이 비어 있으며 우리가 베팅한 기능들(NDBC 부표 실측 데이터 확인, 조류 (tidal currents), COLREGs 규칙 텍스트, 정박 편의성 순위)이 MCP 생태계 어디에서도 선행 사례(prior art)가 없었다는 점입니다. 나쁜 소식은, 단 하룻밤의 스캔만 했더라도 여러 결정이 바뀌었을 것이라는 점입니다. 지도로 바로 이동하세요.

이 스택은 하나의 기본 원칙에 따라 작동합니다: 자신만의 것을 만들기 전에 기존 도구를 사용하거나 개선하라. 우리는 이를 구성 요소별로 적용했습니다. 이것이 우리가 signalk-logbook용으로 작동하던 로그북을 삭제한 이유이며, 기상 서버가 기존의 3개 기상 MCP와 대조하여 감사(audit)를 받은 이유입니다. 우리가 하지 못했던 것은 생태계 _전체_를 한 번에 스캔하는 것이었습니다. 즉, 모든 해양 MCP 서버, 모든 SignalK AI 통합, 우리가 구축하던 것과 인접한 모든 플러그인을 살펴보는 것이었습니다.

7개의 서버를 구축한 후 마침내 스캔을 실행했을 때, 솔직한 질문은 이것이었습니다: 우리는 얼마나 많은 것을 다시 만든 것인가? 이 포스트는 우리가 찾았기를 바랐던 지도로서 공개하는 그 답변입니다.

지도

여기에 있는 모든 것은 공개되어 있으며, 링크는 저장소(repos)로 연결됩니다. "혁신적(Novel)"이라는 의미는 스캔 시점을 기준으로 어떤 MCP 서버에서도 해당 기능을 수행하는 선행 사례를 찾지 못했음을 의미합니다.

또한, 함대(fleet)의 영향력 밖에도 지도에 포함되어 있습니다:

• d3kOS — Raspberry Pi 기반의 AI 항해 컴퓨터: 오프라인 음성 인식, PDF 매뉴얼 기반의 엔진 진단 RAG (Retrieval-Augmented Generation), 선수 카메라(bow-camera) 객체 탐지(object detection) 기능을 제공합니다. 매뉴얼 RAG와 선수 카메라 기능은 우리가 운영 중인 그 어떤 것보다 앞서 있으며, 주목할 가치가 있습니다.
• Windward MAI Expert — 상업용 함대 규모의 "알람(alarm) → 에이전트 기반 보강(agentic enrichment) → 서사적 브리핑(narrative brief)" 솔루션입니다. 크루저(cruiser)가 직접 실행할 수 있는 수준은 아니지만, 알람 분류(alarm-triage) 에이전트 패턴을 독립적으로 검증해 줍니다.
• Saillogger's AIS MCP — 현재는 좁은 범위의 스텁(stub) 형태이며, signalk-console과 동일한 저자가 개발했습니다.

스캔을 통해 실제로 발견한 사실

1. 우리는 전체를 새로 구축하지 않았습니다 — 이 분야는 정말 희소합니다. 7개의 서버 중 4개는 선행 기술(prior art)이 전혀 없었습니다. 이는 놀라운 결과였습니다. MCP 서버는 겉보기에 거의 모든 것에 대해 존재하지만, "해양 + 운영 + 에이전트 대응(agent-facing)" 영역은 거의 비어 있습니다. 만약 이 분야에서 개발을 고려 중이라면, 생태계 스캔에 드는 비용은 단 하룻밤 정도이며, 이 분야는 여전히 대부분 미개척 상태입니다.

2. 단 하나의 진짜 놓친 사례는 PostgSail이었습니다. 자체적으로 활발히 유지 관리되는 MCP 서버를 갖춘 Apache-2.0 라이선스의 항해 데이터베이스(voyage database)로, 항해 기록, 여행 요약, 모니터링, 유지보수 노트 등을 제공합니다. 우리는 로그북(logbook) 통합 기능을 출시한 이후에 이를 발견했습니다. 사후 평가 결과는 "이 스택을 채택하지 말고, 도구 설계 방식만 빌려오라"는 결론에 도달했습니다(이는 대시보드를 목표로 하는 Postgres/Timescale/Grafana 계층 전체를 포함하지만, 우리의 로그는 YAML 형식으로 선박 내에 존재합니다). 하지만 이는 운이 좋았던 판결이었습니다. 구축 전 스캔을 수행했다면, 이는 동전 던지기가 아닌 결정의 문제가 되었을 것입니다.

3. 라이선스 또한 선행 기술의 일부입니다. signalk-hour-meter는 엔진 가동 시간(engine-hours)을 위한 채택 후보처럼 보였으나, 스캔 결과 수년간 방치되었으며 결정적으로 라이선스가 없음이 확인되었습니다. 라이선스가 없다는 것은 모든 권리가 보유(all-rights-reserved)되어 있음을 의미합니다. 즉, 패턴은 읽을 수 있지만 코드를 배포할 수는 없습니다. 단 한 번의 확인으로 "채택"이 "패턴 참조 전용"으로 1분 만에 바뀌었습니다. 애착을 갖기 전에 반드시 라이선스를 확인하십시오.

4. 이름 충돌은 협업의 대상이 아닙니다. 현재 활발하게 운영되고 있으며 완성도 높은 범용 weather-mcp 조직(org)이 존재합니다. 해당 조직의 README에는 자신들의 해양 데이터가 "항해에 적합하지 않음(not suitable for navigation)"이라고 명시되어 있는데, 이는 선상 운용 도구(on-boat operational tool)와는 정반대되는 성격이며 부표 관측 데이터(buoy observations)도 전혀 포함되어 있지 않습니다. 이름은 같지만 철학은 완전히 다릅니다. 실질적인 교훈은 다음과 같습니다: 만약 당신의 리포지토리(repo) 이름이 포화 상태라면(관련 없는 weather-mcp가 8개 이상 존재할 때), 문서와 교차 참조(cross-ref)에서 항상 조직(org) 이름을 통해 명확히 구분하십시오.

5. 인적 지도(people map)가 가치의 절반을 차지합니다. 이번 스캔의 가장 유용한 결과물은 코드가 아니었습니다. 우리가 인지하지 못한 채 이미 여러 생태계 저자들의 작업물을 _사용하고 있었다_는 사실을 발견한 것이었습니다. 우리가 채택한 로그북 플러그인(logbook plugin), 평가 목록에 있는 Victron 플러그인, 그리고 우리가 검토했던 레이더 서버(radar server)가 그 예입니다. 선행 기술 스캔(prior-art scan)은 당신이 누구의 작업물에 의존하고 있는지를 보여주는 지도의 역할도 겸하며, 바로 그들이 당신이 대화를 나누고, 기여(contributing back)하며, 크레딧을 표기해야 할 대상입니다.

실행 가능한 교훈

이번 스캔에는 GitHub 토픽, SignalK 플러그인 레지스트리, 그리고 MCP 디렉토리를 에이전트(agent)의 도움을 받아 검색하는 데 단 하룻밤이 소요되었습니다. 여전히 희소한(sparse) 니치(niche) 시장임에도 불구하고, 이 과정은 반드시 검토했어야 할 프로젝트 하나를 찾아냈고, 라이선스 문제로 채택 예정이었던 프로젝트 하나를 중단시켰으며, 동료의 상반된 아키텍처를 파악했고, 우리가 의식적으로 선택하지 않았던 세 가지 업스트림 의존성(upstream dependencies)을 밝혀냈습니다.

따라서 이는 사후 검토가 아닌, 체크리스트의 단계가 되었습니다:

새로운 빌드 도메인인가?
1. 먼저 스캔하십시오: 설계 문서(design doc)를 작성하기 BEFORE, GitHub 토픽 검색 + MCP 디렉토리 + SignalK 플러그인 레지스트리(appstore)를 확인하십시오.
...

3단계는 복리 효과를 내는 부분입니다. 기록된 판결(verdicts) 덕분에 우리는 "우리가 얼마나 많은 것을 다시 만들었는가?"라는 질문에 느낌이 아닌 표로 답할 수 있게 되었으며, 이 포스트의 내용 또한 바로 그 판결들로 구성되어 있습니다.

위의 모든 내용은 github.com/sailingnaturali에서 제공되며, 완전 전기 동력 요트(all-electric sailboat)의 에이전트 스택(agent stack)을 위해 구축되었습니다. 만약 당신이 해양-MCP(marine-MCP) 분야에서 개발 중이라면, 이 지도는 넓은 공해(open water)가 펼쳐져 있음을 알려줍니다.

관련 글:
adopt vs build: the ship's logbook ·
the NDBC buoy reality-check how-to ·
named tools vs execute-code for voice agents