아내가 내가 새로 산 암호화 무전기를 만지작거리는 걸 보더니 뭔 데 쓰는 거냐고 물었다.

“상상해 봐,” 내가 말했다. “내 폰에서 메시지를 입력해서 너한테 보내면, 그게 바로 네 폰에 뜬다고 생각해 봐. 즉시!”

아내는 감동하지 않았다.

“정전이든 뭐든 전화망이 끊겨도 쓸 수 있어… 심지어 사회가 붕괴해도.” 그래도 반응이 없었다.

“우리가 서로 무전 거리에 없어도, 이웃들 무전기로 이루어진 메시 네트워크를 통해 메시지를 전달할 수 있어. 근데 걱정 마! 무전기가 우리 메시지를 종단간 암호화하니까 아무도 내용을 볼 수 없어.” 이쯤 되니 아내는 방을 나가버렸다.

아내는 정말 멋진 사람이지만, 솔직히 말해 ‘암호화된 오프그리드 메시징에 대한 열정’은 그중 하나가 아니었다.

내가 아내에게 그토록 열심히 설명하던 기술은 바로 MeshCore였다.

tl;dr - 그래서 총평은?

결론부터 보고 싶다면 요약을 보면 된다.

MeshCore란?

MeshCore는 저렴한 장거리(LoRa) 무전기에서 동작하는 소프트웨어다. LoRa 무전기는 경로가 얼마나 트여 있느냐에 따라 수 마일까지 송신할 수 있다. 아마추어 무전기와 달리 미국에서는 LoRa 주파수로 송신하는 데 면허가 필요 없으므로, 누구나 LoRa 무전기를 사서 바로 대화를 시작할 수 있다.

MeshCore는 단순히 무전으로 메시지를 주고받는 것 이상이다. 이름에 들어간 ‘mesh(메시)’는 MeshCore 사용자들이 메시 네트워크를 이루기 때문이다. Alice가 친구 Charlie에게 메시지를 보내고 싶지만 Charlie가 무전 거리를 벗어나 있다면, 근처에 있는 또 다른 MeshCore 사용자인 Bob을 거쳐 메시지를 전달할 수 있다. 그러면 Bob이 그 메시지를 Charlie에게 전달한다.

오프그리드 통신에 대한 나의 꿈

나는 종말론적인 프레퍼까지는 아니지만, 장기 정전이나 식량 부족, 가뭄 같은 현실적인 재난 상황에 대비해 계획을 세우는 편이다.

MeshCore를 처음 들었을 때, 근처에 사는 친구들에게 기기를 몇 개 나눠주면 비상시에 서로 연락할 수 있겠다는 생각이 들었다. 혹시 서로 무전 거리를 벗어나더라도 이웃 몇 명을 더 참여시키면 될 것 같았다. 그러면 정전이나 전화망 마비에도 끄떡없는 메시징 네트워크를 만들 수 있을 테니까.

왜 Meshtastic이 아니라 MeshCore인가?

MeshCore는 Meshtastic이라는 기술이 대중화한 아이디어를 더 새롭게 구현한 것이다.

나는 Tyler Cipriani의 2022년 블로그 글에서 Meshtastic을 처음 알게 됐다. 아이디어 자체는 멋지다고 생각했지만, 당시 Tyler의 결론은 Meshtastic이 버그가 많고 일반인이 쓰기에는 너무 어렵다는 것이었다.

나는 둘 중 하나도 써본 적이 없어서 MeshCore나 Meshtastic 어느 쪽에 특별한 애착이 있는 건 아니다. Mastodon에서 팔로우하는 몇몇 사람들이 MeshCore에 열광하는 걸 보고 한번 써보기로 했다. 대부분의 MeshCore 호환 기기는 Meshtastic과도 호환되니, 한쪽을 먼저 시험해 보고 나중에 다른 쪽도 쉽게 해 볼 수 있다.

Meshtastic과 MeshCore의 차이를 깊이 이해하고 있는 건 아니지만, 내가 파악한 바로는 MeshCore의 핵심 차별점은 대역폭을 아끼는 데 있다. Meshtastic은 사용자가 밀집한 지역에서 확장성 문제가 생긴다고 한다. Meshtastic 프로토콜이 MeshCore보다 훨씬 수다스러워서, 그 잡담이 전파를 가득 메워 메시지 전달을 방해한다는 불만이 종종 보인다. MeshCore는 네트워크 수다를 최소화해 이 문제를 해결하려 한다.

