Windows 11 새 Media Player, RAM 3.5배 더 쓰고 인기 동영상 코덱은 유료화

 (extremetech.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Windows 11의 새 Media Player는 기본 미디어 앱으로 이동하는 과정에서 메모리 사용량과 코덱 과금이 함께 논란이 되고 있음
  • Windows Latest 테스트 기준 유휴 상태 RAM 사용량은 새 플레이어가 약 377MB, 기존 Windows Media Player가 약 103MB로 약 3.5배 차이남
  • 로컬 동영상 파일 시작 시간도 기존 약 2초에서 새 플레이어 약 3초로 늘어 약 50% 증가함
  • Microsoft는 HEVC(H.265) 재생을 유료 “HEVC Video Extensions”로 제공하고, Windows 11 24H2에서는 내장 AC-3(Dolby Digital) 코덱도 제거함
  • VLC처럼 자체 코덱을 포함한 서드파티 플레이어는 Microsoft의 유료 확장 기능에 덜 의존하는 대안이 될 수 있음

새 Media Player의 성능 부담

  • Windows 11의 새 Media Player는 Groove Music과 클래식 Windows Media Player를 대체하는 기본 앱 역할을 맡음
  • Windows Latest 테스트에서는 아무 작업도 하지 않는 유휴 상태에서도 메모리 사용량 차이가 크게 나타남
    • 새 Media Player: 약 377MB RAM
    • 기존 Windows Media Player: 약 103MB RAM
    • 차이는 약 3.5배

로컬 동영상 실행 속도 저하

  • 로컬 동영상 파일을 여는 시간도 새 Media Player에서 더 길어짐
    • 기존 플레이어: 약 2초
    • 새 Media Player: 약 3초
    • 시작 시간이 약 50% 증가함

코덱 지원과 유료 확장

  • Microsoft는 HEVC(H.265) 재생을 Microsoft Store의 유료 “HEVC Video Extensions” 앱으로 제공함
  • Windows 11 버전 24H2에서는 내장 AC-3(Dolby Digital) 코덱이 제거됨
    • 해당 시스템의 새 Media Player는 AC-3 오디오 트랙을 기본으로 재생할 수 없음

기본 앱 전환과 남아 있는 선택지

  • 새 Media Player는 모든 Windows 11 PC에서 Groove Music과 클래식 Windows Media Player를 대체함
  • 클래식 Windows Media Player는 선택적 구성 요소로 계속 제공되지만, 기본 선택지는 새 Media Player 쪽으로 이동하고 있음
  • 서드파티 플레이어를 써도 괜찮다면 VLC 같은 대안도 있음
    • VLC는 자체 코덱을 포함해 Microsoft의 유료 추가 기능에 의존하지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • HEVC 지원 제거는 Microsoft의 선택이라기보다 라이선스 풀 가격 인상 때문일 가능성이 큼
    요즘 Windows Media Player 사용량 자체가 적고, HEVC 재생은 더 적을 것임. 대부분의 콘텐츠 재생은 스트리밍과 브라우저에서 일어남. RAM 증가도 운영체제 네이티브 프런트엔드 API 대신 JS/TS로 프런트엔드를 만드는 흐름의 결과로 보임. 앱 개발 측면에서는 JS UI 개발자를 훨씬 쉽게 뽑을 수 있고, LLM도 UML보다는 React 앱을 훨씬 잘 다룰 가능성이 큼
    [1]: https://arstechnica.com/gadgets/2026/04/lawsuits-licensing-a...

    • 사용자에게는 나빠지고 개발자에게는 쉬워지는 절충은 받아들일 수 없고, 비판받아 마땅함
    • Google과 Apple도 약간 오른 라이선스 비용을 내는 대신 흔한 동영상 형식 지원을 제거했다면 조금은 이해했을지도 모름
      Microsoft는 성과 없는 인수합병에 큰돈을 쓸 때는 세상 모든 돈을 가진 것처럼 행동함. 그 돈 일부를 사용자 경험 유지에 써야 함. Dell 같은 회사들이 RAM 8GB짜리 새 Windows 노트북을 내놓는 상황에서 불필요한 메모리 팽창은 용납하기 어려움
    • 지금쯤이면 AI에게 2010년 이후 작성된 모든 UI 코드를 Win32와 MFC로 대충 다시 쓰게 해도, 요즘 밀어붙이는 쓰레기보다 훨씬 나은 결과가 나올 것 같음
    • RAM 증가가 OS 네이티브 프런트엔드 API 대신 JS/TS로 프런트엔드 엔지니어링을 하는 흐름 때문이라면, 왜 이런 다중 운영체제 앱 빌드 도구들은 네이티브 코드로 컴파일하고 네이티브 API를 활용하지 않는지 궁금함
      그런 도구가 아예 없는 건가?
    • 이 앱은 JS/TS를 쓰지 않음. 스킨을 바꾼 Groove Music이고, 전부 C++ 또는 C#일 것 같으며 아마 C# + UWP/WinUI2 XAML 기반임
      Windows 8.x의 Xbox Music은 실제로 웹 기술 기반이었지만, Windows 10에서 Groove Music으로 바뀌면서 C#과 XAML로 다시 작성됨

  • Microsoft가 Copilot으로 바이브 코딩을 이 정도까지 내부 적용하는 건 인정해야 할 듯함
    고객에게 나쁜 해법을 쓰라고 권하면서 내부에서는 다른 걸 쓴다고는 할 수 없게 됨

    • 이 앱은 스킨을 바꾼 Groove Music이고, 대부분은 Windows 10 초기인 2014~2017년에 작성되어 Copilot보다 훨씬 이전의 코드임
      Windows 11에서 Media Player로 리브랜딩된 것도 2022년쯤이라 그 흐름보다 앞서고, 이후로는 거의 손대지 않은 상태임

  • 흥미로운 건 이게 웹 버전도 없는 네이티브 앱인데도 HTML/JS로 작성하기로 했다는 점임
    Microsoft가 WinUI로 다시 만들겠다고 한 뒤의 일이라 더 이상함. 네이티브가 HTML/JS보다 마찰이 큰 건 이해하지만, 에이전트형 개발이 등장하면서 그 장벽은 많이 낮아졌음. 제대로 생각하고 만든 것 같지 않음

    • HTML/JS를 쓰지 않음. 적어도 C#을 네이티브로 친다면 완전한 네이티브 앱이고, C#과 UWP/WinUI2 XAML로 작성됨
      Windows 8.x의 Xbox Music은 웹 기술 기반 UI였지만, Windows 10에서 Groove Music으로 리브랜딩되면서 UI 계층이 다시 작성됨. Xbox Music 자체도 Zune의 UI 계층을 스킨 변경/재작성한 것이었고 Zune은 C++였으니, 이미 네이티브→웹→네이티브 한 바퀴를 돈 셈임. “새” Media Player도 패키지 메타데이터에서는 아직 “ZuneMusic”으로 식별됨. 또한 Groove Music은 주로 2014~2017년 Windows 10 초기에 작성됐고, Windows 11의 Media Player 리브랜딩도 2022년에 있었으며 이후 거의 바뀌지 않았음
    • 사실 장벽이라고 할 것도 거의 없음. WinForms나 WPF에서 UI 만드는 게 실제로 어렵지 않고, WinUI도 마찬가지일 거라고 봄
      문제는 어렵다는 게 아니라 많은 사람이 HTML/JS 안락지대를 벗어나려는 시도조차 하기 귀찮아한다는 데 있음

  • 클래식 버전 이후로 Microsoft의 형편없는 미디어 플레이어를 자발적으로 쓴 적은 없는 것 같음
    주로 MPC-BE를 쓰고, 일부 코덱이 잘 안 맞으면 VLC를 예비로 씀. 둘 다 nVidia 초해상도 기능도 사용할 수 있음

  • 요즘도 플레이어에 모든 코덱을 설치하려고 K-Lite Codec Pack을 쓰는 사람이 있나? 아니면 그냥 VLC를 쓰나?

    • XP 시절에는 K-Lite Codec Pack과 CCCP(Combined Community Codec Pack)를 좋아했음. 특히 MKV와 애니메이션 파일을 이것저것 보던 때 유용했음
      하지만 요즘은 VLC나 MPC-HC가 기본으로 재생하지 못하는 미디어 파일을 거의 만나지 않음. 그냥 넣으면 재생됨
    • 요즘은 SMPlayer만 설치해도 플레이어 안에 코덱이 다 포함되어 있음
    • 그런 방식은 약 10년 전에 사실상 사라졌음
      대부분이 H.264, H.265, VP9, AV1, MP3, AAC이기 때문임
    • mpv

  • 최신 Media Player가 유휴 상태에서 약 377MB RAM을 쓰고, 구형 플레이어는 약 103MB였다는 건데, 아무것도 안 하는 데 103MB도 많아 보임

    • 미디어 플레이어라면 앨범 커버 이미지와 짧은 오디오 조각을 즉시 재생하려고 메모리에 많이 올려두는 건 이상하지 않음
      전체 라이브러리의 메타데이터와 여러 색인도 있을 것임. SSD가 빨라졌으니 새 플레이어는 캐시를 덜 할 거라고 기대할 수도 있지만, 인터넷 기반이든 로컬 HDD NAS든 네트워크 저장소 사용 증가가 이를 상쇄할 수 있음
    • 같은 파일로 재보니 mpv도 144MB, VLC도 144MB가 나옴
      RAM을 더 적게 쓰는 다른 선택지가 있나?

  • HEVC가 유료화됐다는 기사는 2018년에도 이미 찾을 수 있음
    그리고 여기서 말하는 “새” Media Player가 뭘 뜻하는지도 애매함. 2022년에 배포된 앱임. 이 기사는 엉망이고, 원 출처 기사는 괜찮음
    [0]: https://www.windowscentral.com/microsoft-now-charging-hevc-v...
    [1]: https://en.wikipedia.org/wiki/Windows_Media_Player_(2022)
    [2]: https://www.windowslatest.com/2026/06/16/microsoft-reveals-w...

    • 거의 10년 전부터 별로였다는 뜻이니, 내 경험과도 맞아떨어짐

  • “나쁜 설계의 프랙털”이라는 표현을 PHP에 써버린 게 아쉬울 정도로, Microsoft에서 나오는 많은 것들에 잘 맞음
    몇 주 동안 PowerBI를 쓰고 있는데, 망가지는 방식이 새로워서 가끔 감탄하게 됨

  • 공인 Microsoft 안티팬이지만, 비교하자면 Apple의 Music.app도 RAM을 대략 580MiB 정도 씀

    • Windows용 iTunes는 아직도 물 호스처럼 메모리가 새고, 온라인 라디오를 듣다 보면 4GB까지 올라갈 수 있음

  • 관리 코드로 작성됐으니 뭘 기대하겠음? 예전 Windows 핵심 앱들은 순수 C++였음
    “안전한” 언어를 충분히 오래 요구했다면 RAM 비용도 감수해야 함

    • WinUI와 WinAppSDK는 대부분 C++인 WinRT 위에 만들어져 있음
      여기서 웃긴 점은 Windows 부서가 Vista가 Longhorn을 이긴 뒤 COM을 갱신한 형태로 .NET을 죽이려 했고, AddRef/Release 때문에 WPF 앱보다 느려졌다는 것임
      https://arstechnica.com/features/2012/10/windows-8-and-winrt...
답변달기