우리딸 생일을 축하한다.

사랑하는 딸아... 오늘이 두번째 생일이란다. 생일 진심으로 축하한다. 그리고 아빠는 네가 아빠 껌딱지라서 너무 행복하고 고맙다. ^^

DevOps Isn't Killing Developers – But it is Killing Development and Developer Productivity

안녕하세요. ^^

옥희 회원님께서 번역해 주신 DevOps관련 글입니다.
모든 개발자들이 개발 방법론 협업 방법에 대해서 항상 고민하고 있습니다.
이와 관련해 한번쯤 꼭 읽어 보시기를 권해드립니다.

출처 원문 : http://java.dzone.com/articles/devops-isnt-killing-developers

DevOps Isn't Killing Developers – But it is Killing Development and Developer Productivity

DevOps은 개발자를 힘들게 하지 않는다.-다만,  개발과 개발자의 생산성을 놀랍도록 끌어올린다.

이러한 DevOps Zone 은 PagerDuty와 새로운 C.A.L.M을 지속하고 DevOps 문화를 설립한 것을 수행한 분들에 의해 소개되었다. Devops은 개발자를 힘들게 하지 않는다 (적어도 내가 아는 한 어떤 개발자도 난처한 적 없다.) 그러나 Devops은 개발자를 미치게 만들거나, 소프트웨어를 개발하고 전달하며 우리가 대부분 생각하는 방법을 제시한다. 애자일(Agile)은 총이며, Devops는 방아쇠를 당긴다.

전달보단 흐름으로…..

 바다가 변화하듯, 소프트웨어 역시 개발되고 전달된다. 큰 규모의 폭포와 같은 소프트웨어 개발 프로젝트는 단계적인 전달과 나선형(Spiral) 접근법을 제공한다. 그리고 소규모팀들에게 제한된 시간에 일 할 코드를 전달한다.(사용중인 스크럼[Scrum]이나 다른 반복적인 애자일 방법들을 제시한다). 이제 트렌드가 스크럼에서 칸반(Kanban)으로 이동 하고 있다. 직관적인 하나의 계속적인 흐름(One-Piece Continuous Flow) 그리고 Devops에서 생산하는 코드의 계속적인 배치(Continuous Deployment) 도 주목 받고 있다.

 다양한 규모가 축소되는 방향으로 개발이 자꾸 집중되기 때문에, 일을 빠르게 끝마치기 위해 시간 틀(frame)을 시행한다. 이런 면과 기준 그리고 프로젝트 검토에서 조금씩 확실하게 최선을 다해 검토하고 진행 중인 일의 한계와 과업의 수준을 최적화 하기위해 통제(Control)한다. 이런 소프트웨어 제품의 규모에 따라서, 어떠한 프로젝트 팀은 1년 후에 완성된 결과물(프로젝트)을 전달하거나, 스크럼 팀(Scrum team)이 1달 후나 1주 후에 프로젝트를 완수하고, 어떤 개인적인 개발자는 몇 시간 후나 며칠 후에 개발을 시작한다.  “끝냈다”는 것의 뜻과 “작동중인 소프트웨어” 라는 것은  암호 혹은 부호로 처리가 되어 있고 잘 되거나 시험운행(테스트)하는 것이 가능하며 제작한 소프트웨어를 증명할 준비가 된 생산작업에 의해서 바뀔 수 있다는 것이다. -지금(“끝은 공유를 의미한다.(Done Means Released)”에서).

 지속적인 전달과 지속적인 배치는 지속적인 통합이라 말할 수 있다.. 작업에서 신속한 배치는 수작업으로 확인하는 담당자나 수작업 테스트 중일 때 있어서, 시간을 낭비하지 않는다. 개발자들은 코드를 제품출시 하기 전에  소프트웨어 제품을 시험운행하며, 소프트웨어에서 발생한 문제를 해결하기 위해, 해당 소프트웨어 제품의 모든 버그를 포착하여 문제를 해결해야 할  책임이 있다.(아카[aka]”시험운행 중으로서의 관찰”에서)

  그 이유는 데브옵(Devops)은 개발자들에게 소프트웨어 제품생산을 손쉽게 하며, (소프트웨어 제품)동작시 위험이 프로젝트 위험보다 더 중요하게 되며, (소프트웨어 제품)동작에 대해 측정한 것 역시 프로젝트를 측정한 것보다 중요하다. 소프트웨어 제품을 작업함에 있어서 시스템 가동시간과 순환시간(cycle time)은 획득한 가치나 속도로 대체한다. 다급한 마감시한에 대한 강조는 생산시 다급함에 대한 강조며 관심사 1순위로 대신하게 된다.

  데브옵(Devops)은 프로젝트를 전달하거나 심지어 기능을 전달하지 않는다. 이것은 최소화된 리드타임(생산부터 완성까지 걸리는 시간)과 작업에서 생산까지 최적화된 흐름, 화제를 놓치지 않으며, 쓸데없는 일을 하지 않음과 동시에 지연되고 미뤄진것은 신뢰할 수 있는 시스템으로 개선하는 것, 운영비용을 삭감하고 생산에서 개발까지 계속적인 조언으로 반영한다. 추가로, 표준화하고 자동화하는 절차가 가능한 많이 있다. 보통의 공학기술 보다 과정을 제어하고 생산하는 것이다.

