Jetson AGX Orin 패키지 버전 관리 (2025-09-25)

Jetson AGX Orin 패키지 버전 관리 (2025-09-25)

1. 서론: Jetson AGX Orin 소프트웨어 생태계의 이해

NVIDIA Jetson AGX Orin 플랫폼에서의 성공적인 애플리케이션 개발 및 배포는 하드웨어의 강력한 성능만큼이나 복잡하고 긴밀하게 통합된 소프트웨어 생태계에 대한 깊은 이해를 요구한다. Jetson의 소프트웨어 스택은 단순히 개별 패키지의 집합이 아니라, 특정 하드웨어 기능과 최적의 성능을 보장하기 위해 세심하게 조정되고 검증된 통합 시스템이다. 따라서 체계적인 버전 관리 전략의 부재는 예측 불가능한 오류, 성능 저하, 심지어 시스템 비호환성 문제로 이어질 수 있다. 본 문서는 Jetson AGX Orin 환경에서 안정적이고 재현 가능한 개발 및 배포 파이프라인을 구축하기 위한 고급 패키지 버전 관리 방법론을 제시한다.

Jetson 소프트웨어 생태계의 핵심 구성 요소와 그들의 계층적 의존성을 파악하는 것이 모든 버전 관리 전략의 출발점이다.

  • JetPack SDK (Software Development Kit): JetPack은 Jetson 플랫폼을 위한 공식 소프트웨어 스택으로, AI 기반 엣지 애플리케이션 구축에 필요한 모든 도구와 라이브러리를 포괄하는 상위 개념이다.1 이는 단순한 설치 프로그램이 아니라, 특정 버전의 운영체제, 드라이버, 라이브러리들이 상호 호환되도록 NVIDIA가 사전에 구성하고 검증한 패키지의 묶음이다.

  • Jetson Linux (구 L4T - Linux for Tegra): JetPack의 근간을 이루는 것은 Jetson Linux 드라이버 패키지(BSP, Board Support Package)이다.3 Jetson Linux는 부트로더, 특정 버전의 Linux 커널, NVIDIA 하드웨어 드라이버, 그리고 특정 Ubuntu 버전을 기반으로 하는 루트 파일 시스템(예: JetPack 5는 Ubuntu 20.04, JetPack 6는 Ubuntu 22.04 기반)을 포함한다.3 이 BSP는 Jetson SoC의 하드웨어 가속기(GPU, DLA, PVA 등)를 직접 제어하는 로우레벨 소프트웨어 계층이다.

  • 핵심 가속 라이브러리 (CUDA, cuDNN, TensorRT): Jetson Linux 위에 AI 애플리케이션의 핵심인 고성능 컴퓨팅 라이브러리들이 위치한다. 여기에는 GPU 가속 컴퓨팅을 위한 CUDA Toolkit, 딥러닝 연산을 위한 cuDNN, 그리고 추론 최적화를 위한 TensorRT가 포함된다.1 이 라이브러리들은 특정 Jetson Linux 버전 및 하드웨어 드라이버와 강력한 의존성을 가진다.

이러한 구성 요소들 간의 관계는 매우 긴밀하게 결합되어 있다. 각 JetPack 릴리스는 특정 버전의 L4T, CUDA, cuDNN, TensorRT와 명시적으로 연결된다.8 예를 들어, JetPack 5.1은 L4T 35.2.1과 CUDA 11.4를 포함하며 8, JetPack 5.1.1은 L4T 35.3.1, CUDA 11.4, TensorRT 8.5.2, cuDNN 8.6.0을 포함한다.9 이러한 의존성 사슬은 버전 관리의 복잡성을 야기하는 주된 원인이다. 만약 개발자가 L4T 커널 드라이버와의 호환성을 고려하지 않고 임의로 CUDA 툴킷 버전만 업그레이드할 경우, 시스템 불안정, 성능 저하, 또는 애플리케이션의 완전한 실패로 이어질 수 있다.

이러한 관점에서 Jetson의 소프트웨어 스택은 일반적인 데스크톱이나 서버의 운영체제라기보다는 하드웨어와 깊이 결합된 ’펌웨어’로 개념화하는 것이 더 정확하다. 일반적인 Linux 환경에서는 sudo apt upgrade 명령어를 통해 시스템을 최신 상태로 유지하는 것이 일반적인 관행이지만 10, Jetson 환경에서는 이 접근 방식이 심각한 위험을 초래할 수 있다. NVIDIA는 자체 APT 저장소를 통해 Jetson Linux의 핵심 구성 요소(

nvidia-l4t-core, nvidia-l4t-kernel 등)에 대한 업데이트를 배포한다.11 사용자가 무심코

apt upgrade를 실행하면, 초기 플래싱 시점에 설정된 커널이나 부트로더 버전과 호환되지 않는 새로운 드라이버 패키지가 설치될 수 있으며, 이는 예기치 않은 JetPack 버전 점프나 시스템 벽돌 현상으로 이어질 수 있다는 사례가 다수 보고되었다.12

따라서 Jetson의 핵심 L4T 패키지들은 운영체제의 일부라기보다는 SoC의 GPU, DLA(Deep Learning Accelerator), PVA(Programmable Vision Accelerator)와 같은 하드웨어 블록을 위한 펌웨어처럼 다루어야 한다.5 이는 안정적으로 검증된 기준선을 설정하고, 개별적인 부품 교체가 아닌 전체 시스템 관점에서 신중하고 계획적인 업데이트를 수행해야 함을 의미한다. 이러한 이해는 본 문서에서 제시하는 모든 버전 관리 전략의 근본적인 철학을 형성한다.

