소프트웨어 개발에서 소프트웨어 디자인이 중요한 것은 엄연한 사실입니다. 디자인은 소프트웨어 개발의 중심입니다. 문제는 어떻게 디자인을 할 것인가입니다. 대표적인 방법이 Design By UML과 Design By Code (또는 Design By Programming)라고 할 수 있습니다.
일반적인 소프트웨어 개발이 [요구사항분석 -> 디자인 -> 구현 -> 배치 -> 테스트] 형태로 이루어진다고 할 때 두 방식은 전혀 다른 모습으로 나타납니다. Design By UML은 각 단계를 더 세분화하는 방식으로 갑니다. RUP 방법론에서 디자인 단계만 10 단계 이상입니다. 반면 Design By Code는 디자인과 구현 단계의 구분을 희석시키면서 각 단계를 단순하게 합니다. 결과적으로 Design By UML은 Waterfall Process를, Design By Code는 Iterative Process를 따르게 됩니다. 역설적인 것은 RUP가 주창하는 개발 모델은 "Iterative and Incremental process"라는 겁니다. RUP를 비판하는 많은 사람들의 주장 중 하나가 바로 "RUP는 Iterative Process를 주장하긴 하지만 RUP를 적용한 프로젝트는 Waterfall로 가기 쉽다"라는 겁니다. RUP의 근간이 되는 UP(Unified Process)는 정말로 훌륭한 방법론입니다. 하지만 Rose를 비롯한 Rational사의 각종 툴의 마케팅 수단으로 악용된(?) RUP는 쓰레기가 된 겁니다.
RUP 가 Design By UML의 한 극단을 차지하고 있다면, Kent Beck은 Design By Code의 다른 극단을 차지하고 있습니다.(eXtreme Programming을 사용하는 모든 사람들이 UML을 사용하지 않는 것은 아닙니다. Kent Beck이 유독 심할뿐입니다.) 그렇다면 어떤 방식을 따를 것인가?
논의 진전을 위해 대상 프로젝트를 객체지향언어를 이용한 비즈니스 애플리케이션 개발에 한정하도록 하겠습니다.(UML 자체가 객체지향 방식으로 소프트웨어를 디자인할 때 사용하는 것이고, 우리 회사가 개발하는 시스템이 주로 비즈니스 애플리케이션이기 때문에 이런 범위 제한은 당연하다 하겠습니다.)
소스 코드를 담고 싶은 UML
UML의 등장과 성공은 C++가 Java로 대표되는 객체지향언어의 등장입니다. "코드를 UML로 UML을 코드로(Reverse or Forward Engineering)"가 가능해지면서, UML이 부각되었습니다.(Model-Driven Architecture는 여기서 한 걸음더 나간겁니다.) UML은 꾸준히 코드를 담고 싶어합니다. 그러나 언제나 "싶어함"에 그칩니다. 이런 와중에서 사람들은 "소스 코드로 디자인할 수 있다."라는 사고까지 다다릅니다. 디자인은 UML로만 할 수 있는게 아니라 코드로도 할 수 있는 거였다. 사실상 객체지향언어의 등장이 새로운 패러다임 전환을 가져온 것이 바로 "소스코드로 디자인할 수 있다"는 겁니다. Jack Reeves의 [The Source Code is the Design]이 이를 잘 설명해주고 있습니다.
객체지향에 대해서 잘모르면 UML Notation을 알아도 UML을 쓸 수 없습니다. 객체지향에 대해서 잘알면 UML 보다는 코드로 디자인하는 것이 더욱 풍부하고 생산적입니다. 슬픈 UML...
동작하고 싶은 UML
비즈니스 애플리케이션은 요구사항이 애매모호한데다가 사춘기 소녀처럼 시도때도 없이 변하고 삐지는 특성이 있습니다. 이 문제에 대처하는 방법은 동작하는 시스템을 멍청한(?) 사용자나 고객에게 보여주는 겁니다. "이거 니가 원하는 건 맞아? 아냐? 그럼 어떻게 해줄까?" 만고 불변의 진리는 UML은 동작하지 않는다는 것입니다. 또한 디자인하는 과정에서도 현재의 디자인이 맞는지 확인할 수 있는 것이 중요합니다. UML은 동작하지 않습니다. Design By Code만이 이를 보장해줍니다. 자동화된 단위 테스트를 계속 수정하면서 개발자(혹은 디자이너)는 자신의 디자인에 대한 Feedback을 받으면서 디자인을 수정할 수 있습니다.
커뮤니케이션이 쉬운 것 같은 UML
UML을 중시하는 많은 사람들은 UML을 통해 고객 또는 비즈니스 도메인 전문가와 쉽게 커뮤니케이션할 수 있다고 생각합니다. 맞습니다. 맞구요... 하지만 뭐하러 그걸 고객이나 비즈니스 도메인 전문가에게 보여줍니까? 커뮤니케이션 대상은 개발자간에 이루어질 뿐입니다. 커뮤니케이션도 UML보다는 코드가...
결론적으로 소프트웨어 개발은 Design By Code를 중심으로 이루어저야 합니다. UML은 보조적인 수단일 뿐입니다. 보조적인 수단이란 의미는 개발 중에 UML로 작성된 것을 산출물로 관리하지 않는다는 것입니다. 프로젝트의 규모는 "Design By UML이냐? Design By Code나?"는 논쟁과 직접적인 상관관계가 있다고 보지는 않습니다. 그보다는 "Waterfall이냐? Iterative?"라와 관계될 것 같습니다. 이 이야기는 다음 기회에... 어찌되었든 RUP도 "Iterative and Incremental Process"에 기반하고 있다고 주장합니다.
잡설 하나. 예전에 처음 Rose를 사용했을 때 가장 큰 불만은 작은 모니터와 A4 종이만 지원하는 프린터였습니다. 만약 [마지막 황제] 시절의 대한극장 스크린만한 모니터와 그만한 종이를 지원하는 프린터가 있다면... 그리고 그걸 볼 수 있는 성능 좋은 돋보기가 있다면 Design By UML도 괜찮을 수 있습니다.
잡설 둘. UML이 시스템을 문서화할 때는 좋은 것 같습니다. 지들(고객)이 읽을 것도 아니면서 UML로 작성한 문서를 받으면 "헤헤헤"하니.. 뽀대가 나기는 합니다. 그런데 Reverse Engineering을 아십니까?
잡 설 셋. 비용을 고려하면 98년도에 네덜란드가 우리는 5:0으로 이기듯, Design By Code의 Design By UML에 대한 압승입니다. 천이백만원 짜리 툴이라는 게 뽀대는 나지만... 내실을 기할 때입니다. Open Source 진영의 개발자들이 UML을 싫어하는지 아직은 쓸만한 UML 모델링 툴이 없습니다.
잡설 넷. 작년 이맘 때까진 저도 RUP와 UML 추종자였습니다. 저처럼 지조가 깊은 사람이 변심한 건 Kent Beck의 "In software development, Duplication is evil. And UML is duplication of source code. Therefore, UML is evil."이라는 논박하기 어려운 명제 때문이었습니다.
No comments:
Post a Comment