제9부 로보틱스

9.3 JetPack·L4T II — 컨테이너·배포

9.3.1 이 장에서 배우는 것 / 선수 지식

9.2에서 Jetson을 플래시·부팅했다. 이제 그 위에 애플리케이션을 컨테이너로 배포·운영하는 법을 본다 — 데이터센터(제7부 k8s·6.7 NIM)에서 본 컨테이너의 이점(재현성·의존성 격리·배포 일관)을 엣지 로봇에서. 그러나 엣지 컨테이너는 데이터센터와 결정적으로 다른 점이 있다 — 컨테이너가 호스트의 L4T 드라이버에 결합되고, arm64 아키텍처이며, 수많은 로봇에 OTA로 배포한다. JetPack 묶음(9.2~9.3)의 마무리.

핵심 통찰: 엣지 컨테이너는 호스트 JetPack/L4T 버전에 묶인다 — GPU·DLA 드라이버가 컨테이너가 아니라 호스트(L4T) 에 있고, 컨테이너는 NVIDIA 컨테이너 런타임으로 그것을 쓴다. 그래서 임의의 CUDA 컨테이너나 못 실행하고, 호스트 L4T 버전과 호환되는 L4T 베이스 이미지여야 한다(데이터센터보다 엄격). 그리고 배포는 한두 서버가 아니라 현장의 수많은 로봇이라 플릿 관리·OTA가 핵심이다.

배우는 것:

왜 엣지 컨테이너 — 재현성·격리·배포 일관(데이터센터와 같은 이점, 엣지에서).
L4T 컨테이너 아키텍처 — 호스트 드라이버 결합, NVIDIA 런타임(7.2), L4T 베이스 이미지.
버전 결합 — 컨테이너 CUDA/TensorRT가 호스트 JetPack/L4T와 호환(9.2 확장).
arm64 — Jetson은 aarch64, 데이터센터(x86)와 다른 빌드.
플릿 관리·OTA — 수많은 로봇에 컨테이너·OS 업데이트, A/B 파티션·롤백.
엣지 vs 데이터센터 컨테이너 차이 — arch·드라이버 결합·자원·연결·규모.

선수 지식: 9.2(JetPack/L4T 버전·드라이버)·7.2(nvidia-container-toolkit)·5.11·6.7(Triton/NIM 컨테이너)·6.8(배포·스케일). 전력 운영은 9.4, Isaac은 9.7. 환경은 Jetson·컨테이너.

정직: L4T 베이스 이미지 태그·버전·플릿 도구는 세대·버전·생태계 의존이다 — 이 장은 엣지 컨테이너 아키텍처·배포 개념을 가르치고 구체 태그·도구는 "확인 필요". 컨테이너·OTA·플릿은 임베디드 운영의 일반 개념(다른 엣지도 유사).

9.3.2 왜 엣지 컨테이너 — 데이터센터 이점을 엣지로

컨테이너의 이점(제7부)이 엣지에도 적용된다:

핵심: 엣지에서도 컨테이너는 재현성·격리·배포 일관을 준다 — 특히 수많은 로봇에 동일 환경을 배포하고 OTA로 갱신할 때 결정적. 데이터센터(6.7 NIM·제7부)의 컨테이너 운영이 엣지로 확장되되, 다음 절의 호스트 드라이버 결합·arm64·플릿 차이가 있다.

9.3.3 L4T 컨테이너 아키텍처 — 호스트 드라이버 결합

엣지 컨테이너의 결정적 차이: GPU·DLA 드라이버가 컨테이너가 아니라 호스트(L4T)에 있다.

L4T 베이스 이미지(NGC):

핵심: 엣지 컨테이너는 "앱·라이브러리는 컨테이너, 드라이버는 호스트(L4T)" 다 — NVIDIA 런타임이 호스트 드라이버를 컨테이너에 연결. 그래서 컨테이너의 CUDA/TensorRT 버전이 호스트 L4T(JetPack) 버전과 호환돼야 하고, L4T 베이스 이미지를 그 버전에 맞춰 쓴다. 데이터센터보다 결합이 강하다(9.2 버전 묶음의 컨테이너판).

9.3.4 버전 결합·arm64

