IP 주소를 통하여 해당 IP에 해당하는 Hostname 알아내기.

CMD > nbtstat -a [IP Address]

블로그 이미지

Moonistar moonistar


Some users & customers have asked about the most recent release of Apache Hadoop, v1.0: what’s in it, what it followed and what it preceded.  To explain this we should start with some basics of how Apache projects release software:

By and large, in Apache projects new features are developed on a main codeline known as “trunk.”  Occasionally very large features are developed on their own branches with the expectation they’ll later merge into trunk.  While new features usually land in trunk before they reach a release, there is not much expectation of quality or stability.  Periodically, candidate releases are branched from trunk.  Once a candidate release is branched it usually stops getting new features.   Bugs are fixed and after a vote, a release is declared for that particular branch.  Any member of the community can create a branch for a release and name it whatever they like.

This diagram illustrates the history of the various Apache Hadoop releases and their origins.  There are 3 occasions where community releases from the Apache Hadoop project broke with what would be a more traditional release & branch convention.  These occasions are usually the source of confusion for users.

  1. More than a year after Apache Hadoop 0.20 branched, significant feature development continued on just that branch and not on trunk.  Two major features were added to branches off 0.20.2.  One feature was authentication, enabling strong security for core Hadoop.  The other major feature was append, enabling users to run Apache HBase without risk of data loss.  The security branch was later released as 0.20.203.  These branches and their subsequent release have been the largest source of confusion for users because since that time, releases off of the 0.20 branches had features that releases off of trunk did not have and vice versa.
  2. Apache Hadoop .22 released chronologically after Apache Hadoop 0.23.  In actuality Apache Hadoop 0.23 is a strict superset of features over 0.22 but it actually released a month before 0.22.
  3. A few weeks after 0.23 released, the 0.20 branch formerly known as 0.20.205 was renumbered 1.0.  There is next to no functional difference between 0.20.205 and 1.0.  This is just a renumbering.

Because of issue #1, there has been an 18 month period where there has been no one Apache release that had all the committed features of Apache Hadoop.  This table illustrates the point:

As members of the Apache Hadoop community, Cloudera engineers have focused their efforts on getting back to releases that are strict superset of all of the features of any past releases so as to avoid having to make the unpleasant choice of picking one feature set over another.  The good news is minus the confusion over the 1.0 numbering, we are basically there.  There have been two good recent releases off of trunk (0.22 and 0.23) one of which (0.23) does have all of the features of any past release.  It’s very possible these new releases will get renumbered to 2.0 or 3.0 or some other number to indicate they are functional supersets of 1.0 but this remains to be decided.

Many of you are CDH users and by now you’re wondering what Apache Hadoop you are running today and what Apache Hadoop you’ll be running in the future.  This diagram shows the CDH releases and the Apache Hadoop releases they draw from.

The CDH1 distribution incorporated the 0.18.3 Apache Hadoop release.  The CDH2 distribution incorporated the 0.20.1 Apache Hadoop release.  The CDH3 distribution incorporated the 0.20.2 Apache Hadoop release plus the features of the 0.20.append and 0.20.security branches that collectively are now known as “1.0.”  The Apache Hadoop in CDH3 has been the equivalent of the recently announced Apache Hadoop 1.0 for approximately a year now.  The CDH4 distribution will likely incorporate a release from the 0.23.x series.  We also do quarterly updates for CDH releases.  These updates typically include backports from trunk that fix bugs or improve performance & stability, not new component releases.  In some cases when it is not destabilizing or compatibility breaking, a CDH update will include an incrementally new component version.  For example CDH3U0 uses HBase 0.90.0 whereas CDH3U2 uses HBase 0.90.4.

Cloudera’s Distribution including Apache Hadoop currently incorporates and integrates 13 different open source components to create a single open source Apache Hadoop based data management platform.  11 of the 13 components come from Apache projects, Apache Hadoop being one of them.  All of these projects have their own branch and release quirks because each project is a different collection of individuals with different motivations and preferences.  This is a feature, not a bug of the Apache community process.  By creating an environment where individuals with disparate motivations can all contribute, projects attract more contributors and more innovation.

CDH has a multi-year history of annual releases, quarterly updates, clear upgrade paths and strong policies around maintaining compatibility and stability across updates.  This has only been possible because the CDH engineering team is comprised of more than 20 engineers that are committers and PMC members of the various Apache projects who can shape the innovation of the extended community into a single coherent system.  It is why we believe demonstrated leadership in open source contribution is the only way to harness the open innovation of the Apache Hadoop ecosystem.

The most current GA release of CDH is CDH3, update 2.  Find out more about it here.

블로그 이미지

Moonistar moonistar

Tag apache, Hadoop

JBoss 서버를 이렇게 저렇게 바꾸고 테스트하다가

어느 순간 부터 아래와 같은 화면이 뜨고 사람을 초조하게 만들었다.

EJB와 Struts 프로젝트에서 저게 딱 떠 있으니, 왠지 심각하진 않아도 거슬려서 다음 작업을 못하겠다는...

수정 방법은 간단하다.

해당 프로젝트의 Properties 에 들어가서 Project Facets 에 들어가서 Runtime 환경을 현재 상황에 맞게 수정해주면 된다.

블로그 이미지

Moonistar moonistar

  • KTB에서는 2010년도 정기시험 계획 일정입니다.
    FL 정기시험: 6회 시행, 2009년과 같이 1,3,5,7,9,11월 격월 주기로 시행
    AL 정기시험: 2회 시행, 상반기 6월, 하반기 12월 예정































* 위 일정은 예정 사항으로 변경 될 수 있습니다.
* AL정기시험은 야간에 장시간 진행되는 점을 고려하여 6월 4일, 12월 3일 금요일로 변경하였습니다.

  • ISTQB 자격증을 보유하고 계신 분들의 공식 까페를 개설하였습니다.

까페명: Certified Peoples

URL: http://www.sten.or.kr/club/club_main.php?cb_id=cb_certpeoples 

가입 방법: STEN 홈페이지에 로그인 후, 해당 까페 URL을 통해 가입신청 하시면 됩니다.

               관리자가 ISTQB 자격증 보유 여부를 확인 후 가입 승인을 하게 됩니다.

블로그 이미지

Moonistar moonistar

1. instsrv.exe 와 srvany.exe 파일을 시스템 디렉토리(C:\Windows) 폴더로 복사

2. 커맨드 창에서 instrv <service_name> srvany.exe 실행

3. 레지스트리를 열어 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service_name> 에서
   Parameter 키 생성

4. Parameters 키에 Application(이름) REG_SZ(종류) 형식으로 문자열 값 생성. 데이터에 실행 시키고자 하는 응용프로그램 Path 입력

5. 서비스에서 <service_name> 속성을 눌러 로그온 탭으로 이동. 다음 계정으로 로그온에서 서비스와 데스크톱 상호 작용 허용 체크

6. 시스템 재부팅후 서비스 제대로 올라오는지 확인

블로그 이미지

Moonistar moonistar

Visual Studio에서 *.sln 파일과 *.vcproj 파일을 제외한 모든 파일들은

서버에 commit 하지 않아도 된다.
블로그 이미지

Moonistar moonistar

1회에선 세 가지 오픈소스 이슈 트래커를 리뷰해 보았죠? 그리고 제가 직접 이슈 트래커를 개발하면서 겪은 고민들을 다른 이슈 트래커들에서는 어떻게 해결하고 있나에 초점을 맞춰 리뷰를 했어요. 그래서 주로 이슈 트래커에 어떤 기능이 어떻게 구현되면 좋은가에 초점을 맞췄죠. 이번엔 조금 다른 각도의 고민들을 이야기해볼까 해요. 이슈 트래커가 팀 작업에서 어떤 역할을 담당하고, 어떻게 활용해야 할 것인가 하는 문제 말이죠. 때때로 이슈 트래커 자체의 기능만으로는 풀 수 없는 문제들이 생기거든요. 지금부터 그런 상황들을 하나씩 보면서 어떻게 풀어내면 좋을지를 이야기해볼 겁니다. 정답을 제시할 수는 없겠지만 이슈 트래커를 사용하는 데 도움이 될 것이라고 생각해요.


