펌웨어는 디바이스를 작동시키고, 시스템 엔지니어링은 디바이스를 유지 관리합니다.

ESP32 Fleet 플릿 확장은 펌웨어 작성보다 훨씬 어렵습니다.

 

ESP32용 펌웨어를 작성하는 것은 쉬운 부분입니다. 수천 대의 장치를 현장에서 안정적으로 유지하는 것이야말로 진정한 엔지니어링의 시작입니다.

 

대부분의 ESP32 프로젝트는 코드의 결함 때문에 실패하는 것이 아닙니다. 확장성을 나중에 고려했기 때문에 실패하는 것입니다. Wi-Fi 연결이 끊기고, 장치가 예기치 않게 재부팅되고, 플래시 메모리가 마모되고, OTA 업데이트가 부분적으로만 성공하고, 한 번의 잘못된 릴리스로 수백 대의 노드가 조용히 먹통이 되는 등의 문제가 발생합니다.

 

소규모 환경에서는 USB 케이블로 디버깅할 수 있지만, 플릿 규모에서는 메트릭, 하트비트, 그리고 몇 달 전에 세운 가정을 바탕으로 디버깅해야 합니다.

 

첫 번째 냉혹한 현실은 OTA가 단순한 기능이 아니라 시스템이라는 것입니다. 버전 관리, 롤백, 전원 손실 복구, 단계적 배포, 대역폭 제약 조건은 업데이트 로직 자체보다 훨씬 중요합니다. 시스템이 업데이트를 안전하게 실패 처리할 수 없다면 OTA를 지원할 준비가 된 것이 아닙니다.

 

두 번째 현실은 연결이 보장되는 것이 아니라 확률적이라는 것입니다. 펌웨어는 패킷 손실, DNS 오류, 캡티브 포털, 장시간 오프라인 상태를 고려해야 합니다. MQTT 세션 처리, 지수 백오프, 로컬 데이터 버퍼링은 최적화가 아니라 필수 요구 사항입니다.

 

세 번째 교훈은 관찰 가능성이 로깅보다 중요하다는 것입니다. 시리얼 로그는 확장성이 떨어집니다. 확장성이 뛰어난 것은 디바이스 상태 원격 측정, 하트비트 토픽, 재설정 이유 추적, 힙 사용량 추세, 전체 디바이스의 펌웨어 버전 가시성입니다.

 

네 번째 과제는 플래시 메모리와 RAM이 장기적인 부담이라는 점입니다. 한 번의 재부팅 후에도 유지되는 메모리 누수는 몇 달 안에 디바이스를 망가뜨릴 수 있습니다. 테스트에서는 무해해 보이는 플래시 쓰기 작업도 실제 운영 환경에서는 섹터를 손상시킬 수 있습니다. 내구성을 고려한 설계는 선택 사항이 아닙니다.

 

마지막으로, 개별 디바이스의 동작보다 전체 시스템의 동작이 더 중요합니다. 디바이스를 관리하는 것이 아니라 배포를 관리해야 합니다. 배포, 장애율, 지연 시간 곡선, 복구 동작 등이 모두 중요합니다. 대부분의 팀이 어려움을 겪는 부분이 바로 이러한 사고방식의 변화입니다.

 

제 원칙은 간단합니다. 현재 몇 대의 디바이스가 비정상 상태인지, 그리고 그 이유는 무엇인지 30초 이내에 파악할 수 없다면, 시스템은 운영 준비가 되지 않은 것입니다.

 

펌웨어는 디바이스를 작동시키고, 시스템 엔지니어링은 디바이스를 유지 관리합니다.

 

ESP32 제품을 개발하는 경우, 이 계층이 진정한 차별화가 이루어지는 곳입니다.

 

fb: https://www.facebook.com/groups/esp32esp8266forbeginner/