[장선진] 삶을 위한 소프트웨어

항상 고민했던 부분이 소프트웨어(Software)란 무었인가?라는 물음이었습니다. 정말 어려운 이 문제에 관심을 가지는 이유는 제가 소프트웨어를 좋아하고 좋은 소프트웨어를 만들어 내고 싶기 때문입니다.



즉 소프트웨어에 대한 제 자신만의 생각을 명확하게 가지고 있어야, 삶을 위한 소프트웨어에 대한 구체적인 생각을 정리할 수 있다고 생각하고 있기 때문입니다.

따라서 저는 항상 소프트웨어란 무었인가?(What is the software?)란 질문을 스스로에게 던지곤 하였습니다.

많은 문헌들과 인터넷에서도 수 많은 소프트웨어의 정의가 있습니다. 하지만 대부분 소프트웨어의 분류를 정하고 각 분류별로 소프트웨어의 특징을 설명하여 정의하거나, 아니면 소프트웨어 개발 방법론 차원에서 소프트웨어를 바라보고 있습니다.

물론 이러한 정의 역시 틀린 것은 아닙니다.

하지만 소프트웨어는 그렇게 쉽게 정의할 수 있는 것이 아니란느 생각이 많이 듭니다.


여러분들은 소프트웨어가 무었이라고 생각하시나요 :-)


한때는 소프트웨어를 생명체과 같다고 생각하기도 하였습니다. 마치 살아있는 동물과 같은 생명체 말이죠 ;-)
현재 저와 여러분들은 모두 소프트웨어를 통하여 제가 쓴 글을 보고 계십니다. 마치 생명체가 다른 생명체에게 이야기를 하듯이요~

제가 쓴 글은 웹 어플리케이션 서버(WAS)라는 생명체에게 전달되고 이 글은 다시 DBMS라는 생명체에 전달됩니다. 그리고 DBMS는 제 글을 잘 보관하고 있다가 웹 브라우져란 생명체가 네트워크란 신경망을 통하여 WAS에 제 글을 요청하고 WAS는 다시 DBMS에 요청하여 HTML이란 넘을 재빠르게 만들어서 맛있는 쿠키(Cookie)까지 넣어서 보내주면, 웹 브라우져는 다시 OS를 통하여 여러분들이 보고 있는 모니터를 통하여 빛으로 출력시킵니다.

마치 하나의 에코 시스템(Eco System)과 같은 이러한 일련의 과정은 마치 생명체가 서로 유기적으로 얽혀있으면서 살아가는 과정과 매우 비슷하다는 생각을 하곤 하였습니다.

하지만 생명체는 원래 스스로 존재하여야 하는데, 소프트웨어는 스스로 존재하지 못하며, 스스로 진화하지 못하는 문제점이 있습니다. 이에따라 소프트웨어는 생명체와 비슷하지만 생명체는 아니다라는 결론에 도달하였습니다.

그럼에도 불구하고 소프트웨어는 진화하고 있으며, 매일 매일 인간이 산소를 먹고 이산화탄소를 배출하듯이, 소프트웨어도 전기를 먹으면서 전기를 통하여 소통하고 전기를 소모하여 인간하고 비슷하게 이산화탄소를 배출하고 있습니다.

그리고 우리가 사용하는 소프트웨어는 매일 매일 진화하고 있습니다. 이러한 진화를 소프트웨어가 스스로 만들어내지는 않지만, 인간의 도움을 받아 이제 소프트웨어와 소프트웨어간의 자유롭게 통신하여 서로 필요로하는 정보를 주고 받고 있습니다.

따라서 어느 정도 진화하고 있다고 볼 수 있습니다. 다만 진화를 스스로 하지 못하는 것은 현실입니다. 하지만 누가 아나요~


I, Robot의 VIKI (Virtual Interactive Kinetic Intelligence)나 Matrix의 Oracle과 같이 스스로 생각하는 소프트웨어가 나올지 모릅니다. :-)



여튼 아직도 소프트웨어를 생명체로 보기엔 무리가 많이 따릅니다.

