OTA(Over-the-Air) Update

• OTA Update는 기기의 펌웨어/소프트웨어를 유선 연결 없이 Wi-Fi·셀룰러 등 무선 네트워크로 갱신하는 방식
• 임베디드·IoT 기기 한정으로는 **FOTA(Firmware Over-The-Air)**라고 부르는 배포 기법
• 사용자가 USB 케이블·전용 툴 없이 원격에서 대규모로 배포 가능한 업데이트 채널
• 다운로드 → 검증 → 재부팅 → 자가진단 → 확정/롤백으로 이어지는 무중단·복구가능(power-safe) 갱신 절차

해당 개념이 필요한 이유

• 현장에 이미 배포된 수십~수만 대의 기기를 일일이 회수하거나 USB로 물리 연결하지 않고 버그 수정·기능 추가를 반영하기 위해
• 사용자에게 “새 버전이 나왔으니 컴퓨터에 연결해서 사이트에서 펌웨어를 받아 구우세요”라고 요구하지 않고, 기기가 스스로 받아 적용하는 경험을 주기 위해
• 업데이트 도중 정전/네트워크 끊김이 발생해도 기기가 벽돌(brick)이 되지 않도록 이중 슬롯 + 롤백으로 안전하게 처리하기 위해

AS-IS — USB로 직접 굽는 방식 (사용자가 지양하는 흐름)

sequenceDiagram
    autonumber
    actor U as 사용자
    participant PC as 컴퓨터(플래셔 툴)
    participant D as ESP32 기기
    U->>PC: 릴리스 사이트에서 .bin 펌웨어 다운로드
    U->>D: USB 케이블 물리 연결
    PC->>D: esptool로 flash 전체 굽기
    D-->>U: 재부팅 후 새 펌웨어 실행
    Note over U,D: 기기마다 케이블 연결·수동 작업 필요 → 확장 불가

TO-BE — OTA (기대하는 흐름: 알림 → 버튼 → 무선 갱신)

sequenceDiagram
    autonumber
    participant S as 펌웨어 서버/클라우드
    participant D as ESP32 기기
    actor U as 사용자(앱)
    S-->>D: "새 버전 v1.2.0 있음" 알림(push/manifest)
    D-->>U: 앱에 업데이트 가능 표시
    U->>D: [업데이트] 버튼 클릭
    D->>S: 새 펌웨어 이미지 요청(HTTPS)
    S-->>D: 이미지 스트리밍 전송
    D->>D: 비활성 슬롯에 기록 + 서명/무결성 검증
    D->>D: 부팅 파티션 전환 후 재부팅
    D->>D: 자가진단 성공 → 확정 (실패 시 자동 롤백)
    D-->>U: 업데이트 완료 보고

OTA가 실제로 동작하는 방식 (ESP32/ESP-IDF 기준)

ESP32는 플래시 메모리를 파티션(partition) 이라는 용도별 구획으로 나눠 쓴다. OTA의 핵심은 **앱 슬롯이 2개(이중 슬롯, A/B)**라는 점이다.

파티션 레이아웃

파티션 구성은 CSV로 정의하며, 기본 위치는 오프셋 0x8000(4KB 한 섹터)이다.

# Name,   Type, SubType,  Offset,   Size
nvs,      data, nvs,      0x9000,   0x6000
otadata,  data, ota,      0xf000,   0x2000
factory,  app,  factory,  0x10000,  1M
ota_0,    app,  ota_0,    ,         1M
ota_1,    app,  ota_1,    ,         1M

파티션	종류	역할
factory	app	공장 출하 초기 펌웨어 (선택적)
ota_0 / ota_1	app	서로 교대로 쓰이는 두 개의 앱 슬롯
otadata	data	다음에 어느 슬롯을 부팅할지 가리키는 포인터 + 롤백 상태 (두 섹터라 정전에도 하나는 생존)
nvs	data	Wi-Fi 자격증명·설정 등 비휘발성 저장. 앱을 갈아끼워도 값 보존 → 사용자 설정 유지

