내 물건인데 내 마음대로 못 하는 기분
전동 킥보드를 타보신 분이라면 한 번쯤 이런 생각 해보셨을 거예요. “왜 최고 속도가 이렇게 묶여 있지?”, “앱 없으면 설정도 못 바꾸네”, “회사 서버 닫히면 이거 벽돌 되는 거 아냐?” 하드웨어는 분명 내가 돈 주고 샀는데, 그 안에서 돌아가는 소프트웨어는 제조사가 꽉 쥐고 있는 상황이죠.
한 개발자가 이 상황을 그냥 두지 않고, 자기 킥보드의 펌웨어를 통째로 분석해서 Rust로 새로 작성한 과정을 블로그에 공개했어요. 펌웨어가 뭐냐면, 컴퓨터로 치면 운영체제와 프로그램을 합친 것 같은, 기기 안의 작은 칩에서 돌아가는 소프트웨어예요. 킥보드의 경우 모터를 얼마나 세게 돌릴지, 배터리를 어떻게 관리할지, 계기판에 뭘 보여줄지가 전부 펌웨어가 결정하는 거죠.
이 글이 흥미로운 건 결과물보다 과정이에요. “리버스 엔지니어링”이라는 게 실제로 어떤 단계를 거치는지, 그리고 왜 하필 Rust를 골랐는지가 잘 드러나거든요.
1단계: 안에 뭐가 들었는지부터 알아내기
리버스 엔지니어링의 첫걸음은 물리적인 분해예요. 킥보드를 뜯어보면 보통 세 덩어리의 기판이 나와요. 모터 컨트롤러(모터에 전류를 보내는 파워 회로와 이를 제어하는 MCU), 배터리 관리 시스템(BMS라고 하는데, 배터리 셀 상태를 감시하고 과충전이나 과방전을 막는 회로), 그리고 핸들에 붙은 계기판이에요. 이 세 부분이 서로 케이블로 연결돼서 대화를 주고받고 있죠.
MCU가 뭐냐면, 마이크로컨트롤러라고 해서 CPU, 메모리, 입출력 핀이 한 칩에 다 들어간 작은 컴퓨터예요. 킥보드류에는 STM32나 GD32 같은 ARM Cortex-M 계열이 많이 쓰여요. 칩 표면에 적힌 부품 번호를 읽고 데이터시트를 찾으면, 어떤 핀이 뭘 하는지, 플래시 메모리가 몇 KB인지 같은 정보를 알 수 있어요.
그다음은 디버그 포트 찾기예요. 대부분의 MCU에는 개발 단계에서 쓰는 SWD나 JTAG이라는 디버그 인터페이스가 있어요. 제조사가 이걸 막아두지 않았다면(생각보다 안 막아둔 경우가 많아요), 몇 천 원짜리 ST-Link 같은 프로브를 연결해서 칩 안의 펌웨어를 통째로 읽어낼 수 있거든요. 이게 리버스 엔지니어링의 재료가 돼요.
2단계: 기계어 덩어리에서 의미 찾아내기
읽어낸 펌웨어는 그냥 바이너리 덩어리예요. 소스 코드도, 함수 이름도 없죠. 여기서 Ghidra 같은 디스어셈블러(기계어를 사람이 읽을 수 있는 어셈블리로 바꿔주는 도구)를 써요. 처음엔 수천 개의 이름 없는 함수만 보이는데, 실마리는 “주변장치 주소”에 있어요.
이게 뭐냐면, MCU에서는 GPIO 핀이나 UART 통신 같은 하드웨어 기능이 특정 메모리 주소에 매핑돼 있어요. 데이터시트를 보면 “UART1은 0x40013800번지”처럼 딱 정해져 있거든요. 그래서 코드에서 그 주소를 건드리는 함수를 찾으면 “아, 이 함수가 계기판이랑 통신하는 부분이구나”를 알 수 있어요. 이런 식으로 퍼즐을 하나씩 맞춰 가는 거예요.
또 하나 중요한 건 기판 사이의 통신 프로토콜이에요. 로직 애널라이저(신호선의 0과 1을 시간에 따라 기록해주는 장비)를 통신선에 물려놓고 실제로 오가는 패킷을 관찰하면, “이 바이트가 속도, 이 바이트가 배터리 잔량, 마지막은 체크섬”처럼 구조를 알아낼 수 있어요. 펌웨어 분석과 실제 신호 관찰을 교차 검증하면서 이해도를 높이는 거죠.
3단계: 왜 Rust로 다시 쓰나
원래 펌웨어는 거의 확실히 C로 작성돼 있었을 거예요. 임베디드 세계의 표준 언어니까요. 그런데 글쓴이는 Rust를 골랐어요. 이유는 몇 가지가 있어요.
첫째, 안전성이에요. 모터 제어 코드에서 버퍼 오버플로나 널 포인터 같은 버그가 나면 사람이 다칠 수 있잖아요. Rust는 이런 메모리 오류를 컴파일 시점에 잡아줘요. 둘째, 최근 임베디드 Rust 생태계가 정말 좋아졌어요. embedded-hal이라는 공통 인터페이스 덕분에 칩이 바뀌어도 코드 재사용이 쉽고, embassy라는 프레임워크를 쓰면 RTOS 없이도 async/await로 여러 작업(모터 제어, 통신, 계기판 갱신)을 동시에 깔끔하게 다룰 수 있어요. 셋째, probe-rs 같은 도구로 플래싱과 디버깅이 한 명령에 끝나서 개발 경험 자체가 C 툴체인보다 쾌적해요.
물론 함정도 있어요. 모터 제어에는 PWM 타이밍이나 인터럽트 처리처럼 하드웨어를 직접 만지는 부분이 많은데, 이런 곳은 결국 unsafe 블록을 써야 하고, 여기서 실수하면 Rust라도 못 지켜줘요. 그리고 벤더가 제공하는 C 라이브러리에 비해 Rust 크레이트가 지원 안 하는 주변장치가 있을 수 있어서, 레지스터를 직접 다뤄야 하는 경우도 생겨요.
업계 맥락: 내 기기를 내가 고치는 흐름
이 프로젝트는 혼자만의 취미 이상의 의미가 있어요. 최근 몇 년간 “수리할 권리(Right to Repair)” 운동이 커지면서, 제조사가 소프트웨어로 기기를 잠그는 것에 대한 반발이 강해졌거든요. 킥보드 쪽에서는 커스텀 펌웨어를 올리는 커뮤니티가 이미 활발하고, 3D 프린터의 Klipper나 Marlin, 드론의 Betaflight처럼 오픈소스 펌웨어가 원래 펌웨어를 대체한 성공 사례도 많아요.
Rust 쪽으로 보면, 리눅스 커널이 Rust를 받아들이고, 마이크로소프트나 구글이 시스템 코드를 Rust로 옮기는 흐름과 같은 선상에 있어요. “임베디드는 C만 된다”는 통념이 실제 프로젝트로 깨지고 있는 거예요.
한국 개발자에게 주는 시사점
한국에서도 전동 킥보드 공유 서비스가 많고, IoT나 로봇 스타트업이 늘고 있어서 임베디드 개발 수요가 꾸준해요. 웹 개발만 하다가 하드웨어 쪽에 관심 생긴 분이라면, 이 글은 좋은 로드맵이에요. “STM32 개발 보드 하나 사서 Rust로 LED 깜빡이기”부터 시작하면 이 글에서 다룬 과정을 작은 규모로 직접 따라 해볼 수 있어요.
다만 실제 킥보드로 하실 땐 주의하셔야 해요. 모터 제어 펌웨어를 잘못 짜면 급가속이나 브레이크 불능 같은 사고로 이어질 수 있고, 국내에서는 개인형 이동장치의 최고 속도가 법으로 정해져 있어서 제한을 푸는 건 법적으로 문제가 돼요. 배우는 건 좋지만 공도에서 타는 기기에 적용하는 건 다른 문제예요.
마무리
한 줄로 정리하면, “내가 산 기기의 소프트웨어를 내가 이해하고 다시 쓸 수 있다”는 걸 실제로 보여준 프로젝트예요. 리버스 엔지니어링은 특별한 천재만 하는 게 아니라, 데이터시트 읽기와 끈기로 되는 일이라는 것도요.
여러분은 어떠세요? 집에 있는 기기 중에 “이거 펌웨어 뜯어보고 싶다”는 생각이 드는 게 있나요? 그리고 임베디드에서 Rust가 C를 대체할 수 있을 거라고 보시나요?
🔗 출처: Hacker News