265. 창발성 (Emergent Abilities) - 파라미터와 훈련 데이터 규모가 특정 임계치를 넘겼을 때, 사전에 프로그래밍/학습하지 않은 복잡한 추론 논리 능력이 스스로 발현되는 현상

핵심 인사이트 (3줄 요약)

본질: CoAP(Constrained Application Protocol)은 UDP 기반의 경량 M2M(머신투머신) 통신 프로토콜로, HTTP/RESTful 모델을 차용하되 2바이트 최소 헤더로 대역폭과 전력 소비를 최소화하여 8비트 마이크로컨트롤러에서도 동작할 수 있게 설계된 IoT 전용 프로토콜입니다.

가치: MQTT가 브로커 중심의 Pub/Sub 모델이라면, CoAP는 리소스 중심의 요청-응답 모델로, 별도의 브로커 없이 기기 대 기기(P2P) 직접 통신이 가능하여 지연 시간을 최소화합니다.

융합: CoAP은 6LoWPAN과 결합하여 IEEE 802.15.4 저전력 센서 네트워크에서 IPv6 통신을 가능하게 하며, 이는 초소형 IoT 센서의 웹(World Wide Web) 진입을 의미합니다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념 정의

CoAP(Constrained Application Protocol)은 2014년 **IETF(국제 인터넷 표준화_task Force)**에서 RFC 7252로 공식 표준화된 머신투머신(M2M)용 경량 웹 프로토콜입니다. 설계 목표는 명확합니다: **"수십 킬로바이트의 메모리와 수십 밀리와왓트의 전력만 가진 8비트 마이크로컨트롤러(MCU)"**에서도 동작할 수 있을 만큼 가벼우면서도, 웹의 약속(HTTP)을踏襲하여 범용 웹 개발자와의 통합을 용이하게 하는 것입니다.

CoAP의 가장 중요한 특징은 UDP 전송 프로토콜 사용입니다. TCP(Transmission Control Protocol)는 신뢰성 보장을 위해 3-Way Handshake(연결 수립)와 4-Way Handshake(연결 종료)를 필요로 하며,这一点가 지연과 오버헤드를 增加시킵니다. CoAP은 대신 UDP(User Datagram Protocol) 위에 자체적인 **신뢰성 메커니즘(Confirmable/Non-confirmable)**을 얹어, 대역폭이 극히 제한된 센서 네트워크에서도 통신할 수 있게 합니다.

왜 CoAP인가? — HTTP와 MQTT의 딜레마

IoT 센서 네트워크에는 세 가지 주요 제약이 존재합니다:

┌──────────────────────────────────────────────────────────────┐
│           IoT 센서 네트워크의 3대 제약 조건                           │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│   ① 메모리 제약 (Memory Constraint)                           │
│      8-bit MCU: SRAM 2KB, Flash 64KB only!                   │
│      → HTTP 라이브러리조차 탑재 불가                           │
│                                                              │
│   ② 전력 제약 (Power Constraint)                             │
│      배터리 자율 동작 5~10년 목표                              │
│      → TCP 연결 수립만으로 일일 배터리의 10% 소모 가능           │
│                                                              │
│   ③ 대역폭 제약 (Bandwidth Constraint)                       │
│      IEEE 802.15.4: 250kbps MAX                             │
│      → HTTP 헤더(200B+)는 감당 불가                           │
│                                                              │
│   💡 해결책: CoAP                                             │
│   ① 4바이트 최소 헤더 → 메모리 적재 가능                       │
│   ② UDP 기반 → TCP 핸드셰이크 생략 → 전력 대폭 절감            │
│   ③ HTTP/RESTful 호환 → 기존 웹 개발자와 지식 공유 OK          │
└──────────────────────────────────────────────────────────────┘

CoAP과 HTTP/RESTful의 관계 — "웹의 축소판"

