합동회사 코무라소프트
문의하기
메뉴

장비에 올릴 OS로서 OpenHarmony는 선택지가 되는가 ── Windows IoT·임베디드 Linux와의 비교

· 업데이트: · · OpenHarmony, 임베디드, OS 선정, 장비 임베디드, Windows IoT, Linux, 제조업, 기술 상담

수정 이력(5건, 최종 수정 2026년 09월 03일)

이 글에 적용한 변경 사항의 기록입니다. 보관해 둔 수정 전 버전은 DOI가 부여된 고정 URL에서 읽을 수 있습니다.

Codex 리뷰에 따라 상담·문의 링크에 /ko/ 로케일 접두를 붙였습니다. 본문의 기술적인 주장은 바꾸지 않았습니다.
permalink·저자 표기·지식 맵 래퍼·깨진 내부 링크 등 CI가 지적한 표시용 수정을 반영했습니다. 본문의 기술적인 주장은 바꾸지 않았습니다.
기사 앞머리에 「이 기사의 지식 맵」을 추가했습니다. 본문에서 다루는 개념 사이의 관계를 한 장의 그림으로 조망할 수 있습니다. 관계의 전체 목록(근거 URL·확신도·확인일 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리하고, 기계 가독 데이터를 JSON-LD와 Turtle로 공개하고 있습니다. 수정 전 버전 보기 (DOI: 10.5281/zenodo.21733191)
외부 리뷰(1283건)에 대응하여 본문을 갱신했습니다. 개별 변경 내용은 아래 이력을 참조하십시오.
결론 바로 뒤에 평가 축마다 세 선택지를 비교하는 종합 판정표를 추가하고, 8장의 판단표 앞에는 판정 흐름을 나타내는 플로차트를 두었습니다. 아울러 비교표의 전제 용어(Yocto, LTSC) 보충과 지원 기간 정보의 기준일·확인처를 명시했습니다. 개발 보드의 입수성은 확인 절차를 제시하는 형태로 한정했습니다.
최초 공개
이 글을 인용하기(DOI(등록된 아카이브): 10.5281/zenodo.22175194)

아래 DOI는 이전에 등록된 아카이브를 가리키며 현재 본문과 다를 수 있습니다. 현재 본문을 참조할 때는 이 페이지의 URL을 사용하세요.

Go Komura (2026). 「장비에 올릴 OS로서 OpenHarmony는 선택지가 되는가 ── Windows IoT·임베디드 Linux와의 비교」. 합동회사 코무라소프트. https://comcomponent.com/ko/blog/openharmony-embedded-os-selection/

DOI(등록된 아카이브)
10.5281/zenodo.22175194
DOI(마지막 등록 버전)
10.5281/zenodo.22175195

이전 기사 「OpenHarmony란 무엇인가」에서는 OpenHarmony·HarmonyOS·HarmonyOS NEXT라는 세 실체를 구분했습니다. 여기서부터는 실무 이야기입니다. 장비에 올릴 OS로서 OpenHarmony는 정말로 선택지에 들어가는가.

장비 제조사의 OS 선정은 기능 비교보다 먼저 결정되는 요소가 있습니다. 10년 움직이는 장비에 2년밖에 유지보수되지 않는 OS는 올릴 수 없습니다. 벤더 SDK가 Windows에만 있는 카메라를 쓴다면 그 OS는 처음부터 후보 밖입니다. 이 기사에서는 Windows IoT Enterprise LTSC·임베디드 Linux(Debian / Yocto 기반)·OpenHarmony를 장비의 시간축과 조달 관점에서 나란히 비교하고, 채택해도 되는 조건과 제외해야 할 조건을 판단표로 정리합니다.

덧붙여 본 기사는 「OpenHarmony를 권하는 기사」도 「하지 말라는 기사」도 아닙니다. 당사가 평소 다루는 것은 Windows의 장비 소프트웨어이지만, 선택지를 올바르게 비교하지 못한 채 「새로운 기술이니까」 혹은 「중국발이라서」로 판단이 정해져 버리는 장면을 여러 번 보아 왔습니다. 판단 재료를 갖추는 것이 목적입니다.

1. 먼저 결론

  • 유지보수 기간이 최대의 갈림점입니다. OpenHarmony 커뮤니티의 Release 브랜치는 2년(능동 유지보수 1년＋수동 유지보수 1년), LTS 브랜치라도 3.5년(2년＋1.5년)입니다. Windows 11 IoT Enterprise LTSC 2024의 10년과는 전제가 다릅니다. 12
  • 게다가 근년에는 LTS 브랜치가 생성되지 않았습니다. LTS는 초기에 나왔고(1.1.0 LTS, 3.0-LTS), 공식 유지보수 일정표에 남는 LTS는 2021년 9월의 3.0-LTS가 마지막입니다. 3.1 이후에 공개된 브랜치는 모두 Release입니다. 34
  • 따라서 커뮤니티 버전을 제품에 그대로 올리는 운용은 성립하지 않습니다. 채택한다면 상용 디스트리뷰션의 벤더 유지보수를 사거나, 자사에서 브랜치를 유지보수하고 CVE 대응까지 수행하는 체제가 필요합니다. Huawei는 「OpenHarmony는 100을 넘는 상용 버전을 릴리스했다」고 설명하며, 이 상용 층이 실제 채택처입니다. 5
  • 리소스 하한은 OpenHarmony가 압도적으로 낮습니다. 경량 시스템은 최소 128 KiB의 MCU부터 동작합니다. Windows 11 IoT Enterprise LTSC의 특정 용도 디바이스 최소 요건은 메모리 2GB·스토리지 16GB이므로, 애초에 무대가 다릅니다. 67
  • 기존 Windows 장비 소프트웨어 자산은 가져올 수 없습니다. C#/.NET, Win32, COM, WPF/WinForms에 해당하는 실행 환경이 없고, UI는 ArkTS＋ArkUI, 드라이버는 HDF라는 다른 체계가 됩니다. 이식이 아니라 다시 만들기입니다.
  • 실제 병목은 벤더 SDK입니다. 산업용 카메라, 모션 컨트롤러, PLC 통신 라이브러리의 상당수는 Windows용, 그다음 Linux용만 제공됩니다. OpenHarmony용 드라이버 유무는 OS 비교보다 먼저 확인해야 할 항목입니다.
  • 일본어 1차 정보와 지원은 거의 없습니다. 공식 문서는 중국어와 영어 두 종류이며 일본어판은 없습니다. 8 중국어 또는 영어 기술 문서를 끝까지 읽을 수 있는 인원이 있는 것이 실질적인 전제 조건입니다.
  • 맞는 용도는 분명히 있습니다. 중국 시장용 제품, 복수 기기 연동(DSoftBus)이 제품 가치의 중심에 있는 기기, 화면이 있는 IoT 기기에서 ArkUI의 UI를 쓰고 싶은 경우, MCU부터 리치 디바이스까지를 하나의 체계로 맞추고 싶은 경우입니다. 9

평가 축×선택지의 종합 판정을 먼저 한 장으로 정리합니다. 이후 각 장에서 다루는 내용의 요약입니다. 기호는 ◎=그대로 적합 / ○=조건부 적합 / △=주의가 필요 / ×=적합하지 않음의 4단계입니다.

평가 축 Windows IoT Enterprise LTSC 임베디드 Linux(Debian / Yocto) OpenHarmony 상세
유지보수 기간(장비의 10년에 충분한가) ◎ 10년 고정. 2024 LTSC는 2034년 10월까지2 ○ Debian 약 5년, Yocto LTS 4년. 상용 계약으로 연장1011 △ 커뮤니티는 Release 2년·LTS 3.5년. 벤더 유지보수 구매가 전제1 3장
리소스 하한(얼마나 작은 기기에 올릴 수 있는가) × 최소 메모리 2GB·스토리지 16GB7 △ MMU가 있는 프로세서와 수십 MB급 RAM이 전제 ◎ 경량 시스템은 128 KiB MCU부터6 2장
벤더 SDK(산업용 카메라, 모션, PLC 통신) ◎ 제1 대응처 ○ 제공되어 있으면 사용 가능 × 우선 기대하기 어렵다 5장
언어·UI 체계(기존 Windows 자산 반입) ◎ C#/.NET, Win32, COM, WPF가 그대로 동작 × 다시 만들기. 다만 C/C++의 계측·제어 로직은 이식하기 쉽다 × 다시 만들기. ArkTS＋ArkUI, 드라이버는 HDF 5장
일본어 정보·일본 국내 지원 ◎ 일본어 문서와 일본 국내 대리점·창구 ○ 일본어 기술 정보가 풍부 × 공식 문서는 중국어·영어만8 5장
기기 연동(기기 발견·데이터 동기화·앱 이전) △ 자체 구현 △ 자체 구현 ◎ DSoftBus와 분산 데이터 관리·분산 스케줄러가 표준9 8장

보다시피 OpenHarmony가 ◎가 되는 것은 리소스 하한과 기기 연동의 두 축이고, 기존 자산·SDK·일본어 정보의 세 축은 ×입니다. 이 형태는 「우열」이 아니라 「맞물리는 조건이 한정된다」는 것을 보여 줍니다. 어떤 조건이면 맞물리는지는 8장의 판단표에서 개별적으로 제시합니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 34건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 비교의 전제를 맞춘다 ── 무엇을 무엇과 비교하는가

비교를 시작하기 전에 대상을 명확히 합니다. 「OS」라고 한 말로 층이 다른 것을 나란히 놓으면 논의가 맞물리지 않습니다.

선택지 실체 커널 UI·앱 층
Windows 11 IoT Enterprise LTSC Microsoft의 상용 OS 제품 Windows NT Win32 / WinUI / WPF / WinForms, .NET
임베디드 Linux(Debian 기반) 디스트리뷰션 Linux 임의(Qt, GTK, Wayland compositor 등)
임베디드 Linux(Yocto 기반) 자사 빌드 디스트리뷰션을 만드는 틀 Linux 임의
OpenHarmony 표준 시스템 OS 프로젝트(디스트리뷰션화가 필요) Linux ArkUI, ArkTS, Ability
OpenHarmony 소형 시스템 동일 LiteOS-A 표준 그래픽 프레임워크
OpenHarmony 경량 시스템 동일 LiteOS-M 경량 그래픽 프레임워크

표 안의 용어를 두 가지만 보충합니다. Yocto는 완성된 OS가 아니라, 레시피(빌드 절차의 정의)를 조합해 자사 제품용 Linux 디스트리뷰션을 빌드하는 틀입니다. LTSC(Long-Term Servicing Channel)는 기능 업데이트를 넣지 않고 보안 업데이트만 장기간 제공하는 Windows의 제공 모델로, 장비처럼 구성을 고정하고 싶은 용도를 위한 선택지입니다.

여기서 잡아 둘 것은 OpenHarmony는 Windows IoT처럼 「사서 올리는 완제품」이 아니다는 점입니다. 위치는 Yocto에 가깝고, 「이것을 토대로 자사 제품용 구성을 만든다」는 틀입니다. 다만 Yocto와 달리 UI 프레임워크와 앱 모델까지 한 세트로 정해져 있는 만큼, 위쪽까지 쌓여 있습니다.

OpenHarmony의 시스템 타입 정의는 다음과 같습니다. 6

시스템 타입 프로세서 최소 메모리 상정 제품
경량 시스템 Arm Cortex-M, 32비트 RISC-V 등의 MCU 128 KiB 접속 모듈, 센서, 웨어러블
소형 시스템 Arm Cortex-A 등의 애플리케이션 프로세서 1 MiB IP 카메라, 도어스코프, 라우터, 드라이브 레코더
표준 시스템 Arm Cortex-A 등의 애플리케이션 프로세서 128 MiB 완전한 애플리케이션 프레임워크를 가진 화면 있는 기기

장비 임베디드 맥락에서 비교 대상이 되는 것은 주로 표준 시스템(HMI가 있는 장비)과 경량 시스템(센서 노드, 통신 모듈)입니다. 소형 시스템은 카메라 제품 쪽에 가깝습니다.

3. 지원 기간 비교 ── 장비의 시간축에 맞는 것은 어느 쪽인가

장비에 넣는 PC나 보드는 장비 본체와 같은 10년 전후의 라이프사이클로 계속 움직일 것이 요구됩니다. 이 관점에서 각 선택지를 나란히 놓으면 차이는 분명합니다.

선택지 지원 기간 구체 예 출처
Windows 11 IoT Enterprise LTSC 2024 10년 2024년 10월 1일 시작, 2034년 10월 10일 종료 2
Windows 10 IoT Enterprise LTSC 2021 10년 2032년 1월 13일 종료 12
Debian(LTS 포함) 약 5년 Debian 12 bookworm의 LTS 기간은 2026년 6월 11일〜2028년 6월 30일 10
Yocto Project LTS 4년 5.0 Scarthgap은 2024년 4월〜2028년 4월, 6.0 Wrynose는 2026년 4월〜2030년 4월 11
OpenHarmony LTS 브랜치 3.5년(2년＋1.5년) 3.0-LTS는 2021년 9월 30일〜2025년 3월 30일 13
OpenHarmony Release 브랜치 2년(1년＋1년) 4.1-Release는 2024년 3월 30일〜2026년 3월 30일 13

이 표는 2026년 7월 시점의 각 공식 정보에 근거합니다. 지원 기간과 종료일은 개정되므로, 채택 판단 직전에는 반드시 1차 정보로 확인하십시오. 확인처는 다음과 같습니다.

특히 OpenHarmony는 후술하듯 5.x계·6.x계가 유지보수 일정표에 아직 실려 있지 않습니다. 이 표의 행에 없는 버전을 검토할 때는 기간이 미확정이라는 전제로 보십시오.

추가로 읽어 둘 점이 두 가지 있습니다.

첫 번째. OpenHarmony의 「수동 유지보수 기간」은 품질이 떨어집니다. 공식 수명 주기 관리 정책에서는, 능동 유지보수 기간에는 커뮤니티가 태그 버전을 계획적으로 내어 결함과 보안 취약점을 수정하지만, 수동 유지보수 기간에 들어가면 태그 버전의 계획·릴리스는 이루어지지 않고, 중대 이상의 보안 취약점과 결함만이 수정 대상이 됩니다. 1 즉 실질적인 「안심하고 쓸 수 있는 기간」은 Release 브랜치에서 1년, LTS에서 2년으로 보아야 합니다.

두 번째. 근년에는 LTS 브랜치가 생성되지 않았습니다. 공식 유지보수 일정표에 실리는 LTS는 3.0-LTS(2021년 9월)가 마지막이고, 3.1·3.2·4.0·4.1은 모두 Release 종류입니다. 3 LTS 자체는 그 이전에도 나왔고, 릴리스 노트 색인에는 1.1.0 LTS(2021년 4월)와 그 계열이 남아 있지만 모두 End of Life입니다. 4 나아가 5.x계와 6.x계는 이 유지보수 일정표에 아직 기재가 없습니다. 10년의 장비 라이프사이클을 전제로 하면, 「어느 브랜치에 얼마나 유지보수가 붙는지」가 릴리스마다 읽히지 않는 상태가 이어지고 있는 셈입니다.

한편 Windows 11 IoT Enterprise LTSC 2024는 고정 라이프사이클 정책으로, 2034년 10월 10일이라는 종료일이 처음부터 확정되어 있습니다. 2 Debian도 각 릴리스의 통상 지원과 LTS 기간이 공표되고, Yocto Project도 LTS 릴리스를 4년간 지원한다고 명시합니다. 1011

이것은 OpenHarmony의 품질이 낮다는 이야기가 아닙니다. 이 유지보수 모델은 「커뮤니티 버전을 그대로 제품에 올리고 방치한다」는 쓰임을 상정하지 않았다는 것뿐입니다. 실제 산업 채택에서는 상용 디스트리뷰션 벤더가 자사에서 브랜치를 유지보수하고, 유지보수를 유상으로 제공합니다. 채택 검토 때 확인할 것은 「OpenHarmony의 지원은 몇 년입니까」가 아니라, 「그 디스트리뷰션의 벤더는 어느 브랜치를, 언제까지, 어떤 SLA로 유지보수합니까」입니다.

4. 하드웨어의 선택지

커뮤니티가 대응을 공표한 개발 보드는 22기종입니다. 13 장비와 관련될 만한 것을 골라내면 다음과 같습니다.

시스템 타입 보드 SoC 문서상의 상정 용도
표준 HiHope HH-SCDAYU200 Rockchip RK3568 NVR, 산업 게이트웨이, 가전
표준 MILOS_Standard0 NXP i.MX8M Mini 산업·의료용 고성능 계측 기기, 산업 제어와 HMI, 교통, 방재, 빌딩
표준 Yangfan Rockchip RK3399 디지털 사이니지, 무인 단말, 산업 제어 호스트, 로봇
표준 ZLG 개발 보드 Allwinner T507 산업 제어, 스마트 콕핏, 스마트 전력
표준 Unionpi Tiger Amlogic A311D 산업 제어, AI 에지 컴퓨팅
소형 BearPi-HM Micro ST STM32MP157A 스마트 홈, 중앙 제어 화면
경량 Niobe407 ST STM32F407IGT6 스마트 교통, 산업 제어
경량 HPM6750EVK2 HPMicro HPM6700(RISC-V) 산업 제어, 에지 컴퓨팅

중요한 것은 SoC 벤더가 중국계만이 아니다는 점입니다. NXP i.MX8M Mini나 ST의 STM32 시리즈가 대응 리스트에 들어 있는 것은, 일본의 장비 제조사에게 현실적인 의미가 있습니다. 이미 채택 실적이 있는 SoC 패밀리로 검토할 가능성이 있기 때문입니다.

다만 주의점도 그만큼 큽니다.

  • 대응 보드 리스트와, 실제로 손에 넣는 산업용 보드는 별개입니다. 여기에 실린 것은 평가 보드 중심이고, 10년 공급 보증이 붙은 산업용 보드에 OpenHarmony가 공식으로 올라가 있는지는 별도로 확인이 필요합니다. 표의 「상정 용도」는 문서상의 위치이지, 공급 보증도 일본 국내 유통의 뒷받침도 아닙니다.
  • 입수성은 일본에서 개별 확인이 필요합니다. 이 목록의 보드는 중국 시장용이 중심이며, 일본 국내 대리점에서 보통 살 수 있다고는 할 수 없습니다. 평가기를 마련하기 전에 (1) 보드 벤더의 판매 페이지와 국경 간 EC에서의 취급, (2) 일본 국내 판매 대리점의 유무, (3) 양산 시 최소 로트와 공급 연수, 의 세 점을 문의로 확인하십시오. 여기가 막히면 이후의 기술 검증은 모두 멈춥니다.
  • 자사 하드웨어에 올린다면 포팅이 자사 작업이 됩니다. Windows IoT라면 「OEM 대리점을 통해 라이선스를 사고, 드라이버는 벤더가 공급한다」로 끝나는 곳이, OpenHarmony에서는 자사 또는 디스트리뷰터의 작업이 됩니다.
  • 드라이버의 취급은 「어디서부터 쓰느냐」에 따라 달라집니다. OpenHarmony는 HDF(Hardware Driver Foundation)라는 통일 드라이버 기반을 가지며, 이는 플랫폼 비의존·커널 비의존 설계로 모든 시스템 타입에 적용됩니다. 9 다만 표준 시스템의 커널은 Linux이므로, 기존 Linux 커널 드라이버를 그대로 넣고 V4L2나 입력 디바이스 같은 통상의 Linux 인터페이스를 통해 쓰는 것 자체는 가능합니다. 적합 작업이 필요해지는 것은 그 디바이스를 OpenHarmony의 시스템 서비스나 프레임워크에서 HDI를 통해 다루게 하고 싶을 때입니다. 기존 Linux BSP가 있다면 「모든 드라이버를 HDF로 다시 쓴다」고 견적할 필요는 없습니다. 어느 디바이스를 OpenHarmony 프레임워크에 노출할지를 먼저 정하고, 그 범위만 공수에 넣으십시오.

덧붙여 보드 조달에서 멈춰 있는 단계에서도 검증은 시작할 수 있습니다. 실기를 사기 전에 QEMU로 구조와 기동 흐름을 확인하는 절차를 9장에 적어 두었습니다. 또한 자사 기판의 SoC가 이미 정해져 있다면, 평가 보드를 찾기보다 그 SoC로의 포팅 공수를 견적하는 편이 실제적인 경우도 있습니다.

5. 개발 환경과 언어 ── 기존 자산은 가져올 수 있는가

항목 Windows IoT Enterprise LTSC 임베디드 Linux OpenHarmony
빌드 시스템 MSBuild / Visual Studio Make / CMake / BitBake(Yocto) GN + Ninja9
주요 언어 C#, C++, VB C, C++, Python, Rust ArkTS(TypeScript 확장), C, C++
UI 프레임워크 WPF, WinForms, WinUI Qt, GTK, Flutter 등 ArkUI
드라이버 WDM / WDF Linux 커널 드라이버 HDF
IDE Visual Studio 임의 DevEco Device Tool(Windows＋Ubuntu 병용) 또는 CLI14
일본어 문서 있음 풍부 없음(중국어·영어만)8

장비 소프트웨어 자산의 관점에서 보면 이야기는 단순합니다. Windows로 작성된 장비 소프트웨어는 OpenHarmony에 가져올 수 없습니다. C#/.NET도 Win32도 COM도 WPF도 대응하는 실행 환경이 없습니다. UI는 ArkTS와 ArkUI, 하부는 C/C++로 다시 쓰게 됩니다.

더욱 현실적인 장애는 벤더 SDK의 대응 상황입니다. 산업용 카메라 SDK, 모션 컨트롤러 라이브러리, PLC 통신 미들웨어, 이미지 처리 라이브러리 ── 이들 상당수는 Windows용이 첫째이고, Linux용이 제공되어 있으면 나은 편이라는 것이 실정입니다. OpenHarmony용 제공은 기대할 수 없습니다. 따라서,

OS 비교보다 먼저, 장비에 필요한 주변 디바이스와 미들웨어의 리스트를 만들고, 각각의 OpenHarmony 대응 상황을 확인한다.

이것을 하지 않고 OS 비교표만으로 논의하면 후공정에서 반드시 무너집니다. 당사가 장비 소프트웨어 상담을 받을 때도 맨 먼저 이 리스트를 만드는 데서 들어갑니다.

개발 환경의 입구는 두 가지가 마련되어 있습니다. GUI의 DevEco Device Tool(Windows에서 코드 편집·디버그·쓰기, Ubuntu에서 컴파일이라는 병용 구성)과 CLI에 의한 절차입니다. 14 소스 취득은 repo 도구로, gitcode.com·gitee.com·GitHub 미러가 안내되어 있습니다. 15

6. 라이선스와 지식재산

OpenHarmony는 단일 라이선스가 아닙니다. 넣는 범위마다 확인이 필요합니다.

대상 라이선스 실무상의 주의
많은 컴포넌트(빌드 시스템, ArkUI 엔진 등) Apache License 2.016 저작권·특허 조항 준수, 변경점 표시
LiteOS-A 커널 BSD 3조항17 저작권 표시와 바이너리 배포 시 면책 조항의 재게재
표준 시스템의 Linux 커널 부분 GPLv2(Linux 커널 본체의 라이선스) 장비를 고객에게 배포할 때에, 배포한 바이너리에 대응하는 소스(개변분을 포함)를 배포처에 제공할 의무. 사내 이용에 머무는 개변에는 제공 의무가 생기지 않음
공식 문서 CC BY 4.018 인용 시 표시

「OpenHarmony는 Apache 2.0이니 안심」이라고 묶어 버리면 표준 시스템 커널 부분의 GPL 의무를 놓칩니다. 장비에 올리는 범위의 리포지토리를 열거하고 LICENSE를 하나씩 확인하는 것이 원칙입니다. 이 점은 Windows IoT(상용 라이선스 한 줄로 끝남)와의 실무적 차이가 됩니다.

GPLv2에 대해 한 점 보충합니다. 의무가 발생하는 것은 배포(distribution) 시점이지, 개변한 시점이 아닙니다. 사내 검증기에서 커널을 개변해 움직이고 있을 뿐이면 제공 의무는 생기지 않고, 그 장비를 고객에게 납입한 단계에서 배포한 바이너리에 대응하는 소스 코드를 배포처에 제공할 의무가 발생합니다. 장비 제조사에게는 「납품＝배포」이므로 결국 대응이 필요해지지만, 사내 시작 단계부터 공개 의무가 있는 것은 아니라는 구분은 잡아 두십시오(구체적인 적합 방법은 자사 법무·지식재산 부서와 확인하십시오).

7. 인증과 에코시스템 참가

제품으로서 「OpenHarmony 호환」을 대외적으로 표방하려면 OpenAtom 재단의 호환성 평가를 통과해야 합니다. 기술적 토대는 OpenHarmony의 XTS(X Test Suite) 이고, 공식 문서에서는 「OpenHarmony 호환성 테스트 스위트 군을 제공하며, 현재 지원되는 애플리케이션 호환성 테스트 스위트(ACTS)와 장래 지원될 디바이스 호환성 테스트 스위트(DCTS)를 포함한다」고 설명되어 있습니다. 9 즉 공식 문서의 서술(2026년 7월 시점)에서는 현시점에 제공되는 것은 ACTS이고, DCTS는 장래 제공이라는 취급입니다.

한편 커뮤니티의 인증 절차 자료에서는 XTS를 ACTS·HATS(하드웨어 추상 계층 호환성)·DCTS의 세 갈래로 설명하며, 공식 문서의 서술과 어긋납니다. 19 신청자가 자사에서 적합 개발과 셀프 테스트를 하고, 테스트 리포트를 첨부해 신청한다는 흐름 자체는 공통입니다.

공수를 견적할 때는 DCTS를 필수 요건으로 단정하지 마십시오. 어느 스위트가 신청 시점에 실제로 요구되는지는 인증 창구에 직접 확인하는 것이 확실합니다. 이런 「공식 문서와 커뮤니티 자료가 일치하지 않는」 상황은, 일본어 1차 정보가 없는 것과 맞물려, 채택 시의 커뮤니케이션 비용으로 잡아 두어야 할 것입니다.

사내 검증이나 단발 장비에만 쓴다면 인증은 불필요하지만, 대외적으로 호환성을 표방하는 제품, 혹은 에코시스템의 일원으로 다루어지고 싶은 제품에서는 통과하는 전제가 됩니다. 공수로서 처음부터 견적해야 할 항목입니다.

8. 판단표 ── 채택해도 되는 조건, 제외해야 할 조건

판단표에 들어가기 전에, 거기에 이르는 판정 흐름을 한 장으로 둡니다. 전제를 확인하는 순서가 중요하며, 시장·제품 요건이 먼저, 기술 검토는 나중입니다. 기술적으로 만들 수 있어도, 유지보수를 계약으로 굳히지 못하면 장비에는 올릴 수 없습니다.

예아니요예아니요갖춰진다 / 자사에서 만들 수 있다갖춰지지 않는다굳힐 수 있다굳힐 수 없다있다없다장비에 올릴 OS를 고른다중국 시장용 제품인가, 또는요건이 OpenHarmony 호환 지정인가복수 기기 연동(DSoftBus)이제품 가치의 핵심인가주변 디바이스와 미들웨어의벤더 SDK가 OpenHarmony에서 갖춰지는가(갖춰지지 않는 부분을 자사에서 만들 수 있는가)유지보수를 계약으로 굳힐 수 있는가(상용 디스트리뷰션의 벤더,또는 자사에서 CVE 대응까지 갖는 체제)중국어 또는 영어 기술 문서를끝까지 읽을 수 있는 요원이 있는가OpenHarmony를 정면에서 검토상용 디스트리뷰션 경유로 조달Windows IoT LTSC 또는 임베디드 Linux기존 자산과 벤더 SDK 대응으로 정한다OpenHarmony는 제외

그림 1: OpenHarmony를 채택할지의 판정 흐름. 각 분기의 근거는 아래 판단표의 행에 대응합니다

분기 가운데 Q3(벤더 SDK)와 Q4(유지보수 계약)에서 떨어지는 안건이 실제로는 많다는 것이 이 기사의 취지입니다. 아래 판단표는 이 그림의 각 분기를 구체적인 상황으로 펼친 것입니다.

상황 권장 이유
10년 가동 장비에 넣는 HMI 있는 PC, 기존 Windows 자산 있음 Windows 11 IoT Enterprise LTSC 2024 2034년 10월까지 10년 지원. 기능 업데이트 없음. 장비 소프트웨어·벤더 SDK가 그대로 동작2
10년 가동 장비, Linux용 SDK가 갖춰져 있음, 사내에 Linux 요원 있음 상용 지원이 붙은 임베디드 Linux Yocto LTS로 4년, 상용 디스트리뷰션의 장기 지원 계약으로 연장 가능11
중국 시장에 내는 제품으로, 요건이 「OpenHarmony 호환일 것」 OpenHarmony(상용 디스트리뷰션 경유) 시장 요건이 OS를 정한다. 벤더 유지보수를 포함해 조달한다
고객이 HarmonyOS 에코시스템(AppGallery 배포, HarmonyOS 앱 연동) 참가를 요구 OpenHarmony로는 요건을 충족하지 못함 AppGallery도 HMS도 HarmonyOS SDK도 OpenHarmony에는 포함되지 않고, HarmonyOS 앱의 호환성도 보증되지 않는다. HarmonyOS 대응 제품·HarmonyOS SDK를 고를 필요가 있다
복수 기기 연동(기기 발견·데이터 동기화·앱 이전)이 제품 가치의 핵심 OpenHarmony DSoftBus와 분산 데이터 관리·분산 스케줄러가 표준으로 올라간다9
MCU부터 리치 디바이스까지, 제품 라인을 하나의 체계로 맞추고 싶다 OpenHarmony(검토 가치 있음) 128 KiB부터 128 MiB 이상까지 동일 체계로 커버6
센서 노드·통신 모듈(MCU, 수백 KiB급) OpenHarmony 경량 시스템 또는 RTOS Windows IoT는 무대 밖(최소 2GB)7
10년 유지보수를 계약으로 보증하고 싶다, 사내에 중국어·영어 기술 문서를 읽는 요원이 없다 제외 커뮤니티 유지보수는 최대 3.5년, 일본어 문서·일본어 1차 지원이 없다18
산업용 카메라·모션 컨트롤러 등의 벤더 SDK에 의존하는 장비 제외(사전 확인 필요) 벤더 SDK의 OpenHarmony 대응은 우선 기대할 수 없다
기존 C#/.NET·COM 자산을 살리고 싶다 제외 대응하는 실행 환경이 없고, 다시 만들게 된다
조달 방침의 제약이 「프로젝트의 거버넌스·운영 주체」에 대한 것 Eclipse Oniro 계열을 검토 Oniro는 유럽 재단 거버넌스 아래. 다만 2026년 7월 시점에서 Incubating이며, 커뮤니티 규모도 본체와는 비교가 되지 않는다
조달 방침의 제약이 「중국 유래 코드를 포함하지 않을 것」에 대한 것 제외 Oniro도 OpenHarmony의 기반 층 위에 구축되므로, 거버넌스가 유럽 재단이어도 코드 유래의 제약은 해소되지 않는다

9. 채택한다면 맨 먼저 할 일

판단표에서 「채택」으로 기울었다면, 착수 순서는 이렇게 됩니다.

  1. 주변 디바이스와 미들웨어 목록화. 카메라, I/O, 통신, 모션, 이미지 처리 ── 각 벤더의 OpenHarmony 대응 가부를 확인합니다. 여기서 막히면 다른 공정을 진행할 의미가 없습니다.
  2. 시스템 타입의 확정. 경량/소형/표준 중 어느 쪽으로 만들지를 정합니다. 이로써 커널(LiteOS-M / LiteOS-A / Linux)도 앱 작성법도 달라집니다.
  3. QEMU로 구조 확인. 실기 보드를 사기 전에, device_qemu가 마련한 Arm Virt(LiteOS-A / Linux), Cortex-M4, Cortex-M55, RISC-V 등의 에뮬레이션 환경에서 빌드와 기동 흐름을 확인할 수 있습니다. 20
  4. 유지보수 브랜치의 고정과 빌드 재현성 확보. repo의 매니페스트를 고정하고(태그 지정이 확실합니다), 사내 미러를 가지며, 5년 후에 같은 바이너리를 재생성할 수 있는 상태를 만듭니다. 15 상류 호스팅이 gitcode.com 중심인 점도, 사업 계속 관점에서는 자사 미러를 가질 이유가 됩니다.
  5. 라이선스 목록화. 넣는 범위의 리포지토리를 열거하고, Apache 2.0 / BSD / GPL의 의무를 정리합니다.
  6. 유지보수 계약 교섭. 상용 디스트리뷰션 벤더와 「어느 브랜치를, 언제까지, 어느 SLA로」 유지보수할지를 계약으로 굳힙니다. 여기가 정해지지 않으면 채택 판단을 보류해야 합니다.
  7. 호환성 평가(XTS)의 필요 여부 판단. 대외적으로 호환성을 표방한다면 공수를 처음부터 쌓습니다.

10. 정리

  • OpenHarmony는 기술적으로는 이치에 맞는 설계로, 128 KiB MCU부터 128 MiB 이상의 리치 디바이스까지를 하나의 체계로 커버하고, 기기 연동(DSoftBus)을 표준으로 갖습니다. 산업 용도를 상정한 대응 보드도 있으며, NXP나 ST의 SoC도 포함됩니다.
  • 한편 장비의 10년 라이프사이클이라는 관점에서는 커뮤니티의 유지보수 기간(Release 2년, LTS 3.5년)은 분명히 부족합니다. 게다가 LTS 브랜치는 2021년의 3.0-LTS 이후 생성되지 않았습니다. 채택한다면 상용 디스트리뷰션의 벤더 유지보수가 전제입니다.
  • 일본의 장비 제조사에게 실질적인 채택 조건은 세 가지입니다. (1) 벤더 SDK가 OpenHarmony에 대응하는가, (2) 중국어 또는 영어 기술 문서를 끝까지 읽을 수 있는 요원이 있는가, (3) 유지보수를 계약으로 굳힐 수 있는 벤더가 있는가. 하나라도 빠지면 Windows IoT Enterprise LTSC나 상용 지원이 붙은 임베디드 Linux가 장비의 시간축에 더 맞습니다.
  • 반대로, 중국 시장용 제품, 기기 연동이 제품 가치의 핵심인 제품, MCU부터 리치까지를 한 체계로 맞추고 싶은 제품 라인에서는 정면에서 검토할 가치가 있습니다.

OS 선정은 「어느 쪽이 우수한가」가 아니라 「장비의 시간축·조달·요원과 어느 쪽이 맞물리는가」의 문제입니다. Windows 쪽의 선정 기준은 「산업용 PC에는 어느 Windows를 넣어야 하는가」에 정리해 두었습니다.

관련 기사

관련 상담 영역

合同会社小村ソフト에서는 장비에 올릴 실행 기반의 선정 지원, 기존 Windows 장비 소프트웨어의 이전 가부 가름, 장기 가동을 전제로 한 구성 리뷰를 다룹니다. 「새로운 OS가 후보에 올랐지만 사내에 비교할 재료가 없다」는 단계부터 상담하실 수 있습니다.

참고 링크

  1. OpenHarmony, OpenHarmony Version Lifecycle Management. Release 브랜치의 수명 주기가 2년(능동 유지보수 1년＋수동 유지보수 1년), LTS 브랜치가 3.5년(2년＋1.5년)인 것, 수동 유지보수 기간에서는 태그 버전의 계획·릴리스를 하지 않고 중대 이상의 보안 취약점과 결함만 수정하는 것에 대해. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. Microsoft Learn, Windows 11 IoT Enterprise LTSC 2024 - Microsoft Lifecycle. 2024년 10월 1일 시작, 연장 지원 종료가 2034년 10월 10일(합계 10년)인 것에 대해. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. OpenHarmony Documentation, OpenHarmony Version Definitions. LTS·Release 브랜치의 유지보수 일정표(이 표에 실리는 LTS는 3.0-LTS뿐이고, 1.0.1·3.1·3.2·4.0·4.1이 Release 종류인 것, 4.1-Release의 유지보수 종료가 2026년 3월 30일인 것, 5.x계·6.x계가 아직 표에 기재되지 않은 것)에 대해. ↩ ↩2 ↩3 ↩4 ↩5

  4. OpenHarmony Documentation, Release Notes 색인. 3.0-LTS(2021년 9월 30일)와 그 계열이 게재되고 3.1 이후는 모두 Release 종류인 것, 1.x계에도 LTS(1.1.0 LTS 외)가 존재했으나 End of Life로 되어 있는 것, 및 6.1 Release(2026년 3월 8일)가 게재되어 있는 것에 대해. ↩ ↩2

  5. 華為, HarmonyOS 7 開発者Beta 正式启动，全场景智能操作系统再升级. 2026년 6월 12일의 HDC 2026에서 OpenHarmony가 100을 넘는 상용 버전을 릴리스했다고 설명된 것에 대해. ↩

  6. OpenHarmony Documentation, Quick Start Overview. 경량 시스템(MCU, 최소 128 KiB), 소형 시스템(Cortex-A, 최소 1 MiB), 표준 시스템(Cortex-A, 최소 128 MiB)이라는 세 시스템 타입의 정의와 상정 제품에 대해. ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, Minimum System Requirements - Windows IoT Enterprise. 특정 용도 디바이스용 OPTIONAL 최소 요건으로 메모리 2GB·스토리지 16GB가 정의되어 있는 것에 대해. ↩ ↩2 ↩3

  8. OpenHarmony Documentation, README. 공식 문서가 중국어(zh-cn)와 영어(en) 두 언어로 제공되고 일본어판이 존재하지 않는 것, 및 각 버전과 API 레벨의 대응에 대해. ↩ ↩2 ↩3 ↩4

  9. OpenHarmony Documentation, OpenHarmony Project. 4층 아키텍처와 Linux/LiteOS의 멀티 커널 설계, HDF(Hardware Driver Foundation)에 의한 통일 드라이버 기반, DSoftBus·분산 데이터 관리·분산 스케줄러, 빌드 시스템이 GN+Ninja인 것, XTS가 호환성 테스트 스위트 군이며 「현재 지원되는 애플리케이션 호환성 테스트 스위트(ACTS)와 장래 지원될 디바이스 호환성 테스트 스위트(DCTS)」라고 서술되어 있는 것에 대해. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  10. Debian Wiki, LTS. Debian LTS가 각 안정판 릴리스의 수명을 적어도 5년으로 연장하는 프로젝트인 것, Debian 12 bookworm의 LTS 기간이 2026년 6월 11일부터 2028년 6월 30일인 것에 대해. ↩ ↩2 ↩3 ↩4

  11. Yocto Project Wiki, Releases. LTS 릴리스가 4년간 지원되는 방침인 것, 5.0 Scarthgap이 2024년 4월 릴리스로 2028년 4월까지, 6.0 Wrynose가 2026년 4월 릴리스로 2030년 4월까지 지원되는 것에 대해. ↩ ↩2 ↩3 ↩4 ↩5

  12. Microsoft Learn, Windows 10 IoT Enterprise LTSC 2021 - Microsoft Lifecycle. 연장 지원 종료가 2032년 1월 13일인 것에 대해. ↩

  13. OpenHarmony Documentation, OpenHarmony Development Boards List. 커뮤니티 대응 개발 보드가 22기종인 것, 및 각 보드의 SoC와 상정 용도(MILOS_Standard0의 NXP i.MX8M Mini가 산업·의료용 계측 기기와 산업 제어·HMI를, Niobe407의 STM32F407가 산업 제어를 상정 용도로 든 것 등)에 대해. ↩

  14. OpenHarmony Documentation, Quick Start Overview. 디바이스 개발의 입구로서 DevEco Device Tool을 쓰는 IDE 모드(Windows에서 코드 개발·디버그·쓰기, Ubuntu에서 소스 컴파일이라는 하이브리드 구성)와 CLI 모드 두 종류가 마련되어 있는 것에 대해. ↩ ↩2

  15. OpenHarmony Documentation, Source Code Acquisition. repo 도구에 의한 소스 취득 절차와 gitcode.com·gitee.com·GitHub의 각 미러, 브랜치 지정·태그 지정 방법에 대해. ↩ ↩2

  16. OpenHarmony, arkui_ace_engine LICENSE 및 build LICENSE. ArkUI 엔진 및 빌드 시스템 리포지토리가 Apache License 2.0으로 배포되는 것에 대해. ↩

  17. OpenHarmony, kernel_liteos_a LICENSE. LiteOS-A 커널이 BSD 3조항 라이선스로 배포되는 것에 대해. ↩

  18. OpenHarmony, docs LICENSE. 공식 문서 리포지토리가 Creative Commons Attribution 4.0 International로 제공되는 것에 대해. ↩

  19. 開放原子開源基金会 커뮤니티 자료, OpenHarmony-XTS認証流程(2차 정보). 커뮤니티의 인증 절차 자료가 XTS를 ACTS(앱 호환성)·HATS(하드웨어 추상 계층 호환성)·DCTS의 세 갈래로 설명하는 것, 신청자가 기업 계정을 취득하고 적합 개발과 셀프 테스트를 하며 테스트 리포트와 PCS 자기 점검표를 첨부해 신청하는 흐름인 것에 대해. DCTS의 위치는 공식 문서(「장래 지원될 디바이스 호환성 테스트 스위트」)와 어긋나므로, 본문에서는 그 차이를 명시하고 있다. ↩

  20. OpenHarmony, device_qemu README. QEMU에 의한 에뮬레이션 대상으로서 Arm Virt(LiteOS-A), Arm Virt(Linux), Cortex-M4(mps2-an386), Cortex-M55(mps3-an547), RISC-V(riscv32_virt), Xtensa(esp32), C-SKY(SmartL_E802)의 절차가 마련되어 있는 것에 대해. ↩

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

산업 기기의 OS로 OpenHarmony를 채택해도 괜찮습니까?
조건에 따라 다릅니다. 결정적인 것은 유지보수 기간의 취급입니다. OpenHarmony 커뮤니티의 Release 브랜치는 수명 주기가 2년(능동 유지보수 1년＋수동 유지보수 1년)이고, LTS 브랜치라도 3.5년입니다. 10년 가동하는 장비에 커뮤니티 버전을 그대로 올리면, 제품 수명 도중에 보안 수정이 멈춥니다. 채택한다면 상용 디스트리뷰션의 벤더 유지보수를 구매하거나, 자사에서 브랜치를 유지보수하고 CVE 대응까지 수행하는 체제를 갖추는 것이 전제입니다. 이 체제를 마련할 수 없다면 Windows IoT Enterprise LTSC(10년)나 상용 임베디드 Linux의 장기 지원 계약이 장비의 시간축에 더 맞습니다.
OpenHarmony와 임베디드 Linux 중 어느 쪽이 더 가볍습니까?
OpenHarmony 쪽이 하한이 더 낮습니다. OpenHarmony의 경량 시스템은 Arm Cortex-M이나 32비트 RISC-V MCU에서 최소 128 KiB 메모리부터 동작하고, 소형 시스템은 1 MiB 이상, 표준 시스템은 128 MiB 이상입니다. 일반적인 임베디드 Linux는 MMU가 있는 프로세서와 수십 MB 이상의 RAM이 전제이므로, MCU 영역까지 같은 OS 체계로 커버할 수 있는 것은 OpenHarmony의 특징입니다. 다만 경량 시스템의 커널은 LiteOS-M이고 표준 시스템의 Linux와는 실행 환경이 전혀 다르므로, 「같은 OS이므로 같은 앱이 동작한다」는 것이 아니라는 점에 주의하십시오.
기존 Windows 장비 소프트웨어를 OpenHarmony로 이식할 수 있습니까?
실질적으로 다시 만들게 됩니다. C#/.NET이나 Win32, COM, WPF/WinForms로 작성된 장비 소프트웨어는 OpenHarmony 위에 대응하는 실행 환경이 없습니다. UI는 ArkTS＋ArkUI, 하부는 C/C++, 드라이버는 HDF(Hardware Driver Foundation)라는 다른 체계로 다시 쓰게 됩니다. 게다가 산업용 카메라나 모션 컨트롤러의 벤더 SDK는 Windows(그다음 Linux)용만 제공되는 경우가 많아, 그 지점이 이식의 실제 병목입니다. 기존 자산을 살리는 전제라면 Windows IoT Enterprise LTSC로 옮기거나, Linux용 SDK가 제공되는 디바이스로 한정한 임베디드 Linux가 현실적입니다.
OpenHarmony 대응을 내세우려면 인증이 필요합니까?
제품으로서 「OpenHarmony 호환」을 표방하려면 OpenAtom 재단의 호환성 평가(인증)를 통과해야 합니다. 기술적 토대는 OpenHarmony의 XTS(X Test Suite)라는 테스트 스위트 군입니다. 다만 내역은 출처에 따라 서술이 다르며, 2026년 7월 시점의 공식 문서는 「현재 지원되는 ACTS(애플리케이션 호환성 테스트 스위트)와 장래 지원될 DCTS(디바이스 호환성 테스트 스위트)」라고 적고 있습니다. 한편 커뮤니티의 인증 절차 자료는 여기에 HATS(하드웨어 추상 계층 호환성)를 더한 구성으로 설명합니다. 공수를 견적할 때는 DCTS를 필수 요건으로 단정하지 말고, 신청 시점에 실제로 요구되는 스위트를 인증 창구에 확인하십시오. 사내 검증만으로 쓰는 경우에는 인증이 불필요하지만, 대외적으로 호환성을 표방하는 제품에서는 필요합니다.
일본어 지원이나 정보는 어느 정도 있습니까?
공식 문서는 중국어와 영어 두 종류이며 일본어판은 없습니다. 커뮤니티 논의도 중국어가 중심입니다. 상용 디스트리뷰션 벤더도 중국 기업이 중심이며, 일본어로 1차 지원을 받을 수 있는 창구는 한정됩니다. 따라서 사내에 중국어 또는 영어 기술 문서를 끝까지 읽을 수 있는 인원이 있는 것이 실질적인 채택 조건입니다. 이 점은 Windows나 주요 Linux 디스트리뷰션과 비교할 때 분명한 차이입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.

문의하기
블로그 목록으로 돌아가기