오픈비 : 삽질은없다

티스토리에 정착하여 글을 쓰기 시작한지 10년째 되었네요.

계속해서 매월 한 개 이상의 글을 적어왔는데, 최근 몇 년 동안은 포스팅을 거의 못했습니다.

시간이 지나고 업무경험이 쌓일수록 생각은 많은데 글을 쓰는 건 더 조심스러워 지네요.

오늘은 4차산업혁명에 대한 이해와 오픈소스는 어떤 역할을 하는지 생각해 보겠습니다.

마이클 포터 교수는 IT가 3번에 걸쳐 큰 변혁의 물결을 가져오고 있다고 이야기 합니다.

- 제 1 물결은 1960년대부터 70년대까지 주문처리나 경비지급, CAD, 생산관리 등 가치사슬의 개별활동을 자동화하면서 기존 수작업에 비해 비즈니스 생산성이 크게 향상.

- 제 2 물결은 1980년대 상용 인터넷이 탄생하고 90년대등러 고속 대용량화와 저가화가 진행되면서 인터넷을 통해 컴퓨터간 쉬운 연결이 가능.

- 제 3 물결은 최근에 나타나는 현상으로 제품에 센서와 프로세서, 소프트웨어, 연결 기능등이 내장되어 제품이 만들어 내는 데이터가 클라우드에서 수집, 분석되어 제품의 기능과 성능을 크게 향상.

이러한 제 3의 물결의 제품을 포터는 스마트 커넥티드 제품이라고 부르며 모니터링, 제어, 최적화, 자율성의 4단계로 구분되는 역량모델을 이야기합니다.

마이클 포터의 이러한 전망에 대해 PTC의 헤플만은 스마트 커넥티드 제품을 실현하기 위해서는 제품, 연결기능, 제품 클라우드, 보안기능, 외부 게이트웨이, 업무 시스템과 통합 등으로 구성된 새로운 기술 스택이 필요하다고 이야기 합니다.

제가 이해하고 있는 4차산업혁명은 온라인과 오프라인이 연결되는 온디멘드 서비스 유형에서 나아가, 모든것이 연결된 세상(IoT), IoT 로 수집되는 데이터의 CPS(Cyber-Physical System)에서 분석, 분석에서 나아가 기술과 사람의 의사결정력이 결합된 의사결정체계가 각 산업에서 분산을 통한 의사결정의 위임을 담당할때 성공적인 모습이라고 생각합니다. 따라서 많은 기업들이 자사의 제품 가치에 대한 높은 이해와 수집되는 데이터 분석기술에 대한 융합이 가능한 전문가를 요구하고 있으며 CDO(최고데이터책임자)를 둔 기업도 출현하고 있습니다.

IT 기업의 입장에서 보면 향후 4차산업혁명의 물결에 대응하기 위해서는 다양한 디바이스간의 연결이 가능한 기술(IoT framework, gateway, network protocol), 데이터를 수집하고 분석하는 기술(Bigdata analysis architecture, 분산파일시스템 응용기술), 데이터 기반 실시간 의사결정기술(AI, context decision making) 등이 중요하게 대두 될 것이라 생각됩니다.

현재 이러한 중요 기술들은 국내에서 원천기술을 확보하고 있는 경우가 거의 없으며, 대부분의 핵심기술은 오픈소스 프로젝트에서 제공됩니다. 따라서 앞으로는 시장에서 오픈소스를 활용한 기술개발이 더욱 심화될 것이고 기업에서 오픈소스 활용 거버넌스를 제대로 준비하고 않아서 발생되는 문제점도 커질 것입니다.  

때문에 향후 4차산업혁명의 성공을 위해서 조직은 오픈소스 기술에 대한 경험 축적과 함께 오픈소스 거버넌스의 조직 내 구축이 함께 되어야 할 것입니다.

일요일이라 밀린 일을 하러 사무실에 나왔다가 불현듯 셀프회고를 하게 되어서, 생각난 참에 예전 자료를 정리해봤습니다. 일하러 왔다가 딴길로 샌 하루네요 ㅎㅎ

예전에는 기술에 대한 관리업무가 저의 주 업무였는데 최근 몇년동안에 경영 전반에 대한 시야가 필요한 업무를 더 많이 하게 되었습니다. 지금 책상위의 내용을 보니 예전에 다루던 주제들이 많이 바뀌었다는걸 알 수 있네요.

사실 갑자기 애자일에 대한 기록을 돌아보게 된 것은 얼마전 링크드인을 통해서 모회사의 스크럼마스터 자리에 대한 제안이 있었습니다. 덕분에 정신없이 달려오던 지난 몇년을 돌아보게 되었죠. 

오늘은 애자일에서 제가 배운것과 여전히 남은 것에 대한 이야기입니다.

