원격근무 개발자의 자기관리 - 우리는 모두 원격근무자다!

.

상대적이면서도 절대적인 개인취향이 반영된 어떤 개발자의 맥 환경

https://github.com/doortts/env-of-mac

.

개발자의 의사소통 능력

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20160718075808

개발자의 의사소통 능력은 코딩실력보다 중요하다. 이미 여러 번 했던 이야기다.'개발자의 생명은 커뮤니케이션'이라는 칼럼에서 개발자의 의사소통이 정확히 무엇을 의미하는지도 설명했다. 이번 글은 그 내용의 확장판이다. 개발자가 좋은 의사소통을 하기 위해서 기억해야 하는 내용을 설명한다.

​

1. 어머니에게 말한다고 생각하라

개발자 10명 중에서 8명은 상대가 말을 들을 준비가 되었는지 헤아릴 줄 모른다. 자기 머리 속에 있는 생각을 상대방이 똑같이 하고 있을 거라고 착각한다. 자기 흥에 겨워 이야기하지만 듣는 사람에게는 의미없는 소음에 불과하다. 본론을 꺼내기 전에 반드시 기본적인 문맥과 개념을 설명하고, 상대가 이야기를 들을 준비가 되었는지 살피면서 자세한 이야기로 넘어가는 것이 커뮤니케이션의 기본이다.

​

상황이나 상대방에 따라 이야기의 형식과 내용을 달리하며 적절하게 말 할 수 있는 능력을 키우려면 자신의 이야기를 듣는 상대가 어머니라고 생각하면 좋다. 어머니에게 새로 작성한 코드의 내용이나 머릿속에 그득한 생각을 (기본적인 문맥과 개념에 대한 설명없이) 묘사할 수 있겠는가? 그렇게 하면 어머니는 그대의 등짝을 때릴 것이다. 듣는 사람을 부드럽게 자신이 원하는 대화의 문맥 속으로 끌어들이는 능력. 그것이 커뮤니케이션 능력의 핵심이다.

​

2. 구현과 인터페이스, 구체와 추상, 디테일과 개념을 분리하라

초, 중급 개발자는 종종 디테일의 늪에 빠진다. 자기 코드가 성취한 내용을 드러내고 싶은 욕망이 들끓기 때문에 누가 말을 걸면 준비과정 없이 디테일로 다이빙을 한다. 개념과 추상을 이용해서 대화하는 법을 익히지 못했기 때문에 자세한 구현(implementation)을 이용해서 말하고 설명한다. 디테일의 미로에 갇혀 헤매다 정작 해야할 말은 못하고 대화가 끝나는 경우가 많다. 고급 개발자로 발돋움 하기 위해서는 반드시 개념과 추상으로 말하는 법을 익혀야 한다.

​

3. 자기방어는 독약이다

개발자 10명 중에서 2~3명 정도가 이런 습관을 가지고 있다. 말을 걸면 무조건 자기방어를 한다. 질문의 의도와 아무 상관이 없다. 내가 질문한 목적은 프로젝트 관리 차원에서 궁금해서, 혹은 문제가 있으면 도와주고 싶어서 질문을 한 것인데, 필요한 대답은 하지 않고 자기에게 방해가 되었거나 될 지도 모르는 일을 끝없이 나열한다. 어쩌다 한 번이면 그런가 하고 넘어가지만, 말을 걸때마다 그러면 이상한 생각이 든다. 자기방어를 하지마라. 자기를 방어하기는 커녕 허접한 개발자로 보이게 하는 지름길이다.

​

4. 듣는 힘을 키워라

커뮤니케이션 능력의 80%는 상대의 말을 알아듣는 능력이다. 나머지 20%는 자기 생각을 상대가 이해할 수 있게 표현하는 능력이다. 초보 개발자일수록, 혹은 지위가 낮을수록 듣고 이해하는 능력이 중요할 것 같지만 사실은 정반대다. 시니어 개발자일수록, 그리고 회사에서의 지위가 높을수록 다른 사람의 말을 듣고 이해하는 능력이 생명이다. 그래서 지위가 높아지면서 말이 많아지는 사람은 작은 그릇이고, 지위가 높아지면서 말이 줄어드는 사람은 큰 그릇이다. 듣는 힘을 키워라. 많이 들을수록 더 높아진다.

​

5. 웅얼거리지 마라

