펌웨어 업데이트와 현장 증거 — 부트로더·A/B 롤백·서명·전원 차단·호환성·추적성

개념

업데이트는 가장 위험한 기능이다

웹 서비스는 잘못 배포해도 이전 버전으로 되돌리면 된다. 임베디드 장치는 업데이트 자체가 실패할 수 있고, 실패한 장치는 부팅조차 못 하는 벽돌(brick)이 된다. 현장의 장치 수만 대 중 1%만 벽돌이 되어도 수백 번의 방문 수리나 회수가 필요하다. 그래서 업데이트 기능은 제품의 다른 어떤 기능보다 강하게 시험한다. 레슨 1의 층 그림에서 부트로더가 따로 있던 이유가 이것이다.

부트로더가 하는 일

전원 켬
  │
  ▼
[부트로더]  ← 스스로는 거의 업데이트하지 않는, 가장 작고 가장 오래 사는 코드
  ├─ 1. 하드웨어 최소 초기화
  ├─ 2. 업데이트 요청 확인(플래그, 버튼, 통신 명령)
  ├─ 3. 응용 이미지 무결성 검사(CRC·해시)
  ├─ 4. 서명 검증(보안 부팅)
  ├─ 5. 부팅할 슬롯 선택(A/B)
  └─ 6. 응용으로 점프 ── 실패 시 → 복구 모드 / 다른 슬롯

부트로더 시험의 핵심은 모든 실패 경로가 복구 가능한 상태로 끝나는가 다.

A/B 파티션과 롤백

플래시에 이미지 슬롯을 두 개 두면, 동작 중인 A를 건드리지 않고 B에 새 이미지를 쓴 뒤 다음 부팅부터 B를 쓰도록 전환 할 수 있다. 새 이미지에 문제가 있으면 A로 돌아간다.

상태 흐름
  A 활성 ─ B에 새 이미지 기록 ─ B 검증 ─ "B를 시험 부팅" 표시 ─ 재부팅
       ─ B 부팅 ─ 자가 확인 통과 → "B 확정" 표시 (이제 B 활성)
                 └ 자가 확인 실패 / N회 부팅 실패 / 확정 전 워치독 리셋
                                  → A로 롤백

시험 포인트는 이렇다.

• 확정 조건 — 새 이미지가 무엇을 확인한 뒤 스스로 확정하는가(통신 정상, 센서 정상, 일정 시간 동작). 확정이 너무 빠르면 결함 있는 이미지가 확정되고, 확정 조건이 없으면 롤백이 동작하지 않는다
• 롤백 발동 — 부팅 직후 크래시, 부팅 루프, 확정 전 워치독 리셋 각각에서 A로 돌아가는가
• 롤백 방지(anti-rollback) — 보안 결함이 고쳐진 버전에서 취약한 이전 버전으로 공격자가 되돌리는 것 은 막아야 한다. 버전 카운터가 있으면 기능 롤백(방금 올린 이미지 실패)과 보안 롤백 금지가 충돌하지 않는지 확인한다
• 데이터 호환성 — B가 설정 형식을 바꿔 저장한 뒤 A로 롤백하면 A가 새 형식을 읽을 수 있는가. 가장 자주 빠지는 시험이다

A/B를 쓰지 않고 슬롯 하나에 덮어쓰는 설계도 있다. 이 경우 쓰기 도중 실패하면 부트로더의 복구 모드만이 유일한 안전망이므로, 복구 모드 시험의 비중이 훨씬 커진다.

서명과 무결성

두 가지는 다른 질문에 답한다.

CRC는 우연한 오류를 잡지만 의도적 변조는 막지 못한다. 공격자는 이미지를 바꾼 뒤 CRC도 다시 계산하면 된다. 그래서 보안이 요구되는 제품은 서명 검증이 필수다. 시험은 한 바이트 변조, 서명 부분 변조, 다른 키로 서명, 서명 없는 이미지, 잘린 이미지, 너무 큰 이미지, 헤더의 길이 값 조작(버퍼 넘침 유도)까지 포함한다. 마지막 두 개는 부트로더의 입력 검증 시험이다.

업데이트 모든 단계에서의 전원 차단

