수요일, 5월 20, 2020

어떤 일이든 더 나은 방법이 있다는 믿음

개발자보다 관리자 역할을 더 중시하게 된지도 10년쯤 되었다. (그전 10년도 관리자였지만 미안 ㅠㅠ)

지적 노동의 관리자로서 가장 중시하는 것은 어떤 문제에 부닥치든 "어떤 일이든 더 나은 아이디어가 있다고 생각"하느냐이다.

직접적으로 사람과 조직의 생각들이 열려있냐를 보게 되고
막다른 골목에 다다라서도 더 현명한 접근법이 있을수 있다고 생각하여 사람들을 불러 조언을 구하고 토론을 하게 되고
개인의 아이디어보다 토론과 서칭 등을 통해 더 많은 아이디어를 구하게 되고
의사결정에서도 wicked problem의 룰을 따라 숙려의 시간에 따른 충분한 의사결정을 하고 실행 과정에서 다시 조정하는 것을 기본으로 삼게 된다.

물론 지적 노동이니만큼 아이디어를 낼수 있는 사람들의 성향도 중요하여 조직 운영도 의견을 내는 걸 어려워하지 않게 해야 하고 개인들이 생각을 많이 하도록 goal setting도 해야 하고 코칭도 필요하고 ...
그러다보니 개인들의 소통 능력을 가장 중시하고 ...
(물론 지적 노동의 특성 상 개인들의 능력도 중요하게 생각하지만 그것은 아이디어의 깊이와 횟수에 대한 확률이라고 생각하기 때문에 소통 능력이 떨어지면 다른 사람들을 이해시키지 못하고 또 일회성 아이디어를 다중의 조언을 통해 개선할 기회가 적기 때문에 소통 능력 다음으로 생각한다)
조직의 문화적 측면도 매우 중시한다. 목적을 중시하고 누구나 쉽게 의견을 제시하고 빠르게 오류를 인정하고 등등 하나의 의견이 더 나은 의사결정의 seed가 될 수 있도록 하는 데 신경을 많이 쓰는 편이다.
소통 능력이 떨어지는 친구들은 대부분 설득이 가능하다고 생각하는데 (업을 같이 하는 곳에서는 의도부터 나쁜 사람은 없다..) 굳이 안되는 사람들은 과감하게 배제해서 문화적 리스크를 줄인다. 

월요일, 10월 07, 2019

python 언어의 간결함

python을 사용하는 건 대부분 딥러닝을 포함한 분석 때문이긴 하지만 언어의 간결성 때문에 프로토타입 소프트웨어를 만들 때에도 매우 편리하다.
flask 웹 서버가 매우 확장성이 좋은데 template 지원 기능이 기존의 JSP, ASP와는 전혀 다른 방식으로 간편하다.
게다가 matplotlib으로 만든 차트를 웹에서 d3 기반으로 embed하는 것(mpld3)도 가능하다.
데이터 -> python -> 웹까지 쉽게 연결되는 셈이다.

최근 빅데이터 처리를 위해 JVM 기반인 Spark 위에서 python 프로세스를 fork/exec 시키는 PySpark를 왜 쓰나 분석해보기도 했는데 (데이터 전달과 serialize 오버헤드에도 불구하고) 역시 python이 갖고 있는 Java나 Scala가 주지 못하는 데이터 처리 능력 때문인 것 같다.
시스템적인 측면에서 보면 python을 웹 서버나 분산 미들웨어로 쓰는 건 매우 어리석은 일이라고 볼 수 있어서 (multithread 기반의 concurrency가 global interpreter lock 때문에 몹쓸 놈이 되기 때문) python 기반의 openstack을 toy 시스템 외에 production으로 쓰려는 건 바보같은 짓이라고 생각하는데
Google이 십여년 전에 Google AppEngine이라는 PaaS 서비스를 오픈하면서 python 언어로 먼저 제공하고 그 다음에 Java 언어를 지원했던 이유를 알 것 같다. (클라우드 서비스에서 스케일링은 미들웨어가 아닌 컨테이너와 같은 OS 가상화를 통해 지원하면 되니... process pooling을 사용하거나 중요한 백그라운드 잡을 c/c++로 개발했을 수도...)