웅얼거리는 사람이 있다. 단순히 스타일의 문제라고 말할 수 있지만, 스타일도 커뮤니케이션의 일부다. 개발자 컨퍼런스에 가면 참석자들이 흔히 투표용지나 앱을 이용해서 세션에 대한 평점을 매긴다. 연구에 의하면 세션에 대한 높은 평점과 가장 관련이 높은 요소는 기술적인 깊이나 인기있는 주제가 아니라 발표자의 발음과 태도다. 일상적인 대화에서도 마찬가지다. 말하는 사람은 웅얼거리는 것이 편할지 몰라도 듣는 사람은 고통스럽다. 웅얼거리지 마라. 웅얼거리는 습관을 극복하려는 노력을 기울이고 싶지 않으면 그냥 입을 다물어라.

​

6. 추상과 구체의 변증법

이벤트 소싱과 더불어 최근 개발자 사이에서 많은 관심을 끌고 있는 디자인 패턴인 CQRS의 창시자 그레그 영이 밝힌 일화다. 자기가 컨퍼런스에 스피커로 참가해서 처음 CQRS의 개념을 (그때는 아직 CQRS라는 이름이 붙지 않았다) 설명할 때 앞자리에 마틴 파울러나 도메인 주도 개발로 유명한 에릭 에반스 같은 대가들이 앉아 있었다. 강연이 끝나자 에릭 에반스가 다가와서 말했다. "네 프리젠테이션은 정말 엉망이었어." 1시간 동안 열심히 들었지만 무슨 말을 하는지 하나도 알아들을 수 없었다는 말을 덧붙였다. 그레그 영의 설명에 구체성이 결여되었기 때문이다.

​

앞에서 추상과 구체를 구분해야 한다고 말했지만, 새로운 개념을 설명할 때는 추상만으로 부족하다. 추상에서 구체로, 다시 구체에서 추상으로 범주를 반복해서 넘나드는 변증법이 필요하다. 구체의 영역으로 내려왔을 때 디테일의 늪에 빠지는 것은 곤란하지만, 그렇다고 해서 구체를 무시하고 추상만으로 이야기하는 것은 한계가 있다. 적절한 예와 비유, 그리고 개발자에게는 간단하게나마 코드를 보여주는 것이 필요하다.

​

7. 브리또의 역설

극도로 추상적인 개념인 모나드를 브리또 빵에 비유해서 설명하다가 폭망한 이야기는 업계의 전설이다. 자바스크립트의 거장인 더글라스 크록포드 같은 사람도 이런 저런 예를 들어 모나드를 설명하다가 스텝이 꼬이면서 망한 전력이 있다. 최근에 한빛에서 번역되어 나온 닐 포드의 '함수형 사고'도 비슷하다. 닐 포드가 함수형 패러다임을 설명하기 위해서 동원한 예가 오히려 이해를 가로막는다는 독자들의 불만이 적지 않다.

​

말하는 사람 자신이 특정한 기술에 대해서 이해하는 것과, 이해한 내용을 적절한 예를 동원해서 설명하는 것은 두 개의 독립적인 능력이다. 우리가 특정 기술을 잘 알기 위해서 노력과 훈련을 동원하는 것처럼, 좋은 설명을 위해 좋은 예를 동원하는 힘을 가지려면 그에 맞는 노력과 훈련이 필요하다. 기술을 이해했다고 해서 저절로 비유를 잘할 수 있는게 아니다. 두 개의 능력을 동일한 것으로 착각하는 사람 때문에 커뮤니케이션은 종종 붕괴된다.

​

지면 관계상 별도의 항목으로 다루지 못하지만 포함시키고 싶은 이야기가 많다. 솔직하라. 대화 상대와 진심으로 공명하라. 허언하지 마라. 등등. 이런 이야기는 개발자의 커뮤니케이션과 관련되었다기보다 커뮤니케이션 일반에 해당하는 항목이다. 아무리 강조해도 지나치지 않으므로 한 번 더 이야기하자. 개발자의 의사소통 능력은 코딩실력보다 중요하다. 코딩만 중요한 게 아니다. 우리 말로 말하고, 쓰고, 읽고, 듣는 것을 가벼이 여기지 마라. 좋은 개발자로 성장하기 위해서 반드시 기억해야 하는 명제다.

