제5부 운영체제 다루기

5.3 OTA 업데이트와 원격 관리

3.3에서 App Lab의 Remote Management 개념을 개관했다면, 이 장은 그것을 실전으로 이어받아 실제로 OTA(Over-The-Air) 업데이트를 수행하고, 원격에서 보드를 관리하며, 업데이트가 실패했을 때 무엇을 해야 하는지를 다룬다.

5.3.1 App Lab Settings — 원격 관리의 중심

3.3.5에서 App Lab Settings 페이지의 다섯 섹션(App Lab 자체 정보, Device Details, System Info, Operating system, Network Connections)을 개관했다. 이번 장에서 실전으로 쓸 곳은 그중 둘이다 — System Info의 Update 버튼(소프트웨어 업데이트, 5.3.3)과 Operating system의 Flash Board 버튼(업데이트가 도저히 안 풀릴 때의 최후 수단, 5.3.4).

한 가지 자동화 동작을 먼저 알아 둘 필요가 있다 — SBC 모드로 부팅한 App Lab은 부팅할 때마다 보드와 의존성을 최신 버전으로 자동 갱신한다. 상시 인터넷에 연결된 데스크톱 용도라면 편리하지만, 오프라인·에어갭 환경이나 부팅 시간이 중요한 현장이라면 이 자동 갱신이 예상치 못한 지연이나 실패로 이어질 수 있다는 점을 염두에 둔다(3.3.6).

5.3.2 Network Mode — 원격에서 App Lab 접속하기

보드가 USB로 컴퓨터에 연결되어 있지 않아도, 같은 로컬망에 있다면 App Lab이 mDNS로 보드를 찾아 Network 태그를 붙여 보여준다. 클릭해서 Linux 비밀번호를 입력하면 USB 연결 없이 원격으로 App Lab 전체 기능(코드 편집, App 배포, Settings 접근)을 그대로 쓸 수 있다.

Network Mode는 최초 설정 때 자동으로 켜지지만, 터미널(SSH 또는 ADB 셸)에서 직접 제어할 수도 있다.

arduino-app-cli system network-mode enable    # 켜기
arduino-app-cli system network-mode disable   # 끄기
arduino-app-cli system network-mode status    # 현재 상태 확인

무인 배포 현장에서 보드가 부팅 후 자동으로 원격 관리 가능한 상태가 되도록 하려면, 이 값이 enable로 유지되는지 배포 전에 확인해 둔다.

5.3.3 소프트웨어 업데이트 절차

5.3.3.1 GUI 경로 — App Lab이 자동으로 물어볼 때

보드가 인터넷에 연결되면 App Lab이 자동으로 업데이트를 확인한다. 업데이트가 있으면 대화상자가 표시되며, Install(다운로드·설치)이나 Skip(미루기) 중 고를 수 있고 Show update details로 무엇이 바뀌는지 미리 볼 수 있다. 다운로드 도중 연결이 끊겨도 재접속 시 이어받기가 가능하다(resumable) — Wi-Fi가 불안정한 현장에서 특히 유용한 특성이다.

수동으로 지금 바로 확인하고 싶다면 Settings > System Info의 Update 버튼을 누른다.

5.3.3.2 CLI 경로 — 원격·무인 업데이트

SSH로 접속한 상태(5.2)나 자동화 스크립트에서는 arduino-app-cli로 업데이트를 직접 트리거할 수 있다.

arduino-app-cli system update

옵션:

옵션	동작
`--only-arduino`	Arduino 관련 패키지만 업그레이드(Debian 시스템 패키지는 변경하지 않음)
`--yes`	모든 확인 프롬프트를 자동 승인 — 무인 실행에 필요

무인 스크립트라면 다음처럼 쓴다.

arduino-app-cli system update --yes

이 명령은 OS와 Arduino 소프트웨어 구성 요소 양쪽의 패키지 목록을 갱신하고 사용 가능한 업데이트를 내려받아 적용한다. 내부적으로는 Debian 공식 저장소와 Arduino 전용 저장소(apt-repo.arduino.cc)에서 PGP 서명·TLS로 검증된 패키지를 받아온다 — 일반 sudo apt update && sudo apt upgrade와 겹치는 부분이 있지만, arduino-app-cli system update는 Arduino 쪽 구성 요소까지 함께 관리해 주는 상위 명령이라고 볼 수 있다.

⚠️ 업데이트 후 재부팅 동작에 주의: 업데이트가 재부팅을 유발하는 경우, 5.1에서 다룬 "표준 종료 명령은 클린 셧다운 후 자동 재기동된다"는 이 보드 특유의 동작이 그대로 적용된다. 무인 원격 업데이트 스크립트를 작성할 때는 재부팅 이후 보드가 다시 네트워크에 연결되기까지의 시간을 충분히 확보해야 한다.

