편의점 냉장고에서 바다 위 선박까지, IoT는 연결될 때도 끊길 때도 멈추지 않아야 합니다
편의점 냉장고에서 바다 위 선박까지, IoT는 연결될 때도 끊길 때도 멈추지 않아야 합니다
냉장·냉동, 방제·위생, 조선, 모빌리티, 검사장비. 다섯 산업의 현장에서 검증한 IoT 관제 플랫폼 구축기

지난 글에서 저희는 IoT Ops를 소개했습니다. 산업마다 반복되는 디바이스 인증, 데이터 수집, 저장, 운영 관제의 공통 구조를 미리 만들어 두고, 고객은 자기 산업만의 차별화에 집중하게 하자는 이야기였습니다.

그 글을 읽고 나면 자연스럽게 다음 질문이 남습니다. 그래서 그 위에서 실제로 무엇이 지어졌는가.
이번 글이 그 답입니다. IoT Ops를 기반으로 구축한 고객 현장 다섯 곳의 이야기를 담았습니다.
여러 산업의 현장을 겪으며 저희가 내린 결론이 있습니다. IoT는 온라인일 때만 잘 돌아가면 되는 시스템이 아닙니다. 온라인과 오프라인, 두 상태 모두에서 제 역할을 해야 합니다.
네트워크는 끊어집니다. 서버는 장애를 일으킵니다. 장비는 바다 한가운데 떠 있기도 합니다. 그런 순간에도 데이터가 사라지지 않고, 서비스가 멈추지 않고, 다시 연결되면 오프라인 동안 쌓인 데이터를 이어서 보내는 구조를 만드는 데 IoT 프로젝트 시간의 대부분이 들어갑니다.
저희가 수행한 프로젝트 가운데 오프라인 대응과 실시간 처리가 두드러졌던 다섯 곳을 골라 보여드리겠습니다.
CASE 01 · C사 · 냉장·냉동
1. 클라우드 이전의 새로운 전략 : 마이그레이션과 현대화를 한 번에
냉장·냉동 업계 최초 AWS 클라우드 기반 통합관제 플랫폼
편의점과 매장의 냉장 쇼케이스는 한번 설치되면 제조사의 눈에서 사라집니다. 고장이 나면 매장 점주가 전화로 증상을 설명하고, 기사가 출동해서야 원인을 알 수 있었습니다. 그 사이 상하는 것은 냉장고 속 상품이고, 무너지는 것은 매장의 하루 매출입니다.
관리 대상은 쇼케이스 하나가 아닙니다. 상업용 쇼케이스, 인버터 냉동기, 차량용 냉동기, 물류창고용 저온 시스템, 업소용·가정용 주방 냉장·냉동기기까지, 식품 산지에서 매장으로 이어지는 콜드체인 전 구간에 제품이 놓여 있습니다. 제품마다 봐야 하는 지표와 고장 유형도 다릅니다.
이 프로젝트에서 저희는 Wi-Fi 모듈이 탑재된 이 제품들을 AWS IoT로 연결해, 냉장·냉동 업계 최초의 클라우드 기반 24시간 통합관제 체계를 구축했습니다.
핵심은 화면이 아니라 ‘업무 흐름’이었습니다. 관제 화면에서 끝나지 않고 설치 정보 등록, 이상 알림 발생, CS 티켓 발급, 부품 주문, 서비스 배정, 완료 처리까지 기간계¹ CS 시스템과 연동된 실제 운영 업무 전 구간을 담았습니다. 장비의 상태 정보도 플랫폼에서 이력으로 관리됩니다.
원격 진단·제어
운전 상태와 알람을 실시간으로 확인하고, 개별 제어부터 전체 에코모드 전환까지 원격으로 처리합니다.
고장진단 가이드와 주요 부품 분석
고장 신호가 오면 어떤 부품을 봐야 하는지까지 함께 제시합니다. A/S 접수부터 조치까지의 판단 근거가 시스템 안에 있습니다.
FOTA²와 기간계 연동
펌웨어 원격 업데이트는 물론, 기존 영업·서비스 시스템과 연결했습니다. 따로 노는 시스템이 아니라 업무에 붙어 있는 플랫폼입니다.


