amplengine님의 이글루

오래 전부터 국내를 강타(?)하며 여러 개발팀에 유행처럼 도입되는 XP(eXtreme Programming). 하지만 XP를 적용한다 하더라도 기대만큼의 효과를 얻기란 쉽지 않다. 협업 또한 많은 사람들이 위키가 대세라고 이야기하지만 위키 또한 생각한 것만큼의 생산성을 얻을 수 있으려면 많은 희생이 뒤따르게 마련이다. 특집 3부에서는 위키보다 간단하면서도 높은 참여효과를 얻을 수 있는 BTS에 대해 알아본다.

개발팀이 가장 효과적으로 정보를 공유하면서 프로젝트를 진행할 수 있으려면 어떻게 하면 좋을까? 아마 많은 사람들이 위키 활용이라고 말할 것이다. 하지만 국내 개발자 중 아직 위키에 익숙하지 않은 사람들도 많다. 필자가 생각하기에 위키를 능숙하게 사용할 수 있는 개발자는 1%정도도 안 될 듯하다.

누군가 위키를 써 봤는데 좋다는 말에 프로젝트에 강제로 위키를 도입하려고 한다면 적잖은 무리가 따를 것이다. 단 1%의 개발자 때문에 나머지 개발자들이 희생을 해야 할 것이기 때문이다.

그렇다고 위키가 나쁘다고 말하려는 것은 아니다. 위키에 익숙한 개발자나 팀이라면 위키를 쓰는 것이 맞다. 하지만 아직 위키에 익숙지 않은 사람들이 훨씬 더 많다면 생각을 좀 달리해 봐도 좋겠다는 이야기다.

최근에는 위키를 좀 더 쉽게 사용할 수 있도록 서비스되는 것들도 있지만, 역시 설치형이 아니라면 이것도 좀 찜찜하다. 남의 회사 서비스에 자사의 기밀사항들을 올려두기가 개운치 않은 탓이다.

다들 좋다고 하는 위키를 자꾸만 깎아 내리는 필자의 의도는 뭘까? 만약, 팀원 대다수가 위키 사용에 익숙지 않고 협업을 위해 위키와 유사한 것을 안전하게 쓰고 싶다면 BTS를 사용해 봐도 좋겠다는 이야기를 하고자 하는 것이다.

BTS의 활용

앞서 주절주절 설명한 위키의 문제점들을 보완할 수 있는 방법 중 하나가 바로 특집 3부에서 알아볼 BTS(Bug Tracking System)다.

BTS는 말 그대로 버그 잡는 시스템이다. 그동안의 경험으로 보면 위키 보다는 BTS를 적용 하였을 때 개발자들의 참여도가 더 높았다. 자신이 만든 코드에 문제가 있어서 누군가 문제를 공개적으로 제기하면 남의 일이 아닌 이상 관심을 가지게 될 수밖에 없는 까닭이다.

일단 문제가 생기면 사실을 해명하든지 아니면 문제를 해결해야 자신의 실력을 입증할 수 있을 터다.

이 글에서는 이런 목적으로 사용할 수 있는 BTS 프로그램 중 일본인 개발자가 만든 kagemai를 기준으로 소개하려고 한다. 인터페이스가 일본어로 되어 있어 좀 낯설지도 모르겠지만 기능이 간단하니 그리 문제가 되진 않을 것이다.

게다가 한글을 적용하는 것 또한 가능하다. 굳이 이 프로그램을 소개하는 이유는 그동안 써 본 여러 BTS 시스템 중 kagemai가 가장 편리하게 사용할 수 있었기 때문이다.

<화면 1> kagemai 개발 홈페이지

국내에서는 Trac도 BTS로 많이 쓰이고 있지만, 버전 컨트롤 시스템과 위키의 통합측면에서는 좋지만 사용법이나 인터페이스 측면에서는 저는 약간 우리 문화에는 맞지 않는 듯하다.

<화면 2> kagemai의 BTS 예시 화면

일반적으로 BTS 시스템의 사이클은 다음의 6단계로 구성된다.

