이기종 하드웨어 전반에 Edge AI 배포하기: 호환성에서 통제된 구성으로

이 글과 전체 아키텍처의 관계

이 글은 기존에 개발해 온 Edge Appliance 아키텍처를 대체하는 것이 아니라 시리즈 전반에서 다룬 내용을 확장합니다. It Started With a Kubernetes Upgrade에서는 인프라, 플랫폼 및 애플리케이션이 서로 다른 수명 주기에 따라 발전할 때 발생하는 문제를 소개했습니다. What Is a Product Version? 에서는 제품 버전을 애플리케이션 릴리스의 동의어가 아닌 검증된 구성으로 정의했습니다.  Configuration Is Part of the Product에서는 제품 경계에 구성을 포함했으며,  From Product Version to Product Package 에서는 논리적인 구성에서 이를 전달하는 결과물로 논의를 확장했습니다.

Edge AI 사례에는 AI 런타임 계층과 LLM 계층이라는 두 가지 새로운 소프트웨어 요소가 추가됩니다. 또한 물리적 하드웨어 구성을 명시적인 호환성 경계로 설정합니다. 기본적인 아키텍처 원칙은 동일합니다. 독립적으로 발전하는 요소는 각각의 버전과 소유권 경계를 유지해야 하며, 제품 버전에는 함께 검증된 요소가 기록되어야 합니다.

이 글에서 대문자로 표기된 용어는 의도적으로 정의한 아키텍처 용어입니다. 제품 버전, 계층, 하드웨어, 제품 매니페스트 및 관련 개념의 정의는 아키텍처가 발전해도 일관성을 유지할 수 있도록 지속적으로 업데이트되는  Edge Appliance Glossary 에서 관리됩니다.

하드웨어가 릴리스 모델의 일부가 되는 시점

공장 내부에서 로컬로 실행되는 산업용 어시스턴트를 생각해 보겠습니다. 작업자는 지속적인 클라우드 연결 없이 이 시스템을 사용해 장비 정보를 조회하고, 현장에서 발생한 이벤트를 요약하며, 작업에 필요한 안내를 받을 수 있습니다. 제품팀은 동일한 제품 버전을 두 가지 장치 제품군에 배포하려고 합니다. 하나는 특정 가속기 스택이 적용된 x86 프로세서 기반이고, 다른 하나는 ARM 기반으로 서로 다른 가속기와 메모리 프로필을 사용합니다.

사용자의 관점에서 두 시스템은 동일한 릴리스로 인식되어야 합니다. 동일한 제품 동작, 애플리케이션 워크플로 및 LLM 기반 기능을 제공해야 합니다. 그러나 하드웨어에서 애플리케이션으로 이어지는 경로는 동일하지 않습니다. 두 대상 시스템에는 서로 다른 드라이버 제품군, 런타임 릴리스, 플랫폼 구성 요소 및 아티팩트 패키징 또는 컴파일 방식이 필요할 수 있습니다. 컨테이너화가 이러한 관계를 없애는 것은 아닙니다. 애플리케이션은 이식할 수 있지만 가속기를 사용하는 데 필요한 소프트웨어는 이식하기 어려울 수 있습니다.따라서 제품을 이해하기 위해서는 소프트웨어를 여러 계층으로 분리하고 물리적 하드웨어를 해당 계층 외부에 두는 방법이 유용합니다.

이 글에서 사용하는 모델은 다음과 같습니다. 애플리케이션 계층에는 제품별 기능이 포함됩니다. LLM 계층은 제품 버전에 포함되는 단일 LLM을 식별합니다. AI 런타임 계층은 해당 LLM을 실행하거나 제공합니다. 플랫폼 계층은 공통 운영 기능을 제공합니다. 인프라 계층은 운영체제, 커널, 드라이버, 펌웨어 종속성 및 이와 유사한 하위 수준 구성 요소를 통해 물리적 시스템을 구동합니다. 이러한 계층 아래에는 어떤 하위 계층 조합이 가능한지를 제한하는 물리적 구성인 하드웨어가 존재합니다. 이러한 전체 스택 관점은 이 아키텍처만의 개념이 아닙니다. 최근의 산업용 Edge AI 연구에서도 배포를 마지막 단계의 모델 패키징으로 보지 않고, 하드웨어와 BSP/OS, 런타임과 가속, 애플리케이션과 추론 및 검증을 포괄하는 시스템 문제로 다뤄야 한다고 설명합니다.