이 플랫폼은 해외 편의점 매장 오픈과 함께 글로벌 현장에도 적용되었습니다. 서울의 관제 화면에서 해외 매장의 쇼케이스 상태가 보입니다. 고객이 전화하기 전에 제조사가 먼저 알게 되면서, A/S는 사후 대응에서 선제 대응으로 순서가 바뀌었습니다.
CASE 02 · C사 · 방제·위생
2만 대 장비, 72억 건 데이터를 멈추지 않고 옮기다
On-Premise·Azure에 분산된 IoT 환경을 AWS로 통합한 데이터 수집 플랫폼
해충 방제는 현장을 눈으로 확인해야 하는 일이었습니다. 음식점, 카페, 급식소, 식품 공장처럼 위생이 곧 신뢰인 사업장에 설치된 장비를 사람이 돌며 확인해야 했습니다. 방제 대상도 하나가 아닙니다. 쥐를 잡는 구서 트랩, 바퀴 같은 보행 해충용 트랩, 파리·모기를 잡는 UV 포충기가 각각 다른 방식으로 포집하고, 확인해야 하는 지표도 다릅니다. 이 장비들을 사람이 주기적으로 돌며 포집 상태를 확인하고 서비스 주기를 감으로 조정했습니다. 방제 성과가 좋았는지는 다음 방문 때가 되어야 알 수 있었습니다.

장비가 데이터를 보내기 시작하면 이 순서가 뒤집힙니다. 어느 매장의 포집량이 갑자기 늘었는지, 주방과 창고 중 어느 구역에서 발생이 반복되는지, 어떤 점포가 다음 점검 대상인지를 방문 전에 알 수 있습니다. 해충 방제가 ‘정기 순회’에서 ‘발생 데이터에 따른 대응’으로 바뀌는 지점입니다.
문제는 규모였습니다. 전국에 2만 대가 넘는 방제·위생 장비가 데이터를 보내는데, 이를 받는 구조가 사내 서버 한 대의 단일 구조였습니다. 이 서버에 문제가 생기면 2만 대 전체의 데이터 수신이 멈춥니다. 장애가 복구되어도 밀렸던 트래픽이 한꺼번에 몰려 다시 쓰러질 수 있는, 전형적인 단일 장애점(SPOF)³ 구조였습니다. 실제로 장애가 잦았고, 장비가 늘어날수록 서비스가 멈출 위험도 함께 커졌습니다.
저희는 이 환경을 AWS 기반으로 재설계했습니다. 목표는 두 가지였습니다. 허브·Wi-Fi·LTE·Wi-SUN⁴ 등 통신 모듈별로 흩어진 엣지⁵ 데이터와 기존 Azure 환경의 데이터를 하나로 통합하는 것, 그리고 장애가 잦았던 온프레미스⁶ 서버를 클라우드로 전환해 장비가 계속 늘어나도 서비스가 흔들리지 않게 하는 것.
데이터 수집만 옮긴 것이 아닙니다. 설치 정보 등록부터 원격 제어와 FOTA, 이상 알림 발생 시 CS 티켓 발급과 부품 주문, 서비스 배정과 완료 처리까지 기간계 CS 시스템과 연동된 운영 서비스 전 구간을 함께 구축했습니다.
유실을 허용하지 않는 파이프라인
실시간 스트림(Kinesis)을 이중 구조로 설계하고, 처리에 실패한 메시지는 별도 대기열(DLQ)⁷에 격리했다가 원인 파악 후 재처리합니다. 받다가 흘리는 데이터를 구조적으로 없앴습니다.
목적별 3계층 저장소 (Hot·Warm·Cold)
최근 데이터는 빠른 조회용(Hot), 집계 데이터는 운영 분석용(Warm), 원본 로그는 장기 보관용(Cold)으로 분리 저장해, 한 DB에 모든 부하가 몰리던 병목을 해소했습니다.
실시간 관제 · 원격 제어 · FOTA
2만 대 장비의 운전 상태를 실시간으로 관제하고, 원격 제어와 펌웨어 업데이트를 같은 플랫폼에서 처리합니다. 수집에서 그치지 않고 관제·제어·배포까지 담습니다.

