19.8.3. 실무 개발 시 흔히 발생하는 오류 및 해결 방안(Troubleshooting)

19.1 단원부터 19.8 단원까지, 우리는 uORB 아키텍처의 설계, 구현, 다중 인스턴스 스케일링, 그리고 런타임 VFS 모니터링까지 현존하는 대부분의 코어 기술을 습득했다. 이론상으로는 이 모든 코드와 매뉴얼이 완벽하다면 드론은 단 한 번의 에러도 없이 창공을 갈라야 한다.

하지만 냉혹한 로보틱스 실무(Practice)의 현장에서는, 개발자가 짜놓은 C++ 코드가 제아무리 우아해도 리얼타임 운영체제(RTOS)의 타이밍(Timing) 제약과 메모리 물리계의 한계에 부딪히며 상상조차 하지 못했던 온갖 미지의 버그를 맹렬하게 토해낸다. 이 단원은 피투성이가 된 수많은 PX4 선배 개발자들이 기체를 수십 번 바닥에 꽂아가며 뼈저리게 터득해 낸 **‘uORB 3대 치명적 런타임 재플린(Zeppelin) 버그’**의 해결(Troubleshooting) 백서이다.

1. 실무의 늪: 문법이 아닌 문맥의 오류

앞서 말했듯 컴파일러(GCC)가 잡아내는 붉은색 문법(Syntax) 에러는 아주 쉽고 친절한 에러다. 코드를 고치면 그만이기 때문이다. 진정한 공포는 에러 한 줄 발생시키지 않고 컴파일도 100% 성공하며 start 명령어도 우아하게 먹히는데, 기체가 비행 도중 조용히 미쳐버리는 문맥(Context)과 타이밍의 오류이다.

이어지는 단원들에서는 여러분이 개발 랩(Lab) 현장에서 밤을 새우게 만들 가장 대표적인 3가지 악성 uORB 런타임 버그의 징후와 그 물리적 절제(Cut-off) 수술법을 공개한다.

1. 침묵의 블랙박스 (19.8.3.1 단원): “내 퍼블리셔 데몬은 완벽하게 데이터를 쏘고 있는데, 비행을 마치고 SD 카드의 ULog를 꺼내보니 내 데이터만 통째로 하얗게 누락되어 있다.” 이 황당한 증상의 99%는 타임스탬프(timestamp)를 구조체에 수동으로 꽂아 넣는 코드를 까먹었을 때 발생하는 로거(Logger) 데몬의 시스템적 보이콧 현상이다.
2. 질식하는 CPU (19.8.3.2 단원): “SITL을 띄우고 내 구독자 모듈을 실행시켰더니 방 안의 노트북 쿨러가 여객기 이륙하는 소리를 내며 돌고 전체 시스템 틱(Tick)이 박살 난다.” 이것은 구독자 단에서 px4_poll()의 타임아웃 인자를 0이나 무한대로 잘못 주어, 스레드가 100%의 CPU를 무한 데드 루프로 갉아먹고 있는 참사이다.
3. 데이터의 환각 (19.8.3.3 단원): “구독자가 받은 GPS 데이터가 가끔 한 번씩 위경도 숫자가 깨져서 순간 이동을 한다.” 이것은 퍼블리셔가 데이터를 메모리에 적고(Write) 있는 바로 그 찰나의 순간에, 구독자가 락(Lock) 없이 그 메모리를 동시에 읽어가며(Read) C++ 구조체 바이트가 반으로 찢어져 버린 끔찍한 데이터 경쟁(Data Race) 참사이자 동기화(Synchronization)의 실패이다.

이 세 가지 악성 종양의 본질을 꿰뚫고 제거하는 능력을 확보해야만, 비로소 당신은 자기가 짠 모듈을 남의 기체에 자신 있게 이식(Porting)할 수 있는 진정한 시니어(Senior) 아키텍트로 인정받을 수 있다.