센서·게이트웨이·메시징·엣지·클라우드

마지막으로 받은 값이 지금의 온도일까

한빛도서관 자료실의 화면에 온도 24도가 표시된다. 센서가 방금 측정한 값일 수도 있지만, 통신이 끊기기 전 한 시간 전에 보낸 값일 수도 있다. 숫자를 받았다는 사실만으로 현재 상태를 정확히 안다고 할 수 없다. 측정 대상·단위·시각·오차와 전달 과정을 함께 읽어야 한다.

이 장은 자료실의 온습도를 관찰해 담당자에게 상태를 알려 주는 가상 IoT 사례다. 실제 보존환경의 기준값이나 화재·생명안전 제어를 설계하는 문서가 아니다. 자동 냉난방·출입 제어는 범위에서 제외하며 아래 IO-B1·IO-T1·IO-A1의 임계값과 데이터량은 계산을 위한 자체 조건이다.

앞선 신호·채널과 연결

신호와 채널은 정보를 물리량으로 표현하고 매체를 통해 전달하는 관계를 다뤘다. IoT에서는 센서의 관측을 신호·메시지·네트워크로 이어 가므로 측정 의미와 전달 성공을 구별한다.

1. IoT와 엣지 구조의 정의

사물인터넷(IoT)은 물리적 대상의 센서·장치와 네트워크·서비스를 연결해 관측 정보와 허용된 처리를 이어 주는 체계다.

IoT·엣지 구조는 물리적 대상의 센서·장치가 만든 정보를 네트워크·메시징으로 연결하고, 필요한 처리를 현장 가까운 엣지와 원격 서비스에 배치하여 관찰·판단·행동·운영을 이어 주는 구조다. 인터넷에 직접 연결된 센서만 IoT인 것은 아니며, 제한된 장치가 게이트웨이를 통해 연결되는 구성도 있다.

센서는 온도·빛·움직임 같은 물리량을 신호로 바꾸는 장치다. 액추에이터는 명령을 받아 밸브·모터·스위치처럼 물리적 행동을 만드는 장치다. 관측 메시지의 전달 성공과 실제 물리적 동작 성공은 다르다. 이 사례에서는 측정·안내만 사용하고 제어 권한은 주지 않는다.

엣지 컴퓨팅은 데이터가 생기거나 사용되는 곳에 가까운 자원에서 일부 처리를 수행하는 배치다. 센서 자체·현장 장비·근처 서버 등 여러 위치일 수 있다. 클라우드는 이 사례에서 여러 장소의 데이터를 보관·분석·관리하는 원격 자원으로 사용한다. 클라우드의 서비스·배치 모델과 공유책임은 뒤의 서비스·배치 모델과 공유책임에서 따로 다룬다.

W3C WoT Architecture1.1은 장치·중개자·원격 서비스를 연결하고 다양한 프로토콜 위에서 상호작용을 표현하는 구조를 설명한다.¹ 장치가 같은 통신 규격을 쓴다는 사실만으로 숫자의 단위·의미·권한까지 맞는 것은 아니다.

2. 센서는 현실을 제한된 조건으로 관측한다

표본 주기는 얼마마다 측정하는지다. 10초마다 한 번 측정하면 그 사이의 짧은 변화는 놓칠 수 있다. 기록을 더 촘촘하게 한다고 센서 자체의 응답 속도·정확성이 자동으로 좋아지지도 않는다. 배터리·대역폭·보관량과 필요한 사건의 시간 규모를 함께 비교한다.

분해능은 구별해 표현할 수 있는 작은 변화의 크기이고 정확성은 실제 값에 얼마나 가까운지와 관련된다. 소수점 한 자리로 26.1도를 표시해도 오차가 0.1도 이내라고 단정하지 않는다. 같은 방향으로 치우치는 오차와 측정마다 흔들리는 오차도 구별한다.

교정은 기준과 비교해 측정의 관계·오차를 확인하는 과정이다. 센서 위치·설치·노화·전원·주변 환경이 바뀌면 결과도 달라질 수 있다. 찬바람이 직접 닿는 센서의 값이 자료실 전체를 대표한다고 가정하지 않는다. 센서 하나가 고장났다고 반드시 통신도 끊기는 것은 아니므로 연결 상태와 측정 품질을 따로 본다.

데이터가 없으면 0도가 아니라 ‘미수신’이다. 범위를 벗어난 값은 실제 이상인지 센서·변환 오류인지 확인해야 한다. 반복되는 같은 값도 안정된 환경일 수도, 센서가 멈춘 상태일 수도 있다. 값 하나만으로 원인을 단정하지 않고 시각·순서·품질·장치 상태를 연결한다.

3. 게이트웨이·브로커·애플리케이션은 다른 책임이다

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

