This Month I Learned - 2019년 7월
General
- ”이동진 어려운말, 잘난체” 기생충 평 논란···심각한 韓문해력 - 중앙일보 - 이 글을 공유하면서 평가하는 많은 사람들이 ‘사람’ 이라는 단어를 ‘개발자’ 로 치환해도 대체적으로 맞는 말이라는 이야기를 했다. 그 말 뜻이 완전히 이해 되진 않았지만, 개발자로서 일을 하면서 글을 쓸 일이 많고, 특히 원격 근무 위주로 일하는 회사에 소속되어있는 만큼 글로 소통하는 일은 더더욱 중요하다고 느낀다. 그런데 그 글을 잘 읽지 못하고 쓰지 못하게 되면 소통하기가 어려워지고, 새로운 지식을 습득하기도 어려워진다. 더 많이 읽고, 더 많이 이해하고 받아들이며 더 많이 정리하는 습관을 들이는게 장기적으로 유리하다고 믿고 있다.
- 박사, 전문가 그리고 백종원 | ㅍㅍㅅㅅ - 우리는 어떤 사람을 ‘박사’ 라고 부르는가? 물론 공식적으로는 학위를 가진 사람을 박사라고 부를 수 있겠지만, 단순히 학위만으로 끝나는게 아니다. 끊임없이 자신이 연구할 수 있는 사람이라는 것을 증명하고, 그 실적도 내야 한다. “어떤 분야의 전문가라는 것은 해당 분야의 전문가들에게 자신의 연구실적으로 인정을 받는 것이지, 대중적인 인기나 베스트셀러 혹은 유튜브 구독자 수로 인정을 받은 것이 아니다.” 라는 구절이 인상깊었다.
- 이직 사유로서의 성장의 의미 - 나는 개발자로서 4년 가까이 일해오면서 남들에 비해서 조금 잦은 이직을 했다. 이직을 하면서 매번 생각했던 것은 ‘나 자신의 성장’이었다(물론 돈도 중요한 요소 중 하나다). 적어도 막연한 이유로 이직을 하진 않았다. 이직의 사유 뿐 아니라 이직 할 회사를 고르면서도 나 자신의 성장을 어떤 식으로 이루고 싶은지 명확한 관점을 가지고 있다면 더 마음에 드는 회사에 갈 확률이 높아지지 않을까 한다.
- 직장인을 위한 GTD 시작하기 (How To Start GTD) - GTD(Getting Things Done)은 할일 관리 방법론 중 하나다. 나는 어릴 때부터 요령 피우는 것을 좋아하는 성격 때문에 일 그 자체보다 ‘어떻게 효율적으로 일을 처리할 수 있을까?’ 를 고민하고 공부한 적이 많았다. 그렇게 GTD의 개념은 10년 전부터 알고 있었지만 그리 잘 실천이 되진 않았다. 하지만 최근 들어 다시 한번 내 자신의 생산성에 대해 깊은 고민을 하면서 기본 개념을 살펴보다 이 슬라이드를 발견했다. 필요한 내용만 잘 정리되어 있어서 할일 관리를 해보고자 하는 사람들에게 꼭 권해보고 싶은 슬라이드였다. 장표 수는 80장 정도 되지만 실제로 21쪽까지만 봐도 된다. 그 이후는 도구 소개, 이메일과 함께 사용하는 관리 방법인데 나는 둘 다 필요없었다.
- Things 3 - 할일 관리 앱은 어지간한 것은 다 써 왔지만, Things 3는 가격이 꽤 부담된다고 생각하여(iPhone, iPad, Mac 다 합쳐서 $80) 여태까지 구입을 꺼리고 있었다. 내가 이 돈을 줘 가면서까지 할 일을 관리할 정도는 아니라고 생각하기도 했다. 하지만 오히려 다른 도구들을 다 써보고 나서 Things를 접하니 그 유용함을 느끼고 훨씬 더 잘 활용할 수 있게 되었다. 아직 구입한지 몇일 되지 않았지만 돈도 아깝지 않다. 맥을 쓰지 않거나 다양한 플랫폼을 이용하는 사람들에게는 Todoist나 TickTick을 추천한다.
Developer
- 입력 지연 해소되나, 카이스트 레이턴시 보정 기술 개발 - 게이머 입장에서 상상해본다면 게임 할 때 입력 지연을 보정한다고 하면 키 입력과 화면을 동기화하는데 많은 고민을 할 것이라 생각한다. 하지만 어디까지나 물리적인 한계가 있다. 특히 요즘 같이 무선 장비가 여기저기 연결되어 있는 세상에선 더욱 그렇다. 이 기사에서 소개하는 기술은 오히려 발상을 역전시켜 인풋렉만큼 게임의 난이도를 약간 변화시키는 기법이었다. 플랫포머류 게임에 아주 잘 맞아 보인다. (추가: 실제로 현업에 종사하는 게임 개발자 분들에게는 많은 비판을 받았던 내용이다)
- 소프트웨어 환멸감 - muchtrans - 제대로 최적화되지 못한 애플리케이션을 만들어온 개발자로서 언제나 마음 한켠에 후회를 안고 살아간다. 분명 하드웨어는 많이 발전했는데, 우리가 쓰는 애플리케이션은 그에 걸맞는 최적화가 안 되어 있는 경우들을 보면서 똑같은 생각을 할 때가 있다. ‘이 똑똑한 사람들이 이 훌륭한 하드웨어를 가지고 만든 소프트웨어가 왜 이렇게 느리고 답답할까?’ 이 글에서는 개발자/시장 모두 신경쓰지 않아서 생기는 문제였다고 강하게 비판하고 있다. 하지만 조금만 더 생각해보면, 최적화는 기기의 성능에 맡겨두고 머리를 싸매야 할 다른 고민거리가 충분히 많기도 하다.
- 그래도 다시 코드리뷰 2 - 서지연님의 ‘그래도 다시 코드리뷰’ 이후 새로운 발표 슬라이드. 외국계 회사라는 새로운 환경에서 일을 하시면서 겪었던 경험과 함께 코드 리뷰에 대해 참고할 만한 좋은 내용을 많이 알려주셨다.
- 예의 바른 소프트웨어 - 기계인간 John Grib - 앨런 쿠퍼의 ‘정신병원에서 뛰쳐나온 디자인’ 의 일부를 정리한 글이다. 책을 가지고 있으면서도 아직 읽지 못했는데 이렇게라도 일부를 접하게 되어 반갑다. 이 글을 읽고 UI를 개발하는 사람으로서 (사용자에게) 예의 바른 소프트웨어가 무엇일까 더 고민하게 된다.
- Open Source Guides - Github에서 만든 오픈 소스 가이드. 프로젝트를 시작하는 방법 뿐 아니라 다른 프로젝트에 기여를 할 때 어떻게 해야하는지 기본적인 내용을 안내하는 것을 넘어서 커뮤니티 구축, 메인테이너와 리더십, 비용을 지불하거나 라이센스에 신경쓰는 것 까지 거의 모든 내용을 망라하고 있다. 한글 번역도 초벌번역이긴 해도 잘 되어있다. 수정 기여가 아직 머지되지 않은 상태인데 이슈 진행상황을 다시 살펴봐야겠다. 🤔
- QuickAndDirty - 영록이 홈페이지 - 지금 Quick & Dirty 는 커녕 Slow & Dirty 를 하고 있다고 생각하고 있다. 개발자 입장에서 MVP(Minimum Viable Product)라는 것이 무엇인지, 그리고 처음 MVP를 만들고 나서 무리없이 개선을 할 수 있는 상황까지 프로젝트를 진행하려면 어떤 방식으로 개발을 해야할지 안내하는 조언이 담겨있다. 이 글을 추천하신 분께서는 필요한 것만 취사선택해서 보지 말고 내용 전체를 자세히 읽은 다음 본인에게 맞게 체화할 것을 더더욱 강조하였다.
- 10배 뛰어난 개발자 되기 - 7월 초에 개발자 소셜 미디어에서 많이 거론되었던 용어 중 하나로 ‘10x engineer’가 있다. 원문을 그대로 받아들이기보단 나름 ‘어떤 사람이 훌륭한 개발자인가?’ 라는 주제를 되짚어보는데 좋은 촉매재가 되었다고 생각한다. 그리고 아마 이전에 링크한 적이 있다고 생각하지만 링크한 글은 자신이 아니라 주변 사람의 실력을 10배 끌어올릴 수 있는 뛰어난 동료가 되는 방법에 대해 이야기한다.
- Great Developer Habits - WWDC 2019 - Videos - Apple Developer - 제목부터 구미가 확 당기는 발표다. 특히 ‘문서의 역할도 하는 코드’ 에 대해 일부 비판하기도 한다. ‘내 코드는 self-documenting 하다고요! 과연 그럴까요?’ 아무리 훌륭한 코드라도 What을 전달할 수는 있지만 Why는 전달할 수 없다.
- Handbook | GitLab - 깃랩의 핸드북이다. 무려 깃랩 사용 방법이 아니고 회사 자체에 대한 핸드북이다. 원격 근무 비중이 높은 회사일 수록 문서화를 잘 하고 그 문서를 관리하는 것이 중요하다고 생각하는데, 깃랩의 핸드북은 그 중에서도 독보적으로 뛰어나다. 이들은 “handbook first” 라는 마음가짐을 가지는 것이 불필요하게 반복적인 소통을 줄인다고 믿고 있다. 그래서 그 핸드북을 최신 상태로 유지하고 직군에 관계 없이 다양한 사람들이 기여할 수 있도록 권하고 있다.
- 덤으로 핸드북을 둘러보다 프론트엔드 개발자 공고도 살펴봤는데 굉장히 상세한 Job description에, 자신들이 개발자들의 레벨을 나누는 아주 명확한 기준을 제시하고 있어서 자신의 수준이 어느정도인지 참고하거나 채용 공고를 작성할 때 큰 도움이 될 것 같다.
- REST - 기계인간 John Grib - REST(Representational State Transfer)라는 개념을 소개한 Roy T. Fielding의 논문을 직접 읽고 요약하셨다고 한다. 물론 원문을 읽는게 더 좋을 수는 있으나 결코 쉽지는 않을 테니, 우리가 흔히 웹 개발하면서 읊는 RESTful이 무엇인지 조금 더 자세히 알고 싶다면 요약본이라도 읽어보는 것이 좋겠다.
Docker
JS / TS
Frontend
React