긍정적 사고, 음식의 절제, 규칙적인 운동

카니발리제이션 - cannibalization

한 기업에서 새로 출시하는 상품으로 인해 그 기업에서 기존에 판매하던 다른 상품의 판매량이나 수익, 시장점유율이 감소하는 현상을 가리킨다. 카니발리제이션(cannibalization)이란 동족살인을 뜻하는 카니발리즘(cannibalism)에서 비롯된 용어로, 자기잠식 또는 자기시장잠식이라는 의미이다.

직원이 불법프로그램을 사용했을 때 그 직원이 저작권법 위반으로 형사책임을 부담하는 것은 당연하다.

직원이 속한 회사도 형사택임을 부담할까?

결론부터 말하자면, 직원이 업무에 관련해 불법프로그램을 사용하면 그 회사도 벌금형에 처벌된다.

 - '법인 또는 개인의 업무에 관해' 불법프로그램을 사용했을때에만 회사도 같이 형사책임을 지도록 한다.

직원이 사적으로 불법프로그램을 사용하면 회사는 형사책임을 부담하지 않는다.

[저작권법 제 141조(양벌규정)] 법인의 대표자나 법인 또는 개인의 대리인/사용인 그 밖의 종업원이

그 법인 또는 개인의 업무에 관하여 죄를 범한 때에는 행위자를 벌하는 외에 그 법인 또는 개인에 대하여도

각 해당조의 벌금형을 과한다. 다만, 법인 또는 개인이 그 위반행위를 방지하기 위하여 해당 업무에

관하여 상당한 주의와 감독을 게을리하지 아니한 경우에는 그러하지 아니하다.

제타바이트[ zettabyte ]

https://drupal.org/

http://drupal.kldp.net/about-drupal

드루팔은 PHP로 작성된 오픈 소스 콘텐츠 관리 프레임워크, 콘텐츠 관리 시스템, 블로그 엔진이다. 처음에는 게시판으로 만들었으나 여러 가지 유용한 기능을 추가하여 현재의 모습을 가지게 되었다

드루팔(Drupal)은 개인 또는 커뮤니티가 웹사이트의 다양한 자료들을 손쉽게 관리, 조직, 출판할 수 있도록 다양한 기능을 제공하는 오픈소스 프로그램입니다. 세계의 수많은 사용자들과 조직들이 드루팔을 사용하고 있습니다.

드루팔을 활용할 수 있는 사이트의 종류는 다음과 같습니다

• 커뮤니티 포탈,토론 사이트
• 협동 웹사이트/인트라넷 포탈
• 개인 웹사이트
• 팬 사이트
• 전자 상거래 어플리케이션
• 리소스 디렉토리

드루팔은 다음과 같은 기능을 갖고 있습니다. 모듈을 통해 더 다양한 기능들이 개발되어 사용되고 있습니다.

• 컨텐츠 관리 시스템 (CMS, Contents Management System)
• 블로그
• 공동 집필 환경
• 포럼
• 뉴스레터
• 사진 갤러리
• 파일 업로드 및 다운로드

드루팔은 GPL 라이센스의 오픈소스 소프트웨어입니다. 수천명의 사용자와 개발자로 이루어진 커뮤니티에 의해 개발되고 유지되고 있습니다. Drupal은 자유롭게, 그리고 무료로 다운로드 받아 사용할 수 있습니다. 만일 Drupal이 제공하는 기능에 만족한다면, 당신의 요구사항에 더욱 적합하게 Drupal을 확장시키고 다듬는데 동참할 수도 있습니다.

• 드루팔 홈페이지: http://drupal.org/
• 영어 소개: About Drupal

http://allofsoftware.net/entry/전지전능한-슈퍼-개발자의-역설

전규현님 블로그에서 펌.

필자는 여러 소프트웨어 회사에서 많은 개발자를 만난다. 그러면 보통 회사에 한두명씩 전지전능한 슈퍼 개발자가 있는 것을 보게 된다.

이들은 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반관리, 전략 수립 등 엄청나게 많은 일을 한다. 직책은 대부분 팀장이다.

여러분의 회사에도 이런 개발자가 한두명씩은 있을 것이다. 이들이 여러분의 롤모델인가? “나도 그런 전지전능한 개발자가 되어야지”라는 다짐을 하는가? 아니면 혹시 여러분이 이런 전지전능한 개발자인가?

이렇게 많은 일을 하는 개발자가 One man company에만 있는 것이 아니다. 개발자가 수백명이 넘는 회사에서도 드물지 않게 만날 수 있다.

