큰 회사를 제외하고 일반적으로 작은 형태의 IT 회사는 다양한 형태가 존재하지만 무리하게 일반화를 굳이 하자면, CTO (Technology) 주도의 회사와 CPO (Product) 주도의 회사가 있습니다. 


쉽게 말하자면 기술 주도의 회사와 기획 주도의 회사 입니다. 각각의 장점이 확실히 존재합니다. 기술 주도는 제품이 단순하고 개발 이터레이션이 짧게 돌아가고, 기획 주도는 창의적이고 다양한 시도를 하기에 기존하고 다른 제품이 나올 확률이 높습니다. 어떤 개발 스타일을 제가 좋아하는 것은 별도로 치고도, 잘 생각해 보면 회사의 개발 방향이 이런 형태중에 한가지에 가까울 수가 있습니다. 


다만 개발자 출신으로서 생각해 보기에는 (초보) 개발자는 기술 주도의 회사가 더 편하겠지요? 아무래도 CTO 가 주도하는 사이클을 몸에 익히면 추후에 팀장이나 또는 본인이 CTO 로 나아갈 때 도움이 됩니다. 


그렇다고 기획 주도의 회사가 (초보) 개발자가 일하기 힘들기만 한 것이냐? 그렇지는 않습니다. 고난 속에서도 배우는 것이 있듯이 나중에 기획이 바꼈을 때 어떻게 기획자들과 싸워서 일정을 쟁취해야 하는지에 대해서 확실히 배울 수가 있습니다. 다만 변경되는 일정에 대한 짜증은 별도이지만요. 즉 심각하게 힘들게 하는 SI 의 대비를 미리 할 수가 있다는 것입니다. 농담 처럼 이야기 하지요 SI 에 계속 있으면 안되지만 군대 가듯이 SI 를 해 볼 필요는 있다고 말이죠. 그리고 이 바닥에서 말하듯이 개발자에게 있어 군대란 .. 


즉 처음의 논조와는 달라졌지만 (초보) 개발자가 기획 주도 회사에서 일할 때 


1. 자주 기획이 변한는 것에 대한 불만

 - 기획이 자주 변경 되는 건 당연한 일이 라고 여겨야 합니다. 

 - 잘 교육된 기획자가 아니면 아닐 수록 생각을 확정 못 시키고 자주 기획이 변경됩니다.


2. 기획이 바꼈는데도 일정을 고정할려고 하면

 - 절대 납득하고 날 새시면 안됩니다. 

 - 그 기획자에게도 기획이 바뀌면 일정이 변경된다는 것을 교육 시켜야 합니다. 그래야 그 분도 나중에 다른 개발자랑 일할 때 신경을 써 줍니다. 


3. 지속적으로 일정 관리에 대한 분위기 조성

 - 어떠한 일이 있더라도 기획이 바뀌면 일정은 무조건 변경되야 한다는 것을 모든 개발 참여자들이 인지하는 분위기를 조성해야 합니다. 

 - 그래서 개발 시작 전에 기획이 확정 되어지고 그 기획은 마일스톤 (or 스프린트) 기간 내에는 변경이 안되게 확답을 받아야 합니다. 

 - 개발 일정이 변경 되는 것에 대한 원인이 기획 변경에 있다는 것이 인지되면 기획자들도 조금 더 노력해서 기획을 확정 지으려고 합니다.


최근 회사 개발자가 확정 안되어진 기획서를 가지고 개발하는 데 짜증을 내길래 달래주다가 정리한 글입니다. 


저작자표시

제가 좋아하는 무협용어로 바꾸어봐도 비슷한 이야기라고 생각합니다. 고수와 중수의 차이란? 요즘 프로젝트들이 실패하는 광경을 여러번 봤기 때문에 다시금 이러한 생각을 하게 되는군요. 고수(고급)와 중수(중급)는 기술상으로는 별 차이가 없다고 봅니다. 가장 큰 차이는 무엇이 있을까? 라는 고민을 해보니 기술적으로 보면 그리 큰 차이가 없다고 봅니다. 구글이 모든 프로그래머들의 성전이 된 지금에 있어서는 고수도 검색하고 중수도 검색하고 하수도 검색합니다. 같은 기술을 찾아서 적용하는 것은 이해 속도의 차이일뿐 기술적으로 난이도가 크지는 않습니다. (예전에는 당연히 이것도 고수가 되는 조건중의 하나였을 것입니다) 


