소프트웨어를 구현한다는 것은?

소프트웨어는 무엇이라 말할 수 있는가 ?

소프트웨어란 프로그램과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체를 말한다. 소프트웨어에 프로그램 이외의 문서와 정보를 포함시키는 이유는 이들 모두가 소프트웨어 생산 행위의 결과이기 때문이다. 또한 프로그램은 프로그램 언어로 작성된 코드, 즉 정적인 표현을 의미하지만 소프트웨어는 프로그램이 컴퓨터를 가동시킨다는 동적인 의미도 포함하고 있다.

소프트웨어는 종이나 자기 디스크와 같은 유형의 매체에 저장되지만 개념적이고 무형적이다. 건축이나 자동차는 그 생산물을 보고 그 구조를 쉽게 파악할 수가 있으나 소프트웨어는 그 생산물의 구조가 코드 안에 숨어 있다. 이를 소프트웨어의 비가시성(invisibility) 이라고 한다. 소프트웨어의 다른 특성으로 복잡성(complexity)을 들 수 있다. 소프트웨어는 개발 과정이 복잡할 뿐만 아니라 전산화 대상 업무, 소프트웨어 시스템 자체가 난해하다. 소프트웨어는 수학이나 물리학에서 볼수 있는 규칙적이고 정형적인 구조가 없다. 요구나 환경의 변화에 따라 적절히 변형시킬 수 있는 특징(conformity)이 있다.

[Brooks, 1987]

소프트웨어를 정의하는 것은 어려운 일이지만 다음과 같은 특징을 가지고 있다고 본다.

• 소프트웨어는 부드럽다(soft). 적응력이 있으며 변경되기도 한다. 기계 엔지니어들이 설계하고 구현한 물리적 장치와는 매우 다르다.
• 광범위하게 적용될 수 있는 몇 가지 소프트웨어 규칙들이 있다. 화학 엔지니어와 전기 엔지니어들은 물리학과 화학의 기본 원칙을 따라 설계한다. 만약 소프트웨어 법칙이 있다면 아직 그것들을 발견하지 못한 것 같다. 컴퓨터 하드웨어 디자이너들은 정확한 공식을 사용하면 그들이 설계하는 칩에서 발생하는 열의 양을 계산할 수 있지만 소프트웨어 엔지니어들은 프로그램 사이즈 같은 제품 속성을 측정할 방법 조차도 합의에 이르지 못한다.
• 소프트웨어는 대량으로 생산되지 않는다. 자동차 같은 경우는 대량 생산이 가능하다. 액세서리는 변화시킬 수 있지만 기본 디자인을 반복적으로 사용한다. 소프트웨어는 그렇지 않다. OS 같은 특정 프로그램을 복사하여 수백만 사용자들에게 배포할 수는 있지만 단 하나의 실제 프로그램만 구현해야 한다. 제조 과정에는 카피를 만드는 것이 포함되지만 또 다른 동일 제품을 구현하는 것은 포함되지 않는다.
• 소프트웨어의 스펙은 지속적으로 변한다. 심지어 개발 사이클 후반에도 바뀔 수 있다. 절반 정도가 완성된 다리를 보고, "저기요, 내가 보기에 이 다리가 여기 보다는 저쪽에다 짓는 것이 나을 것 같은데요! " 라고 말하는 고객은 없을 것이다. 불행히도 그와 같은 요구 사항에 대한 변경 요청은 소프트웨어에는 끊임없이 발생한다.

 

소프트웨어 공학이란 ?

소프트웨어 공학이란 소프트웨어의 품질과 생산성을 향상시키기 위하여 사용자의 요구사항을 체계적으로 분석하여 설계 및 구현, 구현된 시스템의 시험 그리고 유지보수 및 폐기 시까지 소프트웨어 전수명주기 간에 걸쳐 이루어지는 체계적인 접근법을 말한다.

[Sommerville, in “Software Engineering”]

소프트웨어 엔지니어링은 신뢰성 있고 실제 머신에서도 효율적으로 작동하는 소프트웨어를 얻기 위해 올바른 엔지니어링 원칙을 확립하고 사용하는 것이다

[A Report on a Conference Sponsored by the NATO Science Committee. NATO 1969]

“The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software.

(소프트웨어의 개발, 운영 및 유지보수에 체계적이고, 훈련이 잘 된 정량적인 접근 방법을 적용하는 것으로,소프트웨어 개발및 관리를 공학적으로 접근하는 것을 말한다)”