할 일 목록과 이슈 트래커의 통합

예전에는 이슈 트래커를 버그 트래커(bug tracker)라 불렀어요. 지난 번에 리뷰한 버그질라(Bugzilla)의 이름도 거기서 나온 거죠. 그 때는 목적이 버그 목록 관리뿐이었거든요. 그런데 버그 트래커를 쓰다보니 기능 개선 요구나 아이디어 제안, 질문 등도 처리해야 했는데 이게 버그는 아니지만 버그와 아주 비슷한 방식으로 관리해야 하는 것들이죠. 그래서 버그 트래커의 기능을 조금만 확장하면 좀 더 범용적인 이슈를 다룰 수 있겠구나 해서 버그 트래커들이 전부 이슈 트래커로 확장된 거랍니다.
이렇게 확장해 쓰다 보면 팀이 해야 할 일의 목록과 이슈 목록이 아주 비슷해집니다. 추가 기능이든 버그 수정이든 개발자가 하는 일은 대부분 이슈 트래커에 올라올 법한 일이죠. 그러다 보니 아예 할 일 목록(to do list) 자체를 이슈 트래커로 관리하면 좋지 않겠냐는 아이디어가 나왔고 그 아이디어를 구현한 것이 지난 번에 소개했던 트랙(trac)입니다. 트랙이 이슈가 아닌 티켓(ticket)이라는 개념을 사용한다고 언급했는데 이건 개념 자체가 바뀌었음을 나타내는 것이죠.
지난 글에서 맨티스(Mantis)나 버그질라는 일반 사용자를 염두에 두고 만든 게 아니라고는 했지만 실제로 모질라 같은 프로젝트에서는 사용자들이 버그를 보고하는 창구로 버그질라를 그대로 사용해요. 이 때 이슈는 사용자가 이슈를 올리는 것에서 라이프사이클이 시작되는 거죠. 하지만 트랙은 좀 더 개발자 중심적이예요. 버그 같은 게 생기면 트랙에서는 개발자가 그 버그에 대한 티켓을 만들어요. 뭔가 할 일이 생기면 전부 티켓으로 만들죠. 그래서 티켓을 모두 완료하면 릴리스를 하게 된답니다.
사실 기존 이슈 트래커도 이렇게 사용할 수 있지만 트랙은 용어부터 이슈 대신 티켓이란 말을 사용하고 로드맵과 연동하도록 만들어서 이슈 트래커를 할 일 목록으로 사용하기 좀 더 좋은 어포던스(affordance)를 주었습니다. 그래서 할 일 목록 관리를 트랙 하나로 통합하게 되죠. 물론 다른 이슈 트래커도 그렇게 쓰게 되는 경우가 많아요. 제가 경험했던 몇몇 팀들도 처음에는 할 일 목록과 이슈 트래커를 따로 쓰다가 목록 두 개를 봐야 하는 일이 번거로워지자 그냥 하나로 통합하기로 결정하고 이슈 트래커에 할 일을 다 관리하는 상황이 되기도 했죠. 트랙 개발자도 아마 이런 현상을 겪었기 때문에 좀 더 적극적으로 통합하도록 유도하기 위해 트랙을 그렇게 만들었을 겁니다.
하지만 경험상으론 이게 좋은 것 같지 않아요. 먼저 정말 모든 할 일이 이슈 트래커로 모을 수 있는 성격이냐 하는 문제가 있습니다. 팀이 하는 일이 늘 개발 업무만 있는 것은 아니죠. 이를테면 디자인 시안을 다시 잡아본다든가, 협업하는 다른 팀과 미팅을 한다든가, 조사를 한다거나 하는 개발 이외의 업무가 늘 있어요. 그럼 이런 일들도 이슈 트래커에 올릴 수 있을까요? 물론 올릴 수야 있겠지만 그렇게 하면 이런 이슈들은 개발하는 소프트웨어의 기능이 아니기 때문에 로드맵에 포함시킬 수도 없고 릴리스 노트(release note)에 넣을 수도 없어요. 뭔가 불일치가 생기기 시작하면 결국은 또 다른 할 일 목록이 생기게 되요.
라이프사이클도 좀 달라요. 할 일 목록은 단순하게 ‘했다’, ‘아니다’만 표기할 수 있으면 되는데 이슈는 몇 가지 단계를 거칩니다. 새로 올라온 이슈를 보고 팀원들이 처리할 것인지 말 것인지를 결정하고 또 처리한다면 누가 맡았는지, 사용자에게 어떻게 피드백을 하는지 등이 다 기록되거든요. 그래서 할 일 목록 관리용으로 이슈 트래커를 쓰기는 좀 무거운 감이 있죠.

의사 소통 문제

하지만 이보다 더 근본적인 문제가 있어요. 이슈 트래커를 할 일 목록 관리로 사용하면 이런 일들이 생깁니다.

  • A: 사용자가 이런 피드백을 보내왔어요.
  • B: 아, 이슈 트래커에 정리해 올려주세요. 나중에 볼께요.
또, 이런 일도 생겨요.
  • A: 지난 번에 이거 말씀드렸죠?
  • B: 이슈 트래커에 없잖아요. 할 일은 전부 거기에 올려주셔야죠.
이렇듯 팀 내 의사 소통을 이슈 트래커가 대체해 버리는 현상이 생기는 거죠. 이건 좋지 않아요. 가장 효율적인 의사 소통은 사람과 사람이 얼굴을 보고 대화하는 거예요. 그런데 이슈 트래커를 공식 채널로 사용하면 사람 대 사람 간의 의사 소통이 점점 줄어들고 자기 일에만 빠져들어 버리죠. 물론 이런 스타일을 선호하는 사람도 있습니다. 뭔가 할 일이 다 정해져 목록에 올라가 있고 그것만 하면 되는 게 편하다는 거죠. 하지만 이런 방식이 팀워크를 해치는 모습을 많이 봐왔어요. 말로 하면 금방 끝났을 일을, 이슈 트래커를 거치면서 의도는 와전되고 댓글에 댓글이 달리면서 감정이 상하기도 하죠. 온라인으로만 의견을 교환하면 필요 이상으로 적대적이 될 때가 많아요. 생각해 보세요. 자기 팀에 공무원처럼 도장 찍고 결재 받아와야만 일을 하겠다는 사람이 늘어나면 어떻게 될까요?
그래서 애자일 방법론 진영에도 소프트웨어로 할 일을 관리하는 것은 좋지 않다는 의견을 제시하는 사람이 많아요. 잘 알려진 사용자 스토리(user story)도 소프트웨어보다는 종이와 펜을 사용해 서로 교감하면서 일을 하기를 권장하죠. 애자일 방법론 중 XP(eXtreme Programming)의 창시자인 워드 커닝햄은 위키조차도 프로젝트 관리용으로 쓰면 팀내 의사 소통을 저해할 수 있다는 이야기를 해요. 위키의 창시자이기도 한데 말이죠.
일의 크기도 문제가 될 수 있어요. 개발을 하다 보면 자잘한 버그가 많이 생기죠? 이를테면 라벨에 오타가 하나 있을 경우 어떻게 하나요? 이슈 트래커에 가서 이슈를 새로 등록하고 담당자를 지정하고 처리되기를 기다린다? 그것보다는 그냥 고칠 수 있는 사람한테 가서 이거 좀 고쳐주세요 하는 게 낫겠죠. 2분 안에 끝날 일이 이슈 트래커를 거치면 하루짜리 일이 될 수 있어요.
사용자 스토리를 사용할 때도 이슈 트래커의 역할이 애매해져요. 사용자 스토리에서는 일의 단위로 스토리를 사용해요. 기능에 대해 좀 두루뭉술하게 서술한 것이고 이걸 작업 단위로 삼죠. 보통 스토리 카드를 이용해 관리하는데, 카드를 쓰면 여러 가지 장점이 있어요. 쉽게 쓰고 버릴 수 있죠. 그래서 스토리를 쪼개거나 합치거나 분류하거나 하는 일이 쉬워요. 팀원들이 다 같이 작업하기도 좋구요. 하지만 컴퓨터 위에서는 그 정도로 쉽지 않습니다. 협업하기도 어렵고 여러 개의 아이템을 동시에 다루는 것도 어렵죠. 컴퓨터가 글쓰기는 더 애자일하게 만들어주었지만 목록 관리는 여전히 종이와 펜이 더 빠른 것 같아요.
그럼 반대로 이렇게 물을 수도 있겠죠. "사용자의 피드백도 그냥 종이와 펜으로 관리하면 되지 않은가?" 하구요. 그런데 보통 사용자의 요청은 기록이 남아야 하고 변경 관리가 되어야 해요. 처리되었으면 되었다고 알려줘야 하고 처리하지 않는다면 그 이유를 알려줘야 하죠. 사용자가 클레임(claim)을 제기할 때를 대비해 기록도 남아 있어야 합니다. 사용자가 개발팀으로 찾아올 수 있는 경우가 많지 않기도 하죠. 기록이 남아야 하는 문제는 역시 컴퓨터로 하는 게 좋고 변경 관리까지 해야 한다면 이슈 트래커를 쓰는 게 편하겠죠.


