개발자 로드맵 - Roadmap to becoming a web developer in 2017

https://github.com/WegraLee/developer-roadmap

Balsamiq 을 이용해서 만들었다고 하네요. 

...

개발자의 평생공부

[임백준 칼럼] 실력은 고통의 총합이다

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20170616090644&lo=z46

평생 공부하는 건 개발자만이 아니다. 다른 직업을 가진 사람들도 쉼 없이 공부하고, 컨퍼런스와 세미나를 참가하고, 스터디를 한다. 공부없이 할 수 있는 일이 없기 때문이다. 언뜻 보기에 공부와 거리가 멀어 보이는 바텐더조차 공부할 것이 많다. 바텐더를 위한 컨퍼런스는 물론이고 전문적인 팟캐스트 방송까지 있다. 공부는 누구나 하는 것이므로 공부한다는 사실만으로 엄살을 떨 필요는 없다. 문제는 공부의 방향이다.

​

개발자의 경우는 평균적으로 보았을 때 3년 전에 학습한 지식이면 낡은 징후를 보이기 시작하고 5년이면 생명을 다한다. 더 오래가는 지식도 물론 있다. 프로그래밍의 본질에 가까운 지식은 수명이 오래가고 파편적인 지식일수록 수명이 짧다. 그래서 본질을 추구하며 에피파니(Epiphany)를 경험한 사람은 그렇지 않은 사람에 비해서 공부로 인한 스트레스를 덜 받는다. 중요한 것과 중요하지 않은 것을 구별하는 혜안이 있기 때문이다.

​

두 사람의 개발자가 있다고 하자. 한 사람은 최신 트렌드에 밝다. 아마존 람다를 이용해서 서버리스 시스템을 구축하고, 코세라 강의를 들으며 머신러닝을 공부한다. 페이스북에서 친구들이 공유하는 새로운 도구를 건드려보며 지식을 확장하고, 컨퍼런스와 스터디를 참석하여 동기를 부여 받는다. 함수형 언어를 학습하고, 새로운 파이썬 라이브러리도 사용하고, 리액트와 앵귤러로 코드를 짜서 웹사이트도 구축해본다. 부지런하다.

​

다른 한 사람은 최신 트렌드에 관심이 없다. 대신 회사에서 주어지는 요구사항을 날카롭게 분석하고, 꼼꼼한 설계과정을 거쳐서 코드를 작성하고, 정밀하게 테스트하고, 출시가 성공적으로 끝나면 다음 요구사항을 읽는다. 20년째 한 언어를 사용해서 코딩을 하고 있으며 다른 언어나 플랫폼에 대해서 관심이 없다. 하지만 그의 추상은 도메인주도 개발이나 디자인 패턴을 기계적으로 적용하는 수준을 뛰어넘는다. 요구사항을 코드로 바꾸는 과정에서 필요한 추상을 스스로 만들어내고 새로운 구조물의 상호작용, 데이터의 무결성, 성능 등을 빈틈없이 사고한다. 철두철미하다.

​

회사에서 새로 만들어야 하는 중요한 소프트웨어 제품이 있다고 하자. 이 제품을 잘 설계해서 정해진 시간 안에 출시함으로써 회사의 비즈니스에 결정적인 도움을 주어야 하는 상황이다. 이런 상황이라면 둘 중 누구에게 일을 맡길 것인가? 아이디어의 타당성을 검증하는 POC(Proof of Concept) 프로젝트나 단순한 R&D 업무라면 최신 트렌드에 밝은 사람을 고려할 수 있을 것이다. 하지만 비즈니스의 성공과 직결되는 실전이라면 그럴 수 없다. 실전이 필요로 하는 사람은 두 번째 유형이다. 그가 가진 능력이 프로그래밍의 본질에 더 가깝기 때문이다. (첫 번째 사람이 두 번째 사람이 가진 능력까지 가지고 있다면 이야기는 달라진다.)

​

