장치에 탑재할 OS로서 OpenHarmony는 선택지가 될 수 있는가 ── Windows IoT·임베디드 Linux와의 비교

지난 글 「OpenHarmony란 무엇인가」에서는 OpenHarmony·HarmonyOS·HarmonyOS NEXT라는 세 가지 실체를 구분했습니다. 여기서부터는 실무 이야기입니다. 장치에 탑재할 OS로서, OpenHarmony는 정말로 선택지에 들어갈 수 있는가.

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

덧붙여 이 글은 ‘OpenHarmony를 추천하는 글’도 ‘OpenHarmony를 그만두라는 글’도 아닙니다. 당사가 평소 다루는 것은 Windows 장치 소프트웨어이지만, 선택지를 제대로 비교하지 못한 채 ‘새로운 기술이니까’ 또는 ‘중국발이니까’라는 이유만으로 판단이 정해지는 장면을 여러 번 보아 왔습니다. 판단 재료를 갖추는 것이 이 글의 목적입니다.

1. 먼저 결론

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

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

보시는 바와 같이, OpenHarmony가 ◎가 되는 것은 리소스 하한과 기기 연동이라는 2개 축이며, 기존 자산·SDK·일본어 정보 3개 축은 ×입니다. 이 형태는 ‘우열’이 아니라 ‘맞아떨어지는 조건이 한정적’이라는 것을 나타냅니다. 어떤 조건이면 맞아떨어지는지는 8장의 판단표에서 개별적으로 제시합니다.

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

비교를 시작하기 전에 대상을 명확히 하겠습니다. ‘OS’라고 한마디로 말해도 계층이 다른 것을 나란히 놓으면 논의가 맞물리지 않습니다.

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

여기서 짚어야 할 것은, OpenHarmony는 Windows IoT처럼 ‘사서 그대로 탑재하는 완성품’이 아니다라는 점입니다. 위치상으로는 Yocto에 가까우며, ‘이것을 토대로 자사 제품용 구성을 만드는’ 프레임워크입니다. 다만 Yocto와 달리, UI 프레임워크와 앱 모델까지 일체로 정해져 있는 만큼, 상위 계층까지 이미 쌓여 있습니다.

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

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

3. 지원 기간 비교 ── 장치의 시간축에 맞는 것은 무엇인가

장치에 내장되는 PC나 보드는 장치 본체와 동일하게 10년 전후의 라이프사이클 동안 계속 동작할 것이 요구됩니다. 이 관점에서 각 선택지를 나란히 놓으면 차이는 명백합니다.

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

• OpenHarmony: Version Lifecycle Management(생명주기 관리 정책)와 Version Definitions(브랜치 종류와 유지보수 일정표)¹³
• Windows: Microsoft Lifecycle(제품별 라이프사이클)²
• Debian: Debian Wiki LTS¹⁰
• Yocto Project: Releases¹¹

특히 OpenHarmony는 뒤에서 설명하듯 5.x 계열·6.x 계열이 유지보수 일정표에 아직 등재되어 있지 않습니다. 이 표에 없는 버전을 검토할 경우에는 기간이 미확정이라는 전제로 보시기 바랍니다.

추가로 짚어야 할 점이 두 가지 있습니다.

첫째. OpenHarmony의 ‘수동 유지보수 기간’은 품질이 떨어집니다. 공식 생명주기 관리 정책에 따르면, 주동 유지보수 기간에는 커뮤니티가 태그 버전을 계획적으로 출시하여 결함과 보안 취약점을 수정하지만, 수동 유지보수 기간에 들어가면 태그 버전의 계획·출시는 이루어지지 않고 심각도 이상의 보안 취약점과 결함만이 수정 대상이 됩니다.¹ 즉 실질적으로 ‘안심하고 사용할 수 있는 기간’은 Release 브랜치는 1년, LTS는 2년으로 봐야 합니다.

둘째. 최근 LTS 브랜치가 나오지 않고 있습니다. 공식 유지보수 일정표에 등재된 LTS는 3.0-LTS(2021년 9월)가 마지막이며, 3.1·3.2·4.0·4.1은 모두 Release 종류입니다.³ LTS 자체는 그 이전에도 나온 바 있으며, 릴리스 노트 색인에는 1.1.0 LTS(2021년 4월)와 그 계열이 남아 있지만, 모두 End of Life 상태입니다.⁴ 게다가 5.x 계열과 6.x 계열은 이 유지보수 일정표에 아직 기재되어 있지 않습니다. 10년의 장치 라이프사이클을 전제로 하면, ‘어느 분기에 얼마만큼의 유지보수가 붙는지’를 릴리스마다 예측할 수 없는 상태가 계속되고 있는 셈입니다.

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

이것은 OpenHarmony의 품질이 낮다는 이야기가 아닙니다. 이 유지보수 모델은 ‘커뮤니티판을 그대로 제품에 탑재하여 방치’하는 사용 방식을 상정하지 않았을 뿐입니다. 실제 산업 채택에서는 상용 배포판 벤더가 자체적으로 분기를 유지보수하며, 유지보수를 유상으로 제공합니다. 채택 검토 시 확인해야 할 것은 ‘OpenHarmony의 지원은 몇 년입니까’가 아니라, ‘그 배포판의 벤더는 어느 브랜치를, 언제까지, 어떤 SLA로 유지보수합니까’입니다.