JetPack 버전L4T 릴리스Ubuntu 버전Linux 커널CUDA ToolkitcuDNNTensorRT
JetPack 6.0 DPL4T 36.222.045.1512.28.98.6
JetPack 5.1.1L4T 35.3.120.045.1011.48.6.08.5.2
JetPack 5.0.2L4T 35.120.045.1011.48.4.18.4.1
JetPack 4.6.2L4T 32.7.218.044.910.28.2.18.2.1

표 1: JetPack 버전별 주요 구성 요소 매핑. 이 표는 각 JetPack 릴리스가 특정 버전의 L4T, Ubuntu, 커널 및 AI 라이브러리와 어떻게 긴밀하게 연결되어 있는지를 명확히 보여준다. 개발자는 이 표를 통해 특정 프로젝트에 필요한 “골든 구성“을 식별하고 버전 충돌의 원인을 진단하는 기준으로 삼을 수 있다. 3

2. 호스트 시스템 패키지 버전 관리 전략

Jetson AGX Orin의 호스트 운영체제는 모든 애플리케이션이 실행되는 기반이므로, 이 계층의 안정성과 예측 가능성을 확보하는 것이 무엇보다 중요하다. 이 섹션에서는 안정적인 기준 환경을 설정하고, 이를 의도치 않은 변경으로부터 보호하며, 필요에 따라 정밀하게 패키지 버전을 제어하는 체계적인 방법론을 제시한다.

2.1 기준 환경 설정: NVIDIA SDK Manager를 이용한 정밀 플래싱

모든 버전 관리의 시작은 깨끗하고 신뢰할 수 있는 기준선(baseline)을 설정하는 것이다. NVIDIA SDK Manager는 특정 JetPack 버전을 Jetson 디바이스에 설치하는 공식적이고 가장 신뢰성 높은 도구이다.16 이 도구를 사용함으로써 개발자는 알려진 양호한 상태(known-good state)에서 프로젝트를 시작할 수 있다.

플래싱 절차는 일반적으로 Ubuntu x86 기반의 호스트 PC에 Jetson 디바이스를 연결하고, 디바이스를 강제 복구 모드(Force Recovery Mode)로 부팅하는 과정을 포함한다.2 SDK Manager의 가장 큰 장점은 설치하고자 하는 JetPack 버전을 명시적으로 선택할 수 있다는 점이다. 이는 프로젝트의 요구사항에 맞는 정확한 버전의 L4T, CUDA, cuDNN, TensorRT 조합을 시스템에 설치할 수 있게 하여, 기준 환경에 대한 완벽한 제어를 가능하게 한다.18

또한, SDK Manager는 설치 과정을 세분화할 수 있는 유연성을 제공한다. 사용자는 ‘Jetson OS’(핵심 L4T BSP)만 먼저 플래싱한 후, ‘JetPack SDK Components’(CUDA, cuDNN, TensorRT, 예제 등)는 나중에 네트워크를 통해 SDK Manager로 설치하거나, Jetson 디바이스 상에서 직접 apt 명령어를 사용하여 설치할 수 있다.16 프로덕션 환경에서는 최소한의 필수 패키지만 포함하는 ’Jetson OS’를 기준으로 삼고, 애플리케이션에 필요한 라이브러리는 별도로 관리하는 것이 일반적이다. 이처럼 SDK Manager를 통한 정밀 플래싱은 예측 가능하고 재현 가능한 시스템의 초석을 다지는 필수적인 첫 단계이다.

2.2 버전 확인 및 조회

시스템에 변경을 가하기 전에 현재 상태를 정확히 파악하는 것은 필수적이다. Jetson 환경에서는 여러 명령어를 통해 설치된 소프트웨어 스택의 버전을 상세하게 확인할 수 있다.

  • JetPack 및 L4T 버전 확인:

  • 가장 간단한 방법은 /etc/nv_tegra_release 파일의 내용을 확인하는 것이다. 이 파일의 첫 줄에는 L4T 릴리스 버전과 빌드 정보가 포함되어 있어, 현재 시스템의 JetPack 버전을 유추할 수 있다.8

  • 더 정밀한 L4T 버전 정보는 dpkg-query --show nvidia-l4t-core 명령어를 통해 얻을 수 있다. 이 명령어는 nvidia-l4t-core 패키지의 정확한 버전과 빌드 타임스탬프를 출력하여, 시스템의 근간을 이루는 BSP 버전을 명확하게 식별하게 해준다.8

  • CUDA 버전 확인:

  • 설치된 CUDA Toolkit의 버전은 nvcc --version 명령어를 통해 확인할 수 있다. 이 명령어는 NVIDIA CUDA Compiler(NVCC)의 버전 정보를 출력하며, 이는 개발 및 컴파일 환경의 기준이 된다.19

  • APT 저장소의 가용 버전 조회:

  • 특정 패키지를 설치하거나 다운그레이드하기 전에, 현재 시스템의 APT 저장소에서 어떤 버전들을 사용할 수 있는지 확인해야 한다. apt-cache madison <package-name> 명령어는 해당 패키지에 대해 사용 가능한 모든 버전, 해당 버전이 속한 저장소, 아키텍처 정보를 표 형식으로 보여준다.20

  • 유사한 기능으로 apt list --all-versions <package-name> 명령어도 사용할 수 있다.22 이 명령어들을 통해 특정 버전의 설치 가능 여부를 사전에 파악하고, 버전 충돌을 예방하기 위한 계획을 수립할 수 있다.

