마이크로소프트의 오픈소스 개발에 워크스루를 활용하는 방법

마이크로소프트가 오픈 개발 모델로 전환한 것은 대규모 오픈소스 개발 관리는 어떻게 하는지 연구할 수 있는 흥미로운 사례다. 수백만 명의 사용자와 수천 명의 잠재적인 기여자를 감당해야 하는 마이크로소프트의 프로젝트 유지 관리자는 대부분의 오픈소스 프로젝트에는 아직 없는 문제에 직면해 있다.

마이크로소프트급 규모에서 프로젝트 유지 관리자는 개발 책임자보다 제품 관리자 또는 프로젝트 관리자에 더 가깝다. 내부 및 외부 기여자와 함께 작업하는 동시에 직접 프로젝트 백로그 항목을 처리하고 버그와 문제도 해결한다. 기능 요청 관리도 하는데, 해당 프로젝트에 익숙하지 않고 기업 애플리케이션 배포의 제약을 잘 모르는 자발적 기여자와 작업할 때가 많다.
 

 

깃허브(GitHub)에서의 대규모 협업

깃허브에서 코드베이스를 확인할 수 있지만, 소스 코드를 이용할 수 있다고 해서 협업을 대신할 수는 없다. 새로운 기여자가 코드의 특정 부분을 변경해야 할 때 그 코드의 위치로 어떻게 찾아갈까? 복제한 저장소를 검색하거나 디버거를 실행하면서 중단점을 추가하는 방법이 있지만 지루하게 시행 착오를 거쳐야 한다. 자발적 기여자의 시간은 낭비해서는 곤란한 귀중한 자원인데 잃어버리기도 너무 쉽다. 작업하기 더 편리한 프로젝트에 관심을 빼앗기기 때문이다.

이런 상황을 타개하고자 윈도우 오픈소스 팀은 많이 사용되는 코드베이스에 속하는 윈도우 터미널(Windows Terminal)에서 새로운 프로세스를 실험하기 시작했다. 이제 프로젝트 유지 관리자는 작업이 필요하다면 무엇이 필요하고 새로운 코드와 변경된 코드는 어디에 넣어야 하는지에 대한 간단한 안내서를 작성하고 있다. 워크스루라는 이 문서는 코드와 커뮤니티에 정통하다는 점을 적극 활용하여 기여자의 도움이 필요한 코드베이스의 ‘문제 공간’으로 신입 기여자를 안내한다.

워크스루는 사용자 이야기와 프로젝트 설명서의 중간 위치에 있다. 기여자가 프로젝트에 가치 있는 기여를 할 수 있는 시작점을 ‘최대한 간단하게’ 알려 주는 역할을 한다. 어차피 대부분의 오픈소스 기여자는 이미 개발 경험이 풍부하고 그 경험을 더 많은 동료 개발자에게 기부하기 위해 각자의 일정에 따라 자기 시간을 내서 일하고 있는 사람들이다.
 

워크스루란 무엇인가?

워크스루는 기여자가 작업을 처음 시작할 때 필요한 맥락을 파악할 수 있도록 문제와 코드를 고차원적으로 설명한 것이다. 해당 코드의 ‘정신적인 길잡이’로서 파일, 메소드, 정의의 위치를 알려 준다. 워크스루 내 다른 요소로는 코드 조각이나 유사 코드는 물론, 동일한 코드 부분과 연동하거나 비슷한 기능을 구현하는 풀 요청에 대한 링크가 있을 수 있다.

워크스루는 독립적인 문서로서 프로젝트 설명서의 일부로 포함될 수 있지만 문제 토론의 댓글처럼 간단한 형태로 대체될 수도 있다. 이는 놀라운 일이 아니다. 마이크로소프트의 오픈소스 접근 방식은 깃허브의 사회적 코딩 모델과 밀접하게 연관되어 있다. 마이크로소프트는 이와 동일한 도구를 활용하여 서식화 된 워크스루를 추가하고 있다. 개발자가 코드를 탐색하는 데 도움이 되는 핵심 요소를 강조하기 위해 기본적인 마크다운(Markdown) 기능을 사용한다. 워크스루에는 예상되는 UI 동작을 설명하기 위해 필요하면 애니메이션 GIF도 포함시킬 수 있다.

워크스루는 비교적 격식에 얽매이지 않은 프로젝트 관리 방식이지만 작성 방식에는 어느 정도 체계가 있다. 워크스루는 마치 개발 책임자와의 대화나 화이트보드 주변에 모여 진행하는 브레인스토밍 세션처럼 문제 해결의 초기 단계라고 생각하면 된다.
 

프로젝트 보드에 워크스루 지정

워크스루를 깃허브에서 사용할 때 흥미로운 부분은 프로젝트에 지정할 수 있다는 점이다. 따라서 워크스루를 프로젝트 보드에 추가할 수 있고 프로젝트 보드에서는 난이도 표시, 사용자에게 문제 지정, 결과 풀 요청에 대한 세부 정보 기재 등의 목적으로 워크스루에 메타데이터를 추가할 수 있다.

처음에는 기능 요청이나 버그 수정에 대한 맥락을 간단하게 제공하는 수단으로 시작했던 것이 이제는 기본적인 프로젝트 관리 도구가 되었다. 그러나 여전히 적절한 수준으로 격식에 얽매이지 않는 특징이 유지되고 있다. 기여자가 결과 프로젝트를 추적할 필요가 없다. 이는 오로지 프로젝트 유지 관리자를 위한 도구다. 이를 통해 프로젝트 유지 관리자는 작업이 진행 중인 워크스루와 기여자의 작업 시작에 도움이 될 정보가 더 필요한 워크스루를 확인할 수 있다.
 

스토리텔링을 통한 코드 작성

워크스루는 프로젝트 스토리텔링의 흥미로운 사례다. 마이크로소프트는 문제 및 그 가능한 해결 방법을 함께 이해하기 위해 내부적으로 이야기 기법을 사용한 역사가 길다. 이런 이야기는 애자일 개발 방법론보다 높은 수준에서 작동하며 해당 기능의 잠재적인 사용자는 물론 바람직한 최종 상태를 기술할 때가 많다.

마이크로소프트가 격식을 차린 기업 개발 체계에서 벗어난 이 접근 방식을 취한 목적은 프로젝트에서 코드를 넣을 위치를 빠르게 알려주고 잠재적인 기여자에게 동기를 부여하기 위해서다. 깃허브에서 문제의 맥락과 코드에 대한 이해 없이 문제를 살펴보는 것은 벅찰 때가 많다. 해결하기 쉬운 문제가 되기도 하는데 이는 코드 베이스에 대한 깊은 지식을 바탕으로 어떤 모듈을 사용하고 어떤 리소스를 수정할지 아는 것에 달린 경우가 많다. 

워크스루는 편리하게 격식을 차리지 않고 이해하기 쉬운 접근 방식이다. 기여자들을 멀어지게 하는 대신 기여자들이 작업을 시작하기에 필요한 만큼만의 정보를 제공하되 기여자들의 진취적인 자세와 전문 지식을 과소평가하지 않는다. 이는 프로젝트 유지 관리자들이 사용하는 모든 도구에 중요한 요건이다. 어느 프로젝트에서나 최악의 결과는 자원 봉사자를 소외시키는 것이다.

마이크로소프트 안팎에서 이 기법을 도입하여 적용하는 오픈소스 프로젝트가 늘어나기 바란다. 차세대 기여자들이 첫 풀 요청 작성이라는 어려움을 극복하는 데 도움이 될 기법이다.
editor@itworld.co.kr