PyPy의 분산 및 애자일 개발

Note

이 페이지는 현재의 오픈 소스 개발 모델이 등장하기 이전의 개발 방식을 설명합니다. (현재는 매년 열리는) 스프린트에 참여하시는 것도 언제나 환영하지만, https://github.com/pypy/pypy/ 에 있는 GitHub 저장소를 통한 참여를 권장합니다. 이슈는 issue tracker에 등록하고 논의할 수 있으며, pull requests도 환영합니다.

PyPy는 코드를 만들어 내는 일만을 다루지 않습니다. 코드를 어떻게 만들어 내는가 하는 방식도 함께 다룹니다. 커뮤니티 안에서 작업을 조율하고, 그 작업이 프로젝트 중 EU의 자금 지원을 받는 부분과 잘 융합되도록 하는 일은 참으로 까다로운 과제입니다. 물론 저희의 목표는 커뮤니티의 작업 방식이 가능한 한 방해받지 않도록 하고 PyPy에 기여하는 일이 여전히 즐겁고 흥미롭게 느껴지도록 하는 것이지만(;-), 동시에 EU는 물론 자금 지원을 받는 다른 프로젝트들에도 오픈 소스의 아이디어, 도구, 방법론이 개발 프로젝트를 운영하는 정말 좋은 방식이라는 것을 보여 주려는 것이기도 합니다. 그래서 저희는 PyPy라는 프로젝트가 운영되는 방식, 즉 분산적이고 애자일한 방식이 다른 오픈 소스 개발 프로젝트와 상업 프로젝트에도 유용할 수 있다고 생각합니다.

이를 달성하기 위한 주요 방법은 다음과 같습니다:

  • 스프린트 주도 개발
  • 동기화 회의

이를 달성하기 위한 주요 도구는 다음과 같습니다:

  • py.test - 자동화된 테스트
  • Git - 버전 관리
  • 투명한 커뮤니케이션과 문서화(메일링 리스트, IRC, 튜토리얼 등)

스프린트 주도 개발:

스프린트란 무엇이며, 우리는 왜 스프린트를 진행합니까?

원래 Python 커뮤니티에서 사용하는 스프린트 방법론은 Zope3 개발 과정의 관행에서 비롯되었습니다. 스프린트의 정의는 “개발자들이 한 방에 모여 짝을 이루어 특정 서브시스템을 구축하는 데 집중하는 이틀 또는 사흘간의 집중 개발 세션”입니다.

그 밖의 일반적인 스프린트 요소는 다음과 같습니다:

  • 10명 이하입니다(다만 PyPy를 비롯한 여러 프로젝트에서 그보다 많은 인원이 참여한 사례도 있었습니다. 이는 권장 사항이며, 꼭 필요한 최소한의 조율 시간 외에 추가 시간을 들이지 않고도 서로 교류하고 소통하며 작업할 수 있는 임계 규모의 인원을 확보한다는 생각에 근거한 것으로 보입니다. 2005년과 2006년의 스프린트에는 스프린트마다 약 13~14명이 참여했으며, PyPy 스프린트 중 참가자가 가장 많았을 때는 개발자 24명이 참여했습니다)
  • 코치(코치는 스프린트의 “관리자”로서 목표를 설정하고, 준비하고, 작업을 이끌고 조율하며, 진행 상황을 추적하고 이를 팀이 볼 수 있도록 합니다. 여기서 짚고 넘어가야 할 중요한 점이 있습니다. PyPy의 스프린트에는 코치가 있었던 적이 한 번도 없습니다. 그 대신 전체 그룹이 함께 짧은 현황 회의를 열며, 결정도 같은 방식으로 내립니다. 지금까지 이 방식은 잘 작동해 왔으며, 릴리스 등 압박이 큰 상황에서도 엄청난 성과를 거둘 수 있었습니다. 대신 현지 주최자가 있는데, 대개 그 지역에 사는 개발자이며, 여기에 스프린트를 준비하고 조직하는 개발자가 한 명 더 있습니다. 이들은 스프린트가 시작된 뒤에는 스프린트를 “관리”하지 않으며, 이들의 역할은 오히려 실무 지원에 가깝습니다. 그렇다고 해서 앞으로 코치 기법이나 그와 비슷한 방식을 활용할 일이 없다는 뜻은 아닙니다).
  • 코딩만 합니다(이 부분은 까다로운 문제입니다. 스프린트 방식을 그저 비전을 구상하고 의견을 모으는 데에만 활용한 프로젝트들도 있었습니다. PyPy도 이와 비슷하게 브레인스토밍 형식의 시작 스프린트를 연 적이 있습니다. 그렇지만 지금까지는 이것이 공식 방침입니다. 다만 다시 말씀드리자면, PyPy 스프린트에 와 보시면 저희가 소그룹별로 스프린트 계획, 문서화, EU 산출물 및 평가 조율 등 다른 소소한 활동도 꽤 많이 하고 있다는 것을 아실 수 있습니다. 하지만 걱정하지 마십시오. 저희의 주된 초점은 프로그래밍입니다 ;-)
  • XP 기법(주로 페어 프로그래밍과 단위 테스트이며, PyPy는 이러한 측면에 크게 의존하고 있습니다)을 사용합니다. 핵심 개발자와 코드베이스에 대한 지식 수준이 다양한 사람들을 짝지어 작업한 결과, 사람들이 상당히 빠르게 시작하여 개발에 참여할 수 있었습니다. (프로젝트와 코드베이스를 처음 접한) 많은 참가자들이 페어 프로그래밍과 자동화된 테스트 작업을 병행하는 것이 시작하기에 매우 좋은 방법이었다고 밝혔습니다. 물론 이것은 딜레마이기도 합니다. 핵심 개발자들이 특히 까다로운 문제를 해결하기 위해 서로 짝을 지어야 할 수도 있는데, 이는 다른 짝들의 구성과 성과에 영향을 미치기 때문입니다.