레슨 6의 "플래시 쓰기 중 차단"을 업데이트 전 과정으로 확장한다. 업데이트를 단계로 나누고 각 단계에서 전원을 끊는다.

단계                          차단 후 기대
1. 다운로드 중(수신 버퍼)       기존 이미지로 정상 부팅, 다운로드 재시작 가능
2. 비활성 슬롯 지우기 중        기존 이미지로 정상 부팅
3. 비활성 슬롯 쓰기 중          기존 이미지로 정상 부팅, 반쯤 쓴 슬롯은 무효 처리
4. 새 이미지 검증 중            기존 이미지로 정상 부팅
5. 부팅 슬롯 전환 표시 기록 중   기존 또는 새 이미지 중 하나로 부팅, 절대 벽돌 아님
6. 새 이미지 첫 부팅 중         새 이미지 재시도 또는 기존으로 롤백
7. 확정 표시 기록 중            어느 쪽이든 정상 부팅
8. 설정 마이그레이션 중          이전 또는 새 형식 중 하나로 일관되게

5번과 8번처럼 한 번의 작은 기록 이 상태를 바꾸는 순간이 가장 위험하다. 레슨 6처럼 차단 시점을 잘게 옮기며 자동으로 수백~수천 번 반복한다. 업데이트 한 번에 수 분이 걸리면 이 시험은 며칠이 걸리므로, 시험 일정에 미리 넣어야 한다. 전원 차단 외에 통신 끊김(다운로드 중 연결 종료), 저전력(배터리 잔량이 낮을 때 업데이트 시작 거부)도 같은 표로 관리한다.

호환성 매트릭스

현장에는 여러 하드웨어 리비전, 여러 펌웨어 버전, 여러 설정이 섞여 있다. 새 펌웨어가 모든 조합에서 동작한다고 가정할 수 없다.

모든 조합을 시험하면 폭발한다. 모듈 3 레슨 5의 페어와이즈 조합처럼 줄이되, 현장 보급 대수가 많은 조합과 가장 오래된 시작 버전 은 반드시 포함한다. "지원 안 함"과 "롤백 금지"도 결과다. 그 조합에서 업데이트를 시도하면 거부하고 이유를 기록하는지 를 시험한다. 부품 변경으로 보드 리비전이 바뀌면 펌웨어가 하드웨어 리비전을 식별하는 방법(ID 핀, EEPROM 값)부터 확인한다.

OTA와 규제

무선 업데이트(OTA)는 위의 모든 시험에 네트워크 조건(모듈 29)과 보안이 더해진다. 차량은 UNECE R156(소프트웨어 업데이트와 소프트웨어 업데이트 관리 시스템)이 형식 승인 조건으로 소프트웨어 업데이트 관리 체계를 요구한다. 테스터에게 중요한 것은 업데이트마다 어떤 차량에 어떤 소프트웨어 버전이 들어가는지 식별하고, 업데이트가 안전하게 수행됨을 보여주는 기록 이 요구된다는 점이다. 이 레슨 뒷부분의 추적성이 곧 그 기록이다.

현장 로그 — 저장 공간이 모자랄 때

장치에는 수십 KB의 로그 공간밖에 없는 경우가 흔하다. 그래서 무엇을 어떻게 남길지 설계한다.

• 링 버퍼 — 고정 크기 영역을 돌려 쓰며 가장 오래된 기록을 덮는다. 최근 이벤트는 항상 남는다. 시험: 버퍼가 가득 찬 뒤 덮어쓰기 경계, 전원 차단 시 마지막 기록의 보존, 쓰기 빈도와 플래시 수명 (레슨 1의 EEPROM 수명 계산)
• 크래시 덤프 — 예외·워치독 리셋 직전의 레지스터·스택·태스크 정보를 전용 영역(리셋에도 지워지지 않는 RAM 영역이나 플래시)에 남긴다. 시험: 의도적 예외를 일으킨 뒤 다음 부팅에서 덤프가 읽히는가, 덤프 기록 중 전원 차단 시 부팅이 멀쩡한가
• 리셋 원인과 카운터 — 리셋 원인별 누적 횟수, 가동 시간. 가장 싸고 가장 쓸모 있는 현장 증거다
• 이벤트 우선순위 — 공간이 모자라면 정보성 로그를 먼저 버리고 고장·안전 이벤트는 별도 영역에 보존한다
• 타임스탬프 — 실시간 시계가 없는 장치는 가동 시간과 부팅 횟수로 순서를 복원할 수 있게 한다

