[IOT-011][실무] 센서 데이터를 모아 클라우드에서 관찰하기
페이지 정보

본문
[이번 수업]
센서 값을 읽고, 연결이 끊기면 보관했다가 클라우드로 보내며, 수집 상태까지 관찰하는 흐름을 배웁니다. 텔레메트리는 멀리 있는 장치의 측정값과 상태를 전송해 살펴보는 데이터입니다. 누락·중복·지연을 알아낼 수 있어야 운영 가능한 시스템이 됩니다.
[선수지식]
IOT-007의 MQTT, IOT-009의 장치 보안, IOT-010의 엣지 처리를 알면 좋습니다. Python 리스트와 딕셔너리를 읽을 수 있으면 됩니다.
[학습목표]
1. 센서 이벤트의 식별 정보와 단위를 정한다.
2. 오프라인 버퍼와 중복에 견디는 흐름을 설명한다.
3. 장치 데이터와 운영 지표를 나눠 관찰한다.
[핵심개념]
측정 이벤트에는 device_id, 순서 번호, UTC 측정 시각, 값, 단위, 스키마 버전을 넣습니다. 스키마는 필드와 형식을 정한 약속입니다. 수집 직후 범위와 자료형을 확인하고 잘못된 값은 별도로 셉니다. 클라우드 수신 시각도 기록하면 전송 지연과 장치 시계 오차를 구분할 수 있습니다.
MQTT에서 장치는 주제에 메시지를 발행하고 브로커는 구독자에게 전달합니다. QoS 0은 손실될 수 있고, QoS 1은 중복될 수 있으며, QoS 2는 한 송신자와 수신자 사이의 중복 전달을 막는 절차가 더 큽니다. 전체 저장 과정에서는 메시지 ID나 device_id와 순서 번호로 중복을 막으세요. 연결이 끊기면 크기가 제한된 로컬 큐에 저장하고 삭제 기준·묶음 크기·재시도 간격을 정합니다.
센서 값은 업무 데이터이고 지표와 로그는 파이프라인 상태를 설명하는 관측 데이터입니다. 읽은 수, 잘못된 수, 전송 성공·실패, 대기열 길이, 마지막 수신 시각을 기록하세요. 로그에는 원인을 찾을 정보만 남깁니다.
[따라하기]
telemetry_demo.py를 만들고 붙여 넣으세요. 외부 서버 없이 첫 값을 대기열에 넣었다가 연결이 돌아오면 두 건을 함께 보냅니다.
```python
import json
samples = [
{"seq": 1, "at": "2026-09-06T00:00:00Z", "temp": 21.4, "online": False},
{"seq": 2, "at": "2026-09-06T00:01:00Z", "temp": 21.8, "online": True},
{"seq": 3, "at": "2026-09-06T00:02:00Z", "temp": None, "online": True},
]
outbox = []
stats = {"read": 0, "invalid": 0, "sent": 0}
for sample in samples:
stats["read"] += 1
if sample["temp"] is None:
stats["invalid"] += 1
continue
outbox.append({
"device_id": "sensor-demo-01",
"schema": 1,
"seq": sample["seq"],
"measured_at": sample["at"],
"value": sample["temp"],
"unit": "C",
})
if sample["online"]:
print("전송:", json.dumps(outbox, ensure_ascii=False))
stats["sent"] += len(outbox)
outbox.clear()
stats["queued"] = len(outbox)
print("지표:", json.dumps(stats, ensure_ascii=False))
```
macOS·Linux에서는 `python3 telemetry_demo.py`, Windows에서는 `py telemetry_demo.py`를 실행합니다. 환경에 따라 `python`도 됩니다. 예상 결과는 전송 목록에 seq 1과 2가 나오고, 지표가 `read: 3`, `invalid: 1`, `sent: 2`, `queued: 0`을 나타내는 것입니다. 실제 네트워크 요청은 없습니다.
[흔한 실수]
단위·시각·순서 번호를 빼면 값을 해석하기 어렵습니다. 무한 대기열은 저장 공간을 채우고 연결 직후 몰아 보내면 통신량이 급증합니다. 수집·대기·전송 단계를 따로 측정하세요.
[보안 주의]
장치마다 고유한 신원과 최소 주제 권한을 주고 TLS로 통신하세요. 기본 비밀번호나 하나의 비밀을 여러 장치에 재사용하지 않습니다. 인증 정보 교체와 분실 장치 차단 절차를 준비하고 위치·사용자 식별값은 꼭 필요한 범위에서만 담습니다. 실습은 본인 소유의 로컬·격리 환경과 가짜 데이터에서만 진행하세요.
[직접 해볼 과제]
네 번째 정상 샘플을 online이 false인 상태로 추가해 queued가 1이 되는지 확인하세요. 온도 범위를 벗어난 값도 invalid로 세고 최대 대기열과 오래된 데이터 처리 규칙을 적어 보세요.
[확인문제]
1. 측정 이벤트에 순서 번호가 필요한 이유는 무엇인가요?
2. MQTT QoS 1에서 중복을 고려해야 하는 이유는 무엇인가요?
3. 센서 값과 전송 지표를 따로 기록하면 무엇을 구분할 수 있나요?
[다음 학습]
IOT-012에서 센서 수집부터 저장과 대시보드까지 이어지는 작은 IoT 프로젝트를 설계합니다.
[공식 참고 자료]
https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
https://opentelemetry.io/docs/concepts/signals/
https://www.rfc-editor.org/info/rfc8259
https://csrc.nist.gov/pubs/ir/8259/a/final
https://docs.python.org/3/library/json.html
센서 값을 읽고, 연결이 끊기면 보관했다가 클라우드로 보내며, 수집 상태까지 관찰하는 흐름을 배웁니다. 텔레메트리는 멀리 있는 장치의 측정값과 상태를 전송해 살펴보는 데이터입니다. 누락·중복·지연을 알아낼 수 있어야 운영 가능한 시스템이 됩니다.
[선수지식]
IOT-007의 MQTT, IOT-009의 장치 보안, IOT-010의 엣지 처리를 알면 좋습니다. Python 리스트와 딕셔너리를 읽을 수 있으면 됩니다.
[학습목표]
1. 센서 이벤트의 식별 정보와 단위를 정한다.
2. 오프라인 버퍼와 중복에 견디는 흐름을 설명한다.
3. 장치 데이터와 운영 지표를 나눠 관찰한다.
[핵심개념]
측정 이벤트에는 device_id, 순서 번호, UTC 측정 시각, 값, 단위, 스키마 버전을 넣습니다. 스키마는 필드와 형식을 정한 약속입니다. 수집 직후 범위와 자료형을 확인하고 잘못된 값은 별도로 셉니다. 클라우드 수신 시각도 기록하면 전송 지연과 장치 시계 오차를 구분할 수 있습니다.
MQTT에서 장치는 주제에 메시지를 발행하고 브로커는 구독자에게 전달합니다. QoS 0은 손실될 수 있고, QoS 1은 중복될 수 있으며, QoS 2는 한 송신자와 수신자 사이의 중복 전달을 막는 절차가 더 큽니다. 전체 저장 과정에서는 메시지 ID나 device_id와 순서 번호로 중복을 막으세요. 연결이 끊기면 크기가 제한된 로컬 큐에 저장하고 삭제 기준·묶음 크기·재시도 간격을 정합니다.
센서 값은 업무 데이터이고 지표와 로그는 파이프라인 상태를 설명하는 관측 데이터입니다. 읽은 수, 잘못된 수, 전송 성공·실패, 대기열 길이, 마지막 수신 시각을 기록하세요. 로그에는 원인을 찾을 정보만 남깁니다.
[따라하기]
telemetry_demo.py를 만들고 붙여 넣으세요. 외부 서버 없이 첫 값을 대기열에 넣었다가 연결이 돌아오면 두 건을 함께 보냅니다.
```python
import json
samples = [
{"seq": 1, "at": "2026-09-06T00:00:00Z", "temp": 21.4, "online": False},
{"seq": 2, "at": "2026-09-06T00:01:00Z", "temp": 21.8, "online": True},
{"seq": 3, "at": "2026-09-06T00:02:00Z", "temp": None, "online": True},
]
outbox = []
stats = {"read": 0, "invalid": 0, "sent": 0}
for sample in samples:
stats["read"] += 1
if sample["temp"] is None:
stats["invalid"] += 1
continue
outbox.append({
"device_id": "sensor-demo-01",
"schema": 1,
"seq": sample["seq"],
"measured_at": sample["at"],
"value": sample["temp"],
"unit": "C",
})
if sample["online"]:
print("전송:", json.dumps(outbox, ensure_ascii=False))
stats["sent"] += len(outbox)
outbox.clear()
stats["queued"] = len(outbox)
print("지표:", json.dumps(stats, ensure_ascii=False))
```
macOS·Linux에서는 `python3 telemetry_demo.py`, Windows에서는 `py telemetry_demo.py`를 실행합니다. 환경에 따라 `python`도 됩니다. 예상 결과는 전송 목록에 seq 1과 2가 나오고, 지표가 `read: 3`, `invalid: 1`, `sent: 2`, `queued: 0`을 나타내는 것입니다. 실제 네트워크 요청은 없습니다.
[흔한 실수]
단위·시각·순서 번호를 빼면 값을 해석하기 어렵습니다. 무한 대기열은 저장 공간을 채우고 연결 직후 몰아 보내면 통신량이 급증합니다. 수집·대기·전송 단계를 따로 측정하세요.
[보안 주의]
장치마다 고유한 신원과 최소 주제 권한을 주고 TLS로 통신하세요. 기본 비밀번호나 하나의 비밀을 여러 장치에 재사용하지 않습니다. 인증 정보 교체와 분실 장치 차단 절차를 준비하고 위치·사용자 식별값은 꼭 필요한 범위에서만 담습니다. 실습은 본인 소유의 로컬·격리 환경과 가짜 데이터에서만 진행하세요.
[직접 해볼 과제]
네 번째 정상 샘플을 online이 false인 상태로 추가해 queued가 1이 되는지 확인하세요. 온도 범위를 벗어난 값도 invalid로 세고 최대 대기열과 오래된 데이터 처리 규칙을 적어 보세요.
[확인문제]
1. 측정 이벤트에 순서 번호가 필요한 이유는 무엇인가요?
2. MQTT QoS 1에서 중복을 고려해야 하는 이유는 무엇인가요?
3. 센서 값과 전송 지표를 따로 기록하면 무엇을 구분할 수 있나요?
[다음 학습]
IOT-012에서 센서 수집부터 저장과 대시보드까지 이어지는 작은 IoT 프로젝트를 설계합니다.
[공식 참고 자료]
https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
https://opentelemetry.io/docs/concepts/signals/
https://www.rfc-editor.org/info/rfc8259
https://csrc.nist.gov/pubs/ir/8259/a/final
https://docs.python.org/3/library/json.html
- 이전글[CORE-012][실무] 내 컴퓨터와 인터넷 연결 지도로 정리하기 26.09.06
- 다음글[MOBILE-011][실무] 앱에 서명하고 안전하게 스토어에 배포하기 26.09.06
댓글목록
등록된 댓글이 없습니다.
