Jetson 양산 OS 개발기 ① · 바이코드(ByCode)
잘 돌아가던 개발 키트, 그대로 1,000대를 만들 수 있을까
NVIDIA Jetson Orin Nano 개발 키트로 시제품을 만들었다고 하자. CUDA도 잘 돌고, 추론도 잘 된다. 이제 양산 차례다. 1,000대를 만들어 현장에 내보내야 한다.
가장 쉬운 길은 개발하던 그 이미지를 그대로 굽는 것이다. JetPack을 설치한 그 Ubuntu 그대로. 그런데 정말 그래도 될까?
이 글은 그 질문에서 시작한다. 우리는 Jetson Orin Nano를 양산용 경량 Edge OS로 만드는 과정을 기록하고 있다. 이 시리즈는 그 개발기다. 첫 편의 주제는 단순하다. 왜 개발용 JetPack 이미지를 양산에 그대로 쓰면 안 되는가.
JetPack은 훌륭한 ‘개발’ 이미지다 — 바로 그게 문제다
JetPack은 Ubuntu 위에 CUDA 툴킷, cuDNN, TensorRT, VPI, 각종 샘플, 데스크톱 환경까지 한 번에 얹어 준다. 개발 단계에선 더없이 편하다. 필요한 게 전부 들어 있으니까.
문제는 양산 제품이 필요로 하는 게 정반대라는 점이다. 양산 장비에 필요한 건 “개발에 필요한 모든 것”이 아니다. “현장에서 실제로 도는 것”뿐이다. 개발을 편하게 해 주던 그 풍성함이, 양산에선 고스란히 부채가 된다.
숫자로 본 격차 (직접 측정)
말로만 하면 추상적이다. 그래서 직접 재 봤다. 동일한 L4T R36.5.0 베이스 위에서, 스톡 JetPack과 우리 Yocto OS의 rootfs 실사용 용량을 측정했다.
| 이미지 | rootfs 실사용 | 무엇이 들어 있나 |
|---|---|---|
| 스톡 JetPack (base L4T) | 7.8 GB | OS + GPU 드라이버 |
| 스톡 JetPack (풀 SDK) | 21 GB | + CUDA·cuDNN·TensorRT·VPI·샘플 |
| 우리 Yocto OS | 약 1.0 GB | OS + GPU 드라이버 (AI 런타임은 컨테이너로) |
(자체 실측, 2026-06. 측정 방법: 부팅 후 du -xsh /, 컨테이너·유저데이터 제외. 셋 다 동일 L4T R36.5.0.)
온디바이스 AI를 돌리려고 CUDA·TensorRT까지 담은 풀 JetPack과 비교하면 약 21배 차이다.
오해를 막기 위해 덧붙인다. CUDA와 TensorRT가 사라진 게 아니다. 컨테이너로 자리를 옮겼을 뿐이다. 그래서 AI 모델이나 런타임을 바꿀 때 OS 전체를 다시 굽지 않는다. 컨테이너만 따로 업데이트한다. (이 컨테이너에서 GPU 추론이 실제로 도는지는 별도로 검증했다 — deviceQuery와 TensorRT 추론 모두 통과.)
덧붙여 분명히 해 둔다. 이 21배는 OS 레이어(rootfs) 비교지, 장비 전체 저장량 비교가 아니다. 컨테이너 이미지도 저장공간을 쓰므로, AI 스택까지 더한 총량이 21배 작다는 뜻은 아니다. 요점은 OS와 앱의 분리다 — OS는 작고·안정적이고·감사 가능한 상태로 두고, 자주 바뀌는 AI 런타임·모델은 별도 레이어로 독립 업데이트한다. 양산·OTA·보안에서 의미 있는 건 바로 이 분리다.
그래서 OS 이미지 크기가 왜 중요한가? 공장에서의 플래시·프로비저닝 시간, 무선 업데이트(OTA) 페이로드, 그리고 보안 점검·인증이 따라붙는 공격 표면 — 이 모든 게 OS 이미지 크기에 비례한다. 1,000대, 10,000대로 가면 그 차이는 그대로 곱해진다.
정직하게 — 부팅 속도는 우리의 차별점이 아니다
여기가 마케팅 글이라면 다음 줄은 “게다가 부팅도 빠릅니다”여야 한다. 그런데 측정해 보니 아니었다. 그래서 그 주장은 하지 않는다.
같은 NVMe에서 전원을 켜고 로그인까지 — 우리 Yocto는 30.7초, 스톡 JetPack은 32.2초였다(각각 3회 중앙값, 자체 실측). 사실상 같다. 이유는 단순하다. 그 시간의 약 18초가 두 이미지가 똑같이 거치는 UEFI 부트로더 펌웨어이기 때문이다.
OS 부분(커널 + 유저스페이스)만 떼어 보면 우리가 13초, JetPack이 15초로 우리가 조금 가볍다. 하지만 헤드라인을 붙일 만한 차이는 아니다.
부팅 단축은 별도 과제로 남겨 뒀다(병목인 UEFI 쪽). 그 전까지 우리는 측정하지 않은 우위를 팔지 않는다. 이 글에서 한 가지만 가져간다면 — 숫자는 직접 재고, 안 나온 우위는 주장하지 않는다는 점이다.
그럼 진짜 문제는 무엇인가 — ‘양산 OS의 규율’
크기도, 부팅도 표면적인 증상이다. 본질은 따로 있다. 양산 OS는 개발 이미지가 공짜로 주지 않는 다음을 갖춰야 한다.
- 최소한의, 감사 가능한 rootfs — 현장에서 도는 것만 담는다. 작을수록 비용·OTA·공격 표면이 함께 줄어든다.
- 재현 가능한 빌드 — 클린 머신에서 문서만 보고도 같은 이미지가 나와야 한다. 우리는 빌드에 쓰인 레이어를 커밋 해시까지 고정해 기록한다.
- 원자적 OTA와 롤백 — 업데이트 중 전원이 끊겨도 장비가 벽돌이 되면 안 된다. A/B 두 슬롯으로 실패 시 되돌린다. (자체 서버가 아니라 검증된 오픈소스 OTA를 통합하는 방향.)
- OS와 분리된 컨테이너 AI — 모델 교체가 OS 재플래시를 요구하지 않게 한다.
- 플릿 운영과 수명주기·보안 책임 — 다가오는 보안 규제까지 포함해, 출고 뒤의 장비를 책임지는 구조.
JetPack을 그대로 구우면 이 중 어느 것도 저절로 따라오지 않는다. 그게 “왜 안 되는가”에 대한 진짜 답이다.
현재 상태를 정직하게 적는다. 우리 v0.1에서 최소 rootfs와 컨테이너 추론은 실측으로 확인했다. 롤백 OTA와 온디바이스 레퍼런스 앱은 지금 개발 중이다. 이 시리즈는 그 과정을 순서대로 공개한다.
“그냥 Yocto 쓰면 되는 거 아냐?”
예상되는 반론이다. 맞는 말이고, 한 가지 사실을 정직하게 덧붙여야 한다. 2026년 6월 JetPack 7.2부터 NVIDIA가 Jetson용 Yocto를 공식 지원하기 시작했다 [1][2]. 그전까지 커뮤니티(OE4T) 중심이던 경로가, 이제 NVIDIA가 보증하는 경로가 됐다 [3]. 그러니 “Yocto를 쓴다”는 것 자체는 더 이상 비법이 아니다. 이제 베이스라인이다.
하지만 NVIDIA가 주는 건 “검증된 레시피로 직접 빌드하라”는 재료다. 완성된 양산 OS가 아니다. 그 레시피에서 출발해 앞 절의 규율(최소 이미지·재현 빌드·롤백 OTA·플릿·보안)을 갖춘 제품 OS로 다듬는 일에 시간과 책임이 든다. 우리가 만드는 가치는 OS 빌드 그 자체가 아니라 그 ‘위’에 있다.
정리, 그리고 다음 편
개발 키트의 이미지와 양산 제품의 OS는 다르다. 그 격차를 메우는 게 우리가 하는 일이다.
다음 편에서는 한 단계 내려간다. meta-tegra로 Orin Nano를 Yocto로 처음 부팅시키는 실제 절차를 0부터 따라간다. 빈 보드에서 첫 로그인 프롬프트까지, 막혔던 지점과 함께 기록한다.
참고 자료
- NVIDIA, Deploy Agentic-Ready AI at the Edge … JetPack 7.2 (2026-06)
- NVIDIA, Yocto on Jetson Platforms (Jetson Linux r39.2, 2026-06-02 갱신)
- OE4T, meta-tegra (커뮤니티 Yocto BSP, JP6.2.2 / L4T R36.5.0)
footprint·부팅 시간 수치는 ByCode 자체 실측(2026-06): rootfs
du -xsh /, 부팅systemd-analyze+ 영상 n=3 중앙값. 동일 L4T R36.5.0 베이스.
이 글은 바이코드가 Jetson 기반 양산용 Edge OS를 만드는 과정을 공개하는 개발기 시리즈의 첫 편입니다.