이러한 조회 명령어들은 시스템의 현재 상태를 진단하고, 향후 패키지 관리 작업을 계획하는 데 필수적인 정보를 제공한다.

2.3 APT를 이용한 패키지 버전 제어

안정적인 기준 환경이 설정되고 현재 버전이 파악되었다면, 다음 단계는 APT(Advanced Package Tool)를 사용하여 패키지 버전을 능동적으로 제어하고 시스템을 의도치 않은 변경으로부터 보호하는 것이다.

  • 특정 버전의 패키지 설치:

APT는 특정 버전의 패키지를 명시적으로 설치하는 기능을 제공한다. 이는 sudo apt install = 구문을 통해 이루어진다.23 여기서

<version-string>apt-cache madison을 통해 확인한 정확한 버전 번호여야 한다. 이 기능은 프로젝트가 특정 라이브러리 버전에 의존할 때, 또는 새로운 버전에서 발견된 버그를 회피하기 위해 이전 버전으로 다운그레이드해야 할 때 매우 유용하다. 이는 버전 제어의 가장 기본적인 수단이다.

  • apt-mark hold를 통한 시스템 고정:

Jetson 호스트 시스템의 안정성을 유지하는 데 있어 가장 핵심적인 명령어는 apt-mark hold이다. sudo apt-mark hold 명령어는 지정된 패키지를 ‘보류’ 상태로 만들어, apt upgrade나 apt dist-upgrade 실행 시 해당 패키지가 자동으로 업데이트되거나 제거되는 것을 방지한다.26 이는 서론에서 언급한 ‘APT의 함정’, 즉 무분별한 업그레이드로 인해 핵심 L4T 구성 요소가 손상되는 것을 막는 가장 효과적인 방어 수단이다.

이러한 도구들을 바탕으로, 전문가 수준의 워크플로우는 시스템 설정을 두 단계로 명확히 구분한다. 첫 번째는 ’프로비저닝 단계(Provisioning Phase)’이다. 이 단계에서는 SDK Manager로 깨끗한 OS를 플래싱한 후, git, vim, python3-pip와 같이 개발에 필요한 기본 도구들을 apt install을 통해 설치한다.

프로비저닝이 완료되면, 시스템은 즉시 두 번째 단계인 ’강화 단계(Hardening Phase)’로 전환되어야 한다. 이 단계에서는 사전에 정의된 핵심 nvidia-l4t-* 패키지 목록에 대해 apt-mark hold 명령어를 실행하는 스크립트를 구동한다. 이 강화 단계를 거친 후에야 비로소 시스템은 안정화된 것으로 간주하며, 애플리케이션 개발 또는 배포 준비가 완료된 것이다. 이처럼 ‘프로비저닝 후 강화’ 워크플로우를 공식화함으로써, 문제가 발생한 후에 반응적으로 대처하는 것이 아니라, 사전에 위험을 차단하는 능동적이고 체계적인 시스템 관리 체계를 구축할 수 있다.

분류명령어설명사용 예시
버전 확인cat /etc/nv_tegra_releaseL4T 릴리스 버전 확인head -n 1 /etc/nv_tegra_release
dpkg-query --show <pkg>특정 패키지의 설치된 버전 확인dpkg-query --show nvidia-l4t-core
nvcc --versionCUDA 컴파일러 버전 확인nvcc --version
저장소 조회apt-cache madison <pkg>패키지의 사용 가능한 모든 버전 조회apt-cache madison nvidia-jetpack
apt list --all-versions <pkg>패키지의 사용 가능한 모든 버전 조회 (대안)apt list --all-versions nvidia-l4t-core
버전 제어apt install <pkg>=<ver>특정 버전의 패키지 설치/다운그레이드sudo apt install docker-ce=5:27.5.1-1~...
apt-mark hold <pkg>패키지 자동 업데이트 방지sudo apt-mark hold nvidia-l4t-kernel
apt-mark unhold <pkg>패키지 보류 상태 해제sudo apt-mark unhold nvidia-l4t-kernel
apt-mark showhold보류 상태인 모든 패키지 목록 확인sudo apt-mark showhold

표 2: 핵심 버전 관리 명령어 요약. 이 표는 Jetson 호스트 시스템에서 버전을 관리하는 데 필수적인 명령어들을 기능별로 정리한 빠른 참조 가이드이다. 8

