Windows 앱의 웹 전환, 하지 않는 편이 나은 경우 ── 판단표와 '분할'이라는 현실적 해법

“사내에서 사용하는 Windows 앱을 슬슬 웹으로 만들고 싶다” ── 이런 상담은 해마다 늘고 있습니다. 타당한 동기인 경우도 많지만, 이야기를 들어보면 웹으로 전환하면 오히려 사용하기 불편하고 비용이 더 드는 앱을, 전면적으로 웹 전환하려는 경우가 적지 않습니다.

미리 말해두자면, 이 글은 “웹 전환은 하지 말라”는 이야기가 아닙니다. 여러 거점에서의 이용, 단말 관리 축소 등 웹 전환이 명확히 정답이 되는 상황은 많습니다. 문제는 웹 전환에 맞지 않는 성격의 앱까지 일괄적으로 ‘근대화 = 웹 전환’으로 단정해버리는 것입니다. 이 글에서는 Windows 수탁 개발 현장에서 실제로 판단에 사용하고 있는 “웹 전환을 하지 않는 편이 나은 경우”를 가려내는 방법과, 전부 웹이냐 전부 Windows냐의 양자택일에 머물지 않는 분할이라는 현실적 해법을 정리합니다.

1. 먼저 결론(판단표)

앱 전체가 아니라 앱이 가진 기능·성격별로 판단하는 것이 포인트입니다.

그리고 결론을 먼저 적습니다.

• “웹으로 전환하고 싶다”는 요구에는 대개 서로 다른 세 가지 문제가 섞여 있습니다. 배포의 번거로움·이용 장소의 제약·기술의 진부화입니다. 각각 해결책이 다르며, 웹 전환으로만 해결되는 것은 이 중 일부에 불과합니다(2장).
• 장치 연동·로컬 파일 처리·오프라인 운용이 있는 앱은 그 부분을 웹으로 전환하지 않는 편이 안전합니다. 브라우저는 보안상 로컬 자원 접근을 의도적으로 제한하고 있으며, 이는 웹의 결함이 아니라 설계 사상입니다¹. 우회책이 있더라도 지원 브라우저의 제약이나 운영 복잡화라는 별도의 비용을 끌어들입니다(3~5장).
• 웹 전환은 ‘이식’이 아니라 ‘재구축’입니다. 기존 화면 자산은 그대로 가져갈 수 없고, 완성 후에도 서버 운영이라는 지속 비용이 새롭게 발생합니다. 견적의 전제를 여기에 두지 않으면 도중에 계획이 무너집니다(7장).
• 현실적인 해법은 분할입니다. 열람·집계·리포트는 웹으로, 장치 연동·현장 입력은 Windows에 남기고, 공통 API와 데이터베이스로 연결합니다. 전면 웹 전환보다 작게 시작할 수 있고, 효과가 큰 부분부터 순서대로 진행할 수 있습니다(8장).

2. “웹으로 전환하고 싶다”의 내용을 분해한다

웹 전환 상담을 받으면 가장 먼저 하는 일은 요구 사항의 분해입니다. “웹으로 만들고 싶다”는 말 뒤에는 대개 다음 세 가지 중 하나(또는 여러 개)가 있습니다.

(1) 배포·업데이트의 번거로움을 없애고 싶다. “버전을 올릴 때마다 모든 단말을 돌며 설치하고 있다”는 고민입니다. 이는 웹 전환으로 확실히 해결되지만, 웹으로 전환하지 않아도 해결할 수 있습니다. ClickOnce나 MSIX 같은 자동 업데이트 기능을 가진 배포 방식으로 전환하면, Windows 앱을 그대로 유지하면서 배포 작업을 거의 제로로 만들 수 있습니다. 자세한 내용은 「Windows 앱의 배포 방식을 어떻게 고를까 - MSI / MSIX / ClickOnce / xcopy / 자체 updater의 판단표」에서 정리하고 있습니다. 배포에 대한 고민만이 동기라면 웹 전환은 과잉 투자입니다.