이 프로젝트에서 가장 공들인 부분은 이관이었습니다. 오래 운영해 온 노후 데이터베이스에는 72억 건의 데이터가 사실상 하나의 테이블에 로그처럼 쌓여 있었습니다. 서비스와 분석, 이력 관리의 근거가 되는 자산이라 한 건도 버릴 수 없었고, 옮기는 동안에도 서비스는 돌아가야 했습니다.
그래서 이관은 세 갈래로 진행했습니다. 첫째, 현장의 2만 대 장비는 손대지 않았습니다. 장비를 교체하거나 방문하는 대신 데이터 수집 경로를 일시적으로 이중화해, 기존 서버와 신규 AWS 플랫폼이 같은 데이터를 동시에 받게 했습니다. 둘째, 과거 데이터는 원본 DB를 백업한 뒤 신규 구조에 맞게 스키마를 변환하고, 데이터 성격에 따라 실시간 조회용·집계용·장기 보관용 저장소로 나눠 배치로 옮겼습니다. 셋째, 이관이 끝난 뒤 건수와 정합성을 원본과 대조해 유실이 없음을 확인하고 나서야 기존 플랫폼을 내렸습니다. 노후 장비와 노후 DB라는 조건에서도 72억 건이 무손실로 신규 플랫폼에 올라간 이유입니다.

통신 통합도 이 프로젝트의 성과입니다. 방제 현장은 음식점 주방, 지하 창고, 식품 공장 설비실처럼 통신 환경이 제각각이라 장비마다 통신 방식이 다를 수밖에 없습니다. 허브, Wi-Fi, LTE, 그리고 저전력 장거리 통신인 Wi-SUN까지 국내에서 손꼽히게 다양한 방식이 섞여 있었습니다. 수집 진입점도 하나가 아닙니다. 레거시 장비는 TCP 소켓으로 직접 붙고, 기존 Azure 환경의 데이터는 API로 인수하며, 장비가 올리는 페이로드는 바이너리와 JSON이 섞여 있습니다. 이를 진입 단계에서 파싱해 하나의 통합 프로토콜로 변환하기 때문에, 이후 저장·분석 계층은 장비 종류를 신경 쓰지 않습니다.
이렇게 정리된 구조는 국내에서 멈추지 않습니다. 클라우드 기반으로 재설계한 덕분에 해외 법인과 사업장도 같은 플랫폼 위에서 확장할 수 있습니다. 리전과 테넌트⁸를 분리해 국가별 데이터 보관 요건과 운영 조직을 나누면서도, 관제 화면과 CS 연동 흐름은 국내에서 검증한 그대로 재사용합니다. 새 국가에 진출할 때 플랫폼을 다시 만들지 않아도 됩니다.
쌓인 방제 데이터는 관제용으로만 쓰이지 않습니다. 포집 이력과 이미지 데이터는 이미지를 보고 해충 종류를 자동 판별하는 AI를 학습시키기 위한 선행 자산이 됩니다. 오늘의 방제 기록이 내일의 판별 서비스 재료가 되는 구조입니다.
CASE 03 · H사 · 조선
바다 위 오프라인 환경을 극복하는 엣지-클라우드 연동 체계
선박 CCTV 안전 관제를 위한 엣지 기반 OTA⁹·미디어 전송 체계
앞의 두 현장이 가끔 오프라인이 되는 환경이라면, 선박은 다릅니다. 위성과 LTE에 의존하는 바다 위에서는 오프라인이 예외가 아니라 기본값입니다.
이 환경에서 풀어야 했던 문제는 두 가지였습니다. 육상에서 선박의 CCTV 관제 소프트웨어를 안전하게 업데이트하는 것, 그리고 선박에서 감지된 안전 이벤트 영상을 육상으로 보내는 것.
저희는 선박마다 AWS IoT Greengrass 기반의 엣지 에이전트를 배포하고, 클라우드와 엣지가 역할을 나누는 구조를 설계했습니다.
끊겨도 처음부터 다시 받지 않는 업데이트
수 GB급 업데이트 파일을 통째로 내려받다 회선이 끊기면 처음부터 다시 받아야 합니다. 그래서 파일을 나눠 내려받고 체크섬으로 검증한 뒤 적용하도록 설계해, 불안정한 회선에서도 배포가 끝까지 완료되게 했습니다.
회선이 끊겨도 데이터는 남습니다
위성·LTE가 끊기면 상태 보고와 전송 대기 데이터를 선박 내 로컬 저장소에 쌓아 두고, 다시 연결되면 자동으로 이어서 전송합니다.
선박이 감지한 안전 이벤트 영상을 육상에서 확인
AI 영상 분석(YOLO)이 감지한 안전 이벤트의 이미지와 영상을 선박 내 임시 저장소에 보관했다가, 대용량 파일도 나눠서 클라우드로 업로드합니다.
배에 오르지 않는 원격 점검
선박 방화벽 내부 장비에 보안 터널로 원격 접근할 수 있어, 문제가 생겨도 배에 사람이 오를 필요가 없습니다.


