💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 2026년 IoT 클라우드는 왜 다시 봐야 하는가

2018년쯤 IoT 클라우드 플랫폼을 정리한 사람이 있다면, 그 표는 지금 절반이 비어 있다. 구글이 2023년 8월에 Cloud IoT Core를 종료한 것이 신호탄이었다. 같은 분야에서 IBM Watson IoT Platform이 2024년 8월에 뒤따라 사라졌다. "빅 클라우드 셋"이라는 표현은 더 이상 IoT에서는 통하지 않는다. AWS와 Azure 둘만 남았고, 둘 다 자사의 매니지드 IoT 스택을 게걸스럽게 확장하고 있다.

그렇다고 매니지드 IoT가 죽었느냐 하면 정반대다. Particle은 셀룰러 영역에서 단단해졌고, Arduino Cloud는 IoT Cloud Editor를 추가해 메이커·교육 시장의 진입 장벽을 낮췄으며, Adafruit IO와 Blynk는 5달러 보드 사용자들의 사실상 디폴트가 됐다. 오픈소스 진영에서는 ThingsBoard가 풀스택(메시지 브로커·룰 엔진·대시보드)을 묶어 자체 호스팅의 선택지를 만들었고, Balena가 Docker 기반 fleet 관리로 라즈베리 파이 양산에 가까운 운영을 가능하게 했다. Mainflux는 2024년에 Magistrala로 리브랜딩되며 같은 아키텍처의 LF Edge 호환 후속이 됐다. 엔터프라이즈 산업 영역은 Bosch IoT Suite와 Schneider Electric EcoStruxure가 가져갔다. Edge 런타임은 Azure IoT Edge·AWS Greengrass·Open Horizon(LF)·KubeEdge(CNCF) 4개로 좁혀졌다.

> "구글이 떠난 자리, 매니지드는 더 분화했고, 오픈소스는 더 단단해졌다." — 2026년 IoT 클라우드 지도의 한 줄 요약.

이 글의 목표는 18개 플랫폼을 같은 축으로 분해해 정직하게 비교하는 것이다. 비교 후에는 DIY 메이커, 스타트업, 엔터프라이즈, 셀룰러 사업자 — 4가지 시나리오에서 어떤 조합이 맞는지 결정 트리까지 그린다. 모든 가격·기능 수치는 2026년 5월 기준이며, 구조적 차이에 집중한다.

가격은 빠르게 바뀐다. 6개월 뒤 숫자가 바뀌어도 결정 프레임은 유효해야 한다.

1장 · 2026년 IoT 클라우드 지도 — 4분류

플랫폼이 너무 많아 보이지만, 결국 4개 분류로 나뉜다. 분류 자체가 의사결정의 첫 단추다.

**(A) 빅 클라우드 IoT — AWS / Azure**

하이퍼스케일러가 자기 클라우드 안에 IoT 스택을 매니지드로 제공. AWS IoT Core·Greengrass·Device Defender·SiteWise, Azure IoT Hub·IoT Edge·Azure Sphere. 강점은 다른 클라우드 서비스와의 통합(Lambda, Kinesis, Event Hubs, Stream Analytics, S3, Cosmos DB 등). 약점은 록인과 디바이스당 비용. 구글 IoT Core는 종료됐고, IBM Watson IoT도 사라졌다.

**(B) 매니지드 IoT 전문 업체 — Particle / Arduino / Adafruit / Blynk / Losant**

IoT 자체를 본업으로 하는 SaaS. 셀룰러 모뎀까지 묶어주는 Particle, 메이커·교육 시장에 강한 Arduino Cloud와 Adafruit IO, 모바일 앱 빌더가 강한 Blynk, 산업·중간 시장을 노리는 Losant. 강점은 도메인 집중과 단순함. 약점은 빅 클라우드 만큼의 데이터 분석·AI 통합 깊이는 없다.

**(C) 오픈소스 셀프 호스팅 — ThingsBoard / Balena / Magistrala (Mainflux)**

직접 서버를 운영하거나 자체 클라우드에 띄운다. ThingsBoard는 풀스택(MQTT·룰 엔진·대시보드)을 묶은 자바 기반, Balena는 Docker 기반 fleet 관리(라즈베리 파이·NVIDIA Jetson에 강함), Magistrala는 Go 기반 마이크로서비스 아키텍처(Mainflux의 후속). 강점은 데이터 주권·록인 없음·커스터마이즈, 약점은 운영 부담.

**(D) 엔터프라이즈 산업 IoT — Bosch / Schneider EcoStruxure**

산업·빌딩·에너지 도메인에 특화. Bosch IoT Suite는 자동차·인더스트리 4.0, Schneider EcoStruxure는 전력·HVAC·빌딩 자동화. 강점은 도메인 모델과 OT(Operational Technology) 통합, 약점은 가격과 폐쇄성.

이 4분류 위에 **Edge 런타임** 레이어가 따로 산다. Azure IoT Edge, AWS Greengrass, Open Horizon(LF Edge 산하), KubeEdge(CNCF) 4개가 시장을 가져갔다. 디바이스에서 컨테이너·함수를 실행하는 것이 핵심.

그리고 **프로토콜** 레이어. MQTT 5.0이 2018년의 3.1.1을 빠르게 대체하는 중이고, CoAP·AMQP·OPC UA·LoRaWAN·Sigfox는 각자의 영역에서 살아남았다. Matter는 스마트홈 전용이라 이 글에서는 다루지 않는다(별도 글 예정).

> 4분류를 머리에 넣고, 이제 하나씩 본다. 각 장은 같은 틀로 정리한다 — Surface·강점, 디바이스 SDK, 메시징·라우팅, Edge·디바이스 관리, 가격, 약점, 한 줄 요약.

2장 · AWS IoT Core + Greengrass + Device Defender + SiteWise

**Surface · 강점**

AWS의 IoT 스택은 단일 서비스가 아니라 **퍼즐 조각의 집합**이다. 코어 메시징은 AWS IoT Core, 엣지 런타임은 AWS IoT Greengrass v2, 보안·이상 탐지는 AWS IoT Device Defender, 산업 자산 모델링은 AWS IoT SiteWise, 디바이스 관리는 AWS IoT Device Management, 디바이스 시뮬레이션·테스트는 AWS IoT Device Tester. 이 모자이크가 강점이면서 동시에 학습 곡선이다.

**디바이스 SDK**

공식 SDK는 C, C++, Python, JavaScript/Node.js, Java, Embedded C(FreeRTOS 통합). FreeRTOS를 Amazon이 인수해 자사 스택과 통합한 것이 2017년 — 2026년 시점에는 ESP32·STM32·Nordic·NXP에서 FreeRTOS + AWS IoT Device SDK 조합이 사실상 표준 레퍼런스가 됐다.

**메시징·라우팅**