1. 적응성 

  고수들은 새로운 개발 환경, 새로운 언어에 적응이 빠릅니다. 새로 리눅스 환경에서 개발을 하든 , 또는 파이선에 플라스크로 개발을 하던, Node.js 로 개발하던 고수들은 당황하지 않고 '조금만 배우면 되지' 라는 마음으로 기술을 배우지만 중수들은 그러하지 않습니다. 일례로 자바를 잘하는 집단을 보유한 회사에서 파이썬으로 된 솔루션을 해석을 못해서 타 회사에게 맡기는 경우를 본 적이 있습니다. '대체 왜?' 라고 생각하시는 분들도 많겠지만 '귀찮음' 인지 진짜 몰라서 인지 그러한 경우에 포기를 하더군요. 이런 점에서 고수와 중수의 차이를 보게 됩니다. 단지 마음가짐의 차이가 아니겠는가? 라고 하시는 분도 있겠지만 마음가짐과 실제로 조금이라도 경험을 해본 것에 따르는 차이도 무시 못하겠더군요. 즉 한가지 기술에만 안주해서 '그걸로 다 되는데 왜 새로운 것을 배워야 하나?' 라는 마음가짐과 실제로 경험을 안 겪어본 사람과 새로운 것을 이거저거 실험해보는 사람과의 차이는 정말 무시하기 힘듭니다. 


2. 리더쉽 

 사실 이것이 가장 큰 이유라고 저는 보고 있습니다. 조금이라도 규모가 큰 작업들은 무조건 PL(Program Leader)급을 고용해서 진행하라는 조언을 아끼지 않는 이유가 바로 이러한 이유때문입니다. 위에서도 기술적인 난이도가 거의 없다고 말씀드렸습니다. 사실상 초급(하수)들을 데려다가 시간을 주고 괴롭히면(?) 어느정도 아웃풋이 나옵니다. 그건 정말 조그마한 프로젝트의 경우에만 그렇습니다. 정말 커다란 프로젝트나 말도 안되는 고객의 요구를 들어줘야 하는 프로젝트의 경우에 팀을 이끌어 가는 고수가 없다면 정말 헤아릴 수 없는 손해를 봅니다. 가장 최근에 이러한 경우를 겪었기에 정말 자신있게 말씀드릴 수가 있습니다. 안 그러한 분야가 거의 없겠지만 커다란 프로젝트는 정말 선택의 연속입니다. 여기 선택의 과정에서 적절하게 선택을 행해주지 않는다면 정말 배가 산으로 가는 경우를 자주 목격합니다. 따라서 본인 혼자의 기술 숙련도 뿐만 아니라 속해져 있는 모든 팀원들의 프로젝트 적응성을 이끌어 나갈수 있는 인재를 진정한 고수라고 볼 수 있습니다. 


그렇다면 경영자의 관점에서는 언제 어떠한 경우에 고수,중수,하수 를 적절하게 쓸 수가 있을까요? 아까 말했듯이 프로젝트의 규모에 따라서 고용 여부를 결정할 수가 있을 것입니다. '고수는 비싸지 않느냐?' 라고 외치는 경영자 분들이 계십니다. 하지만 그 몇 백만원을 아끼려다 2-3개월 딜레이 되고 몇천을 날리는 경우를 수도 없이 봤기 때문에 정말 단언할 수가 있습니다. 중요하거나 시간내에 끝내야 되는 일이라면 꼭 '고수'를 고용해서 고객(자사의 개발이라면 본인)의 신뢰를 얻어 내시기 바랍니다. 



저작자표시
저도 개발자 출신으로 사업을 오래했지만, 제안에 대해서 대충 그런 느낌을 가지고 있지만 남에게 설명할 수준이나 어떤 이론적으로 적립 되지 않았던 것을 지인(제안, 마케팅쪽 구루) 을 통해서 명쾌하게 전달을 받았습니다. 

즉 개발자 출신이 사업 제안을 할 때 유의할 점은

사업 제안이 비용절감 측면으로 접근을 하면, 기업의 오너 외에는 거의 관심을 가지지 않는다. 따라서 실무자들을 대상으로 하는 사업 제안은 항상 매출 향상 쪽에 촛점을 맞춰서 진행하라



라는 조언이 되겠습니다.  

아 명확하게 꼬집어 주니 뭔가 머릿속에서 꽝하는 울림이 느껴지더군요. 제 자신도 개발자 출신이기 때문에 뭔가 아이템을 개발하거나 재밌는 것을 만들었던 것을 뒤 돌아보면 항상 기존에 있는 것들에 대한 효율성 증대 측면에서 접근하는 경우가 많았습니다. (IT 라는 것의 태생 자체가 기존의 인프라에 추가해서 비용을 절감하는 측명이 강했던 것도 사실입니다!!)

