80/20 법칙, 그리고 소프트웨어

최근 나만의 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년대 초 이 두 사람은 일본으로 건너가 당시 조잡한 품질의 물건만 생산해내던 일본 기업들에게 고품질과 높은 생산을 할 수 있는 품질 혁명을 일으키게 된 것입니다.

출처: http://www.amazon.com/Quality-Handbook-McGraw-Hill-International-Editions/dp/0071165398/ref=sr_1_1?ie=UTF8&s=books&qid=1228867990&sr=1-1

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

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

출처: http://www.amazon.com/Architect-Quality-Autobiography-Joseph-Juran/dp/0071426108

많은 각광을 받고 있는 식스 시그마(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 법칙 만들기란 책에서 많은 부분 참고하였습니다.