어떤 식으로 통합할 것인가

그래도 여전히 문제는 남습니다. "그럼 결국 목록 두 개를 관리하는 것인가?" 하는 문제 말이죠. 분명히 통합해서 보고 싶은 욕구가 있고 이 욕구를 불합리하다고 할 수는 없어요. 그럼 어떻게 해결할 수 있을까요? 아직 뾰족한 해답은 없지만 몇 가지 제시는 할 수 있을 것 같아요.

일일 회의에서 이슈 리뷰하기

많은 팀에서 매일 아침에 일일 회의를 합니다. 애자일 방법론에서 이야기하는 ‘daily standup meeting’을 생각하면 되요. 어제 무슨 일이 있었는지, 그리고 오늘 무슨 일을 할 것인지를 이야기하는 거죠. 이 때 전날 올라왔거나 변경된 이슈들을 뽑아서 하나씩 같이 이야기하면 좋아요. 이야기하다 보면 자연스럽게 이슈를 어떤 식으로 처리할지에 대해 의견을 교환할 수 있죠. 간단한 일이면 바로 처리할 수도 있을 테니 굳이 목록에 관리할 필요가 없고 좀 오래 걸리는 일이면 스토리 카드에 써서 벽에 붙여서 다른 스토리와 같이 관리할 수도 있고요.

할 일 목록에 이슈 트래커를 통합

이슈 트래커에서 할 일 목록을 관리하는 것이 부작용을 낳는다면 그 반대는 어떨까요? 위에서 언급한 것처럼 일일 회의에서 이슈를 리뷰하고 스토리 카드에 쓰는 식도 부작용이 있을까요? 경험상으로 의사 소통에 큰 부작용은 없었어요. 이슈 트래커는 아침에만 보고 바로 할 일 목록으로 전환되니까 목록을 두 개 봐야 하는 필요성도 없어졌구요. 다만, 일을 끝냈을 때 이슈 트래커에 가서, 보고했던 사용자에게 알려주는 일을 잊어 버리는 경우가 종종 생겼습니다. 그래서 스토리 카드를 쓸 때 이슈 트래커에서 온 것이라는 것을 표시하는 관례를 만들었는데 약간 번거롭지만 이 문제는 해결이 되었어요.
하지만 또 다른 문제가 있었어요. 바로 스토리와 이슈가 일의 크기와 일을 서술하는 세밀함(granulity)이 다르다는 점입니다. 스토리는 보통 작게 잡아도 하루, 보통 3일 정도 걸리는 일이 많지만 이슈는 그렇지 않아요. 큰 일도 가끔 있지만 대부분 몇 시간 안에, 혹은 몇 분 안에 해결할 수 있는 일이죠. 그러다 보니 같은 등급으로 관리하기가 좀 이상하고 스토리 기반 작업 시간 추정에도 오차를 만들어냅니다. 그래서 이슈 여러 개를 묶어 스토리 하나로 처리해 보기도 하고 별도로 작은 이슈 처리만 하는 시간을 정해보기도 했어요. 둘 다 효과가 약간은 있었지만 문제를 완전하게 해결하지는 못하더군요. 하지만 의사 소통 문제에 비하면 이 정도는 작은 문제죠. 사실 이런 크기 차이는 그냥 인정하고 하나로 통합해 가면 크게 문제가 되지는 않아요.

스토리를 소프트웨어로 관리하는 경우

스토리를 소프트웨어로 관리하면 부작용이 생긴다고 했지만 사실 어쩔 수 없이 소프트웨어로 쓰게 되는 경우가 생겨요. 위(?)에서 그렇게 하라고 정해버렸다든지, 혹은 팀원이 멀리 떨어져 있는데 협업을 해야 한다든지, 무슨 일을 했는지에 대한 업무 보고를 상세하게 써야 한다든지 하는 경우죠. 이 때는 그냥 위와 같은 방법으로 할 수도 있긴 하지만 이왕 소프트웨어를 쓰는 건데, 좀 더 편하게 할 수 있는 방법을 생각해볼 필요가 있어요.
요즘 OpenAPI를 이용해 매시업을 하는 게 유행처럼 번지고 있는데 이걸 여기서 활용할 수 있어요. 이슈 트래커들이 API를 제공하는 경우가 별로 없지만 대부분 약간만 손보면 API처럼 사용할 수 있어요. 그래서 이슈 트래커에서 최근 목록을 긁어와 할 일 목록에 통합해 보여주도록 약간만 코딩을 하면 할 일 목록 뷰에서 다 같이 볼 수가 있어요. 그래서 할 일 목록에서 완료 표시를 하면 자동으로 이슈 트래커에서 해결 상태로 바꾼다든지 하는 정도의 기능만 넣으면 쉽게 통합해 쓸 수 있죠.

용어 정의하고 공유하기

너무 무거운 이야기를 길게 끌어온 것 같아 이번엔 좀 가벼운 이야기를 해보겠싑니다. 팀에서 이슈 트래커를 사용하다 보면 용어 문제로 충돌이 생기기도 해요. 팀에서 맨티스를 쓸 때 이런 일이 있었어요. 어떤 사람이 이슈를 읽고 나서 자기가 확인했다는 의미에서 확인된 이슈로 상태를 바꿔놨어요. 그런데 다른 사람은 확인된 이슈를 앞으로 하기로 결정된 일이라 생각해 버리고, 할지 안 할지 결정이 아직 안 됐는데 그 일을 처리하고 반영해 버렸어요. 그래서 문제가 생겼죠. 이런 일을 막으려면 미리 용어들을 잘 정해 놓아야 해요. 특히 이슈 상태가 뭘 의미하는지를 잘 공유해야 해요. 이슈 트래커마다 상태에 대해 사용하는 용어와 의미가 조금씩 다르죠. 예를 들어 맨티스는 상태도 있고 처리 상태도 있어 더 헷갈리죠. 이런 경우 팀이 용어에 대해 어떤 의미로 사용할지 충분히 공유를 해야 해요.
마찬가지로 분류에 대해서도 합의해야 해요. 분류도 의사 소통 오류가 많이 생기거든요. 사람마다 각자 자기 마음대로 분류할 수 있게 하면 같은 의미인데 분류가 두 개 생기거나 하나의 분류인데 서로 다른 의미로 사용하거나 하는 경우가 생겨요. 이슈 개수가 늘어나면 분류가 필수인데 이렇게 불일치가 생기면 분류를 신뢰할 수 없게 되어 버리죠. 그래서 이슈 트래커에서 접하는 용어들은 전부 팀 내에서 공유하는 게 좋아요.