이 글에서 살펴보는 제품 릴리스 문제도 동일한 시스템 현실에서 출발하지만, 다른 질문을 다룹니다. 전체 스택을 모든 환경에서 동일하게 구성할 수 없을 때 하나의 제품 ID를 어떻게 유지할 수 있는지를 살펴봅니다.

Figure 1. 이 글에서 사용하는 제품 계층

하드웨어는 개발, 스테이징 또는 프로덕션과 같은 수명 주기 환경이 아니므로 이러한 구분은 중요합니다. 하드웨어는 물리적인 호환성 경계입니다. 특정 가속기를 탑재한 x86 시스템과 다른 가속기를 탑재한 ARM 시스템이 모두 프로덕션 환경에서 작동하더라도 각각 서로 다른 검증된 소프트웨어 구성이 필요할 수 있습니다. 하드웨어를 릴리스 모델의 명시적인 요소로 정의하면 이러한 제약 조건이 배포 로직 내부에 숨겨지지 않고 명확하게 표시됩니다.

제품 버전을 정의하는 요소

여러 하드웨어별 구성을 허용하면 제품 버전을 더 이상 ‘변경할 수 없는 하나의 파일 스택’으로 정의할 수 없습니다. 제품 버전에는 더욱 명확한 의미론적 정의가 필요합니다. 이 모델에서 제품 버전은 릴리스가 약속하는 사용자 가시적 동작과 두 가지 논리적 불변 요소인 애플리케이션 계층 버전, LLM ID 및 버전으로 구성된 기능 계약을 나타냅니다. 제품 버전 4.0에 애플리케이션 7.2와 LLM X 3.1이 포함된 경우 제품 버전 4.0을 지원하는 모든 하드웨어 구성에서는 동일한 애플리케이션 버전과 동일한 LLM ID 및 버전을 사용해야 합니다.

이를 통해 유용한 ID 경계를 설정할 수 있습니다. 애플리케이션 버전, LLM ID 또는 버전, 기능 계약이 변경되면 논리적인 제품이 변경된 것이므로 새로운 제품 버전이 필요합니다. 특정 하드웨어 구성에 사용되는 구성만 변경하는 경우에는 제품 버전 경계 아래에서 처리합니다. 이러한 구분을 통해 드라이버 패치, 다른 런타임 빌드 또는 새롭게 지원되는 가속기를 독립적으로 발전시키면서도 제품 버전의 의미를 유지할 수 있습니다. 여기에서 ‘논리적’이라는 표현은 중요합니다. 버전을 고정한다고 해서 모든 대상 시스템에서 물리적 파일이 바이트 단위까지 동일해야 하는 것은 아닙니다.

동일한 애플리케이션 버전도 다른 방식으로 패키징되거나 서로 다른 아키텍처용으로 빌드될 수 있습니다. 동일한 LLM도 다른 가속기에서 실행하기 위해 다른 실행 표현이 필요할 수 있습니다. 런타임은 대상별 커널을 컴파일할 수 있으며, 모델은 엣지 장치의 컴퓨팅 및 메모리 범위에 맞도록 양자화될 수 있습니다. 이 글에서는 동일한 소스 모델에서 생성되고 제품 버전의 검증 기준을 충족한다면 양자화를 동일한 LLM 버전의 대상별 표현으로 취급합니다. 이는 모든 조직의 모델 버전 관리에 적용되는 보편적인 규칙이 아니라 의도적으로 선택한 아키텍처 원칙입니다.

중요한 점은 논리적 ID와 아티팩트 ID가 서로 다른 개념이라는 것입니다. 제품 버전은 제품에 어떤 애플리케이션과 LLM이 포함되어 있는지를 알려줍니다. 하드웨어별 릴리스 메타데이터는 어떤 구체적인 아티팩트가 검증되고 전달되었는지를 알려줍니다. 대상별 변환을 허용하면 출처 정보도 재현 가능성의 일부가 됩니다. 특정 파일이 LLM X 3.1을 나타낸다고 기록하는 것만으로는 충분하지 않습니다.릴리스 메타데이터를 통해 다음 정보를 확인할 수 있어야 합니다.

