OTA 업데이트 설계: 정상 확인과 롤백

원격 장비에 새 펌웨어를 보냈지만 재부팅 후 연결이 끊긴다면, 다운로드 성공률만으로는 유지보수 품질을 판단하기 어렵습니다. OTA(무선·네트워크를 통한 펌웨어 갱신)는 파일 전송, 이미지 검증, 시험 부팅, 정상 확정과 복구를 구분해 설계해야 합니다. 이 글은 일반적인 설계 판단을 위한 예시이며 특정 고객 장비의 구현이나 시험 결과를 소개하는 글이 아닙니다.

1. 다운로드 완료와 정상 확정을 분리합니다

Espressif ESP-IDF v5.4.2의 ESP32 OTA 문서는 실행 중인 앱과 별도인 OTA 슬롯에 새 이미지를 기록하고, 검증 후 다음 부팅 대상을 바꾸는 구조를 설명합니다. 앱 슬롯 두 개 이상과 OTA 데이터 파티션이 필요합니다. 롤백은 CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE 설정을 전제로 하며, 기본적으로 활성화된 기능이라고 가정하면 안 됩니다.

이 설정에서는 새 앱이 ESP_OTA_IMG_PENDING_VERIFY 상태로 진단을 수행한 뒤 esp_ota_mark_app_valid_cancel_rollback()으로 정상 상태를 확정합니다. 확정 전에 재부팅되면 이전의 부팅 가능한 앱으로 복귀하는 절차가 적용됩니다. 따라서 시작 함수에 들어오자마자 성공을 확정하면 이후 발생하는 주요 기능 장애를 이 확인 단계에서 잡지 못할 수 있습니다. 사용하는 칩과 SDK 버전에 맞춰 설정과 API 반환값을 확인하십시오.

2. 정상 판정은 제품 기능을 기준으로 정합니다

다음은 가상의 원격 센서 장비에 적용할 수 있는 설계 예시입니다. 메모리 할당과 필수 태스크 시작, 설정 해석, 센서 응답 및 로컬 데이터 처리까지 확인한 뒤 정상 확정을 허용합니다. 단순히 LED가 켜지거나 로그 한 줄이 출력되는 조건만으로는 핵심 기능을 확인했다고 보기 어렵습니다.

• 필수 진단: 장비의 기본 기능을 수행하는 데 꼭 필요한 항목과 실패 시 복구 조건을 문서화합니다.

• 외부 의존성: 통신망 장애와 펌웨어 결함을 구별합니다. 서버에 연결되지 않았다는 이유만으로 무조건 롤백하면 정상 펌웨어도 현장 망 상태 때문에 되돌아갈 수 있습니다.

• 시간 제한: 진단을 무한 대기하지 않게 하고, 시간 초과 시 재시도·복귀 정책을 정합니다. 실제 부팅·센서 준비 시간을 측정해 한계를 정해야 합니다.

• 출력 상태: 업데이트와 진단 중 액추에이터 출력은 장비별로 정의한 안전 상태를 유지합니다. 모든 설비에서 전원 차단이 곧 안전 상태인 것은 아닙니다.

서버 통신 자체가 제품의 필수 기능이라면 제한된 연결 시험을 정상 조건에 포함할 수 있습니다. 이때는 통신 두절 시 현장 유지 운전 여부, 진단 기한과 작업자의 복구 방법까지 함께 합의해야 합니다.

3. 부트로더마다 시험 부팅 방식이 다릅니다

MCUboot 공식 설계 문서는 swap 방식에서 새 이미지를 시험 실행한 뒤 앱이 정상 표시를 남기면 영구 적용하고, 그렇지 않으면 다음 부팅에 되돌리는 구조를 설명합니다. 처음부터 영구 적용하도록 요청하는 경로도 있으므로, 업데이트 API 호출이 시험 적용인지 영구 적용인지 구별해야 합니다. direct-XIP·RAM-load 등의 모드는 복귀 설정과 이미지 구성 조건이 다릅니다.