패키지 와일드카드역할 설명보류(Hold) 이유
nvidia-l4t-kernel*Linux 커널 및 관련 헤더, DTB(Device Tree Blob) 파일시스템의 가장 근간이 되는 구성 요소. 임의의 커널 업데이트는 드라이버 비호환성 및 부팅 실패를 유발할 수 있으므로, 플래싱 시점의 버전을 엄격하게 유지해야 한다.
nvidia-l4t-coreJetson Linux 핵심 시스템 라이브러리 (RM, DLA, PVA 등)하드웨어 가속기를 직접 제어하는 드라이버와 라이브러리. 커널 및 다른 nvidia-l4t-* 패키지들과 긴밀하게 연결되어 있어 버전 불일치는 심각한 시스템 오류를 초래한다.
nvidia-l4t-bootloader부트로더 업데이트 페이로드부팅 프로세스를 관장하는 핵심 소프트웨어. 잘못된 업데이트는 시스템을 부팅 불능 상태로 만들 수 있다. 부트로더 업데이트는 전체 BSP 업그레이드의 일부로만 신중하게 수행되어야 한다.
nvidia-l4t-firmwareTegra SoC 및 일부 Wi-Fi 칩을 위한 펌웨어하드웨어의 저수준 동작을 제어하는 펌웨어. BSP 버전과 엄격하게 동기화되어야 한다.
nvidia-l4t-multimedia*멀티미디어(카메라, 비디오 인코딩/디코딩) API 및 라이브러리하드웨어 비디오 코덱 및 카메라 ISP(Image Signal Processor)와 직접 상호작용한다. nvidia-l4t-core 및 커널 드라이버 버전에 의존적이므로 함께 고정해야 한다.
nvidia-l4t-display*디스플레이 드라이버 및 관련 커널 모듈디스플레이 출력을 담당하는 드라이버. 커널 버전과 직접적인 의존성을 가지므로 커널과 함께 버전을 고정해야 한다.

표 3: 권장 apt-mark hold 패키지 목록. 이 표는 프로덕션 환경의 안정성을 극대화하기 위해 ’강화 단계’에서 보류 상태로 설정해야 할 핵심 L4T 패키지 목록과 그 이유를 제시한다. 이 패키지들을 고정함으로써, 일반적인 시스템 패키지(apt upgrade)는 업데이트하면서도 Jetson의 핵심 BSP는 안정적으로 유지할 수 있다. 11

3. 컨테이너 환경에서의 버전 관리 격리

호스트 시스템의 안정성을 확보했다면, 다음 과제는 애플리케이션 자체의 복잡한 의존성을 관리하는 것이다. 현대적인 소프트웨어 개발에서 이 문제에 대한 가장 효과적인 해결책은 컨테이너화(Containerization)이다. 컨테이너는 애플리케이션과 그 의존성들을 호스트 시스템으로부터 격리된 독립적인 환경에 패키징하여, “내 컴퓨터에서는 됐는데…“와 같은 고질적인 문제를 해결한다. Jetson 플랫폼에서는 NVIDIA Container Toolkit을 통해 이러한 격리의 이점을 GPU 가속 애플리케이션에까지 확장할 수 있다.

3.1 NVIDIA Container Toolkit의 원리 및 설정

표준 Docker 환경은 Linux 커널의 네임스페이스와 cgroup을 사용하여 프로세스를 격리하지만, GPU와 같은 특수 하드웨어에 대한 접근은 기본적으로 제공하지 않는다. NVIDIA Container Toolkit은 이 간극을 메우는 핵심적인 미들웨어이다.29

이 툴킷의 핵심 원리는 nvidia라는 커스텀 런타임을 Docker에 추가하는 것이다. 사용자가 docker run --runtime nvidia... 명령을 실행하면, 이 런타임이 활성화된다. 런타임은 컨테이너가 시작될 때 호스트 시스템에 설치된 NVIDIA 드라이버 라이브러리(예: libcuda.so)와 GPU 디바이스 노드(예: /dev/nvidia0) 같은 필수 파일들을 컨테이너 내부로 자동으로 마운트한다.29 이 과정을 통해 컨테이너 내의 애플리케이션은 마치 호스트에 직접 설치된 것처럼 GPU 하드웨어 가속 기능을 투명하게 사용할 수 있다.

JetPack 4.x 및 5.x 버전에서는 NVIDIA Container Toolkit이 기본적으로 함께 설치되었다.29 그러나 JetPack 6부터는 호스트 PC를 통해 플래싱할 경우 Docker 엔진 자체가 기본 설치 항목에서 제외되는 변경 사항이 있었다.13 따라서 개발자는 Docker 엔진을 수동으로 설치하고,

nvidia-ctk와 같은 도구를 사용하여 Docker 데몬이 nvidia 런타임을 기본으로 사용하도록 설정해야 한다.30

또한, 최신 Docker 버전(예: v28.x)과 JetPack 6 간의 호환성 문제가 보고된 바 있으며, 이로 인해 특정 버전의 Docker로 다운그레이드하고 해당 패키지를 apt-mark hold 해야 하는 경우도 발생했다.13 이는 컨테이너 환경 자체를 구성하는 데에도 세심한 버전 관리가 필요함을 시사한다.

3.2 공식 L4T 베이스 컨테이너 활용

안정적인 컨테이너 환경을 구축하는 가장 좋은 방법은 NVIDIA가 공식적으로 제공하고 관리하는 베이스 이미지를 사용하는 것이다. NVIDIA는 NGC(NVIDIA GPU Cloud) 컨테이너 레지스트리를 통해 Jetson 플랫폼에 최적화된 다양한 컨테이너 이미지를 제공하며, 그중 가장 기본이 되는 것이 nvcr.io/nvidia/l4t-base이다.31

이 베이스 이미지들은 호스트 시스템의 L4T 버전에 맞춰 태그가 지정되어 있다. 예를 들어, 호스트가 L4T 35.1(JetPack 5.0.2)을 실행 중이라면, l4t-base:r35.1.0 태그를 가진 이미지를 사용해야 호환성이 보장된다.31 이 태그 매핑은 컨테이너 내부의 사용자 공간 라이브러리와 호스트의 커널 및 드라이버 간의 호환성을 유지하는 데 결정적인 역할을 한다.