4. 하드웨어 선택지

커뮤니티가 지원을 공표한 개발 보드는 22종입니다.¹³ 장치와 관련이 있을 만한 것을 추려내면 다음과 같습니다.

중요한 것은 SoC 벤더가 중국계만은 아니라는 점입니다. NXP i.MX8M Mini나 ST의 STM32 시리즈가 지원 목록에 포함되어 있는 것은, 일본 장치 제조사에게 현실적인 의미가 있습니다. 이미 채택 실적이 있는 SoC 패밀리로 검토할 수 있는 가능성이 있기 때문입니다.

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

• 지원 보드 목록과 실제로 구할 수 있는 산업용 보드는 별개입니다. 여기에 실린 것은 평가 보드가 중심이며, 10년 공급 보증이 붙은 산업용 보드에 OpenHarmony가 공식적으로 탑재되어 있는지는 별도로 확인이 필요합니다. 표의 ‘예상 용도’는 문서상의 위치일 뿐, 공급 보증도 일본 국내 유통의 근거도 아닙니다.
• 입수 가능성은 일본에서 개별적으로 확인해야 합니다. 이 목록의 보드는 중국 시장 대상이 중심이며, 국내 대리점에서 일반적으로 구매할 수 있다고는 할 수 없습니다. 평가 기기를 준비하기 전에 (1) 보드 벤더의 판매 페이지와 국경 간 전자상거래에서의 취급 여부, (2) 국내 판매 대리점의 유무, (3) 양산 시 최소 로트와 공급 연수, 이 세 가지를 문의를 통해 확인하시기 바랍니다. 이 부분에서 막히면 이후의 기술 검증은 모두 멈추게 됩니다.
• 자사 하드웨어에 탑재하려면 포팅이 자사 작업이 됩니다. Windows IoT라면 ‘OEM 대리점을 통해 라이선스를 구매하고, 드라이버는 벤더가 공급’하는 것으로 끝나는 부분이, OpenHarmony에서는 자사 또는 디스트리뷰터의 작업이 됩니다.
• 드라이버의 취급은 ‘어디에서 사용하는가’에 따라 달라집니다. OpenHarmony는 HDF(Hardware Driver Foundation)라는 통합 드라이버 기반을 갖추고 있으며, 이는 플랫폼 비의존·커널 비의존 설계로 모든 시스템 타입에 적용됩니다.⁹ 다만 표준 시스템의 커널은 Linux이므로, 기존 Linux 커널 드라이버를 그대로 탑재하고 V4L2나 입력 디바이스 같은 일반적인 Linux 인터페이스를 통해 사용하는 것 자체는 가능합니다. 대응 작업이 필요해지는 것은 해당 디바이스를 OpenHarmony의 시스템 서비스나 프레임워크에서 HDI를 통해 다루게 하고 싶은 경우입니다. 기존 Linux BSP가 있다면 ‘모든 드라이버를 HDF로 다시 작성한다’고 가정할 필요는 없습니다. 어느 디바이스를 OpenHarmony의 프레임워크에 노출시킬지를 먼저 정하고, 그 범위만을 공수에 반영하시기 바랍니다.

덧붙여, 보드 조달 단계에서 막혀 있어도 검증은 시작할 수 있습니다. 실기를 구매하기 전에 QEMU로 구조와 부팅 흐름을 확인하는 절차를 9장에서 소개합니다. 또한 자사 기판의 SoC가 이미 정해져 있다면, 평가 보드를 찾기보다 해당 SoC로의 포팅 공수를 산정하는 쪽이 더 실질적인 경우도 있습니다.

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

장치 소프트웨어 자산이라는 관점에서 보면 이야기는 단순합니다. 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를 통한 절차입니다.¹⁴ 소스 취득은 repo 도구로 이루어지며, gitcode.com·gitee.com·GitHub의 미러가 안내되어 있습니다.¹⁵

6. 라이선스와 지적재산

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

‘OpenHarmony는 Apache 2.0이니까 안심’이라고 뭉뚱그려 버리면, 표준 시스템 커널 부분의 GPL 의무를 간과하게 됩니다. 장치에 탑재하는 범위의 저장소를 나열하고 LICENSE를 하나씩 확인하는 것이 원칙입니다. 이 점은 Windows IoT(상용 라이선스 하나로 완결)와의 실무적인 차이가 됩니다.

GPLv2에 대해 한 가지 보충하겠습니다. 의무가 발생하는 것은 배포(distribution)의 시점이며, 수정한 시점이 아닙니다. 사내 검증기에서 커널을 수정하여 동작시키는 것만으로는 제공 의무가 발생하지 않으며, 그 장치를 고객에게 납품한 단계에서 배포한 바이너리에 대응하는 소스 코드를 배포처에 제공할 의무가 발생합니다. 장치 제조사에게는 ‘납품＝배포’이므로 결국 대응이 필요해지지만, 사내 시제품 단계부터 공개 의무가 있는 것은 아니라는 구분은 짚어 두시기 바랍니다(구체적인 적합 방법은 자사의 법무·지적재산 부서와 확인하시기 바랍니다).

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

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

