AEGLOSLAB Arduino UNO Q 완전 가이드

제5부 운영체제 다루기

5.1 Debian 부팅·서비스 관리

UNO Q의 QRB2210(MPU)은 전원이 들어오면 자동으로 Debian Linux를 부팅한다. 이 장은 그 부팅 과정을 단계별로 살펴보고, Debian 표준 서비스 관리 도구인 systemd·systemctl로 UNO Q 특유의 서비스(예: arduino-router)를 다루는 법, 그리고 journalctl로 부팅·시스템 로그를 확인하는 법을 다룬다. 마지막으로 이 보드에서 특히 주의해야 할 종료·재부팅의 함정을 정리한다.

이 장은 MPU(QRB2210) 쪽 Debian 운영체제만 다룬다. STM32U585(MCU) 쪽 Zephyr 펌웨어의 리셋·재시작은 별도 메커니즘이며 3.2·3.4에서 다룬다.

5.1.1 부팅 과정 개요

UNO Q는 전원 버튼이 없어도 전원이 들어오면 자동으로 부팅한다 — 공식 사용자 매뉴얼은 "전원 버튼을 누를 필요가 없다, 전원이 공급되면 자동으로 부팅한다"고 명시한다. 부팅은 크게 전원 시퀀싱 → 초기 부트로더 → 커널 → systemd → 서비스 기동의 순서로 진행된다.

전원 인가 USB-C 5V 또는 VIN 7-24V PMIC(PM4125) 시퀀싱 3.3V 안정화 후 1.8V 인가 SPL·U-Boot 초기 부트로더 Linux 커널 부팅 systemd 초기화 unit·target 순차 기동 네트워크·App Lab 서비스 기동 STM32 ready 신호 (전원 인가 후 약 20초)

전원 시퀀싱 세부(3.3V 레일이 안정된 뒤 약 1ms 후 1.8V 레일이 켜지는 순서 등)는 하드웨어 관점에서 2.4(전원 설계와 소비전력)에서 다룬다. 이 장에서는 그 이후, 즉 QRB2210이 커널을 적재하고 사용자 공간(userspace)을 구성하는 과정에 집중한다.

5.1.1.1 초기 부팅 로그를 직접 보는 법 — Hardware Debug UART

SSH나 ADB가 아직 기동되지 않은 아주 초기 단계(SPL, U-Boot 로그, 전원 협상·하드웨어 초기화 메시지)를 보려면 JCTL1 커넥터의 Hardware Debug UART를 쓴다. 이 인터페이스는 SoC의 메인 콘솔(TTY)에 직접 연결되며, 115200bps · 1.8V 로직 레벨로 동작한다. 1.8V 신호이므로 3.3V USB-TTL 변환기를 그대로 연결하면 보드가 손상될 수 있다 — 반드시 1.8V 호환 변환기(예: DSD Tech SH-U09C5급)를 써야 한다. 로그인 후에는 App Lab에서 설정한 Linux 계정으로 셸에 들어갈 수 있어, 네트워크가 전혀 기동되지 않는 상황의 최후 진단 수단이 된다.

이 방법은 평소 개발에는 거의 쓸 일이 없다 — 부팅 자체가 실패하거나 네트워크·ADB가 모두 막힌 극단적 상황을 위한 것이다. 일상적인 셸 접근은 5.2(SSH)이나 ADB를 쓴다.

5.1.1.2 전원 버튼

UNO Q에는 재부팅 전용 전원 버튼이 있다. 공식 문서에 명시된 동작은 다음 하나뿐이다.

  • 길게 누름(5초 이상): 보드의 Linux 쪽이 재부팅된다.

짧게 눌렀을 때의 동작은 공식 문서에 명시돼 있지 않다 — 확인 필요. 전원을 완전히 차단하는 스위치가 아니라는 점에 유의한다(부팅은 전원 인가로만 자동 시작되며, 버튼은 재부팅 트리거일 뿐이다).

5.1.2 systemd 서비스 관리 기초

Debian trixie 기반의 UNO Q는 다른 현대 Debian 계열과 마찬가지로 systemd를 초기화 시스템(init system)으로 쓴다. 서비스(데몬)는 unit이라는 단위로 관리되며, 가장 흔한 것이 .service 유닛이다.

명령동작
systemctl status <unit>현재 실행 상태·최근 로그 일부 확인
sudo systemctl start <unit>지금 즉시 시작(재부팅 후에는 자동 시작 안 됨)
sudo systemctl stop <unit>지금 즉시 중지
sudo systemctl restart <unit>중지 후 재시작
sudo systemctl enable <unit>부팅 시 자동 시작하도록 등록
sudo systemctl disable <unit>부팅 시 자동 시작 해제
sudo systemctl enable --now <unit>등록과 동시에 즉시 시작

