IE 모드 다음은 WebView2로 괜찮은가 ── ActiveX가 동작하지 않는 제약과 현실적인 마이그레이션 설계

이전 글 「IE 모드 의존 사내 Web 시스템을 어떻게 연명시키고, 어떻게 벗어날 것인가」에서는, IE 모드는 어디까지나 기한이 있는 연명 조치이며 병행해서 출구를 설계해야 한다고 썼습니다. 그 「출구」에 대한 상담을 받다 보면 높은 빈도로 등장하는 것이 WebView2입니다. 「사내 Web 시스템을 전용 앱 안에 표시하고 싶다」「데스크톱 앱의 일부 화면만 Web 기술로 만들고 싶다」「Electron은 무겁다고 들었는데 대안이 있는가」──모두 WebView2가 선택지로 떠오르는 장면입니다.

한편 WebView2에는 도입 전에 알아두어야 할 특유의 성질이 있습니다. 런타임을 어떻게 배포할지, 사용자 데이터 폴더를 어디에 둘지, 네이티브 측과 Web 측을 어떻게 대화시킬지. 그리고 무엇보다, IE 모드에서 동작하던 ActiveX는 WebView2에서는 동작하지 않는다는, 마이그레이션 계획의 근간에 관련된 제약이 있습니다. 이 글에서는 WebView2의 기본 구조부터 배포・설계・보안, IE 모드 탈출과의 현실적인 조합 방법까지를 정리합니다.

1. 먼저 결론

• WebView2는 Chromium 기반의 Microsoft Edge를 Windows 앱에 임베드하는 컨트롤입니다. WinForms / WPF / WinUI / Win32 C++에서 사용할 수 있으며, 기존 데스크톱 앱에 「일부만 Web UI」를 추가하는 용도에 적합합니다.¹
• 런타임은 원칙적으로 Evergreen(자동으로 업데이트되는 공유 런타임)을 사용합니다. Windows 11에는 기본 탑재되어 있지만, 「설치되어 있을 것」이라고 전제하지 않고 설치 프로그램에 존재 확인과 부트스트랩을 포함시키는 것이 공식 권장 방식입니다.²
• 오프라인 환경이나 검증이 끝난 구성을 고정하고 싶은 공장・제조 라인용으로는 Fixed Version(앱에 동봉)이 있지만, 동봉물이 250MB를 넘고 보안 업데이트를 스스로 배포할 책임을 지게 됩니다. 안이하게 선택하지 마십시오.³
• 가장 먼저 걸리는 것은 사용자 데이터 폴더(UDF)입니다. 기본값으로는 exe 옆에 생성되기 때문에, Program Files 아래에 설치된 앱에서는 실행에 실패합니다. %LOCALAPPDATA% 아래를 명시적으로 지정하는 것을 정석으로 삼으십시오.⁴
• 네이티브⇔Web 연동은 PostWebMessageAsJson / WebMessageReceived를 통한 메시지 교환을 기본으로 하고, AddHostObjectToScript(COM 객체 노출)는 신뢰할 수 있는 콘텐츠로 한정합니다.¹
• WebView2 안에서 ActiveX는 동작하지 않습니다. ActiveX를 포함한 IE 모드 의존 페이지를 「WebView2로 옮기기만 하면 끝」이라고 할 수 없으며, ActiveX가 담당하던 처리를 네이티브 측으로 옮기는 설계가 필요합니다. 이것이 IE 모드 탈출 계획의 핵심입니다.⁵

2. WebView2의 기본 구조

WebView2는 「SDK(앱에 포함시키는 API)」와 「런타임(클라이언트에 설치되는 Edge 기반 실행 환경)」이라는 2가지로 구성되어 있습니다. Visual C++ 런타임이나 .NET 런타임과 같은 구도로, 앱은 NuGet 패키지 Microsoft.Web.WebView2를 참조하여 빌드하고, 실행 시에는 클라이언트 위의 런타임을 사용해서 동작합니다.³

지원 플랫폼은 광범위해서, .NET Framework 4.6.2 이상 / .NET Core 3.1 이상의 WinForms・WPF, WinUI, Win32 C++에서 이용할 수 있습니다. 기존 WinForms 업무 앱의 화면 1개만 WebView2로 바꾸는 식의 단계적인 사용이 가능한 것이, 프레임워크 자체를 갈아타는 방식(Electron 등)에 비해 큰 장점입니다. UI 프레임워크 자체의 선정은 「WinForms / WPF / WinUI 판단표」도 참조하십시오.

