Recent Comments 가져오기

논어ISBN : 9788970650340를 읽고..

서점에 가면 프로젝트 관리와 관련된 책들이 널려있다. 특히 애자일 열풍?이 불어닥치면서 애자일 관련된 책들만해도 수십권은 되어보인다. 그런책들은 언제 시간나면 한번 읽어보기로 하고, 논어에 나오는 격언들을 프로젝트관리에 적용시켜보면 어떨까라는 생각이 느닷없이 든김에 생각을 정리해 보기로 했다.

공자왈 백성들을 정치로 인도하고 형벌로 다스리면 백성들은 형벌을 면하고도 부끄러워함이 없다. 그러나 덕으로 인도하고 예로써 다스리면, 백성들은 부끄러워할 줄도 알고 또한 잘못을 바로잡게 된다.
공자왈 군자는 천하에서, 반드시 그래야만 한다는 것도 없고, 절대로 안된다는 것도 없으며, 오직 의로움만을 따를 뿐이다
공자왈 군자는 말에 대해서는 모자라는 듯이 하려하고, 행동에 대해서는 민첩하려고 한다
자유왈 임금을 섬김에 번거롭게 자주 간언을 하면 곤욕을 치루고 치욕을 당하게 되고, 친구에게 번거롭게 자주 충고하면 곧 소원해진다.
공자왈 군자는 절박한 것은 도와주지만 부유한자가 더 부자가 되게 도와주지 않는다
자로가 여쭈었다. 선생님께서 삼군을 통솔하신다면 누구와 함께 하시겠습니까 ? 공자께서 말씀하시길 맨손으로 범을 잡고 맨몸으로 황하를 건너려다 죽어도 후회가 없는 사람과는, 나는 함께하지 않겠다. 반드시 일을 대담에 신중하게 하고, 계획을 잘 세워 일을 이루는 사람과 함께 하겠다.
공자왈 부가 만약 추구해서 얻을 수 있는 것이라면, 비록 채찍을 드는 천한 일이라도 하는 하겠다. 그러나 추구해서 얻을 수 없는 것이라면 내가 좋아하는 일을 하겠다
군자는 평온하고 너그럽지만, 소인은 늘 근심에 쌓여있다.
마굿간에 불이 났었는데, 공자께서 퇴근하시어 사람이 다쳤느냐라고 물으시고는 말에 대해서는 묻지 않으셨다.
공자께서 말씀하셨다. 지나친 것은 모자란 것과 마찬가지이네

중궁이 정치에 대해 여쭙다. 공자께서 말씀하시길 먼저 실무자들에게 일을 분담시키고, 작은 잘못은 용서해 주며, 현명한 인재를 등용하거라
섭공이 정치에 대해서 묻자, 공자님께서 말씀하시길 가까이 있는 사람들은 기뻐하고, 먼 데 있는 사람들은 찾아오도록 하는 것입니다라고 하셨다.
자하가 정치에 대해 여쭙자, 공자께서 말씀하시길 빨리 성과를 보려 하지 말고, 작은 이익을 추구하지 말라. 빨리 성과를 보려하면 제대로 성과를 달성하지 못하고, 작은 이익을 추구하면 큰일이 이루어지지 않는다
공자께서 말씀하셨다. 가난하면서 원망하지 않기는 어렵지만, 부자 이면서 교만하지 않기는 쉽다
공자께서는 네 가지를 절대로 하지 않으셨다. 사사로운 뜻을 갖는일이 없으셨고, 기필코 해야 한다는 일이 없으셨으며, 무리하게 고집부리는 일도 없으셨고, 자신만을 내세우려는 일도 없으셨다.
현대 자본주의 사회에서 살아남기 위한 덕목은 스피드와 경쟁력, 효율성이다. 이를 달성하기 위해서 시간과 공간을 집적시키길 원한다. 때로 인간다운 삶을 포기해야 한다. 이러한 현실에 비추어 유교의 가르침은 고리타분하고 비현실적이라는 느낌을 줄 수 있다. 욕심 없이 유유자적하면서 살 것이라면 모르지만 치열한 경쟁 사회에서 살아가기위한 지침으로 삼기엔 적당하지 않다고 생각되어지기 때문이다. 아름답지만 현실적이지 않은 가르침이라고나 할까 ?

시간과 공간을 집적시켜서 효율을 극대화 시키고 그것으로 이윤을 창출했던 산업시대에는 확실히 유교의 느긋함, 길게 보기, 사람 중심으로 보기, 결과 보다는 과정이 런건 사치로 여겨졌을 지도 모르겠다. 정보화,인터넷 시대인 지금 이러한 인식이 변하고 있다. 소프트웨어 업계의 여러가지 새로운 개방방법론들은 산업시대의 것들과는 분명히 다르며, 동양적사상을 오히려 따르려 하고 있음을 느낄 수 있다.

공자님의 격언을 보면 일관되게 일을 함에 있어서 소소한 것에 크게 신경쓰지 말라라고 하신다. 그게 해야할 업무이건 실수이건 간에 말이다. 큰것을 해결하면, 작은 것은 알아서 해결되는 경우가 많기 때문이다. 작은 것들에 신경을 쓰는 가장 흔한 이유는 잠깐이면 끝낼 수 있는 것 아니냐. 내가하면 5분안에 끝낼 수 있는데..라는 생각 때문인 것 같다. 큰일을 해결하면 작은일들도 해결되지만 작은일들이 모이면 큰일이 된다. 네버엔딩 프로젝트가 될 수도 있다. 인내와 믿음이 있어야 가능한 일이다.

음.. 완성된 문서가 아닙니다. 문서는 wiki 를 통해서 계속 수정/보완해나갈 생각입니다.

1 Linux More Popular as Deployment Platform

많은 개발자들이 자신의 실력을 다른 개발자들에게 자랑하기 위해서 혹은 그들과 의견을 주고 받기 위한 목적으로 오픈소스 프로젝트를 수행한다. 많은 경우 프로젝트 리더들은 프로젝트를 함께 개발하는 개발자의 소프트웨어 개발 환경에 대한 정보를 알기를 원한다.

이클립스 프로젝트는 4월 일반적인 개발자들이 어떠한 환경에서 개발을 하는지에 대한 광범위한 조사를 실시 했다. 주목할만한 내용은 개발플렛폼으로 리눅스가 상당한 진보를 이루어냈으며, 특히 배포플랫폼으로써는 윈도우즈를 추월했다는 점이 될 것이다.

이클립스 제단의 마케팅 디렉터인 Ian skerrit 이클립스를 사용하는 개발자의 64%가 윈도우즈를 사용하고 27%가 리눅스를 사용하고 있다는 결과를 발표하였다. 참고로 2007년 조사결과에 따르면 윈도우즈 사용자는 74% 리눅스 사용자는 20% 였다. 상당한 개발자가 리눅스를 개발환경으로 이동되었음을 알 수 있다.