물리 환경을 센서가 관측해 게이트웨이에 보내는 입력은 아래 기존 상세 그림과 함께 읽는다. 현장 경로는 시각·단위·품질을 확인해 표시·경고하고, 원격 경로는 임시 저장 뒤 브로커로 전달한다. 세 구독 역할은 별개이며 브로커 수신이 이력 저장 완료나 물리 동작을 뜻하지 않는다. IO-G1은 관측·경고 사례이며 자동 제어를 허용하지 않는다.

게이트웨이는 장치망과 다른 서비스의 경계에서 연결·프로토콜 변환·집계·임시 저장 등을 맡을 수 있다. 메시지 브로커는 발행자와 수신자를 연결해 메시지를 전달한다. 애플리케이션은 받은 값의 업무 의미를 판단하고 화면·기록·안내를 만든다. 한 컴퓨터에서 여러 역할을 실행할 수 있어도 책임은 구별한다.

현장망을 선택할 때는 거리·장애물·간섭·전원·전송량·관리 가능성을 본다. 저전력과 긴 배터리 수명이 중요하면 통신 주기·메시지 크기·재전송 부담을 줄이는 설계를 검토한다. 높은 전송률이 필요한 영상과 드문 온도 기록을 같은 조건으로 평가하지 않는다. 명목 속도만으로 현장 도달 범위와 지속성을 확정하지 않는다.

현장 게이트웨이가 모든 장치를 연결한다면 하나의 고장이 여러 센서의 관측을 끊을 수 있다. 대체 경로·임시 보관·현장 담당자의 확인을 계획해야 한다. 반대로 모든 센서를 직접 원격 서비스에 연결하면 관리·인증·업데이트 대상이 늘 수 있다. 구조의 단순함과 장애영향 범위를 같이 비교한다.

메시지가 도착해도 현재 온도 확인이 남는다 · 상태 따라가기

수신 연결이 없어도 원래 사건 시각과 상태를 보존한다. 모든 단계에서 장치 사건·버퍼·수신·최신성의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

IO-B1처럼 현장 버퍼를 두는 구성의 전달 경로다. 버퍼는 단절 중 이력을 보존하고, 복구 후에는 신규 메시지와 함께 내보낸다. 화면에서는 관측시각·품질·중복을 별도로 검사한다. 현장 안내는 게이트웨이의 별도 판단이며 이 그림은 실제 설비 제어를 부여하지 않는다.

이 예의 조건

• IO-B1처럼 현장 버퍼를 두는 구성의 전달 경로다. 버퍼는 단절 중 이력을 보존하고, 복구 후에는 신규 메시지와 함께 내보낸다. 화면에서는 관측 시각·품질·중복을 별도로 검사한다. 현장 안내는 게이트웨이의 별도 판단이며 이 그림은 실제 설비 제어를 부여하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상센서 관측	원 설명ID·시각·단위·품질
대상게이트웨이	원 설명형식·현장 조건 확인
대상현장 버퍼	원 설명단절 중 이력 보존
대상원격 브로커	원 설명토픽·전달 단계
대상이력·상태 처리	원 설명중복·관측 순서 구별
대상담당자 화면	원 설명신선도와 안내 판단

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결센서 관측 → 게이트웨이	원 라벨·방향관측 / 정방향 / 실선
연결게이트웨이 → 현장 버퍼	원 라벨·방향보관 / 정방향 / 실선
연결현장 버퍼 → 원격 브로커	원 라벨·방향전송 / 정방향 / 실선
연결원격 브로커 → 이력·상태 처리	원 라벨·방향수신 / 정방향 / 실선
연결이력·상태 처리 → 담당자 화면	원 라벨·방향확인 / 정방향 / 실선

원그림의 경계

경계	포함 대상
경계현장: 관측과 단절 대응	포함 대상센서 관측, 게이트웨이, 현장 버퍼
경계원격: 전달과 상태 해석	포함 대상원격 브로커, 이력·상태 처리, 담당자 화면

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
연결 중단 수신 연결이 없어도 원래 사건 시각과 상태를 보존한다.	값·보충 정보 장치 사건·버퍼: 옛 시각 자료 보관 수신·최신성: 수신 대기	변화·이유 저장 시각을 새 측정 시각으로 바꾸지 않는다.
재연결·혼합 연결 복구 뒤 옛 자료와 새 자료가 함께 전달될 수 있다.	값·보충 정보 장치 사건·버퍼: 옛·새 사건 전송 수신·최신성: 순서·중복 확인	변화·이유 도착 순서가 사건 발생 순서는 아니다.
최신성 재검사 사건 시각·중복·순서를 대조하여 현재에 쓸 값을 판단한다.	값·보충 정보 장치 사건·버퍼: 원래 시각 유지 수신·최신성: 최신성·품질 검사	변화·이유 오래된 자료를 새 도착만으로 최신값으로 쓰지 않는다.
실제 저장 확인 broker 수신과 이후 저장·업무 반영 완료를 구별한다.	값·보충 정보 장치 사건·버퍼: 같은 사건 ID 수신·최신성: 수신 / 저장 확인	변화·이유 전달 단계마다 확인 범위가 다르다.