로그 형식에는 펌웨어 빌드 해시 를 반드시 넣는다. 현장에서 올라온 크래시 덤프의 주소를 해석하려면 정확히 같은 빌드의 심볼 파일이 필요하기 때문이다.

추적성 — 요구사항에서 보드 시리얼까지

감사자나 고객이 "이 요구사항은 이 장치에서 검증되었는가"라고 물으면 한 줄로 답할 수 있어야 한다.

요구사항 SWR-0412  "설정 저장 중 전원 차단 시 이전 또는 새 설정으로 부팅"
   │
   ├─ 시험 케이스   TC-FI-P-07 (장애 주입 매트릭스 FI-P-07)
   │
   ├─ 실행 기록     2026-09-18 22:14, HIL-02, 1,200회 반복, 합격
   │
   ├─ 펌웨어       FW 2.4.1, 빌드 해시 7f3a9c1, 빌드 서버 산출물 ID
   │
   ├─ 하드웨어      보드 Rev C, S/N B0412, 전원 장치 교정 만료일 2027-03
   │
   └─ 증거 파일     로그, 결과 CSV, 오실로스코프 캡처(레슨 4 형식)

핵심은 버전 이름이 아니라 빌드 해시 로 잇는 것이다. "2.4.1"은 두 번 빌드될 수 있지만 해시는 하나다. 보드 시리얼은 하드웨어 리비전과 개별 보드의 특이성(한 보드만 이상한 경우)을 추적하게 한다. 계측 장비의 교정 상태도 증거의 일부다. 교정이 만료된 장비의 측정값은 심사에서 문제가 된다.

감사를 위한 증거 관리

모듈 35 레슨 6과 7에서 본 시험성적서와 A-SPICE 평가 준비를 임베디드 증거로 옮기면 이렇게 정리된다.

• 불변 보관 — 결과 파일은 시험 직후 수정 불가능한 저장소에 해시와 함께 보관한다
• 재현 가능성 — 펌웨어 이미지, 시험 스크립트 버전, 플랜트 모델 버전, 장비 구성이 결과와 한 묶음이다
• 양방향 추적 — 요구사항에서 결과로, 결과에서 요구사항으로 모두 찾을 수 있다
• 실패 이력 보존 — 불합격 결과와 그 결함, 수정 빌드, 재시험 결과를 지우지 않는다. 합격만 남은 기록은 오히려 의심받는다
• 보존 기간 — 제품 수명과 규제 요구(자동차·의료기기는 10년 이상인 경우가 많다)에 맞춘다

실무에서 왜 필요한가

현장 장치의 업데이트 실패는 제품 전체의 신뢰를 한 번에 무너뜨린다. 수만 대를 벽돌로 만든 업데이트는 기술 결함을 넘어 회수 비용과 기사 제목이 된다. 동시에 현장 로그와 추적성은 출시 뒤의 유일한 시험 환경 이다. 현장에서 올라온 크래시 덤프를 빌드 해시로 정확한 코드에 연결할 수 있어야 재현 불가 결함을 고칠 수 있다. 업데이트·롤백·전원 차단을 체계적으로 시험하고, 증거를 추적 가능한 형태로 남기는 테스터는 개발 단계뿐 아니라 제품 수명 전체의 품질을 책임지는 역할을 한다.

채용시장에서의 위치

IoT·자동차·가전 분야의 펌웨어 검증 공고에서 "FOTA/OTA 시험", "부트로더 검증", "양산 소프트웨어 형상 관리" 경험이 자주 우대된다. 차량 분야는 UNECE R155·R156 대응으로 소프트웨어 업데이트 관리와 증거 체계를 이해하는 인력 수요가 커졌다. 면접에서 "업데이트 중 전원이 끊기면 어떻게 되는가, 어떻게 시험하나"라는 질문에 단계별 차단 표 로 답하고, "현장 결함을 어떻게 추적하나"에 빌드 해시와 보드 시리얼로 잇는 추적 사슬 을 설명할 수 있으면 이 모듈 전체를 소화했다는 신호가 된다.

실습 과제

