Windows 8 개발 프로젝트의 뒷 이야기

우리는 Consumer Preview 릴리스에 대한 자세한 정보, 일부 달라진 변화, 아직 블로그에 소개되지 않은 기능을 설명해 오면서 잠시 숨을 고르고 우리 팀을 간단히 소개하고 싶었습니다. Windows 8 개발 작업은 매우 중요한 프로젝트이며 다양한 배경과 경험을 가진 팀이 참여하고 있습니다. 이러한 팀의 다양성은 Windows를 사용하는 전 세계 고객의 다양성을 반영하고 있는 것이어서 자랑스럽게 생각합니다. 팀 구성원 중 한 명인 Larry Osterman은 예전에 Windows 7 개발 작업을 이전 버전과 비교한 블로그 글을 썼습니다. 그가 이번에도 두 명의 팀 구성원을 인터뷰하는 형식으로 Windows 8 프로젝트의 뒷 이야기를 소개합니다.
- Steven

3년 전, 저는 Windows 7 개발 프로세스에 대한 글을 Engineering Windows 7 블로그에 올렸습니다. 이 글에 이어 이번에는 Windows Runtime Experience 팀에 뒤늦게 합류한 두 사람을 인터뷰하여 그들의 이야기를 들어보는 시간을 갖고자 합니다. 두 명 모두 Windows 8 프로젝트가 시작되기 얼마 전에 Windows 개발 업무를 시작했기 때문에 Windows 개발의 전 과정을 경험한 것은 Windows 8이 처음입니다.

간단히 자신을 소개해 보세요. 어느 팀에서 왔으며 Microsoft에서 근무한 지는 얼마나 되셨나요?

Chris: 안녕하세요, 저는 Chris Edmonds입니다. 오리건에서 태어나 자랐으며 오리건 주립 대학을 다녔습니다. NASA와 Garmin에서 인턴 과정을 거치면서 로봇 공학부터 항공 전자 공학에 이르는 다양한 분야의 프로젝트를 경험하고 매니코어 프로세서의 고속 라우팅에 대해 연구했습니다. Microsoft에는 오리건 주립 대학을 다닐 때 채용되었는데, 지금으로부터 약 2년 6개월 전에 Windows 팀에 합류했습니다.

Mohammad: 안녕하세요,저는 Mohammad Almalkawi입니다. Microsoft Windows 부서의 소프트웨어 디자인 엔지니어이며 저 역시 Microsoft에서 근무한지 약 2년 6개월이 되었습니다. 저는 어바나-샘페인에 있는 일리노이 대학을 졸업했으며, 내결함성(fault-tolerance) 및 실시간 시스템 통합에 대한 연구를 수행했습니다.

Windows 8 개발 프로젝트에서 맡고 있는 업무는 무엇인가요?

Chris: 저는 Windows 7이 상용화되기 몇 달 전에 Windows 팀에서 일을 시작했습니다. 그러다가 얼마 지나지 않아 새로 구성된 Windows Runtime Experience 팀에 합류하게 되었습니다. Runtime Experience 팀은 여러 가지 Windows 런타임(WinRT) 인프라를 구축하는 업무를 진행하고 있는데 Windows 8을 개발하는 동안 저는 WinRT의 다양한 분야를 경험할 수 있었습니다.

세 번의 마일스톤 중 첫 번째 마일스톤에서 저는 WinRT 시스템의 핵심 패턴을 정의하는 업무를 맡았습니다. 우리는 프로젝트를 세 개의 마일스톤으로 나누고 스케치 단계에서 완제품까지 아키텍처와 구현을 이러한 마일스톤으로 구분했습니다. Windows 8의 여러 기술을 조정하기 위해서는 필요한 모든 작업을 포함해야 하는데, 첫 번째 마일스톤(M1)에서는 이벤트, 개체 구성, 비동기 메서드 및 메서드 오버로드에 대한 패턴을 설계했습니다. WinRT와 상호 운용되는 각 프로그래밍 언어에서 개발자를 위해 이러한 기본 개념을 자연스럽고 친숙한 방법으로 노출할 수 있도록 강력한 패턴을 정의하는 것이 중요했습니다.

두 번째 마일스톤에서는 Metro 스타일 응용 프로그램을 배포하는 데 참여할 수 있는 기회가 있었습니다. 특히 저는 WinRT를 이용한 Metro 스타일 응용 프로그램을 등록하여 그 프로그램이 출시되고 계약을 진행할 수 있도록 하는 업무를 맡았습니다.