그럼 소프트웨어를 무었이라고 봐야 할까요?
어림 짐작하기에도 소프트웨어는 펌웨어(Firmware)부터 미들웨어(Middleware) 및 시스템 소프트웨어(System Software) 및 게임, 그리고 사무용 소프트웨어 등등... 정말 많은 분류를 가지고 있습니다.

최근에는 iPhone의 돌풍으로 인하여 핸드폰에 탑재되는 수 많은 소프트웨어들이 각광을 받고 있습니다.
정말 iPhone 위에서 실행되는 소프트웨어는 무궁무진한데 그 중에는 오카리나를 불 수 있는 소프트웨어까지 있습니다. 제가 iPhone을 사고 싶은 가장 큰 이유가 바로 이 오카리나 소프트웨어 때문이었죠 :-)


이렇게 다양하고 많은 분야에서 활용되는 소프트웨어를 정의한다는 것은 정말 어려운 일 가운데 하나라고 생각합니다.


하지만 최근 저는 소프트웨어는 서비스이다.(Software is a Service.)라고 정의해가고 있습니다.
마치 SaaS(Software as a Service)의 짝퉁같은 이 정의는 SaaS를 접하기 이전부터 약간씩 가지고 있던 생각이지만, 사실 SaaS라는 패러다임을 접하면서 더욱 강하게 구체화해 나가고 있습니다.

생각해보면 서비스는 사람을 위하여 존재합니다.

거의 모든 서비스는 사람과 직접 관계되어 있거나 궁극적으로 사람을 위하여 존재하는 경우가 대부분입니다. 식당에서 식사를 하기 위해 웨이터에게 서비스를 받는 것은 결국 사람을 위한 서비스이며, 마찬가지로 제 글을 웹 브라우져란 넘이 여러분에게 보여주는 것 또한 웹 서핑이란 서비스를 웹 브라우져란 친절한 웨이터의 서비스입니다.

우리가 가장 많이 사용하는 웹 어플리케이션들은 대부분 어플리케이션이라고 생각이 들지 않습니다. 언제 포털 사이트나 검색 사이트를 이용하기 위하여 뭔가를 여러분의 컴퓨터에 설치한 적이 있으신가요? 아 웹 브라우져를 설치하셨군요 :-) 하지만, 꼭 어느 특정 포털 사이트나 검색 사이트를 이용하기 위해서 설치하신 것은 아니죠.

즉, 웹 어플리케이션이란 소프트웨어가 어려분에게 수 없이 많은 정보와 기능을 제공하고 있음에도 불구하고 여러분들은 웹 어플리케이션을 소프트웨어로 바라보지 않고 포털의 서비스, 검색 사이트의 서비스로 인식하고 있다는 것입니다.

마찬가지로 최근 패키지형 소프트웨어 역시 이와 유사한 행보를 보이고 있습니다. 즉 자동 업데이트 기능인데요, 언제 내가 요청하지도 않았음에도 불구하고 자동으로 업데이트를 하여 더욱 좋은 기능을 사용할 수 있도록 지원하거나 결함이 있는 기능을 수정해줍니다.


즉, 서비스가 강화된 것입니다. 소프트웨어에 서비스가 강화되다니!!이게 무슨 말이랍니까?


개발자 입장에서 소프트웨어의 개발은 정말 서비스 정신을 가지고 할 수 없는 작업중에 하나입니다. ^^;;
"내가 무슨 커피숍의 바리스타도 아니고 어떻게 서비스 정신을 가지고 소프트웨어를 만들어 냅니까?" 라고 이야기하실 수도 있지만, 소프트웨어를 사용하는 여러분 자신도 더 좋은 서비스를 제공하는 소프트웨어를 선호할 것입니다.

왜냐하면 더 좋은 서비스를 제공하는 소프트웨어가 당근 더 좋기 때문입니다.

개인적으로 웹 브라우져를 거의 무조건 화이어 폭스를 사용합니다. 우선 인터넷 익스플로러가 느리기도 하지만 질 좋은 무료 플러그인들 덕에 웹 서핑을 정말 편하게 하고 있기 때문입니다. 이 플러그인들이 없다면 제 웹 서핑은 정말 최악일 것입니다.

이런 제가 화이어 폭스를 선택한 것은 당근 화이어 폭스가 인터넷 익스플로러보다 서비스가 좋기 때문입니다.