메시지가 도착해도 현재 온도 확인이 남는다 · 상태 따라가기

수신 연결이 없어도 원래 사건 시각과 상태를 보존한다. 모든 단계에서 장치 사건·버퍼·수신·최신성의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

IO-B1처럼 현장 버퍼를 두는 구성의 전달 경로다. 버퍼는 단절 중 이력을 보존하고, 복구 후에는 신규 메시지와 함께 내보낸다. 화면에서는 관측시각·품질·중복을 별도로 검사한다. 현장 안내는 게이트웨이의 별도 판단이며 이 그림은 실제 설비 제어를 부여하지 않는다.

이 예의 조건

• IO-B1처럼 현장 버퍼를 두는 구성의 전달 경로다. 버퍼는 단절 중 이력을 보존하고, 복구 후에는 신규 메시지와 함께 내보낸다. 화면에서는 관측 시각·품질·중복을 별도로 검사한다. 현장 안내는 게이트웨이의 별도 판단이며 이 그림은 실제 설비 제어를 부여하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상센서 관측	원 설명ID·시각·단위·품질
대상게이트웨이	원 설명형식·현장 조건 확인
대상현장 버퍼	원 설명단절 중 이력 보존
대상원격 브로커	원 설명토픽·전달 단계
대상이력·상태 처리	원 설명중복·관측 순서 구별
대상담당자 화면	원 설명신선도와 안내 판단

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결센서 관측 → 게이트웨이	원 라벨·방향관측 / 정방향 / 실선
연결게이트웨이 → 현장 버퍼	원 라벨·방향보관 / 정방향 / 실선
연결현장 버퍼 → 원격 브로커	원 라벨·방향전송 / 정방향 / 실선
연결원격 브로커 → 이력·상태 처리	원 라벨·방향수신 / 정방향 / 실선
연결이력·상태 처리 → 담당자 화면	원 라벨·방향확인 / 정방향 / 실선

원그림의 경계

경계	포함 대상
경계현장: 관측과 단절 대응	포함 대상센서 관측, 게이트웨이, 현장 버퍼
경계원격: 전달과 상태 해석	포함 대상원격 브로커, 이력·상태 처리, 담당자 화면

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
연결 중단 수신 연결이 없어도 원래 사건 시각과 상태를 보존한다.	값·보충 정보 장치 사건·버퍼: 옛 시각 자료 보관 수신·최신성: 수신 대기	변화·이유 저장 시각을 새 측정 시각으로 바꾸지 않는다.
재연결·혼합 연결 복구 뒤 옛 자료와 새 자료가 함께 전달될 수 있다.	값·보충 정보 장치 사건·버퍼: 옛·새 사건 전송 수신·최신성: 순서·중복 확인	변화·이유 도착 순서가 사건 발생 순서는 아니다.
최신성 재검사 사건 시각·중복·순서를 대조하여 현재에 쓸 값을 판단한다.	값·보충 정보 장치 사건·버퍼: 원래 시각 유지 수신·최신성: 최신성·품질 검사	변화·이유 오래된 자료를 새 도착만으로 최신값으로 쓰지 않는다.
실제 저장 확인 broker 수신과 이후 저장·업무 반영 완료를 구별한다.	값·보충 정보 장치 사건·버퍼: 같은 사건 ID 수신·최신성: 수신 / 저장 확인	변화·이유 전달 단계마다 확인 범위가 다르다.

4. 한 메시지는 값뿐 아니라 ‘무슨 관측인가’를 설명해야 한다

자체 메시지 IO-M1은 아래 의미를 가진다고 정한다. 이는 제작용 JSON 파일이나 실제 장치 프로토콜을 새로 만드는 작업이 아니라 학습용 데이터 계약이다.

수신 시각도 별도로 남긴다. 장치 시계가 정확하지 않다면 그 불확실성을 표시한다. 실제 시각과 동기화되기 전 장치의 임의 시간을 절대시각처럼 사용하지 않는다. 시간대와 단위만 통일해도 시계 오차가 없어지는 것은 아니다.

관측 나이도 구간으로 읽을 수 있다. 수신 측의 현재 시각이 정확하고 장치 시각의 오차가 최대 ±2초라면, 시각 차이로 계산한 나이 14초의 실제 범위는 12~16초다. 신선도 한계 15초를 걸치므로 ‘확실히 신선하다’고 승인할 수 없다. 이 사례에서 신선함은 실제 나이 0~15초라는 조건이므로, 가능한 구간이 그 범위 안에 모두 들어오는지 확인한다. 미래로 보이는 시각·오차 상한 부재는 별도 확인 대상이다.

중복을 구별할 업무 식별자는 장치·재시작 구간·순번처럼 실제 충돌과 재부팅을 고려해 정한다. 통신 패킷 식별자는 재사용될 수 있어 영구 관측 ID를 자동으로 대신하지 않는다. 동일 사건의 재전송을 새 측정으로 더하면 평균·경고 건수·요금이 틀어질 수 있다.