CoAP은 HTTP/RESTful 모델의 **대칭적 복사본(symmetric twin)**입니다. HTTP의 주요 개념(메서드: GET/POST/PUT/DELETE, 상태 코드: 2.04 Changed, 4.04 Not Found, URI: coap://device/temperature)을 그대로 차용하되, 바이너리 인코딩과 UDP传输으로 바꿈으로써 경량화를 달성했습니다.

HTTP	CoAP	의미
`GET /temp`	CON GET `coap://device/temp`	리소스 요청
`200 OK`	`2.05 Content`	정상 응답
`201 Created`	`2.01 Created`	리소스 생성
`404 Not Found`	`4.04 Not Found`	리소스 없음
TCP 포트 80	UDP 포트 5683	전송층

┌──────────────────────────────────────────────────────────────┐
│         CoAP vs HTTP vs MQTT — 3대 IoT 프로토콜 비교              │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  [HTTP — "등기우편 (1:1 요청-응답)"]                           │
│   Client ──────── GET /temp ────────▶ Server                 │
│            ◀────── 200 OK + JSON ────────                    │
│   ✅ 범용 웹 표준 ✅ 직관적                                    │
│   ❌ 무겁다 (200B+ 헤더) ❌ TCP 핸드셰이크 ❌ Pull만 가능        │
│                                                              │
│  [MQTT — "우체국 (Pub/Sub 브로커)"]                            │
│   Sensor ──publish──▶ Broker ◀──subscribe── Dashboard       │
│   ✅ 확장성 우수 ✅ 1:N 가능  ✅ QoS 보장                      │
│   ❌ 브로커 필수 ❌ TCP 기반 (오버헤드) ❌Publish者/구독자 느슨한 연결 │
│                                                              │
│  [CoAP — "전화 (P2P 경량 요청-응답)"]                         │
│   Sensor ◀──── GET ─────▶ Actuator                          │
│            ──응답 (2.05 Content)──▶                           │
│   ✅ 초경량 (4B 헤더) ✅ UDP 기반 ✅ P2P 직접通信 ✅ RESTful    │
│   ❌ 브로커 없음 (확장성 제한) ❌ 자체 신뢰성 메커니즘 복잡       │
│                                                              │
│  🌟 선택 기준:                                              │
│   - 대규모 중앙集식 데이터 수집 → MQTT                        │
│   - 센서-액추에이터 P2P 직접 제어 → CoAP                     │
│   - 기존 웹 서비스와 통합 → HTTP/RESTful                      │
└──────────────────────────────────────────────────────────────┘

[다이어그램 해설] 세 가지 프로토콜은 각각 다른 comunication 패턴에 최적화되어 있습니다. HTTP는 "편지 보내기" — 보낼 때와 받을 때가明确히 구분되고, 답장(응답)을 기다려야 합니다. MQTT는 "우체국 시스템" — 우체국(브로커)에 편지를投放하면 우체국이 수신자에게自動 배포합니다. CoAP는 "전화 통화" — 전화를 걸어 바로 상대방이 받으면 거기서 바로 대화가 이루어집니다(지연 최소화). 중요한 점은 이 세 가지가 서로 배타적이지 않으며, 실제 IoT 시스템에서는 여러 프로토콜이 동시에 사용되는 경우가 많다는 것입니다.

📢 섹션 요약 비유: CoAP를 **"무전기(워키토키)"**로 비유할 수 있습니다. 무전기는 전화(TCP/HTTP)처럼 연결 설정을 필요로 하지 않고, 전원을 누르면 바로 말할 수 있습니다(UDP/P2P). 물론 동시에 다수가 이야기하면音声이 충돌하므로, 무전기는 한 번에 한 명만 말하는 규칙(half-duplex)이 있고, 상대가 잘 들었는지 확인하기 위해 " copie?"(Confirmable)라고 물어봅니다. CoAP의 Confirmable(확인 요청)/Non-confirmable(비확인 요청) 메커니즘은 바로 이 무전기 대화 규칙과一模一样입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

CoAP 메시지 구조 — 바이너리 인코딩

CoAP의 가장 큰 특징은 HTTP의 텍스트 기반 헤더를 고정 4바이트 바이너리 헤더로 대체한 것입니다. 이로 인해 파싱 overhead가 극적으로 감소합니다.

┌──────────────────────────────────────────────────────────────┐
│                  CoAP 메시지 구조 (바이너리)                       │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌────────┬────────┬────────┬────────┬──────────┬──────────┐ │
│  │ Ver(2) │  T(2)  │  Token Length(4) │  Code(8) │  Msg ID(16) │ │
│  └────────┴────────┴────────┴────────┴──────────┴──────────┘ │
│    4bit     2bit        4bit            8bit         16bit     │
│                                                              │
│  [옵션 (Options) — 가변 길이, TLV 인코딩]                       │
│  ┌────────┬────────┐                                         │
│  │ Option Delta │ Option Length │ (Option Value)           │
│  └────────┴────────┘                                         │
│                                                              │
│  [페이로드 (Payload) — 바이너리 데이터]                          │
│  Payload Marker (0xFF) 이후 모든 데이터                          │
│                                                              │
│  🌟 핵심: HTTP는 "안부편지 (텍스트)"라면,                       │
│     CoAP는 "전보 (바이너리)". 훨씬 짧고 빠르다!                  │
└──────────────────────────────────────────────────────────────┘

[다이어그램 해설] HTTP의 텍스트 기반 헤더는 사람이 읽을 수 있어 디버깅에는 좋지만,每一位의미를 표현하기 위해 수 바이트의 텍스트가 필요합니다. CoAP의 바이너리 헤더는 한 **nibble(4비트)**에 버전(2비트), 타입(2비트)을 모두 표현합니다. 이 차이는 대역폭이 250kbps인 IEEE 802.15.4 네트워크(가정용sensor)에서 엄청납니다. 실제로 CoAP는 HTTP 대비 90% 이상의 메시지 크기 감소를 달성하여, 제한된 sensor网络에서도高效な数据传输を可能にします.

Confirmable / Non-confirmable 메시지

CoAP은 UDP의 비신뢰성를 보완하기 위해 자체적인 확인 메커니즘을 제공합니다.

메시지 유형	약자	설명	사용 시나리오
Confirmable	CON	수신자가 반드시ACK(확인)으로 응답해야 함	중요 명령, 알람 (재전송 보장)
Non-confirmable	NON	응답을 기다리지 않고 계속 진행	주기적 센서 데이터 (유실이 치명적이지 않음)
Acknowledgement	ACK	CON 메시지에 대한 수신 확인	—
Reset	RST	수신자가 메시지를 이해하지 못할 때	—

Observe 옵션 — Server Push 기능

HTTP는 클라이언트가 Pull(긁어오기) 방식으로만 데이터를 가져올 수 있습니다. 반면 CoAP은 Observe(관찰) 옵션을 통해 서버가 상태 변화를 Push(밀어넣기) 방식으로 클라이언트에 알릴 수 있습니다.

  Client                                    Server
    │                                          │
    │  CON GET /temperature [Observe: 0]        │
    │ ─────────────────────────────────────────▶│
    │                                          │
    │  ACK 2.05 Content (temperature=25°C)     │
    │ ◀─────────────────────────────────────────│
    │                                          │
    │  (5초 후)                                │
    │                                          │
    │  NON 2.05 Content (temperature=26°C)      │  ← Server가 먼저 전송
    │ ◀─────────────────────────────────────────│
    │                                          │
    │  (5초 후)                                │
    │                                          │
    │  NON 2.05 Content (temperature=28°C)      │
    │ ◀─────────────────────────────────────────│

[다이어그램 해설] Observe 옵션은 HTTP의 Polling(주기적 요청)과 비교했을 때 네트워크 트래픽을 획기적으로 절감합니다. HTTP에서 5초마다 온도를 확인하려면 매번 GET 요청을 보내야 하지만(1초 * 5회 = 5초분 대역폭 사용), CoAP Observe는 서버가 온도가 변할 때만 Push하므로 실제로 변화가 없을 때는 아무 트래픽도 발생하지 않습니다. 이것은 배터리 수명이 중요한 IoT 센서에서 결정적인 차이를 만듭니다.

리소스 발견 (Resource Discovery)

CoAP 기기는开机時に 자신을 설명하는 /.well-known/core URI에 접근 가능한 리소스 목록을 게시합니다. 이는 웹의 **WADL(Web Application Description Language)**와 유사한 기능으로, 새로운 기기가 네트워크에 접속했을 때 자동으로 어떤 리소스를 제공하는지 탐색할 수 있게 합니다.

📢 섹션 요약 비유: CoAP의 메시지 구조는 **"전보(Telegraph)"**와 같습니다. 옛날 전보는 한 글자당 비용이 나가서 사람들은 짧은略語를 썼습니다. CoAP도 마찬가지 — 수십 킬로바이트 메모리만 가진 작은 기기에서는冗長한 텍스트 헤더를积載할 여유가 없기에, 4비트, 8비트 단위의 **짧은 부호(바이너리)**로 messages를 압축합니다. 그래도 의미는 온도 센서 "GET /temp" → "2.05 Content 25°C"로 完全 전달됩니다. 전보가 짧은 부호로長文을 전달한 것처럼, CoAP도 작은 기기에서 중요한 message를 빈틈없이 전달합니다.

Ⅲ. 융합 비교 및 다각도 분석

CoAP vs MQTT — 설계 철학의根本적 차이

구분	CoAP	MQTT
패러다임	RESTful 요청-응답 (리소스 중심)	Pub/Sub (토픽 중심)
传输 프로토콜	UDP	TCP
브로커	불필요 (P2P 직접 통신)	필수
메시지 크기	~4바이트 헤더	~2바이트 헤더
확장성	제한적 (P2P 구조)	매우 높음 (Pub/Sub 구조)
QoS 모델	CON/NON/ACK/RST (단순)	3단계 QoS (정교함)
역사적 기点	IETF (웹 표준)	IBM (M2M 산업용)
주요 용도	센서-P2P 직접 통신, M2M	대규모 중앙 수집, 스마트 팩토리

6LoWPAN과 CoAP — IPv6의 IoT 세계 진입

**6LoWPAN(IPv6 over Low-Power Wireless Personal Area Networks)**은 IEEE 802.15.4 네트워크(250kbps) 위에서 IPv6 패킷을 전송하기 위한 헤더 압축 및 단편화 프로토콜입니다. 이 duo(6LoWPAN + CoAP)은 **"초소형 IoT 센서의 웹(World Wide Web) 진입"**을意味합니다.

┌──────────────────────────────────────────────────────────────┐
│           6LoWPAN + CoAP — 초소형 IoT의 웹 표준 스택               │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  [애플리케이션 계층]  ←  CoAP (RESTful 리소스 접근)              │
│         │                                                  │
│         ▼                                                  │
│  [전송 계층]       ←  UDP (CoAP는 TCP 대신 UDP 사용)           │
│         │                                                  │
│         ▼                                                  │
│  [네트워크 계층]    ←  IPv6 (6LoWPAN이 헤더를 압축)              │
│         │                                                  │
│         ▼                                                  │
│  [적응 계층]       ←  6LoWPAN (단편화 + 헤더 압축)              │
│         │                                                  │
│         ▼                                                  │
│  [MAC/PHY 계층]   ←  IEEE 802.15.4 (250kbps 저전력 무선)        │
│                                                              │
│  🌟 핵심 가치: 기존 웹 개발자가 익숙한 HTTP/RESTful 지식을        │
│     그대로 IoT 센서 네트워크에 적용 가능!                          │
│     ex) 웹 브라우저에서 `coap://[fc00::1234]/temp`로 센서 접근   │
└──────────────────────────────────────────────────────────────┘

