frontend-briefing-2026-04-20-KST

01-tanstack-rsc.md

React Server Components Your Way, 한국어 번역

• 원문 제목: React Server Components Your Way
• 원문 링크: https://tanstack.com/blog/react-server-components
• 번역일: 2026-04-20 KST
• 커뮤니티 발견: Hacker News, This Week in React #277

번역

TanStack 팀은 늘 같은 철학을 강조해 왔다. 90%의 일반적인 요구는 쉽게 해결하되, 나머지 10%의 고급 요구에서는 프레임워크가 개발자를 가두지 말아야 한다는 것이다. React Server Components(RSC)도 같은 관점으로 접근했다.

글은 먼저 RSC 자체를 부정하지 않는다. 무거운 렌더링 로직을 클라이언트에서 서버로 옮기고, 자주 바뀌지 않는 콘텐츠를 더 세밀하게 캐시할 수 있다는 점에서 RSC는 분명 강력한 원시 도구라고 본다. Markdown 파싱, 코드 하이라이팅, 날짜 포매팅, 검색 인덱싱, 콘텐츠 변환 같은 일은 특히 RSC와 궁합이 좋다.

다만 현재 많은 RSC 프레임워크는 "서버가 트리를 소유하는 구조"를 기본 전제로 둔다. 서버가 전체 트리를 잡고, use client 로 인터랙티브한 부분을 표시하고, 프레임워크 관례가 렌더링과 재조합 방식을 거의 전부 결정한다. TanStack는 바로 이 지점을 문제로 본다. 단지 RSC의 이점을 얻기 위해 앱 전체가 서버 우선 구조를 중심으로 재편되어야 하는가, 라는 질문이다.

TanStack Start의 핵심 아이디어는 간단하다. RSC를 특수한 프레임워크 전용 개념이 아니라, "클라이언트가 가져오고(fetch), 캐시하고(cache), 렌더링(render)할 수 있는 React Flight 스트림"으로 취급하자는 것이다. 즉 RSC를 JSON 데이터처럼 더 잘게, 더 명시적으로 사용할 수 있게 만들겠다는 접근이다.

이 접근을 위해 글은 세 가지 원시 API를 제시한다.

• renderToReadableStream: 서버에서 React 엘리먼트를 Flight 스트림으로 렌더링한다.
• createFromReadableStream: 클라이언트나 SSR 환경에서 Flight 스트림을 다시 React 엘리먼트 트리로 복원한다.
• createFromFetch: fetch 응답으로부터 직접 RSC를 디코딩한다.

중요한 포인트는 이 과정에 "숨겨진 특별 프로토콜"이 없다는 점이다. 표준 Flight 스트림이 들어오고, React 엘리먼트가 나온다. 그래서 RSC를 기존 데이터 흐름과 자연스럽게 결합할 수 있다.

캐시 전략도 새로 배우지 않아도 된다

글은 RSC의 캐시 전략을 새로 발명할 필요가 없다고 강조한다. RSC가 그냥 데이터가 되면, 캐시도 기존 도구를 그대로 쓸 수 있다.

• TanStack Query에서는 일반 async query처럼 다룰 수 있다. queryKey, staleTime, background refetch 같은 기존 기능을 그대로 활용한다.
• TanStack Router에서는 loader 결과를 캐시하듯 RSC도 같은 방식으로 저장하고 재사용할 수 있다.
• CDN 레벨에서도 GET 서버 함수 응답을 일반 HTTP 응답처럼 캐시할 수 있다.

즉 RSC를 도입했다고 해서 캐시 전략 전체를 다시 학습하거나, 프레임워크 고유의 블랙박스를 받아들일 필요가 없다는 주장이다.

보안 관점에서 use server 액션을 의도적으로 배제

TanStack Start는 use server 액션을 지원하지 않는다. 최근 RSC 생태계에서 나온 여러 CVE가 서버 함수와 Flight payload 처리 경계에서 발생했다는 점을 의식한 설계다. 대신 createServerFn 기반의 명시적 RPC 호출을 사용한다. 글은 이것이 네트워크 경계를 더 분명하게 만들고, 직렬화, 검증, 미들웨어 처리를 더 의식적으로 설계하게 해 공격면을 줄인다고 설명한다.

RSC가 특히 잘 맞는 경우와 아닌 경우

TanStack 팀은 tanstack.com의 콘텐츠 중심 영역을 실제로 RSC 기반으로 옮기고 수치를 공유했다.

• 블로그 글 페이지는 gzipped client JS가 약 153KB 감소했다.
• 문서 페이지도 약 153KB 감소했다.
• 예제 문서 페이지는 약 40KB 감소했다.
• 특정 페이지의 Lighthouse 점수는 52에서 74로 상승했고, Total Blocking Time은 1200ms에서 260ms로 줄었다.

하지만 글은 RSC가 만능 성능 쿠폰은 아니라고 선을 긋는다. 이미 인터랙션 중심인 대시보드, 빌더, 장시간 유지되는 앱 세션 같은 화면은 RSC를 넣는다고 자동으로 빨라지지 않는다. 실제로 클라이언트에서 하던 무거운 일을 제거할 때만 큰 효과가 난다.

그래서 이 글의 결론은 "모든 라우트를 서버 컴포넌트로 바꿔라"가 아니다. 콘텐츠가 무겁고, 정적이거나, 의존성이 큰 영역에서는 강력하고, 상태와 상호작용이 중심인 앱 화면에서는 이득이 제한적일 수 있다는 현실적인 정리다.