가장 단순한 임베딩은 다음과 같은 코드가 됩니다(WPF/WinForms에 공통되는 사고방식입니다).

var env = await CoreWebView2Environment.CreateAsync(
    browserExecutableFolder: null,   // Evergreen 런타임을 사용
    userDataFolder: Path.Combine(
        Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
        "KomuraSoft", "MyApp", "WebView2"));
await webView.EnsureCoreWebView2Async(env);
webView.CoreWebView2.Navigate("https://internal.example.co.jp/app/");

포인트는 기본값에 맡기지 않고 CoreWebView2Environment를 직접 생성하고 있다는 점입니다. 이유는 다음 2개 장에서 설명합니다.

도입 절차 자체는 단순하며, WinForms / WPF라면 다음과 같은 흐름입니다.

1. NuGet에서 Microsoft.Web.WebView2를 프로젝트에 추가한다(디자이너의 도구 상자에도 WebView2 컨트롤이 나타납니다)
2. 폼／윈도우에 컨트롤을 배치한다
3. 위 코드처럼 EnsureCoreWebView2Async로 초기화한 다음 Navigate한다

여기서 한 가지, 처음에 꼭 짚어 두어야 할 API상의 주의점이 있습니다. webView.CoreWebView2는 초기화가 완료될 때까지 null입니다. 폼의 생성자에서 CoreWebView2.WebMessageReceived += ...처럼 이벤트를 구독하려다가 NullReferenceException이 발생하는 것은 흔한 실수이며, 초기화 관련 처리는 「EnsureCoreWebView2Async의 await 이후」로 모으는 것이 기본형입니다. Source 속성에 값을 대입하면 초기화가 암묵적으로 시작되지만, 환경(UDF 위치 등)을 지정하고 싶은 앱에서는 명시적으로 EnsureCoreWebView2Async(env)를 먼저 호출하는 구성으로 통일하는 쪽이 사고가 적습니다.

또한, WebView2의 이벤트는 모두 UI 스레드에서 발생합니다. WebMessageReceived 안에 무거운 처리(기기 접근이나 파일 I/O)를 그대로 작성하면 Web 측의 조작감까지 덩달아 멈추게 되므로, 네이티브 측 처리는 async/await로 피해서 처리합니다. 이 부근의 원칙은 「WPF/WinForms의 UI 스레드와 async/await」에서 쓴 내용을 그대로 적용할 수 있습니다.

3. 런타임 배포 ── Evergreen과 Fixed Version

3.1 Evergreen(권장)

Evergreen은 클라이언트에 설치된 공유 런타임을 모든 WebView2 앱이 사용하고, 런타임은 자동으로 업데이트되는 방식입니다. 보안 패치가 자동으로 적용되고 디스크 사용량이 작다는 이유로 공식적으로도 명확히 권장하고 있습니다.⁶

실무에서 주의할 점은 3가지입니다.

• 존재 확인을 구현한다. Windows 11에는 기본 탑재되어 있고 Windows 10에도 널리 배포되어 있지만, 그래도 「설치되어 있지 않은 단말」은 존재합니다. .NET에서는 CoreWebView2Environment.GetAvailableBrowserVersionString()으로 확인할 수 있지만, 런타임이 설치되지 않은 환경에서는 이 호출 자체가 예외(WebView2RuntimeNotFoundException)로 실패하므로, try/catch로 감싸서 「예외 = 미설치」로 판정하고 부트스트래퍼(작은 온라인 설치 프로그램) 또는 독립 실행형 설치 프로그램 실행으로 이어지는 형태로 설치 과정에 포함시킵니다.²
• 런타임 업데이트 추적을 설계한다. 런타임이 업데이트되어도, 실행 중인 앱은 이전 버전을 계속 사용합니다. NewBrowserVersionAvailable 이벤트를 감지해서 「재시작하면 업데이트가 반영된다」는 흐름을 만들어 두는 것이 권장 패턴입니다.²
• 사내 업데이트 통제와 정합성을 맞춘다. Edge 브라우저와 WebView2 런타임의 업데이트 정책은 별개입니다. 그룹 정책으로 런타임 업데이트를 막고 있는 환경에서는 Evergreen의 전제(최신 버전이 설치되어 있다)가 무너지므로, 최신 API를 사용할 경우 기능 감지(feature detection)를 넣습니다.⁶

