컨퍼런스를 통해서 먼저 소개하였고, 프리젠테이션을 통해서 안드로이드의 문제를 해결할때 필요한 여러 오픈소스들을 설명해 드렸습니다.  (재미난 것은 외국에서도 Android Bootstrap이라는 형태로 기존 Android의  문제를 해결하기 위해 여러 오픈소스를 묶어 제공을 했고, 안드로이드 개발자에게는 꽤 인기가 좋은 것으로 알고 있습니다.  )

이 버전보다 더욱 업데이트된 모바일 참조 아키텍처 (안드로이드) 를 발간 하였습니다. (링크를 통해 다운 받으시면 됩니다 – 소프트웨어 공학센터에 이메일 가입이 필요합니다)

안드로이드 어플리케이션 블록 아키텍처 

기존의 안드로이드의 구조(젤리 빈 기준)는 진성주 군과 분석하여  정리해보았습니다 (이 링크를 클릭하시면 됩니다).

그리고 저희가 몇가지 오픈소스들을 더해서 아래와 같이 추가된 모델을 만들었습니다.  새로 추가된 오픈소스가  기존의 어떤 안드로이드 패키지와 연관이 있는지 색깔을 입혀 표현을 하였습니다.

저희가 이번 백서에 다룬 오픈소스는 다음과 같습니다.

• fHalo – facebook client library
• Simple, Google gson – marshaller
• RoboGuice, AndroidAnotations – IoC
• Logdog – microlog4adnroid
• funf – sensing framework
• Android Billing Lib
• ActionBar
• Binding Framework  (UI MVC framework)

예를 들어 Android Billing Library는 안드로이드의  In App Purchase를 쉽게 해주는 라이브러리로 , 저희가 Reversing하여 다음처럼 모든 오픈소스에 아키텍처를 분석하였습니다.

실제 안드로이드 개발자에게 도움이 될수 있게, 다음과 같이 내용을 다루었습니다.

• 각각의 오픈소스마다의 개별적인 아키텍처 설명 추가
• 기존 안드로이드의 유사 컴포넌트 보다 무엇이 개선되어졌는지
• 어떻게 오픈소스를 쓸수 있는지 코드 레벨까지 설명

이런 형태대로  아키텍처와 실 사용 방법까지 되어 있으니 안드로이로 개발하시는 중소기업이나 개발자들에 많은 도움이 되리라 확신합니다.

도움이 필요하신 분은..

위 문서를 보시고, 세미나나 안드로이드에 오픈소스 적용, 아키텍처 설계및 리펙토링에  도움이 필요하신 분은 실무 적용 멘토링 서비스를 신청(양식 다운)하시면 저희가 파견가서 도움을 드립니다.  필요하신 분은 신청해 주세요

최강의 어벤젼스 맴버들이 가서 도와드립니다. (자칭 어벤젼스요 쿨럭… )

최강의 맴버들과 과제를 맺으며..   

이 과제가 성공적으로 마치기 위해 노력해준 여러 집필자들이 있었고, 이 과제가 마칠때 정말 좋은 일들이 있었습니다.

• 말랑 스튜디오 (알람몬) 의 김영호, 강진석 군(현 삼성전자) 은  알람몬을 만들때의 노하우를 많이 전달해 주었고, 시리즈 A의 투자를 이끌어 낼 정도로 좋은 일이 있었습니다.
• Sleep if you can의 신재명 군은 아이폰 매출 1위를 달성하며, 1주에 1000만원이 넘는 매출을 올리면서 승승장부하고 있습니다.
• 분석과 여러 가지 힘든 일을 도 맡아 준 Usergrid Stack 컨트리뷰터인 진성주군에게 매우 큰 감사를 드립니다.
• 소마에 멘티 오유환 군은 특채로 경력을 2년 인정받아, 3년차로 LG에 입사하게 되었구요.

정말 좋은 일만 가득한 한해였으며, 저희가 이번 추가 과제에 도움이 될만한 여러 오픈소스와 참조 아키텍처 모델들을 공유하도록 하겠습니다.   감사합니다.

실제 고객을 한번도 만나보지 않고 기획이나 UX팀에서 날라온 공급자 중심의 설계, 그리고 고객들의 불만을 대응하기 위해 일정에 쫓겨가며 헐레벌떡 기능을 구현하게 만들고, QA팀과 이건 버그가 아니다라고 실강이 한 기억들이 납니다.  저의 고객은 임원인 경우가 많죠.

사실 저도 이러한 부분과 거리가 멀었고,  소프트웨어 마에스트로 과정을 통해서 깨닫게 되었습니다.

알람몬을 만든 김영호 사장님이나,  Sleep if you can의 신재명군과  같이 그들이 얼마나 고객의 피드백을 받아가며, 그리고 사업적으로 살아남기 위해 여기 저기 뛰어나닐수 밖에 없는 모습을 보며, ” 나는 저 나이에 저런 열정이 있었나?” 라며 되돌아 보게 됩니다. (이 친구들과 같이 한 정부 과제가 있는데 그중 일부가 여기에 있으니 참고하세요)

NHN NEXT의 휴먼 디자인 프로젝트나  소프트웨어 마에스트로 과정은 비록 리얼 월드는 아니지만, 최대한 그것에 가깝게 갈려고 많은 교수님들과 멘토님들이 날카롭게 질문을 합니다. (아무리 가깝게 할려고 해도 자기돈으로 하는 사업이 아니니 리얼월드가 아닌점은 사실이구요. 하지만 노력을 많이 가하고 있다는 점을 알아 주셨으면 합니다.)

기술을 학습하기 위해 억지로 만든 프로젝트가 아닌.  사용자에게 줄수 있는 핵심 가치(우리 프로젝트의 가치)가 무엇이고, 그걸 어떻게 찾아가는지에 대해서 많은 협의및 고민을 합니다. SK 컴즈 CEO 셨던 주형철 부학장님이나, 저와 많은 코웍을 하시는 장선진 멘토님에게  전혀 다른 두가지 입장 (거대한 기업을 이끌었던 경험과,  스타트업에서 정말 얻는 고충)들을 곁에서 많으 조언과 코치를 받았습니다.

평가 시즌을 거치면서 우리가 만든 소프트웨어의 가치는 무엇이고, 이 가치를 팀원 모두가 잘 공유하고 있고, 이게 프로젝트가 끝날때 까지 잘 유지되어서, 핵심 가치를 잘 전달할수 있는 소프트웨어가 될수 있을까? 에 대한 고민을 가지게 되었고, 결국 상품기획, 개발자, 디자이너 성향을 가진 종합 예술인(?) 분을 모셔서 어렵게 코칭을 받았습니다.

그 과정을 어떻게 하나 하나 진행했는지를 이번 포스트에서 공유하고자 합니다. 소마에 과정의 예산으로 한 것이라, 당연히 외부에 공유가 되어야 할거고, 지금 NHNNEXT 학생들도 이 주제에 대해서 크게 고민을 하고 있을거 같아 적어 봅니다.

프로젝트 상황 (Context) 