[Definition by IEEE Computer Societ]

즉, 소프트웨어 공학이라는 것은 소프트웨어의 개발, 운영 및 유지 보수에 체계적이고, 훈련이 잘되고 정량적인 접근 방법을 적용하는 것을 의미하며, 이는 곧 소프트웨어에 공학적으로 접근하는 것을 말한다. 1968년10월 7일 ~ 11일 간 열린NATO 소프트웨어 엔지니어링 컨퍼런스에서 소프트웨어 위기(Software Crisis)라는 용어가 처음 언급된 이후 소프트웨어 개발에 공학적인 접근 방법의 필요성이 제기되면서 소프트웨어공학이라는 용어가 처음 소개되었으며 이후로 약간씩의 수정이 가해졌지만 소프트웨어공학의 정의는 대체로 유사한 내용을 담고 있다.

이러한 역사적 배경때문에 소프트웨어 공학의 출발은 상업용 어플리케이션이 아닌 국방 또는 정부 시스템을 개발하기 위한 요구사항들을 충족시키기 위하여 발전되었다. 실재로 소프트웨어 개발에서 체계적이고, 훈련되고, 정량화를 통한 측정 가능한 접근방식은 안정성이 최우선 가치가 되는 시스템 개발에서 아주 효과적인 것으로 증명되었다. (그러나 상업용 어플리케이션은 안정성이 최우선 되는 시스템과는 다르다.)

소프트웨어공학 관련 기술 및 지식은 다양한 분류가 가능하겠지만 2004년 IEEE 컴퓨터 학회는 소프트웨어공학 전체를 10개의 기술 분야로 분류하고 각 기술별로 필요한 상세 지식을 정의한 Guide to SoftWare Engineering Body Of Knowledge (SWEBOK 2004) 를 내놓았다. (소

프트웨어 공학자가 알아야할 지식의 범위에 대한 표준 ISO/IEC 24773) 

1. 소프트웨어 요구 사항
2. 소프트웨어 설계
3. 소프트웨어 구현
4. 소프트웨어 시험
5. 소프트웨어 유지 보수
6. 소프트웨어 형상 관리
7. 소프트웨어 공학 관리
8. 소프트웨어 공학 프로세스
9. 소프트웨어 공학 도구 및 방법
10. 소프트웨어 품질

그러나 소프트웨어 공학은 진실 또는 거짓의 개념이 아닌 유용한가/유용하지 않는가 의 개념이다. 유용한가의 여부는 해보지 않고서는 알수 없다. 무턱대로 비판없이 사용하는 것은 브룩스가 이야기한 은빛 총알과 다르지않다.

소프트웨어 라이프사이클(Software Life Cycle)

소프트웨어 라이프사이클이란 소프트웨어를 생산하기 위해 필요한 모든 활동들을 설명하는 모델을 의미한다. 소프트웨어를 개발하는 스타일이라고 할 수 있다. 비슷한 용어로 소프트웨어 프로세스(Software process), 소프트웨어 개발 프로세스(Software Development Process) 가 있다.

소프트웨어 개발의 각 단계와 절차는 어떤 입장(스타일)에서 소프트웨어를 만드느냐에 따라 조금씩 다르며, Waterfall, Spiral, Prototyping, Incremental, Evolutionary 등 여러가지 모델들이 있다.

유사한 용어인 소프트웨어 개발 방법론은 소프트웨어 공학의 원리를 소프트웨어 라이프 사이클에 적용한 개념으로 소프트웨어를 생산하기 위해 반복적으로 수행되는 작업활동, 절차, 산출물, 기법등을 체계적으로 정리한 것이다.

성공적인 소프트웨어 개발

성공적인 소프트웨어 개발은 비용, 납기, 품질 3가지 요소를 만족시킬수 있음을 의미한다.

IBM 386 메인 프레임의 아버지인 프레드 브룩스는 "No Silver Bullet" 에서 "하드웨어의 생산성과 같은 소프트웨어 개발의 생산성을 10배 향상시킬수 있는 마법과 같은 해결책은 없다" 라고 단언한다.

1994년 베일에 감추어진 SW 프로젝트의 성공과 실패에 대한 보고서로 많은 이들의 주목을 받았던Standish Group 의 정기적 보고서 통계 자료에 따르면 SW 프로젝트 성공률은 2009년을 제외하고 년간 1.7% 정도 성공률이 개선되는 것으로 보여진다. 이러한 경향이 계속된다면 2014년에는 SW 프로젝트 성공률은 50% 에 이를것으로 추정하고 있다.

	날짜	성공률
