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

프로세스와 스레드

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

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

단일 컴퓨터 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)