3.2 Fixed Version(한정된 용도)

Fixed Version은 특정 버전의 런타임을 앱에 동봉하는 방식입니다. 동작 검증이 끝난 구성을 그대로 고정할 수 있기 때문에, 오프라인 제조 장비나 변경 관리가 엄격한 환경에서는 합리적인 선택이 됩니다. 다만,

• 동봉되는 바이너리가 250MB를 넘어 배포물이 그만큼 커진다²
• 런타임이 자동으로 업데이트되지 않으므로 브라우저 엔진의 취약점 수정을 자체 릴리스로 배포해야 할 책임을 지게 된다
• 업데이트를 게을리하면 「낡은 Chromium을 탑재한 업무 앱」이 사내에 계속 남게 된다

이런 무거운 대가가 있습니다. 표시할 콘텐츠가 완전히 폐쇄망・자사 관리이고, 릴리스 사이클에 런타임 업데이트를 포함시킬 수 있는 체제가 있는 경우에만 선택하십시오.

4. 처음에 걸리는 함정 ── 사용자 데이터 폴더

WebView2는 Cookie・캐시・권한 등을 사용자 데이터 폴더(UDF)에 저장합니다. UDF의 위치를 지정하지 않으면 기본 위치(대부분의 구성에서 exe와 같은 위치 옆)에 만들려고 하기 때문에, Program Files 아래에 설치된 앱에서는 쓰기에 실패해 초기화 오류가 됩니다. 개발 PC(디버그 실행, 쓰기 가능한 폴더)에서는 동작하는데 설치하는 순간 동작하지 않는──전형적인 「배포하고 나서야 발견되는」 결함입니다.⁴

대책은 단순합니다. 앞의 코드 예시처럼 %LOCALAPPDATA% 아래의 앱 전용 폴더를 항상 명시적으로 지정하는 것입니다. 아울러 다음 사항도 설계에 포함시켜 두십시오.

• UDF는 사용자별・앱별로 나눈다(여러 앱에서 공유하지 않는다)
• 네트워크 드라이브 위에 두지 않는다(속도 저하・손상・데이터 손실의 원인이 됩니다)⁴
• 제거 시나 「로그인 정보 지우기」 기능으로 UDF를 삭제하는 절차를 정해 둔다(Cookie와 사이트 데이터가 남는 위치라는 것을 운영자가 모르면, 퇴사자 단말 정리 등에서 누락됩니다)

앞서 소개한 글 「업무용 Windows 앱의 로컬 데이터 저장」에서 다룬 「exe 옆에 쓰지 않는다」는 원칙의 WebView2 버전이라고 생각하십시오.

5. 네이티브⇔Web 연동 설계

WebView2를 「그냥 브라우저 틀」 이상의 것으로 만들어 주는 것이 네이티브 코드와 Web 콘텐츠의 상호 연동입니다. 방법은 주로 2가지가 있습니다.¹

5.1 Web 메시지(기본형)

네이티브 측에서 PostWebMessageAsJson으로 JSON을 보내고, Web 측은 window.chrome.webview.addEventListener("message", ...)로 받습니다. 반대 방향은 window.chrome.webview.postMessage(...)와 WebMessageReceived 이벤트입니다. 느슨한 결합이며, 노출할 작업을 한 곳에서 검사할 수 있기 때문에, 우선 이것을 기본 연동 수단으로 삼습니다.

// 네이티브 → Web
webView.CoreWebView2.PostWebMessageAsJson(
    JsonSerializer.Serialize(new { type = "deviceStatus", connected = true }));