First CHAOS 보고서	1994	16%
"Extreme CHAOS"	2001	28%
CHAOS	2003	31.1%
CHAOS	2006	35%
CHAOS	2009	32%

성공적인 소프트웨어 개발을 위하여 방법론과 도구 관련하여 엄청난 투자가 이루어 졌다.

소프트웨어 구현

소프트웨어에서의 구현(Construction)이란 소프트웨어를 구성하는 프로그램과 관련 여러 산출물들을 만들기 위하여 필요한 실무적 활동(Activity)들을 의미한다.

보통 소프트웨어 구현은 아래의 그림이 보여주듯이 소프트웨어 라이프사이클 모델에서 상세설계 > 코딩 과 디버깅 > 시스템 테스트 단계(Phase) 를 구현이라고 표현 한다.

스티브 맥코넬은 그의 저서 Code Complete 2 에서 기존의 시각과는 조금 다르게 구현(Construction)을 라이프사이클 모델의 특정 단계(Phase)가 아닌 활동(Activity)으로 보고있다.  아래 그림은 소프트웨어 개발 활동들과 연관된 구현의 위치를 보여준다.

그림에서 구현의 대부분의 활동은 코드 작성과 디버깅이며, 상세설계, 구현 계획, 단위테스트, 통합, 통합 테스트와 같은 활동들도 수반한다.

또한 스티브 맥코넬은 소프트웨어 구현은 다음과 같은 이유에서 아주 중요하다고 말한다.

구현은 소프트웨어 개발에서 큰 비중을 차지한다.

구현은 소프트웨어 개발 과정에서 중심적인 활동이다.

구현에 집중함으로써, 프로그래머 개인의 생산성을 극대화할 수 있다.

구현의 결과물인 소스 코드만이 소프트웨어를 정확하게 설명한다.

구현은 반드시 수행되는 유일한 활동이다.

참고서적 및 자료

Software engineering: Report of a conference sponsored by the NATO Science Committee

Steve McConnell, Code Complete 2

Steve McConnell, Professional software development

Guide to SoftWare Engineering Body Of Knowledge (SWEBOK 2004)

R.S. Pressman,  Engineering: A Practitioner's Approach

Gray Pollice, http://www.ibm.com/developerworks/kr/library/pollice/index.html

구글 검색통계로 보는 Springframework 인기

여기 저기에서 스프링프레임워크를 사용하고 있는데 과현 전세계적으로 인기는 어떻까?

간단하게 구글 검색통계에서 "springframework" 검색어에 대한 지역/도시 별 관심도을 보았다.

지역별로는

한국>홍콩>인도>싱가포르>노르웨이>대만>중국>러시아>스위스>오스트리아

도시별로는

서울>Bangalore>홍콩>베이징>싱가포르>상하이>샌프란시스코>도쿄>위싱턴>뉴욕

위의 결과만 보아도 국내의 스프링 프레임워크에 대한 열기는 대단한 것으로 보인다.

언제부터 이렇게 관심이 높아졌을까를 알아보기 위해서 지역을 한국에 국한하여 검색을 해본다 결과에 따르면 2006년 부터 관심도가 급증한 것으로 보인다.

 

다른 지역들과의 비교를 위해서 이번에는 한국,미국,인도, 몇몇 지역별로 비교하여 검색해본다. 재미있는 것은 한국과 같이 눈에띄게 관심도의변화 추이가 나타나는 국가는 없다는 것이다.

너무 특정 기술을 신봉한는 듯한 모양새가 보이는 것 같기도 하다.

소셜 미디어 혁명

소셜 미디어는 단순한 유행에 불과한가? 아니면 산업혁명 이래 가장 큰 변화인가? 소셜 노믹스에 오신것을 환영합니다. 소셜 미디어는 웹 사용 목적에 있어 포르노 서비스를 제치고, 어느덧 NO 1 이 되었다.

고성능 자바 프로그래밍 - 동기화

프로세스와 스레드

프로세스는 여러 컴퓨터 프로그램들을 동시에 실행할 수 있는 컴퓨터 시스템에 의해서 순서되로 실행된는 하나 또는 그이상의 스레드로 구성된  컴퓨터 프로그램의 인스턴스이다.

