복잡한 추상화를 걷어내기: dRehmFlight가 보여주는 엔지니어링의 본질
엔지니어로서 연차가 쌓이다 보면, 우리는 필연적으로 ‘추상화(Abstraction)’ 와 애증의 관계를 맺게 됩니다. 클라우드 인프라든, 프론트엔드 프레임워크든, 혹은 임베디드 시스템이든, 우리는 밑바닥의 복잡성을 숨겨주는 도구들에 의존합니다. 하지만 그 도구가 ‘블랙박스’가 되어버리는 순간, 우리는 통제력을 잃습니다.
최근 Hacker News에서 화제가 된 dRehmFlight 프로젝트는 바로 이 지점을 파고듭니다. 수천 개의 파라미터로 가득 찬 기존의 상용 Flight Controller(FC) 소프트웨어에 지친 엔지니어들에게, 이 프로젝트는 “First Principles(제1원칙)” 로 돌아가자는 강력한 메시지를 던집니다.
오늘은 이 ‘미친’ 프로젝트가 왜 단순한 드론 취미를 넘어, 소프트웨어 엔지니어링 관점에서 훌륭한 사례 연구인지 뜯어보겠습니다.
1. 문제는 ‘설정’이 아니라 ‘제어’다
보통 드론을 만든다고 하면 Betaflight나 ArduPilot을 떠올립니다. 훌륭한 소프트웨어들이지만, 코드를 수정하기보다는 수백 개의 옵션을 ‘설정’하는 데 시간을 쏟게 됩니다. 만약 여러분이 일반적인 쿼드콥터가 아니라, 날개가 펄럭이는 Cyclocopter나 비대칭 VTOL 기체를 만들고 싶다면? 그때부터는 설정 지옥(Configuration Hell)이 시작됩니다.
Nick Rehm이 개발한 dRehmFlight 는 접근 방식이 다릅니다. 그는 Teensy 4.0/4.1 마이크로컨트롤러(600MHz ARM Cortex-M7)를 기반으로, 비행 제어 로직을 사용자가 직접 코딩하도록 유도합니다.
2. “I’m not a software guy”라는 거짓말
Hacker News의 한 유저는 Nick Rehm이 영상에서 “전 소프트웨어쟁이가 아닙니다(I’m not a software guy)“라고 말한 뒤, 곧바로 제어 이론 마스터클래스를 펼치는 아이러니를 지적했습니다. 저도 그 부분에서 웃음이 터졌습니다. 코드를 보면 알 수 있거든요. 그는 훌륭한 엔지니어입니다.
가장 인상적인 기술적 결정은 “Single File Architecture” 입니다.
- 관행: 보통 엔터프라이즈급 프로젝트나 ArduPilot 같은 오픈소스는 수백 개의 파일로 모듈화되어 있습니다.
- dRehmFlight: 핵심 로직을 의도적으로 하나의
.ino(Arduino) 파일에 몰아넣었습니다.
제가 CTO로서 코드 리뷰를 할 때 팀원이 2,000줄짜리 main.c를 가져오면 당장 리팩토링하라고 했을 겁니다. 하지만 이 프로젝트의 목적은 ‘교육’과 ‘접근성’ 입니다. 초보자가 파일 간의 의존성(Dependency)을 추적하느라 길을 잃지 않도록, Loop() 함수 안에서 센서 데이터를 읽고, PID 제어를 수행하고, 모터 믹싱(Mixing)을 하는 전 과정을 한눈에 보여줍니다.
이는 “목적에 부합하는 아키텍처가 최고의 아키텍처” 라는 사실을 상기시켜 줍니다. 과도한 클린 코드는 때로 진입 장벽이 됩니다.
3. 하드웨어 추상화의 힘: Control Mixing
이 프로젝트의 백미는 Control Mixer 부분입니다. 일반적인 FC는 ‘Quad X’, ‘Hexa’ 같은 프리셋을 선택합니다. 하지만 dRehmFlight는 사용자가 직접 수학적 매핑을 정의합니다.
// 예시: 기괴한 형태의 기체를 제어하는 로직이 단 몇 줄의 수식으로 표현됨
motor1 = throttle + pitch_PID + roll_PID - yaw_PID;
motor2 = throttle - pitch_PID + roll_PID + yaw_PID;
// ...이 단순함 덕분에, 아래 이미지와 같은 ‘Giant Spinning Drone’ 같은 괴작(?)도 탄생할 수 있었습니다. 기체 전체가 회전하여 양력을 얻으면서도, 상단 플랫폼은 역회전(de-spun)하여 카메라와 센서의 방향을 유지합니다. 이건 기존 상용 FC로는 구현하기 거의 불가능에 가까운 제어 로직입니다.
4. Hacker News의 반응: 천재와 광인 사이
HN 커뮤니티의 반응을 살펴보면 흥미로운 논쟁이 있습니다.
- “Lilienthal의 재림인가?”: 한 유저는 Nick Rehm을 초기 항공 개척자인 오토 릴리엔탈(Otto Lilienthal)에 비유했습니다. 릴리엔탈은 직접 만든 글라이더를 테스트하다 추락사했죠. Nick이 15미터 상공에서 테스트하는 것을 보고 “천재성과 광기는 종이 한 장 차이”라며 안전을 우려하는 목소리가 높습니다. 솔직히 저도 동의합니다. Fail-safe가 부족한 실험 기체는 언제든 흉기가 될 수 있으니까요.
- Companion Computer의 가능성: 또 다른 유저는 이 FC가 Raspberry Pi 같은 보조 컴퓨터와 연결되어 Computer Vision 을 수행하고, 제어 입력을 직접 주입(inject)하는 기능에 주목했습니다. 이는 단순한 RC 장난감이 아니라, 자율 비행 연구를 위한 가장 저렴하고 강력한 플랫폼이 될 수 있음을 시사합니다.
5. Verdict: 엔지니어라면 한 번쯤 봐야 할 코드
dRehmFlight는 상용 제품에 탑재될 만큼 안정적이거나 기능이 풍부하지는 않습니다. GPS Waypoint 비행이나 정교한 Fail-safe 기능을 원한다면 ArduPilot을 쓰세요.
하지만 “기계가 어떻게 움직이는지” 를 이해하고 싶다면, 그리고 남들이 만들어놓은 API 뒤에 숨는 것에 지쳤다면, 이 프로젝트는 최고의 교과서입니다.
Teensy 보드 하나와 몇 줄의 코드로 중력을 거스르는 경험. 이것이 우리가 처음에 엔지니어링을 사랑하게 된 이유 아니었나요?
References: