요즘IT
위시켓
최근 검색어
전체 삭제
최근 검색어가 없습니다.

데스크톱 앱 혹은 윈도우 프로그램*(이하 윈 앱)은 과거 C언어 기반인 Win32 API에서부터 출발했고 GUI 기반 프로그램 개발에 있어 거의 필수적인 매체였기 때문에 많은 사랑을 받았었다.

회원가입을 하면 원하는 문장을
저장할 수 있어요!

다음

회원가입을 하면
성장에 도움이 되는 콘텐츠를
스크랩할 수 있어요!

확인

IT서비스

윈도우 프로그램은 정말로 사라질까?

년차,
어떤 스킬
,
어떤 직무
독자들이 봤을까요?
어떤 독자들이 봤는지 궁금하다면?
로그인

데스크톱 앱 혹은 윈도우 프로그램*(이하 윈 앱)은 과거 C언어 기반인 Win32 API에서부터 출발했고 GUI 기반 프로그램 개발에 있어 거의 필수적인 매체였기 때문에 많은 사랑을 받았었다.

 

윈도우 프로그램이란? 

Windows OS에서 동작하는 GUI 기반 데스크톱 앱을 의미한다. 윈 앱과 웹 앱은 어떤 차이가 있을까? MS 워드를 쓴다고 가정하자. 웹 브라우저로 MS오피스365에 접속해서 사용하는 프로그램은 웹 앱이다. 이와 달리 MS 워드 프로그램을 자기 PC에서 구동해 사용한다면 그 프로그램은 바로 윈 앱이다. 과거에 GUI 기반으로 PC에서 동작하는 프로그램을 개발하려면 Visual Basic, Win32 API, MFC 등을 사용했다. 현재는 WinForm C#, WPF, VB.NET과 같은 닷넷 프레임워크 계열로 개발한다.

 

웹으로 연 MS오피스365는 웹 앱(좌)이다. 윈도우PC에 설치된 MS오피스365는 윈 앱(우)이다 <출처: 작가>

 

하지만 최근에는 자바스크립트와 웹 서비스의 눈부신 발전, 그리고 HTML5와 프론트엔드 프레임워크의 등장으로 인해 웹 앱 기반 작업이 많아졌다. 이와 함께 윈 앱의 영역은 자연스럽게 축소되어왔다. 그에 따라 SI 기업은 웹 앱의 이점들을 인지하며 점차 자신들이 개발해온 솔루션들을 윈 앱에서 웹 앱으로 전환하기 시작했다. 상황이 이렇다보니 ‘윈 앱 개발이 SI 시장에서 사라지는 것이 아니냐’는 의견이 나오기도 했다.

 

그럼에도 불구하고 속단해서는 안 된다. 스마트팩토리 분야에서는 윈 앱 개발이 지금까지도 활발하게 쓰이고 있기 때문이다. 물론 스마트팩토리 개발사들도 웹 앱의 발전을 지켜보아왔다. 다만 그 과정에서 내부 시스템 구조에 어떤 것이 최적의 선택일지, 무엇을 웹 앱으로 할지 윈 앱으로 할지 경험을 통해 결정했을 뿐이다.

 

스마트팩토리 분야에서도 윈 앱의 역할이 많이 줄어든 것은 사실이다. 그러나 여전히 웹 앱으로 전환하기 어려운 역할이 있었기에 완전히 바뀌지는 않았다. 스마트팩토리 개발자로 성장하려면 웹 앱과 윈 앱을 모두 개발할 수 있는 역량을 갖춰야 하는 이유이다. 무엇보다 각 매체를 시스템의 어떤 영역에 배치할 것이냐에 대해, 그 방법론과 구조를 숙지해둘 필요가 있다.

 

본 글은 먼저 윈 앱이 스마트팩토리에서 아직까지 활용되는 이유를 설명할 것이다. 다음으로 크로스플랫폼의 동향을 분석하며 윈 앱이 현재 어떤 위치에 있는지 분석하겠다. 마지막으로는 윈 앱의 전망에 대해 알아볼 예정이다.

 

 

스마트팩토리에서 윈 앱은 어떻게 활용되고 있는가

근래의 웹 앱은 매우 훌륭한 방법론이다. 특히 생산성과 유지보수성, 디자인 등을 고려할 때 IT시스템 개발에 있어서는 거의 필수적인 프레임워크가 되었다.

 

이런 장점에도 왜 스마트팩토리 분야에서는 여전히 윈 앱을 고집하는 경우가 많을까? 그 이유는 공장에서 활용되고 있는 프로그램이 어떤 성격을 가지는지 들여다 보면 충분히 알 수 있다. 지금까지도 생산 현장에서 가동 중인 윈 앱 대부분은 현장에서 작업자들이 조작하는 단말기 프로그램에 집중되어 있다.

 

생산현장 단말기 프로그램의 예시 모습 <출처: 작가>

 

