Smart Farm

온실 센서 값은 끊기거나 튀고, 기기 시간이 틀리기도 하며, DB나 백엔드가 잠시 멈춰도 측정값을 잃으면 안 됩니다. 흙이 마르면 사람이 화면을 보기 전에 펌프가 켜져야 하고, 네트워크가 끊겨도 펌프가 계속 돌아 물이 넘치면 안 됩니다. 남의 농장 데이터에 접근할 수 없어야 하는 것도 기본입니다.

실제 ESP32(DHT22, 정전식 토양 수분, BH1750 조도, 수위, 릴레이 + 12V 펌프)와 프로덕션 데모용 시뮬레이터가 같은 경로로 Mosquitto(TLS 8883, QoS 1)에 보냅니다. NestJS 11 IoT 파이프라인이 기기 API 키, payload 형태, topic과 deviceId 일치, 센서 소유권, 보정을 확인하고 Redis 버퍼(재시도, DLQ)를 거쳐 MongoDB에 원시 값과 90일 TTL time-series로 저장한 뒤 시간·일·월 집계를 만듭니다. 센서별 Z-score 이상 탐지(≥ 2 경고, ≥ 3 심각), 식물 건강 지수, Open-Meteo 날씨(10분 캐시)를 계산하고, 자동화 규칙이 액추에이터 상태를 바꾸면 MQTT로 RELAY_ON/OFF를 기기에 보냅니다. 대시보드는 GraphQL(resolver 51개)과 Socket.IO로 실시간 갱신되며 한국어, 영어, 우즈베크어를 지원합니다.

크게 보기

무엇을 바꿨나

hash + zset 버퍼와 30/60/120초 backoff, DLQ, 멈춘 메시지 복구(e49f6d32), DB 오류를 '잘못된 키'와 구분(e49f6d32), MQTT 지속 세션과 onApplicationBootstrap 연결(c4010d09), best-effort 오류 로그(9ddb7dbb). DB 중단 중 handler 오류는 4건에서 0건이 됐습니다. 측정은 sf-outage-check.sh와 sf-restart-check.sh로 프로덕션에서 했고, 시뮬레이터 부하(30초에 약 2건)입니다.

증상

가입 mutation에 memberRole: "ADMIN"을 보내면 ADMIN 회원이 만들어졌습니다(probe before).

원인

CreateMemberInput에 memberRole 필드가 있었고 memberModel.create(input)이 입력 전체를 저장했습니다. 프로필 수정의 MemberUpdateInput도 역할, 상태, 이메일, 비밀번호를 받았습니다. 같은 감사에서 @Roles(MANAGER)는 있지만 @UseGuards(RolesGuard)가 없어 회원 목록이 토큰 없이 열려 있었고({"total":7}), guard가 클래스 수준 @Roles를 읽지 않아 버퍼 관리 resolver도 열려 있었습니다.

해결

입력에서 필드를 없애고 create와 $set에 허용된 필드만 넘깁니다(22a760bd). guard를 붙이고 getAllAndOverride로 handler와 클래스를 함께 읽어, 잘못된 토큰은 401입니다.

재발 방지

고치기 전 프로덕션의 악용 흔적을 먼저 확인했습니다(회원 7명 모두 WORKER/ACTIVE, 권한 계정 0, 의심 호출 0). member-security.spec.ts 13개가 수정 전 코드에서 12개 실패하는 것을 확인했고, 배포 후 외부 probe 5개가 모두 거부됐습니다.

테스트 수

89

커버리지

—

CI

—

테스트 도구

Jest 30, ts-jest, 실제 redis-server, Mosquitto 2.0.18, MicroPython stub harness

배포 환경

VPS 한 대의 docker-compose.prod.yml: mongo(768m), redis(128m, requirepass, AOF), mosquitto(64m, 외부에는 8883 TLS만, Caddy 인증서 read-only, allow_anonymous false, password file + ACL, persistence), backend(768m, internal 네트워크만, mongo/redis가 healthy일 때 기동), web(64m), device-simulator(96m, demo 프로필). 공용 Caddy가 HTTPS를 관리합니다. 배포: git pull --ff-only → build backend → up -d backend. 비밀값(MONGO_PASSWORD, REDIS_PASSWORD, MQTT_BACKEND_PASSWORD, SECRET_TOKEN)은 서버 .env에만 있고 없으면 compose와 백엔드가 시작되지 않습니다.