세 번째 마일스톤에서는 많은 그룹 간 공동 작업이 필요했는데, 이때 배운 것이 Windows 8과 같이 폭넓고 깊이 있는 프로젝트를 진행하는 데 많은 도움이 되는 것 같습니다. 저는 팀의 일원으로 Metro 스타일 응용 프로그램에 대한 응용 프로그램 모델의 핵심 부분을 정의하고 구현했습니다. 이는 여러 UI 플랫폼에서 여러 언어로 작성된 Metro 스타일 앱이 계약 및 응용 프로그램 수명과 관련하여 일관적인 방식으로 작동하도록 하기 위한 작업이었습니다.

Mohammad: 저는 Windows 8 개발 프로젝트에 거의 처음부터 참여할 기회가 있었습니다. 우리는 Windows 8의 목표를 실현하기 위해 기능적으로 중요한 세 개의 마일스톤(M1, M2 및 M3)을 지정했습니다. 각 마일스톤은 다음과 같이 구성됩니다.

• 기능 팀 회의 및 Windows 파트너 팀과 사내 관련 팀의 적극적인 참여를 통해 요구 사항을 세밀히 분석하는 사양 및 디자인 단계 - 기능 팀은 특정 기능을 담당하는 개발자, 테스터 및 프로그램 관리자로 구성되며, 인원은 일반적으로 4~5명입니다. 이 단계에서는 기능(프로그램 관리자), 개발 디자인(개발자), 테스트 디자인 및 위협 모델(테스터) 등의 사양 문서와 실행 계획(팀 전원)이 결과물로 도출됩니다. 이를 통해 우리는 기능에 대한 자세한 내용을 보다 잘 이해하고 집중된 노력으로 자신감 있게 실행할 수 있습니다.
• 단위 테스트 및 기능 테스트와 함께 사양 단계에서 확인된 기능을 구현하는 코딩 단계
• 여러 팀이 협력하여 만든 다양한 결과를 통합하고 버그를 수정하는 통합 및 안정화 단계

첫 번째 마일스톤에서 저는 응용 프로그램 확장의 검색 및 활성화 디자인/개발을 맡았습니다. 이 WinRT 인프라는 응용 프로그램이 OS 지원 계약(예: 검색 및 공유)에 참여할 수 있도록 하며, 검색 및 공유 참(Charm)과 같은 Windows의 놀라운 기능의 기반이 됩니다.

두 번째 마일스톤에서 저는 WinRT 도구 체인에 의해 생성된 Windows 메타데이터와 JavaScript 및 C# 언어에서 예측된 사항을 연결하는 핵심 API인 Windows 메타데이터 확인 기능을 구현했습니다.

끝으로, 세 번째 마일스톤에서는 Chakra JavaScript 엔진에서 WinRT 네임스페이스 및 유형에 대해 반사 기능을 지원하도록 하는 네임스페이스 열거 API의 디자인 및 개발을 담당했습니다. CLR과 Visual Studio에서도 이 API를 사용하여 각각 메타데이터 확인을 구현하고 WinRT 유형에 대한 Intellisense를 지원합니다.

하루 일과는 어떤 모습인가요? Chris: 평소의 모습 말씀이신가요? 제가 Windows 업무를 수행하면서 정말 좋은 점 중 하나는 평범한 날이 거의 없다는 것입니다. 제품 주기에 따라 사양을 작성하거나, 코드를 작성하거나, 팀원들과 아이디어를 구상하거나, 버그를 수정하거나 그 밖의 다양한 작업을 진행하면서 하루를 보냅니다. 맡은 작업은 다양하지만 일상이 거의 늘 문제를 해결하는 것과 관련이 있습니다. 크래시 원인을 찾든, 기능 디자인을 도와주든 매일 똑똑한 사람들과 함께 흥미로운 문제를 해결합니다.

가장 놀라웠던 점은 무엇인가요?

Chris: Windows 업무를 수행하면서 가장 놀라웠던 점은 팀의 규모와 어느 시점에서든 예정되어 있는 작업의 수였습니다. 저에게 맡겨진 몇 안 되는 기능에 대한 작업을 진행하면서 사양 및 솔루션을 만들기 위해 여러 팀에 속한 수백 명의 사람들을 만나볼 수 있는 기회를 가졌습니다. 처음에는 정말 흥분되었고 다소 움츠려들기도 했지만 여러 팀이 힘을 모아 멋진 솔루션을 만들어내는 과정이 늘 놀라웠습니다. Windows 사용자 수와 Windows가 사용되는 방식의 수를 생각해 보면 우리처럼 '소수'의 사람들이 이 모든 작업을 이루어냈다는 사실이 실로 믿기지 않습니다.

