결론 요약

1. Zephyr RTOS 4.4는 2026년 4월 공개된 최신 안정판으로, Zephyr SDK 1.0과 C17을 기본 개발 기준으로 올렸습니다.
2. WireGuard·Wi-Fi Direct·실험적 부하 기반 CPU 주파수 조절·Cortex-M 문맥 전환 개선이 더해져 연결성과 전력 효율을 함께 다듬었습니다.
3. Python 3.12, Devicetree와 네트워크 API 변경, Mbed TLS 4.1 전환이 포함되므로 제품 코드는 릴리스 노트보다 마이그레이션 가이드를 먼저 확인해야 합니다.

Zephyr RTOS 4.4, 임베디드 개발 현장에서 무엇이 달라질까

새 RTOS 버전이 나왔다는 소식을 들으면 가장 먼저 어떤 생각이 드시나요? 새 기능보다 "지금 잘 돌아가는 보드가 또 깨지는 건 아닐까"라는 걱정이 앞서는 분도 많을 겁니다. 임베디드 소프트웨어는 서버 애플리케이션처럼 문제가 생기면 곧바로 이전 컨테이너로 되돌리기 어렵습니다. 부트로더, 보드 설정, 드라이버와 인증 범위까지 서로 물려 있기 때문입니다.

2026년 4월 14일 공개된 Zephyr RTOS 4.4는 그런 현실을 염두에 두고 살펴볼 만한 릴리스입니다. 화려한 기능만 늘린 것이 아니라 도구 체계, C 언어 기준, 네트워크 보안, 메모리 오류 탐지와 성능 측정 방법을 함께 손봤습니다. Zephyr 프로젝트가 매년 두 차례 주요 버전을 내는 새 주기로 전환한 뒤 처음 나온 릴리스라는 의미도 있습니다.

이번 글에서는 기능 목록을 차례로 옮기기보다 실제 제품 개발자가 판단해야 할 질문을 중심으로 살펴보겠습니다. 지금 3.7 LTS에 머물러야 하는지, 4.3 기반 프로젝트를 올린다면 무엇부터 확인할지, WireGuard 같은 새 기능을 어느 수준까지 믿어도 되는지 하나씩 짚어보겠습니다.

Zephyr RTOS 4.4가 바꾼 개발 기준부터 살펴보기

Zephyr 4.4는 2027년 4월까지 지원되는 최신 안정판입니다. 반면 3.7은 2029년까지 지원되는 LTS입니다. 숫자만 보면 4.4로 바로 옮기는 것이 자연스러워 보이지만, 제품 수명과 인증 일정까지 고려하면 답은 달라질 수 있습니다. 새 기능이 필요한 신규 제품이라면 4.4가 매력적이고, 이미 양산 중이며 장기 보안 수정이 더 중요한 제품이라면 3.7 LTS 유지가 합리적일 수 있습니다.

이번 버전부터 Zephyr SDK 1.0이 기준 도구 체계로 자리 잡았습니다. GNU 도구 모음이 갱신됐고 Clang/LLVM 지원이 실험적으로 들어왔으며, Windows·Linux·macOS용 QEMU와 OpenOCD도 SDK에 함께 제공됩니다. 개발자마다 제각각 설치한 컴파일러와 디버거 버전 때문에 재현이 어려웠던 팀이라면 CI와 로컬 개발 환경의 기준점을 맞추기 쉬워진 셈입니다.

C17 기본 전환은 문법보다 빌드 재현성의 문제입니다

최소 C 표준도 C17로 올라갔습니다. C17 자체는 대규모 문법을 새로 추가한 버전이 아니지만, Zephyr가 C11 계열 기능을 일관되게 활용할 수 있는 기반을 마련했다는 점이 중요합니다. 정적 단언이나 _Generic 같은 기능을 공통 기준으로 쓸 수 있고, 오래된 컴파일러를 계속 배려하느라 생기던 조건부 코드도 줄일 수 있습니다.

