Share via

Windows 7 엔지니어링에 참가한 한 개발자의 의견

  • Article

이 글을 쓴 사람은 Larry Osterman입니다. Larry는 Windows 팀에서 가장 경험이 많은 개발자 중 한 명이며 1980년대 중반부터 Microsoft에서 재직해 왔습니다. Windows 팀 전체에서도 Larry보다 오래 재직한 사람은 단 세 명 뿐입니다. 개인적으로는 제가 1989년Microsoft에서 다시 일하기 시작했을 때 Larry를 알게 되었습니다. “멀티미디어” 팀에서 일하고 있었고 제가 참가했던 첫 회사 전체 모임에서 Larry는 빌 게이츠로부터 직접 5년 재직상을 받았습니다. 당시 저에게는 정말 멋진 광경이었죠. Windows 7 프로젝트에서 Larry는 각종 장치와 Windows를 연결해주는 오디오, 비디오, 블루터스 등 온갖 멋진 기능들에 대해 일하는 “장치 및 미디어” 팀에서 개발자로 참여했습니다.

Larry는 이전의 여러 Windows 경험에 비추어 이 글을 썼으며 그의 생각은 많은 사람들과 공유할 가치가 있다고 생각합니다. 이 글은 우리가 어떻게 팀으로 일을 하는지 보여줄 것이고, 소프트웨어 팀의 일원으로 일하는 분께는 정말 흥미로운 글이 될 것입니다. Vista와 비교되기도 하겠지만 아시다시피 세상에는 일하는데 있어 완벽한 방법은 없으며 이 글은 하나의 견해를 보여 줄 것입니다.

글을 남겨주신 Larry에게 감사 드립니다. – Steven

이런 글을 쓸 기회를 주신 Steven과 Jon에게 감사 드립니다.

저는 Windows 7을 제작하는 데 있어 저의 경험을 어느 정도는 Windows Vista 제작 경험에 비교해 얘기하고 싶습니다. 이것은 저의 경험일 뿐이라는 것은 주지해 주십시오. 다른 팀원들은 또 다른 의견이 있을 것입니다. 바라건데 모두 의견 공유에 동참하면 좋겠습니다.

Windows 7 제작 경험은 Vista 때와 비교해 완전히 달라졌습니다. 대략적인 제품 개발 프로세스는 바뀌지 않았지만, 조직적으로 볼 때 Windows 7 프로세스는 대단히 향상되었습니다.

Windows Vista에서 WAVE (Windows Audio Video Excellence) 그룹의 일원이었습니다. 납품에 대해 궁극적 책임을 지는 그룹 매니저가 그룹 활동을 이끌었습니다. 그리고 그룹 매니저에게 보고하는 테스트 매니저, 개발 매니저, 프로그램 매니지먼트 매니저가 있었습니다. 하나의 기능을 제작하는 프로세스는 대략 다음과 같이 이루어졌습니다. 프로그램 매니지먼트 매니저는 Windows에 어떤 기능이 들어갈지 어떤 PM(프로그램 매니저)이 어떤 기능에 책임을 져야하는지 등에 대해 결정합니다. 개발 매니저는 어떤 개발자가 어떤 기능을 맡을지 결정합니다. PM은 개발팀과 협력해서 자신이 맡은 기능에 대해 기능 설명과 작동 원리를 담는 기능 스펙을 작성합니다. 테스터가 이 과정에서 반드시 관여하지는 않습니다. 해당 기능을 맡은 개발자는 그 기능이 어떤 식으로 실행될지 디자인 스펙을 작성합니다. 그리고 나서 그 기능을 맡고 있는 테스터는 어떤 식으로 기능 테스트를 할지 테스트 계획을 작성합니다. PM 또는 개발자 중 한 사람은 또한 기능에 대한 위협 모델을 작성했습니다.

