UML Fever

얼마전에, 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에서 사용하는 모든 기술, 더 나아가서는 모든 기술에 적용된다고 생각한다. 어떤 기술에 대한 제대로 된 지식이나 경험의 부족은, 그 기술이 어떠한 해결책에 적합한지를 제대로 평가하지 못하게 만들고, 그 기술에 대한 맹신이나 잘못된 적용을 낳는 것 같다. 이와 비슷한 얘기를 삼색볼펜초학습법과 소프트웨어 엔지니어링이란 글에서도 언급을 했었다.