Mohammad: Microsoft에서 제가 가장 놀랐던 점은 실제 문제를 던져 주고 거의 처음부터 중요한 사항을 터득할 기회를 제공한다는 점입니다. 교육이 아니라 실무를 통해 배우기 때문에 필요할 때 즉시 활용할 수도 있다는 점이 좋은 것 같습니다.

물론 오로지 혼자서 습득하는 것은 아닙니다. 필요할 때 도움을 주는 많은 지원 채널, 도메인 전문가, 선임 엔지니어들이 있습니다.

Windows 8은 지금까지 경험해 본 다른 프로젝트와 어떻게 다른가요?

Chris: 오리건 주립 대학과 이전 인턴 과정(대부분의 코드 프로젝트가 Windows에 비해 소규모임)에서는 주로 소규모 프로젝트를 수행했기 때문에 가장 큰 차이점은 매일 읽어야 하는 코드의 양입니다. Microsoft에 입사하기 전에는 이전 마일스톤에서 직접 작성한 코드를 검토하는 동시에 다른 팀이 작성한 코드를 읽고 디버깅하는 데 많은 시간을 보냈습니다. 그 덕분에 제대로 작성된 코드의 중요성을 알게 되었습니다.

해결해야 했던 가장 큰 과제는 무엇이었나요?

Mohammad: 팀에 참가하는 즉시 COM 활성화의 잘 모르는 코드를 수정해야 했습니다. 이 코드는 Windows의 많은 구성 요소가 기반으로 하는 매우 기초적인 코드이므로 코드를 잘못 변경하여 역효과가 발생하는 일이 없도록 해야 했습니다.

제가 속한 팀의 전문가들에게는 이 코드가 간단해 보일 수 있지만 저 같은 신참에게는 결코 그렇지 않았습니다. 저는 이해도를 높이는 동시에 다른 코드를 건드리지 않고 필요한 사항을 변경한다는 확신을 가지기 위해 코드를 많이 읽고 디버거 과정을 거치고 많은 테스트 사례를 작성해야 했습니다.

Windows 8의 계획을 무엇에 비유할 수 있는지 말해 주시겠어요?

Chris: Windows 8 계획은 팀원마다 다른 의미로 다가오는 것 같습니다. 계획의 일환으로 새로 구성된 Runtime Experience 팀은 다양한 언어, 스택, 프레임워크 및 기술을 사용하여 앱을 구축하기 위해 일주일을 보냈습니다. 이는 Windows 8의 디자인 핵심 기조가 여러 언어로 프로그래밍할 수 있다는 점 때문입니다. 이러한 목표를 이루기 위해 우리 각자는 기존에 익숙하지 않은 언어를 사용해야 했으므로 하나씩 체계적으로 습득해 나갈 수밖에 없습니다. 저는 3D 지형 생성 프로그램에서는 IronPython과 XNA를 사용하고, 사진 갤러리 앱에서는 HTML\JavaScript를 사용하고, C++로 작성된 간단한 2D 물리 엔진에서는 그리기용 GDI를 사용했습니다. 앱 구축 연습부터 우리는 각 앱의 구축 경험에 대한 프레젠테이션을 작성하여 각 경험의 수준을 좋음, 나쁨, 매우 나쁨으로 구분하여 팀 간에 공유했습니다.

어떤 점이 인상적이었나요?

Mohammad: 저는 야간 구축 및 품질 관문을 통해 수천 명의 Windows 소프트웨어 엔지니어를 지원하고 운영 체제의 수백 만 코드 줄을 정상적으로 유지하는 Windows 엔지니어링 시스템의 품질이 매우 인상적이었습니다. 자동화된 품질 관문에는 중요한 포괄적 테스트, 성능 테스트, 응용 프로그램 호환성 테스트, 정적 코드 분석 및 그 밖에 신속하게 문제를 해결하고 순방향 및 역방향 통합을 통해 분기 전파를 철저하게 제어하는 데 사용한 몇 가지 다른 테스트가 포함됩니다.

마일스톤 기대 품질(MQ)이란 무엇인가요?