어떤 소스 모델에서 파생되었는지 어떤 변환 또는 컴파일 과정을 통해 생성되었는지 결과에 실질적인 영향을 미치는 매개변수는 무엇인지 실제로 검증을 통과한 아티팩트의 변경 불가능한 다이제스트는 무엇인지 이러한 정보가 없으면 두 파일에 동일한 논리적 버전 레이블이 지정되어 있어도 서로 다른 아티팩트를 나타낼 수 있으며 그 출처를 추적할 수 없습니다.

하드웨어는 비기능적 동작에도 상당한 영향을 줄 수 있습니다. 처리량, 지연 시간, 전력 소비, 토큰 생성 속도, 메모리 압박 상황에서의 최대 컨텍스트 및 동시 워크로드 처리 용량은 하드웨어 구성에 따라 달라질 수 있습니다. 목표는 이러한 수치를 모든 하드웨어에서 동일하게 만드는 것이 아닙니다. 검증된 구성이 제품 버전을 나타내기 전에 충족해야 하는 최소 운영 범위를 정의하는 것입니다. 제품에 따라 검증 기준에는 메모리 상한, 지연 시간 임계값, 시작 시간, 전력 예산 또는 최소 처리량 등이 포함될 수 있습니다. 구체적인 SLO 설계는 이 글의 범위를 벗어나지만 다음 원칙은 중요합니다. 기능적 ID가 동일하다고 해서 성능도 동일한 것은 아니며, 하드웨어의 다양성이 릴리스 기준의 필요성을 없애는 것도 아닙니다.

이 글에서는 하드웨어 구성별로 서로 다른 LLM을 사용하는 것도 허용하지 않습니다. 하드웨어 A에서 한 LLM을 사용하고 하드웨어 B에서 다른 LLM을 사용할 수 있게 되는 순간 릴리스 모델은 더 어려운 질문에 답해야 합니다. 서로 다른 두 모델이 동일한 제품 기능을 구현한다는 것을 어떤 근거로 증명할 수 있는지를 판단해야 합니다. 이를 위해서는 모델 평가, 동작 동등성, 품질 임계값 및 드리프트에 대한 더욱 폭넓은 논의가 필요합니다. 하나의 LLM ID와 버전을 고정하면 먼저 하드웨어 구성 문제에 집중할 수 있습니다.

하나의 제품 버전과 여러 하드웨어별 구성

제품 버전에 하나의 범용 하위 계층 스택이 반드시 필요한 것은 아닙니다. 지원되는 하드웨어 구성마다 하나의 검증된 구성이 필요합니다.

Figure 2. 하나의 제품 버전은 동일한 애플리케이션 버전과 LLM ID 및 버전을 유지하면서 서로 다른 하위 계층 구성에 대응할 수 있습니다.

이 예시에서 제품 버전 4.0은 애플리케이션 7.2와 LLM X 3.1을 고정하지만, 구체적인 엔지니어링 요구사항에 따라 하위 계층은 달라집니다. 하드웨어 A는 AI 런타임 1.8, 플랫폼 3.4 및 인프라 2.1로 정상적으로 작동할 수 있습니다. 하드웨어 B는 해당 가속기 지원이 추가된 AI 런타임 2.0이 필요할 수 있습니다.이 런타임에는 인프라 2.3에 포함된 새로운 드라이버 또는 커널 기준과 통합을 위한 최신 플랫폼 릴리스가 필요할 수 있습니다. LLM도 논리적으로는 LLM X 3.1을 유지하면서 다른 방식으로 컴파일되거나 양자화된 아티팩트로 표현될 수 있습니다.이는 임의적인 스택 분화가 아니라 하드웨어에서 비롯된 종속성 체인입니다.

이러한 구분을 통해 두 가지 일반적인 실패 유형을 방지할 수 있습니다. 첫 번째는 인위적인 버전 분화입니다. 고객에게 보이는 제품이 변경되지 않았는데도 하드웨어별 하위 계층이 바뀔 때마다 새로운 제품 버전을 생성하는 경우입니다. 두 번째는 숨겨진 변동성입니다. 제품 버전은 그대로 유지하면서 배포 로직이 장치에 적합해 보이는 조합을 암묵적으로 선택하는 경우입니다. 첫 번째 방식은 제품 버전 체계를 복잡하게 만들고 버전의 의미를 약화합니다. 두 번째 방식은 릴리스를 재현하기 어렵게 만들고, 사후에 실제 구성을 파악하는 것을 거의 불가능하게 합니다.