다음으로, 개발자는 기능에 대한 코드를 작성하기 시작하고 PM은 그 기능 제작이 스케줄대로 진행되고 있는지를 점검합니다. 개발자가 코드 작성을 끝내면 테스터는 테스트 케이스를 작성하기 시작했습니다.

일단 기능에 대한 코드가 완료되어 소스 트리(source tree)에 체크인되면 “winmain” 브랜치(branch)로 옮겨졌습니다. 루트가 “winmain”이고 이곳이 궁극적으로 Windows Vista가 되는 코드 베이스입니다. 각 개발자는 “기능 브랜치”에서 작업하고 변경 사항은 “통합 브랜치”에서 합쳐지며 다시 각 통합 브랜치는 winmain으로 옮겨지는 것입니다.

코드 작성이 되고 나면, 테스터는 테스트하고 개발자는 버그(오류)를 고치고 프로그램 매니저는 프로그램 매니지먼트를 했습니다. 제품 개발이 진행되면서 버그를 고친 코드를 winmain에 체크인하는 것이 점점 더 힘들어졌습니다. 왜냐하면 모든 버그 수정 코드는 다른 버그를 유발할 수 있는 가능성을 내포하고 있으며, 따라서 각 버그 수정과 관련된 위험도를 측정해서 위험 허용을 점진적으로 감소시켜나가야 하기 때문입니다. 이 프로세스를 책임진 팀은 “ship room”에서 매일 모여 어떤 변경 사항을 제품에 적용하고 어떤 부분을 제외해야 할 지를 결정했습니다. 이는 정말로 어려운 과정이었습니다. 때로는 제품 품질과 관련된 여러 팀이 특정 버그 수정의 이점에 대해 몇 시간씩 논쟁하기도 했습니다.

전반적으로 이런 방식은 Microsoft가 지난 수 십년간 소프트웨어를 개발해 온 방식과 별 다를 바가 없습니다. 기본적으로는 제가 대학교 때 소프트웨어 엔지니어링 수업에서 배운 바와도 일치합니다.

경영팀은 Windows 7에서는 Windows 엔지니어링의 조직 구조를 변경하기로 결정했습니다. 특히 제가 일하는 WEX (Windows Experience) 부서에는 더더욱 그랬습니다. 수직적 구조 대신 Steven은 개발, 테스트, 프로그램 매니지먼트를 대표하는 세 명의 총 책임자로부터 직접 보고를 받는 구조를 택했습니다. 각 총 책임자 휘하에는 6명의 개발, 테스트, 프로그램 매니지먼트 중간 매니저들이 있으며 WEX에서도 각 담당별로 한 명의 중간 매니저들이 배치되었습니다. 중간 매니저들은 다시 각각 6명의 팀장으로부터 보고를 받으며 각 팀장은 5명에서 많게는 15명의 팀원들과 함께 일합니다. 이런 보고 체계는 다소 논란의 여지는 있지만 지금까지는 아주 성공적이었습니다.

또 다른 중요 변화는 “세 개의 엔지니어링 부문” 개념 도입입니다. “세 개의 엔지니어링 부문”은 개발, 테스트, 프로그램 관리의 각 담당 대표의 집합입니다. 모든 일을 위해 반드시 “세 개의 엔지니어링 부문”을 구성해야 합니다. 어떤 그룹이 특정 분야에 대해 집중할 필요가 있다면 “세 개의 엔지니어링 부문”이 프로세스 관리를 위해 함께 일해야 합니다. 프로세스 입력을 세 개의 엔지니어링 부문이 모두 함께 하는 것입니다. 모든 관리 수준에 있어 이 세 개의 엔지니어링 부문이 적용됩니다. WEX의 주요 그룹 총 매니저 수준에서도 세 개의 엔지니어링 부문이 있고, 중간 매니저 수준도 마찬가지로 운용됩니다. 제가 속한 Devices and Media 그룹에서도 총 책임을 지는 DKCW라고 불리우는 세 개의 엔지니어링 부문이 있습니다. 제가 일하는 음향 팀에는 매니저들로 이루어진 SNN이라는 세 개의 엔지니어링 부문이 있습니다. 또한 보안, 성능, 호환성 등을 위해서도 세 개의 엔지니어링 부문이 존재합니다.

