에세이
개발에 대한 생각을 자유롭게 정리하는 공간
좋은 질문이 좋은 답보다 귀하다
AI가 코드를 짜기 시작하면서 '시니어'라는 말이 가리키는 내용이 조금씩 바뀌고 있다. 코드를 잘 짜는 사람에서 질문을 잘 다듬는 사람 쪽으로.
AI는 모르는 게 아니라 못 버리는 거다, Knowledge Conflict라는 이름의 병목
Next.js 15 코드를 짜달라고 공식 문서를 통째로 붙여줘도 모델은 13 패턴으로 회귀한다. 이건 단순 무지가 아니다. 학계가 Knowledge Conflict라고 이름 붙인 현상이고, RAG가 만능이 아닌 이유이기도 하다.
좋은 추상은 항상 늦게 온다
두 군데에서 비슷한 코드를 본 순간 추상화하고 싶어진다. 그 충동이 만든 부채를 세 번 부검한다. HOC hell, 모든 상태를 Redux로 넣던 시기, 그리고 지금도 진행 중인 커스텀 훅의 과도한 분해까지.
Electron은 이기지 않았다, 비교할 대상이 없었을 뿐이다
Tauri도 Wails도 Electron을 못 이긴 건 기술 문제가 아니다. 대안이 풀려는 문제는 개발자의 불만이고, 사용자는 그 문제를 가지고 있지 않다. 1Password, Slack, Linear가 증명하는 구조적 비대칭.
캐시 무효화는 왜 30년째 풀리지 않는가, Phil Karlton의 한 줄과 현대 프레임워크의 절반
1996년 Netscape 엔지니어가 남긴 한 줄의 농담이 왜 2026년의 우리 프레임워크를 설명하는가. 캐시 무효화가 안 풀리는 건 기술이 부족해서가 아니다.
한 번 식었다가 앞서버린, StyleX
2024년엔 다들 반신반의했던 Meta의 스타일링 시스템이 어느새 이 카테고리에서 가장 앞선 설계가 됐다. 그 사이에 무슨 일이 있었는지, 기술적으로 뭐가 특별한지.
Netflix는 왜 React를 걷어냈는가, 2017년의 답이 프레임워크의 디폴트가 되기까지
Netflix가 랜딩 페이지에서 클라이언트 React를 떼어낸 결정에서 시작해, 그 문제의식이 어떻게 Next.js의 오늘로 이어졌는지, 그 여정이 개발자에게 남기는 질문을 따라간다
되돌릴 수 없는 결정과 소프트웨어 설계
git revert는 되지만 아키텍처 선택은 안 된다. 되돌릴 수 없는 결정의 존재가 소프트웨어 설계의 근본 원칙들을 만들어냈다는 이야기.
React의 휴리스틱으로 바라본 공학적 사고
O(n³)을 O(n)으로 만든 React의 Diffing 알고리즘. 완벽한 정답 대신 충분히 좋은 답을 선택하는 공학의 본질에 대한 이야기.
TC39 Signals, 리액티비티의 공용어가 될 수 있을까
React를 제외한 거의 모든 프레임워크가 손을 잡았다. 프레임워크마다 따로 놀던 반응성 시스템을 언어 차원에서 통일하겠다는 제안, TC39 Signals의 이야기.
FSD, 폴더 구조가 설계가 되는 순간
Feature-Sliced Design을 실제 프로젝트에 적용해보니, 어느 순간부터 코드가 어디에 있어야 하는지 고민하지 않게 됐다. 디렉토리 아키텍처가 왜 중요한지, FSD는 그 문제를 어떻게 푸는지에 대한 이야기.
완성형 컴포넌트 vs 헤드리스, 디자인시스템의 첫 번째 갈림길
Ant Design 같은 완성형 컴포넌트의 편함과 Radix UI 같은 헤드리스의 유연함. 뭐가 더 좋냐가 아니라, 뭘 만드느냐에 따라 답이 달라진다.
SSR로의 회귀? 아니, 나선형 진보
PHP에서 SPA로, 다시 SSR로, 같은 자리로 돌아온 것 같지만 한 단계 위에서 돌아왔다. 1세대 SSR과 3세대 SSR이 본질적으로 어떻게 다른지에 대한 이야기.
Jotai vs Zustand, 무엇이 더 나은가가 아니라, 무엇이 우리에게 맞는가
두 라이브러리를 줄세우는 비교 글이 많지만, 정작 중요한 질문은 '무엇이 더 좋은가'가 아니라 '우리 프로젝트에 무엇이 맞는가'다.
하네스 엔지니어링은 새로운 것이 아니다
2026년 AI 업계의 뜨거운 키워드, 하네스 엔지니어링. 과연 새로운 엔지니어링 분야인가, 원래 해야 했던 일에 이름을 붙인 것인가.