로봇팔을 제어하는 소프트웨어를 JavaScript로 만든다고 하면, 많은 분들이 놀랍니다. CES 혁신상을 수상한 슈퍼노바 휴니트 로봇 제어 소프트웨어가 이 접근의 대표 사례입니다. "웹 기술로 하드웨어를 제어할 수 있나요?" 네, 가능합니다. 그리고 최근에는 합리적인 선택이 되는 경우가 꽤 있습니다.

전통적인 디바이스 소프트웨어

산업용 디바이스, 로봇, IoT 기기의 제어 소프트웨어는 전통적으로 C++, C#, Qt 같은 네이티브 기술로 개발됩니다. 네이티브의 강점은 명확합니다. 하드웨어에 직접 접근하고(시리얼 통신, USB, GPIO), 실시간에 가까운 성능을 내고, OS 레벨에서 자원을 촘촘히 관리할 수 있습니다.

하지만 현실에서 마주치는 문제도 있습니다. Windows와 macOS 양쪽을 지원하려면 코드가 두 벌이 되고, UI 개발 속도가 느린 편이며, 시니어 C++/Qt 개발자 풀이 점점 얇아지고 있습니다. 자동 업데이트 배포도 웹 계열 대비 손이 많이 갑니다.

Electron: 웹 기술로 데스크톱 앱

Electron은 웹 기술(HTML/CSS/JavaScript)로 데스크톱 애플리케이션을 만드는 프레임워크입니다. VS Code, Slack, Discord, Figma — 우리가 매일 쓰는 앱 상당수가 Electron으로 만들어져 있습니다.

디바이스 소프트웨어에 Electron을 쓰는 이유는 비교적 단순합니다. macOS와 Windows를 한 벌 코드로 지원할 수 있고, React/Vue 같은 모던 프레임워크로 UI 개발 속도가 빠르고, Node.js를 통해 시리얼 통신·USB·파일 시스템 같은 네이티브 API에도 접근할 수 있습니다. 개발자 풀이 C++ 대비 훨씬 넓고, 자동 업데이트 기능이 프레임워크 레벨에 내장되어 있다는 점도 실무에서 크게 체감됩니다.

실제 사례: 슈퍼노바 휴니트(Hunuit) — CES 혁신상 수상

프로덕트 메이커(구 모슈)가 개발한 슈퍼노바의 휴니트(Hunuit) 소프트웨어가 대표적인 사례입니다. 이 제품은 CES 혁신상(Innovation Award)을 수상했습니다. 휴니트는 로봇팔(6축 다관절), 로봇 카메라, 레이저 프린터, AI 비전 시스템을 하나의 Electron 앱에서 통합 제어합니다. macOS와 Windows 양쪽에서 동작하며, COLAB 연동·로그인·커뮤니티 기능까지 하나의 소프트웨어에 들어가 있습니다.

"웹 기술로 로봇팔까지 제어한다"는 말이 생소할 수 있지만, 실제로는 UI와 디바이스 통신을 잘 분리해 두면 충분히 현실적인 선택이 됩니다.

오픈소스 생태계의 힘

웹 기술을 선택하는 또 다른 이유는 오픈소스 생태계입니다. npm에 공개된 JavaScript/TypeScript 라이브러리는 수백만 개에 달합니다. 시리얼 통신, USB 제어, 블루투스, MQTT, gRPC — 디바이스 통신에 필요한 대부분의 프로토콜이 이미 오픈소스 라이브러리로 존재합니다.

C++/Qt로 개발하면 이런 기능을 직접 구현하거나 제한된 상용 라이브러리에 의존해야 하는 경우가 많습니다. 웹 기술에서는 검증된 오픈소스를 가져다 쓰고 핵심 비즈니스 로직에 집중하는 전략이 가능합니다.

AI가 발달하더라도, G-code 파서·고성능 차트 라이브러리·3D 렌더링 엔진처럼 수십만~백만 라인 규모의 코드는 AI로 쉽게 대체되지 않습니다. 오픈소스 생태계에서는 이미 검증된 구현을 그대로 가져다 쓸 수 있습니다. 기술 선택 시 "이 기술 생태계에서 우리가 필요한 것들이 이미 공개되어 있는가"를 확인하는 것도 꽤 중요한 판단 기준입니다.

언제 웹 기술이 적합한가

모든 디바이스 소프트웨어에 Electron이 맞지는 않습니다. 웹 기술이 잘 맞는 경우는 디바이스 제어와 대시보드·관리 UI가 모두 필요한 서비스, macOS와 Windows 양쪽 지원이 필요한 서비스, UI가 복잡하거나 자주 바뀌는 서비스, 클라우드 API·실시간 데이터 연동이 중심인 서비스, 빠른 프로토타이핑 후 점진적 개선이 핵심인 서비스입니다.