// Web → 네이티브
webView.CoreWebView2.WebMessageReceived += (s, e) =>
{
    // 예상한 오리진 이외(외부 사이트로 이동한 후 등)에서 온 메시지는 처리하지 않는다
    if (!e.Source.StartsWith("https://internal.example.co.jp/", StringComparison.Ordinal))
        return;

    AppMessage? msg;
    try { msg = JsonSerializer.Deserialize<AppMessage>(e.WebMessageAsJson); }
    catch (JsonException) { msg = null; }
    if (msg?.Type is null)
        return;  // 형식이 잘못된 경우 여기서 버린다(필요하면 로그로)

    // type별로 허용된 작업만 실행한다
};

Web 측(JavaScript)에서는 이렇게 받습니다. 특별한 라이브러리는 필요 없으며, WebView2가 주입하는 window.chrome.webview 객체를 사용하기만 하면 됩니다.

// 네이티브로부터의 메시지를 받는다
window.chrome.webview.addEventListener("message", (e) => {
    if (e.data.type === "deviceStatus") {
        updateStatusBadge(e.data.connected);
    }
});

// 네이티브로 요청을 보낸다
document.getElementById("print-label").addEventListener("click", () => {
    window.chrome.webview.postMessage({ type: "printLabel", copies: 2 });
});

수신 측에서는 위 코드처럼 e.Source(메시지를 보낸 페이지의 URI)를 먼저 검사하고, 그 위에서 「메시지의 type을 화이트리스트로 검사하고, 예상 외의 경우는 무시하며 로그로 남긴다」를 철저히 지킵니다. Web 측은 링크 하나・리다이렉트 하나로 외부 사이트로 이동할 수 있으므로, 「지금 표시되고 있는 것은 우리 페이지일 것」이라는 안이한 생각으로 발신처 검사를 생략하지 마십시오. 반대로 Web 측에서도 window.chrome.webview가 존재하지 않는 경우(일반 브라우저에서 열린 경우)의 대체 동작을 넣어 두면, Web UI 부분을 단독으로 브라우저에서 디버그할 수 있어 개발 효율이 올라갑니다.

5.2 호스트 객체 노출(강력하지만 한정적으로 사용)

AddHostObjectToScript를 사용하면 .NET/COM 객체를 JavaScript에서 직접 호출할 수 있게 됩니다. 내부적으로는 COM의 구조이며, 저희가 오랫동안 다뤄 온 COM 기술이 이런 곳에서 여전히 현역으로 쓰이고 있다는 점이 흥미롭습니다만, Web 콘텐츠에 네이티브 객체를 직접 쥐여준다는 것은 그 페이지가 침해당했을 때의 영향도 그만큼 크다는 뜻입니다. 노출하는 것은 자사가 관리하는 콘텐츠로 한정하고, 노출하는 메서드는 필요 최소한으로 좁히십시오. 신뢰할 수 없는 페이지를 표시할 가능성이 있는 WebView에는 등록하지 않는다는 것이 원칙입니다.

5.3 로컬 콘텐츠 로드

HTML/JS를 앱에 동봉해서 표시하는 경우, file://로 직접 읽는 것이 아니라 SetVirtualHostNameToFolderMapping으로 가상 호스트 이름에 폴더를 매핑하는 것이 정석입니다. 콘텐츠가 https://appassets.example/와 같은 오리진을 갖게 되므로, localStorage 등 오리진을 전제로 하는 Web API를 문제없이 사용할 수 있고, 크로스 오리진 접근의 허용 수준도 지정할 수 있습니다. 호스트 이름에는 실제로 존재할 수 없는 예약 도메인(.example 등)을 사용하고, 접근 종류는 필요 최소한(먼저 DenyCors)부터 시작합니다.⁷

6. IE 모드 탈출과 WebView2 ── ActiveX는 동작하지 않는다

여기가 이 글에서 가장 중요한 절입니다. IE 모드가 연명될 수 있는 것은, Edge 안에서 실제 IE11(Trident 엔진)이 동작하고 있어 ActiveX나 브라우저 헬퍼 개체가 그대로 동작하기 때문입니다.⁵ 반면 WebView2는 Chromium이며, ActiveX를 호스팅하는 구조가 없습니다. 즉,

「IE 모드에서 동작하는 사내 시스템을 WebView2 셸로 옮긴다」는 것은, ActiveX에 의존하지 않는 화면에 대해서만 성립합니다.

라는 제약을 바탕으로 마이그레이션 계획을 세워야 합니다. 현실적인 마이그레이션 순서는 다음과 같습니다.