앱 파티션은 64KB 정렬이 필요하고, Name은 최대 16바이트다. 오프셋을 비워두면 자동 계산된다.

업데이트 절차 — “비활성 슬롯에 쓰고 포인터만 바꿔 재부팅”

sequenceDiagram
    autonumber
    participant App as 현재 앱(ota_0에서 실행 중)
    participant Flash as 비활성 슬롯(ota_1)
    participant OtaData as otadata 파티션
    participant Boot as 부트로더
    App->>Flash: esp_ota_begin() — 대상 슬롯 준비/erase
    loop 다운로드되는 청크마다
        App->>Flash: esp_ota_write() — 조각 기록
    end
    App->>Flash: esp_ota_end() — 이미지 무결성 검증
    App->>OtaData: esp_ota_set_boot_partition() — 다음 부팅=ota_1
    App->>Boot: 재부팅
    Boot->>OtaData: 어느 슬롯 부팅할지 확인
    Boot->>Flash: ota_1의 새 펌웨어 로드/실행

이 구조 덕분에 다운로드 도중 전원이 꺼져도 원래 슬롯(ota_0)은 그대로 멀쩡해서 기기가 죽지 않는다.

부트로더의 부팅 선택

**부트로더(bootloader)**는 전원이 켜질 때 가장 먼저 도는 코드로, 파티션 테이블과 otadata를 읽어 어느 앱을 실행할지 결정한다.

sequenceDiagram
    autonumber
    participant BL as 2차 부트로더
    participant PT as 파티션 테이블(0x8000)
    participant OD as otadata
    participant App as 선택된 앱 슬롯
    BL->>PT: 파티션 레이아웃 읽기
    BL->>OD: 어느 OTA 슬롯이 활성인지 확인
    alt otadata 비어있음/손상
        BL->>App: factory 앱으로 폴백
    else 유효한 OTA 슬롯 지정
        BL->>App: 지정된 ota_N 앱 로드/실행
    end

안전장치: Rollback과 Anti-Rollback

• Rollback(롤백): 새 펌웨어가 첫 부팅 시 자가진단에 실패하거나 부팅 직후 계속 죽으면, 부트로더가 자동으로 이전 정상 슬롯으로 되돌린다.
  • 새 앱은 첫 부팅에서 정상 확인 후 esp_ota_mark_app_valid_cancel_rollback()를 호출해 “나 정상”이라고 확정해야 한다.
  • 확정 없이 죽으면 상태가 PENDING_VERIFY → ABORTED로 넘어가며 되돌아간다.
• Anti-Rollback(다운그레이드 방지): eFuse(1회성 하드웨어 퓨즈)에 보안 버전을 기록해, 예전 취약 버전으로 되돌리는 공격을 차단한다. 32비트라 최대 32번의 anti-rollback 갱신 한도가 있다.

핵심: “알림 → 업데이트 버튼” UX는 어떻게 만드는가

원하는 경험의 관건은 **“기기가 새 버전을 어떻게 알아채느냐”**이고, 크게 두 방식이다.

1) Pull 방식 (폴링 + 버전 매니페스트)

기기가 주기적으로 서버의 작은 JSON(매니페스트)을 확인한다.

{ "version": "1.2.0", "url": "https://.../fw_1.2.0.bin", "sha256": "..." }

기기가 자기 버전과 비교해서 더 높으면 “업데이트 가능”으로 표시 → 사용자가 버튼을 누르면 그때 url을 받아 OTA 절차 실행. 서버 인프라가 단순(정적 파일 호스팅이면 충분)하지만, 확인 주기만큼 알림이 늦고 불필요한 트래픽이 있다.

2) Push 방식 (MQTT 상시 연결)

**MQTT(Message Queuing Telemetry Transport)**는 저전력·저대역폭 기기에 최적화된 발행/구독(pub/sub) 경량 메시징 프로토콜이다. 기기가 브로커에 상시 연결해 OTA 토픽을 구독하면, 서버가 새 버전을 publish하는 순간 즉시 기기에 도달한다.

