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을 더 적게 쓰는 다른 선택지가 있나?