Windows Vista와 비슷하게, 세 개의 엔지니어링 부문 책임자들이 모여 출시하게 될 기능들에 대해 결정합니다. 그리고 각 기능을 담당할 “기능 팀(feature crew)”을 만듭니다. 일반적으로 하나의 기능 팀에는 개발자가 한 두명, PM이 한 명, 테스터가 한 두명 배치됩니다.

Vista와 Windows 7 사이의 큰 차이점 중 하나는 각 기능팀이 해당 기능 전체에 대해 책임진다는 것입니다. 기능팀은 공동으로 디자인 일을 하고, PM은 기능 스펙을 작성하고, 개발자는 디자인 스펙을 작성하며 테스터는 테스트 스펙을 작성합니다. 기능 팀은 함께 위협 모델(Threat Model) 작업을 하며 다른 문서도 작성합니다. Windows Vista 개발 과정에서 경영진이 기능 팀에게 계속 지시 및 피드백을 주었던 것과는 달리 Windows 7에서는 경영진이 개발 프로세스에 관여를 많이 하지 않았습니다. 기능 팀에서 코딩 준비가 되었다고 결정하면 기능 팀은 중간 수준의 세 개의 엔지니어링 부문 팀과 만나 기능에 대해 안전 점검을 합니다. 프로세스에서 이 부분이 매우 중요한데 이는 중간 수준의 세 개의 엔지니어링 부문 팀이 기능 팀에게 계획의 실효성에 대해 자세한 피드백을 줄 수 있기 때문입니다.

그러면 기능 팀은 마침내 코딩을 시작할 준비가 된 것입니다. 어느 정도는 말입니다. 여전히 기능 팀에 “준비 완료”라고 결정되기 전에 검토해야 할 사항들이 있습니다. 예들 들어, 기능에 대한 위협 모델은 보안 세 개의 엔지니어링 부문 팀으로부터 검토받아야 합니다. 마찬가지로 다른 문서들도 각기 다른 세 개의 엔지니어링 부문 팀으로부터 검토받을 필요가 있습니다.

하나의 기능은 완성되기 전에는 winmain 브랜치로 체크인될 수 없습니다. 완성된다는 의미는 winmain 체크인 이전에 출시될 수준이어야 한다는 것이고 UI 및 기능 구현이 모두 되어있어야 합니다. 추가적으로, 기능팀은 다른 Windows 7 기능에 대한 의존도가 있을 경우 해당 두 기능팀은 서로가 상호 의존도에 대한 이해를 하고 있다는 내용의 서비스 수준 계약(SLA)에 반드시 서명해야 합니다. 이런 SLA는 매우 중요한데 이는 각 팀이 기능 의존 연관팀을 알고 해당 기능의 디자인을 바꾸거나 혹은 기능 제거 시 의존 연관팀에서 이를 알고 적절히 대응하도록 해줄 수 있기 때문입니다. 또한 이를 통해 각 컴포넌트간의 통합도 더 견고히 할 수 있는데 팀 간의 상호 이해를 통해 각 팀이 보다 밀접하게 연결되어 있기 때문입니다.

Vista 프로젝트에서는, 기능 개발이 여러 중요 시점(milestone)에 걸쳐 있는 경우가 일반적이었습니다. 그래서 완료되지 않은 코드도 트리에 체크인 된 것입니다. Windows 7에서는 구현이 완료된 기능만 체크인 가능하도록 되었으며 각 중요 시점이 제품에 있어 마지막 중요 시점이며 일정 연기는 없다는 자세로 임했습니다. 따라서 각 팀은 해당 중요 시점 내에 기능이 실질적으로 구현되도록 집중했습니다.