5.3.4 업데이트 실패·롤백 대응

정직하게 밝혀야 할 부분: UNO Q 공식 문서에서, 업데이트가 실패했을 때 이전 버전으로 자동으로 되돌아가는 A/B 파티션식 원자적 롤백(atomic rollback) 메커니즘이 존재한다는 근거는 찾지 못했다 — 확인 필요. 현재 확인되는 것은 "다운로드가 끊겨도 이어받는다(resumable)"는 수준의 복원력이지, 설치까지 끝난 뒤 문제가 생겼을 때 소프트웨어적으로 자동 되돌리는 기능은 아니다. 그러니 실무에서는 아래와 같은 단계적 대응이 현실적이다.

재시도한다. 네트워크 문제로 실패했다면 재접속 후 업데이트를 다시 시도하는 것만으로 해결되는 경우가 많다(resumable 특성).
공간을 확보하고 재시도한다. 스토리지 부족으로 실패했다면(5.4 참고), 오래된 App 이미지를 정리한다.

   arduino-app-cli system cleanup

이 명령은 더 이상 쓰지 않는 App 이미지를 지워 디스크 공간을 확보한다 — 특히 여러 번 App을 빌드·재빌드한 보드에서 효과가 크다.

최신 펌웨어인지 확인한다. 오래된 펌웨어 버전이 원인인 사례가 보고돼 있으므로(5.1.5.2 참고), Settings에서 현재 버전을 확인한다.
그래도 안 되면 재설치(Flash)한다. App Lab이 여전히 보드를 인식한다면 Settings > Operating system > Flash Board로 새 이미지를 내려받아 설치한다. 이때 "Preserve user data during the board flashing process"를 체크하면 /home/arduino(사용자 데이터 파티션)는 보존한 채 시스템 파티션만 새로 기록한다 — 사실상 이것이 UNO Q에서 가장 확실한 "정상 상태로 되돌리기" 수단이다.
App Lab이 보드를 전혀 인식하지 못하면 — 부팅이 안 되거나 네트워크에서 검색되지 않는 최악의 경우 — Arduino Flasher CLI로 EDL(Emergency Download Mode)에 진입시켜 복구한다.

   # EDL 핀을 점퍼로 단락한 뒤 USB-C 연결
   ./arduino-flasher-cli flash latest --preserve-user

EDL 진입·핀 위치 등 구체 절차는 5.4.4에서 자세히 다룬다.

정리하면, UNO Q의 실질적인 "롤백"은 소프트웨어 자동 복원이 아니라 재플래시(가능하면 사용자 데이터 보존)라는 물리적 안전망에 가깝다. 상용 배포 전이라면 이 전제를 팀에 명확히 공유해 둘 필요가 있다.

5.3.5 원격 무인 관리 실무 팁

여기부터는 검증된 절차라기보다 필자의 견해다 — 근거와 함께 제시한다.

소수 보드로 먼저 검증한다. 필드에 여러 대를 배포했다면, 업데이트를 전체에 동시 적용하기 전에 한두 대에서 먼저 arduino-app-cli system update를 실행해 문제가 없는지 확인하는 편이 안전하다 — 근거: OTA 실패 시 자동 롤백이 없다는 점(5.3.4)을 고려하면, 실패의 파급 범위를 줄이는 것이 최선의 방어다.
주기적 업데이트를 cron이나 systemd timer로 자동화하는 것은 일반 Debian 관행이며 기술적으로는 가능하지만, UNO Q에서 공식적으로 권장·검증된 패턴은 아니다 — 확인 필요. 자동화한다면 반드시 실패 시 알림(예: 5.1에서 다룬 journalctl 로그를 rsyslog로 원격 서버에 전송)을 함께 구성해, 업데이트가 조용히 실패한 채 방치되는 상황을 피한다.
업데이트 직전 스냅숏 대신 데이터 백업을 정례화한다. 파일시스템 스냅숏 기능은 확인되지 않으므로(5.4), 중요한 데이터는 업데이트 전 scp/rsync로 별도 백업해 두는 편이 안전하다(5.2).

5.3.6 다음으로

업데이트·재빌드가 반복되면 eMMC 공간이 빠르게 줄어든다 — 다음 5.4에서 저장 공간 구조와 정리 전략, 그리고 방금 언급한 --preserve-user·--root-size 플래그를 자세히 다룬다. 업데이트나 재부팅이 계속 실패하는 경우의 체계적인 진단은 부록 A.1(트러블슈팅)도 함께 참고한다.