다른 세 현장이 설치 등록부터 서비스 배정·완료까지 운영 업무 전 구간을 구축한 것과 달리, 이 프로젝트는 배포와 전송 체계를 먼저 세우는 단계입니다. 오프라인이 기본값인 환경에서는 데이터가 오가는 길부터 확보해야 그다음 서비스가 성립하기 때문입니다. 육상의 IoT가 연결이 복구되면 이어가는 설계라면, 해상의 IoT는 끊긴 상태에서도 일하는 설계여야 합니다.
배포가 어느 선박에서 어디까지 진행됐는지, 성공했는지 실패했는지는 모두 클라우드에서 이력으로 관리됩니다. 구축을 완료했고, 실제 운항 환경의 위성 통신 현장 테스트로 검증을 이어가고 있습니다.
CASE 04 · H사 · 모빌리티
달리는 차 안으로, 실시간 서비스를 되돌려 보내다
SDV¹⁰ 시대의 커넥티드카 — 양산 차량 인포테인먼트 실시간 데이터 파이프라인
소프트웨어로 정의되는 차, SDV 시대의 자동차는 저희가 다뤄 온 IoT 디바이스 가운데 가장 크고 가장 빠르게 움직이는 디바이스입니다. 차량의 기능이 하드웨어가 아니라 소프트웨어로 정의되고, 출고 이후에도 서비스가 계속 추가됩니다. 그 서비스의 뒤편에는 차량과 클라우드를 이어주는 데이터 파이프라인이 있어야 합니다.
이 프로젝트에서 저희는 완성차 그룹의 소프트웨어 계열사와 함께 양산 차량의 인포테인먼트(IVI)¹¹ 실시간 데이터 체계를 구축했습니다. 저희가 맡은 몫은 AWS 인프라 아키텍처 설계와 구축, 그리고 차량 데이터가 오가는 수집·배포 파이프라인입니다.
구조의 핵심은 데이터가 한 방향으로 흐르고 끝나지 않는다는 점입니다. 전국을 달리는 차량들이 라디오·미디어 청취 데이터를 올리면, 스트림 분석이 실시간 랭킹과 통계를 만들고, 그 결과가 다시 차량 안 화면의 서비스로 내려갑니다. 지금 이 순간 가장 많이 듣는 라디오 채널, 실시간 인기 콘텐츠 같은 정보가 데이터를 만든 바로 그 차량들에게 되돌아가는 순환입니다. 수집이 곧 서비스가 됩니다.
실시간 수집과 재배포의 순환
차량이 MQTT¹²로 올린 데이터를 IoT Core와 스트림(MSK)으로 받아 실시간 분석하고, 랭킹·통계 결과를 서비스 토픽으로 다시 차량에 내려보냅니다. 수 분 안에 도는 수집·분석·배포 사이클입니다.
차량 데이터 수집을 소프트웨어로 정의
어떤 차종의 어떤 신호를 언제 수집할지 신호 카탈로그, 차량 모델, 수집 캠페인으로 정의하고 관리하는 도구를 직접 개발했습니다. 데이터 수집 정책이 코드와 화면에서 정의되는, SDV다운 운영 방식입니다.
차량 단위 인증과 프로비저닝
차량마다 토큰 기반 인증을 거쳐야 서비스에 접근할 수 있고, 신규 차량은 정해진 프로비저닝 절차로 등록됩니다. 대규모 차량의 신원을 안전하게 관리하는 기반입니다.
수집·서비스 상태 모니터링
수집 데이터와 서비스 로그를 오픈서치 대시보드로 모니터링합니다. 양산 서비스답게, 흐름이 끊기면 사람이 먼저 알 수 있어야 합니다.


