React, Next.js, Vue 실전 — 디자인 시스템, 성능 최적화, 접근성까지.
작년 10월에 React Compiler 1.0이 나왔을 때, 솔직히 반신반의했다. Meta가 자기네 앱에서 잘 돌아간다는 건 알겠는데, 내가 관리하는 5년 된 Next.js 프로젝트에서도 그럴까. 반년 정도 프로덕션에서 돌린 지금, 이야기할 게 좀 쌓였다. #300개의 useMemo가 사라진 월요일 Next.js 16.2에서 React Compiler 지
4월 24일이 뭐냐고? ADA Title II 디지털 접근성 규정의 준수 마감일이다. 미국 공공기관과 그 파트너사가 WCAG 2.1 Level AA를 의무적으로 맞춰야 하는 날짜. "우리는 한국 회사니까 상관없다"고? 글로벌 서비스 하나라도 걸려 있으면 이야기가 달라진다. 게다가 WCAG 2.2가 올해 안에 ISO 40500:2026으로
CI 파이프라인에서 린트 단계가 45초 걸릴 때는 아무도 신경 안 썼다. 빌드가 3분이었으니까. 그런데 Vite 8과 Turbopack 덕에 빌드가 40초로 줄어버리니, 린트 45초가 갑자기 병목으로 눈에 들어왔다. Biome를 도입하고 그 45초가 0.8초가 됐다. 문제는 .eslintrc.json이 아직 프로젝트 루트에 남아있다는 거다. #56배 빠르다
2019년쯤이었나. 프로젝트에서 node-sass를 dart-sass로 교체하고 나서 CI 빌드 시간이 40초 줄었을 때, 팀 슬랙에 "🎉" 리액션이 12개 달렸다. Sass 전처리기가 프론트엔드 빌드 체인에서 차지하는 무게를 체감한 순간이었다. 그로부터 7년, W3C가 CSS 네이티브 믹스인 스펙을 밀어붙이고 있고, Chrome 146
Cloudflare가 Astro를 인수하고 석 달이 지났다. 그리고 Astro 6가 나왔다. 릴리스 노트를 훑다가 한 줄에서 멈췄다 — "astro dev now runs on workerd." 이거, 생각보다 큰 얘기다. #"내 컴퓨터에선 되는데"의 진짜 원인 프론트엔드 개발자가 가장 많이 듣는 말이 뭐냐고 물으면 대부
금요일 밤 10시, npx @tailwindcss/upgrade를 돌렸다. "대부분의 프로젝트는 1~2시간이면 끝난다"는 공식 문서의 말을 믿었다. 3시간 반 뒤에도 나는 opacity 유틸리티를 수작업으로 고치고 있었다. #설정 파일이 통째로 사라졌다 이번 메이저 업데이트의 가장 큰 변화는 철학 자체의 전환이다. JavaScript 설정
React 진영에서 10년 넘게 "가상 DOM이면 충분하다"고 말해왔고, Vue는 Proxy 기반 반응성으로 나름의 영역을 지켰다. 그런데 Vue 3.6 베타가 나오면서 뭔가 이상한 일이 벌어졌다. Evan You가 @vue/reactivity의 핵심을 alien-signals라는 외부 라이브러리로 통째로 교체한 거다. 자기 집 엔진을 남
지난달 사이드 프로젝트 하나를 Next.js 16.2로 올리면서 viewTransition 플래그를 켜봤다. Framer Motion의 AnimatePresence와 motion.div로 라우트 전환을 처리하던 코드가 200줄 가까이 됐는데, React 19.2의 <ViewTransition> 컴포넌트로 교체하니 절반 이상이 증발했다. 번들에서
솔직히 고백하자면, 나는 Web Components에 세 번 데였다. 2018년에 Polymer로 사이드 프로젝트 만들다가 Shadow DOM 스타일링에서 포기했고, 2021년에 Lit 1.0 시절 써봤다가 SSR 불가능이라는 벽에 부딪혔고, 2023년에는 팀원 설득에 실패했다. "그냥 React 쓰면 되잖아요." 그런데 2026년 4월,
TypeScript 6.0이 3월 말에 정식 출시됐다. 새 기능? 거의 없다. 대신 tsconfig.json에서 쓰던 옵션 상당수에 deprecation 경고가 뜬다. 이게 왜 중요하냐면, 6.0이 JavaScript로 작성된 마지막 TypeScript 컴파일러이기 때문이다. 다음 메이저 버전은 Go로 재작성된 완전히 다른 엔진이고, 지금 뜨는 경고를 무시
구글이 3월 코어 업데이트에서 INP를 공식 랭킹 시그널로 격상시켰다. LCP 임계값도 2.5초에서 2.0초로 졸라맸다. 그런데 현실은? 전체 웹사이트의 43%가 아직도 Interaction to Next Paint 200ms 기준을 못 넘기고 있고, 그중 React·Next.js 기반 사이트의 실패율은 서버 렌더링이나 정적 사이트 대비 3배다. 프레임워크
3월 12일에 Vite 8이 정식 릴리스됐다. 이번 메이저 업데이트의 핵심은 단 하나, Rolldown이다. esbuild와 Rollup을 동시에 대체하는 Rust 기반 번들러가 디폴트 옵션으로 탑재됐다. 사내 프로젝트에 바로 올려봤고, 결론부터 말하면 돌아갈 생각이 없다. #왜 이중 번들러 체제가 문제였나 Vite를 써본 사람이라면 이 구조의 불편함을 한
올해가 KWCAG 2.2 공공기관 의무 적용 연도라는 걸 기억하는 프론트엔드 개발자가 몇이나 될까. "접근성은 퍼블리셔 일"이라고 넘기기엔, 2.2에서 추가된 9개 검사항목이 꽤나 JS 컴포넌트 레벨의 수정을 요구한다. 특히 React나 Vue 기반 SPA를 운영하는 팀이라면, 라우팅 전환 시 포커스 관리부터 동적 콘텐츠 알림까지 손봐야
#tooltip 위치 계산하던 JS, 이제 지워도 된다 tooltip 하나 제대로 만들려고 getBoundingClientRect() 호출하고, ResizeObserver 붙이고, 뷰포트 경계 체크하고, 화살표 방향 뒤집는 로직까지 — 솔직히 이게 2026년에도 필요한 코드인가 싶었다. Chrome 143에서 나온 Anchored Container Quer
Vercel이 최신 Next 릴리스에서 Turbopack 안정화보다 AGENTS.md 기본 포함과 에이전트 전용 브라우저 CLI를 앞세웠고, 프레임워크의 1순위 사용자를 사람에서 AI 에이전트로 바꾸고 있다는 신호가 뚜렷하다. 일주일 전 릴리스된 16.2의 헤드라인은 Turbopack 200건 수정이나 PPR 보안 패치가 아니다. create-next-ap