Ray Book

에세이

개발에 대한 생각을 자유롭게 정리하는 공간

  1. 93%가 통과하던 지표

    지표 하나를 바꾸자 같은 웹의 65%만 통과했다.

  2. 디스크 정리하다가 앱을 만들었다

    내 맥에서 111GB가 나왔다. 범인은 Xcode였다.

  3. TanStack npm 침해 사고

    들어온 경로는 의존성이 아니라 GitHub Actions 워크플로였다.

  4. Navigation API가 Baseline이 됐다

    라우터가 16년간 대신해온 일이 브라우저로 넘어가기 시작했다.

  5. 오버라이드는 왜 생기나

    컴포넌트를 덮어쓰는 건 규칙 위반이 아니라 쓰는 사람이 코드로 남긴 요구사항이다.

  6. CSS-in-JS 10여 년

    이 스타일링 방식이 어떻게 떴고 왜 밀려났는지, 무엇이 남았는지 정리했다.

  7. JS 도구들은 왜 네이티브로 갈아탈까

    셀프호스팅이라는 오랜 이상이 왜 무너졌고, 생태계는 그 대가로 무엇을 치르고 있나.

  8. React는 왜 재귀를 버렸을까

    Fiber의 진짜 효과는 5년 뒤 React 18에서야 드러났다.

  9. react-perfscope를 만들면서

    숫자는 이미 충분했다. 부족한 건 맥락이었다.

  10. 잘 짜는 것보다 잘 묻는 게 어렵다

    AI가 코드를 짜기 시작하면서 시니어라는 말이 가리키는 내용이 바뀌고 있다.

  11. AI가 옛날 지식을 못 버리는 이유

    공식 문서를 통째로 붙여줘도 모델은 예전 패턴으로 돌아간다. Knowledge Conflict라고 이름 붙은 현상이다.

  12. 이거, 함수로 빼야겠는데

    빨리 묶고 싶은 충동이 만든 부채 세 건을 되짚는다.

  13. Electron은 왜 안 밀려났을까

    대안이 풀려는 문제는 개발자의 불만이고, 사용자에게는 그게 잘 안 보인다.

  14. 캐시 무효화는 왜 아직도 어려울까

    30년 전 농담 한 줄이 지금 프레임워크에도 그대로 들어맞는다.

  15. StyleX는 너무 일찍 나왔다

    설계는 처음부터 앞서 있었는데 왜 다들 망설였을까.

  16. Netflix가 React를 뺀 이야기

    랜딩 페이지에서 클라이언트 React를 떼어낸 문제의식이 지금의 Next.js로 이어졌다.

  17. 되돌릴 수 있는 결정, 없는 결정

    git revert는 되지만 아키텍처 선택은 안 된다.

  18. React는 생각보다 대충 계산한다

    O(n³) 문제를 O(n)으로 줄인 건 정답 대신 충분히 좋은 답을 고른 결과다.

  19. TC39 Signals 제안 뜯어보기

    프레임워크마다 따로 놀던 반응성 시스템을 언어 차원에서 통일하자는 제안이다.

  20. FSD, 폴더 구조로 설계하기

    디렉터리 아키텍처가 왜 중요한지, FSD는 그 문제를 어떻게 푸는지 정리했다.

  21. 완성형이냐 헤드리스냐

    디자인시스템의 첫 갈림길. 답은 뭐가 더 좋냐가 아니라 뭘 만드느냐에 달렸다.

  22. 다시 SSR로, 근데 그 SSR은 아니다

    1세대 SSR과 3세대 SSR이 실제로 어떻게 다른지 짚어본다.

  23. Jotai냐 Zustand냐

    무엇이 더 좋은가보다 우리 프로젝트에 무엇이 맞는가.

  24. 하네스 엔지니어링, 새로운 게 있나

    2026년의 키워드가 된 이 말이 정말 새로운 분야인지 따라가봤다.