통제된 구성 모델은 제품 버전 수준에서 안정적인 ID를 유지하면서 대상별 차이를 그 아래에 명시적으로 표시합니다. 이제 질문은 “제품 버전 4.0은 어떤 스택인가?”가 아닙니다. “하드웨어 A에서 제품 버전 4.0을 지원하는 검증된 구성은 무엇이며, 하드웨어 B에서는 어떤 구성이 지원하는가?”가 됩니다.

호환성, 검증 및 릴리스 선택은 서로 다른 결정입니다

구성을 명시적으로 정의하면 개별 구성 요소가 아닌 전체 시스템의 속성으로 호환성을 판단할 수 있습니다. 특정 인프라 버전이 유효하게 릴리스되었거나 플랫폼 버전이 지원될 수 있습니다. AI 런타임도 정식으로 제공될 수 있습니다. 그러나 이러한 사실만으로는 고정된 애플리케이션 및 LLM과 함께 특정 하드웨어 구성에서 해당 조합이 정상적으로 작동한다고 증명할 수 없습니다.

따라서 후보 구성은 제안에 불과합니다. 호환성 평가는 후보 구성을 다음과 같은 알려진 관계와 비교합니다. 하드웨어 공급업체의 호환성 매트릭스 런타임 지원 표 플랫폼 제약 조건 드라이버 요구사항 엔지니어링 조직에서 관리하는 규칙 이러한 관계를 충족하는 후보가 호환 가능한 구성이 됩니다. 이러한 규칙에는 이미 알려진 정보가 포함되며, 명백하게 유효하지 않은 조합이 검증 리소스를 소비하지 않도록 방지합니다.

이러한 관계 자체도 버전이 관리되는 엔지니어링 지식으로 취급해야 합니다. 런타임은 특정 드라이버 수준 이상에서만 가속기를 지원할 수 있습니다. 플랫폼 릴리스에는 이전 인프라 릴리스에서 사용할 수 없는 커널 기능이 필요할 수 있습니다. 보드 개정으로 인해 AI 런타임에서 사용할 수 있는 메모리가 감소할 수도 있습니다. 이러한 제약 조건이 배포 스크립트나 엔지니어의 지식에만 존재하면 구성 과정은 시행착오에 의존하게 됩니다.제약 조건을 명시적으로 관리하면 릴리스 시스템은 호환성 평가를 제약 조건 기반의 선택 문제로 처리할 수 있습니다. 먼저 알려진 요구사항을 위반하는 조합을 제거한 뒤, 남은 후보에 검증 리소스를 사용합니다.

이는 CI/CD의 형태도 바꿉니다. 하드웨어가 호환성의 한 차원이 되면 파이프라인은 더 이상 하나의 선형적인 빌드·테스트·배포 경로가 아닙니다. 파이프라인은 ‘제품 버전 × 하드웨어 구성’의 매트릭스와 유사하게 작동합니다. 각 행에는 서로 다른 하위 계층 릴리스와 대상별 아티팩트가 적용될 수 있지만, 모든 행은 동일한 제품 수준의 릴리스 계약을 통과해야 합니다. 현재의 Edge AI MLOps 지침에서도 이와 동일한 운영 방식을 설명합니다. 파이프라인에서 하드웨어별 변형을 빌드하고, 출시 후 호환성 문제를 발견하는 대신 대표적인 물리적 하드웨어에서 이를 검증합니다. 그러나 호환성이 검증을 의미하는 것은 아닙니다. Edge AI에서는 제품을 하나의 시스템으로 검증해야 하므로 두 번째 불확실성이 추가됩니다.

호환 가능한 구성이 모든 지원 표의 조건을 충족하더라도 제품 버전의 기능 계약을 충족하지 못할 수 있습니다. 모델이 로드되더라도 허용하기 어려운 결과를 생성할 수 있습니다. 가속기별 실행 경로로 인해 수치적인 차이가 발생할 수 있으며, 애플리케이션 통합 과정에서 런타임별 예외 상황이 발생할 수도 있습니다. 따라서 검증은 릴리스 대상 하드웨어 구성에서 정확한 대상 아티팩트를 포함한 실제 구성을 테스트해야 합니다. 정확한 아티팩트가 해당 검증을 통과한 호환 가능한 구성은 검증된 구성이 됩니다.

