IoT 시스템 아키텍처 — 통신 모델부터 AWS까지, 이론과 실전의 연결

IoT(Internet of Things)는 단순히 센서를 인터넷에 연결하는 것이 아닙니다. 수많은 이질적 시스템들이 유기적으로 협력하여 하나의 인텔리전트 시스템처럼 동작하는 것 - 이것이 IoT 어플리케이션의 본질입니다.

이 글에서는 IoT 시스템의 통신 모델(Client/Server vs Messaging), 네트워크 계층 구조, MQTT 프로토콜의 CS적 배경, 그리고 실제 AWS 서비스와의 연결까지 정리합니다.

1. IoT 시스템의 계층 구조

IoT 시스템은 크게 세 개의 계층(Layer)으로 구성됩니다.

Device Layer (하단)

센서, 액추에이터, 카메라, 스마트 락 등 물리적 장치가 존재하는 계층입니다. 이 장치들은 현실 세계를 모니터링(sensing)하거나, 제어 명령을 실행(actuating)하는 역할을 합니다.

Device Layer의 특성:

• 제한된 컴퓨팅 리소스: CPU, RAM, 저장장치가 극도로 제한된 환경입니다. 이것이 MQTT처럼 경량 프로토콜이 필요한 근본적 이유입니다.
• 다양한 통신 인터페이스: Bluetooth, ZigBee, LoRa, Wi-Fi, 셀룰러(LTE/5G) 등
• 전력 제약: 배터리로 동작하는 경우가 많아 통신 빈도와 데이터 처리를 최소화해야 합니다.

Gateway / Edge Layer (중간)

Device와 Cloud 사이를 중계하는 계층입니다. 스마트폰, 셋톱박스, 라즈베리파이 같은 장비가 이 역할을 합니다.

 

통신 구간	프로토콜	특성
Device ↔ Gateway	Bluetooth, ZigBee, BLE	저전력, 단거리, 저대역폭
Gateway ↔ Cloud	Wi-Fi, LTE/5G, 유선 LAN	고대역폭, 안정성
Device ↔ Cloud (직결)	Wi-Fi, LTE/5G	Gateway 없이 직접 연결. 전력·비용 상승

 

Gateway의 실무적 역할:

• 프로토콜 변환: BLE → MQTT 등 디바이스 통신을 클라우드 통신으로 변환합니다.
• Edge Computing: 데이터를 클라우드로 보내기 전에 고집·필터링·전처리를 수행합니다.
• 로컬 의사결정: Latency가 크리티컬한 경우 클라우드 왕복 없이 Edge에서 즉시 대응합니다.

AWS에서는 AWS IoT Greengrass가 이 역할을 담당합니다 — Lambda 함수를 Edge 디바이스에서 실행하고, 로컬에서 MQTT 메시지를 처리할 수 있습니다.

Cloud Layer (상단)

데이터 저장(Data Management), 분석(Data Analysis), AI 추론(Prediction)이 이루어지는 계층입니다.

AWS 기준으로 매핑하면:

• 데이터 수집: AWS IoT Core (MQTT Broker)
• 데이터 저장: DynamoDB, S3, Timestream
• 데이터 분석: IoT Analytics, Kinesis Data Analytics
• AI/ML: SageMaker, Rekognition
• 이벤트 라우팅: IoT Rules Engine

---

2. 두 가지 통신 모델 — IoT의 가장 중요한 아키텍처 결정

IoT 시스템의 통신은 두 계층으로 나됩니다.

HW Communication (Device ↔ Computer)

• ZigBee, Bluetooth, TCP/UDP, LTE/5G
• 컴퓨터 네트워크 수업에서 배우는 영역입니다.

SW Interaction (SW System ↔ SW System)

• Client/Server Model (RESTful API)
• Messaging Model (MQTT)
• IoT 어플리케이션의 본질은 상단입니다.

HW 통신은 인프라입니다. 실제로 IoT 시스템을 설계할 때 핵심적인 아키텍처 결정은 소프트웨어 시스템 간의 인터랙션 모델을 무엇으로 선택하느냐입니다. 이것이 시스템의 확장성, 성능, 결합도를 결정합니다.

---

3. Client/Server 모델 — 익숙하지만 IoT에서는 한계가 있는 모델

우리가 익숙한 웹 어플리케이션의 표준 모델입니다. IoT로 매핑하면:

• Server: 클라우드 시스템 (Data Management & Analysis)
• Client: IoT 디바이스
• 통신 방식: HTTP 기반 RESTful API

Client/Server 모델의 특성

Tightly Coupling	Client가 Server의 API 인터페이스를 알아야 합니다	Server 측 인터페이스가 변경되면 모든 Client(IoT 디바이스)를 업데이트해야 합니다
Synchronization (Blocking)	Client는 Request를 보내고 Response가 올 때까지 기다립니다	수백 개 디바이스가 동시에 요청하면 Server에 병목 발생
Client Initiation Only	통신은 항상 Client가 먼저 시작합니다	Server가 디바이스를 먼저 호출할 수 없습니다

Client Initiation Only —-IoT에서 가장 치명적인 한계