Composite Components라는 새로운 조합 방식

글의 후반부에서 가장 흥미로운 부분은 Composite Components다. 기존 use client 모델은 서버가 렌더링할 클라이언트 컴포넌트의 위치를 결정한다. 반면 Composite Components는 서버가 슬롯만 남기고, 실제로 어떤 클라이언트 UI를 꽂아 넣을지는 클라이언트가 결정한다.

예를 들어 서버는 게시글 본문과 다음 글 링크를 렌더링하면서,

• renderPostActions 같은 슬롯으로 클라이언트 액션 영역을 비워둘 수 있고
• children 슬롯으로 댓글 컴포넌트 같은 것을 받게 할 수 있다.

이 방식의 핵심은 서버가 클라이언트 컴포넌트를 검사하거나 변형하지 못하고, 그냥 "여기에 무언가 온다"는 합류 지점만 정의한다는 것이다. 덕분에 클라이언트는 서버에서 받은 조각을 자기 상태, provider, 레이아웃, 조건부 렌더링과 다시 조합할 수 있다.

정리

이 글이 주는 실무적 메시지는 명확하다.

1. RSC는 프레임워크 전체를 서버 우선으로 재편해야만 쓸 수 있는 기능일 필요가 없다.
2. RSC를 스트리밍 가능한 데이터로 보면 Query, Router, CDN 등 기존 도구와 자연스럽게 통합된다.
3. 성능 이점은 콘텐츠 중심 화면에서 특히 크며, 인터랙션 중심 화면에서는 냉정하게 비용 대비 효과를 봐야 한다.
4. Composite Components처럼 서버와 클라이언트의 경계를 더 명시적으로 만드는 접근은 앞으로 React 아키텍처 논의를 꽤 흔들 가능성이 있다.

현재 시점에서 TanStack Start의 RSC 지원은 실험적이지만, "RSC를 프레임워크의 신앙이 아니라 도구로 되돌리자"는 제안 자체는 아주 강하다.

02-github-diff-performance.md

The Uphill Climb of Making Diff Lines Performant, 한국어 번역

• 원문 제목: The uphill climb of making diff lines performant
• 원문 링크: https://github.blog/engineering/architecture-optimization/the-uphill-climb-of-making-diff-lines-performant/
• 번역일: 2026-04-20 KST
• 커뮤니티 발견: This Week in React #277

번역

GitHub는 PR 리뷰가 서비스의 심장이라고 말한다. 문제는 GitHub 규모의 PR은 한두 줄 수정부터 수천 개 파일, 수백만 줄 변경까지 폭이 너무 크다는 점이다. 그래서 Files changed 탭은 작은 PR에서는 당연히 빨라야 하고, 거대한 PR에서도 완전히 무너지면 안 된다.

이 글은 React 기반 새 Files changed 경험을 기본값으로 전환하면서 어떤 성능 문제를 해결했는지를 설명한다. 최적화 전에는 극단적인 PR에서 JavaScript heap이 1GB를 넘고, DOM 노드 수가 40만 개를 넘어가며, 상호작용이 체감될 정도로 느려졌다고 한다. INP도 허용 범위를 넘어서 입력 지연이 분명하게 느껴졌다.

GitHub는 여기서 "은탄환 하나"를 찾지 않았다. 대신 PR 크기와 복잡도별로 다른 전략을 조합했다.

• 일반적인 중대형 PR에서는 diff line 자체를 가볍게 만드는 최적화
• 초대형 PR에서는 virtualization으로 우아하게 성능 저하를 제어하는 전략
• 어떤 크기의 PR이든 효과가 누적되는 기반 컴포넌트와 렌더링 개선

v1의 문제: 한 줄이 너무 비쌌다

초기 React 버전(v1)에서는 diff 한 줄을 렌더링하는 비용이 컸다.

• unified view 한 줄당 DOM 요소가 대략 10개
• split view 한 줄당 DOM 요소가 대략 15개
• syntax highlighting이 들어가면 <span> 이 더 늘어나 DOM이 더 커짐
• React 컴포넌트도 unified에서 최소 8개, split에서 최소 13개
• 한 줄에 20개 이상의 event handler가 붙기도 함

처음에는 작은 재사용 컴포넌트를 많이 쪼개는 방식이 좋아 보였지만, 대규모 PR에서는 이 비용이 누적되어 크게 터졌다. 작은 컴포넌트마다 이벤트 핸들러가 달리고, split/unified 양쪽을 위한 공통 래퍼가 불필요한 로직을 함께 들고 다니면서 오버헤드가 커졌다.

v2의 방향: 단순화

GitHub는 성능 개선 목표를 세 가지로 잡았다.

• 메모리와 JS heap 줄이기
• DOM node 수 줄이기
• 평균 INP와 p95/p99 개선하기

핵심 전략은 단순화였다. 상태를 줄이고, 엘리먼트를 줄이고, JavaScript를 줄이고, React 컴포넌트를 줄이는 것.

작은 변경도 무시하지 않았다. 예를 들어 line number 셀에서 불필요한 <code> 태그 두 개를 제거하면, 1만 줄 PR에서는 DOM 노드 2만 개가 줄어든다. 이런 식의 사소한 감축이 실제로는 큰 차이를 만들었다.

