애플리케이션 개발에 참여하는 개발자들의 역할이 점점 더 세분화, 전문화되고 있는 현실에서 소수 개발자의 능력만으로 프로젝트를 성공적으로 완료하는 것이 점점 더 어려워지고 있다. 애플리케이션에 대한 고객들의 높은 요구사항과 프로젝트 규모의 대형화, 다양한 기술 요소들이 등장하고 있는 탓이다. 때문에, 프로젝트의 성공 요인으로 개발자들의 기술적인 능력도 중요하지만 프로젝트에 참여하고 있는 구성원들 간의 효율적인 커뮤니케이션이 더 중요하게 되었다.

며칠 전 필자는 동영상 서비스에 초점을 겨냥한 비디오로그(http://videolog.blog.naver.com)라는 신규 서비스를 오픈했다. 이 비디오로그는 규모 측면에서 그다지 크지 않은 규모의 프로젝트였으나 애플리케이션을 개발하는데 예상보다 많은 시간이 소요되었다.

이유야 많겠지만 1차적인 이유로 점점 더 전문화되고 있는 애플리케이션 개발자들 간의 의사소통 비용이 급격하게 늘어난 점을 들 수 있을 것이다.

비디오로그를 오픈하기 전까지 애플리케이션 개발에 참여한 팀은 최초 기획을 담당한 기획팀과 서버 측 개발을 전담한 개발팀, 자바 스크립트와 Ajax 개발을 담당한 Ajax 개발팀, 플래시 개발을 담당한 플래시 개발팀, HTML 코딩을 담당한 코딩팀, 디자인을 담당한 디자인팀, 최종 테스트 및 품질 검증을 담당한 QA팀까지 모두 7개 팀이다.

효율적인 커뮤니케이션이 프로젝트 성공요인의 중요한 요소로 부각되면서 프로젝트 구성원들 간의 커뮤니케이션을 지원하기 위해 많은 도구들이 등장하고 있다. 그 중에서도 프로젝트 업무와 기능, 이슈, 버그에 대한 관리와 추적이 가능한 Jira와 Bugzilla, Trac과 같은 프로젝트 관리 툴은 프로젝트 구성원들 간의 원활한 커뮤니케이션을 위하여 유용한 도구이다.

특히 최근에 배포된 Eclipse Europa(Eclipse 3.3 버전)에 기본적으로 포함되어 있는 Mylyn 플러그인과 Jira, Bugzilla, Trac과 같은 프로젝트 관리 툴의 통합은 개발자와 개발자, 개발자와 QA에 사이에 발생하는 커뮤니케이션 비용을 상당부분 줄여준다.

이 글에서는 이런 프로젝트 관리 툴 중에서 Jira에 초점을 맞추어 프로젝트를 시작하는 초기와 프로젝트 진행중, 프로젝트 완료 후 유지 보수하는 시점까지의 활용방안에 대하여 살펴볼 것이다. 필자가 프로젝트를 진행할 때 사용하고 있는 사용자 스토리 기반으로 Jira를 협업에 어떻게 활용할 수 있는지에 대하여 다루고 있다.

또한 Jira와 Eclipse Mylyn을 통합한 시너지 효과가 개발자와 QA에게 얼마나 큰 도움을 주는지에 대하여 깊이 있게 살펴볼 것이다.

기획자의 역할

기획자가 어떤 업무를 담당하는지에 대하여 생소한 독자들이 있을 것이다. 기획자의 역할은 애플리케이션의 기능을 기획, 분석하고 고객과의 협의 등을 담당한다. 국내 대형 포털들과 웹 에이전시에서는 이 같은 업무을 전담하는 기획자라는 역할을 분리하여 운영하고 있다. 대부분의 프로젝트에서는 기획자가 PM의 역할까지 담당하는 경우도 흔하다. 포털이나 웹 에이전시가 아닌 일반 SI 프로젝트에서는 기획자가 PM, 업무 분석을 담당하는 업무 분석가, 고객의 역할로 생각하면 된다.

사용자 스토리를 이용한 기능 분석

상세 기획이 완료되면 기획자와 개발자가 한 자리에 모여 기획서를 바탕으로 애플리케이션 개발에 필요한 모든 기능에 대한 분석 작업을 하게 된다. 각각의 기능에 대한 분석은 사용자 스토리를 기반으로 하고 있다.

사용자 스토리에 해당하는 기능 분석 작업이 완료되면 각각의 사용자 스토리에 스토리 포인트를 부여한다. 즉, 각각의 사용자 스토리를 완료하는데 소요되는 업무량을 점수화하여 상대적인 작업량을 판단하는 것이다.

사용자 스토리

『사용자 스토리』라는 책을 보면 사용자 스토리를 다음과 같이 정의하고 있다. 사용자 스토리는 소프트웨어의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것이다. 사용자 스토리는 다음 세 측면으로 구성된다. • 서술(written description) : 스토리는 서술 형태로 기록되며, 계획하거나 기억하기 위한 단서로 사용된다. • 대화(conversaction) : 스토리는 대화를 통해 세부사항을 구체화한다. • 테스트(test) : 스토리는 테스트를 통해 세부사항을 문서화하고 전달하며, 스토리의 완료 여부를 판단한다.

이 작업과 동시에 각 사용자 스토리에 대한 우선순위를 결정한다. 사용자들이 애플리케이션을 사용하는데 얼마나 필요한 요소인지에 따라서 상, 중, 하로 분류하는 것이 일반적이다. 많은 기획자들이 우선순위를 결정할 때 대부분의 사용자 스토리에 대하여 ‘상’으로 결정하는 경향이 있다.

이와 같은 상황이 발생하면 개발자가 적극적으로 참여하여 사용자 스토리에 대한 우선순위를 재조정할 수 있도록 유도해야한다. 우선순위를 재조정하지 않을 경우 모든 사용자 스토리의 우선순위가 높아 무엇을 먼저 개발해야 할지 판단하기 힘들게 된다. 또한 일정의 압박으로 일부 기능을 제외해야 할 때 판단 기준으로 사용하기 힘들어진다.

기획자와 개발자가 협의하여 결정한 사용자 스토리는 Jira에 등록한다. 프로젝트를 시작할 때는 각각의 사용자 스토리를 언제까지 완료할지 결정하지 않은 상태로 Jira에 등록한다. 사용자 스토리를 등록할 때 결정된 우선순위까지 모두 입력한다. Jira에 사용자 스토리를 등록한 화면은 <화면 1>과 같다.

<화면 1> 사용자 스토리를 등록한 Jira 화면

사용자 스토리를 등록할 때 각 사용자 스토리와 관련된 기획서나 문서를 첨부한다면 개발을 담당하는 개발자나 테스트 케이스를 만들어야 하는 QA에게 도움을 줄 수 있다.

요구사항 변경으로 인한 기획서 변경이나 업무 로직의 변경은 프로젝트를 진행하는 중에도 수시로 발생한다. 그 때마다 수정된 기획서나 요구사항 문서를 전달해야 한다면 이를 읽는 개발자들은 거의 없을 것이다.

기획서나 요구사항 문서가 방대하여 개발자나 QA들이 새로 읽는데 거부감을 느낄 것이기 때문이다. 여러 프로젝트에서 문서와 개발이 분리되어 진행되는 경우를 자주 본다.

그러나 Jira의 사용자 스토리별로 수정된 부분의 기획서와 관련 문서를 변경한다면 해당 기능을 개발하고 있는 개발자만 선택적으로 분석할 수 있다. 또한 Jira의 알림 기능을 이용하여 변경된 내용을 관련자들에게 전달할 수도 있다.

<화면 2> 사용자 스토리에 기획서를 첨부한 Jira 화면

<화면 2>는 사용자 스토리와 관련 있는 기획서를 첨부한 Jira 화면이다.

반복 주기(Iteration) 결정과 사용자 스토리 선택

사용자 스토리에 대한 분석과 Jira 등록이 완료된 후 개발자들은 배포주기를 몇 주 단위로 가져갈지에 따라서 1주에서 4주 간격으로 하나의 반복주기를 결정하게 된다. 1주 또는 2주 단위로 반복주기를 짧게 가져가는 것이 일반적이다.

개발자들은 반복주기 내에서 개발 가능한 범위 중 우선순위가 높은 사용자 스토리를 먼저 선택하게 된다. 이와 같이 결정된 사용자 스토리는 Jira의 버전 관리 기능을 이용하여 <화면 3>처럼 관리된다.

<화면 3> 반복주기 1에서 개발할 사용자 스토리들

Jira와 Mylyn 통합 및 활용

반복주기에 대한 결정과 각 반복주기 내에서 구현할 사용자 스토리가 결정되었다면 그 다음은 개발 작업을 진행하게 된다. 개발할 때 Jira를 이용하여 업무를 관리하면 많은 이점을 얻게 된다.

개발자가 Jira에 접근하고 관련 정보를 참조하기 위해 Eclipse 플러그인으로 개발되어 있는 Mylyn과 통합할 수 있다. Jira를 Mylyn과 통합할 경우 Task에 대한 조회와 새로운 Task 추가, 각 Task별 스케줄 관리 등 Jira가 지원하는 모든 기능을 Eclipse 개발 툴 내에서 실행할 수 있다.

<화면 4>는 Eclipse Mylyn을 이용하여 각 컴포넌트별, 반복주기별로 Task를 조회한 화면이다. Mylyn을 이용할 경우 Jira가 제공하는 모든 조회 조건별로 Task를 조회할 수 있기 때문에 자기 자신에게 할당되어 있는 Task만 조회하여 개발할 수도 있다.

<화면 4> Eclipse Mylyn을 이용하여 Jira의 Task를 조회한 화면

Eclipse Mylyn을 이용하여 Jira와 통합했을 때 Jira가 지원하는 기능만을 사용하는 것에 대한 이점이라면 개발자 입장에서는 하나의 일관된 개발 툴을 사용한다는 것 밖에 없을 것이다. 그러나 Eclipse Mylyn 플러그인은 Jira가 가지고 있는 기능 이외에 개발자와 QA를 위한 많은 기능들을 포함하고 있다.

Eclipse Mylyn을 Jira와 통합하여 사용했을 때 얻게 되는 가장 큰 이점은 각 Task를 작업할 때 개발자들이 접근해야 되는 개발 자원을 통합해서 관리할 수 있다는 점이다.

최근의 경향을 보면, 애플리케이션을 개발할 때 다수의 프레임워크를 사용하기 때문에 개발자들이 기능 하나를 개발하며 접근해야 하는 자원의 수가 10개를 넘기기 십상이다. 현재 필자가 기능 하나를 개발하기 위하여 접근해야 하는 개발 자원을 보면 다음과 같다.

• DAO 인터페이스 클래스, DAO 구현 클래스
• DAO 테스트 클래스
• DAO 구현 클래스를 위한 Spring 프레임워크 설정 파일
• IBatis 프레임워크 설정 파일
• 비즈니스 인터페이스 클래스, 비즈니스 구현 클래스
• 비즈니스 테스트 클래스
• 비즈니스 구현 클래스를 위한 Spring 프레임워크 설정 파일
• Action 구현 클래스
• Action 테스트 클래스
• Webwork 프레임워크 설정 파일
• UI를 담당하고 있는 JSP 파일

이 목록은 하나의 기능을 추가하거나 수정할 때 필자가 반드시 접근해야 하는 개발 자원들이다. 기능을 완료한 다음 개발자원에 다시 접근할 필요가 없다면, 해당 기능과 관련된 개발 자원을 몰라도 괜찮을 것이다. 그러나 하나의 기능을 완료할 때까지 같은 파일에 몇 십 번 씩 접근하는 것이 일반적이다.

기능을 처음 개발할 때는 관련된 개발 자원을 찾는 것이 그리 어렵지 않다. 그러나 몇 주가 지난 후에 기능을 수정하기 위하여 관리 기능을 찾는 것은 미로 속에서 출구를 찾는 것만큼이나 어려운 작업이다. 물론 이 같은 문제점 때문에 명명 규칙을 잘 지켜 일정 부분 해결하고 있지만 이 또한 제한되어 있는 것이 사실이다.

개발할 때 발생하는 이 같은 문제점을 해결하기 위하여 Eclipse Mylyn 플러그인은 각 Task별로 관련 있는 개발 자원을 관리할 수 있도록 지원하고 있다. Eclipse Mylyn은 각 Task와 관련 있는 개발 자원들의 집합을 컨텍스트(Context)라고 부른다. 예를 들어 개발자 간에 다음과 같은 협업이 가능하게 된다.

A라는 개발자가 Jira에서 관리하고 있는 ‘새로운 사용자를 추가할 수 있어야 한다'는 사용자 스토리를 개발하기 위하여 <화면 5>와 같이 개발 자원을 생성했다.

Eclipse Mylyn 2.0의 Context 지원

Eclipse Mylyn 2.0 버전까지는 JSP, XML 파일까지 하나의 Context로 관리할 수 있도록 지원하지 않고 있다. 이 점이 아직까지 하나의 단점이기는 하지만 Java 소스에 대한 Context 관리만으로도 충분한 효과를 볼 수 있다. 앞으로 출시될 버전에서 JSP, XML 파일까지 하나의 Context로 관리할 수 있기를 기대해본다.

<화면 5> A 개발자가 사용자 추가 기능을 구현하기 위하여 생성한 자바 클래스

A 개발자가 ‘새로운 사용자를 추가할 수 있어야 한다’ 사용자 스토리를 개발하기 위하여 생성한 모든 자바 클래스에 대한 정보는 Eclipse Mylyn의 Context 추가 기능을 이용하여 Jira에 저장된다.

B 개발자는 Eclipse Mylyn에서 ‘새로운 사용자를 추가할 수 있어야 한다’ 사용자 스토리에 대한 Context를 복구하면 <화면 5>와 똑같은 개발 자원에 접근할 수 있는 것이다. 단, Eclipse Mylyn 2.0 버전에서는 아직까지 JSP, XML 파일에 대한 자원 관리가 되지 않고 있어 하나의 아쉬움으로 남는다.

Jira에 저장되는 Context 정보는 Jira가 Eclipse Mylyn을 이용하여 별도로 제공하는 기능이 아니다. Eclipse Mylyn은 관련 Context 정보를 압축하여 Jira에 첨부파일로 저장하는 방식으로 관리한다. 따라서 Eclipse Mylyn의 Context 기능은 Jira와 별도로 Bugzilla, Trac과 같은 프로젝트 관리 툴과 통합해서 사용할 수도 있다.

Task에 Context를 추가한 다음Jira에 접근해보면 <화면 6>과 같이 mylyn-context.zip 파일이 Task에 첨부되어 있는 것을 확인할 수 있다.

<화면 6> Task에 Context를 추가했을 때 첨부된 Mylyn Context 압축 파일

개발자 본인이 작업한 기능에 대한 관련 자원을 찾는 것도 어려운데, 다른 개발자가 작업한 기능과 관련된 개발 자원을 찾는 것의 어려움은 말할 필요조차 없을 것이다. 이 과정에서 발생하는 비용과 개발자의 사기 저하 또한 상당히 크다. Eclipse Mylyn의 Context 기능은 개발자 간의 협업을 극대화함으로써 개발 생산성을 향상 시키는 결과를 가져온다.

Jira와 Eclipse Mylyn을 통합했을 때 얻게 되는 또 하나의 이점은 각 Task별로 버전 관리 시스템에 소스를 Commit하는 것이 가능해진다는 것이다. 버전 관리 시스템을 사용할 때 개발자들이 소스 코드를 Commit하는 과정을 살펴보면 다음과 같다.

• A 기능을 구현한다.
• A 기능의 구현이 완료되기 전에 B 기능의 버그를 수정한다.
• A 기능을 구현하는 중 다른 요구사항으로 인해 C 기능을 구현한다.
• A, B, C 기능들을 일괄적으로 Commit 한다.
• 일괄적으로 Commit을 했기 때문에 A, B, C 모든 기능들에 같은 주석을 추가한다.

국내 현실에서 버전 관리 시스템을 기반으로 작업할 때 이런 경우는 다반사로 발생한다. 특히 이 과정에서 발생하는 첫 번째 문제점은 A 기능이 완료되지 않은 상태에서 일괄 Commit을 했기 때문에 컴파일 에러가 발생하고, 이로 인해 빌드가 정상적으로 되지 않는 경우가 많다는 것이다.

두 번째 문제점은 일괄 Commit을 하면서 모든 기능에 대하여 같은 주석을 추가했기 때문에, 프로젝트를 진행하는 중에 과거 소스에 대한 이력을 보더라도 해당 시점에 무슨 작업으로 인해 Commit을 했는지가 명확하지 않다는 것이다.

필자 또한 소스 코드를 Commit할 때 각 기능별로 분류해서 Commit하고, 각 기능별로 서로 다른 주석을 달지 않는다. 이상적으로는 각 기능단위로 Commit하고, 각 기능에 따라 다른 주석을 추가하는 것이 맞겠지만 일정의 압박으로 인해 여러 개의 기능을 같이 Commit하는 것이 일반적이다.

이 같은 소스 코드 관리의 문제점을 Jira와 Eclipse Mylyn을 이용하여 해결할 수 있다. Eclipse Mylyn은 Jira의 각 Task별로 개발 자원을 관리할 수 있기 때문에, 각 Task 별로 변경된 소스 코드에 대해서 Commit하는 것이 가능하다. <화면 7>은 각 사용자 스토리별로 변경된 소스코드가 관리되고 있는 화면이다.

<화면 7> 각 Task별로 소스 코드를 Commit할 수 있는 Eclipse Mylyn 기능

또한 각 Task별로 Commit이 가능하기 때문에 Task별로 주석을 추가할 수 있다. 뿐만 아니라 Jira가 관리하고 있는 Task명이나 Task의 상태, URL 등에 대한 주석을 자동적으로 추가할 수도 있다(<화면 8> 참조).

프로젝트를 진행하다보면 일정상의 이유 때문에 소스 코드를 Commit할 때 주석을 추가하지 않는 경우가 많은데 Eclipse Mylyn의 이 같은 기능은 개발자들이 주석을 추가하는데 투자해야할 부담을 덜어줄 것이다.

<화면 8> 소스 코드 Commit시 Jira 정보를 자동적으로 추가한 기능

반복주기 완료
반복주기를 완료하기 위해서는 각 반복주기 내에서 개발하기로 계획한 사용자 스토리를 완료해야 한다. 그러나 개발자의 판단만으로는 사용자 스토리를 완료했는지의 여부를 판단하기 어렵다.

개발자들이 자신이 개발하면서 예상한 정상적인 경우에만 테스트를 진행하는 것이 일반적이서 개발자들만의 판단으로 사용자 스토리의 완료여부를 결정하게 될 경우 버그가 발생할 확률이 높다.

따라서 각 사용자 스토리의 완료여부에 대한 판단은 최종적으로 QA가 판단해야 한다. QA는 개발자 관점이 아닌 기능적인 관점에서 사용자 스토리를 바라보기 때문에 정교한 테스트를 진행하는 것이 가능하기 때문이다. 개발자가 완료했다고 결정한 사용자 스토리에 대하여 QA가 테스트를 진행할 경우 다수의 버그가 발생하는 경우는 수도 없이 많이 보게 된다.

이와 같이 개발을 완료한 사용자 스토리에 대하여 QA는 테스트를 진행하게 된다. 이때 개발자와 QA 사이의 협업에서도 Jira는 그 진가를 발휘한다. QA는 각 사용자 스토리에 대한 테스트를 진행하면서, 테스트 시 발생한 버그에 대하여 Jira에 등록한다. 각 개발자는 Jira에 등록된 버그 중 자신에게 할당된 버그를 수정하는 작업을 진행하게 된다.

Jira를 도입하기 전까지는 일정 시간 테스트를 진행한 다음 버그 목록을 메일을 통해서 전달했을 것이다. 그러나 Jira를 이용할 경우 버그 등록과 개발자에 의한 버그 수정 후 문제 해결, 해결된 버그에 대하여 최종 테스트 완료 후 종결까지 모든 과정을 Jira를 이용하여 일관된 방식으로 물 흐르듯이 처리하는 것이 가능하다(<화면 9> 참조).

<화면 9> 반복주기 1을 완료하고 반복주기 2를 진행할 때의 Jira 화면

자신의 프로젝트 구성원 중에 QA가 있다면 참 행복한 경우이다. 그러나 아직까지 국내 대부분의 프로젝트에 QA 역할을 전담하는 사람이 있는 경우는 드물다. QA에 대한 전담자가 없는 경우라도 반복주기를 완료할 때 사용자 스토리를 개발한 개발자가 테스트를 주도하도록 하는 것은 좋지 않다.

자기 자신이 개발한 기능에 대해서는 매번 같은 방법으로 테스트를 진행하기 때문에 버그를 찾기가 어렵다. 때문에, QA가 없는 상황이라면 개발자들끼리 상호 테스트를 진행하여 버그를 찾고 문제를 해결하도록 하는 것이 좋다.

유지보수 시 Jira 활용
웹이 처음 등장했을 때는 얼마나 빨리 새로운 서비스를 오픈하느냐가 서비스의 성패를 좌우했다. 그러나 웹이 급격하게 성장하고 고객들의 요구사항이 높아지면서 서비스 개발 비용보다는 유지보수 비용에 몇 배나 많은 비용이 발생하게 되었다.

처음 서비스를 운영할 때는 미처 생각하지 못했던 이 같은 유지보수 비용은 신규 서비스를 개발하고, 고객들의 요구사항을 만족시키는데 큰 걸림돌이 되고 있다.

애플리케이션 개발을 완료한 후에는 개발을 담당하던 기획자, 개발자, QA는 관련 서비스에 소홀하게 된다. 완료된 프로젝트는 유지보수 담당자에게 전달되어 새로운 고객 요구사항을 반영하고, 문제점을 찾아 해결하는 작업을 진행하게 된다. 애플리케이션을 개발할 때까지만 해도 잘 진행되던 프로세스는 없어지고, 구두나 메일을 통한 업무 요청과 버그 수정 요청들이 난무하게 된다.

유지보수를 담당하는 개발자, QA는 신규로 추가되는 기능과 애플리케이션이 이미 가지고 있는 문제점을 해결하는 일이 너무 바빠서 이와 같이 무작위로 전달된 Task들을 관리하기 힘든 상황이 된다. 이 때 Jira와 Eclipse Mylyn을 이용하여 지속적인 관리를 한다면 기존 버그나 신규 요구사항을 일관되게 관리하는 것이 가능해진다.

특히 Eclipse Mylyn은 개발자들의 유지보수 비용을 줄여주는 역할을 한다. 대부분의 프로젝트들이 개발할 때의 개발자와 유지보수를 담당하는 개발자가 다르다. 따라서 유지보수를 맡은 개발자는 인수인계를 받았다 할지라도 새롭게 맡은 애플리케이션에 익숙해지는데 많은 시간이 걸린다.

유지보수를 하는 개발자 관점에서 처음에 가장 힘든 부분은 각 기능과 관련되어 있는 개발 자원을 찾는 것이다. 도대체 해당 기능과 관련된 개발 자원이 어디에 위치해있는지를 몰라 갈팡질팡하는 경우를 종종 본다. 자신이 개발한 애플리케이션이 아니기 때문에 이는 당연한 결과일 것이다.

이 때 Eclipse Mylyn의 Context 개념은 유지보수를 맡은 개발자가 사용자 스토리와 관련된 소스 코드를 관리하는데 도움을 준다. 또한 Eclipse Mylyn은 해당 기능을 구현하기 위하여 지금까지 개발자가 작업해온 히스토리를 추적할 수 있는 기능까지 제공하기 때문에 기능을 처음 분석하는 개발자에게 많은 도움을 줄 수 있다.

<화면 10>은 하나의 사용자 스토리를 구현하기 위하여 처음부터 마지막까지 작업한 내역에 대한 추적이 가능하도록 지원하고 있는 Mylyn 기능이다.

<화면 10> Context의 히스토리를 추적할 수 있는 Mylyn 기능

필자가 지금까지 참여해왔던 프로젝트의 구성원들을 보면 기존의 개발 방식을 잘 바꾸지 않으려는 성향을 가진 사람들이 있었다. 지금까지 익숙해져 있는 개발 방식이 가장 좋은 상태라 생각하고, 새로운 툴을 익히거나 새로운 개발 방식을 적용하는데 대한 거부감을 갖는 것이다.

그러나 내가 현재 하고 있는 일 중에서 얼마나 많은 일들이 단순, 반복적으로 진행되고 있는지에 대하여 자신의 주위를 한번 둘러보는 여유를 가졌으면 좋겠다. 많은 부분에서 비효율적인 요소들을 찾아낼 수 있을 것이다.

이 같은 단순, 반복적인 작업에 반기를 들고 새로운 시도를 하려는 기획자, 개발자들이 프로젝트마다 한두 명씩은 있다. 그러나 다른 프로젝트 참여자들로 인해 이들의 의지는 시간이 지날수록 점점 꺾이는 경우를 종종 본다.

새롭게 적용하고자하는 기술, 툴들이 모든 경우에 좋은 것은 아니지만, 이러한 시도에 처음부터 거부감을 가지고 접근할 필요는 없을 것이다. 적용하고자 하는 툴의 활용가치와 적용범위를 명확히 하여 적용한다면 프로젝트에 십분 활용할만한 가치들을 발견할 수 있을 것이다.

이 글에서 소개하고 있는 Jira와 Eclipse Mylyn 또한 국내 개발자들에게는 생소할 것이다. 아직까지 너무 이상적이라고 받아들이는 기획자나 개발자들 또한 많을 것이다. 그러나 언제까지 이상적인 개발 방식으로 치부할 사항은 아니다. 현재 모든 기능을 적용하기 힘들겠지만 일부분만이라도 적용해 나간다면 프로젝트를 진행하는데 도움을 받을 것이다.

이 문서가 Jira를 이용해서 프로젝트 협업을 위한 만병통치약처럼 비춰지지만 하나의 툴만으로 모든 프로젝트 구성원을 만족하기란 힘든 일이다. Jira와 더불어 같이 사용한다면 좋을 것으로 생각하는 툴은 이번 특집기사에서 다루고 있는 위키이다.

문서의 생성, 결합, 관리, 공유가 용이한 위키와 Jira를 결합한다면 프로젝트 구성원들 간의 협업을 한층 더 향상 시킬 수 있을 것으로 기대한다.

Jira와 위키 같은 툴의 장점에도 불구하고 잘못 사용할 경우 발생하는 부작용도 따르게 마련이다. 프로젝트를 같이 진행하고 있는 PM의 다음 글이 우리들에게 이에 대한 경각심을 불러일으킨다.

"저는 프로젝트 구성원과 툴이 혼연일체가 되지 않고 작업자가 소외되는 순간 업무 효율성과 관리 정확도는 떨어진다고 생각합니다. 이러한 기본 원칙이 지켜진 상태에서 Jira와 위키의 장점이 결합된다면 툴 적용에 찬성합니다."

결국 툴 하나 사용한다고 해서 프로젝트 구성원들 간의 협업을 향상시킬 수는 없다. 툴은 단지 협업을 도와주는 도구일 뿐이다. 프로젝트 구성원들 간의 상호 신뢰가 밑바탕이 되었을 때 툴의 도입은 협업을 극대화시키는 역할을 할 것이다.

막연히 누군가 현재 진행하고 있는 프로젝트를 성공시켜줄 것을 기대하지 말고 자기 자신이 프로젝트의 성공을 위하여 적극적인 자세를 가져보는 것은 어떨까? 같이 일하는 동료들과 신뢰를 쌓고 협업을 향상시키기 위한 노력을 내 자신부터 실천에 옮긴다면 지금보다는 훨씬 재미있게 일할 수 있지 않을까?

이런 적극적인 시도를 하는 사람들에게 Jira와 Eclipse Mylyn은 짜릿함을 안겨줄 것이다. 필자와 같이 Jira와 Eclipse Mylyn의 재미에 빠져볼 사람은 없는가? @


참고자료
1. Jira : http://www.atlassian.com/software/jira/
2. Bugzilla : http://www.bugzilla.org/
3. Trac: http://trac.edgewall.org/
4. Eclipse Europa: http://www.eclipse.org/europa/
5. Eclipse Mylyn: http://www.eclipse.org/mylyn/
6. 사용자 스토리 마이크 콘 지음/한주영, 심우곤, 송인철 공역, 2006, 인사이트


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