이런 회사에서는 모든 길이 로마로 통하듯이 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결이 된다. 이 전지전능한 개발자가 모든 기술과 정보를 꽤 뚫고 있어서 문제가 발생하면 즉시 해결해주고 회사는 그럭저럭 굴러간다. 이 개발자가 나가면 회사는 망할 것만 같다.

이런 현상이 좋아보이는 사람도 있을지 몰라도 회사는 인력적으로 큰 리스크를 안고 있는 것이고 뛰어난 개발자를 가장 가치 있는 일에 제대로 사용하지 못하는 손해를 입고 있는 것이다. 전지전능한 개발자는 본인이 선택을 해서 그런 위치가 된 것은 아니다.

회사가 성장과정에서 적당한 때 조직을 전문화하고 변화를 꾀했어야 하는데 그냥 달려만 오다보니 능력이 좋은 개발자가 이거 저거 다 떠 안게 되면서 이런 현상이 벌어지게 되었다. 좀더 잘할 수 있는 분야에 집중했다면 본인 역량 면으로도, 미래 가치면으로도 훨씬 좋은 결과를 가져왔겠지만, 지금은 회사의 맥가이버가 된 상황에 만족할 수 밖에 없다.

다른 회사로 가면 지금의 가치는 대부분 사라지고 만다. 개발자 본인에게도 안타까운 상황이다.

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능하다. 아주 작은 회사에서나 그렇게 하는 것이다. 이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 한다. 모든 일을 잘한다는 것은 애초에 불가능하다. 특히 중요한 일은 주 업무인 개발을 할 시간이 확 줄어 든다는 것이다.

대부분의 이들은 예전에는 뛰어난 개발자였다. 하지만, 개발 이외 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됐다. 그리고 각 일의 Switching cost가 만만치가 않다. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거다.

심지어는 그런 개발자에게 테스트, 고객 응대, 기술 지원까지 하라는 것은 100원주고 20원짜리 일을 시키는 것과 같다. 비효율적일 뿐만 아니라 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못한다.

이런 슈퍼 개발자는 다른 소프트웨어 회사에 가면 가치가 확 떨어진다. 분야가 달라지면 Domain Knowledge 관련 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 된다. 관리자가 되어야 하나 고민이 많다. 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되는 경우도 있다.

회사는 이들에 대한 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 된다. 이들이 등돌리면 회사는 휘청거린다.

이것이 개발자 탓일까? 아니면 회사 탓일까? 회사 탓이다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야한다. 그런데 개발자가 맨땅에서 북치고 장구치고 다 하고, 회사에서는 이를 방치하다보니 이렇게 되는 것이다. 하지만 많은 경영자들은 개발자가 잘 하니 그냥 그렇게 개발자가 다 해야 하는 것으로 아는 경우가 매우 많다.

그럼 어떻게 해야 할까?

개발자가 개발에 전념할 수 있도록 항상 여건을 조성해줘야 한다. 회사가 아주 작아서 어쩔 수 없이 개발자가 여러가지 일을 겸해서 하고 있다고 하더라도 회사가 조금만 커져도 개발자의 일에서 개발업무가 아닌 일을 떼어낼 수 있도록 준비를 해야 한다.

조직이 조금 커지면 테스터를 뽑고, 기술지원인력을 보강하는 것이 좋다.

개발자 10명이 이거 저거 모든 일을 다하는 것보다. 개발자 7명에 테스터2명, 기술지원 인력 1명인 조직이 더 낫다. 개발자가 개발에 더 집중할 수 있고 개발자 10명이서 하는 일보다 더 많은 일을 할 수 있다. 물론 조직과 더불어 프로세스, 기반시스템, 개발문화도 뒷받침이 되어야 하지만 이는 기본으로 생각하자.

이렇게 조직이 분리되고 개발자가 개발에 전념을 할 수 있어야 개발이 좀더 체계적으로 진행된다. 다른 조직의 인력과 협업을 하기 위해 필요한 최소한의 문서도 만들어야 하고 프로세스도 자연스럽게 필요하게 된다. 커뮤니케이션을 위한 기반시스템도 잘 활용하게 된다.

조직이 더 커지면 분리해야 하는 역할이 점점 많아진다. 즉 조직이 세분화 된다. 이는 회사 규모에 따라서 다르니 이 일이 개발자가 해야 하는 일인지 잘 생각해보고 결정하면 된다.

여기서 개발자의 업무를 모두 나열할 수는 없지만 회사에서 개발자가 개발에 집중할 수 있도록 노력하는 일은 대단히 중요하다. 개발자가 잘 해낸다고 그냥 방치하면 안된다. 개발자는 개발을 잘할 때 회사의 보물이 되는 것이다. 다른 일들은 여건이 되는 대로 다른 전문가에게 맡기도록 하자.