JetPack 5 (L4T r34.1)부터 중요한 아키텍처 변화가 있었다. 이전 버전에서는 CUDA, cuDNN, TensorRT와 같은 AI 라이브러리들이 호스트에서 컨테이너로 마운트되었지만, JetPack 5부터는 이 라이브러리들이 컨테이너 내부에 직접 설치되는 방식으로 변경되었다.31 이 변화는 컨테이너의 이식성과 독립성을 크게 향상시켰다. 이제 컨테이너는 호스트의 전체 JetPack 설치에 의존하는 대신, 호환되는 L4T 커널 드라이버만 있으면 되므로, 훨씬 더 자기 완결적인(self-contained) 실행 단위가 되었다.

l4t-base 이미지는 멀티미디어, 그래픽스 API 등 L4T BSP의 일부 패키지를 포함하지만, CUDA와 같은 전체 AI 스택을 포함하지는 않는다.31 따라서 개발자는 Dockerfile 내에서

apt install 명령어를 사용하여 필요한 버전의 nvidia-l4t-cuda, nvidia-l4t-cudnn, nvidia-l4t-tensorrt 등의 패키지를 명시적으로 설치하여 커스텀 이미지를 빌드해야 한다.

3.3 jetson-containers를 활용한 동적 컨테이너 빌드

복잡한 AI/ML 애플리케이션은 PyTorch, TensorFlow, ROS, OpenCV 등 수많은 라이브러리에 의존하며, 이들의 버전을 맞추고 컴파일하는 것은 매우 까다로운 작업이다. dusty-nv/jetson-containers 프로젝트는 이러한 복잡성을 해결하기 위해 등장한 강력한 오픈소스 컨테이너 빌드 시스템이다.35

이 프로젝트는 복잡한 Dockerfile을 직접 작성하는 대신, 필요한 패키지들을 선언적으로 조합하여 컨테이너를 빌드할 수 있는 고수준의 도구를 제공한다. 예를 들어, PyTorch, Transformers, ROS2 Humble Desktop을 포함하는 컨테이너를 빌드하고 싶다면, 다음과 같은 간단한 명령어를 실행하면 된다 35:

$ jetson-containers build –name=my_container pytorch transformers ros:humble-desktop

jetson-containers의 핵심 기능 중 하나는 autotag 스크립트이다. 이 스크립트는 현재 호스트 시스템의 L4T 버전을 자동으로 감지하고, 이에 호환되는 컨테이너 이미지를 로컬, 레지스트리, 또는 신규 빌드를 통해 찾아준다.35 이는 개발자가 L4T 버전 호환성을 수동으로 추적해야 하는 부담을 크게 줄여준다.

더 나아가, 이 빌드 시스템은 환경 변수를 통해 주요 구성 요소의 버전을 유연하게 지정할 수 있는 기능을 제공한다. 예를 들어, 특정 프로젝트를 위해 CUDA 12.6 기반으로 컨테이너를 빌드해야 한다면 다음과 같이 실행할 수 있다 35:

CUDA_VERSION=12.6 jetson-containers build transformers

이러한 접근 방식은 프로젝트별로 상이한 의존성 요구사항을 충족시키는 데 엄청난 유연성을 제공한다.

이상의 논의를 종합하면, Jetson 개발 및 배포를 위한 최적의 패러다임은 ‘안정적인 호스트, 민첩한 컨테이너(Stable Host, Agile Container, SHAC)’ 모델로 요약할 수 있다. 1부에서 설명한 전략에 따라 호스트 시스템은 apt-mark hold를 통해 안정적으로 ’강화’된 상태를 유지하며, 펌웨어처럼 취급된다. 반면, 모든 애플리케이션 로직, 라이브러리, 복잡한 의존성은 버전 제어가 용이하고 재현 가능한 컨테이너 내부에 캡슐화된다. JetPack 5 이후의 컨테이너 아키텍처 변화는 이러한 모델을 더욱 강력하게 뒷받침하며, jetson-containers와 같은 자동화 도구는 이를 현실적으로 구현 가능하게 만든다.

SHAC 모델은 Jetson 개발의 근본적인 딜레마, 즉 하드웨어에 종속된 안정적인 BSP에 대한 필요성과 프로젝트별로 유연한 애플리케이션 스택에 대한 필요성 사이의 충돌을 해결한다. 관심사의 분리(separation of concerns)를 명확히 함으로써, 단일 Jetson 디바이스에서 서로 다른 버전의 PyTorch, ROS, CUDA를 요구하는 여러 프로젝트를 충돌 없이 동시에 개발하고 관리할 수 있게 해준다.37 이는 가장 성숙하고 견고한 버전 관리 접근 방식이라 할 수 있다.

4. 프로덕션 배포를 위한 통합 버전 관리 로드맵

1부와 2부에서 논의된 전략들을 통합하여, 실제 프로덕션 환경에 견고하고 유지보수 가능하며 재현 가능한 애플리케이션을 배포하기 위한 구체적인 로드맵을 제시한다. 이 로드맵은 개발 초기 단계부터 배포 후 유지보수까지 전 과정에 걸쳐 버전 관리를 체계적으로 통합하는 것을 목표로 한다.

4.1 개발 및 배포 워크플로우 설계

