MeshCore 개발팀, 상표권 분쟁과 AI 생성 코드 문제로 분리

 (blog.meshcore.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 빠르게 성장한 메쉬 네트워킹 프로젝트에서 상표권 출원과 AI 생성 코드 사용 문제가 겹치며 core team과 Andy Kirby가 갈라짐
  • Andy Kirby는 Claude Code를 광범위하게 사용해 standalone device, 모바일 앱, web flasher, web config 도구까지 확장했고, 팀은 이 작업 상당수가 vibe coded 형태였으며 이를 숨겼다고 적고 있음
  • 분리의 직접 계기로는 Andy가 3월 29일 MeshCore 상표를 팀에 알리지 않고 출원한 일이 있었고, 이후 의도를 둘러싼 대화가 결렬되며 소통도 끊긴 상태임
  • core team은 공식 MeshCore를 GitHub 저장소가 규정하는 단일 source of truth로 못박았고, 새 거점인 meshcore.io를 중심으로 펌웨어 개발, 앱 릴리스, 기술 문서, 개발자 논의를 이어감
  • 2025년 1월 시작 이후 공식 Map의 38,000개 이상 노드와 공식 App의 100,000명 이상 활성 사용자를 확보한 만큼, 공식 정보 공간과 운영 주체를 분명히 하는 일이 더 중요해짐

분리 배경

  • MeshCore 개발팀은 프로젝트 시작 이후 MeshCore Companion, Repeater, Room Server 펌웨어를 85개 이상 릴리스했고, 75종이 넘는 하드웨어 변형을 지원해 옴
  • 팀은 AI 생성 코드에 늘 조심스러운 태도를 유지해 왔지만, Andy Kirby가 Claude Code를 광범위하게 사용해 독자적으로 움직이기 시작했고 standalone device, 모바일 앱, web flasher, web config 도구까지 MeshCore 생태계 전반으로 작업 범위를 넓혀 감
  • Andy Kirby는 해당 작업 대부분이 vibe coded 형태라는 점을 팀에 숨긴 것으로 적혀 있음
  • 팀은 MeshCore Discord에서 AI와 신뢰를 주제로 설문을 진행했지만, 본문에는 설문 수치나 세부 결과가 텍스트로 제시되지 않음
  • 갈등이 본격화된 계기로, Andy가 3월 29일자로 MeshCore 상표를 출원했고 이를 팀에 알리지 않았다고 적혀 있음
    • 팀은 그의 의도를 논의하려 했지만 대화가 결렬됐고, 현재는 Andy와 소통이 끊긴 상태임
  • 팀은 최근 몇 달간 이 문제를 해결하려고 애썼고, 프로젝트를 위해 오랫동안 일한 팀 입장에서는 내부 인물이 로봇과 변호사와 손잡은 일처럼 느껴질 정도로 충격이 컸음

공식 MeshCore

  • 현재 다투는 핵심은 ‘official’ 표기 사용권이며, Andy는 자신이 브랜드를 소유한다고 강하게 주장하면서 MeshOS 라인에 이 표현을 적극 사용하고 있음
  • 팀은 실제로 유일한 공식 MeshCore를 GitHub 저장소로 규정함
    • 해당 저장소가 무엇이 MeshCore인지 결정하는 source of truth로 작동함
    • Andy는 그 저장소에 한 번도 기여한 적이 없음
  • 내부 분리 이후 팀은 meshcore.io를 새로 열었고, Andy가 meshcore.co.uk와 원래 Discord 서버를 통제하고 있어서 다른 선택지가 거의 없었음
  • 새 사이트를 연 뒤 Andy가 Claude를 사용해 그 look and feel까지 복제했고, 그러지 말아 달라는 요청도 받아들여지지 않았음

프로젝트 성장

  • MeshCore는 2025년 1월에 시작한 뒤 매우 빠르게 성장함
  • 이 글 시점 기준 공식 MeshCore Map에는 전 세계 38,000개 이상 노드가 표시되고, 공식 MeshCore App은 Android와 iOS에서 100,000명 이상 활성 사용자를 보유함
  • 프로젝트 규모가 커질수록 core team이 제공하는 공식 정보 공간의 중요성이 더 커짐
  • 최근에는 국가별 사이트와 지역 메쉬 커뮤니티 중심의 MeshCore 웹사이트 확산이 이어졌고, 다음 예시를 직접 나열함
  • Andy Kirby는 개인 YouTube에서 MeshCore 홍보에 큰 역할을 했지만, 지금은 자신의 제품 홍보에 집중하고 있음

앞으로의 운영 방향

  • core team은 meshcore.io를 중심으로 펌웨어 기능 개발, 버그 수정, PR 관리, 개발자 논의를 계속 이어감
  • 새 펌웨어와 앱 릴리스의 변경 로그, 블로그 글, 기술 문서는 이제 아래 채널을 통해 배포됨
  • 블로그에 참여하는 인물과 역할도 함께 공개함
    • Scott는 프로젝트 창립자이자 lead firmware engineer이며 Ripple firmware 개발자이기도 함
    • Recrof는 공식 MeshCore Map 개발자이자 Firmware Flasher 담당이며, MeshCore Map 초기 개발에 대한 통찰도 공유함
    • Liam Cottle는 공식 MeshCore App 개발자로, MeshCore App 시작 가이드를 게시할 예정임
    • FDLamotte는 MeshCore용 Python 도구와 STM32 펌웨어 변형 작업을 맡고 있음
    • Oltaco는 펌웨어 업데이트 신뢰성을 높이는 새 OTA Fix bootloader 작업을 맡음

코어 팀

  • 현재 MeshCore 팀은 Scott, Liam, Recrof, FDLamotte, Oltaco로 구성됨
  • 이 팀은 앞으로도 사람이 직접 작성한 소프트웨어를 바탕으로 고품질 설계와 개발을 이어갈 계획임

새로운 거점

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 아직 안 써봤다면 Reticulum을 꼭 살펴보길 권함
    기본 프로젝트는 지금 새 유지보수자가 필요해 보이고, 메인 개발자의 강한 입장도 좀 있긴 하지만, 분산 네트워킹 프로토콜 계층 설계는 정말 잘 다듬어져 있음
    데스크톱 앱은 인터넷(IP)이나 기존 LoRA 보드의 USB 연결로 동작하고, 최근 https://lilygo.cc/products/t-echo-lilygo를 사서 오픈소스 펌웨어를 올려 써봤는데 USB로 데스크톱에 붙이거나 Bluetooth로 https://github.com/torlando-tech/columba와 연결하는 경험이 아주 좋았음
    이 앱 덕분에 메시징 지원 면에서 Reticulum이 정말 1급 시민처럼 느껴지고, 제한은 있지만 파일이나 이미지도 보낼 수 있음
    네트워크 레벨에서 동작하니 Reticulum 위에서 자기 앱을 직접 만들 수도 있음

    • 이미 LoRa에서 잘 돌아가지만, 이건 전송 매체에 종속되지 않는 프로토콜이라 앞으로 halow, 광학, wifi 같은 다른 전송 방식에서도 잘 맞을 거라고 봄
      사람들도 언젠가는 LoRa가 단순 텍스트 메시징을 넘는 대역폭·속도 요구를 절대 못 따라간다는 걸 깨닫게 될 것 같음
      그래도 Reticulum LoRa 1홉으로 실시간 음성 통화를 해봤는데 생각보다 꽤 괜찮게 동작했음
      시작용 위키는 여기 있음: https://reticulum.miraheze.org/wiki/Welcome
    • Reticulum으로 뭔가 만들어보려고 한 달을 썼지만, 프로토콜을 다루는 툴링이 너무 부족했음
      앱만 만들고 싶은 입장에서는 개발 경험이 꽤 짜증나는 수준이었고, 개념은 멋지지만 발목 잡는 함정이 너무 많아서 부트스트랩하기 지속 가능해 보이지 않았음
      특히 nrf52 LoRA 장치에서 돌리려고 Rust no-std로 스택을 포팅해서 기존 MeshCore 네트워크로 reticulum 패킷을 실어보려 했는데, 내 패킷이 제대로 만들어졌는지조차 확인하기가 악몽 같았음
    • 실제 환경에서 작동하는 Reticulum 네트워크는 한 번도 못 봤음
      늘 아주 작은 테스트베드만 봤음
    • 어느 주파수 대역을 받게 되는지 궁금함
      그게 실제로 중요한지도 궁금함
    • nomadnet이 Go로 다시 쓰였으면 좋겠음

  • 왜 mesh 프로젝트들은 이렇게 상표권 집행이 지나치게 엄격한지 모르겠음
    Meshtastic도 비슷하고, 내가 MeshCore에 관심을 갖게 된 계기 중 하나도 Meshtastic 상표 규정을 읽고 너무 과하다고 느꼈기 때문임

    • 라디오 쪽 문화가 일반적인 오픈소스 문화와는 꽤 다른 것 같다는 느낌이 듦
      자유롭고 제한 없는 공유는 세상의 기본값이 아니라 오히려 특이한 편에 가까움
    • 관련 인물들은 잘 모르지만, 아마 아마추어 무선 자격증 가진 사람들일 가능성이 높아 보임
    • 지금 단계에서 MeshCore를 MeshTastic과 같은 수준의 집행 사례로 비교하는 건 공정하지 않다고 봄
      현재로선 팀의 다른 구성원 승인 없이 영국에서 한 사람이 상표를 등록한 사건처럼 보이고, 아직 누군가를 실제로 공격하고 있는 건 아님
    • 이유는 단순함. 돈 냄새가 나기 때문임
      MeshCore는 사용자 10만 명이 넘고 중계기도 전 세계에 잡초처럼 늘어나고 있어서, 여기서 현금화하려는 유인이 아주 큼
      특히 여기서 현금화하려는 사람은 펌웨어나 앱 개발 쪽이 아니라 마케팅 쪽 사람이었음
    • 프로토콜은 CC이고 Mark도 마음껏 쓰라고 했다고 들었음
      다만 자기 작업물이 멈출 수 없는 AI 살상 네트웜에 기여하는 건 원치 않는 듯함

  • We have always been wary of AI generated code, but felt everyone is free to do what they want and experiment, etc. But, one of our own, Andy Kirby, decided to branch out and extensively use Claude Code, and has decided to aggressively take over all of the components of the MeshCore ecosystem: standalone devices, mobile app, web flasher and web config tools.
    And, he’s kept that small detail a secret - that it’s all majority vibe coded.
    맥락이 더 없으면 이런 프레이밍은 꽤 의심스러움

    1. 누군가가 생태계를 "장악"한다는 건 AI 사용과는 전혀 다른 문제임. 그게 정확히 무슨 뜻인지 모르겠고, 그냥 그 사람이 뭔가를 공개했고 사람들이 쓰고 싶어 한다는 뜻인지도 모르겠음
    2. 코드가 실제로 나쁜가가 더 중요함. 팀이 그가 AI를 쓰는 줄 몰랐다는 건, 적어도 코드 자체는 겉보기에 문제가 없었다는 뜻처럼 들림. 그러면 왜 코드 자체의 완성도로 판단하지 않는지 모르겠음
      상표 출원은 사실이라면 분명 적대적이고 나쁜 행동이지만, 누군가가 Claude Code를 썼다는 이유만으로 분노하진 않겠음
    • 동의함
      MeshCore를 실제로 쓰고 있고 중계기도 여러 개 운영하지만, AI 보조 코딩 자체는 신경 쓰지 않음
      다만 특히 클로즈드소스라면 그 사실은 공개해야 한다고 봄
      상표권으로 생태계를 가져가려는 시도는 미친 일처럼 보이고, Andy는 GitHub 프로젝트 자체엔 기여하지 않고 개인적인 영리 부가물만 만들었다는 점도 걸림
      동시에 MeshCore 핵심 팀도 반AI 편향을 붙여서 더 강한 서사를 만들려 한 건 맞아 보임
    • 동의하지 않음
      오히려 이렇게 공개적으로 문제 삼은 걸 지지함
      AI가 뱉은 엉성한 1000줄을 전부 제대로 리뷰했다고 말하는 사람은 자신이나 남을 속이고 있는 거고, 실제로 대규모 코드 리뷰를 해본 적도 없을 가능성이 큼
      텍스트 1000줄을 읽는 것과 코드의 복잡도 영향과 엣지 케이스를 분석하는 건 완전히 다른 일이고, 그런 종합 리뷰는 며칠이 걸릴 수도 있음
      100줄짜리 PR만 봐도 몇 시간씩 걸릴 수 있는데, "제가 다 검토했습니다" 같은 태도로 넘어가니 0-day와 유출이 점점 많아진다고 봄
      그래서 "You are absolutely correct, apologies for the oversight, here's a revised version:" 같은 식의 산출물은 절대 못 믿겠음

    • Is the code bad? It sounds like they had no idea he was using AI. That seems to imply there was nothing wrong with the code as-is. Why not judge it on it's merits?
      AI를 조금이라도 써봤다면 실제로는 이렇게 안 돌아간다는 걸 알게 됨
      AI 출력은 그럴듯하지만 틀린 결과를 만드는 데 아주 능하고, 애초에 그럴듯함에 최적화돼 있어서 종종 맞기도 하지만 틀릴 때는 좋아 보이는 코드를 만들어내므로 오히려 판단이 더 어려워짐
      사람이 쓴 코드는 좋은지 아닌지 감을 잡기가 상대적으로 더 쉬움
      물론 AddressSanitizer 같은 오라클이 있거나 기존 프로젝트를 복제하면서 동작을 직접 비교할 수 있는 예외는 있지만, 대개는 그런 사치가 없음

  • MeshCore와 Meshtastic을 좀 만져봤는데 재미는 있어도 전반적인 과대평가는 심하다고 느낌
    여기 끼어드는 SHTF 성향 사람들 때문에 개념 자체가 좀 흐려짐
    센서 네트워크 용도에는 관심이 있었지만, 실제 대화의 대부분은 Hello World 같은 텍스트를 주고받는 데 꽂힌 사람들 얘기이고, 정작 진짜 SHTF 상황에서 이런 네트워크가 얼마나 형편없이 동작할지는 잘 못 보는 듯함

    • 나도 거의 같은 느낌임
      두 모바일 앱 다 꽤 엉성하고, Meshtastic은 Android와 Apple UI 팀이 서로 대화도 안 하는 것처럼 보여서 더 짜증남
      서로 다른 플랫폼을 쓰면 신규 사용자 온보딩이나 질문 답변이 너무 어려움
      싸고 재미있게 구축하긴 했지만, 최소한 메시지를 안정적으로 안 놓치게 해주는 더 나은 메시지 지속성이 있었으면 좋겠음
    • Meshtastic과 GPS를 이용해서 큰 캠프장을 걸어다니며 지역을 점령하는 게임에 참여해봤는데, 그런 용도에는 정말 잘 맞았고 꽤 재미있었음
      하지만 내 생명이 이런 메시 네트워크에 달린 진지한 상황이라면 매우 불안할 것 같음
      이런 걸 신뢰 가능한 수단으로 고려하기엔 아직 너무 불안정하고, 그래도 아예 없는 것보단 나을 수는 있겠음
      장치 셋업도 문제인데, 인터넷 없는 곳에서도 한 군데서 작업하려고 raspberry pi 3에 전체 개발 환경을 올리려 했더니 기본 클라이언트 인터페이스인 거대한 웹 앱을 빌드하다가 메모리가 먼저 바닥났음
    • 대체로 동의하고 하나 더 보태고 싶음
      표준 부재도 실제 SHTF 상황에서 사용성을 크게 떨어뜨릴 것 같음
      예를 들어 왜 meshstastic보다 meshcore를 써야 하는지조차 명확하지 않고, 그런 상황에서 LoRa 자체가 내 머릿속 우선순위가 될 것 같지도 않음
    • 센서 쪽을 만들고 싶다면 LoRaWAN을 보는 편이 나음
      Mikrotik 베이스스테이션에 Chirpstack 백엔드를 붙이면 되고, 이 조합은 상용 환경에서 아주 많이 검증됐음
    • SHTF가 뭔지 모르겠음

  • 이 클라이언트 앱이 아직도 클로즈드소스인가
    나라면 그 시점에서 바로 탈락이고, 이런 일이 벌어진 것도 전혀 놀랍지 않음
    이걸로 끝나지도 않을 것 같음

    • https://github.com/zjs81/meshcore-open
      이제 닫힌 클라이언트는 더 이상 필요 없음
    • 어디서든 쓰고 싶은 base-station radio용으로, 매우 모바일 친화적인 오픈소스 self-hosted 클라이언트를 직접 개발하고 있음
      MQTT, community observers, bots, webhooks 등도 지원하고, 라디오에 묶이지 않은 일상용 클라이언트가 필요해서 시작했는데 지금은 파워 유저용 동반 클라이언트로 꽤 완성도가 올라감
      라디오 API와 펌웨어는 오픈되어 있고, 다른 선택지가 매우 많고 때론 클로즈드소스 옵션보다 기능적으로 더 낫기까지 하니, 돈을 벌기 위해 일부 소프트웨어를 닫는 선택 자체에는 별 반감이 없음
      https://github.com/jkingsman/Remote-Terminal-for-MeshCore
    • 아직도 클로즈드소스라는 걸 알고 꽤 놀랐고, 아마 바뀌지도 않을 것 같음
      우리 지역 메시도 지난주에 meshcore를 시험 중이었는데, 이걸로 내 관심은 사실상 사라짐

  • YouTube에서 Andy Kirby를 본 적 있는데, 영상이 너무 자극적이고 과장되고 클릭베이트처럼 보여서 그 사람을 프로젝트 운영과 연결해서 보게 됐고, 그때부터 meshcore에 정이 떨어졌음
    이번 일은 그때의 직감이 맞았다는 느낌을 줌

  • 지금 상황을 보면, .io 사이트에는 "MESHCORE" 로고가 있고 .co.uk 사이트에는 "MESHCORE(tm)" 로고가 걸려 있음
    [1]: https://meshcore.io
    [2]: https://meshcore.co.uk

  • 이 프로젝트를 써본 적도 없고 관련자도 모름
    그런데 누군가가 "전부 AI로 다시 쓰겠다"는 식으로 나올 때마다 결국 큰 진상으로 드러나는 경우가 너무 자주 보여서 흥미로움
    물론 이 사람만 그런 건 아닐 수 있고, 내가 뒷배경을 다 아는 것도 아니라 이 글 전체를 신뢰할 수 있는지는 판단 못 하겠음
    그래도 내 작은 표본에서는 신호 대 잡음비가 꽤 좋다고 느낌

  • Would you trust AI generated mesh firmware?
    AI 생성 코드의 신뢰성을 걱정하기엔 정작 자기들 코드 품질부터 너무 낮아서 황당함
    자동화 테스트도 없고, 테스트를 추가하려는 시도도 무시해 왔음
    [0] https://github.com/meshcore-dev/MeshCore/pull/925
    [1] https://github.com/meshcore-dev/MeshCore/issues/1059
    [2] https://github.com/meshcore-dev/MeshCore/pull/1065
    [3] https://github.com/meshcore-dev/meshcore.js/pull/11
    마지막으로 봤을 때도 입력 검증이 거의 없어서 지구 범위를 벗어난 GPS 좌표 같은 말도 안 되는 값도 그대로 브로드캐스트할 수 있었고 코드가 그걸 그냥 받아들였음
    신생 프로젝트가 허덕이는 건 이해하지만, 코드 품질에는 투자하지 않으면서 그 문제로 남을 훈계하는 태도는 거슬림
    MeshCore를 좋아하고 싶지만 운영 방향이 자꾸 발목을 잡고, 내가 아는 주요 운영자 둘인 Scott Powell과 Liam Cottle도 펌웨어 위에 클로즈드소스 비즈니스 레이어를 얹어 사업화하려는 중이라 인센티브가 뒤틀려 보임
    오픈코어 모델 자체가 문제라는 뜻은 아니지만, 이 경우엔 오픈소스 대안을 눌러두고 자기네 유료 클로즈드소스 제품을 밀게 만들 수 있음
    게다가 미국용으로 권장하는 MeshCore 브로드캐스트 설정은 불법인데, 몇 달 전에 Liam과 Scott에게 메일을 보냈더니 무시당했음
    [4] https://github.com/meshcore-dev/MeshCore/issues/945

    • #4는 정말 짜증남
      나도 ham이긴 하지만 규정 한 번 어겼다고 FCC에 바로 신고할 타입은 아니고, 다만 왜 그런 규정이 있는지 모르거나 신경도 안 쓰는 태도는 걱정됨
      우선 규정 해석이 맞는지는 확신 못 하지만, 일단 맞다고 치면 스레드에 있는 다른 사람들도 대부분 그 해석이 맞다고 전제하는 듯했음
      내 눈엔 "우리가 규정을 어기고 있으니 바꿔야 한다"에 대해 "Seattle에선 불편하니 안 함", "Boston에서도 잘 안 되니 불가"라고 답하는 식으로 읽혔음
      이건 규정이 자발적 선택 사항인 것처럼 굴 일이 아님
      공용 전파 자원을 쓰는 사람들은 대체로 법을 지키고 있고, 프로젝트가 합법적으로 쓰면 성능이 나빠진다면 그건 프로젝트 쪽이 고쳐야 할 문제임
      이런 이유 때문에 나이 든 ham들이 왜 점점 예민해지는지도 이해는 감

    • Would you trust AI generated mesh firmware?
      이 질문 자체도 유도 질문임
      지금까지 제시된 구체적 사실은 그가 단지 Claude Code를 썼다는 것뿐임
      그래서 테스트는 통과하는지, 보안 결함이 생겼는지, 테스트되지 않은 회귀가 들어갔는지가 더 중요함

    • 지구 범위를 벗어난 GPS 좌표가 구체적으로 어떤 값을 말하는지 궁금함
    • 애초에 프로토콜에 GPS 송수신이 왜 필요한지도 잘 모르겠음

    • It's ridiculous to me that they're concerned about the trustworthiness of AI-generated code when their code quality is so low.
      동의하지만, 그래도 지금 코드는 최소한 구조는 어느 정도 말이 됨
      AI가 끼면 정말 slopaghetti가 될 가능성이 큼
      자동화 테스트를 안 받는 것도, 지금 이슈 540개와 PR 270개가 열려 있고 리뷰 인력이 두 명뿐이라면 어느 정도 계산이 나옴
      이런 드라마까지 겹쳤으니 외부 기여를 더 못 믿게 될 수도 있음
      코드를 실제로 머지시키고 싶다면 Evo 포크 쪽 사람에게 가는 게 더 나을 수 있고, 내가 듣기로는 관심 있는 PR을 머지시키는 방법은 GitHub 이슈에 충분한 좋아요를 모으거나 Discord에 들어가 직접 요청하는 것뿐임
      [1] https://github.com/mattzzw/MeshCore-Evo

  • 개발에 AI를 쓰는 건 좋아하고, 현대 개발에서 중요하다고도 봄
    다만 AI와 사람이 직접 쓴 코드는 분명 차이가 있으니 그 사실은 반드시 공개해야 함

    • 그뿐만이 아님
      프로젝트의 큰 부분을 vibe coding으로 만들었다면, 그 사람이 정말로 DCO에 동의할 권리가 있는지, 그리고 해당 코드베이스의 LICENSE로 배포할 권한이 있는지도 애매해짐
    • 맞는 말임
      프로그램이 뭘 하는지 파악하는 것 자체도 쉽지 않지만, 사람이 쓴 코드라면 적어도 어떤 의도는 있었다고 볼 수 있음
      AI로 만든 코드는 왜 그게 들어갔는지조차 알 수 없음
      인터넷 곳곳에 vibe coded 프로젝트를 올리면서도 처음엔 그런 사실을 숨기고 그냥 "내가 만들었다"고 말하며 칭찬은 다 가져가는 경우가 너무 많음
      그러다 나중에 자기는 아무것도 쓰지 않았고 어떻게 동작하는지도 모른다고 밝혀지면, 그제야 "AI 쓰는 건 문제없다"고 넘어가려 함
      하지만 AI를 도구로 쓰는 것과, 이해도 없이 그대로 복붙하고 전부 자기 공처럼 포장하는 건 전혀 다른 일임
답변달기