"그래서, 설계는 어떻게 해야하나?"
"UML이면 다된다면서 왜 Doxygen같은 것을 쓰나?"
등등등

최근에 UML을 동료들에게 전파하면서(내것으로 체화된 Agile 개발 방법) 받은 질문이다.
종종 UML에 대한 의문과 질문을 받는데... 특히 Doxygen과 같이 사용하는 부분에 대해 의문을 많이 가지고 있었다.

잠깐 생각을 해보자.

"개발이 과학인가?"

과학이 되려면 몇가지 조건이 있는데 일단 다른 건 다 제쳐두고...
"과학은 누구든 A를 집어넣으면 어디서나 B라는 결과물이 나와야한다."
즉, 객관적이고 타당한 논리는 언제 어디서 누구에게나 대입하더라도 맞아야 한다.
이게 안된다면 과학이 아니다. 그래서 우리는 "XX설"이라는 식으로 정의하거나 "종교"의 이름을 붙이기도 한다.

그런데 개발을 한번 보자.

똑같은 UML이 아니더라도 우리가 익숙한 Workflow diagram을 개발자 10명에게 주고 그대로 개발하라고 하면 같은 결과가 나올까?

오히려 조건중에 시간을 짧게 가지고 갈수록 실패하는 개발자가 더 늘어날 뿐이다.
결론부터 내리자면 개발은 과학이 아니라 "기술(ART)"이다.

다시 주제로 돌아와 UML은 건축설계서와 같은 도면에 불과할 뿐이다.
CASE툴을 가지고 MDA한답시고 상세하게 UML그려서 Code로 Export해봤자. 사람이 100라인으로 끝낼 수 있는 일을 CASE 툴은 그 이상의 쓸데 없는 코드를 양산할 뿐이다.

* 첨부된 논문은 이를 실증한 것이다.



다시말해 UML을 신봉하고 그것이 개발 설계의 전부인양 생각하면 큰 코다친다.
UML은 의사소통의 도구로 활용되어야 하고 살아 있는 지도를 만들기위해 Doxygen과 같은 인공위성 지도를 찍어야 하는 것이다.

다시말해 UML은 "손으로 측량된 지도"라면 Doxygen과 같은 도구는 "인공위성지도"이다.
이 둘을 한번 비교해보자.

먼저 Doxygen만 사용했을때를 인공위성의 지도로 한번 보도록 하자.
사용자 삽입 이미지
어떤가? 알아 볼수나 있을까?
손으로 그린 지도인 UML을 한번 보자.
사용자 삽입 이미지
어떤가? 알아 보기가 훨씬 쉽다.

이제 잠깐 망각의 시간을 보낸뒤 순서를 바꿔보자.
일부로 이미지를 보기 힘들게 더 작게 만들었음을 참고하자.
사용자 삽입 이미지
사용자 삽입 이미지
이미지가 더 작아져서 보기가 더 불편함에도 인공위성사진만 보았을 때 보다 한결 이해가 편하다.

이것이 바로 UML과 Doxygen을 함께 사용하는 이유이다.

앞에서도 증명해보았지만 "개발은 과학이 아니다." 사람마다 훈련받은 강도가 다르고 훈련된 결과가 달라 개발자 한 사람 한 사람이 보유한 기술의 난이도, 성숙도가 다르다.

따라서, 설계과정에서 아키텍트는 모든 역량을 누구나 알아듣기 쉽게 설계서를 그려나가야 한다.
UML이 아니라도 좋다. 일단 나는 UML이 편하기 때문에 사용할 뿐이며 만약 Balsamiq과 같은 Mockup Tool로 그 과정을 밟아가도 괜찮다. 그리고 이해했는지 확인하자.
확인 하는 방법은 간단하다. 스스로 편하다고 생각하는 표기법으로 변환해보라고 하던가. 아니면 WhiteBoard에 그림으로 설명해보라고 하면 된다.

이렇게 확인한 업무를 진행하고 이후에 생성된 Doxygen과 UML을 한번더 검토한후 설계와 다른부분이 나타나면 왜 다르게 했는지 편안하게 물어보고 합리적이라고 생각하면 UML을 고치면 그만이다.

결론은 UML을 맹신하지 말자. 그러나, UML은 커뮤니케이션 도구로 짱이다.


* 추후에 UML 강좌를 한번 Open하겠습니다.

2011/03/09 01:02 2011/03/09 01:02

트랙백 주소 :: 이 글에는 트랙백을 보낼 수 없습니다