Windows 앱의 Web화, 하지 않는 편이 나은 경우 ── 판단표와 ‘분할’이라는 현실적 해법

「사내에서 쓰는 Windows 앱을 이제 Web으로 바꾸고 싶다」──이런 상담은 해마다 늘고 있습니다. 타당한 동기인 경우도 많은 한편, 이야기를 들어 보면 Web화하면 오히려 쓰기 어렵고 비용이 더 드는 앱을 전면 Web화하려고 하는 경우가 적지 않습니다.

미리 말해 두면, 이 기사는 「Web화는 하지 말라」는 이야기가 아닙니다. 여러 거점에서의 이용이나 단말 관리 축소처럼 Web화가 명확히 정답이 되는 상황은 많이 있습니다. 문제는 Web화가 맞지 않는 성질의 앱까지 한데 묶어 「현대화 = Web화」로 정해 버리는 것입니다. 이 기사에서는 Windows 수탁 개발 현장에서 실제로 판단에 쓰는 「Web화하지 않는 편이 나은 경우」의 가려내는 법과, 전부 Web이냐 전부 Windows냐의 양자택일로 두지 않는 분할이라는 현실적 해법을 정리합니다.

1. 먼저 결론(판단표)

앱 전체가 아니라 앱이 가진 기능·성질마다 판단하는 것이 핵심입니다.

기호는 다음 의미로 씁니다. ◎ = Web화 효과가 크다 / ○ = Web화에 맞다 / △ = 주의(조건에 따라 맞지 않는다. Web화 이외의 해결책을 먼저 검토한다) / × = 맞지 않는다(브라우저의 구조적 제약에서 비롯되므로, 공들여 만들어도 뒤집기 어렵다).

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

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

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 21건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 「Web화하고 싶다」의 내용을 분해한다

Web화 상담을 받았을 때 먼저 할 일은 요청의 분해입니다. 「Web으로 하고 싶다」는 말 뒤에는 대개 다음 세 가지 중 하나(또는 여러 개)가 있습니다.

(1) 배포·업데이트 수고를 없애고 싶다. 「버전 업할 때마다 전 단말을 돌며 설치하고 있다」는 고민입니다. 이는 Web화로 확실히 해결되지만, Web화하지 않아도 해결할 수 있습니다. ClickOnce나 MSIX처럼 자동 업데이트 메커니즘을 가진 배포 방식으로 바꾸면, Windows 앱인 채로 배포 작업을 거의 제로로 만들 수 있습니다. 자세한 내용은 「Windows 앱 배포 방식 고르기」에서 정리하고 있습니다. 배포 고민만이 동기라면 Web화는 과잉 투자입니다.

(2) 어디서든·어느 단말에서든 쓰고 싶다. 여러 거점에서의 이용, 고객사나 자택에서의 접근, 태블릿에서의 참조──이는 Web화가 가장 빛을 발하는 지점입니다. 다만 여기에서도 「전 기능을 어디서든 쓰고 싶은지」인지 「데이터를 어디서든 보고 싶은지」인지는 나눠서 확인합니다. 실무에서는 후자인 경우가 많고, 그 경우에는 열람·집계 부분만 Web으로 내보내는 분할 구성(제8장)으로 충분합니다.

(3) 오래된 기술에서 벗어나고 싶다. 「만든 사람이 퇴직했다」「.NET Framework 그대로라 불안하다」는 동기입니다. 이는 정당한 문제의식이지만, 해결책이 Web화라고는 할 수 없습니다. 어차피 다시 만든다면 업무 성질이 데스크톱에 맞을 때는 최신 .NET으로 Windows 앱으로 다시 만드는 선택지가 있습니다(WinForms / WPF / WinUI 고르는 법). 또한 Web으로 바꾼다고 진부화에서 벗어날 수 있는 것은 아니다는 점도 짚어 두어야 합니다. IE 전용으로 만든 사내 Web 시스템이 IE 종료로 갈 곳을 잃은 사례는 기억이 새롭습니다(「IE 모드를 통한 사내 Web 시스템의 수명 연장과 출구 전략」). Web 앱도 프레임워크나 브라우저 변화에 맞추는 보수는 필요하며, 「Web화 = 보수로부터의 해방」이 아닙니다.

이 분해를 하면 「Web화로만 해결되는 것」「Web화 이외로도 해결되는 것」「Web화해도 해결되지 않는 것」이 보입니다. 이를 바탕으로 이후의 「Web화하지 않는 편이 나은 경우」에 해당하는 기능이 없는지를 확인합니다.

