21.10. 커스텀 모듈의 딥(Deep) 성능 분석, 프로파일링 및 GDB 트러블슈팅

아마추어 코딩과 범용 상용 항공 소프트웨어를 가르는 가장 큰 장벽은 ‘내 코드가 얼마나 빠른가(Performance)’, 그리고 **‘내 자원을 얼마나 적게 먹는가(Resource Footprint)’**를 수학적으로 증명할 수 있느냐에 달려 있다.

우리는 앞선 21.1장에서부터 21.9장에 걸쳐 완벽한 ’정답 위주’의 C++ 모듈 하나를 조립해 냈다.
“잘 돌아가네! 투하도 잘 되네!” 하고 기뻐하며 짐을 싸기엔 아직 이르다. 비행 제어 시스템의 진짜 적은 겉으로 드러나는 에러 로그가 아니라, 수백 마이크로초(us) 단위로 소리 없이 쌓여가는 **지연 라우팅(Latency Routing)**과 보이지 않는 곳에서 피를 흘리는 **메모리 누수(Memory Leak)**다.

1. 하위 1%의 병목(Bottleneck)을 찾는 여정

수억 원짜리 라이더(LiDAR)를 장착한 드론이 나무에 부딪혀 박살 났다고 가정해보자. 블랙박스를 뜯어보니 장애물 회피 모듈이 장애물을 보고 회피 명령을 내리기까지 단 2밀리초(ms) 늦었을 뿐이다. 그 2ms의 딜레이가 어디서 생겼을까? CPU가 느려서? 아니다. 개발자가 생각 없이 짜놓은 for 루프 하나, 혹은 습관적으로 찍어댄 PX4_INFO 한 줄이 다른 데몬들과 락 버퍼(Lock Buffer)를 다투느라 발생한 ‘병목(Bottleneck)’ 현상이다.

본 장(21.10장)에서는 우리가 작성한 코드를 가혹한 시험대 위에 올릴 것이다. 단순히 작동하는 것을 넘어, **“내 코드는 한 바퀴 도는 데 정확히 32us가 걸리며, CPU 점유율은 0.1%를 넘지 않는다”**고 숫자로 증명하는 딥(Deep) 프로파일링 기술을 배울 것이다.

우리가 해체해 볼 PX4의 치명적인 디버깅 무기들은 다음과 같다.

1. perf_counter API: 내 루프가 돌아가는데 걸린 시간(Latency)을 마이크로초(us) 단위로 도려내어 집계하는 실시간 스탑워치 기술. (21.10.1장)
2. top 커맨드와 RAM 점유율: 백그라운드 데몬화된 내 모듈이 픽스호크의 심폐 기능(CPU Load)과 램(Stack Memory)을 얼마나 좀먹고 있는지 해부하는 기술. (21.10.2장)
3. GDB 하드웨어 디버거: 기체가 수십 미터 상공에서 커널 패닉(Kernel Panic)을 일으키며 추락했을 때, 그 폭발 직전의 CPU 레지스터(Register) 상태를 멈춰 세워 범인(Faulting Instruction)을 색출하는 JTAG/SWD 하드웨어 디버깅 기법. (21.10.3장)

엔지니어의 직감이나 “잘 될 거야“라는 믿음은 다 쓰레기통에 버리자. 오직 터미널에 찍히는 차가운 숫자들만이 드론의 추락을 막을 수 있다. 가장 먼저, 내 코드의 실행 지연 시간(Execution Delay)을 발가벗기는 perf_counter의 칼날 속으로 21.10.1장에서 진입해 보자.