저희가 가치를 찾기 위한  프로젝트에 대해 설명드리면, 제가 세미나나 포스팅을 통해 여러번 소개를 드렸던 STAN4J를 Web 형태로 보여주는 프로젝트 입니다. 이것들을 저렴하게 또는 오픈소스로 만들어서  Jenkins 플러그인과 서비스로 배포한다는 지극히 개발자 적인 마인드로 접근을 했습니다.

하지만 파고들다 보니 SQAM 이라는 시장이며 고가 제품군들이 포진하고 있으며, 사용자 조사를 통해서 저희만의 강점과 여러가지 pain point를 찾았습니다.  그 부분은 여튼 저희만의 무기니까 먼 훗날 소개를 하도록 하구요.   M1 기능을 구현한 버전을 직접 보시도록 하시죠.

위 Stanly M1 단계를 만든후 여기 저기 피드백을 받으니, 경쟁 제품과의 차별화 포인트를 찾고 우리가 가야할 가치에 대해서 좀더 다듬을 필요가 있다고 생각이 들었습니다.

프로젝트 가치 찾기 워크샵 절차와 숙제

스타트업이라면 모든 팀원이 모여서 하시는게 좋습니다.   모든 팀원의 이 프로젝트가 추구하는 가치와  우리는 이러한 어플리케이션을 만들구나 라고 명확하게 서로간에 Consensus를 이루게 만들수 있는 좋은 장치지요.

다음과 같은 절차로 프로젝트의 핵심 가치 찾기를 하는 워크샵이었습니다 .

1. 목적과 목표 수립
2. why & why not buy?
3. simple value proposition
4. user profiling -> opportunity 도출
5. convergence
6. 핵심 concept 및 value 도출
7. summary

애자일 종합 예술인 께서 위와 같은 절차는 다음과 같은 큰 프레임 안에서 움직이는 절차라고 말씀해 주셨습니다.

시작 – Divergence – Convergence – Divergence – Convergence 라는 절차 즉 아이디어를 막 내다가, 다시 모아서 정리하고, 또 다시 정리된 아이디어에서 더 다양한 것들을 찾기 위해 아이디어를 확산하고, 다시 재정리하는 것이지요.

이 프로젝트를 하기 위해선 다음과 같은 사전 숙제가 필요합니다.

1. target customer 도출 : 누가 stanly를 살건지 2~3명 정의
2. 정의한 customer의 persona 만들기 :어떤 사람이고 어떠한 성향인지등 상상해서 작성. 예) “david은 30살의 IT 엔지니어로서 평소에 아키텍쳐에 관심이 많은 사람이다.”
3. stanly를 고객이 왜 사는지(why buy?) 왜 안사는지(why not buy?)에 대해서 이유를 각각 30개씩 적어오기. 
4. 본인이 생각하는 stanly의 awesome한 기능 “딱 하나만” 선정해오기.

소마에 멘티인  양현철(Y), 정승수(J), 오혜성(O) 친구들이 한 숙제입니다.  이 친구 다 순수 개발자이기 때문에,  기술위주,  기능위주라고  애자일 전문가 (종합 에술인)께서 피드백을 주셨습니다. 모법 답안은 아니지만 많은 개발자에게 도움이 될거 같아 공유합니다.

다른 사람에게 프로젝트의 가치를 설명하기 위해서.. 

개발자가 흔히 빠지는 오류

• 일반인 : 개발자에게 너 뭐하냐?  
• 개발자: 클라우드 개발해요.
• 일반인 : 클라우드하고 뭐하세요?  
• 개발자 : MySql Sharding을 통해 1억개의 노드를 핸들링해요.

일반인이 알고 싶은것은 Sharding까지해서 뭘하는지 실제 고객에게 어떤 형태로 서비스가 되는지가 더 중요하다는 것을 이야기 못하지요. 만약 이 일반인이 VC라면?   개발자는 대단하겠다고 하지만..  일반인, 투자자는 이해 못합니다. 이 사람들에게 명확하게 이해할수 있는 단어로 요약 정리할 수 있는게 중요합니다.

타겟 유저 선정과 페르소나 구하기(실제는 관찰하고 고민해야 하지만, 가상으로 정의함) 

페르소나 (Persona): 특정 타겟 Customer를 정한 다음, 그 사람의 생활 패턴들을 정의하고, 사용 시나리오를 도출하는 것을 말합니다.  Stanly라는 소프트웨어를 누가 사고, 어떻게 사용할 것인가?  사실 타겟 고객의 관찰을 통해서 페르소나를 구해야하며, 다음과 같이 페르소나를 구하는 절차들이 있습니다.

실례:

절차를 거쳐 위와 같이 고객의 Persona를 만들어야 합니다. 하지만 저희는 나름대로 시장을 조사해서 다음과 같이 Y,O군의 고객의 페르소나를 구했습니다.

Y군:

•  안드로이드 어플리케이션을 만드는 프로그램 아르바이트를 하는 손오공군. 아르바이트를 의뢰한 업체에 결과물을 전달할때 Stanly로 분석한 결과(개발과정 중에 프로그램의 구조, 오염도의 변화)도 함께 전달하여. 추후 의뢰업체에서 유지보수를 용이하게 할 수 있도록 함
•  안드로이드 어플리케이션을 만드는 중소 SI업체 안드로만드로, 소프트웨어 구조를 파악하여 개발자마다 담당 업무를 분담하기 위하여 사용, 개발자마다 끼친 코드 오염도 표시하여 적절함 갈굼에 사용
• 자바 오픈소스 프로젝트 파운더, 오픈소스는 많은 사람들이 커밋을하여 구조가 복잡해 질 수 있으므로, 구조가 유지될 수 있도록 감시용으로 사용

O군 :

•  중견기업의 들어온지 얼마 안된 개발자: 존은 어느정도 자리잡은 중견기업(D 회사)에 취직한 초보 개발자이다. 처음 들어와 프로젝트에 참여하기 위해 전체적인 구조를 파악하여 팀에 빠르게 적응하기를 원하는 사람
• 중견기업의 프로젝트의 리더 개발자(?) : 칼은 중견 기업에 상당히 큰 규모의 프로젝트를 장기간 진행하면서 서비스하는 프로젝트의 개발자이다. 서비스가 장기화되면서 기능의 추가나 유지보수 등의 작업으로 인해 프로젝트의 구조를 개선할 필요가 있어진 개발자
• 오픈소스 개발자 : 론은 오픈소스 커밋터로 활동하고 있다. 오픈소스 활동을 하면서 다양한 사람들이 기능을 추가하거나 유지보수 하는 경우가 많아서 프로젝트의 구조가 자주 변경되어서 프로젝트의 구조가 꼬이는 상황이 자주 발생하여 해당 상황을 해결하고 싶어하는 개발자
• 초보 개발자 : 콘은 대학교 3~4학년에 재학중인 개발자 지망생이다. 기초적인 개발은 할 수 있지만 보다 프로젝트의 좋은 구조를 구성하기 위해 패턴등과 같은 기법에 많은 관심을 가지고 있는 개발자

팀원, 또는 이해당사자들의 프로젝트 목적(Purpose)과 목표(Goal) 

프로젝트의 목적과 목표에 대해서 각 팀원들이  생각하는 바를 적습니다.  목적과 목표를 나누어서 이해하실 필요가 있습니다.