v2에서는 한 줄당 컴포넌트 수를 8개에서 2개 수준으로 낮췄다. split/unified 전용 컴포넌트를 각각 따로 두어 일부 중복을 감수했지만, 대신 데이터 접근과 렌더링 구조가 훨씬 단순해졌다.

이벤트와 상태도 위로 올리고, 필요한 곳에만 둠

이벤트 처리도 각 줄마다 핸들러를 붙이지 않고, 상위 레벨 핸들러 하나가 data-* 속성을 보고 동작하게 바꿨다. 예를 들어 드래그로 여러 줄을 선택할 때도 각 라인이 자기 함수를 가지는 대신, 상위 핸들러가 어떤 줄이 선택 중인지 판별한다.

또 댓글 작성 상태나 컨텍스트 메뉴 상태처럼 복잡한 상태를 diff line 본체에 다 얹어 두지 않았다. 실제로 댓글이나 메뉴가 열리는 줄은 일부뿐인데, 모든 줄이 그 상태를 들고 있을 이유가 없기 때문이다. 그래서 이런 상태는 조건부로 렌더링되는 자식 컴포넌트로 밀어 넣었다. 글은 이것이 Single Responsibility Principle에도 더 맞는 구조라고 설명한다.

useEffect 축소와 O(1) 조회

실무적으로 특히 눈에 띄는 부분은 여기다. GitHub는 v1에서 흩어진 useEffect 와 O(n) 조회가 렌더링 비용과 재렌더를 키운다고 봤다.

그래서 v2에서는:

• useEffect 사용을 diff 파일 최상단으로 엄격히 제한하고
• line wrapper 같은 하위 컴포넌트에는 effect를 넣지 못하게 lint 규칙까지 추가했으며
• 공용 상태와 diff 상태 머신을 Map 기반으로 바꿔 O(1) 조회를 가능하게 만들었다.

예를 들어 특정 파일의 특정 줄에 댓글이 있는지 확인할 때, 선형 탐색 대신 commentsMap[path][line] 형태의 즉시 조회를 쓰게 만든 것이다. 이건 성능뿐 아니라 코드의 예측 가능성도 높인다.

수치로 본 개선 결과

10,000줄 diff를 split view로 비교한 측정에서:

• 전체 코드 라인 수: 2,800 → 2,000, 약 27% 감소
• 고유 컴포넌트 타입 수: 19 → 10, 약 47% 감소
• 렌더된 전체 컴포넌트 수: 약 183,504 → 50,004, 약 74% 감소
• DOM 노드 수: 약 200,000 → 180,000, 약 10% 감소
• 메모리 사용량: 약 150250MB → 80120MB, 대략 절반 수준
• INP: 약 450ms → 100ms, 약 78% 개선

초대형 PR은 virtualization으로 대응

p95 이상 규모, 즉 diff line이 1만 줄을 넘는 초대형 PR에서는 아무리 컴포넌트를 최적화해도 한 번에 다 렌더링하면 한계가 있었다. 그래서 GitHub는 TanStack Virtual을 도입해 화면에 보이는 부분만 DOM에 유지했다.

그 결과 p95+ PR에서는:

• JS heap과 DOM 노드가 10배 수준으로 감소했고
• INP가 275700ms 이상에서 4080ms 수준으로 내려갔다.

즉 평상시에는 브라우저 기본 동작과 find-in-page 같은 경험을 유지하고, 초대형 PR에서는 가상화로 살아남는 이중 전략을 취한 셈이다.

기타 최적화도 실무 감각이 좋다

글은 추가로 다음도 언급한다.

• :has(...) 같은 무거운 CSS selector 제거
• 드래그/리사이즈를 GPU transform 기반으로 재설계
• interaction 단위 INP 추적, diff 크기별 세분화, 메모리 tagging을 Datadog 대시보드로 모니터링
• 서버에서 보이는 diff line만 hydrate
• progressive diff loading과 background fetch로 초기 체감 속도 개선

정리

이 글의 핵심은 결국 "대규모 UI 성능 개선은 화려한 마법보다 단순화의 누적"이라는 점이다.

• 컴포넌트 수를 줄이고
• DOM을 줄이고
• 상태를 필요한 곳에만 두고
• 이벤트를 위임하고
• effect를 제한하고
• 조회를 O(1)로 바꾸고
• 정말 큰 경우에는 가상화를 쓰는 것

이 조합이 결과적으로 React 기반 대형 UI를 다시 빠르게 만들었다. FE 실무에서는 특히 useEffect 억제, 상태 국소화, 이벤트 위임, Map 기반 상수 시간 조회, 그리고 "중복을 조금 허용해도 더 단순한 구조가 낫다"는 메시지가 꽤 직접적으로 와닿는다.

03-vertical-codebase.md

The Vertical Codebase, 한국어 번역

• 원문 제목: The Vertical Codebase
• 원문 링크: https://tkdodo.eu/blog/the-vertical-codebase
• 번역일: 2026-04-20 KST
• 커뮤니티 발견: This Week in React #277

번역

이 글은 코드베이스를 components / hooks / types / utils / constants 같은 식으로 나누는 전통적인 수평 분할(horizontal split)을 강하게 비판한다. 이유는 간단하다. 이 구조는 "무슨 일을 하는 코드인가"가 아니라 "어떤 종류의 파일인가"를 기준으로 묶기 때문이다.

