태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

UML전문가가 설계전문가?

2009/04/15 23:28 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

종종 "소프트웨어 설계를 잘 하려면 UML을 잘 알아야 합니까?"라는 질문을 받습니다. 

사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다.
기법은 기법일 뿐입니다. 내용은 아니죠.

UML은 잘 정리된 모델링, 설계 기법이며 툴이고 많은 장점을 가지고 있다고 생각합니다.
그럼에도 불구하고 소프트웨어 설계라고 하고 UML을 떠올리는 것을 보면 UML이 본의 아니게 나쁜 일도 했다는 생각이 듭니다. 

잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를 잘 설명한 것입니다. UML이 그 중의 하나가 될 수도 있고, 전통적인 Flowchart, DFD, 수도코드나 글로 설명할 수도 있습니다. 설계는 어떠한 다이어그램을 그리고 어떤 툴을 쓰냐에 따라서 잘 되었는지 결정되는 것이 아니고 어떤 식으로 접근해서 설계를 하였고, 리뷰 하였는지가 더 중요하고, 이를 보고 구현을 담당한 개발자(본인일지라도) 충분히 구현할 수 있는 적당한 정도가 좋습니다. 그리고 미래의 비즈니스 비전에 대응할 수 있는 구조여야 합니다.

따라서 나는 설계를 시작할 때 종이와 연필 또는 화이트보드를 가지고 시작합니다. 개발자들이 토론을 하면 깔끔하게 컴포넌트를 나누는 것으로 설계를 시작합니다. 
설계 초기부터 툴을 이용해서 정리를 시작하면 감이 잘 안 오고 잦은 수정 때문에 귀찮을 수가 있습니다.

UML을 아는 것은 좋습니다. 남들이 UML로 작성해 놓은 것을 읽을 수는 있어야 하니까요.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  
저작자 표시 비영리 변경 금지

'프로젝트 > 설계' 카테고리의 다른 글

설계가 필요할까?  (4) 2011/12/22
Software Architect를 양성하는 나라  (10) 2011/12/19
UML전문가가 설계전문가?  (6) 2009/04/15
코더(Coder)의 비애  (6) 2008/11/24

전규현 프로젝트/설계 , , , , , ,

Trackback Address: http://allofsoftware.net/trackback/112 관련글 쓰기
  1. 2009/04/18 07:17
    UML의 가치 Tracked from The Art of Software Development
  2. 2009/08/09 02:44
  1. 좋은 말씀이십니다.
    저도 설계를 최초 시작할때는 역시 볼펜과 종이를 가지고 시작합니다.

    물론 사전 요구사항 분석은 기본이지요. 그리고 나서 전체적인 시스템 구조를 어떻게 가져가야 할까를 종이로 열심히 그림으로 그리죠^^! 툴을 잘 다룬다면 좋겠지만, 꼭 잘 다뤄야만 전문가인건 아니죠^^!

  2. 돌이아버님 안녕하세요. ^^
    연필이 좋으면 글을 더 잘 쓸 수 있다는 것과 비슷합니다. 물론 좋은 연필을 사용하면 전혀 나쁠 것은 없지만, 글을 잘 쓰기위해서는 좋은 연필을 사기보다는 책을 많이 읽고 글쓰는 법도 배우고 글도 많이 써봐야죠.

  3. Blog Icon
    작은악마

    당연한 글인데 읽는 순간 많은 생각이 드네요.

    옛날 UML을 보고 감탄하고 그에 따라 볼려고 애쓰다보니.. 가장 핵심적인 면을 놓친것이 많았다 싶습니다.
    사실 적용한다고 해놓고 막상 한건 -_- 문서만 UML 형식으로 만들곤 했지만 말입니다..

  4. 작은악마님 안녕하세요. 축구 좋아하는 어린이가 멋진 축구화 보고 황홀해하고 축구화 살려고 축구는 안하고 맨날 아르바이트 하는 격이죠. 축구화 신경안쓰고 맨날 연습했으면 훨씬 잘할 것을...

  5. 다들 일정관리 어떻게 하고 있나 몇몇 회사분들게 물어보니
    "이것저것 다써봤지만 결국 비지오와 액셀 그리고 달력으로 돌아왔어 ㅎㅎㅎ"
    이렇게 결론이 나더군요.

    "툴이나 기법이 중요한게 아니고 사람이 중요하구나"
    라는걸 다시 느낀것 같습니다.

  6. 안녕하세요. 당근천국님

    저도 왠만한 프로젝트 일정관리 아직도 엑셀로 합니다. ^^ 그게 더 나아요.

문서를 작성하면 더 오래 걸린다는 고정관념

최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다. 어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서..

이슈를 모으기도 정말 어렵다.

많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다. 복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다. 기초..

변화에 실패하는 9가지 고정관념

회사는 끊임없이 변화하지 않으면 지속 성장하지 못한다. 하지만 변화는 피와 살을 깍는 고통을 동반하고 또 많은 회사가 변화에 실패해서 성장하지 못하거나 사라져간다. 보통의 사람들은 대부분 변화를 싫어하고 기존에 하던대로 계속..

좋은 프로그래머가 되는 24가지 방법

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생하기 어려운 일이다. 2. 프로그래밍 기초 원리를 완전히 이해해야 한다. 원리를 모르면 근본적인 해결을 할 수 없다. 3. 문제 해결 능력을 키워야 한다...

요즘 실리콘밸리에서는...

얼마전 실리콘밸리의 한 Startup company에서 CTO로 일하고 있는 오랜 친구가 한국에 놀러와서 같이 여행을 갔다. Informix에서 소프트웨어 엔지니어로 시작해서 한 20년 정도 일한 중국인 친구다. 같이 일을..

전문가 vs. 책임자

우리나라 조직문화는 전문가보다 책임자를 선호한다. 조직의 장이 책임을 지고 모든 일을 알아서 하는 것이다. 상명하복 관계 위주다. 경영자가 SW개발에 대해서는 잘 모르는 경우 누구 한명이 책임지고 개발해줬으면 하는 생각을 하..

소프트웨어 회사의 자산은?

소프트웨어 회사의 자산은 무엇일까? 흔히 개발자가 소프트웨어 회사의 재산이라고 한다. 이런 회사일 수록 회사가 가지고 있는 것은 정말 개발자밖에 없다. 또한 파악하기 어려운 한 무더기의 소스코드가 있다. 개발자들이 나가면 이..

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..