JVM으로 python을 fork하는 PySpark도 어쨌든 시스템 미들웨어로서 python을 쓰는 것은 무리이지만 데이터 분석은 python으로 하고 싶은 요구사항에서 나온 거라고 생각된다.
데이터 오버헤드 관점에서는 정말 말이 안되는 것 같은데 그래도 이렇게 요구사항을 맞추다보니 여러 가지 아이디어가 붙어서 나름 PySpark도 오버헤드를 많이 줄이긴 했다. (RDD 개념의 데이터는 JVM 메모리 상에 있는데 python에서 user defined function으로 작성하여 실행하면 실제 데이터 연산은 컬럼 기반으로 메모리에 저장된 JVM 위의 RDD에서 컬럼별로 배치로 가져와 처리하도록 하는 기능이 강화되었다. 통신 오버헤드는 양적으로는 그대로이지만, 통신 횟수가 극적으로 줄어든다. 온라인 처리이면 어이없는 짓이지만 배치 처리이기 때문에 말이 된다. Apache Arrow 참고)

데이터를 다루는 일을 python만큼 범용적으로 잘하기는 쉽지 않을 것 같다. 그리고 시스템적인 측면은 취약하지만 규모가 작거나 배치적 성격이 강하다면 한계를 알고 비켜서 사용하면 많은 경우는 문제가 되지 않을 것이다.

Flask의 템플릿 기능은 정말 단순하면서도 python의 힘을 잘 보여주는 것 같다. (python을 사용하는 사람에게는 학습 비용이 매우 작다)
Flask를 micro-framework이라고 부르는데 Java에서도 Blade 같은 게 등장하긴 했다.

일요일, 4월 07, 2019

소프트웨어 엔지니어가 critical thinking을 학습하려면

젋은 친구들이 소프트웨어를 업으로 하고 기업에 입사하거나 창업에 도전하는 모습이 이제는 사회적으로도 상당히 기대를 받는 장면이 되었다.

그런데 지식 산업인 소프트웨어를 연구 개발하는 역할을 하기 위해 어떤 성장이 필요할까?

개인적으로 최근 몇년간 딥러닝 쪽 공부를 하면서 미국 대학 강의를 들을 기회가 많은데 대학 시절에 공부를 제대로 하지 않아서인지 상당히 인상적인 부분이 있었다.

아마 명강의란 그런 것이 아닌가 싶은데 지식의 전달 방식의 차이였다.
대부분의 책에서 찾아보기 힘든 교수님의 지식에 대한 직관(intuition) 혹은 관점에 대한 전달이었다.

수학적 증명을 하고 난 다음에 이것을 수식이 아니라 직관적으로는 어떻게 이해를 할 수 있느냐 하는 부분이 매우 중요한데 지식을 이해한다는 것이 어떤 솔루션이나 아이디어의 기반이 되는 지식으로 발전하기 위해서는 직관이 가능한 멘탈 이미지로 머리 속에 재정립시킬 필요가 있다.

  • 지식이 머리 속에서 살아 있는 직관 가능한 모델이 되어서 여러 가지 개념들과 느낌들이 무수히 연결되어야 한다.
  • 즉, 평소에도 친숙하게 느낄 정도로 쉬운 개념이거나 숙련으로 쉽게 연상할 수 있는 개념이 되어야 한다. 예를 들어 친숙한 ‘코끼리’라는 개념은 여러 가지 코와 귀, 몸무게, 여러 가지 코끼리의 특성에 대한 것들을 연결시켜준다.
  • 쉽게 직관할 수 있는 모델로서 이해하는 과정이 intuition 관점의 추가 이해라고 볼 수 있다.
  • 이 멘탈 이미지 혹은 개념적 요소로 인지하면 비로소 지식은 유연성을 얻어 이를 기반으로 다양한 유추가 가능해진다. 
