> 참고: 이 글은 Ars Technica 원문 전문을 확인하지 못한 채 썼어요. 확인된 건 '윈도우 11 우클릭 메뉴가 개선되고, 같은 시기에 PC 매출이 줄고 있다'는 제목 수준의 사실까지예요. 바뀌는 항목과 배포 일정, 매출 수치는 원문에서 확인해 주세요. 아래 내용은 기존에 공개된 기술 자료를 바탕으로 한 배경 설명이에요.
윈도우 11에서 파일을 우클릭했다가 '추가 옵션 표시'를 한 번 더 눌러 본 적, 다들 있으시죠? 압축을 풀거나 터미널을 열려고 우클릭했는데 원하는 메뉴가 없어서 한 단계 더 들어가야 하는 그 경험이요. 마이크로소프트가 바로 이 우클릭 메뉴를 손본다는 소식이에요. 사소해 보여도 하루에 수십 번 반복하는 동작이라, 2021년 윈도우 11 출시 때부터 꾸준히 불만이 나왔던 부분이거든요.
타이밍도 눈여겨볼 만해요. PC 매출이 줄어드는 시기에 나온 개선이니까요. 새 기능을 얹기보다 기본기를 다듬는 쪽으로 무게가 옮겨 가는 흐름과도 맞닿아 있어요.
우클릭 메뉴는 왜 두 개가 됐을까
이 문제를 이해하려면 메뉴가 왜 둘로 나뉘었는지부터 봐야 해요. 겉보기엔 디자인 변경 같지만, 사실은 구조 문제였거든요.
예전 윈도우에서는 앱이 우클릭 메뉴에 항목을 넣을 때 '셸 확장(shell extension)'이라는 걸 썼어요. 이게 뭐냐면, 앱이 만든 DLL(실행 코드 묶음)을 탐색기 프로세스 안에 직접 끼워 넣는 방식이에요. IContextMenu라는 오래된 COM 인터페이스를 쓰고요. 비유하자면 우리 집 거실에 아무나 들어와서 자기 물건을 펼쳐 놓게 허락한 셈이에요. 앱을 많이 깔수록 메뉴가 길어지고, 확장 하나가 느리면 우클릭 전체가 버벅이고, 확장 하나가 죽으면 탐색기까지 같이 넘어가기도 했어요.
그래서 윈도우 11은 새 방식을 내놨어요. 앱이 IExplorerCommand 인터페이스를 구현하고, MSIX 패키지나 스파스 패키지(설치 방식은 그대로 두고 앱 신원만 부여하는 가벼운 패키지)로 '나는 이런 메뉴를 넣겠다'고 선언하게 한 거예요. 탐색기가 앱 코드를 마구 불러오지 않도록 제어하기 쉬워지니 더 빠르고 안전해지죠. 옛날 방식으로 만든 항목은 '추가 옵션 표시' 안쪽의 구형 메뉴로 밀려났고요.
문제는 여기서 생겼어요. 구조는 좋아졌는데, 많은 앱이 새 방식으로 바로 옮겨 오지 않았거든요. 사용자 입장에서는 늘 쓰던 압축 프로그램이나 Git 도구 메뉴가 사라진 것처럼 보였어요. 잘라내기, 복사 같은 기본 동작이 글자 없는 아이콘으로 바뀐 것도 적응을 어렵게 했고요. 그래서 Shift+F10으로 구형 메뉴를 바로 열거나, 아래처럼 레지스트리를 고쳐서 옛날 메뉴로 되돌리는 비공식 방법까지 널리 퍼졌어요.
reg add HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32 /f /ve
공식 지원 방법이 아니라서 업데이트로 동작이 달라질 수 있다는 점은 기억해 두세요.
업계 흐름에서 보면
'제3자 코드를 핵심 프로세스에서 떼어 내자'는 건 윈도우만의 고민이 아니에요. macOS의 Finder는 앱 확장과 빠른 동작(Quick Actions)이라는 정해진 틀로 메뉴 확장을 받아요. 브라우저 확장이 Manifest V3로 옮겨 간 것, VS Code가 확장을 별도 프로세스에서 돌리는 것도 같은 맥락이에요.
다만 윈도우의 어려움은 호환성의 무게예요. 수십 년간 쌓인 앱 생태계를 한 번에 옮길 수 없으니, 두 메뉴가 약 5년을 공존한 거죠.
2026년 들어 마이크로소프트가 윈도우 품질 개선을 공개적으로 약속한 것도 함께 볼 만해요. 2025년 10월 윈도우 10 지원 종료로 당겨진 교체 수요가 지나갔고, 메모리 가격 상승도 PC 시장에 부담이 됐어요. 이번 매출 감소의 직접 원인은 원문 수치를 봐야 알 수 있지만, 사용자가 매일 느끼는 불편을 줄이는 일의 무게가 커진 건 사실로 보여요.
한국 개발자에게 주는 시사점
윈도우용 데스크톱 앱을 만든다면 이 소식은 꽤 실무적이에요. 국내에는 압축 프로그램, 문서 뷰어, 사내 보안 도구처럼 탐색기 메뉴에 붙는 프로그램이 많잖아요. 아직 IContextMenu만 쓰고 있다면 IExplorerCommand와 스파스 패키지로 옮길 계획을 세워 보세요. 다만 이번 개선이 구형 항목의 노출 방식까지 바꾸는지는 원문과 공식 문서로 먼저 확인하는 게 좋아요.
테스트할 때는 두 메뉴를 모두 확인하세요. 마이크로소프트는 새 기능을 사용자별로 단계적으로 배포하는 경우가 많아서, 같은 빌드인데도 팀원마다 화면이 다를 수 있거든요. 재현 환경과 절차를 문서로 남겨 두면 나중에 고생을 덜어요.
윈도우 앱을 안 만드는 분에게도 배울 점이 있어요. 구조 개선 자체는 옳았지만, 사용자의 손버릇을 깨는 비용이 컸다는 점이에요. 우리 서비스의 내부 구조를 바꿀 때도 마찬가지예요. 이전 경로를 얼마나 유지할지, 외부 연동사가 따라올 때까지 얼마나 기다릴지, 변경 후 사용자의 클릭 수가 늘지 않았는지를 함께 봐야 해요.
마무리
한 줄로 정리하면, 우클릭 메뉴 문제는 단순한 디자인 취향이 아니라 보안과 성능을 위한 구조 전환이 사용자 경험과 어긋나면서 생긴 문제였어요.
여러분은 윈도우 11의 우클릭 메뉴를 그대로 쓰시나요, 아니면 구형 메뉴로 되돌려 쓰시나요? 구조는 좋아졌는데 사용자 불만이 늘어난 경험이 있다면 들려주세요.
🔗 출처: Hacker News