저의 애자일에 대한 시작을 더듬어보니 2006년 즈음에 켄트벡의 글을 만나면서 시작되었던 것 같습니다.

이 책을 통해 비슷한 고민에 대한 좋은 이야기를 접한 다음, 켄트벡, 김창준 이라는 키워드에서 TDD, 디자인패턴, 사용자스토리, 회고, xper 등으로 확산되었습니다.

애자일 프랙티스들을 여러 방식으로 적용해 보면서 익히고, 저의 주 업무가 변경되면서  그 과정에서 이런저런 현실적인 문제들을 만나서 현재 저에게 남은 것을 살펴보면 회고와 스크럼 보드 그리고 철학이네요.

우리는비슷한문제를풀고싶어하는다른이들과협업을즐기고, 개발하는내용을오픈소스화하고커뮤니티와정보를공유하며, 애자일한고객접근을통해고객의만족도를높이려고노력합니다

위의 글은 현재 회사의 웹사이트에 적어 둔 소개 내용입니다.

애자일이 저에게는 큰 영향을 주었던 것이 분명하고, 많은 것을 배웠습니다. 예전처럼 기술에 대한 고민은 자주 하지 못하지만 기업의 경영에서도 그 정신을 항상 잊지 않으려고 합니다.

얼마전부터 IT 기획을 배우고 싶은 주변 사람들끼리 모여서 매주 스터디를 하고 있습니다. 스터디 첫날에 각자가 생각하는 기획이란 무엇인가에 대해서 이야기 하는 시간이 있었는데, 기획이라는 단어는 다양한 계층에서 다양한 관점으로 해석이 되고 있더군요. 

제품 기획 또는 서비스 기획을 IT 기획자라고 이야기 할 수도 있지만, 제가 생각하는 IT 기획은 그것보다는 좀 더 광의의 의미이며 그 내용을 정리해 보고 학습 로드맵을 정리해 보려고 합니다.

1. IT 기획의 정의

기획(企劃)이란 단어의 뜻을 네이버에서 확인하니 아래처럼 나오네요.

기획이란 보다 효과적이고, 효율적으로 목표달성을 하기위해 가장 적합한 행동을 설계하는 것을 의미한다고 할 수 있고, IT 기획이란 IT의 목표를 달성하기 위한 적합한 행동을 설계하는 것이라고 할 수 있겠죠. 

그럼 IT의 목표는 무엇일까요?

IT의 목표는 비즈니스를 돕는 IT와 IT 제품/서비스를 제공하는 IT 본연의 비즈니스 관점으로 생각해 볼 수 있습니다.

첫번째, 비즈니스를 돕는 관점에서 보면 기업은 업무를 지원하는 역할을 IT에 기대하고 MIS, EIS, SCM, CRM 등의 분야에 IT 기술을 활용합니다. IT 기술을 업무 지원에 사용하거나, 원가절감과 시간단축을 기대하고 IT를 사용하는 유형입니다.

두번째, IT 본연의 관점에서 보는 경우는 IT 기술을 이용하여 제품이나 서비스를 판매하거나, IT 서비스 또는 프로젝트 중심의 비즈니스를 통하여 수익을 발생시키는 유형입니다.

이 두가지 유형의 기업들은 IT를 통하여 새로운 비즈니스 창출을 통해 신규수익을 발생 시키거나, 경쟁우위 무기로 활용 기존의 매출을 증대시키거나, 내부혁신 촉매로 활용하여 업무 생산성을 증대하는 것이 주요 목적이 됩니다.

따라서 IT 기획이란 IT를 통한 신규 비즈니스의 창출, 경쟁우위로 활용, 내부혁신의 촉매로 활용하기 위한 적합한 행동을 설계하는 것을 의미합니다.

2. IT 기획의 대상

IT의 목표를 달성하기 위한 IT 기획업무의 대상은 아래의 3가지로 구분할 수 있습니다.

1) 전략

2) 사업

3) 제품/서비스

1) 전략 부문

- 어떻게 효과적으로 정보기술을 연계하고 적용할 것인가에 대하여 전략 및 해결책을 찾고 실행계획을 수립하는 과정 : 정보화 전략 계획 수립(ISP: Information Strategy Planning)

- IT 체계에 대한 효과적인 분석 및 활용 기법 : EA(Enterprise Architecture)

- 비즈니스 프로세스에 대한 효과적인 개선안 수립 기법 : BPR (Business Process Re-engineering), PI (Process Innovation)

2) 사업 부문

- 환경분석

- 업무분석

- 문제해결/이슈분석 기법

- 조사방법 활용

- 변화관리방법론

- 전략개발방법론

- 리스크 관리방법론

3) 제품/서비스 부문

- 제품/서비스 및 산업에 대한 이해

- 제품/서비스 기획 프로세스 지식