나는 무선 전문가가 아니다

이쯤에서 밝혀두자면, 나는 무선 쪽 사람은 아니다.

LoRa 커뮤니티의 많은 사람들은 아마추어 무선이나 다른 종류의 무선 통신 경험이 있는 무선 애호가인 것 같다.

나는 기술에 밝은 소프트웨어 개발자이지만 무선 통신에 대해서는 아는 게 전혀 없다. 혹시 내가 무선 전송에 대해 잘못 이해하고 있다면 그 때문이다.

Heltec v3: MeshCore를 가장 저렴하게 시작하는 방법

MeshCore 펌웨어는 수십 종의 기기에서 동작하지만, 공식 웹사이트에서는 특히 세 가지 기기를 추천한다. 그중 가장 저렴한 것이 Heltec v3다. 나는 27달러짜리를 두 개 샀다.

Heltec v3를 USB-C 포트로 컴퓨터에 연결하고 MeshCore 웹 플래셔로 최신 펌웨어를 올렸다. 기기는 “Heltec v3”, 모드는 “Companion Bluetooth”, 버전은 “v1.9.0”을 선택했다. 새로 설치하는 거라 “Erase device”를 눌렀다.

그리고 MeshCore 웹 앱을 이용해 Heltec을 블루투스로 휴대폰과 페어링했다.

MeshCore 웹 앱에서 헤매기

좋아, 휴대폰과 MeshCore 기기를 페어링했는데… 이제 뭘 해야 하지?

앱은 온보딩 측면에서 별로 도움이 되지 않았다.

“Map”을 눌러 근처에 다른 MeshCore 사용자가 있는지 확인해 봤다.

어라, 뉴질랜드 지도다. 나는 미국에 사는데 좀 의외였다. 지도를 이리저리 둘러봐도 어디에도 MeshCore 활동이 보이지 않아서, 이 지도가 도대체 뭘 하는 건지 알 수가 없었다.

뉴질랜드 지도를 보니 나라마다 LoRa에 쓰는 무선 주파수가 다르다는 게 떠올랐다. 앱이 기본 위치를 뉴질랜드로 잡는다면, 방송 주파수도 뉴질랜드 기준으로 잡혀 있을 가능성이 높았다.

설정에 들어가니 “Radio Settings” 항목이 있었는데, 드롭다운일 줄 알고 눌렀더니 숫자를 직접 입력하라고 했다. 그러다 희미하게 보이는 “Choose Preset” 버튼을 발견했는데, 거기에는 “커뮤니티에서 제안한” 국가별 프리셋이 나열돼 있었다. 뭔지 하나도 모르겠지만 커뮤니티 의견에 토를 달 수 있나. 나는 “USA/Canada (Recommended)”를 선택했다.

설정에서 기기 이름도 바꿀 수 있길래 유용해 보였다:

내 주변에는 다른 MeshCore 사용자가 없는 것 같았는데, 예상한 일이었다. 그래서 Heltec을 두 개 산 것이었다.

오래된 휴대폰과 두 번째 Heltec v3로 같은 과정을 반복했지만, 서로를 인식하지 못했다. 나중에야 두 번째 기기의 주파수를 미국용으로 설정하는 걸 깜빡했다는 걸 깨달았다. MeshCore 앱이 초기 온보딩을 좀 더 신경 써줬으면 하는 이유가 또 하나 생긴 셈이다.

좋아, 이제 드디어 서로를 인식한다! 두 기기 모두 공개 채널에 메시지를 올릴 수 있게 됐다.

다이렉트 메시지 기능 파악하기

친구들과 MeshCore로 대화하려면 대화 전체를 공개 채널에 뿌리고 싶지 않으니, 다이렉트 메시지를 테스트해 볼 차례였다.

공개 채널에서 연락처를 보고 다이렉트 메시지를 보낼 수 있을 거라 예상했지만 할 수 없었다. 이름을 눌러도 아무 반응이 없었다. “Participants” 화면이 있긴 한데, 거기서 할 수 있는 건 차단뿐이고 다이렉트 메시지는 보낼 수 없었다.

이상한 설계 선택처럼 느껴졌다. MeshCore 사용자가 공개 채널에 글을 올렸는데 왜 그 사람에게 바로 말을 걸 수 없는 걸까?

