잠깐 프로젝트가 딴 데로 샜더니 이런 상황이 되어 버렸다. JIRA를 사용하여 진행 사항 등이 관리되는 것은 아주 좋은데, 상황이 이렇게 되고 보니 너무 적나라하게 보인다는 생각이 든다. (오른쪽 Task List에 보이는 뻘건 항목이 다 지연된 것이다. -_-;)

 예전에도 한 번 고민했던 기억이 있는 쓰레드에 관한 의문의 다시 나를 덮친다. 딴 일 많은데.. -_-;

왜 한 Thread는 한 번만 실행할 수 있는 걸까?

 물론 Runnable을 구현해서  Thread를 새로 만들어가며 작업하면 문제없이 프로그래밍을 할 수 있다. 하지만 IllegalThreadStateException을 피하는 방법(어라? 비?...)을 알고 픈게 아니라. 왜 한 번 사용한 Thread를 버려야하는지에 대한 이유가 궁금하다. (잠시 검색해봤지만 원하는 답은 아직 안나오네...)

 약간 뒷북인데, 프로젝트에서 JIRA 테스트 버전을 깔아서 ISSUE관리를 하고 있다.

 아직 JIRA의 기능을 구석구석 아는 것은 아니지만, Eclipse와 Issue를 연동하는 기본 기능만으로도 매우 강력한 무언가를 느끼게 해준다.

 나와 또 다른 아키텍트가 번갈아가며 Open Source인 Bugzilla를 Linux서버에 설치하는 작업을 tlfvo하고 (버그질라는 소문대로 너무나도 설치가 번거로왔다.) 임시로라도 JIRA 한 번 써보자하여 Test버전을 설치했다. 그런데, 깔끔함과 편리함에 완전 반해서 다음 프로젝트부터라도 PM에게 사달라고 조를까 생각 중이다.

 진행 상황 보고 등의 거창한 기능은 둘째치고, 일단 Issue가 어딘가에 저장된다는 것 자체가 "단기기억상실증"에 시달리고 있는 나와 같은 이들에게는 매우 좋은 기능이다. 이 기회에 고백하건데, 이 글을 쓰고 있는 본인은 업무 진행에 관하여 잘 까먹을 뿐만아니라 산만하기까지 하다. (결과가 짐작되는가?) 이 문제를 해결하다 보면 다른 문제에 대한 실마리가 보이기도 하고, 또 다른 문제를 풀다 보면 원래의 문제에 대한 호기심이 발동되는 등 거대한 산만함을 주체하기가 힘든 것이 사실이다.

 이럴 때 일단 JIRA에 프로젝트를 등록하고, 프로젝트의 구성요소인 component (가장 큰 대분류의 프로젝트의 하위 분류 정도로 생각하면 되겠다)를 만들어 놓으면 안도감마저 든다.

 위의 그림에서 보이듯이 Eclipse의 Task Manager라고 할 수 있는 Mylyn과도 연동된다.(참고로, Eclipse 3.3에서는 Mylyn이 디폴트로 깔려 있다. 3.2에서도 버전에 맞는 Mylyn을 설치하면 된다.) 더군다나, 작업을 하다보면 해당 이슈에 context가 자연스럽게 등록된다. (우호!!) Context란 해당 issue와 관련있는 여러 주변 환경이라고 보면 되는데, 관련 패키지, 클래스 등이 포함된다. 지금 위 그림에 오른쪽에 보이는 클래스는 현재 활성화 되어 있는 issue와 관련된 것들이 filtering 되어서 보이고 있다.

 핵심은 위에 보이는 Package Explorer의 "Focus on Activate Task"버튼. 해당 버튼을 누르면 현재 선택된 issue와 관련된 context를 메서드 단위까지 등록할 수 있다. 어떤가? 이만하면 지병(건망증+산만함)을 극복하고 Project를 열심히 할 수 있다는 희망이 보이지 않는가?

 개인적인 견해이지만, Project에 형상관리시스템(CVS)과 Issue관리시스템(혹은 Bug Tracking System)은 필수 요소 중에서도 필수 요소라고 생각한다. 사실 그 동안 버그질라는 널리 사용됨에도 불구하고 설치와 운용의 측면에서 애로 사항이 상당히 있었으나, JIRA의 경우 WAR파일 배포로 끝나는 초간단 설치에서 여러가지 깔끔하고 편리한 기능에 이르기까지 사용하면 반할만한 요소가 많다. 실제로 상당한 가격(평균 120만원 정도. 참고로 Open Source Project에서는 무료로 사용할 수 있다.)을 지불해야 함에도 이러한 편의성 때문에 굉장히 많은 프로젝트에서 구입해서 쓰고 있다고 한다.
 
 궁금하다면 클릭(http://www.atlassian.com/software/jira)해 보길...

 Appication의 설계를 하거나 프로젝트 멤버끼리 의사 소통을 하다 보면 꼭 필요한 UML 다이어그램이 있기는 하지만, 본인의 지론이 '형식을 위한 형식은 안된다'이기에 코딩에 앞서 UML만을 열심히 그리는 것이 바람직하다고 생각하지는 않는다. 그렇다 보니 Version-up 된 UML 2.0에서 더욱 복잡해지고 정교해진 다이어그램들에 대해 질색하는 것이 사실이다. 그렇다, 솔직히 말해 본인의 지론은 본인의 성격, 즉 귀차니즘에 근거한다.

 누군가가 "UML 꼭 익혀야 하나요?" 라고 묻는다면 간단하게 "상황이 허락한다면 아니요" 하겠지만, 예외가 몇 개 있다. 오늘 소개할 액티비티 다이어그램(Activity Diagram)은 그러한 예외 중 하나이다. 실제 코드의 작성과 문서화에 도움이 되는 UML 다이어그램 중 프로젝트에서 상대적으로 잘 안 보이는 것이 Activity Diagram인데, 국내 프로젝트에서는 안보이다가도 외국 문서를 보면 Activity Diagram을 심심치 않게 접할 수 있다. 예를 들어, 아래는 일본 NTT Data의 Framework 문서에 등장하는 Activity Diagram을 필자가 번역한 것이다.

 거의 업무 흐름도를 대체하여 사용하고 있음을 알 수 있다. (참고로 동그란 놈은 프로세스를, 각진 사각형은 전달되는 데이터를 나타낸다.) 이렇게, Acitivity Diagram은 객체 지향 모델링이라는 본연(?)의 업무 이외에도 처리 순서나 Workflow를 나타내기 위해서라면 장소를 가리지 않고 등장할 수 있다. 한마디로 구현에서부터 비지니스를 표현하는 영역에 이르기까지 상태나 순서의 흐름을 나타내기 위해서라면 폭넓게 활용될 수 있다는 것! UML 2.0에서는 statechart로 분류되던 상황에서 벗어나 독립적인 Diagram이 되었다는 사실은 이를 잘 말해준다. 앞으로도 Activity Diagram은 다양한 분야에서 폭넓게 쓰이지 않을까 조심스레 예측해본다. DSL(Domain Specific Language)등에서, 다시금 "UML은 부족합니다" 의 건전한 비판이 나오는 것은 아주 바람직하다고 본다. UML은 사실어떤 이유에서건 B2B의 SI 영역에서 절대불가침의 권위를 세워 온 것은 사실이다. 하지만 UML은 RUP 프로세스 자체는 아니며, 표현 도구로서 매우 유용한 면이 있는 것도 사실이다.

 자주 그려보게 되는 업무 흐름도나 자신이 작성한 component의 흐름도 등을 표현할 때, 보통 ppt장표를 활용하여 자신만의 기호로 표시하는 경우가 많은데 객체 지향 설계를 하고 있다면 이럴 때 Acitivity Diagram을 활용해 준다면 좋을 듯 싶다.