에지 AI와 TinyML: IoT 현장에서 온디바이스 추론을 설계하는 법

현장에서 끝내는 추론

에지 AI는 센서 데이터가 생기는 장치에서 바로 ML 추론을 수행하는 아키텍처다. 네트워크 의존도를 낮추면서 지연시간, 비용, 프라이버시 제약에 대응한다. 센싱부터 전처리, 추론, 행동까지 현장에서 처리하고, 필요할 때만 요약 데이터를 클라우드로 올리는 하이브리드 패턴이 여기에 속한다.

TinyML은 수십KB~수MB 메모리의 MCU에서 동작하는 초경량 ML 기술 스택이다. 정수 양자화, 연산 축소, 고정소수점 커널 최적화가 중심이 된다.

온디바이스 추론은 스마트폰, 게이트웨이, 임베디드 보드에서 모델을 로컬로 실행하는 방식이다. NPU, GPU, DSP 같은 하드웨어 가속기를 활용할 수 있지만 배터리 제약도 함께 고려해야 한다.

경량 모델과 장치 런타임을 함께 맞춘다

모델 경량화에는 포스트 트레이닝 정수 양자화(INT8), 구조적 프루닝, 지식증류를 적용할 수 있다. 정확도 손실을 최소화하면서 메모리와 연산량을 줄이는 균형이 필요하다.

런타임과 가속기 선택도 장치별로 달라진다. TFLite Micro, ONNX Runtime Mobile, Core ML, NNAPI, Ethos-U, Jetson TensorRT 등을 사용할 수 있으며, 타겟별 커널 선택과 연산자 호환성 검증이 필요하다.

운영 측면에서는 OTA 모델 배포, A/B 롤아웃, 모델 메트릭 텔레메트리 수집을 구성한다. 오프라인 캐시와 버퍼링, 실패 복구 전략도 포함해야 한다. Secure Boot, 신뢰 실행 환경(TEE), 모델 암호화와 백업키 관리는 보안 계층을 이루고, PII는 로컬에서 익명화·집계한 뒤 전송한다.

클라우드 추론과 다른 제약 조건

항목	엣지 추론(TinyML/On-Device)	클라우드 추론
지연시간	1~50 ms(로컬 처리)	100~500 ms+(네트워크 왕복 포함)
전력소비	수 mW~수백 mW(양자화 모델)	전송·대기 전력 증가 가능
확장성	장치 수 증가에 비례 분산	중앙 확장 용이, 네트워크 병목 가능
일관성(버전)	A/B·점진 배포 필요	중앙 통제 용이
안정성(오프라인)	네트워크 무관 동작	연결 의존
운영 편의	현장 관측 한계, 원격 디버깅 필요	관측성·로깅 풍부
모델 성능/크기	소형·경량, 일부 정확도 손실	대형 모델 가능, 최고 정확도

엣지 추론은 오프라인에서도 동작하고 현장 반응이 빠르지만, 장치별 관측성과 원격 디버깅이 과제가 된다. 클라우드 추론은 중앙 통제가 쉬운 대신 네트워크 왕복과 연결 상태의 영향을 받는다.

센서 데이터가 행동으로 이어지는 경로

예지보전에서는 진동·전류 센서 신호에서 FFT나 멜스펙을 추출하고 TinyML 분류로 이상을 감지한다. MCU(예: Cortex-M4F)와 TFLite Micro 조합이 여기에 해당한다.

스마트 카메라와 비전 장치는 Jetson 또는 NPU 보드에서 객체를 탐지한 뒤 영역을 마스킹하고 메타데이터만 전송할 수 있다. 개인정보 노출을 줄이고 대역폭을 절감하는 방식이다.

리테일 풋폴 분석은 사람 수와 체류시간을 로컬에서 산출해 집계값을 업로드한다. 실시간 대기열 관리와 직원 배치 최적화에 연결된다. 웨어러블 헬스 환경에서는 PPG·IMU 신호의 이상을 감지해 장치에서 알림을 내고 이벤트만 동기화해 배터리 수명을 늘린다.

⤢✕

모델 업데이트는 Tx 단위의 A/B 스왑으로 처리하고 실패하면 롤백한다. 연결이 끊긴 동안에는 로컬 캐시를 유지하다가, 다시 연결되면 요약 데이터를 업로드한다.