같은 식별자는 같은 관측 내용을 가리켜야 한다. 장치 A·부팅구간 7·순번 105의 재전송은 새 관측이 아니지만, 장치 A·부팅구간 8·순번 105는 재부팅 뒤 다른 관측일 수 있다. 같은 세 항목인데 값이나 관측시각이 다르면 정상 중복으로 버리지 말고 충돌을 기록한다. 단순 순번이나 MQTT 패킷 식별자만 중복 키로 쓰면 새 관측을 버리거나 오래된 내용을 덮어쓸 수 있다.

5. MQTT의 전달 수준을 업무 완료로 과장하지 않는다

MQTT는 발행·구독 방식의 메시징 프로토콜이다. 장치는 토픽으로 메시지를 발행하고 구독자는 지정한 토픽 조건의 메시지를 브로커에서 받는다. 토픽은 전달 경로의 이름이며 메시지 값의 정확성을 검증하는 규칙은 아니다. OASIS MQTT5.0은 다음 전달 수준을 구별한다.²

QoS는 송신자와 수신자 사이의 전달 절차에 관한 보장이다. 센서→브로커와 브로커→구독자의 조건·수명·실패는 별도로 확인한다. 수신확인은 애플리케이션이 내용을 처리했는지와 구별되므로 QoS2가 밸브의 실제 개폐나 장부의 한 번 갱신을 자동으로 증명하지 않는다.²

retained 메시지는 토픽의 보존된 마지막 값을 새 구독자 등에게 제공하는 기능이며 전체 측정 이력 저장소가 아니다. 과거 상태일 수 있으므로 관측시각·유효기간을 확인한다. Will은 정한 연결 종료 상황에 대해 서버가 발행하는 메시지이며 물리 센서 고장의 직접 진단과 같지 않다. 세션·메시지 만료와 저장 용량도 전달 범위에 영향을 준다.²

이 사례는 상태 전달에 QoS1을 쓰되 관측 ID로 중복을 처리하고 실제 저장 상태를 확인하는 안을 검토한다. 중요한 정보를 영구 보관할 필요가 있으면 별도 이력 저장과 누락 대사를 둔다. 모든 메시지에 가장 높은 QoS를 붙이는 것으로 비용·성능·업무 정합성이 동시에 해결된다고 하지 않는다.

6. 늦게 도착한 메시지가 최신 상태를 덮어쓰지 않게 한다

IO-T1에서는 두 메시지를 같은 센서에서 보냈고 장치 시각이 확인됐다고 가정한다. A는 10:00:00에 측정하여 10:00:05에 도착한다. B는 09:59:55에 측정했지만 재전송으로 10:00:07에 도착한다. 수신 순서에서는 B가 뒤지만 관측 순서에서는 A가 뒤다.

이력에는 둘 다 필요한 관측일 수 있다. 그러나 ‘현재 값’ 화면을 수신 순서대로 덮어쓰면 과거 값 B가 최신처럼 보인다. 업무가 요구하는 시간 순서와 허용할 늦은 자료의 범위를 정하고, 과거 이력의 보완과 현재 상태 갱신을 분리한다. 시계가 틀렸다면 시간순으로만 정렬하는 방식도 신뢰할 수 없으므로 순번·재시작·동기 상태를 함께 본다.

이 예의 신선도 한계를 15초로 정했다면 10:00:20 시점의 A는 20초 전의 관측으로 이미 오래됐다. 화면에 마지막 값을 참고로 남길 수 있지만 현재 정상이라고 표시하지 않는다. 네트워크가 복구된 뒤 과거 데이터가 밀려오는 경우에도 원래 관측시각을 보존하고 그 시각의 이력을 채운다.

순서와 중복, 누락은 별개다. 중복 제거를 했어도 빠진 관측이 남을 수 있고, 순서가 맞아도 각 값의 단위가 잘못됐을 수 있다. 끝까지 상태를 대사하지 않고 통신 성공 수만 보고하지 않는다.

7. 따라 계산 IO-B1: 통신량과 오프라인 보관

센서 200개가 각각 10초마다 메시지 한 개를 만들고, 관측 메타데이터를 포함한 응용 레코드가 80바이트라고 가정한다. 규칙적인 생성·무손실·일정한 크기의 계산 모형이며 실제 MQTT/TCP/TLS 헤더, 재전송·색인·저장 여분은 제외한다.

전체 생성률은 200/10=20개/초, 응용 데이터량은 20×80=1,600바이트/초다. 비트로는 12,800비트/초, 즉 12.8 kbps다. 하루 86,400초이므로 138,240,000바이트, 십진 138.24 MB가 된다.

연결이 한 시간 끊겨도 현장에서 계속 같은 비율로 기록하면 1,600×3,600=5,760,000바이트, 5.76 MB가 필요하다. 현장 버퍼 총 8 MB에서 80%만 이 기록에 사용할 수 있다면 사용 가능량은 6.4 MB다. 이 단순 모형에서 보관 가능 시간은 6,400,000/1,600=4,000초, 66분 40초다.

