제0부 오리엔테이션

0.1 UNO Q란 무엇인가 — 두 개의 브레인, 왜 이런 구조인가

제0부 오리엔테이션. Arduino UNO Q(이하 UNO Q)를 한 문장으로 요약하면 다음과 같다 — "클래식 UNO의 폼팩터에 리눅스 컴퓨터와 실시간 마이크로컨트롤러를 함께 넣은 보드." 이 장에서는 그 구조가 정확히 무엇이고, 왜 이렇게 만들었는지를 설명한다. 사양표는 뒤에서 계속 반복해 나오니, 여기서는 전체 구조를 먼저 개관한다.

0.1.1 한눈에 보는 UNO Q

UNO Q는 Arduino가 Qualcomm과 협업해 2025년 출시한 보드로, 공식 소개는 "올인원 툴박스(All-In-One Toolbox)"다. 겉모습은 클래식 Arduino UNO와 같은 폼팩터(68.58mm × 53.34mm)를 유지하면서, 보드 위에 서로 다른 두 개의 프로세서를 탑재했다.

• High-Level Brain (하이레벨 브레인): Qualcomm Dragonwing™ QRB2210 — 쿼드코어 64비트 Arm Cortex-A53 @ 2.0GHz. Debian Linux OS를 구동한다.
• Real-Time Brain (리얼타임 브레인): STMicroelectronics STM32U585 — Arm Cortex-M33, 최대 160MHz. Zephyr 기반 Arduino Core로 스케치를 구동한다.

Arduino 공식 사용자 매뉴얼(User Manual, SKU ABX00162/ABX00173, 2026-08-17 개정판 기준)은 이를 각각 MPU(Microprocessor Unit)와 MCU(Microcontroller Unit)로 부른다 — "MPU는 완전한 운영체제와 복잡한 소프트웨어를 구동하는 고성능 애플리케이션 프로세서, MCU는 I/O·제어에 특화된 빠르고 정밀한 타이밍의 소형 저전력 컨트롤러"라는 것이 공식 정의다.

두 프로세서 모두 같은 보드 위에서 각자의 전원 도메인(MPU I/O는 1.8V, MCU I/O는 3.3V)을 가지고 독립적으로 동작하며, 필요할 때만 서로 통신한다. 이 통신 구조는 0.1.5에서 짧게 미리 보고, 상세는 3.4·8.3에서 다룬다.

라인업(2GB/16GB, 4GB/32GB)과 가격은 1.1에서 자세히 다룬다. 여기서는 "두 개의 뇌를 가진 보드"라는 구조 자체에 집중한다.

0.1.2 첫 번째 브레인 — High-Level Brain (QRB2210 MPU)

QRB2210은 원래 Qualcomm이 IoT·엣지 기기용으로 만든 SoC(Dragonwing 브랜드, 舊 QCS/QCM 라인업 계열)로, UNO Q는 이를 그대로 탑재해 Debian Linux를 정식 구동한다. 공식 매뉴얼 기준 역할은 다음과 같다.

• 연산: 쿼드코어 Cortex-A53 @ 2.0GHz + Adreno 702 GPU(845MHz) — 3D 그래픽·영상 가속.
• 카메라 파이프라인: 듀얼 ISP(13MP+13MP 동시, 또는 25MP @ 30fps 단일) — MIPI CSI-2 4레인.
• 디스플레이: MIPI DSI 4레인, 온보드 ANX7625 브리지를 통해 USB-C DisplayPort Alt-Mode로도 출력(단, MIPI-DSI 신호는 JMEDIA1 헤더와 USB-C 출력이 멀티플렉스되어 있어 동시에 하나만 활성화된다 — 확인됨).
• 네트워킹: Wi-Fi 5·Bluetooth 5.1(WCBN3536A/Qualcomm WCN3980 모듈), USB 3.1(역할 전환 지원).
• 소프트웨어 생태계: Debian이므로 apt 패키지, Python, Docker, ROS2(커뮤니티 빌드) 등 리눅스 생태계를 그대로 쓸 수 있다.

이 브레인이 맡는 일은 "부하가 크고 유연해도 되는 것들" — AI 추론, 네트워크 통신, 데이터베이스, 웹 서버, 복잡한 애플리케이션 로직이다. 상세 아키텍처는 2.1, AI·GPU 활용은 제9부(9.1~9.5)에서 다룬다.

0.1.3 두 번째 브레인 — Real-Time Brain (STM32U585 MCU)

STM32U585는 ST의 저전력 Cortex-M33 마이크로컨트롤러다. UNO Q에서는 Zephyr RTOS 위에 구축된 Arduino Core로 동작해, 개발자 입장에서는 기존 아두이노 스케치(setup()/loop())를 그대로 작성한다 — 내부적으로 Zephyr가 동작하고 있다는 사실은 대부분의 사용 시나리오에서 감출 수 있다.