컴퓨터 프로그램은 수동적인 명령(어)들의 모음이지만, 프로세스는 이러한 명령(어)들의 실재 실행을 의미한다.  예들들어 같은 컴퓨터 프로그램의 여러 인스턴스들을 시작한다는 것은 하나 이상의 프로세스가 실행된다는 의미이다.

단일 컴퓨터 CPU는 (클럭 사이클 마다)  한번에 하나 또는 그 이상의 명력(어)들을 실행한다. (슈퍼스칼라 CPU 아키텍처 참조)

사용자가 여러 프로그램을 한꺼번에 실행하려면, 단일 CPU 시스템은 시분할(time-sharing) 을 할 수 있어야 한다. 시분할(time-sharing)은 프로세스들이 실행과 실행대기 사이를 전환(switch)할 수 있게 하는데, 대부분의 경우 전환은 아주 빠르게 이뤄지기 때문에, 여러 프로세스들이 동시에 실행되는 것과 같은 효과를 제공한다. 하나 이상의 CPU 을 사용한다면 보다 실제에 근접하는 동시 실행을 가능하게 할 것이다.

자바가상머신을 프로세스라고 한다면 스레드는 자바가상머신에 의하여 수행되는 바이코드 명령들의 순서라고 볼수 있다. 스레드에는 명령들의 순서, 메소드들의 의하여 사용되는 지역변수와 인자들(런타임 스택)이 저장된다. 스레드들은 자신만의 런타임 스텍을 갖고 있기 때문에 지역변수와 인자값들은 항상 스레드에 안전하게 된다. 즉 어떤 스레드에서 다른 스레드의 러타임 스텍에 접근할 수 있는 방법이 제공되지 않는 것이다. 이러한 이유에서 힙 메모리에 저장된는 정턱 필드와 객체의 모든 필드들에 대한 접근이 없는 메소드는 다른 스레드들로 부터서 안전하게 동작할 수 있다.

스레드에 안전하다는 것(thread-safe)은 메소드가 다중 스레드 환경에서 안전하게 동작할 수 있다는 것을 의미한다. 즉 스레드는 프로세스 수준 (자바가상머신의 스텍) 에서 공유되는 데이터를 여러 다른 스레드들과 함께 안전하고 효율적으로 접근할 수 있어야 할 것이다.

동기화

스레드 안정성의 핵심에는 동기화라는 개념이 있다. 동기화란, 여러개의 스레드가 동시에 안전하게 동작할 수 있게 하는 매커니즘을 의미한다. 자바는 다음 두가지 고유한 동기화 매커니즘을 가지고 있다.

• 동기화된(synchronized) 블럭과 함수
  
• 휘발성(volatile) 변수

전통적으로 시스템의 한정된 자원이 특정 프로세스에 점유되었는지 여부를 표시하기 위하여 세마포어(Semaphore)라는 용어를 많이 사용한다. C에서는 시스템의 모든 자원들은 세마포어라는 플래그가 존재하고 이 세마포어를 먼저 획득한 프로세스 만이 리소스를 점유하여 사용하는 개념으로 사용된다.

 

세마포어는 수기신호라는 의미이다. 즉, 어떤 자원의 상태를 수기신호에 비유해 운영체제 내부에서 사용가능, 또는 사용불가의 상태를 관리하는 정도로 이해하면 된다. 시스템 관점에서는 동시에 다수의 프로세스가 동일한 자원을 점유하여 시스템이 불안정해지는 것을 방지하기 위한 개념이라고 할 수 있다.

 

자바는 이 개념을 객체에 적용하여 뮤텍스(mutex:Mutual Exclusion)라는 용어로 부른다.  즉, 동시에 하나의 객체 인스턴스에 접근할 수 있는 스레드는 오직 하나만 존재하여야 한다는 개념이다.

 

다른 말로는 객체 락(Object lock) 라고 표현하기도 하는데 각 객체에 해당하는 락를 먼저 획득하는 스레드가 해당 객체을 사용할 수 있다는 개념이다. 당연이 락(lock)을 획득한 스레드가 락을 풀어주기 전에는 다른 스레드는 그 객체를 사용할 수 없게 된다.

동기화을 사용하면 어떤 스레드가 락을 획득하든지 스레드는 주어진 변수들에 대한 단독 접근과 변경을 할 수 있도록 보호받으며, 스레드들이 다음으로 락을 획득할때 변수들이 보여지게 된다.