따라서 한 시간 기록은 산술상 들어가지만 여유가 충분하다는 실측 보증은 아니다. 실제 저장 부가정보·재전송 큐·쓰기 수명·전원 실패·다른 서비스 사용량을 반영해야 한다. 한도가 차면 어떤 기록을 보존·압축·집계하거나 버릴지와 누락 표시를 미리 정한다.

통신 복구 후에는 새 자료와 밀린 자료를 함께 보내야 한다. 처리율이 생성률과 같으면 backlog가 줄지 않는다. 예를 들어 저장·전송이 초당 40개를 처리하고 새 생성이 20개면 밀린 72,000개의 순수 감소율은 20개/초이므로 3,600초가 더 필요하다. 이 계산은 안정적인 처리율과 추가 손실이 없다는 별도 가정에 따른다. 연결 복구와 이력 복구 완료를 구별한다.

복구 구간 전체에서 최대 잔량을 확인한다. 처리율이 새 유입보다 작으면 연결이 살아 있어도 버퍼가 더 찬다. 기록 수로 계산할 때 잔량 변화는 유입 건수−처리 건수이며, 80바이트의 일정한 레코드라는 전제 아래 바이트로 바꿀 수 있다. 복구 마지막의 빠른 처리율만 사용하지 않고, 그 전에 느린 구간에서 한도를 넘었는지도 확인한다.

8. 어떤 일을 현장에서 하고 무엇을 원격으로 보낼까

현장의 신선도 확인·단위 검사·간단한 경고는 엣지에 둘 수 있다. 원격에는 여러 자료실의 이력 분석·집계·관리 등을 둘 수 있다. 가까이 배치했다고 항상 빠르지는 않다. 현장 자원이 부족하거나 큐가 길면 처리 지연이 클 수 있고, 원격 사용에는 통신 의존이 추가된다.

별도 IO-L1은 관측 처리 20 ms, 게이트웨이 30 ms, 통신 100 ms, 원격 대기 50 ms, 응용 판단 20 ms를 직렬로 합해 220 ms라고 가정한다. 현장 판단을 20+30+20 ms로 끝낼 수 있으면 70 ms다. 통신·대기가 줄었지만 동일한 기능·품질을 제공할 수 있는지 별도로 확인해야 한다. 숫자는 실제 제품의 지연이 아니다.

자체 경고 IO-A1은 정상·신선한 온도 관측이 28도 초과로 두 번 연속 들어오면 ‘확인 필요’를 알리고, 알림 뒤 27.5도 이하에서 해제한다고 정한다. 이처럼 켜는 기준과 끄는 기준을 달리하는 히스테리시스는 경계 주변의 잦은 전환을 줄이는 방식이다. 실제 보존 기준을 정한 것이 아니며 센서 오차·시각을 먼저 확인한다.

모든 값이 정상·신선하고 처음에는 알림이 꺼져 있다고 가정하여 27.9, 28.1, 28.2, 27.8, 27.5의 순서를 따라가자.

켜기 전 초과가 이어지지 않으면 연속횟수는 다시 0부터 센다. 켜진 뒤에는 28도 이하라는 이유만으로 끄지 않고 별도로 정한 27.5도 이하를 확인한다. 그래서 넷째 관측에서 알림이 유지된다. 누락·오래된 값은 연속 조건의 정상 관측으로 넣지 않고 이 예에서는 연속횟수를 초기화한다. 이 규칙이 모든 빠른 이상을 잡는다는 보장은 없으며 측정주기와 별도의 안전설비를 대체하지 않는다.

9. 장치·통신·운영의 보안 책임

무선 업데이트(OTA)는 장치에 직접 저장매체를 연결하지 않고 원격 연결을 통해 소프트웨어나 설정을 전달·갱신하는 방식이다. 다음 절에서는 이를 장치 생명주기와 설치·복구 관점에서 더 자세히 다룬다.

NISTIR8259A의 핵심 능력은 장치 식별, 허용된 설정 변경, 데이터 보호, 인터페이스 접근 제한, 안전한 소프트웨어 업데이트, 보안상태의 확인으로 정리된다.³ 이 여섯 항목은 위험에 맞는 요구를 만드는 출발점이며 도구 설치만으로 얻는 인증이 아니다.

도서관에서는 장치별 소유·위치를 확인하고 공통 비밀번호의 무분별한 공유를 피한다. 브로커 인증뿐 아니라 장치가 어느 토픽에 발행·구독할 수 있는지 제한한다. 한 센서가 다른 센서의 식별자로 데이터를 올리거나 관리 명령을 보내지 못하게 한다. 전송 보호는 메시지 내용과 인증정보를 보호하지만 센서의 잘못된 측정까지 진실로 만들지는 않는다.

