온디바이스 비전·멀티모달 AI — 사용자 추종부터 자율주행까지

개요 — 온디바이스 비전·멀티모달 AI의 지형과 제약

온디바이스(on-device) 추론은 카메라·IMU 스트림을 클라우드로 보내지 않고 단말 내부 NPU/GPU에서 직접 처리한다. 스마트폰 AR·사용자 추종 로봇·ADAS/자율주행이 모두 같은 방향으로 수렴하는 이유는 네 가지다.

• 지연(latency): 충돌 회피·AR 렌더링·추종 제어는 왕복 네트워크(수십~수백 ms)를 감당할 수 없다. 카메라 프레임당 예산은 보통 **33 ms(30 FPS)~16 ms(60 FPS)**다.
• 프라이버시: 얼굴·실내 영상·차량 주변 영상은 단말을 떠나지 않는 편이 규제·신뢰 측면에서 유리하다.
• 비용: 수백만 대 단말의 영상을 상시 클라우드 추론하면 GPU 비용이 비현실적이다.
• 오프라인: 터널·지하·산간 등 무연결 환경에서도 동작해야 한다.

스마트폰 vs 차량 임베디드 제약

같은 "엣지"라도 두 영역의 전력·열·연산 예산은 자릿수 단위로 다르다.

스마트폰에서는 **지속 성능(sustained FPS)**이 피크 TOPS보다 중요하다. NPU 활용이 핵심으로, LiteRT 기준 Snapdragon 8 Elite Gen 5에서 NPU는 CPU 대비 지연을 ~1–20% 수준까지 줄여 56개 이상 모델이 5 ms 미만으로 동작한다. 차량 측은 절대 연산은 풍부하나 다중 카메라·LiDAR 동시 처리 + 기능안전이 병목이다.

대표 과제와 후보 모델(수치·라이선스)

• 객체 탐지(Detection): YOLO11(Ultralytics)은 n/s/m/l/x로 확장되며 COCO mAP50-95 39.5(n, 2.6M, T4 1.5 ms) ~ 54.7(x, 56.9M), 라이선스는 AGPL-3.0 + 상용 Enterprise다. 트랜스포머 계열 RF-DETR(Roboflow)은 T4·TensorRT FP16에서 56.5 AP(L), 2XL은 60.1 AP로 최초로 실시간 60 AP를 넘었다. Nano~Large와 코드는 Apache 2.0, XL/2XL은 PML 1.0으로 분리된다. → AGPL 회피가 중요하면 RF-DETR 코어 또는 별도 상용 라이선스.
• 추적/재식별(Tracking·ReID): OSNet은 경량 ReID 백본으로 Market-1501 **Rank-1 94.8%**급, 사용자 추종에서 탐지+ByteTrack류 추적기와 결합한다.
• VLM(멀티모달): SmolVLM2(256M/500M/2.2B, Apache 2.0)는 256M이 추론 시 1 GB 미만 GPU 메모리로 동작하며 500M은 iOS HuggingSnap에서 완전 온디바이스로 구동된다. 장면 설명·시각 질의응답을 단말에서 처리.
• VSLAM/AR: ARCore/ARKit은 VIO(카메라+IMU) 기반 6DOF 추적·평면 검출을 OS 레벨에서 제공. 로봇·연구용은 RTAB-Map(상용 친화, 자유 사용), stella_vslam/ORB-SLAM3는 GPLv3(폐쇄소스 상용은 별도 라이선스 필요)라는 점이 제품화 시 결정적이다.

클라우드-엣지 분담

전부 온디바이스일 필요는 없다. 일반적 분담은 엣지=실시간 지각(탐지·추적·VIO·SLAM 프런트엔드), **클라우드=비실시간·대형 작업(파인튜닝, 데이터 라벨링, 대형 VLM 추론, 맵 최적화·재배치)**이다. 예: 단말은 경량 탐지로 후보를 만들고, 모호한 케이스만 대형 VLM에 위임(cascade). 차량은 안전상 지각·제어는 온보드 고정, 클라우드는 OTA·플릿 러닝에 사용.

전체 파이프라인 개관

1. 데이터 수집·라벨링(클라우드): 도메인 영상 수집, 오토라벨링, 큐레이션.
2. 시뮬레이터 보강: 자율주행 CARLA(MIT), 로보틱스 Isaac Sim(NVIDIA, 상용 라이선스)로 코너케이스 합성.
3. 파인튜닝: 사전학습 백본(RF-DETR/YOLO/SmolVLM)을 타깃 도메인에 적응.
4. 경량화: 양자화(INT8)·프루닝·증류로 NPU 적합화.
5. 변환·런타임: LiteRT(Android/NNAPI·NPU·Core ML), ONNX Runtime+QNN(Snapdragon Hexagon), CoreML(Apple Neural Engine)로 타깃별 컴파일.
6. 배포·검증: 지속 FPS·열·전력 프로파일링, 정확도 회귀 테스트.

핵심 선택 기준은 **(정확도 mAP) × (지속 FPS) × (전력) × (라이선스 적합성)**의 4축 트레이드오프이며, 특히 AGPL/GPL 계열은 상용 폐쇄 제품에서 별도 검토가 필수다.

객체 탐지 — YOLO 계열 vs RF-DETR

온디바이스 객체 탐지는 크게 두 흐름으로 갈린다. CNN 기반 YOLO 계열(검증된 모바일 표준)과 트랜스포머 기반 RF-DETR(real-time DETR)다. 선택은 정확도-지연 트레이드오프뿐 아니라 라이선스와 배포 파이프라인 성숙도에 의해 결정된다.

YOLO 최신 계열 (v8 / v10 / v11)

세 버전 모두 앵커프리(anchor-free) 헤드를 채택하지만 후처리 전략이 다르다.

• YOLOv8: 앵커프리 + decoupled head. 성숙한 TensorRT/CoreML/TFLite 익스포트로 모바일 배포 생태계가 가장 두텁다. NMS 필요.
• YOLOv10: NMS-free end-to-end 설계가 핵심. 학습 시 one-to-many·one-to-one을 함께 쓰는 consistent dual assignments로 추론 시 NMS를 제거해 지연 변동성을 줄였다. 논문 기준 YOLOv10-S는 NMS 제거로 end-to-end 지연을 약 4.63ms 단축하며 44.3% AP 유지(arXiv 2405.14458).
• YOLO11: NMS 기반 디코딩은 유지하되 예측을 더 정제해 후처리 부하를 낮췄다. **동급 대비 파라미터 22% 감소(YOLO11m vs YOLOv8m)**로 효율이 가장 좋다.

공식 COCO val2017 벤치마크(640px, T4 TensorRT FP16):

출처: Ultralytics YOLO11 Docs.

모바일 실측: CoreML/TFLite 익스포트 시 YOLOv8s급은 최신 스마트폰에서 약 30 FPS, YOLO11n은 엣지에서 sub-3ms·30–50 FPS 수준이 보고된다. 단, INT8 양자화 시 캘리브레이션이 부실하면 mAP 손실이 평균 약 7.2점까지 날 수 있으므로 PTQ 캘리브레이션·QAT가 필수다(arXiv 2510.09653).

RF-DETR (real-time DETR)

Roboflow가 개발한 트랜스포머 검출기로 DINOv2 ViT 백본 + weight-sharing NAS로 정확도-지연 곡선을 탐색한다. DETR 계열답게 앵커프리이며 NMS도 불필요(end-to-end set prediction)하다. ICLR 2026 채택.

공식 COCO 벤치마크(T4 TensorRT FP16, batch 1):

출처: roboflow/rf-detr GitHub. RF-DETR-2XL는 real-time 모델 최초로 COCO 60 AP 돌파.

입력 해상도가 RF-DETR 정확도-지연을 직접 조절하는 1차 변수다(Nano 384²→2XL 880²). 다만 ViT 백본 특성상 파라미터·메모리가 동급 YOLO 대비 크고(Nano도 30.5M), 모바일 NPU의 트랜스포머 연산(어텐션) 지원이 아직 고르지 않아 순수 모바일(스마트폰 NPU) 배포는 YOLO보다 검증이 부족하다. 현실적으로 T4/Jetson/Orin급에서 강점이 분명하다.