참고로 이후의 케이스는 성질이 두 종류로 나뉩니다. 케이스 1~4(제3~6장)는 「기술적으로 Web화에 맞지 않는다」는 이야기이고, 케이스 5(제7장)는 「비용 구조를 잘못 읽는다」는 이야기입니다. 전자는 해당하면 그 기능을 Web으로 내보내지 않는 판단으로 직결되지만, 후자는 해당해도 중지의 이유가 아니라 견적의 전제를 고치는 이야기로 받아들여 주세요.

3. 케이스 1: 장치·주변 기기와 직접 연결되어 있다

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

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

「Web Serial API나 WebUSB로 브라우저에서 시리얼 통신할 수 있지 않느냐」는 반론도 있을 수 있습니다. 실제로 존재하지만, 대응 브라우저가 한정됩니다. Web Serial API는 Chrome / Edge 등 Chromium 계열에 더해 2026년 5월 릴리스의 Firefox 151에서 데스크톱판 Firefox도 대응했지만, Safari는 미지원(모바일도 Android판 Chrome이 Bluetooth 경유 시리얼에 부분 대응하는 데 그칩니다)이고, WebUSB는 지금도 Chromium 계열 한정입니다³. 「어느 브라우저에서든 쓸 수 있다」는 Web화의 최대 이점에 제한을 더한 채로, 장치 연결 시에는(적어도 최초나 기기 추가마다) 사용자가 브라우저 대화 상자에서 기기를 골라 허가하는 조작이 전제가 되므로, 업무 시스템의 장치 연동 수단으로는 수지가 맞지 않는 경우가 많은 것이 실정입니다.

여기서 든 브라우저 대응 현황은 변화가 빠르고 수명이 짧은 정보입니다(Web Serial API의 Firefox 대응도 비교적 최근의 움직임입니다). 실제로 판단할 때는 이 기사의 서술을 그대로 쓰지 말고, MDN의 각 API 페이지에 있는 「Browser compatibility」에서 최신 대응 현황을 확인해 주세요. 한편 「샌드박스가 로컬 자원에 대한 접근을 제한한다」는 원칙 그 자체는 설계 사상이므로, 이쪽은 단기간에 바뀌지 않습니다.

또한 「Web 앱 + 각 단말에 상주하는 연동 에이전트」라는 구성으로 우회하는 방법도 있지만, 이는 배포·업데이트가 필요한 Windows 프로그램이 결국 남는 구성입니다. 그 자체는 나쁜 것이 아니며, 오히려 제8장의 분할 구성의 한 형태입니다. 다만 「Web화하면 단말에 아무것도 넣지 않아도 된다」는 당초 기대와는 다른 이야기라는 점은 계획 단계에서 공유해 둘 필요가 있습니다.

장치 연동 부분의 설계는 「외부 장치의 상태 확인·표시 베스트 프랙티스」도 참조해 주세요.

4. 케이스 2: 로컬 파일·다른 앱과 깊게 연동하고 있다

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

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

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

이런 기능을 Web화하려고 하면 「파일을 서버에 업로드하게 하고, 서버 측에서 처리한다」는 형태로의 업무 흐름 변경이 필요합니다. 그것으로 업무가 성립한다면 선택지이지만, 기가바이트급 파일을 일상적으로 다루거나, 사외에 내보낼 수 없는 데이터를 로컬에서만 처리하거나, Excel 자산과 밀결합되어 있다는 사정이 있다면 그 부분은 Windows 앱(폴더 감시·일괄 처리 같은 무인 처리라면 Windows 서비스)으로 남기는 쪽이, 만드는 쪽도 쓰는 쪽도 무리가 없습니다. 다만 Excel과의 COM 연동만은 둘 장소에 주의가 필요합니다. Microsoft는 서비스 등의 무인·비대화 환경에서의 Office 자동화를 비권장·비지원으로 두고 있으므로⁵, Excel을 자동 조작하는 처리는 사용자가 로그온하여 쓰는 데스크톱 앱 쪽에 두거나, Office를 실행하지 않는 Open XML 계열 라이브러리로 읽고 쓰기로 바꿉니다. Excel 연동하는 방법은 「Excel 장표 출력 만드는 법」, 폴더 감시는 「FileSystemWatcher의 안전한 기본」에서 다루고 있습니다.

5. 케이스 3: 네트워크가 불안정한 현장에서, 멈추면 안 되는 업무에 쓴다

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

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