(2) 어디서든·어떤 단말에서든 사용하고 싶다. 여러 거점에서의 이용, 영업처나 자택에서의 접근, 태블릿에서의 조회 ── 이것이야말로 웹 전환의 본령입니다. 다만 여기서도 “모든 기능을 어디서든 사용하고 싶다”는 것인지, “데이터를 어디서든 보고 싶다”는 것인지는 구분해서 확인해야 합니다. 실무에서는 후자인 경우가 많으며, 이 경우 열람·집계 부분만 웹으로 내보내는 분할 구성(8장)으로 충분합니다.

(3) 오래된 기술에서 벗어나고 싶다. “만든 사람이 퇴사했다”, “.NET Framework 상태가 불안하다”는 동기입니다. 이는 정당한 문제의식이지만, 해결책이 반드시 웹 전환인 것은 아닙니다. 어차피 다시 만들 것이라면, 업무의 성격이 데스크톱에 적합하다면 최신 .NET으로 Windows 앱을 재구축하는 선택지도 있습니다(Windows Forms, WPF, WinUI 중 어느 것으로 할까 - 신규 개발, 기존 자산, 배포, UI 표현의 판단표). 또한 웹으로 만든다고 진부화에서 벗어날 수 있는 것은 아니라는 점도 짚어두어야 합니다. IE 전용으로 만들어진 사내 웹 시스템이 IE 종료로 갈 곳을 잃은 사례는 기억에 생생합니다(「IE 모드 의존 시스템 탈피 가이드」). 웹 앱도 프레임워크나 브라우저의 변화에 따라가는 유지보수가 필요하며, “웹으로 만들면 유지보수에서 해방된다”는 것은 아닙니다.

이렇게 분해하면 “웹 전환으로만 해결되는 것”, “웹 전환 외의 방법으로도 해결되는 것”, “웹 전환으로도 해결되지 않는 것”이 보이기 시작합니다. 그런 다음, 이어지는 “웹 전환을 하지 않는 편이 나은 경우”에 해당하는 기능이 없는지 확인해 나갑니다.

3. 사례 1: 장치·주변기기와 직접 연결되어 있다

제조 장치와의 통신, 계측기·검사기로부터의 데이터 수집, 시리얼(RS-232C) 연결 저울·바코드 리더, 특수 프린터의 세밀한 제어 ── 하드웨어와 직접 대화하는 기능을 가진 앱은 그 부분의 웹 전환에 구조적으로 적합하지 않습니다.

이유는 단순합니다. 브라우저상의 코드는 샌드박스라는 격리된 환경에서 동작하기 때문입니다. 웹페이지를 여는 것만으로 단말 내부의 파일이나 기기를 마음대로 건드릴 수 있다면 곤란하므로, 브라우저는 로컬 자원 접근을 의도적으로 차단하고 있습니다. 이는 웹의 결함이 아니라 보안 설계 그 자체입니다. 예를 들어 C#으로 웹 클라이언트를 작성할 수 있는 Blazor WebAssembly에서도 코드는 브라우저의 보안 샌드박스 내에서 실행되며, 파일 시스템 접근이나 임의의 네트워크 연결은 PlatformNotSupportedException이 발생합니다¹. 할 수 있는 일은 브라우저 기능의 범위 내로 제한됩니다².

“Web Serial API나 WebUSB로 브라우저에서 시리얼 통신을 할 수 있지 않은가”라는 반론도 있을 수 있습니다. 실제로 존재하기는 하지만, 지원 브라우저가 한정적입니다. Web Serial API는 Chrome / Edge 등 Chromium 계열에 더해 2026년 5월 출시된 Firefox 151부터 데스크톱 Firefox도 지원하게 되었지만, Safari는 미지원(모바일도 Android용 Chrome이 Bluetooth 경유 시리얼에 부분적으로만 대응)이며, WebUSB는 지금도 Chromium 계열에 한정됩니다³. “어떤 브라우저에서든 사용할 수 있다”는 웹 전환의 최대 장점에 제약을 붙인 데다, 장치 연결 시에는 (적어도 최초 1회나 기기 추가 때마다) 사용자가 브라우저 대화 상자에서 기기를 선택해 허가하는 조작이 전제가 되기 때문에, 업무 시스템의 장치 연동 수단으로는 수지가 맞지 않는 경우가 많은 것이 실정입니다.

