커뮤니케이션 : 인간과 인간이 서로의 의사나 감정, 생각을 주고 받는 수단.

미국인과 한국인은 왜 의사, 감정, 생각이 전달되기 힘든가. (얕은 수준에서 말구요)

바디랭귀지를 포함한 대부분의 언어가 다르기 때문입니다.

한국 사람끼리는 언어가 잘 소통되는가?

병원 갔는데, 의사가 전문 용어로 쏼라 쏼라 하면 못 알아 먹습니다. 언어는 전문 영역이 다르다.

이게 부서간에도 똑 같습니다. 전문 용어가 판이하죠. 표현하는 법 또한 다릅니다. 공대생과 미대생이 표현하는 법이 다르듯이요.

누구와의 커뮤니케이션인가가 중요합니다.

당연히 커뮤니케이션을 하려면, 상대방의 언어를 이해해야 합니다.

누구든 간에, 팀내 커뮤니케이션이란 팀원의 언어를 이해해야 하고, 부서간의 커뮤니케이션이라면 부서 전체의 언어를 이해해야 합니다.

그러니 당연히 올라갈 수록 엄청 노력해야 하고, 똑똑해야죠. 타 부서간의 예절도 매우 중요해지고.

* 적당히라는 말은, 수준이 깊을 수록 대화가 쉽습니다.

영어를 슬랭까지 이해하면 설명으로 할 껄 한방에 끝내잖아요. 쉽다는 뜻. 다 하기는 역시나 매우 어렵습니다.

관리자가 기술에 대해 많이 알면 알 수록 도움이 된다고 생각합니다. 그렇지만 현실적으로 실제 개발자보다 많이 알기란 불가능에 가깝습니다. 따라서 관리자가 기술을 최대한 많이 알되, 기술자를 신뢰하며 커뮤니케이션하여 기술자가 올바른 방향을 잡을 수 있도록 진행하는 것이 중요하다고 생각합니다.

기술 자체는 어려울 것이 없습니다. 일견 새로워 보이더라도 결국 과거의 것을 다르게 적용한 것일 뿐이기 때문에 기술자에게 현재 진행중인 프로젝트에 대해 상세히 물어보고 상세히 설명하도록 요구한다면 그 기술의 큰 맥을 잡을 수 있습니다.

기술의 논리를 잡았다면, 그 논리에 기반하여 현재 진행 방향이 올바른지, 하려는 일이 이 기술로 적합한지에 대해 기술자와 토론합니다. 그러다 보면 올바른 방향을 잡을 수 있을 것이라 생각합니다. 물론 이 과정에는 많은 기력이 소모되기 때문에, 회의 자체도 정기적으로 정해진 시간에 어떠한 내용을 논의할 것인지 사전에 정해둔 후 진행하는게 좋다고 생각합니다. 무작위적 회의는 회의로서의 가치도 없다고 생각합니다.

관리자가 기술을 모른다면, 기술을 이해하기 전 까지는 큰 진행 방향은 잡더라도 세부적 진행 방향은 잡지 않는 것이 좋습니다. 관리자가 기술자 만큼 해당 목표 도달을 위해 적합한 기술을 잘 알기 어렵기 때문입니다. 제안은 할 수 있더라도 그 방향을 고집하지 않는 것이 좋은 것 같습니다. 본문에 나온 하둡을 예로 들면, 하둡은 연산처리에 오랜 시간이 소모되는 것이 큰 특징입니다. 모처의 부서 결과물을 보니 입력 데이터를 대단히 빨리 처리하여 대응해야 하는 곳에 하둡을 사용했더군요. 입력데이터가 주어진 시점부터 결과가 나오기까지 어느정도 걸리냐 물었더니 24~40시간 걸린다고 합니다. 결국 뭐 다 엎었겠죠.. 분명 그 팀은 어디선가 문제가 있었던겁니다. 책임은 관리자가 지게 되는데, 관리자의 책임도 클테고요. 관리자가 하둡이 좋아서 하둡으로 하라 했을 수도 있고, 기술자가 하둡의 특성을 몰라서 하둡으로 하면 될것이다고 했을 수도 있을테고, 결국 무언가 문제가 있어서 그런 결과가 나온 것일텝니다.

하둡 사례와 같이, 기술의 개념만 봤을때는 관리자가 생각하기엔 무척 좋은 기술로 보이더라도, 이 기술의 특성을 자세히 아는 기술자가 실제로 이 기술이 목표달성에 도움이 되는지 알 수 있습니다. 관리자는 큰 방향을 제시하고, 기술자가 세부적인 목표를 정하며, 관리자는 목표 설정시 많은 대화를 통해 정말 올바른 방향인지 크로스체크하는 것이 중요하다 생각합니다. 알아서 잘 하는 기술자도 있습니다만..

아무튼 이러기 위해서는 관리자도 중요하지만, 기술자도 중요합니다. 기술자가 무엇보다도 잘 알거나 부지런해야 합니다. 해당 기술을 잘 알아야 세부방향을 잘 정할 수 있기도 하거니와, 결국 관리자는 그 기술자로부터 기술의 세부내용을 알게 됩니다. 관리자가 따로 기술에 대해 공부한다 하더라도 그 기술을 실제로 적용하는 기술자만큼 자세히 알기란 어려우니까요. 그러면 좋은 기술자를 뽑거나 길러야하는데, 아 너무 말이 길어지는군요.