• 목적 (purpose) 은 : Jolt award 빛나는 최고의 분석 툴 (끝이 없다. 쉽게 말해 Approach를 말한다.)
• 목표 (goal)는 : 100  copy ( 달성하면 끝나는 것 )

이 프로젝트를 통해서 서로 얻고자 하는 목적과 목표를 적습니다. 저희팀은 아래와 같이 나왔습니다.

목적을 정할때. Scope을 정하면 가야할 방향을 정하기가 쉽습니다.  단기, 중장기 전략을 구해야 하지만, 좀더 현실적인 단기적인 목적을 쉽게 결정하기 위해 scope을  남은 3개월 프로젝트에서 라고 정하였습니다.  

이때 나온 몇몇 문제들을 공유하자면. 개발자가들은  머리속에서 어느정도  구현 강도를 알기 때문에, 당장 구현할 수 있는 범위에서 이 목표를 정하는 우를 범합니다.  원래는 모든 소프트웨어가 우리것을 적극 활용할수 있게 하자고 했는데, 한 멘티가  그건 힘들거 같으니 오픈소스 프로젝트를 분석한 결과를 갤러리 같이 보여주는 정도가 어떻겠냐고 말을 했습니다.   그래서 애자일 종합 예술인께서 Why라는 카드를 꺼냈습니다.  그 대답은 홍보였습니다.  홍보가 우리 프로젝트의 목적은 아니라는 것을 알고 있었고, 그래서 다시 수정을 하여 조기에 프로젝트의 문제를 해결해 줘서 사용자가 Stanly 에게 감사해한다 라고 목적을 정했습니다.

그리고 easy to use, easy to understand는 좋은 목적이 되지 못합니다. 너무 추상적이기 때문에  어렵다는 거죠. 일종의 함정같은 미사어구라고 종합예술인(애자일 마스터) 이 말씀해 주셨습니다. 좀더 자세히 설명해야 하는데, 이 부분은 다음 단계에서 이야기를 나누어 좀더 구체화 하기로 했습니다 .

Why Buy & Why not Buy

고객은 왜 우리 Stanly를 살까? 왜 안 살까? 에 대해서 각자 30개씩 적었구요. 3명이 적었으니 3* 60 = 180개를 소리내어 읽어가며 마음에 드는 단어들을 postit에 적게 했습니다. 소리를 내어서 읽는 이유는  말이 되는지 안되는지, 어떤 의미인지 그리고 다른 사람들을 집중하게 만들수 있게 만들기 위해서 입니다.

why buy에 해당하는 단어는 파란색 post it으로 why not buy에 해당하는 단어는 빨간색으로 post it으로 적었습니다. 그래서 post it들을 그룹화 하고 재 배치를 했습니다.

이러한 툴을 모르는 대부분의 학생들이 아이디어를 발굴할때, 서로의 아이디어를 비교하고 서로 오랜 설득끝에 하나의 아이디어를 내는데,   과정 과정 하나가 어떻게 도출되었는지 이해하기 어려운 면이 있습니다.  그래서 그 과정이 제대로 되었는지 다시 되돌아서 확인을 해야하고, 그것 자체를 불쾌하게 생각하는 친구도 있씁니다.

토론을 통해서 하는 방법은 다양성을 죽이고 하나만 살리는 방법이라면, 이러한 툴을 사용하니, 서로의 생각들을 모아 그룹화함으로써, 협력하여 자연스럽게 의견을 모아내는 힘이 아닌가 쉽습니다.   그냥 이런 툴을 써서 아 이렇구나 도출된다고 볼수 있지만, 전자 후자를 다 겪어보는 저의 입장에서는 마찰없이 자연스럽게 의견이 도출된다는 점이 감사했습니다. 여튼 짜잔 다음과 같이 사는 이유 (파란색) , 안 사는 이유 (빨간색)으로  큰 상위 개념으로 그룹화되어서 나왔습니다.

왜 사야 하는지, 왜 안 사는지에 대한 잠재적인 수요가 나왔습니다. (판매되는게 아니라면 왜 쓰는지, 왜 안쓰는지로 하시면 될듯 해요. )

Simple Value 발굴 (Bottom Up 으로) 

왜 사는지, 안 사는지 (Why Buy &  Why not buy) 를 통해서 기능들을 Offers 에 더 그룹화하거나 핵심 요소를 찾아 매핑을 하고 이걸 모아서 Value 찾아보는 방법을 취해 보았습니다. 가치 2개는 Why Buy에서, 가치 1개는  Why not buy에서 뽑도록 권고했습니다.  이때 발생한 문제는 offers를 들어간 것들을 찾기가 쉽지 않았습니다. 다시 한번 적절하게 그루핑하고, 버릴걸 버린다는게 쉽지 않더라구요.

애자일 종합 예술인께서 옆에서 계속 도와 주었습니다. 5 Whys 기법과 적절한 어휘 선정등에 대해서요.    이건 추상화하면서 명시적으로 표현하는 것을 다 만족하기가 쉽지 않은거 같습니다.

페르소나에서 돌아와 User Profiling ,  Opportunity (기회 요소) 도출, Convergence 

모든 이해 당사자가  1명이 제시한 3개의 페르소나에서 가장 우선순위가 높은 페르소나 1개를 선정합니다.  이전에서 했던 정보들을 가지고 가장 우선 순위가 높은 Persona를 선정하는 것이지요.  저희가 투표해서 다음과 같이 선정되었습니다.

• Y군 : 자바 오픈소스 프로젝트 파운더, 오픈소스는 많은 사람들이 커밋을하여 구조가 복잡해 질 수 있으므로, 구조가 유지될 수 있도록 감시용으로 사용
• J군 : 기업에 다니다가 중견기업 프로젝트 매니져로 들어온 매니저 b씨 대기업에서 비싸고 좋은 툴들을 사용해봄
• O군 : 론은 오픈소스 커밋터로 활동하고 있다. 오픈소스 활동을 하면서 다양한 사람들이 기능을 추가하거나 유지보수 하는 경우가 많아서 프로젝트의 구조가 자주 변경되어서 프로젝트의 구조가 꼬이는 상황이 자주 발생하여 해당 상황을 해결하고 싶어하는 개발자

선정된 3사람의 유저 시나리오를 딥하게 작성해 보았습니다.

3명이서 각자 작성한 시나리오를 가지고  Opportunity를 도출합니다.  각 문장을 쭉 읽어가면서, 마음에 드는 단어를 Post it에 적고 다시 이렇게 그룹화 합니다.

다음과 같이  Opportunity를  서로 엮어서 Convergence를 도출했습니다.

• 아키텍처 파악
• 공유
• 원인 파악
• 방향성 유도
• 아키텍처 관리

핵심 Concept및 Value (가치) 도출

지금까지 데이터를 다시 조합하고 고민해서, 위의 칸에 데이터를 넣어서 핵심 개념과 가치를 도출해야 합니다. 5시간을 쉬지 않고 달려서 그런지 친구들이 이 문장을 보고 멍해지더라구요.  이걸 어떻게 채워야 할지 고민을 하고,  지금까지 쌓아온 여러 지표들을 다시 보고 또 다시 보면서 고민을 했습니다.  이 마지막 핵심 가치를 뽑기 위해서 정말 많은 고민을 했습니다. 명확하며, 가치를 잘 표현할수 있는 문장을 뽑아내는 작업을 해야만 했습니다.