sequenceDiagram
    autonumber
    participant D as 기기(구독자)
    participant B as 브로커
    participant S as 서버(발행자)
    D->>B: topic "device/123/ota" 구독 + 상시 연결
    Note over D,B: 평소엔 유휴, 연결만 유지
    S->>B: publish "v1.2.0 있음" to "device/123/ota"
    B-->>D: 즉시 메시지 전달 (알림!)

MQTT에서 꼭 알아야 할 4가지:

• Broker(브로커): 모든 메시지가 거쳐 가는 중앙 허브. 구독 관리·라우팅 담당 (예: Mosquitto, HiveMQ, AWS IoT Core).
• Topic(토픽): device/123/ota 같은 계층형 주소. 구독자는 관심 토픽만 받는다.
• QoS(전달 보증): 0 최대 1회(fire-and-forget), 1 최소 1회(중복 가능), 2 정확히 1회. OTA 알림엔 보통 QoS 1 이상.
• Retained / Last Will: 토픽의 마지막 메시지를 새 구독자에게 자동 전달(retained), 기기가 갑자기 끊기면 대신 보내는 유언 메시지(LWT)로 온라인 여부 감지.

목표(알림 + 버튼, USB 지양)에는 Push(MQTT) 또는 관리형 플랫폼이 가장 잘 맞는다. 알림만 먼저 주고 실제 다운로드/적용은 사용자가 버튼을 누른 이벤트에서 트리거하면, “알림 → 버튼 → 갱신” 흐름이 그대로 구현된다. 진행률·성공/실패도 같은 MQTT 채널로 되보고할 수 있다.

ESP32에서 OTA를 구현하는 선택지

방법	특징	알림/버튼 UX
esp_https_ota (ESP-IDF)	HTTPS로 이미지 받아 굽는 표준 컴포넌트. 서버·매니페스트 직접 구성	직접 구현
ESP RainMaker	Espressif 관리형 클라우드. esp_rmaker_ota_enable() 한 줄로 OTA + 폰 앱 + 알림 + 진행률 되보고 (AWS S3 기반, MQTT Force Push)	거의 완성형 제공
Arduino ArduinoOTA/Update	개발 단계 로컬 네트워크 업로드에 편리	배포용으론 부적합
esp32FOTA 라이브러리	JSON 매니페스트 기반 폴링 OTA를 간단히 구현	매니페스트로 구현
AWS IoT / Azure Device Update	대규모 fleet 캠페인·롤아웃 관리	플랫폼 제공

실전 파이프라인: 내가 개발 → 배포 → 보드가 스스로 설치

가장 중요한 전제 — “OTA 클라이언트는 이미 판 펌웨어 안에 있다”

OTA가 성립하려면, 처음 판매한 v1.0.0 펌웨어 안에 “업데이트를 확인·다운로드·설치하는 코드(OTA 클라이언트)“가 이미 들어 있어야 한다. 나중에 서버에 뭘 올려서 기기를 “실행”시키는 게 아니라, 기기 안의 그 코드가 스스로 서버를 확인하고 자기 자신을 갈아끼운다. 개발자가 원격에서 손대는 건 오직 “서버에 새 bin과 버전 정보를 올리는 것”뿐이다.

만약 v1.0.0에 OTA 클라이언트를 안 넣고 팔았다면, 그 보드들은 영영 USB로만 업데이트해야 한다. 그래서 첫 출하 때 OTA 클라이언트를 꼭 포함시키는 게 핵심이다.

전체 그림