deployment 플랫폼으로 보자면 리눅스가 43%로 41%의 윈도우를 앞지르고 있다.

개발자 커뮤니티는 데스크탑 개발환경과 deployment 개발환경을 지속적으로 리눅스로 바꾸어나가기 때문인 것으로 보고 있다. Skerrit는 그의 블로그에서 우분투와 레드햇으로의 이동은 분명한 이득을 주지만 윈도우즈는 그러하지 못하기 때문이라고 그 이유를 설명한다.

이러한 결과가 발생한 또 다른 이유는 리눅스 친화적인 Mysql과 Oracle과 같은 데이터베이스의 점유율 때문이다. 이들 두 데이터베이스의 점유율은 55%가 넘고 있다.

또한 이번 조사 결과는 기업들이 단지 오픈소스를 사용하기만 하는데에 머무르지 않고, 오픈소스에 공헌을 하는 정도로 오픈소스에 대한 인식이 성숙되었음을 보여주고 있다.

2007년에 46%의 기업들이 OSS의 사용을 허락했지만 OSS에 대한 공헌은 이루어지지 않았다. 즉 내부적으로 OSS를 사용하기만 했다. 지금은 이 비율이 27%로 줄었다. 이제 48.2% 의 응답자들이 그들의 기업이 OSS 커뮤니티로의 지원을 허락하고 있다고 응답을 하고 있다. 2007년의 37%에 비하면 10%나 증가한 수치다. - 국내의 경우에도 대략 2007년과 2008년을 기점으로 기업들의 오픈소스에 대한 직접적인 참여와 지원이 늘어나고 있다. -. OSS를 통한 비지니스 모델에 기대를 걸고 있다는 응답도 2007년 10%인 것에서 2008년 15.6%로 대폭 증가했다.

2 The Open Source Developer Report 2009

이 문서는 2009년 Eclipse Community 의 보고서인 The Open Source Developer Report를 보고 정리했다.

2.1 핵심 내용

이 보고서는 다음과 같은 핵심내용을 포함하고 있다.

• 리눅스는 데스크탑과 서버 환경모드를 공유하고 있다. 개발자들이 개발을 위한 데스크탑운영체제로 Microsoft 윈도우즈에서 리눅스와 Mac OX로의 이동하는 모습이 분명히 감지되고 있다. 특히 depolyment 운영체제환경으로 리눅스는 가장 일반적인 플렛폼이 되었다.
  
• Mysql 과 Oracle 데이터베이스는 55%이상의 지배적인 점유율을 보여주고 있다.
  
• 형상관리도구로는 SVN(Subversion)이 57% 점유율을 보여주고 있다.
  
• 기업은 성숙한 OSS 모델을 받아들이고 있다.
  
  1. 더 많은 기업들이 오픈소스 소프트웨어의 사용과 기여에 참여하고 있다. 보고서에 따르면 2008년 48.2%였다. 2007년에는 37%였다.
     
• 15.6 %의 회사가 OSS에 연계한 비지니스 모델을 만들고 있다.
  
  

3 보고서 참여자 통계 자료

응답자의 반이상이 프로그래머였으며 기타 시스템 아키텍쳐, 매니저, 소프트웨어 품질관리 및 테스터, 마케팅 메니저 등이 참여하였다.

4 개발자 데스크탑 개발 환경

개발자가 사용하는 데스크탑 운영체제 통계정보를 보여주고 있다. 윈도우즈에서 Linux와 Mac OSX로 이동하는 것을 확인할 수 있다. 26.9%의 개발자가 주요 개발 데스크탑 환경으로 리눅스를 사용하고 있다고 응답했는데, 2007년에 비하면 7%가 증가한 수치다.

2007년에 비하면 10%가량 줄어들긴 했지만, 여전히 윈도우즈는 64%의 사용율을 가지는 지배적인 운영체제다. 가장 많이 사용되는 리눅스 배포판은 Unbuntu인 것으로 조사되었다. Mac OSX도 2007년 3.5%에서 6.9%로 증가했다.

1. Windows Server or Client : 64.3%
   
2. Linux : 26.9%
   
   1. Ubuntu 14.5%
      
   2. Fedora 3.4%
      
   3. SUSE 3.2%
      
   4. Debian 2.6%
      
   5. RHEL 1.3%
      
   6. 기타 배포판 1.8%
      
3. Mac OSX : 6.9%
   
4. Sun Solaris or OpenSolaris : 0.9%
   
5. Other : 0.8%
   

4.1 IDE : 통합개발 환경

Eclipse IDE가 가장 인기있는 개발환경으로 지목되었다.

1. Eclipse JDT : 60%
   
2. Eclipse PHP 개발 툴 : 12.6%
   
3. Eclipse C/C++ 개발 툴 - CDT - : 6.3%
   

4.2 형상관리 툴

SCM(Source code management), CMS(changes management) 그리고 BM(Build management)에 대한 사용율을 조사한 자료다.

5 언어 및 응용프로그램

자바는 커뮤니티에 의해서 주도적으로 사용되는 언어였으며, 76.6%가 그들의 첫번째 언어로 자바를 사용한다고 응답했다. 개발용도는 Server-Centric 30.2%, 웹이 24.7%, 데스크탑 애플리케이션이 23.4%였다.



이 보고서는 주요 3가지 개발용도에 대해서 각각 어떠한 툴 혹은 언어를 사용하는지에 대해서 조사했다.

5.1 Server-Centric 애플리케이션

server-centric 애플리케이션의 개발을 위해서 가장 널리 사용되는 되는 것은 servlet이였다. 그다음으로는 spring 프레임워크였으며, EJB도 38.3%로 널리 사용되는 것으로 조사되었다. 대표적인 server-centric 애플리케이션은 J2EE 애플리케이션, 데이터베이스 애플리케이션, ERP, CRM 등이 있다.

5.2 Web, Rich 인터넷 애플리케이션

웹과 rich Internet 애플리케이션 (RIAs)의 경우에는 주도적인 프레임워크나 툴이 없는 것으로 조사되었다. 오픈소스 Ajax 프레임워크, Flash/Flex 등이 많이 사용되었으며, 아예 사용하지 않는 다는 응답도 꽤 되었다. GWT가 많이 사용되고 있다는 점이 눈에 띈다.

5.3 Rich Desktop Applications

Eclipse RCP (47.6%)와 Swing (43.8%)로 양분되어 있는 모습을 보여주고 있다.

6 Deployment 환경

개발자들이 그들이 개발한 애플리케이션이 설치될 타겟 환경으로 어떠한 것을 이용하는지에 대한 조사내용을 포함하고 있다. 운영체제, 데이터베이스 그리고 애플리케이션 서버 환경에 대해서 조사를 했다.

