[번역] 프리 소프트웨어 프로젝트에서의 품질 관리 관행과 문제점

* 이 보고서는 저자의 허락 하에 요약, 번역되었습니다. 2006년에

프리 소프트웨어 프로젝트에서의 품질 관리 관행과 문제점


(Quality Practices and Problems in Free Software Projects)

원저자: Martin Michlmayr, Francis Hunt, David Probert,
        Centre for Technology Management, University of Cambridge
        martin@michlmayr.org

번역: 이 민석 (한성대학교 컴퓨터공학과 교수, minsuk@hansung.ac.kr)

요약 - 프리 소프트웨어와 공개 소스 프로젝트의 결과물은 품질이 좋은 것으로 인식되고 있다. 일부 프리 소프트웨어에서 관찰되는 높은 수준의 품질은 다른 개발자에 의한 소스 검토를 권장하는 공개적인 개발 모델과 관계가 있다고 여겨진다. 일부 프리 소프트웨어의 품질이 비공개 상용 소프트웨어의 품질에 필적(더 좋지는 않아도)할만하다 할지라도 모든 프리 소프트웨어 프로젝트가 성공적이며 품질이 높다고 볼 수는 없다. 완성도가 높고 성공적인 프로젝트들조차 품질 문제에 직면한다. 이들 문제점 중 일부는 대부분이 자원 개발자에 의해 진행되는 분산 개발 모델을 따르는 프리 소프트웨어와 공개 소스 프로젝트의 고유 특성과 연관되어 있다. 이 연구에서는 프리 소프트웨어, 공개 소스 개발자와의 인터뷰를 통하여 실제적인 품질 문제와 여러 가지 품질 관리를 위한 개발 관행들이 확인되었다. 이 논문에 제시된 인터뷰 결과는 현재의 프리 소프트웨어 프로젝트의 품질 현황을 점검하고 품질 개선 절차 개발의 출발점으로 삼을 수 있을 것이다.

주요 용어 - quality practices, quality assurance, quality improvement, free software, open source.

I. 서론

최근 프리 소프트웨어와 공개 소스 개발 모델은 다른 개발 모델들을 대치할 수 있을 정도의 경쟁력을 갖추었다. Linux, Apache, Samba와 같은 많은 대중적 제품들이 공개 소스 모델을 따라 만들어졌으며, 프리 소프트웨어 응용 프로그램의 수도 꾸준히 증가하고 있다. 2001년에 행한 프리 소프트웨어 연구에서는 5천 5백만 라인 이상의 소스를 찾아냈는데 이의 가치는 COCOMO 모델[4]을 따라 평가할 때, 19억 달러에 이르는 것으로 추정되며, 그 규모는 그 이후에도 2배 이상 증가했다[5].

프리 소프트웨어 모델은 주요 소프트웨어들의 창조에 기여했으며, 많은 프리 소프트웨어 응용 프로그램은 공개 소스가 아닌 독점 소유의 소프트웨어를 능가하거나 버금가는 품질을 갖추고 있다[6][14]. Raymond는 그의 저서 “성당과 시장 (The Cathedral and the Bazaar)”에서 이러한 높은 수준의 품질이, 부분적으로는 프리 소프트웨어 프로젝트에서 흔히 이루어지는 많은 다른 개발자에 의한 소스 검토와 사용자의 참여 덕분이라고 말하고 있다[13]. 이러한 가설은 다른 개발자에 의한 소스 검토가 소프트웨어의 품질에 중대한 영향을 끼친다는 전통적인 소프트웨어 엔지니어링 기술 연구 결과와 일치하는 것이다.

Raymond의 가설은 거의 맞는 것처럼 들리긴 하지만, 여전히 실험에 근거한 자료 분석을 통하여 엄격하게 증명되고 검사되어야 한다. 보통 프리 소프트웨어의 품질에 관한 언급의  대부분은 실험적 증거보다는 단편적인 일화에 근거한 것들이 많다. 많은 프리 소프트웨어 응용 프로그램이 이룬 최근의 성공들을 고려하면, 어느 정도는 이런 소프트웨어들이 사용자들의 요구와 품질 기준을 만족시킨다고 여길 수도 있다. 그럼에도 불구하고, 프리 소프트웨어의 품질에 대한 연구와 독점 소프트웨어와의 품질 비교를 위한 실험적 연구가 필요하다고 본다. 특히 프리 소프트웨어 모델과 관련된 문제점들을 도출하는 작업은 유익한 것으로 사료되며, 이러한 연구의 결과물은 앞으로 개발 절차 개선을 위한 전략을 개발하는데 사용될 수 있을 것이다.

II. 연구 배경