게이트웨이에 저장한 사본과 관리 화면·로그도 보호 대상이다. 현장 접근·디버그 인터페이스·키 교체·지원 종료·업데이트 책임을 정한다. 제조사 문서·취약점 통보·지원과 사용자의 실제 운영도 연결해야 하며, 이 비기술적 지원은 NIST8259B에서 별도로 다룬다.⁴

IO-G1의 선택은 관측 ID·시각·단위·품질을 가진 레코드, 현장 신선도·경고와 제한 버퍼, 인증·토픽 권한이 있는 브로커, 원격 이력·대사다. 담당자는 통신 상태뿐 아니라 미수신·오래됨·교정·누락·중복·버퍼 잔량을 본다. 불명확한 값으로 자동 제어하는 안과 연결 성공만으로 기록 완료를 선언하는 안은 기각한다.

10. 자체 10점 문제와 완성 답안

IO-B1의 데이터량과 버퍼를 계산하고, MQTT QoS와 관측시각의 한계를 설명하시오.

IO-B1의 센서 수·주기·바이트와 80%의 사용 가능 공간을 먼저 적는다. 쌓인 메시지를 비울 때는 전송량에서 계속 생기는 신규량을 뺀다.

10점 자체 연습의 구성과 완성 답안

목차: 생성률·단위 → 버퍼시간 → 전달과 처리 → 시각·신선도.

IO-B1·IO-T1의 단계	답안에서 따로 확인할 값
센서 생성	단위·관측 시각·ID, 20건/초
게이트웨이 임시 저장	장애 시간, 1시간 72,000건·5.76 MB
MQTT 전달	홉별 전달 수준, 애플리케이션 중복 구분
이력과 현재값	관측 순서·신선도, 늦게 도착한 오래된 값의 처리

현장·원격 분기와 기존 전달 상세 그림을 함께 사용한다.

완성 답안

센서 200개가 10초마다 80바이트를 만들면 20레코드/초, 1,600바이트/초, 12.8 kbps의 응용량이다. 하루 138.24 MB, 한 시간 5.76 MB다. 8 MB 중 80%인 6.4 MB를 사용하면 4,000초, 66분 40초를 보관할 수 있다. 실제 헤더·재전송·색인·쓰기·전원 조건은 별도로 반영한다.

MQTT QoS1은 중복 전달 가능성을, QoS2는 해당 프로토콜 전달 교환의 정확히 한 번을 다룬다. 메시지 수신과 애플리케이션 저장·물리 행동의 완료는 다르므로 관측 ID와 실제 결과를 대사한다. retained 값도 전체 이력이나 현재 측정값이 아니다.

IO-T1은 늦게 도착한 B가 더 오래된 관측이므로 현재 상태를 수신 순서대로 덮어쓰지 않는다. 관측·수신 시각·순번·시계 상태를 연결하고 신선도 한계를 넘으면 오래됨을 표시한다. 미수신을 0도나 정상으로 바꾸지 않는다.

11. 자체 25점 문제와 완성 설계 답안

자료실 관찰 IoT 구조 IO-G1을 센서·게이트웨이·메시징·엣지/클라우드·보안·복구 관점에서 설계하시오.

IO-T1의 관측·수신 순서를 별도로 적고 IO-A1의 엄격한 초과·연속 횟수·해제 조건을 차례로 적용한다. 오래된 재전송을 현재 안내의 근거로 삼지 않는다.

25점 자체 연습의 설계 과정과 완성 답안

목차: 측정 조건 → 게이트웨이·메시징 → 엣지/원격 역할 → 보안·복구 → 운영 증거

현장 경고와 원격 저장 경로를 구분한다. 센서는 품질·시각을 포함한 관측을 만들고, 게이트웨이는 현장 판단과 임시 저장을 맡는다. 브로커는 장치별 권한 아래 메시지를 전달하며 원격 시스템은 중복·신선도·복구를 처리한다. 전달 완료를 원격 저장 완료나 물리 동작 완료로 바꾸어 해석하지 않는다.

완성 설계 답안

IO-G1의 목적은 자료실 온습도 관측과 담당자의 상태 확인 지원이며 화재·생명안전·자동 냉난방 제어는 제외한다. 설치 위치·센서 범위·분해능·교정·표본주기를 정하고 숫자와 실제 대표성을 구별한다. 장치 ID·부팅구간·순번·관측시각·단위·품질·설정 판본을 레코드에 연결한다.

게이트웨이는 장치망 연결과 단위·시각·품질 확인, 제한된 임시 저장을 맡는다. 신선도와 IO-A1의 두 번 연속 초과·별도 해제 조건을 현장에서 판단하되 오래된 값·누락을 정상 관측으로 쓰지 않는다. 원격 서비스는 브로커를 통해 이력·집계·장치 상태를 관리한다. 게이트웨이와 브로커·응용의 역할이 같은 기계에 있어도 책임을 구분한다.