위의 이미지를 보자. 이 프로그램은 저울계와 WinAPI로 연결되어 있다. 바코드스캐너의 경우는 직렬로 연결된다. 온습도계와 TCP/IP로 통신하고 있으며 데이터베이스는 ADO로 연결한 상태다. 또 각각 자원의 투입 시간을 계산하기 위한 멀티스레드 자원도 갖추고 있다. 이 모든 기능은 비동기로 작동한다. 예컨대 라벨을 출력하고 있는 중이라도 다른 모든 기능은 이와 상관없이 동작해야 하며, 바코드를 스캔하고 있더라도 저울계의 값은 문제없이 프로그램에 표현되어야 한다.

 

이런 프로그램을 웹 앱으로 개발해야 한다면, 두 가지 핵심 문제에 봉착하게 된다. 먼저 첫 번째로, 웹 앱의 클라이언트를 제어하는 자바스크립트는 멀티스레드를 지원하지 않는다. 바코드를 스캔하여 데이터를 처리하는 와중에는 다른 기능이 작동하지 않는다는 뜻이다. 물론 node.js의 promise나 async가 있으므로 액션을 비동기로 제어할 수도 있으나 스레드 실행 단위로 이를 제어할 방법은 현재로서는 없다.

 

두 번째는 다중 통신 접점 문제다. 만약 여러 장비를 연동하는 단말기가 10~20대 정도 있다면 어떨까? 연동한 장비들의 통신을 모두 웹 서버 하나에 집중해 연결해야 하므로 서버가 너무 비대해진다. 물론 Redis와 같은 인메모리 DB를 중간자로 두는 경우도 생각해볼 수 있겠다. 그러나 이는 제한적인 임시 방편으로 보인다. 이 역시 단말기들과 Redis가 원격으로 통신하므로 딜레이가 당연히 발생하기 때문이다. 무엇보다 Redis는 싱글스레드라는 제약이 있다.

 

반응 속도 혹은 통신 딜레이 문제는 무엇보다 제조업의 생산성과 관련이 깊다. 보통 고객사는 단말기를 조작할 때 작업자가 프로그램을 “그냥 지켜보는” 시간이 너무 길지 않기를 바란다. 실제로 1~2초 정도의 딜레이만 생겨도 개선을 요구하는 경우가 무척 흔하다. 이렇듯 작업자의 조작 행위는 제조업에서는 상당히 비싼 행위다. 웹 앱을 활용하려고 이런 행위 중간중간 통신 딜레이를 늘리는 것은 바람직하지 않을 것이다.

 

근래 들어 고객사들은 공정별 작업자의 평균 작업 시간의 허용 수준까지 소프트웨어 계약서에 명기하기 시작했다. 그만큼 프로그램의 반응 속도가 스마트팩토리 업계에서 매우 중대한 사안임을 알 수 있다. 통신으로 데이터가 왔다갔다 하는 것보다 되도록 PC 내부 메모리에서 이를 처리하는 것이 가장 빠르고 좋다는 뜻이다.

 

 

크로스 플랫폼 전략

이처럼 스마트팩토리 업계에서는 그 산업의 특성으로 윈 앱을 등한시할 수 없다. 다만 윈 앱은 윈도우 OS에서만 작동한다는 한계를 가지고 있다. Win32 API에 기반한 C# WinForm과 WPF 모두 그렇다. 또 윈도우 OS는 라이센스 때문에 확실히 비용적인 측면에서 부담을 준다.

 

소프트웨어 개발 업체 입장에서도 이런 윈 앱의 특징 때문에 개발 비용이 커질 때도 있다. 개발된 앱이 윈도우 OS에서만 작동한다는 말은 맥과 안드로이드에서는 작동하지 않는다는 말이다. 즉, 단말기의 OS가 달라지면 이에 맞춰 새로 개발을 해야하는 경우도 발생한다.

 

이는 사실 윈 앱과 리눅스 앱 사이 차원에서는 별로 큰 문제가 아니었다. 오히려 정말 큰 문제가 생긴 것은 모바일 쪽이었다. 안드로이드와 맥이라는 모바일 OS의 양대 산맥이 존재하는 상황에서 개발 업체는 각각의 앱을 따로 개발해야 했고, 이 때문에 비효율이 발생했다. 그래서 크로스 플랫폼* 지원을 통해 다양한 OS에서도 앱이 구동하게 지원하는 전략이 등장하게 된다.

 

크로스 플랫폼이란? 

둘 이상의 OS에서 정상 구동을 지원하는 시스템을 의미한다. Flutter, React Native, MAUI와 같이 모바일 중심 라이브러리들이 대표적인 크로스 플랫폼들이다.

 

최근 들어 모바일 쪽의 네이티브 앱 프레임워크(리액트 네이티브, 플러터)들이 등장하며 스마트팩토리 개발사들은 중요한 기로에 서게 되었다고 생각한다. 다시 말해 윈 앱을 개발하기 위해 반드시 Win32 API 기반 개발 도구로만 개발할 필요가 없어졌다는 소리다. 이들 프레임워크로 모바일 앱뿐 아니라 윈 앱도 개발할 수 있기 때문이다.

 

이런 정세에 앞서 개발한 윈 앱 솔루션을 가진 스마트팩토리 개발사들의 입장은 두 갈래로 갈라질 것이다. 윈 앱을 MAUI로 마이그레이션을 할 것이냐, 아니면 네이티브 앱으로 새로 개발할 것이냐, 이다.

 

 