아울러 서비스는 진화합니다. 누구를 위해서 진화합니까? 바로 여러분들을 위해서 서비스는 진화합니다.
마찬가지로 소프트웨어도 진화합니다. 바로 여러분들을 위해서 진화하는데, 사실 여러분들에게 더 좋은 기능, 즉 더 좋은 서비스를 제공하기 위해서 진화합니다.

소프트웨어 진화의 이유가 분명해졌습니다. 바로 여러분들에게 더 좋은 서비스를 제공하기 위해서 소프트웨어는 진화한다는 것이 제 생각입니다.
아울러 서비스는 결국 사람이 사람을 위해서 제공하는 것입니다.

따라서 생명체로는 풀리지 않았던 진화를 시켜주는 주체가 바로 우리 자신이며, 우리가 우리들에게 더 좋은 서비스를 제공할 수 있는 소프트웨어를 만드는 과정이 바로 소프트웨어의 진화이다. 라고 정의할 수 있습니다.

이러한 소프트웨어의 진화는 우리가 소프트웨어로부터 제공받는 서비스의 질이 만족스러울때까지 진화할 것입니다. 즉, 소프트웨어의 진화와 발전은 결국 사람을 향한다는 것입니다.

사람을 향한 질 높은 서비스를 제공할 수 있는 소프트웨어를 만드는 과정이 소프트웨어의 진화 과정이라고 볼 수 있습니다.
현재 iPhone의 돌풍으로 모바일 어플리케이션 분야에서 이러한 소프트웨어의 진화가 급격하게 진행되고 있습니다.



이에따라 오랜 저의 숙제였던 그럼 삶을 위한 소프트웨어는 무었인가? 라는 제 자신의 질문에 이제 답 할 수 있습니다.

사람들의 삶의 질을 높일 수 있는 서비스를 제공하는 소프트웨어가 바로 삶을 위한 소프트웨어라고 정의하였습니다.

이 문제로 지난 몇년간 고민해 왔었습니다만, 이제 이러한 정의를 바탕으로 더욱 삶을 위한 소프트웨어를 가열차게 만들어 가겠습니다. ^^~
감사합니다~

언제부터인지 가장 정겨운 소리 중에 하나가 구세군의 청명한 종소리인것 같습니다.
지하철에서.. 길에서 우리에게 우리 주변의 어려운 사람들을 다시한번 생각하게 하는 구세군의 종소리..

이 종소리가 없었다면 우리는 아마도 다른 어려운 이웃들을 생각하지 못하고 지나치게 될 것 같습니다.

저는 구세군의 청명한 종소리야 말로 우리에게 가장 필요한 소리라고 생각합니다.
마찬가지로 제 블로그가 여러분들에게 구세군의 청명한 종소리와 같은 블로그가 되었으면 좋겠습니다.

여러분들에게 가끔 지친 일상에 다른 것들을 찬찬히 살펴보고 생각하게 할 수 있는 블로그가 되었으면 좋겠습니다.

그리고 한가지 더 붙인다면 자선냄비와 같은 소프트웨어를 만들고 싶습니다.
정말 옛날에는 집에 쓰던 냄비에 빨간색 페인트를 발라서 사용했었을 것 만 같은 자선냄비는 우리의 마음을 녹여내 맛있는 음식을 만들어내는 진정한 냄비인것 같습니다.

우리에게도 이런 자선냄비와 같은 소프트웨어가 필요하지 않을까 생각합니다.
올해 저는 "Software in Life"란 팀을 통하여 삶을 위한 소프트웨어를 하나 만들었었습니다.

바로 "Vision Software in Life"입니다.
사람들의 삶에서 가장 소중한 비전(Vision)을 관리하는 소프트웨어였지요~

이 소프트웨어는 아직 많이 다음어져야 하고 많이 개발되어야하지만, 이 소프트웨어에는 모든 사람들이 자신이 이루고 싶은 비전을 달성할 수 있도록 도와주려는 마음이 담겨져 있습니다.

