19.9.1. 코딩 컨벤션(PX4 Coding Standards) 준수 확인 (make format)

비행 제어 소프트웨어는 인명과 직결되는 항공 우주 공학의 핏줄이다. 수십 개국의 언어와 억양을 가진 전 세계 수백 명의 오픈소스 개발자들이 하나의 거대한 PX4 리포지토리에 C++ 코드를 쏟아붓고 있기 때문에, 이 코드가 1인의 천재가 짠 것처럼 완벽한 형태학적(Morphological) 일관성을 유지하지 못하면 프로젝트는 금세 유지보수 불가능한 쓰레기장으로 전락해 버리고 만다.

이 파멸을 막기 위해 PX4 코어 유지보수 위원회(Maintainers)는 살벌할 정도로 엄격한 **‘PX4 Coding Standards’**라는 코드 문법 및 포맷 헌법을 세워두었다. 들여쓰기(Indentation)는 무조건 탭(Tab)이 아니라 스페이스 8칸이어야 하고, 포인터 캐스팅 괄호 뒤에 띄어쓰기를 넣으면 안 되며, 함수 선언 중괄호는 항상 다음 줄에서 시작해야 한다는 식의 무자비한 강제 조항들이다.

1. CI/CD 봇(Bot)의 단두대와 무자비한 반려(Reject)

만약 당신이 아무리 뛰어난 다중 인스턴스 핫스왑 알고리즘을 짰다고 해도, 포인터 별표(*)의 위치가 변수 쪽에 안 붙고 타입 쪽에 붙어있거나(int *a 대신 int* a 사용), 쓸데없는 빈 줄 끝에 스페이스 공백(Trailing Whitespace) 쓰레기가 남아있다면 어떻게 될까?

당신이 자랑스럽게 깃허브(GitHub)에 PR(Pull Request)을 날린 지 단 3초 만에, 깃허브 액션(GitHub Actions) 기반의 잔혹한 CI/CD 검열 봇(Astyle/Format Checker)이 붉은색 엑스(X) 표시를 띄우며 당신의 PR 코드를 시스템 병합 후보에서 걷어차 버릴 것이다. 심지어 인간 리뷰어(Reviewer)들은 당신의 코드가 무슨 일을 하는지 읽어보기도 전에 格式(Format) 불량을 이유로 매몰차게 PR 창을 닫아버린다.

2. 자동 세탁기 가동: make format

다행히도 당신이 이 수백 장짜리 코딩 컨벤션 율법을 눈 빠지게 외울 필요는 없다. PX4 소스 트리의 루트(Root)에는 당신이 짠 못생긴 우물 안 개구리식 코드를 단 한방에 전 세계 표준의 아름다운 비율로 강제 전신 성형수술 해주는 마법의 명령어가 숨통을 트여놓고 있다.

SITL을 빌드하듯 콘솔 창에서 PX4 최상위 디렉터리로 들어가 아래의 명령어를 무심하게 때려 보자.

cd ~/src/PX4-Autopilot
make format

명령이 타격되는 순간, Astyle (Artistic Style)이라는 C/C++ 포맷팅 파서 엔진이 굉음을 내며 깨어나 펌웨어 소스 트리 전체를 미친 듯이 크롤링(Crawling)한다. 그리고 당신이 대충 복붙해서 삐뚤빼뚤하게 박아넣은 px4_uorb_example.cpp 소스 코드를 후벼파서, 탭 문자를 파괴하고 공백을 재배열하며, 어긋난 중괄호를 전부 공식 교과서 포맷으로 억지로 잡아 뜯어 꿰매버린다.

10초쯤 뒤 명령어가 종료되고 git diff를 쳐보면, 당신은 스스로 짠 코드가 얼마나 엉망진창의 비율을 가지고 있었는지를 뼈저리게 확인하게 될 것이다. 깃허브에 내 소스 코드를 git push하기 전, 이 make format 세탁기를 한 번 돌려 반짝반짝하게 광을 내는 것은, 글로벌 항공 우주 오픈소스 생태계에 입장하는 개발자로서 지켜야 할 최소한의 샤워 의식이자 목욕 재계이다.