제5부 운영체제 다루기

5.5 전력·성능 관리

2.4에서 다룬 것은 보드가 몇 볼트·몇 암페어를 요구하는지, PMIC가 레일을 어떻게 만드는지 같은 하드웨어 전원 설계였다. 이 장은 그 위에서, 이미 전원이 들어온 UNO Q가 동작 중에 CPU 클록·발열·불필요한 소비전력을 어떻게 관리할지를 다룬다.

먼저 정직하게 밝혀야 할 점: UNO Q 전용 전력·성능 관리 가이드는 공식 문서에 따로 없다. 이 장의 상당 부분은 QRB2210이 표준 Linux ARM SoC이므로 일반적인 ARM SBC(라즈베리파이 등) 전력 관리 원칙이 원리상 적용된다는 전제로 구성했고, UNO Q에서 실제로 검증된 부분과 아직 확인하지 못한 부분을 절마다 구분해 표기한다.

5.5.1 CPU governor — 표준 Linux cpufreq 인터페이스

Linux 커널의 cpufreq 서브시스템은 CPU 코어별로 동작 주파수와 그 결정 정책(governor)을 /sys/devices/system/cpu/cpuN/cpufreq/ 아래 sysfs 파일로 노출한다. UNO Q 커뮤니티 포럼에도 이 표준 인터페이스가 그대로 존재함을 확인한 스크립트가 공유돼 있다 — 커뮤니티 방법(비공식)이지만, 표준 커널 기능이 이 보드에서도 동작한다는 사실 자체는 신뢰할 만하다.

현재 상태를 확인한다.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor         # 현재 governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq         # 현재 주파수(kHz)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors  # 이 보드에서 고를 수 있는 governor 목록

QRB2210은 쿼드코어이므로 코어 4개(cpu0~cpu3) 각각에 같은 확인·설정이 필요할 수 있다.

5.5.1.1 흔한 governor의 의미 (일반 ARM Linux 지식)

아래는 UNO Q에 국한된 내용이 아니라 리눅스 cpufreq의 일반적인 governor 종류다. UNO Q에서 실제로 어떤 governor를 지원하는지는 위 scaling_available_governors 명령으로 직접 확인하는 것이 가장 정확하다.

governor	동작
`performance`	항상 최고 클록 고정 — 지연시간이 중요한 실시간성 작업에 유리하지만 발열·소비전력 최대
`powersave`	항상 최저 클록 고정 — 소비전력·발열 최소, 성능 최저
`ondemand` / `schedutil`	부하에 따라 동적으로 조절 — 대부분의 범용 워크로드에 무난한 기본값
`conservative`	`ondemand`과 비슷하되 더 점진적으로 클록을 올림
`userspace`	사용자가 `scaling_setspeed`로 직접 고정 주파수를 지정

governor를 바꾸려면 모든 코어에 같은 값을 써 준다.

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

이 설정은 재부팅하면 기본값으로 돌아간다. 부팅마다 고정하고 싶다면 이 명령을 실행하는 systemd 유닛을 직접 만들어 enable하는 방법이 있다(5.1에서 다룬 유닛 관리 방식을 그대로 응용). UNO Q 전용 governor 설정 서비스가 기본 이미지에 포함돼 있는지는 확인하지 못했다 — 확인 필요.

5.5.2 발열과 스로틀링

QRB2210은 UNO Q 보드 위에서 팬 없이(fanless) 동작한다 — 방열은 기판·부품 표면의 자연 대류(passive convection)에만 의존한다. 서드파티 방열판 설계 프로젝트(PCBWay에 공개된 커뮤니티 열 시뮬레이션)에 따르면, QRB2210에는 thermal-throttling 임계 온도가 존재하며 이를 넘으면 클록을 낮춰 성능이 저하된다. 같은 자료는 지속적인 GPU/DSP/VPU 부하(예: 엣지 AI 추론을 오래 실행하는 시나리오)에서 시뮬레이션한 보드 표면 최고 온도가 약 55°C로 안정화되며 "임계 온도보다 충분히 낮다"고 보고했다.

⚠️ 다만 이는 서드파티(비공식) 커뮤니티 자료이며, 정확한 임계 온도 수치 자체는 공개되지 않았다 — UNO Q 고유 확인 필요. 결론만 실무적으로 취하면 다음과 같다.

짧은 버스트 작업(가끔 한 번씩 실행되는 추론)은 방열판 없이도 대체로 문제되지 않을 가능성이 크다.
지속적으로 GPU·DSP를 고부하로 구동하는 워크로드(연속 비전 추론, 상시 모델 서빙 등)라면 방열판이나 통풍이 되는 인클로저 설계를 고려하는 편이 안전하다 — 구체적인 인클로저·방열 설계는 11.1(인클로저 설계 원칙 — 포트 배치와 방열)에서 다룬다.

5.5.2.1 온도 직접 확인하기

표준 Linux 커널 열 관리 프레임워크는 /sys/class/thermal/thermal_zoneN/temp에 밀리섭씨(m°C) 단위로 온도를 노출하는 것이 일반적이다. UNO Q에서 정확히 어떤 thermal_zone 번호가 SoC 코어 온도를 가리키는지는 이 책에서 직접 확인하지 못했으므로, 아래처럼 있는 항목을 모두 조회해 라벨(type)로 판별하는 방법을 권한다.

for zone in /sys/class/thermal/thermal_zone*; do
  echo "$zone: $(cat $zone/type) $(( $(cat $zone/temp) / 1000 ))°C"