1. 현황 조사: IE 모드 의존 페이지를 「ActiveX 등 IE 고유 기술을 사용하는 화면」과 「단지 오래된 방식으로 만들어졌을 뿐인 화면」으로 분류한다(IE 모드 글의 사이트 목록 현황 조사를 그대로 활용할 수 있습니다).
2. IE 고유가 아닌 화면: 최신 브라우저 대응으로 개수하여 Edge 자체로 표시하거나, 업무 단말 앱에 통합하고 싶다면 WebView2 셸에 올린다.
3. ActiveX 의존 화면: ActiveX가 담당하던 기능(시리얼 통신, 파일 접근, 전용 기기 제어 등)을 네이티브 측(WebView2의 호스트 앱)으로 옮기고, Web 메시지를 통해 호출하는 형태로 재설계한다. 「브라우저 안의 ActiveX」를 「앱 안의 Web UI + 네이티브 처리」로 뒤집는 이미지입니다.
4. ActiveX 자체를 남길지・래핑할지・교체할지에 대한 판단은 「ActiveX/OCX 유지・래핑・교체 판단표」의 기준을 그대로 적용할 수 있습니다.

이 3번의 재설계가 바로 WebView2 도입의 실질적인 공수이며, 「WebView2를 넣으면 IE 모드에서 벗어날 수 있다」는 단순한 이야기가 아니라는 기대치 조정이 계획 단계에서 필요합니다. 반대로 말하면, ActiveX의 기능을 호스트 앱으로 옮기는 설계만 마치면, UI는 Web 기술로 자체 개발・유지보수하기 쉬워지고, 배포는 데스크톱 앱으로 통제할 수 있다는 양쪽 모두를 취할 수 있습니다.

7. 사내 시스템에서 반드시 나오는 구현 과제

WebView2 도입을 검토하면 업무 담당자 쪽에서 반드시 나오는 질문이 몇 가지 있습니다. 미리 정리해 두겠습니다.

7.1 인쇄와 보고서

「IE 때는 인쇄 버튼으로 보고서가 나왔다」는 요건은, WebView2에서는 2가지 방식으로 대응할 수 있습니다.

• 화면을 그대로 인쇄: CoreWebView2.ShowPrintUI()로 인쇄 대화상자를 띄우거나, PrintAsync로 무인 인쇄. 브라우저의 인쇄와 동등하므로 CSS의 인쇄 지정(@media print)이 그대로 적용됩니다.
• PDF로 출력: PrintToPdfAsync로 표시 중인 페이지를 PDF 파일로 떨어뜨릴 수 있습니다. 「보고서는 PDF로 저장해서 공유 폴더로」라는 업무 흐름에는, 네이티브 측에서 파일명・저장 위치를 통제할 수 있는 이쪽이 적합합니다.¹

픽셀 단위의 자릿수 맞춤이 요구되는 복사식 전표와 같은 보고서는, Web의 인쇄로 맞춰 나가기보다 네이티브 측의 보고서 출력(Excel 보고서 만드는 방법에서 정리한 방식)으로 가져가는 판단도 포함해서 검토하십시오.

7.2 파일 다운로드와 업로드

다운로드는 기본값으로도 브라우저와 마찬가지로 동작하지만, 업무 앱에서는 DownloadStarting 이벤트로 개입하는 것이 정석입니다. 저장 위치를 고정한다, 확장자로 허용・거부를 판정한다, 기본 다운로드 UI를 없애고 앱 측 알림으로 대체한다, 와 같은 통제를 걸 수 있습니다.¹ 업로드(<input type="file">)는 특별한 구현 없이도 OS의 파일 선택 대화상자가 열립니다.

7.3 인증과 SSO

사내 Web 시스템 측이 Windows 통합 인증(NTLM/Kerberos)이라면, WebView2에서도 대체로 브라우저와 마찬가지로 통과됩니다. Basic 인증을 사용하는 오래된 시스템에는 BasicAuthenticationRequested 이벤트로 자격 증명을 제공할 수 있어, 로그인 화면을 띄우지 않고 넘어갈 수도 있습니다──다만 그 자격 증명을 어디에 저장할지는 바로 DPAPI 글에서 다룬 이야기가 됩니다. Microsoft Entra ID(구 Azure AD)의 SSO를 OS의 로그인 정보로 통과시키고 싶다면, 환경 옵션 AllowSingleSignOnUsingOSPrimaryAccount의 활성화를 검토합니다.

