Vite — 거짓말 안 하는 dev
Webpack 시대 빌드 도구는 느린 production 빌드와 빠르지만 다른 dev 빌드를 따로 유지했어. 그러니 dev에선 멀쩡하고 prod에서만 터지는 버그가 숨어들기 쉬웠지. Vite의 dev server는 ESM-native야. browser가 module을 요청할 때 필요한 것만 바꿔서 건네고, production은 Vite 8의 Rust 기반 bundler인 Rolldown이 묶어.
cwkPippa에서 얻는 실용적 효과는 단순해. 코드를 저장하면 chat 화면이 거의 즉시 바뀌고, HMR이 가능하면 컴포넌트 상태도 보존해. 다만 빠른 dev server가 production 검증을 대신하진 않아. 마지막 판단은 언제나 production build와 실제 served route가 해.
Tailwind 4 — utility-first, CSS-native config
Tailwind 4는 JavaScript config 중심 방식에서 CSS-native @theme 블록으로 옮겨 갔어. design token이 CSS에 있으니 쓰이는 곳과 가깝고, CSS 변수와도 자연스럽게 이어져.
왜 utility-first일까? 실제 앱에선 픽셀 수준의 차이를 빨리 ship해야 하는데, 맞는 CSS 파일과 selector를 찾아 헤매는 순간 흐름이 끊겨. JSX 옆의 p-4 rounded-lg bg-bg-elevated는 멀리 떨어진 sibling 파일의 스타일보다 읽고 고치고 지우기 쉬워.
사실 빌드 도구와 스타일 도구의 공통 목표는 기술 선택을 자랑하는 게 아니야. 수정한 사람이 결과까지 가는 거리를 줄이는 거지. 그래서 HMR이 빠르다는 말보다 중요한 질문은 이거야. 수정 뒤 production build가 같은 계약을 지키나? utility가 편하다는 말보다 중요한 질문도 이거고. 같은 디자인 결정을 여러 화면에서 조용히 공유하나? 속도는 검증과 일관성을 데리고 올 때만 자산이야.
도구 이름은 바뀌어도 이 판단 기준은 안 바뀌어. local feedback은 빨라야 하고, production 결과는 재현돼야 하며, design token은 한 군데서 설명돼야 해. 셋 중 하나라도 빠지면 빠른 화면 만들기가 아니라 빠른 drift 만들기야.