MQTT 3.1.1과 MQTT 5.0 모두 지원. 5.0의 `User Properties`, `Reason Codes`, `Shared Subscriptions`, `Message Expiry` 같은 핵심 기능이 2024년부터 GA. 메시지는 IoT Rules Engine을 거쳐 Lambda, Kinesis, S3, DynamoDB, SQS, SNS, Step Functions, Timestream 등으로 라우팅된다. 룰 엔진은 SQL 유사 구문으로 표현된다.

-- 온도가 80도 넘으면 Lambda 호출, 모든 메시지는 Timestream에 저장

SELECT *, topic(2) AS device_id

FROM 'sensors/+/temperature'

WHERE temperature > 80

**Edge · Greengrass v2**

Greengrass는 디바이스에서 Lambda 함수, Docker 컨테이너, ML 모델을 실행하는 엣지 런타임. v2는 컴포넌트 기반 아키텍처 — `aws.greengrass.Cli`, `aws.greengrass.StreamManager`, `aws.greengrass.Nucleus` 같은 빌트인 컴포넌트와 커스텀 컴포넌트를 조합한다. 배포는 `greengrass-cli` 또는 클라우드 콘솔에서.

**Device Defender · 보안**

이상 탐지(Detect), 보안 감사(Audit), MQTT 토픽 별 ACL을 자동 검증. 2026년에는 ML 기반 이상 탐지가 기본. 위협 인텔리전스 통합도 GA.

**SiteWise · 산업 자산 모델링**

공장 라인의 OPC UA 서버에서 데이터를 끌어와 자산 계층을 모델링한다. SiteWise Edge로 온프레미스에서 데이터 수집·집계 가능. 산업 IoT의 핵심 도구.

**가격**

- 메시지: 100만 건당 약 1달러(미국 동부 기준)

- 디바이스 연결: 분당 0.08달러/100만 분

- 룰 엔진: 100만 룰 실행당 0.15달러

- Greengrass: 디바이스당 월 0.16달러(처음 1000개는 무료)

- SiteWise: 자산·속성 수에 비례

실제 청구서에서 가장 큰 부분은 Rules Engine과 Timestream/Kinesis 비용인 경우가 많다.

**약점**

- 학습 곡선이 가파르다. 6~7개 서비스를 다 알아야 풀 스택이 작동한다.

- 다른 클라우드에 데이터를 보내려면 추가 작업이 필요(인입은 쉽지만 송출은 비용·복잡도 증가).

- 디바이스당 비용이 100만 대 이상 규모에서 부담된다(특히 Greengrass).

**한 줄 요약**

> 가장 완전한 스택. 학습 곡선과 록인을 받아들일 수 있다면 IoT의 끝판왕. 산업 IoT 또는 AWS 코어 인프라가 이미 있는 조직의 디폴트.

3장 · Azure IoT Hub + IoT Edge + Azure Sphere

**Surface · 강점**

마이크로소프트의 IoT 스택은 Azure IoT Hub(코어 메시징), Azure IoT Edge(엣지 런타임), Azure IoT Central(SaaS 형 IoT 앱 플랫폼), Azure Digital Twins(자산·관계 모델링), Azure Sphere(MCU급 보안 OS·하드웨어)로 구성된다. 2025년에는 Azure IoT Operations가 추가돼 Arc 기반 Kubernetes 엣지로 확장됐다.

**디바이스 SDK**

공식 SDK: C, .NET, Python, Java, Node.js, Embedded C. Azure RTOS(구 ThreadX)를 무료화한 후 ESP32·STM32에서도 잘 돈다. 2025년에는 Azure RTOS가 Eclipse Foundation으로 이관돼 **Eclipse ThreadX**로 다시 오픈소스화됐다 — 마이크로소프트는 여전히 주요 컨트리뷰터.

**메시징·라우팅**

MQTT 5.0 지원이 2024년 GA. 디바이스 → IoT Hub로 D2C(device-to-cloud), 클라우드 → 디바이스로 C2D(cloud-to-device). 메시지는 Event Hubs, Service Bus, Blob Storage, Cosmos DB로 라우팅. 디바이스 트윈(Device Twin) — JSON 문서로 디바이스 상태를 미러링하는 핵심 추상화. 이게 Azure의 가장 독특한 부분.

{

"deviceId": "thermostat-001",

"desired": { "targetTemp": 22, "fanSpeed": "auto" },

"reported": { "targetTemp": 22, "fanSpeed": "auto", "currentTemp": 23.4 }

}

`desired`는 클라우드가 원하는 상태, `reported`는 디바이스가 보고한 실제 상태. 이 둘이 같아질 때까지 디바이스가 따라간다. 선언적 디바이스 제어의 표준 패턴.

**Edge · IoT Edge**

Docker 기반(정확히는 Moby) 컨테이너 런타임. 각 모듈은 컨테이너 이미지로 배포된다. 시뮬레이터, Stream Analytics(엣지에서 SQL), Function App, Custom Vision 같은 마이크로소프트 서비스가 모듈로 제공. 모듈 간 통신은 `edgeHub`라는 메시지 라우터를 통한다.

**Azure Sphere — 종료된 줄 알았던 그 OS**

2024년에 종료 발표가 있었지만 2025년에 살아남았다. MediaTek MT3620 MCU + Pluton 보안 서브시스템 + Linux 기반 보안 OS. MCU급 디바이스에 7년간 마이크로소프트가 보안 패치를 제공하는 모델. 가격은 디바이스당 일회성 8.95달러(2026년 기준).

**Azure IoT Operations — 2025년 신상**

Kubernetes 엣지를 Arc로 묶는 새 스택. Kafka 기반 MQTT 브로커, OPC UA 커넥터, 데이터 처리 파이프라인이 핵심. 산업 IoT를 Arc + K8s로 재구성하는 시도.

**가격**

- IoT Hub 무료 티어: 일 8000 메시지(테스트용)

- B1: 디바이스당 월 약 10달러부터 시작, 디바이스 수와 메시지 빈도에 따라 변동

- IoT Edge: IoT Hub 가격에 포함, 디바이스당 추가 비용 없음(코어가 오픈소스라)

- Sphere: 디바이스당 8.95달러 일회성

**약점**

- 디바이스 트윈 모델은 강력하지만 학습 곡선이 있다.

- Azure IoT Central은 잘 만들었지만 가격이 예측하기 어렵다.

- Azure Sphere의 미래는 여전히 불확실. 2024년 종료 위기를 거치면서 신뢰가 깎였다.

**한 줄 요약**

> 디바이스 트윈과 Eclipse ThreadX가 무기. Azure 인프라가 이미 있는 조직에서는 AWS와 동급. 마이크로소프트 생태계와의 통합이 결정 인자.

4장 · Google Cloud IoT Core 종료(2023.8) — 의미

2022년 8월 16일, 구글이 발표했다. "Cloud IoT Core를 2023년 8월 16일에 종료한다." 1년의 마이그레이션 기간. 업계가 흔들렸다.