MQTT 발행·구독의 토픽 권한을 제한하고 QoS1의 중복은 관측 ID로 처리한다. 센서→브로커와 브로커→구독자의 전달 조건과 실제 이력 저장을 나누어 확인한다. 늦은 자료는 과거 이력을 보완하되 현재값을 잘못 덮어쓰지 않는다. 시간 기준이 불명확하면 그 불확실성을 표시하고 추가 대사를 한다.

IO-B1의 생성 20건/초와 1시간 5.76 MB를 바탕으로 버퍼·저장 부가정보를 계획한다. 6.4 MB 가용 공간의 66분 40초는 단순 산술상 한계이며 실제 장애·쓰기 조건을 검증해야 한다. 복구 뒤 새 자료와 backlog를 함께 처리하며, 초당 40건 처리·20건 유입이면 1시간 backlog를 없애는 데 추가 1시간이 필요하다. 연결 복구와 이력 대사 완료를 나눈다.

운영자는 장치 소유·키·토픽·인터페이스 접근·사본·업데이트·지원종료와 알림 대응을 관리한다. 전송 보호와 수신확인이 측정 정확성을 보증하지 않음을 유지한다. 비정상 시각·단위·권한·버퍼 초과·측정 신뢰 상실에서는 해당 자동 판단을 보류하고 현장 확인으로 인계한다. 장치 수와 연결률이 아니라 누락·지연·측정 품질·실제 대응까지 증거를 남긴다.

12. 자기교정

조건 변경

같은 센서가 5초마다 측정하면? 40건/초·3,200바이트/초로 두 배다. 6.4 MB 가용 버퍼의 시간은 2,000초, 33분 20초여서 한 시간을 보관하지 못한다.

IO-T1의 최신 A 뒤 새 값 없이 10:00:20이 되면? A의 나이는 20초로 예제의 15초 한계를 넘는다. 숫자는 참고값으로 남길 수 있지만 현재 정상의 근거로 쓰지 않는다.

한 시간 backlog가 있을 때 처리율이 30건/초면? 새 생성 20건/초를 빼면 감소 10건/초다. 72,000건을 없애려면 7,200초, 2시간이다. 그동안 손실·추가 장애가 없다는 가정을 함께 적는다.

독립 확인: 연속 두 번에 오래된 관측을 넣어도 될까

IO-A1에서 처음 안내가 꺼져 있다. 차례대로 신선한 28.1도, 오래된 28.2도, 신선한 28.3도, 신선한 28.4도가 도착한다. 누락·오래된 자료는 켜기 전 연속 횟수를 초기화한다는 기존 조건을 적용한다. 각 단계의 횟수와 켜짐 여부를 쓰고, 이후 신선한 27.8·27.5에서 해제 여부를 판단한다.

변경 조건의 완전한 풀이와 오답 교정

첫 28.1은 28을 엄격히 초과하므로 횟수 1이지만 아직 꺼져 있다. 둘째는 오래된 자료라 횟수를 0으로 초기화한다. 셋째 28.3은 횟수 1로 꺼짐, 넷째 28.4는 횟수 2로 켜짐이다. 이후 27.8은 해제 조건 27.5 이하를 충족하지 않아 켜짐을 유지하고 27.5에서 꺼진다. 둘째 도착만으로 켜졌다는 답은 신선도 조건을 누락했다. 27.8에서 끈다는 답은 켜기 조건 28 초과와 해제 조건 27.5 이하를 같은 문턱으로 잘못 바꿨다. 메시지 도착과 실제 현장 제어 성공은 별개이며 이 문제의 결과는 관찰용 안내 상태다.

풀이를 닫고 A가 나중에 수신된 B보다 최신인 이유, 보내기 40개/초에서 쌓인 자료가 20개/초로 줄어드는 이유, retained 메시지를 현재 측정으로 표시하면 안 되는 이유를 설명한다.

2026-10-05 MQTT5.0 OASIS 표준의 4.3 전달 단계별 QoS를 다시 대조했다. 이 연결의 프로토콜 전달 의미를 앱 저장·업무 처리·물리적 작동의 전체 성공으로 확대하지 않는다.

근거와 범위

장치·시각·수치·알림기준·표·문제·답안은 자체 교육용이다. 실제 기기 등록·센서 수집·통신·제어·보존환경 시험·독립 감수는 수행하지 않았다.

회독의 핵심

IoT는 연결된 숫자보다 물리적 관측과 책임의 사슬이다. 값·단위·시각·품질을 함께 읽고 메시지 전달·이력 저장·실제 행동을 나눈다. 현장과 원격에 필요한 역할을 배치하고 누락·중복·지연·오프라인·보안까지 실제 상태로 관리한다.

관측과 복구 조건을 바꿔 확인하기