보통 프리 소프트웨어 프로젝트는 품질 확보와 중요한 관계가 있는 두 가지 특징을 가지고 있다. 첫째, 많은 경우 프리 소프트웨어 프로젝트는 전 세계에 분산되어 진행된다. 둘째, 프리 소프트웨어 프로젝트의 구성원들은 보통 보수를 받지 않는 자원 개발자들이다. 프리 소프트웨어를 설치한다는 것으로 나타나는 프리 소프트웨어에 대한 관심은 일반 사용자들을 위한 성공적이고 완성도 높은 제품들이 분산 개발 방식으로 자원 개발자들 의해 만들어질 수 있다는 것을 분명하게 보여 주고 있다. 프리 소프트웨어 개발 모델은 독점 소프트웨어 개발 모델보다 나은 어떤 이점들을 제공하는데, 그 이점은 프리 소프트웨어 모델이 다른 개발자들에 의한 진지한 소스 검토를 받을 가능성이 높다는 것과 전 세계로부터 뛰어난 프로그래머들을 흡수할 수 있다는 것이다. 그러나 프리 소프트웨어도 개발 모델의 특수성으로 인한 여러 문제들을 가지고 있다. 예를 들어, 프리 소프트웨어 프로젝트가 갖는 자원 봉사의 속성 때문에 개별 프로젝트 구성원들을 지속적 참여를 전적으로 기대하는 것이 불가능하다[11]. 이런 문제는 프로젝트의 분산 개발 속성에 따라, 자신에게 할당된 작업을 소홀히 하는 자원 개발자를 확인하는 것과, 더 많은 개발자가 필요한 개발 영역에 관한 판단을 더욱 어렵게 만든다[10].

공개 소스에 관한 연구 대부분이 Apache[12]와 GNOME[9]와 같이 대중적이고 성공적인 프로젝트에 초점을 맞추고 있지만, 모든 프리 소프트웨어 프로젝트가 완성도가 높거나, 성공적이거나, 아니면 고품질에 이르는 것은 아니라는 우려도 증가하고 있다. 95,000개가 넘는 프리 소프트웨어와 공개 소스 프로젝트를 호스트 하는 가장 대중적인 사이트인 SourceForge는 유지 보수가 잘 되고 있는 프리 소프트웨어 응용 프로그램을 찾기 위한 훌륭한 소스이기도 하지만, 같은 사이트에는 많은 중단된 프로젝트들과 저 품질의 소프트웨어들도 함께 있다[7]. 중단된 프로젝트 중 일부는 더 높은 가능성을 가진 흥미로운 프로젝트가 분명히 더 많은 자원 봉사자를 끌어들인다는 선택 과정의 측면에서 설명될 수 있지만, 한편으로는 프로젝트의 실패가 프로젝트 관리 기술의 부족과 연관이 있다는 것을 제시하는 연구도 있다[15]. 또, 규모가 크고 성공적인 프로젝트라 해도 자원 개발자의 지속적인 개발 지원의 어려움[10][11], 버그에 대한 개발자들의 지속적인 대처 부족[17] 등, 품질과 관련된 중요한 문제들에 직면하고 있다.

프리 소프트웨어 개발 모델이 기업 업무 및 높은 안정성을 요구하는 업무에 적합한 수준의 완성도와 고품질의 소프트웨어를 창조하기 위한 경쟁력 있는 모델로 남기 위해서는, 프리 소프트웨어의 품질 확보와 프로젝트 관리에 있어, 앞서 언급한 문제들과 다른 품질 관련 문제들을 모두 고려한 해결 방법을 찾아 내야한다. 프리 소프트웨어 프로젝트의 품질을 확보하고 더 개선하기 위한 개발 관행과 개발 절차를 확보하기 위한 첫 단계는, 현재 이용되는 품질 유지를 위한 여러 개발 관행과 품질 문제들을 명확하게 확인하는 것이다. 그러나 지금까지는, 프리 소프트웨어 프로젝트에서의 품질 유지와 관련된 초기 조사만이 일부 실시되었다[19][20]. 이 논문의 나머지 부분은 다양한 분야의 프로젝트들에서 활동하고 있는 프리 소프트웨어 개발자들과의 인터뷰 결과를 담고 있다. 이 인터뷰 결과는 현 시점에서 품질 관리를 위한 개발 관행들과 문제점의 상황을 더욱 정확하게 판단하는데 도움이 될 것으로 기대된다.

III. 연구 방법

이 연구를 위해 프리 소프트웨어와 공개 소스 개발자 7명과 인터뷰를 실시하였다. 인터뷰 대상 개발자들의 프로젝트들이 매우 다양했기 때문에, 인터뷰 대상의 수가 비교적 적었음에도 불구하고 다양한 종류의 프리 소프트웨어 프로젝트들을 대변할 수 있는 결과를 얻었다고 믿는다. 한 프로젝트는 대학에서 학부 학생들에게 소프트웨어 개발 프로젝트에 대한 경험을 주기 위해서 시작된 뒤, 나중에 이 대학 학생들이 외부 기여자로 참여하는 커뮤니티 프로젝트로 바뀐 것이며, 다른 하나는 대기업에 의해 이루지는 연구 활동의 일부이다. 또 다른 하나는 대학에서 이루어진 연구 프로젝트의 결과이며, 나머지 다른 나머지 프로젝트들은 커뮤니티 프로젝트로 시작되었다. 프로젝트의 규모는 Apache, GNOME과 Debian 같은 대규모 프로젝트부터 VideoLAN과 Dasher 같은 규모가 좀 더 작은 프로젝트까지 다양하다.