데브옵은 개발자 생산성 역시 기여한다.

데브옵은 또한 개발자의 생산성에 기여한다.

 당신은 LOC에 의해서 개발자 생산성을 판단하거나 기능의 강조점 이나 기능점 이거나 이야기의 강조할 점 이거나 빠르기나 작성된 많은 코드 몇 줄의 다른 측정법 등을 적은 코드로 판단한다. 사회 공공 기반 시설과 제시안 [플랫폼] 등을 이해하는 것에 대한 시간 학습은 확실히 만들고 설정을 올바르게 하는 것이다. 그것은. 또한, 계속적으로 발전시키고(Building) 전달하며, 다양한 경로를 계속적으로 배치하는 것이다. 옵스(ops)를 살피기 위해 돕는 것과 이슈를 해결하는 것은, 긴급한 고객의 다양한 요청에 응답하는 것이고 질문과 성능 문제에 대해 관찰하고 시스템을 감시하는 것은 일을 정확하게 하는 것이며, A/B 실험 운영하는 것을 돕는 것이다. 변화를 장려하고 준비하는 것은 시험운행하고 코딩(소프트웨어를 제작하고)하고 설계하며 필수적인 것에 대해 미리 시도하고 개발하는 것으로 부터 시간을 쓰는 것이다.

다중 작업(Multi-Tasking)과 일의 중단에 대한 영향

데브옵에서의 최우선의 변화와 일의 중단으로부터 독자 여러분은  개발자를 보호할 수 없고, 당신이 칸반과 엄격하게 WIP 제한을 사용할지라도,  심지어는 딱 맞게 경영할지라도-이건 독자여러분이 원치 않을 것이다. 개발자들은 운영을 원활하게 하며 고객에 대응할 필요가 있고, 생산한 것으로부터 조언을 받고 수정할 수도 있으며, 문제를 해결함과 동시에 되도록 이면 빠르게 실수를 발견하고 해결하는 것에 도움을 주는 것 이다. 모두에게 이것이 의미하는 것은, 특히 가장 재능있는 개발자들은, 모든 시간을 할애하지 않더라도 대부분 옵스를 필요하게 될 수 있다.

  개발자들은 몇 시간뒤에 대기 중이었다가 옵스에 접속한다. 하루의 일과를 마치고 난 뒤(퇴근 후), 다시 말해서 (누군가의 호출에 시달리거나) 의무를 다하고 옵스에 접속한다는 것이다. 그리고 시간을 투자하며 문제해결을 위해서 지원 한다는 뜻은 정말 문제가 되게 하지 않기 위해서, 긴 밤과 주말을 바쳐가며 소프트웨어 제품의 이슈를 찾아내고 문제점을 해결하기 위해 도움을 주며, 다음날 피로에 쩔어도 자잘한 운영과 시험운행 및 시스템 대체 작동과 미리 운행(roll-forward)하고 다시 소스를 원복하고(commit 하기 전 roll-back), 프로젝트가 끝난 뒤에도 참여 하며, 프로그램이 뭔가 잘못 돌아가거고 시스템이 대체 작동되거나 미리 운행 (roll-forward)하거나 소스를 원복(원상복귀)시켜도 동작하지 않을 때 문제의 원인을 분석하는 것을 말하는 것이다.

  당신은 중단과 운영상의 문제에 대해서 계획 할 수 없다. 그리고 당신은 그것들과 관련된 것을 또한 계획할 수 없다. 개발자들은 그들이 자주 베푸는 헌신에 대해 잊을 것이다. 그러면 왜 그들이 어째서 헌신하는가? 계획을 수립하거나 평가하는 것에 대해서 왜 신경을 쓰는 것인가? 가장 중요한 것에 집중하는 하기 전에, 제대로 우선순위를 매기는 것은 옵스나 고객이 갑자기 필요로 하는 것, 추가로 당신이 할 수 있는 것을 바로 실행하는 것 -  그렇지 않으면 뭔가 더 중요하거나 이슈화 된 것 그리고 그것을 미연에 방지하는 것이다.

  개발자로서 옵스에 더욱 시간을 쓰고 책임감을 가지고 행동하는 것은 다중 작업 그리고 본연의 임무를 수행하는 것과 중단 및 비효율성을 가져오기도 한다(본연의 임무만 집중했을때 얻을 이익을 일컫는다). 개발자가 옵스에 참여해서 투자해야 할 시간이 증가하고, 손해보는 시간과 본인을 위한 일을 하지 못하는 것 등이 중단 및 비효율성을 의미한다. 이러한 것은 생산성이 지연되는 결과를 가져온다. 그리고 반면에, 문제해결에 참여한 사람들의 생각하는 능력에 있어서 매우 큰 영향을 주고 문제해결에 기여한다. 그렇지만 계속적인 개발 조언만으로도 개발자만의 작업흐름을 방해한다.

