IoT
센서와 스위치가 인터넷에 붙으면 생기는 문제들 — 작은 기기에 맞는 프로토콜, 몇 년 가는 전지, 엣지와 클라우드의 일 나누기, 기기마다 신원 주기, 원격 업데이트, 그리고 방치된 기기가 만드는 보안 사고 — 를 직접 계산한 그림으로 따라간다.
목차 (12)
IoT의 구조: 기기, 게이트웨이, 클라우드
IoT(사물 인터넷)는 컴퓨터가 아닌 물건 — 온도 센서, 도어락, 전구, 공장 모터 — 이 네트워크로 값을 보내고 명령을 받는 것이다. 대부분 세 층으로 나뉜다.
- 기기: 재는 쪽(센서)과 움직이는 쪽(액추에이터). 작은 마이크로컨트롤러와 무선 칩이 들어 있고, 전지로 도는 것이 많다. 기기 안쪽의 하드웨어는 임베디드 노트에 있다.
- 게이트웨이·허브: 전력이 적은 기기는 BLE·Zigbee·Thread·LoRa처럼 근거리·저전력 무선을 쓰고, 게이트웨이가 이를 받아 인터넷 쪽 프로토콜로 바꾼다. 값을 모으고 거르는 엣지 처리도 여기서 한다.
- 클라우드: 메시지를 받는 브로커, 기기 목록과 상태를 관리하는 기기 관리, 데이터를 쌓고 분석하는 저장소, 앱이 쓰는 API가 있다.
와이파이나 셀룰러를 쓰는 기기(카메라, 원격 검침기)는 게이트웨이 없이 바로 클라우드에 붙는다. 대신 전력을 더 쓴다. 어떤 무선을 고르느냐가 곧 전지 수명·거리·비용을 정하는데, 각 무선 기술의 원리는 무선 통신 노트에 있다.
MQTT: 발행과 구독
웹은 브라우저가 서버에 묻고 답을 받는 요청–응답 방식이다. IoT에서는 센서가 값이 생길 때마다 보내고, 여러 곳(앱, 기록 서버, 경보기)이 그 값을 받아야 한다. 이를 위한 표준이 MQTT다. 모든 기기와 앱이 브로커 하나에 TCP로 연결해 두고, 메시지는 home/livingroom/temp 같은 토픽 이름을 달고 다닌다.
보내는 쪽은 토픽에 발행(publish)하고, 받는 쪽은 토픽 필터를 구독(subscribe)한다. 필터에는 와일드카드가 있다. +는 한 단계(home/+/temp는 모든 방의 온도), #는 그 아래 전부(home/#는 집의 모든 것)에 맞는다. 브로커는 발행된 메시지를 필터가 맞는 구독자에게만 나눠 준다. 발행자는 누가 듣는지 모르고 알 필요도 없다.
구독자 넷이 브로커에 토픽 필터를 등록해 두었다. +는 한 단계, #는 그 아래 전부에 맞는다. 발행자는 누가 듣는지 모른다.
MQTT 5.0은 2019년 3월 OASIS 표준이 되었다. 쓸모 있는 장치가 몇 가지 더 있다. 토픽의 마지막 값을 브로커가 기억해 두었다가 새 구독자에게 바로 주는 보존 메시지(retained), 기기가 인사 없이 끊기면 브로커가 대신 "나 꺼졌음"을 발행하는 유언 메시지(Will)다.
전달 보장은 QoS 세 단계로 고른다. QoS 0은 한 번 보내고 끝이라 잃을 수 있다(최대 한 번). QoS 1은 PUBACK을 받을 때까지 다시 보내니 반드시 가지만, ACK가 사라지면 같은 메시지가 두 번 갈 수 있다(최소 한 번). QoS 2는 네 번의 주고받기로 정확히 한 번을 보장한다. 1분마다 오는 온도처럼 다음 값이 곧 오는 데이터는 QoS 0이면 충분하고, "문이 열렸다" 같은 사건은 QoS 1에 받는 쪽이 중복을 걸러 내는 방식이 흔하다. QoS 2는 왕복이 많아 정말 필요할 때만 쓴다.
CoAP, HTTP와 메시지 크기
더 작은 기기에는 TCP 연결을 계속 붙잡고 있는 것도 부담이다. CoAP(RFC 7252, 2014년)은 웹의 모양(주소, GET·POST·PUT·DELETE)을 그대로 두고 UDP 위에서 4바이트 고정 헤더로 줄인 프로토콜이다. 메시지마다 확인을 받는 확인형(CON)과 받지 않는 비확인형(NON)을 고르고, 값이 바뀔 때 알려 달라는 관찰(Observe) 옵션으로 구독 비슷한 일도 한다. 보안은 TLS 대신 UDP용인 DTLS를 쓴다.
HTTP도 쓸 수는 있다. 방화벽을 잘 통과하고 도구가 많아서, 가끔 보내는 기기나 와이파이 기기는 HTTPS로 바로 API를 부르기도 한다. 다만 헤더가 글자로 되어 있어 작은 값 하나에도 메시지가 커진다. 온도 값 {"t":21.5} 하나를 보내면 MQTT PUBLISH는 35바이트, CoAP 요청은 40바이트인데, 꼭 필요한 헤더만 단 HTTP/1.1 요청은 124바이트다. 실제 HTTP 요청은 인증·쿠키 헤더로 이보다 훨씬 크고, 연결마다 TCP·TLS 악수가 붙는다. 전지로 도는 기기는 라디오를 켜 둔 시간이 곧 전력이라, 이 차이가 수명으로 돌아온다.
저전력 설계: 보고 주기가 수명을 정한다
전지로 도는 IoT 기기는 거의 모든 시간을 잠들어 있다가 잠깐 깨어 재고 보내고 다시 잔다. 깨어 있는 비율이 듀티 사이클이다. 평균 전류는 (깨어 있는 전류 × 시간 + 잠든 전류 × 나머지 시간) / 주기이고, 수명은 대략 전지 용량 / 평균 전류다. 마이크로컨트롤러의 슬립 모드와 1분마다 깨는 센서 예는 임베디드 노트의 전력 관리 절에 있으니, 여기서는 무선 쪽 결정을 본다.
밭의 토양 수분 센서가 깨어 재고 LoRa로 한 번 보내는 데 30 mA를 1.5초 쓰고, 잠든 동안 3 μA를 쓰며, 전지가 2,600 mAh라고 하자. 15분마다 보내면 계산상 약 5.6년, 5분마다면 1.9년, 1분마다면 0.4년이다. 보고 주기를 바꾸는 한 줄 설정이 수명을 열 배 넘게 바꾼다. 거꾸로 1시간마다면 19.1년이 나오지만, 그쯤 되면 전지 자체의 자가 방전과 보관 수명이 먼저 한계가 된다.
그래서 설계는 이런 질문이 된다. 정말 15분마다 알아야 하는가, 값이 크게 바뀔 때만 보내면 안 되는가. 여러 번 잰 값을 모아 한 번에 보낼 수 있는가(라디오를 켜는 횟수가 준다). 응답을 기다리는 확인형 전송이 꼭 필요한가. 잠든 전류도 무시할 수 없다. 끄지 않은 LED나 새는 풀업 저항 때문에 잠든 전류가 50 μA라면 15분 주기의 수명이 5.6년에서 3.0년으로 준다. 와이파이 6의 TWT(깨어날 시각을 AP와 약속)나 셀룰러의 절전 모드도 같은 생각 — 라디오를 꺼 둘 수 있는 시간을 늘리기 — 에서 나왔다.
엣지와 클라우드: 어디서 계산할까
모든 원본을 클라우드로 보내면 처리는 단순하지만 통신비·전력·지연이 커진다. 엣지 처리는 기기나 게이트웨이에서 먼저 계산하고 결과만 올리는 것이다. 모터의 진동을 1 kHz로 2바이트씩 재는 센서를 생각하자. 원본을 그대로 올리면 하루 172.8 MB인데, 게이트웨이가 FFT로 주파수 성분을 보고 1분마다 64바이트 요약(최대값, 주요 주파수, 이상 여부)만 올리면 하루 92.2 kB다. 주파수 분석은 신호 처리 노트에 있다.
엣지에 두는 것이 맞는 일은 대체로 세 종류다. 지연이 짧아야 하는 판단(모터를 바로 멈춘다), 인터넷이 끊겨도 돌아야 하는 기능(집 안 조명 자동화), 밖으로 내보내기 꺼려지는 데이터(카메라 영상에서 사람 수만 세어 올린다). 반대로 여러 기기·여러 현장을 함께 봐야 하는 분석, 긴 기간의 추세, 모델 학습은 클라우드가 잘한다. 실제로는 클라우드에서 학습한 모델을 엣지에 내려보내 돌리는 식으로 함께 쓴다.
프로비저닝과 기기 인증
공장에서 똑같이 찍어 낸 기기 수만 대가 각자 "나는 이 기기다"를 증명해야 한다. 모든 기기에 같은 비밀번호나 API 키를 넣으면, 기기 하나를 뜯어 키를 꺼낸 사람이 모든 기기인 척할 수 있다. 그래서 기기마다 고유한 신원을 준다. 흔한 방식은 공개 키 인증서다.
- 공장에서: 기기 안의 보안 칩(secure element, TPM 같은 것)이 스스로 키 쌍을 만든다. 개인 키는 칩 밖으로 나오지 않는다. 제조사의 인증 기관(CA)이 공개 키에 서명한 기기 인증서를 기기에 기록한다.
- 현장에서: 기기는 클라우드에 상호 TLS(mTLS)로 접속한다. 서버만 인증서를 보이는 웹과 달리 기기도 인증서를 내고, 서버는 그 인증서가 제조사 CA로 이어지는지, 폐기되지 않았는지 확인한다. 그다음 사용자가 앱에서 QR 코드를 찍는 식으로 기기를 자기 계정에 묶는다(소유권 등록).
이렇게 하면 기기 하나가 털려도 그 인증서만 폐기하면 된다. 인증서와 TLS의 원리는 암호학 노트, 인증 전반은 보안 › 인증에 있다.
OTA 펌웨어 업데이트
기기는 팔린 뒤에도 버그가 발견되고 보안 구멍이 알려진다. 사람이 일일이 찾아가 고칠 수 없으니 네트워크로 펌웨어를 바꾸는 OTA(over-the-air) 업데이트가 필수다. 동시에 OTA는 가장 위험한 기능이기도 하다. 업데이트 도중 전원이 나가거나 새 펌웨어에 버그가 있으면 기기가 아예 켜지지 않을 수 있고(벽돌), 업데이트 경로가 뚫리면 공격자가 모든 기기에 자기 펌웨어를 심을 수 있다.
그래서 두 가지를 지킨다. 첫째, 서명 검증이다. 제조사가 개인 키로 이미지(정확히는 이미지의 해시와 버전 등을 담은 매니페스트)에 서명하고, 기기는 미리 심어 둔 공개 키로 확인한 것만 설치한다. 버전 순번도 함께 확인해, 서명은 진짜지만 구멍이 있는 옛 이미지로 되돌리는 것을 막는다. IETF의 RFC 9019가 이런 구조를 정리했다. 둘째, A/B 파티션이다. 펌웨어 자리를 둘 두어 지금 도는 쪽은 건드리지 않고 다른 쪽에 쓴다.
평소: 평소에는 슬롯 A의 v1로 돈다. 슬롯 B에는 예전 이미지가 남아 있다.
안드로이드 휴대폰과 크롬북도 같은 생각으로 업데이트한다. 플래시가 모자라 슬롯을 둘 둘 수 없는 작은 기기는, 작은 복구용 부트로더만 따로 남겨 두고 실패하면 그 부트로더가 다시 내려받게 한다. 업데이트를 한꺼번에 내보내지 않고 일부 기기부터 차례로 늘리는 것도 사고를 줄인다.
보안: 방치된 기기가 무기가 된다
IoT 보안 사고의 상징은 2016년의 Mirai다. 미국 CISA의 경보에 따르면, Mirai는 인터넷을 계속 훑어 원격 관리(Telnet)가 열린 기기를 찾고, 흔한 기본 아이디·비밀번호 62쌍을 차례로 넣어 보는 단순한 방법으로 가정용 공유기·네트워크 카메라·DVR을 감염시켰다. 이렇게 모은 기기로 2016년 9월 보안 블로그 KrebsOnSecurity에 620 Gbps가 넘는, 뒤이어 프랑스 호스팅 업체 OVH에 1.1 Tbps 이상의 DDoS 공격을 했다. 기기 하나하나는 보잘것없지만 수십만 대가 모이면 큰 서비스를 쓰러뜨린다. 주인은 대부분 자기 기기가 감염된 줄도 몰랐다.
교훈은 단순하다.
- 모두 같은 기본 비밀번호를 없앤다: 기기마다 다른 초기 비밀번호를 붙이거나, 처음 켤 때 반드시 바꾸게 한다. 사용자라면 받자마자 바꾼다.
- 쓰지 않는 원격 관리를 닫는다: Telnet 같은 관리 포트를 인터넷에 열지 않고, 공유기의 UPnP가 꼭 필요하지 않으면 끈다. IoT 기기는 손님용처럼 따로 분리한 네트워크에 둔다.
- 업데이트 지원 기간을 확인한다: 보안 업데이트가 끊긴 기기는 알려진 구멍이 그대로 남는다. 살 때 제조사가 업데이트를 언제까지 주는지 보고, 끝난 기기는 바꾸거나 인터넷에서 떼어 놓는다.
규제도 이 방향으로 가고 있다. EU의 사이버 복원력법(Cyber Resilience Act)은 디지털 요소가 있는 제품을 파는 제조사에 설계·개발·유지 보수 전반의 보안 요구와 취약점 처리를 의무로 지운다. 2024년 12월 10일 발효되었고, 취약점·사고 보고 의무는 2026년 9월 11일부터, 주요 의무는 2027년 12월 11일부터 적용된다. 요구를 맞춘 제품에는 CE 마크를 붙인다. 네트워크 쪽 방어는 보안 › 네트워크 보안에 있다.
스마트홈과 Matter
스마트홈의 오랜 문제는 칸막이였다. 전구는 A사 앱, 도어락은 B사 앱, 음성 비서는 C사 것만 지원해서, 기기를 살 때마다 어느 생태계에 붙는지 따져야 했다. Matter는 업계 단체 CSA(Connectivity Standards Alliance)가 만든 공통 응용 계층 표준으로 이 칸막이를 없애려 한다.
- 네트워크: 와이파이와 Thread 위에서 돈다. 전원에 꽂힌 플러그·카메라는 와이파이, 전지로 도는 센서는 Thread를 쓴다. Thread는 IPv6를 쓰는 저전력 메시라서, 허브·스마트 스피커 같은 경계 라우터를 거쳐 집 안 IP 망과 하나가 된다.
- 설정: 새 기기는 블루투스 LE로 휴대폰과 처음 만나 네트워크 정보와 인증서를 받는다(커미셔닝).
- 여러 관리자: 한 기기를 여러 회사의 앱·음성 비서가 함께 제어할 수 있다.
- 집 안 제어: 명령이 클라우드를 돌아 나오지 않고 집 안 망에서 직접 오가니 빠르고, 인터넷이 끊겨도 동작한다.
집에서 기기를 붙일 때 자주 막히는 곳이 둘 있다. 첫째, 값싼 와이파이 스마트 플러그·전구·카메라는 대부분 2.4 GHz 와이파이만 지원한다. 공유기가 2.4 GHz와 5 GHz를 한 이름으로 묶어 내보내면 설정 단계에서 연결이 실패하기도 하는데, 그럴 때는 2.4 GHz 이름을 따로 열어 붙인다(대역 차이는 무선 통신 노트). 둘째, 제조사 클라우드를 거쳐야만 동작하는 기기는 그 회사가 서비스를 끝내면 집 안에 있어도 먹통이 된다. 오래 쓸 기기라면 Matter처럼 집 안에서 직접 제어되는지, 앱 없이도 기본 동작(스위치 켜고 끄기)이 되는지를 살 때 확인한다.
산업 IoT
공장·발전소·수처리장의 IoT는 집과 우선순위가 다르다. 기계를 멈추지 않는 것이 먼저라 장비는 수십 년을 쓰고, 오래된 제어 장비는 보안을 생각하지 않고 만든 프로토콜(예: Modbus)로 말한다. 현장 장비를 직접 제어하는 쪽을 OT(운영 기술), 사무실과 업무 시스템 쪽을 IT라 부르며, 둘을 층으로 나누고 사이를 방화벽과 중간 지대(DMZ)로 막는 구조가 흔하다. 제어 명령은 좁게 막고, 측정값은 중계 서버를 거쳐 위로만 넘긴다.
대표적인 쓰임은 예지 보전이다. 앞 절의 진동 센서처럼 모터·펌프의 진동·온도·전류를 계속 보고, 고장 직전에 나타나는 패턴을 찾아 미리 부품을 바꾼다. 정해진 날마다 바꾸는 것보다 덜 버리고, 고장 나서 서는 것보다 덜 잃는다. 생산 라인 전체의 상태를 모아 가상으로 재현해 보는 디지털 트윈도 같은 데이터 위에서 한다.
데이터 흐름: 기기에서 대시보드까지
IoT 데이터는 대부분 "언제, 어느 기기가, 무슨 값"인 시계열이다. 흐름은 보통 두 갈래다. 실시간 경로에서는 브로커가 받은 메시지를 스트림 처리기가 곧바로 훑어 규칙(온도가 넘으면 알림)과 이상 감지를 돌리고, 시계열 데이터베이스에 넣어 대시보드가 그린다. 배치 경로에서는 원본을 데이터 레이크에 그대로 쌓아 두었다가, 나중에 긴 기간의 분석이나 모델 학습에 쓴다.
기기가 많으면 메시지 수가 금방 커지고, 기기 시계가 틀리거나 늦게 도착하는 데이터도 섞인다. 늦게 온 데이터를 어떻게 다루는지, 스트림과 배치를 어떻게 나누는지는 빅데이터 노트와 데이터 엔지니어링 노트에서 이어진다.
핵심 자료
기기 안쪽(마이크로컨트롤러·버스·전력)은 임베디드 노트, 무선 구간은 무선 통신 노트에 있다.
| 자료 | 종류 | 요지 | 링크 |
|---|---|---|---|
| MQTT Version 5.0 | 표준 | 2019년 3월 OASIS 표준. QoS 0·1·2의 전달 보장, 토픽 필터 와일드카드, 유언(Will) 메시지. | OASIS |
| RFC 7252 — The Constrained Application Protocol (CoAP) | IETF 표준 | UDP 위의 4바이트 헤더, 확인형·비확인형 메시지, GET·POST·PUT·DELETE. | RFC Editor |
| RFC 9019 — A Firmware Update Architecture for IoT | IETF 문서 | 서명된 매니페스트, 신뢰 앵커로 검증, 순번으로 옛 이미지 거부, 예비 이미지 보존. | RFC Editor |
| Heightened DDoS Threat Posed by Mirai and Other Botnets | 보안 경보 | 2016년 Mirai가 기본 계정 62쌍으로 공유기·카메라·DVR을 감염시킨 방식과 권고 대책. | CISA |
| Cyber Resilience Act | EU 정책 | 디지털 제품의 보안 요구. 2024년 12월 발효, 보고 의무 2026년 9월, 주요 의무 2027년 12월부터. | European Commission |
| Matter | 업계 표준 | 와이파이·Thread 위에서 돌고 BLE로 설정하는 스마트홈 공통 표준. | Connectivity Standards Alliance |
- MQTT Version 5.0 — OASIS
- RFC 7252 — The Constrained Application Protocol (CoAP) — RFC Editor
- RFC 9019 — A Firmware Update Architecture for IoT — RFC Editor
- Heightened DDoS Threat Posed by Mirai and Other Botnets — CISA
- Cyber Resilience Act — European Commission
- Matter — Connectivity Standards Alliance
- What is Thread — Thread Group
- About LoRaWAN — LoRa Alliance