이 인터뷰는 인터뷰 대상자가 속해 있는 프로젝트의 전반적인 품질 문제에 관한 탐구를 위하여 정형화된 형태를 갖추지는 않았으며, 아래와 같은 항목들이 직접적으로 질문되었고, 다른 주제들에 대한 자유로운 인터뷰 방법을 함께 사용하였다:

- 당신이 참여한 프로젝트에 품질에 관한 이슈들이 있습니까? 만약 그렇다면, 그 이슈들은 무엇이며, 그것을 어떻게 방식으로 처리합니까?
- 프리 소프트웨어와 공개 소스 프로젝트의 품질을 보장하기 위해 어떤 기술이 적용될 수 있습니까?
- 참여한 프로젝트에는 품질을 보장하기 위해 어떤 장치가 있습니까?
- 당신은 공개 소스와 상용 소프트웨어의 품질을 어떻게 비교할 수 있다고 보십니까? 언제 어떤 소프트웨어가 다른 소프트웨어보다 품질이 높다고 이야기할 수 있습니까?

IV. 결과

인터뷰 결과는 인터뷰에서 확인된 현재의 개발과 품질 유지를 위한 관행들에 대한 검토와 공개 소스 프로젝트가 직면한 품질 문제들에 관한 요약 등 두 영역으로 나누어 설명한다. 이 두 영역을 다루기 전에 먼저, 프리 소프트웨어 프로젝트 구성원들이 자신들의 프로젝트 품질을 어떻게 생각하는지에 대해 개괄적으로 살펴본 후에 상용 소프트웨어 품질 대비 공개 소스 소프트웨어 품질에 대한 질문 결과에 대해 이야기할 것이다. 인터뷰 대상자들이 이 질문에 대해서 전혀 편견이 없는 답변을 했다고 기대되지는 않기 때문에, 프리 소프트웨어와 공개 소스 개발자들이 가진 품질에 대한 주관적인 생각을 알 수 있을 것이다.

인터뷰 대상자 중 몇 명은 프리 소프트웨어든 비공개 상용 소프트웨어든 어느 한 쪽의 품질이 더 높다고 말했다. 그러나 많은 인터뷰 대상자들은 프리 소프트웨어가 더 훌륭한 품질을 가질 수 있는 가능성을 더 많이 가지고 있고, 보안 버그와 같은 중요한 이슈에 더 빠르게 반응할 수 있다고 느꼈다. 이렇게 느끼는 데는 여러 이유가 있다. 첫째, 공개 소스라는 속성이 피드백을 더욱 촉진하여 소프트웨어를 개선하는데 도움이 될 수 있다는 것이다. 피드백은 버그 리포트의 형태나 기능에 대한 요구 형태로 나타날 수 있다. 둘째, 많은 인터뷰 대상자들은 자원 개발자들이 그들이 원하는 일을 한다는 점 때문에, 프리 소프트웨어 프로젝트에서 더 높은 동기 부여가 일어난다고 느꼈다. 다른 개발자들과의 공개적인 협력 및 다른 사람들의 의견 제시를 받는 것 등이 소프트웨어의 한 부분을 담당한다는 자신의 일에 더 높은 동기를 부여한다. 일부 인터뷰 응답자는 높은 동기 부여가 소프트웨어의 품질에 긍정적으로 작용한다고 생각했다. 셋째, 한 인터뷰 응답자는 프리 소프트웨어의 분산 개발 속성 때문의 더 많은 인적 자원을 끌어들일 수 있다고 말했다. 그는 “프리 소프트웨어는 보통 전통적인 소프트웨어 회사가 어떤 문제에 대해 보통 구할 수 있는 해결책보다 더 폭넓은 전문적 기술과 지식의 덕을 볼 수 있다”고 주장했다. 상업적 개발과 비교하여 커뮤니티 프로젝트의 부족한 점은 자원과 인프라의 부족이었다. 마지막으로, 한 인터뷰 응답자는 이 두 모델의 근본 원리가 서로 반대되기 때문에 공개 소스 개발 모델과 폐쇄적인 개발 모델을 비교하는 것은 매우 어려운 일이라고 답했다. 소스를 공개하지 않는 회사들은 대개 자신들의 소프트웨어 결함과 소스 코드를 숨기기 때문에, 공개 소스와의 직접적인 비교는 어렵다.  이 차이는 분명히 학문적 연구가 채워줄 수 있는 영역이다.

A. 개발과 품질 유지를 위한 관행