예를 들어 useTheme 와 useTodo 가 같은 hooks 폴더에 있지만, ThemeProvider 나 todo 화면 근처에는 없게 된다. 처음 프로젝트를 열 때는 이런 구조가 편해 보일 수 있다. 대부분의 파일이 컴포넌트고, 나머지 폴더는 몇 개 안 되기 때문이다. 하지만 시간이 지나고 코드가 커지면 바로 탐색성과 변경 비용이 무너진다.

글은 Sentry 코드베이스를 예로 든다. 10년 넘게 수평 구조를 유지한 결과 top-level components 디렉터리에 200개가 넘는 파일이 쌓였다. 그 파일들의 공통점은 "컴포넌트다"뿐이다. 기능적 관련성은 거의 없다. 결국 무언가를 찾으려면 어디서부터 찾아야 할지조차 모른다.

인간뿐 아니라 AI 에이전트에게도 구조가 중요하다

글쓴이는 요즘 에이전트 시대를 언급하면서도, 오히려 그럴수록 구조가 더 중요하다고 말한다. 사람과 에이전트 모두 효율적으로 일하려면 경계, 제약, 빠른 피드백 루프가 필요하다. 탐색하기 쉬운 프로젝트 구조, 좋은 lint 규칙, 강한 TypeScript 설정, 빠르고 안정적인 테스트는 에이전트에게도 그대로 도움이 된다.

즉 "AI가 다 알아서 고쳐줄 테니 구조는 중요하지 않다"는 태도는 현실적이지 않다는 주장이다. 유기적으로 오래 자란 코드베이스일수록 구조가 생산성을 결정한다.

핵심 원칙: 같이 바뀌는 코드는 같이 있어야 한다

글의 중심 문장은 이거다.

Code that changes together should live together.

예를 들어 Widget 컴포넌트의 props 타입은 대부분 컴포넌트 파일 안에 같이 둔다. 왜냐하면 읽을 때 함께 보고 싶기 때문이다. 그런데 여기에 데이터 패칭이 추가되면, 수평 구조에서는 widgetQueryOptions 같은 것이 갑자기 utils/widget.ts 로 가버린다. 기술적으로는 util이지만, 논리적으로는 Widget의 일부다.

결국 수평 구조는 응집도(cohesion)를 낮추고, 관련 없는 코드끼리 묶어 버린다. utils 폴더는 특히 "컴포넌트도 훅도 아닌 모든 것"이 쌓이는 잡동사니 창고가 되기 쉽다.

대안: 수직 분할(vertical structure)

이 글이 제안하는 방식은 도메인 중심 구조다. 예를 들어 widget 관련 코드는 전부 src/widgets/ 아래에 둔다.

• 컴포넌트
• 훅
• 타입
• 쿼리 옵션
• 유틸
• 상수

무엇이든 상관없다. 중요한 것은 기술적 종류가 아니라 기능적 목적이다. 이렇게 하면 "이 코드가 무엇을 하는가"를 알 때 찾기가 훨씬 쉬워지고, 변경도 한 영역 안에서 끝나는 경우가 많아진다.

이 방식은 팀 구조와도 잘 맞는다. 실제 조직도 billing 팀, dashboard 팀, profiling 팀처럼 도메인 단위로 일하는데, 코드만 types/util/components 기준으로 갈라놓는 것은 오히려 현실과 어긋난다는 지적이다.

공유 영역도 도메인으로 다룬다

수직 구조를 제안하면 흔히 "여러 화면에서 같이 쓰는 코드는 어디에 두나"라는 질문이 나온다. 글의 대답은 그 자체를 하나의 수직(vertical)로 보라는 것이다.

예를 들어 여러 화면이 함께 쓰는 PageFilters 는 그냥 공용 유틸이 아니라, pageFilters 라는 독립된 도메인으로 볼 수 있다. 이 코드는 components 폴더, types 폴더, utils 폴더로 흩어져 있을 때보다, src/pageFilters/ 안에 모여 있을 때 훨씬 발견하기 쉽고 ownership도 명확해진다.

응집도만으로는 부족하고, 경계도 필요하다

관련 코드를 모으는 것만으로는 충분하지 않다. 어떤 코드는 외부에서 써도 되고, 어떤 코드는 내부 전용인지 경계를 정해야 한다. 글은 가장 좋은 방식으로 monorepo를 제안한다.

• 각 vertical을 하나의 패키지처럼 두고
• package.json 의 exports 로 public interface를 정의하고
• pnpm workspace 같은 도구로 의존성을 명시적으로 관리한다.

이렇게 하면 어떤 vertical이 어떤 vertical에 의존하는지 드러난다. Nx처럼 프로젝트 간 의존성 규칙을 강제하는 도구도 쓸 수 있다. monorepo가 아니어도 eslint-plugin-boundaries 같은 도구로 deep import를 막고 경계를 세울 수 있다.

트레이드오프도 있다

글은 공짜 점심은 없다고 인정한다.

• 어떤 코드를 어느 vertical에 둘지 판단하는 일은 어렵다.
• private 코드를 강조하면 팀별로 비슷한 것을 중복 구현할 위험도 있다.

결국 더 많은 팀 간 소통이 필요하다. 하지만 글쓴이는 그게 바로 소프트웨어 엔지니어링의 본질이라고 본다. 쉬운 규칙 하나로 끝나지 않더라도, 장기적으로 살아남는 코드베이스를 원하면 수직 구조로 가는 편이 낫다는 결론이다.

정리

이 글의 실무적 요지는 분명하다.