윈도우 프로그램의 미래

GUI 기반 프로그램으로 높은 성능이 필요하거나 타 시스템과 연동을 처리하여 디스플레이 해줘야 할 때, 또는 멀티스레드를 처리해야 할 경우 여전히 윈 앱은 필수적이다. 웹 앱은 꽤 먼 미래에도 웹 브라우저 내부에서 작동할 것이므로 한정된 자원과 싱글 스레드를 사용해야 한다. 이런 웹 앱의 문제가 해결되지 않는 이상 윈 앱은 살아남을 것이다.

 

다만 윈 앱 개발자는 최근 크로스 플랫폼 프레임워크들의 동향을 주목해야 한다. 특히 이런 분위기에서 윈 앱을 MAUI로 마이그레이션 할 것인가, 아니면 모바일 네이티브 앱으로 갈아탈 것이냐라는 중요한 기로에 서는 일이 많아질 것이다.

 

MAUI로 마이그레이션하는 작업은 새로 개발하는 것보다는 비용이 저렴할 수 있다. 다만 이는 향후 마이크로소프트 닷넷의 전략과 지원에 따라 갈릴 문제로 예단하기 어렵다. 개인적인 견해로는 닷넷 MAUI의 장기적인 전망이 그리 밝아보이진 않다. 닷넷 MAUI의가장 큰 문제는 다른 네이티브 앱 프레임워크들에 비해 인기가 떨어진다는 점이다. 특히 이런 경우 마이크로소프트는 지원을 종료할 수 있다. (닷넷 리무팅과 Window CE 모바일이 대표적인 예다.)

 

이와 마찬가지로 모바일 네이티브 앱 프레임워크들 역시 과연 얼마나 오랫동안 살아남을지, 그에 대한 지원이 지속될 수 있는지도 고민해봐야 할 문제다.게다가 윈도우에서 정상적이고 완전한 동작이 되도록 앱을 개발하려면 그만한 관심과 지원이 필요한 법인데, 모바일에 비해 윈도우 지원에 적극적일 것 같지는 않다. 따라서 크로스플랫폼 전략을 고민하는 스마트팩토리 개발 업체라면 당분간 상황을 지켜보며 크로스플랫폼과 윈 앱이 양립하는 상황에 따라 빠르게 대처할 수 있도록 준비해야 한다.

 

또한 인터페이스 관련 라이브러리들의 강력함도 고려해볼 문제다. Win32 API는 아주 오래 살아남아 전통적으로 쓰여 왔다. 이 때문에 오래된 생산 장비들을 연동해야 하는 경우, 여전히 Win32 API 라이브러리에 의존해야 할 때가 많다. 스마트팩토리 분야에서 개발자가 연동해야 할 장비들은 여전히 최신 장비가 아닐 때가 많다는 것도 잘 염두해야 한다.

 

 

마치며

윈 앱은 앞으로도 사라지지 않을 것이다. 다만 현재 윈 앱 개발 업계에서는 크로스플랫폼 지원이 흥행하고 있고 이에 따라 많은 것이 달라지지 않을까 전망한다.

 

그럼에도 지금까지 함께 알아본 내용을 고려했을 때, 아직은 이러한 미래가 정말로 도래할 것인지는 지켜봐야 한다. 또 그런만큼 고전적인 윈 앱 개발 방식은 오랜 기간 살아남을 것으로 보인다. 만약 지금 윈 앱을 개발하며 미래가 불투명하다고 생각하는 주니어 개발자가 있다면, 그 기회가 마찬가지로 매우 중요한 기회라는 점을 인식했으면 한다.

 

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.

좋아요

댓글

공유

공유

댓글 14
kjidrr
            잘 배웠습니다. 감사합니다!
          
2024.05.28. 오후 15:29
DSK
작가
            @kjidrr 감사합니다!
          
2024.05.28. 오후 23:05
제조업 분야 전문 소프트웨어 개발자
63
명 알림 받는 중

작가 홈

제조업 분야 전문 소프트웨어 개발자
63
명 알림 받는 중
제조업분야 SI를 주로 해왔습니다. 주어진 시간에 요구사항을 반영하는 그 짜릿함을 잊지 못해 이 바닥에서 손을 놓지 못하고 있지요. 그 중에 특히 제조업 분야는 가장 짜릿하고 흥미로운 과제들이 많습니다. 물론 이 바닥은 다른 분야보다 상당히 어렵고 다양한 난관들을 헤쳐나가야 합니다. 그럼에도 이 일을 시작하고 싶으시다고요? 좋습니다. 저는 그런 분들을 돕고자 이 곳에 자리를 잡고 글을 쓰기로 했습니다. 같이 가보실까요?

좋아요

댓글

스크랩

공유

공유

요즘IT가 PICK한 뉴스레터를 매주 목요일에 만나보세요

요즘IT가 PICK한 뉴스레터를
매주 목요일에 만나보세요

뉴스레터를 구독하려면 동의가 필요합니다.
https://auth.wishket.com/login