고객에게 빠르고 효율적인 서비스를 제공하는 이 시스템은, 기술의 발전과 함께 더욱 복잡하고 다양한 기능을 수행하게 되었습니다.
특히 저희 같은 키오스크로 상품만 결제하는게 아닌 통제와 모니터링이 실시간으로 일어나야하는 특수성 때문에 사용기술에 대한 검토를 오랫동안 진행해 왔습니다.
1. 기술의 파편화와 그 해결 방안:
맞춤형 시스템 개발에서 기술의 파편화는 프로젝트의 지속 가능성과 효율성을 저하시킵니다. 이를 해결하기 위해서는 통합적인 기술 전략이 필요합니다. 이는 프로젝트의 범위와 요구 사항을 명확히 하고, 통합된 개발 프로세스를 수립하는 것을 포함합니다.
2. 프레임워크 선택의 중요성:
프레임워크 선택은 시스템의 전반적인 성능, 확장성 및 유지 보수에 근본적인 영향을 미칩니다. 여기서 주요 고려 사항은 프레임워크의 기술적 적합성, 커뮤니티 지원, 그리고 미래 지향적인 개발 가능성입니다. 예를 들어, React나 Node.js와 같은 현대적 프레임워크는 풍부한 라이브러리와 커뮤니티 지원을 제공하며, 키오스크 시스템의 대화형 사용자 인터페이스 개발에 적합합니다.
3. 안정성 확보 전략:
키오스크 시스템의 안정성은 사용자 경험과 직결됩니다. 이를 위해 의존성 관리, 지속적인 통합 및 배포(CI/CD) 시스템 구축, 그리고 철저한 테스팅 프로세스가 필수적입니다. 또한, 시스템은 OS의 변화에 강하게 영향을 받지 않도록 설계되어야 합니다. 이를 위해 컨테이너화 및 가상화 기술을 적용하여, 어플리케이션과 기반 OS 사이의 격리를 강화할 수 있습니다.
4. 미래 지향적 개발:
키오스크 시스템의 개발은 단순히 현재의 요구 사항을 충족시키는 것을 넘어서, 미래의 변화에 유연하게 대응할 수 있는 구조를 갖추어야 합니다. 이를 위해 개발자들은 최신 기술 동향에 주의를 기울이고, 시스템을 지속적으로 업데이트하며, 사용자 피드백을 적극적으로 수집하고 반영해야 합니다.
이런 측면을 저희 개발팀이 고려하면서 정리했던 내용을 공유하려고 합니다.
어플리케이션의 안전에 초점을 맞추다 보니 Chromium의 탑제 여부를 중심으로 보게 되었습니다.
여러 지점들을 운영하면서 가장 크게 느낀점은 업무용 기기들은 지점이나 사용자들이 익숙하지 않다는 겁니다.
아무래도 초기에 키오스크 시장에 도입할때 그런고려가 없었다 보니 회사도 고객도 알수없는 이유들로 문제를 겪게 되었었고 이런저런 문제를 해결하다 보니
"어떠한 상황에서도 어플리케이션이 최종적으로 종료 되어야 한다"에 의존성 라이브러리들과 특히 Chromium의 탑제 여부가 굉장히 중요하다고 결론 내었습니다.
”Chromium을 안쓰고 네이티브로 구현하면 되지“ 라고 하실수 있지만 렌더러를 직접 구현해서 앱을 만들고 사용성과 안전성을 모두 해결하는게 쉬운일이 아니기 때문에 프래임워크를 찾게 되었습니다.
1. Electron:
- Chromium 내장 여부: 내장함.
- 설명: Electron은 Chromium을 내장하여 웹 기술을 이용한 크로스 플랫폼 데스크탑 애플리케이션 개발을 가능하게 합니다.
2. NW.js:
- Chromium 내장 여부: 내장함.
- 설명: NW.js (이전의 node-webkit) 역시 Chromium을 내장하고 있으며, 웹 기술을 사용하여 데스크탑 애플리케이션을 개발할 수 있습니다.
3. Proton Native:
- Chromium 내장 여부: 내장하지 않음.
- 설명: Proton Native는 React Native 기반으로, 네이티브 컴포넌트를 사용하여 데스크탑 애플리케이션을 구축합니다. 따라서 Chromium을 사용하지 않습니다.
4. Flutter (데스크탑 버전):
- Chromium 내장 여부: 내장하지 않음.
- 설명: Flutter는 자체적인 렌더링 엔진을 사용하여 애플리케이션을 구축합니다. Flutter는 웹뷰를 사용할 수 있지만, 기본적으로는 Chromium을 내장하지 않습니다.
5. React Native for Windows:
- Chromium 내장 여부: 내장하지 않음.
- 설명: React Native for Windows는 네이티브 Windows API를 사용하여 애플리케이션을 구축하므로, Chromium을 내장하지 않습니다.
6. Tauri:
- Chromium 내장 여부: 내장하지 않음.
- 설명: Tauri 웹뷰를 사용할 수 있지만, 기본적으로는 Chromium을 내장하지 않습니다.
7. Native Window App
- Chromium 내장 여부: 내장하지 않음.
- 설명: Windows API를 사용하여 애플리케이션을 구축하므로, Chromium을 내장하지 않습니다.
실제로 저희 개발팀은 해당앱으로 모두 구현 테스트를 했고 다들 머리가 아프지만 엄청난 브런치들을 만들어 버렸고 소소하게 다른데 쓰기는 했지만 결론에 도달하여
현재는 프래임워크의 프래임워크를 만들어 버렸습니다 ㅠㅠ😓
시작을 한 제가 잘못입니다. 이 자리를 빌어서 죄송합니다.
여러 기능 중에 IOT 와 사용성에 중요한 부분들만을 끌어다 각기 재연결하고 통신누락과 원격제어, 모니터링 위한 모델들을 별도로 개발 통합해서 만들게 되었고 현재 스페이스포스 앱의 기본 프래임워크가 되었습니다
# 스페이포스 키오스크 프레임워크 예시
spaceKiosk.init({
ready: function(){
console.log("whenReady");
},
}).then(async (spaceElectron) => {
await MSystem.showMainWindow();
});해당 함수로 키오스크 앱이 뚝딱 만들어집니다.
옵션들이 있지만 아직 내부 보안이라서 그래도 개발이 이전과 비교하면 엄~~~~~청 나게 간소화 되었다.
언젠가는 조금도 보안과 안정화가 이루어지면 오픈소스로 공개할 계획을 가지고 있습니다.
OpenJS, 하드웨어사와, van사 기타등등과 협상이 되어야 하겠죠 😅
우리가 흔히 알고 접하는 윈도우앱 과는 많이 다르기 때문에 그 또한 험난한 길이 예상됩니다.
(해주실거죠 대표님?)
꼭! 혹시라도 이쪽업계 종사자 분이나 함께 하고자 하시는 분들은 당부하고 싶은게.
기존의 어플리케이션(앱이던 웹이던) 은 개인을 위해 제공하고 운영하였기 때문에 사용자가 인지하고 문제를 해결할 수 있지만 키오스크 어플리케이션(앱이던 웹이던) 은 불특정 다수가 사용하고 사용법과 인프라, 하드웨어등의 인지가 없기 때문에 훨 ~~~~~~~~ 신 오류와 운영에 자체 처리 로직이 중요합니다.
껐다 켜세요가 없다.!! 사용자는 오류를 해결할 의사가 없다.!! ( 있을 수도 있지만 )
참고로 저희는 와탭으로 모든 로그를 보고 있지만 앱만은 sentry.io 를 쓰고있습니다.
통합할 수 있게 와탭 개발자님들 도와주세요 ~~
자체 프래임워크는 자동으로 sentry.io 가 적용됩니다.