또한 “웹 앱 + 각 단말에 상주하는 연동 에이전트”라는 구성으로 우회하는 방법도 있지만, 이는 배포·업데이트가 필요한 Windows 프로그램이 결국 남는 구성입니다. 그 자체가 나쁜 것은 아니며, 오히려 8장에서 다루는 분할 구성의 한 형태이지만, “웹으로 전환하면 단말에 아무것도 설치할 필요가 없어진다”는 당초의 기대와는 다른 것임을 계획 단계에서 공유해 둘 필요가 있습니다.

장치 연동 부분의 설계는 「외부 기기의 상태 확인과 표시의 베스트 프랙티스 - 『접속 중』으로만 끝내지 않는 설계」도 참고하기 바랍니다.

4. 사례 2: 로컬 파일·다른 앱과 깊이 연동되어 있다

다음으로 많은 것이, 단말 내부의 파일이나 다른 애플리케이션과의 연동이 업무의 핵심이 되는 경우입니다.

• 공유 폴더나 로컬 폴더를 감시하여 놓인 파일을 자동으로 처리한다
• 수백·수천 개의 파일을 일괄로 변환·이름 변경·분류한다
• Excel을 실행하여 COM을 통해 리포트를 작성하거나, 기존 Excel 매크로와 연동한다
• 다른 업무 앱과 파일·프로세스 간 통신으로 데이터를 주고받는다

브라우저의 파일 접근은 원칙적으로 “사용자가 그때그때 대화 상자에서 선택한 파일”로 한정됩니다. 사용자 조작 없는 일괄 접근이나, 브라우저를 닫아도 계속 동작하는 상주형 감시는 불가능합니다. 최근의 File System Access API는 사용자가 선택한 폴더 단위의 접근을 가능하게 하고, 선택한 폴더 내의 변경을 페이지를 열어둔 동안만 감시하는 실험적 API(FileSystemObserver)도 등장했지만, 이들은 Chromium 계열에 한정되어⁴ 장치 연동과 동일한 “지원 브라우저를 제한한다”는 문제를 안고 있습니다. 로컬의 다른 프로세스(Excel 등)를 브라우저에서 실행하여 조작하는 수단은 애초에 존재하지 않습니다.

이런 종류의 기능을 웹으로 전환하려면 “파일을 서버에 업로드하게 하고 서버 측에서 처리한다”는 형태로 업무 흐름을 변경해야 합니다. 그렇게 해서 업무가 성립한다면 선택지가 되지만, 기가바이트급 파일을 일상적으로 다룬다, 사외로 반출할 수 없는 데이터를 로컬에서 완결 처리한다, Excel 자산과 밀접하게 결합되어 있다와 같은 사정이 있다면 그 부분은 Windows 앱(폴더 감시·일괄 처리 같은 무인 처리라면 Windows 서비스)으로 남기는 편이 만드는 쪽에도 사용하는 쪽에도 무리가 없습니다. 다만 Excel과의 COM 연동만큼은 배치 위치에 주의가 필요합니다. Microsoft는 서비스 등 무인·비대화형 환경에서의 Office 자동화를 권장하지 않으며 지원하지 않는다고 명시하고 있으므로⁵, Excel을 자동 조작하는 처리는 사용자가 로그인하여 사용하는 데스크톱 앱 쪽에 두거나, Office를 실행하지 않는 Open XML 계열 라이브러리를 이용한 읽기·쓰기로 대체해야 합니다. Excel 연동을 만드는 방법은 「Excel 장표 출력을 어떻게 만들까 - COM 자동화 / Open XML / 템플릿 방식의 판단표」, 폴더 감시는 「FileSystemWatcher 사용법과 주의점 - 누락, 중복 알림, 완료 판정의 함정」에서 다루고 있습니다.

5. 사례 3: 네트워크가 불안정한 현장에서, 멈출 수 없는 업무에 사용한다

웹 앱은 그 구조상 네트워크가 살아있는 것을 전제로 합니다. 서버 사이드 렌더링형 웹 앱은 물론이고, C# 계열에서 인기 있는 Blazor Server도 모든 UI 조작이 서버와의 상시 연결을 거쳐 처리되기 때문에 연결이 끊기면 앱이 동작을 멈춥니다. 오프라인 지원은 없다고 공식 문서에 명시되어 있습니다².

