블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

스타트업에서 일하기 위한 준비


멀쩡하게 국내 최고 기업중의 하나인 기업을 다니다가, 스타트업의 일원으로 몬가를 만들어 내겠다는 생각에, 안정적이고 좋은 직장을 박차고 나왔다. 마흔이 넘은 나이에, 스타트업이라니, 누가 보면 제정신이 아니라고 할 수 도 있겠지만이번이 인생에 있어서 마지막 도전이 아닐까 하는 생각이 든다. 해도 후회, 안해도 후회 할거면 해보고 후회하자는 결정을했다.

지금까지 일해온 방식이, 최종 의사 결정자이기 보다는 의사 결정을 수행하는 입장에 있었기 때문에, 새로운 일은 나름대로 도전이다

더군다나, 대기업이나 벤더의 경험에서 스타트업이라는 무한의 정글로 도전을 하면서, 다른 비지니스 모델과 환경, 그리고 모바일 및 스타트업의 전성 시대에서, 생각하는 방식이 다른 젊은 사람들과의 일은 기존에 일하던 방식에서 무엇인가의 변화가 필요하다는 생각을 가지도록 하였다.

그래서, 스타트업과, 사람들이 일하는 문화에 대해서 다른 시각을 가지기 위해서, 휴가 기간동안, 피플웨어와 린스타트업이라는 두권의 책을 가지고 왔건만, 도무지 제대로 이해가 되지 않아서, 글로써 정리함으로써, 내것으로 만들고자 한다.

다른 세대의 개발자, 다른 환경 그리고 다른 역할


다른 세대의 개발자


이직을 결정하고 나서, 시간이 나는데로, 새로운 회사의 사람들과 대화를 하고 이해하려고 노력을 했다. 흔히 말하는 현대의 스타트업 개발자들의 특성을 파악하고 준비하기 위함이었는데, 몇가지 발견한 흥미로운 사실이 있는데, 그 중에서 첫번째는 나름 혁신 적이고 변화에 빠른 사람이라고 생각한 나 조차도, 이미 새로운 세대에 비교해서는 새로운 세대가 아니라는 것이다.

새로운 세대, 스타트업 개발자의 특징을 몇가지 보면, 기술이나 역할에 대한 두려움(?)이 없고, 멀티롤을 한다. 내가 경험한 몇 안되는 스타트업은 모바일 서비스를 기반으로 하는 회사들로, 대부분 모바일 개발자가 주요 엔지니어링을 하고 있으며, 필연적으로 필요한 서버 백엔드와 인프라 엔지니어링도 이 모바일 개발자가 배워서 하고 있었는데, 기존의 서버 개발자들이 같은 업무를 수행했다면, 아마도 조금 더 좋은 설계와 많은 검증으로 좋은 시스템을 만들어 냈을 것이다. 그러나, 그 만큼 리소스(시간)도 많이 소요되었을 것이고, 해보지 않은 분야에 대한 거부감도 생각보다 컸을 것이다.

그러나, 이 모바일 백 그라운드의 스타트업 엔지니어들의 특징중의 하나는 새로운 기술에 대한 거부감이 상대적으로 적고, 인터넷의 발전(스택 오버플로등)등으로 그냥 자료를 찾아서 한다. 말 그대로 그냥한다. 애자일 방법론에 대해서 제대로 교육을 받거나 공부를 해본적은 없지만, 인터넷에서 찾아본 문화와 단편적인 지식으로나마 애자일 스럽게 나름 효율적인 프로세스를 구축해가고 있다.

고가용 고성능 시스템을 만들지는 못하지만, 서비스가 커감에 따라 장애등을 겪으면서 시스템을 고도화해나가고, 직접 고객 서비스에서 피드백을 받으면서 만든 코드하나하나가 비지니스에 영향을 주는 것을 느끼면서 배워 나가고 있다.

오히려 대기업이나 벤더에서 잘 닦여진 프로세스와 가이드 보다, 직접 몸으로 부딪혀 나가면서 서비스를 해나가는 정글에서 배워나간 지식들이 훨씬 더 가치가 있게 보인다고나 할까?


다른 환경


팀 확장을 위해서, 사람들을 뽑고, 기존 사람들을 살펴보면서 인지한것 중의 하나는 환경이 차이가 꽤나 크다는 것이다. 스타트업인 만큼 자금 집행이 쉽지 않기 때문에 많은 돈을 주고 엔지니어를 데리고 오거나, 쉽게 교육등에 투자하기가 어려우며, 또한 좋은 복리후생이나 안정적인 직업 보장성으로 사람을 데리오기도 힘들다. 이른바 스타트업에서 열정페이론이 언급되는 이유도 이런 이유가 아닌가 싶다.

