Edge ML은 크기에 집착한다

Source: Dev.to

UPS Could Deliver Your Amazon Package on a Cargo E‑Bike

대부분의 도시에서, 대부분의 소포에 대해 이것이 실제로 더 빠를 수 있습니다. 주차 필요 없음. 교통 체증 없음. 바로 문 앞까지.

그 대신 16,000 lb 트럭이 당신의 아파트 건물 앞에 공회전하고, 운전자는 전화 충전기가 들어 있는 봉투를 들고 3층 계단을 걸어 올라갑니다.

UPS가 어리석은 것이 아니라, 트럭은 복잡한 경우를 처리합니다: 대량 배송, 무거운 물품, 200개 정류장이 있는 상업용 경로 등. 복잡한 경우를 위한 인프라를 구축하면, 쉬운 경우를 운영하는 것이 자유롭게 느껴집니다. 같은 트럭, 같은 운전사, 같은 경로. 왜 최적화해야 할까요?

하지만 “자유롭게 느껴진다”는 실제로는 자유롭지 않습니다. 트럭은 공회전 시 디젤을 태우고, 존재하지 않는 상업용 주차 공간이 필요하며, 운전사는 30 %의 시간을 소포를 배달하는 대신 복잡한 문제를 위해 설계된 차량을 운영하는 물류 관리에 소비합니다.

The Edge‑ML Parallel

우리는 복잡한 경우(대형 언어 모델, 멀티모달 추론, 생성 AI)를 위한 인프라를 구축했고, 이제 그것을 모든 것에 사용하고 있습니다.

• 센서 분류? 신경망을 배포합니다.
• 이상 탐지? 트랜스포머를 파인튜닝합니다.
• 예측 유지보수? 당연히 딥러닝이 필요합니다.

업계는 트럭을 더 좁은 주차 공간에 넣는 방법을 찾느라 3년을 보냈습니다. 대부분의 배송은 트럭이 필요하지 않았습니다.

두 가지 실수, 하나가 아니라

크기 집착은 두 가지 별개의 문제를 숨깁니다:

1. 잘못된 모델 선택 – 팀은 가벼운 모델만으로 충분할 때도 과도하게 큰 모델을 선택하는 경우가 많습니다.
2. 배포 경로 계획 – 올바른 모델을 사용하더라도 경로가 부실하면 패키지(또는 예측)가 늦게 도착하거나 전혀 도착하지 않을 수 있습니다.

대부분의 엣지 배포는 예측 유지보수, 이상 탐지, 센서 분류, 품질 관리와 같은 표형 데이터 문제를 다룹니다.

2022년 NeurIPS 논문은 실무자들이 이미 의심하던 바를 확인했습니다: XGBoost와 Random Forests와 같은 트리 기반 모델이 45개의 벤치마크 데이터셋에서 표형 데이터에 대해 딥러닝보다 우수합니다.

• 산업용 IoT 연구에서 XGBoost가 공장 설비 고장을 예측하는 데 96 % 정확도를 달성했으며, 다운타임을 45 % 감소시켰다고 밝혔습니다.
• Random Forest는 설비 고장 분류에서 **98.5 %**의 정확도를 기록했습니다.

소형 모델은 성능이 떨어지는 것이 아니라, 적절한 규모입니다.

• TensorFlow Lite Micro는 16 KB에 들어갑니다.
• TinyML 제스처 인식은 138 KB 크기와 30 FPS로 동작합니다.

이것은 트럭이 아니라 전자 자전거와 같습니다.

하지만 배포 경로가 더 중요합니다. Industry 4.0 AI 프로젝트의 70 %가 파일럿 단계에서 배포 수준의 오케스트레이션 문제 때문에 중단됩니다. 모델은 데모에서는 잘 작동하지만, 실제 배포에서는 문제가 발생합니다.

오케스트레이션 격차

Kubernetes 초창기에 우리는 비슷한 실수를 저질렀습니다. 컨테이너 스케줄링이 가장 어려운 부분이라고 생각했죠. 실제로 가장 어려운 부분은 스케줄링 이후—네트워킹, 스토리지, 관측성, 업데이트, 롤백, 전체 운영 라이프사이클이었습니다.