이슈는 어떻게 할당할 것인가

이 문제는 작업 할당에 대한 문제이기도 해요. 일반적으로 이슈 관리자가 있으면 이슈 관리자가 읽고 다른 팀원에게 할당해주는 경우가 많죠. 그럼 개발자들은 자기에게 할당된 이슈만 보고 작업하고요. 하지만 지난 회에서 언급했듯이 이런 구조는 부작용이 많아요. 이슈 관리자가 모든 팀원들이 어떤 일을 하는지 정확히 알아야 하는데 그렇지 못할 때가 많아 부적절한 사람에게 할당하기도 하거든요. 제대로 할당하려면 어차피 의사 소통을 한 번 거쳐야 해요. 그럴 바에는 아침 일일회의 때 이슈를 한 번 공유하고 그 자리에서 이야기하는 게 더 좋죠. 그리고 그 이슈를 가장 잘 처리할 수 있는 사람은 본인이 제일 잘 알게 마련입니다. 그래서 누군가가 일을 할당해 주는 식보다는 스스로 일을 가져갈 수 있게 유도하는 것이 좋고요.



기존 오픈소스 이슈 트래커를 써보고 또 직접 개발한 이슈 트래커를 다른 사람에게 써보게 하기도 했는데 그러면서 사람들이 이슈 트래커라는 시스템에 갇히기 쉬운 것 같다고 느꼈습니다. 무슨 일이든 자꾸 이슈 트래커 안에서 해결하려고 하죠. 그러다 보면 위에서 살펴본 것처럼 여러 가지 부작용이 생겨요. 가서 그냥 말 한 마디 하면 해결될 일인데 시스템에다 올려놓고 왜 안 해주냐고 투덜거리죠. 기능적으로도 그래요. 다른 소프트웨어와 조금만 조합하면 쉽게 풀 수 있는 문제를 전부 이슈 트래커의 기능으로 커버해야 한다고 생각할 때가 많아요. 저 역시 그런 함정에 빠지곤 합니다. ECUS에는 검색 조건 저장 기능이 있습니다. 그런데 사실 알고 보면 검색 조건이 URL에 반영되기 때문에 즐겨찾기만 해놔도 해결할 수 있는 문제였어요. 그런데 거기까지 생각하지 못하고 기능으로 넣어버린 거죠. 그랬더니 그렇게 저장한 검색 조건을 다른 팀원과 공유할 수 있게 해달라고 하더라고요. 이것도 그냥 URL 복사해주면 되는 건데 말입니다. 물론 UI의 편의성이라든지 하는 문제는 있겠지만 어쨋든 사람들이 시스템에 갇히는 모습 중 하나인 것 같아요. 이런 점을 극복하고 다른 소프트웨어나 다른 도구, 방법과 잘 조화시켜 사용하면 훨씬 편하게 이슈 트래커를 쓸 수 있어요. 그리고 위에서 살펴본 문제들, 잘 보면 알겠지만 대부분 의사 소통 문제입니다. 이슈 트래커 자체가 의사 소통 도구인데 이걸 이슈 목록 관리로만 보면 의사 소통 문제들이 생기는 것 같아요. 시스템이 의사 소통을 도와줄 수는 있어도 대신해줄 수는 없습니다. 어떤 시스템이든 그걸 사용하면서 의사 소통에 장애가 생기기 시작한다면 사용 방법을 바꿔보는 것이 좋아요. 저도 이런 문제를 많이 겪었어요. 모든 작업 흐름(workflow)의 시스템화를 외치는 팀장 때문에 전부 그룹웨어에 통합해 써보기도 했고 또 일마다 그 성격에 맞는 도구를 써야 한다며 대여섯 개의 도구가 난립하기도 했죠. 이슈 트래커를 쓰면서 의사 소통 단절이 생기니까 다른 걸로 바꿔보자면서 계속 새로운 도구만 찾아다기도 했고요. 하지만 대개 문제는 시스템 자체보다 그 시스템을 어떻게 사용하느냐에 있었어요. 시스템을 지혜롭게 사용하는 방법을 배우면서 시스템 자체의 문제까지 극복하기도 했구요. 더 좋은 이슈 트래커를 찾기 위해 소스포지를 뒤지고 개발해 보고 하는 것도 좋지만 오늘은 이슈 트래커를 잘 사용하는 방법에 대해 팀원들끼리 이야기를 해보는 것이 어떨까요?

   소셜 북마크

   mar.gar.in mar.gar.in
    digg Digg
    del.icio.us del.icio.us
    Slashdot Slashdot

기존 오픈소스 이슈 트래커를 써보고 또 직접 개발한 이슈 트래커를 다른 사람에게 써보게 하기도 했는데 그러면서 사람들이 이슈 트래커라는 시스템에 갇히기 쉬운 것 같다고 느꼈습니다. 무슨 일이든 자꾸 이슈 트래커 안에서 해결하려고 하죠. 그러다 보면 위에서 살펴본 것처럼 여러 가지 부작용이 생겨요. 가서 그냥 말 한 마디 하면 해결될 일인데 시스템에다 올려놓고 왜 안 해주냐고 투덜거리죠.
기능적으로도 그래요. 다른 소프트웨어와 조금만 조합하면 쉽게 풀 수 있는 문제를 전부 이슈 트래커의 기능으로 커버해야 한다고 생각할 때가 많아요. 저 역시 그런 함정에 빠지곤 합니다. ECUS에는 검색 조건 저장 기능이 있습니다. 그런데 사실 알고 보면 검색 조건이 URL에 반영되기 때문에 즐겨찾기만 해놔도 해결할 수 있는 문제였어요. 그런데 거기까지 생각하지 못하고 기능으로 넣어버린 거죠. 그랬더니 그렇게 저장한 검색 조건을 다른 팀원과 공유할 수 있게 해달라고 하더라고요. 이것도 그냥 URL 복사해주면 되는 건데 말입니다.
물론 UI의 편의성이라든지 하는 문제는 있겠지만 어쨋든 사람들이 시스템에 갇히는 모습 중 하나인 것 같아요. 이런 점을 극복하고 다른 소프트웨어나 다른 도구, 방법과 잘 조화시켜 사용하면 훨씬 편하게 이슈 트래커를 쓸 수 있어요.
그리고 위에서 살펴본 문제들, 잘 보면 알겠지만 대부분 의사 소통 문제입니다. 이슈 트래커 자체가 의사 소통 도구인데 이걸 이슈 목록 관리로만 보면 의사 소통 문제들이 생기는 것 같아요. 시스템이 의사 소통을 도와줄 수는 있어도 대신해줄 수는 없습니다. 어떤 시스템이든 그걸 사용하면서 의사 소통에 장애가 생기기 시작한다면 사용 방법을 바꿔보는 것이 좋아요.
저도 이런 문제를 많이 겪었어요. 모든 작업 흐름(workflow)의 시스템화를 외치는 팀장 때문에 전부 그룹웨어에 통합해 써보기도 했고 또 일마다 그 성격에 맞는 도구를 써야 한다며 대여섯 개의 도구가 난립하기도 했죠. 이슈 트래커를 쓰면서 의사 소통 단절이 생기니까 다른 걸로 바꿔보자면서 계속 새로운 도구만 찾아다기도 했고요. 하지만 대개 문제는 시스템 자체보다 그 시스템을 어떻게 사용하느냐에 있었어요. 시스템을 지혜롭게 사용하는 방법을 배우면서 시스템 자체의 문제까지 극복하기도 했구요. 더 좋은 이슈 트래커를 찾기 위해 소스포지를 뒤지고 개발해 보고 하는 것도 좋지만 오늘은 이슈 트래커를 잘 사용하는 방법에 대해 팀원들끼리 이야기를 해보는 것이 어떨까요?