1. 매일 4시간 이상 코딩을 한다
대단할 것 없는 '팁'으로 들릴지 모르겠다. 매일 최소 8시간 이상, 아니 10시간 이상 책상 앞에 앉아있는 개발자가 많기 때문이다. 그러나 이메일 관련 스타트업 카피인(Copyin)을 창업한 피터 닉시 CEO는 자신을 포함해서 개발자들이 실제 개발에 투자하는 시간은 많지 않다고 지적했다.

그는 "아마 모든 개발자들이 미팅, 탁구, 점심 등에 헛되이 시간을 낭비하는 프로젝트에서 일한 경험이 있을 것이다. 방해가 많은 사무 환경에서 온전히 4시간 이상 개발에만 매진하기란 쉽지 않다"라고 말했다.

4시간을 일하기 위해서는 이런 업무 방해를 피해야 한다. 닉시에 따르면, 업무에 집중해 '뇌'가 각종 변수들을 처리하고 있을 때, 단 한 번의 방해로 집중이 흐트러지면 이를 되찾는데 최대 1시간이 소요될 수 있다.

2. 팀 문화에 적응한다
효과적인 개발자가 되기 위해서는 동료들과 잘 어울리는 팀 플레이어가 되는 것이 중요하다. 개발자 네트워크인 스케일러블 패쓰(Scalable Path)의 데미언 필라트로 CEO에 따르면, 이는 우수한 코딩 능력과 다년간의 경력보다 훨씬 더 중요한 요소다.

그는 건방진 사람과 일하는 것이 얼마나 불쾌한지 생각해보라고 지적하며, 능력과 별개로 일단 '함께 즐겁게 일할 수 있는 사람'이어야 한다고 강조했다. 그렇지 않은 사람은 전체 팀의 사기에 영향을 준다.

거만한 성격의 사람만 문제를 일으키는 것은 아니다. 어떤 이유든 팀 환경이 불편한 사람도 문제가 될 수 있다고 지적했다. 그는 "이를 테면 일부 문화권의 국가에서 온 개발자들은 갈등을 피하고, 할 수 없는 일, 문제가 될 수 있는 일을 솔직히 말하지 않는 경향이 있다. 이런 태도도 문제가 될 수 있다"라고 말했다.

3. 남는 시간에도 개발을 한다
현실을 직시하자. 개발자가 업무 시간에만 개발을 한다면, 새로운 기술을 배우거나 새로운 분야의 경험을 쌓기 힘들다. 웹 개발사인 애디드 바이트(Added Bytes)를 창업한 데이브 차일드는 이런 이유로 여유 시간에 코딩을 하는 것이 중요하다고 강조했다.

그는 "내가 알고 있는 최고의 개발자들은 모두 사이드(곁가지) 프로젝트를 갖고 있었다"라고 말하며, "사이드 프로젝트에 업무용 기술을 활용하는 개발자는 단 한 명도 없었다"라고 강조했다.

4. 너절한 코드를 쓰는 방법을 배운다
유능한 개발자가 아주 우수한 코드를 개발해야만 하는 프로젝트는 사실 극소수다. 통상은 일반적인 플랫폼 위에 특정한 기능을 구현한다.

닉시는 이를 가장 훌륭하게 달성하는 방법은 제 기능을 하는 코드를 재빨리 개발하고, 이를 보강하는 방법이라고 말했다.

그는 "코드가 지저분하고, 반복되고, 네이밍이 나빠도 상관 없다. 코드로 솔루션의 토대를 만들고, 이를 보강하면 된다. 처음부터 완벽을 추구하면 실제 달성한 성과가 극소수에 불과할 수 있다"라고 말했다.

5. 같은 일을 너무 오래하지 않는다
개발 직종의 한 일자리를 얻어, 여기에 '정착'해 버리면 개발 역량을 잃어버릴 수 있다. 필요한 업무를 완벽하게 터득하면 '막다른 골목'에 도달, 자신의 역량을 발전시키지 못하기 때문이다. 그 결과 더 유능한 프로그래머가 되지 못한다.

닉시는 "스스로에게 계속 도전해야 한다. 몇 년 동안 같은 일을 했다면, 배울 것을 모두 배웠을 것이다. 여기에 안주해서는 안 된다. 새로운 도전을 찾아 떠나야 한다"라고 말했다.