그리고 별거 아닌거 같은데 큰 투자를 받거나 온갖 특혜를 받으면서 진행되는 프로젝트를 보면 이러한 매출이 증대될 것이라고 제안서에 쓰여져 있었던 경우가 많았습니다. 그렇습니다!! 저는 알지도 모르고 그런 제안들이 '기술적 기반이 뒷받침 안됐구나 쯧쯧' 이라는 거지가 재벌을 걱정해 주는 꼴이였습니다. 

 기술적으로 훌륭하게 만들어진 아이디어나 솔루션이 있다고 하더라도, 사업 제안자 분들께서는 그 만들어진 솔루션으로 어떻게 해서 매출을 일으킬 것인가에 대한 확실한 방법성을 제공해야 할 것입니다. (이는 내 자신에게도 똑 같은 다짐입니다) 
저작자표시
   by Andrew McAfee and Erik Brynjolfsson

클라우드도 HBR 에 실릴 때까지 거의 5년이란 세월이 흘렀습니다. 그러나 빅 데이타(Big Data)는 3년이 안 걸리는 시간안에 실리는 기염을 토했습니다. 무엇이 다를까요? 왜 요즘 어디서나 빅 데이타 라는 이야기가 이슈일까요? 

빅 데이타가 새로운 개념이냐 아니냐를 떠나서 기술 (IT) 쪽과 경영쪽 전부가 관심을 가지는 분야임에는 분명합니다. 저도 이 분야에 대한 기술은 어느정도 습득하고 있고 여러 군데에서 일을 해 봤지만 개념도 잘 모르면서 단지 빅 데이터를 해 줬으면 하는 요청들이 많습니다. (데이터가 1400 건 정도 쌓여 있는데 빅 데이터에 맞게 구성해 줬으면 합니다.. 뭐 이런식의?..) 그래서 아직 우리나라 일반적인 기업에 바로 적용하기에는 어느 정도 거품이 있어 보입니다. 그래도 적어도 어떤 개념인지는 알아야 하지 않겠습니까? 

이 아티클은 바로 그 빅 데이타를 경영쪽에서 바라보는 관점에서 정리한 글입니다. 경영진들에게 빅 데이타가 어떤 개념인지 소개하는 것에 가깝지만 이 또한 일반 사람들에게도 소개하기에 좋은 글인 것 같아서 조금 정리해 보았습니다. 


"You can't manage what you don't measure" (당신은 측정 할 수 없는 것을 경영할 수 없다)


이 빅 데이타의 개념을 적절히 활용하면 태생이 디지털적으로 태어난 기업 (예를 들자면 아마존..)뿐만 아니라 전통적인 기업들도 적절하게 변모시킬 수가 있습니다. 

대체 그렇다면 어떤점이 새로운 것인가? (항상 듣는 질문입니다)

세가지 핵심적인 차이가 있습니다. 보통 3V 라고 불리는 차이점입니다. 누가 대체 빅 데이타가 기존의 BI (Business Intelligence) 와 데이타 마이닝 (Data Mining) 과 차이가 뭐냐고 물어본다면 바로 이 대답을 해 주면 될 것입니다. (쿨하게 3V 라고 불리는 차이가 있습니다.. 어쩌구 저쩌구 하시면 됩니다 ㅎㅎ)

1. Volume (용량)

기존과는 비교도 안 될 만큼의 많은 양입니다. 기존 디비 (Database) 정도로는 택도 없는 용량이라고 생각하시면 됩니다. 예를 들어 월마트는 시간당 2.5 페타바이트의 자료가 생겨난다고 합니다. (1페타는 대략 1000 테라라고 보시면 됩니다) 

2. Velocity (속도)

많은 응용분야에서 용량보다는 속도가 더욱 중요합니다. 실시간에 근접할 정도로 빠른 속도를 가져야만 합니다. 

3. Variety (다양성)

빅 데이타에서 활용되는 자료들은 대표적으로 로그 데이터를 비롯해서 소셜 네트워크 서비스에 포함된 이미지 형태, 센서로부터의 분석, GPS 시그널등으로 무척 다채로우며 전통적인 자료들에 비해서 새로운 형태의 자료의 모습을 취합니다. 


아티클에서 나오는 시어즈 홀딩스(Sears Holdings)의 적용 사례를 보겠습니다. 