두 이미지 영역을 확보했다는 사실만으로 모든 제품에서 같은 롤백 동작이 보장되지는 않습니다. 플래시 용량, 이미지 크기 증가 여유, 부트로더 방식, 메타데이터와 서명 영역을 포함해 파티션을 결정하십시오. 이 글의 앱 업데이트 흐름을 부트로더나 파티션 테이블 자체를 바꾸는 작업에 그대로 적용하면 안 됩니다.

4. 펌웨어를 되돌려도 설정은 되돌아가지 않을 수 있습니다

예를 들어 새 버전이 센서 설정의 형식을 변경하고 이전 형식의 데이터를 지웠다고 가정해 보겠습니다. 앱은 이전 버전으로 복귀해도 그 버전이 새 설정을 해석하지 못하면 기능은 복구되지 않습니다. 이는 앞서 설명한 부팅 확인 기능과 별도로 검토할 설계 문제입니다.

권장 검토 방법은 설정에 형식 버전을 기록하고, 시험 부팅 중에는 이전 버전이 읽을 수 있는 데이터를 보존하는 것입니다. 새 형식으로 변환할 때 원본을 바로 덮어쓸지, 별도 영역에 변환본을 둘지 결정하고 정상 확정 이후 정리 시점도 정합니다. 서버 API와 메시지 형식 역시 구버전 복귀를 허용하는 기간 동안 호환되어야 합니다.

또한 보안상 오래된 취약 버전으로의 복귀를 금지하는 anti-rollback과 장애 복구용 rollback은 목적이 다릅니다. ESP-IDF의 anti-rollback은 칩에 기록된 보안 버전보다 낮은 앱을 제한합니다. 그러므로 예전 이미지가 남아 있어도 복귀가 허용되는지 확인해야 합니다. 보안 버전 갱신과 복구 이미지 정책을 함께 검토하십시오.

5. 성공 경로보다 실패 지점별 시험을 먼저 준비합니다

다음은 개발·검증 계획에 넣을 수 있는 시험 항목입니다. 표는 수행 결과가 아니라 확인해야 할 기대 동작을 정리한 것입니다.

시험 기록에는 HW 리비전, 부트로더·앱 버전, SDK 설정, 전원 차단 지점, 재부팅 원인, 최종 실행 버전을 남깁니다. 복귀 가능한 이미지가 없거나 보안 정책상 복귀할 수 없는 경우를 위한 서비스 포트·현장 복구 절차도 별도로 준비합니다. 정상 확정 이후에 발견되는 결함은 초기 시험 부팅 롤백만으로 해결되지 않으므로 운영 중 감시와 후속 배포 정책이 필요합니다.

6. 발주 전에 합의할 네 가지

고객과 개발팀은 업데이트 허용 시간, 정상 판정 조건, 복구 후 유지해야 할 설정, 원격 복구가 불가능할 때의 대응 방법을 먼저 합의하는 편이 좋습니다. 초기 소수 장비에 단계적으로 배포하고 장애 징후가 보이면 확대를 중단하는 절차도 운영 계획에 포함하십시오. 이러한 기준이 있어야 “업데이트 기능 구현 완료”의 범위를 검수 가능한 조건으로 바꿀 수 있습니다.

참고 자료

• Espressif — ESP-IDF v5.4.2, ESP32 Over The Air Updates: OTA 슬롯, 앱 확인과 롤백, 보안 버전 제한.

• MCUboot — Bootloader design: test·permanent·revert와 모드별 복귀 조건.

자료 확인일: 2026-11-09. 적용 시 대상 MCU·SDK·부트로더의 확정 버전 문서를 기준으로 다시 검토해야 합니다. 대표 이미지는 업데이트와 복귀를 설명하는 생성형 개념 일러스트이며 실제 나로시스템 제품 사진이나 성능·인증 증빙이 아닙니다.