디바이스가 냉장고에서 자동차로 바뀌어도 뼈대는 같습니다. 인증서 기반 연결, 스트림 수집, 실시간 처리, 목적별 저장이라는 앞의 현장들에서 검증한 구조 위에, 차량이라는 디바이스의 특성인 큰 규모와 높은 실시간성, 그리고 차량으로 되돌아가는 배포 경로가 얹혔습니다. 관제로 시작한 IoT가 차량 서비스의 기반이 되는 것, 저희가 SDV 시대를 준비하는 방식입니다.
CASE 05 · T사 · 검사장비 (진행 중)
‘장비를 파는 회사’에서 ‘가동을 보장하는 회사’로
산업용 X-ray 검사장비를 위한 AIoT 통합관제 플랫폼 · 구축 진행 중
이차전지·반도체 검사에 쓰이는 산업용 X-ray 장비 제조사인 이 고객사는 지금 비즈니스의 전환점에 서 있습니다. 글로벌 고객사들이 입찰 단계에서부터 원격 정비·모니터링 탑재를 필수 사양으로 요구하기 시작했기 때문입니다.
좋은 장비를 만드는 것만으로는 부족하고 장비의 가동까지 책임져야 하는 시대. 저희는 그 전환을 뒷받침할 통합관제 플랫폼을 함께 구축하고 있습니다. 앞의 네 현장과 달리 이 프로젝트는 지금도 진행 중입니다.
핵심 과제는 다른 제조사 현장과 같습니다. 장비를 온라인으로 관제하고 서비스 업무와 연결해, 고객 입장에서 끊기지 않는 서비스를 만드는 것입니다. 해결 방식도 C사의 두 현장에서 검증한 구조를 그대로 가져왔습니다. 이상 알림이 CS 티켓 발급, 부품 주문, 서비스 배정과 완료 처리로 이어지는 운영 흐름, 그리고 국가별 리전과 테넌트를 분리해 유럽, 일본, 중국, 동남아시아, 북미, 중미 등 해외에 설치된 장비까지 같은 플랫폼에서 관제하는 글로벌 확산 구조입니다.
다른 점은 하나, 이 장비는 항상 온라인이 아니라는 것입니다. 검사장비는 업무시간에만 가동되고, 공장 내부망 정책상 외부와 끊긴 채로 있는 시간이 오히려 더 깁니다. 그래서 장비 옆에 AWS IoT Greengrass 엣지를 두고, 오프라인 동안 쌓인 데이터를 연결되는 순간 이어서 보내는 구조가 필수였습니다. 돌아오는 방향도 마찬가지입니다. 오프라인 중에 내려간 제어 명령과 설정은 디바이스 섀도우¹³와 리테인드 메시지¹⁴에 보관되어, 장비가 다시 연결되는 순간 마지막 상태로 자동 동기화됩니다.
- 장비의 핵심 신호를 놓치지 않고 수집
- X-ray 튜브의 진공도와 온도, 디텍터의 상태, 본체의 냉각·전원 신호까지 고장의 전조가 되는 텔레메트리¹⁵를 Greengrass 엣지에서 수집합니다. 오프라인 상태에서도 수집은 계속되고, 임계치를 넘는 신호는 알람으로 만들어져 서비스 업무로 이어집니다.
- 오프라인이 되어도 잃지 않는 3중 안전망
- 업무시간 외에는 꺼져 있고 내부망도 자주 끊기는 장비 특성에 맞춰, 엣지의 영속 버퍼가 오프라인 구간의 데이터를 쌓아 두고 재연결 시 순서대로 이어서 전송합니다. 처리 실패에 대비한 재처리 대기열, 저장 계층 병렬 적재까지 더해 열악한 필드에서도 데이터 유실을 막습니다.
- 수명주기 기반 3계층 저장
- 실시간 조회용(Hot), 운영 분석용(Warm), 장기 보존·AI 학습용(Cold)으로 데이터를 나눠 쌓습니다. C사 방제·위생 현장에서 검증한 것과 같은 기본 구조입니다.
- 전 세계 장비를 한 화면에
- 국가별 리전과 테넌트를 분리해 해외 고객사에 설치된 장비까지 지도 위 한 화면에서 관제하고, 이상 징후는 알람에서 CS 티켓 발급, 부품 주문, 서비스 배정으로 이어집니다.
- 원격 제어 · FOTA
- 장비 상태 관제에 더해 원격 제어와 펌웨어 업데이트를 같은 플랫폼에서 처리합니다. 글로벌 고객사가 요구하는 원격 정비의 핵심입니다.