내년에는 "Vision Software in Life"를 더욱 발전시켜서 정말 자신의 비전을 실현하고 싶은 분들에게 도움을 드리고 싶습니다.
그 외에도 많은 다른 소프트웨어를 만들어서 소프트웨어의 자선냄비를 만들고 싶습니다.

올 한해동안 저의 부족한 블로그를 애독해주신 모든 분들에게 진심으로 감사드립니다.
아울러 변함없이 내년에도 더 청명한 이야기와 자선냄비와 같은 소프트웨어를 만들겠습니다.

2010년에는 모두 소망하시는 것들이 꼭 이루어지는 한해가 되시길 진심으로 기원드립니다.
감사합니다. :-)

출처: http://www.innoworks.co.kr/community/happyhours.html?mode=read&id=197&kw_name=&kw=&page=1&kindcheck=&kc=

상상력에 관한 좋은 격언이 있습니다.

상상력은 지식보다 더 중요하다.

아인슈타인(Albert Einstein)

만약 아인슈타인이 상상력이 없는 사람이었다면,  E=MC2이란 유명한 공식은 탄생하지 않았을 것이며, 우리는 블랙홀의 존재를 알 수 없었을 것이며, 빛을 통한 여행이란 것이 무었인지 알 수 없었을 것입니다.

이 모든 것은 상상력에서 시작되었습니다.

무었인가를 상상한다는 것은 정말 즐거운 일이라고 생각합니다.
하지만 정신없이 일하다보면 상상하는 것을 잊어버릴때가 있습니다.

내 앞에 닥친 이넘의 버그를 잡아야... 이 문서를 완성해야.. 이 비즈니스 로직을 완성해야.. 이 프로그램을 완성해야.. 이 소프트웨어를 완성해야.. 이렇게 바로 앞에 있는 수 많은 일때문에 즐거운 상상을 하지 못할때가 많습니다.

하지만, 가끔 이 소프트웨어에 이런 기능이 더 부가된다면.. 이 소프트웨어를 사용하는 사람 중에 이런 사람도 있다면.. 이 소프트웨어가 이렇게 발전할 수 있다면.. 이렇게 멍때리듯이 상상을 해본다면 분명히 어려분들의 소프트웨어는 더욱 풍요로워질 것이라고 생각합니다.

개인적으로 직장이 집에서 먼관계로.. 거의 두시간 가까이 걸리는 관계로 소위 멍때리는 시간이 많습니다.
이때 이런 저런 상상을 합니다.

그냥, 스쳐가는 바깥 풍경을 바라보면서, 내가 지금 만들고 있는 소프트웨어에 대한 이런 저런 상상을 합니다.

제가 만드는 소프트웨어가 가장 훌륭한 기능을 제공할 수 있다면.. 제가 만드는 소프트웨어의 UI가 사용자가 정말 쓰고 싶은 UI라면.. 제가 만드는 소프트웨어의 가치가 더 높아진다면... 이렇게 상상을 하다보면, 아 우선 이렇게 하면 되겠구나! 이런 기능이 추가되면 좋겠구나! 이렇게 함께 만들면 더 재미있겠는걸~ 등등의 생각을 하게 됩니다.

그리고 그러한 생각을 하나씩 하나씩 동료들과 나눕니다. 그리고 소프트웨어는 점점 개선되어 가고, 더욱 좋은 소프트웨어가 되어 가고 있다는 느끼고 있습니다. 물론 앞으로 가야할 길은 많이 많이 남았지만, 이러한 상상을 하나 하나씩 현실로 변화시키면서 저는 즐거움을 느끼고 있습니다.

그래서 전 소프트웨어가 가장 큰 원동력은 상상력이라고 생각합니다.
소프트웨어 개발자들의 경우 상상력이 풍부하여야 한다고 생각합니다. 주어진 비즈니스 로직대로.. 주어진 설계서대로.. 주어진 개발 방식대로.. 주어진 프레임웍대로.. 아무런 의심과 상상없이 개발한다는 것은 사실 아주 따분한 일입니다.

내 상상력이 묻어나는 소프트웨어를 만든다는 것, 그리고 그것을 함께 만들어 간다는 것, 거기에 다른 사람의 상상력까지 함께 보탠다면, 아마도 세상에서 가장 훌륭한 소프트웨어가 만들어지지 않을까요?