그렇다면 어떻게 사람을 데리고 와야 할까? 결국 스타트업은 사람이 우선인데, 어떻게 사람을 유지하고 좋은 사람을 데리고 올 수 있을까? 금전적인 부분은 배제하고 생각할 수 있는 것은, 일하고 싶게 만들어 주는게 아닐까 싶다. 대부분 좋은 보상을 받는 회사에 근무하고 있는 사람이 이직을 원하는 이유는 나는 더 할 수 있는데, 회사가 주는 권한이 작다.” “내가 인정을 덜 받고 있다.” “조금 더 옳고 효율적인 방향으로 일하고 싶다.”라는 느낌이 아닌가 싶다. 그렇다면 결국 대기업에 비해서 스타트업이 줄 수 있는 메리트는 권한이다. 스스로 납득할 수 있는 일을 하게 하고, 그것을 하기 위해서 스스로가 팀을 납득 시키도록 하는 환경을 조성해야 한다. 이를 위해서는 팀 중심으로 일을 해야하고, 납득을 제대로 하기 위해서 같은 눈 높이를 가져야 한다. 극단적인 예를 들어 엔지니어가 자동화를 하고 싶은 의지가 있을 때, 이것이 비지니스에 얼마나 도움이 되는지 다른 사람을 납득시키고 수행할 수 있어야 한다. 이렇게 의견을 제시하고 상대방을 납득 시킬 수 있는 환경을 조성하는 것이 수평적인 소통 문화, 그리고 결정된 일을 권한을 가지고할 수 있게 하는 권한을 이양하는 문화 조성이 필요하지 않을까 한다.


다른 역할


지금까지 내가 해왔던 역할이라면, 개발 팀원으로써 지시를 받아서 일을 하거나, 매니져로써 지시를 내리는 입장이었다. 이번 역할을 그 이상의 역할에서 팀이 제대로일 할 수 있도록 하는 역할이다. 팀의 규모가 커지고 비지니스의 속도가 빨라지며 기술의 변화가 심해짐에 따라서 일일이 지시를 통해서 해결할 수 는 없다. 권한을 다른 사람에게 대행 시키고 의사 결정 권한을 분산 시켜야 하는 역할이다. 지금까지는 직접 코딩하고, 직접 설계하고, 직접 팀을 관리했지만 이번부터는 팀원들이 이것을 할 수 있도록 만들어 줘야 하는 역할이다. 즉 직접 뛰는 역할 보다는 뛸 수 이쓴 환경을 조성해 주는 역할이다.

이번에 피플웨어를 읽던 중 재미있는 구절중의 하나가

대다수의 관리자는 자신에게 기술적인 걱정보다 사람 걱정이 더 많다는 사실을 기꺼이 인정한다. 그러면서도 그렇게 관리하는 관리자는 극히 드물다. 그들은 기술이 주요 걱정 거리인 양 간리한다. 팀원들이 풀어야 할 가장 꼬이고 재미난 퍼즐을 스스로 고민하며 시간을 보낸다. 마치 업무를 관리하기 보다는 직접 업무를 수행하려는 듯 행동한다.” – 피플웨어 3

예전에 약 60명 정도의 팀을 이끌고 전체적인 프로그램을 관리할때는 돌이켜보면, 직접 기술을 고민하고 해결하려고 한적이 있었다. 스스로를 VP of engineering / Chief Architect로 정의했으니까주요 기술 의사 결정에 관여하고 가이드를 주는 일을 했는데.. 근래에는 이게 과연 옳은 행동이었는지에 대해서 고민중이다. (아직 결론은 내지 못했지만…) 그렇다고 경험을 통해서 이미 겪고 알고 있으면서 의견을 개진 하지 않고 팀이 풀도록 놔두는 것 역시, 내 경험에 대한 낭비가 되고경험을 잘 살려서 팀을 옳바른 방향으로 갈 수 있도록 돕는 것 역시 새로운 역할에서 주어진 숙제가 아닌가 싶다.


결론


구체적인 실천 방향에 대해서 고민해보고 또 고민을 하지만 결론은 나지 않는다. 아직 우리가 어떻게 일하고 있는지 나는 모르기 때문이다. 아마도 2~3개월 같이 서비스를 개발해나가고 사람과 부딪혀 가면서 이해해야 아마도 구체적인 실천 방향을 정의하고 실행해 나갈 수 있지 않을까 싶다. 그럼에도 불구하고 책을 읽고 생각을 하고 정리를 하는 것은 최소한의 방향성과 다른 환경에서 일하기 위한 기본 원칙을 나름데로 정의하기 위함이다.

