이 값의 주인이 누구인지부터 정한다
서버 상태와 클라이언트 상태를 한 스토어에 섞었다가 무효화 시점을 아무도 답할 수 없게 된 경험. 경계를 긋는 기준을 정리했습니다.
Notes · 개발 노트
책 내용을 옮겨 적은 글은 없습니다. 실제로 잘못 만들었다가 문제를 겪고, 고치면서 그제야 이해한 것들만 적습니다. 그래서 글마다 어느 프로젝트에서 나온 이야기인지 밝혀 뒀습니다.
상태관리1편
이 값의 주인이 누구인지부터 정한다
협업1편
백오피스는 남의 하루를 줄여주는 일이다
아키텍처2편
Notion을 CMS로 쓰기, 그리고 두 번째 프로젝트에서 알게 된 것 · 필터를 클라이언트 상태에 두면 안 되는 이유
성능2편
빠른 것과 빠르게 느껴지는 것은 다르다 · 혼자 쓰던 계산기에 사용자가 생겼을 때
기초2편
집계가 하루씩 밀린 이유는 UTC였다 · 클라이언트 검증과 서버 검증은 다른 일을 한다
회고1편
라이브러리를 고를 때 무엇을 보는가
서버 상태와 클라이언트 상태를 한 스토어에 섞었다가 무효화 시점을 아무도 답할 수 없게 된 경험. 경계를 긋는 기준을 정리했습니다.
숙박 앱 관리자 시스템을 만들며 배운 것. 개발자가 아닌 사람이 매일 여덟 시간 쓰는 화면에서는 기준이 달라집니다.
관리자 시스템을 만들지 않고 기업 사이트를 넘기는 방법. 첫 프로젝트는 잘 됐고, 두 번째 프로젝트에서 무엇이 부족했는지 드러났습니다.
관광 사이트의 숙소 목록 필터를 useState로 만들었다가 URL로 옮기면서 알게 된 것들. 공유·뒤로 가기·검색 색인이 한꺼번에 따라왔습니다.
이미지가 수십 장씩 들어가는 관광 사이트에서 로딩 시간을 줄이지 않고도 체감 품질을 바꾼 방법들.
근태 계산기를 만들다 시간대 때문에 집계가 어긋났습니다. 저장은 UTC, 표시는 지역 시간이라는 원칙이 왜 필요한지 직접 부딪히며 배운 기록.
한 파일에 다 밀어 넣은 계산기를 네이버 카페에 공유했더니 사람들이 쓰기 시작했습니다. 그때부터 코드가 문제가 됐습니다.
블로그를 만들려다 사실상 표준처럼 쓰이던 라이브러리의 업데이트가 멈춘 걸 발견했습니다. 그때 기준이 바뀌었습니다.
파일 첨부 문의 폼을 만들다 확장자만 바꾼 파일이 그대로 통과하는 걸 보고 알게 된 것. 검증에는 목적이 두 개입니다.
모든 노트는 실제 프로젝트에서 겪은 문제에서 출발합니다. 각 글 하단에는 관련 작업으로 가는 링크가 있고, 반대로 작업 상세 페이지에도 그 프로젝트에서 나온 노트가 연결되어 있습니다.
작업 원장 보기