---

배경

GTC 2026에서 “IGX and Jetson: Autonomous Robots and Physical AI Applications” 세션을 준비하면서, IGX와 AGX의 차이가 뭔지, 그리고 두 플랫폼 간 전환을 대비하려면 소프트웨어를 어떻게 설계해야 하는지 정리할 필요가 있었다.

알아보면서 HAL, API, 드라이버 같은 개념이 자연스럽게 엮이는데, 이게 의외로 헷갈리는 부분이라 한번에 정리한다.

---

IGX vs AGX: 칩이 다른 게 아니라, 보드가 다르다

SoC(칩)는 동일한 Orin이다. 차이는 그 위에 뭘 얹었느냐.

	Jetson AGX Orin	IGX Orin
SoC	Orin (동일)	Orin (동일)
안전 MCU	없음	Infineon AURIX TC397 (ASIL-D급)
FSI (Functional Safety Island)	SoC 내부에 있지만 비활성화	활성화 (독립 전원 격리)
BMC (원격관리)	없음	Aspeed AST2600, OpenBMC
SmartNIC	없음	ConnectX-7 (100GbE)
SW 스택	JetPack (무료)	IGX OS + AI Enterprise (유료 구독)
안전 인증	불가 (NVIDIA 공식: “계획 없음”)	Certification-Ready
지원 기간	~5년, best-effort	10년, SLA 포함
가격	모듈 $899 / DevKit $1,999	비공개 (추정 $5,000~$15,000)

핵심은 이거다:

1. 칩은 같다. 별도 인증을 칩 레벨에서 받는 게 아니다.
2. IGX는 NVIDIA가 직접 만드는 제품이다. 제3자 보드 회사가 만드는 게 아니라 NVIDIA 자체 제품 라인.
3. 보드 위에 안전 MCU + BMC + 보안 칩을 추가한 것. 하드웨어 설계 자체가 다르다.
4. Jetson AGX Orin으로는 기능안전 인증이 불가능하다 — NVIDIA가 공식적으로 선언했다. FSI가 칩 안에 있지만 상업용 모듈에서 꺼져 있다.
5. IGX도 “인증 완료”가 아니라 “인증 준비 완료” — 실제 인증은 시스템 통합업체가 NVIDIA의 Safety Evidence Package를 받아서 직접 해야 한다.

”그러면 AGX 칩 사서 직접 IGX급으로 만들면 되지 않나?”

이론적으로 가능하지만 현실적으로 어렵다:

• Orin SoC 내부의 FSI가 Jetson 모듈에서는 꺼져 있다 — NVIDIA 협조 없이 켤 수 없다
• Safety Evidence Package는 IGX 구매자/NDA 파트너에게만 제공된다
• “IGX”는 NVIDIA 상표라 쓸 수 없다
• 직접 안전 MCU를 얹는 건 가능하지만, 그건 자체 안전 보드 설계이고 인증도 처음부터 직접 해야 한다

실용적 결론

스타트업 단계에서는 Jetson AGX Orin으로 개발하되, 산업용 고객이 ISO 13849 / IEC 61508 인증을 요구하는 시점에 IGX로 전환하는 것이 현실적이다. 이때 소프트웨어 전환 비용을 줄이려면 HAL(Hardware Abstraction Layer) 설계가 필요하다.

---

HAL이 뭔가

추상화(Abstraction) = 세부사항을 숨기고, 쉬운 버튼만 보여주는 것.

자동차로 비유하면:

엑셀을 밟으면 차가 간다. 근데 안에서는:

• 가솔린차: 인젝터 → 연소 → 크랭크 회전
• 전기차: 배터리 → 인버터 → 모터 회전
• 수소차: 수소 → 연료전지 → 모터 회전

운전자는 그냥 엑셀만 밟는다. 내부가 뭔지 몰라도 된다.

“엑셀 페달”이 추상화다.

HAL = Hardware Abstraction Layer = 하드웨어용 엑셀 페달.

SDK가 하드웨어를 직접 부르는 대신, 중간에 번역기를 하나 끼우는 것:

HAL 없으면:
  SDK → "Jetson GPIO 42번 핀에 전압 HIGH 줘"
  → 나중에 IGX로 바꾸면? 코드 전부 수정해야 함

HAL 있으면:
  SDK → "모터 켜" → HAL이 알아서 번역
                      ├ Jetson이면: GPIO 42번 HIGH
                      └ IGX이면:   GPIO 42번 HIGH + 안전MCU에 알림