인터뷰 결과 얻어진 놀라운 관찰 가운데 하나는 여러 개발 관행과 절차가 여러 프로젝트들에 대하여 어떻게 다르게 채택되고 있는가이다. 이 절에서는 인터뷰를 통해 확인된 여러 개발 관행들에 대해 요약해서 설명한다. 거의 모든 프로젝트가 이런 개발 절차의 일부분만을 채택하는 반면에, 몇몇 소수의 프로젝트는 모든 부분을 따른다. 왜 이런 현상이 일어나는지와 프로젝트들이 이러한 개발 관행들을 더 많이 도입함으로써 결국 이득을 볼 수 있을지는 분명하지 않다. 다만 흥미로운 사실 하나는 모든 인터뷰 응답자가 개발 절차와 특히 훌륭한 인프라의 중요성을 강조하였다는 점이다.

확인된 개발 관행들은 대체로 다음 세 영역으로 나누어 설명할 수 있다.

1) 인프라

프리 소프트웨어 프로젝트는 분산, 협력 개발을 가능케 하는 인프라에 많이 의존한다. 인프라의 중요 부분은 다음과 같다:

- 버그 추적 시스템 (예, BugZilla): 이는 사용자의 피드백을 수집하는데 사용된다. 이 시스템은 실제 버그 리포트뿐만 아니라 기능에 대한 요구를 저장할 때도 자주 사용된다.
- 버전 관리 시스템 (예, CVS, SVN, Arch) : 이 시스템은 여러 사람이 동시에 같은 코드 기반에서 일하는 것과 누가 어떤 것을 변경했는지 계속 추적하는 것을 가능하게 한다.
- 자동 빌드 (예, tinderbox): 버전 관리 시스템 내의 최신 코드가 계속 성공적으로 빌드 되는 것을 보장한다. 시험 빌드는 다른 여러 하드웨어나 소프트웨어 환경에서도 진행될 수 있다.
- 메일링 리스트: 개발자, 사용자들 사이의 의사소통에 사용된다.

많은 프로젝트가 이런 인프라를 사용하는데 반해, 그 사용 방법은 프로젝트마다 상당히 다르다. 이 인프라 사용 방법, 즉 관행의 차이는 프로젝트의 품질과 밀접한  관계를 가질 수 있다. 예를 들어, 일부 프로젝트는 자동 빌드 시스템을 이용하여 결함이 제거될 때까지 향후 개발을 중지하는 매우 엄격한 정책을 채택하고 있다. 또 버전 관리 시스템의 사용에 따른 관행 또한 매우 다양하다. 일부 프로젝트에서는 첫 기여 이후에 그 기여자에게 바로 소스 등록 권한을 주기도 한다. 또 다른 프로젝트에서 개발자는 다른 개발자의 신뢰를 얻기 위해 몇 달 동안 일을 해야 하는 경우도 있고, 주 개발자만이 소스 등록 권리를 가지는 프로젝트도 있다. 프로젝트 품질에 이러한 다른 개발 관행이 미치는 영향은 앞으로 더 세밀한 연구가 필요하다고 사료된다.

2) 프로젝트의 절차

프리 소프트웨어의 개발에는 많은 단계적 절차들이 개입되지만, 대부분은 어디에도 문서화되어 있지 않으며, 개발자들이 그 절차들을 묵시적으로 따른다.

- 참여: 프로젝트들은 잠재적 구성원들이 프로젝트에 참여하기 위해서는, 대부분 문서화되어 있지 않은, 그 프로젝트에서 정한 절차를 따를 것을 요구한다. 이러한 절차는 프로젝트에 따라 상당히 다양하다. 몇몇 프로젝트는 높은 품질의 결과물을 기대할 수 있는 개발자들에게만 참여를 허용하는 것을 명시적으로 밝히고 있는 반면에, 다른 프로젝트들은 더 개방적이다. [18]에서 프로젝트 참여를 위한 가입 양식 하나를 볼 수 있다.
- 릴리즈: 릴리즈 정책은 프로젝트에 따라 다르지만 많은 경우 프리즈 단계를 거친다. 기능 프리즈는 새 기능을 코드에 추가하지 않고 버그를 고칠 충분한 시간을 벌기 위하여 한다. 또한 최근에는 문자열 프리즈가 인기를 얻어가고 있다. 그것은 다른 나라의 언어로 소프트웨어를 번역하는 개발자들이 소프트웨어 릴리즈 전에 사용된 문자열에 대한 번역을 할 수 있는 기회를 제공한다.
- 브랜치:  이는 안정적 버전과 개발 버전을 유지하는 것처럼 프로그램 버전들 간의 차별화를 위해 사용된다. Arch와 같이 브랜치 관리를 쉽게 만들어주는 새로운 개발 도구는 개발 프로세스에 막대한 영향을 끼쳤다.
- 다른 개발자에 의한 소스 리뷰: 전형적으로 버전 관리 시스템을 통한 소스의 수정은 다른 프로젝트 구성원들에 의해 검토되지만, 많은 경우에 이런 형태의 피어 리뷰가 공식화 되어있지는 않다. 즉, 개발자들은 자신이 수정한 것을 다른 프로젝트 구성원들이 검토해주기를 원하지만 실제로 그렇게 하는 것을 보장할 방법이 없다. 다른 한편, 일부 프로젝트는 이 절차를 상당히 엄격히 실행하며 소스 등록을 하기 전에 반드시 코드를 검토할 것을 요구한다.
- 테스트: 새로운 릴리즈가 프로젝트의 기준을 만족시키는지, 주요한 퇴보가 없는지를 확인하기 위하여 일부 프로젝트는 테스트 체크 리스트를 가지고 있다. 이 리스트는 가장 중요한 기능들을 포함하고 있으며, 어떻게 실험할 것인가를 간략하게 설명하고 있다. 릴리즈는 테스터들이 다른 플랫폼에서 체크 리스트의 내용을 하나하나 검사하고 새 버전이 중요한 프로그램의 중단이나 이전 기능이 동작하지 않는 퇴보 현상이 나타나지 않았음을 확증하고 난 이후에 이루어진다. 자동 시험 도구를 가지고 있는 프로젝트는 거의 없기 때문에, 테스트 체크 리스트를 가지고 있는 것은 적어도 중요한 구성 요소와 기능의 작동을 보장하기 위한 좋은 해결책이 될 수 있다.
- 품질 보증: 일부 프로젝트는 드러난 오류들을 제거하기 위해 버그 데이나 버그 잡기 파티 등을 개최한다. 이 과정에서 중복된 버그 리포트를 확인하고, 또 수정된다.