나중에야 “Advert”를 해야 한다는 걸 알아냈다. “Zero Hop”, “Flood Routed”, “To Clipboard” 세 가지 옵션이 있는데, 무슨 뜻인지 하나도 몰랐다. “flood”는 좀 무례하게 들리고 “Zero Hop”은 우아하게 들려서 “Zero Hop”을 눌렀다.

좋다! 이제 기기 2에서 기기 1이 보인다. 기기 2에서 기기 1에게 인사를 건네보자.

어라, 뭐가 잘못된 거지? 기기 2에서도 “Advert”를 해야 하나?

그래, 해봤더니 짜잔! 이제 메시지가 간다.

꽤 답답한 사용자 경험이다. 양쪽에서 모두 advert를 해야 한다면, 왜 MeshCore는 핸드셰이크가 절반만 끝난 상태에서 메시지를 보내게 내버려 둔 걸까?

“Advert”가 내 기기의 공개 키를 알리는 과정이라고 짐작은 되지만, 왜 이걸 미리 명시적으로 해야 하는지 이해가 안 된다. 공개 채널에 글을 올리거나 누군가에게 다이렉트 메시지를 보내려 할 때 MeshCore가 암시적으로 처리하면 안 되는 걸까?

어쨌든 공개 채널이든 DM이든 혼자서 대화할 수 있게 됐다. 다음으로 넘어가자!

MeshCore 기기를 더 주문하다

Heltec v3 보드는 MeshCore를 실험해 보기에는 좋았지만, 실제 상황에서는 비실용적이었다. 별도의 전원이 필요하고 페어링할 휴대폰도 있어야 했다. USB-C to USB-C 케이블로 휴대폰에서 전원을 공급해 보려고 했지만 Heltec 보드는 휴대폰 전원으로는 켜지지 않았다. 진짜 비상 상황에서는 실패 지점이 너무 많다.

MeshCore 웹사이트에서는 다른 두 가지 호환 기기를 추천하고 있어서, 그 두 가지를 주문했다. Seeed SenseCAP T-1000e(40달러)와 Lilygo T-Deck+(100달러)였다.

SenseCAP T-1000e 테스트하기

T-1000e는 Heltec v3보다 확실히 나아졌다. 배터리와 안테나가 내장된 일체형이라 더 단순하고 견고하게 느껴졌다. 가볍기도 해서 배낭에 넣어두면 있는지도 모를 정도였다.

짜증나게도 T-1000e는 전용 USB 케이블을 써서, 내가 쓰는 일반적인 USB 케이블로는 충전이나 펌웨어 플래싱을 할 수 없었다:

Heltec은 웹 플래셔를 썼지만, T-1000e는 소스에서 직접 플래싱해 보기로 했다:

git clone https://github.com/meshcore-dev/MeshCore.git

# Latest firmware version at the time I tested.
FIRMWARE_VERSION='companion-v1.9.0'
git checkout $FIRMWARE_VERSION

나는 Nix를 쓰는데, 저장소에 default.nix가 있어서 direnv로 의존성이 자동으로 설치됐다. 이어서 T-1000e 펌웨어를 이렇게 플래싱했다:

# Specify the device settings, from variants/t1000-e/platformio.ini.
DEVICE_SETTINGS='t1000e_companion_radio_ble'
pio run \
  --environment $DEVICE_SETTINGS \
  --target upload \
  --upload-port /dev/ttyACM0

그다음 T-1000e를 휴대폰과 페어링했는데, Heltec을 쓸 때와 거의 같았다. 다른 점이 있다면 T-1000e에는 화면이 없어서 블루투스 페어링 비밀번호가 기본값인 123456이라는 것뿐이었다. 블루투스 거리 안에 있는 누구든 쉽게 내 T-1000e를 탈취해 내 메시지를 다 읽을 수 있다는 뜻인가?

게다가 T-1000e는 전원을 끌 수도 없는 것 같았는데, 방송용 기기로서는 바람직하지 않다. 제조사는 그냥 며칠 동안 충전하지 말고 두면 배터리가 방전된다고 안내한다.

업데이트: MeshCore 기여자 Frieder Schrempf가 이 문제를 수정했다. 커밋 07e7e2d에 포함됐으며, MeshCore 펌웨어 v1.11.0에 들어갔다. 이제 T-1000e 상단의 버튼을 길게 누르면 전원을 끌 수 있다.

Lilygo T-Deck 테스트하기

