General

• 이직률 0% 조직의 동료와 문화 
  • 세상에는 정말 다양한 형태의 조직이 있다. 나도 많은 조직을 겪어보진 못했지만, 막연히 ‘이런 조직에 소속되어 있으면 좋겠다’ 는 생각으로 이직을 했고, 그렇게 지금 있는 회사에서 계속 일을 하고 있는 것이다.
  • 강남언니를 서비스하는 힐링페이퍼는 종종 소문으로만 ‘괜찮은 조직이다’, ‘조직원들의 실력이 뛰어나다’ 는 이야기를 들었다. 그러다 회사 슬랙에 공유된 글을 통해 이 조직은 어떻게 일하는지 배울 수 있는 기회를 얻게 되었다.
  • ‘최고의 직자은 탁월한 동료들과 함께 일할 기회가 주어지는 곳이다’ 라는 말은 지당하다고 생각하는데, 그 탁월한 동료들과 함께 일하면서 시너지를 어떻게 끌어올릴 수 있을지 궁금했던 적이 많았다. 내 주변 동료들도 탁월한 사람들이지만 그 사람들과 같이 성장해나간다는 느낌을 잘 받지 못하고 있었기 때문이다. 그래도 환경이 잘 주어진다면 서로를 존중하고 서로를 통해 발전할 수 있다는 듯 하다.
  • 조금씩이지만 분명하게 더 좋은 방향으로 변화를 추구하는 조직이라는 점도 강조했다. 조직은 하나의 유기체와 같아서, 언제나 같은 형태를 유지하진 않는다. 그렇다면 더 좋은 방향으로 변화를 추구하는 것이 옳은 전략일 것이다.
  • CSS(Continue, Stop & Start)라는 방식의 구성원 사이에 피드백을 주고받는 제도도 흥미로웠다. 가끔은 최소 1년에 한번 최소한 같은 팀의 구성원들끼리 피어 리뷰를 하는 시간을 가질 수 있다면 좋겠다고 생각했는데, 훨씬 자주 서로 의미 있는 피드백을 주고받는다는 것이다.

Developer

• 함수 작성 전에 무엇을 생각해야 할까? 
  • 새로운 함수를 작성하기 전에, 호출하는 방식 혹은 흐름을 먼저 작성해보라는 조언이다.
  • 함수로부터 기대하는게 무엇인가? 함수가 무엇을 리턴할 것인가? 이 함수는 무엇을 할 것인가(함수의 이름이 무엇인가)?
  • 이런 방법을 적용하기 위해 TDD를 반드시 적용해야 할 필요는 없지만, 이 과정은 TDD의 일부라고 할 수 있다. 잘 정립된 함수는 가독성 좋은 코드를 만드는 발판이 되기도 한다. 결국 자기 자신을 위해서라도 좋은 함수를 디자인하라는 것이다.
• 지역성의 원칙을 고려한 패키지 구조: 기능별로 나누기 
  • 간만에 안희종님이 좋은 글을 써 주셨다. 지역성의 원칙을 고려하여 하나의 기능 단위로 사용되어야 하는 코드들을 모으는 것을 권장하는 내용이다.
  • 예를 들어 컴포넌트>기능A / API호출>기능A / 유틸리티>기능A 같은 형식으로 각 코드의 ‘역할’ 기준으로 쪼개지 말고 기능A>컴포넌트,API호출,유틸리티 처럼 하나의 의미있는 기능 단위로 활용되는 모듈을 모으는 형식으로 패키지를 구성하는 것이다.
  • 막연하게 ‘기능 단위로 코드를(혹은 컴포넌트를) 묶는게 좋지 않을까?’ 하고 약간 프로젝트 구조를 수정한 적이 있었는데 꽤 컴포넌트를 찾고 관리하기 편해졌었다. 장기적으로는 이런 방식의 프로젝트 구성이 되도록 수정해보고 싶다.
  • 💵 캐시가 동작하는 아주 구체적인 원리  - 본문 안에 포함되어있던 이 글도 좋아서 읽어볼만 하다.
• 박규현 님의 트윗 
  • 개발자가 지속적인 성장을 위해 뭔가 끊임없이 학습해야 한다는 이야기는 많이 듣게 된다. 그런데 “어떤 마음가짐을 가지고 무엇을 학습해야 하는가?” 를 깨닫기까지는 생각보다 여러 시행착오를 거쳐야 한다고 느꼈다.
  • 이 트윗은 현실적인 관점에서 개발자의 의식적인 훈련이 어떻게 이루어져야 하는지 알려준다.
    • 지금 공부하는 기술의 지속성을 생각하여 공부를 적당히 하기
    • 읽은 것이 있다면 몇 줄이라도 타이핑해보기
    • 읽는 것과 타이핑 하는 것의 순환을 만들기
    • 이걸 평상 반복하는 것이 개발자
