# 메타, Windows 11용 WhatsApp 네이티브 앱을 중단하고 웹 래퍼(WebView)로 교체 > Clean Markdown view of GeekNews topic #24364. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24364](https://news.hada.io/topic?id=24364) - GeekNews Markdown: [https://news.hada.io/topic/24364.md](https://news.hada.io/topic/24364.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-14T21:35:06+09:00 - Updated: 2025-11-14T21:35:06+09:00 - Original source: [windowslatest.com](https://www.windowslatest.com/2025/11/12/meta-just-killed-native-whatsapp-on-windows-11-now-it-opens-webview-uses-1gb-ram-all-the-time/) - Points: 2 - Comments: 1 ## Topic Body - Windows 11용 **WhatsApp이 WebView2 기반 웹 래퍼 형태로 전환**, 기존 **WinUI/UWP 네이티브 앱이 중단**됨 - 새 버전은 **web.whatsapp.com을 WebView2 컨테이너로 로드**하며, 로그인 화면에서도 **최대 300MB RAM**을 사용 - 로그인 후에는 **메모리 사용량이 2GB까지 증가**, 평균적으로 **백그라운드에서 1.2GB RAM**을 지속적으로 점유 - **성능 저하, 느린 로딩, 알림 지연** 등 문제가 보고되었으며, Windows 11의 **알림 및 방해 금지 모드와의 호환성도 낮음** - Microsoft Store를 통한 자동 업데이트로 배포 중이며, **기존 네이티브 앱 사용자도 곧 강제 전환**될 예정 --- ### WhatsApp의 Windows 11 버전 변경 - Windows 11용 WhatsApp이 **네이티브 앱에서 WebView2 기반 웹 래퍼로 전환**됨 - 새 앱은 **web.whatsapp.com을 WebView2 컨테이너로 로드**하는 구조 - 이전에는 Electron 기반으로 시작해, 이후 **UWP/WinUI 네이티브 앱**으로 발전했으나 다시 웹 기반으로 회귀 - 이 변경으로 인해 **성능 저하와 높은 메모리 사용량**이 발생 ### 메모리 사용량 비교 - 테스트 결과, **새 WebView2 버전은 로그인 화면에서 약 300MB RAM**을 사용 - 로그인 후 모든 채팅을 불러올 때 **최대 2GB RAM**, 평균적으로 **1.2GB RAM**을 백그라운드에서 유지 - 반면, **기존 네이티브 앱은 평균 190MB**, 유휴 상태에서는 **100MB 이하**로 감소 - 활동이 많을 때도 **최대 300MB 수준**에 그침 - 다수의 대화창을 열면 **새 버전이 3GB RAM까지 도달할 수 있음** ### 성능 및 기능 문제 - 새 WhatsApp은 **느린 반응 속도와 긴 로딩 시간**을 보임 - 대화 전환 시 **지연 현상**이 발생 - **Windows 알림 시스템과의 연동이 불안정**하며, **방해 금지 모드(Do Not Disturb)** 및 **Active Hours 기능**과의 호환성 문제 존재 - **알림 지연** 문제도 보고됨 ### 업데이트 및 회피 가능성 - **WhatsApp 버전 2.2584.3.0**이 Microsoft Store를 통해 배포 중이며, **기존 네이티브 앱을 자동으로 대체** - 사용자가 업데이트를 미루면 잠시 기존 앱 사용이 가능하지만, **모든 사용자가 곧 로그아웃되어 WebView2 버전으로 강제 전환**될 예정 ### 기타 맥락 - 이 변경은 **Apple Watch용 WhatsApp 네이티브 경험 출시 시점**과 겹침 - Apple Watch는 1억 1,500만 명의 사용자를 보유 - Windows는 10억 대 이상의 활성 기기를 보유하지만, **Meta와 Microsoft 모두 Windows용 네이티브 앱 개발을 축소하는 추세** - 원문은 **Meta가 비용 절감을 위해 웹 코드베이스 유지로 전환했을 가능성**을 언급했으나, 구체적 이유는 명시되지 않음 ## Comments ### Comment 46332 - Author: neo - Created: 2025-11-14T21:35:07+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45910347) - 내가 직접 설계하고 지켜온 앱이 이렇게 바뀌어버려서 조금 **씁쓸한 마음**임 예전의 네이티브 앱은 완벽하진 않았지만, 생산성 도구로서 환경을 존중하려는 느낌이 있었음 결론적으로 대기업에게 **네이티브 데스크톱 앱**은 현실적으로 불가능하다고 봄. 이유는 조율 비용 때문임 여러 플랫폼에서 동시에 기능을 출시하려면 복잡도가 기하급수적으로 늘어남. 느긋한 개발 속도라면 가능하겠지만, 빠른 실험과 반복을 원한다면 결국 웹 코드 한 번 쓰는 게 낫다는 결론에 다다름 요즘은 Microsoft조차 이런 방식으로 개발하고 있음. 아이러니하게도 작은 회사일수록 네이티브 앱을 더 잘 유지할 수 있음 - 이 말이 이해가 안 됨. 나와 동료 둘이서 **wxWidgets**로 오디오 신호 처리용 크로스플랫폼 GUI를 만들었는데, macOS와 Windows에서 잘 돌아갔음 대기업이 텍스트 버블과 이모지를 네이티브로 못 그린다는 건 납득이 안 됨. 예전 **MSN Messenger**도 그 정도는 했었음 - 문제의 핵심은 인력 수가 아니라 **조율 비용**임 워터폴 방식에서는 괜찮지만, 요즘의 ‘Agile’식 개발에서는 완전 혼돈임 Android나 iOS는 네이티브 경험이 중요하니 감수할 만하지만, Windows는 API가 계속 바뀌고 네이티브 감각도 거의 사라졌음 차라리 **Telegram처럼 Qt**로 만들었으면 나았을 것 같음 - 예전에 **Facebook과 Messenger의 Windows 버전**을 만들었는데, 웹 대비 사용률이 1%도 안 돼서 경영진이 실패로 간주했음 - 혹시 Windows에서 DB 키의 **비밀 저장소 위치**를 알려줄 수 있는지 궁금함. DB가 곧 막히기 전에 내보내고 싶음 - 요즘 앱들은 사용자보다 **개발자 중심으로 최적화**되어 있음 처음엔 장인정신으로 만든 네이티브 앱이 인기를 얻지만, 회사가 커지면 실험과 텔레메트리, 빠른 반복이 우선이 됨 독점적 지위 덕분에 품질은 중요하지 않게 되고, 결국 **Electron 덩치 앱**이 되어도 아무도 어쩌지 못함 - 교체 이유는 명확함. 웹 버전에서 새 기능을 빠르게 내보내는데, 네이티브 클라이언트는 그걸 따라잡기 어려웠음 그래서 결국 **웹 래퍼**로 전환한 것임 요즘 ‘네이티브 Windows 앱’이란 개념 자체가 모호하고, 성능이나 오프라인 대응도 웹으로 충분히 구현 가능함 다만 GPU 프로세스가 400MB까지 커지는 건 좀 웃김. 그래도 Meta 같은 대기업이니까 가능한 일이라 생각함 - 이제는 Windows조차 **네이티브 느낌**이 거의 사라진 듯함 - 사실 예전 네이티브 클라이언트가 기능적으로 더 앞서 있었음. **영상 통화** 같은 기능도 있었음 Meta가 웹 클라이언트를 주력으로 삼으면서, 비모바일 플랫폼은 전부 웹으로 통합한 듯함 - 나는 항상 ‘모든 걸 웹으로 하자’는 개발자들과 싸우고 있음 “Firefox가 지원 안 해. Chrome 안 써.”가 내 **최종 무기**였는데, 요즘은 Safari 핑계도 써야 함. React 때문임 - 2012년에 Facebook이 HTML5 앱을 버리고 **iOS 네이티브 코드로 재작성**했던 걸 생각하면 이번 결정은 역행처럼 보임 관련 글: [Making News Feed Nearly 50% Faster on iOS](https://engineering.fb.com/2014/10/31/ios/making-news-feed-n...) - 요즘은 아무도 네이티브 앱을 만들고 싶어하지 않거나, 그걸 주장할 위치에 있지 않은 듯함 경영진 입장에서는 여러 플랫폼에 같은 기능을 개발하는 게 낭비로 보이니까 **숫자 중심 개발**로 흐름 성능이나 메모리 사용은 고려되지 않고, “웹앱도 충분히 빠르다”는 인식이 퍼져 있음 - 나는 WhatsApp의 **옛 네이티브 Windows 앱**이 정말 끔찍했다고 생각함 자주 입력이 멈추거나 악센트 문자가 깨져서 재시작해야 했음. 새 Electron 앱은 무겁지만 적어도 **제대로 작동함** - 나도 같은 버그를 봤음. 요즘은 채팅 앱 만드는 게 불가능한 과학처럼 느껴짐. **ICQ 시절**엔 다 됐는데, 그 기술이 사라진 듯함 - “작동한다”는 표현이 과장일 수도 있음. Linux로 옮긴 뒤엔 오히려 속이 시원했음 - 나도 헤비 유저인데, 이번 변화가 오히려 기대됨. Electron이라도 예전보단 나을 거라 믿음 - 사실 Electron이 아니라 **WebView2** 기반임 [Microsoft WebView2 공식 페이지](https://developer.microsoft.com/en-us/Microsoft-edge/webview2/?form=MA13LH) - Meta가 그렇게 인재가 많다면서 이런 앱을 내놨다는 게 믿기지 않음 - 예전엔 **128MB RAM**과 단일 코어 CPU로도 음성·영상 통화가 가능했는데, 지금은 효율이 퇴보한 것 같음 - 사실 이건 **Jevons 역설**의 사례임. 효율이 높아질수록 자원 소비가 늘어남 JS와 웹의 성능 향상은 결국 더 많은 광고와 코드 배포로 이어졌음 [Jevons paradox 위키](https://en.wikipedia.org/wiki/Jevons_paradox) - 물론 예전엔 해상도와 비트레이트가 낮고 암호화도 없었지만, 그래도 지금보다 효율적이었던 건 사실임 - 나도 32MB RAM의 ThinkPad로 모든 걸 잘 했던 기억이 있음 - WhatsApp이 웹 래퍼 → 네이티브 → 다시 웹으로 돌아간 건 흥미로운 순환임 네이티브 유지 비용이 크다고 하지만, 이렇게 **몇 년마다 리라이트**하는 게 더 낭비 아닌가 싶음 - 내부 정치 싸움의 결과일 수도 있음. **잘못된 기술 결정**을 내린 사람이 승진했을 뿐임 - 웹 개발자들은 대부분 시간을 **의존성 업데이트**나 프레임워크 싸움(특히 React 욕)으로 보냄 - 아무도 “앱을 다시 쓰지 말자”고 해서 승진한 적은 없음 - Windows의 네이티브 프레임워크가 너무 **엉망**이라 Microsoft조차 안 씀. 버그와 누락된 기능이 많고, Chrome은 이런 문제를 겪지 않음 - 결국 **승진 인센티브** 문제임. 잘 돌아가는 앱을 유지한다고 보상받지 못함 - 나는 자주 여행을 다니는데, **여러 휴대폰에서 WhatsApp을 동시에** 쓸 수 있으면 좋겠음 여행용 폰을 초기화할 때마다 백업·복원이 번거로움 - 지금은 최대 4~5대까지 설치 가능함. 메인 기기 외에도 클라이언트들이 독립적으로 메시지를 주고받을 수 있음 - 나는 WhatsApp을 안 쓰지만, **Telegram**은 여러 기기에서 완벽히 동기화됨. 요즘은 다들 Telegram을 씀 - 초기화한 폰에는 어떤 앱을 설치하는지 궁금함 - Meta의 **AI 코딩 에이전트**가 네이티브 앱 하나 제대로 못 유지한 건가 하는 생각이 듦 - 하지만 **AI로 만든 네이티브 앱**이라도 크게 다르진 않았을 것 같음 - 이런 **웹 기반 전환 추세**는 앞으로도 계속될 것 같음 Microsoft의 **New Outlook**도 사실상 웹 클라이언트를 EXE로 감싼 형태임 덕분에 COM Add-in, VBA, MAPI, .PST 지원 같은 핵심 기능이 사라졌음 이런 흐름이 결국 **문명 붕괴의 신호**일지도 모름 관련 글: [Collapse of Civilization](https://news.ycombinator.com/item?id=25788317) - New Outlook에서 **검색 기능이 제대로 작동하지 않음**. 자기 자신에게 보낸 메일도 몇 개만 나옴 - 우리 조직에서도 모두 **옛 Outlook이 훨씬 낫다**고 불평함 - **Flutter**가 좋은 절충안이 될 수 있었을 것 같음 크로스플랫폼 데스크톱 앱을 효율적으로 만들고, 리소스도 훨씬 덜 쓸 수 있었을 것임 - 실제로는 메모리를 많이 쓰는 게 아니라 **V8이 예약만** 하는 것일 수도 있음 Windows에서 256MB 단위로 예약하기 때문에, 여러 프로세스가 있으면 1GB까지 잡히는 것처럼 보임 작업 관리자에서 보이는 건 실제 사용량이 아니라 **Chromium의 예약 메모리**임 WhatsApp의 잘못이라기보단 Chromium의 구조적 문제임 - 그래도 그런 플랫폼을 선택한 건 **책임이 있음** 메모리를 먹는 걸 알면서도 Electron을 택한 건 결국 그들의 결정임 예전 iOS WhatsApp이나 2018년 Windows 버전과 비교해도 기능 차이는 거의 없을 텐데, 굳이 새로 만들 이유가 있었는지 의문임