6. 최신성을 유지한다
소프트웨어 기술은 빠른 속도로 끊임없이 변한다. 이는 지금 당장은 유용한 코딩 기술이 미래에는 쓸모 없게 될 수도 있다는 의미이다. 소프트웨어 개발 부문에서 오랫동안 커리어를 유지할 계획이라면, 새 트렌드와 언어가 등장할 때마다 이에 뒤지지 않게 준비를 해야 한다.

개발사인 프로그레스 소프트웨어(Progress Software)의 토드 앵글린 최고 에반젤리스트는 "지금 갖고 있는 지식을 남은 커리어 내내 활용하는 것은 불가능한 일이다. 계속해서 학습을 해야 한다. 지금 알고 있는 것만으로는 살아남을 수 없기 때문이다"라고 말했다.

그는 그러나 모든 것에 정통하려 하지 말고, 관심 있는 분야에 집중하는 것이 중요하다고 덧붙였다. 그는 "중요한 것은 계속해서 배우려는 갈망과 열정이다. 그러나 더 깊은 전문성을 획득할 분야를 결정해야 한다. 모든 것을 배우려 시도하지 않는다. 불가능한 일이기 때문이다. 집중이 필요하다"라고 말했다.

필라트로도 여기에 동의했다. 그는 "개발 업무 중 절반은 과거 해보지 않은 업무이기 마련이다. 따라서 정작 중요한 것은 학습 방법, 정보 획득 방법일 수 있다. 스스로에게 필요한 지식을 가르칠 수 있어야 한다"라고 말했다.

7. 중요하다고 생각하는 것을 위해 코딩한다
'비 어 베터 디벨로퍼(Be a Better Developer)'라는 블로그의 운영자인 그레고 리글러는 열정을 갖고 있는 프로젝트에 참여, 코딩에 모든 것을 쏟아 붓는 것이 아주 중요하다며, 이를 위해서는 개발 대상이 중요하다고 말했다.

그는 "중요하게 생각하는 코딩에 매진해야 동기가 부여된다. 이는 특정 방식으로 앱을 작동시키는 개발, 또는 머신을 작동시키는 개발 등 다양하다. 어느 쪽이든 의미를 발견할 수 있고 즐길 수 있는 일이어야 한다. 즐길 수 있다면, 아주 좋은 코드를 개발하게 될 것이다"라고 말했다.

.

좋은 개발자 되기

* 프로그래머가 되는 법

* 읽기 쉬운 코드 작성법

.

.

[개발人] 송창현 “개발자도 기획자다”

http://www.bloter.net/archives/166736

‘스스로 원하는’ 개발자가 되는 게 중요

송창현 연구센터장은 이 때 얻은 경험을 바탕으로 현재 네이버 개발자들을 가르친다. 2008년 네이버에 입사해 기술혁신센터를 비롯해 다양한 개발 조직을 이끌면서, 개발자들이 최대한 자유롭고 즐겁게 개발하면서 동시에 열정적인 개발자가 될 수 있는 환경을 조성하려고 노력했다. 실제로 그가 수장이 돼 운영하는 네이버랩스실 한 쪽 벽면에는 다음과 같은 글이 적혀 있다.

1. 팀이 없는 것처럼 협업하라. 같이 일을 하게 되면 자리를 옮겨서 같이 해라.
2. 지시하지 말고 토론하라.
3. 자신이 무엇을 하고 있고, 무엇을 잘 하는지, 무엇을 하고 싶어하는지 알려라.
4. 핵심기능·기술에만 먼저 집중하여 작게 시작하여 완성하고, 자신을 성장시키며 제품도 같이 성장시켜라
5. 자신보다 더 똑똑한 사람을 뽑아라. 단 팀플레이어만.
6. 자신과 생각이 다른 사람들과 가까이 하라. 불편함을 우정으로 풀어라.
7. 빠른 성장과 진행을 위해 팀을 작게 만들어라.
8. 잘못되어 가는 것이 보이면 빨리 뒤집어라. 고칠것이 있으면 자신이 고쳐라.
9. 자신이 만들고 있는 것이 어떤 유저의 어떤 문제를 해결하는지 자신에게 물어라
10. 항상 유저를 찾고 그들과 소통하라
11. 지식 공유를 하지 않는다는 것은 자신이 성장하고 있지 않다는 이야기다.
12. 결코 어른이 되지 마라. 기술에 대한 열정과 마음은 그대로 남아 있어라.