3) 문서화

많은 인터뷰 응답자가 자신이 참가하고 있는 프로젝트의 개발 관행에 대한 문서화가 미흡하다고 비판했다. 프로젝트에 참가하고 기여하는 방법에 대한 명확히 설명한 문서를 가지고 있는 프로젝트는 별로 없다. 어떤 경우에는, 개발자가 제출한 소스 코드가 프로젝트 주 개발자에 의해 검토된 후 정해진 코딩 스타일을 따르지 않았다고 거부당하기도 했는데, 사실 그 코딩 스타일이라는 것이 문서로서 명확히 되어있는 것도 아니었다. 그러나 기여자의 수가 많은 일부 프로젝트들의 대부분은 훌륭한 문서를 가지고 있다.

- 코딩 스타일: 이 문서는 개발자들이 따라야 하는 소스 코드 스타일을 설명하는 문서이다.
- 소스 등록: 누가, 언제 프로젝트의 버전 관리 시스템에 수정된 소스를 등록할 수 있는지 나타내는 문서이다.

B. 품질 문제

인터뷰에서 확인된 품질 문제들은 대개, 프리 소프트웨어 커뮤니티에서, 해결되어야 할 것으로 생각되어 왔던 이슈들이었기 때문에 특별한 관심을 요한다. 앞부분에서 언급된 많은 개발 관행들이 프로젝트에 쉽게 채택되고 있지 못하고 있는 한편, 앞으로 언급될 품질 문제에 대한 훌륭한 해결책들도 역시 개발되어야 한다.