이제 Lilygo T-Deck을 테스트할 차례였다.

이건 MeshCore 중에서도 처음부터 가장 기대했던 부분이었다.

T-1000e 같은 기기를 기술에 익숙하지 않은 친구들에게 건네준다면 실제 비상 상황에서 잘못될 일이 너무 많았다. “어, MeshCore 앱이 없다고? 어, 휴대폰이랑 페어링이 안 된다고? 어, 휴대폰 배터리가 다 됐다고?”

T-Deck은 2000년대 Blackberry처럼 생겼다. 올인원 기기라 휴대폰 페어링이나 앱 설치가 필요 없어 엄청 간단해 보였다. 몇 개 사서 친구들에게 나눠주고 싶었다. 사회가 붕괴하고 도시가 혼란에 빠져도, 우리는 2005년인 양 종말용 해커 Blackberry로 계속 대화할 수 있을 테니까.

이건 Blackberry가 아니다

T-Deck 전원을 켜자마자 환상이 깨졌다. 이건 전혀 Blackberry가 아니었다.

참고로 이게 2003년의 Blackberry 모습이다:

T-Deck의 소프트웨어 경험을 논하기 전에, 하드웨어 자체가 너무 크고 투박하다. 22년 전에 만들던 하드웨어 제품의 품질조차 따라가지 못하는 걸까?

처음부터 T-Deck은 쓰기가 불편했다. 기기 중앙의 작고 허술한 썸휠을 눌러 UI를 탐색하는데, 반응이 제멋대로라 스크롤의 절반은 씹혔다.

좋은 소식은 터치스크린이 있다는 것이다. 하지만 터치스크린도 내 터치의 절반을 놓쳤다:

UI 요소를 “클릭”하는 방법이 세 가지나 있다. 트랙볼을 누르거나, “Enter” 키를 누르거나, 화면을 탭하는 것이다. 특정 UI 요소가 어느 입력을 기대하는지는 세 가지를 다 시도해 봐야 알 수 있다!

참고: Lilygo T-Deck+를 DFU 모드로 전환해 플래싱하기

T-Deck+를 재플래싱하는 방법을 찾는 것 자체가 어려웠다. Jeff Geerling의 긴 영상을 하나 찾았는데, 거기서 그는 재플래싱 방법을 찾는 데 얼마나 오래 걸렸는지 답답해하더니… 정작 어떻게 했는지는 설명하지 않았다!

내게 통했던 방법은 다음과 같다:

1. T-Deck의 USB-C 연결을 해제한다.
2. T-Deck 전원을 끈다.
3. USB-C 포트를 통해 T-Deck을 컴퓨터에 연결한다.
4. 중앙의 썸휠을 길게 누른다.
5. 기기 전원을 켠다.

혼란스럽게도 기기가 DFU 모드에 들어갔다는 표시가 전혀 없다. 화면이 켜지지 않는다는 사실이 어찌 보면 표시라면 표시다. 내 시스템에서는 dmesg 로그에 연결이 표시되기도 했다.

T-Deck으로 메시징하기

T-Deck 탐색 방법을 겨우 익힌 뒤 메시징을 시도했는데, 여전히 당황스러운 경험이었다. 예를 들어, 지금 내가 어떤 화면에 있는지 맞춰 보라:

“공개 채널 채팅”이라고 맞췄다면 나보다 훨씬 잘 맞춘 것이다. 내 눈에는 이 화면이 뭘 하는 건지 전혀 알 수 없었기 때문이다. 심지어 채팅 메시지가 표시될 때도 어렴풋이 채팅 인터페이스처럼 보일 뿐이었다:

그 외에도 혼란스러운 UX를 많이 겪었지만, 일일이 다 적자니 너무 지루하다.

결론적으로 비극적인 점은, 이건 비상시에 믿고 쓸 수 있는 기기가 아니라는 것이다. UX 곳곳에 함정과 막다른 골목이 너무 많아 사람들이 걸려 넘어지고 결국 나와 연락조차 할 수 없게 될 것이다.

현장에서 MeshCore 테스트하기

T-Deck이 내 마음을 아프게 했지만, 그래도 다른 기기로는 MeshCore를 써보고 싶었다.

책상 위에서 몇 센티미터 떨어진 거리가 아니라, 실제 환경에서 이 기기들이 어떻게 동작하는지 확인할 필요가 있었다.

1마일 거리에서 T-1000e에서 Heltec으로

