Dharma

   by Marco Bertini , John T. Gourville

   "소비자는 봉이 아니다. 기업과 함께 가는 동반자다"

공유 가치 (Shared Value) 에 관해서, 'Creating Shared Value - by Michael Porter, Mark Kramer 1-2월 2011년 HBR 아티클' (그 유명한 마이클 포터 교수가 쓴 아티클 입니다) 에서 언급된 바로는


   많은 사람들이 잘못 알고 있어서 안타까웠나 봅니다.


기업은 오랫동안 가격을 한 소비당 더 많이 끌어낼 수 있는 방향으로 이용해 왔습니다. 그런데 이러한 방법은 두 가지면에서 파괴적입니다. (망했습니다)

첫째. 소비자를 적대적으로 만듭니다. 그래서 적대적인(적대적으로 돌변한) 이러한 가격정책을 이끄는 업체를 빠르게 응징합니다.

둘째. 소비자와 기업 양쪽에게 다 이득을 주는 새로운 가치를 생성하지 못합니다.


이러한 이유때문에 기업은 '반드시' 소비자와 함께 공유되는 가치 생성하는 것을 이끌어야  합니다. 다음에 나오는 5가지의 전략이 도움을 준다고 합니다.

 
Focus on Relationships, Not on Transactions (거래가 아니라 관계에 집중하라)
   
가격정책으로 고객을 '지갑'이 아니라 '사람'으로 가치화 하는 통신 수단으로 사용해야 합니다. 고객과의 관계를 중요시 하라는 이야깁니다.
   

Be Proactive (앞서서 대처하라)

기업과 소비자 양쪽을 다 이롭게 하는 소비자 행동을 유발하는 방식으로 가격 정책을 세워야 한다는 것입니다. '공유 가치' (Shared Value) 를 창출 할 수 있게 가격 정책을 가져가야 한다고 이야기 합니다.


Put a Premium on Flexibility (프리미엄을 변동성 있게 관리하라)

소비자의 요구의 이동에 맞춰서 변경될 수 있는 가격 정책을 수립하고 공정한 '공유 가치'를 확립할 수 있게 합니다.
   

Promote Transparency (투명성을 강화시켜라)

소비자가 가격 정책을 이성적으로 납득할 수 있게 해야 합니다. 이를 위해서 투명하게 판단할 수 있는 근거를 제시해야 합니다.


Manage the Market's Standards for Fairness (공정성을 위해서 시장의 표준을 관리하라)

확실하게 가격 정책과 소비자의 기대치 (공정하고 가격 결정 프로세스가 명확한것에 대한) 가 만날 수 있게 설계를 해야 합니다.

보통 이런것들 볼 때마다 과장이 좀 심하구나 라는 생각을 했는데, IT 관련 사업을 해 본바, 그리 과장이 아닌 것들도 눈에 띕니다. 유머라고도 볼 수 있고 또는 교훈이라고 생각할 수 있겠습니다.

1. \"오늘까지\"라는 말은 \"내일 아침까지\"라는 말이다.

2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사양은 프로그램을 완성한 후에 추가된다.
   기본 사양은 완성품을 고객이 보고 나서 결정된다.
   상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.

    하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
    다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
    디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.
    주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
    이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.

12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1＋1=2를 이해하지 못하는 사람의 모임이다.

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
     나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
     시스템 엔지니어에게 고객은 돈이다.
     프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
      웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
      시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
      프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의
     목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는
     도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
      운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
      따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번
      일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.
      미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이,
      쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와
     납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 \"캐쥬얼 데이\"를 세간에서는 휴일이나 공휴일이라고 부르는
      것 같다.

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
      영업은 꿈을 말한다.
      시스템 엔지니어는 공상을 이야기한다.
      프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
      1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지
      않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37. 아마추어는 버그발견의 천재이다.

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다.
      시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
      프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을
      깨닫고 빨리 최종요구조건을 확정하는 것이다.

     SE가 고객에게  사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
     개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
     개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
     개발비의 10%만이 프로그램의 개발에 사용된다.

하둡에서 파생된 로그를 수집하고 , 분석할 수 있는 오픈소스 솔루션입니다. 물론 로그를 분석하는 것은 하둡의 맵-리듀스를 이용합니다.

하둡 자체가 로그를 분석하기 위한 목적으로 태어났기 때문에, 로그를 수집하는 솔루션은 어찌보면 당연하게 하둡에서 파생될 수 밖에 없었을 거라 생각합니다.

설치법 자체는 간단합니다. 척와 소스를 내려 받습니다.

http://ftp.daum.net/apache/hadoop/chukwa/chukwa-0.4.0/ 여기에 가면 있습니다.

  
  
하면 컴파일 되면서 설치 완료 입니다.
척와를 제대로 동작시키기 위해서는 하둡이 설치되어 있어야 합니다.

