일렉트론 전환기

웹 클라우드 문제점 일렉트론 전환 이유

저희는 병원에 B2B 서비스를 제공하며, 초기에는 클라우드 기반 웹 애플리케이션으로 서비스를 배포하였습니다.
하지만 병원의 여러 요구사항과 사용 환경을 분석한 결과, 클라우드 방식만으로는 충분한 안정성과 사용자 경험을 제공하기 어렵다는 한계가 있었습니다.

이에 따라 Electron을 활용한 데스크톱 애플리케이션으로 전환을 결정하게 되었습니다.

저희가 마주한 전환 이유는 다음과 같습니다.

1. 로그인 유지 문제 – 웹앱에서 지속적으로 로그아웃되는 현상

🔍 발생한 문제
웹앱을 사용하는 과정에서 로그인이 지속적으로 풀리는 문제가 발생하였습니다.
병원에서는 여러 업무를 병행하며 사용해야 하는데, 로그인 상태가 유지되지 않으면 반복적인 로그인 과정이 필요하여 업무 효율성이 크게 저하되었습니다.

📌 PWA의 한계:

웹앱을 PWA(Progressive Web App)로 설치하더라도, 브라우저 환경에 따라 세션 유지 정책이 다르기 때문에 로그인 상태가 일정하지 않았습니다.
또한, Chrome 업데이트 및 정책 변경에 따라 예상치 못한 세션 만료 문제가 발생할 가능성이 높았습니다

2. 알림 문제 – 백그라운드에서 FCM(Firebase Cloud Messaging) 알림이 잘 보이지 않는 문제

🔍 발생한 문제
병원 업무에서는 실시간 알림이 필수적입니다. 예를 들어, 새로운 환자 요청이나 중요한 공지사항이 즉시 전달되어야 하지만, 웹앱 기반으로 FCM을 적용했을 때 백그라운드 상태에서 알림이 크롬의 알림형태로 제공되다 보니 가시성이 떨어진다는 목소리가 많았습니다.

일렉트론 구조

Electron의 구조를 간략히 살펴보면, 메인 프로세스(Main Process)와 렌더러 프로세스(Renderer Process)로 구분되며,
이를 통해 데스크톱 애플리케이션이 웹 기술(HTML, CSS, JavaScript)과 OS의 네이티브 기능을 효과적으로 활용할 수 있습니다.

1. Main Process (메인 프로세스)
Electron 애플리케이션이 실행될 때 가장 먼저 시작되는 프로세스로, 앱의 수명 주기를 관리합니다.
메인 프로세스는 Node.js 환경에서 실행되며, 다음과 같은 역할을 수행합니다.

✅ 애플리케이션 창(Window) 생성 및 관리
✅ 파일 시스템, OS API 등 네이티브 기능 접근
✅ 백그라운드 작업 및 IPC (Inter-Process Communication) 관리
✅ 시스템 트레이, 메뉴, 알림(Notification) 등 운영체제 기능과 상호작용

2. Renderer Process (렌더러 프로세스)
각각의 애플리케이션 창에서 실행되는 개별 프로세스로,
웹 브라우저의 역할을 하며 HTML, CSS, JavaScript로 UI를 렌더링합니다.
일반적인 웹앱과 동일하게 동작하지만, 메인 프로세스와 통신하면서 OS 기능을 활용할 수 있습니다.

✅ UI 렌더링 및 사용자 인터페이스 관리
✅ IPC(Inter-Process Communication)를 통해 메인 프로세스와 데이터 교환
✅ DOM 조작 및 이벤트 핸들링

3. IPC (Inter-Process Communication) - 프로세스 간 통신
메인 프로세스와 렌더러 프로세스는 서로 직접 접근할 수 없으며, IPC를 이용해 데이터를 주고받습니다.

초기 일렉트론 구조

초기에는 React로 구성된 프로젝트를 기반으로 Electron으로 패키징하는 구조를 만들었습니다.
이를 통해 기존 웹 애플리케이션의 UI 및 기능을 유지하면서도 데스크톱 환경에서 안정적인 실행이 가능하도록 구축하였습니다.

Electron의 기본적인 배포 구조를 설정한 후, electron-updater를 활용하여 자동 업데이트 기능도 함께 구현하였습니다.
이를 통해 새로운 기능이 추가되거나 버그가 수정될 경우, 사용자가 수동으로 업데이트하지 않아도 자동으로 최신 버전을 받을 수 있도록 설정하였습니다.