소프트웨어를 기업 환경에서 다루는 사람이라면 소프트웨어에 맞는 생각하는 방법을 배워야 더 큰 소프트웨어를 다룰 수 있고, 또 깊이를 가질 수 있다.
창의적 사고의 중요한 요소라고 하는 critical thinking(임계적 사고)이나 system thinking(체계의 사고)은 특정 지식 혹은 영역에서 임계적 요소를 식별하고 이를 좀더 깊이있게 사고할 수 있는 능력이라고 할 수 있다.

그런데 critical thinking, system thinking의 방법은 지식 분야별로 도메인별로 크게 형태가 다를 수 있다.
여기에서 정말 중요한 학습이 필요하다.

앞에서 대학 강의를 얘기했었는데 이러한 임계적 사고가 대학 교수님들의 명강의를 통해서도 어느 정도 체득이 가능하다고 본다.
하지만, 기업에는 같이 문제를 해결하고자 하는 여러 뛰어난 동료들이 있을 수 있다.
이들이 문제를 바라보는 시각, critical path에 대한 판단법, 시스템을 바라보는 사고 체계 등을 옆에서 지켜볼 수 있다면 금방 자기의 것으로 소화할 수 있다.
개별 지식 자체가 아니라 사고의 방식, 도메인을 접하는 시스템에 대한 개념 모델을 엿볼 수 있다.
이러한 시스템적 사고의 방법을 배울 수 있는 동료나 선배가 있는 곳이 좋은 성장의 장소가 된다.
물론 이들과 오픈으로 토론하고 문제를 함께 찾아갈 수 있는 문화가 뒷받침되어야 한다.

개별 지식에 대한 학습은 혼자서 꾸준히 하면 되는 것이지만, 판단의 수준을 높이는 것은 혼자 학습만 해서 이루긴 어렵다.
생각하는 방법의 차이를 주의깊게 보고 이를 자기의 것으로 소화하려는 노력이 진정한 큰 성장을 가져온다.

주변에 배울 사람이 없는 환경이라면 끊임없이 생각을 정리하고 체계화하여 intuition으로 발전시키는 노력을 기울일 필요가 있다. 물론 주변에 배울 사람이 있을 경우에도 먼저 개인의 intuition을 정리하고 이를 오픈하여 개인의 편향이나 오류를 검증할 필요가 있다.

추천한다면 주변의 개념을 넓혀 도움을 주거나 나눌 사람을 기업내외를 막론하고 주기적으로 함께 지식 이해의 수준을 높여갈 수 있도록 찾을 필요가 있다.
배울만한 멤버와 오픈된 토론 문화를 가진 스터디 그룹을 찾아 참석하는 것도 좋은 방법이다. (그런 스터디 그룹이 많지는 않을 것이다.)

지식 기업들에게는 개개인의 학습 능력과 성장이 무엇보다 기업의 잠재력이 되기 때문에 이러한 성장을 매우 중시한다.
유감스럽게도 우리나라 IT 기업들의 수준은 개인의 역량 측면에서나 개인의 역량을 결과물로 총합해내는 측면에서나 그렇게 뛰어난 편이 못된다.

그렇기 때문에 기업의 성장은 외부로부터 우수한 인재를 영입을 하는 것으로 해결하기가 어렵다. 기업 구성원의 성장과 기술적으로 더 나은 솔루션을 의사결정할 수 있는 문화를 만들어가야 한다.

개인의 Career path도 자신의 기술적 성장에 베팅하는 것이 미래에 가장 효과적인 자산이 될 수 있을 것이다.

월요일, 3월 25, 2019

아이디어는 가장자리에서 발생한다



그림의 중심과 에지 사이의 거리는 복잡성의 정도를 표현한 것이다.
아이디어는 항상 복잡한 영역에서 발생하지 않지만, 현재 지식 수준의 경계에서 발생한다.
따라서, 거듭된 사고를 끝까지 한다면 누구나 새로운 아이디어를 만들 수 있다.

