IoT 장치의 OTA 업데이트는 새 BIN 파일을 내려받는 것으로 끝나지 않습니다. 설치 중 전원이 끊기거나 새 펌웨어가 부팅 직후 재시작해도 현장에서 다시 연결할 수 있어야 합니다. 제품 설계 단계에서 업데이트 성공 조건과 이전 버전으로 돌아가는 조건을 함께 정해야 하는 이유입니다.
이 글은 ESP32·ESP-IDF v6.0.2 문서의 애플리케이션 OTA와 rollback을 기준으로 복구 절차를 정리합니다. 다른 칩·SDK 버전은 해당 버전 문서를 확인하세요. 아래 시험표는 설계 예시이며 실제 보드에서 전원 차단 시험을 수행했다는 의미는 아닙니다.
실행 중인 앱과 새 앱을 다른 슬롯에 두기
일반적인 애플리케이션 OTA는 ota_0, ota_1 같은 두 앱 슬롯과 부팅 선택 정보를 보관하는 otadata를 사용합니다. 새 이미지를 비활성 슬롯에 기록하고 검증한 후 다음 부팅 대상을 바꿉니다. otadata는 두 플래시 섹터를 사용하도록 설계되어 있습니다. Espressif OTA 문서
전체 플래시 용량에서 앱 두 개의 공간만 빼면 되는 것은 아닙니다. NVS, 파일시스템, 인증서·설정 영역과 향후 앱 증가분도 고려합니다. factory 앱은 구성에 따라 선택 사항이며, factory가 있다고 해서 항상 현재 제품에서 사용할 수 있는 복구본이 되는 것도 아닙니다. 이전 앱이 현재 하드웨어와 설정을 읽을 수 있어야 합니다.
개발 환경에서 다음 명령으로 실제 프로젝트의 파티션 배치를 확인할 수 있습니다. 장치에 플래시하는 명령은 아닙니다.
idf.py partition-table
두 OTA 슬롯 각각에 배포할 이미지가 들어가는지 확인하고, 앱 오프셋과 정렬은 해당 파티션 도구의 검사 결과를 따릅니다. 공통 CSV를 여러 플래시 용량의 보드에 무조건 적용하지 마세요. Espressif 파티션 테이블 문서
다운로드 완료와 정상 부팅 승인을 나누기
정상적으로 내려받은 이미지도 잘못된 핀 설정이나 초기화 오류 때문에 실행되지 않을 수 있습니다. 그래서 앱 설치 검증과 첫 부팅의 기능 진단을 별도로 둡니다.
ESP-IDF v6.0.2에서 CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE을 활성화한 구성은 새 앱의 첫 부팅을 검증 대기 상태로 관리합니다. 앱은 진단에 성공하면 esp_ota_mark_app_valid_cancel_rollback()으로 정상 동작을 승인합니다. 검증 대기 중 승인 없이 재부팅되면 rollback 절차가 적용됩니다. 오류를 확인한 앱은 esp_ota_mark_app_invalid_rollback_and_reboot()를 사용할 수 있습니다. 복귀할 수 있는 유효한 이전 앱이 있어야 한다는 조건도 함께 확인해야 합니다. Espressif App Rollback 설명
SDK 업그레이드 때는 이 옵션의 기본값과 첫 부팅 처리 방식을 다시 확인합니다. 이 글의 기준 버전 동작을 모든 ESP-IDF 버전에 그대로 적용하지 않습니다.
첫 부팅 진단에는 제품의 필수 기능을 넣기
“로그 한 줄을 출력했다”는 조건만으로 정상 앱을 승인하면 센서 초기화 실패를 놓칠 수 있습니다. 반대로 외부 클라우드가 잠시 응답하지 않는다는 이유만으로 매번 rollback하면 현장에서 불필요한 버전 왕복이 생깁니다.
다음은 로컬 센서 게이트웨이를 가정한 승인 기준 예시입니다.
| 검사 | 성공 기준 예시 | 실패했을 때 남길 정보 |
|---|---|---|
| 설정 읽기 | 지원하는 설정 스키마와 필수 값 확인 | 스키마 버전·오류 코드 |
| 필수 주변장치 | 사용 중인 센서·통신부 초기화 완료 | 대상 장치·실패 단계 |
| 주 작업 루프 | 정한 관찰 구간 동안 치명 오류 없음 | reset 원인·실행 단계 |
| 로컬 복구 경로 | 제품에서 정한 관리·복구 기능 사용 가능 | 접속 상태·진단 결과 |
외부 서버 연결이 제품의 필수 기능인 경우에는 별도 제한 시간과 실패 정책을 둡니다. 진단 시간이 무한정 길어지지 않도록 하고, 오류 기록을 저장하는 과정도 이전 앱에서 읽을 수 있게 설계합니다.
앱을 되돌려도 설정은 남을 수 있다
새 앱이 공용 NVS의 설정 구조를 바꾸고 원래 필드를 지운 뒤 실패했다고 가정해 봅시다. 부트로더가 이전 앱으로 돌아가도 그 앱이 새 설정을 읽지 못하면 정상 복구가 아닙니다.
이를 피하는 설계 방법은 설정에 스키마 버전을 붙이고, 처음에는 이전 데이터를 유지한 채 새 형식을 만드는 것입니다. 새 앱 승인이 끝난 후에도 롤백 가능 기간 동안 이전 형식을 보존할지 정합니다. 실제 데이터 마이그레이션 방식은 저장 용량과 제품 수명에 맞춰 결정합니다.
또한 애플리케이션 슬롯 OTA의 복구 특성을 부트로더·파티션 테이블·모든 데이터 파티션 변경에까지 확대해서 생각하면 안 됩니다. 기록 대상과 업데이트 방식에 따라 전원 중단 위험이 다릅니다. 공용 데이터 구조 변경은 앱 배포와 별도 검토 대상으로 두세요. Espressif OTA 업데이트 모드
전원 중단 지점을 나눈 시험표
| 중단 시점 | 제품에서 확인할 내용 |
|---|---|
| 새 이미지 일부만 수신 | 기존 앱으로 다시 부팅하고 재시도 가능 |
| 새 이미지 검증 실패 | 실패 이미지를 다음 부팅 대상으로 선택하지 않음 |
| 다음 부팅 대상 전환 전후 | 부팅 가능한 앱 선택과 로그 확인 |
| 첫 부팅 진단 중 | 미승인 앱 처리와 이전 앱 복구 확인 |
| 새 설정 작성 중 | 이전 앱에서도 설정 복구 가능 |
| 정상 승인 이후 | 이후 장애에 대한 별도 복구 정책 확인 |
첫 부팅 rollback이 평생 동안 모든 장애를 자동 복구해 주는 것은 아닙니다. 정상 승인 이후 수 시간 뒤 발생하는 누수·교착 상태는 별도의 장시간 시험과 장애 처리 정책이 필요합니다.
전송 검증과 버전 정책까지 연결하기
HTTPS OTA는 서버 인증서 검증을 포함해 설정하고, 해당 제품이 요구하는 이미지 서명 검증도 적용합니다. 잘못된 인증서나 변조된 이미지는 실패 경로에서 시험해야 합니다. 전송이 암호화되어 있다는 사실과 펌웨어의 출처를 검증한다는 사실은 구분합니다. Espressif ESP HTTPS OTA 문서
Anti-rollback을 쓰는 제품은 이전 앱의 보안 버전이 복귀 조건을 만족하는지도 확인해야 합니다. eFuse에 기록되는 보안 버전 정책은 일반 버전 문자열과 다르므로 출하 정책에 맞춰 설계하고, 이 글을 따라 임의로 eFuse를 변경하지 않습니다.
개발 중에는 Tera Term으로 부팅 로그를 모으고, 현재 앱 버전·실행 슬롯·reset 원인·검증 상태를 한 기록으로 묶어 확인하면 실패 지점을 찾기 쉽습니다.
작성·문서 확인: 2026년 9월 13일. 기준: ESP32, ESP-IDF v6.0.2. 실제 보드·플래시 구성에서 시험한 뒤 제품에 적용해야 합니다.