AI 워크로드에서 ‘검증됨’은 성공적인 배포나 추론 시작 이상의 의미를 가져야 합니다. 검증은 대표적인 하드웨어에서 기능 계약과 필수 운영 범위를 모두 충족한다는 것을 입증해야 합니다. 제품에 따라 다음 항목이 포함될 수 있습니다. 동작 회귀 검사 지연 시간 메모리 사용량 전력 소비량 토큰 생성 속도 동시 처리 성능 하드웨어에 따라 발생하는 작은 출력 차이는 허용될 수 있지만, 사전에 정의된 허용 오차와 승인 기준을 충족해야 합니다. 호환성은 구성이 작동할 가능성이 있다는 의미이며, 검증은 특정 하드웨어에서 정확한 아티팩트 세트가 릴리스 계약을 통과했다는 의미입니다.

마지막 단계는 선택입니다. 엔지니어링 과정에서 여러 개의 호환 가능한 후보를 발견하고 그중 하나 이상을 성공적으로 검증할 수 있습니다. 그렇다고 배포 과정에서 이들 중 하나를 동적으로 선택해서는 안 됩니다. 릴리스 프로세스에서 해당 하드웨어 구성을 위한 하나의 검증된 구성을 선택해야 합니다. 무엇을 배포할지에 대한 결정은 배포 시점의 휴리스틱이 아니라 릴리스 메타데이터에 기록되어야 합니다.

Figure 3. 통제된 구성은 후보 생성, 호환성 평가, 정확한 아티팩트 확인, 하드웨어별 검증 및 릴리스 선택을 분리합니다.

이러한 분리는 운영 측면에서 중요합니다. 호환성은 무엇이 작동할 수 있는지를 알려줍니다. 검증은 무엇이 실제로 작동한다고 입증되었는지를 알려줍니다. 릴리스 선택은 제품에 실제로 무엇이 포함되어 배포되는지를 알려줍니다. 이러한 단계를 하나의 불투명한 배포 과정으로 결합하면 장애 원인을 진단하기 어려워지고 릴리스를 재현하기도 어려워집니다.

제품 매니페스트를 통한 선택된 구성의 명시화

구성이 선택되면 이를 지속적으로 보존할 수 있는 표현 방식이 필요합니다. 이 글에서는 이를 위해 제품 매니페스트와 제품 매니페스트 목록이라는 용어를 사용합니다. 기존 Edge Appliance 아키텍처에서는 제품 매니페스트를 통해 제품 버전의 구성을 명시적으로 표현했습니다. 이기종 하드웨어는 여기에 새로운 차원을 추가합니다. 이제 특정 하드웨어 구성에 맞춰 구성을 결정해야 합니다. 제품 매니페스트는 하나의 하드웨어 구성에서 하나의 제품 버전을 지원하도록 선택된 구성을 설명합니다. 여기에서 단수형을 사용하는 것은 의도적입니다. 하나의 제품 매니페스트는 하나의 하드웨어별 구성을 설명하며, 제품 매니페스트 목록은 해당 제품 버전에 속하는 제품 매니페스트의 집합을 묶어 관리합니다. 구조적으로는 OCI 이미지 인덱스가 플랫폼별 이미지 매니페스트를 가리키는 방식과 유사합니다. 제품 매니페스트는 선택된 계층 버전을 식별하며, 특히 검증된 구체적인 아티팩트의 변경 불가능한 ID를 기록합니다.

Figure 4. 제품 매니페스트 목록은 하나의 제품 버전을 하드웨어 구성별로 변경할 수 없는 하나의 하드웨어별 매니페스트 개정에 매핑합니다. 논리적인 애플리케이션 및 LLM 버전은 고정되지만 구체적인 아티팩트 다이제스트는 달라질 수 있습니다.

재현 가능성을 확보하려면 버전 레이블만으로는 충분하지 않으므로 아티팩트 ID가 필요합니다. 애플리케이션 7.2에는 ARM 빌드와 x86 빌드가 존재할 수 있습니다. LLM X 3.1에도 두 가지 대상별 표현이 존재할 수 있습니다. 이들은 논리적으로는 동일한 애플리케이션 7.2와 LLM X 3.1이지만, 릴리스에서는 특정 대상에서 실제로 어떤 아티팩트를 테스트했는지 확인할 수 있어야 합니다. 콘텐츠 다이제스트 또는 이와 동등한 변경 불가능한 식별자가 이러한 정확성을 제공합니다.

