뉴스 알림에 가입하세요 업데이트를 절대 놓치지 마세요.
ZDNET의 주요 시사점
- Windows 11 기본 사항에 중점을 두려는 Microsoft의 계획은 좋은 첫 번째 단계입니다.
- 중요한 다음 단계는 Windows 참가자 프로그램을 개혁하는 것입니다.
- 디자인 결정에 대한 투명성이 높아지면 도움이 될 것입니다.
이 말을 들어보셨다면 멈추십시오. Microsoft는 새로운 기능과 친숙한 사용자 인터페이스를 갑자기 탈피한 새 버전의 Windows를 출시하여 엄청난 환영을 받으며 출시했습니다. 고객들은 ‘으흐흐’, ‘좋아하지 않음’, ‘으으’의 조합으로 반응한다. 이에 대응하여 CEO는 몇 가지 경영상의 변화를 꾀하고, 새로운 리더는 기본으로 돌아가 고객이 요구하는 것을 제공하겠다고 약속합니다.
Windows Vista에 대한 반응을 설명하고 있습니까? 윈도우 8? 윈도우 11? 물론 정답은 “위의 모든 것”입니다.
또한: Microsoft는 Windows의 대대적인 변경을 발표했지만 사과는 하지 않았습니다.
Windows 고장 수리 이야기의 최신 기사에서 Microsoft의 Windows + 장치 사업부 사장인 Pavan Davaluri는 Windows Insider(그리고 더 나아가 공개 릴리스를 실행하는 수십억 명 이상의 고객)에게 공개 서한을 작성하여 회사의 “품질에 대한 약속”을 강조했습니다.
편지에는 야심찬 목표에 대한 내용이 길었지만 구체적인 결과물이 부족했습니다. 그럼에도 불구하고 그것은 올바른 방향으로 나아가는 단계였습니다.
Windows 11의 반응성과 일관성을 향상시키시겠습니까? 네, 부탁드립니다. 다시 시작을 보다 명확하게 제어하여 OS, 드라이버 및 앱의 기본 안정성을 개선하고 Windows 업데이트 환경을 보다 예측 가능하게 만들고 싶으십니까? 전적으로. Copilot AI 기능이 Windows에 어떻게, 어디서 적용되는지에 대해 “보다 의도적으로” 사용하시겠습니까? 마지막으로!
또한: Microsoft 365 Copilot 출시는 완전히 재앙이었습니다.
우리는 앞으로 몇 주 안에 이러한 이니셔티브의 첫 번째 예를 보기 시작할 것입니다. Microsoft가 적극적인 경청 모드에 있는 한, 저는 Microsoft가 이러한 고상한 약속을 어떻게 이행할 수 있는지에 대해 몇 가지 구체적인 제안을 드리고 싶습니다.
1. 미리보기 빌드를 다시 유용하게 만들기
Davuluri의 공개 서한이 Windows 참가자 프로그램 회원에게 전달된 것은 우연이 아닙니다. 정의에 따르면 이들은 유용한 피드백을 제공하고 테스트 랩에서는 나타나지 않는 실제 사용 사례에서 제품을 사용해 볼 가능성이 가장 높은 Microsoft 최고의 고객 중 일부입니다.
지난 11월, 저는 Windows 참가자 프로그램의 간략한 역사를 작성하여 최근 몇 년간 프로그램의 점진적인 악화에 대한 불만을 토로했습니다. Windows 11 개발이 고객과 단절되고 동기화되지 않은 것처럼 느껴지는 이유를 찾고 있다면 아마도 여기에서 시작해야 할 것입니다.
또한: Windows Insider 프로그램은 혼란스럽습니다.
12년 전, Windows 10 개발 주기가 시작되면서 Microsoft는 Insider 프로그램을 시작했습니다. 이는 기업 고객, 교육자 및 매니아들에게 새로운 Windows 버전이 출시되기 몇 달 전에 시험해 볼 수 있는 기회를 제공했기 때문에 매우 큰 일이었습니다. 수백만 명의 테스터가 버그 보고서와 원격 측정을 제공하므로 심각한 버그가 세상에 퍼지기 전에 신속하게 처리될 가능성이 꽤 있었습니다.
이 모든 것은 다양한 Insider 채널(Release Preview, Beta, Dev, Canary)이 공개 릴리스에서 연결이 끊어지면서 2022년에 끝났습니다. 내 겸손한 제안? 그 연결을 다시 가져오세요.
- 베타 채널은 다음 H2 기능 업데이트의 미리보기가 되어야 하며, 출시 날짜가 다가옴에 따라 점차적으로 더욱 다듬어지는 월간 릴리스가 포함됩니다.
- Release Preview 채널은 관리자가 향후 릴리스를 테스트하여 널리 배포하기 전에 문제를 식별할 수 있도록 하는 것을 목표로 대중에게 공개될 내용의 미리보기여야 합니다.
- 실험은 특정 릴리스에 연결될 필요가 없는 Dev 및 Canary 채널에 맡기십시오.
너무 많은 것을 요구하는 것은 아닌 것 같습니다.
2. 품질 테스트와 기능 테스트를 분리하세요
Windows 11 개발자가 수행한 가장 근본적으로 비생산적인 조치 중 하나는 참가자 프로그램을 새로운 기능에 대한 대규모 AB 테스트로 전환하는 것이었습니다. 새로 출시된 빌드에 대한 문서에서는 새로운 기능이나 사용자 인터페이스의 변경 사항을 집중 조명할 수 있지만 모든 테스터가 이를 볼 수 있는 것은 아닙니다. 그 결과는 대규모 혼란이었다.
또한: 저는 10년 동안 Windows 원격 측정을 연구해 왔습니다. 제가 끄는 유일한 설정은 다음과 같습니다.
내 목표가 Windows 빌드의 품질을 스트레스 테스트하는 것이라면 이러한 불일치로 인해 미칠 것입니다. 내 목표가 다음 버전의 Windows에 무엇이 나올지 이해하는 것이라면 이러한 불일치로 인해 미칠 수도 있습니다.
이러한 게이트키핑을 해결하기 위해 일부 내부자는 숨겨진 실험 기능을 켜거나 끄는 ViVeTool이라는 비공식 오픈 소스 명령줄 유틸리티를 사용합니다.
그렇다면 기능을 수정하려는 테스터가 AB 테스트를 선택하도록 허용하는 것은 어떨까요? 버전 A에서 B로 전환하고 다시 버전으로 전환할 수 있는 옵션을 사용하여 선택한 각 내부자가 테스트 중인 기능을 문서화할 수도 있습니다.
3. 공개 릴리스의 도랑 제어 기능 출시
여러분과 제가 모두 기능적으로 동일한 하드웨어에 Windows의 최신 공개 릴리스를 설치한다면 동일한 경험을 하게 될 것입니다. 그렇죠?
죄송합니다. Microsoft의 “지속적인 혁신” 이니셔티브와 “제어 기능 롤아웃”이라는 기술 덕분에 더 이상 상황이 작동하지 않습니다.
Microsoft가 해당 기술을 설명하는 방법은 다음과 같습니다.
Microsoft는 기존 Windows 월간 업데이트 프로세스를 사용하여 Windows 11에 새로운 기능과 향상된 기능을 더 자주 출시함으로써 지속적인 혁신을 제공하기 위해 최선을 다하고 있습니다. 우리의 단계적이고 신중한 접근 방식은 Windows 참가자 프로그램 및 Microsoft Edge에서도 사용되는 CFR(제어 기능 롤아웃) 기술을 사용하여 새로운 기능을 도입할 수 있습니다.
해당 각주를 따르면 다음과 같은 설명을 얻을 수 있습니다.
¹CFR을 사용하면 월별 선택적 비보안 미리 보기 릴리스를 설치하는 장치부터 시작하여 기능이 점진적으로 출시될 수 있습니다. 각 기능이 준비되었음을 확인한 후 점진적으로 새 장치에 출시하고 최종적으로는 후속 월별 보안 업데이트에 기본적으로 활성화되도록 포함할 것입니다.
지난 11월에 제가 지적했듯이 제어 기능 롤아웃의 목표는 합리적으로 보입니다. 즉, 릴리스된 Windows 버전을 실행하는 사람들의 작업을 방해하지 않도록 변경 사항을 확인하는 것입니다. 하지만 이것이 전체 Insider 프로그램의 요점이 아닙니까? 제어된 기능 출시는 Windows 릴리스 버전을 실행하는 모든 고객이 이제 또 다른 테스트 채널의 구성원이 된다는 것을 의미하지 않습니까? 그렇다면 현재 Windows 11 공개 릴리스를 실행하는 두 PC의 시작 메뉴 레이아웃이 다른 이유는 무엇입니까? 내가 기업 트레이너라면, 동료들과 기능이 다른 일부 사람들이 있고 그들의 버전이 언제 바뀔지 모른다는 사실을 학급 사람들에게 어떻게 말해야 합니까?
그리고 제가 질문하는 한, 현재 보안 업데이트라고 불리는 것에서 새로운 기능이 출시되는 이유는 무엇입니까?
모든 고객에게 기능을 안정적으로 제공할 수 없다면 공개 출시 준비가 되지 않은 것입니다. 하드웨어가 지원하는 한 공개 빌드가 모든 사람에게 동일하게 작동하도록 만드세요. 동일한 Windows 11 빌드를 실행하는 두 대의 컴퓨터가 나란히 있는 경우 동일한 기능을 사용할 수 있어야 합니다.
4. 결정 이면에 있는 ‘이유’를 더 많이 공개하세요.
실망스럽고 혼란스러운 Windows Vista 릴리스 이후 Steven Sinofsky가 Windows 개발 책임자로 취임했을 때 그가 소개한 것 중 하나는 “Engineering Windows 7″(간단히 E7)이라는 블로그였습니다. 이 책은 2008년 8월부터 2010년 2월까지 출판되었습니다. (궁금한 분들을 위해 Sinofsky가 제공하는 인터넷 아카이브에서 대부분의 완전한 사본을 보실 수 있습니다.)
해당 페이지는 오래 전에 Microsoft 서버에서 제거되었지만 2008년 Windows Experience 블로그에 게시된 서명되지 않은 이 게시물은 어떻게든 살아 남았습니다.
Windows 7 엔지니어링 블로그는 Windows 7 엔지니어링에 대한 공개 토론을 만들기 위해 설계되었습니다. 어떻게 우리는 현재 코드명 Windows 7인 Windows의 다음 버전을 만들고 있습니다. 내려진 엔지니어링 결정에 대한 이해의 배경을 조성합니다. Windows 7을 출시하기 위해. (원본에서는 강조)
현재 가장 많이 사용되는 운영 체제의 다음 버전을 엔지니어링하는 것은 매우 복잡한 소프트웨어 프로젝트입니다. 왜? Windows는 매우 큰 사용자 기반을 갖고 있고 그 사용자 기반도 매우 다양하기 때문입니다. Windows의 다음 버전을 계획하고 궁극적으로 개발하는 것은 Microsoft가 현재 Windows를 사용하는 모든 유형의 고객의 요구 사항을 배우고 이해해야 하기 때문에 매우 중요한 작업입니다. Windows 7 엔지니어링 블로그에서는 Windows 7을 고객에게 제공하기 위해 고객의 요구 사항을 균형 있게 조정하는 방법에 대한 양방향 토론을 기대할 수 있습니다.
Windows 7 엔지니어링 블로그에서 찾을 수 없는 한 가지는 주요 제품 발표입니다. 초점은 단순히 Windows 7의 엔지니어링에 대해 논의하는 것입니다.
E7 블로그는 엔지니어와 제품 디자이너가 Windows 7을 구축하는 방법을 결정한 이유에 대한 자세한 토론을 통해 진정으로 혁명적이었습니다. 또한 오늘날 Microsoft의 Windows 블로그에 게시되는 많은 내용을 정의하는 마케팅 용어가 전혀 없었습니다. 가장 중요한 것은 그 블로그가 중요한 일을 성취했다는 것입니다. 즉, Microsoft가 순전히 임의적인 이유로 자신이 좋아하는 기능을 변경했다고 확신하는 회의적인 고객에게 직접적으로 이야기했다는 것입니다.
Windows를 구축하는 사람들이 피드백을 듣고 있다는 점을 고객에게 확신시키고 싶다면 해당 수준의 기술 투명성을 확보하십시오. 마케팅 담당자에게 손을 대지 말라고 말하세요.