AI 모델 파일을 여러 엣지 장비에 배포하기

시작하기

기본 개념

AI 모델을 엣지 환경에서 실행하는 경우 중앙 서버에서 학습하거나 준비한 모델 파일을 여러 엣지 장비에 배포해야 합니다.

예를 들어 새로운 이미지 분석 모델을 공장 카메라 장비에 배포하거나, 매장과 물류센터에 설치된 엣지 서버의 모델을 새로운 버전으로 교체할 수 있습니다.

이때 실제 배포 대상은 모델 파일 하나로 끝나지 않을 수 있습니다. 모델과 함께 추론 설정, 클래스 정보, 실행 설정 파일 등을 동일한 장비에 함께 반영해야 하는 경우가 있습니다.

                    Model Repository
                           │
              Model + Config + Metadata
                           │
                           ▼
                    Distribution Flow
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
      Edge Device 01   Edge Device 02   Edge Device 03
          │                │                │
          ▼                ▼                ▼
       Model Ready      Model Ready      Check Required

여러 장비에 파일을 직접 복사하면 장비별로 어떤 모델 버전이 반영되었는지, 필요한 설정 파일이 모두 전달되었는지 각각 확인해야 합니다.

Flow를 활용하면 모델 파일 준비 → 배포 대상 선택 → 여러 엣지 장비 병렬 전송 → 장비별 결과 확인까지 하나의 흐름으로 구성할 수 있습니다.

이 레시피에서는 중앙에 준비된 AI 모델과 설정 파일을 여러 엣지 장비에 배포하고, 장비별 파일 처리 결과와 성공 여부를 확인하는 방법을 구성합니다.

배포 구성

엣지 장비의 모델 배포는 모든 장비에 동일한 모델을 전달하는 방식뿐 아니라, 장비 유형이나 설치 위치에 따라 서로 다른 모델과 설정을 전달하는 방식으로도 구성할 수 있습니다.

예를 들어 동일한 카메라 장비가 설치된 여러 공장에는 같은 모델을 배포하고, 다른 환경의 장비에는 별도의 모델과 설정 파일을 전달할 수 있습니다.

                  AI Model Package
                         │
             ┌───────────┴───────────┐
             │                       │
             ▼                       ▼
       Standard Model           Specialized Model
             │                       │
       ┌─────┼─────┐           ┌─────┴─────┐
       ▼     ▼     ▼           ▼           ▼
     Edge A Edge B Edge C    Edge D      Edge E

장비 수가 많아질수록 파일을 장비별로 개별 관리하기보다 배포 기준과 대상 장비를 함께 구성하는 것이 중요합니다.

파일 구성

AI 모델을 배포할 때는 실제 모델 파일 외에도 추론에 필요한 설정과 부가 파일이 함께 사용될 수 있습니다.

예를 들어 다음과 같은 파일 구조로 모델 패키지를 구성할 수 있습니다.

model-release/
│
├── model/
│   └── inference-model.bin
│
├── config/
│   └── inference.yaml
│
├── labels/
│   └── classes.json
│
└── metadata/
    └── version.json

각 파일은 엣지 장비에서 서로 다른 용도로 사용됩니다.

이처럼 모델 패키지를 하나의 배포 단위로 구성하면 여러 파일을 각각 전송하는 대신, 실제 장비에서 필요한 파일 구성을 함께 전달할 수 있습니다.

IT 엔지니어

장비 연결

먼저 AI 모델이 준비된 시스템을 Source로 연결하고, 모델을 실행할 엣지 장비를 각각 Target으로 구성합니다.

엣지 장비는 동일한 네트워크에 있는 장비뿐 아니라 지점, 공장이나 원격 환경에 설치된 서버일 수도 있습니다.

                   Model Source
                 /release/model-v2
                         │
                         ▼
                    Deployment
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
       Edge-01         Edge-02        Edge-03
     /opt/model       /opt/model     /opt/model

각 Target에서는 모델 파일을 저장할 위치를 지정합니다.

장비마다 동일한 디렉터리 구조를 사용한다면 공통 경로를 적용할 수 있고, 운영 환경이 다른 경우에는 장비별 저장 위치를 다르게 구성할 수 있습니다.

이를 통해 어떤 모델을 어느 장비에 배포할지 명확하게 구성할 수 있습니다.

대상 구분

모든 엣지 장비가 동일한 역할을 수행하지 않는 경우에는 장비를 역할이나 설치 환경에 따라 구분해 배포할 수 있습니다.

예를 들어 공장 내부의 검사 장비와 외부 매장의 분석 장비가 서로 다른 모델을 사용하는 경우 각각 다른 배포 대상을 구성할 수 있습니다.

                    Deployment Flow
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
        Factory Group   Store Group   Test Group
             │             │             │
             ▼             ▼             ▼
        Model-A v2      Model-B v4   Model-A v3