개발자가 코드를 확인한 뒤에, 계속적인 통합을 위해 단위별 테스트를 하는 것은 더욱 퍼포먼스를 증대시키고, 몇 초 혹은 몇 분이 빨라진 다는 점에서 개발자들이 개발자의 괴업과 함께 행동할 수 있게 된다. 그러나 작업을 위해 즉각적으로 배치하는 것이 의미하는 것은 통합테스트 단위를 더욱 확장하는 것을 통해 운영하는 것을 뜻하고, 시스템 시험운행과 계속적인 전달을 위한 다른 확인도 하는 것을 뜻한다(더 철저하게 시험운행 하는 것과 더욱 시간을 들여서 확인 하는 것).그리고 그 다음, 배치를 통해서 단계적으로 실행하며, 작업을 살피고 모든 일이 제대로 돌아가는지 확인 하면서, 어떤 것이 잘못 되었는지 확인 하는 것이다.

만약 거의 모든 단계들이 자동화되고 최적화 되어 있을지라도, 이것들 전부 추가 시간과 코딩하는 것을 떠나서 개발자의 주의가 필요하다.

  작업의 흐름을 최적화 하는 것과 운영을 밖의 의미는 개발자의 에너지를 희생하는 것이다. 또는 개발일 그자체를 늦추는 일을 발생시킨다.

기대와 통계(예측) 및 변화해야 할 우대정책

  데브옵에서 방법이란, 개발자들(그리고 옵스) 과업을 변화하는 방법과,  그들이 관리되어 지는 것의 변화하는 방법을 이야기 하는 것이다. 그것은 또한 개발자들을 위해 중요한 기대와 통계, 장려책을 변화하기 위한 것이기도 하다.

 데브옵의 성공은 운영중인 정보기술 통계에 의해 측정되고, 어떠한 범주의 프로젝트 전달 목표에 의한 것이 아니며, 일정과 비용, 발표할 목표나 최우선적인 헌신을 충족하는 것도 아니며, 혹은 심지어는 제품 디자인 목표에 만족하는 것도 아니다.