Client/Server 모델에서는 서버가 클라이언트에게 먼저 연락할 방법이 없습니다.

• IoT 디바이스가 데이터를 보내서 저장·분석하는 것(Monitoring)은 가능합니다.
• 하지만 클라우드가 분석 결과를 바탕으로 능동적으로 IoT 디바이스를 제어하는 것(Control)은 불가능합니다.

예를 들면, 스마트 공장의 센서가 이상 온도를 감지하여 클라우드가 "제조라인 중단" 명령을 내려야 하는 상황에서, Client/Server 모델로는 클라우드가 디바이스에게 먼저 메시지를 보낼 수 없습니다. 디바이스가 다음 Polling 시점까지 기다려야 합니다.

HTTP/1.1에서는 이 한계를 극복하기 어렵습니다. WebSocket이나 HTTP/2 Server Push가 대안으로 존재하지만, IoT 디바이스의 제한된 리소스에서는 적합하지 않은 경우가 많습니다.

Client/Server가 적합한 경우

그럼에도 불구하고 Client/Server 모델이 완전히 부적합한 것은 아닙니다:

• 소수의 디바이스, 낮은 빈도의 데이터 전송
• Monitoring 중심 워크로드 (Control이 필요 없는 경우)
• 디버깅과 정확성 검증이 우선인 개발 초기 단계
• Synchronous한 특성 덕분에 실행 순서가 예측 가능하고, 디버깅이 쉬움

---

4. Messaging 모델 (Publish/Subscribe) - IoT의 주도적 통신 모델

Client/Server 모델의 한계를 해결하기 위해 등장한 것이 Messaging 모델(Publish/Subscribe)입니다. IoT 어플리케이션의 주도적 통신 모델입니다.

핵심 구조:

• 중앙에 Message Broker가 존재합니다.
• Broker 내부에 Message Queue(Topic)가 있습니다.
• 모든 시스템은 Queue에 Publish 또는 Subscribe만 합니다.

Messaging 모델의 핵심 특성

특성	설명	Client/Server와의 차이
Loosely Coupling	Publisher와 Subscriber가 서로를 알 필요 없습니다	Client가 Server API를 알아야 하는 Tight Coupling과 정반대
Asynchronous	Publish하면 즉시 다음 작업으로 넘어갑니다. Blocking 없음	Request 후 Response를 기다리는 Blocking과 정반대
Bidirectional	누구나 Publish하고, 누구나 Subscribe할 수 있습니다	Server가 Client에게 먼저 연락 불가능한 제약이 없음
Event-Driven	메시지 도착 = 이벤트 발생 → 즉시 반응	EDA와 자연스럽게 결합

 

MQTT - IoT의 표준 메시징 프로토콜

MQTT(Message Queuing Telemetry Transport)는 1999년 IBM이 위성 통신용으로 개발한 경량 메시징 프로토콜입니다.

경량성	헤더가 최소 2바이트. HTTP의 수백 바이트 헤더와 비교 불가
QoS 레벨	0 (At-most-once), 1 (At-least-once), 2 (Exactly-once)
Persistent Session	디바이스가 잠시 끊겨도 재접속 시 밀린 메시지 수신
Last Will & Testament	디바이스가 비정상 단절되면 Broker가 자동으로 유언 메시지를 발행
전송 계층	TCP/IP 위에 동작 (포트 1883, TLS는 8883)

 

MQTT vs HTTP — 성능 차이가 극단적인 이유

비교	MQTT	HTTP (REST)
헤더 크기	2 bytes 최소	~800 bytes (Cookie, User-Agent 등)
통신 패턴	Persistent TCP Connection 유지	매 요청마다 TCP Handshake (Keep-Alive 없으면)
데이터 전송 방향	양방향 (Server→Client 가능)	단방향 (Client→Server만 가능)
전력 소모	그대로 유지하는 TCP 커넥션으로 낮음	매번 새 커넥션으로 높음
10,000개 디바이스 시	Broker가 Fan-out으로 처리	각각 API 콜 필요, 서버 부하 폭주

배터리로 동작하는 온도 센서가 1초마다 데이터를 보내는 상황을 상상하면, MQTT의 2바이트 헤더 vs HTTP의 800바이트 헤더는 네트워크 대역폭과 전력 소모에서 압도적인 차이를 만듭니다.

---

5. Pub/Sub 실제 동작 흐름

1단계: Subscribe

• Data Analysis 시스템이 Message Queue A를 Subscribe합니다. ("센서 데이터가 들어오면 알려달라")
• IoT Device #1, #2가 Message Queue B를 Subscribe합니다. ("제어 명령이 들어오면 알려달라")

2단계: Publish (Monitoring)

• IoT Device #1이 센서 데이터를 Queue A에 Publish합니다.

3단계: Notify + 분석

• Broker가 Queue A를 Subscribe 중인 Data Analysis에게 Notify합니다.
• Data Analysis가 데이터를 분석하고 판단을 내립니다.

4단계: Publish (Control)

• Data Analysis가 제어 명령을 Queue B에 Publish합니다.
• Broker가 Queue B를 Subscribe 중인 Device #1, #2에게 Notify합니다.

