2023년 말, 중국 남부의 3PL 분류 센터에서 이상한 문제가 발생했다. 화물은 벨트 위를 초속 1.8미터로 날아다니는데, 화물 인식은 클라우드 AI 추론으로 돌리고 있었다. 왕복 한 번에 380밀리초가 걸렸고, 그 사이 화물은 68센티미터를 이동했다. 분류 슈트의 폭은 고작 60센티미터였다. 오분류율은 0.3%에서 4.7%로 치솟았다. 하루 80,000개의 화물 중 3,700개 이상이 잘못된 슈트로 떨어진 것이다. 그날 밤 엔지니어들은 모델을 현장의 엣지 박스로 옮겼다. 지연시간은 60밀리초 미만으로 떨어졌고, 다음 날 오분류율은 0.4%로 돌아왔다.
모든 창고는 결국 AI 추론의 엣지 vs 클라우드라는 질문에 직면한다. 그 계산법을 세 부분으로 정리했다. 지연시간, 비용, 그리고 네트워크가 죽었을 때 무슨 일이 생기는지.
먼저 원칙: 학습과 추론은 다른 일이다
운전 배우기와 운전하기의 차이를 생각해 보자. 운전학원에서 배운다(클라우드 — 큰 연산력, 서두르지 않는다). 하지만 도로에 나오면 스스로 실시간으로 반응한다(엣지 — 밀리초의 반응). AI도 마찬가지다. 클라우드에서 모델을 학습시키는 것은 당연하지만, 추론을 어디에서 돌릴지는 워크로드에 달려 있다.
창고의 AI 워크로드는 세 가지 맛이 있다.
- 컴퓨터 비전: 바코드 판독과 재스캔, 화물 파손 검출, 치수 측정, 지게차와 보행자 안전 검출. 데이터가 크다(영상 스트림이 쏟아져 들어온다), 실시간 요구가 엄격하다.
- 음성: 음성 피킹, 예외 보고용 음성→텍스트. 음성 스트림은 실은 아주 작다 — 하지만 상호작용은 폐루프이고, 사람은 기다려 주지 않는다.
- 예측: 수요 예측, 보충 제안, 인력 계획. 배치 작업이다. 답이 한 시간 뒤에 와도 아무도 신경 쓰지 않는다.
그리고 가짜 요구에 대한 직설 한마디. 어느 창고 주인이 클라우드 AI로 컨베이어 위 화물을 실시간으로 셀 수 있냐고 물은 적이 있다. 나는 광전 카운터는 몇백 달러면 되고, 네트워크도 필요 없고, 지연시간은 사실상 제로라고 답했다. AI는 만능 망치가 아니다. 모든 걸 못 취급하는 건 그만두자. 현장에서 즉각 기각.
엣지 vs 클라우드: 지연시간 계산법 — 창고가 감당 못하는 밀리초는 몇인가
첫 번째 갈림길은 지연시간 예산이다. 클라우드 추론 지연시간 = 업로드 + 클라우드 연산 + 다운로드. 일반적인 구성에서 왕복 한 번이 100–300 ms, 네트워크 흔들림 때는 500 ms를 넘기는 것도 전혀 이상하지 않다. 엣지 추론은 로컬에서 돌고, 보통 30–80 ms면 끝난다.
지연시간 예산으로 세 개의 선을 그어 보자.
| 지연시간 예산 | 대표 워크로드 | 둘 곳 |
|---|---|---|
| 밀리초 폐루프(<100 ms) | 소터 분류, AMR 장애물 회피, 안전 긴급정지 | 엣지, 논의의 여지 없음 |
| 초 단위 상호작용(<1–2 s) | 음성 피킹 확인, 스캔 검증 | 엣지 또는 인근 노드 |
| 수 분 이상 | 수요 예측, 보충, 보고서 | 클라우드 |
지연시간 계산을 해 보자. 소터 1.8 m/s, 클라우드 왕복 380 ms, 화물 변위 = 1.8 × 0.38 = 68 cm. 슈트 폭은 60 cm — 인식 결과가 돌아올 때쯤이면 화물은 이미 자기 슈트를 지나쳐 버렸다. 이건 알고리즘 문제가 아니라 물리다. 어떤 모델 정확도로도 구할 수 없다.
여기가 직관을 거스르는 부분이다. 많은 사람들이 "클라우드 연산력이 더 강하니 인식 정확도도 높다"고 착각한다. 틀렸다. 정확도는 모델과 학습 데이터에서 나온다 — 같은 모델을 엣지 하드웨어에서 돌리면 정확도는 동일하다. 클라우드가 진짜로 나은 것은 정확히 두 가지뿐이다. 모델 학습과 수천 개 작업의 일괄 처리. "정확도 향상을 위해 클라우드를 고른다"는 건 바보 세금을 내는 셈이다.
엣지 vs 클라우드: 비용 계산법 — 대역폭 청구서 vs 하드웨어 청구서
두 번째 계산은 돈이다. 클라우드는 트래픽과 API 호출에 계속 과금한다. 엣지는 일회성 하드웨어 투자 + 전기세다. 계산법이 다르다.
대역폭부터 보자. 1080p 카메라 한 대, H.264, 업로드 2 Mbps. 2 × 86,400 / 8 ≈ 하루 21.6 GB, 카메라 한 대당 월 약 650 GB다. 20대면 월 13 TB의 업스트림 트래픽이 나온다. GB당 단가는 말하지 않겠다 — 클라우드 업체의 최신 공개 요금을 확인해 보라 — 하지만 수십 테라바이트 규모에서는 그 청구액으로 엣지 박스를 몇 대나 살 수 있다.
2024년 3월, 중국 동부의 의류 창고가 음성 피킹을 클라우드 경유로 운영했다. 작업자는 수량을 말하고 확인음을 1.2초 기다렸다. 하루에 수백 번씩 수량을 되말했고, 생산성은 종이 피킹 아래로 떨어졌다. 인식을 현장 엣지 박스로 옮기니 지연시간이 300 ms 미만으로 줄었다. 미묘한 교훈은 이렇다. 음성 데이터는 아주 작다. 그래서 대역폭이 병목이었던 적은 한 번도 없었다 — 상호작용 지연시간이 문제였다. 사람을 1초 기다리게 하면 짜증 내고, 되말하고, 시스템 전체가 느려진다. "작은 데이터, 빡빡한 상호작용" 워크로드에서 클라우드는 고생하느라 돈을 쓰는 셈이다.
비교식은 간단하다. 엣지는 3년 상각 하드웨어 + 전기세 + 유지보수 인건비를 3년간의 총 추론 횟수로 나눈다 — 그게 추론당 비용이다. 클라우드는 트래픽 + API 요금을 총 호출 수로 나눈다. 작은 숫자가 이긴다. 24시간 안정적인 워크로드는 엣지에서 아름답게 상각된다. 간헐적인 배치 워크로드는 클라우드의 종량제가 더 싸다. 그게 비용의 갈림길이다.
네트워크가 죽으면: 클라우드가 놓치는 걸 엣지가 받을 수 있을까
세 번째 계산은 모두가 잊는 것이다. 창고의 네트워크는 죽는다. 나는 봤다. 지자체 도로 공사로 절단된 광케이블, ISP 장애, 죽은 코어 스위치. 클라우드 추론이 죽으면 모든 게 함께 죽는다. 로컬 하드웨어의 엣지 추론은 계속 돌아간다.
2024년 8월, 중국 북부의 창고가 도로 공사로 광케이블을 잃었다 — 6시간의 오프라인. 입고 스캔 비전은 엣지에서 돌아갔기에, 그 6시간 동안 약 9,000박스를 다운타임 없이 처리했다. 반면 옆의 풀클라우드 창고는 같은 6시간을 수기로 입고 기록하며 보냈다. 축소 모드를 미리 설계하라. 비전은 바코드만으로 떨어뜨리고(파손 검출은 생략), 음성 피킹은 버튼 확인으로 폴백하고, 예측 작업은 네트워크가 돌아올 때까지 멈춘다. 축소 모드는 타협이 아니다 — 설계의 일부다.
유지보수의 함정: 엣지 하드웨어를 비참하게 만드는 세 가지
원칙은 정리했고, 갈림길은 그었다 — 이제 유지보수의 함정이다. 이게 엣지의 진짜 비용이다.
첫째, 열과 먼지. 여름에 40°C가 되는 창고는 흔하다. 먼지로 막힌 엣지 박스가 뜨겁게 돌아가면, 정격 50,000시간의 MTBF는 가볍게 반 토막 난다. 분기별 청소를 표준 절차에 넣어라 — 열 스로틀링이 걸린 뒤에 떠올리면 늦다.
둘째, 모델 버전 불일치. 엣지 박스 20대, A 박스는 v2.3, B 박스는 v2.1, 인식 결과가 엇갈린다 — 그 디버깅은 울고 싶어진다. 모든 박스에 OTA 일괄 배포하고, 배포마다 박스별로 버전 검증을 하고, 불일치 시 알림을 띄워야 한다. 엣지 배포가 가장 자주 폭발하는 곳이 여기다.
셋째, 모니터링의 사각지대. 죽은 클라우드 서버는 1분 안에 누군가에게 알림이 간다. 구석에서 죽어가는 엣지 박스는 며칠이고 눈치채지 못한다. 하트비트 보고 + 워치독, 5분 오프라인이면 자동 알림 — 첫날부터 설정하라.
그래서 돈이 아까운가? 이 한 숫자만 보라
맨 처음 말로 돌아가자. 추론당 비용이다. 3년간의 엣지 총 지출을 3년간의 총 추론 횟수로 나눈다. 클라우드의 트래픽 + API 요금을 총 호출 수로 나눈다. 작은 숫자가 이긴다. 지연시간 예산이 "가능"을 정하고, 추론당 비용이 "경제적"을 정하고, 오프라인 폴백이 "생존 가능"을 정한다. 세 계산을 모두 돌리면 엣지 vs 클라우드의 답은 저절로 쓰인다.
Da Liu, 자동화 엔지니어 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