쌓인 데이터는 관제에서 끝나지 않습니다. 데이터 분석으로 제품을 고도화하고, AI가 이상 데이터를 감지해 먼저 알려주고 알림 룰셋을 자동 추천하며, 촬영 조건을 산출해 엣지에서 자율 추론하는 단계로 이어집니다. 나아가 예지보전과 자원관리(ERP)가 맞물려, 이상 감지부터 정비 계획과 자원 배정까지 순환하는 구조로 확장합니다. 오늘 유실 없이 쌓은 데이터가 그대로 내일 AI의 학습 데이터가 됩니다.
다섯 번의 프로젝트의 공통점
디바이스·엣지 → 수집 → 처리·저장 → 백엔드 서비스 → 프론트 서비스 → AI 분석·예지보전(고도화)
산업도 통신 환경도 달랐지만, 다섯 프로젝트의 구성도를 겹쳐 놓으면 같은 계층이 남습니다. 오프라인 구간을 흡수하는 엣지와 큐, 유실을 허용하지 않는 수집 파이프라인, 목적별로 나뉜 저장 계층, 그 위에 얹히는 백엔드 서비스와 관제 프론트엔드입니다. 여기에 공통으로 붙는 세 가지가 더 있습니다. 알림을 기간계 CS 업무(티켓 발급·부품 주문·상태 관리)로 넘기는 연동, 쌓인 데이터를 분석해 제품을 고도화하고 AI 이상 감지·예지보전으로 이어 가는 축, 국가별 리전·테넌트를 분리해 해외 현장까지 같은 구조로 확산하는 설계입니다.
그리고 저희는 이 공통 구조를 프로젝트마다 처음부터 새로 만들지 않습니다. 디바이스 인증, 수집 파이프라인, 관제·알림, CS 연동처럼 반복되는 계층은 사내에서 공통 기반으로 발전시켜 온 IoT Ops 위에서 시작합니다. 다섯 현장의 플랫폼도 이 공통 기반을 각 산업의 조건에 맞게 확장하는 방식으로 구축했습니다. 프로젝트마다 바닥부터 다시 만들지 않으니 구축 기간과 리스크가 줄고, 한 현장에서 검증된 개선이 다음 현장에 그대로 반영됩니다.

프로젝트 한눈에 보기