온디바이스 적합성과 트랜스포머의 한계

• NMS/후처리: RF-DETR·YOLOv10은 NMS-free라 지연이 결정적(deterministic)이라 실시간 파이프라인에 유리. YOLOv8/v11은 NMS 의존.
• 양자화·익스포트: YOLO는 LiteRT(TFLite)/CoreML/ONNX Runtime INT8 경로가 성숙. ViT는 INT8 양자화 시 어텐션 민감도가 높아 FP16 우선이 안전.
• 메모리/대역폭: 모바일에선 파라미터가 작은 YOLO11n/s가 유리.

선택 기준 (실무)

1. 스마트폰·모바일 NPU 타깃, 라이선스에 민감(독점 제품) → YOLO11n/s를 Enterprise 라이선스로(오픈소스 사용은 AGPL-3.0 카피레프트). NMS-free가 필요하면 YOLOv10.
2. Apache 2.0 등 비카피레프트 + 파인튜닝 정확도 우선, Jetson/Orin·서버급 → RF-DETR(Nano~Large). 단 XL/2XL은 PML 1.0(상용 제약 확인 필요).
3. 극단적 저지연·결정적 지연 → YOLOv10 또는 RF-DETR(둘 다 NMS-free).
4. 생태계·디버깅 편의·기존 파이프라인 호환 → YOLOv8/v11.

핵심: **라이선스(YOLO=AGPL-3.0/Enterprise, RF-DETR=Apache 2.0+일부 PML 1.0)**와 타깃 하드웨어의 트랜스포머 지원 여부가 모델 선택을 가른다.

YOLOX — Apache 2.0 라이선스의 앵커프리 대안

YOLOX(Megvii, 2021)는 YOLO 구조에 앵커프리 + 디커플드 헤드(분류·회귀 분기 분리) + SimOTA 동적 라벨 할당을 도입한 검출기로, 결정적 강점은 Apache 2.0 라이선스다. Ultralytics YOLO(AGPL-3.0)의 카피레프트 부담 없이 상용 폐쇄 제품에 쓸 수 있고, RF-DETR보다 가볍다.

• 디커플드 헤드: 분류·회귀를 분리해 수렴 속도·정확도 향상(약간의 추가 연산).
• SimOTA: 추가 솔버 하이퍼파라미터 없이 동적 매칭으로 학습 시간 단축, 강증강(Mosaic+MixUp).
• 온디바이스 배포: 공식 ONNX·TensorRT·ncnn·MNN·OpenVINO 데모 제공 → 모바일 NPU/엣지 친화(Nano/Tiny가 스마트폰 타깃).

3자 선택 가이드

경량 비전-언어 모델(VLM) — SmolVLM과 온디바이스 멀티모달

온디바이스 VLM은 이미지 픽셀과 자연어를 함께 입력받아 캡션·답변·구조화 텍스트를 생성한다. 핵심 구조는 거의 동일하다: ① 비전 인코더(SigLIP/ViT 계열)가 이미지를 패치 임베딩으로 변환 → ② 프로젝터/커넥터가 이를 LLM 토큰 공간으로 정렬 → ③ 소형 LLM이 텍스트와 함께 자기회귀 디코딩. 7B급 LLaVA·Qwen2.5-VL-7B 대비 핵심 차별점은 LLM 백본과 이미지 토큰 수를 동시에 줄여 모바일·임베디드 RAM 예산(1~4GB)에 맞추는 것이다.

SmolVLM: 구조와 토큰 효율

SmolVLM(HuggingFace)은 256M·500M·2.2B 세 크기로 제공된다.

• 256M = SigLIP-B/16(93M) + SmolLM2-135M
• 500M = SigLIP-B/16(93M) + SmolLM2-360M
• 2.2B = SigLIP-SO400M(400M) + SmolLM2-1.7B

토큰 효율이 온디바이스 핵심이다. SmolVLM은 2×2 픽셀 셔플(pixel shuffle) 로 2×2 피처 블록을 채널 4배 단일 벡터로 합쳐 이미지 토큰 수를 1/4로 줄인다(어텐션 비용은 약 1/16). 신모델은 토큰당 4096픽셀을 인코딩(2B는 1820픽셀/토큰)하고, 고해상도는 이미지를 서브이미지로 쪼개는 타일링으로 처리하되 <row_1_col_1> 같은 구분자를 1토큰으로 매핑해 오버헤드를 줄인다. 결과적으로 256M은 추론 시 1GB 미만 GPU RAM으로 동작하고, M4 Max MacBook의 브라우저(WebGPU)에서 약 80 decode tok/s를 낸다.

벤치마크(Instruct, 공식 모델카드):

500M이 256M 대비 문서/차트에서 큰 폭으로 앞서므로, UI/문서 이해가 목표면 500M이 실용 하한선이다. 라이선스는 모델·데이터·학습 레시피 모두 Apache-2.0으로 상용 배포에 제약이 없다.

온디바이스 용도와 트레이드오프

• 이미지 캡셔닝 / 태깅: 256M로 충분. 짧은 출력은 디코딩 토큰이 적어 지연이 작다.
• VQA(시각 질의응답): 일반 장면은 500M~2B, 정밀 텍스트 답변은 OCRBench 높은 모델 필요.
• UI/문서 이해(스크린샷·영수증·차트): 고해상도 타일링 + 높은 DocVQA가 필수 → SmolVLM-2.2B, Qwen2.5-VL-3B 권장.

지연·메모리 결정 요인: (1) 이미지 토큰 수(타일 개수×해상도) — 프리필 비용을 지배, (2) LLM 백본 크기 — 디코딩 속도, (3) 양자화. INT4/INT8(GPTQ·AWQ·llama.cpp Q4_K)로 가중치를 줄이면 2B급도 휴대폰 4GB RAM에서 동작 가능하나, OCR·차트 정밀도가 먼저 저하되니 문서 태스크는 INT8 이상 유지를 권한다. 런타임은 llama.cpp/MLX(애플 실리콘), ONNX Runtime, MediaPipe/LiteRT를 주로 쓴다.

대안 비교

선택 기준

• 최소 메모리·웹/브라우저·실시간 캡션: SmolVLM-256M/500M (1GB 미만, WebGPU).
• 균형 잡힌 일반 VQA·간단 통합: moondream2 또는 MobileVLM V2 1.7B.
• 문서·차트·UI 정밀도 우선: Qwen2.5-VL-3B 또는 SmolVLM-2.2B, INT8 유지.
• 라이선스: 위 모델 모두 Apache-2.0 → 상용 온디바이스 탑재 시 추가 제약 없음(단, 학습 데이터 출처와 파생물 표기 의무는 별도 확인).

사용자 추종(Person Following) — 탐지·추적·재식별(OSNet)

사용자 추종은 카메라가 비추는 군중 속에서 **단 한 명(타깃)**을 끝까지 놓치지 않고 따라가는 과제다. 표준 파이프라인은 검출 → MOT(다중객체추적) → 재식별(ReID) 3단으로 구성되며, 여기에 거리/방향 추정과 모션 제어가 붙는다.

파이프라인 구조

• 검출(Detection): YOLO 계열(YOLOv8n/11n, RT-DETR)로 사람 bbox를 매 프레임 추출. 온디바이스에서는 nano급(~3M 파라미터) + INT8 양자화로 모바일 NPU/Jetson에서 30 FPS 이상 확보.
• MOT(추적): 검출 박스를 프레임 간 연결해 track ID 부여. 칼만 필터(모션) + 헝가리안 매칭이 기본.
• ReID(재식별): 가림·프레임아웃 후 재등장한 사람을 외형 임베딩으로 동일 인물에 다시 결합. OSNet이 사실상 표준.

MOT: ByteTrack vs BoT-SORT

실무 권장: 카메라 자체가 움직이는 추종 응용은 BoT-SORT(CMC가 자기운동 보상)가 ID 안정성에서 유리. 연산 여유가 적으면 ByteTrack + OSNet 임베딩만 선택적으로 호출.

재식별(ReID): OSNet