엣지 ML도 지금 이 교훈을 배우고 있습니다. MLOps가 패키징된 모델에서 끝난다면, 오케스트레이션이 시작됩니다—그리고 오케스트레이션이 바로 엣지 ML이 종종 실패하는 지점입니다.

배송 물류가 어려운 이유를 생각해 보세요. 차량 자체가 문제가 아니라, 변화하는 상황 속에서 수천 대의 차량을 조율하는 것이 어려운 겁니다. 사용 사례에 비해 너무 큰 차량/아티팩트를 운영한다면, 모든 것이 더 복잡해질 뿐입니다.

주요 과제

결론

• 작업에 맞는 도구를 선택하세요. 많은 엣지 작업에서는 가벼운 트리 기반 모델이나 TinyML 추론 엔진이 바로 필요한 전자자전거(e‑bike)와 같습니다.
• 모델 크기만이 아니라 오케스트레이션에 투자하세요. 견고한 라우팅, 업데이트 파이프라인, 플릿 관리가 진정한 차별화 요소입니다.
• 노후화와 이질성의 비용을 기억하세요. 가장 작은 모델이라도 신선하고 일관되게 유지하지 못하면 큰 부담이 될 수 있습니다.

올바른 차량 과 올바른 경로에 집중한다면, 엣지 ML은 마침내 빠르고 저렴하며 신뢰할 수 있게—디젤 트럭의 짐을 뒤로하고—패키지를 전달할 수 있습니다.

엣지 디바이스가 일주일 동안 오프라인이 되면 어떻게 될까?

오래된 모델과 대기 중인 데이터와는 언제 다시 연결되나요? 모든 도로가 항상 열려 있다고 가정하고 경로를 계획하는 것과 같습니다. 다리 하나가 닫히는 순간, 전체 시스템이 붕괴됩니다.

데이터 파이프라인 문제

여기서 “자유롭게 해라”는 실제로 자유롭지 않다. Edge ML이 모델이 너무 커서 실패하는 것이 아니다. 데이터 파이프라인이 양방향 흐름을 위해 설계되지 않았기 때문에 실패한다.

배송 네트워크는 수십 년 전부터 이 점을 배웠다. 패키지는 창고에서 나가지만, 반품은 다시 들어온다. 손상 보고도 다시 들어온다. 배송 확인도 다시 들어온다. 역물류는 순물류만큼 중요하며, 종종 더 어렵다.

전통적인 ML 가정

Edge Device → Cloud → Inference → Response

Edge ML이 실제로 필요로 하는 것

Edge Device ↔ Local Inference ↔ Selective Sync ↔ Model Updates ↔ Back to Edge

이 양방향성은 대부분의 팀이 예상하지 못하는 문제를 만든다. IBM edge deployment guide에서 언급하듯이:

“엣지 배포 시나리오에서는 프로덕션 데이터를 클라우드로 보낼 직접적인 이유가 없다. 이 경우 데이터를 절대 받지 못하게 되고, 학습 데이터의 정확성을 확인할 수 없게 된다. 일반적으로 학습 데이터는 증가하지 않는다.”

모델은 자신이 보는 데이터에 따라 개선된다. 그 데이터가 엣지를 떠나지 않으면 모델은 개선되지 않는다. 하지만 모든 데이터를 클라우드로 보내면, 탈피하려던 중앙집중식 아키텍처를 다시 구축하게 되며, 지연 시간과 대역폭 비용이 추가된다. 이는 모든 반품을 본사의 물류센터를 통해 라우팅하는 것과 같다. 기술적으로는 맞지만 운영상은 악몽이다.

Edge‑to‑cloud ETL 파이프라인은 중요한 인프라로 부상하고 있다. 이 파이프라인은 다음을 필요로 한다:

• 실시간 수집
• 적응형 변환
• 연결이 끊겼을 때의 우아한 복구
• 데이터 주권 제약 준수