• 스크럼에 대한 경험 및 개인적인 생각 - FutureSeller 
  • 회사 조직 개편(하지만 내가 가까이 일해야 하는 우리 팀 구성원 자체는 거의 바뀌지 않았다) 이후, 새로운 팀으로 일할 때 어떤 방식으로 우리가 효율적으로 일해야 하나 같이 고민을 해 보았다. 그러던 와중에 이런 글을 추천받아서 읽게 되었는데, 스크럼을 도입하고 활용하게 된 이야기부터 회고를 통한 통찰이 잘 배들어 읽기 좋았다.
  • 덤으로 연결되어 있는 글 도 읽어보았다. 글 내용이 GraphQL 도입기인데 ‘언제 나도 GraphQL을 도입해보나’ 라는 생각보단, 업무에서 발생하는 다양한 문제 해결 과정을 이렇게 글로 만들어 공유하는 모습에 주목했다. 나도 이미 매일 작성하는 나만의 업무일지로 기록을 하고 있음에도 불구하고 이 글처럼 내용을 갈무리하여 공유하는 일은 거의 하지 않았다는 생각이 들었다.
  • 물론 모든 사람(개발자 등)이 이런 방식으로 자신의 삽질 과정을 기록하고, 회고하고, 공개하며 발전하기 위한 노력을 하기는 어렵다. 그러므로 이런 글을 작성하고 공유해주시는 분들을 존경한다.
  • 덕분에 누구나 볼 수 있도록 공유하기 위한 목적이 아니어도, 최소한 자기 자신을 위한 기록 및 회고 습관을 더 잘 형성해야겠다고 느끼는 계기를 얻었다.

Frontend

• You might not need shadow DOM — Hjorthhansen 
  • 한동안 코드 리뷰를 해주는 일을 하고 있는데, Shadow DOM(쉐도우 돔)을 한번 알아보고 활용할 것을 추천해줬다가, 추가 질문을 받고 조사해보니 지금 시점에선 어지간하면 안 써도 되지않겠나 하는 생각이 들었다.
  • 그 당위성에 대해 추가로 조사를 해보고자 검색을 했는데 이 글이 가장 잘 정리되어있었다. 너무 길지도 않으면서 쉐도우 돔이 어떤 문제를 해결할 수 있는지, 그 한계는 무엇이고, 대안으로 “쉐도우 돔을 쓰지 말 것” 을 권장하는 글이다.
  • 2년 전쯤 웹 컴포넌트에 대해 학습하고 발표한 적이 있긴 했지만… 나도 결국 제대로 활용해본 적이 없구나.
• CSS로 구현하는 Scroll snap 
  • Fullpage.js 같은 라이브러리로 페이지 스크롤링을 제어하는 방법도 있지만(용도도 약간 다르고), 일정 위치에 스크롤이 걸리도록 만드는 UI를 만들어야 할 때가 가끔 있다.
  • 위 트윗은 스크롤 스내핑을 구현하는 ‘아주’ 간단한 예제를 보여준다. 가볍게 따라해보고 익히기엔 좋다.
  • 좀 더 자세한 원리와 정보를 알고 싶다면 역시 CSS Tricks의 글 을 봐야 한다.

React

• Redux 를 넘어 SWR 로(1) | LearnApplyShare 
  • 페이지별로 집중화된 mobx-state-tree 스토어를 운용하는 식으로 프로젝트를 꾸리고 있지만, 장기적인 관점에서 useSWR 혹은 react-query 같은 라이브러리의 방법론을 통해 서버와의 데이터를 동기화하는게 훨씬 효율적이라고 느끼고 있었다. 당장 적용하기에 먼 산처럼 느껴지고 있었지만.
  • 2편까지 있는 이 글은 현재까지 주로 사용되어왔던 Redux, MobX 등을 활용한 상태관리법에서 한 단계 나아가 useSWR 을 어떻게 서버와의 데이터 동기화에 활용할 수 있고, 로컬 상태관리 도구로도 사용할 수 있는지 좋은 예시와 함께 안내한다.