• 공장·창고·야외 현장: Wi-Fi 전파가 금속 선반이나 기계에 가려져, 순간 끊김이 일상적으로 일어난다
• 멈추면 안 되는 라인: 기록·지시 화면이 몇 분만 멈춰도 생산이나 출하에 영향이 있다
• 회선이 가늘고 불안정한 거점: 모바일 회선에 의존하는 임시 사무소, 선상·산간 등

네이티브 Windows 앱은 로컬에 데이터를 가지고 오프라인에서도 동작을 이어가며, 회선 복구 후에 동기화하는 구성을 자연스럽게 만들 수 있습니다. 오프라인 동작은 Microsoft 자신이 네이티브 앱을 고르는 이유로 드는 항목이기도 합니다⁶. PWA(Service Worker)나 클라이언트 측에 데이터를 두는 설계로 Web 앱을 오프라인 대응시키는 것도 기술적으로는 가능하지만, 동기화·충돌 해결까지 포함해 공들여 만드는 것은 상당한 추가 투자이며, 「Web화하면 싸진다」는 당초 기대와는 반대 방향으로 작용합니다.

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

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

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

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

열람·승인·가끔의 등록 정도라면 Web 폼으로 충분합니다. 그러나 입력 속도 그 자체가 업무 생산성에 직결되는 화면은, Web화의 효과(어디서든 쓸 수 있다)를 실제로 누리는지──그 화면은 결국 사무소의 고정 좌석에서만 쓰지 않는지──를 냉정히 확인해 주세요. 쓰는 장소가 고정이라면 Web화로 얻는 것은 없고, 잃는 것만 있습니다.

7. 케이스 5: 「이식」 견적으로 「다시 만들기」를 시작해 버린다

여기까지는 기능·이용 형태의 이야기였지만, 마지막은 비용 구조의 이야기입니다. Web화 계획이 도중에 무너지는 전형 패턴은 「지금 있는 것을 Web으로 옮긴다」는 이식 이미지로 견적하고, 실제로는 다시 만들기였다는 것이 나중에 드러나는 경우입니다.

• 화면 자산은 가져갈 수 없습니다. WinForms나 WPF의 화면 정의·화면 로직을 Web으로 자동 변환하는 현실적인 수단은 없고, UI는 전 화면을 다시 설계해 다시 만듭니다. 화면 수 × 복잡도가 그대로 공수가 됩니다.
• 업무 로직 점검이 먼저 필요합니다. 오랫동안 운영된 앱은 명세서에 없는 업무 규칙이 코드 안에만 존재하는 일이 드물지 않습니다. Web화는 그것을 전부 파내어 재구현하는 작업을 포함합니다. 이 점은 VB6 / Access 업무 앱의 마이그레이션에서 쓴 「처음부터 전면 재작성하지 않는다」는 원칙이 그대로 들어맞습니다.
• 완성 후의 운영 비용이 구조적으로 늘어납니다. 데스크톱 앱의 운영은 단말을 돌보는 일이었지만, Web 앱에서는 서버(또는 클라우드)의 구축·감시·백업·인증서와 보안 업데이트가 지속적인 일로 발생합니다. 사내에 그 체제가 없으면 외부 위탁비가 매달 듭니다. Web화의 비용 비교는 초기 개발비뿐 아니라 이 러닝 코스트까지 포함해 할 필요가 있습니다.
• 보안의 전제가 바뀝니다. 사내 LAN 안에서만 움직이던 앱을 Web으로 만들어 사외 접근을 허용한 순간, 인증·인가·통신 암호화·공격 대책의 요구 수준은 한 단계 올라갑니다. 이것도 「Web화 비용」의 일부입니다.

품의나 사내 비교에 쓸 때는 다음 형태로 맞추면 논의가 맞물립니다.

총액 = 초기 개발비(다시 만들기의 공수) + 월액 운영비 × 12 × 예상 이용 연수 + 이행기의 일시 비용(데이터 이행·교육·병행 기간)

핵심은 비교하는 안을 같은 연수로 맞추는 것입니다. 「Web화」와 「Windows 앱인 채로의 현대화(최신 .NET으로의 이행·배포 방식 개선·UI 쇄신)」를, 예를 들어 5년으로 나란히 놓고 총액을 냅니다. 초기 비용만 나란히 놓으면 서버 운영이라는 지속 비용이 시야에서 사라지고, 반대로 월액만 보면 다시 만들기의 규모가 보이지 않습니다. 예상 이용 연수는 업무 시스템의 교체 주기(사내에서 지난번에 언제 바꿨는지)에서 정하는 것이 현실적입니다.

