농장 현장을 버티는 확장 가능한 농업 IoT 네트워크 플랫폼 아키텍처 설계

농업용 IoT 네트워크 플랫폼이 해결해야 하는 핵심

• 현장 환경: 전원 불안정, 습기/먼지, 통신 음영, 장비 재부팅/단선이 흔함
• 통신 다양성: Wi-Fi / Ethernet / LTE-M(NB-IoT) / LoRa / 위성 등 혼재
• 데이터 성격: 센서(주기), 이벤트(알람), 제어(명령), 대용량(이미지/펌웨어) 혼합
• 운영 요구: 원격 장애 대응, OTA, 장비 수천~수만대 확장, 비용(통신/클라우드) 최적화
• 보안 요구: 장비 단위 신원, 키/인증서 관리, 위변조 방지, 공급망(펌웨어) 안전

레이어별 플랫폼 구성(권장 표준 아키텍처)

A. 디바이스 레이어(센서/액추에이터/컨트롤러)

• 센서: 온도/습도/토양수분/EC/pH/CO₂/조도 등
• 액추에이터: 펌프/밸브/환풍기/히터/차광막 등
• 로컬 로직(필수)
  • 네트워크 끊겨도 안전 상태 유지(FAIL-SAFE)
  • 임계치 기반 로컬 자동제어(최소 기능)
  • 데이터 버퍼링(스토어&포워드), 시간 동기화(NTP)

예시(로컬 FAIL-SAFE)

• 토양수분 센서가 3회 연속 결측이면 → 펌프 “정지” + 경고 이벤트만 전송
• CO₂ 목표치를 못 맞추면 → 로컬 PID는 유지하되 “클라우드 제어 명령”은 보수적으로 적용

B. 엣지/게이트웨이 레이어(라즈베리파이/임베디드 리눅스)

게이트웨이는 “플랫폼의 현장 대리인”입니다. 아래 기능이 사실상 승부처예요.

• 연결 매니저(Connectivity Manager)
  • 우선순위/페일오버: Ethernet > Wi-Fi > LTE-M
  • 링크 품질 측정(RSSI, ping, DNS, HTTP probe)
  • 캡티브/SSID 변경/재연결 자동화
• 메시지 라우터(Protocol Bridge)
  • 센서(Serial/RS485/Modbus) → MQTT/HTTPS 변환
  • 로컬 큐잉(디스크 기반) + 재전송(retry/backoff)
• 디바이스 섀도우/디지털 트윈
  • “현재 상태(report)”와 “희망 상태(desired)” 동기화
  • 오프라인 시 desired 누적 → 온라인 시 적용
• OTA/원격 진단
  • 펌웨어/애플리케이션 업데이트
  • 원격 로그 수집, 헬스 체크, 구성 배포

C. 클라우드/플랫폼 레이어(AWS IoT Core 같은)

• 디바이스 레지스트리/프로비저닝: 장비 ID, 인증서, 정책, 속성 태깅(농장/동/라인/구역)
• 메시지 브로커: MQTT topics 설계, QoS, 라우팅 규칙
• 데이터 파이프라인
  • Raw 저장(시계열 DB/오브젝트 스토리지)
  • 실시간 처리(알람, 자동 제어, 이상탐지)
  • 장기 분석(작황/환경 패턴, 비용/에너지 최적화)
• 운영/관제
  • 기기 상태(온라인율, 배터리, 통신품질)
  • OTA 성공률, 장애 분포, 지역/통신사 이슈

D. 앱/서비스 레이어(대시보드/모바일/제어 UI)

• 농장별 모니터링 대시보드
• 알람(문자/앱푸시/슬랙/전화)
• 제어 정책(스케줄, 조건부, 권한 기반)

네트워크 플랫폼 설계 포인트

(1) 통신 추상화: “링크”와 “메시징”을 분리

• Link Layer: Wi-Fi/Ethernet/LTE-M 연결 관리(상태/품질/전환)
• Messaging Layer: MQTT/HTTPS/CoAP 등 상위 프로토콜
• Application Layer: 센서 수집/제어/OTA 로직

