파일럿 vs. 엔지니어: UAV 조종이 내가 코드를 작성하는 방식을 바꾸다

Source: Dev.to

전기·전자공학 전공 학생이자 UAV 조종사 면허를 가진 나는 두 개의 화면 앞에서 수많은 시간을 보냈다. 하나는 비행 제어 로직을 작성하는 IDE이고, 다른 하나는 하늘에 떠 있는 그 로직을 모니터링하는 지상 관제소(GCS)다.

여정 초기에 나는 Gazebo 시뮬레이션이 완벽하면 실제 비행도 완벽할 것이라고 생각했다. 틀렸다. 책상에서 현장으로 옮겨가면서 “완벽한 코드”가 현실의 “혼돈”을 고려하지 않으면 실패할 수 있다는 것을 배웠다.

관성은 단순 변수 그 이상

시뮬레이터에서는 관성이 물리 엔진 안의 숫자에 불과하다. 현장에서는 갑작스러운 돌풍 때문에 VTOL이 전환 중에 추가로 1미터 정도 표류하는 이유가 된다. 조종사가 되면서 “예측” 코드를 작성하게 되었다. 이제 LQR이나 PID 컨트롤러를 구현할 때

[ u(t)=K_p,e(t)+K_i\int e(t),dt+K_d,\frac{d}{dt}e(t) ]

단순히 이득값 ((K_p, K_i, K_d))만 보는 것이 아니라, 항공기가 물리적으로 어떻게 버티거나 순간적으로 자리 잡을지를 시각화한다.

“만약에” 사고방식 (Fail‑safes)

프로그래머는 if‑else 문을 생각한다. 조종사는 “지금 링크가 끊어지면 어떻게 할까?”를 생각한다. 이 관점은 내 코드를 보다 견고한 페일‑세이프 메커니즘으로 전환시켰다. NavGuard 레이어가 GPS 스푸핑 시도를 감지하면, 코드는 밀리초 단위로 판단해야 한다: IMU를 신뢰할 것인가, 아니면 비상 착륙을 시작할 것인가? 조종사는 “똑똑한” 코드가 아니라 “예측 가능한” 코드를 원한다.

// Simple PID controller example
double u(double e, double integral, double derivative,
         double Kp, double Ki, double Kd) {
    return Kp * e + Ki * integral + Kd * derivative;
}

환경에 대한 존중

전자전(EW), 신호 간섭, 센서 노이즈는 눈에 보이지 않는 적이다. 이러한 “보이지 않는” 요인들이 내 비행 임무를 방해하는 것을 보면서 항공 전자공학에 대한 관심이 커졌다. 이제 나는 단순히 데이터를 처리하는 것이 아니라, 그 데이터를 의심하는 코드를 작성한다.

결론

조종사가 된 덕분에 나는 더 나은 엔지니어가 되었다. 이는 운영자를 향한 공감을 심어주었기 때문이다. 더 나은 펌웨어를 작성하고 싶다면 IDE를 떠나 비행 현장으로 나가라. 코드가 바람과 싸우는 모습을 보면 교과서 어느 장보다 많은 것을 배울 수 있다.