누구에게나 딱 맞는 소프트웨어를 만들고 싶어요 라고 하면? 감이 오시나요?  오지 않죠. 그래서 몇번을 지우고 다시 적으면서 찾았습니다.

타겟 유저(고객)은 편하게 찾았으나 가치를 찾기가 역시 고민이었습니다. “문제점을 한번에 보여주는 뷰”   한번에.. 이게 무슨 의미이지?   한번에라는 말은 너무 추상적인 단어입니다.  그래서 5 Whys 방법으로 다시 파고 들었습니다.

서로 협업하여, 한발 한발 근본적인 원인을 찾아갔습니다. 아마 이게 디테일의 힘 아닐까 쉽습니다.

결국 서로 협의해서 “문제점을 조기에 알려주는 기능 (Early Warning)” 으로 서로 협의하고 찾아내었습니다.

역시 다른 것도 이렇게 한발 한발 찾아나갔습니다.  말싸움이지만 가치를 찾는 싸움을 계속 합의하고 고민하고 찾아 나갔습니다.

결국 오랜 시간 동안 힘들게 다음과 같은 가치를 도출했습니다.!!

Stanly는 0) 소프트웨어 개발 팀 에게  핵심 가치로   1) 소프트웨어를 확장 가능한 구조로 유지하고, 2) 문제점을 조기에 알려주고, 3) 직관적이고 명시적인 문제원인과 분석결과를 공유하는 가치를 제공한다.

정리하며.. 

지금까지 저희들은 stan4j 비슷한거라고 서로 머리속에 그림을 그려오기는 했으나, 각자 세부적인 생각들 즉 지향점이 다른  상태에서 시스템이 만들어 왔다는 것을 깨달았습니다.

일반사람도 쉽게 짧은 시간 안에 이 소프트웨어는 이러한 것을 하기 위해 만들어 졌구나 라고 하는 핵심 가치를 발굴하고 이 가치가 그대로 소프트웨어 개발 끝까지 가게 하는 것.  다른 생각들을 그룹화하고 모으고, 다시 흩어 뜨리고 다시 모으는 작업을 하면서 더 단단하게 만드는 작업을 했습니다.

물론 전략적 수정이 있을순 있으나, 그래도 시작지점에서 모두 동일한 가치를 깨닫고 갈수 있다는게  이 워크샵을 통해 얻을수 있었습니다.  Stanly 팀원 오혜성, 정승수, 양현철 만세!!  NHNNEXT 만세!!

조엘 온 소프트웨어에 나온 하나의 글이 돌아다니기에 생각을 적어봅니다. 정말 오랜만에 개인의 생각을  적어본 글이네요…

더 나은 코딩을 만들기 위한 12단계 라는 주제로 아래와 같은 지침을 제시하고 있습니다.

• Source Control(소스 컨트롤)을 사용하십니까?
• 한번에 빌드를 만들어낼 수 있습니까?
• daily build(일별 빌드)를 만드십니까?
• 버그 데이타베이스를 가지고 있습니까?
• 새로운 코드를 작성하기 전에 버그들을 잡습니까?
• up-to-date(최신) 스케줄을 가지고 있습니까?
• spec(설계서)를 가지고 있습니까?
• 프로그래머들이 조용한 작업환경을 가지고 있습니까?
• 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
• 테스터들을 고용하고 있습니까?
• 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
• hallway usability testing(무작위 사용성 테스팅)을 하십니까?

우와 이것을 잘 지키면 정말 더 나은 코딩을 만들기 위한 단계가 될까가.. 저의 얼굴일 살짝 찌뿌려 지더라구요…  뭔가 불편합니다.

왜 이런 생각을 가졌을까요?    뭐가 빠졌다고 생각이 들기 때문입니다. Kent Beck님이 한국에 세미나때.. 하셨든 말들.. 그리고 Linda Rising 누님께서 나눈 말때문이거 같아요.  전 대기업에서 일을 해왔지만, 소마에 프로그램을 통해 많은 스타트업을 보았고. 많은 것을 깨달았습니다.

이것보다 선행되어야 하는게 있습니다.

• 정말 고객이 원하는 소프트웨어 일까요?
• 고객이 짜증내고 불편해 하는 pain point를 개발자도 알고 있나요?
• 고객의 피드백을  다음 전략때 반영할 정도로 고객의 말을 잘 경청하고 우선순위를 매기고 있나요?
• 팀원이 서로를 신뢰하고 있나요?
• 나의 문제가 나만의 문제가 아니라, 팀의 문제이고 같이 고민해줄 동료가 있나요?
• 오늘 팀원들 중에 인상이 안 좋은 팀원에게  무슨 일이 있냐며 안부를 물어 보셨나요?
• 슬픈 일이 있는 동료에게 위로의 메세지나 차라도 한잔 나눌 만큼 조직은 따뜻한가요?

서로를 신뢰하지 못한 팀들에게 망할 분업화에가 더해진 상황에서, 만약 위에 12단계가 실행된다면. 책임 전가에 여러가지 고통.. 다들 아시잖아요..

물론 현실은 차갑지만, 그래도 고객을 보며, 서로 끈끈한 스타트업이 정신건강에는 더 좋습니다..  더 이상 말하지 않겠습니다. 이 바닥에 좀  있으신 분은 아실거에요..  제가 왜 이런 말을 하는지..

독자들과 한발짝 다가가서 더 많은 이야기를 나눌수 있어서 좋았습니다.

아래와 같은 주제들을 60분간 나누었습니다.

• 소프트웨어 아키텍트가 알아야 할 97가지 어떤 책인가?
• 아키텍트는 신기술에 대한 이해가 필수적인데 어떻게 기술을 접하고 있나요
• 국내에서 아키텍트가 되는 법
• 아키텍트는 코딩을 잘 해야 한다.
• 기획자로 일하는 것이 아키텍트로써의 도움이 되는가?
• 아키텍트가 되기 위해 지금 당장 해야하는 것이 있다면?

더 궁금한 것들이 있으면 아래에 댓글을 주시면 성심 성의껏 작성하겠습니다.

또한 김지영 이사님의 인맥으로 지앤선의 많은 저자들이 기다리고 있으니, 계속되는 Face2Face 이벤트도 기대해 주세요.

PLoP을 다닌지 5년만에 되었네요.  아시아 학회의 공동 의장이기도 하지만, 이로서 더 넓은 영향력을 얻게 되었습니다.

이제 좀더 패턴을 제대로 인식하고, 상위 레벨에서 이야기 나눌수 있도록 노력하겠습니다.   NHN NEXT의 교수로 자리를 옮긴 후 많은 지적 자유와 대외 활동이 보장되어 지고,  더구나 학생들에게 더 나은 경험과 가치관도 전달될수 있게 이야기를 나누어 보고자 합니다.

한발 한발 꿈에 가까워 지네요.  더 나은 지식 공유와 동반 성장을 위해 노력하겠습니다.  홧팅!