개발자가 공부하는 것은 그래서 두 번째 유형의 사람이 가진 능력, 본질적인 능력을 키우는 것을 의미한다. 프로그래밍의 본질은 문제의 해결이다. 트렌드를 좇는 것은 파편적인 지식을 획득하는 것에 불과하기 때문에 큰 의미가 없다. 페이스북이나 트위터의 타임라인을 보면 수만가지 새로운 기술과 도구가 날마다 쏟아진다. 좋은 개발자라면 그런 것들을 모두 알아야 하는가? 전혀 그렇지 않다. 파편적인 지식은 파편적인 태도만으로 충분하다. 트렌드에 필요한 것은 가벼운 눈팅이지 공부가 아니다. 공부는 본질에 다가서려는 노력이다.

​

나는 프로그래머다 컨퍼런스에서 한 참석자가 ‘실력을 키우려면 어떻게 해야하는가’라는 질문을 한 적이 있다. 나는 그때 실력이 무엇을 의미하는지부터 생각해보자고 대답했다. 우리는 종종 실력을 이미 알고 있는 지식의 총량으로 착각한다. 실력과 지식의 총량은 희미한 상관관계가 있기는 하지만 사실상 무관하다. 진짜 실력은 임기응변이기 때문이다. 실력은 주변상황에 휘둘리지 않는 집중력이다. 해결해야 하는 문제가 무엇인지 알아채는 감각이다. 처음 본 문제를 해결하는 능력이다. 이러한 임기응변, 집중력, 감각, 그리고 능력은 이미 알고있는 지식으로부터 나오는 것이 아니다. 그것은 본질에 다가가기 위해서 감내해온 고통, 불면의 밤, 좌절, 환희, 이런 것으로 점철된 뜨거운 경험에서 나오는 것이다. 

그래서 실력은 지식의 총합이 아니다. 

고통의 총합이다.

​

여러분이 페이스북 타임라인을 보다가 누가 공유한 새로운 기술에 대한 링크를 저장했다고 하자. 영원히 볼 일이 없는 글을 저장하는 행위는 쇼핑몰 사이트에서 위시리스트나 보관함에 마음에 드는 상품을 담는 심리와 정확히 일치한다. 즉, 그것은 공부가 아니라 쇼핑이다. 쇼핑과 눈팅이 자체로 의미없는 일은 아니지만 그걸 공부로 착각하는 사람은 파편적인 지식의 늪에서 빠져나오기 어려울 것이다.

​

개발자에게 공부가 무엇을 의미하는지 알아보았으니 어떻게 공부해야 하는지에 대해서도 잠깐 짚어보자. 지면관계상 짧은 아포리즘 형식으로 나열해 보았다.

​

1. 지금 다니고 있는 회사에서 하는 일을 잘하기 위해서 노력하는 것이 가장 좋은 공부다.

2. 회사에서 하는 일과 개인적으로 공부하는 내용을 최대한 근접시키기 위해서 노력하라.

3. 새로운 기술을 익히는 최선의 방법은 스스로 문제를 정의한 다음, 새로운 기술을 이용해서 그 문제를 풀어보는 것이다. 책을 읽거나 동영상을 보는 것은 그보다 하위수준의 방법이다.

4. 신기술을 좇는 메뚜기가 되지 말라.

5. 모든 것을 알아야 한다는 강박을 버려라. 미리 획득하는 지식의 99%는 무용지물이다. 필요할 때 필요한 기술을 익힐 수 있는 것이 능력이다. 그 능력을 키워라.

6. 이상한 나라의 앨리스에 나오는 토끼굴(rabbit hole)을 피하라. 카테고리이론을 알아야 함수형 언어를 쓸 수 있는게 아니고, 선형대수학을 공부해야 머신러닝을 할 수 있는게 아니다. 토끼굴에 빠져서 한없이 들어가다보면 비본질적인 공부에 시간을 허비하게 된다.

7. 겉만 핥는 것은 경박하지만 토끼굴에 빠지는 것은 우매하다. 둘 사이의 적당한 지점에서 균형을 잡는 것이 개발자의 능력이다.

8. 머리에 들어오지 않는 어려운 개념이나 용어는 자투리 시간을 이용해서 반복적으로 읽고 암기하라. 나중에 큰 그림을 공부할 때 도움이 된다.