이 경우 하나의 모델을 모든 장비에 일괄 배포하는 대신 장비 그룹과 모델 버전을 기준으로 대상 범위를 나눌 수 있습니다.

이렇게 구성하면 새로운 모델을 배포할 때 실제 적용 대상만 선택해 필요한 장비로 전달할 수 있습니다.

배포 실행

모델 파일과 대상 장비를 구성한 뒤에는 파일을 여러 Target으로 병렬 배포합니다.

병렬 배포를 사용하면 하나의 장비에 대한 파일 전송이 완료된 뒤 다음 장비로 순차적으로 전달하는 대신, 여러 엣지 장비를 대상으로 동시에 배포 작업을 진행할 수 있습니다.

                     Model Package
                           │
                           ▼
                     Deployment Flow
                           │
           ┌───────────────┼───────────────┐
           │               │               │
           ▼               ▼               ▼
        Edge-01          Edge-02          Edge-03
           │               │               │
           ▼               ▼               ▼
       Transferring    Completed        Transferring

장비별 배포는 각각 독립적으로 진행되므로 특정 장비의 연결 상태를 다른 대상과 구분해 확인할 수 있습니다.

예를 들어 일부 장비의 모델 배포가 완료된 상태에서 특정 장비의 연결을 추가로 확인해야 하는 경우 해당 Target의 결과를 별도로 확인할 수 있습니다.

실행 조건

모델 배포는 새로운 파일이 준비되는 즉시 실행할 수도 있고, 운영자가 모델을 확인한 뒤 지정한 시점에 실행하도록 구성할 수도 있습니다.

특히 여러 엣지 장비에서 운영 중인 모델을 교체하는 경우에는 배포 시점과 이전 작업의 완료 상태를 함께 고려할 수 있습니다.

Model Update
     │
     ▼
┌───────────────┐
│ Release Check │
└───────┬───────┘
        │
   ┌────┼─────────┐
   ▼    ▼         ▼
Manual  Schedule  Previous
Run              Job Complete
   │    │         │
   └────┴────┬────┘
             ▼
        Deployment

이를 통해 모델 파일이 아직 준비되지 않았거나 이전 작업이 완료되지 않은 상태에서 배포가 시작되는 상황을 줄일 수 있습니다.

배포 흐름

엣지 장비의 모델 배포는 단순한 파일 전송으로 끝나지 않고, 실제 장비에 필요한 파일이 모두 반영되었는지 확인하는 과정까지 연결할 수 있습니다.

Model Package Ready
        │
        ▼
Target Selection
        │
        ▼
Parallel Distribution
        │
        ├──── Edge-01 ────┐
        ├──── Edge-02 ────┤
        └──── Edge-03 ────┘
                           │
                           ▼
                    Result Review
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
        All Completed              Check Required
             │                           │
             ▼                           ▼
       Next Operation                Retry Target

필요한 경우 모델 배포가 완료된 이후 별도의 검증 작업이나 운영 확인 작업을 연결할 수도 있습니다.

예를 들어 모든 대상 장비에 모델 파일이 정상적으로 반영된 경우 다음 작업을 실행하고, 특정 장비에서 추가 확인이 필요한 경우 해당 장비의 상태를 확인하도록 구성할 수 있습니다.

결과 확인

배포 작업이 실행되면 Runs에서 전체 배포 상태와 장비별 처리 결과를 확인합니다.

여러 엣지 장비에 동일한 모델을 배포하더라도 각 Target의 결과를 구분해 어느 장비까지 정상적으로 파일이 반영되었는지 확인할 수 있습니다.

실행 결과에서는 다음 항목을 확인할 수 있습니다.

이렇게 하면 여러 장비의 파일 배포 결과를 각각의 장비에서 확인하지 않고 하나의 실행 화면에서 비교할 수 있습니다.

실패 대응

여러 엣지 장비 중 일부에서 모델 파일이 정상적으로 반영되지 않은 경우에는 해당 Run의 상세 정보를 확인해 문제가 발생한 장비와 파일 처리 상태를 확인합니다.

예를 들어 원격 장비의 연결이 중단되었거나 지정된 모델 경로에 파일을 저장할 수 없는 경우에는 Target 연결과 경로, 접근 권한을 확인할 수 있습니다.

Deployment Run
       │
       ▼
Device Status
       │
 ┌─────┼─────────────┐
 ▼     ▼             ▼
Edge-01 Edge-02    Edge-03
  ✓       ✓           !
                      │
                      ▼
                 View Details
                      │
           ┌──────────┼──────────┐
           ▼          ▼          ▼
       Connection    Path    Permission
           │          │          │
           └──────────┼──────────┘
                      ▼
                    Adjust
                      │
                      ▼
                     Retry
                      │
                      ▼
                  New Result

실패가 발생한 경우에는 다음 항목을 함께 확인할 수 있습니다.