많은 분들에게 도움이 되길 바라구요.

슬라이드 쉐어에 공유를 해 놓았고,  pptx를 다운 받으실 수 있게 해 놓았습니다.

이번 발표에는 다음과  같은 내용을 다루었습니다

• 오픈소스의 역사및 현재 이야기
• 라이센스 변화에 따른 에셋으로써 오픈소스
• 안드로이드의 로그 문제 해결 – Logdog  구현 이야기  
• 오픈소스 엔진니어링 – Facebook Framework인  fHalo 구축 사례
• 오픈소스를 외부에 공개하기 

많은 분에게 도움이 되길 바라며, 재미난 오픈 소스 프로젝트로 조만간 찾아 뵙겠습니다.

• 시간: 2월 28일 수요일 오후 9시 부터 ~ 10시(?) 이구요 
• 준비물 : 마이크랑 화상 캠이 필요합니다. 
• 등록하는 곳 : 지앤선 이벤트 페이지  

이 행사는 위 책의 출판사인 지앤선에서 야심차게 준비하는 프로젝트입니다. 가능한 지방에 있는 분들과 좀더 소통을 하고, 추후 고등학생들과 같이 꿈나무들과 이야기를 나누는 채널도 만들어 보고자 합니다

지방에 있는 분들을 먼저 고려해서, 5분을 모셔서  이런 저런 이야기를 나누고자 해요.

특별히 주제가 딱 있는 것은 아니지만,  아래와 같은 이야기들을 서로 나누고자 합니다.

• 아키텍트로써 성장하기 위한 고민들이나,
• 제가 업게 TOP의  유명한 아키텍트들을 만나면서 얻었던 경험들, 
• 소프트웨어 아키텍트가 알아야 할 97가지에서 궁금하거나, 좀더 곱씹어보고자 하는 이야기들
• 아니면 난 아무것도 모르겠다.  개발자로써 이러한 고민이 있으니 어떻게 생각하냐 등.

지방에 있는 분이 먼저 우선 순위가 높으시나, 많은 참여 바랍니다.

어플리케이션 블록

어플리케이션 블록 이라는 것은? 기존 Framework들을 더 쉽게 잘 쓸수 있게 추상화 놓은 Block으로 보시면 됩니다.  .NET에서 Enterprise Library가,  Java진영에서는 Spring이 좋은 예 입니다.

어플리케이션 블록이라는 단어를 유행시킨 것이 Microsoft인데 Android 4.0부터 안드로이드 공식문서에서 “어플리케이션 블록”이라는 단어를 종종 쓰고 있습니다. 즉 Microsoft 출신의 개발자들이 많이 Google로 흡수되었다는 좋은 예이지요.

안드로이드는 이미 좋은 Framework입니다. 하지만 단편화나 UI쪽으로는 개발자를 골치아프게 하는 여러 이슈들이 많습니다. 이러한 문제를 해결하기 위해 무수한 오픈소스가 존재중이며, 알람몬, Sleep if you can 을 비롯해, 안드로이드  개발자들이 자주 사용하는 여러 오픈 소스들을 모아서 정리하고 Layer별로 분류후 아키텍처와 사용 방법을 정리해 공유한 자료입니다.  도움을 주신 알람몬 팀, 신재명, 진성주 님에게 감사를 드립니다.

발표자료

많은 참조 바라며, 12월 18일 삼성전자에 발표를 하러가면서 내용을 조금더 업데이트 했습니다.

이 중에 fhalo 와 logdog은 소프트웨어 마에스트로 과정을 통해 만든 오픈소스 에셋이며, fhalo는 해외에서 문의가 올 정도로 이제 조금씩 입소문이 나고 있는 오픈소스 입니다.  facebook 제어와 로깅 시스템으로 바로 쓰셔도 무난하게 쓰실 수 있으니, 많은 사용 부탁드립니다.

• Opening
  • 안드로이드와 오픈소스 그리고 폐쇄성
  • 안드로이드 어플리케이션 블록
• UI Block
  • ui biniding framework (MVVM)
  • android ui pattern
  • actionbar – sleep if you can
  • hybrid framework = cocos 2d + custom text view
• Network Block
  • marshaller (simple, gson)
  • marshaller + dispatcher (retrofit)
  • sns layer (fhalo)

• Commom Block
  • logging framework (microlog)
  • DI Framework (roboguice)
  • Lightweight DI Framework (dagger)
  • Sensing Framework (funf)
• Baas Block
  • user behavior analyze (localytics)
  • logging bass framework (logdog)
  • bass service (parse)
  • open source BaaS (usergrid stack)
• Ending
  • 정리및 아키텍처 문서 0.9 버젼 공개

또한 감사드릴 일은  slideshare에 공개한지 몇시간이 지나, hot on facebook에 올라가, facebook에서 활발하게 공유, 교환 되는 자료로 등재되었다는 것입니다. 여러분의 공유 감사드리며, 계속 좋은 자료를 발굴해 오픈소스 에셋들을 추가 확장 공유하도록 하겠습니다.  감사합니다.

12월 14일 소프트웨어 아키텍트 컨퍼런스에 발표를 합니다.

저를 포함해 알람몬의 개발을 지휘하는 CTO 강진석 님, 그리고 요즘 이슈가 되는 BaaS의 전문가 진성주 PD 님과 함께 80분간 재미난 이야기들을 전달해 드릴 겁니다.  저보다 훨씬 대단한 2분이랑 같이 해서 마음이 무겁네요. 재미난 쇼가 되어야 할거 같아요.

주제는 Android OpenSource Application Block  입니다.  안드로이드 개발시 필요한 여러 에셋들을 소개하는 세션이 될거 같습니다. 슬라이드 쉐어에서 많은 트래픽을 받았던  안드로이드를 개발자를 위한 오픈소스 이야기 보다 더 풍성한 내용으로 설명을 드릴겁니다.

상세한 주제는 아래와 같습니다.

• Opening
  • 안드로이드와 오픈소스 그리고 폐쇄성 손영수
  • 안드로이드 어플리케이션 블록 손영수
• UI Block
  • ui biniding framework (MVVM) 손영수
  • android ui pattern 손영수
  • actionbar – sleep if you can 손영수 강진석 (Sleep if you can)
  • hybrid framework = cocos 2d + custom text view 손영수, 강진석
• Network Block
  • marshaller (simple, gson) 진성주
  • marshaller + dispatcher (retrofit) 진성주
  • sns layer (fhalo) 손영수

• Commom Block
  • logging framework (microlog) 손영수,강진석
  • DI Framework (roboguice) 진성주
  • Lightweight DI Framework (dagger) 진성주
• Baas Block
  • user behavior analyze (localytics) 손영수
  • logging bass framework (logdog) 손영수
  • bass service (parse) 진성주
  • open source BaaS (usergrid stack) 진성주
• Ending
  • 정리및 아키텍처 문서 0.9 버젼 공개  손영수

많은 분들에게 도움이 되는 세미나가 될수 있게 준비해보겠습니다. 12월 14일날 뵈요.