**왜 종료됐는가**

구글의 공식 입장은 "파트너 생태계가 충분히 성숙해 직접 운영할 필요가 없다"는 것. 실제 이유는 더 복잡했다. (a) AWS·Azure가 IoT에서 압도적이라 따라잡기 어려웠다. (b) IoT Core 매출이 GCP의 다른 영역 대비 작았다. (c) 디바이스당 비용 구조가 GCP의 다른 서비스와 어울리지 않았다.

**마이그레이션 결과**

구글은 ClearBlade, Akenza, SoftServe 같은 파트너를 추천했다. 실제로는 많은 사용자가 **AWS IoT Core 또는 Azure IoT Hub로 이주**했다. 일부는 ThingsBoard·EMQX 등 오픈소스로 갔다.

**남긴 것**

- Pub/Sub은 살아남았다 — IoT 데이터 인입의 백엔드로 여전히 GCP에서 쓸 수 있다.

- BigQuery·Dataflow는 IoT 데이터 분석에 강력하다 — 인입만 다른 곳에서 받아 BigQuery에 넣으면 된다.

- Google Distributed Cloud Edge는 엣지 컴퓨팅에 살아남았지만 IoT Core의 직접적인 후속은 아니다.

**의미**

빅테크가 IoT를 떠나면서 시장이 두 가지 방향으로 갈렸다. (a) AWS와 Azure가 점유율을 빨아들였다. (b) 오픈소스 진영(ThingsBoard, EMQX, Magistrala)이 반사 이익을 봤다. "구글이 떠난" 이 사건이 오픈소스 IoT를 다시 부상시킨 가장 큰 동인이다.

> 구글이 떠난 자리에는 록인을 두려워하는 조직이 ThingsBoard·Magistrala 같은 오픈소스로 갔다. "또 떠날까봐"라는 두려움이 결정의 기준이 됐다.

5장 · IBM Watson IoT 종료(2024.8) — 또 하나의 사라진 빅 플레이어

2023년 8월에 구글이 떠난 자리. 그 1년 뒤, IBM이 같은 길을 갔다.

**Watson IoT Platform 종료**

2023년 12월, IBM은 Watson IoT Platform을 2024년 12월에 종료한다고 발표했다. 실제 종료일은 일정대로 진행됐다. Maximo Application Suite의 IoT 기능이 일부 후속을 맡았지만, "디바이스 → 클라우드 → 분석"을 통합 매니지드로 제공하던 Watson IoT의 자리는 비었다.

**왜**

구글과 비슷하다. (a) AWS·Azure에 밀렸다. (b) IBM의 IoT 영업은 산업 솔루션(Maximo)으로 흡수돼 디바이스-당 IoT 서비스가 별도로 살아남기 어려웠다. (c) Red Hat 인수 이후 IBM의 IoT 전략은 OpenShift·MQTT(HiveMQ 파트너십) 쪽으로 옮겨갔다.

**Maximo로의 흡수**

IBM Maximo Application Suite는 자산 관리 SaaS인데, 여기에 IoT 모니터링·예지 보전 기능이 포함된다. Watson IoT 사용자들은 (a) Maximo로 이주하거나 (b) AWS·Azure로 갔다.

**남은 IBM IoT 자산**

- HiveMQ 파트너십 — MQTT 브로커의 표준 중 하나.

- Red Hat AMQ Streams(Kafka 기반) — IoT 데이터 인입에 쓰임.

- OpenShift on Edge — 엣지 컴퓨팅 플랫폼.

> 빅테크가 "IoT는 우리가 직접 안 한다"는 입장을 두 번 연달아 보였다. 구글·IBM이 떠난 자리는 AWS·Azure로 쏠리거나 오픈소스로 분산됐다.

6장 · Particle — 매니지드 셀룰러 IoT의 강자

**Surface · 강점**

Particle은 셀룰러 IoT를 매니지드로 푸는 단 하나의 회사라고 봐도 좋다. 디바이스(Photon 2 = Wi-Fi, Boron 404X = LTE-M, Tracker SoM = LTE-M+GPS), 셀룰러 SIM(자체 회선 또는 협력 통신사), 클라우드(Particle Cloud), 디바이스 OS, SDK를 한 번에 묶어 판다.

**디바이스 SDK · Device OS**

공식 SDK는 자체 Device OS(C++ 기반, ARM Cortex-M 시리즈)와 Wiring 호환 API. Arduino를 알면 5분 안에 쓴다. Webhook으로 외부 API 호출, Variables/Functions로 클라우드에서 직접 디바이스 함수 호출 가능.

// Particle Device OS — 5분 안에 익히는 패턴

void setup() {

Particle.variable("temp", currentTemp);

Particle.function("setLed", setLed);

}

void loop() {

currentTemp = readTemp();

Particle.publish("temperature", String(currentTemp), PRIVATE);

delay(60000);

}

**셀룰러 영역의 차별점**

Particle은 직접 SIM 카드를 발급하고, 글로벌 LTE-M 로밍을 제공하며, 데이터 요금까지 디바이스 구독에 포함시킨다. **MB 단위로 가격이 책정**되고, 디바이스당 월 데이터 한도 안에서 자유롭게 쓸 수 있다. 이게 AWS·Azure에는 없는 결정적 가치다.

**Edge · Mesh**

원래 Mesh 네트워크(802.15.4 기반)를 밀었지만 2020년에 단종됐다. 지금은 디바이스 단위 셀룰러·Wi-Fi에 집중. Particle Edge SoM 라인은 산업용으로.

**가격**

- 디바이스 활성화: 디바이스당 일회성 약 3달러

- 셀룰러 데이터: 디바이스당 월 3MB까지 약 2달러부터, 50MB까지 약 5달러

- 클라우드 메시지: 기본 무료 한도, 추가는 메시지 수 기반

- Photon 2(Wi-Fi 디바이스): 약 25달러

- Boron 404X(LTE-M): 약 50달러

**약점**

- 디바이스가 Particle 하드웨어로 묶인다. ESP32·STM32를 그냥 쓰기 어렵다.

- 글로벌 셀룰러 로밍이 일부 국가에서 제약이 있다(특히 중국).

- 분석·AI 통합은 AWS·Azure만큼 깊지 않다.

**한 줄 요약**

> 셀룰러 IoT를 단순하게 시작하고 싶다면 Particle. 디바이스·SIM·클라우드를 한 회사에서 받는 가치가 압도적이다. 록인은 받아들여야 한다.

7장 · Arduino Cloud + IoT Cloud Editor

**Surface · 강점**