이것이 문제가 되는 것은 다음과 같은 환경입니다.

• 공장·창고·야외 현장: Wi-Fi 전파가 금속 선반이나 기계에 가로막혀 순간적인 단절이 일상적으로 발생
• 멈출 수 없는 라인: 기록·지시 화면이 몇 분만 멈춰도 생산이나 출하에 영향을 미침
• 회선이 가늘고 불안정한 거점: 모바일 회선에 의존하는 가설 사무소, 선상·산간 지역 등

네이티브 Windows 앱은 로컬에 데이터를 가지고 오프라인에서도 동작을 계속하다가 회선 복구 후 동기화하는 구성을 순순히 만들 수 있습니다. 오프라인 동작은 Microsoft 스스로가 네이티브 앱을 선택하는 이유로 꼽고 있는 항목이기도 합니다⁶. PWA(Service Worker)나 클라이언트 측에 데이터를 가지는 설계로 웹 앱을 오프라인 대응시키는 것도 기술적으로는 가능하지만, 동기화·충돌 해결까지 포함해 제대로 만들려면 상당한 추가 투자가 필요하며, “웹으로 전환하면 저렴해진다”는 당초의 기대와는 반대 방향으로 작용합니다.

판단의 핵심은 “네트워크가 30분 끊겼을 때, 그 업무는 기다릴 수 있는가”입니다. 기다릴 수 없다면, 적어도 그 업무를 담당하는 화면은 로컬에서 동작하는 것으로 만들어 두어야 합니다.

6. 사례 4: 키보드 중심의 고속·대량 입력이 업무의 중심

전표 입력, 검품·출하 등록, 콜센터 응대 화면 ── 하루 종일 그 화면을 마주하고 키보드 중심으로 대량의 데이터를 입력하는 유형의 업무입니다. 이 영역은 데스크톱 UI의 완성도가 높아, 웹 전환으로 체감 품질이 떨어지기 쉬운 영역입니다.

• 응답 지연: Blazor Server와 같은 서버 연결형에서는 모든 사용자 조작에 네트워크 왕복이 개입되어 UI 지연 시간이 커집니다². 조작 1회당 수십 밀리초라도, 하루 수천 회의 조작이 이루어지는 입력 업무에서는 “걸리는 느낌”으로 확실히 체감됩니다.
• 키보드 조작의 재현: Enter로 항목 이동, 기능 키 할당, 입력 중 즉시 유효성 검증 같은 “입력 업무의 당연한 것들”은 브라우저의 기본 동작(Enter로 폼 제출, F1으로 도움말 등)과 충돌하면서 만들어야 합니다. 불가능한 것은 아니지만, 데스크톱이라면 프레임워크와 그리드 컴포넌트가 처음부터 갖추고 있는 품질을 추가 비용을 들여 따라잡는 구도가 됩니다.
• 대량 데이터의 그리드: 수만 행을 가상 스크롤로 가볍게 표시하고, 셀 편집·열 고정·복사&붙여넣기까지 대응하는 데스크톱급 그리드를 웹에서 구현하려면 고기능 상용 컴포넌트 도입과 상당한 튜닝이 필요합니다.

열람·승인·가끔의 등록 정도라면 웹 폼으로 충분합니다. 그러나 입력 속도 자체가 업무 생산성에 직결되는 화면은, 웹 전환의 효과(어디서든 사용할 수 있다)를 실제로 누리는지 ── 그 화면은 결국 사무실의 고정석에서만 사용하는 것은 아닌지 ── 를 냉정하게 확인해야 합니다. 사용 장소가 고정되어 있다면 웹 전환으로 얻는 것은 없고 잃는 것만 있습니다.

7. 사례 5: ‘이식’의 견적으로 ‘재구축’을 시작해버린다

지금까지는 기능·이용 형태에 관한 이야기였지만, 마지막은 비용 구조에 관한 이야기입니다. 웹 전환 계획이 도중에 무너지는 전형적인 패턴은 “지금 있는 것을 웹으로 옮긴다”는 이식의 이미지로 견적을 내고, 실제로는 재구축이었다는 것이 나중에 밝혀지는 것입니다.