만난지 2년 만이였어요. SPLASH와  Agile 컨퍼런스가 겹치면서, PLoP에 못 나오셨거든요. 정말 반가웠습니다.  하루 내내 우리 나라의 문화를 알기위해서 창덕궁 , 전쟁 기념관 등을 돌아다니며, 관심있게 보셨구요.  특히 거북선에 관심을 보이셨답니다.

저녁에 NHN  그린 팩토리 앞 나루 라는 퓨전 레스토랑에서 인터뷰를 하며 저희 EVA 식구들의 궁금중을 푸는 시간을 가졌습니다.  여러분에게 어떠한 이야기가 오고 갔는지 전달해 드리고자 합니다.   사실 모임전에 저희끼리  Google Drive를 통해 저희들의 질문들을 모아 놓았고,  다양한 사람들의 의견을 물을 수 있도록 안배를 해, 각자 우선 순위 높은  자시만의 고민에 대해  물어 볼수 있었습니다

이 질문을 통해 책에서나 세미나에서 듣지 못했던 사람 Linda에 대해서 많은 것을 깨달을수 있었으며, 70세의 나이에도 불구하고 정말 철저한 자기 관리에 놀랐습니다. 특히 롤 모델이 없는 여성 개발자들에겐 Linda Rising이 좋은 롤 모델이 될거라고 믿습니다.

이 글 정리에 큰 도움을 주신 김동현님, 유성우님 에게 깊은 감사를 드립니다. 

인터뷰..

손영수 :  소프트웨어 컨설턴트로 일하시다가 특별히 사람에 관심을 가지게 되어 Fearless Change 서적을 집필한 이유가 있으신가요?

Linda: Chilli PLoP (아리조나 주에서 열림. 그해 핫 이슈가 되는 것들을 모아 나누는 PLoP) 에서 Mary Lynn Manns을 만났습니다. 거기서 이야기를 나누면서 만들게 되었습니다. 그리고 몇번의 PLoP으로 지식을 보강해 Fearless Change패턴을 만들었습니다.

제가 처음에(20년전) Pattern에 대해 공부하였을 때, S/W개발에 대한 수 많은 패턴들이 있었고, 그러한 Pattern들을 소개하기 위한 패턴을 만들기 시작하였습니다. 그렇게 해서 만든 패턴을 지도교수에게 보여주자 교수는 ‘당신들이 만든 패턴은 단지 패턴을 소개하기 위한 패턴이 아니다. 그것은 패턴을 넘어서 새로운 아이디어를 소개하는 패턴으로 보인다’ 라고 했습니다. 하지만 우리의 경험은

패턴밖에 없었기 때문에 처음에는 이를 거부했습니다. 그 후, 우리는 이 패턴을 다른 영역(애자일 프로세스의 도입 같은)에 적용해 보고서야, 새로운 Idea를 소개하는 것도 가능하다는 것을 깨닫게 되었습니다.

이러한 것을 깨닫고 나서부터 저는 Agile 을 시작하였고 결국 “패턴을 소개하기 위한 패턴에서 새로운 아이디어를 소개하는 패턴” 을 발표하게 되었습니다. 그것이 Fearless Change의 시작이었습니다.

Lidna : 여기서 제가 질문을 드리겠습니다.  Pattern을 소개하는 Pattern에서 새로운 Idea를 소개하는 Pattern으로 translating 하실 수 있습니까?

EVA팀 : 예 이미 몇 번 PLoP에 논문을 낸 경험도 있습니다.

Linda’: 실제로 translating 할 수 있는데 여기서 중요한 점은 Pattern은 같다는 것이고 다만 translating을 할때에 examine(검사)하고 확인해야 합니다. 저는 지금 이러한 것들을 통해서 세상을 구하기 위한(Saving the world) 책을 쓰고 있습니다.

박선욱 : 우리나라에서는 평등한 조직 구조가 힘들기 때문에 토론문화가 발전하기 힘듭니다. 그렇다면 회고 프랙티스가 바뀌어야 할 것 같은데, 어떻게 생각하시나요?

Linda: Agile이 처음 시작된 1900년대 중반에는 다양한 Agile process가 있었습니다. XP (kent beck), Scrum (Jim Copelin) 등이요.  그때에는 한국과 일본처럼, 서로 싸움을 많이 했습니다.  (인터뷰 전에 같이 용산 전쟁 기념관에 갔는데, 일본과 중국과의 전쟁을 너무 인상 깊게 보셔서 이 말씀을 하신거 같아요)

왜냐하면 너무나 가깝고 비슷하기 때문입니다. 그들 서로가 다른 점에 집중했습니다. XP에는 없는 Scrum 방법, Scrum에는 없는 XP 방법 같은 것들 말입니다. 1번에서 10번까지 Scrum에서 지켜야 할일(해야 할 프랙티스) List를 만들고 이러한 List를 Action처럼 정해서 따르지 않으면 Scrum이 아니다 이런 식으로 말이죠.

하지만 이 말은 틀립니다. 현재는 그들이 애자일 선언에 나온 가치를 추구하는데 더 좋은 방법이 다른 방법론에 있으면 훔쳐서라도 적용합니다. (훔치다라는 표현에 모두들 웃었다 – 질문자 첨) 예전에는 애자일 컨퍼런스에 CMM측(대표적인 경직된 방식:애자일의 반대)이 참가한다면, 무조건 반대했습니다. 이제는 달라요. 그들에게도 배울 점이 있기 때문에 환영합니다.

그에 따라서 현재에서는 모든 방법론들이(XP, Scrum, etc) 모두 같고(same) 끊임없이 변화하고 있어서 전체적인 구조는(Overall structure) 너무 유동적입니다(fulid).

박선욱: 동양과 서양의 문화가 다른데 거기에 따라서 Agile을 다르게 적용할 수 있을까요?

Linda: 모든 나라에서 Agile이 다르게 적용되고 있는데 여기에 대한 문제는 없는가? 라는 질문인데, 초기의 Agile은 Honeymoon stage(단점도 모두 장점으로 보이고 서로 너무 좋아하는 시기)이기 때문에 여러곳에서 심지어 적용하지 말아야 되는 곳에서도 적용이 되어서 많은 문제점들이 나타나고 있습니다. 왜냐하면 이제 Honeymoon stage가 아니라 Next step이기 때문입니다. 제 생각에 Agile은 지역 문화에 따라 달라져야 한다고 생각합니다.

실제로 Agile을 사용하는 것이 목표가 아니라 고객을 더욱 만족 시키는 것, 돈을 더 버는 것, 세상을 더 좋게 만드는 것, 이러한 것들이 실제의 목표 때문입니다. 이러한 목표를 성취하는데 Agile이 좋다면 Agile을 따르고 Waterfall이 좋다면 Waterfall을 따르면 됩니다.

애자일은 오늘보다 더 나은 내일을 .., 올해보다 더 나은 내년을 가져오면 됩니다.  애자일의 프랙티스는 그것을 하기 위한 방법 중 하나일 뿐입니다. 여러분의 상황에서 가장 나은 방법을 찾으면 됩니다. 그것이 애자일 프랙티스로 소개된 적이 있느냐 없는냐는 중요하지 않습니다. 그 프랙티스가 세상을 더 좋게 만들고, 더 나은 소프트웨어를 만들고, 여러분을 더 발전시킨다면 그것은 애자일 입니다.