Cookie는 UDF에 저장되므로, 앱을 재시작해도 로그인 상태는 유지됩니다. 「로그아웃 기능으로 세션을 확실히 지우고 싶다」는 경우에는 CookieManager로 명시적으로 삭제하는 구현을 넣으십시오.

7.4 개발 시 디버깅

WebView2의 내부는 Chromium이므로, 개발 중에는 F12의 DevTools를 그대로 사용할 수 있습니다(CoreWebView2Settings.AreDevToolsEnabled가 기본값으로 활성화되어 있습니다). 게다가 앞서 말한 대로 Web UI 측을 「브라우저 단독으로도 동작」하도록 만들어 두면, UI의 개발・디버깅은 일반적인 Web 개발로 진행하고, 네이티브 연동만 WebView2 위에서 확인하는 식으로 업무를 나눌 수 있습니다. Web 자산을 앱에 가둬 두어도, 개발 경험은 Web 그대로 유지할 수 있다는 뜻입니다.

8. 보안 설계의 요점

WebView2 앱은 「브라우저를 내장한 앱」이므로, 브라우저에 준하는 위협 모델로 생각합니다.

• 표시할 콘텐츠를 한정한다: NavigationStarting에서 이동 대상을 사내 도메인 화이트리스트로 검사하고, 예상 외의 URL은 기본 브라우저로 넘긴다(NewWindowRequested도 마찬가지로 처리한다).
• 신뢰 경계를 넘는 기능을 좁힌다: 호스트 객체의 노출 범위, Web 메시지로 허용하는 작업은 최소한으로. 외부 사이트를 표시할 수 있는 WebView와 네이티브 연동을 갖는 WebView를 나누는 것도 유효합니다.
• 이용자 대상 기능을 환경에 맞게 조정한다: CoreWebView2Settings로 「브라우저다움」을 필요한 만큼만 남길 수 있습니다. 키오스크 단말이나 현장 단말에서는 좁혀 두면 사고가 줄어듭니다.
• Fixed Version이라면 업데이트 계획에 책임을 진다: 앞서 말한 대로, 취약점 수정의 배포는 앱 측의 책임이 됩니다.⁶

CoreWebView2Settings에서 자주 조정하는 항목을 들어 두겠습니다. 프로덕션 빌드에서 어떻게 할지를 릴리스 전 체크리스트에 포함시켜 두는 것을 권장합니다.

어느 것이든 「비활성화하면 안전」하다기보다는, 「앱으로서 의도한 조작 이외의 입구를 닫는」 도구입니다. Windows 앱 전반의 보안 향상은 「Windows 앱 보안 최소 체크리스트」도 함께 참조하십시오.

9. 도입 판단 정리

「Windows 전용 사내 앱에서 Web 기술의 UI를 사용하고 싶다」면, Electron보다 WebView2가 기본 선택지입니다. 런타임을 OS 측과 공유할 수 있는 만큼 배포가 가볍고, 기존 .NET 자산과의 통합도 단순합니다.

10. 정리

WebView2는 Chromium 기반의 Web UI를 Windows 앱에 부품으로 포함시킬 수 있는, 사내 시스템의 현대화와 궁합이 좋은 기술입니다. 도입 시 실무 포인트는 Evergreen 런타임의 존재 확인과 업데이트 추적, 사용자 데이터 폴더의 명시적 지정, Web 메시지를 기본으로 한 연동 설계라는 3가지입니다. 그리고 계획 측면에서는, ActiveX는 동작하지 않는다는 제약을 직시하고, ActiveX의 기능을 네이티브 측으로 옮기는 재설계를 공수의 중심에 두는 것입니다.

IE 모드의 기한을 곁눈질하며 「이제 출구를」이라고 생각하고 있다면, 우선 대상 시스템의 현황 조사와 ActiveX 의존 부분의 기능 분해부터 시작하는 것이 확실합니다. 이 부근의 진행 방식은 실제 시스템 구성을 보지 않고서는 판단하기 어려운 부분도 많으므로, 고민되신다면 상담해 주십시오.