1. 수신 측 현재 시각은 정확하고 장치의 절대 시각 오차는 최대 ±2초다. A·B·C의 명목 관측 나이는 각각 14·18·12초이며, 품질은 정상이다. 이 연습의 신선함은 실제 나이가 0초 이상 15초 이하인 것이다. 각 나이 구간을 구하고 확실히 신선함·확실히 오래됨·경계 불확실을 분류하라. A를 현재 정상의 근거로 승인해도 되는가?
2. IO-B1의 일정한 생성 20건/초·80바이트/건이 계속된다. 복구 시작 때 밀린 기록은 72,000건, 사용 가능한 버퍼는 6,400,000바이트다. 첫 600초 동안 처리율은 10건/초, 이후 40건/초이고 손실·부가비용은 없다고 가정한다. 최대 잔량과 전체 복구 시간을 계산하라. 만약 느린 구간이 900초라면 같은 무손실 계산을 그대로 이어도 되는가? 생성·처리는 연속 평균율로 계산하는 교육 모형이다.
3. 관측 ID를 장치·부팅구간·순번의 세 항목으로 정하고, 동일 ID의 값·시각은 같아야 한다. 먼저 A=(장치 A,7,105), 24.1도가 저장됐다. 이어 같은 A와 같은 값·시각의 재전송, B=(장치 A,8,105), 25.0도, C=(장치 A,7,106), 24.2도, 그리고 A와 같은 ID·시각인데 99.9도를 담은 D가 도착했다. 처음 정상 사본은 보존하고 다른 내용은 충돌로 별도 기록한다는 정책이다. 정상 고유 관측·동일 재전송·충돌을 구분하라. 순번 105만 키로 쓰거나 MQTT 패킷 식별자를 영구 ID로 쓰면 충분한가?

시계 오차·복구 중 증가·재부팅 식별의 세 문제 풀이

1. A는 [12,16]초로 15초를 걸치므로 경계 불확실이다. B는 [16,20]초로 모두 15초를 넘으므로 확실히 오래됐다. C는 [10,14]초로 전체가 [0,15] 안에 있어 주어진 시각·품질 조건상 확실히 신선하다. A는 명목 14초만 보고 현재 정상의 근거로 승인하지 않고 오차·재측정 등 추가 확인으로 넘긴다. 이 판단도 해당 오차 상한을 신뢰할 수 있다는 전제에 한정된다.
2. 버퍼 한도는 6,400,000/80=80,000건이다. 첫 600초에 매초 20−10=10건씩 증가하므로 72,000+6,000=78,000건, 6.24 MB가 최대 잔량이다. 이후 매초 40−20=20건씩 감소하여 78,000/20=3,900초가 필요하므로 전체는 600+3,900=4,500초, 75분이다. 느린 구간이 900초라면 계산상 81,000건으로 한도를 1,000건 넘는다. 최초 잔여 8,000건은 800초에 모두 차고 그 이후 추가 기록을 모두 보존할 수 없다. 이 경우 이미 버림·압축·차단 등의 정책이 필요하므로 무손실 복구 완료를 선언하는 같은 계산은 성립하지 않는다.
3. 정상 고유 ID는 A·B·C의 3개다. 같은 A의 동일 사본은 재전송 1개이고, D는 같은 ID에 다른 내용이 있어 충돌 1개다. D로 최초 24.1도를 조용히 덮거나 별도 정상 관측으로 더하지 않는다. 부팅구간 8의 B는 순번 105가 같아도 새로운 관측이므로 순번만으로 제거하면 안 된다. MQTT5.0의 패킷 식별자는 응답 처리 뒤 다시 사용할 수 있고 통신 교환을 구별하므로, 영구 업무 ID를 대신하지 않는다. 이력 저장·충돌 확인은 프로토콜 수신과 별도 처리다.

Footnotes

1. W3C, Web of Things Architecture1.1, Terminology·Building Blocks·Deployment Scenarios. https://www.w3.org/TR/wot-architecture11/ . 2026-09-20 장치·중개·프로토콜·의미의 구조를 확인했다. 원문 그림과 구현 예제는 복제하지 않았다. ↩

2. OASIS, MQTT Version5.0, OASIS Standard07March2019, §§3.3.1,4.1,4.3,4.5의 전달·retained·세션·수신. https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html . 2026-09-20 해당 HTML 원문을 대조했다. 실제 브로커·통신을 실행하지 않았다. ↩ ↩² ↩³

3. NIST, IoT Device Cybersecurity Capability Core Baseline, NISTIR8259A(2020) 공개 소개 및 NIST의 핵심 능력 설명. https://www.nist.gov/publications/iot-device-cybersecurity-capability-core-baseline ; https://www.nist.gov/blogs/manufacturing-innovation-blog/whether-you-build-them-or-buy-them-iot-device-security-concerns . 여섯 능력의 역할을 확인한 범위이며 특정 장치 인증은 아니다. ↩

4. NIST, IoT Non-Technical Supporting Capability Core Baseline: NISTIR8259B, 2021-08-25 발표 안내. https://www.nist.gov/news-events/news/2021/08/iot-non-technical-supporting-capability-core-baseline-nistir-8259b . 문서·통보·지원의 관점만 참고하며 국가별 의무를 이전하지 않는다. ↩