장치 선정부터 배포 관측까지

하드웨어는 연산 요구(FLOPS), 메모리, 전력 예산을 기준으로 고른다. DSP 또는 NPU의 존재 여부와 지원 런타임을 함께 확인한다.

데이터와 특징을 설계할 때는 FFT·MFCC 같은 신호 처리와 엔드투엔드 경량 CNN·TCN 사이의 트레이드오프를 결정한다. 온디바이스 전처리 비용도 측정 대상이다.

INT8 양자화는 대칭·비대칭 방식을 검토하고, 프루닝 이후에는 파인튜닝 재학습을 수행한다. 하드웨어별 연산자 호환성은 유닛테스트로 확인한다.

런타임을 통합할 때는 I/O 파이프라인, 스레딩과 RTOS, 전력 상태 관리(DVFS)를 고려한다. 오류 코드와 워치독 타임아웃도 정의한다. 이어서 OTA, A/B 배포, 지연·정확도·드리프트 모니터링을 구성하고 프라이버시 보존 로깅 정책을 적용한다.

마지막으로 Secure Boot, 펌웨어·모델 서명과 암호화, 키 수명주기 관리를 적용한다. 디버그 포트 보호와 공급망 무결성 검증도 필요하다.

Raspberry Pi에서 TFLite Runtime으로 실행하기

환경은 Raspberry Pi OS Bullseye, Python 3.9+, tflite-runtime 2.12+, quantized INT8 모델(.tflite)을 전제로 한다. 모델 입력은 1x16000(int16 오디오 샘플)이라고 가정한다.

# pip install tflite-runtime sounddevice numpy
import numpy as np, sounddevice as sd
import tflite_runtime.interpreter as tflite

RATE, DURATION = 16000, 1.0
interpreter = tflite.Interpreter(model_path="kws_int8.tflite", num_threads=2)
interpreter.allocate_tensors()
inp = interpreter.get_input_details()[0]
out = interpreter.get_output_details()[0]

def record():
    audio = sd.rec(int(RATE*DURATION), samplerate=RATE, channels=1, dtype='int16')
    sd.wait()
    return audio.flatten()[:16000]

while True:
    pcm = record()
    # 간단 정규화/패딩 생략, 실제는 MFCC 등 특징 추출 권장
    x = pcm.astype(np.int16).reshape(1, 16000, 1)
    interpreter.set_tensor(inp['index'], x)
    interpreter.invoke()
    y = interpreter.get_tensor(out['index'])[0]
    label = np.argmax(y)
    conf = y[label]
    if conf > 0.8:
        print(f"Detected label={label}, conf={conf:.2f}")

실제 배포에서는 MFCC 특징 추출과 고정소수점 전처리 커널을 도입하고, 오디오 VAD로 불필요한 추론을 억제하는 방식을 권장한다.

성능 이득과 운영 비용의 균형

에지 AI는 지연시간을 5~~20배 단축하고 전송량을 80~~95% 절감할 수 있다. 배터리 수명은 1.5~~3배 연장되고 클라우드 비용은 30~~70% 절감된다. 개인정보 보호 강화, 오프라인 탄력성 확보, 현장 실시간성 향상도 함께 기대할 수 있으며, 운영 리스크를 분산하고 장애 도메인을 줄이는 효과가 있다.

모델과 펌웨어에는 이중 서명 검증을 적용하고 A/B 파티션 롤백을 설계한다. 원격 설정은 권한을 분리하고 감사 로깅을 적용한다. 데이터는 로컬에서 익명화한 뒤 요약해 올리고, 텔레메트리에는 샘플링과 차등프라이버시를 고려한다.

경량화에는 대가가 있다. INT8 양자화와 프루닝으로 1~3%p 정확도 손실이 가능하므로 업무 임계치에 맞춰 허용오차를 정해야 한다. 장치 수가 늘수록 관측성과 업데이트 복잡도도 커지며, MLOps 자동화로 이를 보완한다. 가속기 특화 최적화는 이식성을 낮출 수 있으므로 표준 런타임과 연산자 집합을 우선 사용하는 편이 낫다.

하드웨어와 런타임의 최신 지원 여부는 벤더 릴리스 노트를 확인할 필요가 있다. 파일럿 PoC, A/B 배포, 관측과 튜닝을 반복하는 방식으로 점진적으로 도입한다.