버전 결합(9.2 확장):

호스트 L4T를 업그레이드하면 컨테이너 베이스도 그에 맞춰야 한다.

arm64(aarch64) 아키텍처:

데이터센터 x86 이미지를 Jetson에 그대로 못 쓴다(arch 다름).

핵심: 엣지 컨테이너는 arm64로 빌드해야 하고(데이터센터 x86과 다름), 호스트 L4T 버전과 호환돼야 한다. 데이터센터에서 만든 x86 이미지를 Jetson에 그대로 못 쓰고, arm64 + L4T 베이스로 빌드. buildx/멀티아키로 한 번에 빌드하기도. 버전·아키 정합이 엣지 컨테이너의 두 제약.

9.3.5 워크스루 — 컨테이너 실행·빌드

   1) L4T 컨테이너 실행(GPU 사용, NVIDIA 런타임):
      sudo docker run --runtime nvidia -it --rm \
        nvcr.io/nvidia/l4t-base:<tag>           # 호스트 L4T와 매칭되는 태그
      # 안에서: deviceQuery·tegrastats로 GPU 확인 (Jetson은 NVML 없어 nvidia-smi 미지원)
      # CUDA·TensorRT가 호스트 드라이버로 동작

   2) 앱 컨테이너 빌드(arm64, L4T 베이스):
      # Dockerfile
      FROM nvcr.io/nvidia/l4t-base:<tag>        # 호스트 버전 매칭
      RUN apt-get update && ...                  # 앱 의존성
      COPY app /app
      CMD ["/app/run"]
      # Jetson에서: docker build -t myapp:arm64 .
      # 또는 x86 호스트에서 크로스: docker buildx build --platform linux/arm64 ...

   3) TensorRT 엔진은 컨테이너 안에서 Jetson 타깃 빌드(5.2·9.2):
      trtexec --onnx=model.onnx --saveEngine=model.plan --int8 --useDLACore=0 ...

   4) 추론 서빙(엣지 Triton, 5.11):
      Triton을 Jetson에서 실행해 모델 서빙(엣지 추론), 또는 직접 앱

실무: L4T 베이스 이미지(호스트 버전 매칭) + arm64 빌드가 기본. 데이터센터에서 학습한 모델을 arm64 컨테이너에 넣고 Jetson 타깃으로 엔진 빌드(5.2). 엣지 추론 서빙은 Triton을 Jetson에서(5.11) 실행하거나 직접. jtop으로 자원·전력 모니터(9.4).

9.3.6 플릿 관리·OTA

데이터센터는 한 곳의 서버지만, 엣지는 현장의 수많은 로봇이다 — 플릿 관리·OTA가 핵심:

컨테이너 OTA: 앱을 컨테이너로 두면 컨테이너만 교체해 업데이트(빠름·롤백 쉬움) — OS 재플래시 없이. 자주 갱신.
OS OTA(A/B): L4T 업데이트는 위험(부팅 실패=벽돌) → A/B 파티션(두 OS 슬롯)으로 한쪽에 새 OS를 쓰고 부팅, 실패 시 다른 슬롯으로 롤백 — 안전한 OS 업데이트.
플릿 도구·엣지 오케스트레이션: 수많은 기기를 관리(엣지 k8s·KubeEdge·플릿 관리 플랫폼) — 배포·버전·헬스·롤백을 중앙에서.

축	데이터센터	엣지
서버·기기 수	소수 서버	다수 로봇
연결	안정 연결	간헐 연결
물리 접근	가능	어려움
전원·자원	강전원	전력·자원 제약

→ 엣지는 OTA·A/B·플릿 관리·견고성이 더 중요하다.

견해: 앱은 컨테이너 OTA(빠른 갱신·롤백), OS는 A/B 파티션(안전) 으로 나눠 운영한다. 현장 접근이 어려우니 OTA가 필수이고, 부팅 실패가 곧 벽돌이라 A/B·롤백이 안전망. 수많은 로봇은 플릿 관리 플랫폼으로 — 데이터센터 배포(6.8)의 엣지·플릿판. 데이터 플라이휠(7.7·8.14)도 플릿이 데이터 소스.