1. 파일 종류 기준 분할은 작을 때만 편하고, 커질수록 탐색성과 응집도를 해친다.
2. 기능적으로 같이 바뀌는 코드는 같은 폴더, 같은 영역에 두는 것이 맞다.
3. 공용 코드도 "shared" 라는 쓰레기통에 던지지 말고, 독립된 도메인으로 격상해 다루는 게 낫다.
4. 수직 구조는 모놀리식 폴더 정리가 아니라 ownership, 경계, 의존성 설계까지 이어져야 한다.

React나 프론트엔드 프로젝트가 커질수록, 특히 Query 옵션, types, hooks, UI가 한 기능을 중심으로 같이 움직이는 팀이라면 이 글의 제안이 꽤 강하게 먹힌다.

04-custom-eslint-rules.md

Now More Than Ever, You Need to Master Custom ESLint Rules, 한국어 번역

• 원문 제목: Now more then ever, you need to master custom ESLint rules
• 원문 링크: https://neciudan.dev/master-eslint-rules
• 번역일: 2026-04-20 KST
• 커뮤니티 발견: This Week in React #277

번역

이 글은 "불필요한 useEffect를 코드 리뷰에서 매번 말로 싸우지 말고, 룰로 옮겨라"라는 아주 실전적인 문제의식에서 시작한다.

글쓴이는 팀 코드베이스에서 반복적으로 같은 PR 코멘트를 보게 됐다고 말한다. 예를 들어:

useEffect(() => setFiltered(data.filter(...)), [data])

처럼 derived state를 effect로 동기화하는 코드가 올라오면, 리뷰어 여러 명이 "이건 effect가 필요 없다"고 지적하고, 작성자는 반박하고, 짧은 코드 한 줄 때문에 긴 논쟁이 반복된다는 것이다. 그래서 아예 custom ESLint rule을 만들어 이 패턴을 자동으로 잡기로 했다.

코드가 아니라 트리를 본다는 관점

글의 핵심 교육 포인트는 AST(Abstract Syntax Tree)다. 사람이 JavaScript를 보면 텍스트를 보지만, ESLint는 코드를 트리로 본다.

예를 들어 const name = "Dan"; 는 변수 선언 텍스트가 아니라,

• VariableDeclaration
• VariableDeclarator
• Identifier
• Literal

같은 노드가 중첩된 구조로 해석된다. 공백, 세미콜론, 포매팅은 중요하지 않고, 코드의 의미 구조만 남는다.

이 시각이 중요한 이유는 ESLint, Babel, Prettier, TypeScript 모두 결국 AST를 기반으로 움직이기 때문이다. 즉 custom rule 작성은 문자열 비교가 아니라 "이런 형태의 트리를 찾는 패턴 매칭" 문제다.

ESLint는 어떻게 동작하는가

글은 ESLint 동작을 세 단계로 설명한다.

1. 소스 코드를 AST로 파싱한다.
2. 트리를 깊이 우선으로 순회한다.
3. 각 노드에 대해 해당 타입을 듣고 있는 rule listener를 호출한다.

룰은 결국 create() 함수가 있고, 그 안에서 CallExpression, VariableDeclarator 같은 노드 타입별 콜백을 반환하는 객체다. context.report() 를 부르면 에디터나 CI에 경고가 뜬다.

즉 no-console 같은 기본 룰도 본질적으로는 "CallExpression을 볼 때, callee가 console.log 인지 검사하라"는 단순한 함수다.

AST Explorer가 사고방식을 바꾼다

글쓴이는 AST Explorer를 강하게 추천한다. 코드를 붙여 넣고, 대응하는 AST 노드를 클릭해 가며 구조를 보는 순간 custom rule 작성이 훨씬 쉬워졌다고 말한다.

• 화살표 함수는 ArrowFunctionExpression
• 함수 호출은 CallExpression
• 객체 속성 접근은 MemberExpression
• 식별자는 Identifier

처럼 보이기 시작하면, 이제 "나쁜 코드 패턴"을 AST 형태로 찾아내고 그 패턴을 검사하는 룰을 작성할 수 있다.

실제 룰 예시: derived state를 effect에서 세팅하지 말기

글의 대표 예시는 useEffect 안에서 state setter만 호출하는 패턴을 잡는 룰이다.

접근 방식은 이렇다.

• 먼저 useState 호출을 찾아 setter 이름들(setFiltered, setValue 등)을 수집한다.
• 다음으로 useEffect 호출을 찾는다.
• effect body 안의 모든 statement가 setter 호출뿐인지 본다.
• 그렇다면 이 effect는 외부 시스템 동기화가 아니라 derived state 계산일 가능성이 높으니 경고한다.

이 룰은 의도적으로 좁게 만들어져 있다. if 문 안에 setter가 들어간 경우나, .then() 안에서 state를 바꾸는 경우처럼 더 복잡한 케이스는 놓칠 수 있다. 하지만 false positive를 줄이고 "명백한 안티패턴"만 정확히 잡는 데 집중한 설계다.

이 지점이 꽤 중요하다. 커스텀 룰의 첫 버전은 모든 걸 똑똑하게 하려 하지 말고, 팀에서 가장 자주 반복되는 저비용 패턴 하나를 안정적으로 막는 것부터 시작하라는 메시지다.

로컬 플러그인으로 쉽게 붙일 수 있다

ESLint flat config를 쓰면 커스텀 룰 배포도 부담이 적다. npm에 공개 플러그인을 만들 필요 없이, 프로젝트 내부 파일 하나를 eslint.config.js 에서 import 해 local/no-derived-state-in-effect 같은 룰로 바로 쓸 수 있다.