이 방법은 팀이 명확하고 (도전적인) 목표에 집중하게 하면서 협업적으로(페어 프로그래밍, 상황 점검 회의, 토론 등), 그리고 속도감 있게(계획 수립과 요구사항 수집에 오랜 준비 기간을 들이는 대신 짧은 증분과 작업 단위, “직접 해 보기”와 테스트) 일하게 하므로 분산된 팀에 잘 맞습니다. 즉, 대부분의 경우 스프린트는 성과를 얻는 훌륭한 방법일 뿐만 아니라 새로운 사람들이 코드베이스에 익숙해지게 하는 훌륭한 방법이기도 합니다. 또한 페어 프로그래밍 덕분에 팀 내에서 지식을 전파하고 학습하기에도 훌륭한 방법입니다.

스프린트를 실제로 여러 장소를 옮겨 다니며 진행하여, 커뮤니티 내 여러 활발한 개발자 그룹 가까이에서, 그리고 PyCon이나 EuroPython 같은 콘퍼런스 기간에 개최한다면, 팀은 새로운 인재를 더 쉽게 영입할 수 있을 것입니다. 또한 이는 커뮤니티에 활력을 불어넣고 서로 다른 Python 구현 프로젝트 간의 교류를 늘립니다.

방법론은 언제나 그렇듯 프로젝트에 맞게 조정해서 사용해야 합니다(그 반대로 프로젝트를 방법론에 맞추는 경우가 너무나 흔합니다). PyPy 팀은 2003년 초부터 스프린트를 진행해 왔으며, 지금까지 유럽에서 19회, 미국에서 2회, 아시아에서 1회, 총 22회의 스프린트를 진행했습니다. 이 팀에서는 특정 관행들이 더 성공적인 것으로 입증되었으며, 여기서 정리하는 것이 바로 그러한 관행들입니다.

어떻게 이루어집니까?