흔한 실패는 “네트워크 코드”가 애플리케이션 로직과 얽혀서, 특정 통신환경에서만 안정적인 구조가 되는 겁니다.

(2) “스토어 & 포워드(오프라인 버퍼)”는 옵션이 아니라 필수

현장에서는 끊김이 기본값입니다.

• 수집 → 로컬 큐(SQLite/LMDB/파일큐) 저장
• 전송 성공 시 ACK 기반 삭제
• 재전송(backoff + jitter), 전송량 제한(rate limit)
• 중복 제거를 위한 메시지 ID(ULID/UUID)

예시(메시지 포맷 권장)

{
  "deviceId": "farmA-gh1-gw01",
  "ts": 1736300000,
  "seq": 104233,
  "type": "telemetry",
  "payload": { "temp": 24.1, "hum": 61.2, "soil": 32.0 }
}

• seq를 넣으면 중복/유실/재전송을 서버에서 추적하기 쉬워집니다.

(3) MQTT 토픽 설계: 운영/보안/확장을 좌우

권장 토픽 예시(농장/구역/디바이스 단위 식별이 쉬운 구조)

• 텔레메트리
  • farm/{farmId}/device/{deviceId}/telemetry
• 이벤트/알람
  • farm/{farmId}/device/{deviceId}/event
• 명령(클라우드→디바이스)
  • farm/{farmId}/device/{deviceId}/cmd
• 명령 결과(디바이스→클라우드)
  • farm/{farmId}/device/{deviceId}/cmd/ack
• 헬스체크
  • farm/{farmId}/device/{deviceId}/health

예시(명령 메시지)

{
  "cmdId": "01J...ULID",
  "name": "set_irrigation",
  "args": { "zone": "Z3", "durationSec": 120 },
  "expiresAt": 1736300300
}

(4) QoS/세션 전략(현장형 IoT 최적)

• 텔레메트리(주기 데이터): 보통 QoS 0 + 로컬 버퍼로 보완
• 이벤트/알람/제어: QoS 1 권장(재전송 가능)
• 세션: cleanSession=false(혹은 persistent session) + 오프라인 메시지 큐 활용
• 메시지 크기 제한/압축: LTE-M 요금/대역폭 고려(필드 최소화, 필요 시 gzip/CBOR)

통신별 운영 현실과 대응(현장 디테일)

Ethernet

• 가장 안정적, 우선순위 1
• 점검: 링크 다운/스위치 장애/PoE 이슈

Wi-Fi

• 문제: 전파 간섭, AP 재부팅, SSID 변경, 채널 혼잡
• 대응: RSSI 기반 재연결, 다중 SSID, 캡티브 포털 회피, AP 상태 모니터

LTE-M / NB-IoT

• 문제: 지연/패킷 손실/사업자 정책/요금
• 대응: keepalive 최적화, payload 최소화, 전송 배치(batch), 재전송 정책 엄격화

300x250

게이트웨이(Embedded Linux/RPi) 구현 예시

(1) 네트워크 상태 확인(운영 기본)

ip a
ip r
ping -c 3 8.8.8.8
nslookup aws.amazon.com 1.1.1.1
curl -I https://example.com --max-time 5

(2) systemd로 “연결 + 에이전트” 상시 운영

/etc/systemd/system/iot-agent.service

[Unit]
Description=Farm IoT Agent
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/iot-agent
Restart=always
RestartSec=3
Environment=LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now iot-agent
sudo journalctl -u iot-agent -f

(3) MQTT 발행 테스트(현장 점검용)

mosquitto_pub -h <broker> -p 8883 \
  --cafile ca.pem --cert device.crt --key device.key \
  -t "farm/farmA/device/gw01/telemetry" \
  -m '{"temp":24.1,"hum":61.2}'

플랫폼 설계 시 “반드시” 들어가야 할 것들

A. 디바이스 신원(Identity)과 인증서