토요일, 3월 09, 2019

기술 조직의 매니저는 얼마나 많이 필요할까

기술 조직에서 매니저는 얼마나 많이 필요할까.
관리 편의를 위해 일찍 매니저가 된 친구들은 스스로 기술 개발을 하지 못하고 관리와 다른 팀원들의 연구 결과를 간접적으로 이해하고 판단하는 업무를 할수밖에 없는데 지식 체계의 기반이 부족해지고 스스로 연구할 수 있는 능력을 잃게 마련이다.
물론 관리도 재능이 필요한 영역이긴 하지만 상대적으로 단기간에 학습할 수 있는 영역이다.
연구 전문성에 대한 코칭이나 리딩은 금새 학습할 수 있는 게 아니어서 결국 다른 상위 관리자의 의사결정에 기대게 되기도 한다. 
너무 이른 매니저 역할은 전문가로 성장할 기회를 잃기 쉽다는 뜻이다.
기술직을 시작한지 1,2년만에 팀장이 되면 준비없이 관리와 기술 의사결정에 관여하게 된다. 결국 형식적인 패턴에만 익숙해질 가능성이 높다.
이십년 가까이 IT 업종에서 일을 하고 매니저 역할만 했던 이가 얘기를 해보면 전혀 생각의 깊이가 없는 경우를 볼 때가 가끔 있다. 외부에서 보기엔 훌륭하고 성실한 매니저로 비춰지기도 하지만 실제로는 전혀 무언가를 스스로 이해하고 판단하는 환경에 있지 못했던 것이다.
그냥 패턴적으로 조건반사하듯 의사결정을 반복하고 기술적 피드백을 이해하지도 못하는 모습은 웃프다. 
한국은 위계적 문화 때문에 위계 상의 윗 사람이 진정으로 뭘 학습하기가 쉽지 않다. 개인적 성실성으로 한다고 해도 비평해줄 사람이 거의 없다.
깊이있는 의사결정을 할수 있는 오픈된 토론 회의 문화도 큰 역할을 하겠지만 너무 일찍 매니저들을 만들기보다는 관리를 자율 책임에 많은 영역을 넘기고 매니저를 줄이는 방식이 유의미하다고 생각한다.
이런 경우 의사결정자의 윗쪽으로 갈수록 조금 더 큰 인내심을 필요로 할수 있다.
Bottom-up이 활성화되면 top-down은 이해시키는 비용을 포함해야 한다.
위계의 계층을 줄일 수 있는 자율 단위 규모가 최대 100명 남짓이라면 그 정도 안에서 대부분의 크리티컬한 의사결정이 이루어질 필요가 있는 셈이다.
(젊은 친구들이 어쩔수없이 매니저를 맡아야 한다면 너무 오래지 않은 시점에 다른 친구에게 넘기고 기반을 다시 다지는 기간을 갖는 것도 방법일 것 같다.
경력자를 수혈해서 바로 매니저 역할을 맡기는 것은 문화 융합 문제와 자질 등이 우려되므로 일정 기간 유보하는 룰을 만드는 것도 좋을 듯하다.)
물론 기술 조직의 경계와 의사결정 구조에 대한 얘기이다. 성격이 많이 다른 프로젝트성이나 경영 의사결정은 조직의 대표성을 가진 이들과 프로젝트에 직접 관여하는 핵심 당사자들로 구성하는 게 맞겠지만..

토요일, 3월 02, 2019

왜 ‘최고’ 인재들이 창의력 없는 결과를 내놓을까

원 글 : Why hiring the ‘best’ people produces the least creative results
관련 도서 : The Diversity Bonus How Great Teams Pay Off in the Knowledge Economy

창의적인 팀웍을 만들려면 어떻게 해야 할까
나름 재미있는 관점을 제공해주는 글이 있어 소개한다.
한글로 번역한 글을 읽었는데 원 글에 나오는 통계학적 기법이나 마르코프 프로세스를 이해못해서 핵심을 잘못 전달했기에 원 글을 읽어보길 추천한다.