예전, 대기업에 입사할때 숙식을 하는 교육을 받은 적이 있다. 이때, 조별로 많은 과제를 수행했는데, 어떤 부분에서는 답답하기까지 했다. 만약에 팀이었고, 내가 리드 였다면 결정하고 지시해서 빠르게 끝낼 수 있었을 거라는 생각을 했었는데, 결과는 의외였다. 모두 처음 만났기 때문에 서로 동등한 입장에서 경청을 해야 했고, 동등하게 의견도 낼 수 있었다. 내 입장에서는 속이 타들어가고 답답하면서도 두번,세번을 물러서서 생각을 해야했고 의견을 들었어야 했다사람들이 의견을 이야기 하고 새로운 방법을 낼때 마다 놀라운 일이 생겨났다. 내가 생각지도 못한 방법이 나왔고, 그 방법들은 성공했다. 나는 의견을 듣다가 정리되지 않는 부분에 대해서 약간의 방향성만 잡아주고 정리만 해주면 그 아이디어들은 잘 실현화가 되었다. (나는 이것을 leverage 한다고 한다.) 대략 일주일간의 경험이었지만, 존중과 경청, 그리고 각자의 재능이 어떻게 섞여서 새로운 효과를 나타내는 지를 경험한 시기였다. 그래서 팀이 모이고 경청을하고 재능이 섞이면 어떤일이 일어나는지 알 수 있다. 얼마전에 만난 스타트업 대표는 이를 캐미”(Chemi)라고 불렀다. 아마도 화학반응에서 떠온 말이 아닌가 싶다.

그러기 위해서는 나의 권한을 명령 보다는 경청을 하고 존중을해서 사람들이 가지고 있는 재능을 이끌어 내주고, 나의 경험을 바탕으로 의사 결정을 내리고 지시를 하기 보다는 경험을 공유하고 의견을 줘서 팀이 올바른 방향으로 나갈 수 있도록 도와줘야 하지 않을까 싶다. 스타트업에서 리더는 방향을 알려주고 팀을 앞으로 이끄는 주인공이 아니라, 팀이 올바른 방향으로 나갈 수 있게 뒤에서 도와주는 조연이 되어야 하지 않을까?

 

막상 책을 읽은 내용을 정리하려고 글을 쓰기 시작했는데, 책 내용은 막상 정리를 하지 못했다. 다음 글 부터는 책에서 읽은 내용을 정리 하기 시작하겠다.

2015년 개발 트랜드-조대협

IT 이야기/트렌드 | 2015.01.12 10:09 | Posted by 조대협

2015년 개발 트랜드


조대협입니다. 2015년 개발 트렌드에 대해서 간략하게 정리해봅니다. 여러 기술들을 보고 정리한 개인적인 생각이며, 앞으로 저도 집중하려고 하는 분야이기도 합니다.


애자일 및 협업 문화

애자일 과 수평 조직 기반의 개발 문화에 대한 현상은 올해에도 쭈욱 지속될 듯 합니다. 기존의 워터폴이나 경직된 조직 문화와 방법론으로는 현대의 빠른 서비스 개발을 따라갈 수 가 없져

애자일은 워낙 오래전 부터 언급되고 나온거라서 별도로 언급을 하지 않겠습니다만, 왜 이 부분을 2015년의 트랜드로 잡았느냐 하면, 국내 기업의 경우 애자일 프로세스만을 도입하는 것이 아니라, 조직의 구조나 문화 자체를 애자일 사상으로 옮겨가는 경우가 많이 보이기 때문입니다. 기존에 무늬만 애자일이었다면, 작년부터 올해까지는 애자일 문화를 적용하기 위한 직급을 없애고 직책(ROLE) 기반으로 일하기 위한 변화, 수평적 조직 구조, 그리고 스크럼 마스터와 프러덕트 오너등이 조직내에 점점 더 확실하게 자리 잡아 가는 것 같습니다.


MSA 아키텍쳐

작년 중반 부터 떠오르기 시작하더니 국내에도 많은 시스템들이 MSA 사상으로 구현되가고 있는 것들이 보입니다. 이제 시작 단계들로 보이는데, MSA를 적용을 하고 있는 조직들은 MSA가 가지고 있는 전통적인 문제들, 분산 트렌젝션에 대한 처리, 여러개의 API를 모아서 새로운 기능을 만들어내는 aggregation 개념들에서 많은 고민들을 하고 있는 것이 보입니다.

