탈옥한 킨들에서 Rust와 Slint로 GUI 앱 돌리기 - 가장 느린 디스플레이에서 가장 빠른 언어로

전자책 리더에 GUI 프레임워크를 올린다고요?

킨들(Kindle)은 아마존이 만든 전자책 단말기예요. 책 읽으라고 만든 기기죠. 그런데 이 안에는 사실 리눅스가 돌고 있고, ARM 프로세서가 들어가 있어서 "제대로 마음먹으면 컴퓨터처럼 쓸 수 있는" 장치이기도 해요. 이번에 소개할 글은 그런 킨들을 탈옥(jailbreak)해서 Rust로 만든 GUI 앱을 올린 경험을 정리한 내용이에요.

탈옥이라는 말이 좀 무서울 수 있는데, 쉽게 말하면 "제조사가 막아둔 영역에 사용자가 자기 코드를 올릴 수 있게 해방시키는 작업"이에요. 킨들은 KUAL(Kindle Unified Application Launcher)이라는 비공식 런처와 KOReader 같은 대체 독서 앱이 활발한 커뮤니티가 있어서, 탈옥 자체는 비교적 잘 다져진 길이에요. 이번 글의 진짜 흥미로운 지점은 "그 위에 모던한 Rust GUI 프레임워크를 어떻게 올렸느냐"입니다.

Slint가 뭐길래

Rust 진영에는 GUI 프레임워크가 여러 개 있어요. egui, iced, Tauri, GTK 바인딩, Qt 바인딩 같은 것들이 있는데, 그중에 Slint는 좀 독특한 위치예요. 이게 뭐냐면, 임베디드 장치를 주 타깃으로 만들어진 GUI 툴킷이에요. 메모리 적게 쓰고, CPU 적게 쓰고, 작은 화면에 잘 맞춰지도록 설계된 거죠.

Slint는 자체 DSL(도메인 특화 언어)을 써서 UI를 선언적으로 작성해요. QML(Qt의 UI 언어)이랑 비슷한 느낌인데, 그게 Rust로 컴파일되는 구조예요. 그래서 React처럼 "상태가 바뀌면 UI가 자동으로 따라간다"는 패턴을 임베디드 환경에서도 쓸 수 있어요. 차 안의 인포테인먼트 시스템, 산업용 장비 디스플레이 같은 곳에서 이미 쓰이고 있는 진지한 프로젝트입니다.

가장 어려운 부분 - 전자잉크 디스플레이

킨들의 디스플레이는 전자잉크(E-ink)예요. 일반 LCD나 OLED랑은 작동 방식이 완전히 달라요. 어떻게 다르냐면, 일반 디스플레이는 1초에 60번씩 화면을 다시 그리는데(60Hz), 전자잉크는 한 번 그리면 전기를 안 줘도 그 상태로 유지돼요. 대신 갱신할 때 "깜빡"하면서 시간이 꽤 걸려요. 1초에 1~2번 정도 갱신하는 게 한계인 경우도 있죠.

그래서 일반적인 GUI 프레임워크는 킨들에서 잘 안 돌아가요. 마우스 커서가 부드럽게 움직인다든가, 애니메이션이 자연스럽게 흐른다든가 하는 걸 가정하고 만들어졌거든요. 전자잉크에선 그게 다 "잔상 폭탄"이 됩니다. 그래서 이 프로젝트의 핵심은 "Slint의 렌더링 출력을 어떻게 전자잉크에 맞게 조절하느냐"였어요.

글에서 다루는 접근법은 Slint를 소프트웨어 렌더링 모드로 돌려서, 출력 픽셀 버퍼를 직접 받아낸 다음, 그걸 킨들의 framebuffer 장치(/dev/fb0 같은 리눅스 디바이스 파일)에 써넣는 방식이에요. 그리고 갱신이 필요한 영역만 골라서 전자잉크 드라이버에 "여기 다시 그려줘" 신호를 보내는 거죠. 부분 갱신(partial refresh)과 전체 갱신(full refresh)을 적절히 섞어야 잔상도 안 생기고 반응 속도도 그럭저럭 유지돼요.

크로스 컴파일이라는 또 다른 산

킨들은 ARM 프로세서를 쓰는데, 우리가 평소에 개발하는 PC는 보통 x86_64(인텔, AMD)나 ARM64(애플 실리콘)예요. 그래서 "내 맥북에서 컴파일한 바이너리를 킨들에 그대로 올릴 수가 없는" 문제가 생겨요. 이걸 해결하는 게 크로스 컴파일(cross compilation)이에요.

Rust는 다행히 크로스 컴파일이 비교적 잘 되는 언어예요. rustup target add armv7-unknown-linux-gnueabihf 같은 명령어로 ARM용 타깃을 추가하고, 적절한 링커를 설정해주면 됩니다. 다만 킨들 펌웨어는 굉장히 오래된 glibc 버전을 쓰고 있어서, 최신 우분투에서 컴파일하면 "GLIBC_2.34 not found" 같은 에러가 뜨기 일쑤예요. 그래서 정적 링킹(static linking)을 하거나, 오래된 glibc 환경에서 빌드하는 도커 이미지를 따로 만들어야 하는 경우가 많죠.

비슷한 시도들 - 임베디드에서 Rust의 자리

임베디드 분야에서 Rust는 점점 자리를 잡고 있어요. embedded-hal 같은 표준 인터페이스가 정착되면서, STM32, ESP32, RP2040(라즈베리 파이 피코) 같은 마이크로컨트롤러에서도 Rust 코드가 활발하게 돌아가고 있거든요. GUI 쪽에서는 embedded-graphics 라이브러리가 작은 디스플레이용으로 많이 쓰이고, 더 본격적인 화면이 필요하면 이번 글처럼 Slint를 쓰는 흐름이에요.

C/C++로 임베디드 GUI를 만들면 LVGL이라는 라이브러리가 거의 표준이에요. Slint는 그 LVGL의 대안 포지션을 노리고 있는데, "메모리 안전성"이라는 Rust의 강점을 임베디드까지 끌고 온다는 게 큰 차별점이에요. 임베디드 코드는 한번 배포되면 업데이트하기 어려운 경우가 많아서, 메모리 버그 하나가 큰 문제가 되거든요. Rust가 그걸 컴파일 단계에서 막아준다는 게 진짜 가치 있는 부분이에요.

한국 개발자에게 주는 시사점

첫째, Rust를 "빠르고 안전한 백엔드 언어"로만 알고 있다면 임베디드 영역도 한번 들여다볼 만해요. WebAssembly, 게임 엔진, 임베디드, GUI까지 Rust의 적용 범위는 계속 넓어지고 있고, 회사에서 IoT 제품을 만든다거나 키오스크 개발 같은 일을 한다면 진지하게 검토할 가치가 있어요.

둘째, 전자잉크 디스플레이 같은 "특이한 하드웨어"를 다루는 경험은 의외로 시야를 넓혀줘요. 평소에 60Hz 모니터에서 React 컴포넌트 만들 땐 생각 안 하던 "갱신 비용"이라는 개념이 갑자기 중요해지거든요. 이런 제약 조건 안에서 사용성 좋은 UI를 만들어내는 훈련은 일반 웹/앱 개발에도 도움이 됩니다.

셋째, 사이드 프로젝트로 정말 재미있어요. 중고 킨들은 5만원 정도면 구할 수 있고, 탈옥 자료도 잘 정리돼 있어서 주말 프로젝트로 도전해볼 만해요. 결과물을 만들어서 자기 책상 위에 "내가 만든 대시보드 띄운 킨들"을 놓아두면 그 자체로 멋진 포트폴리오가 되죠.