- 제품/서비스 기획 점검

- 제품/서비스 기획 리뷰

- 제품/서비스 기획 평가방법

최근 회사의 업무 아키텍처를 개선하는 작업이 진행되어 조직도, 업무프로세스, R&R, 복지정책 등 다양한 관점에서 변화가 많았습니다. 그러다 보니 이번에 새로 팀장이 된 사람도 있고, 팀의 R&R이 변경되어 팀 비전을 새로 수립하는데 고민하는 팀장도 있는 상태입니다. 팀의 리더들이 고민이 많은 시점이죠.

조직의 성패에서 리더의 중요성은 다들 인식을 하고 있지만, 정작 리더가 되어야 하는 순간에는 별도의 지식체계를 따르는 것이 아니라 타고난 기질과 성장배경 그리고 현장에서 부딪치면서 자연스럽게 리더십을 배우게 됩니다. 과연 모든 사람에게 통하는 보편적인 리더십은 어디에 있을까요?

리더십은 다음의 두 단계를 거치면서 결정됩니다.

1) 조직에 의해서 리더의 지위를 획득하는 단계

2) 팀원들에게 리더십을 얻는 단계

간혹 팀장이라는 지위를 얻으면서 의욕이 앞서서 무리수를 두는 경우를 보게 되는데, 아무리 지위를 얻었다고 해도 진심으로 따르는 사람이 없다면 진정한 리더가 아니라는 것을 명심해야 합니다.

리더십을 결정하는 것이 조직과 팀원이라는 것을 이해한다면 아래 그림과 같은 질문을 해보게 되죠.

"나는 어떤 리더일까?"

조직은 성과를 원하고 팀원은 인정과 칭찬을 원합니다.

결국 리더십을 배운다는 것은 조직과 팀원에게 모두 인정받는 아래의 방법을 배우는 것을 의미하는 것이죠.

1) 팀원들을 섬기는 서번트 리더십 

2) 팀원들의 부족한 능력을 향상시켜서 성과를 만드는 방법

따라서 좋은 팀장이 되기 위해서는 가장 먼저 리더 자신이 전문 분야에 능력 있는 사람이 되고, 자신의 능력을 팀원들에게 잘 전수하는 커뮤니케이션 능력을 키워서 진심으로 따르는 팀원이 많아지도록 계속 노력해야 합니다.

물론 쉽지 않습니다 :-)

오늘은 팀원과 서로가 원하는 이상적인 팀의 운영이란 어떤것인지 팀 운영방식에 대한 이야기를 할 기회가 있었습니다.

좋은 팀이란 무엇보다도 상대에 대한 이해를 기반으로 해야 하는데, 대화를 해보니 팀 리딩에 있어서 팀원들과 함께 팀의 미래에 대한 비젼을 공유하지 못하고 있는 것 같아서 좋은 팀에 대한 제 생각을 한번 정리해 보려고 합니다.

지난 몇년간 애자일하게 일하는 SW기업이 되고자 이런저런 고민을 많이 하고 있습니다.

그 중 'Self-Organizing Team' 이라는 키워드는 매력적이었고 제가 원하던 모델이었죠.

저는 전통적인 조직운영 방식에서 보이는 강력한 중앙집중형 리더십이 조직을 이끌어가는 형태가 아니라

통제가 적고 구성원의 자유도가 높은 리더십으로 운영이 되는 애자일한 조직운영을 하고 싶었습니다. 

Source : http://blogs.seapine.com

제가 이해한 'Self-Organizing'은 멋진 용어이지만, 실제 현업에서 몇년간 해보니

자율적인 업무결정권을 자유로운 업무방식으로 오해하는 팀원이 생기고 그로인해 갈등이 심해지는 경우들이 발생되었습니다.

프로젝트에서 너무 적은 리더십을 가진 스크럼마스터는 팀원이 상호작용하여 협업이 되도록 하기에는 부족하였고

팀원에게 많은 결정사항을 위임하는 자율적 결정방식은 수동적이 지시에 의존해온 팀원들에게 괴로움만 가중시키게 되었습니다.

'서툰 목수가 연장을 탓한다'고 하더니 이게 그런 모습이네요. ㅎㅎ

사실 이것은 리딩을 제대로 못한 저의 무능력 때문이지, 자기조직적팀(Self-Organizing Team)이 잘못된 것은 아니라고 생각합니다.

제가 생각하는 자기조직적인 좋은 팀이란?

프로젝트의 핵심가치를 위반하지 않고 유연하게 해당 업무를 수행할 수 있는 능력이 충분한 사람들의 모임.

- 상호간 업무수행에 있어서 친화력(affinity)이 있을 것.

- 핵심가치를 달성하기 위하여 충분한 자격(competent)을 가질 것

- 팀의 공동문화에 대한 이해와 지지