프로젝트의 복잡성과 요구사항에 따라 적절한 워크플로우를 설계하는 것이 중요하다.

  • 호스트 기반 워크플로우: 애플리케이션이 단일 목적이며 의존성이 비교적 단순한 경우, 1부에서 설명한 대로 호스트 시스템을 정밀하게 관리하는 것만으로 충분할 수 있다. 이 경우, 모든 의존성 패키지의 버전을 스크립트에 명시적으로 고정하고, 시스템을 ’강화’하여 안정성을 확보하는 것이 핵심이다.

  • 컨테이너 기반 워크플로우: 애플리케이션이 복잡하거나, 여러 서비스가 동시에 실행되어야 하거나, 다양한 외부 라이브러리에 의존하는 경우, 컨테이너 기반 워크플로우가 강력히 권장된다.10 SHAC 모델에 따라 호스트는 최소한의 안정적인 BSP만 유지하고, 모든 애플리케이션 로직은 Docker 컨테이너 내에서 실행된다. 이 방식은 의존성 충돌을 원천적으로 방지하고, 개발 환경과 프로덕션 환경의 일관성을 보장한다.

어떤 워크플로우를 선택하든, 프로덕션 환경을 최대한 유사하게 모방한 스테이징(staging) 환경을 구축하여 배포 전 최종 검증을 거치는 것은 필수적인 과정이다. 이를 통해 개발 환경에서는 발견되지 않았던 배포 관련 문제를 사전에 식별하고 해결할 수 있다.10

4.2 재현성 확보: Lock 파일과 버전 명시

프로덕션 환경에서 ’재현성(Reproducibility)’은 시스템의 신뢰성과 직결되는 가장 중요한 가치이다. 재현성이란, 언제 누가 빌드하더라도 항상 동일한 결과물이 생성됨을 보장하는 것을 의미한다.

이를 달성하기 위한 핵심 원칙은 ’모든 것을 명시적으로 버전 고정(pinning)하는 것’이다. 배포 스크립트나 Dockerfile에서 패키지를 설치할 때, apt install libfoo와 같이 버전을 명시하지 않는 것은 잠재적인 시한폭탄과 같다. 대신, apt install libfoo=1.2.3-4와 같이 정확한 버전을 명시해야 한다.39 이는 빌드 시점에 APT 저장소의 패키지 버전이 변경되더라도 결과물에 영향을 주지 않도록 보장한다. Python의

requirements.txt나 Node.js의 package-lock.json과 같은 언어 수준의 의존성 관리 도구도 동일한 원칙을 적용해야 한다.

이러한 버전 고정 관행을 Jenkins나 GitHub Actions와 같은 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인에 통합하는 것이 현대적인 모범 사례이다.10 CI/CD 파이프라인은 소스 코드 변경이 있을 때마다 자동으로 빌드, 테스트, 패키징 과정을 실행한다. 이 과정 전체가 스크립트화되고 버전 관리 시스템(예: Git)에 의해 추적되므로, 모든 배포 아티팩트(예: Docker 이미지)는 일관되고 재현 가능한 방식으로 생성된다. Jetson을 위한 완벽한 CI/CD 파이프라인은 호스트 시스템 설정(플래싱, 패키지 설치, 강화)부터 애플리케이션 컨테이너 빌드 및 테스트까지 전 과정을 자동화해야 한다.

4.3 OTA 업데이트와 버전 관리

배포된 디바이스는 정적이지 않다. 보안 취약점 패치, 버그 수정, 기능 추가를 위해 원격으로 소프트웨어를 업데이트하는 OTA(Over-the-Air) 기능은 프로덕션 시스템의 필수 요건이다. Jetson Linux는 NVIDIA의 APT 서버를 통해 OTA 업데이트를 지원한다.11

그러나 1부에서 확립한 ‘강화된 호스트’ 환경에서는 OTA 전략을 신중하게 설계해야 한다. 핵심 nvidia-l4t-* 패키지들이 apt-mark hold 상태이므로, 단순한 sudo apt upgrade로는 전체 시스템 업데이트가 이루어지지 않는다. JetPack의 마이너 릴리스나 포인트 릴리스로 업그레이드하기 위해서는 /etc/apt/sources.list.d/nvidia-l4t-apt-source.list 파일을 수동으로 수정하여 새로운 버전의 저장소를 가리키게 한 후, sudo apt dist-upgrade를 실행해야 한다.11 이는 상당한 테스트를 요구하는 중대한 변경이다.

여기서 SHAC 모델과 컨테이너화의 진정한 가치가 드러난다. 프로덕션 Jetson 디바이스를 단일 개체가 아닌 계층화된 시스템으로 바라보면, 업데이트 전략 또한 계층적으로 분리할 수 있다.

  1. 베이스 OS(L4T) 계층: 이 계층은 하드웨어와 직접적으로 연관되어 있으므로, 매우 신중하고 낮은 빈도로 업데이트되어야 한다. 업데이트는 전체 JetPack 버전 업그레이드와 같이 철저한 검증을 거친 후에만 적용된다.

  2. 애플리케이션(컨테이너) 계층: 이 계층은 호스트 OS와 분리되어 있으므로, 훨씬 더 민첩하고 빈번하게 업데이트될 수 있다.

예를 들어, 현장에 L4T 35.1과 애플리케이션 컨테이너 v1.0이 배포된 디바이스가 있다고 가정하자. 만약 호스트 OS의 일반 Ubuntu 패키지에서 심각한 보안 취약점(CVE)이 발견되면, 호스트 OS만을 대상으로 한 OTA 업데이트를 푸시할 수 있다. 핵심 nvidia-l4t-* 패키지들은 보류 상태이므로, 이 업데이트는 위험 부담이 큰 드라이버 변경 없이 필요한 보안 패치만 적용하게 되어 리스크를 최소화한다.