한번 상상해보세요 :-)
물론 시간은 걸릴지 모르겠지만, 여러분들이 만들고 꿈꾸는 것들을 상상해보세요~ 그리고 너무 큰것부터 상상하기 보다는 바로 앞에 있는 소프트웨어에 대한 상상부터 시작해보신다면, 쉽게 그리고 빠르기 여러분들의 상상을 현실로 바꿀 수 있을 것입니다.

저 역시 오늘도 오고 가는 지하철에서 그리고 차안에서 삶을 위한 소프트웨어에 대한 상상을 마음껏 하렵니다.
감사합니다. ;-)

최근 나만의 80/20 법칙 만들기란 책을 읽으면서 80/20 법칙에 많은 관심을 가지고 있습니다.
이에따라 일명 파레토 법칙이라고도 하는 80/20 법칙이 소프트웨어에 어떤 영향을 주었는지 알아보고자 합니다.

간단하게 80/20 법칙에 대하여 설명하고자 합니다.

80/20 법칙은 100여년전 이탈리아의 경제학자인 빌프레도 파레토(Vilfredo Pareto)가 처음 주장한 이후 파레토의 법칙, 파레토의 원리, 80/20 규칙, 최소 노력의 원리, 불균형의 원리 등 수많은 명칭으로 불리우는 법칙입니다.

출처: http://www.searchenginepeople.com/blog/search-and-the-pareto-principle.html

그림과 같이 핵심적인 20%의 노력으로 80%의 결과를 얻을 수 있다는 것이 이 법칙의 내용입니다.

따라서 가장 핵심이 되는 20%에 집중해야 하며, 어떻게 핵심적인 20%에 집중할 수 있는지에 관한 것이 80/20 법칙의 핵심입니다.

1950년과 1990년 사이에 일어난 "품질 혁명"은 소비재 상품은 물론 그 밖의 제품의 품질과 가치를 크게 변화시켰습니다.

사실 품질 혁명의 창시자는 루마니아 출신의 미국인인 조지프 주란(Joseph Moses Juran, 당시 전기기사)과 에드워드 데밍(Edward Deming, 당시 통계학자)이었습니다. 이 두 사람은 제2차 세계대전 이후 비슷한 시기에 자신의 이론을 각각 전개하였으나 고품질을 추구하는 미국 대기업의 흥미를 끄는 데 실패하였습니다.



하지만 아니러니하게도 일본 기업들이 주란이 출판한 "품질 관리 핸드북"이란 책에 많은 관심을 보여 1950년대 초 이 두 사람은 일본으로 건너가 당시 조잡한 품질의 물건만 생산해내던 일본 기업들에게 고품질과 높은 생산을 할 수 있는 품질 혁명을 일으키게 된 것입니다.



현재의 주란이라 데밍의 품질 혁명을 적극적으로 실천한 도요타나 일본의 전자 및 가전업체 모두 세계적인 일류기업이 될 수 있었던 것입니다.

이러한 분들은 품질에 관해서는 아키텍트와 같은 분들이십니다. 품질이란 분야는 소프트웨어에서도 마찬가지로 매우 중요한 분야입니다. 나중에 한번 꼭 읽어보고 싶은 책입니다. :-)



많은 각광을 받고 있는 식스 시그마(Six Sigma)의 기본적인 철학은 모두 주란과 데밍에게서 영향을 받았다고 생각됩니다.


Six Sigma의 프로세스에 포함된 각 단계를 어느 방법론에선가 보신것 같지 않으십니까?
최근 각광받고 있는 SOA의 방법론등과 매우 유사한 단계를 가지고 있는 것 같습니다. 과연 뿌리는 어디일까요?


중요한 점은 이 품질 혁명의 바탕이 된 것이 바로 80/20 법칙이라는 점입니다.

조지프 주란은 "파레토 법칙" 혹은 "절대 소수의 법칙"을 신봉하였은데, 그의 책인 "품질 관리 핸드북"에서 제품의 불량 발생요인에 관한 분석시 파레토의 법칙을 인용하였습니다.