세부 운영을 보자면, Windows 7개발 프로세스는 3달 간격의 중요 시점이 몇 개 합쳐져 일정이 이루어집니다. 각 중요 시점은 6주간의 개발 및 6주간의 통합 기간을 갖는데 이 기간에 기능을 세부적으로 조정하고 대부분의 상호 운영성 문제를 해결합니다.

여기까지 배경 설명은 충분한 것 같습니다. Windows 7에 대한 글에서 Vista 관련 부분이 절반 이상을 차지하면 좋지 않겠지요. 서두에서 말씀드린 것처럼 이 글의 목적은 제가 Windows 7 개발자로서 경험한 바를 나누는 것입니다. Windows 7 기간 동안, 저는 3개의 기능 팀에서 일했습니다. 첫 팀에서는 두 개의 기능을, 두번째 팀에서는 8개의 작은 기능을, 세번째 팀에서는 3개의 주기능과 2개의 작은 기능을 완성했습니다. 또한 WEX Devices and Media 보안 팀(이 팀에서 제가 D&M 팀원들과 함께 위협 모델에 대한 시리즈 글을 올렸습니다)에서도 개발에 참여했습니다. 개발부의 전체 시나리오에 대한 세 개의 엔지니어링 부문 개발 일원으로 음향 팀이 Windows 7 기획 과정 초에 정의했던 시나리오들이 실재로 일관되고 검색 가능한 방식으로 완료되도록 참여하기도 했습니다.

덧붙여서, 테스트 팀이 초기 기획 단계에 참가했기 때문에 테스트 팀은 값진 피드백을 제공했고 제작된 기능들이 중요 시점까지 코드 측면에서 완성되었을 뿐만 아니라 테스트 측면에서도 완료되었음을 확인할 수 있었습니다(이는 Vista에서는 빠졌던 부분입니다). 또한 제작된 기능들이 실제로 테스트가 가능한지도 확인할 수 있었습니다. 잘 이해가 안 되시겠지만 어떤 기능을 테스트한다는 것이 얼마나 힘든 일인지 아신다면 놀라실 겁니다. 구체적인 예로, 기획 과정에서 M2에서 작업하던 기능 중의 하나가 M2 중요 시점 내에 완료될 수 없다는 것을 알았습니다. 그래서 해당 중요 시점이 완료되기 전에 그 기능을 제외했습니다. 좀 더 정확하게 말하자면, 그 기능의 새로운 코드가 제품의 일부로 들어가지 못하도록 시스템을 변경했습니다. 다음 중요 시점동안 테스트팀이 테스트 시나리오를 모두 완료한 후에 해당 기능을 다시 추가했습니다. 하지만 우리는 디자인 철학을 일관되게 지켰습니다. 중요 시점 말에 “main” 브랜치에 체크인된 코드는 모두 코드 및 테스트 측면에서 완료된 것입니다. 따라서 M3 없이 Windows 7을 출시한다고 하더라도 포함된 모든 기능에 대해 테스트는 모두 완료된 것입니다. 이는 Vista와 비교해서 정말 엄청난 변화입니다. Vista에서는 코드만 완료되면 체크인되었고 이후 문제는 테스트 팀의 몫이었습니다. 테스트 팀을 초기 기획 단계에 포함시키면서 테스트 조직이 나중에야 문제를 다룰 필요가 없게 된 것입니다. 이는 또한 개발 프로세스가 통제하기 힘든 상황으로 가는 것도 막을 수 있었습니다. 기능 개발은 몇 개의 중요 시점에 걸쳐 있습니다. 사실 음향 팀에서 작업한 기능 중 하나는 3개의 중요 시점에 걸쳐 있는데 해당 기능 팀은 Windows 7 개발이 완료되었을 때 가치 있는 기능을 포함할 수 있도록 일정을 주의 깊게 작성했습니다.

