“이동진 어려운말, 잘난체” 기생충 평 논란···심각한 韓문해력 - 중앙일보 - 이 글을 공유하면서 평가하는 많은 사람들이 ‘사람’ 이라는 단어를 ‘개발자’ 로 치환해도 대체적으로 맞는 말이라는 이야기를 했다. 그 말 뜻이 완전히 이해 되진 않았지만, 개발자로서 일을 하면서 글을 쓸 일이 많고, 특히 원격 근무 위주로 일하는 회사에 소속되어있는 만큼 글로 소통하는 일은 더더욱 중요하다고 느낀다. 그런데 그 글을 잘 읽지 못하고 쓰지 못하게 되면 소통하기가 어려워지고, 새로운 지식을 습득하기도 어려워진다. 더 많이 읽고, 더 많이 이해하고 받아들이며 더 많이 정리하는 습관을 들이는게 장기적으로 유리하다고 믿고 있다.
박사, 전문가 그리고 백종원 | ㅍㅍㅅㅅ - 우리는 어떤 사람을 ‘박사’ 라고 부르는가? 물론 공식적으로는 학위를 가진 사람을 박사라고 부를 수 있겠지만, 단순히 학위만으로 끝나는게 아니다. 끊임없이 자신이 연구할 수 있는 사람이라는 것을 증명하고, 그 실적도 내야 한다. “어떤 분야의 전문가라는 것은 해당 분야의 전문가들에게 자신의 연구실적으로 인정을 받는 것이지, 대중적인 인기나 베스트셀러 혹은 유튜브 구독자 수로 인정을 받은 것이 아니다.” 라는 구절이 인상깊었다.
이직 사유로서의 성장의 의미 - 나는 개발자로서 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배 끌어올릴 수 있는 뛰어난 동료가 되는 방법에 대해 이야기한다.
Handbook | GitLab - 깃랩의 핸드북이다. 무려 깃랩 사용 방법이 아니고 회사 자체에 대한 핸드북이다. 원격 근무 비중이 높은 회사일 수록 문서화를 잘 하고 그 문서를 관리하는 것이 중요하다고 생각하는데, 깃랩의 핸드북은 그 중에서도 독보적으로 뛰어나다. 이들은 “handbook first” 라는 마음가짐을 가지는 것이 불필요하게 반복적인 소통을 줄인다고 믿고 있다. 그래서 그 핸드북을 최신 상태로 유지하고 직군에 관계 없이 다양한 사람들이 기여할 수 있도록 권하고 있다.
덤으로 핸드북을 둘러보다 프론트엔드 개발자 공고도 살펴봤는데 굉장히 상세한 Job description에, 자신들이 개발자들의 레벨을 나누는 아주 명확한 기준을 제시하고 있어서 자신의 수준이 어느정도인지 참고하거나 채용 공고를 작성할 때 큰 도움이 될 것 같다.
REST - 기계인간 John Grib - REST(Representational State Transfer)라는 개념을 소개한 Roy T. Fielding의 논문을 직접 읽고 요약하셨다고 한다. 물론 원문을 읽는게 더 좋을 수는 있으나 결코 쉽지는 않을 테니, 우리가 흔히 웹 개발하면서 읊는 RESTful이 무엇인지 조금 더 자세히 알고 싶다면 요약본이라도 읽어보는 것이 좋겠다.
Practical Advanced TypeScript from @volkeron on @eggheadio - 좀 더 효율적으로 타입스크립트를 사용하게 도와주는 강좌. 만약 타입스크립트의 기본을 이해하고 있고, 실무에서 타입스크립트를 사용하고 있다면 약 한시간의 시간을 들여서 이 강좌를 쭉 살펴보는 것만으로도 큰 도움이 되리라 생각한다. 몰랐던 기능을 알려준다기보단 타입스크립트의 본래 목적에 맞게 더 안전한 타입 구성을 하는데 많은 팁을 제공한다.
Node.js에서의 프로토타입 오염 공격이란 무엇인가 | Coderifleman’s blog - 작년에 npm v6가 나온 이후 npm audit 이라는 모듈 취약점 검사 기능이 생겼다. 검사를 하다 보면 대부분의 취약점이 프로토타입 오염(Prototype pollution)일 때가 있었는데, 대충 머릿속으로 ‘해당 모듈이 프로토타입에 뭔가 추가하는게 있는데 그게 좋지 않은가보다’ 정도로 막연하게 생각하고 잊어버리고 있었다. 최근에 이 글을 읽으면서 막연히 알고 있던 개념을 좀 더 구체적으로 인식할 수 있었다. 결국 프로토타입이라는 JS의 근본적인 문제도 있다고 생각하지만, 적어도 내가 코드를 작성할 때는 __proto__ 를 쓰는데 더욱 주의를 기울이거나 최대한 아예 건드리지 말아야겠다.
Storybook Tutorial - 스토리북을 배우는 문서. 예전에는 내용이 꽤 부실했던 것 같은데 지금은 굉장히 알차게 되어있어서, 스토리북을 처음 시작하고자 하는 사람들에게 적극적으로 권장해주고픈 교재가 되었다.
PWA 하루 만에 도입하기(삽질기) - Evan’s Tech Blog | Blog - PWA를 실무에 도입하면서 ‘처음에는 쉬울 줄 알았는데 해 보니까 아니었다’ 라는 귀중한 경험을 장문의 글로 남겨주셨다. 지금 PWA 도입을 고려하고 있다면 이 글을 보면서 실수 할 수 있는 부분을 한번 살펴 보고 도입을 도전해보아도 아주 좋겠다고 생각했다.
React
GitHub - atlassian/react-sweet-state: Shared state management solution for React - Jira, Confluence로 유명한 아틀라시안에서 공개한 상태 관리 라이브러리. Redux와 Context API의 장점을 적절히 조합했고, Hook을 이용하는 상태 관리도 지원한다. Redux Devtool도 기본으로 지원하기 때문에 문서를 읽어본 바로는 새로이 프로젝트를 사용하고 조금 복잡한 상태관리를 할 일이 있으면 충분히 차용하기 좋은 라이브러리라고 생각한다. 다만 flow로 타입을 매겨두고 타입스크립트 타입은 따로 제공된게 없어서 타입스크립트와 쓰려면 타입 정의를 따로 하거나 기여를 해 두는 수밖에 없겠다.
Blog - Next.js 9 | Next.js - Next.js 버전 9가 7월 8일에 공개되었다. 코어 부분의 코드를 타입스크립트로 재작성하고, 별도의 플러그인을 추가할 필요 없이 타입스크립트를 바로 지원하게 되어 훨씬 편리하게 타입스크립트 기반 개발이 가능해졌다. 더더군다나 리버스 프록시용 API 서버를 별도로 구축하지 않아도 되도록 익스프레스 기반의 API 라우팅을 지원한다. pages/api/<your route> 형식으로 작성 가능하다. 안 쓴지 벌써 1년이나 더 된 사이에 엄청난 발전을 했다고 생각한다.
Virtualize large lists with react-window | web.dev - web.dav 는 더 나은 모던 웹사이트를 만들기 위한 정보를 배울 수 있는 사이트다. 언제부턴가 모던 프론트엔드 프레임워크의 최적화 전략도 소개하고 있는데 이 글에서는 ‘리스트 가상화’ 혹은 ’창에 가두기(windowing)’라는 개념을 사용하여 사용자가 특정 공간(window) 안에 보이는 리스트만 랜더링되도록 하는 전략을 안내한다. react-window 라는 라이브러리를 사용하고 있는데 예제를 따라가보는게 꽤 재미있었다. 다른 팁들도 같이 틈틈이 읽어봐야겠다.
MobX with React - mobx-react 사용자 가이드. 이전에 있던 가이드에서 훨씬 발전했기 때문에 MobX와 리액트를 사용해보려는 사용자는 반드시 가이드를 읽어보았으면 좋겠다. Hook 시대에 들어서면서 MobX의 유용성이 좀 떨어져가는 느낌이 들지만, 이미 쓰고 있는 입장에서 이렇게 잘 되어있는 문서를 보니 내가 잘못 사용하고 있었다고 느끼는 부분도 있고, 지금 MobX를 사용하는 프로젝트를 더 발전시킬 요소도 발견할 수 있어서 충분히 시간을 들여 읽을 가치가 있었다