한편, 커뮤니티의 인증 절차 자료에서는 XTS를 ACTS·HATS(하드웨어 추상화 계층 호환성)·DCTS의 3가지 축으로 설명하고 있어, 공식 문서의 기술과 어긋납니다.¹⁹ 신청자가 자사에서 적합 개발과 셀프 테스트를 수행하고, 테스트 리포트를 첨부하여 신청한다는 흐름 자체는 공통입니다.

공수를 산정할 때는 DCTS를 필수 요건으로 단정하지 마시기 바랍니다. 어느 스위트가 신청 시점에 실제로 요구되는지는 인증 창구에 직접 확인하는 것이 확실합니다. 이러한 ‘공식 문서와 커뮤니티 자료가 일치하지 않는’ 상황은 일본어 1차 정보가 없다는 점과 더불어, 채택 시의 커뮤니케이션 비용으로 미리 예상해 두어야 할 부분입니다.

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

8. 판단표 ── 채택해도 좋은 조건, 보류해야 할 조건

판단표에 들어가기 전에, 거기에 이르는 판정의 흐름을 한 장으로 정리해 두겠습니다. 전제를 확인하는 순서가 중요하며, 시장·제품 요구사항이 먼저이고 기술 검토는 그다음입니다. 기술적으로 만들 수 있더라도 유지보수를 계약으로 확정할 수 없다면 장치에는 탑재할 수 없습니다.

flowchart TD
    S["장치에 탑재할 OS를 선택한다"]
    Q1["중국 시장 대상 제품인가, 또는<br/>요구사항이 OpenHarmony 호환 지정인가"]
    Q2["DSoftBus를 이용한 여러 기기 간 연동이<br/>제품 가치의 핵심인가"]
    Q3["주변 기기와 미들웨어의<br/>벤더 SDK가 OpenHarmony에서 갖춰지는가<br/>갖춰지지 않는 부분은 자체 개발이 가능한가"]
    Q4["유지보수를 계약으로 확정할 수 있는가<br/>상용 배포판 벤더의 지원, 또는<br/>자체 CVE 대응 체제 확보"]
    Q5["중국어 또는 영어 기술 문서를<br/>끝까지 읽어낼 수 있는 인력이 있는가"]
    OH["OpenHarmony를 정면으로 검토<br/>상용 배포판을 통해 조달"]
    OTH["Windows IoT LTSC 또는 임베디드 Linux<br/>기존 자산과 벤더 SDK 지원 여부로 결정"]
    NG["OpenHarmony는 보류"]

    S --> Q1
    Q1 -->|"예"| Q3
    Q1 -->|"아니오"| Q2
    Q2 -->|"예"| Q3
    Q2 -->|"아니오"| OTH
    Q3 -->|"갖춰짐 / 자체 개발 가능"| Q4
    Q3 -->|"갖춰지지 않음"| NG
    Q4 -->|"확정 가능"| Q5
    Q4 -->|"확정 불가"| NG
    Q5 -->|"있음"| OH
    Q5 -->|"없음"| NG
    NG --> OTH

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

분기 중 Q3(벤더 SDK)와 Q4(유지보수 계약)에서 탈락하는 사례가 실제로 많다는 것이 이 글의 요지입니다. 아래 판단표는 이 그림의 각 분기를 구체적인 상황으로 전개한 것입니다.

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 등의 에뮬레이션 환경에서 빌드와 부팅 흐름을 확인할 수 있습니다.²⁰
4. 유지보수 분기 고정과 빌드 재현성 확보. repo의 매니페스트를 고정하고(태그 지정이 확실합니다), 사내 미러를 보유하여 5년 후에도 동일한 바이너리를 재생성할 수 있는 상태를 만듭니다.¹⁵ 업스트림 호스팅이 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를 넣어야 하는가」에서 정리했습니다.

관련 글

• OpenHarmony란 무엇인가 ── HarmonyOS·HarmonyOS NEXT와의 차이를 정리한다
• 산업용 PC에는 어떤 Windows를 넣어야 하는가 ── Windows IoT Enterprise / LTSC 실전 가이드
• Windows 10 지원 종료 이후의 현실적 해법 ── ESU·LTSC·교체 판단표
• 키오스크 모드로 업무 단말을 지키다 ── Assigned Access・Shell Launcher 선택법과 운영 설계

관련 상담 영역

합동회사 코무라소프트에서는 장치에 탑재할 실행 기반의 선정 지원, 기존 Windows 장치 소프트웨어의 이전 가능 여부 판별, 장기 가동을 전제로 한 구성 리뷰를 다루고 있습니다. ‘새로운 OS가 후보로 올라왔지만 사내에 비교할 자료가 없다’는 단계부터 상담받으실 수 있습니다.

• 기술 상담·설계 리뷰
• 소프트 리얼타임 Windows 앱 개발
• Windows 앱 개발
• 문의하기

참고 링크

</content>

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

산업기기의 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.