동기화에 가장 문제시 되는 부분은 오버헤드이다. 만일 스레드들은 서로 락을 획득하기 위하여 지나치게 경쟁을 하게 되면, 아주 비효율적으로 동작하게 된다. 락을 이용한 동기화의 또다른 문제는 어떤 이유에서 락을 가지고 있는 스레드가 지연된다면, 어떤 스레드로 락을 획득하지 못하게 된다.

휘발성(volatile) 변수는 "synchronized" 의 가시성 기능을 제공한다. (원자성 기능을 제공하지 않는다.) 이는 스레드들은 자동적으로 가장 최근에 수정된 휘발성(volatile) 변수 값을 볼수 있음을 의미한다. 아주 제안된 경우에만 사용한다면 스레드에 안전한게 동작할 것이다.

• 자신의 현재 값에 의존하지 않는 변수에 사용.
  
• 다른 변수들과 함께 변하지 않는 값으로 사용되지 않는 경우.
  

마이크로소프트 미래의 컴퓨팅 2029

마이크로소프트 Office lab 팀에서 최근 와튼 비즈니스 테크놀로지 컨퍼런스에서 공개한 미래 컴퓨팅 '2019' 비디오...

주로 MS surface와 각종 터치스크린,E-book 기기들의 광범위한 사용을 보여주고 있다.

(아래 PPT는 마이크로소프트 비즈니스 디비전 사장 Stephen Elop의 프레젠테이션 자료)

 

 

그래픽 디자인의 이해

이태리 출신의 디자이너 마시모 비넬리 (Massimo Vignelli, 1967년 아메리칸 에어라인 로고 디자인, 1995년 베네통 로고 디자인등...)가그의 디자인 철학과 그래픽 디자인 (타이포그래피)의 기본적인 이해를 돕기 위한 96페이지 분량의 무료 PDF를 배포하고 있다.

 

다운로드는 요기클릭

 

제품 디자이너 필수 소프트웨어 기술

미국 웨스턴 와싱턴 대학 산업디자인과 교수인 Jason Morris가, 미국 IDSA 월간 뉴스레터 2007년 3월부터 2008년 10월까지 실린 구인광고 (제품디자인만, 그래픽디자인은 제외...)를 분석하여 업체에서 가장 많이 요구하는 SW Tool 리스트를 작성하였다. 1등은 일러스트레이터, 2등은 포토샵... Alias가 4위, Rhino3D는 6위, 오토캐드는 9위...

 

 

Industrial Design Sandbox: Is Illustrator the New King of ID Software?

 

아작난 세계경제을 초현실주의화풍으로 표현하면

2008년 9월에 퍼블리쉬된 아작난 세계경제를 패러디한 브라질 AE Inventimentos의 초현실주의 프린트 광고 씨리즈.

 

 

소프트웨어 공학에서의 화물숭배

이미지출처 : www.codeforsomething.com

다음글은 아인슈타인 이후 최고 천재로 평가되었던 미국의 물리학자  리차드 파이먼 교수가 1974년 캘리포니아 공대 학위 수여식에서 행한 연설의 일부이다.

 

예전에 남태평양 어떤 섬에는 화물 숭배라는 종교를 믿는 사람들이 있었다. 당시에 섬 하늘에는 전쟁 물자를 수송하는 비행기들이 많이 다녔고, 섬 사람들은 비행기를 신의 전령이라 믿었다. 그들은 언젠가 신이 자신들에게도 비행기에 엄청난 물자를 실어 보내줄 것이라고 생각했다. 그래서 비행기가 섬으로 착륙할 수 있도록 활주로 비슷한 것을 만들기 시작했고, 활주로 좌우에는 유도등처럼 불을 피워 놓았다. 또 사람이 들어와 앉을 수 있도록 관제탐 같은 통나무 집도 만들었고, 대나무를 깎아 안테나처럼 달아 놓았다. 그 안에서 나뭇가지를 헤드셋처럼 묶고 앉아, 비행기가 착륙하기만을 하염없이 기다렸다. 그들은 이전에 다른 곳에서 본 진짜 활주로의 모습을 재현했다. 적어도 그 형태만큼은 완벽했다. 그러나 비행기는 오지 않았다. 나는 섬 사람들이 "과학적인 연구의 형태와 지침"을 따르기 때문에, 이것을 화물 숭배 과학이라 부른다. 그들은 뭔가 중요한 것을 잊고 있음이 분명했다. 왜냐하면 비행기가 한 대도 오지 않았기 때문이다.