sequenceDiagram
    autonumber
    actor Dev as 나(개발자)
    participant PIO as PlatformIO
    participant Host as 펌웨어 호스팅<br/>(S3/GitHub Release/서버)
    participant Broker as MQTT 브로커
    participant Board as ESP32(v1.0.0 실행 중)
    actor User as 최종 사용자(앱)

    Dev->>PIO: 버전 1.1.0으로 빌드
    PIO-->>Dev: firmware.bin 생성
    Dev->>Host: firmware.bin + manifest.json 업로드
    Dev->>Broker: "v1.1.0 나왔음" publish (선택)
    Broker-->>Board: OTA 토픽으로 알림 전달
    Board-->>User: 앱에 "업데이트 가능" 표시
    User->>Board: [업데이트] 버튼 클릭
    Board->>Host: manifest.json 읽고 firmware.bin 요청(HTTPS)
    Host-->>Board: bin 스트리밍
    Board->>Board: 비활성 슬롯(ota_1)에 기록+검증
    Board->>Board: 부팅 슬롯 전환 후 재부팅
    Board-->>User: v1.1.0로 업데이트 완료 보고

Step 1 — PlatformIO로 빌드하고 버전을 심는다

버전을 코드에 박아둬야 기기가 “내 버전 vs 서버 버전”을 비교할 수 있다. platformio.ini에서 빌드 플래그로 주입한다.