백업

—

롤백

—

모니터링

관리자용 GraphQL로 버퍼 상태(pending / retrying / deadLetter) 조회, DLQ 메시지 확인과 정리, Message retry scheduled / Message moved to DLQ 로그. 직접 만든 운영 스크립트: sf-incident-check.sh, sf-security-probe-v2.ps1, sf-outage-check.sh, sf-restart-check.sh

• backend/apps/smart-farm/src/iot/iot-pipeline/iot-pipeline.service.ts

  MQTT 수신, 기기 인증, 버퍼, 읽기값별 저장, 이상 탐지, 규칙 평가

• backend/apps/smart-farm/src/iot/iot-pipeline/sensor-payload.ts

  topic의 deviceId, envelope 검사, recordedAt 시간 창

• backend/apps/smart-farm/src/mid-iot/message-buffers/message-buffers.service.ts

  Redis 버퍼: enqueue/ack/markFailed, backoff, DLQ, 멈춘 메시지 복구

• backend/apps/smart-farm/src/iot/mqtt/mqtt.service.ts

  지속 세션, onApplicationBootstrap 연결

• backend/apps/smart-farm/src/actuator/actuator.service.ts

  릴레이 명령, 펌프 제한, 규칙 원자적 점유

• backend/apps/smart-farm/src/ownership/ownership.interceptor.ts

  전역 소유권 검사, 인자 → 리소스 매핑, @OwnedArgs

• backend/apps/smart-farm/src/ownership/ownership.service.ts

  리소스 → 상위 체인을 farm.memberId까지

• backend/apps/smart-farm/src/account-context-module/auth/guards/roles.guard.ts

  handler + 클래스 역할, 401/403

• backend/apps/smart-farm/src/account-context-module/member/member.service.ts

  가입과 프로필: 허용된 필드만

• backend/apps/smart-farm/src/account-context-module/password-reset/password-reset.service.ts

  OTP: randomInt, 원자적 시도 횟수

• firmware/esp32/main.py

  센서, 릴레이, 펌프 제한, NTP, QoS 1 재구독

• deploy/mosquitto/mosquitto.conf

  TLS 8883, persistence, ACL

2026-10-10–11 감사에서 수정 커밋 9개를 냈고, 모두 전후 측정이 있습니다. MongoDB를 132초 멈춰도 메시지 24/24가 저장됐고(재시도 6회, DLQ 0), 백엔드를 20초 멈춰도 7/7이 도착했으며 그중 백엔드가 꺼져 있던 동안 보낸 메시지는 broker 큐에서 왔습니다. 수정 전 코드에서는 58초 중단에 12건 중 1건, 배포 재시작에 1건이 사라졌습니다. 보안 점검에서 12개 이상의 취약점을 찾아 닫았습니다: 가입 때 memberRole로 ADMIN 되기(22a760bd), 프로필 수정으로 임의 필드 쓰기, 남의 농장·섹터·알림 접근(c2c5ca26), OTP 무제한 추측과 Math.random OTP, 코드에 박힌 JWT 키(a5a1b62e), 프로덕션에 열린 GraphQL playground. 고치기 전에 프로덕션의 악용 흔적부터 확인했습니다(회원 7명, 권한 계정 0, 의심 호출 0). 또 백엔드가 DB에서만 펌프를 켜고 기기에는 아무 명령도 보내지 않던 문제(3f3eacb2), NTP 동기화 전 ESP32가 1970년 시각을 보내던 문제도 고쳤습니다. 처음 세운 가설(오류가 heartbeat에서 나온다)이 틀렸을 때는 로그로 실제 원인(/sensors)을 찾았고, 45초 중단은 드라이버의 30초 대기를 넘지 못해 오류 경로를 검증하지 못한다는 점도 기록했습니다.