하둡 설치는 예전 문서를 참조하시면 됩니다.



에 하둡이 설치되어 있다고 가정합니다. 버젼은 1.0.2 버젼입니다. 그리고 물론 하둡은 떠 있는 상태여야만 합니다.

chukwa-env.sh 파일을 열어서 간단하게 편집해줍니다.


chukwa-env.sh 내용


 
위와 같은 부분을 찾아서 자신의 환경에 맞춰서 변경해줍니다.

  

collectors 내용
  

이부분은 콜렉터 (로그 저장하는 데몬)가 떠 있는 위치를 지정하는 것입니다.

  
initial_adaptors 내용

  
앞의 세개는 루트 권한을 필요로 하기 때문에 # 처리 해 줍니다.


   구동되는데 이 파일 (hadoop-1.0.2-core.jar) 이 필요합니다.

  
컬렉터를 띄우는데 이 파일 (commons-configuration-1.6.jar) 이 필요하더군요.

이제 컬렉터를 띄워줍니다.


로 띄우고

 

로 agent 를 띄워줍니다.
  
http://localhost:50070 에서 실제로 파일이 저장되는지 확인해 봅니다. 대략 5분마다 한번씩  저장됩니다.

어딘가에서 본 글입니다. 어린 마음에 안데르센의 인어공주를 보고 마음이 안좋았습니다. 안그래도 인생 살기 참 힘든데.. (어릴때 였는데도 불구하고..) 동화마저 비극이라니.

그래서 오빠들이 백조인지 기러기가 되버린 공주가 열심히 찔레꽃으로 옷을 짜서 입혀서 다시 인간으로 만드는 동화는 이름도 기억이 안나지만 손에 땀을 쥐고 응원하면서 읽었던 기억이 납니다.

암튼! 내가 어릴 때 봤던 동화는 와전이 됐을 가능성이 크다는 사실이군요. 결국 후배의 말에 따르면 필멸자에서 불멸자가 됐기 때문에 좋다고 해야 할까요? 아무리 불멸자가 됐어도 가지고 싶은(?) 왕자를 못 가졌기에 가지고 싶은 것을 가지는 디즈니식 결말이 마음에 들더군요.

by Sallie Krawcheck 

금융위기와 거대한 규제의 물결 뒤에도 큰 은행들은 여전히 가버넌스 문제(Governance Problem)를 가지고  있습니다.

이러한 문제는 은행 조직 자체가 너무 복잡해져서 이사회가 효과적으로 살펴볼 수가 없는데서 기인합니다. 이사회를 위해서 이러한 복잡성을 단순하게 만들 수 있는 방법이 필요합니다.

이를 위해서 저자는 4가지의 방법을 제시하고 있습니다.

 1. 최고 경영진에게 일반적으로 스톡 옵션 (Stock Option) 뿐만 아니라 채권도 같이 지급하는 것입니다.

   채권에 신경을 쓰기 때문에 최고 경영진은 조금이라도 리스크에 민감하게 경영을 한다는 것입니다.

 2. 침체기에도 자본을 유지하기 위해서 배당금을 정해진 수량이 아니라 수익의 퍼센트로 지급을 해야 한다는 것입니다.

 3. 은행의 효율을 판단하기 위해서는 순 이자수익(net interest income) 을 무시하고 고객  만족 수치에 조금 더 주의를 기울여야 한다는 것입니다.

   순이자수익은 외부 요인에 더 민감하게 변동되기 때문에 은행 자체의 평가에 영향을 줄 수가 없다는 것입니다.

 4. 가장 문제가 있는 사업 영역에 집중하는 것이 아니라 가장 자본을 많이 사용하고 있는 영역에 집중하라는 것입니다.

영등포 스타리움에서 봤습니다. 커다란 화면에서 보니 시원 시원 하더군요. 원작 코믹스에 조금 더 가까운 스파이더맨 입니다. 거미줄을 기계로 쏘고, 신체적 접촉 보다는 '입' 과 '거미줄'을 이용한 공격으로 싸우는 스타일

호불호가 갈립니다만, 리메이크가 아닌  '리부트' 기 때문에 예전에 봤던 장면을 또 보게 되는 그런 면이 있습니다.

뭐 그래도 여주인공역은 이쁘더군요..

 
얼음이 마치 눈송이를 방불케 할 정도로 가늘게 갈아져서 나옵니다. 같이 가신 전문가(?)분에 따르면 "팥은 그 유명한 밀탑에 밀리지만 얼음은 과연 최고라 칭할만 하다" 라는 평을 주셨습니다. 

이런 유명세에 더불어 살인적인 대기열도 감안하셔야 합니다. 요즘 같으면 거의 30분 이상은 기다리셔야 맛 보실 수 있습니다.  

유시민 지음