Windows 7 개발 프로젝트 구성(Organizing the Windows 7 Project)
안녕하세요 Jon DeVaan입니다.
Steven은 우리가 일을 하는데 있어서 매우 중요한 요소인 것, 즉, 어떻게 우리가 엔지니어링“팀”을 구성하고 있는지에 대해 썼습니다. 또 하나의 중요한 요소는 어떻게 우리가 엔지니어링“프로젝트”를 구성하는지 입니다.
우선 몇 가지 양해 말씀을 드리고 시작하겠습니다. 하나는 Steven은 저보다 10배 정도는 빨리 글을 읽고 씁니다. 따라서, 두 사람의 문서를 비교하여 그 정도의 차이가 있다 해도 놀라지 말세요. (저는 이런 생각을 자주하는 편인데, 단지 저만의 질투일지도 모릅니다.) 두 번째는 우리는 “어떻게 Windows를 개발하고 있는가”라는 주제를 공유하고 싶습니다. 왜냐하면, 이렇게 하는 것이, PDC와 WinHEC 가 가까워져 세부 사항기능에 대한 논의를 시작할 때 공통의 문맥을 유지할 수 있기 때문입니다. 우리는 Longhorn/Vista의 교훈을 살려서 어떻게 Windows 7을 개발하고 있는지 말씀 드리고 싶습니다. 이런 모든 사실이 Windows7에 대한 판단에 관계됩니다.
그러면, 이야기를 시작하겠습니다.
Steven가 전에 Microsoft Secrets라는 책을 소개했는데요, 훌륭한 분석 결과라고 생각되어, 저는 이것을 Microsoft의 공학시스템 Version2라고 부릅니다. (Version 1은 색인 카드와 “플로피를 사용한 네트워크”에 관련된, 그다지 여러분이 흥미를 느끼는 내용은 아니라고 생각합니다. ) Version 2는 생각보다 오랫동안 Microsoft에 도움이 되었습니다. Windows XP에서 얻은 교훈과 Longhorn/Vista 시대에서 현저해진 본질적으로 다른 보안 환경에서 제품을 개발하는 접근 방식을 고려할 때 세대 교체의 시기를 맞이하고 있던 것은 명확했습니다.
XP에서 배운 교훈은 우리 업계를 둘러싼 보안에 관한 생각의 변화입니다. 우리가 이 교훈을 어떻게 살렸는지는 보다 안전한 소프트웨어를 개발하기 위해서 Microsoft가 추천하는 엔지니어링 방법에 대해 정리한 Security Development Lifecycle을 읽어보시면 알 수 있을 것입니다. 우리는 내부에서도 Windows를 개발하는데 이 방법을 사용합니다.
이 Blog의 댓글을 보면, 전체 시스템 품질이 여러 가지, 각각의 사람에게 다른 중요성이 있다는 것을 알고 있습니다. 또 Vista의 전체적인 품질에 대해서도 여러 가지 의견이 있습니다. 저는 OS 기초 부분 안정성에 많은 시간을 할애하여, 실제 사용자들로부터 (물론 자발적으로 Customer Experience Improvement program에 참가해 주신 사용자 대상입니다. ) 수집한 원격 측정법 정보 분석에 많은 시간을 들이고 있습니다. 이 원격 측정법 정보가 SP1에서 무엇을 해야만 할 때의 지표가 되었습니다. 저는 Vista로 절전모드/다시 시작이 좋아지고 있다는 여러분의 코멘트를 읽고 매우 기뻤습니다. 또, 이 원격 측정법 정보를 계속 이용하여 Vista를 가장 안정성의 높은 Windows 버전으로 만드는 일에 노력할 수 있다는 것에 (실제, 우리는 그 작업을 실시하고 있습니다) 흥분했습니다. Vista의 보안 취약성을 XP의 절반 이하로 줄이는 것에 성공한 것도 언급하고 싶습니다. 이곳은 Windows 7에 관한 블로그이지만, Windows Vista가 실제로 어떻게 가동하고 있는지에 대해, 깊이 이해하는 노력을 하면서 Windows 7 작업을 진행하고 싶습니다.
무엇보다 중요한 일은 여러분은 메일이나 댓글을 통해서, 얼마나 Windows의 공학시스템을 개선할 수 있는지를 지적해 주셨습니다. 성능, 안정성, 호환성, 새로운 기술에 대응하지 못한 것 등이 댓글의 공통 테마입니다. 이런 문제 해결을 위한 하나의 접근 방식은 우리가 어떻게 Windows 7의 코드베이스 개발을 매일 관리하는지, 즉 일일 빌드 품질을 강화하고 있는지 입니다.
이것을 읽으면서 여러분은“ 당연한 것!”이라고 느끼실지도 모르지만, 그러나 저의 경험에서는 아무리 우리가 원한다 해도 소프트웨어 프로젝트의 규모나 조직에 관계없이 이것은 그렇게 간단히, 명료하게 해결할 수 있는 문제도 아닙니다.
일일 빌드 품질
소프트웨어 프로젝트에서, 매일 매일의 품질은 매우 중요합니다 왜냐하면 매일 남아 있는 작업량 예측하여, 중요한 결정을 해야 하기 때문입니다. 일일 빌드 품질이 낮으면 어느 정도의 작업이 남아 있는지 예측하기 어려워집니다. 그것은 수많은 잘못된 엔지니어링 결정으로 이어집니다. 작업에 종사하는 엔지니어 수가 증가 (왜냐하면 우리는 많은 일을 하고 싶으니까)와 일일 빌드 품질의 중요성이 한층 더 늘어납니다. 왜냐하면 한 명의 프로그래머의 오류 확률에 수반하여, 완성 노력도 증가됩니다. 문제는 제품에 몇 개 버그가 잠복하고 있을지 모른다는 것만이 아닙니다. 만약 문제가 그 정도 라면, 적어도 각각의 결말은 각각의 개발자에 맡길 수 있습니다. 무엇보다 방심할 수 없는 부작용은 각각의 개발자가 일일 업데이트 결과를 개인의 작업에 반영할 자신이 없어졌을 때입니다. 이러한 사태가 일어나면, 우리가 모르는 버그, 호환성 문제나 그 외 우리가 쉽게 알 수 있을 수 없는 문제가 많이 발생합니다. 왜냐하면, 아무도 하나의 머신 위에 Windows 7의 모든 소스 코드 변경이 해결되지 않기 때문입니다.
이 현상을 그림으로 이해하기 위해 그룹 사이즈의 범위내(파란 선)에서 각각의 프로그래머가 100회에 1회의 오류 비율로 얼마나 빌드 중단이 일어나는지를 예측하는 간단한 공식을 이용한 그래프를 준비했습니다. 1%의 오류 비율로 매우 좋은 상황입니다. 동시에 개인의 오류 비율을 반으로 했을 경우(붉은 선)와 10분의 1로 했을 경우(초록의 선)의 빌드 중단 확률의 선을 두 개 동시에 보여줍니다. 알 수 있듯이 각 엔지니어의 일일 품질을 향상하는 메커니즘을 도입하는 일에 의해서 일일 빌드의 전체의 품질을 향상하는데 크게 공헌했습니다.
Windows 개발 팀과 같은 규모가 되면, 매일의 빌드 품질을 향상시키는 것은 아주 어려운 문제입니다.
Windows 7의 개선점은 Windows의 모든 feature 팀을 횡단하여 구축한 공통 자동화 테스트의 인프라에 주력하고 있습니다. 이것은 Vista 공학시스템의 크게 개선되었습니다. (많은 사람이 모를 수도 있지만, 엔지니어링 프로세스와 팀 조직의 사이에는 피할 수 없는 관련성이 있습니다. ) 이 인프라를 사용하여, 우리는 모든 feature 팀이 실시한 코드의 변경을 실제로 매일의 빌드에 병합 하기 전에 확인할 수가 있습니다. feature 팀 내부에서는 이 인프라를 일일 프로그래머가 실시하는 코드 변경 확인에 사용할 수가 있습니다.
Windows 7에서는 매일 높은 수준의 빌드를 만들기에 성공했습니다. 물론, 가끔 개발자 전원의 작업을 통합하는 과정에서 빌드 중단은 일어납니다 그러나 자동화 테스트가 그것들을 사전에 검색하여 수정하는 일에 의해 거의 매일 높은 품질의 빌드 생성에 성공하고 있습니다. 저는 이 프로젝트의 시작과 동시에 Windows 7을 거의 문제 없이 사용하고 있습니다. (여러분도 저와 같이 Windows 7을 사용하고 싶다고 생각하지만, 조금만 더 기다려 주세요!)
참고용으로, 매일 24시간 서버와 클라이언트를 빌드하여 유효성 검사를 하고 있는 우리의 빌드 실습의 사진을 몇 가지 소개합니다.
마무리
이번 포스트는 제가 매일 상당한 시간을 할애하고 있는 내용을 소개했습니다. 재미있으셨는지요? 저희가 얼마나 Windows의 개발 방법의 향상을 전체적인 대처로서 생각해 왔는지 이해하실 수 있으면 좋겠습니다. 우리의 생각이 정말로 올바른지 어떤지, 우리 제품의 품질이 증명해 줄 것이라 생각합니다. 이 소프트웨어 엔지니어링의 중요한 문제에 대해서, 여러분의 생각을 들려주세요!