한편, 개발팀이 AI 모델을 개선하여 애플리케이션 컨테이너 v1.1을 릴리스했다면, 이 새로운 컨테이너 이미지만을 디바이스로 푸시하여 기존 컨테이너를 교체할 수 있다. 이 과정은 기반 OS에 아무런 변경을 가하지 않으므로 매우 빠르고 안전하게 수행될 수 있다.

이러한 ‘계층적 업데이트’ 전략은 대규모 Jetson 디바이스 군집(fleet)의 유지보수성과 보안성을 극적으로 향상시킨다. 하드웨어 의존적인 베이스 OS의 길고 비용이 많이 드는 검증 주기와, 애플리케이션 소프트웨어의 빠르고 민첩한 개발 주기를 분리함으로써, 대규모 프로덕션 배포에 필수적인 안정성과 유연성을 동시에 확보할 수 있다. 이는 성공적인 Jetson 프로젝트를 위한 핵심적인 전략적 이점이다.

5. 결론: 안정적이고 재현 가능한 개발 환경 구축

Jetson AGX Orin의 잠재력을 최대한 활용하기 위해서는 그 복잡한 소프트웨어 생태계를 체계적으로 관리하는 것이 필수적이다. 본 문서는 단편적인 명령어 나열을 넘어, 개발 초기부터 프로덕션 배포 및 유지보수에 이르는 전 과정에 적용할 수 있는 통합적인 버전 관리 철학과 전략을 제시했다.

핵심 전략은 다음과 같이 요약할 수 있다.

  1. 호스트를 펌웨어처럼 다루어라: NVIDIA SDK Manager를 사용하여 깨끗하고 명시적인 버전의 기준선을 설정하고, 즉시 apt-mark hold를 통해 핵심 nvidia-l4t-* 패키지를 ’강화(harden)’하여 안정적인 기반을 확보해야 한다.

  2. 민첩성을 위해 컨테이너화를 수용하라: ‘안정적인 호스트, 민첩한 컨테이너(SHAC)’ 모델을 채택하여, 하드웨어 종속적인 BSP와 애플리케이션 종속성을 명확히 분리해야 한다. 모든 애플리케이션 로직과 라이브러리는 컨테이너 내부에서 관리되어야 한다.

  3. 고수준의 도구를 활용하라: dusty-nv/jetson-containers와 같은 자동화된 빌드 시스템을 활용하여, 버전 호환성이 보장된 복잡한 AI/ML 컨테이너 이미지 생성을 자동화하고 가속화해야 한다.

  4. 재현성을 강제하라: 모든 것을 스크립트화하고, Dockerfile과 배포 스크립트 내에서 모든 패키지 버전을 명시적으로 고정(pinning)해야 한다. 이 모든 과정을 CI/CD 파이프라인에 통합하여 인간의 실수를 배제하고 일관성을 보장해야 한다.

결론적으로, 프로덕션 수준의 고성능 AI 애플리케이션을 목표로 하는 모든 Jetson AGX Orin 개발 프로젝트에 대해 컨테이너 우선(container-first) 전략을 강력히 권고한다. 이 접근 방식은 Jetson 플랫폼이 요구하는 하드웨어 종속적인 안정성과 현대적인 소프트웨어 개발이 요구하는 유연성 및 재현성 사이에서 최적의 균형을 제공한다. SHAC 모델과 계층적 업데이트 전략을 통해 개발자는 변화에 신속하게 대응하면서도 시스템의 신뢰성을 유지할 수 있으며, 이는 장기적으로 성공적인 제품을 만들고 유지보수하는 데 결정적인 요소가 될 것이다.