제가 지금까지 작업을 함께 했던 각 기능 팀은 집중 분야가 많이 다릅니다.핵심 오디오 인프라에 초점을 둔 기능도 있었고, 거의 UX(사용자 경험) 변경에 대한 기능도 있었으며, 좀 더 상위 수준의 컴포넌트에 관여된 기능도 있었습니다. 각 중요 시점이 독립된 것이어서 매우 다른 시스템의 기능들에 대해 일할 기회가 있었던 것입니다. 이는 이전에 경험해 보지 못한 일이었습니다.

Windows 7에서 고위 경영진은 다양한 개발 팀이 어떤 기능들이 Windows 출시 품질 기준을 충족시키지 못할 경우 제외할 지에 대한 결정을 내릴 수 있도록 아낌없는 지원을 했습니다. 기간 내에 기능이 완료되기 힘들다고 기획 단계에서 판단된 경우 제외한 주요 기능들도 물론 있었습니다. Vista에서는 고위 경영진에서 어떤 기능들을 제외해야 할지 결정하는 것은 훨씬 힘들 일이었습니다. Windows 7에서 고위 경영진은 각 기능 팀에서 이런 어려운 결정들을 내리도록 했습니다. 경영진이 꾸준히 전달한 메시지는 “제외할 것은 제외해야 출시가 가능하다” 는 것입니다. 한 기능이 전체 제품 차원에서 맞지 않다면, 전체 시스템을 출시하는데 위험을 초래하는 것보다는 그 기능을 제외하는 것이 대부분의 경우 올바른 결정일 것입니다. Windows 출시에 일반적으로 수천개의 기능이 들어가는데 한 두개의 기능이 완료되지 않아 전체 출시가 늦어진다면 실로 부끄러운 일이 아닐까 생각됩니다.

Windows 7을 제작하는 과정은 또한 훨씬 투명해졌습니다. 의사 결정에 동참하지 않더라고 어떤 결정이 어떤 방식으로 이루어졌는지 알 수 있었던 것 같습니다. 보다 투명한 프로세스를 통해 저와 같은 개별 팀원은 자신의 일정을 보다 잘 계획할 수 있습니다. 이런 투명성은 다양한 기능팀이 각각 해당 기능에 대한 결정을 내릴 수 있도록 한 경영진 결정의 직접적인 결과물입니다. 기능팀이 기획 과정에서 깊이 관여할 수 있도록 함으로써 기능 팀은 자연스럽게 보다 나은 결정을 할 수 있는 것입니다.

물론 이런 투명성은 두 가지 방식으로 작용합니다. 각 팀이 기획 과정에서 진행 중인 상황을 보다 잘 파악할 수 있을 뿐만 아니라 제품에 걸쳐 경영진이 표준화된 보고 체계를 도입했기 때문에 조직의 각기 다른 수준의 매니저들이 이전에 경험해보지 못했던 수준까지 계획 진척 사항에 대한 모니터링을 할 수 있었습니다. 개발자의 한 사람으로서 일주일에 한 번씩 자신의 각 업무별 계획 대비 진척 사항을 보고하는 정도의 일은 별로 부담이 되지 않았습니다. 이러한 상황 보고가 스프레드시트 및 웹 페이지에서 합쳐져 각 관리자는 팀 단위로 계획 대비 진척 상황을 추적할 수 있었습니다. 이렇게 해서 경영진도어떤 팀에 이슈가 있는지 쉽고 빠르게 식별해서일정이 예정대로 진행되도록 적절한 조치를 취할 수 있었습니다. 디자인을 단순화하거나 더 많은 개발자를 투입하는 등의 조치를 취해서 말입니다.

전반적으로, Windows 7을 제작하는 일은 완전한 성공이었습니다. Windows 7 운영 체계를 위해 정말 멋진 기능들을 제작해 왔고 전체 프로세스에 걸쳐서 놀랄만큼 안정적인 체계를 지금까지 만들어냈습니다.

--- Larry Osterman

Comments