거듭 말하지만, 이들은 Web화를 부정하는 재료가 아니라 올바른 전제로 견적하기 위한 재료입니다. 다시 만들기와 러닝 코스트를 반영해도 Web화의 이점이 앞선다면 진행해야 합니다. 앞서지 않는다면 Windows 앱인 채로의 현대화(최신 .NET으로의 이행, 배포 방식 개선, UI 쇄신)라는, 더 작은 투자로 동기의 대부분을 채울 수 없는지를 먼저 검토합니다.

8. 현실적 해법: 전부 Web이냐 전부 Windows냐의 양자택일로 두지 않는다

여기까지의 판단을 실무에 적용하면, 많은 경우 답은 「전면 Web화」도 「현상 유지」도 아니라 분할이 됩니다.

사고방식은 단순합니다. 제1장의 판단표를 앱 전체가 아니라 기능마다 적용하는 것입니다. 전체 그림은 다음과 같습니다.

flowchart TB
    subgraph WEB["Web으로 내보낸다 ── 브라우저"]
        W["열람·검색·집계<br/>장표 다운로드·승인<br/>마스터 유지보수"]
    end
    subgraph WIN["Windows에 남긴다 ── 각 단말의 앱"]
        D["장치·주변 기기와의 연동<br/>로컬 파일의 감시·일괄 처리<br/>오프라인 운영·고속 입력"]
    end
    API["공통의 업무 로직·API"]
    DB[("데이터베이스")]
    W --> API
    D --> API
    API --> DB

그림 1: 분할 구성의 전체 그림. 본사·다른 거점은 브라우저, 현장은 Windows 앱, 데이터와 업무 로직은 공통.

• Web으로 내보내는 것: 여러 거점·여러 사람이 보고 싶은 데이터의 열람·검색·집계, 장표 다운로드, 승인 등의 가벼운 조작. 마스터 유지보수도 대개 여기에 들어갑니다.
• Windows에 남기는 것: 장치·주변 기기와의 연동, 로컬 파일의 감시·일괄 처리, 오프라인에서도 멈추면 안 되는 현장 업무, 고속 입력 화면.
• 공통으로 하는 것: 데이터베이스와 업무 로직입니다. 데이터를 일원화하고, Web 앱과 Windows 앱 양쪽이 같은 API(또는 DB)를 참조하는 형태로 만듭니다. 여기를 공통으로 두면 「현장은 Windows 앱으로 입력하고, 본사는 브라우저로 즉시 확인한다」는, Web화 동기의 대부분을 채우는 구성이 성립합니다.

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

참고로 「화면은 Web 기술로 만들고 싶지만 로컬 자원에도 접근하고 싶다」는 요건에는 Electron이나 Blazor Hybrid(WebView2) 같은 하이브리드형이라는 선택지도 있습니다. 브라우저 샌드박스 제약 없이 Web 기술 UI를 쓸 수 있지만, 이는 배포가 필요한 데스크톱 앱이며 「브라우저만으로 쓰고 싶다」는 요청의 답이 되지는 않는다는 점만 주의해 주세요.

9. Web화를 정하기 전의 체크리스트

견적 의뢰나 사내 품의 전에 다음을 확인해 두면 재작업이 줄어듭니다.

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

이 중 2~5에 해당 항목이 있다면 전면 Web화가 아니라 분할 구성을 축으로 검토할 것을 권합니다. 발주 전의 정리 전반은 「Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리할 점」도 참조해 주세요.

정리

Web화는 도구이지 목적이 아닙니다. 여러 거점에서의 이용이나 단말 관리 축소에는 분명히 효과가 있는 한편, 장치 연동·로컬 파일 처리는 브라우저의 보안 설계에서 비롯된 제약 때문에 프레임워크 선정이나 공들여 만들기로 뒤집기 어렵고, 오프라인 운영·고속 입력은 기술적으로 대응할 수 있더라도 그 구현과 운영 비용이 「Web화로 편해진다」는 당초 목적과 역행하기 쉽습니다. 그리고 Web화는 이식이 아니라 다시 만들기이며, 완성 후에는 서버 운영이라는 새로운 지속 비용이 더해집니다.