SDK 코드는 한 줄도 안 고쳐도 된다. HAL 백엔드만 갈아끼우면 끝.

실제로 추상화해야 하는 3가지

과도하게 설계할 필요 없다. 하드웨어를 직접 부르는 부분만 한 단계 감싸면 된다.

1. GPIO / 핀 제어

// 직접 호출 (추상화 없음)
tegra_gpio_set(PIN_42, HIGH);

// HAL로 감싸기
wim_gpio_set(MOTOR_ENABLE, HIGH);
// → Jetson backend: tegra_gpio_set()
// → IGX backend:    tegra_gpio_set() + safety_mcu_notify()

2. Safety Watchdog

wim_safety_heartbeat();    // 주기적 호출
wim_safety_estop();        // 비상정지

// Jetson backend: 소프트웨어 watchdog (자체 구현)
// IGX backend:    AURIX TC397 하드웨어 watchdog 연동

3. 시스템 모니터링

wim_system_health_check();

// Jetson backend: sysfs 읽기 (온도, 전압)
// IGX backend:    BMC API 호출 (OpenBMC REST)

---

HAL vs API vs 드라이버 — 뭐가 다른가

API = “이렇게 부르면 이렇게 해줄게” 라는 약속

API는 방향이 없다. 그냥 “호출 규격”이다.

• 카카오맵 API: getRoute(서울, 부산) → 경로 줌
• OpenAI API: chat("안녕") → 답변 줌
• WIM SDK API: moveMotor(joint1, 90도) → 모터 움직임

HAL = 하드웨어를 부를 때 쓰는 API

HAL이 특별한 게 아니라, API인데 대상이 하드웨어인 것:

	대상	예시
Web API	외부 서버	POST /api/chat
Library API	소프트웨어 함수	cv2.imread("photo.jpg")
HAL	하드웨어	wim_gpio_set(MOTOR, HIGH)

드라이버 = 실제로 하드웨어를 조작하는 코드

HAL은 “누구한테 시킬지” 결정하고, 드라이버가 “실제로” 한다.

호텔에서 "방 청소해주세요" 라고 프론트에 말함
    ↓
프론트 직원이 해당 층 담당 청소부에게 전달  ← HAL
    ↓
청소부가 실제로 방에 가서 청소함             ← 드라이버

	HAL	드라이버
하는 일	”누구한테 시킬지” 결정	실제로 하드웨어 조작
비유	교환원 / 라우터	실제 작업자
코드 내용	if Jetson → A드라이버, if IGX → B드라이버	레지스터 쓰기, 패킷 전송, 타이밍 제어
하드웨어 지식	거의 없음 (이름만 앎)	매우 깊음 (프로토콜, 타이밍, 레지스터)
교체 빈도	안 바뀜	하드웨어 바뀌면 새로 작성

전체 구조

고객/개발자
    ↓  WIM SDK API (고객이 호출하는 인터페이스)
WIM SDK 내부 로직
    ↓  HAL (어떤 드라이버 쓸지 연결)
    ├── EtherCAT 드라이버   ← 실제로 EtherCAT 패킷 만들어서 보냄
    ├── CAN 드라이버        ← 실제로 CAN 프레임 만들어서 보냄
    └── GPIO 드라이버       ← 실제로 핀 전압 올리고 내림

고객은 HAL의 존재를 모른다. SDK API만 쓴다. HAL은 내부에서 하드웨어 교체를 쉽게 하려고 만드는 것이다.

---

정리

개념	한 줄 요약
IGX vs AGX	칩은 같고, IGX는 NVIDIA가 안전 부품을 얹은 산업용 보드
추상화	세부사항 숨기고 쉬운 인터페이스만 보여주는 것
API	”이렇게 부르면 이렇게 해줄게” 라는 호출 약속
HAL	API인데 대상이 하드웨어인 것. 하드웨어 교체 시 윗단 코드를 안 고치게 해줌
드라이버	실제로 하드웨어를 물리적으로 조작하는 코드

스타트업 단계에서 HAL을 거창하게 만들 필요는 없다. 하드웨어 직접 호출하는 함수들을 우리 이름으로 한번 감싸두기만 하면, 그게 HAL이다. 나중에 Jetson → IGX 전환이 필요할 때 백엔드 파일 하나만 추가하면 된다.

← All posts