Electron의 자동 업데이트 기능은 일반적인 애플리케이션 환경에서는 앱이 재시작될 때 업데이트를 확인하고 적용하는 방식으로 동작합니다.
그러나 병원에서는 다음과 같은 업데이트 적용의 어려움이 있었습니다.

1. 병원 시스템의 특성상 종료 시점이 없음
   ✅ 병원의 시스템은 24시간 운영되며, 특정 사용자가 주기적으로 앱을 종료하거나 다시 실행할 일이 거의 없음
   ✅ Electron의 자동 업데이트는 앱을 재시작해야 적용되는데, 병원의 업무 환경에서는 재시작이 어려운 상황
   ✅ 즉, 새로운 업데이트가 릴리즈되어도 사용자가 앱을 닫고 다시 실행하지 않으면 적용되지 않음

2. 초기 서비스 업데이트 빈도가 높았음
   ✅ 서비스 초기에 자주 업데이트가 필요했으며, 중요한 기능 추가 및 버그 수정이 잦았음
   ✅ 하지만 병원의 업무 흐름상 즉각적인 업데이트 적용이 불가능하여, 최신 기능이 반영되지 않는 문제 발생
   ✅ 중요한 보안 패치나 긴급 버그 수정이 있어도, 사용자가 앱을 다시 실행하지 않으면 반영되지 않아 업무 차질 발생 가능

3. 업데이트가 적용되지 않은 상태에서 충돌 및 오류 발생
   ✅ 업데이트가 정상적으로 이루어지지 않은 상태에서, 구버전과 서버 API 간의 호환성이 깨지는 문제 발생
   ✅ 병원의 여러 기기에서 서로 다른 버전을 실행하면서, 데이터 동기화 및 UI 불일치 현상이 발생
   ✅ 특정 기능이 최신 API를 사용해야 하는데, 구버전에서는 해당 API가 없어 비정상적인 동작 발생

이런상황이기에 웹뷰를 도입하는 방향으로 전환 했습니다.

최종 일렉트론 구조

🔧 최종 Electron 구조
초기에는 React 기반의 프로젝트를 Electron으로 패키징하는 방식으로 구축하였지만, 병원의 특수한 업무 환경을 고려하여 웹뷰(WebView) 구조를 도입하였습니다.

✅ 메인 프로세스는 그대로 유지하면서, 렌더러 프로세스에서 웹뷰(WebView)를 사용하여 웹앱을 로드
✅ 최신 기능이 추가될 때마다 애플리케이션 자체를 업데이트할 필요 없이, 웹 서버에서 즉시 반영 가능
✅ Electron을 통해 네이티브 기능(알림, 파일 접근, 트레이 아이콘 등)을 그대로 활용하면서, 웹앱의 유연성을 확보

📌 최종 구조 다이어그램

Main Process → 애플리케이션 관리, 자동 업데이트, 네이티브 API 호출
Renderer Process → 웹뷰(WebView) 기반으로 React 웹앱을 로드
Electron의 네이티브 기능 → 로그인 유지, FCM 알림, OS 연동 기능 유지

일렉트론 자동 업데이트

CareFlow Electron 앱은 GitHub Releases를 활용하여 자동 업데이트 기능을 구현했습니다. 이를 통해 병원 현장에서도 사용자는 별도의 수동 업데이트 없이 항상 최신 기능과 패치를 받을 수 있습니다.

✅ autoUpdater 모듈 활용
Electron의 electron-updater 패키지를 이용해 자동 업데이트 로직을 구성했습니다. 앱 실행 시 버전 체크를 수행하고, 새로운 릴리즈가 감지되면 다운로드 후 재시작 시 자동으로 반영됩니다.

✅ GitHub Releases 연동
배포는 GitHub의 릴리즈 페이지를 통해 진행되며, 최신 버전의 .dmg(macOS), .exe(Windows) 파일을 포함한 릴리즈가 올라가면 자동으로 앱 내부에서 감지됩니다.

✅ 무중단 배포 경험 제공
백그라운드에서 업데이트를 다운로드하고, 사용자에게는 알림(Notification)만 표시되도록 하여, 사용성 저하 없이 부드러운 업데이트 경험을 제공합니다.

✅ 보안성과 확장성 확보
자동 업데이트와 웹뷰 구조를 결합함으로써, 클라이언트 앱은 Electron의 안정성과 네이티브 기능을 유지하면서, 대부분의 비즈니스 로직은 웹에서 신속하게 대응할 수 있도록 분리되었습니다.