6. 참고 자료

  1. JetPack Software Stack for NVIDIA Jetson - NVIDIA Developer, https://developer.nvidia.com/embedded/jetpack
  2. Installing JetPack L4T — platypus_boat_doc 0.1 documentation, https://platypus-boats.readthedocs.io/en/latest/source/jetson/TX2/os-install.html
  3. Jetson Linux | NVIDIA Developer, https://developer.nvidia.com/embedded/jetson-linux
  4. collabnix.com, https://collabnix.com/how-to-find-jetpack-version-of-nvidia-jetson-nano/#:~:text=NVIDIA%20Jetson%20Nano%20is%20a,for%20AI%20and%20deep%20learning.
  5. NVIDIA® JETSON AGX ORIN™ DEVELOPER KIT - Cloudfront.net, https://d29g4g2dyqv443.cloudfront.net/sites/default/files/akamai/Jetson_AGX_Orin_Developer_Kit_RG.pdf
  6. Jetson Linux 36.2 - NVIDIA Developer, https://developer.nvidia.com/embedded/jetson-linux-r362
  7. JetPack SDK 4.6.4 - NVIDIA Developer, https://developer.nvidia.com/jetpack-sdk-464
  8. How to find Jetpack version of NVIDIA Jetson Nano - Collabnix, https://collabnix.com/how-to-find-jetpack-version-of-nvidia-jetson-nano/
  9. JetPack SDK 5.1.1 - NVIDIA Developer, https://developer.nvidia.com/embedded/jetpack-sdk-511
  10. Best Practices and Considerations for Packaging and Deploying Python Web Applications -, https://www.quanthub.com/best-practices-and-considerations-for-packaging-and-deploying-python-web-applications/
  11. Software Packages and the Update Mechanism — Jetson Linux Developer Guide documentation - NVIDIA Docs Hub, https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/SoftwarePackagesAndTheUpdateMechanism.html
  12. Avoiding apt upgrade from Jetpack 6.1 to Jetpack 6.2 - Jetson AGX …, https://forums.developer.nvidia.com/t/avoiding-apt-upgrade-from-jetpack-6-1-to-jetpack-6-2/322877
  13. Docker Setup on JetPack 6 - Jetson Orin - JetsonHacks, https://jetsonhacks.com/2025/02/24/docker-setup-on-jetpack-6-jetson-orin/
  14. Dev Kit Weekly: NVIDIA Jetson AGX Orin Developer Kit - YouTube, https://www.youtube.com/watch?v=v1im63U5AfU
  15. JetPack and Jetson Linux (L4T) Versions - JetsonHacks, https://jetsonhacks.com/jetpack-and-jetson-linux-l4t-versions/
  16. Installing Jetpack SDK Components alongside the CTI-L4T BSP - Connect Tech Inc., https://support.connecttech.com/hc/en-us/articles/4416086952603-Installing-Jetpack-SDK-Components-alongside-the-CTI-L4T-BSP
  17. Jetson AGX Orin Developer Kit User Guide - Two Ways to Set Up Software, https://developer.nvidia.com/embedded/learn/jetson-agx-orin-devkit-user-guide/two_ways_to_set_up_software.html
  18. Install Jetson Software with SDK Manager - NVIDIA Docs Hub, https://docs.nvidia.com/sdk-manager/install-with-sdkm-jetson/index.html
  19. different ways to check for nvidia jetpack versions - GitHub Gist, https://gist.github.com/jadwigo/86b905ca2573dc7b9a685652b82ef590
  20. How to find out which versions of a package can I install on APT - Super User, https://superuser.com/questions/393681/how-to-find-out-which-versions-of-a-package-can-i-install-on-apt
  21. How can I check the available version of a package in the repositories? - Ask Ubuntu, https://askubuntu.com/questions/340530/how-can-i-check-the-available-version-of-a-package-in-the-repositories
  22. How can I see all versions of a package that are available in the archive? - Ask Ubuntu, https://askubuntu.com/questions/447/how-can-i-see-all-versions-of-a-package-that-are-available-in-the-archive
  23. Checking the Package Version Before Installing It Using apt | Baeldung on Linux, https://www.baeldung.com/linux/apt-check-package-version
  24. How to install specific version of some package? [duplicate] - Ask Ubuntu, https://askubuntu.com/questions/428772/how-to-install-specific-version-of-some-package
  25. How to install specific Ubuntu deb packages, with exact version?, https://askubuntu.com/questions/92019/how-to-install-specific-ubuntu-deb-packages-with-exact-version
  26. Apt Upgrade Hold Back Risky Packages | ARK Documentation, https://arkelectron.gitbook.io/ark-documentation/embedded-computers/ark-just-a-jetson/apt-upgrade-hold-back-risky-packages
  27. How to prevent updating of a specific package? - Ask Ubuntu, https://askubuntu.com/questions/18654/how-to-prevent-updating-of-a-specific-package
  28. How to Apply Distro Upgrade (apt upgrade) on Jetson Modules? - Forecr.io, https://www.forecr.io/blogs/bsp-development/how-to-apply-distro-upgrade-apt-upgrade-on-jetson-modules
  29. NVIDIA Container Runtime on Jetson (Beta) — Cloud Native …, https://nvidia.github.io/container-wiki/toolkit/jetson.html
  30. Installing the NVIDIA Container Toolkit, https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html
  31. NVIDIA L4T is a Linux based software distribution for the NVIDIA Jetson embedded computing platform. - NGC Catalog, https://catalog.ngc.nvidia.com/orgs/nvidia/containers/l4t-base
  32. Docker Setup On Jetson Orin - Includes JetPack 6 Docker fix - YouTube, https://www.youtube.com/watch?v=d2I_wjJTekw
  33. Error with “Nvidia Container Runtime with Docker Integration” on AGX Orin with JP6.2, https://forums.developer.nvidia.com/t/error-with-nvidia-container-runtime-with-docker-integration-on-agx-orin-with-jp6-2/324558
  34. Question : Cuda version support · Issue #258 · dusty-nv/jetson-containers - GitHub, https://github.com/dusty-nv/jetson-containers/issues/258
  35. dusty-nv/jetson-containers: Machine Learning Containers for NVIDIA Jetson and JetPack-L4T - GitHub, https://github.com/dusty-nv/jetson-containers
  36. at master · dusty-nv/jetson-containers - GitHub, https://github.com/dusty-nv/jetson-containers?search=1
  37. Jetson Nano - L4T & CUDA/cuDNN best practices for multi-container apps - balena Forums, https://forums.balena.io/t/jetson-nano-l4t-cuda-cudnn-best-practices-for-multi-container-apps/153279
  38. Multiple Jetpack on the Same Jetson TX2 possible? - NVIDIA Developer Forums, https://forums.developer.nvidia.com/t/multiple-jetpack-on-the-same-jetson-tx2-possible/76782
  39. What is Package Management? Best Practices - JFrog, https://jfrog.com/learn/devops/package-management/
  40. So you want to write a package manager | by sam boyer - Medium, https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527
  41. NVIDIA Jetson Linux Developer Guide : Introduction, https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3276/index.html
  42. Upgrade JetPack 5 to Production Version - JetsonHacks, https://jetsonhacks.com/2022/08/20/upgrade-jetpack-5-to-production-version/