9.3.7 중간 점검 (체크포인트)

[ ] 엣지 컨테이너의 이점(재현성·격리·배포 일관·플릿 동일 환경·OTA)을 안다.
[ ] L4T 컨테이너가 호스트 드라이버에 결합(드라이버=호스트 L4T, NVIDIA 런타임)됨과 L4T 베이스 이미지를 안다.
[ ] 버전 결합(컨테이너 CUDA/TensorRT가 호스트 L4T 호환)·arm64 빌드를 안다.
[ ] 플릿 관리·OTA(앱=컨테이너 OTA, OS=A/B 파티션·롤백)를 안다.
[ ] 엣지 vs 데이터센터 컨테이너 차이(arch·드라이버 결합·자원·연결·규모)를 제시한다.

증상→의심: 컨테이너에서 GPU 안 됨 → NVIDIA 런타임(--runtime nvidia)·호스트 드라이버 → 런타임·toolkit(7.2). CUDA 버전 불일치 → 컨테이너 베이스 ≠ 호스트 L4T → 매칭 베이스. exec format error → x86 이미지를 arm64에 → arm64 빌드. TensorRT 엔진 로드 실패 → 다른 버전·GPU(5.2·9.2) → 타깃 빌드. OS 업데이트 후 벽돌 → A/B 없음 → A/B 파티션. 로봇마다 환경 다름 → 컨테이너·플릿 관리. 현장 업데이트 비용 → OTA.

9.3.8 트레이드오프·대안

결정	트레이드오프
컨테이너 vs 네이티브	재현성·격리·OTA vs 약간 오버헤드·단순
Jetson 빌드 vs 크로스(x86)	단순·느림 vs 빠름·QEMU 복잡
컨테이너 OTA vs OS OTA	앱 빠름·자주 vs OS·드물게·A/B
엣지 오케스트레이션 vs 단순 스크립트	플릿 규모·기능 vs 소수·단순
엣지 추론 vs 클라우드	자율·저지연 vs 컴퓨트↓·연결 의존(9.1)

견해: 앱은 컨테이너로(재현성·OTA·롤백), arm64 + L4T 베이스(호스트 매칭) 로 빌드(크로스 빌드로 빠르게), 앱은 컨테이너 OTA·OS는 A/B로 갱신, 플릿은 엣지 오케스트레이션으로. 데이터센터 컨테이너 운영(제7부)을 엣지·플릿·arm64·드라이버 결합에 맞춰 적용. 추론은 엣지(Jetson Triton)·자율(9.1), 비실시간 학습은 클라우드 플라이휠(7.7).

비엔비디아 정직: 엣지 컨테이너·OTA·플릿 관리는 임베디드·IoT 일반 개념(다른 엣지 SoC·플랫폼도 컨테이너·A/B·OTA). Jetson의 강점은 NVIDIA 런타임·L4T 베이스 이미지·CUDA/TensorRT 엣지 스택·데이터센터 연속(8.3). 플릿 도구는 다양(엣지 k8s·각사). 원리(드라이버 결합·arm64·OTA·A/B)를 이해하는 것이 핵심. 태그·도구는 세대·생태계 의존.

9.3.9 흔한 함정

x86 이미지를 Jetson에. arch 다름(arm64) → exec format error → arm64 빌드.
호스트 L4T와 다른 베이스. 컨테이너 CUDA/TensorRT가 호스트 드라이버와 불일치 → 매칭 L4T 베이스.
NVIDIA 런타임 안 씀. --runtime nvidia 없이는 GPU 접근 안 됨 → toolkit·런타임(7.2).
데이터센터 엔진을 컨테이너에. TensorRT 엔진은 GPU·버전 종속(5.2·9.2) → Jetson 타깃 빌드.
OS 업데이트를 A/B 없이. 부팅 실패=벽돌 → A/B 파티션·롤백.
플릿을 수동. 수많은 로봇을 수동 업데이트는 비현실 → OTA·플릿 관리.
OTA 롤백 없음. 문제 업데이트가 전 플릿을 망침 → 롤백·카나리(6.8).
태그·도구를 버전 불문. L4T 베이스·플릿 도구가 세대 의존 — 확인.