과제 1 — 업데이트 단계별 차단 시험 (20분)

스마트 온도조절기(A/B 슬롯, Wi-Fi OTA, 설정 형식이 v2에서 v3로 바뀌는 업데이트)를 가정한다. 본문 여덟 단계 표를 이 제품에 맞게 다시 쓰고, 각 단계의 차단 시점 선택 방법, 반복 횟수, 판정 기준을 적는다. 설정 형식 변경 뒤 롤백 시나리오를 별도 케이스로 추가한다.

과제 2 — 링 버퍼 로그 설계 검토 (10분)

로그 영역 64KB, 레코드 32바이트, 플래시 섹터 4KB·쓰기 수명 1만 회, 평균 초당 0.5개 레코드가 생긴다. 로그가 몇 시간 분량을 담는지, 플래시 수명이 몇 년인지 계산하고, 제품 수명 10년을 만족하지 못하면 어떤 설계 변경(이벤트 우선순위, 레코드 축소, 영역 확대)을 제안할지 적는다.

과제 3 — 추적 사슬 한 줄 (15분)

레슨 6 과제 1에서 만든 워치독 시험 하나를 골라, 본문 추적성 그림 형식으로 요구사항 ID부터 증거 파일까지 한 사슬을 완성한다. 각 항목이 어느 시스템(요구사항 관리 도구, 시험 관리 도구, 빌드 서버, 자산 관리)에서 오는지도 적는다.

자가 체크리스트

• 부트로더의 역할과 모든 실패 경로가 복구 가능해야 한다는 시험 원칙을 설명할 수 있다
• A/B 파티션의 확정·롤백 흐름과 롤백 방지, 데이터 호환성 시험을 설명할 수 있다
• 무결성 검사와 서명 검증의 차이, 이미지 변조 시험 항목을 말할 수 있다
• 업데이트를 단계로 나눠 각 단계의 전원 차단 기대 결과를 쓸 수 있다
• 하드웨어 리비전·펌웨어·설정 호환성 매트릭스를 만들고 줄이는 기준을 말할 수 있다
• 링 버퍼·크래시 덤프·리셋 원인 카운터로 현장 로그를 설계하고 시험할 수 있다
• 요구사항에서 시험·빌드 해시·보드 시리얼·증거 파일까지 추적 사슬을 만들 수 있다

흔한 실수

• 정상 업데이트 경로만 시험한다. 업데이트 시험의 가치는 실패 경로에 있다. 단계별 전원 차단, 통신 끊김, 변조 이미지를 모두 넣는다.
• CRC를 보안 장치로 본다. CRC는 우연한 오류만 잡는다. 변조 방지는 서명 검증이 한다.
• 롤백 뒤 설정 호환성을 확인하지 않는다. 새 버전이 바꾼 설정 형식을 이전 버전이 못 읽으면 롤백이 또 다른 고장이 된다.
• 버전 이름으로 추적한다. 같은 이름의 빌드가 여러 번 나올 수 있다. 빌드 해시로 잇는다.
• 현장 로그에 빌드 정보를 넣지 않는다. 크래시 덤프를 해석할 심볼 파일을 찾을 수 없게 된다.
• 불합격 기록을 정리하며 지운다. 실패와 수정, 재시험의 이력이 증거의 신뢰를 만든다.
• 장비 교정 상태를 증거에서 뺀다. 교정이 만료된 장비의 측정값은 감사에서 인정받지 못할 수 있다.

참고 자료

• UNECE — UN Regulation No. 156, Software update and software update management system — 차량 소프트웨어 업데이트 관리 체계
• MCUboot 문서 — 오픈소스 보안 부트로더의 슬롯 교체·롤백·서명 검증 설계
• ISO/SAE 21434 — Road vehicles, Cybersecurity engineering(업데이트 보안과 연결)
• ISO 26262-6:2018 — Product development at the software level (ISO)
• 레슨 s2-m35-l06 — 도구 신뢰 수준과 기능안전 시험성적서
• 레슨 s2-m35-l07 — Automotive SPICE 4.0 평가 대응과 양방향 추적
• 레슨 s5-m46-l06 — 장애 주입과 플래시 쓰기 중 전원 차단
• 레슨 s5-m46-l01 — EEPROM·플래시 수명 계산