회사에 다닐 때, 몇몇 프로젝트 관리 도구들 – Microsoft Project나 dotproject 같은 웹 기반 도구들을 사용해보았는데, 쓸데없이 너무 복잡하거나, 필수적인 기능이 빠져있는 경우가 많았을 뿐만 아니라, 사용하기가 너무 불편했다.

XP 방법론이나 TDD 같은 practice를 보면서, 그러한 방법론에 잘 들어맞는 툴이 없다는 것도 느낄 수 있었다.

예를 들어, XP 방법론에서는 User Story로부터 요구사항을 수집하고 구현해야할 기능들을 찾아낸다. 그리고 이러한 기능들 중, 특정 기간 내에 개발할 기능들을 골라낸다. 기능별로 여러 사람들에게 분배되고, 기능을 구현하면서 또는 사용자의 피드백을 통해 추가적으로 찾아낸 기능들은 다음번에 구현할 기능으로 넣어둔다. 이러한 프로세스를 따라가면서 기존의 프로젝트 관리 도구를 사용해보라. 페이지를 이리저리 왔다갔다 해야하고, 불필요한 수많은 정보들을 입력해야한다. 방법론이 강조하는 프로세스를 따라가면서, 프로젝트 관리자나 개발자가 프로세스 상에서 발생하는 정보를 자연스럽게 입력하고 조회하는 것은 매우 불편하다.

한마디로, 방법론 상의 프로세스와 프로젝트 관리 도구의 사용성은 잘 들어맞지 않는다. 하지만, 복잡한 프로젝트 관리 도구들을 사용하더라도 위의 프로세스에서 발생하는 정보들을 모두 표현할 수는 있다. 그렇다면 무엇이 문제인가?

그 이유는, 여러가지 방법론 사이의 중요한 차이점이 그것들이 가지고 있는 정보가 아니라, 정보가 전달되는 방법과 방향의 특성 – 프로세스에 있기 때문이다. 우리에게는 프로세스의 흐름을 잘 반영하는 도구를 찾아보기가 힘들다. 만약 이러한 요구를 잘 반영한 도구가 있다면, 요구의 반영은 잘 신경써서 만들어진(crafted) 사용자 인터페이스의 형태로 나타날 것이다. 이러한 점에서, 프로젝트 관리 도구의 불편함은, 도구의 기능적인 면과 도구가 다룰 정보에만 치중하고, 사용자 인터페이스 즉, 도구를 다루는 방법은 무시하는 프로그래머들의 일반적인 경향이 반영된 결과일런지도 모른다.

한편, 기존의 프로젝트 관리 도구들은 방법론의 특성을 제대로 반영하지 못할 뿐만 아니라, 그러한 방법론이 실무에 적용되면서 발생하는 변형들도 잘 반영하지 못한다.

프로세스 상의 약간의 변형이나, 필요한 정보 자체의 변형이 발생하는데, 대부분의 프로젝트 관리 도구는 이러한 변형을 잘 반영할만한 유연성을 갖추고 있지 못하다. 반대로, 특정 방법론(이른바 표준 방법론)에 잘 맞춰져있는 도구에 자신들의 방법론을 맞추는 것은 완전히 어불성설이다. (이는 많은 사람들이 저지르는 실수중의 하나이다.) 프로젝트의 환경에 따라 방법론은 적절하게 변형되기 마련이다.

nohmad 옹의 최근의 웹 어플리케이션에 관한 글에서 소개된 sproutliner는 작업 관리를 위한 도구다. sproutliner는 자기가 원하는 대로 작업 항목의 필드를 늘리거나 줄일 수 있는데, 위와 같은 프로젝트 관리 도구상의 필요를 반영하는 것이 아닐까. 물론 작업 관리라는 한정된 기능을 수행하고 있고, 정보의 변형에 있어서의 요구만을 반영하고 있어서, 아쉬운 점이 좀 남는다.

또, 어떻게 보면, 방법론에 무관하게 유연한 도구를 만들고 싶다는 목적을 달성하기 위해서는, 커다란 단일한(monolithic) 도구가 아니라, sproutliner처럼 서로 통신할 수 있고 조합할 수 있는 작은 단위의 도구들의 형태를 가져야할 지도 모른다.

기회가 된다면, 내 주변의 – 나 자신 또는 나를 포함한 팀의 – 방법론에 잘 들어맞는 프로젝트 관리 도구를 만들어보고 싶다.

루비 프로그램 맨 위에 다음과 같이 적어주면 된다.
(여기를 참고.)

또는 ruby의 command-line parameter로 ‘-rprofile’을 줘도 된다. (역시 profile module을 맨처음 require하는 의미)

이런 방식으로 profiler와 함께 실행시켜보면 다음과 같은 결과를 볼 수 있을 것이다.

%   cumulative   self              self     total
time   seconds   seconds    calls  ms/call  ms/call  name
35.56     0.16      0.16       86     1.86     7.44  Kernel.require
8.89     0.20      0.04       57     0.70     1.58  SubscriptionManager#constructSubscriptionFromRow
8.89     0.24      0.04      203     0.20     0.30  Kernel.puts
6.67     0.27      0.03       23     1.30    10.00  Array#each
6.67     0.30      0.03        7     4.29    12.86  Mysql::Result#each
6.67     0.33      0.03      728     0.04     0.04  Array#[]
4.44     0.35      0.02      407     0.05     0.05  IO#write
4.44     0.37      0.02       18     1.11     1.11  Mysql#initialize
2.22     0.38      0.01       92     0.11     0.11  Kernel.==
2.22     0.39      0.01       80     0.13     0.13  String#==
2.22     0.40      0.01       13     0.77     0.77  Module#attr_accessor
2.22     0.41      0.01       18     0.56     0.56  Mysql#query
2.22     0.42      0.01      119     0.08     0.08  Fixnum#to_s
2.22     0.43      0.01       31     0.32     0.32  Module#attr_reader
2.22     0.44      0.01       22     0.45     0.45  Module#alias_method
2.22     0.45      0.01       57     0.18     0.18  Subscription#initialize