게시된 하나의 제품 매니페스트 목록 개정 내에서의 결정 방식은 다음과 같습니다.

(제품 버전, 하드웨어) → 정확히 하나의 제품 매니페스트 개정

이 규칙은 전달 과정의 모호성을 제거합니다. 또한 엔지니어링 탐색과 릴리스 선택 사이에 명확한 경계를 설정합니다.

엔지니어링 과정에서는 많은 후보를 테스트할 수 있지만, 릴리스된 매니페스트에는 선택된 하나의 결과만 기록됩니다. 이 구조는 개념적으로 OCI 이미지 인덱스와 유사합니다. 논리적 참조를 통해 아키텍처별 구체적인 콘텐츠에 도달할 수 있으며, 변경 불가능한 다이제스트로 정확한 ID를 보존합니다.

이러한 유사성은 사람이 이해하기 쉬운 논리적 이름과 재현 가능한 콘텐츠를 분리한다는 점에서 유용합니다. 그러나 그 이상으로 확장해 해석해서는 안 됩니다. OCI는 여기에서 설명하는 제품 수준의 아키텍처를 정의하지 않으며, Edge AI 제품은 단순한 컨테이너 이미지 이상이기 때문입니다. 다른 전달 시스템도 서로 다른 범위에서 동일한 문제의 일부를 해결합니다.AWS IoT Greengrass는 플랫폼 요구사항에 따라 서로 다른 매니페스트를 선택할 수 있습니다. Mender는 호환되지 않는 장치 유형에 배포하는 것을 방지하기 위해 호환성 메타데이터와 종속성 정보를 전달합니다. OCM은 버전이 지정된 리소스 집합과 구성 요소 참조를 설명합니다.

이러한 시스템 중 제품 매니페스트 모델과 완전히 동일한 것은 없습니다. 하지만 대상별 차이를 명시적인 메타데이터에 기록하고, 장치에서 이를 추측하지 않도록 배포 전에 결정해야 한다는 성숙한 전달 원칙은 공통적입니다. 제품이 발전하면서 두 번째 결과도 나타납니다. 제품 버전 4.0이 애플리케이션 버전, LLM 또는 기능 계약을 변경하지 않고도 하위 계층 패치를 적용하거나 새로운 하드웨어 구성을 지원할 수 있다면, ‘4.0’은 영구적인 하나의 파일 집합이 아니라 릴리스된 구성의 제품군을 의미합니다. 따라서 정확한 재현을 위해서는 제품 버전 외에도 제품 매니페스트 목록 개정이나 해당 목록의 변경 불가능한 다이제스트가 필요합니다.

수명 주기도 아키텍처의 일부가 됩니다

대상별 매니페스트가 주요 릴리스 객체로 관리되면 수명 주기 동작을 배포 관행에 맡기지 않고 명시적으로 정의할 수 있습니다. 먼저 장치는 호환성에 영향을 미치는 물리적 특성을 기반으로 자신의 하드웨어를 결정론적으로 식별해야 합니다. 구체적인 검색 메커니즘은 구현 방식에 따라 다르지만 아키텍처 규칙은 분명합니다. 지원되는 동일한 물리적 구성은 항상 동일한 하드웨어 ID로 결정되어야 합니다. 선택한 제품 매니페스트 목록 개정에 일치하는 매니페스트가 없다면 전달 과정을 안전하게 종료해야 합니다. 가장 유사한 지원 장치를 선택하면 배포 시점에 검증되지 않은 구성을 다시 도입하는 결과가 발생합니다.

하위 계층 패치에서도 제품 ID와 릴리스된 구성의 구분을 유지해야 합니다. 하드웨어 A에 새로운 드라이버, 인프라 빌드, 플랫폼 패치 또는 AI 런타임 패치가 필요하더라도 애플리케이션 버전, LLM ID 및 버전, 기능 계약이 동일하게 유지된다면 제품 버전을 변경할 필요가 없습니다. 대신 해당 대상 시스템을 위한 새로운 변경 불가능한 제품 매니페스트 개정을 생성하고, 이를 가리키는 새로운 제품 매니페스트 목록 개정을 만듭니다. 

