제공 :
한빛 네트워크
저자 : By Andy Oram
역자 : 명경석
원문 :
Finding a sweet spot for crowdsourcing: uTest outsources software testing
속임수가 있는 몇몇의 경우를 제외하곤 위키페디아 같은 피어 프로덕션(peer production)의 약속은 어디에나 적용될 것처럼 보인다. 다만 작업에 함께 참여하는 공헌자와 수혜자 양측에 가치 있는 결과물을 만들어 내기 위한 첫 걸음을 내 딛는 다는 것이 그리 쉬운 일이 아니다. 그런 결과를 얻어내기 위해서는 아래와 같은 요건이 충족되어야 한다.
- 협력관계를 조율하는 것
- 명확한 목표를 설정 하는 것
- 신뢰할 수 있는 사람들이 유지하는 평판시스템(reputation system)과 피드백의 제공
- 참가한 사람들에 대한 보상
그리고 동의하겠지만, 작업을 진행하면서 발생하는 어려움을 감춰주고 모험을 가능하게 하기 위해서는 위와 같은 방법에 따라 돈을 버는 것도 좋은 일이 될 수 있다.
유-테스트는 필요한 요소를 모두 모아둔 것처럼 보인다. 사업 모델은 간단히 설명할 수 있다. 유-테스트를 수행하는 소프트웨어 개발업체를 위해서 버그 발견 시 비용을 지불할 프리랜서 테스터를 고용한다. (몇몇 고객들은 전통적인 소프트웨어 서비스가 그래 왔듯이 정액제 기반 모델을 생각하고 있겠지만 유-테스트의 경우에는 버그 수를 기준으로 해서 테스터에게 비용을 지불한다)
유-테스트는 운영 중이다: 유-테스트는 2008년 4월 제한적으로 접근이 허용된 베타사이트를 연 이후 2008년 8월에 2번 째 자금지원이 이루어지고 정식으로 오픈했다.
현재 2주 또는 3주의 테스트 주기를 가지고 있는 50여 고객과 148개국 11,700명이 넘는 테스터가 참여하고 있다.
테스트의 과정은 잘 알려져 있고 유-테스트를 진행하는 테스터 들은 표준화된 절차를 따라 테스트를 수행한다. 모델은 다소 눈길이 가는 부분을 제공한다. 예를 들면, 몇 천명의 테스터와 같이 접속을 할 경우에도 스크립트와 가상머신에 의존 했던 것보다 더 사실적으로 가상 무역 박람회 같은 어플리케이션을 테스트 할 수 있다. 하지만, 실제로 유-테스트에서 흥미를 끄는 부분은 상호 교류와 보상 시스템이며 이 기사에서 기술하고 있는 것이다.
이 블로그의 몇몇 아이디어가 자발적으로 참여하는 사람들에게는 이익이 될지도 모르는 반면에, 조직화된 커뮤니티들을 통해 실제로 회사를 운영하는 기업들에는 대부분 직접적인 이득을 가져다 준다.
지난 주 자신의 도메인에 크라우드소싱 적용을 시도하려 하는 다른 조직을 돕고자 하는 유-테스트의 최고경영자인 드론 루베니와 만나 몇몇 흥미로운 이야기를 들었다. 나는 모델을 진행하고 나서 유-테스트와 소프트웨어 분야의 다른 크라우드소싱 회사에서 제공하는
탑코더(TopCoder)를 간단히 비교 할 예정이다.
상호교류와 가상 협력활동
유-테스트 기반에서 이루어지는 모호하지 않고 고도로 체계화 되어있는 상호작용도 있다. 예를 들면, 고객은 테스트 사례별로 나누어지고 테스터들에게는 테스트 스크립트를 제공한다. 이것은 신규 고객과 신입 테스터들에게 적절한 방법이다. 유-테스트는 최상의 서비스를 고객에게 제공하려는 프로젝트 매니저에게 새로운 고객을 만들어 준다.
상호작용은 점점 더 정교해 지겠지만 고객들은 스크립트를 디자인하는 테스터들의 경험을 받아들이고 편하게 스크립트를 시작할 것이다. 유-테스트는 일단 실행되는 프로그램을 테스트하는데 전념하겠지만 2009년 1사분기에는 하이레벨 기능의 테스팅을 제공하는 제품을 디자인 할 예정이다.
더 나은 테스트를 수행하기 위해서 협력하고 각 테스트 주기에 고객의 영향이 종종 발휘 되는 동안에 데스터들은 각 제품 관련 커뮤니티를 형성한다. 보상은 대부분의 버그를 찾아내려고 노력하는 각 테스터 개인에게 돌아가긴 하지만 경쟁보다는 협력하는 측면의 동기가 되고 있다. 공동의 목표를 위해서 일하는 다른 시간대, 많은 문화적 차이를 가진 팀원들로 구성된 유-테스트 팀들은 지리적으로 나뉘어져 있는 것이 대부분이다.
높은 수준에 있는 테스터들도 유-테스트 시스템을 잘 사용하는 방법을 연구하고 기술을 향상시키기 위해서 포럼에 참여한다. 그리고 그들 역시 유-테스트 최고의 모집원이 되어서 동료들을 새로운 테스터로 데리고 온다.
상호교류는 잘 체계화된 의견 교환과 채팅을 허용하는 내부 메시지 시스템을 통해서 만들어지는 텍스트를 기반으로 한다. 그렇지만 우리가 예상하는 것처럼 테스터들은 영역을 확장할 것이다. 그리고 이에 맞춰 유-테스트는 멀티미디어를 추가할 계획을 가지고 있다.
혁신과 피어 프로덕션
신생기업인 유-테스트는 줄곧 플랫폼을 넓혀가고 있는 중이다. 그러면서 테스터들과 고객으로부터 많은 것을 얻고 있다. 루베니는 강한 어조로 이야기 했다. “우리는 유-테스트 시스템에서 이루어지는 관계에서 우월한 지위의 파트너가 되는 것을 원하지 않습니다.”
정보교환은 매우 중요하기 때문에 많은 테스터들은 시스템의 잘못된 부분을 정확하게 고객에게 알려줄 수 있도록 슬라이드 쇼 편집기와 비디오 편집기 같은 서드파티 프로그램을 마련한다. 유-테스트는 그런 서드파티 프로그램을 통합해서 테스터들이 인정할 수 있는 플랫폼을 제공하려 하고 있다. 테스터들도 사회적 네트워크 같은 다른 환경에서 자신들이 확보하고 있는 유-테스트 프로파일을 공유하기를 원한다.
결국, 유-테스트는 테스터들과 고객들이 각자의 특징을 추가하여 스스로의 가치를 높여 갈 수 있도록 하기 위해서 오픈소스 플랫폼을 시스템의 일부로 흡수할 것이다.
등급체계와 선택의 기회
유-테스트는 다양한 언어와 플랫폼을 알고 있는 초보자에서 전문가로 형성되어 있는 테스터들과 함께 테스트 경험의 방대한 영역을 제공한다. 각 테스트 주기에서 고객은 어떤 수준의 얼마나 많은 테스터들을 원하는 지 규정한다. 고객들은 어느 순간에 실행되는 서버의 개수를 약정하고 확장하려 하는 고객을 받아들이는 클라우드 컴퓨팅(인터넷 기반의 컴퓨터 기술)같은 테스트 기반을 약정하고 확장할 수 있다.
고객은 테스터들의 지식을 얻는 것과 마찬가지로 규정된 기능을 위해서 적합한 테스터를 요구할 수 있다. 근본적으로 유-테스트는 매주 재구성되고 해체되는 시장의 특성을 가지고 있다. 고객이 테스터를 마음에 들어 하지 않거나 그 반대의 경우에는 다시 함께 일하지 않는다.
유-테스트가 가지고 있는 유연한 계약 시스템은 시간제 부 수입원으로 유-테스트 시스템을 이용하려 하는 테스터들을 쉽게 만들어 낸다. 전형적인 테스트 일정에서 고객의 개발 팀이 금요일에 한 개발 주기를 매듭짓고 테스트를 토요일에 시작해서 일주일 내내 시험한 뒤 고객은 월요일 아침에 사무실에서 오픈 했을 때 완전한 버그 리포트를 얻게 된다. 이런 시간적 조절은 양쪽 모두에게 이점을 가져다 준다.
루베니는 많은 테스터들이 돈을 위해서 라기보다는 다른 좋은 기회를 이용해서 성공할 수 있는 평판을 만들 수 있고 일을 하는 주간 동안 본업 이외의 영역에서 일을 하며 새로운 시스템들을 공부할 수 있는 기회가 있기 때문에 유-테스트에 참여하는 것이라고 말한다.
평판과 정직
고객은 오로지 버그를 찾아낼 때만 돈을 지불한다. 나는 가능한 한 회의적으로 루베니를 몰아 붙이면서 고객이 버그의 존재를 부정하는 것을 방지하고, 어떻게 그런 상황이 일어나지 않도록 할 것인지 물어보았다.
대답은 간단했다: 테스터들은 언제 그들이 부정한 짓을 하는지 알고 있습니다. 그리고, 그들은 서로 의견을 공유합니다. 명백한 버그를 인정하지 않는 고객은 곧 좋지 않은 평판을 얻고 테스터들에게 다음 테스트를 의뢰하기 어려운 상황에 봉착할 것입니다.
실제 운영 중에 그로 인해서 고객들과 테스터가 서로 각각 만족한 결과를 얻어 내려고 하다가 같이 실패하는 역효과가 나타나는 것을 유-테스트로 찾아낸다. 예를 들면, 고객은 유-테스트가 고려하지 않는 현상(버그 리포트가 실제의 버그는 아니지만 여전히 가치 있는 정보와 보상이 된다는 걸 결정 해야 하는 상황에 직면하지 않는 다는 것에 대해서 고객이 결정해야 할 수 있는 현상)을 논의하기 위해서 유-테스트 시스템에 접속한다. 이러한 요구에 대한 방안으로 유-테스트는 버그를 찾아내는 것 이외에도 테스터를 보상하는 ‘가치 있는 피드백’ 프로그램을 만들어 낸다.
유-테스트 시스템은 스스로 모니터링을 한다. 고객/테스터 간에 일어나는 변칙적인 행위(일반적이지 않은 많은 양의 버그 리포트 거부 등)에 대해서 조사 한다.
유-테스트 인증 프로그램도 마찬가지로 새로운 기회를 이용하려는 테스터들 받아들이고 한층 높은 수준의 책임을 다 하도록 하고 있다. 인증 프로그램들은 테스트 커뮤니티 전체를 위한 모델로서 제공될 수도 있지만 현재 인증 프로그램이 완전히 규격화 된 것은 아니다.
추가되는 것들은 무엇인가? 관련된 모두에게 이득과 부를 가져다 주면서 서로 만족할 수 있는 수준에서 참여하는 것을 받아들이는 시스템. 그리고 시스템에서 협력하고 배우며 성장하도록 육성하는 것이다.
필자가 언급했지만 탑코더 처럼 일반적인 경우와는 달리 소프트웨어 아웃소싱 영역에서 성공한 회사의 다른 모델과 유-테스트 모델을 비교하는 것은 흥미로운 일이 될 것이다. 비록 유-테스트가 테스트를 수행하는 동안 탑코더는 디자인과 코딩을 수행하지만 양쪽 모두 인터넷 같은 구성원이 개별적으로 참여하는 세계적인 네트워크에 의존하고 있다. 양측 모두 시스템에 협력하는 온라인 커뮤니티들을 구성 해왔다
최근에 탑코더를 이끄는 프로젝트 매니저 중 하나인 션 캠피온과 홍보이사인 짐 맥켄을 만나서 나눈 대화를 전제로 양 시스템의 영역에서 겹쳐지고 분리되는 부분에 보이는 몇몇 양상에 관해서 언급한다.
협동 대 경쟁
양쪽 회사 모두 비록 설정자체에 경쟁의 양상이 포함된다 할지라도 협력하려 하는 참가자들 에게는 동기가 유발 된다는 것을 발견한다. 이런 양샹은 첫눈에도 명확히 보이겠지만 각 프로젝트 당 할당된 대금은 두 경쟁자 중 가장 좋은 성적을 낸 사람에게만 지불되기 때문에 탑코더에서 더 강하게 나타난다. 그럼에도 불구하고 탑코더의 참여자들은 서로 해당 프로젝트 포럼의 고객 요구사항과 관련된 문의에 대해서 답변을 하고 시스템을 익히는 초보자들을 돕기 위해서 ‘연습실’ 과 프로젝트 포럼이 아닌 일반 포럼에도 시간을 할당한다. 이러한 행위가 그들 모두에게 이득이 되기 때문이다.
동기 부여
유-테스트는 무척 세밀하게 분배되어 있는, 초심자가 실력을 기르기 편리하며 진입하기 위한 낮은 장벽이기도 한 보수를 상대적으로 쉽게 지불하고 있다. 탑코더는 각 프로젝트 상위 5 순위로 구성한 다른 계층을 위해서 ‘디지털 런’이라고 하는 캐쉬 포인트 시스템을 제공해서 승자가 모든 것을 차지하는 모델을 완화하고 있다. 버그 레이스(표준 구성요소에서 버그 하나를 수정하려는 날쌘 경쟁자들 이 참여하는 작은 규모의 경쟁)에서는 약간의 현금을 획득하기 위해서 온 새로운 경쟁자들을 받아들이기도 한다. 그런 식으로 유-테스트와 탑코더 양쪽 모두 임시 공헌자가 손 쉽게 참여할 수 있는 시스템을 마련해 놓았다. 독자 여러분도 원한다면 시간제 부업에 참여할 수 있도록 말이다.
탑코더가 없었다면, 새로운 지식 영역과 기술을 습득할 수 있는 기회가 참여에 대한 가장 강력한 동기가 되었을 것이다. 모든 제안은 최저 기준으로 교섭한다고 해도 전문가에 의해서 검토된다. 경쟁자들의 커뮤니티(약간 모순되긴 하지만 생생하게 현장감 있는 표현을 만들어 낸 것)에서는 단순 참여로도 기술을 얻게 된다. 그리고 참가자들은 다른 외부 활동과 입사지원에서 탑코더 점수로 포인트를 얻을 수 있다.
물론, 경쟁에 있어서 기본적인 (지원자는 경쟁할 수단으로 테스트와 작업문서를 포함하는 프로젝트를 완전히 수행해야만 한다는)규칙들이 주어지는 상황에서 탑코더가 금전적이지 않은 보수를 제공했다면 성공할 수 없었을 것이다.
혼란을 피하기 위해서 나는 유-테스트가 탑코더 같이 경쟁하는 체제가 되지 않도록 유지해야 한다. 유-테스트의 테스터는 작업수행을 위해서 전적으로 자신의 책임하에 작업을 수행하게 된다.
평가와 품질관리
유-테스트의 품질관리는 어떤 수준의 대가를 지불할지 결정할 고객에 의해 정해진다. 테스터들은 묵시적으로 각자의 의사를 표현해서 고객을 평가한다. 탑코더 참여자들 역시 마찬가지다. 탑코더에서 절대적으로 충분한 보상이 제공되지 않거나 불완전하게 정의된 프로젝트는 경쟁자들의 선택을 받지 못한다.
그러나 일단 경쟁이 시작되면 탑코더는 엄격한 품질관리를 요구한다. 고객의 책임이긴 하지만 캠피온 같은 여러 탑코더 품질 매니저에게 검토되는 요구사항과 함께 작업이 시작된다. 내성, 정확성 그리고 (전문 리뷰어에 의해서 발전된 성공 테스트와 상반되는 개념의)실패 테스트가 지속된다. (개별 경쟁자들의 책임아래) 유닛 테스트도 수행된다. 고객은 UI 프로토타입을 제공하여 제품 디자인과 개발을 수행하는 기간 동안 어떤 포인트에 대해서 테스트하고 요구사항도 확인 하게 할 수 있다.
이 회사들의 아이디어 중 많은 것들이 다른 피어 프로덕션 환경에서 수행될 것이고 회사들의 선택 분야에서 두드러지게 될 것으로 보인다. 그렇게 쓰이긴 하겠지만 자신의 산업분야에서 피어 프로덕션을 시도하기를 원하는 사람도 역시 최적의 도구를 찾아내는 방법을 공부함으로써 약간의 팁을 얻을 수 있을 것이다.