- 지원이 없는 코드:  아직 해결되지 않은 문제들 중 하나는 과거에 코드가 제공되었지만 지금은 유지 보수가 되지 않는 코드를 어떻게 하느냐이다. 한 기여자가 잘 알려지지 않은 하드웨어에 소스를 포팅하거나, 특별한 기능을 추가한 소스 코드를 등록을 할 수 있다. 원래 소스에 대한 수정이 다른 개발자들에 의해 되면서, 이런 특별한 기능이나 포팅 결과도 지속적인 개정을 해야만 계속 사용될 수 있다. 그러나 불행히도 소스에 기여한 개발자 중 일부는 사라질 수 있고, 그 코드는 기술 지원과 유지 보수 없이 남겨진다. 주 개발자들은 이런 상황을 어떻게 다룰 것인지 결정해야 하는 어려운 상황에 직면한다.
- 설정 관리: 많은 프리 소프트웨어와 오픈 소스 프로젝트들은 높은 수준의 커스터마이징이 가능하도록 개발된다. 이는 사용자에게 많은 유연성을 제공하는 반면, 테스트 문제를 야기한다. 주 개발자는 모든 경우의 수를 테스트해 보는 것이 매우 어렵거나 불가능하기 때문에 흔히 사용되는 환경에서만 테스트해보는 경향이 있다. 따라서 새로운 버전의 소프트웨어가 릴리즈 되면, 새 버전이 자신의 환경에서 동작하지 않는다는 버그 리포트가 많은 것이 일반적인 일이다.
- 보안 업데이트: 많은 경우에 보안 업데이트는 적시에 이루어지나 때로는 몇 주 혹은 몇 달 동안 이루어지지 않는 경우도 있다.
? 사용자가 버그 리포팅 방법을 모르는 경우 : 전문적인 기술이 별로 없는 사용자들이 프리 소프트웨어를 더 많이 사용함에 따라, 개발자들은 쓸모없는 버그 리포트를 더 받게 된다. 많은 경우 사용자는 버그 리포트를 할 때, 충분한 정보를 포함하지 않거나 중복된 버그 리포트를 제출한다. 그런 버그 리포트는 개발자들의 시간을 빼앗을 따름이다. 일부 프로젝트에서는 버그 리포팅 방법에 대한 더 상세한 설명서를 만들기도 했지만, 많은 사용자들은 버그 리포트 전에 그 설명서를 읽지 않는다.
- 자원 봉사자들의 영입: 일부 프로젝트-특히 아주 인기 있는 프로젝트가 아닐 경우-가 직면한 문제 중 하나는 자원 봉사자들을 참여시키는 문제이다.  보통 프로젝트에 기여하는 방법에는 코딩, 테스팅, 버그 선별 등 여러 가지가 있다. 그러나 많은 잠재적 구성원들은 새로운 소스 코드 개발에만 관심이 있을 뿐, 테스트나 버그를 선별하는 일에 관심 있는 기여자는 별로 없다. 그 결과, 개발자들은 그들의 시간 중 많은 부분을 다른 사람들이 쉽게 해결할 수 있는 작업에 사용해야만 한다.
- 문서화의 미흡: 앞의 문제점은 문서화의 미흡과 관련이 있다고 말할 수 있다. 자원 봉사자들은 어떤 한 영역에 기여를 하고 싶어 하는데 어떻게 시작해야 하는지 모를 수 있다. 실제 잠재적 기여자들이 받을 수 있는 도움은 거의 없고, 문서도 거의 존재하지 않는다. 또한 개발자 문서의 부족은 또한 모든 사람이 같은 기술과 진행 과정을 따르고 있는지 확신할 수 없다는 것을 암시한다.
- 조정과 의사소통의 문제: 일부 프로젝트에는 조정과 의사소통의 문제가 있으며 이는 프로젝트 품질에 나쁜 영향을 줄 수 있다. 때로는 어떤 영역에 대한 책임이 누구에게 있는지 명확하지 않기 때문에 버그에 대해 적절한 의사소통을 할 수 없는 경우도 있다. 또한 작업이 중복될 수도 있고 치명적인 버그를 없애기 위한 조정이 미흡할 수도 있을 것이다.

요약하면, 이 인터뷰는 프리 소프트웨어 프로젝트에서 프로젝트 품질에 잠재적 영향력을 가지고 있는 몇 가지 두드러진 이슈들을 확인했다.

V. 검토와 향후 연구 방향

이 연구에서 행한 인터뷰는 프리 소프트웨어의 품질에 관한 많은 몇 가지 흥미로운 관점을 제시해 주었다. 눈에 띄는 관찰 결과 하나는 프리 소프트웨어 프로젝트들에 사용된 개발 관행의 다양성이다. 인터뷰에 따르면 모든 프로젝트가 따르는 하나의 프리 소프트웨어 개발 모델이 있다고 주장하기 어렵다. 모든 프로젝트는 일반적 속성을 공유하지만, 각 개발 관행 사이에는 분명한 차이들이 존재한다. 다른 개발 관행들이 프로젝트의 품질에 서로 다른 영향을 줄 수 있기 때문에, 이런 개발 관행들과 그 결과 만들어진 소프트웨어의 품질 사이의 연관성에 대해서는 향후 실험적 연구가 요구된다. 그러한 연구를 통하여 특정 프로젝트에 가장 좋은 개발 관행은 무엇인지, 또는 개발 관행의 적용에 영향을 주는 요인들이 무엇인지를 제시할 수 있을 것이다.

또한 인터뷰는 분명히 프로젝트들이 많은 문제에 직면하고 있다는 것을 보여주었다. 이 연구의 대상이 되었던 모든 프로젝트는 성공적인 프리 소프트웨어 프로젝트라고 볼 수 있지만, 그래도 분명히 품질 개선의 여지가 있다. 기술 지원이 없는 코드의 문제점은 현재 있는 기능의 제거가 사용자에게 영향을 줄 수 있기 때문에 대단히 중요하다. 한편으로는, 자원 개발자에 의존하는 프로젝트들은 개별 기능의 유지 보수뿐만 아니라 프로젝트 그 자체의 유지에 대한 보장조차도 명확하지 않다. 이것은 보수를 받지 않는 자원 개발자를 중심으로 진행되는 프로젝트가 높은 품질의 상품을 만들어 낼 뿐 아니라 높은 수준의 품질을 유지하기 위하여 지속적으로 유지 보수될 것인지에 대한 일반적인 의문을 더욱 증폭시킨다.