롤백에도 동일한 원칙이 적용됩니다. 신뢰할 수 있는 롤백은 이전 제품 버전 레이블을 가져와 현재의 종속성을 다시 결정하는 방식으로 과거 상태를 재구성하지 않습니다. 원래의 아티팩트 ID가 포함된 이전 검증 매니페스트 개정을 선택합니다. 재현 가능성은 버전 레이블만의 속성이 아니라 정확한 구성의 속성입니다.

새로운 하드웨어도 같은 방식으로 추가할 수 있습니다. 이후에 추가되는 하드웨어 구성은 동일한 애플리케이션, LLM 및 기능 계약을 기준으로 호환성 평가와 검증을 거쳐야 합니다. 검증을 통과하면 새로운 매니페스트를 생성하고, 새로운 제품 매니페스트 목록 개정에 이를 포함합니다. 이전 목록 개정은 변경하지 않고 그대로 유지합니다.

Figure 5. 제품 버전 4.0은 논리적인 릴리스 ID로 유지하면서 변경 불가능한 제품 매니페스트 목록 개정을 통해 시간 경과에 따른 패치와 새롭게 지원되는 하드웨어 구성을 기록할 수 있습니다.

이러한 개정 모델은 제품에 두 가지 안정성을 동시에 제공합니다. 제품 버전은 논리적인 제품이 변경될 때 바뀌므로 사용자에게 의미 있는 정보로 유지됩니다. 매니페스트 개정은 특정 시점에 정확히 무엇이 릴리스되었는지를 식별하므로 엔지니어링에도 의미 있는 정보로 유지됩니다.

플랫폼 엔지니어링의 책임

플랫폼 엔지니어링에서 반복 가능한 릴리스 프로세스로 구현할 수 있어야 이 아키텍처가 유용해집니다. 그 책임은 단순한 배포 자동화보다 광범위합니다. 플랫폼에는 다음 작업을 수행할 수 있는 메커니즘이 필요합니다. 호환성 지식 활용 하드웨어 매트릭스 확장 정확한 아티팩트 결정 하드웨어별 검증 실행 선택된 구성 기록 롤백 및 향후 재현 지원 결과물은 단순한 배포 파이프라인이 아닙니다. 제품의 의도와 하드웨어 제약 조건을 재현 가능한 증거로 변환하는 릴리스 팩토리입니다.

이 과정에서는 소유권 경계도 중요합니다. 제품 엔지니어링은 기능 계약을 정의하고 제품 버전에 포함할 애플리케이션과 LLM을 결정합니다. 각 계층의 소유자는 자신이 관리하는 계층의 버전, 아티팩트 및 호환성 정보를 게시합니다. 플랫폼 엔지니어링은 이러한 입력을 하나의 릴리스로 구성하고, 제약 조건을 평가하며, 검증을 실행하고, 관련 증거를 보존하는 메커니즘을 제공합니다. 플랫폼에서 모든 호환성 결정을 직접 담당하면 도메인 지식이 잘못된 위치에 집중될 뿐입니다. 플랫폼의 역할은 이러한 지식을 실행하고 감사할 수 있도록 만드는 것입니다.

즉, 플랫폼은 단순히 바이너리를 장치로 이동하는 것이 아닙니다. 제품 ID와 하드웨어별 구성의 관계를 운영 가능한 형태로 구현합니다. 이 과정의 결과물은 다음과 같은 증거입니다. 어떤 제품 버전이 전달되었는지 어떤 하드웨어 구성에 전달되었는지 어떤 계층 릴리스와 아티팩트 다이제스트가 사용되었는지 어떤 검증 결과를 기준으로 릴리스되었는지 전송 메커니즘은 그다음에 결정합니다. 선택된 제품 매니페스트는 GitOps, OTA 메커니즘 또는 네트워크가 분리된 제품 패키지를 통해 전달할 수 있습니다.

이러한 메커니즘은 릴리스가 장치에 도달하는 방법을 결정합니다. 배포 과정에서 구성 로직을 다시 실행하는 대신 이미 선택되고 검증된 구성을 사용해야 합니다. 이는 장치가 수년간 서비스 상태를 유지하고, 하드웨어 제품군이 애플리케이션 릴리스와 독립적으로 발전하며, 제한된 환경이나 네트워크가 분리된 환경에서 배포될 수 있는 엣지에서 특히 중요합니다.