• OSNet(Omni-Scale Network, ICCV 2019): 다중 스케일 스트림 + Unified Aggregation Gate로 입력 의존적 채널 가중. 단 2.2M 파라미터(ResNet50 25M 대비 1/10)로 Market1501 Rank-1 ~93.6%, mAP ~81% 달성 → 온디바이스 ReID의 1순위.
• 동작: 각 track의 bbox 크롭을 512-D(또는 256-D) 임베딩으로 변환, 타깃 임베딩과 코사인 유사도 비교. 임계값(예: 0.6) 이상이면 동일인.
• 갤러리 운용: 타깃 임베딩을 단일 벡터가 아니라 EMA(지수이동평균) 또는 K개 뱅크로 유지해 조명·자세 변화 흡수. 가림 중에는 갱신 동결(drift 방지).

가림·재등장 처리

• 가림(occlusion): MOT가 track을 lost 상태로 두고 칼만 예측으로 위치 외삽, ReID 임베딩은 보존. 재출현 시 IoU가 끊겨도 OSNet 유사도로 재결합.
• 재등장 윈도우: track_buffer(예: 30프레임≈1초) 내 미매칭 track을 후보로 유지. 너무 길면 ID 혼동, 짧으면 영구 손실 → 추종 거리·군중 밀도로 튜닝.
• 오결합 방지: 모션(칼만 게이팅) + 외형(코사인) 이중 게이트로 닮은 사람 오인 억제.

거리/방향 추정 + 카메라·IMU 융합

• 방향(yaw): bbox 중심의 수평 오프셋 → 광학중심 기준 베어링 각. 짐벌/로봇 회전 PID 입력.
• 거리(depth): (a) 스테레오/ToF(RealSense D435i 등) 직접 측정, (b) 단안에서 bbox 높이·키포인트 기반 추정. UAV-사람 추종 연구는 단안 키포인트 깊이 + 깊이카메라를 EKF로 융합해 PID 제어.
• IMU 융합: 스마트폰/드론의 자이로·가속도로 자기운동(ego-motion) 보상 → 흔들림 중에도 bbox 예측 안정. 저조도에서 비전 신뢰도 하락 시 IMU가 단기 추정 유지. BoT-SORT의 CMC를 IMU로 대체/보강하면 GPU 비용 절감.

실시간 제약·정확도 트레이드오프

• 지연 예산: 추종 루프는 20~30 FPS, 엔드투엔드 <50 ms 목표. 검출이 가장 무거우므로 nano 모델 + 320~640 입력 + 프레임 스킵.
• ReID 호출 빈도: 매 프레임 전체 호출은 과부하. 신규/lost track에만 OSNet 실행하거나 N프레임마다 배치 처리.
• 타깃 단일화: 추종은 클래스 1개(타깃)만 정밀하면 되므로, ByteTrack로 전체 추적 후 ReID는 타깃 1:N 비교만 → 연산 대폭 절감.

응용: 로봇·짐벌·드론

• 로봇 카트/캐디: Jetson Orin Nano급에서 BoT-SORT+OSNet, 1~3 m 추종 거리 유지.
• AI 짐벌/액션캠: 모바일 SoC NPU, OSNet-x0.25 경량판으로 셀럽 추종 촬영.
• SAR 드론: 깊이카메라+단안 EKF 융합, PID로 고도·추종 거리 제어(저조도 IMU 보강).

멀티모달 확장으로 SmolVLM(2B) 같은 경량 VLM을 LoRA/QLoRA(~16 GB VRAM 파인튜닝)로 적응시켜 "빨간 옷 입은 사람" 같은 자연어 타깃 지정에 활용하는 흐름도 등장하고 있다.

VSLAM & AR — Stella VSLAM·RTAB-Map·ARCore/ARKit

Visual SLAM 개념

Visual SLAM(VSLAM) 은 카메라 영상만으로(또는 IMU·뎁스 보조) 미지 환경의 지도를 만들면서 동시에 6DoF 자세를 추정한다. 구조는 보통 프런트엔드(특징 추출·트래킹·VO)와 백엔드(포즈그래프·번들조정 최적화)로 나뉘고, 누적 드리프트를 잡기 위한 루프 클로저와 트래킹 실패 후 복귀용 재localization(relocalization) 이 핵심이다. 접근법은 ORB 등 희소 특징을 쓰는 indirect(feature-based) 와 픽셀 밝기를 직접 쓰는 direct(DSO 등) 로 나뉜다. 모바일·자율주행에서는 단안만으로는 스케일 모호성이 있어 VIO(카메라+IMU)나 스테레오/뎁스 융합이 표준이다.

Stella VSLAM vs RTAB-Map