• 화면 자산은 가져갈 수 없습니다. WinForms나 WPF의 화면 정의·화면 로직을 웹으로 자동 변환하는 현실적인 수단은 없으며, UI는 전 화면을 다시 설계하여 재구축해야 합니다. 화면 수 × 복잡도가 그대로 공수가 됩니다.
• 업무 로직의 전수 조사가 먼저 필요합니다. 오랫동안 운영된 앱은 사양서에 없는 업무 규칙이 코드 안에만 존재하는 경우가 드물지 않습니다. 웹 전환은 그것을 전부 발굴하여 재구현하는 작업을 포함합니다. 이 점은 「VB6 / Access 업무 애플리케이션의 연명과 이전 ── 남기다·감싸다·교체하다 판단표」에서 다룬 “갑자기 전면 재작성하지 않는다”는 원칙이 그대로 적용됩니다.
• 완성 후의 운영 비용이 구조적으로 늘어납니다. 데스크톱 앱의 운영은 단말을 관리하는 것이었지만, 웹 앱에서는 서버(또는 클라우드)의 구축·모니터링·백업·인증서와 보안 갱신이 지속적인 업무로 발생합니다. 사내에 그러한 체계가 없다면 외부 위탁 비용이 매달 발생합니다. 웹 전환의 비용 비교는 초기 개발비뿐 아니라 이 운영 비용까지 포함해서 해야 합니다.
• 보안의 전제가 바뀝니다. 사내 LAN 안에서만 동작하던 앱을 웹으로 만들어 사외 접근을 허용하는 순간, 인증·인가·통신 암호화·공격 대응의 요구 수준이 한 단계 높아집니다. 이 역시 “웹 전환 비용”의 일부입니다.

반복하지만, 이것들은 웹 전환을 부정하는 근거가 아니라 올바른 전제로 견적을 내기 위한 재료입니다. 재구축 비용과 운영 비용을 포함해도 웹 전환의 이점이 이를 상회한다면 진행해야 합니다. 상회하지 않는다면, Windows 앱을 유지한 채 근대화(최신 .NET으로의 이전, 배포 방식 개선, UI 개편)라는 더 작은 투자로 동기의 대부분을 충족할 수 있는지를 먼저 검토합니다.

8. 현실적 해법: 전부 웹이냐 전부 Windows냐의 양자택일에 머물지 않는다

지금까지의 판단을 실무에 적용하면, 대부분의 경우 답은 “전면 웹 전환”도 “현상 유지”도 아닌 분할이 됩니다.

사고방식은 단순합니다. 1장의 판단표를 앱 전체가 아니라 기능별로 적용하는 것입니다.

• 웹으로 내보낼 것: 여러 거점·여러 사람이 보고 싶어 하는 데이터의 열람·검색·집계, 리포트 다운로드, 승인 등의 가벼운 조작. 마스터 관리도 대체로 여기에 포함됩니다.
• Windows에 남길 것: 장치·주변기기와의 연동, 로컬 파일의 감시·일괄 처리, 오프라인에서도 멈출 수 없는 현장 업무, 고속 입력 화면.
• 공통화할 것: 데이터베이스와 업무 로직입니다. 데이터를 일원화하여 웹 앱과 Windows 앱이 모두 동일한 API(또는 DB)를 참조하는 형태로 만듭니다. 이 부분을 공통화해 두면 “현장은 Windows 앱으로 입력하고, 본사는 브라우저로 즉시 확인한다”는, 웹 전환 동기의 대부분을 충족하는 구성이 성립합니다.

이 구성에는 전면 웹 전환에는 없는 실무상의 이점이 있습니다. 한 번에 재구축해야 할 범위가 작다는 점, 효과가 큰 부분(열람 계열)부터 단계적으로 진행할 수 있다는 점, 그리고 현장의 사용 편의성을 떨어뜨리지 않는다는 점입니다. 반대로 Windows 앱과 웹 앱 두 계통을 유지보수하는 체계가 필요해지므로, 대상 앱이 작고 기능도 열람 중심이라면 순순히 전면 웹 전환하는 편이 나을 수도 있습니다. 이 역시 양자택일이 아니라 정도의 문제입니다.