이건 원론적인 부분의 문제라고 생각해요. 관리자가 실무를 알아야 하는게 아니라, 그 이전에 관리자가 몇명이냐는거죠. 만일 관리자가 1명이라면, 그 관리자가 실무를 모르면 절대 안되구요. (효율성 면에서 반 이하로 떨어집니다.) 관리자가 2명 이상이라면, 1명이 실무를 알면 될테구요. 즉, 실무를 아는 관리자 레벨이 1명 이상 필요하다는거죠.

지금은 해색주님이 그 실무를 아는 (적어도 그 속내를 이해하는) 관리자 역할을 하고 계신거 같아요. 만일 해색주님마저 실무에 대한 관심을 끊어버리시면, 해색주님을 대신할 누군가가 필요할테구요. 그 인원이 충원되지 않으면, 효율은 반으로 떨어질테고 실무자들은 "안된다 안된다"를 끊임없이 반복하게 되요.

근데 하둡, R 등등 소위 컨셉이 다른 플랫폼들은, 하려고 하는게 아니라 어쩌다 보니 하고 있는 것이라... 프로그래밍 언어도 오래 하다보면 mother language라는게 생긴다는 사실을 깨닫게 되요. ㅎㅎㅎ

뭐.. 근데 우리가 여기에서 줄곧 떠들어봤자 그 분이 관심을 가질만한 의견이 없을거 같아요. 우리가 누군지도 모르시는데...

전 이런 경우 무조건 소위 이름이 거창하게 알려진 전문가가 쓴 책이나 블로그 글 중에 제 의견과 비슷한걸 찾아서 제시하곤 합니다. 훨씬 공신력이 있는 글이니깐요. 물론, 가끔 상대방은 피터 드러커를 꼭 가지고 나와서 응대하는 경우가 있지만요... 전 피터 드러커가 제일 싫어요!!! 솔직히 이 사람 말은 귀에 붙히면 귀걸이고 코에 붙히면 코걸이란 말이지요...

제 생각엔 그분의 말도 어느정도 일리가 있는 말이고,

해색주님의 말도 서로 맞는 말입니다.

다만 그 팀장님 말에 전제가 되어야 할것은 기술적 지원을 해줄 전산팀이 

그 기술과 관련된 모든 회의에서 서포트 해줘야 할겁니다.

왜냐하면 전반적으로 그 기술에 대해서 알고는 있겠지만,

디테일한 기술적인 이해는 빈틈이 많기 때문입니다.

아주 작은 고려사항이 기획에 따라 큰문제가 될수도 있고,

이 기술보다는 다른 기술이 더 적합할수도 있겠죠.

상황에 따라서는 더 좋은 솔루션을 제시해 줄수도 있을겁니다.

그런 부분이 정말 서포트 될수 있는 환경인지 고려해야 합니다.

그게 아니라면 그런 부분에 대한 이해가 필수적인 기획이나 정책 결정 이전에 기술에 대한 이해를 선행해야 겠죠.

어떤 기술들이 있고, 그 기술의 크리티컬한 단점, 현재의 상황에서 운용에 드는 비용, 현재의 문제를 제한 시간내에 처리 가능한가 등도 고려 해야 됩니다.

만일 기술팀에서 그런 기술 지원을 해줄수 있는 환경이라면 기본적인것만 습득하신뒤에.

팀장님 말대로 돈을 버시는 쪽에 집중하시는게 좋을겁니다. 그게 효율이 훨씬 좋으니까요.

기술에 대한 디테일한 사항은 일을 진행하시면서 기술진과의 논의로 습득하시게 될겁니다.

적어도 전문지식은 아니더라도 전반적인 모든일에 대해서 기본이상은 해야 하지 않을까요? 

1. 하둡+R로 할 수 있는 일이 무엇인가? 어떤 것을 어느 수준까지 분석할 수 있는가?

2. 그렇다면 이걸로 무엇을 할 수 있는가? 

   새로운 상품/서비스로 만들어서 내다 팔 수 있는가?

   내부 업무 효율 제고 또는 임직원에게 정보 제공을 통해 사업 기회를 확대하거나, 업무 효율을 높일 수 있는가?

3. 있다면... Let's do it!

==> 팀장님 말씀이나 해색주님 말씀이나 같은 말을 다르게 표현한 걸로 보입니다.

며칠 전에 영문 이력서를 업데이트했는데 매니저 관련 항목에 적은 말은 일에 대해서는 short leash 라고 적었습니다.

short leash 하려면 잘 알아야 한다고 생각합니다.

컴퓨터분야만 놓고 보자면 나의 과거 실무 경험 기술이 닷넷이었기 때문에 닷넷에 특화된 정규식만 아는 것은 괜찮지만.. 자바에서는 정규식 표현이 조금 다를 수 있고 그 때문에 어떤 일들이 가끔 실수하더라. 정도는 경험과 지식으로 대략적으로는 알고 있어야 한다고 생각합니다. 통계도 마찬가지겠지요. SPSS 만 죽어라 했다 하더라도 SPSS 에서 자동으로 처리해주기도 하던 통계처리에 대한 기본을 알면 Matlab이든 R이든 하든 실무자의 일을 이해할 수 있는 것이고...

전산팀에서 해주는 것을 아예 모르면 전산팀의 고객인 사용자 입장에서 제대로 전산팀을 콘트롤하지 못 합니다.

상대방을 잘 다루면서 일 하는 게 일 잘 하는 사람이고.. 타 팀의 서비스가 제대로 안 이루어지는 것(=경쟁력이 없다는 것을 지적하는 것 포함해서..)을 하지 못 하면 회사를 점점 도태시키는 바보같은 매니저겠지요. ^^;; 그저 세미나 다닌다고 일 잘하는 사람은 없습니다.