리눅스는 주목할만한 Depolyment 타겟 운영체제로 성장을 했으며, 지금은 오히려 윈도우를 앞서고 있는 것으로 확인되었다. 2008년 기준 42.7%의 점유율을 보여주고 있는데 2007년의 37%에 비하면 5%가까이 증가한 수치다. Ubuntu(12%), Red Hat Enterprise Linux (10.2%) 배포판이 널리 사용되고 있었다. 결과를 보면 윈도우환경의 유저가 리눅스, Mac OSX 등으로 이동한 것으로 보인다.

6.1 주요 데이터 베이스

예상대로 Mysql 과 Oracle이 각각 27.7%와 27.3%로 주요하게 사용되고 있었다. Mysql과 Oracle은 선호대상이 갈리는 것이 확인 되었다. 기업규모로 보자면, 5000 명 이상을 고용하고 있는 거대 기업의 경우에는 Oracle이 33.5%, IBM DB2가 10.7%, Mysql 이 11.6% 였다.

Oracle은 다음과 같은 선호대상층을 가진다.

• Java를 주요 개발언어로 사용하는 경우
  
• server-centric 애플리케이션을 개발하는 경우
  
• Application 서버를 이용하는 경우
  
  

Mysql은 다음과 같은 선호대상층을 가진다.

• PHP 언어를 주요언어로 사용하는 개발자
  
• RIA/Web 애플리케이션
  
  

6.2 주요 Application 서버

Apache Tomcat이 가장 널리 사용되고 있다. 그다음으로 JBoss, IBM WebSphere가 사용되고 있다. 아무 것도 사용하지 않는다는 응답도 25.3%나 되었다. 5000명이상 고용인을 가진 대기업의 경우에도 여전히 Apache Tomcat이 가장 널리 사용되었으나 IBM WebSphere가 6.9%에서 12.0%로 크게 오르고 Apache Tomcat 는 34.8%에서 26%로 떨어진걸 확인할 수 있었다.

7 평가

몇년전만 하더라도 오픈소스는 기업에서는 받아들이기 힘든 모델이라고 평가되기도 했었다. 혹은 많은 기업들이 단지 오픈소스의 단물만 빨아먹으려고 할뿐 결코 오픈소스 모델에 참여하지는 않을 것이라고 생각되던 때도 있었다.

그러나 이 보고서에 따르면, 오픈소스는 메이저한 개발/배포 환경은 물론이고 비지니스 환경까지 그 영역을 지속적으로 확장시켜가고 있음을 확인할 수 있다. 더불어 분명하게 더 많은 기업들이 적극적으로 오픈소스 모델에 직접적으로 참여하고 있는 것도 확인할 수 있다.

대세는 OSS

저작권의 출현

지각문화

아오.. 일단 포스팅 하고 보자..

1 Thread에 대해서

프로그램을 병렬로 실행시키는 방법으로 fork()에 대해서 알아보았다. fork()는 매우 이해하기 쉬운 프로그래밍 방법이긴 하지만 자원효율성에서 몇가지 문제점을 가지고 있다. 프로세스는 기본적으로 code, data, stack, file I/O, 그리고 signal table의 5가지 요소로 구성이 된다. fork() 를 이용해서 새로운 프로세스를 생성하게 되면, 이러한 5가지 구성요소가 모두 복사가 된다. 그러하다 보니 프로세스를 생성하는데 많은 비용이 소비될 것이다. 대게의 경우에는 프로세스를 새로 생성시킬때 발생하는 성능저하가 문제가 되지는 않겠지만 웹서비스처럼 대량의 접근이 발생하는 영역에서는 문제가 될 수 있다.

fork의 이러한 방식은 상당히 효율이 떨어지는 측면이 있다. 어떤 프로그램을 병렬로 실행시킨다고 했을 때, 실제 우리가 병렬로 실행되기를 원하는 영역은 코드의 일부분이지 프로그램 전체는 아니기 때문이다.

// ... 
pid = fork(); 
if (pid > 0) 
{ 
    // 실제는 이 부분의 코드만 병렬로 실행되면 된다. 
    // fork()는 다른 모든영역의 코드가 복사되어 버린다. 
} 
 

게다가 전혀다른 프로세스를 생성시킴으로써, 프로세스간 통신이라는 상당히 복잡한 문제까지를 해결해야 한다. 병렬로 작동하는 프로그램은 특성상 데이터를 공유하거나 서로 통신을 해야 하는 경우가 많다. 그런데 프로세스는 서로 독립된 객체이므로 일반적인 방법으로는 데이터를 공유할 수가 없다. 이러한 프로세스간 데이터 통신을 위해서 리눅스는 IPC라는 설비를 제공하는데, IPC라는게 사용하기가 여간 까다롭지가 않다. IPC에 대해서는 별도의 장을 할애해서 다룰 계획이다.

Thread를 이용하면 fork()를 이용한 프로세스 기반의 병렬처리의 문제점의 많은 부분을 해결할 수 있다. Thread는 새로운 프로세스를 생성시키지 않고, 특정 문맥(코드)만을 병렬로 실행할 수 있도록 허용한다. 새로운 프로세스를 생성시키지 않기 때문에 그만큼 자원을 아낄 수 있으며, 더 효율적으로 빠르게 움직일 수 있다. 또한 같은 프로세스이기 때문에, 데이터를 공유하기가 쉽다는 장점도 가진다.

1.1 Thread vs Process

Thread는 프로세스와 다음과 같은 차이점을 가진다.

• 프로세스는 독립적이다. 쓰레드는 프로세스의 서브셋이다.
  
• 프로세스는 각각 독립적인 자원을 가진다. 쓰레드는 stat, memory 기타 다른 자원들을 공유한다.
  
• 프로세스는 자신만의 주소영역을 가진다. 쓰레드는 주소영역을 공유한다.
  
• 프로세스는 IPC를 이용해서만 통신이 가능하다.
  
• 일반적으로 쓰레드의 문맥교환(context switching)는 프로세스의 문맥교환보다 빠르다.
  
  

1.2 Multi Thread 프로그램의 단점

모든 도구가 그러하듯이 Multi Thread 프로그램이라고 해서 장점만 가진 것은 아니다. Multi Thread 프로그램은 Multi Process 프로그래밍 방식에 비해서 다음과 같은 단점을 가진다.

• 하나의 쓰레드에서 발생된 문제가 전체 프로세스에 영향을 미친다.
  
  멀티 프로세스의 경우에는 프로세스하나가 문제가 생기더라도 단일 프로세스로 문제가 제한된다. 그러나 멀티쓰레드 프로그램의 경우 하나의 쓰레드에 생긴 문제가 다른 쓰레드에까지 영향을 줄 수 있다. 예를 들어 쓰레드 하나가 다른 프로세스의 메모리 영역을 침범할 경우 프로세스 자체가 죽어버림으로써, 프로세스에 생성된 다른 모든 쓰레드도 프로세스와 함께 죽어버리게 된다. - 이 문제는 해결 가능하지만 여기에서는 다루지 않도록 하겠다. 시그널을 잘 활용하면 된다. 관심있으면 한번 고민해 보기 바란다. -
  