start/stop과 enable/disable은 서로 다른 축이라는 점이 자주 혼동된다 — start는 "지금" 상태를, enable은 "다음 부팅부터" 상태를 결정한다. 상용 배포 전에는 필요한 서비스가 enabled 상태인지 반드시 확인한다.

5.1.3 UNO Q 고유 서비스 다루기

App Lab이 설치하는 서비스 중 실전에서 마주칠 일이 많은 두 가지로 systemctl의 실제 쓰임을 익혀 둔다.

arduino-router — MPU(Linux)와 MCU(Zephyr) 사이, 그리고 Linux 프로세스끼리의 RPC 통신을 중계하는 백그라운드 데몬으로 systemd 서비스로 자동 실행된다. 상태 확인·재시작·로그 추적의 기본 패턴은 다음과 같다.

systemctl status arduino-router          # 상태 확인
sudo systemctl restart arduino-router    # 통신이 멈춘 것 같을 때 재시작
journalctl -u arduino-router -f          # 실시간 로그 추적

일반적인 사용에서는 arduino-router를 직접 건드릴 필요가 없다 — 이 명령들은 App 간 통신이 응답하지 않거나 MCU와의 연결이 이상할 때 진단용으로 쓴다. 이 서비스의 내부 구조(MessagePack RPC, Unix 소켓, LPUART1 전송 등)와 유닛 파일을 직접 편집해 verbose 로깅을 켜는 절차는 3.4(Bridge — MPU-MCU 통신의 내부)에서 깊이 다룬다.

rsyslog — 시스템 로거로, 대부분 기본 설치돼 있다. 설치·기동 여부를 systemd 3종 명령으로 확인·조치하는 흐름이 전형적이다.

dpkg -l | grep rsyslog          # 설치 여부 확인
sudo systemctl status rsyslog   # 실행 상태 확인
sudo systemctl enable rsyslog   # 꺼져 있다면 부팅 시 자동 시작 등록
sudo systemctl start rsyslog    # 지금 즉시 시작

원격 로그 서버로 로그를 전달하도록 설정을 바꾼 뒤에는 sudo systemctl restart rsyslog로 반영한다. 원격지 무인 보드의 상태를 중앙에서 감시하고 싶을 때(5.3.5에서 다시 언급) 이 조합이 출발점이 된다.

5.1.3.1 보안 관점에서 서비스 끄기 — adbd 예시

USB-ADB로 보드를 프로그래밍할 필요가 더는 없는 "완성된 제품" 단계에서는 adbd(ADB 데몬) 자체를 꺼서 USB를 통한 셸 접근 경로를 차단할 수 있다.

sudo systemctl stop adbd       # 지금 중지
sudo systemctl disable adbd    # 다음 부팅부터 자동 시작 안 함

되돌리려면:

sudo systemctl enable adbd
sudo systemctl start adbd

이렇게 하면 이후 보드에 접근하는 유일한 방법은 SBC 모드로 모니터·키보드·마우스를 직접 연결하는 것뿐이다(또는 SSH가 켜져 있다면 SSH — 5.2). 무인 배포용 보드에서 공격 표면을 줄이는 실전 기법이다.

5.1.4 부팅·시스템 로그 확인 — journalctl

systemd의 로그는 바이너리 저널(journal)에 쌓이며 journalctl로 조회한다.

명령용도
journalctl -xe최근 로그를 설명(explanation) 포함해 보기 — 문제 직후 첫 확인용
journalctl -f실시간 팔로우(follow) — tail -f처럼 계속 흘러가는 로그를 지켜봄
journalctl -b이번 부팅의 로그만 — 부팅 원인·순서 확인에 유용
journalctl -b -1직전 부팅의 로그 — 예기치 않은 재부팅 원인 추적
journalctl -u <unit>특정 서비스(unit)의 로그만 필터링
journalctl -u <unit> -f특정 서비스 로그를 실시간으로
dmesg | less커널 부팅 메시지·하드웨어 인식 로그(드라이버 문제 진단에 유용)

로그인·재부팅 이력만 빠르게 감사(audit)하고 싶다면 last 명령이 유용하다. /var/log/wtmp를 읽어 사용자명·접속 터미널(SSH 세션이면 pts/0 등)·접속 IP·로그인/로그아웃 시각·세션 길이를 보여주며, 시스템 재부팅 기록도 함께 남는다 — "누가 언제 접속했는가"와 "언제 재부팅됐는가"를 한 번에 확인하는 감사 도구다.

last

5.1.4.1 journal 디스크 사용량 관리

저널은 시간이 지나면 eMMC 공간을 차지한다. UNO Q의 eMMC는 유한하므로(5.4 참고) 필요하면 저널 크기를 제한한다.