Arduino가 운영하는 IoT 클라우드. 2019년 Arduino IoT Cloud로 시작해 2024년에 IoT Cloud Editor를 추가해 브라우저에서 곧바로 코드를 짜고 디바이스에 업로드할 수 있게 됐다. ESP32·MKR 시리즈·Nano IoT·Portenta·Nicla 시리즈 등 Arduino 보드뿐 아니라 일부 ESP32/ESP8266 일반 보드도 지원.

**디바이스 SDK**

Arduino 표준 라이브러리(ArduinoIoTCloud). 보드 선언, 변수 매핑, 콜백 함수를 코드 몇 줄로 끝낸다.

// Arduino IoT Cloud — 가장 짧은 패턴

#include "thingProperties.h"

void setup() {

Serial.begin(9600);

initProperties(); // 클라우드에서 자동 생성

ArduinoCloud.begin(ArduinoIoTPreferredConnection);

}

void loop() {

ArduinoCloud.update();

// 변수만 바꾸면 클라우드에 자동 동기화

}

`thingProperties.h`는 Arduino Cloud 콘솔에서 변수를 정의하면 자동 생성된다. "코드는 거의 안 쓰고 변수만 바꾼다"가 디자인 철학.

**대시보드**

드래그&드롭 위젯(차트, 게이지, 스위치, 슬라이더, 알림 등). 누구나 15분 안에 자기 IoT 대시보드를 만들 수 있다. 이게 Arduino가 메이커·교육 시장의 디폴트가 된 핵심 이유.

**가격**

- Free: 디바이스 1대, 데이터 한도 제한적

- Maker: 월 5달러, 디바이스 25대

- Maker Plus: 월 10달러, 디바이스 100대

- School: 교실용 별도 플랜

- Pro: 디바이스당 가격, 산업용 기능 포함

**약점**

- 디바이스 수 제한이 크다(Free 1대, Maker 25대). 산업 규모는 불가.

- 데이터 분석은 기본 시각화 수준. 외부로 데이터를 빼야 분석 가능.

- 코드 자유도가 적다 — 변수 모델에 맞춰야 한다.

**한 줄 요약**

> 메이커·학생·교실의 디폴트. 산업 규모로 키우려면 다른 곳으로 가야 하지만, 학습 곡선의 첫 30분은 Arduino Cloud가 가장 짧다.

8장 · Adafruit IO · Blynk — 메이커 시장의 두 거인

**Adafruit IO**

하드웨어 회사 Adafruit가 운영하는 IoT 클라우드. ESP32·라즈베리 파이·Circuit Playground 등 어떤 보드에서도 MQTT·HTTP로 붙을 수 있다. 디자인이 단순하다 — Feeds(데이터 스트림), Dashboards(시각화), Triggers(조건 → 액션), Actions(웹훅). 그게 전부다.

Adafruit IO — Python 클라이언트 한 줄짜리

from Adafruit_IO import Client

aio = Client("your_user", "AIO_KEY")

aio.send_data("temperature", 23.5)

**가격**

- Free: 데이터 30일 보관, 30점/분 처리량, Feeds 10개, Dashboards 5개

- IO+: 월 10달러, 데이터 60일 보관, 60점/분, Feeds·Dashboards 무제한

**Blynk**

모바일 앱 빌더가 시그니처. 위젯을 드래그해 디바이스 제어 앱을 만들 수 있다. 2018년경 1.0이 무료였다가 2021년에 Blynk IoT(2.0)로 클라우드 기반으로 재출시. 현재는 SaaS 모델.

**가격**

- Free: 디바이스 2대, 메시지 100개/일

- Plus: 월 8.99달러, 디바이스 10대, 메시지 500개/일

- Pro: 월 19.99달러, 디바이스 50대, 메시지 5,000개/일

- Business: 디바이스당 가격, 화이트라벨 앱 지원

**Adafruit vs Blynk 결정 트리**

- 모바일 앱이 우선이면 → **Blynk**(드래그앤드롭 앱 빌더)

- 웹 대시보드만 필요하면 → **Adafruit IO** 또는 Arduino Cloud

- 하드웨어를 Adafruit에서 같이 사고 싶으면 → **Adafruit IO**

- 화이트라벨 모바일 앱 → **Blynk Business**

**약점(공통)**

- 규모 한계가 명확. 디바이스 100대를 넘어가면 다른 플랫폼으로 가야 한다.

- 데이터 분석·AI 통합은 거의 없다.

**한 줄 요약**

> Adafruit IO는 가장 단순한 IoT, Blynk는 가장 빠른 모바일 앱 빌더. 둘 다 메이커·취미·교육의 디폴트, 산업 규모에는 안 어울린다.

9장 · ThingsBoard — 오픈소스 풀스택의 표준

**Surface · 강점**

2017년 시작된 자바·Spring 기반의 오픈소스 IoT 플랫폼. 풀스택이라는 점이 결정적이다 — MQTT/CoAP/HTTP 브로커, 디바이스 관리, 룰 엔진, 대시보드, 사용자·테넌트 관리, 알림까지 한 파일로 묶여 있다. Apache 2.0 라이선스의 Community Edition과 상용 Professional Edition이 있다.

**아키텍처**

- 코어: 자바 Spring Boot, PostgreSQL 또는 카산드라(시계열용)

- 메시지 큐: Kafka 또는 자체 큐(개발용)

- 룰 엔진: 노드 기반 시각 편집기(Node-RED 비슷)

- 대시보드: 위젯 라이브러리 + 커스텀 위젯

**디바이스 SDK**

공식 SDK: Python, Java, C(MQTT), JavaScript, Node.js. MQTT만 알면 어떤 디바이스도 붙는다. 디바이스 프로파일이라는 추상화가 있어 디바이스 유형별 텔레메트리 키·속성·트랜스포트 설정을 미리 정의해 둘 수 있다.

**룰 엔진 — 시그니처**

ThingsBoard의 룰 엔진은 다른 플랫폼과 가장 다르게 생겼다. 메시지가 들어오면 노드 그래프를 따라 흐른다. "온도 80도 넘으면 → 슬랙 알림 + DB 저장 + 알람 생성" 같은 로직을 코드 없이 GUI로 그린다.

[Device Telemetry Upload]

↓

[Filter: temperature > 80]

↓

[Save Timeseries] → [Create Alarm] → [Slack Webhook]

이 시각적 룰 엔진 덕분에 비개발자도 운영 정책을 만들 수 있다.

**대시보드**

50개 이상의 빌트인 위젯. 커스텀 위젯은 JavaScript로 작성. 테넌트별로 화이트라벨링 가능.

**Edge · ThingsBoard Edge**

온프레미스 게이트웨이 또는 엣지 서버에서 ThingsBoard 코어의 일부를 실행하는 방식. 클라우드와 양방향 동기화. 산업 현장의 게이트웨이로 잘 어울린다.

**Professional Edition — 상용 차별점**

Community Edition은 무료지만 고급 기능(클러스터링, RBAC 세분화, 화이트라벨, 고급 알림, OAuth2)은 Pro에 있다. Pro 가격은 인스턴스·테넌트 수·기능에 따라 협상.