먼저 T-1000e를 약 1마일 떨어진 친구 집으로 가져가 집 서재에 둔 Heltec으로 메시지를 보내봤다. 전송은 실패했고, 두 기기는 그 거리에서는 서로를 전혀 인식하지 못하는 것 같았다.

뭐, 그럴 수 있다. 나는 교외 주택가에 살고, 우리 집과 친구 집 사이에는 집과 나무, 차들이 가득하니까.

몇 블록 거리에서 T-1000e에서 Heltec으로

다음에 차를 타고 집에서 멀어질 때 T-1000e를 가지고 나가 서재에 둔 Heltec v3로 메시지를 보내봤다.

한 블록 거리: 메시지 성공.

세 블록 거리: 여전히 성공.

다섯 블록 거리: 실패.

그리고 그날 늦게 집에 돌아올 때까지 집에 둔 기기에는 다시 연결할 수 없었다.

몇 블록 거리에서 T-Deck에서 T-1000e로

혹시 문제는 Heltec일까? 계속 Heltec을 집에 두고 테스트했는데, Heltec v3는 안테나가 특히 약하다는 글을 봤다.

이번에는 T-1000e를 집에 두고 T-Deck을 가지고 나가 다시 시도했다.

약 다섯 블록 거리까지는 T-1000e로 메시지를 성공적으로 보낼 수 있었지만, 그 이상은 모두 실패했다.

리피터가 필요한 걸까?

MeshCore 리피터는 WiFi 확장기와 비슷하다. MeshCore 메시지를 수신해 재방송함으로써 도달 범위를 넓혀준다.

리피터가 MeshCore에서 ‘메시’를 만드는 요소다. 리피터들이 서로에게 메시지를 보내며 당신의 MeshCore 메시지를 더 먼 거리까지 운반한다.

기술적으로 꽤 멋진 리피터들이 나와 있다. 태양광으로 동작하고 내장 배터리가 있어 독립적으로 구동되며, 햇빛이 없어도 며칠은 버틸 수 있다.

문제는 리피터가 얼마나 차이를 만드는지 알 수 없다는 것이었다. 안테나가 강한 리피터라면 메시지를 잘 방송하겠지만, 그게 내 문제를 해결해 줄까? 내 T-Deck이 여섯 블록 떨어진 T-1000e에도 메시지를 못 보내는데, 리피터까지는 어떻게 도달하라는 걸까?

이쯤 되니 MeshCore에 대한 열정이 식었고, 얼마나 개선될지도 모르는데 100달러를 더 써서 집에 방송 장치를 설치하고 싶지 않았다.

MeshCore 소스 코드 살펴보기

MeshCore의 펌웨어는 오픈소스라서, T-Deck의 사용자 경험을 개선할 수 있는 부분이 있는지 살펴봤다.

소스 코드를 보고 처음 놀란 점은 자동화된 테스트가 하나도 없다는 것이었다. 나는 간단한 유닛 테스트를 작성했지만, 두 달이 지나도록 MeshCore 팀에서는 아무도 답을 주지 않았다.

가볍게 훑어본 바로는 코드베이스가 지저분하긴 해도 심각할 정도는 아니었다. C++로 작성돼 있고 대부분의 클래스 표면적이 넓어서 private이 아닌 함수와 필드가 20개 이상씩 있었지만, 임베디드 소프트웨어 프로젝트에서는 흔히 보는 모습이다.

또 다른 코드 스멜은 내 유닛 테스트가 호출하는 toHex 함수였다. 이 함수는 raw 바이트를 16진수 문자열로 인코딩한다.

// Create a test input.
uint8_t input[] = {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF};
char output[HEX_BUFFER_SIZE(input)];

// Call the function we're testing.
Utils::toHex(output, input, sizeof(input));

// Verify that toHex encoded our bytes correctly.
EXPECT_STREQ("0123456789ABCDEF", output);

MeshCore의 toHex 구현은 암호학과 전혀 상관없는 함수인데도 두 개의 암호화 라이브러리 헤더에 의존하고 있었다. 각 컴포넌트마다 유닛 테스트를 작성했다면 피할 수 있었을 불필요한 결합이다.

사소하지만 또 하나 불만이었던 건 코드 스타일 규칙이 일관되지 않다는 점이었다. 누군가 이미 저장소에 있는 .clang-format 파일을 쓰자고 제안했지만, 메인테이너는 “커밋할 때 본인 IDE가 불필요한 변경을 만들지 않도록만 하세요”라는 말과 함께 이슈를 닫아버렸다.