• 디버깅이 어렵다. 문맥이 서로 교환되므로 추적하기가 까다롭다.
  
  

이러한 단점이 있음에도 불구하고 멀티쓰레딩 프로그래밍 기법을 선호하고 있다.

1.3 PThread

Thread는 운영체제에서 제공하는 병렬처리 메커니즘으로, 실제 이 메커니즘을 이용하기 위해서는 Thread의 구현체가 필요하다.

리눅스에서는 pthread라는 thread 구현 라이브러리가 사용되고 있다. pthread는 POSIX thread 의 줄임말로 POSIX 표준을 따르고 있다. pthread는 리눅스 뿐만 아니라 다른 거의 대부분의 유닉스에서도 사용할 수 있다. 이외에도 BSD 계열에서 사용하는 'Light Weight Kernel Threads , Apple 에서 사용하는 Multiprocessing Services등의 구현체가 있다. 이 문서는 pthread구현만을 설명하도록 할 것이다.

pthread는 리눅스 운영체제에서 제공하는 thread 를 제어하기 위한 함수들을 모아 놓은 C 라이브러리로, 다음과 같은 기능의 함수군을 제공한다.

• 쓰레드 생성과 종료 관련 함수들
  
• 쓰레드 동기화 관련 함수들
  
  쓰레드는 많은 데이터를 공유한다. 그러므로 데이터에 대한 동기화 문제를 해결해야할 필요가 있다.
  
• 쓰레드 시그널 제어 함수들
  
  signal은 프로세스단위로 작동한다. 그러나 쓰레드 프로그램의 경우, 각 쓰레드 마다 다른 시그널 정책이 필요하므로, 쓰레드 전용의 시그널 제어 함수가 필요하다.
  
  

1.4 Multi Thread 프로그램

