기존 계정에서 실행하는 것은 문제가 없는데 , 네트워크 상에서 (즉 WorkGroup 으로 묶인 계정으로) 로그인 해서 사용할려고 실행할 때 발생하는 에러를 해결하는 방법 입니다.

   
  Debugger entered--Lisp error: (error "The directory ~/.emacs.d/server is unsafe")
     signal(error ("The directory ~/.emacs.d/server is unsafe"))
     error("The directory %s is unsafe" "~/.emacs.d/server")
     server-ensure-safe-dir("~\\.emacs.d\\server\\")
     server-start(nil)
     call-interactively(server-start t nil)
     execute-extended-command(nil)
     call-interactively(execute-extended-command nil nil)


대충 이런 식으로 에러가 발생합니다. 붉은색 으로 표시된 디렉토리 이름은 상황에 따라 다르게 나옵니다. 제 경우에는 위와는 살짝 다르게 "C:\Users\sdssss\AppData\Roaming\.emacs.d\server" 이런식으로 표시 됐습니다.

이유는 간단합니다. 붉은색 으로 표시되는 디렉토리의 소유자 (Owner)가 다르기 때문입니다. 소유자를 바꿔주던가 하는 식으로 해결하는 방법도 있지만 저는

.emacs 파일을 열어서 맨 아래쪽에 다음과 같이 추가해 줍니다.

  
(require 'server)
   (when (and (= emacs-major-version 23)
           (= emacs-minor-version 1)
           (equal window-system 'w32))
   (defun server-ensure-safe-dir (dir) "Noop" t))
   (server-start)


간단하게 설명하자면 server-ensure-safe-dir 이라는 함수가 안전한지 여부를 확인하는 함수인데 소유자 건으로 이 함수에서 에러를 뱉어 내는 것입니다. 이 함수를 무조건 t 만 리턴하는 거수기 함수로 바꿔버리면 모든 것은 간단하게 끝이 납니다.

그리고 추가로 "C:\Users\sdssss\AppData\Roaming\.emacs.d\server"  이 디렉토리 의 마지막 즉 server 디렉토리를 $HOME/.emacs.d 안으로 복사해줍니다. 이건 또 왜 해주냐면, server-ensure-safe-dir 함수가 거수기가 되 버려서 , $HOME 밑에서 server 의 존재를 찾습니다. 따라서 복사해주면 모든 것이 OK 입니다.





바야흐로 폭발적인 데이터의 시대가 왔습니다. 저번 포스트 에서도 언급을 했지만 RDBMS 와 다르게 확장을 주요 특징으로 하는 것이 NoSQL 입니다. 즉 '분산' 으로 그 폭발적인 데이터들을 전부 수용이 가능합니다.

이러한 NoSQL 중에서 CouchDB 를 잠시 살펴보기로 하겠습니다.

http://couchdb.apache.org/

위 링크에서 대략적인 것을 살펴 볼 수가 있습니다. CouchDB 의 가장 큰 특징은 (절대적으로 제 관점입니다)

Subversion 같은 파일 레파지토리 시스템 (File Repository System)을 분산 DB 형태로 바꾸어 놓은 것이라고 할 수 있습니다

세세한 몇가지 특성을 살펴보기로 하겠습니다.

1. Erlang 이란 언어로 쓰여짐
 
가장 빠른 속도를 자랑한다는 소리만 많이 들었습니다만 아직 써보지는 않았습니다. 컴퓨터 언어세계에서 몇개국어 이상을 하다 보니 더 이상 언어 배우는게 힘들더군요. (게임할 시간도 부족.. 쿨럭)

2. DB 속성중 일관성 (Consistency) 가 강화 됐다.
 
저번 포스트 에서 언급 했던 CAP 이론중에서 CP 쪽 특성을 가지고 있는 것이라고 볼 수 있습니다.

3. 사용하기 쉽다
 
몽고디비 (MongoDB) 같은 계열의 특징입니다. 가장 주요하게 설치될때 웹서버도 같이 설치되고 클라이언트랑 HTTP로 통신하고 데이터를 Json 방식으로 주고 받습니다. 당연히 사용하기 쉽겠지요?

4. 양방향 복제 (Bi-Directional Replication)
 
생물학에서 나온 용어 입니다. 초기 세포분열이 시작될때 한 시점을 바탕으로 해서 양쪽으로 똑같이 복제 되가는 형태를 말합니다. 여기서는 데이타가 초기에 디비에 저장될 때, 똑같이 양쪽으로 복제가 일어나는 것을 말하나 봅니다.

5. Document - Based 방식

데이타를 문서 형태로 저장합니다. 초장에 설명 드릴 때 SVN (Subversion) 방식의 디비화 라는 설명을 드렸습니다.

6. RESTful HTTP API 를 지원한다.
 
3번하고 연결되는 내용이기도 합니다만, 성격이 조금 다르지요. 말 그대로 API 형태로 RESTful 방식을 지원합니다.

7. 읽고 쓸 때 락 (Lock)이 없다.
 
보통의 디비랑 다른 점이라고 할 수 있지만, SVN 시스템을 써보셨다면 이해하실 것입니다. 락은 없지만 Conflict 는 생길 수가 있다는 점이 특징입니다. 따라서 마치 SVN 처럼 Conflict 가 생겼다면 변경된 내용이 추가되서 변경할 수 있게 합니다.

8. Crash-Only 설계가 적용되었다.
 
데이터 파일이 항상 무결한 상태에 있음을 보장하기 위해서 캐쉬에 일부 저장했다가 커밋시 커밋된 데이터나 관련된 자료구조를 덮어 쓰지 않는다고 합니다. 개별적인 특징으로 시스템이 돌아가던 서버가 갑자기 꺼진다고 해도 데이터는 무결한 상태가 유지되는 것입니다. 즉 일반적으로 셨다운 (Shutdown)이 없다고 합니다.

9. MVCC (Multi-Version Concurrency Control) 지원
 
이것이야 말로 가장 SVN 같은 시스템과 비슷한 기능입니다. 여러 클라이언트가 동일한 문서를 보고 있다고 해도 그 동일한 문서가 같은 버젼일 수가 없습니다. 즉 어려운 말로 하자면 읽기의 시작부터 끝까지 일관된 스냅샷 (Snap Shot)을 보게 됩니다.

10. 인덱스 업데이트가 언제나 파일 끝에서만 발생하도록 설계됨

11. 컴팩트(Compact) 를 시켜줘야 한다.
 
 데이터 파일을 저장하는 단위는 일정 크기 (MongoDB 는 16메가)로 늘어나게 되어 있는데 , 이 파일의 크기가 한 없이 늘어나는게 아니라 어느 정도 데이터의 가감이 일어나면 크기를 다시 일정한 크기로 줄여줘서 유지하는 방식을 말합니다.

12. _changes 를 이용한 실시간 갱신

사용자가 보고 있는 문서(Document)가 변경 됐으면 _changes 메시지가 클라이언트측에 도착합니다. 그래서 실시간으로 갱신이 되거나, 편집중이였으면 Conflict 가 발생합니다.

13. JQuery Library 가 포함되어 있다.
 
Javascript 형식의 Map/Reduce 도 지원하는데 이러한 것이 가능한 이유가 독립적으로 JQuery Library 가 포함되어 있기 때문입니다.

14. 활용 되는 곳
 
누적 데이터나, 데이터가 전반적으로 바뀌는 변화가 별로 없는 곳, 실행될 질의가 미리 정의되어 있는 곳 , 데이터들의 버젼 관리가 중요한 곳 (마치 Subversion 을 디비화 시킨것 처럼) 보통 CRM (Customer Relationship Management) 나 CMS (Conversational Monitor System) 같은 곳에서 쓰이기 좋습니다.




최근에 다시 피씨를 세팅할 일이 생겨서 (Windows 7) EmacsW32 최신 버젼과 서브버젼 (Subversion) 최신 버젼을 설치하게 되었습니다.

어찌된 일인지 갑자기 잘 되던 SVN 과 Emacs 의 연동이 안되더군요. 그래서 여러가지 방법을 시도하던 와중에 문제점을 발견했습니다.

디렉토리 구조중 최상위 (Root) 를 제외하고는 .svn 폴더들이 전부 사라진 것이였습니다.


이것도 모르고 Emacs 를 버젼별로 깔아대는 삽질을 하고 있었습니다. 결국 비효율적이라고 판단한 svn 개발팀에서 하위 디렉토리의 .svn 폴더들을 삭제하는 결정을 한 것이겠지요. 따라서 엄한 emacs 사용자들만 야단이 났습니다. 지금 릴리즈 되는 버젼들에는 저 변동사항이 적용이 안 되어 있기 때문이지요.

해결 방법은

1. http://bzr.savannah.gnu.org/lh/emacs/trunk/files/head:/lisp/vc/ 사이트에 가셔서 vc-svn.el 을 다운 받고

2. emacs 가 설치되어 있는 곳의 lisp 파일 모아둔 곳으로 이동하셔서 (제 경우에는 C:\Program Files\Emacs\emacs\lisp 에 있습니다) vc-svn.el 과 vc-svn.elc 를 삭제하시고

3. 1에서 다운 받은 파일을 대신 복사해 주는 것입니다. (vc-svn.el 을 컴파일 하고 안하고는 자유 이십니다. 전 귀찮아서 안했음)

완벽하게 해결이 된 것을 확인하 실 수 있습니다.

2012 년 1월 - 2월 통합본 by Ramon Casadesus-Masanell and Jorge Tarzija'n

원본 링크 - http://hbr.org/2012/01/when-one-business-model-isnt-enough/ar/1

"두개 혹은 그 이상의 비지니스 모델 (Business Model)을 동시에 운영하는 것은 매우  어렵다. 그렇지만 회사가 한 단계 도약하기 위해서는 각기 다른 비지니스 모델을 잘 활용해야 한다."

라고 주장을 하고 있지만 여러개의 비지니스 모델을 운영하는 것은 대체적으로 실패합니다.

항공 사업이 특히나 힘들다고 알려져 있습니다. 그렇기 때문에 여러 비지니스 모델중에서 한 가지만 선택해서 집중적으로 발전 시킨 '사우스웨스트' 항공사가 각종  경영 서적들에서 성공 사례로 집중적으로 다루어 지고 있는 이유겠지요.

이럼에도 불구하고 '칠레'의 항공사인 LAN 항공 의 성공 사례를 본 아티클은 소개하고 있습니다. 무려 3가지의 비지니스 모델을 결합시켜서 운영하고 있습니다.

  
국내 여객선 (운송) - 국제 여객선 (전체 서비스) - 화물 수송


사실 이러한 전략적 비지니스 모델의 운영은 여타 항공사들도 시행하고 있는데, LAN 항공만 성공하는 데는 특별한 이유가 있다고 저자들은 보고 있습니다.

이런 전략의 핵심은 '대체제 - 보완제' 에 관한 정의에 있다고 저자는 말합니다. 즉 핵심 인재들의 역량과 회사의 자산을 공유할 수 있는 성격이 강한 비지니스 모델은 '보완제' 성격이 강하기 때문에 동시에 운영할 수 있고 그렇지 않은 것은 '대체제' 성격이 강하기 때문에 동시에 운영하기 힘들다는 것입니다.

그러나 사실 제가 보기에는 이는 '칠레'의 특별한 환경이 존재하기 때문에 가능하다고 봅니다. 칠레의 특산품 (연어 , 아스파라거스, 꽃)들을 빠르게 유럽등지로 수송할 수 있는 장점이 있기 때문에 , 그리고 이러한 '화물 수송 관점'에서 사람의 운임을 책정하기 때문에 다른 항공사보다 최저가의 운임을 매겨 (가격 파괴 효과) 사람 운임만으로는   가기 힘든 노선도 개발할 수 있는 장점이 있습니다.

그리하여 동의하기는 힘들지만 2가지 이상의 비지니스 모델을 운영한다는 것은 위험이라기 보다는 새로운 전략도구라는 것입니다. 다만 그런 비지니스 모델은 위에서 설명한 '대체제'라기 보다는 '보완제'라는 성격이 강해야 하겠지요.



저자 : 제임스 휘트니 힉스 | 역자 : 임옥희 | 감수 : 김문두 

"이 책에 따르면 주변에 정신 병자 아닌 사람이 없고, 현대 사회는 (특히 한국) 미쳐가는 사회다" 

기대했던 것보다는 재미가 많이 떨어진 책입니다. 정신과 의사 입문 교양서 같은 느낌이 강한 작품이였습니다. 이 책이 대체 어디에 쓸만한 것일까를  제가 대신 고민하다 내린 결론은 레퍼런스 북으로 두고 자신이나 주변사람의 어떤 이상 징후가 느껴진다면 그때 책을 펴서 그 부분에 관한 것을 찾아보고 심신의 안정을 느끼는 것이 최우선일 때? 

너무 혹평을 한것 같기는 하나 정말 제가 읽기에는 집중도 안되고 재미도 많이 떨어졌습니다. 그렇지만 각 증상에 대한 정의와 간단한 사례 부분은 재밌게 읽을 수가 있었습니다. 

제가 개인적으로 재미있게 읽었던 부분과 평소 '아주 심각한 병' 이라고 생각하는 부분에 대한 것을 예로 들어보겠습니다.


Religious Preoccupations ( 종교적인 집착 )

종교적인 신앙, 주체성, 타인의 구원에 대해 지나치게 몰두하는 것

"오, 주여, 주님을 위해 찬송하게 하소서!"
당신은 성경책을 치켜들고 거리 한복판에 서 있다. 왜 모든 사람들이 찬송가를 부르지 않을까? 출근 차량들이 빵빵거리면서 당신을 피해서 돌아간다. 등교하는 학생들이 불안한 듯 종종걸음으로 당신의 곁을 지나친다. 오늘 당장 이라도 하나님이 임하실 것이라는 것을 왜 저들은 알지 못할까?
한밤중에 하나님의 목소리가 당신에게 들렸다. "그대가 빛과 진실을 전파하라." 그래서 당신은 꼬박 밤을 새웠다. 집안의 전등과 차고의 전등에 전부 불을 밝혀놓았다. 당신은 초를 들고 거리로 나가 촛불을 켰다. 태양이 떠오르고 있는데, 당신은 쓰레기통에 신문을 가득 던져 넣고 불을 붙였다. 하나님이 기쁨의 신호를 보냈다. 당신은 하나님이 오심을 알리기 위해 거리로 나갔다.

(몇개의 오타를 수정하고 하느님 -> 하나님으로 문맥에 맞게 수정하였음)



이런식으로 사례를 스토리 텔링 기법을 써서 표현한 것은 흥미롭게 읽었지만 그 뒤로 나오는 내용은 걍 정신과 상담과 그에 대한 치료법을 소개하는 것 같았습니다.

결론은 종교적인 집착은 심각한 정신병이라는 것입니다. (응? ..)

 
 
힘들게 저번 포스트 에서 정리를 했더니  더 쉬운 방법이 있다고 알려줘서 정리를 해 둡니다. (시작할 때 왜 알려주지 않은건가여.. )

저번과 거의 동일 합니다.

1. 아파치 설치하기 

$ sudo apt-get install apache2


2. 톰캣 설치하기 

$ sudo apt-get install tomcat7 tomcat7-docs tomcat7-admin tomcat7-examples


  설치해두면 언젠가는 쓸모가 있으니 한꺼번에 설치해줍니다. 

3. 제대로 설치됐는지 확인해보기 

   http://localhost  와 http://localhost:8080 

  으로 페이지가 제대로 뜨는지 확인해 줍니다. 만약 페이지가 제대로 뜬다면 apache2 와 tomcat7 은 제대로 설치된 것입니다. 

여기까지는 동일하고 여기서부터 살짝 바뀝니다.

4. 톰캣 에서 커넥터와 연결시키기 

$ sudo emacs /var/lib/tomcat7/conf/server.xml 


   에서 


       <!-- Define an AJP 1.3 Connector on port 8009 -->
       <!--
       <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
       -->


   로 되어 있는 부분에서 주석을 제거해서 

 

     <!-- Define an AJP 1.3 Connector on port 8009 -->
       <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />


   로 변경합니다. 이것은 포트 8009 로 날라오는 프로토콜(protocol)이 AJP/1.3 인 것은 8443 포트로 넘기라는 것입니다.  8443은 톰캣 서버가 처리를 하는 포트라고 보시면 됩니다.   


5.  Proxy_AJP 모듈 활성화 시키기

소개해주신 분의 말씀으로는 아파치와 톰캣을 너무 자주 연결시키다 보니 아파치에 아예 포함되서 나오게 됐다고 합니다.

 $ sudo a2enmod proxy_ajp  



이 부분이 저번 포스트에서 언급했던 커넥터 부분과 동일한 기능을 하는 부분입니다.  

6. 아파치 에서 톰캣 연결시키기 

$ sudo emacs /etc/apache2/sites-available/default 


   이 부분에 대한 언급이 없어서 제일 어려웠던 부분입니다. 위의 파일을 열어서 


  

       DocumentRoot /var/www
   <Directory />
     Options FollowSymLinks
 AllowOverride None
   </Directory>
   <Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
  </Directory>


   인 부분을 찾아서 


DocumentRoot /var/lib/tomcat7/webapps/ROOT
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/lib/tomcat7/webapps/ROOT/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

        ProxyPass /servlet/ ajp://localhost:8009/servlet/
        ProxyPassMatch ^/.*\.(jsp|do)$ ajp://localhost:8009/

 로 바꾸어 줍니다. 즉 /var/www 을 /var/lib/tomcat7/webapps/ROOT 로 바꾸어 주는 것입니다. 그리고 아래쪽에 

ProxyPass /servlet/ ajp://localhost:8009/servlet/
ProxyPassMatch ^/.*\.(jsp|do)$ ajp://localhost:8009/

를 추가해줍니다. 부연 설명을 하자면 아파치(apache)가 바라보고 있는 DocumentRoot 와 톰캣이 바라보고 있는 webapps/ROOT 를 같은 곳을 바라보게 해주는 것입니다. 그리고 맨 아래에 추가해 준것은 jsp 와 do 로 끝나는 파일은 ajp 프로토콜로 8009 번 포트로 리다이렉션 해주라는 것입니다. 

 
7. 테스트페이지를 만들어 봅니다. 

$ sudo emacs /var/lib/tomcat7/webapps/ROOT/hello.jsp 


   내용은 

  

<HTML>
   <BODY>
   Hello!  The time is now <%= new java.util.Date() %>
   </BODY>
   </HTML>


  로 채우고 저장합니다. 

8. 톰캣과 아파치 재시작 (Restart)

$ sudo /etc/init.d/tomcat7 restart
  $ sudo /etc/init.d/apache2 restart



9. 브라우저에서 
   
    http://localhost  와 http://localhost/hello.jsp 로 테스트 해봅니다.


 
아파치 와 톰캣7.0(Tomcat 7.0) 을 연동시키는 방법에 관한 글입니다. 많은 분들이 당연히 연동 시켜야 한다고 
생각할지 모르지만 톰캣 자체에 웹서버가 포함되어 있기 때문에 꼭 해줄 필요는 없습니다. 

그렇다면 왜 해주는 것인가? 하는 의문이 들 수 있습니다. 톰켓 자체는 서블릿과 JSP 해석에 일을 집중시키고 아파치 자체는 html 과 그외 나머지 리소스를 처리하게 해주는 식으로 분산 시켜주는 효과가 있습니다. 고작 저 따위 이유로  많은 분들이 설정하느라고 고생한다고 합니다. 

그래서 손쉽게 따라하기로 연동시켜보기로 합니다. 

1. 아파치 설치하기 

$ sudo apt-get install apache2


2. 톰캣 설치하기 

$ sudo apt-get install tomcat7 tomcat7-docs tomcat7-admin tomcat7-examples


  설치해두면 언젠가는 쓸모가 있으니 한꺼번에 설치해줍니다. 

3. 제대로 설치됐는지 확인해보기 

   http://localhost  와 http://localhost:8080 

  으로 페이지가 제대로 뜨는지 확인해 줍니다. 만약 페이지가 제대로 뜬다면 apache2 와 tomcat7 은 제대로 설치된 것입니다. 

4. 톰캣 과 아파치를 연결시켜주는 커넥터(Connector) 설치하기

$ sudo apt-get install libapache2-mod-jk


5. 커넥터 설정 

$ sudo emacs /etc/libapache2-mod-jk/workers.properties


   로 열어서 안의 내용을 보면 

workers.tomcat_home=/usr/share/tomcat6


   이것을 실제로 톰캣이 깔려 있는 곳으로 바꾸어 줍니다. tomcat7 에는 

  workers.tomcat_home=/var/lib/tomcat7


  로 바꼈습니다. 그리고 worker.list=ajp13_worker 이 항목을 기억하셔야 합니다. 

6. 톰캣 에서 커넥터와 연결시키기 

$ sudo emacs /var/lib/tomcat7/conf/server.xml 


   에서 


       <!-- Define an AJP 1.3 Connector on port 8009 -->
       <!--
       <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
       -->


   로 되어 있는 부분에서 주석을 제거해서 

 

     <!-- Define an AJP 1.3 Connector on port 8009 -->
       <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />


   로 변경합니다. 이것은 포트 8009 로 날라오는 프로토콜(protocol)이 AJP/1.3 인 것은 8443 포트로 넘기라는 것입니다.  8443은 톰캣 서버가 처리를 하는 포트라고 보시면 됩니다. 
 

7. 아파치 에서 톰캣 연결시키기 

$ sudo emacs /etc/apache2/sites-available/default 


   이 부분에 대한 언급이 없어서 제일 어려웠던 부분입니다. 위의 파일을 열어서 


 

       DocumentRoot /var/www
  <Directory />
    Options FollowSymLinks
AllowOverride None
  </Directory>
  <Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
 </Directory>


  인 부분을 찾아서 


DocumentRoot /var/lib/tomcat7/webapps/ROOT
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/lib/tomcat7/webapps/ROOT/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

    JKMount /*.jsp ajp13_worker


 로 바꾸어 줍니다. 즉 /var/www 을 /var/lib/tomcat7/webapps/ROOT 로 바꾸어 주는 것입니다. 그리고 아래쪽에 

 JKMount /*.jsp ajp13_worker 

를 추가해줍니다. 부연 설명을 하자면 아파치(apache)가 바라보고 있는 DocumentRoot 와 톰캣이 바라보고 있는 webapps/ROOT 를 같은 곳을 바라보게 해주는 것입니다. 그리고 맨 아래에 추가해 준것은 jsp 로 끝나는 파일은 ajp13_worker 를 통하라는 뜻인데  ajp13_worker 를 통해서 톰캣으로 전송하는 것입니다. 

8. 테스트페이지를 만들어 봅니다. 

$ sudo emacs /var/lib/tomcat7/webapps/ROOT/hello.jsp 


   내용은 

 

<HTML>
  <BODY>
  Hello!  The time is now <%= new java.util.Date() %>
  </BODY>
  </HTML>


  로 채우고 저장합니다. 

9. 톰캣과 아파치 재시작 (Restart)

$ sudo /etc/init.d/tomcat7 restart
  $ sudo /etc/init.d/apache2 restart



10. 브라우저에서 
 
    http://localhost  와 http://localhost/hello.jsp 로 테스트 해봅니다. 




 

무엇인가를 해 볼려면 역시 설치부터!! 정말 하둡 초 간단 따라하기 식 설치에 대해서 알아봅니다. 

시작전에 환경세팅이 필요합니다. 어떤 OS 기반위에 설치할 것인가를 정해야 하는데 저는 그냥 리눅스로 정했습니다. 환경세팅자체도 쉽고 하둡도 리눅스를 추천하고 있기 때문입니다. 그래서 가장 최근에 릴리즈된

우분투 11.10 (Ubuntu 11.10) - 다운로드 페이지

로 정했습니다.

하둡 설치 형태는 3가지로 나뉩니다.

1. StandAlone
 - 하둡 파일 시스템을 띄우지 않은 상태에서 동작하는 것만 테스트 해 볼 수 있는 상태이다. 
 
2. Pseudo Distribution
 - 하둡 파일 시스템을 구동시키고 한 컴퓨터에서 모든 데몬들을 띄워서 동작하는 것을 테스트 해볼 수 있는    상태 

3. Cluster
 - 실제로 파일 시스템을 만들고 각 클러스터가 독립적인 기계로 동작하는 방식 

 
이중 StandAlone 과 Pseudo Distribution 을 싱글노드 (Single - Node ) 방식이라고 합니다. 즉 한대의 컴퓨터에서 설치해서 동작시킬 수 있기 때문입니다.  이중 정말 간단한 StandAlone 방식으로 설치해 보겠습니다.

Linux 에서 '터미널' 프로그램을 실행한 후에 

$ sudo apt-get install ssh 
$ sudo apt-get install rsync


위와 같이 입력해서 SSH 서버와 Rsync 를 설치해줍니다. Rsync 는 일반적으로 설치가 되어 있습니다. 기본 준비가 되어 있으면 다음은 하둡을 설치해줄 시간입니다. 

http://ftp.daum.net/apache//hadoop/common/stable/

위 주소를 클릭해서 다운을 받습니다. 최신버젼을 안 쓰고 안정화 버젼을 쓰는 것은 어찌보면 당연합니다. 어디서 문제가 생길지 모르는 버젼보다는 이미 많이 밝혀져서 안정화 버젼을 쓰는 것이 정신 건강상 좋기 때문입니다.

하둡을 실제로 실행하기 전에 환경 변수를 챙겨줘야 합니다. $HOME 에 있는 .profile 파일을 열어서 다음과 같은 내용을 추가해줍니다.

export JAVA_HOME="/usr/lib/jvm/default-java"
export HADOOP_HOME="/home/crazia/work/hadoop-0.20.203.0"


HADOOP_HOME 에서  'crazia' 는 본인의 아이디로 대체 합니다. 
그리고 다시 '터미널' 창에서 다음과 같이 입력해서 변경점을 적용해줍니다. 

$ source ~/.profile 


그리고 $HADOOP_HOME/conf/hadoop-env.sh 파일을 열어서 

# export JAVA_HOME=/usr/lib/j2sdk1.5-sun


위와 같은 부분을 찾아서 그 밑에 

export JAVA_HOME=/usr/lib/jvm/default-java


라고 추가해 줍니다. 이제 여기까지 따라 했으면 준비가 끝났습니다. 간단하게 테스트 해보기로 하겠습니다.

터미널 프로그램에서 $HADOOP_HOME 으로 이동해서 
 

$ mkdir input 
$ cp conf/*.xml input 
$ bin/hadoop jar hadoop-examples-*.jar grep input output 'dfs[a-z.]+' 
$ cat output/*


위와 같이 입력해. 그리고 결과를 확인해 봅니다. 만약 결과가 나온다면 설치는 성공한 것입니다.

사실 여기까지는 정말 별거 아닙니다. 다음 설치를 위한 준비과정이라고 생각하시면 됩니다. 그냥 부담 없이 처음부터 끝까지 쭈욱 따라가기만 하면 설치됩니다. 그리고 다시 한번 개발을 위해서라면 리눅스(Linux) 특히 그중에 우분투( Ubuntu )를 강력 추천합니다.


   
  
 


저자 : Ramon Casadesus Masanell, Joan E. Ricart

    대부분의 기업이 타사와의 경쟁을 고려치 않고 비지니스 모델을 만들기 때문에 대부분 실패하게
    됩니다. 기업간의 경쟁이 고려된 비지니스 모델의 상호작용을 통해서 자사에게는 선순환(Virtuous Cycle)
    을 가져오고 , 덤으로 경쟁기업의 선순환을 약화시킬 수 있습니다.

    그렇다면 어떻게 이런 비지니스 모델을 만들 수 있는 것일까요? 아니 그전에 대체 비지니스 모델이란
    무엇이라고 필자가 생각하는 것일까요?

    
비지니스 모델이란 '선택(Choices)' 와 '결과(Consequences)' 로 이루어 져 있습니다.

    1. 선택
       - 정책 : 조직 운영 전반에 관한 결정
       - 자산 : 기업이 사용하는 유형 자산에 대한 선택
       - 관리 : 정책/자산 선택을 위한 의사결정권에 대한 선택

    2. 결과
       - 유연함 : 정책 결정에 따라 쉽게 변경되는 결과
       - 고정된 : 오랜 기간 정책을 통해 만들어진 문화 같은 것, 타사에서 모방하기 어려운 것


    즉 이런 것들이 포함 된 것이 비지니스 모델이라고 할 수 있는 것이라 합니다.

    그러면 이러한 비지니스 모델을 가지고 무엇을 해야 하는가에 대한 답변을 필자는 하고 있습니다.


    1. 어떻게 비지니스 모델이 선 순환을 생성해 내는가?

       '무엇이 좋은 비지니스 모델인가?' 에 대한 답이 필요

       1) 기업의 목표와 일치성
       2) 자기 강화
          반복을 계속할 수록 점점 강화되는 성질
       3) 견고성


       위에서 나온 (비지니스 모델이란 선택과 결과로 이루어짐) 정의에 따라서 올바른 선택을 통한 결과에
       힘입어 더 좋은 선택을 하게 되며 이런한 과정들이 반복될 수록 좋은 비지니스 모델이 된다는 것입니다.


    2. 비지니스 모델로 경쟁하기

       경쟁자가 없을 때는 선순환의 효력을 주입 시키기 쉽지만, 경쟁이 없을 순 없습니다. 비슷한
       경쟁업체와 경쟁하기 위해서는 기업은 신속한 결정과 그에 따른 결과에 따라 경쟁업체보다 많은
       가치를 창출해야 합니다. 비슷하지 않은 비지니스 모델을 갖춘 기업과 경쟁할 때는 결과를 쉽게
       예측할 수가 없고, 어느 비지니스 모델이 더 잘 수행되는지 알기 어렵습니다.

       - 나의 선 순환을 강화하기

         경쟁자와 더 효과적으로 경쟁할 수 있도록 수정된 비즈니스 모델은 새로운 선 순환 과정을 창출하고
         강화시키는 결과를 가집니다.

       - 상대편의 선 순환을 약화시키기

         리눅스(Linux) 와 마이크로 소프트(Microsoft Windows) 의 경우를 보면 Linux 는 잠재적 가치가 큰
         무료 OS 지만 이를 대응하는 마소의 정책을 보면, 윈도즈 어플리케이션이 리눅스에 돌아갈 수
         있게 절대 허락을 안함 (Mac 에서는 오피스를 돌릴 수 있게 허락했었음)

         리눅스의 가치 창출 잠재력은 이론상으로 윈도즈 보다 더 클 수 있지만, 가치창출의 구동기반인
         소프트웨어쪽을 포함시키지 못하면 절대 마소를 이길 수가 없습니다. (특히나 게임쪽을 보면 더욱
         그렇습니다)

       - 경쟁자를 동반자로 만들기

         다른 비지니스 모델을 갖춘 경쟁자는 가치 창출에서 동반자가 될 수 있습니다. 잠정적으로 보면
         시장의 파이가 커지는 효과를 가져올 수가 있습니다.

    * 비지니스 모델과 전략 과 전술 구분하기

      - 비지니스 모델

        기업을 운영하고, 경쟁시장에서 주주가치를 창출하고 포착할 것인지에 대한 기업논리를
        말합니다. 정확히는 필자가 말했던 것이 정의가 되겠지요.

      - 전략

        차별화된 일련의 활동과 관련되서 유일하고 가치 있는 기업의 위치(position)을 만드는 계획을
        뜻합니다. 기업이 시장에서 어떻게 경쟁하길 원하는지에 대한 선택의 결정을 내포하고 모든
        발생가능한 상황(경쟁자의 움직임 혹은 환경적인 충격과 같은)에 대해서 어떠한 비지니스 모델을
        "임시적"으로 사용할 것인가에 대한 계획을 말합니다.

      - 전술

        전략보다는 비용부담이 적습니다, 그래서 비지니스 모델이 시장에서 전술을 결정합니다.


        새로운 비지니스 모델을 만들던, 기존의 비지니스 모델을 더욱 강화시킬때 이던
        경쟁을 고려하여 선순환을 강화 시킬 수 있는 모델을 염두에 두고 구상하면 더욱
        좋을 것 같습니다.





세상 어디에서나 존재하는 안티세력은 점점 더 개인적인 성향으로 점조직화 하고 소셜 네트워크 같은 새로운 매체를 이용해서 기업에 심각한 위협을 가할 가능성이 있습니다. 이 아티클은 이러한 안티들과 어떻게 맞서 싸울 것인지에 대한 방법을 말하고 있습니다.


기업형 '정보전쟁'에서 승리 또는 방어 하기 위한 5가지 전략을 소개 합니다.

1. Avoid any show of Force
 - 힘있게 보이는 것을 피하라 (그것은 심하게 불공평하게 보이기 때문이다)

명성을 둘러싼 전쟁에서는 많은 자원을 가졌다고 사람들에게 우호적으로 보이지는 않습니다. 오히려 더 큰 사회적 책임이 있다고 보이는 경향이 있습니다. 이러한 것은 심지어 자기 보호를 위해 하는 행동에서조차도 공정하게 보여야 한다고 말해집니다.


2. Respond at high speed with instincts honed by advance training.
 - 훈련을 통해서 미리 갈고 닦은 본능으로 신속하게 (정말 중요함) 대응하라.

대부분의 기업들은 (특히 대기업) 행동이 재빠르지 못하고, 내부의 모든 사람들의 의견이 일치할 때까지 기다리는 경우가 많습니다. 기업 내에서 대처방안에 대해서 열띤 토론을 나누는 시간 동안 피해는 걷잡을 수 없이 눈덩이처럼 늘어나는 경우가 많습니다.


3. Empower frontline teams to meet message with counter message
 - 현장 (일선)에서 일하는 팀에게 반박글을 작성할 수 있는 권한을 주라.

대중은 높은 자리에 있는 사람보다 말단으로 일선(현장)에서 일하는 사람들에게 더 친밀감을 느낀다고 합니다. 회사의 비젼과 가치를 공유하는 직원은 훌륭한 지원군이 되기 때문에 그들을 적극적으로 활용해야 하지만, 고객의 보호나 회사의 기밀 유출에 관한 어느 선까지 허용할 것인지에 대한 가이드 라인을 지속적으로 제공 하고 교육시켜야 합니다.


4. Go rogue in your own tactics
 - 자신만의 전략으로 밀고 나가라.

새로운 미디어 (소셜 미디어 같은)는 기회보다는 위협으로 인식되는 경우가 많습니다. 하지만 도덕적으로 올바르게 사용만 한다면 얼마든지 좋은 기회로 활용될 수 있습니다. (HBR 2010. 11월호 - What’s Your Personal Social Media Strategy? 참조 )


5. Recruit and Deploy “force multipliers” who will echo your message
 - 당신의 메시지를 퍼뜨릴 지원 세력을 구성하고 활용하라.

평판이 대 재앙 수준으로 급격하게 떨어지고 있을 때는 아무리 커다란 '대 기업' 이라고 해도 '지원 세력'을 필요로 합니다. 지원 세력은 말 그대로 기업을 지지하는 독립된 써드파티들의 네트워크를 포함해야 합니다. (이래서 커뮤니티를 운영하는 것이 큰 도움이 된다고 말을 하나 봅니다)


6. Go into Battle with credentials in place
 - 상황에 맞는 자격을 가지고 전쟁터에 나가라.

지원세력을 이용하기 위한 가장 필요한 옵션은 기업이 행했던 '선행'에 대한 자격입니다. 쉽게 말하자면 5번에서 나온 지원 세력이 옆에서 지원을 (인터넷 용어로는 '쉴드' 쳐준다고 합니다) 할려고 해도 기업을 좋게 말하게 할 수 있는 '꺼리'를 가지고 있어야 한다는 것입니다. 착한일을 많이 해 온 기업이면 지원 세력들이 쉴드 쳐주기 쉽다는 것이죠.


대기업에서 큰돈을 이용해서 기존 매체(뉴스, TV , 라디오)를 이용하는 방식만 익숙한 관리자들은 중학생 정도면 쉽게 이용할 수 있는 새로운 미디어 (블로그, 트위터, 페이스 북 등등)를 이용하는데 거부감을 느낄 수도 있습니다. 하지만 이러한 새로운 미디어는 새롭게 등장하는 안티세력들의 강력한 무기가 될 수 있는데 이러한 것들에 익숙하지 않으면 눈뜨고 당할 수도 있습니다. 실제로 많은 글로벌 세계 기업들 조차 이런 사실을 망각하고 많은 평판손해를 입었습니다.

하룻밤도 채 지나지 않아서 기업의 평판이 나락에 떨어질 수 있다는 것을 인식하고 새로운 미디어에 익숙해져야 하며 명성전쟁의 원칙(위의 5가지 원칙)을 가짐으로서 기업은 안티세력의 갑작스러운 최악의 공격으로부터 사업을 보호할 수 있습니다.

아티클에 나와 있는 사례들은 기업 사례의 일반적인 것이라서 최근 이슈가 됐던 타블로 논쟁과 도올의 케이스를  2번 원칙을 미루어 생각해 보았습니다.

도올 (하바드) 과 타블로 (스탠포드)는 둘다 학력 논쟁에 휩쌓였습니다. 타블로가 대응을 5년동안 미루어 오면서 (실은 간간이 소극적인 대응을 하긴 했습니다) 최근에 어떤 일을 겪었는지는 말할 필요도 없을 것입니다. 그와 대비해서 도올은 학력논쟁 이슈가 사람들 사이에서 나오자 마자, 하바드 졸업장을 방송에서 공개 했습니다. 신문지에 쌓여진 하바드 졸업장을 보는 기분이 묘하더군요 ㅎㅎ . 그것 한방으로 모든 이슈는 종식되고 오히려 더 많은 사람이 도올이 정말 많이 배운 사람이라는 것을 실감하게 됐습니다. 신속대응의 좋은 사례라고 보입니다.


아래는 세미나시 나왔던 이슈에 대한 정리 입니다. 참조하세요 





+ Recent posts

티스토리툴바