블로그 이미지

Moonistar moonistar

필자는 최근 회사에서 이슈 트래커를 개발하는 일을 맡았습니다. 그 전에는 맨티스(Mantis)라는 오픈 소스 이슈 트래커를 사용했는데 여러 가지로 만족스럽지 않아 개선 방안을 찾다가 그냥 새로 만들어 보기로 한 것이죠. 물론 기존에 이미 나와 있는 다른 이슈 트래커들도 고려해 봤어요. 오픈 소스 이슈 트래커 중 가장 유명한 버그질라(Bugzilla)를 비롯해 상용 제품 중 가장 널리 쓰이는 Jira, 요즘 프로그래머들 사이에서 인기를 끄는 트랙(trac)까지 대략 10여 종의 이슈 트래커를 평가해 보았는데 어느 것도 팀의 요구를 만족시킬 수 없었어요.

기능이 부족해 그런 것이 아니었습니다. 사실 그 반대였죠. 이런 소프트웨어들은 기능이 너무나 막강해 사용하기 어렵더라고요. 필자가 속한 팀에 필요한 것은 단지 사용자들이 버그를 쉽게 등록하고 그것들을 개발자들이 쉽게 조회하는 것뿐이었거든요. 그래서 기능 측면보다 사용성에 최우선을 두고 새로 만들어 보기로 하고 프로젝트 이름도 ECUS(Engineer and Customer's Understanding and Satifaction)라고 지었어요. 기존 이슈 트래커가 엔지니어에게만 초점을 맞추고 있었다면 이제 고객(customer)에게도 초점을 맞추자는 의도를 나타낸 것이죠.

이 연재에서는 이런 경험에 비추어 여러 이슈 트래커를 살펴보겠습니다. 비교해볼 대상은 트랙, 맨티스, 버그질라 세 가지로 가장 널리 쓰이고 높은 평가를 받는 것들입니다. 단, 단편적인 비교 분석은 지양하고 이슈 트래커 개발 과정에서 필자가 고민했던 문제들을 다른 이슈 트래커들은 어떻게 풀어냈는지, 그리고 ECUS 프로젝트에서는 어떤 대안을 제시하는지에 초점을 맞춰볼 거에요. 물론 ECUS 프로젝트가 리뷰에 포함되기 때문에 필자가 균형 감각을 잃을 위험이 있지만 이슈 트래커에 대한 고민을 보여주려면 결국 ECUS 팀에서 선택한 대안도 보여주는 것이 더 효과적일 것이라 생각합니다.

이슈 트래커는 그 자체의 기능적 특성들을 이해하는 것도 중요하지만 이슈 트래커를 어떻게 사용할 것인지에 대한 문제를 이해하는 것도 중요해요. 프로젝트에서 어떤 역할을 담당하게 할 것인지, 다른 프로젝트 관리 도구들과는 어떻게 조화시킬 것인지, 팀내 커뮤니케이션은 어떻게 할 것인지 등이 제대로 정립되지 않으면 때때로 이슈 트래커가 부정적인 영향을 미치기도 하거든요. 그래서 다음 회에는 이런 부분에 대한 고민을 다뤄보겠습니다.


사용자 모델링과 권한 체계

ECUS 개발에는 XP(eXtreme Programming) 방법론을 적용했어요. XP에서는 보통 사용자 스토리(user story)를 뽑아내는 것으로 시작하는데 그 첫 단계가 사용자 모델링이죠. ECUS 팀에서는 사용자 모델링에서 세 가지 역할을 찾아냈습니다. 먼저 버그나 제안을 등록하는 역할을 일반 사용자로, 버그를 읽고 담당자에게 전달하며 보고한 사람에게 피드백하는 사람을 관리자로 정했어요. 마지막은 실제 이슈를 처리하는 개발자고요. 이렇게 사용자 역할을 나누니 사용자 스토리도 비교적 쉽게 나오더군요.

그런데 사용자 스토리를 이리저리 분류하다 보니 관리자와 개발자를 분리하는 것이 의미가 없겠다는 생각이 들었습니다. 이전에 몇몇 프로젝트에서 나타난 현상인데 이슈 관리자를 별도로 두면 개발자들은 이슈가 올라와도 읽지 않고 관리자가 계속 재촉하거나 할당해야만 읽더라고요. 그러다 보면 개발자는 점점 사용자의 목소리에서 멀어졌고요. 물론 개발에 전념한다는 핑계를 대긴 하지만 필자가 일하는 회사처럼 웹 서비스를 하는 회사에서는 개발자도 고객의 요구를 민감하게 느껴야 한다고 생각해요. 게다가 관리자 역할을 따로 배정하면 그 사람은 어떻게 보면 계속 잡무만 하는 셈이죠. 팀에서 잡일꾼으로 취급 받는 사람이 버그 보고에 즐겁게 응대하기는 어렵겠죠? 그래서 결국 사용자의 역할을 두 가지로 압축했습니다. 관리자 역할은 개발자의 역할도 포함한다고 보고 일반 사용자와 관리자 두 가지로 나눈 것이죠.

사용자의 역할을 두 가지로만 분류하니 권한 모델도 단순해졌습니다. 그래서 관리자는 모든 권한을 다 가질 수 있게 됐죠. 그런데 실제 적용 중에 문제가 생겼어요. 외부 업체와 협업을 하다 보니 외부 업체 사람들이 협업하는 프로젝트의 이슈를 관리할 수 있어야 하는데 그 사람이 우리의 다른 프로젝트까지 보면 안 되는 상황이 생긴 것입니다. 그래서 사이에 한 단계를 더 놓기로 하고 관리자(Adminitrator)의 권한을 한 프로젝트에 대해서만 가질 수 있는 서비스 운영자(Service Manager)를 두었고 이것이 ECUS의 권한 체계로 확립됐습니다.

맨티스는 ‘권한을 볼 수만 있음’, ‘보고 가능’, ‘갱신 가능’, ‘개발자’, ‘매니저’, ‘관리자’ 여섯 가지로 구분합니다. 그리고 프로젝트별로 다른 권한을 줄 수 있죠. 프로젝트 A는 볼 수만 있는데 프로젝트 B는 매니저 권한을 가진다든가 하는 게 가능해요. 그래서 좀 더 세밀하게 조정할 수 있지요(그런데 예전에 맨티스를 쓸 때 보니 그냥 팀원 전부를 다 관리자로 놓고 쓰게 되더군요).

버그질라는 권한 모델이 좀 더 체계적입니다. 사용자를 모아 그룹으로 설정하고 그룹별로 권한을 줄 수 있어요. 사실 이건 ECUS에서 아쉬운 점이기도 합니다. 가끔 사용자 여러 명에게 권한을 줘야 하는 일이 생기잖아요. 버그질라에서는 해당 사용자를 이미 만들어진 그룹에 넣기만 하면 다 똑같은 권한을 줄 수 있는데 ECUS에서는 하나하나 바꿔줘야 하거든요. 그리고 버그질라에서는 권한도 상당히 세분화되어 있어서 이슈를 만드는 권한, 편집하는 권한, 프로젝트를 만드는 권한 등 거의 모든 기능 단위별로 권한을 조정할 수 있어요. 트랙도 비슷하구요. 그래서 버그질라나 트랙을 쓰면 원하는 대로 다 설정할 수 있습니다. 물론 그만큼 어렵지만요.

사실 ECUS처럼 권한 모델을 단순화할 수 있는 것은 아직 필자가 일하는 조직이 100명도 안 되는 작은 조직이기 때문일 겁니다. 조직이 좀 더 커지고 복잡해지면 그만큼 복잡한 권한 체계가 필요해지고 트랙이나 버그질라의 그룹 기반 권한 체계가 부러워질지도 모릅니다. 하지만 아직은 YAGNI(You aren't gonna need it!)!라고 결론을 내려버려도 될 것 같군요.


이슈 등록

이슈 트래커에서 가장 중요한 과정은 아무래도 이슈를 등록하는 과정이라 할 수 있습니다. ECUS 팀에서 다른 이슈 트래커를 포기했던 이유이기도 해요. 먼저 버그질라의 버그 등록 화면을 보세요(그림 1). 뭔가 어지럽죠. 필자도 버그질라에서 버그 보고를 하려다 이 화면을 보고 당황해 포기했던 적이 있습니다. 사실 저렇게 많은 항목이 모두 필수는 아니고 제목과 내용만 필수요소죠. 하지만 UI가 그런 느낌을 주지 않기 때문에 지레 겁먹고 버그 보고를 포기하는, 필자처럼 소심한 사용자가 많은 것 같습니다.

버그질라의 버그 등록 화면
그림 1. 버그질라의 버그 등록 화면

맨티스는 일단 한국어 번역이 있으니 좀 나은 것 같긴 한데 여전히 좀 복잡합니다(그림 2). 트랙은 이보다는 훨씬 쉽고요. 다른 이슈 트래커와는 달리 이슈가 아니라 티켓(ticket)이라는 용어를 사용한다는 점이 조금 걸리긴 한데 복잡한 속성들을 밑으로 끌어내려 놓아 꼭 입력하지 않아도 된다는 느낌을 주고 위지윅 편집기도 붙어 있어 좀 더 쉽게 쓸 수 있는 것 같습니다(그림 3).

맨티스의 버그 등록 화면
그림 2. 맨티스의 버그 등록 화면

트랙의 버그 등록 화면
그림 3. 트랙의 버그 등록 화면

ECUS는 이보다 조금 더 단순하게 만들었어요. 사용자가 그냥 게시판에 글 쓰는 기분으로 쓸 수 있도록 제목과 내용, 첨부 이외의 항목들은 모두 뺐고 관리자가 상태나 우선순위 같은 걸 설정하고 싶을 때도 글 쓸 때부터 하는 게 아니라 글 쓰고 나서 하도록 만들었습니다(그림 4). 그래서 사용자들이 좀 더 편하게 글을 쓰는 것 같습니다(하지만 팀내 개발자들은 글 쓰면서 바로 우선순위 같은 항목을 지정하고 싶다고 불평을 하고 있긴 해요).

ECUS의 버그 등록 화면
그림 4. ECUS의 버그 등록 화면


이슈 찾기

맨티스나 버그질라를 쓰면서 제일 어려웠던 점이 바로 이슈를 찾는 것이었습니다. "어, 그 때 그 이슈 어디 갔더라"부터 "현재 검토하지 않은 이슈들을 찾고 싶어"라든지, "작업 중인 것들을 우선순위대로 보고 싶어"처럼 다양한 조건으로 이슈를 찾아야 하는 경우가 생기거든요. 그래서 이슈를 쉽게 찾는 것도 중요하지만 조금 어렵더라도 원하는 작업을 할 수 있는 게 중요합니다.

먼저 맨티스를 보죠(그림 5). 단순 필터 화면인데 사실 고급 필터를 눌러도 항목은 똑같습니다. 다만 각 항목에서 선택의 자유도가 좀 더 높아집니다. 예를 들면 상태의 경우 단순 필터에서는 새로운 이슈만 본다거나, 해결된 이슈는 제외한다거나 하는 건 가능하지만 폐쇄된 이슈와 검토 중인 이슈만 본다거나 하는 복잡한 조합은 불가능한데 고급 필터에서는 이것이 가능해요. 항목이 너무 많다보니 어지러운 감이 있는데 실제로 사용하는 항목은 얼마 되지 않고 이슈 상태, 우선순위, 할당 정도죠. 가끔 날짜로도 검색하고요. 다행히 맨티스에는 선택한 검색조건을 저장하는 기능이 있어 필터 저장 버튼을 누르면 현재 검색조건이 저장됩니다.

맨티스의 이슈 찾기
그림 5. 맨티스의 이슈 찾기

ECUS도 맨티스의 필터를 출발점으로 삼았습니다. 단순 필터와 고급 필터가 항목은 같고 인터페이스만 다른데 자바스크립트를 잘 활용하면 하나로 잘 합칠 수 있을 것 같더군요. 그리고 실제로 쓰지 않는 항목들은 모두 과감하게 제거하기로 하고 그림 6과 같은 인터페이스를 만들었습니다. 검색조건은 필요 없는 경우는 접어둘 수도 있고요. 맨티스의 필터 저장 기능도 그대로 가져왔고 덧붙여 기본적으로 많이 쓸 것 같은 조건을 바로가기로 만들었습니다. 내가 쓴 글이나 나에게 할당된 글 같은 경우는 따로 검색조건을 열 필요 없이 바로 찾을 수 있죠. 이 기능은 일반 사용자 입장에서도 필요한 기능이에요. 사용자는 자기가 올렸던 글이 어떻게 처리되고 있는지를 보고 싶어하거든요.

ECUS의 이슈 찾기
그림 6. ECUS의 이슈 찾기

버그질라는 단순 검색과 고급 검색이 완전히 분리되어 있습니다. 단순 검색에서는 상태와 제품, 검색어만으로 검색하지만 고급 검색은 아래 그림처럼 모든 필드를 다 검색할 수 있죠. 검색하면 다음과 같은 화면이 나옵니다. 나름대로 두 가지 요구를 모두 만족시킬 수 있는 실용적인 대안이죠.

버그질라의 이슈 찾기

버그질라의 이슈 찾기
그림 7. 버그질라의 이슈 찾기

하지만 한 가지 단점은 검색된 결과를 보는 화면과 검색조건을 입력하는 화면이 분리되어 있어 검색 결과가 맘에 들지 않을 땐 다시 뒤로 돌아가 검색해야 한다는 것입니다. 페이징이 안 되어 검색된 이슈가 많을 경우에는 속도가 엄청나게 느리다는 것도 문제구요. 이 점 때문에 예전에 맨티스와 버그질라를 비교하다 맨티스를 선택했던 거에요.

트랙은 좀 색다른 접근 방식을 취하고 있습니다. 앞서 언급했듯 트랙에서는 이슈를 티켓이라 부르는데 View Ticket 화면을 처음 누르면 ECUS의 바로가기 같은 것들이 뜨고요. 이미 정의된 많은 조건이 링크로 저장되어 있어 누르면 바로 볼 수 있어요.

이 바로가기 조건이 맘에 들지 않으면 Custom Query를 눌러 조건을 직접 지정할 수 있습니다. 검색조건의 오른족 아래에서 add filter 버튼을 누르면 검색조건을 추가할 수 있지요. 제목이나 내용으로 검색할 수도 있고 담당자라든지 티켓의 모든 필드를 검색조건에 넣을 수 있고요. 트랙의 방식도 나름대로 단순 검색과 고급 검색의 필요성을 꽤 실용적으로 만족시켰다고 할 수 있지만 버그질라와 마찬가지로 검색과 관련된 화면이 세 가지라는 점은 다소 걸림돌이 되기도 합니다.


이슈 처리 과정

이슈를 등록하고 찾았으면 이제 해당 이슈에 대한 작업을 해야 하죠. 이슈를 읽고 답글을 달거나, 상태를 변경하고 우선순위를 변경하는 등 다양한 작업이 있어요. 일단 이 중에 제일 중요한 상태 변경 작업만 살펴보겠습니다. 맨티스는 이슈를 보는 화면과 수정하는 화면이 그림 8과 같이 분리되어 있는데 이슈를 보는 화면에서는 이슈에 대한 상세한 내용은 수정할 수 없지만 대신 할당이라든지 상태 변경 같은 작업은 할 수 있습니다. 그래서 실제로 등록된 이슈의 내용을 수정하는 경우가 아니면 이슈 수정화면은 거의 열 필요가 없어요. 하지만 변경 작업을 할 때 코멘트를 입력하는 화면으로 넘어가기 때문에 실질적으로 작업이 한 화면에서 일어나진 않죠. 버그질라도 맨티스와 비슷하구요(그림 9).

맨티스의 이슈 보기 화면과 수정 화면

맨티스의 이슈 보기 화면과 수정 화면
그림 8. 맨티스의 이슈 보기 화면과 수정 화면

버그질라의 이슈 수정 화면
그림 9. 버그질라의 이슈 수정 화면

트랙은 특이하게 이슈 보기와 수정이 한 화면에 붙어 있습니다. 기능적으로 합쳐진 게 아니라 말 그대로 그냥 붙어 있죠(그림 10). 그래서 그냥 볼 때는 별 불편함이 없지만 상태 변경 같은 걸 할 때는 웬지 고치면 안 되는 항목도 같이 고쳐버리는 실수를 할까봐 불안한 느낌이 들더군요. 한 화면으로 모은 점이 장점일 수도 있긴 하지만 맨티스보다 더 어려운 느낌이 듭니다.

트랙의 이슈 보기와 수정 화면

트랙의 이슈 보기와 수정 화면
그림 10. 트랙의 이슈 보기와 수정 화면

ECUS는 맨티스와 비슷합니다. 상태 변경이나 우선순위 변경 등 메타 정보 변경은 보기 화면에서 하고 본문을 수정할 때는 수정 화면으로 가죠. 각종 변경 작업을 할 때는 Ajax를 써서 다른 화면으로 넘어가지 않도록 했어요. 그래서 맨티스보다는 조금 더 편해진 면도 있지만 여전히 항목들이 아래 위로 퍼져 있어서 어지러운 감이 있는 점이 아쉽습니다.

ECUS의 이슈 보기와 수정 화면
그림 11. ECUS의 이슈 보기와 수정 화면


중복된 이슈 다루기

이슈 트래커에서 또 하나 골치아픈 문제가 바로 중복된 이슈입니다. 이슈를 등록하는 사람은 대개 프로젝트팀 외부에 있는 경우가 많다 보니 현재 어떤 이슈가 올라와 있는지에는 관심이 없거든요. 그러니 같은 이슈라도 계속 등록해요. 따라서 이런 문제를 효과적으로 처리할 수 있는 장치가 필요하고요. 이 문제에 대한 처리 방식은 맨티스나 버그질라, 트랙이 모두 비슷합니다. 이슈를 중복된 이슈로 설정하고 같은 내용을 담은 원래 이슈 번호를 기록하게 하는 거죠. 그리고 그 이슈는 닫고 원래 이슈만 계속 다루고요.

그런데 ECUS는 일반 사용자도 써야 하는 시스템이라서 이렇게 할 수 없었습니다. 일반 사용자가 불만사항을 담은 글을 올렸는데 같은 문제를 다른 사람이 올렸다고 해서 새로 올린 사람한테 다른 글에 가서 보라고 하면 불친절하다고 느끼므로 개별적으로 답을 해야 합니다. 또 완전히 중복된 건 아니라고 해도 약간씩 연관된 이슈가 올라오는 경우도 있는데 이런 경우는 버그질라 방식으로 처리할 수 없죠. 그래서 글을 서로 연관 짓는 기능을 만들었습니다. 그림 12에서 연관글 버튼을 누르면 작은 창이 뜨는데 거기서 비슷한 이슈를 찾아 연관글로 지정하는 것입니다. 그럼 두 이슈가 서로 연관되어 어느 쪽 글에서 보든 다른 글이 연관글로 보이죠. 이렇게 연관글 창에서 연관된 글들을 모아 하나하나 보면서 상태를 변경하거나 답글을 달 수 있습니다.

ECUS에서 중복 이슈 처리

ECUS에서 중복 이슈 처리
그림 12. ECUS에서 중복 이슈 처리

그러다가 아예 중복된 이슈가 적게 올라오게 만들면 더 좋지 않을까 하는 생각이 문득 들었어요. 글을 쓸 때 쓰는 내용과 비슷한 내용을 미리 검색해 화면 오른쪽에 보여주면 사용자가 같은 내용을 올리려다가 이미 있는 글에 가서 답글을 달거나 추천을 할 수 있겠죠. 그러면 사용자는 글을 쓰는 수고는 적게 하면서 자신의 의사를 전달할 수 있고 관리자는 더 적은 이슈를 관리해도 되므로 편해질 것이고요.



이슈 트래커는 원래 버그 트래커(Bug Tracker)에서 출발했습니다. 즉 소프트웨어 버그 목록을 관리하는 도구였던 것이죠. 그런데 사용하다 보니 꼭 버그라고는 부를 수 없지만 비슷하게 관리해야 하는 이슈들이 생겼고 그래서 아예 폭을 좀 넓혀 이슈 트래커라고 하고 기능을 약간 확장한 것입니다. 맨티스나 버그질라도 처음엔 버그 트래커라고 불렀지만 이제는 이슈 트래커라 부릅니다. 트랙은 아예 처음부터 이슈 트래커를 지향하고 출발해 티켓이라는 용어까지 정착시켰고요. 이렇게 범위를 확장하다 보니 이슈 트래커가 프로젝트 관리 도구 비슷하게 되어갔습니다. 버그가 할 일(To do)의 일종인데 이걸 확장해 이슈라고 하니까 아예 할 일 목록(To do list)을 통째로 관리해도 되지 않겠느냐 하는 생각을 한 것이죠. 그래서 로드맵(roadmap)이라는 기능이 들어가게 됐습니다. 다음은 맨티스의 로드맵 기능입니다. 목표한 릴리스에 포함될 이슈들을 지정하면 릴리스 스케쥴링을 할 수 있어요.

맨티스의 로드맵 기능
그림 13. 맨티스의 로드맵 기능

트랙에도 이 기능이 잘 통합되어 있죠. 트랙은 처음부터 프로젝트 관리 기능을 다 담을 목적이었거든요.

트랙의 로드맵 기능
그림 14. 트랙의 로드맵 기능

하지만 애자일 방법론을 사용하는 팀에서 ECUS를 사용할 것이라 가정했기 때문에 로드맵 기능은 넣지 않았습니다. XP에서는 보통 프로젝트 관리나 할 일 관리로 소프트웨어 도구보다는 종이나 펜, 화이트보드 등 오프라인 도구를 더 많이 활용하니까요. 그래서 ECUS는 고객과의 커뮤니케이션에만 집중하도록 역할을 부여한 거죠. 팀이 지리적으로 분산된 경우라든가, 혼자 작업하는 경우라면 트랙 같은 시스템이 더 편리할 수 있을 겁니다.



지금까지 오픈 소스 이슈 트래커 세 가지를 리뷰해 보면서 ECUS와 비교해 봤습니다. 사실 이슈 트래킹 기능만으로는 세 가지 모두 별로 부족함이 없죠. 하지만 ECUS를 만들게 된 이유에서 알 수 있듯이 인터페이스, 사용성에 있어서는 개선할 여지가 많아요. 물론 일반 사용자를 고려하지 않고 개발팀 내부에서만 쓸 것이라면 괜찮을지도 모르지만.

하지만 필자는 일반 사용자에게 쉬운 것은 개발자에게도 쉬울 것이라고 생각합니다. 필자가 속한 팀에서 서비스를 오픈했을 때 고객 센터를 맨티스와 연동해 만들었었는데 연동 당시에는 일반 사용자들이 고객 센터에 와서 글을 올리고 개발자들은 맨티스에서 조회하고 처리하는 프로세스를 예상했어요. 하지만 이상하게도 개발자들이 맨티스를 보지 않고 이슈 처리 기능도 다 구현되지 않은 고객 센터에 가서 글을 보더군요. 왜 그런지 물어봤더니 고객 센터 쪽이 UI가 더 쉽고 디자인이 예뻐서 그렇다는 거에요. 결국 개발자도 사람인 이상 개발자에게 적합한 UI와 일반 사용자에게 적합한 UI가 따로 있는 것은 아니라는 이야기죠.

필자의 경험상으로 이슈 트래킹 기능만 놓고 본다면 맨티스가 가장 무리가 없는 것 같습니다. 버그질라의 인터페이스는 우리가 일상적으로 접하는 웹 애플리케이션과 너무 동떨어져 있죠. 기능적으로 막강하고 나름대로 실용성을 추구한 점이 많이 엿보이지만 개발자들조차도 어려워할 정도이니 기획자나 팀장, 디자이너 등 다른 직군과 협업하는 데 쓰기에는 무리가 많아요. 맨티스는 국내 IT 기업에서 비교적 많이 쓰이고 한글 번역도 꽤 잘 되어 있어서 다른 직군과 협업에도 그럭저럭 쓸 만하고요.

트랙은 요즘 한창 주가를 올리고 있는 소프트웨어죠. 처음부터 프로젝트 관리 용도에 초점을 맞췄기 때문에 서브버전(Subversion) 저장소의 소스와 통합할 수 있는 기능도 있고 위키와도 통합되어 있습니다. 서브버전 저장소에 소스를 커밋(commit)할 때 코멘트로 티켓 번호를 달면 자동으로 해당 티켓과 연결되기도 하고 이슈 내용에 위키의 링크를 포함시킬 수도 있기 때문에 종합적인 관리 도구로 사용할 만해요. 그래서 요즘 개발자들 사이에서 급속도로 퍼지고 있죠. 하지만 이 기능을 모두 연동해 사용하는 경우가 아니라면 다른 도구가 더 나은 것 같습니다. 위키 기능도 요즘 좋아지고는 있지만 미디어위키(MediaWiki)나 모인모인(MoinMoin) 같은 막강한 위키를 쓰다가 트랙을 쓰면 불편함을 많이 느끼거든요. 이슈 트래킹과 로드맵 기능은 완성도가 꽤 높지만 맨티스에 비하면 일목요연한 뷰가 좀 아쉽고 통계 기능도 좀 약하죠. 그리고 트랙을 쓸 경우 뭔가 프로젝트 관리 자체가 트랙에 종속되는 현상이 생기기도 하는데 이것도 팀에 따라 문제가 될 수 있어요.

   소셜 북마크

   mar.gar.in mar.gar.in
    digg Digg
    del.icio.us del.icio.us
    Slashdot Slashdot

그렇다면 무엇을 어떻게 선택하면 좋을까요? 조건에 따라 좀 다릅니다. 만약 개발팀 전원이 개발자이고 소스 저장소로 서브버전을 쓴다면 트랙이 제일 좋은 선택일 것이고, 개발자가 아닌 직군과 협업을 해야 한다면 맨티스가 더 나은 대안이 되겠죠. 그런데 만약 일반 사용자까지 포괄하고 싶다면? 현재로서는 세 가지 중 어떤 것도 대안이 될 수 없고 상용 소프트웨어를 고려해보는 것도 방법일 거에요. ECUS가 이미 오픈 소스가 되어 있다면 기쁜 마음으로 추천하겠지만 아직은 그럴 수 없어 안타깝군요.

직접 만들어 보는 것도 좋은 선택이 될 수 있습니다. 사실 팀마다 요구사항이 다 다르기 때문에 각 팀에서 필요한 기능만 구현한다면 그리 어려운 일이 아니에요. 게시판에 부가적인 항목이 몇 가지 더 붙는다고 생각하면 됩니다. 요즘 루비온레일스(Ruby on Rails)나 장고(Django)처럼 웹 애플리케이션을 뚝딱 만들어낼 수 있는 프레임워크가 많으니 며칠 걸리지 않을 거에요. ECUS 프로젝트도 개발한 지 오래되긴 했지만 핵심 기능을 완성하는 데는 2~3주 밖에 걸리지 않았습니다. 바퀴를 다시 발명하는(Reinvent the wheel) 것이 아니라 바퀴를 다시 설계하는(Redesign the wheel) 것이죠. 개발자는 때로는 자신에게 필요한 소프트웨어를 직접 만들 수도 있어야 합니다.

직접 만들지 않더라도 선택하기 전에 직접 설치해 사용해보는 경험은 필수입니다. 그냥 리뷰에서 보는 것과 직접 사용해보는 것은 느낌이 많이 다르거든요. 여기서 리뷰한 세 가지 외에도 살펴볼 만한 소프트웨어가 많습니다. 위키백과의 Comparison of issue tracking systems를 참조해 보세요.

블로그 이미지

Moonistar moonistar

소스 관리 프로그램
영어로는 Revision Control, Version Control, Source Control, Code Management 등 다양한 용어가 존재한다.

공통적으로 소스를 짜면서 서로 협업하고, 유지보수가 쉽게 도와주는 툴이다.

그럼 소스 관리는 왜 필요한가?

1) 안전하고 보안이 잘 된 소스 코드를 만들기 위해서
2) 접근이 용이하도록 하기 위해서
3) 재생산이 가능하도록 하기 위해서
4) 유지보수가 쉽게 하기 위해서

이러한 목적을 바탕으로 한 소스 관리의 목표는 무엇인가?

1) 소스 코드를 중앙집중식으로 저장한다.
2) 당신이 파일에 대해 한 일을 히스토리로 기록한다.
3) 개발자들이 서로 방해하지 않으면서 함께 일할 수 있게 한다.
4) 개발자들이 일을 나누어서 병행으로 수행하고, 나중에 그 결과를 합병할 수 있게 한다.

내가 담당하고 있는 소스를 관리해야 된다. 더 이상 압축해서 파일 서버에 저장하지 않고, 다른 사람과 같이 코드를 작성해야 한다. 아무리 좋은 툴이라도 잘 사용해야 좋은 툴이고 잘 못 사용하면 독이 된다.

앞으로 소스 관리 프로그램을 기능 검토하면서 내가 정리한 자료를 올리 계획이다...

SVN(Subversion) 과 VSS(Visual SourceSafe),,, 이미 내 맘은 SVN으로 기울었지만,,, ㅋ


제발 좀 부지런해지자 ... ㅡ.ㅡ;;

블로그 이미지

Moonistar moonistar