• Replacing Create React App with the Next.js CLI · GitHub 
  • 리액트로 SPA를 만든다고 하면 가장 유명한 보일러플레이트가 리액트 팀에서 공식으로 제공하는 create-react-app (CRA)일 것이다. CRA는 많은 편의기능을 제공하긴 하지만 확장성이 좀 부족하고 전반적으로 무겁다는 단점이 있다.
  • 확장성 부족이야 craco  같은 솔루션을 사용하여 커버할 수 있지만, CRA의 버전 자체가 올라가면 대응하는데 간극이 생길 수도 있고, 정말로 높은 수준의 확장성을 필요로 하는 경우에는 맞지 않는다고 느낀다. 또한 2년정도 프로젝트를 확장시켜오면서 크고 작게 ‘느리다’ 라는 인상을 받고 있었다.
  • 위 글은 CRA를 Next.js CLI로 마이그레이션 하는 안내이다. 하나 특징이 있다면, SPA도 Next.js로 마이그레이션할 수 있다는 것이다. 보통 Next.js 는 SSR(Server Side Rendering) 혹은 SSG(Static Site Generation) 용도로 쓰게 되는데, 몇 가지 설정을 통해 SPA에서도 사용할 수 있도록 만들 수 있다고 한다.
  • 특히 현재 SPA로 앱을 만들고 있고 장기적인 관점에서 SSR 도입을 고려하고 있다면 미리 옮겨두어서 나쁠 것은 전혀 없겠다는 생각이 들었다.
• React Query: It’s Time to Break up with your “Global State”! –Tanner Linsley - YouTube 
  • react-query 라는게 있다는 것을 알게 되고, 이게 내가 지금까지 리액트 애플리케이션을 설계할 때의 생각을 송두리째 바꾸어야 한다는 것까지는 가볍게 인지하고 있었다. 그러나 대체 이 라이브러리 혹은 패러다임을 어떻게 인지하고 접근해야할까 더 정보를 알아보기 위해 문서를 찾아보니, 공식 문서에 바로 소개 영상이 있었다.
  • 자세한 내용은 영상을 참고하는것이 좋고, (이미 영상 내용은 한번 정리를 하여 팀 내부에서 발표를 한 적이 있으니 의욕이 생긴다면 블로그에 포스팅을 할 수도 있을 것이다.)
  • 핵심은 서버에서 가져오는 ‘서버 캐시’ 에 가까운 상태와 UI 상태는 구분이 되어야하고, 리액트의 상태만으로는 그 서버 캐시를 깔끔하게 다루기 어렵다는 것이다. 커스텀 훅을 통해 그 다루기 어려운 서버 상태를 컴포넌트 사이에 적절히 동기화하는 과정을 이 영상에서 단계별로 보여준 뒤에 최종 완성본에 가까운 react-query 적용부분을 보여주는 형태로 되어있다.
  • 아래의 저장소에서 커밋 단위로 따라가다보면 어떤식으로 그 커스텀 훅이 만들어지게 되는지 살펴볼 수 있다. 꽤 흥미롭다.
    • GitHub - tannerlinsley/react-query-blog-refactor-example: A commit-by-commit story of building your own global async server-state management, then migrating it to React Query 

OSS

• upptime - GitHub로 자동 운영되는 오픈소스 업타임 모니터 | GeekNews 
  • New Relic 같은 서비스를 이용하여 사이트의 업타임이나 접근 가능성을 주기적으로 체크하는 경우가 많을텐데, 이 프로젝트를 활용하면 큰 돈 들이지 않고도 적절하게 사이트 업타임을 모니터링할 수 있게 된다.
  • 개인 사이트에 바로 활용해봐도 좋겠고, 비지니스용 사이트도 여유가 된다면 도입 해서 나쁠 것은 없겠지.

Tools

• VS Code Syntax Highlighting on Keynote · GitHub 
  • 전에 대충 만들었던 슬라이드를 키노트로 다시 만들려다보니, 코드 붙여넣을 때 스타일을 어떻게 해야하나 하는 고민이 있었다. 그냥 VSCode에서 작성된 스타일 그대로 복붙이 가능하다.
• wunderpresentation 
  • 노션, 마크다운 등으로 작성된 문서를 프레젠테이션으로 변환해주는 도구
  • mdx-deck 같은것도 좋지만 거의 개발환경을 설정하듯이 만들어야 프레젠테이션을 만들 수 있던 것에 비해 조금 더 쉽게 프레젠테이션을 제작할 수 있다고 생각한다.
  • 그래도 mdx를 활용할 수 있는 mdx-deck 도 나름의 장점이 있으니 적절히 필요에 따라 사용하면 되겠지.