ESP32의 OTA 업데이트는 쉬워 보이지만

ESP32의 OTA 업데이트는 쉬워 보이지만, 기기를 벽돌처럼 먹통으로 만들 수 있습니다.

 

흔치 않은 의견이지만, ESP32 OTA 업데이트가 실제 환경에서 한 번도 실패하지 않았다면, 아마도 충분히 오래 사용하지 않았기 때문일 것입니다.

 

OTA는 튜토리얼에서는 간단해 보이지만, 실제 제품 환경에서는 가장 위험한 기능 중 하나입니다.

 

대부분의 개발팀은 OTA를 펌웨어 업로드 문제로만 생각합니다. 하지만 OTA는 펌웨어 업로드 문제가 아니라, 장애 관리 문제입니다.

 

실제로 기기를 벽돌처럼 먹통으로 만드는 요인은 다음과 같습니다.

 

• 전원이 항상 안정적이라고 가정하고 플래시 메모리에 데이터를 쓰는 경우

• Wi-Fi 연결이 끊길 가능성을 고려하지 않고 Wi-Fi 안정성을 가정하는 경우

• 파티션 테이블을 미리 잠그고 펌웨어 크기가 커지지 않기를 바라는 경우

• 롤백이라고 표시해 놓고 실제로 롤백을 실행하지 않는 경우

• 플래시 메모리의 플래그를 믿고 손상이 발생하지 않을 거라고 생각하는 경우

• "몇 달 동안 잘 작동했으니" 플래시 메모리 마모를 무시하는 경우

 

연구실에서는 OTA가 문제없이 작동하는 것처럼 보이지만, 실제 환경에서는 그렇지 않습니다.

 

전압 강하, EMI, 워치독 리셋, 낮은 RSSI, 불완전하게 기록된 섹터, 조각난 힙, 마모된 플래시 메모리 등은 모두 업데이트 중에 나타나며, 정상 작동 중에는 나타나지 않습니다.

 

냉혹한 현실: 대부분의 ESP32 OTA 구현은 단 한 번의 전원 오류로 영구적인 고장으로 이어질 수 있습니다.

 

생산 수준의 OTA를 위해서는 다음과 같은 엔지니어링 완성도가 필요합니다.

 

• 원자적 전환을 지원하는 듀얼 앱 파티션(단순 점프 방식이 아닌).

• 펌웨어는 전체 부팅 주기를 견뎌낼 때까지 신뢰할 수 없음.

• 전압이 불안정할 경우 업데이트를 거부하는 전력 인식 업데이트 로직.

• 가정이 아닌 오류 주입을 통해 검증된 롤백 경로.

• 충돌 후에도 유지되는 영구적인 업데이트 상태.

• 동시 다발적 장애를 방지하기 위한 플릿 수준의 설계.

 

OTA는 단순히 추가하는 기능이 아닙니다. 최악의 상황에서도 지켜야 할 약속입니다.

 

업데이트 시스템이 문제가 발생하는 바로 그 순간을 견뎌낼 수 없다면, 생산 준비가 된 것이 아닙니다.

 

엔지니어는 OTA 데모의 성공을 축하하지 않습니다. 그들은 최악의 타이밍에 업데이트가 실패하도록 설계합니다.