; platformio.ini
[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
build_flags = -DFW_VERSION="1.1.0"      ; 코드에서 이 값으로 자기 버전 인식
lib_deps = chrisjoyce911/esp32FOTA      ; OTA 클라이언트 라이브러리

빌드하면 산출물은 여기에 생긴다:

.pio/build/esp32dev/firmware.bin        ← 이 파일을 배포한다

Step 2 — bin을 “어딘가”에 올리고, 버전 매니페스트를 함께 둔다

firmware.bin을 기기가 HTTPS로 접근 가능한 곳에 올린다. 후보:

호스팅	성격
AWS S3 / 클라우드 스토리지	정적 파일, 확장성 좋음. RainMaker도 내부적으로 S3 사용
GitHub Releases	무료·간단. 릴리스에 bin 첨부하면 고정 URL 제공
직접 운영하는 nginx/서버	완전한 통제, 접근제어 자유

그리고 **버전 정보를 담은 작은 JSON(매니페스트)**을 같이 올린다. 기기는 bin이 아니라 이 JSON을 먼저 본다.

// manifest.json  (esp32FOTA 형식 예시)
{
  "type": "my-board",
  "version": "1.1.0",
  "host": "https://fw.example.com",
  "port": 443,
  "bin": "/firmware/my-board_1.1.0.bin"
}

Step 3 — 기기에 “새 버전 나왔다”고 알린다 (두 방법)

• Push (MQTT): 서버가 device/+/ota 토픽에 새 버전을 publish → 온라인 기기가 즉시 받아 앱에 배지 표시. 실시간성이 필요하면 이 방식.
• Pull (폴링): 기기가 부팅 시 + N시간마다 manifest.json을 GET해서 자기 버전보다 높으면 표시. 서버가 단순(정적 파일만)해서 시작하기 쉽다.

둘 다 “알림만” 하는 단계다. 실제 다운로드는 아직 시작하지 않는다 — 사용자가 버튼을 누르는 이벤트를 기다린다.

Step 4 — 버튼 클릭 → 기기가 스스로 다운·검증·설치·재부팅

사용자가 버튼을 누르면(앱이 MQTT/BLE/HTTP로 기기에 “업데이트 시작” 신호를 보냄), 기기 안의 OTA 클라이언트 코드가 나머지를 전부 자동으로 한다.

#include <esp32FOTA.hpp>
 
// 내 보드 타입, 현재 버전을 알려주며 OTA 클라이언트 생성
esp32FOTA fota("my-board", FW_VERSION);   // FW_VERSION = "1.1.0"
 
void setup() {
  fota.setManifestURL("https://fw.example.com/manifest.json");
  // (권장) 서명/인증서 검증 설정 — 위조 펌웨어 차단
}
 
// 사용자가 "업데이트" 버튼을 눌렀을 때 호출되는 함수
void onUpdateButtonPressed() {
  if (fota.execHTTPcheck()) {     // 매니페스트 버전 > 내 버전 ?
    fota.execOTA();               // 여기서 전부 자동 수행 ↓
    // 1) firmware.bin 스트리밍 다운로드
    // 2) 비활성 슬롯(ota_1)에 esp_ota_write로 기록
    // 3) 이미지 무결성/서명 검증
    // 4) otadata 포인터를 새 슬롯으로 변경
    // 5) esp_restart() — 재부팅
    // 재부팅 후 부트로더가 ota_1을 선택 → v1.1.0 실행
  }
}

”내가 실행 안 시켜도 자동으로 설치되는” 이유

핵심은 다운로드된 bin을 사람이 어디에 복사하거나 실행하는 개념이 아니라는 점이다. execOTA()가 받은 바이트를 곧바로 비활성 파티션(ota_1)에 굽고, otadata의 부팅 포인터만 바꾼 뒤 재부팅한다. 그러면 부트로더가 다음 부팅에서 새 슬롯을 자동으로 골라 실행한다. 즉:

• 다운로드 == 설치다. 받은 즉시 플래시에 기록되므로 별도 “설치 실행” 단계가 없다.
• 성공 확인 전까지 원래 슬롯(ota_0)은 살아 있어, 새 펌웨어가 부팅에 실패하면 자동 롤백된다.
• 개발자가 하는 일은 오직 **Step 1~3(빌드·업로드·알림)**뿐. Step 4의 물리적 설치는 전부 기기가 한다.

보안: 이미지 서명과 Secure Boot

OTA는 “원격에서 코드를 받아 실행”하는 통로라, 검증이 없으면 공격자가 악성 펌웨어를 밀어넣는 백도어가 된다. 그래서 두 겹의 방어가 필요하다.

• 전송 구간 암호화: HTTPS/TLS로 받아 중간자·DNS 스푸핑 방지 (RainMaker는 서버 인증서 검증 포함).
• 이미지 서명 검증 (Secure Boot): 서명된 이미지만 부팅을 허용한다. ESP32 Secure Boot v2는 RSA-3072(PSS) 공개키 암호로 부트로더·앱을 검증하고, 공개키의 지문을 eFuse에 각인해 위·변조를 막는다.

sequenceDiagram
    autonumber
    participant ROM as ROM 부트로더(변경불가)
    participant BL as 2차 부트로더
    participant App as 앱 이미지
    participant eF as eFuse(공개키 지문)
    ROM->>eF: 공개키 지문 읽기
    ROM->>BL: 2차 부트로더 서명 검증
    Note over ROM,BL: 실패 시 부팅 중단
    BL->>App: 앱 이미지 서명 검증 (부팅 시 + OTA 시)
    App-->>App: 검증 통과 → 실행

핵심은 OTA로 받은 새 이미지도 부팅 시점과 OTA 적용 시점 모두 같은 eFuse 공개키 지문으로 서명 검증을 통과해야 채택된다는 점이다. 즉 esp_ota_end()의 무결성 검증 위에, Secure Boot는 “정품 서명”까지 요구하는 상위 방어선이다.

• Secure Boot vs Flash Encryption: Secure Boot는 위조 코드 실행을 막고(무결성), Flash Encryption은 플래시 내용 읽기를 막는다(기밀성). 목적이 달라 함께 쓰기를 권장한다.
• Anti-Rollback: 취약한 구버전으로의 강제 다운그레이드를 차단(위 안전장치 절 참고).
• 일반적 위협: spoofing, tampering, replay, DoS, 권한 상승 → 검증 없는 OTA는 곧 백도어라는 관점이 필요하다.

참고 문서

• Wikipedia — Over-the-air update
• Wikipedia — MQTT
• ESP-IDF — OTA API Reference
• ESP-IDF — Partition Tables
• ESP-IDF — Secure Boot v2
• ESP RainMaker — OTA Firmware Upgrades
• esp32FOTA (GitHub)