시어즈 홀딩스는 자회사들과 계열 브랜드로부터 수집된 거대한 데이터들이 큰 가치를 지니고 있다고 판단했습니다. 이러한 데이터로부터 개인 고객에 대한 맞춤화된 프로모션을 제공하는것이 사실은 어려운 일이라고 판단했습니다. 기존 방식으로는 개인 고객에 맞춰진 프로모션을 제공하는 데 걸리는 시간이 8주정도 걸리는데 8주 지난 후라면 이 정보가 더 이상 최적은 아니라고 볼 수 있기 때문입니다. 이리 오래 걸리는 이유는 일단 데이터의 양이 많기도 많지만 각각의 브랜드가 가지고 있는 데이타웨어하우스(분석용 데이터 관리 시스템)와 데이타베이스들이 각각 형태도 다르기 때문에 통합해서 돌려야 하기 때문에 대규모 분석을 필요로 하기 때문입니다. 

대규모 분석 시스템을 구축할려면 돈이 어마어마하게 들어가기 때문에 시어즈 홀딩즈는 가격도 싸고 쉽게 적용할 수 있는 방법에 눈을 돌렸습니다. 바로 빅-데이타 사례와 기술에 의지하기로 해서 Hadoop 클러스터를 구축했습니다. (제 블로그에서 검색하면 하둡 구축하는 방법 많이 나옵니다 ㅎㅎ) 시어즈 홀딩즈는 자사의 모든 브랜드로부터 모이는 자료가 하둡 클러스터에 직접 저장되게 시스템을 바꾸고 모여 있는 자료에서 직접 데이터 분석을 시작했습니다. (바로 맵-리듀스 를 이용했을 것입니다) 

결과적으로 대 성공이였습니다. 8주 걸리는 작업이 1주밖에 안걸리고 이 시간은 점점 더 빨라지고 있다고 합니다. 게다가 기존의 데이타마이닝보다 하둡 클러스터가 일을 처리하는 방식이 더 적은 시간으로 더 많은 용량을 처리할 수 있다고 합니다. 더구나 CTO 였던 필 쉘리(Phill Shelley) 가 놀랐던 것은 이 프로젝트를 시작한 2010년 (하둡 정말 초창기 입니다)에는 사람도 구하기 어려워서 이런 일을 전문적으로 처리해 주는 업체에 외주를 줬지만 이후 기존 시스템이 이 새로운 시스템으로 너무 쉽게 변환이 되서 자사 기술자들도 충분히 따라올 수가 있어서 정말 편했다는 것입니다. (돈을 얼마나 줬길래.. -ㅅ- )

이러한 빅 데이타 기술이 필요한 시점에서 기업이 넘어야할 5가지 경영과제가 존재하지만 그중에서 두가지만 살펴보겠습니다. (나머지는 너무 뻔한 이야기라 .. )

1. Technology (기술)

기술로는 Hadoop 을 추천합니다. 하둡은 오픈 소스 프레임워크 입니다. (본문에는 하드웨어를 결합시켰다는 데 사실 무근입니다..) 다만 기존의 비싼 서버들을 이용하는게 아니라 일용품 성격인 값 싼 서버를 여러대 묶어서 사용합니다. 기존에 데이타를 구축하는 기술과 분석하는 기술이 따로 존재했다면 이 하둡은 데이터를 구축하면서 분석하는 모든 행동을 전부 기술자들이 해야 합니다. 이것이 기술자들이 넘어야 할 장벽입니다. 기존 개발자들은 새로운 기술에 거부감을 가지는 경우가 많기 때문에 이 것을 잘 컨트롤 해야 합니다. 이 기술은 너무나 당연하겠지만 빅-데이타 전략의 필수 구성 요소입니다. 

2. Decision Making (의사 결정)

훌륭한 기술자는 자신이 만든 기술이 아니더라도 능숙하게 사용할 수 있어야 합니다. 바로 이점이 이 바닥 (IT)에서의 고수와 중수를 판가름 짓는 가장 큰 요소라고 봅니다. 빅 데이터 시대에서는 정보는 생성되고 전송됩니다. 그리고 전문 지식은 정해진 자리가 있지 않습니다 (항상 정보는 돌아다니니..)리더는 필히 NIH 신드롬을 최소화 하고 여러 기능들을 잘 조합해서 하나로 묶어낼 수 있을만큼 효율적이고 유연한 조직을 만들어야 합니다. 

 