관련 글

• IE 모드 의존 사내 Web 시스템을 어떻게 연명시키고, 어떻게 벗어날 것인가
• ActiveX/OCX를 유지할지, 래핑할지, 교체할지 - 판단표
• COM・ActiveX・OCX란 무엇인가
• WinForms / WPF / WinUI를 어떻게 선택할까 - 판단표

관련 상담 분야

합동회사 코무라소프트는 IE 모드・ActiveX 의존 사내 시스템의 출구 설계, WebView2를 활용한 단계적 현대화, 기존 Windows 앱으로의 Web UI 통합에 관한 상담을 다루고 있습니다.

• 기존 자산 활용・마이그레이션 지원
• Windows 앱 교체
• 기술 상담・설계 리뷰
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

WebView2에서 ActiveX가 동작하나요?

동작하지 않습니다. IE 모드는 Edge 안에서 실제 IE11(Trident 엔진)이 동작하기 때문에 ActiveX가 그대로 작동하지만, WebView2는 Chromium 기반이며 ActiveX를 호스팅하는 구조가 없습니다. 따라서 ActiveX에 의존하는 화면을 「WebView2로 옮기기만 하면 끝」이라고 할 수 없으며, ActiveX가 담당하던 시리얼 통신・파일 접근・전용 기기 제어 등의 기능을 네이티브 측(호스트 앱)으로 옮기고 Web 메시지를 통해 호출하는 형태로 재설계해야 합니다. 이 재설계가 바로 WebView2 도입의 실질적인 공수가 됩니다.

WebView2 런타임은 Evergreen과 Fixed Version 중 어느 것을 선택해야 하나요?

원칙은 Evergreen(자동으로 업데이트되는 공유 런타임)입니다. 보안 패치가 자동으로 적용되고 디스크 사용량도 작기 때문에 공식적으로도 명확히 권장하고 있습니다. Windows 11에는 기본 탑재되어 있지만, 아직 설치되지 않은 단말도 존재하므로 설치 프로그램에 존재 확인과 부트스트랩을 포함시켜야 합니다. Fixed Version(앱에 동봉)은 동봉되는 파일이 250MB를 넘고, 브라우저 엔진의 취약점 수정을 자체 릴리스로 배포해야 하는 책임을 지게 되므로, 오프라인 제조 장비나 변경 관리가 엄격한 환경 등 한정된 상황에서만 선택해야 합니다.

WebView2 앱이 설치 후 실행되지 않는 이유는 무엇인가요?

가장 먼저 걸리는 전형적인 문제가 사용자 데이터 폴더(UDF) 문제입니다. WebView2는 Cookie・캐시・권한을 UDF에 저장하는데, 위치를 지정하지 않으면 기본값으로 exe 옆에 만들려고 하기 때문에, Program Files 아래에 설치된 앱에서는 쓰기에 실패해 초기화 오류가 됩니다. 개발 PC에서는 동작하는데 설치하는 순간 동작하지 않는, 전형적인 배포 후 발견되는 결함입니다. 대책은 CoreWebView2Environment를 생성할 때 %LOCALAPPDATA% 아래의 앱 전용 폴더를 항상 명시적으로 지정하는 것입니다. 네트워크 드라이브 위에 두는 것도 속도 저하・손상의 원인이 되므로 피해야 합니다.

WebView2에서 네이티브 코드와 Web 페이지는 어떻게 연동하나요?

기본은 Web 메시지를 통한 느슨한 결합의 연동입니다. 네이티브 측에서 PostWebMessageAsJson으로 JSON을 보내고, Web 측은 window.chrome.webview의 message 이벤트로 받습니다. 반대 방향은 postMessage와 WebMessageReceived 이벤트입니다. 수신 측에서는 e.Source로 발신처 URI를 검사하고, 메시지의 type을 화이트리스트로 검사하는 것이 중요합니다. AddHostObjectToScript로 .NET/COM 객체를 직접 노출하는 방법도 있지만, 페이지가 침해당했을 때의 영향이 크기 때문에 자사가 관리하는 콘텐츠로 한정하고 노출하는 메서드를 최소한으로 좁혀야 합니다.

저자 프로필

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

Go Komura

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

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