9.3.10 연습문제

연습 1 (드라이버 결합). L4T 컨테이너에서 GPU·DLA 드라이버가 호스트에 있다는 것이 무슨 의미이고, 왜 컨테이너가 호스트 L4T 버전에 결합되는지 설명하라.

정답

의미: 데이터센터처럼(7.2) Jetson에서도 GPU·DLA·멀티미디어 드라이버는 컨테이너가 아니라 호스트(L4T, 9.2)에 있다. 컨테이너는 NVIDIA 컨테이너 런타임(--runtime nvidia)을 통해 호스트의 드라이버·일부 L4T 라이브러리를 마운트해 사용 — 컨테이너에는 앱과 CUDA 런타임 라이브러리만, 드라이버는 호스트. 왜 호스트 L4T 버전에 결합: 컨테이너의 CUDA/TensorRT 런타임이 호스트 드라이버(L4T)와 호환돼야 동작한다 — CUDA 런타임-드라이버 버전 호환 규칙. 호스트 L4T(JetPack)가 특정 드라이버·CUDA 버전을 제공하므로, 컨테이너의 CUDA/TensorRT가 그와 호환되는 버전이어야(L4T 베이스 이미지를 호스트 버전에 맞춰). 그래서 임의의 CUDA 컨테이너나 못 실행하고, 호스트 L4T 버전에 매칭되는 L4T 베이스 이미지(l4t-base, l4t-ml 등)를 써야 한다. 데이터센터보다 결합이 강한 이유: Jetson은 드라이버·L4T가 더 통합돼 있어(임베디드), 컨테이너-호스트 버전 정합이 엄격. 함의: 호스트 L4T를 업그레이드하면 컨테이너 베이스도 맞춰야 하고, 컨테이너 빌드 시 타깃 Jetson의 JetPack 버전을 알아야. 9.2의 "JetPack 버전 묶음"이 컨테이너로 확장된 것. 이것이 엣지 컨테이너 운영의 첫 제약(arm64가 둘째).

연습 2 (arm64). 데이터센터에서 만든 x86 컨테이너 이미지를 Jetson에서 못 쓰는 이유와, arm64 이미지를 만드는 방법을 설명하라.

정답

못 쓰는 이유: Jetson은 ARM64(aarch64) 아키텍처, 데이터센터는 x86_64. 컨테이너 이미지의 바이너리는 특정 CPU 아키텍처용으로 컴파일되어 있어, x86 이미지를 arm64 Jetson에서 실행하면 exec format error(아키텍처 불일치) — CPU가 그 명령어를 이해 못 함. (컨테이너는 커널을 공유하되 바이너리는 arch별.) arm64 이미지 만드는 법: ① Jetson에서 직접 빌드 — Jetson(arm64)에서 docker build → arm64 이미지. 단순하나 Jetson이 빌드에 느릴 수 있음(컴파일). ② x86 호스트에서 크로스 빌드 — docker buildx build --platform linux/arm64로 QEMU 에뮬레이션을 통해 x86 머신에서 arm64 이미지 빌드(또는 arm64 빌드 머신). 빠른 빌드 인프라 활용. ③ 멀티아키 이미지 — buildx로 x86+arm64를 한 이미지(manifest)로 레지스트리에 푸시 → 각 플랫폼이 자기 arch를 받음. 추가: arm64 이미지는 L4T 베이스(호스트 매칭, 9.3.3) 위에 빌드해 드라이버 호환도 맞춰야. TensorRT 엔진은 그 안에서 Jetson 타깃 빌드(5.2). 정리: arch(arm64)와 L4T 버전(호스트 매칭) 둘 다 맞춰야 — 데이터센터 x86 이미지를 그대로 못 쓰고, arm64 + L4T 베이스로 빌드. 크로스/멀티아키 빌드로 CI에서 양쪽을 한 번에. 임베디드 ARM의 일반 제약.

연습 3 (OTA·A/B). 현장의 1000대 로봇에 앱과 OS를 업데이트한다. 앱과 OS를 각각 어떻게 업데이트하고, A/B 파티션이 왜 OS에 필요한지 설명하라.

정답