문제가 해결된 뒤에는 모든 장비의 배포 작업을 다시 구성하는 대신 추가 확인이 필요한 Target을 중심으로 필요한 작업을 다시 실행할 수 있습니다.

재실행 후에는 새로운 Run을 통해 모델과 설정 파일이 해당 엣지 장비에 정상적으로 반영되었는지 확인합니다.

이 과정을 통해 모델 파일 준비 → 배포 대상 구성 → 장비 그룹 구분 → 병렬 배포 → 장비별 파일 반영 → 결과 확인 → 실패 대상 대응까지 이어지는 AI 모델 배포 흐름을 구성할 수 있습니다.

여러 엣지 장비에 모델과 설정 파일을 배포하고 장비별 성공 여부를 함께 관리하면, 새로운 모델을 실제 운영 환경에 반영하는 과정을 개별 장비 작업이 아닌 하나의 관리형 Flow로 운영할 수 있습니다.

개발자

모델과 설정 파일을 여러 엣지 장비에 배포하고 장비별 성공 여부를 확인하기

소스와 대상 엣지 장비들을 장비로 등록한 뒤, 장비별 전송을 만들어 함께 대기하고 성공 여부를 집계합니다. 시작 전에 다음 항목을 준비합니다.

Python·Node.js는 REST를 직접 호출하는 최소 api() 헬퍼와 상태 상수(STATUS_COMPLETE·TERMINAL)를 API 호출 레시피의 것을 재사용합니다. Java·C#은 번들 소스의 InnorixClient(상수 포함)와 Json(C#은 J) 헬퍼를 사용합니다. 장비 식별자와 경로는 실제 값으로 바꿔 넣습니다.

여러 엣지 장비에 모델 배포

대상마다 전송을 만들어 monitorId를 먼저 모은 뒤 전체를 대기합니다. 모델 파일이 원본과 동일하게 전달됐는지 확인하기 위해 checkIntegrity를 켭니다. 전송 생성 자체가 실패한 장비(오프라인 등)는 전송 중 실패와 구분해 따로 수집합니다.

import time


def deploy_model(source, source_path, targets, target_path, action="overwrite"):
    monitors, start_failed = {}, []
    for device in targets:
        try:
            transfer = api("POST", "/api/transfers/manual", {
                "sourceDevice": source,
                "targetDevice": device,
                "targetPath": target_path,
                "sourcePaths": [source_path],
                "sendAllFolder": True,
                "checkIntegrity": True,   # verify model file integrity after transfer
                "transferOptions": {"target-action": action},
            })
            monitors[device] = transfer["monitorId"]
        except Exception:
            start_failed.append(device)   # device whose transfer creation itself failed (e.g. offline)

    results = {}
    for device, monitor_id in monitors.items():
        detail = wait_transfer(monitor_id)
        results[device] = detail.get("status") == STATUS_COMPLETE
    # report devices that never started separately from in-transfer failures
    return {"results": results, "start_failed": start_failed}


def wait_transfer(monitor_id, timeout=14400, interval=5):
    deadline = time.time() + timeout
    while time.time() < deadline:
        detail = api("GET", f"/api/transfers/{monitor_id}") or {}
        if detail.get("status") in TERMINAL:
            return detail
        time.sleep(interval)
    raise TimeoutError(monitor_id)


out = deploy_model("model-src", "/registry/model/v3",
                   ["edge-01", "edge-02", "edge-03"], "/opt/models")
results, start_failed = out["results"], out["start_failed"]
ok = [d for d, c in results.items() if c]
print(f"ok {len(ok)} / started {len(results)} / start-failed {len(start_failed)}")
for device, complete in results.items():
    if not complete:
        print("  transfer failed:", device)
for device in start_failed:
    print("  start failed (check connection):", device)

무결성 검증 서버·장비가 대상인 전송에서는 checkIntegrity: true로 원본과 도착 파일의 체크섬을 비교할 수 있습니다. 자세한 검증 방법은 무결성 검증 레시피를 참고합니다.

오프라인 장비 구분 전송이 시작조차 되지 못한 장비는 실패 파일 목록이 비어 있을 수 있습니다. 이 경우 재시도 대신 장비 연결 상태를 먼저 확인하고, 연결이 복구된 뒤 다시 배포합니다.

실패 장비는 중단 후 재개 레시피의 retry_failed로 실패 파일만 다시 전송합니다.

구현 결과

이 레시피를 적용하면 다음 흐름으로 모델을 여러 엣지 장비에 배포할 수 있습니다.

모델 레지스트리 (model-src)
   ↓  장비별 전송 생성(checkIntegrity) → monitorId 수집  

edge-01 · edge-02 · edge-03 배포
   ↓  전체 대기 → 장비별 성공 여부 집계  

실패 장비만 재배포

모델·설정 파일을 여러 엣지 장비에 배포하고 무결성을 검증하며, 장비별 성공 여부를 집계해 실패 장비만 다시 배포할 수 있습니다.