50 KB 모델이든 5 GB 모델이든 여기서는 동일한 도전에 직면한다. 파이프라인은 파라미터 수를 신경 쓰지 않으며, 마치 경로가 트럭을 타든 자전거를 타든 상관하지 않는 것과 같다.

실제로 효과가 있는 것

에지 ML에서 성공을 거두는 팀들은 차량을 최적화하는 것을 멈추고 경로를 최적화하기 시작했습니다.

계층형 추론

빠른 의사결정과 복잡한 추론을 분리합니다.

• 에지에서 벡터 검색이 5‑10 ms 안에 실행됩니다 – RTInsights 기사를 참고하세요.
• GPU가 필요 없습니다.
• 간단한 분류와 캐싱은 로컬에서 수행됩니다.
• 복잡한 추론은 네트워크가 허용할 때만 선택적으로 라우팅됩니다.

이것은 라스트‑마일 배송을 위한 전기자전거이며, 대량 창고 이동을 위한 트럭입니다. 차량을 배송에 맞추세요, 그 반대가 아니라.

에지 MLOps 미러

클라우드 기능을 최소한으로 로컬에 복제합니다. 네트워크가 사라져도 에지 노드는 여전히:

• 모델 수명 주기 관리
• 로컬 캐시에서 업데이트 처리
• 텔레메트리를 나중에 동기화하도록 큐에 저장

이는 클라우드‑네이티브 아키텍처가 무시하는 네트워크 장애를 인식합니다. 디바이스는 오프라인이 됩니다. 문제는 배포가 연결을 잃는가가 아니라, 연결이 끊겼을 때도 계속 작동하느냐입니다. 본부가 어두워져도 기능하는 로컬 파견 센터를 떠올려 보세요.

데이터 지역성을 첫 번째 원칙으로

• 2025년까지 기업 데이터의 50 % 이상이 에지에서 처리될 예정 – Medium 기사를 참고하세요. 2021년에는 10 %에 불과했습니다.
• 이미 제조, 소매, 의료, 물류 분야에서 진행 중입니다.
• 성공적인 조직은 에지 배치를 일류 인프라로 간주하고, 지능형 데이터 오케스트레이션을 구축해 데이터를 컴퓨팅으로 옮기기보다 컴퓨팅을 데이터로 이동시킵니다. Telefonica 블로그도 참고하십시오.

선택적 동기화

학습 데이터 문제를 해결합니다.

• 모든 에지 데이터를 클라우드로 보낼 필요는 없습니다—대표 샘플만 보내면 됩니다.
• 이상치와 에지‑케이스 실패는 반드시 전송해야 합니다.
• 모델 신뢰도와 데이터 신규성에 따라 정책이 자동으로 조정되는 스마트 필터링을 에지에서 수행하면, 대역폭이나 중앙 저장소를 과부하시키지 않으면서 학습 파이프라인에 데이터를 공급할 수 있습니다.

손상 보고서만 보내세요. 모든 패키지가 정상 도착했다는 확인은 보내지 마세요.

우리의 솔루션: Expanso

우리는 데이터 오케스트레이션에 초점을 맞춰 Expanso를 구축했습니다. 모델이 50 KB 의사결정 트리이든 4 GB 양자화 LLM이든, 병목 현상은 올바른 데이터를 올바른 장소에 적시에 전달하는 것, 이기종 플릿 전반에 걸친 업데이트 조정, 그리고 절반 이상의 노드가 간헐적으로 연결된 상황에서도 가시성을 유지하는 데 있습니다. 우리의 접근 방식은 에지 노드를 클라우드 아키텍처에 뒤늦게 붙이는 것이 아니라, 데이터 파이프라인의 일류 참여자로 취급합니다. 차량 설계가 아니라 경로 계획에 집중합니다.

Where This Is Heading

• $378 billion projected edge‑computing spending by 2028 – see the ITProToday forecast.
• IDC expects edge AI deployments to grow at 35 % CAGR over the next three years.