즉 도입 비용은 생각보다 낮다.

• eslint-rules/no-derived-state-in-effect.js 파일 하나 만들고
• config에서 plugins.local.rules 로 등록하고
• 원하는 severity로 켜면 끝이다.

룰이 여러 개로 늘어나면 eslint-rules/index.js 로 모아도 된다.

테스트와 auto-fix

글은 RuleTester로 룰을 검증하는 방법도 소개한다. valid / invalid 코드 조각을 넣으면 룰이 기대대로 동작하는지 바로 확인할 수 있다. 이건 커스텀 룰을 실무에 넣을 때 꽤 중요하다. 룰이 코드베이스 전체에 영향을 주기 때문에, 오탐이나 누락을 테스트로 고정하는 습관이 필요하다.

auto-fix도 설명하지만, 모든 룰에 auto-fix가 필요한 것은 아니라고 한다. 예를 들어 derived state effect를 자동 수정하려면 useState 제거, useEffect 제거, 새로운 const 선언 삽입까지 해야 할 수 있다. 이런 변환은 AST 분석보다 안전성 보장이 더 어렵기 때문에, 경고만 주는 편이 더 나을 수 있다.

글의 더 큰 메시지

이 글은 ESLint를 단순 스타일 검사기가 아니라 "팀의 반복 논쟁을 툴로 내리는 장치"로 보게 만든다.

• 코드 리뷰에서 계속 같은 말을 하게 되는가?
• 팀 규칙이 있는데 사람마다 해석이 달라 논쟁이 길어지는가?
• 특정 안티패턴을 미리 막고 싶은가?

그렇다면 custom rule이 답이 될 수 있다. 특히 React 실무에서는 useEffect, state setter, 이벤트 핸들러, 폼 submit, 네이밍 규칙처럼 팀마다 중요하게 보는 패턴이 분명하기 때문에, custom ESLint rule은 생각보다 ROI가 크다.

정리

1. AST를 이해하면 ESLint 룰은 무섭지 않다.
2. 커스텀 룰은 반복되는 PR 리뷰 코멘트를 자동화하는 가장 현실적인 방법 중 하나다.
3. 첫 버전은 좁고 정확하게 만드는 편이 낫다.
4. auto-fix는 멋있지만, 안전하게 바꾸기 어려우면 경고만 줘도 충분하다.

프론트엔드 팀에서 useEffect 나 폼, 상태 관리 관련 논쟁이 자주 반복된다면, 이 글은 "문서화" 다음 단계로 "도구화"를 진지하게 고려하게 만든다.

05-framework-bundle-benchmark.md

Frontend Framework Bundle Size Benchmark, 한국어 번역

• 원문 제목: Frontend Framework Bundle Size Benchmark: React/Vue/Angular vs Fine-Grained Runtimes
• 원문 링크: https://dev.to/qingkuai/frontend-framework-bundle-size-benchmark-reactvueangular-vs-fine-grained-runtimes-2nk0
• 번역일: 2026-04-20 KST
• 커뮤니티 발견: DEV Community

번역

프레임워크 비교는 보통 DX, 생태계, 런타임 성능 이야기에 집중된다. 하지만 실제 사용자가 가장 먼저 겪는 것은 그보다 앞단이다. 내려받고, 압축을 풀고, 파싱하고, 실행하는 비용이다. 이 글은 바로 그 관점에서 프레임워크 번들 크기를 비교한다.

글쓴이는 같은 TodoMVC 기능 세트를 여러 프레임워크로 각각 구현한 뒤, 동일한 기준으로 번들 리포트를 만들었다. 비교 지표는 다음 세 가지다.

• raw size
• minified size
• minified + gzip size

또 총 크기를 runtime, template, script, style 로 나눠서 본다. 즉 단순 총합만 보는 것이 아니라, 무엇이 비용을 밀어 올리는지까지 확인할 수 있게 만든 벤치마크다.

공정성 제약

구현 차이로 인한 잡음을 줄이기 위해 몇 가지 제약을 둔다.

• 모든 프레임워크가 동일한 TodoMVC 동작을 구현한다.
• template / script / style 산출물을 분리해서 비교한다.
• 스타일은 전부 scope 처리한다. TSX 기반 구현은 CSS Modules를 사용한다.
• 차트 기본 선택에서는 style 비중을 강조하지 않지만, 통계에는 포함한다.

글은 style 차이가 이번 실험에서는 프레임워크 구조보다 scope metadata 영향이 더 큰 경우가 많아서, 핵심 비교 축은 runtime과 script 쪽에 있다고 본다.

메이저 프레임워크 그룹: React, Angular, Vue 3

1개 컴포넌트 기준 minified 번들 크기는 다음과 같았다.

• Angular: 약 201.69KB
• React: 약 189.44KB
• Vue 3: 약 65.64KB

왜 이런 차이가 나는지 보면 runtime 비용이 거의 그대로 드러난다.

• Angular runtime: 약 195.39KB
• React runtime: 약 185.66KB
• Vue 3 runtime: 약 61.83KB

이 벤치마크에서는 앱 규모가 커질수록 Angular가 가장 빠르게 커지고, React도 높은 수준을 유지하며, Vue 3가 이 그룹에서는 상대적으로 낮은 편을 유지한다. 즉 작은 데모 숫자만이 아니라 runtime 기반 비용 구조가 전체 성장 곡선을 좌우한다는 뜻이다.