Chris: 이 마일스톤에서는 코드베이스, 엔지니어링 도구 및 엔지니어링 프로세스를 다음 제품 주기에 맞게 준비합니다. 제가 배운 바에 의하면 MQ는 코드를 검토하면서 간단한 소스 파일 정리부터 Windows 8에서 수행할 작업을 위해 추출 작업을 다시 하는 것까지의 몇 가지 관리 작업을 수행하는 과정을 의미합니다. 코드는 우리의 자산이므로 이러한 자산을 유지 관리하는 데 집중하는 것은 매우 중요한 일입니다. Windows 8의 MQ 중에 저는 세 가지 작업에 참여했습니다. 첫째는 일상적인 테스트 통과를 기반으로 팀의 내부 대시보드를 통해 코드 검사 번호를 자동으로 다시 보고하는 시스템을 만드는 것이었습니다. 이는 제가 Microsoft에서 수행한 첫 번째 작업이었으며 Microsoft의 엔지니어링 시스템에 대해 배울 수 있는 좋은 기회가 되었습니다. 제가 참여한 두 번째 작업은 코드베이스에서 자산을 사용하는 방법을 표준화하는 데 유용한 코드 위생 처리 실무였습니다. 끝으로, 저는 IntelliSense 인프라의 일부를 사용하여 SDK의 모든 부분에 대한 카탈로그를 자동으로 작성하는 프로토타입 시스템 관련 작업을 수행했습니다.

지금은 어떤 부분에 중점을 두고 있나요?

Mohammad: 오직 성능뿐입니다!

제가 맡은 기능은 소프트웨어 스택의 맨 아래에 가까우며 매우 자주 사용되므로 성능이 매우 중요합니다. 따라서 저는 지금 성능을 분석하고 여러 가지 향상된 성능의 프로토타입을 만든 후 이를 통합하는 데 주력하고 있습니다. 우리는 처음부터 뛰어난 성능을 구축했기 때문에 지금은 인프라에 작성된 수많은 코드를 검토하며 이러한 성능을 세밀하게 다듬고 있습니다.

작업의 유효성을 전체적으로 어떻게 검사하나요?

Chris: 응용 프로그램 개발자 경험 개선을 전담하는 팀의 일원으로 우리는 정기적으로 운영 체제 개발자의 모습에서 탈피했다가 다시 본연의 모습으로 돌아오는 것이 중요합니다. 이는 일상적인 업무에서 간단히 수행할 수 있지만 가장 체계화된 형태 중 하나는 응용 프로그램 구축 주간입니다. 계획 과정에서 가진 초기 응용 프로그램 구축 주간을 기반으로 우리는 언어와 API가 서로 다른 여러 팀이 각 마일스톤에서 WinRT를 사용하여 응용 프로그램을 개발하는 시간을 가졌습니다. 여전히 개발 중인 플랫폼에서 앱을 작성하면 몇 가지 흥미로운 해결 과제가 발생하는데, 이러한 주간은 속도의 변화를 줄 수 있는 시간이 됩니다. 이러한 앱 구축 주간(일부에는 더 많은 팀이 참여함)에는 수많은 버그가 제출되므로 우리는 각 개발자의 환경을 보다 자연스럽고 친숙하게 만들기 위해 API 지침의 일부를 다시 생각하고 변경해야 했습니다. "버그"는 치명적인 크래시, 메모리 누설 또는 보안 취약점 등이 될 수 있으며 "올바른 것 같지 않은 것"을 모두 보고하면 됩니다. 우리는 모든 사항을 버그로 간주하여 이러한 보고서를 분류하고 우선 순위를 지정하는 프로세스를 수행했습니다. 보고서는 우리의 API를 기반으로 하는 Windows의 여러 그룹, Microsoft의 다른 그룹, 장치 및 PC 제조업체와 같은 초기 파트너, //build/ 컨퍼런스에서 만난 인턴 사원, 이제 개발자 프리뷰에서 앱을 구축하는 포럼 참가자 등 다양한 사람/그룹에서 제공됩니다.

지금까지 얻은 것 중에서 가장 중요한 교훈은 무엇인가요?

Mohammad: 저는 제품의 규모와 범위가 정해지고 사용자 수가 많은 경우 "잘못될 가능성이 있는 것은 잘못된다"라는 개념을 경험했습니다(그런데 우리는 주 개발 컴퓨터에서 거의 처음부터 우리의 작업에 대한 Dogfood를 내부적으로 수행합니다). 이는 저에게 세부 사항에 주의하고 모든 코드 줄의 품질에 집중하는 것이 프로젝트의 전반적인 안정성에 매우 중요하다는 점을 가르쳐 주었습니다. 물론 이것은 지금까지 제가 얻은 많은 중요한 교훈 중 하나에 불과합니다. 저는 여전히 저의 첫 번째 Windows 버전을 작업하고 있으며 이후 단계에서도 계속해 더 많은 것을 배워 나갈 것입니다.

다음 프로젝트가 무척 기다려집니다.

Chris: 저도 마찬가지입니다.