"불량품의 분포는 매우 불균형해서, 결함의 대부분은 극히 일부 품질의 특성으로 인하여 일어난다"라고 말하며 균일하지 않은 부의 분포는 품질 결함에도 적용할 수 있다라고 덧붙였습니다.

특히 80/20 법칙을 통계적 품질 관리에 응용했는데요, 결함을 일으키는 원인을 중요도 순서로 나열하여 대부분의 결함을 일으키는 소수의 원인을 찾아내도록 권고하였습니다.

즉 모든 문제를 다 해결하려고 하기 보다는 "결정적인 몇 가지 문제"를 찾아서 그것을 해결해야 한다는 것입니다.

20%의 핵심적인 문제를 해결하면, 80%의 중요하지 않은 문제들도 자연스럽게 해결된다는 의미입니다.

스프레드시트 부분에 자료를 입력하거나 가져오십시오. 그리고 원하는 부분을 블록으로 설정한 후 메뉴에서 6가지 그래프 모양 중 원하는 모양을 선택하여 주십시오. 막대 그래프 관리도, 런차트, 산포도, 원 그래프 및 파레토 그래프 중 원하는 유형의 도표를 한번의 클릭으로 작성하실 수 있습니다.

파레토 그래프는 80/20 법칙이 적용되어 있어서, 예를 들어 천가지 소비자 불만 사항 중 약 800가지는 원인의 20%만 없애면 해소할 수 있다는 점을 보여줍니다.

-ABC Data Analyzer 설명 메뉴얼 중에서

이러한 80/20 법칙을 품질관리 뿐만 아니라 문제도 많고 버그도 많은 소프트웨어에 적용한다면 어떻게 될까요?

흔히들 소프트웨어는 자동차와 같이 모든 기어들이 착착 맞아서 일사분란하게 움직여 완벽한 처리를 할 것이라고 생각하는데, 실제 소프트웨어를 사용하다보면 예기치 않은 문제나 버그를 만나는 경우가 무척 많습니다.

저의 경우 엔터프라이즈용 소프트웨어를 개발하는 경우 다양한 고객의 요구사항에 맞도록 구축하다보면 소프트웨어 자체의 결함이라기 보다 고객 관점이 잘못되어 있거나 해당 조직의 비 논리적인 관행 등으로 인하여 프로세스 자체가 잘못되어 있는 경우가 많습니다.

이렇게 프로세스가 잘못되어 있는 경우에는 프로세스를 바로 잡지 못하면, 어쩔 수 없이 소프트웨어의 결함이 유발되어 사용자들에게 좋은 서비스를 제공할 수 없게 됩니다. 그리고 정확하게 추산해보지는 않았지만 이러한 문제로 발생하는 버그가 전체 버그의 대부분을 차지한다는 점입니다.

즉 20%의 잘못된 프로세스만 고치면, 80% 넘는 버그를 제거할 수 있다는 것입니다.
이미 이런 관점에서 소프트웨어 개발이 이루어 지고 있습니다.


1960년대 시작된 정보 혁명은 비즈니스의 많은 분야에서 작업 습관과 효율성을 크게 바꾸어 놓았습니다.
정보 혁명을 뒤에서 추진하는 컴퓨터와 소프트웨어 전문가드은 품질 운동을 가까이에서 접한 사람들이기 때문에 일반적으로 80/20 법칙에 대하여 잘 알고 있으며 이를 광범위하게 적용하였습니다.


사례를 살펴보면 다음과 같습니다.

RISC는 80/20 법칙이 적용된 사례라고 할 수 있습니다.

RISC는 변형된 80/20 법칙을 토대로 개발되었다.
즉 대부분의 소프트웨어가 실행시간의 80%를 전체기능의 20%만을 사용하는데 쓰인다는 것이다.

RISC 프로세서는 그 중요한 20%를 최대한 활용하고, 나머지 80%를 제거함으로써 칩 사이즈와 비용을 크게 낮추었다.

소프트웨어를 사용하는 사람들의 소프트웨어 사용빈도는 80/20 법칙을 따르고 있습니다.
1994년 MacWeek에 다음과 같은 내용이 있다고 합니다.

비즈니스 세계는 오랫동안 80/20 법칙을 따라왔다.

