이 값의 주인이 누구인지부터 정한다
서버 상태와 클라이언트 상태를 Zustand 스토어 하나에 섞어 놨다가, 어떤 값을 언제 새로 받아야 하는지 아무도 답하지 못하게 됐습니다. 그 뒤로 정한 기준을 적었습니다.
Notes · 개발 노트
일하면서 직접 겪은 문제를 정리한 글입니다. 어느 프로젝트에서 나온 얘기인지 글마다 적어 뒀습니다.
상태관리1편
이 값의 주인이 누구인지부터 정한다
협업1편
백오피스는 하루 여덟 시간 쓰는 화면이다
아키텍처2편
Notion을 CMS로 썼더니 두 번째 사이트에서 막혔다 · 필터를 클라이언트 상태에 두면 안 되는 이유
성능2편
로딩 시간을 줄이지 않고 체감 속도를 올린 방법 · 혼자 쓰던 계산기에 사용자가 생겼을 때
기초2편
집계가 하루씩 밀린 이유는 UTC였다 · 클라이언트 검증과 서버 검증은 다른 일을 한다
회고1편
라이브러리를 고를 때 무엇을 보는가
서버 상태와 클라이언트 상태를 Zustand 스토어 하나에 섞어 놨다가, 어떤 값을 언제 새로 받아야 하는지 아무도 답하지 못하게 됐습니다. 그 뒤로 정한 기준을 적었습니다.
숙박 앱 관리자 시스템을 만들면서 알게 된 것들입니다. 개발자가 아닌 사람이 하루 종일 켜 놓고 쓰는 화면은 만드는 기준이 다릅니다.
관리자 시스템 없이 기업 사이트를 넘기려고 Notion을 CMS로 썼습니다. 첫 사이트는 잘 됐는데, 같은 구조를 계열사 사이트에 옮기면서 부족한 부분이 드러났습니다.
관광 사이트의 숙소 목록 필터를 useState로 만들었다가 URL로 옮겼습니다. 링크 공유, 뒤로 가기, 검색 색인이 한꺼번에 해결됐습니다.
이미지가 수십 장씩 들어가는 관광 사이트에서, 로딩 시간은 그대로 두고 사용자가 느끼는 속도를 바꾼 방법들입니다.
근태 계산기를 만들다가 시간대 때문에 집계가 하루씩 어긋났습니다. 저장은 UTC, 표시는 지역 시간으로 하라는 말이 왜 나왔는지 직접 겪은 기록입니다.
한 파일에 다 밀어 넣은 계산기를 네이버 카페에 공유했더니 사람들이 쓰기 시작했습니다. 그때부터 코드가 문제가 됐습니다.
블로그를 만들다가 다들 쓰던 라이브러리의 업데이트가 멈춘 걸 발견했습니다. 그 일로 라이브러리를 고르는 기준이 바뀌었습니다.
파일 첨부 문의 폼을 만들다가 확장자만 바꾼 파일이 그대로 통과하는 걸 봤습니다. 폼 검증에는 목적이 두 가지라는 걸 그때 알았습니다.