Skip to content
오늘을살자
Go back

오늘의 테크 뉴스: SDV, 임베디드, 펌웨어, 반도체 (2026-06-23)

Edit page

기준일: 2026년 6월 23일
범위: 글로벌 / SDV, 반도체, 임베디드·펌웨어

오늘 흐름을 한 문장으로 줄이면 이렇다.

자동차 산업에서 반도체와 펌웨어는 더 이상 보이지 않는 하부 구조가 아니다. SDV, 중앙 컴퓨팅, OTA, 차량 데이터, AI 기능이 한 덩어리로 묶이면서 제품 경쟁력과 출시 속도를 좌우하는 병목으로 올라오고 있다.

특히 펌웨어 엔지니어 입장에서는 “드라이버를 잘 붙인다”에서 한 걸음 더 나아가야 한다. 부팅, 전력 상태, 보안 부트, 진단 로그, 업데이트 실패 복구, 네트워크 관측성까지 차량 수명주기 전체를 같이 봐야 한다.

오늘의 핵심 뉴스

1. 자동차 반도체가 제품 경쟁력의 병목으로 이동

자동차 반도체는 예전처럼 ECU별 BOM을 채우는 부품으로만 보기 어렵다. 전동화, SDV, 고성능 컴퓨팅, 차량 내 AI 요구가 커지면서 SoC, MCU, 메모리, 전력반도체, 보안 IC 선택이 차량 플랫폼 전략과 직접 연결되고 있다.

S&P Global의 2026년 자동차 반도체 시장 분석은 차량이 소프트웨어 정의·컴퓨팅 집약형 구조로 바뀌면서 반도체가 전략적 제약 조건으로 올라오고 있다고 본다. 이 분석에서는 자동차 반도체 시장이 2025년 약 900억 달러에서 2031년 약 1,390억 달러 규모로 커질 수 있다고 보고, 특히 메모리 수요가 새로운 병목으로 드러날 수 있다고 짚는다.

뭐가 달라졌나

기존에는 기능별 ECU에 맞춰 MCU, 센서, 전력반도체를 배치하는 성격이 강했다. 이제는 중앙 컴퓨팅, zonal architecture, 고속 Ethernet, OTA, AI inference 요구가 함께 묶인다.

그래서 “어떤 칩을 쓰느냐”는 단순 원가 문제가 아니다. 부팅 시간, 메모리 대역폭, 보안 기능, OTA 구조, 진단 데이터 수집 범위, 장기 공급 가능성까지 한 번에 따라온다.

펌웨어 관점에서 볼 점

펌웨어는 단일 보드 bring-up이나 peripheral driver 개발에만 머물기 어렵다.

체크해야 할 범위가 넓어진다.

SoC / MCU 선택

Boot chain / secure boot

Memory bandwidth / latency

Power state transition

OTA update / rollback

Diagnostics / logging / field recovery

현장에서 중요한 질문도 바뀐다.

2. SDV 아키텍처는 domain/zonal/centralized 구조로 계속 이동

최근 공개된 SDV 아키텍처 리뷰 논문은 SDV를 단순히 “자동차에 소프트웨어를 많이 넣는 변화”로 보지 않는다. 분산 ECU 중심 구조에서 domain, zonal, centralized computing 구조로 이동하고, 그 위에 service-oriented architecture, middleware, OTA, cloud integration이 올라가는 변화로 설명한다.

뭐가 달라졌나

기능별 ECU에 로직을 고정 배치하던 방식은 점점 한계가 커진다. SDV에서는 차량 기능을 서비스, 미들웨어, 중앙 컴퓨팅 위에 배치하고 OTA로 계속 바꾸는 구조가 중요해진다.

이 변화는 하드웨어 수량을 줄이는 문제만이 아니다. 기능이 어느 ECU에 박혀 있는지가 아니라, 어떤 서비스가 어떤 실행 환경에서 어떤 안전 등급으로 동작하는지가 더 중요해진다.

펌웨어 관점에서 볼 점

펌웨어 엔지니어에게 필요한 경계 지식이 늘어난다.

예전에는 “내 MCU 코드가 정상 동작하는가”가 중심이었다. 이제는 “내 펌웨어가 차량 전체 업데이트, 진단, 안전 구조 안에서 어떻게 관측되고 복구되는가”까지 같이 봐야 한다.

3. RISC-V가 자동차 MCU/SDV 선택지로 부상

RISC-V는 더 이상 연구용 ISA나 저가 임베디드용 선택지로만 보기 어렵다. Infineon은 RISC-V를 SDV에 필요한 개방형·확장형 컴퓨팅 기반으로 설명하고 있고, 자동차용 생태계 구축을 강조하고 있다.

최근 공개된 RISC-V functional safety 분석 논문도 비슷한 방향을 보여준다. 핵심은 “RISC-V가 자동차에 쓸 수 있느냐”보다 “자동차 안전 인증과 보안 요구를 만족하는 플랫폼으로 어떻게 만들 것인가”에 가깝다.

뭐가 달라졌나

Arm Cortex 계열을 기본 전제로 두던 프로젝트에서도 앞으로는 RISC-V 기반 MCU나 safety island를 검토할 가능성이 커진다. 특히 SDV에서는 장기 수명주기, 확장성, 공급망 선택권, custom extension 같은 요소가 같이 논의된다.

하지만 ISA가 열려 있다는 것만으로 자동차 프로젝트에 바로 유리해지는 것은 아니다. ASIL 대응 프로젝트에서는 코어 성능보다 certification package, diagnostic coverage, toolchain qualification, safety manual, fault injection 환경이 더 큰 비용이 될 수 있다.