앱 업데이트 — 컨테이너 OTA: 앱을 컨테이너로 배포하면, 컨테이너만 교체해 업데이트(새 이미지 pull·재시작) — OS 재플래시 없이 빠르고, 문제 시 이전 컨테이너로 롤백 쉬움. 자주 갱신 가능(앱 버그·기능). 플릿 관리 도구로 1000대에 일관 배포·버전 추적·카나리(일부 먼저, 6.8). OS 업데이트 — A/B 파티션: L4T(OS·커널·드라이버) 업데이트는 드물지만 위험 — 부팅 실패하면 로봇이 벽돌(현장 접근 어려움, 1000대 회수 불가). A/B 파티션: 두 OS 슬롯(A·B)을 둬, 한쪽(B)에 새 OS를 쓰고 부팅 시도, 부팅·검증 성공하면 B로 전환, 실패하면 자동으로 A(이전 OS)로 롤백 — 항상 동작하는 OS가 있어 벽돌 방지. OTA로 원격 배포(현장 접근 비용). 왜 A/B가 OS에 필요: ① 부팅 실패 = 복구 불가(원격), ② A/B가 안전망(실패 시 이전으로), ③ 무중단(다른 슬롯에 쓰고 전환). 앱(컨테이너)은 경량이고 롤백 쉬워 A/B 불필요(컨테이너 교체로), OS는 부하가 크고 위험해 A/B 필수. 정리: 앱=컨테이너 OTA(빠름·자주·롤백 쉬움), OS=A/B 파티션 OTA(드물게·안전·자동 롤백). 1000대는 플릿 관리 플랫폼으로 배포·모니터·롤백·카나리. 현장 접근이 어려운 엣지라 OTA·A/B·롤백·견고성이 데이터센터보다 중요(9.3.6). 잘못된 업데이트가 전 플릿을 망치지 않게 카나리·점진 배포(6.8).

연습 4 (엣지 vs 데이터센터). 엣지(Jetson) 컨테이너 운영이 데이터센터(제7부)와 다른 점 넷을 대고, 각각의 함의를 설명하라.

정답

차이 넷: ① 아키텍처(arm64 vs x86) — Jetson은 ARM64, 데이터센터는 x86. 함의: x86 이미지를 그대로 못 쓰고 arm64로 빌드(크로스/멀티아키), 이미지·바이너리를 arch별로 관리. ② 호스트 드라이버 결합(L4T) — Jetson 컨테이너는 호스트 L4T 드라이버에 강하게 결합(9.3.3), 컨테이너 CUDA/TensorRT가 호스트 JetPack 버전과 호환돼야. 함의: L4T 베이스 이미지·버전 정합(데이터센터보다 엄격), 임의의 CUDA 컨테이너 못 돌림. ③ 규모·연결(다수 로봇·간헐 연결·물리 접근 어려움) — 데이터센터는 소수 서버·안정 연결·물리 접근 가능, 엣지는 현장의 수많은 로봇·간헐 연결·접근 어려움. 함의: OTA·A/B 파티션·플릿 관리·롤백·견고성이 핵심(9.3.6) — 수동 업데이트·현장 방문 비현실. ④ 자원·전력 제약 — 데이터센터는 강전원·풍부 자원, 엣지는 배터리·발열·작은 메모리·자원 제약(8.1·9.1). 함의: 컨테이너·앱이 경량·전력 효율(9.4), DLA 오프로드(8.4), 리소스 관리. 추가: 안전·실시간(로봇), 데이터 플라이휠 소스(플릿이 데이터 수집 7.7·8.14). 정리: 컨테이너 이점(재현성·격리·OTA)은 같으나, arm64·드라이버 결합·플릿/OTA·자원 제약이 엣지 특유 — 데이터센터 운영을 이에 맞춰 적용. 임베디드·IoT의 일반 차이(다른 엣지도 유사).

연습 5 (배포 흐름). 데이터센터에서 학습한 인지 모델을 1000대 로봇 플릿에 컨테이너로 배포·운영하는 엔드투엔드 흐름을 설계하라.

정답

