메타, Windows 11용 WhatsApp 네이티브 앱을 중단하고 웹 래퍼(WebView)로 교체

 (windowslatest.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 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가 비용 절감을 위해 웹 코드베이스 유지로 전환했을 가능성을 언급했으나,
    구체적 이유는 명시되지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 내가 직접 설계하고 지켜온 앱이 이렇게 바뀌어버려서 조금 씁쓸한 마음임
    예전의 네이티브 앱은 완벽하진 않았지만, 생산성 도구로서 환경을 존중하려는 느낌이 있었음
    결론적으로 대기업에게 네이티브 데스크톱 앱은 현실적으로 불가능하다고 봄. 이유는 조율 비용 때문임
    여러 플랫폼에서 동시에 기능을 출시하려면 복잡도가 기하급수적으로 늘어남. 느긋한 개발 속도라면 가능하겠지만, 빠른 실험과 반복을 원한다면 결국 웹 코드 한 번 쓰는 게 낫다는 결론에 다다름
    요즘은 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
    • 요즘은 아무도 네이티브 앱을 만들고 싶어하지 않거나, 그걸 주장할 위치에 있지 않은 듯함
      경영진 입장에서는 여러 플랫폼에 같은 기능을 개발하는 게 낭비로 보이니까 숫자 중심 개발로 흐름
      성능이나 메모리 사용은 고려되지 않고, “웹앱도 충분히 빠르다”는 인식이 퍼져 있음

  • 나는 WhatsApp의 옛 네이티브 Windows 앱이 정말 끔찍했다고 생각함
    자주 입력이 멈추거나 악센트 문자가 깨져서 재시작해야 했음. 새 Electron 앱은 무겁지만 적어도 제대로 작동함

    • 나도 같은 버그를 봤음. 요즘은 채팅 앱 만드는 게 불가능한 과학처럼 느껴짐. ICQ 시절엔 다 됐는데, 그 기술이 사라진 듯함
    • “작동한다”는 표현이 과장일 수도 있음. Linux로 옮긴 뒤엔 오히려 속이 시원했음
    • 나도 헤비 유저인데, 이번 변화가 오히려 기대됨. Electron이라도 예전보단 나을 거라 믿음
    • 사실 Electron이 아니라 WebView2 기반임
      Microsoft WebView2 공식 페이지
    • Meta가 그렇게 인재가 많다면서 이런 앱을 내놨다는 게 믿기지 않음

  • 예전엔 128MB RAM과 단일 코어 CPU로도 음성·영상 통화가 가능했는데, 지금은 효율이 퇴보한 것 같음

    • 사실 이건 Jevons 역설의 사례임. 효율이 높아질수록 자원 소비가 늘어남
      JS와 웹의 성능 향상은 결국 더 많은 광고와 코드 배포로 이어졌음
      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

    • New Outlook에서 검색 기능이 제대로 작동하지 않음. 자기 자신에게 보낸 메일도 몇 개만 나옴
    • 우리 조직에서도 모두 옛 Outlook이 훨씬 낫다고 불평함

  • Flutter가 좋은 절충안이 될 수 있었을 것 같음
    크로스플랫폼 데스크톱 앱을 효율적으로 만들고, 리소스도 훨씬 덜 쓸 수 있었을 것임

  • 실제로는 메모리를 많이 쓰는 게 아니라 V8이 예약만 하는 것일 수도 있음
    Windows에서 256MB 단위로 예약하기 때문에, 여러 프로세스가 있으면 1GB까지 잡히는 것처럼 보임
    작업 관리자에서 보이는 건 실제 사용량이 아니라 Chromium의 예약 메모리임
    WhatsApp의 잘못이라기보단 Chromium의 구조적 문제임

    • 그래도 그런 플랫폼을 선택한 건 책임이 있음
      메모리를 먹는 걸 알면서도 Electron을 택한 건 결국 그들의 결정임
      예전 iOS WhatsApp이나 2018년 Windows 버전과 비교해도 기능 차이는 거의 없을 텐데, 굳이 새로 만들 이유가 있었는지 의문임
답변달기