아내가 내가 새로 산 암호화 라디오를 만지작거리는 걸 보더니 뭘 하는 거냐고 물었다.

“상상해 봐”라고 내가 말했다. “내가 휴대폰으로 메시지를 입력해서 너한테 보내면, 그 메시지가 네 휴대폰에 바로 나타나는 거야. 즉시!”

아내는 감흥이 없었다.

“정전이든 사회 붕괴든 전화선이 끊겨도 작동해.” 그래도 반응이 없었다.

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

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

내가 아내에게 열심히 설명하던 기술은 물론 MeshCore였다.

요약 - 그래서 어땠나?

결론이 궁금하다면 요약을 확인하세요.

MeshCore란?

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

MeshCore는 단순히 라디오로 메시지를 보내는 것 이상이다. 이름에 들어간 ‘mesh’는 MeshCore 사용자들이 메시 네트워크를 이루기 때문이다. Alice가 친구 Charlie에게 메시지를 보내고 싶은데 Charlie가 자기 라디오의 도달 범위를 벗어나 있다면, 근처에 있는 또 다른 MeshCore 사용자 Bob을 거쳐 메시지를 전달할 수 있고, Bob이 그 메시지를 Charlie에게 전달한다.

내가 꿈꾸는 오프그리드 통신

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

MeshCore를 처음 들었을 때, 근처 친구들에게 기기를 몇 개 나눠줘 비상시에 연락할 수 있으면 좋겠다고 생각했다. 혹시 서로 전파가 닿지 않더라도 이웃 몇 명을 더 설득해 참여시키면 어떨까 싶었다. 그러면 정전이나 전화 불통에도 끄떡없는 메시징 네트워크를 만들 수 있을 테니까.

왜 Meshtastic이 아닌가?

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 기기를 페어링했는데… 이제 뭘 하면 되지?

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

근처에 다른 MeshCore 사용자가 있는지 보려고 “Map”을 눌러 봤다.

뉴질랜드 지도다. 나는 미국에 사는데 좀 의외다. 지도를 이리저리 살펴봐도 어디에서도 MeshCore 활동이 보이지 않아서 이 지도가 뭘 하려는 건지 모르겠다.

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

설정에 들어가 “Radio Settings” 항목을 봤는데, 드롭다운이 나올 줄 알고 눌렀더니 숫자를 직접 입력하라고 한다. 그러다 눈에 잘 안 띄는 “Choose Preset” 버튼을 발견했는데, 거기엔 “suggested by the community”라고 된 국가별 프리셋 목록이 있었다. 뭐가 뭔지 하나도 모르겠지만 커뮤니티 의견에 토를 달 이유가 있나. 나는 “USA/Canada (Recommended)”를 선택했다.

설정에서 기기 이름을 바꿀 수 있는 것도 보였는데, 유용해 보였다.

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

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

마침내 서로를 인식했다! 이제 두 기기 모두 공개 채널에 메시지를 올릴 수 있다.

다이렉트 메시지 알아내기

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

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

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

결국 “Advert”를 해야 한다는 걸 알아냈다. “Zero Hop”, “Flood Routed”, “To Clipboard” 세 가지 옵션이 있는데 뭔지 하나도 모르겠다. “flood”는 좀 무례하게 들리고 “Zero Hop”은 우아하게 들려서 “Zero Hop”을 눌렀다.

좋다! 이제 Device 2가 Device 1을 인식한다. Device 2에서 Device 1에게 인사를 건네보자.

어라, 뭐가 잘못된 거지? Device 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 펌웨어 v.1.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 생태계에서 아직 언급하지 않은 다른 요소는 리피터다.

MeshCore 리피터는 WiFi 확장기 같은 것이다. MeshCore 메시지를 수신해 재방송함으로써 도달 범위를 넓힌다.

리피터가 MeshCore에서 ‘mesh’를 만드는 요소다. 리피터가 다른 리피터에 메시지를 보내 당신의 MeshCore 메시지를 더 멀리 전달한다.

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

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

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

MeshCore 소스 코드 살펴보기

MeshCore 펌웨어는 오픈소스다, 그래서 T-Deck의 사용자 경험을 개선하기 위해 내가 할 수 있는 일이 있는지 살펴봤다.

소스 코드에서 첫 번째로 놀란 점은 자동화된 테스트가 전혀 없다는 것이었다. 나는 간단한 유닛 테스트를 작성했다, 그런데 MeshCore 팀에서는 두 달이 지나도록 아무도 내 제안에 답하지 않았다.

가볍게 둘러본 바로는 코드베이스가 지저분하긴 하지만 심각할 정도는 아니다. C++로 작성됐고, 대부분의 클래스가 20개가 넘는 non-private 함수와 필드를 가진 넓은 인터페이스를 갖고 있는데, 임베디드 소프트웨어 프로젝트에서는 흔히 보는 모습이다.

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

// 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 구현은 암호학과 전혀 관련이 없는 함수임에도 두 crypto 라이브러리의 헤더에 의존한다. 각 컴포넌트별로 유닛 테스트를 작성했다면 피할 수 있었을 불필요한 결합이다.

또 하나 사소한 불만은 코드에 일관된 스타일 규칙이 없다는 점이다. 누군가 이미 저장소에 있는 저장소에 이미 있는 .clang-format 파일을 사용하자고 제안했다, 하지만 관리자가 이슈를 닫았다. 안내 내용은 “Just make sure your own IDE isn’t making unnecessary changes when you do a commit.”였다.

왜? 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는 있지만 정리 없이 세부 정보만 모아 놓은 잡동사니 수준이다.
  • 괜찮은 비공식 소개 영상이 있긴 하지만, 나는 텍스트 문서를 선호한다.