파인먼은 소위 과학자들 가운데서도 과학적 방법의 모든 형식은 갖추었지만 존경이나 지원할 가치라고는 조금도 없는 유사과학(pseudo-science)이 있음을 지적하며, 이를 화물 숭배 과학이라 하였다. 그는 또한 정직함과 성실성이 결여된 과학을 화물 숭배와 다를 바 없는 유사과학으로 규정하여 크게 주의할 것을 당부하였다.

 

그의 연설 가운데 가장 놀라운 것은 정직한 과학을 위한 제1원칙으로 "스스로를 속이지 말라"는 원칙을 제시한 것이다. 그는 세상에서 가장 속이기 쉬운 것은 자기 자신이며, 자신을 속이지 않는다면 다른 과학자들을 속이지 않는 것도 쉬운 일이라고 하였다. 실험 결과가 유명 과학자의 논문에서 참조한 결과와 다를 때 별다른 가책 없이 자신의 실험 결과를 무시하고 참조한 결과를 존중한다든지, 예측된 결과와 일치하는 실험 결과만을 논문에 포함시키고 다른 결과의 발생 자체를 언급하지도 않는 행태 등은 스스로를 속이는 대표적인 부정직함의 사례일 것이다.

스티브맥코넬은 "프로페셔널 소프트웨어 개발" 에서 소프트웨어공학에서도 화물숭배 현상이 있음을 지적한다.  

 

소프트웨어 개발 방식에는 잘 짜인 계획, 잘 정의된 프로세스, 효율적인 시간사용,  오랜 경험을 통해 좋다고 판명된 소프트웨어 공학 기법들을 적용하여 프로젝트를 성공시키는 "프로세스 기반 개발"과 해당 분야의 최고 인재를 고용하고 전권을 위임을 통하여 동기를 부여하는 "책임 기반 개발" 있다.

 

이 두 개발 방법은 각각 현명하게 사용한다면, 비용을 절감하고 개발기간도 단축하면서 품질 좋은 소프트웨어를 만들어 낼수 있다. 그러나 두가지 방법다 완벽하게 실행되기는 어렵고, 제대로 수행하고 있는 지 알아내기도 어렵다. 그러나 대부분의 조직은 문제의 본질이 아닌 흉내내기에 머문다.

"프로세스를 중시한다고 사칭하는 조직"을 "관료조직"이라고 부른다. 이들은 소프트웨어 프로세스의 형태를 그 본질보다 더 중요하게 생각한다. 프로세스를 잘못 사용하면 오히려 개발자들의 사기가 떨어지고, 생산성도 저하된다.

"책임을 중시한다고 사칭하는 조직"을 착취조직이다 부른다. 이들은 결과(긴 근무시간)와 원인(높은 동기부여)을 혼동한다. 이런 조직에서는 직원들이 똑똑하게 일하는 것보다는 그냥 열씸히 일하는 것을 최고로 친다. 당연희 무질서하고 비효율적이다.

 

즉 문서화를 위한 문서화, 초과근무를 위한 초과근무, SW-CMM에 대한 비굴할 정도의 집착, 무비판적인 RUP나 eXtreme Programming 수용 등 본질보다 형식을 더 강조하는 모든 행위들은 화물숭배 소프트웨어공학이다.

파레토 또는 80/20 법칙

이탈리아의 경제학자 빌프레도 파레토(vilfredo Pareto) 는 경제적 불평등에 대한 예리한 관찰의 결과 그는 이탈리아 땅의 80%는 인구의 20%가 소유하고 있다는 것을 알아냈다. 80/20 법칙이라고 알려진 파레토의 법칙 또는 원리는 보다 최근에는 머피의 경영법칙으로 발전했다. 기업 이윤의 80%는 종업원 중 20%로부터 나오며, 고객서비스 문제의 80%는 고객들 중 20%로부터 나오고, 의사결정의 80%는 회의 시간 중 20%에서 나온다는 것 등이다. 이는 다른 영역에까지 변형되어 적용되었다. 예컨대, 대부분의 사회에서 범죄자의 20%가 범죄의 80%를 저지르고, 운전자의 20%가 사고의 80%를 일으키고, 맥주를 마시는 사람의 20%가 전체 맥주 소비량의 80%를 마신다는 것이다.

 

80/20 법칙은 다양한 모양을 취하면서도 기본적으로는 동일한 현상을 서술한다. 즉 우리 노력의 4/5는 크게 봤을 때 중요하지 않다는 것이다.

 

80/20 비즈니스 전략