[다이어그램 해석] 6LoWPAN의 핵심 기술은 헤더 압축과 단편화입니다. IPv6 기본 헤더는 40바이트인데, IEEE 802.15.4의 최대 프레임 크기는 127바이트뿐입니다. 6LoWPAN은 이를 해결하기 위해 IPv6 헤더를 최소 2바이트로 압축합니다. 이 기술이 없으면 IPv6 패킷 하나를 전송하기 위해 수십 개의 802.15.4 프레임으로 쪼개야 하므로 현실성이 없습니다. 6LoWPAN이 이瓶颈을 해소하여 IPv6가 저전력 센서 네트워크에 진입할 수 있게 한 것입니다.

DTLS — CoAP의 보안 프로토콜

TCP 기반의 TLS가 있는 것처럼, UDP 기반에는 **DTLS(Datagram Transport Layer Security)**가 있습니다. CoAP의 보안을 위해 필수적으로 사용되며, 특히 CoAP Observe 기능을 사용할 때는 데이터가 server→client 방향으로 Push되므로, **양방향 인증(양쪽 모두의 인증서)**이尤为重要합니다.

📢 섹션 요약 비유: CoAP와 6LoWPAN의 관계는 **"전화기와 국제전화 규약"**과 같습니다. 전화기(CoAP)는 한국어와 동일한 대화 규약인데, 이를 국제전화(IPv6 world)를 하려면 국제전화 규약(6LoWPAN)을 통해压缩して переда해야 합니다. 그래야 미국에 있는 무선 sensor(IPv6 기기)와 한국에 있는 teléfono(CoAP 기기)가 서로对话할 수 있습니다. 전화 규약(CoAP)을 国际电话 규약(6LoWPAN)에 적용하려면 약간의 **통역과 압축(헤더 압축 + 단편화)**이 필요한 것과 동일합니다.