한편, eruby interpreter랑은 좀 이상하게 동작하는 (무한루프) 문제가 있어서, eruby tag를 모두 빼고 테스트해야만 했다. 이 문제는 좀 더 살펴보아야겠다.

인터넷 어플리케이션의 세상을 살아가는 소프트웨어 개발자로서, 놓칠 수 없는 흐름이, RIA(Rich Internet Application) 기술의 흐름이다. ActiveX가 기술적으로 좋은 선택이 아님에도 불구하고, 우리나라에 ActiveX 기술이 보편화된 것은, 바로 RIA 기술에 대한 요구의 반영이라고 볼 수 있다.

DHTML이나 Gmail에서 도입된 후 유행하고 있는 ajax, Flash 등도 모두 이러한 흐름의 한 갈래라고 볼 수 있다. (nohmad님의 flickr-throws-flash-adopts-dhtml 참고)

또한, 이러한 frontend 기술들을 backend 기술과 조합한 RIA 솔루션을 제공하는 회사들도 있다. (일전에 #perky 채널에서 rapzzard님이 알려주신 것들을 정리해보았다.)

• Smart Client와 ASP.NET
• Laszlo
• Flex
  • Flex Overview: 상당히 인상적인데, 이것을 처음 본 사람이라면, Adobe와 Macromedia의 합병을 새로운 눈으로 볼 수 있을 것이다.
  • Flex Builder Videos
• Bindows

얼마전에, ACM Queue에 올라온 Death by UML Fever와 UML Fever: Diagnosis and Recovery를 읽었다.

UML을 사용하면서 발생하는 여러가지 부정적인 현상들을 UML Fever라고 표현하고 있다. 이 글을 쓴 Boeing Company의 Alex Bell은 UML Fever의 궁극적인 원인은 그 기술이나 프로세스를 선택하고 적용해야하는 개인의 경험 부족에 있다고 본다. 쓸데없이 메타포를 남발해서 읽기가 굉장히 힘들지만, 요약하면 다음과 같은 현상들로 나타낼 수 있다.

• 자신의 프로그램에 어떠한 기술과 프로세스가 적합한지 평가하는 것이 아니라, 다른 사람이 다른 프로그램에서 사용한 것들 그대로 받아들이는 행위.
• UML 다이어그램만 있으면 자동적으로 소프트웨어를 개발할 수 있고, UML이야말로 모든 소프트웨어 공학의 해결책이다라는 생각.
• UML artifact를 많이 가지고 있을 수록 가치가 증가한다는 생각.
• 쓸데없이 너무 많거나 상세한 UML artifact를 만들어내는 것을 소프트웨어 개발 프로세스나 프레임워크 혹은, UML 그 자체의 탓으로 돌리는 행위.
• 생산성의 향상을 이유로, 자신의 프로세스에 맞지도 않는 비싼 UML 툴을 구입하는 행위.
• 이미 불필요해진 UML artifact를 버려서는 안된다고 생각하고, 비용을 감수하면서 관리하려는 경향.
• 아무런 목적이 없이 UML을 만드는 행위.
• 세분화된 기능적 decomposition을 use-case로 만들려는 경향. (모델을 단순화하려는 목적을 잃고, 오히려 더욱 이해하기 힘들게 만든다.)
• UML 다이어그램을 극단적으로 상세하게 만드려는 욕구. (어떤 것이 중요하고 중요하지 않은지 판단하기 위해서는 코딩 경험이 중요하다.)
• 상세한 디자인 요소들을 포함하는 거대한 UML 모델을 만드는 행위. (코드 없이, 모든 정보를 표현할 수 있다는 생각.)
• UML 디자인 모델과 코드로부터 reverse-engineer한 구현 모델의 차이를 인지하지 못하는 것
• 모든 프로젝트 구성원들이 경험에 상관없이 교환가능하다는 생각.
• 전문적인 기술이 없는 사람을 그 기술이 필요한 position에 기용함으로써, 조직 전체가 그 사람의 practice를 best practice로 여기게 되는 현상.
• 간단한 디자인 툴이나 언어 문법에 대한 클래스에 사람을 보내고서, 전문가로 될 것이라고 기대하는 행위.

UML Fever의 여러가지 현상은 단지 UML에 한정되는 것이 아니라, Software development에서 사용하는 모든 기술, 더 나아가서는 모든 기술에 적용된다고 생각한다. 어떤 기술에 대한 제대로 된 지식이나 경험의 부족은, 그 기술이 어떠한 해결책에 적합한지를 제대로 평가하지 못하게 만들고, 그 기술에 대한 맹신이나 잘못된 적용을 낳는 것 같다. 이와 비슷한 얘기를 삼색볼펜초학습법과 소프트웨어 엔지니어링이란 글에서도 언급을 했었다.