그리고 MSA를 개발하기 위한 개발환경을 셋팅하는데 많은 고민들을 하는데, MSA의 특성상 서버 컴포넌트가 많이 분산이 되고 폴리그랏(다양한 언어로 개발)현상이 조금씩 가속화 됨에 따라서, 이러한 복잡한 개발환경을 어떻게 개발자에게 전달할것인가가 새로운 키워드가 될 듯 합니다.

이에 대한 대안으로는 Docker등이 빠르게 떠오르고 있고, 사내/사외 개발용 클라우드를 구축 하는 움직임이 생기지 않을까 조심스럽게 점쳐 봅니다.

MSA를 적용함에 있어서 앞단에 api gateway (또는 proxy)역할을 하는 것들이 중요해지고 있는데, 현재는 대부분 직접 개발해서 사용하는 경우가 많습니다. 그 만큼 거기에 사용할 제대로된 제품이나 오픈소스가 없다는 것인데, (오픈소스는 현재 WSO2 api gateway, 상용 CA Layer7, 클라우드 기반 서비스 apigee) 아마 금년에는 이러한 needs 때문에 다양한 오픈소스가 나오지 않을까 조심스럽게 기대해봅니다. 2013년까지만 해도 API gateway 오픈 소스 제품들은 손에 꼽을 정도였는데, 작년말에 한번 만들어 볼까 하는 마음으로 살펴보니, 벌써 몇개의 오픈소스들이 시작되고 있더군요

그리고 MSA에 맞춰서, SpringBoot도 같이 올라가면서, 자바 진영의 개발 주류가 되지 않을까 생각해봅니다.


데이타 스트리밍 프로세스

빅데이타 영역은 하둡을 중심으로 어느정도 정리가 되었으나, 근래에 들어서 실시간 데이타 분석에 대한 니즈(needs)가 올라오면서 실시간 스트리밍 처리가 작년말부터 다시 주목 받는것 같습니다. 람다 아키텍쳐나 데이타레이크 아키텍쳐가 다시 언급되는 것도 같은 선상이라고 보는데, 금년에는 Storm,Spark 중심의 실시간 데이타 처리 기술이 다시금 부각되지 않을까 합니다.


머신 러닝의 보편화

머신 러닝은 수학 통계적인 지식이 있어야 접근할 수 있는 분야였지만, 근래에는 Apache Mahout등의 프레임웍으로, 주로 사용되는 머신 러닝 알고리즘 들은 대부분 프레임웍화 되어 있어서 접근이 매우 쉽습니다. 약간의 지식만으로도 머신러닝을 사용할 수 있다는 겁니다.

여기에, Microsoft Azure ML 서비스와, IBM의 왓슨 서비스들은 클라우드 기반으로 머신 러닝 알고리즘을 서비스하는데, 사용이 매우 쉬워서, 일반 개발자들도 쉽게 머신 러닝 알고리즘을 구현 및 운영 환경에 적용이 가능합니다.

다른 빅데이타 분석들도 이런 흐름을 따라가지 않을까 싶은데 제가 보는 관점에서는 ML쪽이 선두가 되서 서비스화되는 현상이 작년말 부터 시작되고, 금년에는 초기 활성화 단계에 들지 않을까 합니다.


폴리 그랏

작년에도 그랬지만, 금년에도 여러가지 프로그래밍 언어를 사용하는 폴리그랏 현상은 더욱 더 가속되지 않을까 합니다. Node.js등은 계속해서 약진할거 같고, Ruby,Groovy와 같은 기존의 스크립트 언어 뿐만 아니라 Google Go, MS가 이번에 Linux까지 자사의 프로그래밍 언어를 지원하겠다고 한 이마당에, 금년에 프로그래밍 언어의 흐름은 지켜볼만 합니다.


기타

자바스크립트의 약진, 자바스크립트 기반의 Pure 웹 클라이언트, 클라우드의 적용 가속화

이런것들은 워낙 뻔한 이야기이니 별도로 언급하지 않겠다. 다만 마지막으로 지켜볼것은 중국 IT 기술의 약진으로, 금년에 중국발 오픈소스나 기술들이 인터넷으로 조금씩 공개되지 않을까 기대해봅니다.


 

두번째 기술 트렌드 분석은 DB2JAVA 즉 OR Mapping Framework 입니다.
IBatis와 Hibernate를 봤는데,
1. IBatis