Ⅳ. 실무 적용 및 기술사적 판단

실전 시나리오 — 스마트 빌딩 HVAC P2P 제어

건물 내 공조 시스템(HVAC: Heating, Ventilation, Air Conditioning)에서 각 존(구역) 온도 센서가 공조기(에어컨室外기)에 직접 명령을 내려야 하는 상황입니다.

문제: 공기品质的恶化的 인해 각 존에서 CO2 센서가 300ppm 이상으로 측정되면, 공조기에 "환풍량을 늘려라"는 명령을 즉시送信해야 합니다. MQTT를 사용하면 브로커를 경유하므로 불필요한 지연이 增加합니다.
CoAP 접근: 각 존의 CO2 센서가 CoAP CON 메시지로 직접 공조기에 PUT /actuator/fan_speed를送信합니다. 공조기는 ACK과 함께 2.04 Changed를 회신합니다. 이를 통해 브로커 없이 P2P 직접 2홉 통신으로 지연 시간 50ms 이내를実現します.
判断: 센서-액추에이터의 직접 P2P 통신이 필요한场景에서는 CoAP이 MQTT보다 적합합니다. 특히 경보/제어처럼 지연 시간이 중요한 상황에서 브로커 경유는 곧바로 응답 시간 증가로 이어집니다.