**약점**

- 자바·PostgreSQL·Kafka·카산드라를 다 운영해야 한다. 운영 부담이 크다.

- 큰 규모(수십만 디바이스)에서는 카산드라 튜닝이 필요하다.

- 라이선스 분리 — Community에 있는 기능과 Pro에만 있는 기능을 미리 알아야 한다.

**한 줄 요약**

> 오픈소스 풀스택 IoT의 사실상 표준. 클라우드 록인을 피하면서 풀 기능이 필요할 때의 디폴트. 운영 인력이 있다면 강력한 선택.

10장 · Balena (구 resin.io) — Docker 기반 fleet 관리

**Surface · 강점**

2013년 resin.io로 시작해 2018년 Balena로 리브랜딩. 디바이스에서 **Docker 컨테이너를 운영하는 fleet 관리** 플랫폼. 라즈베리 파이, NVIDIA Jetson, BeagleBone, Intel NUC 같은 리눅스 디바이스에 강하다. 100대의 라즈베리 파이를 한 번에 배포·업데이트·모니터링하고 싶으면 Balena가 거의 디폴트다.

**Balena 스택**

- balenaOS: Yocto 기반의 최소 리눅스 OS. 부팅·업데이트·복구를 자동화.

- balenaEngine: Moby 기반의 가벼운 컨테이너 런타임(Docker 호환).

- balenaCloud: SaaS 형 fleet 관리 콘솔.

- openBalena: 자체 호스팅 가능한 오픈소스 버전.

**디바이스 SDK · 컨테이너 모델**

디바이스 SDK가 별도로 없다 — **컨테이너 자체가 SDK**다. 개발자는 자기 앱을 Docker 이미지로 만들고, Balena에 git push 하면 디바이스에 배포된다.

Balena의 가장 짧은 워크플로

balena push my-fleet

→ balenaCloud 빌더가 멀티아키텍처 이미지 빌드 → 모든 디바이스에 OTA 배포

이 단순함이 결정적이다. CI/CD가 git push로 끝난다.

**OTA · A/B 업데이트**

balenaOS는 A/B 파티션을 가지고 있어 업데이트 실패 시 자동 롤백한다. 컨테이너 단위 업데이트는 더 빠르고 안전하다.

**가격 · balenaCloud**

- Free: 디바이스 10대까지, 일부 기능 제한

- Production: 디바이스당 월 약 3달러부터(연간 약정)

- Enterprise: 협상

**openBalena**

완전 오픈소스 버전. balenaCloud의 API 호환 백엔드를 자체 호스팅 가능. 무료지만 운영 부담이 있다.

**약점**

- 디바이스가 리눅스 SBC급(라즈베리 파이·Jetson)이 아니면 안 맞는다. MCU는 대상이 아니다.

- 컨테이너 이미지 크기 때문에 대역폭이 부담될 수 있다(셀룰러에서 특히).

- balenaCloud는 SaaS — 자체 호스팅하려면 openBalena.

**한 줄 요약**

> 라즈베리 파이 100대를 운영해야 한다면 Balena가 디폴트. Docker 컨테이너가 IoT 펌웨어를 대체한다는 철학의 가장 성숙한 구현.

11장 · Mainflux → Magistrala — 오픈소스의 리브랜딩

**Mainflux의 역사**

2016년 시작된 Go 기반 오픈소스 IoT 플랫폼. 마이크로서비스 아키텍처(MQTT 브로커, HTTP 게이트웨이, NATS 메시지 버스, PostgreSQL, Redis, InfluxDB 등). Apache 2.0 라이선스. 가볍고 확장 가능한 게 강점이었다.

**왜 Magistrala로 바뀌었나**

2024년, Mainflux는 **Magistrala**로 리브랜딩됐다. 같은 팀(Abstract Machines)이 만들고, 같은 아키텍처를 이어간다. 변경의 이유는 (a) 상표·법적 정리, (b) LF Edge 산하 프로젝트로 가는 그림, (c) 새로운 기능 추가(인증·권한·정책)와 함께 새 이름이 필요했다.

**아키텍처**

- 코어: Go 마이크로서비스 — 각 기능이 별도 컨테이너로 분리.

- 메시지 버스: NATS(고성능 pub/sub).

- 프로토콜: MQTT, HTTP, CoAP, WebSocket, OPC UA.

- 저장: PostgreSQL(메타), InfluxDB/TimescaleDB(시계열).

- 인증·권한: Magistrala의 신규 정책 엔진(OPA 기반).

**Mainflux 대비 Magistrala의 새 점**

- 정책 엔진 통합 — OPA(Open Policy Agent) 기반의 미세 권한 제어.

- 도메인 모델 정비 — Things, Channels, Domains, Groups 같은 추상화 명확화.

- LF Edge 호환 — Open Horizon·EdgeX 같은 LF Edge 프로젝트와 통합 그림.

**디바이스 SDK**

표준 MQTT/HTTP/CoAP만 알면 붙는다. 별도 SDK가 강제되지 않는 게 철학.

**가격**

오픈소스 — 무료. 상용 지원은 Abstract Machines에서 별도 협상.

**약점**

- ThingsBoard보다 대시보드·룰 엔진이 약하다. 시각화는 외부 도구(Grafana 등)를 붙여야 한다.

- 커뮤니티 크기는 ThingsBoard보다 작다.

- 리브랜딩 직후의 마이그레이션 이슈가 일부 남아 있다.

**한 줄 요약**

> Go 기반의 가벼운 마이크로서비스 IoT 코어. 대시보드보다 백엔드를 더 중시하고, 직접 시각화 도구를 붙일 의사가 있다면 강력한 선택. LF Edge 진영의 자연스러운 합류 지점.

12장 · Losant / Bosch IoT Suite / Schneider EcoStruxure — 엔터프라이즈

**Losant**

미국 발 엔터프라이즈 IoT 플랫폼. 디바이스 관리, 시각적 워크플로 엔진, 대시보드, 사용자 관리, 화이트라벨 옵션을 묶어 판다. 산업 IoT·중간 시장이 타깃. 워크플로 엔진이 시그니처 — 노드 기반 GUI에서 데이터 처리·알림·통합을 그린다.

가격: 디바이스 수·워크플로 실행 수 기반. 견적 협상.

**Bosch IoT Suite**

독일 Bosch가 운영하는 IoT 플랫폼. 자동차·인더스트리 4.0·HVAC·빌딩 자동화 도메인에 특화. Eclipse IoT 프로젝트(Ditto, Hono, Vorto, Kanto)의 주요 기여자이며, 자기 자신의 상용 스택을 Eclipse 위에 쌓았다.

- Bosch IoT Things(Eclipse Ditto 기반) — 디지털 트윈.

- Bosch IoT Hub(Eclipse Hono 기반) — 디바이스 연결성.