- 리뷰는 각각의 일정에서 가장 높은 우선순위로 처리하는 태도

- 핵심가치의 달성이라는 목표의 업무안에서는 자체적인 활동

- 중앙집중형 의사결정이 아니라 팀에 의사결정 권한을 분산하고 결과에 대한 책임도 공유

- 개개인은 문제해결을 위하여 능동적인 대응

최근에는 운영방식을 좀 변경했는데 최종결정을 내리는 의사결정프로세스를 명확하게 하여 팀원의 책임을 덜어주면서

팀원들이 능력을 최대한 발휘할 수 있도록 독려하는 형태를 유지하려고 하고 있습니다.

모든 일을 잘하는 슈퍼개발자를 원하는 것은 아니지만 분석, 설계, 코딩, 테스트, 배포를 할수 있는 스크럼 팀원이 다수 있어야 하는데 자원의 확보(항상 팀원이 부족합니다 ㅎㅎ)부터 교육이나 인적자원 관리 등의 이슈가 많아서 팀 리딩이 어려운것은 여전합니다. 하지만, 팀원들이 모두 잘 따라주어서 예전 보다는 훨씬 나아졌으니 앞으로 점점 좋아질거라고 믿습니다.

요즘 잉여시간이 없어서 포스팅을 못하고 있었는데 오늘 이메일로 팀원중의 한명이 다음과 같은 질문을 해왔습니다.

처음에는 재미있고 열정이 가득했던 일이 시간이 지나면서 점점 단조로워지고 예전처럼 재미가 없어서 열정이 줄어드는 문제에 대해서 어떤 해결책이 있을까요?

이와 비슷한 문제를 저도 예전에 고민했던 기억이 나서 답변을 위해서 좀 생각을 해보았는데 딱히 정답이 있는 것이 아니니 제가 생각해 왔던 이야기를 해주는 것이 좋을 것 같아서 글로 정리를 해보았습니다.

어느 조직에서나 조금 경력이 쌓이고 후임자들을 관리해야 하는 자리에 가게되면 팀원들 효율적 생산성 제고 방안에 대하여 생각하게 되죠. 저 역시 SW기업의 좋은 팀워크에 대한 고민이 항상 많습니다. 

개인의 욕구와 동기부여를 위한 이 부분의 설명을 위하여 가장 알려진 것은 매슬로우의 욕구5단계입니다. 매슬로우는 인간의 내부에는 다섯가지의 욕구단계가 존재한다는 논리(인간의 동기와 성격-Motivation and Personality)를 주장하는데 개인에게 동기를 부여하기 위해서는 단계별로 상승하는 인간의 욕구를 제대로 이해해야 한다는 것이죠.

이 5단계는 다시 1~4단계의 결핍욕구와 5단계의 성장욕구로 나눌수 있습니다. 결핍욕구는 주로 연봉이나 근무시간 등의 외부요인으로 충족이 되는 반면 자아실현의 욕구는 자신의 내부요인에 의해서 충족될 수 있다고 합니다. 이 논리가 문화적 차이가 있는 외국에서 정립된 것이므로 우리의 조직문화에서 정답이 되기는 어려울 수 있지만, 제가 팀원들에게 동기를 부여하여 자기실현을 위한 코칭을 할 때 판단기준으로 잘 사용하고 있습니다.

이메일로 받은 질문에 대한 저의 답변은 "아래의 순서대로 해 보세요" 입니다. 

1) 현재의 상태를 진단해본다

2) 자기실현문제가 아니라면 외부환경을 개선해서 해결해 본다

3) 자기실현의 문제라면 자기실현에 성공한 사람들의 특징을 이해하고, 자신의 삶에 적용해 본다

4) 잘 안되었으면 다시 해본다.

음.. 쓰고보니 자주 보시던 점진적 SW개발방법론과 비슷하네요.

저의 경우에는 자기실현의 문제가 있어서 고민을 했었고 제가 이 경우에 적용해본 방법은 팀 스터디를 하거나 오픈소스SW 프로젝트에 참여하거나 특정한 문제를 해결하는 능력을 배양하거나 하는 등의 '최대한 많은 것을 알고 경험하기(peak experiences)' 입니다. 

자기실현에 성공한 사람들의 특징에는 사생활을 즐길수도 있고, 인간관계를 깊이 하는 것도 있고 여러가지 공통된 특징이 발견되었으며 이런 특징을 모두 가지고 있다고 해서 반드시 멋진 인생을 살게 된다고 할수도 없습니다. 따라서 제가 적용한 이 방법이 모든 경우에 적용가능한 은총알이 될 수 없겠죠. 그렇지만 "어떤 인생을 살 것인가"에 대한 고민이 될 때 이런 방법을 고민해 보는 것도 좋을거라고 생각합니다.