글은 수학 전공한 교수님이 논리학 수업 시간에 교통 체증을 컴퓨터로 모델링하는 방법에 대해 설명하는 것으로 시작한다.
교통 체증 상태의 차량의 흐름을 추적하는 건 엄청난 메모리와 연산량을 필요로 하게 된다.
교수님은 이런 경우엔 빈 도로를 추적하면 된다고 아이디어를 제시한다. 교통 체증 상황에서 빈 도로의 흐름을 추적하도록 모델을 만드는 아이디어이다.

이러한 아이디어 이야기들은 몇 가지 공통점이 있다.
1.  복잡한 문제이다. 차원이 높은 문맥을 다루기 때문에 설명하기도, 엔지니어링하기도, 개선하거나 예측하기도 까다롭다.

2.  획기적인 아이디어는 마법처럼 떠오르거나 완전히 새롭게 만들어지지 않는다.
기존의 아이디어, 직관, 기교나 룰에서 출발하며 이것들을 참신하게 적용을 한 것이거나 결합한 것이다.
앞의 교통 체증 사례는 정보 이론의 최소 서술 길이minimum description length 즉, 같은 정보를 가장 짧게 기술하는 기법 개념을 참신하게 적용한 사례라고 볼수 있다.
이러한 아이디어들은 조금의 이득을 가져온다. 하지만 이런 아이디어들이 모이게 되면 커다란 반향을 가져올 수가 있다. 진보는 거대한 도약 만큼이나 작은 걸음들의 누적을 통해서도 크게 이루어진다.

3. 이런 아이디어들은 그룹 환경에서 태어난다.
한 사람이 어떤 문제에 대해 자신의 관점을 얘기하고 해결에 대한 접근법을 설명하거나 해결에 집중하고 있는 부분을 명확히 하면 다른 사람이 의견을 주거나 알고 회피법을 알려주는 식이다.
작고한 존 홀랜드는 늘 다음과 같이 물었다. “마르코프 프로세스로 바꿔서 생각해보았나요? 관련된 여러 개의 상태와 그 상태들간의 전이 경로를 식별해서 생각해보았나요? ” 이러한 질문은 발표자가 문제에 관련된 상태를 정의하도록 강제한다. 이 단순한 행위가 곧잘 어떤 직관으로 이어지기도 한다.

현대 문제들의 복잡성은 종종 개인이 모든 문제를 충분히 잘 이해할 수가 없도록 한다.
복잡한 문제들의 다차원성과 중층성은 실력주의 즉, 최고의 인재를 채용해야 한다는 생각의 근거를 약화시키는 경향이 있다.
최고의 실력자는 없는 것이다. 여러 면에서 최고의 점수를 받은 사람을 뽑는 게 아니라 다양성을 추구하게 된다. 다양한 지식 기반, 도구, 분석 기술을 가진 일련의 사람들을 팀으로 구축하게 된다.
종종 수학자를 포함할 것이며 그 수학자들은 미분 방정식 뿐만 아니라 동적 시스템을 공부했을 것이다.
이렇게 팀은 ‘최고’의 수학자, ‘최고’의 종양학자, ‘최고’의 통계학자 등을 인재 풀에서 선택한 사람들로 구성될 것이다.

이러한 다양성에 대한 주장의 증거는 다양한 아이디어를 결합하는 것이 더 나은 결과를 만드는 경향이 있다는 여러 논문들과 특허 등에서 확인된다.

