에세이
개발에 대한 생각을 자유롭게 정리하는 공간
Navigation API가 드디어 Baseline이 됐다
SPA 라우터가 하는 일은 대부분 브라우저가 안 해주는 일을 대신하는 것이다. pushState 위에 클릭 가로채기, 스크롤 복원, 포커스 관리를 직접 구현해온 16년. Navigation API가 Baseline이 되면서 이 일들이 브라우저로 넘어가기 시작했다.
디자인시스템은 고쳐 쓰는 사람이 키운다
컴포넌트를 고쳐 쓰면 보통 규칙 위반이라고 막는다. 근데 그건 쓰는 사람이 코드로 적어놓은 요구사항이다. 막으면 항의가 오는 게 아니라 팀 폴더에 새 컴포넌트가 하나 생긴다.
CSS-in-JS 10여 년 돌아보기
styled-components의 등장부터 유지보수 모드 선언까지. 한 시대를 만든 스타일링 방식이 어떻게 떴고 왜 밀려났는지, 그 아이디어 중 무엇이 살아남았는지 정리했다.
JS 도구들은 왜 다 네이티브로 갈아탈까
TypeScript 컴파일러는 Go로, Vite의 번들러는 Rust로 다시 쓰였다. 셀프호스팅이라는 오랜 이상이 왜 무너졌는지, 그 대가로 생태계가 무엇을 치르고 있는지 정리했다.
React는 왜 재귀를 버렸을까, Stack에서 Fiber로
React 16이 스택 재조정기를 버리고 Fiber를 도입했을 때 당장 체감되는 건 거의 없었다. 진짜 효과는 5년 뒤 React 18에서야 드러났고, 그 사이 우리가 짜는 컴포넌트에는 지켜야 할 규칙이 하나 생겼다.
성능 도구를 직접 만들어보고 알게 된 것, react-perfscope
Chrome 탭에도 React Profiler에도 숫자는 이미 충분하다. 부족한 건 맥락이었다. React 성능 프로파일러를 직접 만들면서 성능이라는 문제를 다시 보게 된 이야기.
잘 짜는 것보다 잘 묻는 게 어렵다
AI가 코드를 짜기 시작하면서 '시니어'라는 말이 가리키는 내용이 조금씩 바뀌고 있다. 코드를 잘 짜는 사람에서 질문을 잘 다듬는 사람 쪽으로.
AI가 옛날 지식을 못 버리는 이유, Knowledge Conflict
Next.js 15 코드를 짜달라고 공식 문서를 통째로 붙여줘도 모델은 13 패턴으로 회귀한다. 이건 단순 무지가 아니다. 학계가 Knowledge Conflict라고 이름 붙인 현상이고, RAG가 만능이 아닌 이유이기도 하다.
좋은 추상화는 원래 늦게 온다
두 군데에서 비슷한 코드를 본 순간 추상화하고 싶어진다. 그 충동이 만든 부채 세 건을 되짚는다. HOC hell, 모든 상태를 Redux로 넣던 시기, 그리고 지금도 진행 중인 커스텀 훅의 과도한 분해까지.
Electron은 경쟁자가 없어서 이겼다
Tauri도 Wails도 Electron을 못 넘어선 건 기술 문제가 아니다. 대안이 풀려는 문제는 개발자의 불만이고, 사용자에게는 그 문제가 없다. 1Password, Slack, Linear 사례로 살펴본 개발자와 사용자의 동상이몽.
캐시 무효화는 왜 아직도 어려울까
1990년대 Netscape 엔지니어가 남긴 농담 한 줄이 2026년의 프레임워크까지 설명한다. 캐시 무효화가 안 풀리는 건 기술이 부족해서가 아니다.
StyleX는 너무 일찍 나왔다
2024년엔 다들 반신반의했던 Meta의 스타일링 시스템이 결국 살아남았다. 설계는 처음부터 이 카테고리에서 가장 앞서 있었는데, 왜 다들 망설였는지.
Netflix가 랜딩 페이지에서 React를 뺀 이야기
Netflix가 랜딩 페이지에서 클라이언트 React를 떼어낸 결정에서 시작해, 그 문제의식이 어떻게 Next.js의 오늘로 이어졌는지, 그 과정이 개발자에게 남기는 질문을 따라간다.
되돌릴 수 있는 결정, 없는 결정
git revert는 되지만 아키텍처 선택은 안 된다. 되돌릴 수 없는 결정이 있기 때문에 소프트웨어 설계의 근본 원칙들이 생겼다는 이야기.
React는 생각보다 대충 계산한다
O(n³)을 O(n)으로 만든 React의 Diffing 알고리즘. 완벽한 정답 대신 충분히 좋은 답을 고르는 공학의 본질을 짚어본다.
TC39 Signals 제안 뜯어보기
React만 빠지고 나머지 주요 프레임워크가 대부분 참여했다. 프레임워크마다 따로 놀던 반응성 시스템을 언어 차원에서 통일하겠다는 제안, TC39 Signals의 이야기.
FSD, 폴더 구조로 설계하기
Feature-Sliced Design을 실제 프로젝트에 적용해보니, 어느 순간부터 코드가 어디에 있어야 하는지 고민하지 않게 됐다. 디렉터리 아키텍처가 왜 중요한지, FSD는 그 문제를 어떻게 푸는지 정리했다.
완성형이냐 헤드리스냐, 디자인시스템 첫 고민
Ant Design 같은 완성형 컴포넌트의 편함과 Radix UI 같은 헤드리스의 유연함. 뭐가 더 좋냐가 아니라, 뭘 만드느냐에 따라 답이 달라진다.
다시 SSR로, 근데 옛날 그 SSR은 아니다
PHP에서 SPA로, 다시 SSR로. 제자리로 돌아온 것 같지만 한 칸 위에서 돌아왔다. 1세대 SSR과 3세대 SSR이 실제로 어떻게 다른지 짚어본다.
Jotai냐 Zustand냐, 고르는 기준
두 라이브러리를 줄세우는 비교 글이 많지만, 정작 중요한 질문은 '무엇이 더 좋은가'가 아니라 '우리 프로젝트에 무엇이 맞는가'다.
하네스 엔지니어링, 사실 새로운 건 없다
2026년 AI 업계의 뜨거운 키워드, 하네스 엔지니어링. 과연 새로운 엔지니어링 분야인가, 원래 해야 했던 일에 이름을 붙인 것인가.