Fine-grained 그룹: Solid, Vue Vapor, Svelte 5, QingKuai

최근 프레임워크 흐름은 virtual DOM의 일반적인 diffing보다, 더 세밀한 dependency 기반 업데이트로 이동하는 방향이라는 설명이 나온다. 하지만 "fine-grained니까 무조건 작고 좋다"고 말하기는 어렵다.

1개 컴포넌트 기준 minified 수치는:

• Solid: 약 19.04KB
• QingKuai: 약 25.42KB
• Svelte 5: 약 39.25KB
• Vue Vapor: 약 47.27KB

처음 출발점만 보면 Solid가 가장 작다. 하지만 성장 곡선을 보면 이야기가 달라진다.

• QingKuai는 증가 곡선이 더 완만해서, 높은 컴포넌트 수 구간에서는 가장 낮게 끝난다.
• Solid는 출발은 가장 작지만 증가 속도가 더 빠르다.
• Svelte 5와 Vue Vapor는 높은 컴포넌트 수 구간에서 QingKuai보다 높다.
• Vue Vapor는 큰 규모에서 Solid, Svelte 5보다는 낮게 유지된다.

그래서 이 글의 교훈은 "fine-grained가 좋다"가 아니라, "런타임이 어떻게 구성되어 있고 컴포넌트 수 증가에 따라 비용이 어떻게 늘어나는가"가 더 중요하다는 것이다.

Svelte 4는 별도 메모가 필요하다

Svelte 4는 작은 앱에서 매우 매력적인 출발점을 보여 준다.

• 1개 컴포넌트 기준 minified: 약 11.08KB
• runtime: 약 0.71KB

하지만 규모가 커질수록 증가 곡선이 꽤 가파르다. 글은 이를 다음과 같이 해석한다.

• 중앙 집중 런타임 비용은 매우 작다.
• 대신 각 컴포넌트 산출물 안에 반복되는 구현 조각이 더 많이 들어갈 수 있다.
• 그래서 앱이 커질수록 전체 번들 증가 속도가 빨라진다.

실무적으로는 작은 앱이나 극소형 위젯 수준에서는 Svelte 4가 여전히 매우 좋은 선택일 수 있지만, 중대형 앱까지 갈 가능성이 있으면 "초기 최소치"만 보고 결정하면 안 된다는 뜻이다.

결국 중요한 것은 시작점 + 기울기

글쓴이는 이 벤치마크가 네 가지 점을 다시 확인시켜 줬다고 정리한다.

1. 번들 크기는 프레임워크 선택 시 1급 지표여야 한다.
2. "no virtual DOM + fine-grained" 는 중요한 방향이지만, 그 안에서도 구현 차이는 크다.
3. 1개 컴포넌트일 때 가장 작은 결과만 봐서는 안 된다.
4. 중대형 앱에서는 성장 기울기(slope)가 단일 최저점보다 더 중요할 때가 많다.

정리

이 글은 프론트엔드 프레임워크 논의를 조금 더 냉정하게 만든다. 체감 성능은 결국 다운로드, 파싱, 실행이라는 현실을 통과한다. 그래서 프레임워크 비교도 "개발 경험이 좋은가"를 넘어서,

• 초기 런타임 비용이 얼마인지
• 컴포넌트 수가 늘 때 선형으로 커지는지, 급격히 커지는지
• 작은 앱 최적화인지, 큰 앱 확장성까지 괜찮은지

를 같이 봐야 한다.

프레임워크를 새로 고를 때나, 조직 내 기술 선택 근거를 만들 때 꽤 유용한 자료다. 특히 "작은 데모에서는 빠르고 작아 보였는데 실제 제품 규모에서는 왜 무겁지?" 같은 질문에 좋은 반례와 비교축을 준다.

06-chrome-148-beta.md

Chrome 148 Beta, 프론트엔드 관련 변화 한국어 번역

• 원문 제목: Chrome 148 beta
• 원문 링크: https://developer.chrome.com/blog/chrome-148-beta
• 번역일: 2026-04-20 KST
• 커뮤니티 발견: This Week in React #277

번역

Chrome 148 베타에는 프론트엔드 실무에서 바로 체크할 만한 CSS, UI, 성능 관련 변화가 꽤 들어 있다. 원문 전체는 브라우저 플랫폼 전반을 다루지만, 여기서는 FE 관점에서 중요한 부분을 중심으로 옮긴다.

1) Name-only container queries

이제 요소에 container-type 을 지정하지 않고, container-name 만으로 컨테이너 쿼리를 걸 수 있다.

#container {
  container-name: --foo;
}

@container --foo {
  input { background-color: green; }
}

이 변화는 특히 디자인 시스템이나 복합 레이아웃에서 의미가 있다. 기존에는 쿼리를 쓰기 위해 type 지정까지 같이 해야 했는데, 이제 이름 기준으로 더 가볍게 컨테이너를 선언할 수 있다. 컴포넌트 단위 반응형 설계를 조금 더 명확하게 가져갈 여지가 생긴다.

2) text-overflow: ellipsis 와 사용자 상호작용

ellipsis 처리된 텍스트를 사용자가 편집하거나 caret 이동 같은 상호작용을 시작하면, 일시적으로 ellipsis 대신 clip 으로 바뀌어 숨겨진 내용까지 볼 수 있게 된다. editable 요소뿐 아니라 non-editable 요소에도 적용된다.