다만 사내 BSP나 칩 공급사 SDK가 낡은 도구 체인에 묶여 있다면 이야기가 다릅니다. CONFIG_STD_C99나 CONFIG_STD_C11로 잠시 이전 기준을 강제할 수 있지만 이 선택지는 이미 폐기 예정입니다. "일단 빌드만 통과시키자"며 예외 설정을 장기간 남겨두면 다음 업그레이드 때 더 큰 비용으로 돌아옵니다. 먼저 CI 이미지에서 SDK 1.0과 Python 3.12를 고정하고, 애플리케이션보다 외부 모듈과 보드 지원 패키지를 먼저 컴파일해 보는 순서가 안전합니다.

WireGuard와 Wi-Fi Direct가 넓힌 임베디드 네트워크 경계

Zephyr RTOS 4.4에서 가장 눈에 띄는 변화는 네트워크입니다. Wi-Fi 관리 스택에 Wi-Fi Direct가 추가돼 기존 액세스 포인트 없이 장치끼리 탐색하고 직접 연결할 수 있습니다. 현장에서 센서와 게이트웨이를 처음 연결하거나, 네트워크 인프라가 없는 장소에서 장비끼리 데이터를 옮기는 상황을 떠올리면 쓰임새가 분명합니다. WPA2-PSK와 WPA3-SAE 같은 보안 방식도 지원합니다.

WireGuard 지원도 들어왔습니다. 장치 자체에서 암호화 터널을 만들 수 있으니 원격 유지보수 포트를 인터넷에 그대로 노출하지 않고 관리망을 구성할 길이 생겼습니다. 공장이나 건물에 설치된 게이트웨이를 중앙 관제망과 연결할 때 별도 Linux 장비가 맡던 일부 역할을 MCU급 장치 가까이 가져올 수 있습니다.

그렇다고 CONFIG_WIREGUARD를 켜는 순간 제품 보안이 완성되는 것은 아닙니다. VPN은 통신 경로를 보호하지만 키를 어떻게 주입하고 갱신할지, 장치가 탈취됐을 때 어떻게 폐기할지까지 대신 결정해 주지는 않습니다. 난수 품질, 부팅 신뢰 체인, 안전한 저장소와 현장 복구 절차가 함께 설계돼야 합니다. 암호화 처리로 늘어나는 RAM·플래시와 지연 시간도 실제 목표 보드에서 측정해야 합니다.

연결 기능은 실패 경로까지 시험해야 제품 기능이 됩니다

Wi-Fi Direct나 WireGuard 데모가 한 번 연결되는 것과 수천 대의 현장 장치가 몇 년간 운영되는 것은 전혀 다른 문제입니다. 상대 장치가 갑자기 사라졌을 때 세션이 정리되는지, 키 갱신 도중 전원이 끊기면 다시 접속할 수 있는지, 터널이 내려갔을 때 평문 경로로 우회하지 않는지 확인해야 합니다. 네트워크 장애를 정상 동작의 일부로 취급하고 시험 항목에 넣는 편이 좋습니다.

Zephyr 4.4는 USB 호스트 프레임워크와 UVC 카메라 지원도 확장했습니다. Wi-Fi Direct로 연결된 장치가 카메라 데이터를 받고 WireGuard 터널로 전송하는 구성을 상상할 수 있지만, 여러 실험 기능을 한꺼번에 제품 핵심 경로에 넣는 것은 신중해야 합니다. 공식 문서에서 실험적이라고 표시된 기능은 API 안정성과 드라이버 검증 범위가 정식 기능과 다를 수 있으므로, 양산 일정과 분리된 기술 검증 단계에서 먼저 다루세요.

Zephyr 4.4의 힙 강화와 개발 도구가 실무에 주는 이점

임베디드 메모리 오류가 까다로운 이유는 사고 지점과 증상 지점이 멀리 떨어질 수 있기 때문입니다. 버퍼를 몇 바이트 넘겨 쓴 뒤 한참 지나 전혀 다른 태스크에서 할당기가 망가지는 상황이 대표적입니다. Zephyr RTOS 4.4는 CONFIG_SYS_HEAP_HARDENING으로 단계별 힙 검증을 켤 수 있게 했습니다. 기본 수준에서는 이중 해제와 오버플로 같은 오류를 낮은 비용으로 찾고, 높은 수준에서는 할당과 해제 때마다 힙 구조 전체를 더 엄격하게 검사할 수 있습니다.