• Stella VSLAM: ORB 보캐뷸러리 기반 루프 클로저·재localization, 프리빌트 맵에 새 영상을 정합. 다만 ORB-SLAM2 파생 여부로 GPLv3 적용 논쟁(이슈 #249)이 있어 상용 채택 시 법무 검토 필요.
• RTAB-Map: 메모리를 WM/LTM으로 계층화해 대규모 장기 매핑에서 실시간성을 유지. 기본 디스크립터로 BSD 계열(GFTT+BRIEF)을 써 라이선스가 깔끔하고, ROS1/2 패키지(rtabmap_ros)로 바로 통합된다. 벤치마크: 한 비교연구에서 RTAB-Map ATE RMSE ≈ 0.0192 m, ORB-SLAM3 ≈ 0.0091 m(약 2배 차이).

ARCore / ARKit — 모바일 트래킹 스택

• ARCore(Android): MSCKF 계열 VIO(COM, Concurrent Odometry and Mapping)로 카메라 특징 + IMU 융합. Depth API(단안 뎁스 추정, 호환 기기), 평면 탐지, Geospatial API(Street View VPS + GPS로 위경도 앵커, Geospatial Depth는 최대 ~65 m 뎁스맵), Cloud/Persistent Anchor 제공.
• ARKit(iOS): World Tracking(VIO) 위에 LiDAR Scanner(iPhone Pro/iPad Pro)로 즉시 뎁스·Scene Reconstruction → 스캔 없이 즉시 트래킹 시작. ARWorldMap으로 매핑 상태+앵커를 직렬화해 세션 간 재localization, ARGeoAnchor(Location Anchor)로 도시 단위 VPS 앵커링.
• 두 SDK 모두 30 FPS급 실시간 트래킹을 제공하지만 독점·기기 종속이며 raw 맵 데이터 접근이 제한적이다. 자율주행/로봇처럼 맵 소유·이식이 필요하면 Stella/RTAB-Map 같은 오픈 스택이 유리하다.

온디바이스 SLAM 제약

• 연산·발열·전력: 번들조정·루프클로저는 무겁다. ORB-SLAM3 트래킹 스레드는 일반 PC에서 30–40 FPS이나, Jetson TX2·RPi4 등 임베디드에서는 키프레임 수·해상도·특징점 수를 낮춰야 실시간 유지가 가능하다.
• 단안 스케일 모호성 → IMU/스테레오/뎁스 융합 권장.
• 메모리 증가: 맵 키프레임이 누적되므로 RTAB-Map식 메모리 관리나 맵 분할이 필요하다.
• 동적 환경·저조도·텍스처 부족에서 트래킹 손실 → 재localization 회복 경로 필수.

맵 재사용·재localization

장기 운용의 관건은 맵 1회 구축 → 재사용이다. Stella VSLAM은 map.msg save/load + ORB 보캐뷸러리 재localization, RTAB-Map은 멀티세션 매핑과 Localization 모드(맵 고정, 새 노드 미추가)로 드리프트 없는 반복 주행을 지원한다. 모바일에서는 ARWorldMap(iOS)·Cloud/Persistent Anchor(ARCore)로 동일 효과를 얻되 클라우드 의존이 생긴다. 선택 기준: 맵 소유·오프라인·라이선스 자유가 중요하면 RTAB-Map(BSD), 다양한 광학계·360 입력이면 Stella, 빠른 모바일 AR UX면 ARKit/ARCore.

추종/내비 결합

사용자 추종 시스템은 보통 VSLAM이 자기 위치·정적 지도를, 객체탐지(YOLO 등)+ReID(OSNet 등) 가 타깃의 상대 위치를 담당한다. SLAM 맵 좌표계에서 타깃 위치를 추정하면 가림·재등장 후에도 일관된 추종이 가능하고, 점유격자(RTAB-Map 산출) 위에서 로컬 플래너(예: Nav2)로 장애물 회피·경로계획을 결합한다. AR 내비는 ARCore Geospatial/ARKit GeoAnchor로 실세계 좌표에 경로 오버레이를 고정한다. 트레이드오프: 완전 온디바이스 오픈 스택은 통제·이식성이 높지만 튜닝 부담이 크고, ARKit/ARCore는 즉시 견고하나 폐쇄·클라우드 종속이라는 점을 감안해 설계한다.

데이터 파이프라인 & 레이블링

온디바이스 모델의 성능은 모델 구조보다 데이터 품질·분포에 더 크게 좌우된다(data-centric AI). 파이프라인은 수집 → 큐레이션 → 라벨링 → 증강 → 버전관리의 폐루프로 설계하고, 배포 후 실패 케이스를 다시 수집 단으로 되먹임(active learning)하는 구조가 핵심이다.

수집 → 큐레이션 → 증강

• 수집: 차량·스마트폰 실주행/실사용 로그, 공개 데이터셋(COCO, BDD100K, nuScenes), 합성데이터를 혼합. 엣지케이스(야간·역광·악천후·희귀 객체) 비중을 의도적으로 끌어올린다.
• 큐레이션: 임베딩 기반 중복 제거·다양성 샘플링(Lightly 등), 불확실성 샘플링으로 모델이 틀리는 샘플을 우선 라벨링. 아웃라이어(제거 대상)와 엣지케이스(증강 대상)를 구분하는 것이 비용 효율의 관건이다.
• 증강: Albumentations·Mosaic·MixUp·Copy-Paste. 단, 카메라 ISP 특성(노이즈·왜곡)을 넘어서는 과한 증강은 도메인 시프트를 유발하므로 검증셋으로 효과를 측정.

오토라벨링 (모델 인더루프)

수동 라벨링 비용을 줄이는 핵심은 파운데이션 모델을 라벨러로 쓰는 것이다.

• Grounding DINO(Apache 2.0): 자연어 프롬프트로 임의 객체를 검출하는 zero-shot detector. 박스 자동 생성에 사용.
• SAM / SAM 2(Apache 2.0): 박스/포인트 프롬프트를 정밀 마스크로 변환. SAM 2는 비디오 추적까지 지원해 영상 라벨링에 유리. 단, SAM 3는 Apache가 아닌 별도 SAM License이므로 상용 적용 전 약관 검증 필수.
• Grounded SAM / Autodistill(Apache 2.0): "Grounding DINO로 박스 → SAM으로 마스크 → YOLOv8/DETR 등 경량 타깃 모델 학습"을 한 번에 수행. 사람은 검수·교정(human-in-the-loop)만 담당해 처리량을 수배 높인다.

권장 워크플로: 오토라벨 → 신뢰도 임계로 자동/검수 분기 → 저신뢰 샘플만 사람 검수 → 합의 라벨로 재학습.

합성 데이터 & 도메인 랜덤화

실수집이 어려운 위험 시나리오(보행자 충돌 직전 등)는 시뮬레이터로 보강한다.

• NVIDIA Isaac Sim + Replicator / Omniverse: 물리 기반 렌더링 + 프로그래머블 도메인 랜덤화(조명·텍스처·포즈·배경)로 픽셀 단위 정답을 자동 생성. NVIDIA 사례에서 합성데이터 반복 정제 + 도메인 랜덤화로 실제 테스트 AP가 **5% → 87%**까지 개선된 보고가 있다.
• 자율주행은 CARLA(MIT), 로보틱스/사용자추종은 Isaac Sim이 자주 쓰인다. 핵심은 sim-to-real 갭을 줄이는 랜덤화 폭 튜닝과, 소량 실데이터와의 혼합 학습이다.

데이터 품질 · 편향 · 엣지케이스

• 품질: 라벨 오류·클래스 불균형·노이즈가 실패의 주원인. cleanlab류로 라벨 오류 자동 탐지, IoU/합의율 기반 라벨러 간 일치도(IAA) 모니터링.
• 편향: 수집 과정의 지역·시간대·인구 분포 편중을 슬라이스별 mAP로 점검(예: 야간 보행자, 소수 클래스). 슬라이스 성능 격차를 KPI로 관리.
• 엣지케이스: 배포 모델의 오탐/미탐을 자동 마이닝해 데이터셋에 재투입하는 루프 구축.

라벨링 툴 비교

선택 기준: 3D/비디오·온프레미스 → CVAT, 멀티모달·커스텀 ML 루프 → Label Studio, 빠른 PoC·엔드투엔드 → Roboflow.

데이터/모델 버전관리 (MLOps)

• DVC(Apache 2.0): Git과 연동해 대용량 데이터·모델·파이프라인을 버전 관리. 데이터 해시로 재현성 확보.
• MLflow(Apache 2.0): 실험 추적·모델 레지스트리·배포 관리.
• 실무 패턴: DVC(데이터/모델 버전) + MLflow(실험/레지스트리) 조합으로 "어떤 데이터 스냅샷 → 어떤 모델 → 어떤 mAP/FPS"의 리니지를 추적. 온디바이스 배포 모델은 데이터 버전·증강 설정·양자화 파라미터까지 함께 태깅해야 회귀 추적이 가능하다.

모델 파인튜닝 & 도메인 적응

온디바이스 환경(스마트폰·자율주행)은 조명·날씨·카메라 화각·대상 분포가 학습 데이터와 달라, 사전학습 모델을 타깃 도메인에 적응시키는 단계가 정확도를 좌우한다. 핵심은 적은 데이터·연산으로 일반화 성능을 유지하며 도메인 격차를 줄이는 것이다.

전이학습 & 헤드 교체

가장 기본 전략은 COCO/ImageNet 등으로 사전학습된 백본을 재사용하고 태스크별 헤드만 교체·재학습하는 것이다.

• 백본 동결(freeze) 깊이가 핵심 변수다. Ultralytics YOLO는 freeze=10(백본 0~9층 동결, 헤드만 학습) 또는 freeze=[0,3,5]로 부분 동결을 지원한다.
• 일반 특징 보존이 필요하면 깊게 동결, 클래스 불균형·도메인 격차가 크면 얕게 동결해 심층을 재학습한다(MDPI 2025 연구: 보편적 최적 깊이는 없음).
• 데이터가 충분하면(수천 장+) 낮은 LR로 전체 미세조정이 유리하나, COCO 같은 원 도메인 성능 보존이 필요하면 헤드·일부 층만 갱신한다.

PEFT: LoRA / QLoRA · 어댑터

VLM 등 수억~수십억 파라미터 모델은 전체 파인튜닝 비용이 크므로 PEFT로 백본을 동결하고 소수 파라미터만 갱신한다.

• SmolVLM은 LoRA/QLoRA로 16GB VRAM 소비자 GPU에서도 TRL로 SFT·DPO 파인튜닝이 가능하다.
• QLoRA는 4-bit 로딩으로 메모리를 크게 줄이면서 LoRA 수준 정확도를 유지하나, 양자화·역양자화로 학습 속도는 다소 느리다.
• 검출에는 YOLO-Adapter 같은 동결 백본 + 컨볼루션 보틀넥 방식이 few-shot에서 전체 파인튜닝 대안이 된다.

태스크별 전략: 검출 · VLM · ReID

• 검출(YOLO 등): 사전학습 가중치 로드 → 헤드 자동 재초기화 → 커스텀 data.yaml로 학습. 도메인 격차가 작으면 백본 동결로 수십 epoch 내 수렴.
• VLM(SmolVLM·Qwen-VL 등): LoRA로 비전 인코더 동결, 언어·프로젝터에 어댑터. few-shot 정보추출/캡셔닝에 효과적이며 프롬프트 포맷 일관성이 중요.
• ReID(OSNet): Market1501 등으로 사전학습 후 타깃 카메라셋에 미세조정. 크로스도메인엔 인스턴스 정규화를 넣은 OSNet-AIN이 일반화에 유리. 추적기(ByteTrack은 경량·단일카메라, BoT-SORT는 모션보정+ReID로 멀티카메라·고밀도)와 결합한다.

소량 · Few-shot 적응

• 라벨이 수십~수백 장이면 얕은 헤드만 또는 LoRA(낮은 rank)로 제한해 과적합을 억제한다.
• 합성·증강 데이터(in-domain synthesis), Mosaic·copy-paste, 강한 augmentation으로 유효 표본을 늘린다.
• ReID는 라벨이 없을 때 UDA(비지도 도메인 적응)·의사라벨(pseudo-label) + 대조학습으로 타깃 도메인 라벨 의존도를 낮춘다.

도메인 적응 · 증분학습 · 오버피팅 방지

• 증분/연속학습의 최대 난제는 **파국적 망각(catastrophic forgetting)**이다. 새 데이터만 순진하게 학습하면 기존 지식이 소실된다.
• 완화책: 리허설(소량 버퍼 재생), 직교 부분공간 제약(기존 표현과 직교한 차원으로만 갱신 → 망각 ≈0), EWC식 정규화, 동결 + 어댑터 분리.
• 오버피팅 방지: 검증셋 분리, early stopping, 낮은 LR·작은 epoch, weight decay·드롭아웃, mAP/Rank-1 등 도메인 지표로 조기 평가. YOLOv8은 적절한 파인튜닝 시 COCO 성능을 보존할 수 있음이 보고됨.

온디바이스 개인화(on-device adaptation)

• 사용자/차량별 데이터로 단말에서 직접 적응해 프라이버시·지연을 개선. 단, 전력·메모리·발열 제약이 크다.
• 실무 패턴: 백본 동결 + LoRA/어댑터만 온디바이스 갱신(수 MB 업데이트), forward-only·redundancy-aware 연속학습으로 역전파 비용 절감, 야간 충전 시 배치 미세조정.
• 트레이드오프: 잦은 개인화는 망각·드리프트 위험 → 주기적 서버 재학습·검증과 병행하는 하이브리드가 안전하다.

모델 경량화 — 양자화·프루닝·증류·NAS

온디바이스 배포에서 모델 크기·지연·전력은 정확도와 직접 충돌한다. 경량화는 양자화·프루닝·증류·NAS(효율 백본) 의 네 축이며, 실제 가속은 결국 타깃 하드웨어(NPU, ANE, GPU, DSP) 커널이 무엇을 지원하느냐로 결정된다.

양자화 (Quantization)

• PTQ vs QAT: PTQ는 캘리브레이션 데이터 수백 장만으로 적용 가능해 가장 널리 쓰인다. QAT는 학습 비용이 들지만 거의 항상 더 높은 정확도를 내며 4-bit 등 공격적 정밀도엔 사실상 필수. NVIDIA는 QAT로 INT8에서 FP32에 근접한 정확도를 보고한다.
• INT8/INT4: INT8은 FP32 대비 크기 약 1/4로 표준 베이스라인. INT4는 가중치에 한해 트레이드오프가 우수해 LLM/VLM 가중치 압축에 확산 중.
• per-tensor vs per-channel: 활성값은 per-tensor, 가중치는 per-channel(채널별 스케일) 을 써야 손실을 최소화. TensorRT 암시적 양자화는 가중치를 per-channel로 처리.
• 실전: YOLO11n은 TensorRT INT8 익스포트를 지원, Jetson Orin Nano급 추론 약 3~4ms. YOLO11은 depthwise conv 축소·가중치 분포 정규화로 INT8 정확도 저하를 완화하도록 설계됐다.

프루닝 (Pruning)

• 비구조적: 임의 가중치 0. 표준 HW에서 거의 무가속(약 0.5~1.3배), 전용 sparse 커널 필요.
• N:M 반구조적: 2:4 등. Ampere 이후 GPU sparse tensor core에서 약 2배, 정확도 보존 양호.
• 구조적: 채널/필터 제거. 범용 HW에서도 즉시 1.5~2배, 재학습 권장.

모바일 NPU/CPU 타깃은 구조적 프루닝이 정석, NVIDIA GPU는 2:4 sparsity로 약 2배. 프루닝 후 INT4 결합 시 LLaMA-7B 약 4.7배 압축 사례가 보고된다.

지식 증류 (Knowledge Distillation)

큰 teacher의 soft logit·중간 특징을 작은 student로 이전하며, 검출·세그멘테이션에선 백본 교체와 결합한다. MobileSAM은 SAM의 ViT-H 인코더(611M)를 TinyViT(5M) 로 교체·증류해 전체 615M에서 9.66M, 인코더 452ms에서 8ms(전체 약 12ms/이미지)로 단축. 라이선스 Apache-2.0.

NAS·효율 백본

• MobileNetV3: 하드웨어 인지 NAS와 NetAdapt 채널 미세조정의 하이브리드. Large는 ImageNet top-1 75.2%, 약 5.4M 파라미터, Pixel CPU에서 V2 대비 지연 약 20% 감소. Small은 2.5M로 저전력 적합.
• EfficientViT (MIT-Han-Lab): 멀티스케일 선형 어텐션으로 고해상도 dense prediction에서 동일 정확도 대비 다양한 HW에서 큰 속도 향상. B0~B3(엣지)·L(클라우드). Apache-2.0. EfficientViT-SAM 등으로 모바일 세그멘테이션 실현.

하드웨어 인지 최적화

• Apple ANE/CoreML Tools: Neural Engine에선 팔레타이제이션(1~8bit) 이 메모리·지연 이득에 가장 유리, per-channel scale 권장. iOS 18부터 4-bit block-wise 양자화·그룹 채널 팔레타이제이션 지원, iPhone 14 Pro Max에서 4-bit 모델 5~30% 개선 보고.
• Android LiteRT(구 TFLite)/NNAPI: GPU delegate가 INT8 모델 지원. Google은 NNAPI에서 Play Services 기반 LiteRT로의 마이그레이션을 안내 중이라 신규 프로젝트는 LiteRT 우선.
• NVIDIA TensorRT(Jetson 자율주행): INT8/FP8/INT4/FP4 PTQ·QAT, 2:4 sparsity 통합 지원.
• Qualcomm Hexagon NPU: 모바일 DSP/NPU 경로로 INT8 모델 타깃.

선택 기준: (1) INT8 PTQ로 기준선 확보, (2) 정확도 미달 시 QAT·per-channel·혼합정밀도, (3) 지연 예산 필요 시 구조적 프루닝/경량 백본 교체, (4) 정확도 회복은 증류로. 모든 단계는 타깃 디바이스에서 직접 지연을 측정(NAS의 NetAdapt 방식) 하며 Pareto 프론티어를 따라가는 것이 핵심이다.

시뮬레이터 & 합성 데이터 — 비전부터 자율주행까지

실차·실기기 데이터 수집은 비싸고 위험하며 롱테일(야간·악천후·사고 직전) 라벨이 절대 부족하다. 시뮬레이터는 픽셀-퍼펙트 GT 라벨(2D/3D 박스, 세그멘테이션, 뎁스, 광류)을 무한 생성하고, 무엇보다 에이전트의 의사결정이 환경에 되먹임되는 폐루프(closed-loop) 평가를 제공한다.

비전/멀티모달 합성 데이터 생성

게임 엔진 기반 파이프라인이 표준이다.

• Unity Perception(Apache 2.0): 2D/3D 검출·세그·키포인트 GT를 박스아웃으로 제공. 레퍼런스 프로젝트 SynthDet은 63종 grocery 객체를 도메인 랜덤화로 렌더해 합성만으로 2D 검출기를 학습시키는 엔드투엔드 예시.
• NVIDIA Omniverse Replicator / Isaac Sim(Apache 2.0, 현행 v6.0.1, 2026-06): USD 기반 RTX 패스트레이싱으로 물리 정확 합성 데이터를 생성. 단, 배포용 Omniverse Kit은 별도 NVIDIA 라이선스(Enterprise 구독)가 필요하니 주의.
• Unreal Engine 5: CARLA·Project AirSim·DRIVE Sim의 공통 렌더 백엔드. UE는 자체 EULA(런타임 로열티 무료, 게임 매출 100만 달러 초과 시 5% 로열티 — 비게임 사용엔 시트 라이선스).

핵심은 도메인 랜덤화(domain randomization): 조명·텍스처·카메라 포스트프로세싱·객체 배치를 과하게 흔들어 실세계를 분포의 한 샘플로 만든다. VLM 학습용 합성 캡션/QA는 시뮬레이터의 씬 그래프(객체 위치·관계)에서 자동 추출해 환각 없는 GT 멀티모달 쌍을 만들 수 있다.

자율주행 시뮬레이터 비교

선택 기준: 예산·오픈성 우선이면 CARLA, 고충실도 센서 합성/로보틱스면 Isaac Sim, 양산 AV 검증·NVIDIA 스택 통합이면 DRIVE Sim.

센서 모델링 (카메라·LiDAR·IMU)

충실도 차이가 sim2real을 좌우한다.

• 카메라: 단순 핀홀이 아니라 모션블러·롤링셔터·렌즈 왜곡·HDR/톤매핑·LED 플리커까지. DRIVE Sim/Isaac Sim은 RTX 패스트레이싱으로 물리 기반 렌더.
• LiDAR: 레이캐스트에 빔 발산·강도(intensity)·드롭아웃·이중 반사·도플러를 추가해야 실 포인트클라우드 분포에 근접. 디지털 트윈에 실측 지오메트리·센서 사양·배치를 반영한 HiFi-DT 접근이 LiDAR sim2real 갭을 크게 줄인다.
• IMU: 바이어스 드리프트·축 정렬 오차·노이즈 밀도를 모델링해야 VIO/VSLAM 학습·검증에 유효.

sim2real 갭 & 도메인 적응

합성으로 학습한 모델은 도메인 시프트로 실측 mAP가 떨어진다. 대응 두 축:

• 도메인 랜덤화: 분포를 넓혀 강건성 확보(추가 실데이터 불필요, 단 구조화된 BEV/멀티채널엔 한계).
• 도메인 적응: CycleGAN 류 이미지 변환, DANN 류 적대적 특징 정렬 — 실데이터·재학습 비용이 큼. 최근엔 **확산 모델(diffusion)**로 주야·날씨·계절을 가로질러 적응 표현을 학습하는 방향이 부상.
  실무 권장: 합성 80~90% + 실데이터 10~20% 혼합 + 도메인 랜덤화 + 마지막 미세조정으로 격차를 메우고, 커리큘럼/지식증류를 반복한다.

시나리오 생성 & 폐루프 평가

오픈루프(녹화 재생)는 결정이 세계에 영향을 못 줘 인과 오류를 놓친다. 폐루프가 필수다.

• CARLA Leaderboard 2.x: 핵심 지표 Driving Score = Route Completion × Infraction Penalty. CARLA 0.9.14 기준 SENSORS/MAP 두 트랙, NHTSA 프리크래시 유형 기반 시나리오, 학습 90개 루트(약 780.6 km)·검증/테스트 각 20개 루트로 구성.
• 시나리오는 OpenSCENARIO/시나리오 DSL로 파라미터화하고, 적대적·롱테일 케이스를 절차적으로 생성해 커버리지를 끌어올린다. DRIVE Sim 계열은 신경 재구성(neural reconstruction)으로 녹화 데이터를 반응형 폐루프 월드로 전환한다.

실무 팁: 합성 학습 → 도메인 적응 → 폐루프 회귀(regression) 게이트를 CI에 넣어, Driving Score가 임계치 미만이면 온디바이스 배포를 차단하라.

자율주행 온디바이스 & 물리(Physical) 모델

인지: BEV와 Occupancy 표현

카메라/LiDAR 입력을 Bird's-Eye-View(BEV) 격자나 3D Occupancy 복셀로 투영하는 것이 현대 인지 스택의 사실상 표준이다.

• BEVFormer(카메라 전용, Apache-2.0): 시공간 트랜스포머로 nuScenes test에서 NDS 56.9% 달성, LiDAR 베이스라인과 동급.
• BEVFusion(MIT, MIT-Han-Lab): 카메라+LiDAR 통합 BEV로 SOTA 대비 mAP·NDS +1.3%, BEV 맵 분할 mIoU +13.6%를 연산 1.9× 절감하며 달성. NVIDIA DeepStream에 통합됨.
• Occupancy: 동적/비정형 장애물(쓰러진 화물, 미분류 물체)을 박스 없이 표현. TPVFormer(Apache-2.0)는 Tri-Perspective View로 Tesla OccNet의 학술 대안을 제시. Occ3D/SurroundOcc로 dense 라벨 확장.

선택 기준: 박스 기반 3D 검출은 효율적이나 long-tail 장애물에 취약 → occupancy는 안전 마진을 높이지만 복셀 해상도(0.4m vs 0.2m)에 따라 메모리·지연이 급증. 양산은 BEV 검출 + 저해상도 occupancy 병행이 일반적.

모듈러 vs End-to-End

성능 트레이드오프: VAD-Base는 UniAD 대비 계획 변위오차 -30.1%, 충돌률 -29.0%. SparseDrive는 L2 0.58m, 충돌률 **0.06%**로 VAD 대비 충돌률 -71.4%. E2E는 누적 오차·해석성 약화가 단점이라, 양산은 학습 가능한 E2E 백본 + 규칙기반 안전 폴백(fallback planner)을 결합한다.

월드 모델 · 물리/동역학 모델

월드 모델은 (상태, 행동)→미래 관측을 예측해 시뮬·데이터 증강·정책 학습에 쓰인다.

• Wayve GAIA-1: 비디오·텍스트·행동 조건 생성 월드 모델, 9B 파라미터로 스케일.
• GAIA-2: latent diffusion 기반 멀티뷰 일관 생성, ego 동역학·에이전트·도로 시맨틱 제어, 약 2,500만 시퀀스(UK/US/DE) 학습. 코너 케이스 합성으로 검증 커버리지 확대.

물리/동역학: 차량 모델은 단순 kinematic bicycle에서 타이어 슬립을 반영한 dynamic bicycle까지. 계획은 동역학적으로 실현 가능한(곡률·가가속도 제약) 궤적만 생성해야 하며, 시뮬레이터의 물리엔진(PhysX 등)이 이를 강제한다.

시뮬레이터 · 검증 루프

• CARLA(코드 MIT, 에셋 CC-BY; 최신 0.9.16): 도시 주행·센서·시나리오 표준. NVIDIA Omniverse 연계로 SimReady 에셋 확장.
• NVIDIA Isaac Sim(Apache-2.0 + Omniverse 라이선스): GPU 가속 물리·합성 데이터, NuRec(Gaussian Splatting)로 실주행 장면 재구성. 단, Omniverse Kit 재배포는 별도 엔터프라이즈 라이선스 필요.

개발 방법론: 실주행 데이터 수집 → 자동/4D 오토라벨링 → 모델 학습 → CARLA/Isaac + 월드모델로 시나리오 재생·코너케이스 합성 → 개루프(L2/mAP)·폐루프(충돌·route completion) 평가 → 차량 섀도 모드 → OTA. 폐루프 평가가 개루프보다 실제 주행성과와 상관이 높다는 점이 핵심.

임베디드 배포 · 안전 · 실시간 제약

Orin은 L9 등에서 듀얼(508 TOPS)로, Thor는 단일칩 Orin-X 8×로 BEV+occupancy+E2E를 동시 구동. 배포는 TensorRT INT8 양자화·레이어 퓨전이 필수이며, **결정론적 지연(deterministic latency)**과 ISO 26262 ASIL-D, end-to-end 지연 <100ms(통상 인지 10–20Hz) 충족이 모델 선택을 지배한다. 양자화로 mAP 손실(<1–2%)과 안전 마진을 트레이드오프하며, 안전 critical 경로는 이중화·MISRA C 규칙 기반 모니터로 백업한다.

정책 학습 — 모방학습·강화학습(PPO)·온디바이스 Physical AI

정책 학습(policy learning)은 비전 지각 결과를 입력받아 모터 제어 명령을 출력하는 함수 π(a|s)를 학습하는 단계로, 온디바이스 비전·멀티모달 파이프라인의 마지막 지각→정책→제어 루프를 닫는다. 크게 전문가 시연을 모사하는 **모방학습(IL)**과 보상을 최적화하는 **강화학습(RL)**으로 나뉜다.

모방학습: BC → DAgger → ACT → Diffusion Policy

**행동복제(Behavioral Cloning, BC)**는 상태→행동 매핑을 지도학습(MSE 손실)으로 푸는 가장 단순한 방식이다. 구현이 쉽지만 정책이 학습 분포 밖 상태로 진입하면 오차가 누적되는 분포 시프트(covariate shift) 문제가 있다. DAgger는 정책이 실제 방문한 상태에서 전문가 라벨을 추가 수집·재학습해 이를 완화하지만, 실행 중 전문가가 상주해 실시간 교정을 해야 해 비용이 크다.

최근 표준은 행동 청킹과 다중모드 표현이다. **ACT(Action Chunking Transformer, Stanford 2023)**는 CVAE를 다중헤드 어텐션 트랜스포머로 구현해 미래 K개 행동을 한 번에 예측한다(전형적으로 50Hz에서 K≈100, 약 2초 분량). 청크 단위 실행→재계획으로 오차가 에피소드 전체가 아니라 청크 내부로만 누적되어 복합 오차를 끊는다. Diffusion Policy는 행동 분포를 디퓨전으로 모델링해, MSE 기반 BC가 여러 모드를 평균내어 망가지는 멀티모달 문제를 해결한다. 양손 조작 벤치마크에서 ACT·Diffusion·GAIL은 노이즈 섭동에 견고하며 모든 환경에서 높은 보상을 달성해, 탁상 조작의 실무 기본 선택지로 자리잡았다.

강화학습(PPO): on-policy + GAE + MLP 정책망

**PPO(Proximal Policy Optimization)**는 로보틱스에서 가장 널리 쓰이는 on-policy 알고리즘이다. 액터(정책)–크리틱(가치) 구조에서 클리핑된 대리목적으로 정책 갱신을 안정화하고, **GAE(Generalized Advantage Estimation)**로 어드밴티지를 지수가중 추정해 편향–분산을 절충, 낮은 분산·낮은 편향의 안정적 학습 신호를 준다.

PPO가 소형 MLP 정책망과 잘 맞는 이유:

• on-policy의 데이터 갈증을 병렬 시뮬로 해소: PPO는 매 갱신마다 현재 정책의 신선한 롤아웃이 필요해 샘플 효율이 낮지만, GPU 병렬 시뮬이 초당 수십만 스텝을 공급해 단점을 상쇄한다.
• 추론 속도가 곧 학습 처리량: 작은 MLP(예: [512,256,128] 규모)는 수천 환경에서 동시에 빠르게 forward되어 롤아웃이 저렴하다.
• 저차원 상태(관절각·속도·IMU·명령) 입력에는 트랜스포머보다 MLP가 충분하며, 그대로 임베디드 실시간 추론으로 이어진다.

Isaac Gym / Isaac Lab 대규모 병렬 학습이 이를 뒷받침한다. RTX 4090 단일 GPU에서 1,000개 휴머노이드 환경, ANYmal류에서 16,384 에이전트 시 초당 약 150K 환경 스텝의 처리량이 보고된다. RSL-RL·rl_games 같은 라이브러리는 PPO를 GPU 병렬 환경에 결합해, 과거 대규모 CPU 클러스터가 필요했던 사족·휴머노이드 보행을 단일 GPU에서 수십 분~수 시간에 학습한다.

sim2real과 도메인 랜덤화

시뮬레이션 정책을 실물로 옮기는 sim2real의 핵심 도구가 **도메인 랜덤화(domain randomization)**다. 질량·마찰·지연·센서 노이즈·지형 등 물리 파라미터를 학습 중 무작위화해 정책을 한 시뮬에 과적합시키지 않고 실물 분포를 포괄하게 만든다. NVIDIA Isaac Lab은 PhysX 고정밀 물리, 타일드 렌더링, 도메인 랜덤화를 묶어 제로샷 배포를 지향한다. 실제로 Boston Dynamics는 Isaac Lab에서 학습한 Spot 보행 정책을 Jetson AGX Orin에 그대로 올려 추론한다.

모방학습 vs 강화학습(PPO) 비교

보상 설계는 RL의 실질적 병목이다. 추종 보상(목표 속도)·정칙화(에너지·관절 한계·접촉)·생존 보너스를 합성하고, 커리큘럼으로 점진 난이도를 올린다. 실무에서는 IL로 초기화 후 RL로 미세조정하거나, RL 교사 정책을 IL로 증류하는 하이브리드가 흔하다.

온디바이스 Physical AI: 소형 정책·VLA·world model

배포 단계에서 소형 MLP 정책은 Jetson Orin/Thor에서 50Hz 이상으로 실시간 추론된다(예: GR00T 기반 시스템에서 운동 계획 약 12ms/패스, 정책 루프 50Hz). 정책망이 작아 양자화 없이도 임베디드 제약을 만족한다.

반면 **VLA(Vision-Language-Action)**는 일반화 능력을 위해 대형이다. RT-2는 약 55B 파라미터, OpenVLA는 970k 에피소드(Open X-Embodiment)로 학습한 7B 모델로 Llama2 + DINOv2/SigLIP 비전 인코더를 융합한다. OpenVLA는 RT-2-X(55B) 대비 7배 적은 파라미터로 29개 과제 성공률을 16.5%p 앞서며, 양자화·LoRA로 자원 제약 배포를 지원한다. NVIDIA의 Isaac GR00T(휴머노이드 파운데이션 모델), Cosmos world model(합성 궤적·정책 평가)은 이 흐름의 플랫폼화를 보여준다.

선택 기준: 저차원 상태·고주파 제어(보행)는 PPO+소형 MLP 온디바이스 추론, 멀티태스크·언어조건 조작 일반화는 VLA, 데이터 부족 보완은 world model 기반 합성 궤적이다.

파이프라인·평가·안전

전형적 파이프라인은 데이터/시뮬 → 학습(IL/PPO) → 도메인 랜덤화 → sim2real → 온디바이스 배포 → 모니터링이다. 평가는 시뮬 성공률뿐 아니라 실물 제로샷·섭동 강건성·추론 지연(latency)·주파수 충족 여부를 함께 본다. 안전 측면에서는 토크/속도 클램핑, 폴백 제어기, 분포 외 입력 감지, 사람 근접 시 정지 같은 가드레일을 정책 출력 단에 둔다.

온디바이스 런타임 & 배포 스택

학습된 객체탐지·VLM·재식별(ReID) 모델을 폰/차량 SoC에서 실시간으로 돌리려면 "어떤 런타임 + 어떤 가속 백엔드"의 조합이 성능과 라이선스를 동시에 좌우한다. 모델 정확도(mAP)는 PC에서 결정되지만, 체감 FPS·지연·발열은 이 스택에서 결정된다.

추론 런타임 선택

선택 기준

• iOS 단독: Core ML이 ANE를 자동 활용해 INT8에서 최저 전력. 단 변환 의존.
• Android·임베디드 통합: LiteRT가 델리게이트/양자화 툴 성숙도, NPU 통합(Qualcomm·MediaTek 등) 측면에서 가장 무난하고 런타임 풋프린트가 작다.
• PyTorch 자산 그대로: ExecuTorch는 변환·재작성 없이 .pte로 떨궈 객체탐지·세그멘테이션·온디바이스 (V)LM까지 검증됨. PyTorch 네이티브가 강점.
• C++ 경량·소형 vision 모델: ncnn(무의존, BSD)·MNN이 YOLO류 배포에 흔히 쓰임.
• Jetson/자율주행: TensorRT가 사실상 표준(예: YOLOv8n FP16에서 ~4.3ms/233 FPS급). 단 코어가 독점이라 상용 출하 전 라이선스 확인 필수.

모델 변환 & ONNX 함정

PyTorch→ONNX→타깃이 가장 흔한 경로지만 함정이 많다.

• 레이아웃: ONNX/PyTorch는 NCHW, LiteRT/TFLite는 NHWC. 변환 시 transpose가 삽입되어 불필요한 오버헤드·정확도 드리프트 유발 → 변환 후 그래프 점검 필수.
• opset 버전: 변환기 기본 opset(예: tf2onnx 기본 15)과 타깃 런타임 지원 opset 불일치 시 로드 실패. opset을 명시 고정.
• 연산자 커버리지: 미지원 op(예: NMS 변형, 동적 shape, grid_sample) 발견 시 델리게이트가 통째로 CPU 폴백하거나 로드 실패. NNAPI 신델리게이트는 per-op 폴백을 지원하지만 그래프가 잘게 쪼개지면 오히려 느려진다.
• 동적 입력: VLM/시퀀스 모델의 가변 길이는 많은 모바일 델리게이트에서 미지원 → 고정 shape로 export 권장.

델리게이트·가속

LiteRT는 델리게이트로 하드웨어를 추상화한다: GPU 델리게이트(Android는 OpenGL/OpenCL·Vulkan, iOS는 Metal), NNAPI/NPU 델리게이트, Core ML 델리게이트. 모든 op이 한 가속기에 매핑돼야 효과가 크며, 부분 매핑 시 CPU 왕복 비용이 이득을 잠식한다. INT8 양자화는 NPU/ANE의 전제 조건에 가깝고(전력·속도 모두 유리), vision 태스크 대부분에서 거의 무손실로 적용된다.

벤치마킹·프로파일링

• 표준: MLPerf Mobile(mlcommons/mobile_app_open)로 벤더 비교.
• 런타임 내장: LiteRT benchmark tool, Core ML Instruments(Xcode), ORT 프로파일러로 op별 지연·델리게이트 폴백 위치 확인.
• 함정: 콜드 스타트(델리게이트 컴파일 수백 ms~초)와 워밍업 후 스루풋을 분리 측정. 단발 FPS가 아니라 지속(sustained) FPS를 봐야 한다.

배터리·열 관리

지속 추론에서 발열이 1차 제약이다. 측정 연구에서 iPhone 16 Pro는 2회 추론 내 스루풋의 ~44%를 잃고 테스트의 65% 구간에서 그 저하가 유지되며, S24 Ultra는 OS가 GPU 주파수를 강제로 낮춰 약 6회 후 추론이 종료되는 사례가 보고됐다. 대응: INT8/저정밀로 전력 절감, 프레임 스킵·해상도 적응, NPU 우선 라우팅, 듀티 사이클링, 백그라운드 스로틀링.

모델 OTA 업데이트

비전 모델은 수 MB~수백 MB라 전량 재다운로드는 비용이 크다. 델타(차분) 업데이트로 버전 간 차이만 전송해 대역폭·시간을 절감하고, 백그라운드 다운로드 + 포그라운드 설치, 네트워크·배터리·기기 상태를 보는 적응형 스로틀링, 단계적 롤아웃(canary)과 서명·롤백을 갖춘다. 차량(connected vehicle) OTA는 안전 관점에서 A/B 파티션과 서명 검증이 사실상 필수다.

상용화 라이선스 검토

온디바이스 비전·멀티모달 제품에서 가장 큰 법적 리스크는 AGPL-3.0 카피레프트의 전염성이다. 모델·툴마다 라이선스가 제각각이므로, "성능이 좋아서"가 아니라 "출시 모델에 묶어 배포할 수 있는가"를 기준으로 선택해야 한다.

컴포넌트별 라이선스 한눈에 보기

AGPL/카피레프트 리스크 (가장 중요)

Ultralytics YOLO는 AGPL-3.0다. 코드·아키텍처·학습 파이프라인뿐 아니라 사전학습 가중치와 파인튜닝한 가중치까지 카피레프트 대상으로 본다(Ultralytics License). AGPL은 GPL의 "네트워크 서비스 구멍"을 막은 라이선스라, 앱에 바이너리를 배포하지 않고 서버 API로만 제공해도 전체 파생 저작물의 소스 공개 의무가 발동한다. 즉 사내용·SaaS·앱 임베드 어디든 폐쇄형으로 쓰려면 유료 Enterprise License가 필수다.

• YOLO11n은 약 2.6M 파라미터, COCO mAP50-95 ≈ 39.5로 경량 엣지에 매력적이지만, 라이선스 비용·소스 공개 중 하나를 감수해야 한다.
• 대안: RF-DETR(Apache-2.0)로 교체. RF-DETR-Nano(30.5M)~Large 계열은 Apache-2.0이며, RF-DETR-L은 COCO 56.5 AP를 T4·TensorRT FP16 6.8ms에 달성한다(Roboflow blog). 단 RF-DETR+ (XL/2XL)는 PML-1.0로 Roboflow 계정과 약관 동의(accept_platform_model_license=True)가 필요하니 코어(Apache) 모델로 한정하라(rf-detr README).

데이터셋·가중치 라이선스

라이선스는 코드 따로, 가중치·학습데이터 따로 봐야 한다.

• COCO 사전학습 가중치는 보통 코드 라이선스를 따르지만, COCO 이미지 자체는 Flickr 원저작권 + CC BY 4.0 주석이라 데이터 재배포에 주의.
• ImageNet 사전학습은 연구용 약관이 붙는 경우가 많아 상용 가중치는 출처 확인 필수.
• SmolVLM(256M·500M·2.2B)은 모델·데이터셋·레시피 전부 Apache-2.0으로 공개돼 상용 파인튜닝에 깔끔하다(SmolVLM-Instruct). 단 파인튜닝 데이터(예: 합성 캡션)가 GPT 계열 출력이면 모델 산출물 사용 약관이 별도로 적용될 수 있다.

VSLAM/AR·시뮬레이터 주의점

• stella_vslam(2-clause BSD)·RTAB-Map(BSD-3): 코어는 관대하지만 의존 라이브러리에 함정이 있다. RTAB-Map은 OpenCV nonfree(SIFT/SURF) 모듈을 끄면 BSD로 안전하나, 켜면 특허 이슈가 붙는다(rtabmap LICENSE). stella_vslam도 원조 OpenVSLAM이 ORB-SLAM2 유사성 논란으로 한때 GPL 전환을 검토한 이력이 있으니 사용 버전의 라이선스를 고정 확인하라.
• CARLA는 MIT이지만 동봉 에셋(SimReady·Omniverse 연동분)은 별도 약관일 수 있다.
• Isaac Sim은 코드가 Apache-2.0이나, 제3자에게 재배포하거나 서비스로 제공하면 NVIDIA AI Enterprise 라이선스가 필요하다. 시뮬 산출물(영상·데이터셋)만 판매하면 불필요(License FAQ). DRIVE Sim은 공개 OSS가 아닌 NVIDIA 상용 약관 대상이다.
• ARCore/ARKit는 OSS가 아니라 플랫폼 SDK로, 각각 Google/Apple 개발자 약관 하에서만 사용한다.

상용 배포 체크리스트

1. AGPL 격리: YOLO(AGPL)·rf-detr_plus(PML) 등 비-Apache 컴포넌트가 출시 바이너리·서버에 링크돼 있는가? 있으면 교체 또는 유료화.
2. 런타임 확인: ONNX Runtime(MIT)·LiteRT(Apache-2.0)·Core ML EP는 폐쇄배포 무난.
3. 가중치 출처: 각 체크포인트의 학습데이터·산출물 약관까지 추적(데이터 라이선스 ≠ 코드 라이선스).
4. 의존성 스캔: OpenCV nonfree, GPL 트랜시티브 의존, 시뮬 에셋 약관 점검.
5. 추천 폐쇄형 스택: RF-DETR(core)+SmolVLM+OSNet+RTAB-Map(nonfree off)+CARLA+ONNX Runtime/LiteRT — 전부 Apache/MIT/BSD로 소스 공개 의무 없이 상용 가능.