ISO 8402는 품질 보증을 품질에 대한 요구를 만족시키는 방향으로 나아가는 모든 “계획적이고 체계적인 활동들”이라고 정의한다. 많은 프리 소프트웨어 활동에서 볼 수 있는 자원 개발자의 변동성, 무계획적인 개발 등을 고려하면, 프리 소프트웨어 프로젝트가 품질에 대해 계획적이고 체계적인 접근을 할 수 있는지, 그 결과 고품질을 보장할 수 있는지 분명하지 않다. 프리 소프트웨어가 기업 업무 환경과 높은 수준의 안정성을 요구하는 응용에 점점 더 많이 이용됨에 따라, 이러한 의문에 대한 관심은 더 증가될 것이다. 품질에 대한 체계적인 접근의 부족으로 인한 문제들 중 일부는 이미 해결된 것도 있다. 많은 중요한 결점들, 특히 보안과 관련된 이슈들은 매우 빠르게 고쳐진 (종종 1시간 안으로) 반면, 일부는 몇 주 후나 몇 달 후에도 미해결 상태로 남아있다는 것이 인터뷰 중에 지적되었다. 결함 제거에 걸리는 시간은 경우에 따라 상당한 차이가 있으며, 더 체계적인 품질 보증 활동이 적절한 시간 내에 결함을 수정할 수 있게 만들 수 있을 것이다.

최근에 일부 프리 소프트웨어 프로젝트는 품질 보증의 중요성을 깨닫고 전담팀을 구성했다. GNOME는 오랫동안 다양한 품질 보증 관련 작업을 수행했으며[17], Debian은 잘 확립된 QA 팀을 운영하고 있고[2][10], KDE는 2004년 3월에 품질 향상을 위한 작업에 착수했다[8]. 이러한 노력들은 주로 결함이나 더 이상 기술 지원을 받지 못하는 구성 요소를 없애는 것 같은 품질 보증의 기본적 수준에 초점을 맞추고 있다. 그 다음 단계는 최소 수준을 보장하는 것에서 결함 방지와 품질 개선 전략의 이행으로 나아가는 것이다.

품질과 품질 개선에 대한 연구를 위해서는, 실제로 품질 측정을 위한 도구와 평가 기준이 필요하다. 품질 개선을 위한 기술에 대한 평가는 반복적인 품질 측정을 통해서만 가능하다. 불행히도 품질은 정확하게 정의하기가 매우 힘든 개념이다. 많은 사람들이 무엇이 품질을 수반하는지 직관적으로 느낀다. 그러나 정확한 방법으로 품질을 확인해야 할 때, 그 개념은 명확히 정의하기가 매우 어렵다는 것을 알게 된다[1].

품질은 다른 많은 요소들로 구성된 개념이다 [16]. 어떤 사람에게는 고품질 제품인 것이 다른 사람에게도 반드시 같은 식으로 받아들여지는 것은 않는다. 예를 들어, 품질에 대한 사용자의 견해는 소프트웨어 개발자와 다를 수 있다. 자원 개발자들은 대개 자신이 사용할 목적으로 소프트웨어를 만들기 때문에, 기술적으로 미비한 다른 사용자들의 요구와 품질 수준을 고려하지 않는 경향이 있으며, 이 때문에 품질에 대한 사용자와 개발자 사이의 견해 차이는 프리 소프트웨어에서 중요한 의미를 가지고 있다. 상용 소프트웨어 프로젝트가 철저히 유료 고객의 요구에 의해 진행되는 반면, 대부분 자원 개발자에 의해 진행되는 프로젝트에서는 사용자와 개발자 사이에 조정이 거의 없다. 품질에 대한 바람직한 접근은 넓은 시각을 유지하며 소프트웨어에 대한 여러 다른 요구들과 품질의 속성에 대한 고려를 하는 것이다.

이 연구는 어떤 부분을 개선할 수 있는가에 관한 몇 가지 시작점들을 제시하였다. 프리 소프트웨어 프로젝트의 품질과 관련된 다른 문제들에 대하여는 더 많은 샘플을 가진 연구가 앞으로 필요하다. 또한 품질 개선 전략을 만들기 위해서는 품질의 여러 측면들을 측정하고 평가하기 위한 도구와 평가 기준이 필요하다. 이 부분은 학계와 프리 소프트웨어 커뮤니티의 협력으로 상승효과를 얻을 수 있는 영역이다. 앞으로의 품질에 관한 실험적인 연구는 품질을 측정하는 도구와 평가 기준의 개발에 달려있다. 이러한 도구들은 다시 프리 소프트웨어의 개발자들에게 제공되어 자신들의 프로젝트의 품질을 평가하고, 그 결과를 효과적인 품질 개선 전략 개발의 출발점으로 사용할 수 있을 것이다.

VI. 결론

이 논문은 프리 소프트웨어 개발자와 실시한 인터뷰를 통하여, 품질 측면에서 프리 소프트웨어 프로젝트를 관찰하였다. 또한 이 논문에서는 품질과 관련된 소프트웨어 개발 관행이 어떤 것인지와 더불어 프리 소프트웨어 프로젝트가 직면하고 있는 몇 가지의 품질 문제에 대해 기술하였다. 이 연구에서 제기된 여러 이슈들은 품질 개선 전략의 요소와 함께 프리 소프트웨어 프로젝트의 품질에 대한 앞으로의 연구를 위한 출발점으로 사용될 수 있을 것이다.