스프린트에는 여러 가지 측면이 있습니다. PyPy 팀에서는 다음 사항에 중점을 둡니다: 1. 내용(목표) 2. 장소 3. 정보 4. 진행 방식

  1. 내용(목표)은 행사 약 한 달 전에 메일링 리스트(pypy-dev)와 IRC에서 논의합니다. 그에 앞서 “스프린트 사이(between sprints)”라고 부르는 대략적인 계획을 세우며, 스프린트 계획은 이 사안들의 진행 상황을 바탕으로 하되 다가오는 릴리스와 산출물에도 중점을 둡니다. 보통은 핵심 개발자들이 이 일을 맡지만, IRC에서 매주 “pypy-sync 회의”를 열기 시작한 이후로 투명성과 참여도가 높아졌습니다. 동기화 회의와 스프린트 사이의 대략적인 계획을 함께 운영하면 다른 개발자들도 진행 상황을 따라가기 쉬워지고, 그만큼 다가오는 스프린트의 목표 설정에도 참여하기가 쉬워집니다.

    목표는 도전적이어야 합니다. 그렇지 않으면 팀이 온 힘을 쏟도록 이끌어낼 수 없습니다. 하지만 비현실적이어서도 안 됩니다. 비현실적인 목표는 큰 좌절감과 불만을 낳기 쉽기 때문입니다. 스프린트 목표를 정할 때는 참가자를 고려하는 것도 매우 중요합니다. 스프린트가 콘퍼런스(또는 이와 비슷한 공개 행사)와 연계되어 열린다면 실제 코딩 진척에 대한 목표는 더 낮게 잡거나 다른 방식으로 다루어야 합니다. 그 대신 지식 전파에, 그리고 새로 온 사람이나 관심 있는 사람이 PyPy 코드베이스를 어느 정도 이해하도록 돕는 데 초점을 두어야 합니다. 올바른 목표를 정하고 그 목표를 모두가 공유하도록 하는 것은 중요합니다. 그래야 참가자들이 어느 정도 비슷한 기대를 품고 참여할 수 있기 때문입니다 ;-)

  2. 장소 - PyPy 프로젝트에서는 몇 달 앞서 어디에서 스프린트를 진행할지 대략적으로 구상해 둡니다. 그렇게 먼 시점까지 세부 계획을 세워 두지는 않습니다. 날짜와 장소를 알면 항공편 예약이 더 쉬워집니다 ;-) 장소는 생각보다 훨씬 더 중요합니다. 어느 정도 편안하게 작업할 수 있는 환경(최대 15명이 앉아서 작업할 수 있는 곳)이 필요하며, 이는 곧 테이블과 의자, 조명, 전기 콘센트가 있어야 한다는 뜻입니다. 출입 카드가 필요해서 한 사람만 문을 열 수 있는 장소입니까? 얼마나 오래 머무를 수 있습니까? 하루 24시간 머무를 수 있습니까, 아니면 건물주가 23시까지 팀이 나가기를 원합니까? 이는 스프린트의 원하는 결과뿐 아니라 “느낌과 분위기”에도 크게 영향을 줄 수 있는 중요한 질문입니다!

    또한 참가자들이 저렴하게 식사하고 숙박할 수 있는 곳과 어느 정도 가까워야 합니다. 차/커피를 끓일 수 있는 시설과 음식을 보관할 냉장고 같은 것도 필요합니다. 상시 인터넷 연결은 필수입니다 - 스프린트를 열기로 한 장소에 네트워크 접속과 관련된 이상한 규칙 같은 것이 있습니까?

    화이트보드는 유용한 도구이므로 갖춰 두면 좋습니다. 비머(Beamer, 프로젝터를 가리키는 PyPy 은어)는 상태 회의에 매우 유용하므로 최소 1대는 준비되어 있어야 합니다. 프로젝트에서도 스프린트 전용 비머를 1대 보유하고 있습니다.

    따라서 좋은 스프린트 장소의 요건이 충족되는지 확인하는 사람은 현지 인맥이 매우 좋아야 하며, 가급적이면 그곳에 거주하는 사람이어야 합니다.

  3. 정보 - 내용과 목표에 관한 논의(사전 공지)는 보통 pypy-dev(메일링 리스트/IRC)에서 이루어집니다. 그 밖의 모든 스프린트 정보는 pypy-sprint 메일링 리스트의 이메일과 codespeak의 웹 페이지를 통해 배포됩니다. 날짜, 장소, 내용이 모두 확정되면 스프린트 공지를 작성하여 pypy-dev와 pypy-sprint뿐 아니라 comp.lang.python 같은 좀 더 범용적인 메일링 리스트에도 보내고, codespeak에도 갱신합니다 - 이는 스프린트 2~4주 전에 이루어집니다. 스프린트 공지에는 현지 교통편(해당 국가, 도시, 행사장까지 가는 방법), 통화 문제, 음식과 식당 등에 관한 정보를 안내하는 것이 중요합니다. 또한 참가자들이 언제 도착하는지와 어디에 머무는지를 알리는 웹 페이지도 있습니다.

    스프린트 계획 문서는 스프린트 직전까지 갱신되며, 이후 현황 회의 때와 회의 사이사이에 작업을 추적하는 데 사용됩니다. 스프린트가 끝난 후(또는 더 좋게는 메모리가 생생할 때 스프린트 도중에) 개발자 중 한 명이 스프린트 보고서를 작성하여 codespeak에 올립니다. 이 보고서는 스프린트 전체를 요약한 것으로, 수행한 작업과 참여한 사람들에 대해 이야기합니다.

    장소를 계획할 때 매우 중요한 전략 중 하나는 비용 효율성입니다. 숙박비와 식비·교통비를 최대한 낮게 유지하면 더 많은 사람이 경비를 감당하면서 스프린트를 방문하거나 전체 일정에 참여할 수 있습니다. 프로젝트 중 EU의 부분적인 자금 지원을 받는 부분에는 이른바 스프린트 예산이 있으며, 우리는 이 예산으로 개발자들이 스프린트에 참여할 수 있도록 지원하려 합니다(여행 경비와 숙박비). 또한 자금 대부분이 이른바 매칭 펀드(matched funding)이므로, 어차피 우리는 경비 대부분을 각자의 소속 단체와 회사에서 부담합니다.

  4. 진행 방식 - 일반적인 PyPy 스프린트는 7일 동안 진행되며, 중간에 하루 쉬는 날이 있습니다. 스프린트 참가자들은 보통 스프린트 시작 전날 도착합니다. 첫날에는 시작 회의를 하며, 프로젝트에 처음 참여하는 사람이 있거나 새로운 도구나 기능이 구현된 경우에는 튜토리얼도 진행합니다. 참가자들이 짧게 자기소개를 하며 자신의 배경과 기대하는 바를 이야기하는 것도 좋습니다. 안타깝게도 첫날에는 사람들이 도착한 뒤 인터넷과 서버 인프라를 갖추어 가동하는 데 늘 시간이 들며, 주로 오전 시간이 이렇게 소요됩니다. 그래서 저희는 문서를 통해 참가자들이 스프린트에 도착하기 전에 필요한 도구와 설정을 미리 준비하도록 노력하고 있습니다.

    대략적인 진행 시간은 10시부터 17시까지이지만, 사람들은 저녁에도 남아서 코딩을 더 하는 경향이 있습니다. 하루는 짧은 현황 회의로 시작하며, 작업은 필요와 희망에 따라 “짝을 지어” 분배됩니다. PyPy 스프린트는 개발자와 그룹이 주도하며, 별도의 “코치”가 없기 때문에 현황 회의는 대부분 그룹 토론 형식으로 진행되고, 그동안 회의 내용을 기록하고 계획 문서를 갱신합니다. 또한 스프린트는 개발자 그룹이 현지 사정에 밝은 사람(주로 그 지역에 사는 개발자)과 함께 계획하고 실행합니다. 따라서 팀 내에 스프린트를 공식적으로 책임지는 사람은 없습니다.

    휴식일의 업무 외 활동과 친목 행사를 제안하는 것은 휴식을 취하는 것이 얼마나 중요한지 강조하는 좋은 방법입니다. 현지 주최자가 그런 방향으로 몇 가지 조언을 해 주면 좋습니다.

    스프린트가 끝나면 기술적인 요약(목표와 내용을 달성했는지)을 하고, 다음 스프린트까지 작업의 대략적인 초점을 무엇으로 삼을지 정하며, 그러면 스프린트의 수레바퀴가 다시 굴러가기 시작합니다 ;-) 참가자들과 함께 스프린트를 평가하는 것 또한 중요한 부분입니다. 대개는 스프린트가 끝난 뒤 이메일로 질문을 보내는 방식으로 진행하지만, 짧은 그룹 평가로 진행할 수도 있습니다. 평가를 하는 이유는 물론 피드백을 받고, 스프린트를 더욱 효율적이고 즐겁게 만들 기회를 놓치지 않기 위해서입니다.

    저희 스프린트 진행 방식의 가장 큰 과제는 참가자들이 서로 다른 날짜에 도착하고 서로 다른 날짜에 떠난다는 점입니다. 이는 공동 도입부(목표/내용, 튜토리얼, 발표 등)는 물론 기술 요약 같은 마무리 과정에도 영향을 줍니다. 저희는 이 부분에서 아직 적절한 절충점을 찾으려고 애쓰고 있으며, 그렇기 때문에 피드백이 더욱 중요해집니다.

저도 참여할 수 있습니까?

물론입니다. pypy-dev에서 진행되는 작업을 지켜보시면 됩니다. 특히 저희 스프린트에 관한 정보에 관심이 있으시다면 pypy-sprint@codespeak.net을 구독하시고, 공지 등은 codespeak의 뉴스를 확인하십시오.

저희가 여러분이 사는 도시에서 스프린트를 해야 한다고 생각하신다면 이메일을 보내 주십시오. 저희는 스프린트를 활발히 활동하는 개발자(Python, 컴파일러 설계 등)와 교류하는 방법으로 활용하는 데 큰 관심이 있습니다!