• 신규(New) : 버그 보고나 개발 안건으로 신규 안건이 발생
• 할당(Assigned) : 매니저가 안건을 담당자에게 할당
• 착수(Resolved) : 담당자가 작업을 개시할 때에 상태를 착수로 변경
• 확인 대기(reopened) : 작업을 종료한다고 확인 대기로 상태를 변경
• 확인이 끝난 상태(Verified) : 테스터가 개발 환경에서 확인을 실시
• 완료(Closed) : 실전 환경에 적용해 실전 환경에서도 문제가 없으면 안건이 완료


이런 과정을 통해 BTS를 적용하게 되면 다음과 같은 일들을 명확히 할 수 있다.

• 누가 어느 안건의 작업을 하고 있는가?
• 누구에게 어떠한 안건을 할당할 수 있는가?
• 누가 작업이 완료하고 있는지 어떤지?

Kagemai 사용하기

그럼 Kagemai의 사용법에 대해 간단히 알아보자. 이 글에서는 kagemai의 0.8.4 버전을 기준으로 알아볼 것이며, OS는 윈도우2000과 윈도우XP를 기준으로 설명하지만, 리눅스에서도 거의 동일한 방법으로 사용할 수 있다. 아파치와 루비가 설치되어 있어야한다.

Kagemai를 설치하려면 먼저 홈페이지(http://www.daifukuya.com/kagemai)에 접속한 후에 ‘kagemai-0.8.4.tar.gz’ 링크를 클릭하여 다운받아야 한다. 다운로드 받은 파일은 C:\Program Files\Apache GroupApache2\htdocs 폴더의 아래쪽에 ‘kagemai’라는 폴더를 만든 후에 이 폴더에서 압축을 풀면 된다.

Kagemai 사용 설정하기
아파치 안의 ‘\conf\httpd.conf’ 파일을 텍스트 편집 프로그램으로 연 후에 ‘#AddHandler cgi-script .cgi’를 ‘AddHandler cgi-script .cgi’로 코멘트 처리를 삭제한다. 그리고 마지막 행에 다음 내용을 추가한다.

<Directory "C:/Program Files/Apache Group/Apache2/htdocs/kagemai/html">
Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>

그런 다음 kagemai 내의 ‘html\admin.cgi’, ‘html\guest.cgi’, ‘html\user.cgi’ 세 개의 파일을 텍스트 편집 프로그램으로 열어 맨 위 행의 ‘#!/usr/bin/ruby’를 ‘#!C:/ruby/bin/ruby’로 윈도우즈 플랫폼에 맞게 변경한다.Kagemai의 설정이 제대로 되었는지 확인하려면 브라우저를 실행하여 http://localhost:80/kagemai/html/guest.cgi에 접속한다. <화면 3>과 같은 화면이 표시된다면 제대로 인스톨 된 것이다.

<화면 3> 인스톨 성공 화면

전체 설정과 프로젝트 작성

Kagemai의 설치를 성공적으로 마쳤으니 이제 마음껏 사용하기만 하면 된다. 이번 기사의 페이지 분량이 적은 탓에 여러 활용법에 대해서 다룰 수는 없겠지만, 가장 기본적으로 알아두어야 할 기능 위주로 간단히 알아보자.

위키도 마찬가지겠지만 BTS 역시 기능을 많이 아는 것 이상으로 중요한 것이 개발자들의 참여와 활용의지다. 각 기능들에 대해 익히고 나면 이것들을 자신들의 업무에 어떻게 활용하면 좋을 지 생각해 보는 대에서부터 개발 협업이 시작되는 것이다.

전체 설정
‘~/kagemai/html/guest.cgi’에 액세스 하면 <화면 4>와 같은 내용이 표시된다. 여기에서 ‘관리’ 링크를 클릭한다.

<화면 4> 관리 화면

관리 화면이 표시되면 ‘전체의 설정의 변경’ 링크를 클릭한다.

<화면 5> 설정 변경 화면

전체의 설정 화면이 되면 <화면 6>과 같이 각각의 항목을 설정한 후에 [설정을 변경] 버튼을 누르면 설정 완료된다.

<화면 6> 전체 설정 화면

<표 1>은 이때 화면에 표시되는 각 항목들의 설명이다.


프로젝트의 작성
화면상의 ‘관리’를 클릭한 후에 ‘프로젝트의 작성’링크를 클릭한다. 프로젝트 작성 설정 화면이 표시되면 각 항목을 설정한다. 이때, 프로젝트 이름에는 한글을 사용할 수 있다.

<화면 7> 프로젝트의 작성 화면

필드의 추가하기
관리 화면 아래에 있는 ‘필드의 커스터마이즈’ 링크를 클릭한 후에 필드를 커스터마이즈하고 싶은 프로젝트를 선택한다.

<화면 8> 관리 화면의 필드의 커스터마이즈 클릭 화면

필드의 커스터마이즈 화면이 표시되면 변경하거나 삭제할 필드를 선택한 후에 해당 링크를 클릭한다. 새로운 필드를 추가하려면 화면 아래쪽에 있는 ‘추가’를 클릭한 후에 필드 추가 화면에서 새 필드를 추가한다.

<화면 9> 필드의 추가 화면

필드 추가 화면에서 추가할 수 있는 필드의 종류는 총 여섯 가지이다. 각 필드 유형에 대해 간단히 알아보자.

● 문자열 필드
1행의 텍스트 박스가 만들어진다. ID와 표시명, 필드 설명 그리고 문자열 필드의 사이즈를 지정하는 설정 화면이 표시된다.

<화면 10> 문자열 필드 편집 화면

● 단일 선택사항 필드
여러 항목 중 하나만 선택할 수 있는 필드가 만들어진다. 설정 내용은 기본적으로 문자열 필드와 거의 같지만, 선택할 항목을 지정하는 부분이 추가로 있다.

● 복수 선택사항 필드
복수 선택 가능한 드롭다운 필드가 만들어진다. 설정 내용은 단일 선택사항 필드와 거의 동일하다.

● 텍스트 필드
여러 줄의 내용을 입력할 수 있는 텍스트 박스가 만들어진다. 설정 내용은 문자열 필드와 비슷하지만 ‘가로폭’과 ‘행 수’를 지정하는 항목이 추가로 있다.

● 플래그 필드
온·오프 하는 형태로 선택할 수 있는 체크 박스가 추가된다. 디폴트값을 ‘on’이나 ‘off’로 지정할 수 있다.

● 파일 첨부 필드
‘참조’ 버튼을 이용하여 파일을 선택할 수 있는 필드가 추가된다.

정보 공유 효율이 곧 개발 생산성

일반적으로 개발자가 n사람 있으면 개발 스피드가 n배로 향상 되지는 않는다. 서로의 정보 전달에 코스트가 걸려 있기 때문이다. 따라서 좋은 개발 방법은 정보 전달을 효율적으로 가고 있다고 말할 수 있다. 정보 전달을 효율적으로 실시할 수 있어야 개발 스피드를 n배에 근접할 수 있다.

하지만 그러려면 먼저 갖춰져야 할 것이 바로 조직의 변화다. 하지만 누군가 “자 이제 우리 변해보자”한다고 조직이 변화될 리는 없다. 아무리 좋은 개발 방법론이나 시스템을 도입해도 쉽게 개발 생산성이 오르거나 하지는 않는다는 얘기다.

변하기는 해야 하고 쉽게 바뀌지는 않는다면 어떻게 하는 것이 좋을까? 인력을 싹 갈아 치우면서 새로운 조직에 새로운 방법론을 적용한다면 쉬울 것이다. 그

렇지 않다면 기존의 상황을 최대한 유지하면서 구성원들의 생산성을 이끌어내는 방식을 찾아야 할 것이다. 현재 조직에서 가능한 한 변화를 적게 주며 구성원 모두의 호응이 높은 참여를 이끌어 낼 수 있는 방법! 그게 바로 서로 다른 조직 환경에 맞는 XP가 진정한 팀워크를 이루는 방식이 아닐까. @


참고자료
1.Kagemai BTS - http://www.daifukuya.com/kagemai


* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.