디자인 팁 몇 개…
사내용 소프트웨어 디자인 시 고려해야 할 몇 가지 사항에 대해서 이야기 해보자. 사내용 소프트웨어란 무엇일까? 일반적인 상용 소프트웨어는 불특정 다수가 사용할 목적으로 만든다.(예를 들어 포토샵, msn 메신저, 오피스 등) 따라서 개발 품질과 사용 편의성이 높아야 한다. 하지만 사내용 소프트웨어는 회사 안에서 어떤 업무를 처리하기 위해서 사용하는 프로그램이기 때문에 개발 품질과 사용 편의성이 떨어진다. (사내용 프로그램으로는 회계 처리 시스템, 사내 메일 시스템 등)
사용 편의성에 대해서 살펴 보자. Outlook같은 상용 프로그램에서 이메일을 보낼 때, 주소록에서 보낼 사람을 선택해서 drag & drop으로 메일창에 놓으면 자동으로 수신자 리스트에 반영된다. 이렇게 사용자를 편리하게 만드는 GUI는 상용 프로그램에서는 필수다. 하지만 사내용 이메일 프로그램의 경우, drag & drop을 구현해서 쓰는 경우는 없다. 대부분 사용자들이 귀찮지만 주소록에서 하나씩 선택해서 메일 작성창에 사용자를 추가시켜 준다. 즉, 상용 프로그램은 사용자가 귀찮으면 사용하지 않지만, 사내용 프로그램은 조금 귀찮아도 일을 해야 하기 때문에 해당 프로그램을 사용한다.
그럼 사내용 소프트웨어가 상용 소프트웨어와 비교했을 때 품질이 떨어지는 이유는 무엇일까? 답은 돈이다. 소프트웨어의 품질은 쏟아 부은 돈에 거의 비례하게 품질이 좋다. 즉, 90%의 품질을 달성하는데 들어간 비용과 다시 100%의 품질을 달성하기 위해서 투자되는 돈이 거의 같을 수도 있다. 따라서 사내용 소프트웨어는 왠만한 성능과 사용 편의성이 나온다면 더 이상 투자를 하지 않는다.
사내와 상용 소프트웨어의 구분은 여기서 마치고 사내용 소프트웨어를 만들기 위한 몇 가지 디자인 팁에 대해 알아 보자. 소프트웨어 분류에 대해서 상세히 알고 싶은 경우 joel on software의 Five Worlds를 참조하자.
앞서 이야기했듯이 사내용 소프트웨어에 투자되는 돈은 매우 적다. 또한 투자 대비 효과 부분이 명확해야지만이 사내용 소프트웨어를 만든다. 따라서 한정된 자원으로 목적한 바를 이루는 소프트웨어를 만들기 위해서는 디자인 시 아래의 사항을 고려해야 한다.
1. 소프트웨어의 비전을 세우자.
꿈이 없는 삶은 미래가 없듯이, 비전없는 소프트웨어 개발은 고달프다. 소프웨어에 비전을 세우자 라는 말이 무슨 뜻일까? 자다가 봉창 두들기는 소리로 들릴 수 있다. 비전의 정의에 대해서 생각해보자. 비전을 심각하게 이야기하면 어쩌구 저쩌구 현학적으로 풀어낼 수도 있지만 짧은 인생 고단하게 살 필요없다. 비전이란 간단하다. 미래에 그려지는 모습을 간단한 문장 형식으로 적어 놓은 것이다. 나의 비전은 “Software 분야에서의 최고의 Architect가 되자!” 다. 무척 간단하지 않은가? 길가는 유치원생 철이를 붙잡고 물어 봤다.
나 : 철이야 비전이 뭐니?
철이 : 비전이 뭐에요?
나 : 미안. 꿈이 뭐니?(비전이나 꿈이나 같은 뜻이다.)
철이 : 제 꿈은 과학자에요.
나 : 철이도 고달프지만, 즐거운 인생을 살겠구나…
철이는 비전 즉, 꿈이 있기 때문에 꿈을 이루기 위해서 열심히 살면 된다. 사람에게 있어서 비전은 삶의 방향을 알려주는 나침반이듯이, 마찬가지로 소프트웨어의 비전도 개발자와 설계자에게 업무의 방향성을 제시해 준다. 사내 메일 시스템을 만드는 프로젝트를 생각해 보자. 이 프로젝트에서 소프트웨어의 비전을 “제일 좋은 메일 시스템을 만들자”로 정했다. 이렇게 비전을 정하면 소프트웨어의 개발 범위는 무한대로 커진다. 생각해 봐라~ 제일 좋은 메일 시스템이 무엇일까? 메일 용량은 1G에 html 에디터 기능, 미리 보기 기능,다수의 파일 첨부 기능, Pop3 지원 등등 제일 좋은 메일 시스템을 만족시키는 고객의 요구는 끝이 없기 때문에 이런 비전 아래에서는 소프트웨어의 명세를 정하기가 무척 어렵다. 하지만 “쓰기 쉽고 매우 간단한 메일 시스템을 만들자”로 비전을 정하면 앞의 비전보다 프로젝트의 범위가 명확해진다. “쓰기 쉽다”와 “매우 간단한”이라는 어구가 한정되기 때문에 이 기준에 맞지 않는 요구는 프로젝트 개발에서 제외시킬 수 있다.(물론 개인마다 이 기준이 논란의 소지가 있지만 “제일 좋은” 보다는 구체적이라는 점에서 더 나은 비전이다.)
정리하면 명확한 비전은 고객의 요구사항을 수용할 때 기준을 제시하기 때문에, 자원이 한정되어 있을수록 명확한 비전을 세워야 한다.
2. GUI 구성은 간단하게
개발자나 설계자는 자신의 능력을 보이고 싶어한다. 잘난체는 아니고 장인 정신이 투철하기 때문이다. 그래서 사용자에게 많은 기능을 제공해 주고 싶어 한다. 특히 GUI안에서 돌아가는 로직을 만드는 것에 많은 정성을 쏟는 것보다 GUI를 멋지게 꾸미면 되돌아 오는 칭찬이 크기 때문에, 개발자들은 이쁜 GUI를 만들고 싶은 유혹에 빠진다. 하지만 앞에서 이야기했듯이 사내용 소프트웨어는 불편해도 쓸 수 밖에 없다. 불편함의 정도의 문제가 남지만, 아주 불편하지 않고 멍청한 사용성을 제공해 주지 않는다면 큰 불만 없이 소프트웨어를 사용한다. 앞에서 예를 들은 메일에서 drag & drop 기능을 제공하는 것이 필요할까? 논란의 소리가 많지만 개인적인 의견은 사내용 소프트웨어에서는 필요 없다고 본다. drag & drop 기능에 투여되는 개발 시간에 꼭 필요한 다른 기능을 개발하는게 낫기 때문이다.
GUI 부분은 재활용성이 매우 낮고 코딩이 복잡해지는 경향이 있기 때문에 개발자와 유지보수 인원이 다른 경우, 복잡한 GUI는 문제의 소지가 많다. 따라서 GUI 개발에 투입되는 공수와 유지 보수 측면 때문에 GUI는 단순하게 유지하는 것이 좋다.
3. 이미지 사용은 자제 하도록
우리나라 소프트웨어에는 이미지 사용 빈도가 매우 높다. 웹 프로그램일 때는 거의 이미지로 도배를 하기도 한다. 상용 소프트웨어(혹은 웹 프로그램일 때 쇼핑몰, 포탈)와 비교했을 때 사내용 소프트웨어에서 이미지를 사용해서 GUI를 구성하는 경우는 많지 않지만, 외국의 경우와 비교해 보았을 때는 이미지 사용 빈도가 상당히 높다.
구지 TCO(Total Cost of Ownership)를 언급하지 않아도 사내용 소프트웨어에서 비용에 주요 부분을 차지 하는 것은 유지보수비다. 따라서 유지보수가 쉽도록 만든 소프트웨어가 잘 만든 소프트웨어다. 그런데 이미지를 사용하면 유지보수성이 떨어질 수 밖에 없다. 예를 들어 text 기반으로 GUI를 꾸민 경우, IDE에서 제공하는 툴이나 간단하게는 메모장을 사용해서 GUI를 바꿀 수 있다. 하지만 이미지를 사용한 경우에는 일단 그림판을 실행시켜서 bmp 파일을 수정하거나, 파일 포맷이 다른 경우에는 다른 이미지 편집툴을 사용해야 한다. 이런 부분이 대부분 개발자와 유지보수 인원의 귀중한 시간을 허비하게 한다.
물론 고객이 이쁜 GUI를 원해서 할 수 없이 이미지를 사용해야할 때도 있다. 하지만 고객이 원한다고 모든 것을 할 수는 없다. 만일 이미지를 사용해야 한다면 사용을 최대한 자제하고, 웹의 경우에는 스타일쉬트를 최대한 활용하도록 하자. C/S 버전인 경우에는 컨트롤의 align, font 종류 및 크기, layout을 깔끔하게 함으로써 이미지를 사용했을 때의 가독성을 제공할 수 있다.
4. 표준 라이브러리를 사용
MFC를 이용해서 사내용 프로그램을 만들 때에는 SourceForge 같은 사이트에서 다양한 컨트롤과 라이브러리를 다운로드 받아서 사용하는 경우가 있다. 이런 라이브러리(control, active x 등등도 간단히 라이브러리라 부르겠다.)를 사용하는 가장 큰 이유는 개발 편의성과 MFC에서 기능을 제공하지 않기 때문이다. 하지만 MFC에서 제공해 주지 않는 비표준 라이브러리 선택에는 신중을 기해야 한다.
왜냐하면 유지보수 문제가 걸려 있기 때문이다. 개발자와 유지보수 인원이 동일한 경우에는 문제가 되지 않지만, 다를 경우에는 유지보수 비용이 들어가기 때문이다. 만일 사용한 비표준 라이브러리 학습 시간이 많은 경우 무형의 유지보수 비용이 발생하기 때문이다. 따라서 무료로 라이브러리를 다운로드 받거나 돈을 지불하고 상용 라이브러리를 사용할 때는 반드시 해당 라이브러리가 얼마나 쓰기 쉬운지도 살펴 보아야 한다.
하지만 가장 좋은 것은 되도록이면 사용하는 프레임웍에서 제공하는 라이브러리만 사용해서 사내용 소프트웨어를 만드는 것이 좋다.
정리하면서…
이상으로 간단하게 사내용 소프트웨어를 만들 때 고려해야할 디자인 팁 몇 가지를 소개했다. 다음에 시간과 생각이 정리되는대로 다른 팁도 소개하겠다.
About the Author
This is Hani! My job is consulting, system design and project management... Sometimes coding. I hope you have a great time on my blog.