개발 빌드에서는 강한 검사를 켜고 출시 빌드에서는 측정된 오버헤드에 맞춰 수준을 낮추는 식으로 활용할 수 있습니다. 중요한 점은 설정을 켰다는 사실보다 오류가 발생했을 때 로그와 크래시 덤프가 남도록 연결하는 것입니다. 탐지 직후 재부팅만 해버리면 현장에서는 "가끔 리셋되는 장비"로 보일 뿐 원인을 좁히기 어렵습니다.

C 코드에 범위 기반 정리 도우미가 추가된 점도 반갑습니다. 뮤텍스 해제, 메모리 반환, 파일 닫기처럼 빠뜨리기 쉬운 정리 작업을 범위가 끝날 때 자동으로 실행하도록 구성할 수 있습니다. C++의 RAII나 다른 언어의 defer와 비슷한 역할입니다. 조기 반환과 오류 분기가 많은 드라이버 코드에서는 중복된 goto cleanup을 줄이는 데 도움이 됩니다. 다만 기존 코드를 한 번에 바꾸기보다 새 모듈부터 팀 규칙과 정적 분석 기준을 맞춰 도입하는 편이 리뷰하기 쉽습니다.

빌드 대시보드와 벤치마크는 감각을 수치로 바꿉니다

새 dashboard 빌드 대상은 RAM·ROM 사용량, Kconfig 값과 설정 출처, 초기화 단계, Devicetree 구조를 하나의 HTML 보고서로 묶어 보여줍니다. 다음 명령처럼 기존 빌드 뒤에 대상을 지정하면 됩니다.

west build -p -b <board> samples/hello_world -t dashboard

메모리가 왜 갑자기 늘었는지 찾으려고 ram_report, rom_report, 설정 추적 결과를 따로 펼쳐보던 시간을 줄일 수 있습니다. CI에서 기준 브랜치와 변경 브랜치의 보고서를 보관하면 "기능은 작은데 플래시가 왜 40KB 늘었지?" 같은 질문에도 근거를 갖고 답할 수 있습니다.

ZTEST_BENCHMARK() 기반의 벤치마크 프레임워크도 평균, 표준편차, 최솟값과 최댓값을 같은 방식으로 수집하게 해줍니다. Cortex-M 문맥 전환 구현은 공식 thread_metric 측정에서 평균 8% 개선됐지만, 이 수치를 내 제품의 응답 속도 향상으로 그대로 읽으면 안 됩니다. 인터럽트 비율, 캐시, 메모리 배치와 컴파일 옵션이 다르기 때문입니다. 릴리스 수치는 가능성을 알려주는 출발점이고, 최종 판단은 목표 보드의 회귀 벤치마크가 내려야 합니다.

실험적인 CPU 주파수 조절 서브시스템에 추가된 pressure 기반 정책도 같은 관점으로 봐야 합니다. 준비 큐의 태스크 수와 우선순위를 관찰해 부하가 커지면 클록을 높이고 한가해지면 낮춥니다. 센서 처리나 추론처럼 짧은 순간에 계산량이 몰리는 장치에는 유용하지만, 주파수 전환 지연과 전력 절감 폭을 실제 워크로드에서 측정하지 않으면 실익을 알 수 없습니다.

Zephyr 4.4 마이그레이션은 변경 목록을 시험표로 바꾸세요

4.3 프로젝트를 4.4로 올릴 때 새 기능보다 먼저 볼 문서는 4.4 마이그레이션 가이드입니다. 3.7 LTS에서 4.4로 건너뛴다면 4.0부터 4.4까지 각 버전의 마이그레이션 가이드를 순서대로 확인해야 합니다. 4.4는 최소 Python 버전을 3.12로 높였고, 보드·빌드 변수와 여러 Devicetree 속성을 정리했습니다. 일부 네트워크 이름에는 net_, NET_, ZSOCK_ 접두사가 붙었으며, 외부 애플리케이션은 POSIX 헤더와 Zephyr 전용 API의 경계를 다시 확인해야 합니다.