또한 “화면은 웹 기술로 만들고 싶지만 로컬 자원에도 접근하고 싶다”는 요구에는 Electron이나 Blazor Hybrid(WebView2) 같은 하이브리드형이라는 선택지도 있습니다. 브라우저의 샌드박스 제약을 받지 않고 웹 기술의 UI를 사용할 수 있지만, 이는 배포가 필요한 데스크톱 앱이며, “브라우저만으로 사용하고 싶다”는 요구의 답은 되지 않는다는 점만 유의하기 바랍니다.

9. 웹 전환을 결정하기 전의 체크리스트

견적 의뢰나 사내 결재 전에 다음을 확인해 두면 재작업을 줄일 수 있습니다.

1. 동기의 분해: 배포의 번거로움·이용 장소·기술의 진부화 중 무엇이 진짜 과제인가. 배포만이라면 배포 방식 변경으로 충분하지 않은가.
2. 하드웨어 연동 유무: 시리얼·USB·계측기·특수 프린터와 직접 통신하는 기능이 있는가. 있다면 그 부분의 처리 방식(Windows에 남길지/에이전트 구성으로 할지)을 먼저 정한다.
3. 로컬 자원 의존도: 폴더 감시, 파일 일괄 처리, Excel 등과의 프로세스 연동이 있는가. 업무 흐름을 서버 처리형으로 바꿀 수 있는가.
4. 오프라인 요건: 네트워크가 30분 끊겼을 때, 그 업무는 기다릴 수 있는가.
5. 입력 업무의 비중: 하루 종일 키보드로 입력하는 화면이 있는가. 그 화면은 정말로 “어디서든” 사용하는가.
6. 이용자와 장소의 실태: 누가·어디서·무엇을 보고/입력하고 싶은가. “전원이 전 기능을 사외에서” 사용해야 하는지, “본사가 데이터를 보고 싶을 뿐”인지.
7. 운영 체계: 서버의 구축·모니터링·보안 갱신을 누가 담당하는가. 그 비용은 월액으로 얼마인가.
8. 업무 로직의 소재: 사양서는 코드와 일치하는가. 전수 조사에 걸리는 기간을 견적에 포함했는가.

이 중 2~5번에 해당하는 항목이 있다면, 전면 웹 전환이 아니라 분할 구성을 중심으로 검토할 것을 권장합니다. 발주 전 정리 전반에 대해서는 「Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리해야 할 것」도 참고하기 바랍니다.

정리

웹 전환은 도구이지 목적이 아닙니다. 여러 거점에서의 이용이나 단말 관리 축소에는 확실히 효과가 있지만, 장치 연동·로컬 파일 처리는 브라우저의 보안 설계에서 비롯된 제약 때문에 프레임워크 선정이나 구현 노력으로 뒤집기 어렵고, 오프라인 운용·고속 입력은 기술적으로 대응할 수는 있어도 그 구현과 운영의 비용이 “웹으로 전환하면 편해진다”는 당초의 목적과 반대로 작용하기 쉽습니다. 그리고 웹 전환은 이식이 아니라 재구축이며, 완성 후에는 서버 운영이라는 새로운 지속 비용이 추가됩니다.

그렇기 때문에 실무의 판단은 “웹으로 전환할 것인가, 하지 않을 것인가”가 아니라, “어떤 기능을 웹으로 내보내고, 어떤 기능을 Windows에 남기고, 무엇을 공통화할 것인가”라는 설계의 문제가 됩니다. 기존 앱의 전수 조사부터 웹 전환 가능 여부 판단, 분할 구성의 설계까지, 코드와 운영의 실태를 보면서 판단해야 하는 경우가 많으므로, 고민이 되신다면 상담해 주시기 바랍니다.

관련 글

• Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리해야 할 것
• VB6 / Access 업무 애플리케이션의 연명과 이전 ── 남기다·감싸다·교체하다 판단표
• Windows Forms, WPF, WinUI 중 어느 것으로 할까 - 신규 개발, 기존 자산, 배포, UI 표현의 판단표
• Windows 앱의 배포 방식을 어떻게 고를까 - MSI / MSIX / ClickOnce / xcopy / 자체 updater의 판단표
• IE 모드 의존 시스템 탈피 가이드
• 외부 기기의 상태 확인과 표시의 베스트 프랙티스 - 『접속 중』으로만 끝내지 않는 설계
• FileSystemWatcher 사용법과 주의점 - 누락, 중복 알림, 완료 판정의 함정
• Excel 장표 출력을 어떻게 만들까 - COM 자동화 / Open XML / 템플릿 방식의 판단표