반대로 네이티브가 필수인 영역도 분명히 있습니다. 마이크로초 단위의 실시간 제어가 필요한 산업용 PLC, 극도로 제한된 리소스의 임베디드 환경, GPU를 직접 제어해야 하는 게임 엔진·영상 처리 영역입니다. 대부분의 "디바이스를 제어하면서 사용자에게도 보여주는" 소프트웨어는 웹 기술로 충분합니다.

아키텍처 설계

Electron으로 디바이스 소프트웨어를 만들 때의 기본 아키텍처는 대체로 비슷합니다.

렌더러 프로세스(UI)에서는 React/Vue로 대시보드·제어 패널·설정 화면을 구성합니다. 웹 프론트엔드 개발과 동일한 방식입니다.

메인 프로세스(디바이스 통신)에서는 Node.js의 시리얼 포트(SerialPort), USB(node-usb), TCP/UDP 소켓 등으로 디바이스와 통신합니다. 하드웨어 제어 로직이 여기에 들어갑니다.

UI와 디바이스 통신은 Electron의 IPC로 연결됩니다. 예를 들어 UI에서 "로봇팔 이동" 버튼을 누르면 IPC → 메인 프로세스 → 시리얼 통신 → 로봇팔 동작의 흐름을 탑니다.

"웹 기술이면 느리지 않나요?"

가장 많이 받는 질문입니다. UI 렌더링과 디바이스 제어를 분리하면, 성능 병목은 거의 발생하지 않습니다. 디바이스 통신은 Node.js의 네이티브 모듈(C++ 바인딩)로 처리되기 때문에, 순수 C++ 구현과의 성능 차이가 미미한 구간이 많습니다.

VS Code가 수십만 줄의 코드를 실시간으로 분석하면서도 쾌적하게 동작하는 것처럼, 설계만 맞게 잡으면 Electron 앱의 성능은 대체로 충분합니다.

선택지가 생각보다 많다

디바이스/데스크톱 소프트웨어를 만드는 기술은 의외로 다양합니다. 크로스플랫폼 쪽에서는 Electron, Tauri(Rust 기반, 앱 크기가 Electron보다 훨씬 작음), Flutter Desktop(Google의 크로스플랫폼, 모바일 앱과 코드 공유), .NET MAUI(C# 생태계), Qt(QML)(산업용에서 여전히 강세) 등이 실무적인 후보군입니다.

네이티브 쪽은 Swift/SwiftUI(macOS 전용), C# / WPF / WinUI(Windows 전용), C++ / Win32 / Cocoa(최고 성능, 최고 난이도), Java/Kotlin(JVM 기반)이 있습니다.

중요한 건 이 목록을 외우는 게 아니라, 제품의 요구사항을 기준으로 고르는 눈입니다. 절대 오류가 나면 안 되는 소프트웨어(심장박동기·항공 제어·원자력 시스템)에서는 안정성과 검증이 최우선이라 C/C++·Ada 같은 언어와 수십 년간 검증된 도구 체인을 씁니다. Electron으로 심장박동기를 만들 사람은 없습니다.

반대로 스타트업 MVP처럼 생산성이 핵심인 소프트웨어는 Electron이나 Flutter Desktop으로 빠르게 만들고 사용자 반응을 보며 개선하는 쪽이 유리합니다. macOS와 Windows 양쪽 지원이 필수면 Electron·Tauri·Flutter Desktop 같은 크로스플랫폼이 현실적입니다. 게임 엔진이나 영상 편집처럼 극한 성능이 필요한 영역은 여전히 C++로 GPU를 직접 다뤄야 합니다. 기존 웹 서비스와 데스크톱 앱을 함께 가져갈 때는 Electron이 기존 코드 재사용 측면에서 가장 효율적입니다.

정리

"디바이스/로봇 소프트웨어는 C++"이라는 공식은 더 이상 절대적이지 않습니다. UI 비중이 큰 디바이스 소프트웨어는 웹 기술 쪽이 생산성에서 유리하고, 크로스플랫폼이 필요하면 Electron·Tauri·Flutter Desktop 같은 선택지가 많습니다. 디바이스 제어 성능은 네이티브 모듈로 보완이 되고, 절대 안정성이 필요한 영역에서는 여전히 전통적 네이티브가 정답입니다.

기술 선택의 기준은 "전통적으로 뭘 썼냐"가 아니라, "이 제품의 핵심 요구사항이 무엇이냐"입니다.

*디바이스/IoT 소프트웨어 개발에 대해 상담이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요.*