보수를 받지 않는 자원 개발자들에 의한 프로젝트가 높은 수준의 품질을 보장할 수 있는지에 대한 의문이 남아있기 때문에, 프리 소프트웨어의 품질에 관한 향후 연구는 매우 중요하다. 향후 연구로 이 연구에서 발견되지 않은 다른 품질 문제들을 확인하는 것과 프로젝트의 품질에 대한 여러 다른 개발 관행들의 영향을 평가할 것을 제안하였다. 마지막으로, 품질을 측정하고 평가할 수 있는 도구들이 필요하다는 것을 주장하였으며, 그 도구는 프리 소프트웨어의 품질에 대한 향후 학계의 연구와 프로젝트 품질을 개선하기 위한 프리 소프트웨어 개발자 모두를 위해 도움이 될 것으로 사료된다.

VII. 감사의 글

이 연구는 부분적으로 Fotango, NUUG 재단과 EPSRC로부터 지원을 통해 이루어졌다.

참고 문헌

[1] B. Dale and H. Bunney, Total Quality Management Blueprint. Oxford, UK: Blackwell Business, 1999.
[2] “Debian quality assurance team,” http://qa.debian.org/, accessed March 31, 2005.
[3] M. E. Fagan, “Design and code inspections to reduce errors in program development,” IBM Systems Journal, vol. 15, no. 3, pp. 182?211, 1976.
[4] J. M. Gonz´alez-Barahona, M. A. Ortu?no P´erez, P. de las Heras Quir´os, J. Centeno Gonz´alez, and V. Matell´an Olivera, “Counting potatoes: the size of Debian 2.2,” Upgrade, vol. II, no. 6, pp. 60?66, December 2001.
[5] J. M. Gonz´alez-Barahona, G. Robles, M. Ortu?no P´erez, L. Rodero-Merino, J. Centeno Gonz´alez, V. Matellan-Olivera, E. Castro-Barbero, and P. de-las Heras-Quir´os, “Analyzing the anatomy of GNU/Linux distributions: methodology and case studies (Red Hat and Debian),” in Free/Open Source Software Development, S. Koch, Ed. Hershey, PA, USA: Idea Group Publishing, 2004, pp. 27?58.
[6] T. J. Halloran and W. L. Scherlis, “High quality and open source software practices,” in Proceedings of the 2nd Workshop on Open Source Software Engineering. Orlando, FL, USA: ICSE, 2002.
[7] J. Howison and K. Crowston, “The perils and pitfalls of mining SourceForge,” in Proceedings of the International Workshop on Mining Software Repositories (MSR 2004), Edinburgh, UK, 2004, pp. 7?11.
[8] “KDE quality team,” http://quality.kde.org/, accessed March 31, 2005.
[9] S. Koch and G. Schneider, “Effort, cooperation and coordination in an open source software project: GNOME,” Information Systems Journal, vol. 12, no. 1, pp. 27?42, 2002.
[10] M. Michlmayr, “Managing volunteer activity in free software projects,” in Proceedings of the 2004 USENIX Annual Technical Conference, FREENIX Track, Boston, USA, 2004, pp. 93?102.
[11] M. Michlmayr and B. M. Hill, “Quality and the reliance on individuals in free software projects,” in Proceedings of the 3rd Workshop on Open Source Software Engineering. Portland, OR, USA: ICSE, 2003, pp. 105?109.
[12] A. Mockus, R. T. Fielding, and J. D. Herbsleb, “Two case studies of open source software development: Apache and Mozilla,” ACM Transactions on Software Engineering and Methodology, vol. 11, no. 3, pp. 309?346, 2002.
[13] E. S. Raymond, The Cathedral and the Bazaar. Sebastopol, CA: O’Reilly & Associates, 1999.
[14] D. C. Schmidt and A. Porter, “Leveraging open-source communities to improve the quality & performance of open-source software,” in Proceedings of the 1st Workshop on Open Source Software Engineering. Toronto, Canda: ICSE, 2001.
[15] A. Senyard and M. Michlmayr, “How to have a successful free software project,” in Proceedings of the 11th Asia-Pacific Software Engineering Conference. Busan, Korea: IEEE Computer Society, 2004, pp. 84?91.
[16] I. Sommerville, Software Engineering. Essex, England: Pearson Education Limited, 2001.
[17] L. Villa, “Large free software projects and Bugzilla,” in Proceedings of the Linux Symposium, Ottawa, Canada, 2003.
[18] G. von Krogh, S. Spaeth, and K. R. Lakhani, “Community, joining, and specialization in open source software innovation: a case study,” Research Policy, vol. 32, no. 7, pp. 1217?1241, 2003.
[19] L. Zhao and S. Elbaum, “A survey on quality related activities in open source,” Software Engineering Notes, vol. 25, no. 3, pp. 54?57, 2000.
[20] ??, “Quality assurance under the open source development model,” The Journal of Systems and Software, vol. 66, pp. 65?75, 2003.