- Bosch IoT Insights — 분석.

- Bosch IoT Manager — 디바이스 관리.

Eclipse 위에 쌓은 덕분에 폐쇄적이지 않다는 장점. 가격은 엔터프라이즈 협상.

**Schneider Electric EcoStruxure**

프랑스 Schneider Electric의 IoT·OT 통합 플랫폼. 전력·HVAC·빌딩 자동화·산업 자동화 도메인. 도메인 깊이가 차별점이다.

- EcoStruxure Building Advisor — 빌딩 운영 최적화.

- EcoStruxure Power Monitoring Expert — 전력 모니터링.

- EcoStruxure Asset Advisor — 자산 예지 보전.

- EcoStruxure Augmented Operator Advisor — AR 기반 운영자 보조.

가격은 시스템 통합사(SI)를 통한 협상이 일반적.

**엔터프라이즈 결정 트리**

- 일반 산업 IoT, 자체 도메인이 큼 → **Losant** 또는 **Bosch IoT Suite**

- 자동차·인더스트리 4.0 → **Bosch IoT Suite**

- 전력·HVAC·빌딩 → **Schneider EcoStruxure**

- AWS·Azure 인프라가 이미 있음 → **AWS IoT + SiteWise** 또는 **Azure IoT Hub + Digital Twins**

**약점(공통)**

- 가격이 불투명. 디바이스당 비용을 알기 어렵다.

- SI 의존도가 높다 — 자체 개발 팀만으로 풀 구축하기 어려운 경우가 많다.

- 일부는 도메인 외 사용에서 어색하다.

**한 줄 요약**

> 산업 도메인 모델과 OT 통합이 필요할 때 가는 곳. 자동차·전력·빌딩 같은 깊은 도메인이라면 AWS·Azure보다 빠르게 가치를 만든다. 가격은 협상의 영역.

13장 · Edge 런타임 — Azure IoT Edge / AWS Greengrass / Open Horizon / KubeEdge

**왜 Edge 런타임이 따로 산다**

디바이스에서 코드·컨테이너·ML 모델을 실행할 수 있어야 한다. 클라우드까지 모든 데이터를 보내는 모델은 (a) 대역폭, (b) 지연, (c) 오프라인 동작에서 한계가 명확하다. 그래서 Edge 런타임이 분리된 카테고리로 존재한다.

**Azure IoT Edge**

Docker(Moby) 기반 컨테이너 런타임. 모듈 단위 배포. `edgeAgent`·`edgeHub` 두 시스템 모듈이 코어. Stream Analytics, Function App, Custom Vision을 모듈로 제공. 디바이스 트윈·라우팅 모델이 클라우드와 일관된 게 강점.

**AWS Greengrass v2**

컴포넌트 기반. 자체 컴포넌트 + 빌트인 컴포넌트(StreamManager, Lambda, Docker, ML, CLI 등). Lambda 함수를 디바이스에서 직접 실행할 수 있는 게 시그니처. ML 추론 컴포넌트로 SageMaker Neo 모델 배포.

**Open Horizon (LF Edge)**

IBM이 기증해 LF Edge 산하가 된 오픈소스 엣지 오케스트레이션. 자율 정책 기반 — 디바이스에 정책을 부여하면 매칭되는 워크로드가 자동 배포된다. 클라우드 종속이 없다는 점이 차별점. 100만 디바이스 규모를 목표로 설계됨.

**KubeEdge (CNCF)**

Kubernetes를 엣지로 확장한 CNCF 졸업 프로젝트. 디바이스를 K8s 노드처럼 다루며, kubectl로 디바이스에 워크로드를 배포한다. 클라우드 측 컴포넌트(CloudCore)와 엣지 측 컴포넌트(EdgeCore)로 구성. K8s 운영 경험이 있는 팀에 자연스럽다.

**비교 표**

|---|---|---|---|---|

**선택 가이드**

- Azure 클라우드 사용 중 → **Azure IoT Edge**

- AWS 사용 중, Lambda 친숙 → **AWS Greengrass**

- 클라우드 록인 회피, 대규모 자율 배포 → **Open Horizon**

- 이미 K8s를 운영, 디바이스를 K8s 식으로 다루고 싶음 → **KubeEdge**

> Edge 런타임은 IoT 플랫폼 선택과 부분적으로 분리할 수 있다. AWS IoT Core를 쓰면서 KubeEdge로 엣지를 운영하는 조합도 가능하다.

14장 · 프로토콜 — MQTT 5.0 / CoAP / AMQP / OPC UA / LoRaWAN / Sigfox

**MQTT 5.0 — 사실상 표준**

MQTT는 IoT의 기본 프로토콜이다. 3.1.1에서 5.0으로 넘어가면서 (a) User Properties(메타데이터), (b) Reason Codes(에러 명확화), (c) Shared Subscriptions(부하 분산), (d) Message Expiry, (e) Flow Control(흐름 제어)이 추가됐다. 2024년 GA 후 2026년 현재는 모든 메이저 플랫폼이 5.0을 지원한다.

**CoAP — REST의 IoT 사촌**

UDP 기반, HTTP를 닮은 메서드(GET/POST/PUT/DELETE), Observe 패턴. 매우 가벼워서 (a) 배터리·메모리 제약 큰 디바이스, (b) 6LoWPAN/Thread 네트워크에 어울린다. AWS IoT Core·Magistrala·ThingsBoard가 지원.

**AMQP — 엔터프라이즈 메시지 큐**

RabbitMQ·Azure Service Bus가 대표. IoT보다는 엔터프라이즈 메시지 큐의 표준. Azure IoT Hub는 AMQP를 한 옵션으로 제공. MQTT보다 무겁지만 더 풍부한 메시지 의미.

**OPC UA — 산업 자동화의 표준**

공장·플랜트의 PLC·SCADA에서 데이터를 끌어오는 표준. AWS IoT SiteWise·Azure IoT Operations·KEPServerEX 같은 미들웨어가 이걸 MQTT/AMQP로 변환해 클라우드로 올린다. 산업 IoT의 디폴트.

**LoRaWAN — 저전력 광역**

하루 한 번 송신, 수년간 배터리. 농업·자산 추적·도시 인프라에 강하다. Things Network·ChirpStack 같은 LoRaWAN 네트워크 서버가 AWS·Azure로 데이터를 보낸다. AWS는 IoT Core for LoRaWAN을 직접 제공.

**Sigfox — 초저전력 광역, 사업적으로 흔들림**

2022년 Sigfox SA가 파산해 UnaBiz에 인수됐다. 2026년 현재 네트워크는 가동되지만 미래는 불투명. 새 프로젝트는 LoRaWAN이나 NB-IoT를 검토하는 것이 안전.

**프로토콜 결정 트리**

- 일반 IoT 디바이스 → **MQTT 5.0**