journalctl --disk-usage           # 현재 저널이 차지한 용량 확인
sudo journalctl --vacuum-size=200M  # 200MB로 축소(오래된 로그부터 삭제)

이는 UNO Q 공식 문서에 명시된 절차는 아니며, Debian/systemd-journald 표준 옵션을 그대로 적용한 것이다 — 동작 자체는 검증된 표준 기능이지만 UNO Q에서의 기본 저널 보관 정책(용량 상한이 설정되어 있는지)은 별도로 확인하지 않았다.

5.1.5 종료와 재부팅 — 이 보드 특유의 함정

여기가 UNO Q에서 가장 자주 오해를 낳는 부분이다. 일반적인 Debian PC와 달리, UNO Q는 표준 종료 명령을 쓰면 시스템이 정상 종료된 뒤 자동으로 다시 켜진다. 이는 보드의 전원 관리 회로에 내장된 동작이다.

장기 보관·이동 위해 완전히 멈추고 싶다 재시작하고 싶다 목적이 무엇인가? sudo halt sudo reboot / shutdown now / poweroff halted 상태 유지 (네트워크 응답 없음, 전원은 유지) 클린 종료 후 자동 재기동

5.1.5.1 명령별 동작 비교

명령동작
sudo reboot의도한 대로 정상 재부팅
sudo halt권장 — 안전하게 정지시키고, 대부분의 펌웨어 버전에서는 halted 상태를 유지(자동 재시작 안 함)
sudo shutdown now / sudo shutdown -h now / sudo shutdown -P now / sudo poweroff클린 셧다운은 되지만, 보드의 자동 재시작 기능이 몇 초 뒤 다시 전원을 켠다

장기 보관이나 보드를 들고 이동할 때처럼 "완전히 멈춘 상태"가 필요하면 sudo halt를 쓴다.

sudo halt

실행 후:

  • SBC 모드(디스플레이 연결): 화면이 검게 변하면 halt 진행 중이라는 신호. 약 10초 더 기다린 뒤 전원을 분리해도 안전하다.
  • PC-호스트 모드(USB-C/ADB 또는 SSH, 디스플레이 없음): 명령 실행 후 10~15초 기다린 뒤 전원을 분리한다.

halted 상태에서는 SSH·App Lab 등 네트워크 접속에 응답하지 않는다 — 다시 쓰려면 전원을 완전히 껐다 켜야 한다. 전원 LED와 LED 매트릭스는 halt 이후에도 켜져 있을 수 있으니 그것만으로 상태를 판단하지 않는다.

5.1.5.2 halt인데도 자동 재시작되는 경우

일부 조건(전원 공급(PD) 기능이 있는 특정 USB-C 허브, 오래된 펌웨어, 특정 전원 소스 조합)에서는 sudo halt를 실행해도 몇 초 뒤 자동으로 재시작되는 사례가 보고돼 있다. 대응 순서:

  1. App Lab의 Settings > System Info에서 최신 펌웨어인지 확인하고 업데이트한다(5.3).
  2. 그래도 재시작되면, "shutdown indicator"(SBC 모드는 화면이 검게 변하는 시점, PC-호스트 모드는 명령 실행 직후)가 나타난 뒤 1~2초의 짧은 창 안에 전원을 물리적으로 분리해야 한다 — 시간 여유가 적으므로 실패하면 정상적인 재부팅 시퀀스로 넘어간다고 보면 된다.
  3. USB-C PD 허브가 원인으로 의심되면 컴퓨터에 직접 연결하거나, VIN 핀에 7-24V DC를 직접 공급하거나, 다른 허브/어댑터로 바꿔본다.

5.1.5.3 비상 전원 차단

정전 등으로 전원이 급작스레 끊기는 경우, eMMC 스토리지에는 데이터 손실을 줄이는 보호 장치가 있어 대부분 다음 부팅에서 정상 복구된다. 다만 저장되지 않은 작업은 잃을 수 있으므로, 상시 가동이 아니라 보드를 껐다 켜야 하는 상황이라면 가능한 한 sudo halt로 정상 종료하는 편이 안전하다.

문제가 계속되면 journalctl -b로 재부팅 후 로그를 확인해 원인을 추적한다.

5.1.6 다음으로

이 장에서 다룬 서비스·로그·전원 제어는 원격에서도 그대로 쓸 수 있다 — 다음 5.2에서 SSH로 원격 접속하는 법을, 5.3에서 App Lab 기반 OTA 업데이트를 다룬다. 저장 공간이 부족해 서비스가 죽거나 저널이 문제를 일으키는 경우는 5.4(eMMC·파일시스템)을 참고한다.