http://www.seri.org/ic/icDBRV.html?pubkey=ic20121109001&menu_gbn=1&pgsj=&pgno=1&pgor=

○ 조직 구성원들의 참여를 유도하라

조직에서 비전이 공유되지 못하는 가장 큰 이유 중 하나는 경영진이 일방적으로 비전을 제시하기 때문이다. 따라서 비전을 공유하기 위한 첫걸음은 역설적으로 비전을 수립하는 과정에 구성원의 생각과 열망을 담아내기 위해 노력하는 일이다.

IBM의 최고경영자(CEO)였던 새뮤얼 팔미사노는 직원들의 적극적 참여와 의견을 반영하지 않고 만들어지는 조직의 핵심가치는 경영자 혼자만 외치는 슬로건에 지나지 않는다는 신념을 갖고 있었다. 그래서 그는 2003년 7월 23일 회사 내부 전산망을 통해 IBM의 핵심가치 정립에 직원들의 참여가 얼마나 중요한지 설명하며 동참을 호소했다. 그는 이어 7월 29일부터 8월 1일까지 72시간 동안 새로운 IBM의 핵심가치가 무엇이 돼야 하는가에 대한 생각을 공유하는 ‘밸류 잼(Value Jam)’을 실시했다. 당시 임직원 32만 명 중 70% 이상이 참여했고 1만 개가 넘는 아이디어가 채택돼 IBM의 새로운 핵심가치를 수립하는 데 사용됐다.

○ CEO가 스스로 실천하라

많은 리더는 자신이 신년사에서 비전에 대해 한두 번 이야기하면 직원들이 이를 소중히 가슴에 담고 일할 것이라고 기대한다. 하지만 이는 착각이다. 리더가 이를 반복적으로 강조하고 스스로 실천하는 모습을 보여주지 않으면 부하들이 자발적으로 공유하지도, 실천하지도 않는다. 현장에서 일하는 직원들이 조직의 비전과 가치를 가슴에 품을 수 있도록 리더가 적어도 1000번쯤은 외치고 실천하는 모습을 보여야 한다는 잭 웰치의 이야기를 기억할 필요가 있다.

○ 인사 시스템을 비전 달성에 정렬(align)

직원 선발, 평가, 보상, 교육과 관련한 모든 시스템이 비전 달성을 위해 일관성 있게 재편되지 않으면 비전이 슬로건으로 전락할 수밖에 없다. CEO가 외치는 비전과 가치가 반영되지 않는 직원 선발방식, 평가, 보상시스템만 존재한다면 직원들은 당연히 평가와 보상을 잘 받을 수 있는 행동만 할 것이다.

미국의 온라인 쇼핑몰 업체인 자포스(Zappos.com)는 신입 직원을 선발할 때 특이한 방식을 사용한다. 4주간 교육을 시킨 후 신입 직원 각각에게 자포스가 그들의 개인적 비전 및 가치와 일치하는 조직인지, 계속 자포스에서 근무하면 조직의 비전과 가치를 위해 열정적으로 일할 수 있는지 냉정하게 평가해 달라고 권유한다. 만약 조금이라도 의구심을 갖는 직원에게는 회사를 그만두는 대가로 2000달러(약 220만 원)의 수표를 써 준다.

자포스에 계속 남기로 결정한 직원 입장에서 보면 2000달러를 포기했다는 생각에 조직의 비전과 가치를 한층 더 소중하게 생각한다. 그 결과 이들은 회사의 비전과 가치를 달성하기 위해 열정적으로 일하는 ‘주인’이자 ‘전사’로 거듭났다.

○ 애플의 홈페이지에 비전이 없는 이유

스티브 잡스는 회사의 홈페이지에 비전이니 조직의 핵심가치 따위를 올려놓는 행위에 대해 극도로 거부감을 가지고 있었다. “비전과 핵심가치는 실천의 대상이고 조직 구성원 모두가 공유하는 조직 문화이자 DNA가 돼야지 홈페이지에 올리는 선전 문구가 아니다”라는 게 잡스의 지론이었다. 지금도 애플의 홈페이지에 가보면 CEO나 조직의 비전 그리고 애플의 핵심가치에 대한 이야기를 찾아볼 수 없다. CEO가 신년사나 연설을 할 때만 외치는 개인적인 비전, 강당의 한쪽 벽을 차지하는 액자 속에만 존재하는 ‘죽은 비전’은 기업 발전에 오히려 걸림돌이 될 수 있다는 점을 명심해야 한다.