시간이 지날수록 모호성으로 인한 비용은 증가합니다. 제품 버전 4.0에 세 개의 매니페스트 목록 개정과 여러 하드웨어별 구성이 존재한다면, 릴리스 후 6개월이 지난 시점에 “제품 버전 4.0이었다”는 정보만으로는 문제를 진단할 수 없습니다. 통제된 구성 모델은 제품 수준의 ID와 실제로 무엇이 실행되었는지 이해하는 데 필요한 운영 증거를 모두 보존합니다.

“실행할 수 있는가?”에서 “정확히 무엇을 배포하는가?”로

dge AI에 대한 논의는 “이 LLM을 이 장치에서 실행할 수 있는가?”라는 호환성 질문으로 시작하는 경우가 많습니다. 이는 유용한 엔지니어링 질문이지만 아직 릴리스 모델이라고 할 수는 없습니다.

제품 조직은 다음과 같은 더욱 구체적인 질문에 답할 수 있어야 합니다. 이 제품 버전을 정의하는 애플리케이션 버전과 LLM은 무엇인가? 각 하드웨어 구성에 유효한 하위 계층 구성은 무엇인가? 정확히 어떤 아티팩트가 검증되었는가? 릴리스 프로세스에서 어떤 구성을 선택했는가? 향후 어떤 변경 불가능한 개정을 재현하거나 롤백할 수 있는가?

이를 위해 모든 장치에 하나의 범용 소프트웨어 스택을 적용할 필요는 없습니다. 하드웨어별 변경이 발생할 때마다 새로운 제품 버전을 생성할 필요도 없습니다. 논리적인 제품 ID와 하드웨어별 구성을 분리하고, 차이를 명시적으로 표현하며, 전체 구성을 검증하고, 정확한 결과를 기록해야 합니다.

이것이 호환성에서 통제된 구성으로의 전환입니다. 이 방식은 이기종 하드웨어를 배포 시점에 발견하는 예외 상황이 아니라 릴리스 시점에 결정하는 요소로 전환합니다. 또한 플랫폼 엔지니어링에서 결정성과 재현 가능성을 잃지 않으면서 동일한 Edge AI 제품을 서로 다른 하드웨어에 배포할 수 있는 구체적인 메커니즘을 제공합니다.

참고 자료 및 추가 읽기

It Started With a Kubernetes Upgrade: Series origin: 독립적으로 발전하는 인프라, 플랫폼 및 애플리케이션의 수명 주기가 엣지 어플라이언스를 제품 수명 주기 문제로 전환하는 이유를 다룬 시리즈의 시작 글입니다.

Configuration Is Part of the Product: Extends 제품 버전을 단순한 애플리케이션 릴리스 이상으로 정의하고 이 글에서 사용하는 검증된 구성 모델을 설명합니다.

Configuration Is Part of the Product: 제품의 경계를 구성까지 확장하고 제품 소유 구성과 대상 환경 구성을 구분합니다.

From Product Version to Product Package: 논리적인 제품 버전에서 전달 가능한 제품 패키지, 제품 매니페스트, 계층 패키지 및 수명 주기 책임으로 논의를 확장합니다.

Edge Appliance Glossary: 시리즈 전반에서 사용하는 아키텍처 용어의 지속적으로 업데이트되는 정의입니다.

OCI Image Index Specification: 논리적 참조를 플랫폼별 매니페스트에 매핑하는 구조에 관한 외부 참고 자료입니다.

Mender Artifact: 호환성 메타데이터, Provides/Depends 관계 및 페이로드 무결성을 설명합니다.

Open Component Model Component Descriptor: 버전이 지정된 리소스, 소스, 참조 및 서명을 설명합니다.

Edge AI Deployment Beyond Models: 하드웨어, BSP/OS, 런타임, 애플리케이션 및 검증 전반에서 Edge AI 배포를 바라보는 시스템 중심의 관점을 제공합니다.

TinyMLOps: Operational Challenges for Widespread Edge AI Adoption: 분산된 Edge AI 배포에서 발생하는 운영 및 수명 주기 문제를 다룬 연구입니다.