고상원, 윤주환 : 기술의 변화가 빨라지면서 개발자들에게 학습을 강요하는 상황이 생기고 있습니다. 기술의 변화가 일시적인 트랜드에 그치는 경우도 많은데요. 선배 개발자로써 최신 기술에 대한 지속적인 학습이 개발자로서 삶을 유지하는데 매우 중요한 요소라고 보시나요?

Linda: Fortran으로 개발된 아주 오래된 S/W들도 아직까지 많은 분야에서 사용되고 있습니다. IBM에서는 여전히 RPG(Report Program Generator: wikipedia 참고요망)를 사용하고 PL1이나 펀치카드를 이용한 개발도 운영 중에 있습니다. 이러한 다양한 기술들은 수요가 있다면 가능한 한 오래 사용됩니다. 실제로 오래된 기술로 개발된 많은 프로그램들이 현재까지 계속 사용되고 있으며, 신기술로 개발된 굉장한 프로그램들의 비율은 상당히 적습니다.

신기술은 스타트업 같이 새로 시작하는 소규모 회사들이 많이 사용합니다. Dropbox는 클라우드 같은 아주 멋있는 기술을 사용하지만, 실제 지금 개발된 많은 프로그램들은 앞으로도 20~30년 계속 존재 할 것입니다. 신기술은 나도 기꺼이 배울 용의가 있지만, 배우지 않는다고 하더라도 저는 신경쓰지 않을 것입니다. 왜냐하면 우리는 세상이 어떻게 변할지, 어떤 기술이 사라지고 어떤 기술이 나타날지 모르기 때문입니다.

제가 지금 말한 대답을 20년 전의 제가 들었다면, 여러분이 제 질문에 제가 이야기드린 것처럼 대답하셨다면, 저는 아마 여러분을 믿지 않았을 것입니다. 그때의 저는 S/W개발자였기 때문이고 지금의 저 처럼 그때는 어떻게 Brain storming을 하고 사회가 어떻게 변하고 조직이 어떻게 변화하는지에 대해서 생각하지 않았기 때문입니다. 절대로 인생을 사는데 있어서 사람들이 말하는 리스트에 적혀진 것들을 통해서(실천하면서) 배우지 마세요. 여러분이 진정하고 싶고 좋아하는 것을 하세요.

김민정 : 가장 힘들었던 순간이 있었나요? 어떻게 극복하셨나요?

Linda: 남편이 제일 중요한 조력자 입니다. 제가 박사과정 시험을 보았을 때 8개 대학에 모두 합격하였습니다. 저는 남편에게 대학들이 위치한 곳들 중에서 직장을 구해서 저를 도와 달라고 했고 실제로 남편은 저의 박사과정 학교와 같은 곳에서 직장 생활을 하였습니다.

살면서 정말 힘들었던 문제가 무엇인가에 대해 찾기 위해 고민해보았지만(Struggling) 찾을 수가 없네요.. 지금 이 질문을 듣고 생각해보니 아마 제 나이가 70살인게 가장 큰 문제가 아닐까요?

하지만 저는 여전히 하루에 100마일(160km)을 오토바이를 타고 다니고, 좋은 남편이 있고, 건강하고, 굉장한 사람들(여러분)을 만나며 전세계를 돌아 다니고 있습니다. 저는 기독교인이고 축복받았습니다.(I am blessed). 내일 당장 죽더라도 행복한 삶이었다고 말 할 수 있습니다.

얘기를 조금 더 추가해보면 제가 50살이었을 때 박사과정을 마쳤습니다. 무엇인가를 시작하려고 할 때 너무 늦었다, 늙었다, 어리다, 한국사람이다, 이런 것들을 생각하지 말고 제가 50살이었다는 것을 기억하고 저를 Role model삼아 열심히 사셨으면 좋겠습니다.

황선희 : 여러 컨퍼런스나 회사의 중역들을 보면 여성들이 거의 없습니다. 이런 우리나라 상황에서 여성으로서 개발자로서 성장할 수 있는 롤모델을 찾기란 여간 힘든 일이 아닙니다. 미국의 경우에는 어떤지 잘 모르겠습니다만, 린다 여사님이 처음 학위를 받으시고 이쪽 분야에서 일하실 무렵에는 여성들이 별로 없었을 것이라고 생각됩니다. 그런 상황에서 여성으로서 린다 여사님처럼 여성으로서 특정 분야의 전문가로 성장하기 위해 어떻게 하셨는지, 그리고 제가 앞으로 어떤 방향으로 나가야 할지 조언을 주셨으면 합니다.

Linda: 한국의 상황은 어떤가요? 여성들이 많이 이 업종에서 일하고 있나요?

황선희 : 네. 하지만, 회사의 고위 관리직이나이나 컨퍼런스 발표자 중에 여성은 거의 없습니다.

Linda:  정확한 한국의 문화를 모르지만, 미국에서도 COO, CTO에는 거의 여자가 없어요. 여자의 사회 진출, 관리자 레벨 비율, 승진 기회, 봉급의 액수는 남자들과 비교해 볼 때 상당히 낮습니다. 물론 동유럽 국가에서 이쪽 분야에 근무하고 있는 남녀 비율은 50:50입니다. 하지만 미국의 경우도 여자들은 별로 없습니다.

먼저 생각해 보셔야 할게 여자와 남자의 능력이 다르다고 생각하시나요?

모두들: …

Lidna: 여자는 남자와 똑같습니다. 둘은 똑같아요. (성별에 따라 실력이 결정되지 않는다는 내용을 강조하시는 듯이 똑같다는 말씀을 반복하셨다. – 질문자 첨)
여자도 똑같이 재능이 있으며 다 할 수 있어요. 하지만 여자들 스스로가 자신은 세컨 클래스라고 생각하고 있고 그 생각이 그것이 여러분들을 지배하고 있어요. 바로 그게 문제입니다.

관련된 연구 결과가 있는데 알려줄게요. 어떤 연구에서 2개의 피실험자 그룹이 있었죠. 모든 피실험자들의 성적은 비슷했고, 똑 같은 시험 문항을 똑 같은 환경에서 보게 했습니다. 단지 한 그룹의 시험지 맨 위에는 자신이 남성인지 여성인지 성별을 선택하는 질문이 포함되어 있었죠. 그것을 제외하고는 완전히 똑 같은 조건이었습니다. 하지만 결과는 달랐어요. 성별에 대한 질문지를 받은 그룹의 피실험자들은 자신이 그러한 질문을 받고 성별을 기입했다는 사실도 기억하지 못했지만, 그 질문에 답한 여성들의 시험점수는 같은 그룹의 남자들이나 또 다른 그룹의 여성들에 비해 현저히 낮았습니다. (질문자가 뭔가 깨달았기를 바라시면서 잠깐 말씀을 멈추셨다.-질문자 첨)

여기에서도 알 수 있듯이 마음속 깊은 곳에 박혀 있는 고정관념(stereo type)이 여러분(여성분)들의 발목을 잡고 있습니다. 남성과 여성은 다른 점이 없어요. 고정 관점이 문제인거죠. 여러분의 분야에서 성공하기 위해서 여러분이 가지고 있는 그러한 고정관념을 반드시 없애셔야 합니다.