왜? 왜 2025년에 중괄호 위치를 로컬 스타일에 맞추려고 고민해야 하는 걸까? 그냥 포매터를 설정하면 지루한 스타일 문제는 신경 쓰지 않아도 될 텐데.

잠깐, MeshCore가 오픈소스가 아니라고?

원래 T-Deck UI를 이해하려고 MeshCore 소스를 파보기 시작했는데, 관련 코드를 전혀 찾을 수 없었다. MeshCore 안드로이드 앱이나 웹 앱의 소스도 찾을 수 없었다.

그러다 깨달았다. 전부 클로즈드 소스였다. 공식 MeshCore 클라이언트 구현은 모두 클로즈드 소스이자 독점 소프트웨어였다.

뭐라고! 분명 오픈소스라고 광고했잖아! 어떻게 날 속일 수가 있지?

그리고 MeshCore 웹사이트를 다시 보니, 어디에도 “오픈소스”라고 적혀 있지 않았다.

너무나 오픈소스스러운 것이라 당연히 그런 줄 알았다. 하지만 MeshCore의 핵심 부분이 독점 소프트웨어라는 걸 알게 되니 크게 실망했다.

오픈소스 클라이언트가 없으면 MeshCore는 내게 맞지 않는다.

업데이트(2026-01-13): 이제 비공식 오픈소스 클라이언트가 생겼다.

나는 오픈소스 광신자는 아니고 소프트웨어가 독점이어도 괜찮다고 생각한다. 하지만 오프그리드 통신의 핵심은 탈중앙화와 기술의 자유에 있는 만큼, 클로즈드 소스 솔루션에는 동의할 수 없다.

MeshCore 생태계의 일부는 확실히 오픈소스이며 관대한 라이선스로 제공되지만, 핵심인 T-Deck 펌웨어와 웹 앱, 모바일 앱은 모두 클로즈드 소스이자 독점이다. 내가 Heltec v3와 T-1000e에 플래싱한 펌웨어는 오픈소스지만, 무전기를 사용하는 데 썼던 모바일 및 안드로이드 앱(클라이언트)은 클로즈드 소스이자 독점이었다. 내가 보기에는 개발용 CLI 외에는 오픈소스 MeshCore 클라이언트가 없다.

요약

마지막 생각

나는 여전히 MeshCore라는 아이디어 자체는 정말 좋아하지만, 아직 비상 상황에서 통신 수단으로 쓰기에는 실용적이지 않다고 느낀다. 소프트웨어가 너무 쓰기 어렵고, 다섯 블록(약 0.3마일) 이상 떨어진 곳으로는 메시지를 보낼 수 없었다.

나중에 MeshCore를 다시 써볼 의향은 있지만, 오픈소스 클라이언트와 사용성 개선을 기다리고 있다.

MeshCore에서 좋았던 점

• 대기업 인프라에 의존하지 않고 문자 메시지를 보낼 수 있다는 점이 정말 멋지다.
• 재난 대비를 좋아하는 내 취향을 제대로 저격하는 개념이다.
• MeshCore는 다양한 저가 기기에서 동작하며, 그중 많은 기기가 Meshtastic에서도 쓸 수 있다.
• 활발하고 열정적인 커뮤니티가 있다.

MeshCore에서 아쉬웠던 점

• 모든 공식 MeshCore 클라이언트가 클로즈드 소스이자 독점 소프트웨어다.
  • 업데이트(2026-01-13): 이제 비공식 오픈소스 클라이언트가 생겼다.
• 사용자 경험이 너무 취약해서 비상시에 믿고 쓰기 어렵다. 특히 MeshCore를 처음 쓰는 사람과 연락해야 할 때는 더 그렇다.
• 대부분의 하드웨어가 블루투스로 휴대폰과 페어링한다고 가정하는데, 이는 실패 지점과 복잡성을 크게 늘린다.
• 유일한 공식 독립형 기기는 T-Deck+뿐인데, 나는 쓰기 혼란스럽고 답답했다.
• 문서로 된 시작 가이드가 없다.
  • FAQ는 있지만 정리되지 않은 세부 정보들의 뒤죽박죽 모음이다.
  • 괜찮은 비공식 입문 영상이 있긴 하지만, 나는 텍스트 문서를 선호한다.