- 매우 제약된 디바이스, IPv6/Thread → **CoAP**

- 엔터프라이즈 메시지 큐 통합 → **AMQP**

- 공장·플랜트 → **OPC UA**

- 농업·자산 추적·저전력 → **LoRaWAN**

- 셀룰러 광역 저전력 → **NB-IoT** 또는 **LTE-M**(Sigfox는 신규 권장 안 함)

15장 · 한국 / 일본 — 자국 시장의 IoT 클라우드

**삼성 SmartThings Cloud**

삼성의 컨슈머·홈 IoT 플랫폼. Matter 표준에 맞춰 진화 중. 가전·홈 디바이스가 강점. 2024년부터 SmartThings Pro로 상용 빌딩 영역에 진출. 외부 디바이스 통합은 SmartThings API를 통해 가능.

**LG ThinQ Cloud**

LG의 컨슈머 IoT 플랫폼. 가전(냉장고, 세탁기, 에어컨)에 강하다. ThinQ AI라는 음성·이미지 모델이 가전과 통합. 외부 개발자에게는 LG Open Platform이 일부 열려 있지만 제한적.

**KT IoT**

KT의 LTE-M·NB-IoT 기반 셀룰러 IoT 플랫폼. 한국 내 LPWA 네트워크의 핵심. AWS·Azure와 파트너십을 통해 클라우드 연동. 산업·인프라(가스·전력·물) 영역에 강하다.

**SK텔레콤 / LG U+**

각자의 IoT 플랫폼을 운영하지만 KT 대비 IoT-전용 브랜드의 입지가 약하다. SKT는 ifland·메타버스·AI 쪽으로 전환 중이고, LG U+는 가정·미디어에 집중.

**Sony Edge AI**

Sony Semiconductor Solutions의 엣지 AI 플랫폼. IMX500·IMX501 같은 카메라 센서 안에서 AI 추론을 돌린다. 카메라가 곧 IoT 디바이스인 모델. 클라우드 측에서는 AITRIOS라는 SaaS로 fleet 관리.

**NEC IoT**

NEC의 산업 IoT·스마트시티 플랫폼. 일본 정부·지자체 프로젝트에 강하다. 안면 인식·생체 인증을 IoT와 묶는 솔루션이 시그니처.

**Hitachi Lumada**

히타치의 산업 IoT·디지털 플랫폼. 자동차·철도·전력·물 도메인에 특화. 자체 OT 자산이 깊다는 점이 차별점. AWS·Azure와 파트너십도 운영.

**NTT Communications · NTT Data**

일본·아시아 통신 사업자. 셀룰러 IoT 회선(NTT Docomo의 LTE-M·NB-IoT)과 클라우드(NTT Com의 Enterprise Cloud)를 묶어 판다. 글로벌 셀룰러 IoT에서 Particle의 경쟁자 격.

**한국·일본 시장의 패턴**

- 컨슈머 IoT는 자국 가전 브랜드(삼성·LG·Sony·파나소닉)가 가져갔다.

- 셀룰러 IoT는 통신사(KT·NTT)가 자국 시장을 잡았다.

- 산업 IoT는 종합 전기·중공업(LG CNS·Hitachi·NEC)이 SI 형태로 가져간다.

- AWS·Azure는 한국·일본에서도 다국적 기업·스타트업의 디폴트지만, 자국 통신·산업 영역에서는 자국 플랫폼이 우세.

> 글로벌 플랫폼만 보면 자국 시장의 절반을 놓친다. 한국·일본에서 IoT 프로젝트를 한다면 자국 통신사·가전·SI의 IoT 자산을 반드시 함께 본다.

16장 · 누가 무엇을 골라야 하나 — 4가지 시나리오 결정 트리

**시나리오 A · DIY 메이커 / 학생 / 1-10대 디바이스**

- 예산 최소, 학습 곡선 최소 → **Adafruit IO** 또는 **Arduino Cloud**

- 모바일 앱 우선 → **Blynk**

- 자기 인프라를 갖고 싶고 학습 의지가 있음 → **ThingsBoard Community Edition** + 라즈베리 파이

- 코드 안 쓰고 변수만 → **Arduino Cloud + IoT Cloud Editor**

**시나리오 B · 스타트업 / 100-10,000대 디바이스**

- Wi-Fi 디바이스, AWS 인프라 → **AWS IoT Core**

- 셀룰러 디바이스, 글로벌 → **Particle**

- 록인 회피, 운영 인력 있음 → **ThingsBoard PE** 또는 **Magistrala** + 자체 클라우드

- 라즈베리 파이 fleet → **Balena**

- 메시지 양 적고 단순함이 우선 → **Adafruit IO+** (단, 10K는 한계)

**시나리오 C · 엔터프라이즈 / 10,000-1,000,000대 디바이스**

- 산업 IoT, AWS 사용 → **AWS IoT Core + Greengrass + SiteWise**

- 산업 IoT, Azure 사용 → **Azure IoT Hub + Edge + Digital Twins**

- 자동차·인더스트리 4.0 → **Bosch IoT Suite**

- 빌딩·전력·HVAC → **Schneider EcoStruxure**

- 클라우드 록인 회피, 100만+ → **Open Horizon** 또는 **KubeEdge** + 오픈소스 코어

- K8s 운영 중 → **KubeEdge** + **EMQX/HiveMQ** + **InfluxDB/TimescaleDB**

**시나리오 D · 셀룰러 IoT 사업자**

- 글로벌 셀룰러 fleet → **Particle**

- 한국 LPWA → **KT IoT**

- 일본 셀룰러 → **NTT Communications**

- 셀룰러 + AWS → **AWS IoT Core for LoRaWAN** + 자체 SIM

- 셀룰러 + Azure → **Azure IoT Hub** + Azure SIM

**시나리오 E · 컨슈머 가전 / 스마트홈**

- 한국 가전 통합 → **삼성 SmartThings** 또는 **LG ThinQ**

- 일본 가전 통합 → **Sony AITRIOS** 또는 자국 가전 브랜드 API

- 글로벌 스마트홈 → **Matter** 표준 + 자체 매니지드(별도 글 예정)

**플랫폼 선택의 잘못된 신호 5가지**

1. **벤치마크 메시지/초 숫자만 본다.** 실제 운영에서는 디바이스 관리·룰 엔진·대시보드가 더 중요한 경우가 많다.

2. **무료 티어만 본다.** 디바이스 수가 늘면 가격이 폭발하는 플랫폼이 많다. 1만 대 기준 월 비용을 추정하라.

3. **빅 클라우드만 본다.** 록인을 받아들일 준비가 안 됐다면 오픈소스의 운영 비용을 다시 계산하라.

4. **자국 플랫폼을 무시한다.** 한국·일본 시장에서는 자국 통신·가전·SI가 결정적 자산을 갖고 있다.