소프트에어의 경우, 제품 사용시간의 80%가 전체기능의 20%에만 집중되어 있다는 점에서 특히 그렇다.

이는 사용자가 필요로 하지 않고 원하지도 않는 부분에 돈을 낭비하고 있다는 것을 의미한다. 소프트웨어 개발자들은 드디어 이 사실을 깨닫고 이 문제를 모듈화된 응용 프로그램으로 해결하려고 하고 있다.

지금보다 10년 이전인 1994년에도 지금과 비슷한 생각을 했네요 ;-)
아직도 이 문제는 별로 해결된 것이 없나 봅니다. ㅎㅎ

다른 예를 한번 살펴보겠습니다.

워드퍼펙트(WordPerfect)나 다른 소프트웨어 개발자들은 어떻게 이 문제를 해결하는가?
먼저 개발자들은 사용자들이 가장 원하는 것이 무엇이고 그것을 어떻게 사용하고 싶어하는지를 파악한다.

이것이 80/20 법칙이다.

사람들은 프로그램 사용 시간의 80%를 기능의 20%만 사용하며 보낸다.
따라서 우수한 소프트웨어 개발자들은 자주 쓰이는 기능들을 가장 단순화하고 자동화하여 쓰기 쉽도록 한다.

사실 이 예가 저에게도 해당되는데요~ 거의 모든 소프트웨어를 사용하는 경우 아마 거의 20% 정도의 기능만 중점적으로 사용합니다. 따라서 가끔 수 많은 메뉴와 기능 리스트를 볼 때 과연 저 속에 내가 원하는 것은 무었일까? 라고 생각하게 됩니다.

그래서 출현한 것이 마이크로소프트사의 리본 메뉴(리본 형식의 메뉴)입니다.



마이크로소프트의 오피스 2007을 사용하는 사용자를 어리둥절하게 만들었던 리본이란 새로운 메뉴 스타일도 결국 수 많은 기능중에 사용자가 가장 많이 사용하는 기능에 초점을 둔 사용자 인터페이스(UI) 형식입니다.

사실 이 새로운 메뉴 형식은 아직도 논란이 많습니다.
특히 "사람의 뇌의 구조상 계층화하여 표현하는 것이 가장 효과적이다."라고 주장하는 쪽에서는 리본 메뉴는 체계도 없고 기준도 없는 엉터리 UI라고 혹평하고 있습니다.

사실 저도 기존 메뉴나 툴바 형태가 더 편하지 않았나 생각됩니다. 하지만 어느새 리본에 익숙해져가고 있네요..-.-
기존 툴바 및 메뉴 형식의 UI 역시 단점은 있어서 이렇게 될 수 있다는 점입니다.


거의 이렇게 사용하시는 분은 없으시죠 ;-)

이처럼 소프트웨어 분야에서는 활발하게 80/20 법칙을 적용하려고 노력하고 있습니다.

따라서 여러분들이 소프트웨어 개발자라면 지금 만들고 있는 소프트웨어의 핵심 기능이 무었인지 식별하여야 합니다. 그리고 식별된 가장 중요한 20%의 기능을 최대한 잘 만들기 위하여 노력하여야 합니다.


하지만 과연 소프트웨어 분야에서 80/20 법칙을 적용하는것이 말처럼 쉬울까요?

마이크로소프트 역시 리본 메뉴를 만들때 핵심 20%의 기능을 더욱 쉽고 편리하게 사용할 수 있도록 배려하기 위하여 만들었을 것입니다.

하지만 여기에 함정이 있습니다.

"과연 20%의 사용자란 누구를 지칭하는 것인가?" 라는 문제입니다.
만약 여러분이 MS처럼 소프트웨어를 만들고 있는 입장이라면 20%의 사용자를 어떻게 볼까요?

MS 워드 기준으로 살펴볼 때 MS 워드는 전 세계에 수 많은 사용자가 있습니다. 이것이 하나의 문제가 될 수 있는데요~ 동양권에서는 표를 자주 사용하지만 서양권의 문서에서는 거의 표를 사용하지 않습니다. 동양권에서는 이태릭체를 좀처럼 사용하지 않지만, 서양권에서는 많이 사용합니다.