병렬로 작동하지 않는 하나의 문맥흐름만을 가지는 프로그램을 단일 쓰레드 프로그램이라고 한다. 반대로 아래와 같이 문맥이 나뉘어서, 동시에 두개 이상의 쓰레드가 실행되면, 이를 멀티 쓰레드 프로그램'''이라고 한다.

1.5 Process, Kernel Thread, User Thread

프로세스는 가장 무거운 커널의 스케쥴링 단위이다. 프로세스는 운영체제에게 할당받은 자원들 - 파일 핸들러,소켓,장치 핸들러 - 을 할당받게 된다. 프로세스는 독립된 단위로써 파일이나 주소영역 등을 공유하지 않는다.

kernel thread는 가장 가벼운 커널 스케쥴링 단위다. 하나의 프로세스는 적어도 하나의 커널 쓰레드를 가지게 된다. 만약에 프로세스가 하나이상의 쓰레드를 가지고 있다면, 이들 쓰레드는 같은 메모리와 파일자원등을 공유하게 된다. 만약 커널의 프로세스 스케쥴러가 선점형이라면 쓰레드의 스케쥴러도 선점형인 경우가 많다. 참고삼아서 선점형과 비선점형에 대해서 간략하게 설명하도록 하겠다.

• 비선점형 : 특정 프로세스가 CPU를 독점하는 것이 가능하다.
  
• 선점형 : 특정 프로세스가 CPU를 독점하는게 불가능하다.
  

특정 프로세스가 CPU를 독점하는게 불가능하게 하는 것은 프로세스가 인터럽트를 무시하기 못하게 하는 것으로 구현한다. 선점형은 어떤 프로세스가 시스템콜을 수행중이더라도 커널이 인터럽트를 보내면, 즉시 빠져 나와야 한다. 즉 운영체제가 CPU를 선점한다는 얘기가 된다. 시스템콜이 수행중이더라도 인터럽트를 걸고 다른 일을 수행하도록 할 수 있으므로 보다 빠른 반응성을 보여준다.

때때로 쓰레드가 유저영역 라이브러리로 구현되는 경우가 있는데, 이를 user Thread 라고 부른다.

1.6 쓰레드의 생성과 종료

멀티 쓰레드 프로그램이라고 하더라도, 처음 시작되었을 때는 main()에서 시작되는 단일 쓰레드 상태로 작동이 된다. 이 상태에서 pthread_create(3) 함수를 호출함으로써, 새로운 쓰레드를 생성할 수 있다. pthread_create를 이용해서 생성된 새로운 쓰레드를 worker 쓰레드라고 하자.

멀티 쓰레드 프로그램은 다음과 같은 흐름을 가진다.



생성된 worker thread는 언젠가 종료가 될 것이다. Master Thread (이하 부모 쓰레드)는 pthread_join()을 이용해서 worker thread들의 종료를 기다린다. pthread_join()는 종료된 worker thread의 자원을 정리하는 일을 한다. fork()를 이용한 멀티 프로세스 프로그램에서, 부모 프로세스가 wait()를 이용해서 자식 프로세스를 기다리는 것과 같은 이유라고 보면 된다.

1.6.1 pthread_create : 쓰레드 생성

pthread_create(3)함수를 이용하면 새로운 쓰레드를 생성할 수 있다. 이 함수는 다음과 같이 사용할 수 있다.

#include <pthread.h> 
 
int  pthread_create(pthread_t  *  thread, pthread_attr_t *attr,  
     void * (*start_routine)(void *), void * arg); 
 

1. thread : 쓰레드가 성공적으로 생성되었을 때, 넘겨주는 쓰레드 식별 번호.
   
2. attr : 쓰레드의 특성을 설정하기 위해서 사용한다. NULL일 경우 기본 특성
   
3. start_routine : 쓰레드가 수행할 함수로 함수포인터를 넘겨준다.
   
4. arg : 쓰레드 함수 start_routine를 실행시킬 때, 넘겨줄 인자
   

이 함수는 성공적으로 수행되었다면, 0을 리턴한다. 그렇지 않을 경우 1을 리턴한다.

1.6.2 pthread_join : 쓰레드 정리

쓰레드가 실행시키는 것은 함수 이다. 그러므로 return이나 exit(0)등을 이용해서 쓰레드를 종료시킬 수 있게 된다. 그러나 쓰레드 함수가 종료되었다고 해서 곧바로 쓰레드의 모든자원이 종료되지 않는다. fork()기반의 멀티프로세스 프로그램에서 종료된 자식프로세스를 정리하기 위해서 wait()로 기다리듯이, 종료된 쓰레드를 기다려서 정리를 해주어아만 한다. 그렇지 않을 경우 쓰레드의 자원이 되돌려지지 않아서 메모리 누수현상이 발생하게 된다.

pthread_create()로 생성시킨 쓰레드는 pthread_join()을 통해서 기다리면 된다. pthread_join 함수는 다음과 같이 사용할 수 있다.

#include <pthread.h> 
 
int pthread_join(pthread_t th, void **thread_return); 
 

1. th : pthread_create에 의해서 생성된, 식별번호 th를 가진 쓰레드를 기다리겠다는 얘기다.
   
2. thread_return : 식별번호 th인 쓰레드의 종료시 리턴값이다.
   
   

pthread_join이 하는 일은 명확하다. 다만 주의 할것은 pthread_join은 반드시 joinable 한 상태로 생성된 쓰레드만을 기다릴 수 있다는 점이다. pthread_create로 쓰레드를 생성시킬 때, 나중에 join되지 않을 것으로 생각하고 생성시킬 수 있는데, 이렇게 되면 이 쓰레드는 종료하자마자 모든 자원을 해제하며, pthread_join으로 기다릴 수가 없다. 부모쓰레드와 떨어져서 완전히 독립적으로 작용한다고 하여, 이를 detach 한다고 한다. 쓰레드를 detach하는 방법은 아래에서 다룰 것이다.

1.6.3 쓰레드 생성 예제

pthread_create와 pthread_join을 알고 있다면, 이제 thread를 생성시킬 수 있다.

#include <pthread.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <stdlib.h> 
 
// 쓰레드 함수 
void *t_function(void *data) 
{ 
    int id; 
    int i = 0; 
    id = *((int *)data); 
 
    while(1) 
    { 
        printf("%d : %d\n", id, i); 
        i++; 
        sleep(1); 
    } 
} 
 
int main() 
{ 
    pthread_t p_thread[2]; 
    int thr_id; 
    int status; 
    int a = 1; 
    int b = 2; 
 
    // 쓰레드 생성 아규먼트로 1 을 넘긴다.   
    thr_id = pthread_create(&p_thread[0], NULL, t_function, (void *)&a); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 쓰레드 생성 아규먼트로 2 를 넘긴다.  
    thr_id = pthread_create(&p_thread[1], NULL, t_function, (void *)&b); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 쓰레드 종료를 기다린다.  
    pthread_join(p_thread[0], (void **)&status); 
    pthread_join(p_thread[1], (void **)&status); 
 
    return 0; 
} 
 

아주 전형적인 프로그램이긴 하지만 pthread_join부분에 문제가 있다. pthread_join은 쓰레드가 종료될 때까지 블럭되기 때문이다. 이래서는 쓰레드를 두개이상 생성시키지 못할 것이다. 그렇다고 pthread_join을 이용하지 않는다면, 메모리 누수가 생기게 되니, 생략할 수도 없는 노릇이다.

1.6.4 자식쓰레드를 부모쓰레드로 부터 분리하기

pthread_join의 사용으로 발생할 수 있는 문제점을 해결하기 위한, 가장 좋은 방법중의 하나는 pthread_detach 를 이용해서, 자식 쓰레드를 부모쓰레드와 완전히 분리해 버리는 방법이다. 이 경우 자식 쓰레드가 종료되면, 모든 자원이 즉시 반환된다. 반면, 자식 쓰레드의 종료상태를 알 수 없다는 문제가 발생한다. 대게의 경우 자식 쓰레드의 종료상태가 중요한 문제가 되지는 않을 것이다.

만약 자식 쓰레드의 종료상태를 알아내는게 중요하다면, 종료상태를 저장할 전역변수를 두고, 여기에 종료상태를 기록하는 방식을 사용할 수 있을 것이다. 자식 쓰레드가 종료할때, 변수의 값을 바꾸고, 부모쓰레드에 시그널을 전송하는 방법이다. 이 방법은 이 문서의 뒤에서 따로 다루도록 하겠다.

#include <pthread.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <stdlib.h> 
 
// 쓰레드 함수 
// 1초를 기다린후 아규먼트^2 을 리턴한다. 
void *t_function(void *data) 
{ 
    char a[100000]; 
    int num = *((int *)data); 
    printf("Thread Start\n"); 
    sleep(5); 
    printf("Thread end\n"); 
} 
 
int main() 
{ 
    pthread_t p_thread; 
    int thr_id; 
    int status; 
    int a = 100; 
 
    printf("Before Thread\n");  
    thr_id = pthread_create(&p_thread, NULL, t_function, (void *)&a); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 식별번호 p_thread 를 가지는 쓰레드를 detach  
    // 시켜준다. 
    pthread_detach(p_thread); 
    pause(); 
    return 0; 
} 
 

1.7 쓰레드 동기화

이제 우리는 간단한 다중쓰레드 프로그램을 만들 수 있게 되었다. 그러나 이들 쓰레드 생성 함수만 가지고는 복잡한 쓰레드 프로그램을 만들 수가 없다. 쓰레드간 동기화라고 하는 문제가 놓여있기 때문이다. 아주 간단한 프로그램이 아닌한은 반드시 동기화문제를 고민해야만한다.

동기화란 여러가지 의미로 사용될 수 있는데, 이 경우에 있어서 동기화는 서로의 시간을 맞춘다를 의미한다. 멀티쓰레드 프로그램은 하나의 시간에 여러개의 프로세스가 돌아가는 형태를 취한다. 또한 멀티쓰레드 프로그램은 자원의 상당부분을 서로 공유하는 경우가 많다. 만약 단지 자원을 읽어들이는 거라면 상관없지만 읽고/쓰는 것이라면 동기화와 관련된 문제가 발생할 수 있다.

예컨데 다음과 같은 경우다.

1. A와 B 두개의 프로세스가 있다. 이 프로세스는 int count=1 이라는 자원을 공유한다.
   
2. A가 count를 읽어들이고 1을 더한다.
   
3. B가 count를 읽어들인다. 아직 A가 count에 쓰지 않았기 때문에, B도 1을 읽어들인다.
   
4. A가 count에 2를 쓴다.
   
5. B도 count에 2를 쓴다.
   
6. count에는 2가 저장되었다.
   

우리가 원하는 값은 2가 아닌 3이다. 그러나 쓰레드가 동기화 되지 않음으로써, 원치않은 잘못된 연산을 하게 되었다. 우리는 이 문제를 해결해야 한다.

1.8 접근제어

동기화 문제는 현실세계에서도 자주 발생한다. 화장실을 생각하면 된다. 화장실은 공유자원이며, 여러명이 사용한다. 누군가 화장실을 사용하고 있다면, 다른 사람은 화장실을 사용하면 안된다. 이 문제를 우리는 접근을 제어하는 방식으로 해결한다. 문을 걸어 잠궈서 한번에 한사람만 화장실에 들어가도록 하는 방법이다. 매우 이해하기 쉬운 방식이다.

다중쓰레드 프로그램에서도 마찬가지로 접근제어를 이용해서 이 문제를 해결한다. 이를 위해서 pthread는 mutex라는 잠금 메커니즘을 제공한다.

1.8.1 mutex 잠금

동시에 여러개의 쓰레드가 하나의 자원에 접근하려고 할때 발생하는 문제를 pthread는 임계영역을 두는 것으로 해결하고 있다. 임계영역안에는 접근하고자 하는 자원이 놓여있고, 오직 하나의 쓰레드만 임계영역안으로 진입할 수 있도록 제한한다. pthread는 이를 위해서 mutex를 제공한다. mutex는 그 자체가 가지는 잠금의 특성 때문에 mutex 잠금이라고 불리워지기도 한다.



위 그림은 mutex가 작동하는 방식을 보여준다. thread 1이 자원에 접근하면 mutex 잠금을 얻게 된다. 이 잠금은 단지 하나만 존재하기 때문에 thread 2는 잠금을 얻지 못하고 임계영역 밖에서 대기하게 된다. thread 1이 자원을 모두 사용하고 임계영역을 벗어나면 thread 2는 잠금을 얻게 되고 임계영역에 진입해서 자원을 사용할 수 있게 된다.

1.8.2 mutex의 사용

mutex를 사용하기 위해서는 다음의 4가지 함수가 필요하다.

• mutex 잠금객체을 만드는 함수
  
• mutex 잠금을 얻는 함수
  
• mutex 잠금을 되돌려주는 함수
  
• mutex 잠금객체를 제거하는 함수
  
  

1.8.3 pthread_mutex_init

mutex를 사용하기 위해서는 먼저 pthread_mutex_init() 함수를 이용해서, mutex 잠금 객체를 만들어줘야 한다.

pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutex_attr *attr); 
 

이 함수는 두개의 인자를 필요로 한다.

1. mutex : mutex 잠금객체
   
2. mutex_attr : mutex는 fast, 'recursive, error checking의 3종류가 있다. 이 값을 이용해서 mutex 타입을 결정할 수 있다. NULL 일경우 기본값이 fast가 설정된다.
   
   • fast : 하나의 쓰레드가 하나의 잠금만을 얻을 수 있는 일반적인 형태
     
   • recursive : 잠금을 얻은 쓰레드가 다시 잠금을 얻을 수 있다. 이 경우 잠금에 대한 카운드가 증가하게 된다.
     

mutex_attr을 위해서 다음의 상수값이 예약되어 있다.

• fast : PTHREAD_MUTEX_INITIALIZER
  
• recursive : PTHREAD_RECURSIVE_MUTEX_INITIALIZER
  
• error checking : PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
  
  

1.8.4 pthread_mutex_lock

mutex 잠금을 얻기 위한 함수다.

int pthread_mutex_lock(pthread_mutex_t *mutex); 
 

mutex 잠금을 얻는다라는 표현보다는 mutex 잠금을 요청한다라는 표현이 더 정확할 것 같다. 만약 mutex 잠금을 선점한 쓰레드가 있다면, 선점한 쓰레드가 mutex 잠금을 되돌려주기 전까지 이 코드에서 대기하게 된다.

때때로 잠금을 얻을 수 있는지만 체크하고 대기(블럭)되지 않은 상태로 다음 코드로 넘어가야할 필요가 있을 수 있을 것이다. 이 경우에는 아래의 함수를 사용하면 된다.

int pthread_mutex_trylock(pthread_mutex_t *mutex); 
 

1.8.5 pthread_mutex_unlock

mutex 잠금을 되돌려주는 함수다.

int pthread_mutex_unlock(pthread_mutex_t *mutex); 
 

1.8.6 mutex 잠금 예제

count 프로그램을 예제로 할 것이다. 임계영역안에서 보호되어야할 자원은 count이고, 여러개의 쓰레드가 count에 접근해서 +1을 시도하려고 한다. 이때 제대로된 count를 위해서는 한번에 하나의 쓰레드만이 counting을 하도록 해야할 것이다. mutex를 이용해서 임계영역을 보호하도록 할 것이다.

임계영역을 보호하지 않을 경우 다음과 같은 문제가 발생할 수도 있을 것을 예상할 수 있다.

int a = 1;  
Thread A 에서 a를 읽어들인다.  
Thread B 에서 a를 읽어들인다.  
Thread A 에서 a = a+1를 한다.  
{  
    a = a+1;  
    결과는 2;  
}  
Thread B 에서 a++를 한다.  
{  
   a = a + 1; // 읽어들인 값이 1이기 때문에  
   역시 결과는 2가 된다.  
}  
 

두번의 count가 발생했기 때문에 3이되어야 하겠지만 임계영역이 보호되지 않음으로써 2가 되어 버렸다.

mutex는 임계영역을 잠금으로서 이러한 문제를 해결한다. 이러한 문제를 해결하기 위해서는 임계영역에 단지 하나의 쓰레드만 접근하는걸 보장해줘야 할 것이다. mutex는 아래의 요소들을 보장함으로써 이를 보장한다.

• Atomicity - mutex 잠금은 최소단위 연적 - atomic operation - 을 보장한다. atomic operation에 대해서 간단히 설명하고 넘어간다. 자세한 내용은 Atomic Operation을 참고하기 바란다.
  
  1. aotomic operation은 일련의 연산 즉 mutex 잠금 연산이 끝날때 까지 다른 프로세스가 그 연산의 변화를 알 수 없는 상태가 되는 연산을 의미한다. (일반적으로 연산은 이전의 연산의 결과를 관찰한 후에서야 이루어질 수 있게다)
     
  2. 전체연산중 하나라도 실패할 경우 모든 연산이 실패하며 시스템은 전체 연산이 시작하기 전의 상태로 복구된다.
     
• Singularity : 한 쓰레드가 뮤택스 잠금을 얻었다면, 이 쓰레드가 뮤택스 잠금을 내어놓기 전까지는 다른 쓰레드가 뮤택스 잠금을 얻을 수 없도록 한다.
  
• None Busy Wait : 이것은 성능과 관련된 것이다. 바쁜대기상태에 놓이지 않는다는 뜻이다. 뮤택스 잠금을 얻을 수 있는지를 확인하기 위한 연산이 필요하지 않는 다는 의미로 받아들이면 될 것이다.
  
  

이상 mutex는 위의 3가지를 지원하는 것으로 공유되는 자원을 충돌없이 그리고 효율적으로 사용할 수 있도록 보장해준다.

다음은 mutex를 사용한 count 예제프로그램이다.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

#include <stdio.h> #include <unistd.h> #include <pthread.h> int ncount; // 쓰레드간 공유되는 자원 pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; // 쓰레드 초기화 // 쓰레드 함 수 1 void* do_loop(void *data) { int i; pthread_mutex_lock(&mutex); // 잠금을 생성한다. for (i = 0; i < 10; i++) { printf("loop1 : %d", ncount); ncount ++; sleep(1); } pthread_mutex_unlock(&mutex); // 잠금을 해제한다. } // 쓰레드 함수 2 void* do_loop2(void *data) { int i; // 잠금을 얻으려고 하지만 do_loop 에서 이미 잠금을 // 얻었음으로 잠금이 해제될때까지 기다린다. pthread_mutex_lock(&mutex); // 잠금을 생성한다. for (i = 0; i < 10; i++) { printf("loop2 : %d", ncount); ncount ++; sleep(1); } pthread_mutex_unlock(&mutex); // 잠금을 해제한다. } int main() { int thr_id; pthread_t p_thread[2]; int status; int a = 1; ncount = 0; thr_id = pthread_create(&p_thread[0], NULL, do_loop, (void *)&a); sleep(1); thr_id = pthread_create(&p_thread[1], NULL, do_loop2, (void *)&a); pthread_join(p_thread[0], (void *) &status); pthread_join(p_thread[1], (void *) &status); status = pthread_mutex_destroy(&mutex); printf("code = %d", status); printf("programing is end"); return 0; }

1.9 앞으로 할 것

쓰레드는 매우 광범위한 주제로 여기에서는 쓰레드를 사용하기 위한 가장 기본적인 내용만 다루었다. 쓰레드에 대한 좀더 자세한 내용은 별도의 장을 할애해서 다룰 생각이다.

많은 개발자들이 회사일과는 별도로 오픈소스 프로젝트에 참가하려고 한다. 그리고 가능한 이름있는 프로젝트로까지 성장시키기를 원한다. 왜 일까 ? 돈을 벌 기회를 얻을 수 있다라거나 혹은 이름을 알릴 수 있는 기회를 엿볼 수 있다라는 등등의 이유가 있을 수도 있을 것이다. 그러나 그렇게 단정짓기에는 왠지 뒷통수가 근질근질 하다. 단지 그 이유 때문일까 ? 그렇다면 다른 산업분야에 비해서 왜 유독 소프트웨어 분야에서 그런 현상이 발생하는 것일까 ? 이렇게 말하면 오픈소스 공동체 혹은 자유소프트웨어 공동체가 잘 유지되고 있어서라고 대답할 수 있을 것이다. 그럴듯하다. 그렇다면 이렇게 되물어볼 수 있을 것이다. 왜 소프트웨어쪽은 그러한 풀뿌리 공동체 공동체가 살아있는 것일까. 다시 말하자면 왜 유독 놀만한 멍석이 잘 깔려져 있을까 라는 물음이다.

소프트웨어 산업에는 장인정신과 예술인의 중간의 의미를 가지고 있는 해커문화라 는게 남아 있다. 자신의 이름을 걸고 물건을 만드는 장인처럼 자신의 이름이 새겨진 소프트웨어를 만들어내기를 원한다. 혹은 자신의 이름이 아로새겨진 예술작품이 전시되는 것처럼 자신의 이름이 아로새겨진 소프트웨어가 전시 되기를 원한다. 다른 어떠한 산업분야에서도 이러한 모습을 발견할 수 없다. 아마 예술분야에서나 겨우 발견할 수 있을 것이다.

이렇게 멍석을 만들어 놓은 사람이 리차드 스톨만이다. 시대의 반항아. 똘아이?. 소프트웨어 계의 아방가르드, 공산주의자, 사회주의자, 근본주의자, 원리주의자, 순종주의자, 천재 프로그래머, 마지막 해커, 고집쟁이, 피리부는 아저씨, 사이비 교주 요러한 수식어가 따라다니는 사람이다.

이 사람이 어떻게해서 우리가 몸담고 있는 소프트웨어 바닥에 예술계에나 있을 법한 이러한 잘다듬어진 공동체, 해커 마인드를 만들게 되었는지, 소프트웨어 개발은 예술의 그것과 비슷하다라는 생각을 가지도록 했는지 즉 일종의 자존심을 가질 수 있는 문화의 기반을 닦았는지 생각해볼 필요가 있다. 이러한 현상은 예술계에서나 볼 수 있는 것이기 때문에 특이하며 때문에 생각해볼 가치가 있다.

우선 순수예술이라는 것에 대해서 좀 생각을 해봐야 겠다. 비록 소프트웨어 영역에서 처럼 성공적이진 못했지만 소프트웨어처럼 자본과 시장에 대항해서 그들 자신의 공동체를 지키고자 하는 운동들이 있어왔으며, 소프트웨어 보다는 더 오랜 역사를 가지고 있기 때문이다.

기실 예술이라는 것이 지금처럼 대접을 받게 된것은 그리 오래되지 않았다. 근대이전의 예술가는 독립적인 예술가가 아닌 교회 와 궁중의 후원을 받는 고용인에 지나지 않았다. 그러므로 자기가 만들고 싶은 것을 만들어낸다라는 지금의 예술가의 이미지와는 전혀달랐다. 후원을 받는 궁중과 교회에 봉사하는 고용인으로써 그들의 의뢰를 받아서 작품을 만들 따름이었으니 예술가라고 하기에는 부족함이 있었다. 실제 당시의 많은 작품들에 작가가 명시되어있지 않았던데에는 이러한 이유가 있었다. 레오나르도 다빈치, 바흐, 베토벤 정도되는 유명인 정도가 되어야 그나마 이름을 남길 수 있었으며, 이들 당대의 유명인 조차도 종속된 상태에서 벗어날 수가 없었다.

예술가가 예술가로써의 독립적인 지위와 명성 자존심을 회복 한것은 개인의 주체의 중요성이 부각된 르네상스 이후에서 부터이며, 이때부터 일반 대중은 예술에 대한 동경을 가지게 되고 그들을 존경하고 그들과 같이 되고자 하였다. 누구에게도 얽매이지 않고 자신이 만들고 싶어하는 것을 만들며 명성과 부를 누릴 수 있으며, 개인이 인간으로써 가져야할 자존감을 지켜나갈 수 있다!! 얼마나 매력적인가. 물론 이때의 예술가는 태어나면서 부터 자질을 타고난 천재라는 이미지가 강하긴 했지만 말이다.

자본이 지배하는 지금에서도 마찬가지일 것이다. 사람은 자본이나 회사 사회의 굴레에서 자본이나 혹은 고객을 위해서 무엇인가를 만들어내는 것보다는 자신이 자기를 위해서 무언가를 만들어내기를 원한다. 왜 예술가에 대한 동경을 가지고 있을까. 왜 자기 스스로가 자본가가 되길 원하는 것일까. 자기 자신을 위해서 무엇인가를 할 수 있기 때문이다. 자기가 자신을 위해서 무엇인가를 할 수 있다는 것은 자신의 삶을 자신이 책임질 수 있는 상태임을 얘기하는 것이다.

많은 노동자, 기술자들이 장신 혹은 예술가 처럼 그렇게 살기를 원한다. 정확히 말하자면 실용적 예술가라고 할 수 있는 장인이 되길 원한다. 그러나 실패했다. 소프트웨어 분야를 제외하고는... 다른 거의 모든 분야가 산업화되고 자본에 완전 종속되어 버렸다. 소프트웨어분야 처럼 해커문화, 장인문화, 풀뿌리 공동체 문화가 명백하게 남아 있는 분야는 없다.

소프트웨어를 완전히 산업에 종속시키지 않도록 만든데에는 역시 리차드 스톨만과 자유소프트웨어재단 그들의 이상에 따라주었던 도전적이고 열정적인 개발자들의 힘이 무엇보다 컸다고 할 수 있을 것이다. 적당히 자본과 타협하면서 적당히 우리의 자존심을 유지시켜줄 공동체를 지켜나가자라 고 안이하게 타협했던 다른 산업의 노동자와는 다른, 어찌 보면 정줄을 반쯤 놓은 사이비교주처럼 모든 상업, 독점, 자본, 시장, 상품에 일말의 타협도 없이 자신의 철학을 관철시킬려고 하는 이들이 있었기 때문에 어느 산업에서도 볼 수 없는 강력한 공동체를 만들 수 있었을 것이다.

많은 젊은이들이 소프트웨어영역에 대한 막연한 동경을 가지고 있는데에는 자유스러우며 반사회적이며 공동체지향적인 해커문화가 큰 역할을 하고 있다.

자유소프트웨어 재단과 오픈소스 진영의 껄끄러운 관계

많은 사람들이 자유소프트웨어운동과 오픈소스운동이 같은 것이라고 혼동한다. 때때로 오픈소스진영의 대부가 리처드 스톨만인 것으로 소개하는 문서들도 있다. 하지만 자유소프트웨어 재단과 오픈소스진영은 그닥 좋은 관계는 아니다.

2006년 리처드 스톨만이 한국을 방문해서 강연을 하는 와중에 자유소프트웨어가 아닌 오픈소스에 대한 질문을 하자 바로 차단신공을 발휘했다는 에피소드에서 보듯이, 일체의 어떠한 타협을 거부하는 자유소프트웨어 재단과 완고함은 비교적 자본과 시장과 유연한 관계를 보여주는 오픈소스진영은 (언뜻 이해되지 않기도 하겠지만)꽤나 껄끄러운 관계를 유지하고 있다.

아방가르드라고 할 수 있는 리처드 스톨만의 눈에 자본과 시장과 적당히 타협하는 모습을 보이는 오픈소스진영은 적과 손잡은 위험한 불순분자 정도로 보일지도 모르는 일이다. 아마도 분명히 그렇게 생각하고 있으리라고 생각한다. 그의 생각이 지나치게 완고하든지 간에 그의 그러한 행동은 오픈소스진영이 자본과 사회적 공동체 가운데에서 균형을 지킬 수 있도록 긴장감을 주는 것은 분명한 것 같다. 자본과 시장이라는 거대한 세력에 맞서서 자신들의 공동체를 지키려면 이러한 사람도 반드시 필요한 것이라는 생각이 든다.

산업화와 자본화의 거대한 물결속에서도 예술계와 소프트웨어계가 나름 이러한 공동체문화를 지켜나갈 수 있었던건 역량있는 이단아들이 활약해주었기 때문 아닐까.

Command Pattern

욕해가면서 가르쳐줘야 하고 필요하다면 때리면서 갈켜야 빨리 배울 뿐더러 한번 배운것 까먹지 않는 다는 얘기들이 있다.

여전히 사랑의 매라는 이름으로 체벌이 정당화 되고 가정내에서의 폭력역시 여러가지 이유를 들어서 눈감아 주거나 긍정해주는 현실이다. 가정과 학교가 이러하니 사회는 더 말할필요도 없다. 더 빨리, 더 잘 가르키기 위해서는 적당한 욕과 적당한 인격모욕적 행위가 필요한 것으로 인식이 되어지고 있고, 오히려 이렇게 하지 못하는 사람을 무책임하거나 제대로된 사회생활을 못하는 사람 취급을 받기도 한다.
 
나는 이 방식과 생각을 대단히 싫어한다.

이 방식은 대단히 나쁜 방식이다. 다만 결과가 빨리눈에 보인다는 점과 경쟁을 통해서 한명의 수제자만을 키워내기로 마음먹었을 경우 쓸만하다는 이유때문에 널리 사용되어지는 것으로 생각된다.

친구가 이런말을 하더라. 촬영을 가르킬 때 욕하면서 가르키는 거랑 그렇지 않은 거랑 습득속도에 있어서 상당히 큰 차이가 생긴다고.

욕을 하거나 맞거나 인격적으로 무시당하면서 배우면 정말로 잘 배운다. 우린 이걸 경험적으로 알고 있다. 한번 배운거 안까먹는다. 좋은 말로 해서는 안된다라는 말이 괜히 나온게 아니다. 게다가 성과와 결과와 효율이 최고의 가치가 되는 자본주의 사회에서야 더 말할필요도 없을 것이다.

욕을 먹거나 인격적으로 무시당하기를 원하는 사람은 없을 것이다. 그러하니 기를 쓰고 주어진 일을 주어진 방식대로 까먹지 않고 하려고 애를 쓴다. 때때로 자존심을 내세우는 사람들도 있지만 아주 소수만이 자신의 자존심을 내세울수 있을 뿐이다. 그러하니 대부분의 경우 일단 결과는 잘나온다. 그러나 인격적으로 무시를 당하게 되면, 사람의 몸과 마음이 위축이 되기 마련이다. 장점이 있으면 단점이 있는 법. 외연의 속도와 효율을 장점으로 하는 것들은 대게가 그 내연에 감추어진 눈에 보이지 않는 것들을 파괴시킨다. 결국 시키는 것만 잘하는 사람이 만들어지게 된다는 것이다. 복지부동형 인간이라고 한다. 새로운걸 하려고 하지 않는다. 왜 ? 실수하면 욕먹으니까. 인격적인 모독을 당하니까.

개중에는 욕을 먹어도 걸러낼 것은 걸러내고 흘려들을 건 흘려들여서 자신의 방향대로 밀고 배워나가는 소수의 사람들이 있다. 이런 사람들이 흔히 말하는 수제자가 되는 것이다. 몇명의 수제자를 키워내는 도제방식에서 폭력적인 수단이 꽤 잘 들어 맞는 것처럼 보인다는 얘기가 여기에서 나온다. 나머지는 낙오하거나 그냥 저냥 시키는 것만 해내는 주변인이 된다.

수공업이나 사람이 부속품 취급당하는 노동집약적인 산업이 아니면 그나마도 써먹기가 힘든방법이다. 특히 사고의 유연함이 중요한 소프트웨어 산업분야에서는 더 말할 나위가 없을 것이다. 그런데 여전히 도제방식의 반강압적인 학습방식이 사용되는 것 같다. 군대에서 그러했던 것처럼 욕하면서 갈궈야 제대로 배울 수 있다고 생각하는 경우가 많은 것 같다. 사수쯤 되는 위치에 있다면 한번 생각해 봐야할 것이다. 제대로 가르키는 것인지 아니면 제대로 가르키는 것처럼 보이는 것인지.