관련 상담 분야

합동회사 코무라소프트(小村ソフト)에서는 기존 Windows 앱의 웹 전환 타당성 판단, 웹+Windows 분할 구성 설계, 장치 연동·로컬 처리를 포함한 업무 애플리케이션의 개발·개선에 관한 기술 상담을 다루고 있습니다.

• Windows 앱 개발
• 기존 Windows 소프트웨어 개선·유지보수
• 기술 상담·설계 리뷰
• 문의하기

참고 자료

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

오래된 Windows 앱을 갱신하는 김에 웹으로 전환하는 것이 좋을까요?

'오래되었다'는 이유만으로 웹 전환을 하는 것은 권장하지 않습니다. 웹 전환은 이식이 아니라 재구축에 가까운 공수가 들 뿐 아니라, 웹 애플리케이션에도 기술의 진부화는 존재합니다(사내 웹 시스템이 IE 전용으로 남아버린 사례가 대표적입니다). 판단의 기준은 기술의 신구가 아니라 그 앱의 사용 형태입니다. 여러 거점에서 사용하거나 단말 관리를 줄이고 싶다면 웹 전환의 이점이 나타나지만, 장치 연동이나 로컬 파일 처리가 중심이라면 최신 .NET 버전으로의 이전이나 UI 개선 등 Windows 앱을 유지한 채 근대화하는 쪽이 비용 대비 효과가 맞는 경우가 많습니다.

웹으로 전환하면 배포·설치의 번거로움이 없어지지 않나요?

클라이언트 측 배포 작업은 없어지지만, '배포의 번거로움을 없애고 싶다'는 것만이 동기라면 웹 전환보다 가벼운 해결책이 있습니다. ClickOnce나 MSIX 등 자동 업데이트 기능을 가진 배포 방식으로 전환하면, Windows 앱을 그대로 유지하면서도 각 단말을 돌며 설치하는 작업을 거의 없앨 수 있습니다. 또한 웹으로 전환할 경우, 대신 서버(또는 클라우드)의 구축·모니터링·보안 갱신이라는 지속적인 운영 비용이 새롭게 발생합니다. 없어지는 비용과 늘어나는 비용을 모두 보고 판단해야 합니다.

앱의 일부만 웹으로 전환하는 것도 가능한가요?

가능하며, 실무에서는 오히려 그런 형태가 현실적인 해법이 되는 경우가 많습니다. 전형적인 것은 데이터 열람·집계·리포트·여러 거점에서의 조회는 웹으로 내보내고, 장치 연동·현장에서의 고속 입력·로컬 파일 처리는 Windows 앱으로 남긴 뒤, 양쪽을 공통 API와 데이터베이스로 연결하는 구성입니다. 전면 웹 전환에 비해 한 번에 재구축해야 할 범위가 작고, 웹 전환의 효과가 큰 부분부터 단계적으로 진행할 수 있습니다.

Electron이나 PWA, Blazor Hybrid 같은 중간적인 선택지는 어떤가요?

성격이 다른 것들이 섞여 있으므로 나누어 생각할 필요가 있습니다. Electron과 Blazor Hybrid(WebView2)는 데스크톱 앱으로 동작하기 때문에 브라우저의 샌드박스 제약을 받지 않고 파일이나 장치에 접근할 수 있으며, 화면은 웹 기술로 작성할 수 있습니다. 다만 배포·업데이트가 필요한 데스크톱 앱이라는 점은 변하지 않으므로, '브라우저만으로 사용할 수 있게 하고 싶다'는 요구에 대한 답은 되지 않습니다. 반면 PWA는 작업 표시줄에 고정하는 등 설치된 것 같은 사용감을 주더라도, 내부는 브라우저상의 웹 앱 그대로이며 로컬 자원 접근 제약도 일반 웹 앱과 동일합니다. 무엇을 해결하고 싶어서 웹 전환을 검토하는지를 먼저 분해하는 것이 중요합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.