보안 모듈 변화도 작지 않습니다. Mbed TLS는 4.1.0으로 올라갔고 암호 기능은 별도 TF-PSA-Crypto 모듈로 이동했습니다. 인증서 파싱, 엔트로피 공급자, 서버 이름 표시와 관련된 Kconfig 이름도 달라졌습니다. TLS 연결이 컴파일된다는 이유만으로 이전과 같다고 판단하지 말고, 실제 인증서 체인 검증과 만료·오류·재연결 경로를 시험해야 합니다.

드라이버 쪽에는 단위와 기본 동작이 바뀐 항목이 있습니다. 예를 들어 일부 키보드 매트릭스 폴링 속성은 밀리초에서 마이크로초 단위로 바뀌었고, NXP i.MX GPT 카운터의 기본 실행 방식도 달라졌습니다. 이런 변경은 컴파일 오류로 친절하게 멈추지 않고 타이밍 오동작으로 나타날 수 있습니다. 프로젝트에서 쓰는 SoC와 드라이버 이름을 마이그레이션 문서에서 직접 검색해야 하는 이유입니다.

한 번에 올리지 말고 네 단계로 나누면 원인이 보입니다

첫째, 현재 버전에서 모든 테스트와 메모리 사용량을 기준선으로 저장합니다. 둘째, 애플리케이션 기능을 추가하지 않은 채 SDK·Python·Zephyr 버전만 올려 빌드 경고를 없앱니다. 셋째, 보드별 부팅, 저장장치, 네트워크, 저전력 진입과 OTA 업데이트를 하드웨어에서 회귀 시험합니다. 넷째, 힙 강화나 주파수 조절 같은 새 기능을 하나씩 켜고 전후 수치를 비교합니다.

이 순서를 지키면 문제가 생겼을 때 "버전 업 때문인지 새 기능 때문인지"를 구분할 수 있습니다. 보드가 여러 종류라면 모든 조합을 사람이 수동으로 돌리기 어렵습니다. 최소한 west twister 기반 빌드 행렬과 핵심 하드웨어 실기 시험을 CI에 묶어 두세요. 정적 메모리 예산, 부팅 시간, 네트워크 재접속 시간처럼 제품에 중요한 숫자에는 허용 범위를 두는 것이 좋습니다.

결론: Zephyr RTOS 4.4는 기능보다 개발 기준의 변화입니다

Zephyr RTOS 4.4의 가치는 WireGuard나 Wi-Fi Direct 한두 기능에만 있지 않습니다. SDK 1.0과 C17로 도구 기준을 올리고, 힙 오류 탐지와 빌드 대시보드, 벤치마크 프레임워크로 문제를 더 일찍 발견하도록 개발 흐름을 정리했다는 데 의미가 있습니다.

그만큼 업그레이드는 단순한 버전 번호 변경이 아닙니다. Python과 컴파일러, 외부 BSP, Devicetree, 암호 라이브러리와 현장 복구 절차까지 하나의 제품 변경으로 다뤄야 합니다. 특히 최신 안정판과 장기 지원판 중 무엇을 택할지는 새 기능의 매력보다 제품의 남은 수명과 검증 예산을 기준으로 결정하세요.

이번 주에 바로 할 수 있는 일은 간단합니다. 별도 브랜치에서 SDK 1.0 컨테이너를 고정하고, 현재 보드의 hello_world가 아니라 실제 제품 이미지를 빌드해 보세요. 그 결과를 4.4 마이그레이션 가이드와 대조하면 우리 프로젝트가 지금 옮길 준비가 됐는지 훨씬 선명하게 보일 겁니다.

Zephyr RTOS 4.4 참고 자료

• Zephyr 프로젝트: Zephyr RTOS 4.4 출시 소개
• Zephyr 공식 문서: 4.4.0 릴리스 노트
• Zephyr 공식 문서: 4.4.0 마이그레이션 가이드
• Zephyr 공식 문서: 릴리스와 지원 주기