9. 항상 겸손해야 하지만 동시에 자긍심을 가져라. 그대가 지금 작성한 코드, 지금 읽은 책, 지금 공부한 내용을 그대보다 잘 아는 사람은 지구상에 없다. 모든걸 알고 있는 것처럼 보이는 다른 사람들도 그대와 마찬가지로 불안해하고, 위축되고, 두려워하면서 살아가고 있다. 자긍심이란 그런 타인을 돕고자 하는 마음가짐의 다른 이름이다.

10. 혼자 하지 말고 함께 공부하라.

​

이 시점에서 가슴에 손을 얹고 스스로 질문해보기 바란다. 공부가 재밌는가? 정말 재밌는가? 새로운 기술을 익히고, 키보드를 두드리고, 결과를 확인하고, 친구들과 이야기하는 모든 경험이 그대를 행복하게 만드는가? 이 질문에 대한 대답이 예스라면, 그 예스의 강도만큼 그대의 미래는 성공이 보장되어 있는 것이다. 그러므로 개발자는 미래에 대해 불안해할 필요가 없다. 미래의 성공은 예스라는 작은 변수의 함수이기 때문이다. 그 변수는 개발자 자신의 손에 놓여 있다.

.

안드로이드 인스턴트 앱이 모든 개발자에게 공개되었습니다. 바로 지금 개발을 시작해보세요!

https://developers-kr.googleblog.com/2017/06/android-instant-apps-is-open-to-all.html

Android 빠른 실행 앱 : https://developer.android.com/topic/instant-apps/index.html

안드로이드 인스턴트 앱은 앱을 설치하지 않고도 앱을 실행할 수 있는 새로운 방법입니다. 지난 구글 I/O에서 처음 기능이 공개되었고, 올해 초 몇몇 파트너들과 함께 테스트를 진행하며, 이를 통해 기능을 개선하고 다듬었습니다.

그리고 마침내 이번 2017년 구글 I/O에서 모든 개발자에게 안드로이드 인스턴트 앱이 공개되었습니다. 이미 HotPads, Jet, New York Times, Vimeo, One Football 및 한국의 원티드등 50가지 이상의 앱에서 인스턴트 앱을 적용했습니다. 아직 출시 초기이지만, 초기 데이터는 긍정적인 결과를 보여주고 있습니다. 예를 들어, Jet와 HotPads는 두 자릿수의 구매 증가율을 보이고 있습니다.

인스턴트 앱 빌드를 시작하려면 developer.android.com에서 안드로이드 스튜디오 3.0 및 안드로이드 인스턴트 앱 SDK의 최신 미리보기를 다운로드 해야합니다. 기본적으로 인스턴트 앱 지원을 위해 기존에 작성된 앱 코드를 활용하실 수 있습니다. 안드로이드 스튜디오는 필요에 따라 사용자가 앱 기능을 추가로 다운로드할 수 있도록 앱 모듈화에 필요한 도구를 제공합니다. 각 앱마다 다르지만 초창기 파트너의 경우 인스턴트 앱 개발에 약 4~6주일 정도 걸리는 것으로 확인되었습니다.

기존 앱과 마찬가지로 Play Console을 통해 인스턴트 앱을 배포할 수 있습니다. 인스턴트 앱 APK를 설치 가능한 APK와 함께 업로드하기만 하면 됩니다.

인스턴트 앱은 40개국 이상에서 사용되는 최신 안드로이드 기기를 기반으로 계속 성장하고 있습니다. 더 나아가 안드로이드 O에서는 인스턴트 앱을 위한 더욱 효율적인 새 런타임 샌드박스, 앱 크기를 줄이기 위한 공유 가능한 지원 라이브러리 및 런처 통합 지원이 제공됩니다.

자세한 내용은 g.co/InstantApps이나 5월 18일에 발표된 '안드로이드 인스턴트 앱 소개' 세션을 다시 시청해 보시기 바랍니다.

개발자 여러분이 인스턴트 앱으로 어떤 새로운 사용자 경험을 만들어내실지 정말 기대됩니다!

.

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

.

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

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. 브리또의 역설

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

​

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

​

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