80/20 이라는 용어가 언제 처음으로 등장했는지는 명확하지 않지만 대중적인 출판물이나 비즈니스 관련 문헌들에서는 “80/20 법칙” 이라는 문구가 널리 퍼져있다.

 

모든 비즈니스 또는 경제에 있어 가장 근원적인 문제는 자원이 제한되어 있다는 점이다. 우리는 제한된 자원을 어디에 어떻게 우선 투입해야 하느냐를 결정해야 하는데, 전통적인 50:50 패러다임은 투자한 만큼 결과가 나올 것을 가정하고 있다. 하지만 실제 결과를 면밀히 분석해 보면 결과의 80%를 좌우하는 것은 20%의 투자이다. 비즈니스에서 80/20 법칙은 결과의 20%에만 영향을 미치는 투자의 80%를 결과의 80%를 좌우하는 핵심 20%로 옮겨야 한다고 주장한다.

현상	적용 방법
공정의 극히 일부분이 불량의 대부분을 차지한다.	불량의 대부분을 만들어 내는 그 소수의 공정에 자원을 집중해서 개선하면 불량률은 현격하게 떨어진다. 또한 소수의 불량만을 기록하는 나머지 80% 공정에는 품질 관리를 위한 리소스를 덜 투입해도 된다. 이들에게 가는 리소스를 불량의 80%를 만들어 내는 20%의 공정에 쏟아 부어야 한다.
대부분의 소프트웨어는 20%의 기능이 80%만큼 쓰인다.	따라서 80%만큼 많이 쓰이는 핵심 20%의 기능을 현저하게 개선함으로써 경쟁사 제품보다 훨씬 사용자의 생산성을 늘려 주는 소프트웨어를 만들 수 있다. 잘 쓰이지 않는 대부분의 80% 기능을 개선하는 데에 불필요하게 많은 자원을 투입할 필요가 없다.
이익의 80%를 가져다 주는 것은 매출액의 20%를 차지하는 제품이다.	매출의 80%를 차지하지만 이익의 20%만을 가져다 주는 제품은 가급적 비용이 덜 들어가는 방식으로 변화를 주면서, 이익의 80%를 가져다 주는 핵심 품목을 경쟁사보다 현저하게 좋게 만드는 데 주력해야 한다.

 

그렇다면 핵심 20%를 어떻게 찾아낼 수 있을까? 80/20 법칙은 현상이며 데이터로 검증된다. 그러므로 먼저 데이터를 분석해야 하며, (20-80 패턴이 아니더라도) 소수의 투자가 결과의 대부분을 좌우하는 것을 찾아내는 것이 중요하다. 쉽게 생각할 수 있는 것이 '제품'별로, 또는 '고객층'별로 나누어 분석하는 것이다. 예를 들어 컨설팅 회사 A가 수행한 프로젝트들을 규모별로 분석해 봤더니 다음과 같은 결과가 나왔다면,

 

	매출	이익	이익/매출 비율
대규모 프로젝트	35,000	16,000	45.7%
소규모 프로젝트	135,000	12,825	9.5%
총계	170,000	28,835	17.0%

 

매출액으로는 소규모 프로젝트가 대규모 프로젝트의 4배 가까이 되지만 실제 간접 비용이나 기타 비용을 제외한 이익을 기준으로 평가해 보면 대규모 프로젝트가 훨씬 더 높은 이익률을 기록하고 있는 것을 확인할 수 있다.

 

대규모 프로젝트는 매출 기준으로는 전체의 21% [=35000/(35000+135000)]이지만 전체 이익의 56% [=16000/(16000+12825)]를 차지하고 있으므로 "56/21 법칙"이 적용되고 있다고 할 수 있다. 따라서 이 컨설팅 회사의 적절한 비즈니스 전략은 소규모 프로젝트에 투입하는 자원을 가급적 대규모 프로젝트를 수주하기 위한 영업 비용으로 돌리는 것이다.

 

고객을 기준으로 분석을 할 수도 있다. 위의 컨설팅 회사 A 의 고객별 매출과 이익을 분석하였을 때 결과는 다음과 같다면,

	매출	이익	이익/매출 비율
오래된 고객	43,000	24,055	55.3%
약간 오래된 고객	101,000	12,726	12.6%
새로운 고객	25,000	7,956	31.2%

 