• ADC, PWM, CAN(FDCAN), 타이머, LED 매트릭스를 이 MCU가 직접 관리한다.
• 클래식 UNO 형태의 3.3V 헤더(JDIGITAL1·JANALOG1·JSPI1·Qwiic)가 전부 이 MCU에 연결되어 있다 — 즉 "핀에 쓰는 아두이노 코드"는 여전히 이 브레인의 몫이다.
• 결정론적 타이밍이 필요한 작업(모터 PWM, 센서 폴링, 인터럽트 응답)은 이 브레인에서 실행해야 지연이 예측 가능하다 — 이유는 0.1.4, 실전 설계는 제8부(8.1~8.5)에서 다룬다.

즉 "Arduino UNO Q에서 스케치를 업로드한다"고 할 때, 그 스케치는 실제로는 QRB2210이 아니라 STM32U585에서 실행된다.

0.1.4 왜 두 브레인인가 — 설계 철학과 트레이드오프

0.1.4.1 한 프로세서로는 왜 부족한가

한 개의 프로세서에 모든 것을 맡기면 다음 두 요구가 직접 충돌한다.

1. 풍부한 소프트웨어 생태계 — Linux, 패키지 매니저, AI 프레임워크(TensorFlow Lite, ONNX Runtime), 네트워크 스택, 멀티태스킹 스케줄러. 이런 것을 다 쓰려면 일반 목적 운영체제(범용 OS)가 필요하다.
2. 결정론적 실시간성 — 모터 PWM 주기, 센서 인터럽트 응답, 타이밍 크리티컬 제어 루프는 "대부분 빠르다"가 아니라 "항상 정해진 시간 안에 반응한다"를 요구한다. 그런데 Linux 같은 범용 OS는 스케줄러 지연, 캐시 미스, 인터럽트 우선순위 경쟁 때문에 마이크로초 단위의 확정적 타이밍을 보장하기 어렵다(불가능한 것은 아니지만 PREEMPT_RT 같은 별도 튜닝이 필요하고, 그래도 MCU만큼의 결정론에는 못 미친다).

Arduino가 UNO Q 발표 이후 공식 블로그에서 든 표현을 빌리면: "당신은 Linux의 유연함을 원한다. 동시에 실시간 제어의 정밀함이 필요하다(You want the flexibility of Linux. You need the precision of real-time control.)" — 이 두 요구를 하나의 프로세서에 억지로 맞추는 대신, 애초에 역할이 다른 두 프로세서를 한 보드에 탑재하고 그 사이를 빠르게 연결하자는 것이 UNO Q의 설계 결정이다.

0.1.4.2 대안들과의 비교 — 왜 "따로 두 보드"가 아니라 "한 보드"인가

같은 목표(리눅스 + 실시간 제어)를 달성하는 방법은 UNO Q 이전에도 있었다. 흔한 조합은 라즈베리파이 같은 SBC + 별도 아두이노 보드를 USB 시리얼로 연결하는 것이다. Arduino는 자사 블로그에서 이 접근의 문제를 다음과 같이 지적한다(요지 인용): 리눅스 보드만으로는 실시간 I/O를 위해 결국 마이크로컨트롤러가 또 필요하고, 거기에 별도 저장장치·별도 AI 가속기까지 더해지면 "부품 목록(BOM)이 치솟고 통합의 골칫거리가 뒤따른다." 그리고 두 보드를 직접 연결하면 개발자가 "통신·동기화를 손수 관리해야 하는 접착 코드(glue code)"가 계속 늘어난다.

정리하면 세 가지 접근을 놓고 트레이드오프를 볼 수 있다.

1. MCU 단독(클래식 Arduino UNO 등) — 결정론적이고 단순하지만, 리눅스 소프트웨어 생태계·네트워킹·AI 추론이 없다.
2. MPU 단독(라즈베리파이 등) — 리눅스 생태계는 풍부하지만, 하드 리얼타임 I/O가 기본 내장되어 있지 않다(RP2040/Pico 같은 별도 MCU를 추가해야 함, 0.2.3에서 다시 다룸).
3. MPU + MCU를 별도 보드로 조합(라즈베리파이 + 아두이노를 USB/시리얼로 연결) — 목표는 달성하지만, 두 개의 전원·두 개의 부팅 절차·직접 설계해야 하는 통신 프로토콜이 생긴다. 부품 수·소비전력·통합 공수가 함께 늘어난다.
4. MPU + MCU를 한 보드에 통합(UNO Q) — 위 3번의 통합 부담을 보드 설계 단계에서 흡수한다. 두 프로세서는 보드 내부의 전용 통신 계층(Bridge, 0.1.5)으로 연결되어 있어, 개발자가 시리얼 프로토콜을 직접 설계하지 않아도 된다.