실전 시나리오 — 6LoWPAN 기반 산업용 센서 네트워크

공장에서 수백 개의 온도·진동·압력 센서를 IEEE 802.15.4 기반으로 연결하여 환경 데이터를 수집하는 시스템입니다.

判断: IEEE 802.15.4 네트워크에서는 6LoWPAN + CoAP이 사실상 표준 조합입니다. 각 센서가 웹의 URI 형식(coap://[IPv6주소]/temperature)으로 자신의 데이터를 제공하므로, 관리자는 웹 브라우저나任何 REST 클라이언트로 센서 데이터에 접근할 수 있습니다. 이는 기존 IT 인프라(모니터링 대시보드, 데이터베이스)와의 통합을 획기적으로簡素화합니다.

설계 시 주의사항

NAT/firewall 경계 문제: CoAP은 UDP 기반이므로,某些 NAT/firewall 환경에서는 전송되지 않을 수 있습니다.这时候에는 CoAP- TCP/TLS fallback 메커니즘을 구현해야 합니다.
QoS 한계: CoAP의 CON/NON 메커니즘은 MQTT의 3단계 QoS에 비해 단순하여, 정교한 전달 보장이 필요한 대규모 시스템에서는 MQTT가 여전히 우위입니다.
브로커 부재의 양면성: CoAP의 P2P 구조는 브로커가 필요 없어 architecturally 단순하지만, 데이터 수집자가 여러 시스템일 경우(1:N 배포)에는 별도의 Fan-out 로직을 구현해야 하므로 번거로움이 증가합니다.

📢 섹션 요약 비유: CoAP의 P2P 모델은 **"무전기 직접 대화"**와 같습니다. 팀장이 팀원A에게 직접 무전기로 "2번 구역 펌프 켜"라고命令하면 바로 실행됩니다(빠른 응답). 반면 MQTT는 **"본부 통신반(브로커)에 보고하면 통신반이 관련 부서에 한꺼번에 명령 전달"**하는 구조입니다. 부대 규모가 크고 여러 부서가 동시에 같은 정보를 받아야 할 때는 통신반 방식(브로커)이 효율적이지만, 단순히 1:1로 빠르게 명령을 내려야 할 때는 무전기(CoAP P2P)가 더 효율적입니다.

Ⅴ. 기대효과 및 결론

CoAP 도입 기대효과

구분	HTTP/RESTful 사용 시	CoAP 사용 시	개선 효과
메시지 크기	~500바이트 (HTTP 헤더)	~15바이트 (CoAP 헤더)	97% 감소
전력 소비	TCP 핸드셰이크 + 텍스트 파싱	UDP + 바이너리 파싱	85% 감소
MCU 요구 사양	256KB Flash 이상	8KB Flash enough	소형 MCU 호환
응답 속도	100~500ms (TCP 핸드셰이크)	10~50ms (P2P UDP)	80% 향상

결론 및 전망

CoAP은 **"IoT를 위한 RESTful"**이라는 자신의 정체성을 명확히 하여, 기존 웹 개발 생태계와의 통합 가능성을 최대한活用하고 있습니다. 6LoWPAN과의 결합으로 IPv6가 저전력 센서 네트워크에 진입하게 된 것은 웹과 IoT의 경계를 허물었다는 점에서 역사적 의의가 있습니다.

다만 CoAP의 P2P 구조는 대규모 중앙 집중형 데이터 수집 시 브로커 기반 MQTT에 비해 불리하며, UDP 기반의 보안(DTLS) 처리 부담도 무시할 수 없습니다. 향후 QUIC(新一代 전송 프로토콜) 기반의 CoAP over QUIC이 표준화되면, TCP의 신뢰성과 UDP의低|latency을 동시에 취하는 hybrid 접근이 가능해질 전망입니다.

결론: CoAP은 IoT 세계의 **"공용 전화기(Public Phone)"**와 같습니다. 누구든 동전을 넣고 전화를 걸 수 있듯이(웹 표준 호환), 公衆電話기는 별도의 통신사 계약(브로커) 없이도 작동합니다(UDP/P2P). 다만 한번에 다수의 사람에게 전화를 연결하는 것은(1:N 배포) 어렵습니다. 적절한 곳에 적절한 기술을 — 이것이 CoAP와 MQTT를 선택하는 핵심 기준입니다.

📢 섹션 요약 비유: CoAP는 IoT 세계의 **"국제 공용어(에스페란토)"**와 같습니다. 한국어(HTTP)만 하면 한국 사람끼리만 이야기할 수 있지만, 에스페란토(CoAP)를 알면全世界的 어디서든_sensor와 웹 서버가 직접会話할 수 있습니다. 公用어(CoAP)는 배우기 쉽고(단순한 RESTful), UDP 기반이라 即時 전달(低latency)이 되고, 무엇보다 全世界的 표준(IPv6/6LoWPAN) 위에서 작동한다는 것이 가장 큰:value입니다.

📌 관련 개념 맵 (Knowledge Graph)

관련 개념	관계 설명
6LoWPAN	IEEE 802.15.4 네트워크에서 IPv6를 동작하게 하는 헤더 압축·단편화 프로토콜. CoAP와 함께 사용하여 "초소형 IoT의 웹化" 실현
MQTT	CoAP과 함께 IoT 양대 경량 프로토콜. MQTT는 브로커 기반 Pub/Sub, CoAP은 P2P RESTful. 상호 보완적
IEEE 802.15.4	저전력 WPAN의 물리·MAC 계층 표준. 6LoWPAN, Thread, Zigbee 등의 기반
DTLS	UDP 기반의 암호화 프로토콜. CoAP의 보안을 담당 (TLS의 UDP 버전)
Observe 옵션	CoAP의 server push 기능. HTTP의 Polling 대비 네트워크 트래픽을 획기적으로 절감

👶 어린이를 위한 3줄 비유 설명

**CoAP는 "무전기对话"**예요. 사람이 전화기를 들려면 전화국(브로커)에 먼저 연결 설정을 해야 하지만(TCP/HTTP), 무전기는 바로 버튼을 누르고 이야기할 수 있어요(UDP/P2P). 공장 sensor도 무전기처럼 직접 말하면 더 빠르고 더-power-saving해요!
CoAP는 옛날 **전보(텔레그램)"처럼 짧은 부호로 مهم한 message를 전달해요. "온도 25도"를 전보로 보내면 "temp25"로 압축되어 아주아주 짧은 signal로 빠르게 전달돼요.
무선 sensor인 "온도 센서"가 [Observe:0] 옵션을 켜두면, 온도가 변할 때마다 스스로 "온도 올라갔다!"고 **率先して報告(서버 푸시)**해요. 사람들이 수시로 "온도 아직이야?" 하고 물어볼 필요(Polling)가 없어요!