2. Hibernate

언뜻 보기에는 사용량이 유사해보입니다만, 국가별 차이를 비교해보면 재미있는 결과가 나옵니다.
1. Ibatis

2. Hibernate

IBatis의 경우 한국 편중 현상이 매우 심합니다. 반면 Hibernate의 경우 개발이 많은 인도, 특히 델리에서 많이 검색되고 있고, 실리콘밸리가 근접한 샌프란시스코에서도 검색 빈도가 높습니다. 언어 분포에 있어서도 꽤나 골고루 되어 있는 것을 보면, 세계적으로는 Hibernate가 대세, 한국에서는 IBatis의 압도적인 우세 정도로 평가할 수 있습니다.

실제로 IT 구인 사이트 Dice.com의 검색 결과를 보면
 IBatis  86건
 Hibernate  913건
으로 Hibernate가 압도적으로 높습니다.

이 두 데이타 역시 세계적으로는 HIbernate가 대세, 한국은 IBatis가 대세 정도로 분석할 수 있겠습니다.
실제로 프레임웍의 특성을 보면 Hibernate는 잘 설계되고 복잡도가 상대적으로 높은 반면 IBatis는 기능은 간단하지만 SQL을 직접쓰기가 편리하고, Learning Curve가 낮기 때문에 한국 개발자의 특성(??)상 한국에서 인기가 좋은것 같습니다.

그래도 개인적인 생각으로는 그런 이유가 아니라 기술적인 우위라면 우리도 Hibernate의 사용 수치가 높았으면 하는 생각도 듭니다.

'IT 이야기 > 트렌드' 카테고리의 다른 글

DSL (Domain Specific Language)  (0) 2009.07.02
IT 시스템들에 대해 공감이 가는 그림 하나  (4) 2009.06.11
자바 기술 트렌드 분석 - 2. OR Mapping  (1) 2009.04.30
자바 기술 트렌드 분석 - 1. MVC  (1) 2009.04.30
구글  (0) 2007.11.21
요즘 개발의 트렌드  (0) 2007.09.04

자바 기술 트렌드 분석 - 1. MVC

IT 이야기/트렌드 | 2009.04.30 14:15 | Posted by 조대협

백기선님 블로그에서 재미있는 글을 하나 봤습니다. 구글 검색엔진에 http://www.google.com/trends 을 보면 검색어별로 검색 비중에 대한 트렌드를 보여줍니다. 이 데이터를 분석하면 현재 기술의 흐름을 대략 읽어볼 수 가 있겠지요.

먼저 MVC 모델에 대한 분석을 해봤습니다.

1.Struts.


2. Spring MVC

3. JSF

그래프에서 볼 수 있듯이, Struts는 하향세, Spring MVC가 주요인것 처럼 보이고, JSF는 중간 정도로 보입니다. 사실 좀 데이타가 이상한것 같아서 Dice.com이라는 IT 전문 사이트에 가서 해당 키워드를 검색을 해보니 다음과 같은 결과가 나옵니다.
 JSP  1589건  
 Spring MVC  186건  
 JSF  735건  
 Struts  884건   

이 결과로 봤을때는 Spring MVC의 건수가 그리 높지 않습니다. JSF나 Struts가 메인으로 쓰이는 것 같습니다.

구글 트렌드의 국가별 검색 결과를 보면 다음과 같은 결과가 나옵니다.
아래는 Spring MVC의 국가별 검색 비중인데,


한국어의 컨텐츠 비중이 압도적으로 높습니다. 사용 빈도도 한국이 높구요.
이 데이타들을 분석해보면
외국에는 JSF/Struts가 대세, 한국에서는 Spring MVC가 대세인것으로 파악해볼 수 있습니다.

그리고 재미있는 것중에 하나가 JSP 기반의 개발인데,
위의 Dice.com의 검색 결과에서도 볼 수 있듯이 아직도 JSP기반의 개발이 많습니다.

예전에 글을 올렸을때도 비슷한 결과를 얻었던것 같은데, 일단 한국에서는 JSF로 프로젝트를 하는 경우를 거의 보지 못했습니다. 사실 Struts나 Spring MVC를 본 경우보다는 Servlet/JSP가 더 많은것 같더구요. 아니면 가우스와 같은 RIA 클라이언트를 쓰던가요..

약간 한국 개발자들이 국제적인 흐름을 못 쫓아가는 것은 아닌지.. 아니면 커뮤니티 리더들이 제대로 기술을 선도하지 못하는 것인지 하는 생각이 듭니다.