작아 보여도 UX 관점에서는 꽤 반가운 변화다. 긴 텍스트가 잘린 상태에서 커서 이동이나 선택 동작이 덜 답답해진다.

3) Drag and Drop의 dropEffect 를 명세대로 수정

dragEnter, dragOver, dragLeave 이벤트에서 dataTransfer.dropEffect 값을 명세에 맞게 설정하도록 고친다.

드래그 앤 드롭 UI를 직접 구현하는 팀이라면 브라우저 간 일관성 문제를 체크해 볼 필요가 있다. 이벤트 처리 결과에 의존한 로직이 있다면 베타 단계에서 확인해 두는 게 좋다.

4) <video>, <audio> 도 loading="lazy" 지원

이제 이미지와 iframe처럼 비디오, 오디오 요소에도 loading 속성을 줄 수 있다. viewport 근처에 올 때까지 미디어 리소스 로딩을 미룰 수 있으므로, 초기 페이지 로드 비용과 데이터 사용량을 줄이는 데 도움이 된다.

콘텐츠 사이트, 랜딩 페이지, 미디어 카드가 많은 피드 UI에서는 꽤 직접적인 최적화 포인트가 될 수 있다.

5) @supports 안의 at-rule() 지원

CSS @supports 에 at-rule() 함수가 추가되어, 특정 at-rule 지원 여부를 feature detection 할 수 있다. CSS 기능 감지를 더 세밀하게 구성할 수 있다는 뜻이다.

신규 CSS 문법을 점진적으로 도입할 때 fallback 전략을 조금 더 깔끔하게 짤 수 있다.

6) revert-rule 키워드 추가

revert-rule 은 현재 규칙을 무효화하고 이전 규칙 상태로 되돌리는 개념이다. revert-layer 와 비슷하지만, 레이어가 아니라 직전 규칙 단위로 되감는다.

조건부 스타일에서 특히 쓸모가 있다. 조건이 맞지 않으면 현재 선언만 자연스럽게 제거하는 식의 표현이 가능해진다.

div {
  display: if(style(--layout: fancy): grid; else: revert-rule);
}

복잡한 CSS 조건 분기나 테마 시스템에서 유용할 가능성이 있다.

7) text-decoration-skip-ink: all

기존 auto, none 에 더해 all 값이 지원된다. CJK 문자까지 포함해 모든 glyph에 대해 ink-skipping을 적용할 수 있다.

한중일 텍스트가 많은 서비스나, underline 스타일을 정교하게 맞추는 타이포그래피 중심 제품이라면 체크할 가치가 있다.

8) 성능 측정과 플랫폼 확장 포인트도 눈여겨볼 만함

원문에는 CSS 외에도 다음 기능이 들어 있다.

• PerformanceResourceTiming.contentType: 리소스 타이밍 데이터에 콘텐츠 타입을 직접 담는다.
• SharedWorker Android 지원 및 extended lifetime 옵션
• Prompt API 웹 지원 확대
• Web Serial API Android 지원

즉 단순 스타일 변화만이 아니라, 브라우저 성능 계측과 온디바이스 AI, 멀티 컨텍스트 실행 모델까지 점점 넓어지고 있다는 신호다.

9) Origin Trial 중 FE 실무자가 특히 볼 만한 것

Chrome 148의 origin trial 중에는 FE 관점에서 특히 흥미로운 항목도 있다.

• Container Timing API: DOM 하위 섹션이 실제 화면에 그려진 시점을 측정할 수 있다. 컴포넌트 단위 성능 계측에 유용하다.
• Declarative CSS module scripts: shadow root, declarative shadow DOM 과 함께 공유 스타일을 더 선언적으로 관리하는 실험이다.
• HTML-in-canvas: DOM 요소를 canvas/WebGL/WebGPU 텍스처에 그리면서도 인터랙션과 접근성을 유지하려는 시도다.
• Long Animation Frames style duration: long animation frame 안에서 style 계산 시간이 얼마나 들었는지 분리 측정할 수 있다.

디자인 툴, 그래픽 편집기, 복잡한 대시보드, 성능 분석 도구를 만드는 팀이라면 이런 실험 기능의 방향성을 미리 보는 것만으로도 의미가 있다.

정리

Chrome 148 베타를 FE 관점에서 요약하면 이렇다.

1. 컨테이너 쿼리, 조건부 CSS, 타이포그래피처럼 디자인 시스템에 직접 영향을 주는 변화가 들어왔다.
2. 미디어 lazy loading, 성능 계측 API 확장처럼 실제 웹 성능 최적화 포인트도 늘었다.
3. Container Timing, HTML-in-canvas 같은 실험 기능은 향후 고성능 UI 설계 방향을 미리 보여 준다.

당장 전부 써야 하는 건 아니지만, 디자인 시스템과 퍼포먼스 툴링을 다루는 팀이라면 이번 베타는 꽤 볼 만하다.

README.md

frontend-briefing-2026-04-20-KST

• 번역일: 2026-04-20 KST
• 선별 개수: 6

포함된 글

1. React Server Components Your Way
2. The uphill climb of making diff lines performant
3. The Vertical Codebase
4. Now more then ever, you need to master custom ESLint rules
5. Frontend Framework Bundle Size Benchmark: React/Vue/Angular vs Fine-Grained Runtimes
6. Chrome 148 beta

커뮤니티 우선 소스(HN, DEV, This Week in React 등)에서 선별하고, 필요 시 공식 소스를 보완했다.