펌웨어 관점에서 볼 점

RISC-V 프로젝트를 만나면 아래 항목을 초기에 확인해야 한다.

Toolchain qualification
Compiler behavior
Interrupt / exception model
Debug visibility
Custom extension 사용 여부
Lockstep / safety island 구성
Secure debug 정책
Fault injection / diagnostic coverage

즉, “RISC-V라서 좋다”가 아니라 “이 플랫폼으로 safety case를 끝까지 닫을 수 있는가”가 핵심이다.

4. OTA와 hotpatching은 속도와 안전 검증 사이의 싸움

SDV에서 OTA는 이미 기본 전제에 가깝다. 이제 질문은 “업데이트가 가능한가”에서 “얼마나 작게, 빠르게, 안전하게, 실패 없이 패치할 수 있는가”로 바뀌고 있다.

최근 공개된 Patchlings 연구는 자동차 MCU의 flash-based XIP 구조를 고려한 hotpatching 접근을 다룬다. 이 연구는 기존 자동차 업데이트가 안전 기준과 재검증 부담 때문에 오래 걸릴 수 있고, 일반적인 임베디드 hotpatching 기법이 자동차 요구를 충분히 만족하지 못할 수 있다고 본다.

뭐가 달라졌나

OTA는 앱 업데이트와 다르다. 특히 safety-critical ECU에서는 작은 코드 변경도 timing, memory layout, watchdog, interrupt latency, safety analysis에 영향을 줄 수 있다.

그래서 hotpatching이 가능하더라도 다음 질문이 따라온다.

펌웨어 관점에서 볼 점

부트로더와 OTA 설계는 이제 후순위 유틸리티가 아니다. 제품 출시 후 대응 속도를 좌우하는 핵심 인프라다.

실무적으로는 이 조합을 같이 봐야 한다.

Secure boot
A/B partition or fallback image
Signature verification
Rollback policy
Flash wear management
Watchdog coordination
Post-update self-test
Diagnostic log upload

업데이트 실패를 “일어나면 안 되는 예외”로 보지 말고, 반드시 일어날 수 있는 정상 시나리오로 설계해야 한다.

5. 차량 데이터·AI 우선순위는 내부 운영 효율로 이동

차량 데이터의 방향도 조금 더 현실적으로 바뀌고 있다. 초기에는 “차량 데이터를 외부에 판매해 수익화하자”는 이야기가 많았다. 하지만 최근 흐름은 품질 관리, 정비, 고장 예측, OTA 타기팅, 고객 지원처럼 내부 운영 효율에 먼저 쓰는 쪽이 더 강해 보인다.

Sonatus의 2026 SDV Survey는 자동차 업계 관계자 559명을 대상으로 SDV 우선순위를 조사했다. 이 자료에서는 predictive maintenance, containerized application, AI-driven solution 같은 항목이 주요 관심사로 제시된다.

뭐가 달라졌나

데이터 수익화는 말은 쉽지만 현실은 복잡하다. 개인정보, 국가별 규제, 데이터 품질, 고객 동의, OEM과 공급사 간 권한 문제가 얽힌다.

반면 내부 운영 효율은 효과가 더 직접적이다.

펌웨어 관점에서 볼 점

AI 기반 predictive maintenance가 의미 있으려면 원천 로그가 좋아야 한다. 단순히 DTC만 남기는 수준으로는 부족하다.

필드 로그에는 최소한 이런 맥락이 필요하다.

timestamp
reset reason
power state
network state
sensor health
firmware version
OTA history
diagnostic session state
recent fault transition

데이터 품질이 낮으면 AI 모델은 그럴듯한 추측만 한다. 결국 좋은 AI 기능의 출발점은 현장에서 신뢰할 수 있는 firmware telemetry다.

오늘의 실무 체크포인트

가장 먼저 볼 것: OTA·진단·로그 설계

SDV 전환에서 펌웨어가 직접 기여할 수 있는 영역은 명확하다.

새 프로젝트라면 기능 구현보다 먼저 “나중에 문제가 났을 때 이 상태를 볼 수 있는가”를 물어봐야 한다.

다음으로 볼 것: RISC-V와 mixed-criticality 대응

Arm 기반 경험만으로 충분하지 않은 프로젝트가 늘 수 있다. RISC-V toolchain, safety manual, debug, RTOS 포팅 이슈를 천천히 추적할 가치가 있다.

또 RTOS 하나만 보는 대신 Linux, hypervisor, safety island, service-oriented communication이 섞인 구조를 이해해야 한다.

업무 영향 요약

앞으로 펌웨어 엔지니어의 핵심 가치는 “레지스터를 제어하는 코드”만으로 설명되기 어렵다.

더 중요한 가치는 다음에 가깝다.

차량 수명주기 전체에서 안전하게 업데이트되고, 진단 가능하며, 보안적으로 검증 가능한 저수준 소프트웨어를 설계하는 능력.

다음 글감 후보

이 흐름은 하루짜리 뉴스보다 연속 글로 풀어야 더 잘 보인다. 이어서 다뤄볼 만한 주제는 이렇다.

참고한 자료

한 줄 요약

SDV 시대의 펌웨어 가치는 코드를 한 번 잘 올리는 능력보다, 차량 수명주기 전체에서 업데이트·진단·복구·보안을 안전하게 유지하는 설계 능력으로 이동하고 있다.


Edit page
Share this post on:

Next Post
lwIP RAW TCP에서 close가 가끔 실패한다: tcp_close()의 ERR_MEM은 free RAM보다 송신 잔여 상태를 먼저 봐야 한다