done

이 방법 자체는 표준 Linux 관행이지만, UNO Q에서의 출력 예시·정상 온도 범위는 확인 필요로 남겨 둔다.

5.5.3 소비전력 모니터링

라즈베리파이의 vcgencmd measure_volts처럼 SoC 내부 전압·전류를 보여주는 UNO Q 전용 소프트웨어 도구는 공식 문서에서 확인되지 않았다 — 확인 필요, 있다고 단정하지 않는다. 실측이 필요하다면 현재로서는 다음이 현실적인 대안이다.

외부 USB-C 전력계(파워 미터)를 보드 전원 입력단에 연결해 실측한다 — 소프트웨어에 의존하지 않는 가장 확실한 방법.
top/lscpu(5.1에서 다룸)로 CPU 부하율을 간접 지표로 삼아, 부하가 높은 구간과 낮은 구간을 비교하는 정도는 가능하다.

5.5.4 절전 실무 — 일반 원칙과 적용

아래는 일반적인 ARM 임베디드 Linux의 절전 원칙을 UNO Q에 적용한 것이다. UNO Q에서 각 조치가 실제로 얼마나 소비전력을 줄이는지는 실측하지 않았다 — 원리적으로 타당한 조치라는 것이며, 정확한 수치가 필요하면 5.5.3의 외부 전력계로 직접 측정해야 한다.

쓰지 않는 서비스는 끈다. ADB를 더는 쓰지 않는다면 sudo systemctl disable --now adbd(5.1.3.1). 불필요한 백그라운드 App도 arduino-app-cli app stop으로 정지한다.
쓰지 않는 무선을 끈다. Wi-Fi를 안 쓰는 유선 전용 배포라면 nmcli radio wifi off, Bluetooth를 안 쓴다면 nmcli radio bluetooth off(nmcli 자체는 5.1에서 이미 다룬 표준 NetworkManager 도구다).
헤드리스 배포라면 그래픽 스택을 전혀 기동하지 않는다. SBC 모드(데스크톱)로 부팅하지 않고 CLI 전용으로 운영하면 디스플레이·컴포지터 관련 소비전력을 아낄 수 있다 — 단, App Lab 자체가 SBC 모드에서 상시 실행되는 구조이므로 이 선택이 어떤 워크플로우에 적합한지는 3.3·5.3를 함께 참고해 판단한다.
불필요한 USB 주변기기를 분리한다. 특히 버스 파워를 끄는 USB 허브·동글은 유휴 상태에서도 전류를 끈다.
CPU governor를 워크로드에 맞춘다(5.5.1). 상시 고성능이 필요 없다면 performance 대신 schedutil/powersave 계열을 검토한다.

5.5.5 실전 시나리오 — 상시 가동 IoT 노드

여기서부터는 검증된 사실이 아니라 필자의 견해다. 상시 전원이 연결된 채로 몇 주~몇 달 단위로 켜져 있는 IoT 노드(예: 원격 센서 게이트웨이)를 운영한다면, 아래 조합을 출발점으로 고려할 만하다 — 근거와 함께 제시한다.

adbd는 끈다(보안·전력 양쪽 이유, 5.1.3.1). 개발 완료 후 USB 프로그래밍 경로가 더는 필요 없다면 공격 표면과 유휴 전력을 동시에 줄인다.
CPU governor는 schedutil(또는 이 보드가 지원한다면 ondemand)로 둔다. 상시 최고 성능이 필요하지 않은 센싱·주기적 전송 워크로드라면, 매 순간 최고 클록을 고정하는 performance보다 유휴 시 클록을 낮추는 동적 governor가 발열·전력 면에서 유리할 가능성이 크다 — 다만 응답 지연에 민감한 실시간 제어 루프(8.1~8.4의 실시간 응용)라면 반대로 performance가 더 적합할 수 있다.
원격 관리는 SSH만 켜 두고 그래픽 원격 접속(xrdp 등)은 필요할 때만 켠다(5.2.7). 상시 켜 둘 필요가 없는 서비스는 enable이 아니라 필요할 때 start하는 방식으로 다룬다(5.1.2).
저널·로그를 주기적으로 정리해 eMMC 쓰기를 줄인다(5.1.4.1, 5.4). eMMC는 쓰기 횟수에 수명 한계가 있는 플래시 메모리이므로, 불필요하게 많은 로그를 계속 쓰는 것은 장기적으로 전력과는 별개로 스토리지 수명에도 영향을 줄 수 있다 — 다만 UNO Q eMMC의 정확한 내구성 사양은 확인하지 않았다.

이 조합이 모든 상황에 맞는 정답은 아니다 — 실시간 제어가 핵심인 프로젝트라면 전력보다 응답성을 우선해 performance governor와 상시 서비스 기동을 선택하는 것이 오히려 맞는 트레이드오프일 수 있다. 8.1(MCU의 실시간성 이해)에서 이어지는 실시간 시스템 응용 부를 함께 참고해 판단한다.

5.5.6 다음으로

전력·성능 관리는 결국 하드웨어 전원 설계(2.4)와 서비스 관리(5.1)를 워크로드에 맞게 조합하는 문제다. 이것으로 제5부(운영체제 다루기)를 마친다 — 다음 제6부(6.1~6.3)에서는 PC에서 C++/Rust를 크로스 컴파일해 UNO Q로 배포하는 개발 워크플로우를 다룬다.