그래서 실무의 판단은 「Web화할지, 하지 않을지」가 아니라 「어느 기능을 Web으로 내보내고, 어느 기능을 Windows에 남기고, 무엇을 공통으로 할지」라는 설계의 문제가 됩니다. 기존 앱의 점검부터 Web화 가능 여부 판단, 분할 구성의 설계까지, 코드와 운영의 실태를 보면서 판단이 필요해지는 경우가 많으므로, 망설이면 상담해 주세요.

관련 기사

• Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리할 점
• VB6 / Access 업무 앱의 수명 연장과 마이그레이션 ── 유지·래핑·교체 판단표
• WinForms / WPF / WinUI 고르는 법
• Windows 앱 배포 방식 고르기(MSI / MSIX / ClickOnce / xcopy / 자체 업데이터)
• IE 모드를 통한 사내 Web 시스템의 수명 연장과 출구 전략
• 외부 장치의 상태 확인·표시 베스트 프랙티스
• FileSystemWatcher의 안전한 기본
• Excel 장표 출력 만드는 법

관련 상담 영역

合同会社小村ソフト에서는 기존 Windows 앱의 Web화 가능 여부 판단, Web+Windows 분할 구성의 설계, 장치 연동·로컬 처리를 포함한 업무 앱의 개발·수정에 관한 기술 상담을 다루고 있습니다.

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

오래된 Windows 앱을 갱신한다면, 겸사겸사 Web화하는 편이 나을까요?

「오래되어서」라는 이유만으로 Web화하는 것은 권하지 않습니다. Web화는 이식이 아니라 다시 만드는 것에 가까운 공수가 들고, Web 앱에도 기술 진부화는 있습니다(사내 Web 시스템이 IE 전용으로 남은 사례가 그 전형입니다). 판단의 축은 기술의 신구가 아니라 그 앱의 이용 형태입니다. 여러 거점에서 쓰거나 단말 관리를 줄이고 싶다면 Web화의 이점이 나오지만, 장치 연동이나 로컬 파일 처리가 중심이라면 .NET의 새 버전으로의 이행이나 UI 수정 등, Windows 앱인 채로 현대화하는 쪽이 비용 대비 효과에 맞는 경우가 많습니다.

Web화하면 배포나 설치 수고는 없어지지 않나요?

클라이언트 측 배포 작업은 없어지지만, 「배포 수고를 없애고 싶다」는 동기만 있다면 Web화보다 가벼운 해결책이 있습니다. ClickOnce나 MSIX처럼 자동 업데이트 메커니즘을 가진 배포 방식으로 바꾸면, Windows 앱인 채로도 각 단말을 돌며 설치하는 작업은 거의 불필요하게 만들 수 있습니다. 또한 Web화한 경우에는 대신 서버(또는 클라우드)의 구축·감시·보안 업데이트라는 지속적인 운영 비용이 새로 발생합니다. 없어지는 비용과 늘어나는 비용 양쪽을 보고 판단해 주세요.

앱의 일부만 Web화할 수 있나요?

가능합니다. 실무에서는 오히려 그 형태가 현실적 해법이 되는 경우가 많습니다. 전형적인 예는 데이터 열람·집계·장표·여러 거점에서의 참조를 Web으로 내보내고, 장치 연동·현장의 고속 입력·로컬 파일 처리는 Windows 앱으로 남긴 뒤, 둘을 공통 API와 데이터베이스로 잇는 구성입니다. 전면 Web화에 비해 한 번에 다시 만드는 범위가 작고, Web화 효과가 큰 부분부터 단계적으로 진행할 수 있습니다.

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

성질이 다른 것들이 섞여 있으므로 나눠서 생각할 필요가 있습니다. Electron이나 Blazor Hybrid(WebView2)는 데스크톱 앱으로 동작하므로 브라우저 샌드박스 제약 없이 파일이나 장치에 접근할 수 있고, 화면은 Web 기술로 작성할 수 있습니다. 다만 배포·업데이트가 필요한 데스크톱 앱이라는 점은 바뀌지 않으며, 「브라우저만으로 쓰고 싶다」는 요청에 대한 답이 되지는 않습니다. 한편 PWA는 작업 표시줄 고정 등 설치한 듯한 사용감이 되어도 내용은 브라우저 위의 Web 앱 그대로이며, 로컬 자원에 대한 접근 제약도 일반적인 Web 앱과 같습니다. 무엇을 해결하려고 Web화를 검토하는지를 먼저 분해하는 것이 중요합니다.

저자 프로필

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

Go Komura

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

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