이 트레이드오프 정리에서 1·2번은 확인된 사실(하드웨어 구성상 명백)이고, 3·4번의 "장단점" 서술은 Arduino의 마케팅 자료(공식 블로그)에 담긴 논지를 요약한 것이다 — 즉 판매자 관점의 주장이라는 점을 감안해서 읽으면 된다. 실제로 "한 보드 통합"이 모든 프로젝트에 유리한 것은 아니다. 예컨대 MPU와 MCU를 물리적으로 분리해 진동·발열을 격리해야 하는 상황, 혹은 이미 검증된 라즈베리파이 + 별도 MCU 조합이 안정적으로 운용되는 기존 시스템에서는 UNO Q로 전환할 이유가 약하다.

0.1.5 두 브레인은 어떻게 통신하는가 — 짧은 예고

공식 매뉴얼은 두 프로세서의 통신 계층을 "Bridge"라고 부른다 — "Linux 시스템과 마이크로컨트롤러는 Bridge를 통해 통신한다. 이는 Arduino의 RPC(Remote Procedure Call) 라이브러리로, MCU 쪽 스케치가 Linux 서비스를 호출하거나, Linux 애플리케이션이 MCU 주변장치와 상호작용할 수 있게 한다"는 것이 공식 설명이다. 서비스 지향(service-oriented) API로 양방향 함수 호출과 비동기 알림(notification)을 지원하며, 전송 방식으로 USB CDC·UART·SPI 등을 쓸 수 있다고 명시되어 있다.

참고 — "Bridge" 명칭: 2026-08-17자 공식 User Manual과 Inter-Processor Communication 절은 이 통신 계층을 일관되게 "Bridge"(또는 "Arduino Bridge")라고 표기한다. store.arduino.cc 마케팅 페이지 등에서는 "Visual Bridge"라는 표현도 함께 쓰이지만, 기술 문서상의 공식 명칭은 아니다 — 이 책은 기술 문서 표기를 따라 전 장에서 "Bridge"로 통일했다(3.4).

Bridge의 정확한 동작 방식(전송 계층, 지연 특성, API 사용법)은 이 장의 범위 밖이다 — 소프트웨어 스택 관점은 3.4, 실시간성 관점의 지연 실측은 8.3에서 다룬다.

0.1.6 이 책의 구성 — 무엇을 어디서 다루는가

이 책은 UNO Q를 13부 + 부록으로 나눠 다룬다. 전체 장 목록과 읽는 순서는 목차(목차)이 단일 출처이며, 큰 흐름만 요약하면 다음과 같다.

• 제1부(1.1~1.4) 구매와 초기 셋업 — 라인업·가격·구매처·언박싱.
• 제2부(2.1~2.4) 하드웨어 심층 — 두 프로세서 아키텍처, 핀아웃, 고속 인터페이스, 전원.
• 제3부(3.1~3.4) 소프트웨어 스택 — Debian, Zephyr 기반 Arduino Core, App Lab, Bridge(위에서 예고한 통신 계층).
• 제4~5부(4.1~5.5) 프로그래밍과 Debian 운영 — 스케치·App Lab·GPIO·Wi-Fi, SSH·OTA·저장소.
• 제6~7부(6.1~7.4) 개발 워크플로우와 미들웨어 — 크로스 컴파일, Docker, ROS2·Zenoh·DB.
• 제8부(8.1~8.5) 실시간 시스템 응용 — MCU 결정론, PID 모터 제어, STM32에서 PX4/ArduPilot을 MAVLink로 실시간 제어(단, UNO Q가 비행 컨트롤러 펌웨어 자체를 구동하는 것이 아니라 외부 실시간 제어기로 연결되는 구성 — 8.5에서 경계를 명확히 한다).
• 제9부(9.1~9.5) AI·엣지 응용 — GPU/DSP 하드웨어, One-Click AI, GPU 가속 추론.
• 제10~11부(10.1~11.3) 서드파티 생태계와 3D 프린팅 활용.
• 제12부(12.1~12.3) 실전 종합 프로젝트.
• 부록(A.1~A.4) 트러블슈팅·용어집·비교표·참고자료.

다음 장 0.2는 이 구조를 클래식 Arduino UNO·라즈베리파이와 나란히 놓고 "정확히 무엇이 다른가"를 정리한다. 0.3은 UNO Q의 동일 계열 제품인 VENTUNO Q를 개관 수준으로 소개한다.