• 장비마다 고유 인증서/키(공유 키 금지)
• 제조/출고/설치 단계별 키 취급 절차 분리
• 키 저장: 가능하면 TPM/SE(보안칩) 또는 최소한 파일 권한+암호화

점검 포인트

• 같은 인증서를 여러 장비가 쓰지 않는가?
• 인증서 폐기(분실/탈취/폐기장비) 프로세스가 있는가?
• “현장 엔지니어가 USB로 키 복사” 같은 관행이 남아있지 않은가?

B. 권한 최소화(Least Privilege) – MQTT Topic ACL

• 장비는 자기 토픽만 publish/subscribe 가능해야 함
• 와일드카드(#) 남발 금지

예시 정책 의사결정

• farm/{farmId}/device/{deviceId}/# 범위 내에서만 허용
• 명령 수신은 .../cmd만 subscribe
• 데이터 송신은 .../telemetry, .../event, .../health만 publish

C. OTA 보안(공급망 보안의 핵심)

• 업데이트 파일 서명 검증(서명 없는 업데이트 금지)
• 롤백 전략(A/B 파티션 또는 last-known-good)
• 실패 시 부팅 불능(벽돌) 방지: watchdog + safe mode

점검 포인트

• OTA 성공률/실패 원인(네트워크/저장공간/검증실패)을 수집하는가?
• 서명 키가 개발/운영에서 분리되어 있는가?
• 업데이트 서버/버킷 권한이 최소화되어 있는가?

D. 로그/감사/관제(보안 운영)

• 디바이스 이벤트(재부팅/설정변경/인증실패/OTA) 표준화
• 중앙 수집 + 이상탐지(온라인율 급락, 특정 지역만 끊김, 인증실패 폭증)

보안 관점 체크리스트

• “명령 실행(원격 제어)”에 대한 감사 로그가 남는가? (누가/언제/무엇을/결과)
• 디바이스 시간 왜곡(NTP 실패) 탐지하는가?
• 인증 실패(브루트포스/탈취 키) 징후 경보가 있는가?

실전 운영 시나리오로 보는 플랫폼 동작 예시

시나리오 1: LTE-M 끊김 30분 발생

• 게이트웨이: 텔레메트리 로컬 큐 적재(디스크 200MB 제한)
• 제어: 로컬 정책으로 최소 관수 유지, 위험 시 정지
• 복구: 링크 probe 성공 → MQTT 재연결 → 큐 순차 전송(초당 5건 제한)
• 서버: seq 기준으로 중복 제거 + “데이터 지연 수집” 표시

시나리오 2: 원격으로 밸브 열기 명령 전송

• 클라우드: cmdId 발급, expiresAt 설정(예: 2분)
• 디바이스: 명령 수신 → 권한/유효기간 확인 → 실행 → cmd/ack로 결과 회신
• 보안/감사: “작업자 계정 + 승인 여부 + 결과” 로그 남김

시나리오 3: 대규모 OTA 배포(1만대)

• 그룹/캠페인: 농장/지역/통신사별 점진 배포
• 게이트웨이: 다운로드 재시도 + 해시/서명 검증 + 설치 + 재부팅 + 헬스 체크
• 관제: 성공률, 평균 소요시간, 실패 Top 원인 자동 리포트

플랫폼 관점 작업 범위 템플릿

권장 산출물(기술+운영 포함)

• 아키텍처 문서(레이어, 책임, 인터페이스)
• MQTT 토픽/메시지 스키마 정의서(JSON schema)
• 연결 매니저 설계서(상태머신, 페일오버 정책, probe 방식)
• 오프라인 큐 설계(저장소, 한도, 재전송, 중복처리)
• 보안 설계(인증서/ACL/OTA 서명/키관리)
• 운영/관제 지표(SLI/SLO): 온라인율, 메시지 지연, 재전송률, OTA 성공률
• 테스트 플랜: 네트워크 장애 주입(끊김/지연/패킷손실), 전원 차단, 시간 왜곡, 재부팅 루프