핵심 포인트: Data Analysis도 Device도 동등한 위치에 있습니다. 계층적 관계(Client/Server)가 아니라, 관심 있는 Topic에 Publish/Subscribe하는 대등한 관계입니다.

---

6. 실전 사례: 스마트 도어 시스템

앞의 이론이 실제 시스템으로 어떻게 구현되는지 얼굴 인식 스마트 도어 시스템으로 확인합니다.

1. 사람이 문 앞에 서면 IoT Camera가 얼굴을 촬영합니다 (Monitor).
2. 촬영된 이미지를 Message Broker의 door/face-image Topic에 Publish합니다.
3. Face Recognition System이 해당 Topic을 Subscribe하고 있다가, 이미지를 수신합니다 (Notify).
4. Face DB에서 등록된 얼굴과 대조합니다.
5. 일치하면 door/unlock Topic에 "OK" 메시지를 Publish합니다.
6. IoT Lock이 door/unlock Topic을 Subscribe하고 있다가, "OK"를 수신하면 문을 엽니다 (Control).

이 시스템의 아키텍처적 특징

• IoT Camera, Face Recognition, IoT Lock은 서로를 모릅니다. Broker의 Topic만 알 뿐입니다.
• Face Recognition을 AWS Rekognition으로 교체해도, Camera와 Lock은 수정할 필요 없습니다. (Loose Coupling)
• Lock을 다른 제조사 제품으로 교체해도 door/unlock Topic만 Subscribe하면 됩니다.
• 새로운 Consumer(예: 알림 시스템)를 추가해도 기존 시스템에 영향 제로입니다.

AWS로 구현한다면

IoT Camera	실물 디바이스 + AWS IoT Device SDK
Message Broker	AWS IoT Core (MQTT Broker)
Face Recognition	AWS Lambda • Amazon Rekognition
Face DB	DynamoDB 또는 S3
IoT Lock	실물 디바이스 + AWS IoT Device SDK
이벤트 라우팅	AWS IoT Rules (SQL로 필터링 → Lambda 호출)

---

7. 성능과 아키텍처 디시전 — 현업에서 고려해야 할 것들

Fan-out 문제

하나의 이벤트를 수백·수천 개의 Subscriber에게 전달해야 하는 상황에서, Broker의 처리 능력이 병목이 됩니다.

• AWS IoT Core: 기본적으로 Account당 초당 Publish/Subscribe 횟수에 Throttle이 있습니다.
• 대안: IoT Core → SNS → SQS Fan-out 패턴으로 분산 처리

디바이스 수만 대의 Connection 관리

MQTT는 디바이스당 Persistent TCP Connection을 유지합니다. 디바이스가 100만 대라면 100만 개의 TCP 커넥션을 동시에 유지해야 합니다.

• AWS IoT Core는 매니지드 서비스로서 이 커넥션 관리를 대행합니다.
• 자체 Broker(Mosquitto 등)를 운영한다면 C10K/C1M 문제를 직접 대응해야 합니다 — epoll, 비동기 I/O, Connection Pooling 등 시스템 프로그래밍 영역이 됩니다.

Edge vs Cloud - Latency 트레이드오프

처리 위치	Latency	비용	적합한 경우
Cloud	높음 (네트워크 왔복)	낮음 (서버리스 종량제)	복잡한 분석, AI 추론, 장기 저장
Edge	낮음 (로컬 처리)	높음 (Edge HW 필요)	실시간 제어, 안전 크리티컬 시스템

화학 공장의 이상 감지처럼 수 ms 이내에 반응해야 하는 시나리오에서는 Cloud 왔복(~100ms)은 너무 느립니다. Edge에서 즉시 처리하고, 동시에 Cloud에 로그를 전송하는 패턴이 일반적입니다.

---

정리 - Client/Server vs Messaging, 언제 뭔 쓸 것인가

고려 요소	Client/Server (RESTful API)	Messaging (MQTT Pub/Sub)
통신 방향	단방향 (Client → Server)	양방향
결합도	Tight Coupling	Loose Coupling
동기/비동기	동기 (Blocking)	비동기 (Non-blocking)
디바이스 제어	불가 (Server가 먼저 호출 불가)	가능 (Topic에 Publish하면 디바이스가 수신)
헤더 오버헤드	높음 (~800B)	낮음 (~2B)
확장성	Server 병목 위험	Broker 기반 Fan-out
디버깅	쉽음 (순서 예측 가능)	어려움 (비동기 흐름 추적 필요)
적합한 상황	소수 디바이스, Monitoring 전용, 개발 초기	대규모 디바이스, Monitoring + Control, 이벤트 기반 시스템

현업에서는 둘을 병용합니다:

• 사용자 대시보드 → REST API (Request-Driven)
• 디바이스 데이터 수집 + 제어 → MQTT (Event-Driven)
• 주기적 리포트 생성 → CloudWatch Scheduled Rules (Time-Driven)

세 모델은 대체 관계가 아니라 목적에 따라 혼용하는 것이 IoT 시스템 설계의 기본입니다.