* NIH 신드롬 (Not Invented Here!) 여기서 개발한 것이 아닌것을 배척하는 배타적 조직문화를 의미

 

저작자표시


무엇이 고객들의 선택을 더 좋게 하는가? 또 이를 통해 기업이 얻을 수 있는 이점과 고객이 얻을 수 있는
이점은?

기본적으로 기업은 부가가치를 창출해야 합니다. 또 소비자들은 그러한 부가가치들을 인정하고 그것에 대한
댓가를 지불해야 하는 것이지요. 그렇다면 기업은 소비자의 선택사항을 매우 많게 만들고 그중에서 소비자가
고르게 하는 것이 현명하다고 할 것입니다. 그러나 소비자들은 또 그 많은 선택사항에서는 고민할 수밖에
없습니다. 사람인 관계로 쉬운 선택지를 택하고 싶을 것입니다. 한가지만 고르면 나머지가 알아서 세팅이 되면
좋겠다던지 말이죠.

이래서 선택에 관한 것이 기업활동에서 이슈가 될 수 있습니다. 그래서 다음과 같은 아티클이 나온 연유가 될
테죠. 각 선택에 관한 종류들을 알아보기로 하겠습니다.

- Mass Defaults -
 "대중을 상대로한 기본옵션"
말 그대로 모든 대중에게 적용이 되는 옵션입니다. 선택의 폭이 자유롭지가 않습니다. 말 그대로 무조건
디폴트로 제공이 된다고 보는 것이 맞겠지요.
- Benign Defaults -
 "양호한(우세한) 기본옵션"
기업측에서 고려해 볼때 소비자에게 가장 어울리는 옵션들을 모아논 것이라고 할 수 있습니다. 리스크가 가장
적은 것들을 모아논 것이라고 할 수 있습니다. 당연히 해야만 하는 그런 옵션들의 조합입니다.
- Random Defaults -
 "무작위 기본옵션"
어떠한 옵션이 좋은지 선별하기 어려울 때 쓰는 방법입니다. 혹은 어떠한 옵션이라도 별 차이가 없다고 느껴질
때 쓰는 방법이겠지요.
- Hidden options -
 "숨겨진 옵션"
보통 컴퓨터 소프트웨어에 많이 존재하는 숨겨진 옵션입니다. 겉으로 드러나지는 않지만 진정으로 존재하는
옵션입니다. 보통 까페에서 체리에이드를 판매하는 까페는 '체리 콕'을 주문하면 메뉴판에는 존재하지 않지만
만들어 주는 것과 마찬가지로 보면 됩니다.
- Personalized Defaults -
 "개인화된 기본옵션"
개인의 차이와 필요를 반영한 것입니다. 보통 3가지가 있습니다.

 - 현명한 기본옵션(Smart Defaults): 고객의 정보를 활용해서 옵션에 적용시키는 방안입니다. 구글에서
   국가별로 모국어로 된 페이지가 뜨는 것이 대표적이라고 할 수 있습니다. 원하면 바로 다르게 바꿀 수
   있다는 것도 특징입니다.

 - 지속되는 기본옵션(Persistent Defaults) : 과거 고객이 선택했던 정보를 기억해서 그 옵션이 유지되는
   경우입니다. 흡연석을 요구한 고객은 다음에도 흡연석을 요구할 확률이 높다는 것이지요. (끊는 경우라면 뭐
   상관이 없지만 말이죠)

 - 적응적인 기본옵션(Adaptive Defaults) : 큰 카테고리를 결정하면 나머지 옵션들이 자동으로 결정되는
   형식입니다. 소프트웨어 산업계에 많이 존재하는 방안입니다. 가장 쉽게 윈도즈 OS 를 보면
   되겠군요. Business 와 Professional 을 선택하면 그 밑에 생기는 옵션들이 자동으로 선택이
   되어집니다. 이런 방안을 말합니다.

이렇게 많은 옵션의 종류가 있지만, 이를 기업이 악용하는 관계도 심심치 않게 보아왔습니다. 그래서 이런
다양한 옵션에 거부감을 가질 수는 있지만, 또한 윤리적인 차원에서 악용하지 않는 다면, 고객 차원에서는 정말
편안한 선택권을 주어지는 것이라고 볼 수있습니다. - 구글의 예는 정말 편하기 까지 하지요 - 그래서
기업차원에서는 고객의 편안한 선택을 위해서 이러한 방안을 적극적으로 활용할 필요가 있는 것이겠지요.


+ Recent posts

티스토리툴바