• 어떻게 하면 빠르게 팀이 중요한 변화나 문제에 반응할 수 있는가: 작업시간을 변화하는 것과 코딩하는 방법이나 속도 대신 작업 하는 것에 있어서 시간의 흐름(Cycle Time)
• 얼마나 자주 생산하기 위해 변화를 주장하는가.(이것은 여전히 통계적인 면이 있다. 대부분 사람들은 가장 흥분하게 되는 이유는-하루에 얼마나 많은 시간 혹은 1시간에 분당 소요하는 것이나 넷픽스(Netflix)나 아마존(Amazon) 배치의 변화
• 얼마나 자주 실수를 만드는가 - 변화/실패의 비율
• 시스템 의존도와 가동시간-MTBF and especially MTTD and MTTR
• 변화의 비용 - 그리고 전반적인 운영과 지원 비용 등

데브옵스(Devops)는 데브 보다 더욱 옵스다.

  더욱 소프트웨어는 빠르게 배급되고 더욱 생산성이 증하하며, 개발은 유지보수하는 방향으로 가고 있다. 프로젝트 관리는 부수적인 관리와 과업(Task) 관리에 의해 대체되었다. 더욱 많이 짧게 수평적으로 계획하는 것이나 계획하는 것은 제시간에 순차적으로 우선시하는 것과 분류하는 것으로 대체되었다.

  정보 기반시설로서의 코드와 함께 옵스는 개발자가 되었고, 설계하고 코딩 정보 기반시설과 정보 기반시설의 변화, 재활용과 재사용에 대한 생각과 복제와 리팩토링(단위로 묶는 것), 기술적인 의심과 시험 혹은 분석 가능성과 TDD에서 TDI(Test Driven Infrastructure)를 만드는 것에 대해 생각한다. 그들은 더욱 더 날렵하고, 매우 자주 작게 변화를 만들으며, 짬을 만들어서 프로그래밍 하는 것과 시간을 쓰고, 서류작업을 들한다.

  그리고 개발자들은 더욱 옵스같이 일을 하기위해 시작한다. 지원과 동작에 대한 책임을 자발적으로 한다. 동작에대한 위험으 첫번째로 생각하고, 제반시설에 대해 관리하며, 제작하는 것의 도구나, 장기간의 설계목표와 함께 동작지원에 대한 즉각적인 단기간 수요의 조화를 이룰 수 있는 방법을 찾는다.

  이것 중 어느 것도 온라인 사업에서 오랫동안 일한 사람에겐 놀라운 일이 아니다. 독자분들이 시스템을 넘겨주고 고객은 그 시스템을 사용하기 시작하며, 최우선적으로 변화하며, 독자 여러분 들도 일하고 계획 역시 변화해야 하는 것이다.

  이런 식으로 일하는 것은 개발자를 위해서 좋지 않거나 필수적으로 최악이다. 그러나 오늘날 일하는 것과 많은 개발자들이 어떻게 생각 하는 지에 것은 근본적으로 다르다. 더욱 미친듯이 바쁘고 지속적으로 빈번한 방해요인이 오히려 근무시 해야할 일을 잘되게 한다. 동시에 더욱 원칙적이고 더욱 의지한다. 더욱 투명해진다. 더욱 책임감과 의무를 갖는다. 개발은 덜하는 것과 출시, 배포, 동작과 지원에 더 집중한다.

  개발자들과 그들의 관리자들 운영중인 정보기술의 더욱 큰 그림의 부분이 되어가며 사용할 필요가 있고, 앱을 설계하는 것과 작성하고 코드를 넘겨주는 것보다 더욱 중요한다. 이것은 아마도 소프트웨어 개발의 미래일 수 있다. 그러나 모든 개발자가 이것을 좋아하지 않거나 혹은 좋아하기도 한다.

Published at DZone with permission of Jim Bird, author and DZone MVB. (source)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

아무 연관도 없는 내가 왜 OKJSP를 운영하는가?

2013년 5월 OKJSP 운영을 맡게 되었다. 

14년전 개인이 만들고 개인이 운영하던 사이트를 내가 받았다. 내 주관으로 재 해석을 하고 대표님과 함께 OKJSP의 미래 모습과 밑그림만 가지고 개편작업을 시작했다.

결과는 참혹했다.

내가 개발한 신무기를 가지고 나와 뜻을 같이하는 동맹군과 함께 개편이라는 전쟁터에 나섰지만 지원군으로 생각했던 본거지는 나를 무시하며 지원을 해주지 않았고 동맹군은 길어지는 전쟁에서 하나 둘씩 떨어져 나갔다.
결국 전쟁에서 참혹하게 패배했고 남은것은 쓰라린 교훈과 1년이라는 시간이다.

다시 전쟁터에 나섰다.
이번에는 나와 뜻을 함께한 딱 한명의 동맹군이고 그 동맹군에게 전권을 위임하고 나는 본거지에서 지원을 하기로 했다. 여전히 나에게는 수많은 위험들이 있다. 언제 돌아설지 모르는 동맹군을 지원해야 하고 후방에서의 여러가지 정치적인 압박을 홀로 감당해야 한다.

하지만 이렇게 나서는 이유는 
첫째,
내가 가고자 하는 길이 뜬구름 같지만 그 뜬 구름같은 길이 맞다는 확신이 있다.

둘째,
이 전쟁을 무기를 팔려고 하는 기회로 생각하거나 전쟁에서 승리하여 독재 국가를 만들려 하거나 민주주의의 탈을 쓰고 자본주의의 이윤 추구에만 집중하지 않고 개발자들의 삶을 대변해 주는 전쟁임을 객관적인 시각으로 인지하고 있다.

셋째,
내가 만든 사이트도 아니고 개발도 모르고 내가 개편작업을 하지 않는 상황에서 아무런 도움없이 가장 빠르고 완성도 있게 만들 수 있는 유일한 방법이다.

넷째,
어차피 고도화 하는 2차, 3차 전투에 나서야 하기 때문에 노하우를 축척하고 향후 전투에서 리소스를 가장 줄일 수 있는 방법은 방향을 잡고 완성도 있는 기술적인 밑바탕 위에 어떤 것이든 담을 수 있는 캔버스를 만드는 중이기 때문이다.

정치적으로 목표를 위해 방향을 잡으라고 압박이 오지만 오히려 그것이 독이될 수 있다.
1년동안 운영하면서 느낀것은 운영진과 회원들의 방향이 같아야 발전이 이뤄진다. 그 방향은 내가 아무리 개발자라 할 지라도 알 수 없다. 그 방향은 커뮤니티를 통해 알아가는 것이다. 그래서 캔버스를 만든것이다. 캔버스 위에 어떤 내용으로 채워질 지는 이것저것 그려보고 커뮤니티들의 반응을 살펴 보면서 알 수 있는 것이다. 이것이 기존회원들과 신규 회원들을 모두 섭렵하며 변화할 수 있는 방법임을 1년동안의 고생을 통해서 알게 된 노하우다.

이 전투는 이제 시작이다.
이전에는 독립국가의 틀 안에서 만족하고 그 안에서만 티격태격 했지만 이제는 밖으로 나가야 할 때이다. 그러기 위해서 이제 무기를 만들기 시작했고 군대를 조직해서 처음 하는 전투이다. 이 전투의 목적은 어떻게 전투를 해 나가야 하는지 알아가는 과정이지 승리를 위한 전투는 아니다 승리를 위한 전투는 노하우가 쌓인 이후에 2차 전투가 될 것이다.
이런 관점이 아닌 승리를 위한 전투를 하게 된다면 결국 궁극적인 목적이 이윤추구의 도구로 전략하게 될 것이고 결국 여느 커뮤니티 사이트 처럼 개발자들의 영향력을 펼칠 수 있는 사이트라는 승리는 영원히 이뤄질 수 없을 것이다.

그 누구도 그 영향력에 대한 모습을 직,간접의 이윤추구라는 안개속에서 볼 수 없기 때문이다.

몇 백만원이면 벌써 완성도 있는 사이트를 만들고 지금쯤 수익을 내면서 운영하고 있겠지만 그렇지 않고 정치적인 압박을 받고 스스로의 자괴감이 들고 개발자들의 어려운 점들을 이해해 나가면서 내가 이렇게 나가는 것이 맞다는 확신이 선다.

내가 초등학교2학년때 처음 애플 컴퓨터를 보고 꿈꾸었던 개발자의 꿈을 20대 초반에 다시 접했을 때 그것은 재미와 꿈의 대상이 아니고 나를 돈벌게 해 주는 수단으로 전락했다.

이제 SW개발 교육이 정기 교육과정으로 채택되는 이 시점에 나와같은 꿈을 꾸는 학생들에게 SW개발이 돈을 벌게 해 주는 수단으로 전락하지 않고 꿈을 키워나가고 꿈이 곧 인생의 성공의 시발점이 되도록 연결해 주고 싶다. 내가 그들에게 그런 영향력을 줄 수 있는 방법이 OKJSP인 것이다.

지렁이같은 나...

"지렁이도 밟으면 꿈틀 거린다."

이 지렁이가 이런 취급을 받아도 될까?

사람들은 지렁이처럼 굽신거리고 기어다니며 말못하는 존재를 경시한다.
마치 본인은 비교우위에 있는 존재처럼 생각해서 당연히 경시해도 된다는 우월감이 있나보다.

난 성향상 나서는 스타일이 아니고 본래 낮아지는 사람이 높아지는 것이라는 신조가 있어 가능하면 낮아지려고 한다.
그리고 공격적인 성향이 내면에 가득해서 가능하면 말도 아낀다.

그러다 보니 말 못하고 담아두었던 스트레스와 짜증이 얼굴로 표현된다.
그래서 내 얼굴이 10년전만 해도 비웃음의 상징이었다.
난 웃는데 주위에서는 비웃는다고 한다. 그만큼 내 얼굴이 굳어져 있기 때문이다.

하지만 이런 모습은 인생풍파와 상처로 인해 생겨난 성향이라서 그리 쉽게 변화되지 않는다.
장점은 말을 안하니 똑똑해 보이기도 한다.
단점은 똑똑해 보여서 좋아했는데 조금이라도 바보같으면 정말 바보가 된다.
바보취급 당해서 조금이라도 꿈틀거리면 지렁이 취급 당한다.

조금이라도 밟히면 난 지렁이같은 느낌이 든다.

지렁이들은 아무도 못보는 보이지 않는 곳에서 지낸다.
그래서 어디에서도 위로받을 수 없다.
같은 지렁이조차 보이지 않기 때문에...

지독하게 외롭다.

About Startup #3 - 호위무사(참모)

Startup의 조직 구성 중에서 특이한 역할의 구성원이 있습니다.

Startup 리더 중에서 대표의 호위무사 역할을 하는 구성원 입니다.
Startup대표는 일반 기업과 달리 하는일이 많습니다.
회사 운영, 영업, 기획, 개발... 전문적이지 않더라도 모든 분야에 역할이 관련되어 있습니다.
그렇기 때문에 대표가 본인의 역할에 집중할 수 있도록 해 주는 사람이 호위무사 입니다.

보통 참모라고 표현을 하지만 여기서 호위무사라고 표현한 이유는 Startup 안에서의 역할 때문 입니다. 참모의 경우 필드에서 필요한 전투력(행정,영업,잡무)보다는 지성을 겸비해야 하지만 호위무사는 평균 이상의 전투력과 지성 무엇보다 충정심이 있어야 합니다.

조선시대도 아니고 여기서 충정심이 왠 말이냐고 하시겠지만 대표와 같은 비전을 바라보면서 어느 유혹에도 홀리지 않고 끝까지 믿음으로 그 길을 나아갈 수 있어야 하기 때문에 충정심이라고 표현했습니다.
만약 대표가 잘못된 길을 가고 있다고 생각된다면 분명히 얘기해서 본인 생각을 표현해야 겠지만 결코 혼자만의 판단으로 결정을 내려서는 안됩니다.

궁극적으로 호위무사의 역할과 능력에 따라 대표의 추진력이 달라질 수 있습니다.
Startup 회사가 일정 궤도에 올라 자립하게 되었을때 호위무사는 자연스럽게 그 회사의 중요한 역할을 수행하고 있어야 합니다. 그렇지 않고 그냥 대표님의 심부름만 하는 존재가 된다면 제대로 역할을 수행하지 않은 것입니다.

마지막으로 호위무사의 중요한 덕목을 하나 얘기하고 싶습니다.
바로 겸손함 입니다. 호위무사는 절대로 외부에 본인의 역량을 대표 대행으로서의 역량으로 표현해서는 안됩니다.

항상 낮은 위치에서 사업 전반의 필요한 전투력을 분배해서 처리하고 궁극적으로 대표자의 역량을 경영에 집중할 수 있도록 해야 합니다.

About Startup #2

이번에는 Startup 조직원 구성의 이해관계에 대해서 말해보려 합니다.

처음에는 리더들이 모든 일들을 다 망라하면서 열심히 일하다가 도우미 멤버들이 필요하게 되고 그 도우미 리더들은 다시 서브리더 혹은 직원 형태로 일을 하게 됩니다.

여기에서 부터 조직 구성이 시작 됩니다.

기존 리더들은 역할과 책임이 명확하기 때문에 특별히 조직내 이해관계 설정이 어렵지 않지만 추가로 들어온 서브리더 혹은 직원들은 기존 리더들과 차별화된 역할이 필요합니다.

1. 기존 리더외에 추가 리더를 영입하는 경우

기존 리더들과 동일한 역할과 책임이라면 기존 리더들과 협의해서 역할 분담을 하면 되겠지만 아무리 업무가 별개의 업무라 할 지라도 그 외의 사회경력이나 해당 업무 외에 도움이 필요한 인원이라면 기존 리더들과의 차별을 명확히 해야 합니다.

그래야 기존 리더들과 새로운 리더의 스트레스를 줄일 수 있습니다.

예를들어,

기존 리더들이 사회경력이 많고 경험이 많아 업무외에 사회생활에 필요한 덕목과 노하우에 대해서 누군가의 도움을 필요로 하지 않는 사람들이고 새로온 리더는 업무는 잘 하지만 사회경력이 적고 직장생활 하면서의 이런저런 고민이 많고 조언이 필요한 멤버라면 기존 멤버들이 결국 조언자와 비전제시를 해 줘야하는 스트레스를 받게 됩니다.

동등한 입장의 대우를 받는 새로운 리더는 그런 상황 자체에 고맙기도 하겠지만 한편으로는 자신의 능력부족에 대한 스트레스를 받게 됩니다.

그렇다면 양쪽 모두 스트레스를 줄일 수 있는 가장 적합한 방법은 각 능력에 맞는 대우와 비전제시를 해주면 됩니다.

여기서 말하는 대우와 비전제시가 가장 어려운 문제 입니다.

왜냐하면 누구나 욕심이 있고 목표가 크기 때문입니다.

그래서 저는 처음 함께하는 과정이 가장 중요하다고 생각합니다.

기존 리더들의 입장과 새로운 리더의 입장을 고려해서 함께 일하기 위해 달콤한 말로 유혹하고 버티는것은 알아서 하라는 식의 영입은 대표로서 무책임하고 밑에서 열심히 일하는 모든 멤버들에게 스트레스를 가중시키는 일입니다.

그렇다고 대표가 처음부터 끝까지 모든것을 일일이 책임질 수 없기 때문에 처음 영입하는 과정이 중요한 것입니다.

처음 영입할때 기존 멤버들과의 이해관계와 비전에 대해 공유하고 이해시킨 후 새로운 멤버의 역할과 책임을 동시에 아주 명확히 정해야 합니다.

그 역할과 책임이 정해지면 기존 멤버들과의 충분한 논의를 거쳐 함께 생활할 공동의 규칙을 정해야 합니다. 예를들어 출퇴근 시간, 휴가제도, 그리고 서비스가 안정화 되기 전까지는 연봉까지도 공유하는게 제일 좋다고 생각합니다.

그래서 목표를 향해 뛰어가는 서로다른 책임자들이 그동안 살아온 환경과 역할이 다를지라도 톱니 바퀴처럼 잘 맞물려 돌아가서 결과물을 계속해서 뽑아내야 합니다.

2. 기존 리더에 서브 리더 혹은 직원을 영입하는 경우

기존 리더들에 비해 상대적으로 책임과 역할이 작아지는 경우 명확한 기준으로 평가하는 것이 좋습니다. 기존 리더들은 역할과 책임이 큰 만큼 그만큼 자신들의 시간과 능력 + 알파를 투자합니다. 그렇기 때문에 출퇴근 시간, 휴가등에 대해서 믿고 자율에 맡길 수 있는 것입니다. 하지만 상대적으로 책임과 역할이 적은 멤버들은 소외감을 느끼지 않도록 명확한 가치에 대한 기준을 제시해 주어야 합니다.

가장 좋은 방법은 연봉으로 가치를 책정하는 것입니다. 연봉만큼 일을 하고 일한 만큼 연봉을 주면 됩니다. 만약 사정이 어려워서 능력만큼의 연봉을 줄 수 없다면 줄 수 있는 만큼의 멤버를 뽑거나 뽑지 않는것이 좋습니다.

나중에 서비스가 잘 되면 더 챙겨주겠다는 식의 달콤한 말로 유혹을 한다면 기존 멤버만큼의 대우를 바라게 되고 이것은 위에 말한 것 처럼 양쪽 모두에게 큰 스트레스를 주게 됩니다.

가장 좋은 것은...

그 사람에게 맞는 자율과 책임을 주는 것입니다.

검증기간이 필요하고 그 기간이 곧 투자가 되겠지만 처음 약속한 부분에 대해서는 책임을 져야 하기 때문에 처음 시작이 중요한 것입니다.

키울맛 들을맛 볼맛 살맛

먹는 즐거움을 빗대어 아이를 키우는 맛 음악을 들을 맛 영화를 볼 맛 살아갈 맛등 여러가지 맛이 있다.
오늘은 정말 맛이 없다.
특히 살 맛이 없다.

내 인생에 전환점이 결혼이었고 그 결혼에 가장 중심이 되는 신앙과 아내가 주축이 되었는데 아내가 나와 내 가족을 떠나고 싶어 한다. 살면서 해야할 말이 있고 하면 안되는 말이 있는데 하면 안되는 말은 상대방 가슴에 못을 박는 말들이다.
못이 박힐때 아프고 뺄때 아프고 상처가 오래남거나 영원히 치유되지 않고 남아있기 때문이다.

그동안 딸과 아내와 처가댁에 전심을 다해서 모셨지만 돌아오는 것은 떠나고 싶다는 말 한마디 뿐...
하지만 하나님께 감사드린다.
그래도 어제까지 행복했던 시간과 가족을 주셨으니까...
이 못이 계속 박힐지 빠질지 모르겠지만 상처는 영원히 남을 것 같다.


그 동안 짧은 36년동안 참 많이도 참았다.

그 동안 참 많이도 상처 받았다.

다시 참을 일이 올까봐 무섭다.

정말 가능하다면 여기서 이제 그만 끝내고 영원히 안식하고 싶다.

About Startup #1

스타트업 컴퍼니

위키백과, 우리 모두의 백과사전.

스타트업 컴퍼니(영어: startup company) 또는 스타트업(영어: startup)은 자체적인 비즈니스모델을 가지고 있는 작은 그룹이나 프로젝트성 회사를 의미한다.^[1] 이러한 회사들은 대부분 신생이며, 새로운 비즈니스 모델을 개발하거나 새로운 시장을 찾아나서는데 주력한다. 스타트업이란 용어는 닷컴 버블 이후 함께 등장하는데, 당시에는 닷컴 회사들을 지칭하는 의미로 쓰였다.

스타트업 회사의 진화[편집]

스타트업 회사는 다양한 분야를 총괄한다. 스타트업 회사를 정의하는 가장 중요한 요소는 비즈니스 모델을 세우고 판로를 개척하는 것이다. 스타트업 회사는 일반적으로 하나의 사업 내용을 가지고 모델을 처음부터 끝까지 개발하는 과정을 포함한다. 스타트업 회사는 다양한 마일스톤(Milestone, 목표)^[2]를 거치며 성장한다. 회사는 개별적으로 성장하기도 하며, 다른 회사와의 합병이나 인수를 통해 성장하는 것이 일반적이다. 신생 회사이며 적은 자본으로 시작할 확률이 매우 높기 때문에 사업이 본 궤도에 오르기 어렵다.

스타트업 회사의 특성상 투자자들은 일반적으로 신생 회사의 불안정성을 감수하고 투자한다. 즉, 적은 자본금과 높은 위험성, 그리고 높은 잠재적 보상이 스타트업 기업의 특징이라고 할 수 있다. 성공적인 스타트업 회사는 업계의 비즈니스 규모를 확장시키는 특징을 가지고 있기 때문에, 회사의 성장 또한 빠르며, 제한적인 자본과 노동 그리고 지대를 가지고 사업을 시작할 수 있다.

스타트업 자본조달 순환도

스타트업 기업들은 소규모이고, 새로운 아이디어를 가지고 시작하기 때문에 투자를 받기 어렵다. 투자는 벤처 캐피털 회사와 엔젤 투자자들이 지원하는 것이 일반적이다. 많은 스타트업들은 초기에 창업자의 자본을 사용한다. 현재는 추가적인 자금 조달 방식이 등장하였는데, 일반 개인들이 투자하는 방식인 크라우드 펀딩이 그것이다.^[3]

스타트업 문화[편집]

스타트업 기업들은 일반적으로 자유로운 노동환경에서 근무하고 있으며, 이것은 스타트업 문화의 근간을 이루고 있다. 1960년, 더글라스 맥그레고리(Douglas McGregor)가 발표한 논문에 의하면, 노동환경에서의 상벌 제도는 업무 효율을 올려주는데 필수가 아니며, 몇몇 사람들은 인센티브가 없을 때, 더욱 더 업무 효율이 올라간다고 언급했다.^[4] 이러한 요소는 경제적 유인이 아니라 업무 효율을 저해하는 것일 수 있으며, 자유로운 근무환경이야말로 근로자들이 더욱 업무에 집중하게 할 수 있게 돕는다는 것이다.

이러한 문화는 오늘날 미국의 거대 기업을 만드는 핵심 요소이기도 했다. 이 중 구글은 스타트업 회사를 인수하며 성장한 스타트업회사이며, 모든 근로자들이 집에서 일하는 듯한 업무 환경을 제공하는 대표적인 기업이다.^[5] 이러한 업무 환경의 저변에는 편안한 환경에서 일하며, 업무 본질에 집중할 수 있게 만들어 줄 수 있을 것이라는 기대가 내포되어있다.