나이가 많아서, 너무 젋어서, 여러분이 아시아인이라서.. 아닙니다.  저는 50살에 박사학위를 받았습니다. 이 분야에는 정말 똑똑한 사람들이 많죠. 그리고 70이 된 지금까지 여러 나라의 여러 사람들과 일하고 있고요. Linda가 할 수 있으면 나도 할 수 있다고 생각하세요. 만약 린다가 할 수 있으면 여러분도 할 수 있습니다.(질문자를 보면서 그리고 한 사람 한 사람 여성 참석자들을 둘러 보면서 진심 어린 표정을 지으며 말씀하셨다) 분명 제가 여러분의 롤모델이 될 수 있을 거에요.

만약 린다가 할 수 있다면 여러분도 할 수 있습니다.
만약 린다가 할 수 있다면…..

황선희: I can do it.    /  Linda: 맞아요. You can do it.

린다여사님의 대답이 끝나자 참석자 모두들 박수를 쳤다. 그 자리에 참석했던 4명의 여성 개발자들은 물론이고, 자신에게 주어진 개발자와 IT관련 분야의 포지션에서 성장을 위해 성실히 노력하는 EVA팀을 비롯한 그 자리에 모인 사람들은 그녀의 오랜 경험으로부터 나온 진심 어린 조언에 모두 감동하였다.

황선희 :
이후 나는 헤어지는 장소에서 잠깐의 대화를 나누었다. 린다 여사님은 나에게 “당신이 어떻게 성장할지 기대가 됩니다. 제게 잘 되어가고 있는지 메일을 보내주세요.” 라며 따뜻하게 격려의 말씀을 잊지 않으셨다.

진성주 :  매사 불평 불만을 많이 얘기하는 사람이 팀원인 경우, 팀의 분위기가 많이 어두워 집니다. 해당 사람이 팀에서 영향력이 있는 경우, Fearless Change 에서 나오는 패턴들을 사용하려고 해도 어려워 집니다. 해당 사람을 설득할 수 있는 권위자, 조력자의 도움을 외부에서 받을 수 없는 경우 어떤 식으로 변화를 만들어 내는게 좋을까요?

Linda: 팀원중 의 부정적인 사람도 있는데 그 사람을 변화 시키기 위해서는 먼저 그 사람과 좋은 관계를 맺고 잘 지내야 합니다. 예를 들어서 그 부정적인 사람과 커피를 마시면서 자신의 새로운 아이디어를 보여주면서 그 분의 생각을 물어보세요. 여기서 대화 할 때는 “당신이 틀렸어, 내가 옳아” 라는 논쟁을 하는 것이 아니라 상대방의 대답을 듣고(경청), 의견을 물어보세요. 이 것은 스티븐 코비의 “성공하는 사람의 7가지 습관”에서도 나온 것입니다. “Listen to agreement” 동의를 얻기 위해서 경청해야 합니다. 그의 의견을 존중하는 것이 중요하고 아마도 그는 자신의 그를 존경하는지 안 하는지 알고 있을 것입니다. 여러분이 아직 그를 존경하지 않는다면, 존경하는 마음이 생길 때까지, 대화를 미루어야 합니다. 식사를 하면서, 거부감을 무너뜨리고, 한번에 그사람을 다 바꿀려고 하지마라. 점진적으로 계단을 밟아가면서 서로를 이해하고, 생각을 공유하면 된다.

송지현 : 저희 팀에도 비슷한 분이 있는데 언제나 너무 부정적입니다. 가만히 있어도 얼굴 표정에 그런 것들이 나타납니다. 그분에게 한 번만 긍정적으로 생각하면 안되겠냐고 물어봤는데도 전혀 변화의 기미가 보이지 않는데 이러한 분은 어떻게 변화시킬 수 있을까요?

Linda: ‘Fearless change’의 한 부분에 ‘Champion skeptic’이 있습니다. 팀의 그런 부정적인 사람도 필요 합니다. 왜냐하면 위험 관리가 필요 하기 때문입니다. 그 사람을 통해서 팀의 문제, 부작용 등을 찾아 내야 하기 때문입니다. 그 사람을 회의적인 챔피언이 되게해서 여러분의 프로젝트에 문제점을 발견하도록 하세요. 꼭 그렇게 하셔야 합니다

김현종 : 어떤 변화를 시도하려 할때 사람들은 항상 두려움이 앞서게 됩니다. 변화를 이루는 과정속에서의 생기는 어떤 두려움이라 생각이 드는데요. 이를 극복 하기 위해서 어떠한 것들이 필요 한가요?

Linda: 변화하는 두려움을 극복하기 위해서는 작은 것부터 실천하는 것이 중요합니다. 혁명이나 큰 변화들은 대게 아주 작은 실천(변화)에서 시작되었습니다. 이러한 특징 때문에 Agile process에서도 매일 Standup meeting을 하는 것입니다. 5분의 시간 동안 어제 한 일, 오늘 할 일을 통해서 실천하는 것입니다. “All change begins with a small change”
또 이러한 것을 시작할 때 우리 뇌에 “나는 할 수 있다. 나는 안 두렵다.” 말해보세요. 이것은 ‘Just do it’ 패턴입니다. 책에서도 나와 있듯이 작은 것부터 실천해보세요.

사소한 것부터 변화를 시도하는 것이 중요합니다. 어제보다 나은 오늘이 되면 되고, 올해 보다 나은 내년이 되면 됩니다. 조금씩 점진적으로 더 나은 변화를 추구하세요.

양진욱 : 왜 책 제목을 ‘Fearless change’라고 하셨나요?

Linda: 처음 뉴욕에서 편집자 미팅을 했을 때 아무런 이름도 정해지지 않았어요. 편집자가 여러가지 책 제목을 내놓으며 한 가지를 뽑으라고 했죠. 책에 있는 여러가지 Pattern들 중에서 제일 중요한 Pattern을 책 제목으로 하고 싶었어요. 그래서 책 제목을 fearless change라고 하였습니다. 이 Pattern이 가장 중요하니까요.

맺음

Linda 여사와의 인터뷰가 끝난 후, EVA팀 개인 하나 하나 선배의 진솔한 가르침과 여운이 남았다.  개발자/ 아키텍트/ PM 이전에  우리는 사람이고, 오히려 사는 지혜를 들려 주었다고 생각이 들었다.   비록 자주 만날수 없지만, 명함을 나눠주시면서 궁금한게 있으면 얼마든지 질문을 하라고 하시니, 정말 든든한 선배를 얻은거 같다.  어서 Fearless Change를 출간 시켜야지.  그리고 계속 우리 EVA 식구는 한 걸음씩 전진해 나갈거다.   EVA 식구들의 환한 기념 사진과 함께 인터뷰를 마무리 하고자 합니다.

이번 인터뷰로 기뻐하는 EVA  식구들을 볼 때, 저 역시 정말 큰 힘이 나구요. 더 큰 성장이 눈앞에 있음을 확인했습니다.   저희는 정말 한마리 기러기가 되어서 멀리 날아갈겁니다.  멀리~~~