그 투자는 더 나은 트럭을 만드는 데 쓰이는 것이 아닙니다. 양자화 문제는 대부분 해결되었습니다. 돈은 실제로 엣지 배포를 작동하게 하는 물류 계층에 들어갑니다.

Federated learning (source)은 연구 호기심에서 생산 요구사항으로 전환되고 있습니다. 이는 데이터를 중앙집중화하지 않고 엣지 데이터에서 모델을 개선할 수 있는 유일한 실용적인 방법으로, IBM 가이드가 경고한 학습‑피드백 루프를 해결합니다. 이기종 환경 전반에 걸친 배포를 단순화하기 위해 표준화된 엣지‑클라우드 오케스트레이션 프로토콜이 등장하고 있습니다. AI가 수천 대의 장치에 분산됨에 따라 보안 표면이 크게 확대되고 있습니다.

이러한 변화를 성공적으로 탐색하는 기업들은 가장 작은 차량이나 가장 빠른 엔진을 가진 기업이 아닙니다. 그들은 차량 최적화가 기본적인 조건일 뿐, 경쟁 우위가 아니라는 것을 일찍이 인식한 기업들입니다. 핵심 문제는 언제나 차량 관리, 경로 계획, 패키지 추적, 그리고 상황 변화에 따른 우아한 성능 저하에 관한 것이었습니다.

Source: https://www.distributedthoughts.org/edge-ml-size-obsession/

올바른 질문

“내 신경망을 엣지 하드웨어에 맞게 어떻게 압축하지?” 가 아니라

“내 실제 문제를 해결할 수 있는 가장 간단한 모델은 무엇인가?” 로 시작하세요. 센서 데이터의 경우, 흔히 결정 트리가 적합합니다—킬로바이트 단위이며 기가바이트가 아닙니다. 이는 표 형식 데이터에서 신경망보다 뛰어난 성능을 입증했습니다.

언어 작업에는 트랜스포머가 필요합니다. Adobe의 SlimLM 은 가능한 모습을 보여줍니다: 1 억~10 억 파라미터, 스마트폰에서 문서 지원.

그 다음에 스스로에게 물어보세요:

• 내 인프라가 실제로 이를 배포하고 유지 관리할 수 있는가?
• 파편화된 장비군에 업데이트를 푸시할 수 있는가?
• 엣지 노드가 연결이 끊겼을 때도 동작할 수 있는가?
• 데이터 파이프라인이 양방향 흐름을 지원하는가?
• 수천 개의 분산 노드에서 추론 품질을 모니터링할 수 있는가?

크기 집착은 두 번이나 핵심을 놓쳤습니다:

1. 간단한 모델이 더 잘 작동할 때 복잡한 모델을 고집함.
2. 실제 병목이 배포였음에도 압축에만 집중함.

UPS가 곧 전자자전거로 봉투를 배달하기는 어렵습니다. 트럭 인프라는 이미 존재하고, 경로는 계획돼 있으며, 운전자는 훈련돼 있습니다. 전환에는 비용이 듭니다.

하지만 처음부터 엣지 ML을 구축한다면 선택권이 있습니다. 트럭이 진지한 물류 기업이 사용하는 수단이므로 트럭 함대를 구축하거나, 실제로 배달하는 물품을 보고 작업에 맞는 차량을 선택할 수 있습니다.

• 배포 가능한 50 KB 모델 은 배포되지 못하는 50 MB 모델 보다 낫습니다.
• 전자자전거라도 작동 가능한 경로가 필요합니다.

엣지는 ML 프로젝트가 사라지는 곳이 아니라, 물류가 성장해야 하는 곳입니다.

---

인텔리전트 데이터 파이프라인이 AI 비용을 줄이는 방법을 배우고 싶으신가요? Expanso 확인하기.

NOTE: 현재 머신러닝을 위한 데이터 준비의 실제 과제—운영, 컴플라이언스, 비용 문제—에 대해 책을 쓰고 있습니다. 여러분의 의견을 듣고 싶습니다.

원문은 Distributed Thoughts 에서 처음 공개되었습니다.