랜덤 포레스트에서 활용하고 있는 기법인 boostrap aggregation 즉, bagging 기법에서 다양성의 유용성은 확인될 수 있다.
(Bagging은 분산을 감소시키는 앙상블 기법이며 결과적으로 여러 개로 나뉘어진 트레이닝 셋을 통해서 각각 만들어진 결과들의 평균이나 투표를 통해 최종 결과물을 내는데 일반적으로 분산이 줄어들고 accuracy가 좋아지게 된다. 부트스트랩은 외부에 의존하지 않고 자신의 힘으로 여러 단계를 거쳐 무언가를 이루는 과정을 뜻하는 표현인데 통계적으로는 동일한 데이터 셋을 여러 개의 데이터 셋으로 나눠서 샘플링하는 방법을 뜻한다. 즉, 동일한 데이터 셋 중 일부를 무작위로 샘플링해서 교체하는 방식으로 여러 벌의 데이터 셋을 만드는 기법이다.)
또다른 앙상블 기법인 boost 기법은 가장 어려운 부분에 집중해서 (boost는 여러 학습자들 중 정확도가 가장 낮은 학습자들의 비중을 높여 학습시키는 방법) 학습하여 결과적으로 더 많은 다양성을 거치면서 정확도가 높아지게 한다.

단순히 공통된 기준에 따른 고득점자를 채용하는 방식은 다양성이 아니라 동질성을 높이는 방식이다.
알파벳 자회사인 X의 CEO인 아스트로 텔러는 다음과 같이 말한다.

“중요한 건 서로 다른 지적 관점을 가진 사람들을 보유하는 것입니다. 지금까지 탐험해보지 못한 영역을 탐험하고자 한다면 자신과 닮고 자신과 비슷하게 사고하는 사람을 뽑는 것은 최선의 방법이 아닙니다.”

글쓴이는 다양성이 팀웍의 핵심이라고 생각하고 다양한 전문가를 채용하고 이를 팀웍을 통해 부트스트랩이나 부스팅 등 협업적(앙상블)으로 아이디어를 만들어내는 팀을 구성하는이 최선이라고 얘기하고 있다.

그룹 창의성의 가능성을 보여주는 적절한 비유라고 생각된다.
서로 협업하고 의사 소통할 수 있으며 아이디어를 만들어낼 수 있는 문화, 그 기반은 다양한 아이디어를 만들고 의견을 제시하는 학습하는 개인들이기도 하다.

토요일, 2월 16, 2019

창의성을 발현시키려면

아이디어의 시대이다. 모든 기술은 학습과 아이디어를 통해 유지되고 발전한다.
하지만 특별한 우연이 창의를 만드는 건 아니다.

나는 창의성은 ‘끝까지 생각’하는 여정에서 ‘단속적으로 생각을 많이’ 하는 데서 나온다고 생각한다.
수없이 거듭되는 문제 재인지, 심화 속 어느 순간에 Aha의 찰나가 숨어있다.

적절한 문제 정의는 솔루션을 유추하게 해주는데 ‘끝까지’는 수많은 단계iteration를 의연하게 거쳐갈 수 있어야 하며 ‘단속적’이라는 뜻은 생각의 속도 조절이 도움이 된다는 뜻이다.
물론 이 속도 조절에는 생각의 방향을 역방향으로 틀어 다시 문제의 재정의로 회귀하는 걸 포함한다.
방향 전환은 속도를 떨어뜨리지만 목표 지점을 다시 찾게 하고 더 나은 길을 찾을 수 있게 해준다.

많은 생각을 끊임없이 완급과 방향을 조절하며 엄밀한 문제 해결의 지점으로 찾아가는 과정은 무작위적인 과정이 아니다.
무작위적인 과정은 평범한 관행적 사고에 머물게 한다.
끝까지 검증하고 경계를 밀어붙이는 엄밀성이 창의를 만든다.
마치 aha 현상이 무작위적 사고인 것처럼 보이지만 뇌의 다양한 사고 패턴들이 무의식적으로 동작하는 것일뿐 그 패턴 관점에서는 개인별 특성을 가질 수 있다.
그 특성은 물론 유전과 학습을 통해 갖춰지며 변화해간다.

즉, 개인별 타고난 특성과 엄밀한 아이디어 경험들이 창의적 사람을 만든다고 봐야 한다.

Nothing mystic.