이런 문화적인 차이를 생각해볼 때 과연 리본메뉴에 표 관련 기능은 어떻게 배치하는게 좋을까요?


이것이 20%의 함정입니다.
모든 사용자를 너무 일반화한다면 정작 중요한 사용자를 위한 기능을 놓칠 수 있습니다. 제가 읽은 나만의 80/20 법칙 만들기란 책에서도 이러한 일반화된 오류에 대하여 언급하고 있습니다.


약간 다른 이야기를 하면 최근에는 오픈소스 소프트웨어의 약진으로 인하여 소프트웨어 간의 기능상의 명확한 우위성을 확보하기가 어려지고 있습니다.

만약 MS Office가 없더라도 Open Office에 MS Office가 지원하는 기능의 거의 모든 것들을 제공하고 있으므로 크게 걱정하지는 않습니다. 다만 서로 호환문제 때문에 킬러 어플리케이션인 MS Office를 사용하고 있을 뿐입니다.

즉 이미 경쟁 소프트웨어간 가장 중요한 20%의 기능은 대부분 수준이 비슷하다는 것입니다.

워드의 경우 표그리기, 스타일 정의하기, 폰트 지정하기 등등이 기본적인 20%의 기능은 제가 볼때 Open Office나 MS Office 모두 별 차이가 없습니다. 이미 20%의 핵심 기능은 모든 경쟁 소프트웨어가 충분히 갖추어져 있다는 것입니다.


이러한 문제에 관해서 우리에게 좋은 시사점을 던져주는 조엘 아저씨의 Strategy Letter IV: Bloatware and the 80/20 Myth란 글을 참고해 보시기 바랍니다.

간략하게 소개하면 다음과 같습니다.

만약 워드프로세서를 만드는데 20%에만 집중하여 개발하였다고 하자.

훌륭하게 동작하는 20%의 기능이 완성되어 이 워드프로세서를 판매하려고 하는데 한 작가가 "이 워드프로세서는 단어수를 셀 수 있나요?"라고 물었다.

당연히 20%의 기능에 없는 기능으로 워드프로세서에는 구현되어 있지 않았다. 하지만 작가 입장에서는 기고할 원고의 분량을 체크하기 위하여 반드시 단어수를 셀 수 있는 기능이 필요하였다.

과연 이 작가가 요구하는 기능이 20%의 핵심기능일까? 이 작가는 20%의 핵심적인 사용자일까?

여하튼 결론은 이 워드프로세서는 작가의 혹평을 받으며 팔 수 없었다는 것이다.

이것이 조엘이 이야기하는 80/20 법칙의 신화입니다.

소프트웨어에 있어 기능 관점에서 80/20 법칙을 적용시키기에는 무리가 따릅니다.

하지만 단위 테스트 관점에서 80/20 법칙을 적용시킨다면 많은 의미가 있을 것 같습니다. 경험상으로 가장 근본이 되는 에러를 해결하면 자연스럽게 나머지 에러가 해결되는 경우가 많았습니다.
단위 테스트에 대한 실제적인 사례나 통계를 한번 알아봐야겠습니다.


결론적으로 말씀드리면 80/20 법칙은 소프트웨어의 기능을 정의하고자 할 때 핵심적인 기능에 집중할 수 있는 논리적인 근거를 제공합니다.

하지만 현재의 소프트웨어 환경에서는 핵심적인 20%의 핵심 기능만 제공하기에는 무리가 따릅니다.

따라서 핵심적인 20%의 기능과 함께 80%의 특화된 기능을 제공하여 소프트웨어의 경쟁력을 높여야 할 때라고 생각됩니다.

그런 의미에서 롱테일 법칙도 좋은 논리적인 기반을 제공하여 준다고 생각됩니다. 나중에 한번 롱테일 법칙을 기준으로 소프트웨어를 바라보겠습니다.

80/20 법칙을 기본으로 소프트웨어를 개발하면서 80%로 자연스럽게 확장할 수 있는 방안을 마련한다면 매우 유익한 소프트웨어를 개발할 수 있을 것 같습니다.

이상입니다~ 감사합니다. ;-)

나만의 80/20 법칙 만들기란 책에서 많은 부분 참고하였습니다.