5. **단일 플랫폼만 본다.** AWS IoT Core + ThingsBoard 대시보드, Particle + Azure 백엔드 같은 조합이 흔하다.

17장 · 안티패턴 · 흔히 보는 실수

1. **빅 클라우드를 자동으로 선택한다.** "AWS 쓰니까 AWS IoT" 라는 추론이 잘 맞는 경우도 있지만, 디바이스 수·메시지 빈도·데이터 분석 깊이에 따라 다른 선택이 더 싸고 단순한 경우가 많다.

2. **구글이 떠난 사건을 잊는다.** 빅테크가 IoT 서비스를 종료한 전례가 있다. 록인을 두려워해야 할 이유. 데이터 인입은 표준 프로토콜(MQTT 5.0)로, 데이터는 표준 포맷(JSON/Parquet)으로 두면 이주가 쉽다.

3. **셀룰러 비용을 추정 안 한다.** 디바이스당 월 데이터 비용이 IoT 플랫폼 비용의 5~10배가 되는 경우가 흔하다. 클라우드 청구서만 보면 진짜 비용을 놓친다.

4. **Edge 런타임을 늦게 추가한다.** 디바이스가 늘어난 뒤 엣지 처리를 추가하면 아키텍처 재설계가 필요하다. 처음부터 엣지 처리가 필요한지 결정하라.

5. **디바이스 보안을 사후 추가한다.** AWS IoT Device Defender, Azure Defender for IoT, ThingsBoard의 OAuth2 같은 보안 도구를 처음부터 켜둔다. 100만 대가 된 뒤에 보안 사고가 나면 비용이 1000배다.

6. **오픈소스 운영 비용을 과소평가한다.** ThingsBoard·Magistrala·EMQX를 직접 운영하면 SRE·DBA·보안 인력이 필요하다. 매니지드 대비 진짜 비용을 계산하라.

7. **프로토콜 록인을 잊는다.** AWS의 비표준 MQTT 확장(예: HTTP-MQTT 변환)에 종속되면 이주가 어렵다. 표준 MQTT 5.0만 쓰도록 강제한다.

18장 · 다음 글 예고 · 결론

다음 글에서는 **Matter 표준과 스마트홈 IoT 2026** — 삼성 SmartThings, Apple Home, Google Home, Amazon Alexa의 Matter 호환 현황과, 가정용 IoT가 빅테크 5사로 압축되는 그림을 본다. 그 다음은 **OPC UA + 산업 IoT 심층** — 공장·플랜트의 PLC·SCADA에서 어떻게 데이터를 끌어와 AWS IoT SiteWise·Azure IoT Operations로 올리는지의 실제 아키텍처.

**핵심 정리**

- 빅 클라우드 IoT는 AWS·Azure 둘만 남았다. 구글 IoT Core(2023.8)·IBM Watson IoT(2024.8)는 종료됐다.

- 매니지드는 Particle(셀룰러), Arduino Cloud(메이커), Adafruit IO·Blynk(취미)로 분화됐다.

- 오픈소스는 ThingsBoard(풀스택), Balena(Docker fleet), Magistrala(Mainflux 후속)가 자리를 잡았다.

- 엔터프라이즈는 Bosch IoT Suite·Schneider EcoStruxure·Losant가 도메인을 가져갔다.

- Edge 런타임은 Azure IoT Edge·AWS Greengrass·Open Horizon·KubeEdge 4개.

- 프로토콜은 MQTT 5.0이 표준, OPC UA가 산업, LoRaWAN이 LPWA에서 산다.

- 한국·일본은 자국 통신·가전·SI(KT·NTT·삼성·LG·Sony·Hitachi)가 자국 시장의 절반을 가져갔다.

> 2026년 IoT의 본질은 "어떤 빅 클라우드를 쓸 것인가"가 아니라 **"디바이스 수·데이터 주권·록인 회피·운영 인력"의 4축에서 어디에 서느냐**다. 18개 플랫폼은 이 4축의 어느 한 지점에 자리잡고 있다. 자기 위치를 정확히 알면, 답은 셋으로 좁혀진다.

참고 / References

- [AWS IoT Core — Overview](https://aws.amazon.com/iot-core/)

- [AWS IoT Greengrass v2 — Developer Guide](https://docs.aws.amazon.com/greengrass/v2/developerguide/)

- [AWS IoT Device Defender](https://aws.amazon.com/iot-device-defender/)

- [AWS IoT SiteWise](https://aws.amazon.com/iot-sitewise/)

- [Azure IoT Hub — Documentation](https://learn.microsoft.com/en-us/azure/iot-hub/)

- [Azure IoT Edge — Documentation](https://learn.microsoft.com/en-us/azure/iot-edge/)

- [Azure Sphere — Documentation](https://learn.microsoft.com/en-us/azure-sphere/)

- [Azure IoT Operations — Overview (2025)](https://learn.microsoft.com/en-us/azure/iot-operations/overview-iot-operations)

- [Google Cloud IoT Core Retirement Notice](https://cloud.google.com/iot/docs/release-notes)

- [IBM Watson IoT Platform Retirement](https://www.ibm.com/cloud/architecture/architectures/iotArchitecture/)

- [Particle — Cellular IoT Platform](https://www.particle.io/)

- [Arduino IoT Cloud](https://cloud.arduino.cc/)

- [Adafruit IO](https://io.adafruit.com/)

- [Blynk IoT](https://blynk.io/)

- [ThingsBoard — Open-Source IoT Platform](https://thingsboard.io/)

- [Balena — Container-based IoT](https://www.balena.io/)

- [Magistrala (Mainflux successor)](https://github.com/absmach/magistrala)

- [Losant — Enterprise IoT Platform](https://www.losant.com/)

- [Bosch IoT Suite](https://bosch-iot-suite.com/)

- [Schneider Electric EcoStruxure](https://www.se.com/ww/en/work/campaign/innovation/overview.jsp)

- [Open Horizon — LF Edge](https://www.lfedge.org/projects/openhorizon/)

- [KubeEdge — CNCF](https://kubeedge.io/)

- [MQTT 5.0 Specification — OASIS](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)

- [CoAP — RFC 7252](https://datatracker.ietf.org/doc/html/rfc7252)

- [OPC UA — OPC Foundation](https://opcfoundation.org/about/opc-technologies/opc-ua/)

- [LoRaWAN — LoRa Alliance](https://lora-alliance.org/about-lorawan/)

- [Sigfox / UnaBiz](https://www.unabiz.com/)

- [Samsung SmartThings](https://www.smartthings.com/)

- [LG ThinQ](https://www.lg.com/global/lg-thinq/)

- [Sony AITRIOS](https://www.aitrios.sony-semicon.com/en/)

- [Hitachi Lumada](https://www.hitachi.com/products/it/lumada/global/en/index.html)

- [NTT Communications](https://www.ntt.com/en/services/network/iot.html)