다섯 번의 프로젝트가 우리에게 가르쳐 준 것 — IoT 프로젝트의 세 가지 질문
냉장 쇼케이스, 방제 장비, 선박 CCTV, 달리는 차량, X-ray 검사기. 산업도 장비도 통신 환경도 전부 달랐지만, 프로젝트가 성공하기 위해 답해야 했던 질문은 언제나 같았습니다.
첫째, “오프라인이 되면 어떻게 되는가?”
네트워크 단절, 서버 장애, 트래픽 폭주 같은 비정상 상황을 먼저 설계해야 합니다. 방제·위생 현장의 이중 수집과 재처리 대기열, 조선 현장의 오프라인 큐잉, 검사장비 현장의 3중 안전망은 전부 이 질문의 답입니다.
둘째, “현장에 가지 않고 해결할 수 있는가?”
냉장·냉동의 원격 진단·제어, 방제·위생의 장비 교체 없는 플랫폼 전환, 선박에 오르지 않는 원격 접근과 OTA가 그 답입니다. 출동이 필요한 경우에도 기사가 모바일로 설치 정보와 점검 결과를 등록해 같은 플랫폼에 쌓이므로, 현장에서 돌아와 다시 입력하는 일이 없습니다. 현장 출동이 줄어드는 만큼 운영 비용과 대응 시간이 함께 줄어듭니다.
셋째, “쌓인 데이터로 무엇을 할 것인가?”
관제 화면은 시작일 뿐입니다. 72억 건의 데이터 자산, 실시간 랭킹이 되어 차량으로 되돌아가는 주행 중 데이터, 검사장비의 AI 학습용 데이터 계층처럼 오늘의 운영 데이터가 내일의 예지보전과 AI 서비스의 토대가 되도록 처음부터 설계해야 합니다. 이 토대는 한 번에 완성되지 않고, 운영하면서 지속적으로 쌓아 가는 것이 중요합니다.
현재까지의 여정, 그리고 다음 구간
냉장 쇼케이스, 방제 장비, 선박, 자동차, 검사장비. 산업은 달랐지만 여정의 방향은 하나였습니다. 현장의 장비가 오프라인이 되어도 데이터가 남고, 다시 연결되면 이어서 처리되고, 그 사이에도 서비스가 멈추지 않는 구조를 만드는 일입니다.
지금까지의 여정은 엣지에서의 오프라인 수집과 큐잉, 유실 없는 저장·처리, 알람에서 CS 업무로 이어지는 연결, 국가별 리전·테넌트로 나누는 글로벌 확산까지 왔습니다.
앞으로의 여정은 쌓인 데이터에서 시작합니다. 데이터를 분석해 제품을 고도화하고, AI 이상 감지와 알림 룰셋 자동 추천을 거쳐 예지보전으로, 관제하는 IoT에서 AI가 판단하고 움직이는 운영(AX)으로 나아갑니다.

이 글에 담은 다섯 곳은 그 여정의 일부입니다. 프로젝트는 구축으로 완성되지 않고, 한 단계씩 다음 모습으로 진화합니다. 지금까지가 데이터를 유실 없이 모으는 IoT의 이야기였다면, 이제 남은 구간은 그렇게 쌓인 데이터를 쓰는 IoT입니다. 이상 신호를 먼저 알아채는 AI 감지, 현장별 알림 룰셋 자동 추천, 그리고 데이터 분석을 통한 제품 고도화입니다.
다음 편 예고 — 구축 이후의 운영, 그리고 판단하는 IoT. 알람을 줄이는 일, 데이터 품질을 지키는 일, 그리고 쌓인 데이터가 이상 감지와 예지보전으로 이어지는 과정을 다룹니다.

용어 한 줄 정리
1. 기간계 시스템 회사의 핵심 업무(영업·CS·재고 등)를 처리하는 사내 기반 시스템
2. FOTA (Firmware Over-The-Air) 현장에 가지 않고 무선으로 장비의 펌웨어를 업데이트하는 방식
3. SPOF (단일 장애점) 그 하나가 멈추면 전체 서비스가 멈추는 지점
4. Wi-SUN 검침기·센서망에 쓰이는 저전력 장거리 무선 통신 규격
5. 엣지 (Edge) 클라우드가 아니라 장비 바로 옆(현장)에서 데이터를 처리하는 컴퓨팅
6. 온프레미스 (On-Premise) 클라우드가 아닌 사내 전산실에 직접 구축·운영하는 서버 환경
7. DLQ (Dead Letter Queue) 처리에 실패한 메시지를 버리지 않고 따로 모아 두는 대기열
8. 테넌트 하나의 플랫폼 안에서 회사·조직별로 분리된 공간
9. OTA (Over-The-Air) 소프트웨어·설정을 원격으로 배포하는 방식의 통칭
10. SDV (Software Defined Vehicle) 기능이 하드웨어가 아니라 소프트웨어로 정의되고 출고 후에도 업데이트되는 차량
11. IVI (인포테인먼트) 차량 안의 미디어·내비게이션·정보 서비스 시스템
12. MQTT IoT 장비가 쓰는 경량 양방향 메시징 프로토콜
13. 디바이스 섀도우 장비의 최신 상태·설정을 클라우드에 복사해 두는 장치. 오프라인 중의 변경도 재연결 시 동기화됨
14. 리테인드 메시지 장비가 나중에 접속해도 받아볼 수 있게 보관되는 마지막 메시지
15. 텔레메트리 장비가 주기적으로 보내오는 상태·측정 데이터
✍️ by 천필호, Specialty Service Unit