흐름: ① 데이터센터 학습(제4~6부, NeMo 6.2) — 모델 학습, ONNX 등 이식 포맷으로. ② arm64 컨테이너 빌드 — L4T 베이스(타깃 JetPack 매칭, 9.3.3) 위에 앱·모델·의존성을 arm64로 빌드(buildx/멀티아키, CI). ③ Jetson 타깃 TensorRT 엔진 — 컨테이너 안(또는 빌드 시) 모델을 Jetson GPU·DLA 타깃으로 엔진 빌드(5.2·8.4, INT8/FP16 5.4), 안전 critical이면 검증(8.11). ④ 레지스트리 — 컨테이너 이미지를 레지스트리(NGC/사설)에 푸시(버전 태그). ⑤ 플릿 배포(OTA) — 플릿 관리 플랫폼으로 1000대에 컨테이너 OTA 배포: 카나리(소수 로봇 먼저, 6.8)로 검증 후 점진 확대, 문제 시 롤백. 각 로봇은 호스트 L4T 버전이 맞아야(베이스 매칭). ⑥ 엣지 실행 — 로봇이 컨테이너로 인지·자율(Isaac 9.7, Triton 엣지 서빙 5.11 또는 직접). 자원·전력 모니터(jtop 9.4). ⑦ 모니터링·헬스(7.7) — 각 로봇의 버전·상태·헬스·실패를 중앙에서. ⑧ 데이터 플라이휠(7.7·8.14) — 플릿이 실패·엣지케이스를 수집 → 데이터센터 재학습 → 새 컨테이너 → OTA(다시 ②). OS 업데이트(L4T)는 드물게 A/B 파티션 OTA(안전·롤백). 운영: 앱=컨테이너 OTA(빠름·카나리·롤백), OS=A/B, 버전·아키·드라이버 정합(9.2~9.3). 핵심: 데이터센터 학습→arm64/L4T 컨테이너→Jetson 엔진 빌드→레지스트리→플릿 OTA(카나리·롤백)→엣지 실행→모니터·플라이휠. 데이터센터-엣지 연속(8.3)이되 arm64·드라이버 결합·플릿·OTA·A/B가 엣지 특유. 1000대 규모라 자동화·카나리·롤백·헬스가 필수 — 수동 불가. 안전·실시간(로봇)·전력(9.4)도 고려.

9.3.11 요약 · 다음 장(JetPack 묶음 마무리)

엣지 컨테이너는 데이터센터와 같은 이점(재현성·격리·배포 일관)을 주되, 수많은 로봇에 동일 환경·OTA로 배포할 때 결정적.
L4T 컨테이너는 호스트 드라이버에 결합 — GPU·DLA 드라이버는 호스트(L4T), 컨테이너는 NVIDIA 런타임으로 사용. 컨테이너 CUDA/TensorRT가 호스트 JetPack/L4T 버전과 호환돼야(L4T 베이스 이미지, 데이터센터보다 엄격).
arm64(aarch64) 로 빌드해야(데이터센터 x86과 다름, 크로스/멀티아키) — x86 이미지는 Jetson에서 안 됨. TensorRT 엔진은 컨테이너 안에서 Jetson 타깃 빌드(5.2).
플릿 관리·OTA: 앱은 컨테이너 OTA(빠름·롤백), OS는 A/B 파티션(부팅 실패=벽돌 방지·자동 롤백). 현장 접근 어려운 엣지라 OTA·견고성·카나리가 핵심.
엣지 vs 데이터센터: arch·드라이버 결합·자원/전력 제약·다수·간헐 연결·물리 접근이 차이 — 데이터센터 운영을 이에 맞춰. 정직: 태그·도구 세대 의존, 컨테이너·OTA는 임베디드 일반 개념.
JetPack·L4T(9.2~9.3) 완료: 플래싱·부팅(9.2) → 컨테이너·배포(9.3). Jetson 소프트웨어 스택을 익혔다.

다음 장: 9.4 Jetson 전력·성능 운영. 엣지의 천장인 전력·열을 운영한다 — nvpmodel로 전력 모드(전력 예산·클럭) 설정, 발열·throttling 관리, 메모리 공유(통합 메모리)·jetson_clocks, 전력 vs 성능 트레이드오프를 로봇 운영 관점에서 본다.