오래된 고객이 매출 규모로는 26%에 불과한데 전체 이익의 84%를 가져다 주고 있다는 것을 알 수 있다. 위의 컨설팅 회사 A는 신규 고객을 유치하기 위해 마케팅 비용을 지출하는 것보다는 그 비용을 기존 고객 (특히 오래된 기존 고객) 이 더욱 많은 지출을 할 수 있도록 유도하는 쪽으로 돌리는 것이 바람직하다. 이익의 80% 이상을 가져다 주는 고객은 바로 이 26%의 오래된 단골들이기 때문이다. 이들이 바로 작은 매출 규모 뒤에 숨어 있는 핵심 20% 라고 할 수 있다.

이외에도 경쟁적 세분화 또는 경쟁적 세그멘테이션 (Competitive segmentation) 방법이 있다. 경쟁적 세그멘테이션은 다음 2 질문에 대하여 YES 에 해당하는 부분을 독립적인 세스먼트로 세분화하는 것을 의미한다.

• 이 부분에서 다른 주된 경쟁자와 맞서게 되는가?
• 이 부분에서 경쟁상의 상대적 위치가 달라지는가?

예를 들어, A 제품을 40대 이상 연령층에게 판매하려면 X라는 경쟁사와 경쟁을 해야 하고, A 제품을 20대 이하 연령층을 대상으로 판매할 때는 Y라는 경쟁사와 맞서야 한다면 두 경우는 독립적인 세그멘트로 취급되어야 한다. 따라서 각각 개별적으로 매출과 비용 그리고 이익을 분석해야 한다.

두 번째 질문도 유사한 의미이다. 똑같이 X라는 경쟁사와 경쟁을 하더라도, A 제품에서는 우리가 시장 점유율 2위인데 B 제품에서는 시장 점유율 1위라면 두 제품은 별개로 취급되어야 한다.

위와 같은 선택과 집중을 단지 '이익률이 높은 쪽에 집중한다'라는 것으로 오해 해서는 안 된다. 여기에서의 목적은 다른 부문에 비해서 마진율이 높은 부문을 찾는 것만이 아니라 이익의 대부분을 가져오는 '소수'을 찾는 것이다.

 

특정 제품일 수도 있고, 특정 고객층일 수도 있고, 고객과 제품을 혼합한 특정 세그멘트일 수도 있고, 특정 지역일 수도 있다. 중요한 것은 이익의 80%를 가져오는 소수의 세그멘트가 존재한다는 사실이고, 그 세그멘트를 찾아 내는 것이다.

결론

80/20 법칙은 단순히 효과가 좋은 부분을 찾아서 집중하는 것이 아니다. "결과의 막대한 부분을 좌우하는 소수"을 찾아 그 세그멘트에 집중하는 것에 있다.

 

 

 

 

Top 20 Best Software Enginnering Books, Ever

네델란드 ISM eCompany, CIO(Chief Information Officer) "Jurgen Appelo." 씨가 그의 블로그에 게시한 Top 100 Best Software Engineering Books, Ever 에서 상위 20 만 발최한것. 2권은 읽어 본기억이 나는데 ..

 

1. Steve McConnell Code Complete: A Practical Handbook of Software Construction
2. Elisabeth Freeman, etc.Head First Design Patterns
3. Steve McConnell Rapid Development
4. Erich Gamma Design Patterns: Elements of Reusable Object-Oriented Software
5. Bruce Schneier Applied Cryptography: Protocols, Algorithms, and Source Code (2nd Edition)
6. Robert C. Martin Agile Software Development: Principles, Patterns and Practices
7. Joel Spolsky Joel on Software
8. TomDeMarco, Timothy Lister Peopleware: Productive Projects and Teams (2nd Edition)
9. Frederick P. Brooks The Mythical Man-Month, Anniversary Edition (2nd Edition)
10. Martin Fowler Refactoring: Improving the Design of Existing Code
11. Mike Cohn Agile Estimating and Planning
12. Alistair Cockburn Writing Effective Use Cases
13. Bertrand Meyer Object-Oriented Software Construction (2nd Edition)
14. Steve McConnell Software Estimation: Demystifying the Black Art
15. Mike Cohn User Stories Applied: For Agile Software Development
16. Donald E. Knuth The Art of Computer Programming, The, Volumes 1-3 Boxed Set (2nd Edition)
17. Martin FowlerPatterns of Enterprise Application Architecture
18. Jeffrey Friedl Mastering Regular Expressions
19. Andrew Hunt, David Thomas The Pragmatic Programmer: From Journeyman to Master
20. Karl E. Wiegers Software Requirements (2nd Edition)