LLM 시대에 React는 더 이상 다른 프레임워크와 경쟁하지 않는다. React는 이미 거대한 플랫폼이 되었다. LLM 훈련 데이터, 시스템 프롬프트, 개발자 출력 사이의 자기 강화 피드백 루프로 인해 React를 대체하는 것은 사실상 불가능해졌다.
Builtwith 데이터에 따르면 지난 12개월 동안 1300만 개 이상의 React 사이트가 새로 배포되었다. LLM 도구의 토큰 사용량 증가 곡선과 React 배포 증가 곡선이 놀랍도록 유사한 패턴을 보인다. Replit, Bolt와 같은 도구들은 시스템 프롬프트에 React를 명시적으로 하드코딩한다. 개발자가 유지보수할 수 있는 코드는 곧 React를 의미하기 때문이다.
새로운 프레임워크나 웹 플랫폼 기능이 성공하려면 LLM 훈련 데이터에 포함되고, 도구 제작자들이 시스템 프롬프트를 수정하고, 개발자들이 이를 요청하도록 만들어야 한다. 하지만 첫 단계만 완료하는 데도 최소 12~18개월이 걸리며, 그동안 React 생태계는 또 다시 천만 개 이상의 사이트를 생성한다. 이것이 바로 "dead framework theory"다. 새로운 프레임워크가 출시 시점부터 이미 죽어있는 세상을 의미한다.
WebAssembly라는 이름 때문에 많은 개발자들이 Wasm을 웹 기술이자 어셈블리 언어로 오해한다. 하지만 웹 어셈블리는 웹만을 위한 기술도 아니고 어셈블리도 아니다. WebAssembly라는 이름은 프로젝트 펀딩을 위한 네이밍이었다. Wasm은 가상 머신에서 실행되는 바이트코드로, JVM이나 .NET 바이트코드와 더 유사하다.
Wasm의 진정한 가치는 샌드박스 실행 환경과 보안성에 있다. 가상 머신이 명시적으로 노출하지 않는 한 파일 시스템이나 네트워크에 접근할 수 없어, 어떤 코드도 안전하게 실행할 수 있다. 또한 완전히 명세화되어 있고 정적 타입 시스템을 갖추고 있어, 컴파일러 작성자에게 이상적인 컴파일 타겟이 된다.
Wasm은 브라우저에서 시작했지만, 서버나 임베디드 장치에서도 실행될 수 있는 범용 플랫폼으로 진화했다. LLVM을 통한 컴파일도 가능하지만, 구조화된 제어 흐름과 예외, 고차 함수 등을 기본 제공하므로 직접 Wasm을 타겟으로 하는 것이 더 효율적이다. wasmtime, binaryen, WebAssembly Binary Toolkit 등 다양한 도구를 통해 Wasm 개발을 시작할 수 있다.
디자인 시스템에서 범용 <Tooltip> 컴포넌트를 제공하는 것은 좋지 않은 추상화다. 툴팁은 잘못 사용하기 쉽고, 접근성, 키보드 상호작용, 일관성 있는 사용자 경험 등 고려해야 할 사항이 많다. Material UI의 예시처럼 비대화형 요소에 툴팁을 추가하면 호버에서는 작동하지만 키보드 포커스에서는 작동하지 않는 문제가 발생한다.
저수준의 <Tooltip> 컴포넌트 대신, 더 높은 수준의 패턴 컴포넌트를 제공해야 한다. <Button>이나 <Link> 같은 대화형 컴포넌트에 선택적 title prop 추가하기, <IconButton>에 필수 title prop 요구하기, 명시적인 <InfoIcon> 컴포넌트 제공하기, 밑줄이 있는 <InfoText> 컴포넌트 제공하기 등의 방법이 있다.
제약은 창의성을 낳는다. 단지 공간이 부족하다고 해서 정보를 툴팁에 숨길 수 없다면, 아이디어를 처음부터 다시 생각하게 된다. 디자인 시스템을 구축한다면, 공개 인터페이스에 <Tooltip> 컴포넌트를 추가하려는 충동을 억제해야 한다.
유사하게 깃허브에서는 최근 Toast를 사용성, 접근성 관련 이유로 제거하였다.
URL은 단순한 주소가 아니라 강력한 상태 관리 도구다. PrismJS 다운로드 페이지의 URL에는 선택한 테마, 언어, 플러그인 등 모든 설정이 인코딩되어 있다. URL 하나로 공유 가능하고, 북마크 가능하며, 브라우저 히스토리가 자동으로 작동하고, 딥링킹이 가능하다.
URL의 각 부분은 서로 다른 유형의 상태를 인코딩한다. 경로 세그먼트는 계층적 리소스 탐색에, 쿼리 파라미터는 필터와 옵션에, 앵커 프래그먼트는 클라이언트 사이드 내비게이션에 적합하다. GitHub의 라인 하이라이팅, Google Maps의 좌표와 줌 레벨, Figma의 캔버스 위치와 선택된 요소, 전자상거래의 필터 등이 모두 URL을 통해 상태를 관리하는 좋은 예시다.
URL에 포함할 상태를 선택할 때는 간단한 규칙을 따르면 된다. "다른 사람이 이 URL을 클릭했을 때 같은 상태를 봐야 하는가?" 검색 쿼리, 필터, 페이지네이션, 뷰 모드 등은 URL에 포함하기 좋지만, 민감한 정보, 임시 UI 상태, 저장되지 않은 폼 입력 등은 다른 상태 관리 방법을 사용해야 한다. URLSearchParams API와 React Router, Next.js의 useSearchParams 훅을 활용하면 URL 상태 관리를 쉽게 구현할 수 있다.
React의 'use client'와 'use server' 같은 지시어(Directive)는 언어 기능처럼 보이고 느껴지지만, 실제로는 언어 기능이 아니다. 이것은 빌드 도구를 위한 신호로, 번들러와 컴파일러가 소비하는 도구 레벨의 지시사항이다.
이러한 혼란은 새로운 현상이 아니다. C/C++의 #pragma와 #define 같은 전처리기 지시어도 비슷한 혼란을 야기했다. 많은 초보 개발자들이 #pragma once를 C++ 언어 기능으로 오해했지만, 실제로는 컴파일러 힌트였다. JavaScript 지시어도 같은 패턴을 따른다. JavaScript 엔진은 이것이 무엇을 의미하는지 모르며, 번들러가 실행 전에 무엇을 재작성할지 결정한다.
지시어는 나쁜 것이 아니라 강력한 도구다. 하지만 명확성 부채(clarity debt)를 수반한다. "지시어는 빌드 도구를 위한 메모이지 JavaScript를 위한 것이 아니다"라는 간단한 문장으로 70%의 오해를 해결할 수 있다. C/C++ 커뮤니티가 전처리기 단계에 대한 멘탈 모델 교육으로 혼란을 줄인 것처럼, JavaScript 커뮤니티도 같은 전환이 필요하다.
[참고] 빠르게 읽고 싶다면 번역글을 참고하자
Vercel은 플랫폼을 넘어 JavaScript의 의미론을 도전하는 기능들을 출시하고 있다. Server Actions, 'use cache', 'use workflow' 같은 디렉티브는 단순한 라이브러리 추가가 아니라 새로운 언어 구조처럼 작동한다. 이는 차세대 프로그래밍 언어가 분산 시스템의 복잡성을 네이티브로 관리해야 한다는 비전을 보여준다.
프로그래밍 언어는 항상 복잡성을 관리하기 위해 진화해왔다. 어셈블리는 CPU 명령어를, C는 레지스터와 제어 흐름을, Java는 메모리 관리를, Go는 동시성을 추상화했다. 다음 단계는 데이터 관리의 복잡성을 다루는 것이다. 계산이 어디서 일어나는지, 데이터가 어떻게 이동하는지, 접근이 빠르고 지속 가능하며 신뢰할 수 있는지를 보장하는 것이다.
Vercel의 새로운 기능들은 직렬화 가능한 클로저(serializable closures), 대수적 효과(algebraic effects), 점진적 계산(incremental computation)이라는 세 가지 핵심 개념 위에 구축된다. Server Actions은 클라이언트와 서버 경계를 지우고, 'use cache'는 언어 레벨 캐싱을 제공하며, 'use workflow'는 내구성 있고 재개 가능한 함수를 만든다. 이는 프로그래밍 언어 자체가 분산 애플리케이션의 특성을 이해하고 관리하는 미래를 향한 프로토타입이다.
State of React 2025 설문조사가 시작되었다. React 생태계의 현재 상태와 트렌드를 파악하기 위한 연례 설문조사로, 개발자들의 React 사용 현황, 선호하는 라이브러리, 프레임워크, 상태 관리 도구 등에 대한 의견을 수집한다.
설문은 한국어를 포함한 다국어로 제공되며, React 개발자라면 누구나 참여할 수 있다. 커뮤니티의 인사이트를 공유하고 React 생태계의 미래 방향을 함께 만들어가는 기회가 될 것이다.
Google Chrome은 2026년 10월 Chrome 154 릴리스부터 "Always Use Secure Connections" 설정을 기본적으로 활성화한다. 이는 웹의 보안을 한 단계 더 강화하는 중요한 결정이다.
HTTPS를 기본값으로 설정함으로써 사용자들은 더 안전한 웹 브라우징 경험을 얻게 된다. HTTP 사이트에 접근하려 할 때 자동으로 HTTPS로 업그레이드를 시도하며, HTTPS를 지원하지 않는 경우에만 경고를 표시한다.
React 컴포넌트 재사용성에 대한 과도한 집착이 오히려 과잉 엔지니어링의 위기를 초래한다는 비판적 시각을 담은 글이다.
개발자들이 DRY(Don't Repeat Yourself) 원칙을 잘못 적용하면서 컴포넌트를 지나치게 추상화하고, 수많은 props를 전달하는 "prop soup" 현상이 발생하고 있다. 이는 결과적으로 코드의 복잡성을 증가시키고 유지보수를 어렵게 만든다.
저자는 "post-reuse mindset"를 제안하며, 명확성과 유지보수성을 위해 의도적인 중복을 허용하고, 단순하고 자기 완결적인 컴포넌트를 만들 것을 권장한다.
Microfrontend를 설명하는 공식 스펙으로, OpenAPI가 Microservice에 대해 하는 것처럼 Microfrontend의 표준화를 목표로 한다.
메타데이터, 에셋(JS, CSS), 설정 스키마, 메시지 스키마(pub/sub), API 프록시, 보안 힌트를 포함한 포괄적인 명세를 제공한다. Microfrontend 개발과 통합을 분리하여, 서버가 노출하는 Microfrontend를 애플리케이션에 통합하는 과정을 단순화한다.
microfrontends:
- name: My First Microfrontend
assets:
basePath: /public
js:
moduleSystem: ESM
initial:
- Microfrontend.js
config:
schema:
type: object
properties:
welcomeMessage:
type: stringTypeScript 지원과 타입 안전성을 제공하며, Microfrontend를 Microservice처럼 다루는 새로운 패러다임을 제시한다.
웹 개발자가 웹 애플리케이션 기능을 "도구"로 AI 에이전트, 브라우저 어시스턴트, 보조 기술에 노출할 수 있도록 하는 JavaScript 인터페이스 제안이다.
기존 Back-end 통합 방식과 달리 WebMCP는 웹 페이지 UI 내에서 클라이언트 측에서 도구를 실행하여, 협력적인 human-in-the-loop 워크플로를 가능하게 한다. 개발자는 Front-end 코드를 재사용하여 AI 에이전트 통합을 단순화하고, 개발 부담을 최소화하며 접근성을 개선할 수 있다.
/**
* Filters the list of templates based on a description.
*
* description - A visual description of the types of templates to show
*/
filterTemplates(description);W3C Web Machine Learning Working Group에서 제안한 이 프로토콜은 AI 기반 웹 경험의 표준화를 목표로 하고 있다.
최근 10년간 Front-end 개발에서 가장 큰 변화는 브라우저가 프레임워크의 핵심 기능들을 직접 지원하기 시작했다는 점이다.
Shadow DOM, ES 모듈, Navigation API, View Transitions API 등 네이티브 웹 플랫폼 기능들이 라우팅, 상태 관리, 컴포넌트 격리 등 프레임워크가 제공하던 기능을 대체하고 있다. 프레임워크가 제공하던 기능들이 이제는 브라우저 표준으로 자리잡으면서, 개발자들은 무거운 번들과 복잡한 추상화 레이어 없이도 고성능 애플리케이션을 구축할 수 있게 되었다.
프레임워크는 여전히 개발자 경험과 팀 스케일링에서 가치를 제공하지만, 이제는 필수가 아닌 선택의 영역으로 이동하고 있다. 현대 웹 개발자라면 브라우저 네이티브 API를 적극 활용하고, 프레임워크 의존성을 재검토할 필요가 있다.
웹 애니메이션 기법들을 브라우저 렌더 파이프라인(Layout, Paint, Composite)과 실행 스레드(메인 vs 컴포지터)에 따라 S부터 F까지 등급으로 분류한 가이드다.
브라우저는 Layout → Paint → Composite의 3단계 렌더 파이프라인을 거치며, 각 단계를 건너뛸수록 성능이 향상된다. transform과 opacity 속성은 하드웨어 가속을 통해 컴포지터 스레드에서만 실행되어 S등급 성능을 제공하는 반면, CSS 변수를 사용한 애니메이션은 상속으로 인해 D등급으로 평가된다.
개발자는 will-change 속성, SVG 속성의 한계, View Transitions API 등을 이해하고, 애니메이션 기법 선택 시 성능과 유연성 간의 트레이드오프를 고려해야 한다.
1년간 Next.js App Router와 React Server Components(RSC)를 실무에 사용한 후의 비판적 리뷰다.
낙관적 업데이트(optimistic updates)가 복잡한 클라이언트 측 우회 없이는 불가능하고, 캐시된 데이터에도 불구하고 모든 네비게이션마다 중복 데이터 페치가 발생하며, 레이아웃에 인위적 제약이 있고, 콘텐츠의 "이중 다운로드"(HTML과 RSC 페이로드) 문제가 있다. Turbopack 역시 성능과 디버깅 문제를 보였다.
저자는 TanStack Start로 성공적으로 마이그레이션했으며, 코드 단순화와 성능 향상을 경험했다. 조건부 import와 모듈 확장 전략을 통해 점진적 마이그레이션이 가능했음을 보여준다.
이 영상은 Cory House가 지난 10년간 React를 사용하며 얻은 핵심 교훈과, React 생태계의 데이터 패칭·상태 관리·서버 컴포넌트·Sync Engine까지 이어지는 흐름을 정리한 발표다. 초창기 class 컴포넌트 시절부터 React 19까지의 변화 과정을 폭넓게 다룬다.
발표에서는 useEffect의 복잡성과 한계를 시작으로, 커스텀 훅→TanStack Query→Suspense for Data Fetching→React Server Components→Convex/ElectricSQL 기반 Sync Engine으로 발전해온 패턴을 설명한다. 특히 Zod 기반 런타임 데이터 검증과 Sync Engine을 활용한 Local-First 아키텍처가 미래 프런트엔드 개발의 핵심 요소가 될 것이라는 인사이트를 강조한다.
이 내용은 프런트엔드 개발자가 React 애플리케이션을 설계할 때 단순 UI 구현을 넘어 “데이터 흐름 전체”를 바라보는 관점의 중요성을 보여준다.
영상은 TanStack 생태계를 소개하며 React Query를 넘어 멀티 프레임워크 기반으로 확장된 최신 TanStack 도구들을 설명한다. 특히 타입 안정성과 일관된 DX를 핵심 원칙으로 삼아 Query, Form, DB 등 다양한 라이브러리를 구성한 철학을 강조한다.
주요 내용으로는 TanStack Form의 동기·비동기 검증, 디자인 시스템과의 높은 결합도, Zod 기반 유효성 검사 등이 소개된다. 또한 TanStack DB는 실시간 데이터와 live-query 방식으로 전통적인 CRUD 모델을 대체하는 접근을 제안하며, Firebase나 Convex 같은 실시간 DB와 달리 특정 벤더에 종속되지 않는 어댑터 기반 구조를 제공한다고 설명한다.
영상 후반부에서는 TanStack Start가 Next.js App Router의 복잡성을 대체할 수 있는 현실적인 대안으로 소개되며, 전체적으로는 Next.js를 대신해 사용할 수 있는 새로운 선택지로 제시된다. TanStack Start는 파일 기반 라우팅, 라우트별 SSR 전략(SSR / Data-only / SPA), 서버 함수(method 지정 가능), Zod 기반 입력 검증, 미들웨어 등을 통합한 SPA-first 프레임워크다. 기존 Vite SPA에 SSR·BFF 기능을 자연스럽게 결합해 하나의 앱 안에서 SPA·SSR을 유연하게 혼합할 수 있다는 점을 장점으로 제시한다.
토스에서 공개한 웹 접근성 개발에 입문하기 위한 실용적인 가이드다. 스크린 리더를 기본 도구로 하여, 개발자가 스크린 리더 호환성을 확보하는 방법을 다룬다.
스크린 리더는 화면 속 요소와 정보를 음성으로 전달하는 보조 기술이다. 접근성을 고려한 코드를 작성하려면 스크린 리더가 내용을 자연스럽게 읽도록 만드는 것이 핵심이다. 이 가이드는 개발자가 실제로 스크린 리더를 사용하며 접근 가능한 웹을 구현하는 방법을 단계별로 안내한다.
JavaScript ES2022에서 도입된 Error.cause는 에러 체이닝을 통해 더 깔끔한 디버깅을 가능하게 한다.
기존 에러 처리 방식은 원본 에러의 스택 트레이스와 타입 정보를 잃어버리는 문제가 있었다. Error.cause를 사용하면 새로운 에러로 감싸면서도 원본 에러의 컨텍스트를 보존할 수 있다.
try {
JSON.parse('{ bad json }');
} catch (err) {
throw new Error('Something went wrong', { cause: err });
}이 기능은 내장 에러 클래스와 커스텀 에러 클래스 모두에서 작동하며, Node.js 16.9+ 및 최신 브라우저에서 지원된다. 에러 로깅, 디버깅, 테스트 검증 등에서 유용하게 활용할 수 있다.
대부분의 경우 복잡한 JavaScript 날짜 선택기는 불필요하며, 더 나은 대안들이 존재한다는 주장을 담은 가이드다.
네이티브 HTML <input type="date">, <input type="time">, <input type="datetime-local"> 요소들은 내장된 접근성, 성능, 국제화 지원을 제공한다. 제한된 옵션의 경우 select 요소, 자유 입력이 필요한 경우 마스크 입력과 클라이언트 측 유효성 검사를 조합하는 것이 효과적이다.
JavaScript 날짜 선택기는 복잡한 UX 문제를 야기할 수 있으므로, 네이티브 HTML 요소와 간단한 대안들을 우선 고려하는 것이 사용자 경험과 접근성 측면에서 더 나은 선택이 될 수 있다.
CSS Custom Highlight API는 JavaScript로 텍스트 범위를 생성하고 CSS로 스타일링할 수 있는 메커니즘을 제공하는 웹 표준이다.
기존의 ::selection, ::spelling-error, ::grammar-error 같은 브라우저 정의 하이라이트 의사 요소의 개념을 확장하여, 개발자가 임의의 Range 객체를 생성하고 스타일링할 수 있도록 한다. DOM 구조에 영향을 주지 않고 프로그래밍 방식으로 텍스트 범위를 생성하고 하이라이트할 수 있어, 텍스트 에디터의 맞춤법/문법 오류 표시, 코드 에디터의 구문 오류 하이라이트, 검색 결과 강조 등에 유용하다.
// Range 생성 및 Highlight 등록
const range = new Range();
range.setStart(parentNode, 10);
range.setEnd(parentNode, 20);
const highlight = new Highlight(range);
CSS.highlights.set('search-results', highlight);::highlight(search-results) {
background-color: #ff0066;
color: white;
}협업 텍스트 에디터에서 사용자별로 다른 색상을 적용하거나, 검색 결과를 동적으로 하이라이트하는 등의 실용적인 활용이 가능하다.
Prisma는 심각한 Cold Start 문제로 drizzle, Kysely 등의 라이브러리에 대체되고 있었다. 오래전부터 Prisma 팀은 이런 문제를 해결하기 위한 여러 개선 작업을 해왔지만 이번 업데이트는 특히나 주목할 만하다.
Cold Start는 서버리스 환경에서 함수가 처음 실행되거나 오랜 시간 유휴 상태 후 재실행될 때 발생하는 초기 지연 시간을 의미한다. Prisma는 Rust 엔진과 무거운 의존성으로 인해 이 문제가 특히 심각했다.
앞서 진행된 Prisma 팀의 개선 작업은 Prisma 팀의 블로그에서 확인할 수 있다.
이번에 릴리스된 Prisma ORM 7.0은 Rust-free 클라이언트로 전환하여 대대적인 성능 개선을 이루었다. 번들 크기가 90% 감소했고, 쿼리 실행 속도는 3배 빠르며, CPU와 메모리 사용량이 크게 줄었다. Vercel Edge와 Cloudflare Workers 배포도 간소화되었다.
Rust에서 TypeScript로 클라이언트를 재구축한 이유는 Contribution 장벽을 낮추고 성능을 개선하기 위해서다. 기존의 Rust와 JavaScript 런타임 사이의 통신 계층이 순수 JavaScript보다 느리고 추가 의존성을 생성하고 있었다. TypeScript로 전환하면서 번들이 작아지고 배포가 단순해졌으며, Deno 같은 런타임 지원이 쉬워졌다.
Prisma 툴이 생성하는 코드가 node_modules 밖으로 이동하여 개발자 워크플로우가 개선되었다. 프로젝트 소스 코드에 타입과 클라이언트가 생성되므로, 개발 도구와 파일 watcher가 변경사항에 반응할 수 있다. (더 이상 restart typescript를 하지 않아도 된다.) 새로운 Prisma config 파일로 프로젝트 설정을 동적으로 관리할 수 있다. ArkType 창시자와 협업하여 타입 생성을 최적화했고, 스키마 평가에 필요한 타입이 98% 감소했으며 전체 타입 체크가 70% 빨라졌다.
React Grab는 앱의 모든 엘리먼트를 클릭만으로 Cursor, Claude Code 등의 AI 코딩 에이전트에 전달할 수 있게 해주는 도구다. 기본적으로 AI 에이전트는 페이지의 엘리먼트에 접근할 수 없는데, React Grab가 이 문제를 해결한다. 포인트 앤 클릭만으로 컨텍스트를 제공할 수 있다.
사용법은 간단하다. ⌘C를 누른 채로 페이지의 아무 엘리먼트나 클릭하면 된다. Cursor, Claude Code, OpenCode 등과 함께 작동하며, 단일 스크립트 태그만 추가하면 된다. Next.js, Vite, Webpack 등 다양한 프레임워크와 빌드 도구에서 사용할 수 있는 설치 방법을 제공한다.
개발 환경에서만 활성화되도록 설정할 수 있어 프로덕션 빌드에 영향을 주지 않는다. AI 기반 개발 워크플로우와 결합하여 UI 개발 속도를 크게 향상시킬 수 있는 혁신적인 도구다.
패키지 설치 없이 script 태그 주입만으로 사용할 수 있는 가이드를 제공해서 손쉽게 테스트해볼 수 있다.
<script
src="//unpkg.com/react-grab/dist/index.global.js"
crossorigin="anonymous"
data-enabled="true"
></script>
pip(picture in picture) 기능을 구현한 React 라이브러리다. 브라우저의 Document Picture-in-Picture API를 사용하여 구현되어서, Video 뿐만 아니라 어떤 HTML 요소도 pip로 표시할 수 있다.
Document Picture-in-Picture API는 아쉽게도 safari, firefox 브라우저에서 지원되지 않는다.
pip-tools.com에서 해당 라이브러리의 데모를 확인할 수 있다.
Turborepo 2.6이 릴리스되었다. 마이크로프론트엔드 개발을 위한 로컬 프록시, Bun 패키지 매니저의 안정화, 터미널 UI에서의 태스크 검색 기능이 주요 개선 사항이다.
마이크로 프런트엔드는 여러 애플리케이션이 하나의 프로덕션 도메인에서 제공되는 아키텍처다. 프로덕션 배포에는 도움이 되지만 로컬 개발 시 여러 앱과 포트를 관리해야 하는 어려움이 있었다. Turborepo 2.6의 마이크로 프런트엔드 프록시를 사용하면 모든 애플리케이션을 하나의 포트에서 하나의 명령으로 실행할 수 있다.
Bun 패키지 매니저가 이제 Stable 버전으로 제공된다. Turborepo는 bun.lock v1 파일 형식을 파싱하여 변경된 의존성이 있는 패키지만 캐시 미스를 발생시킨다. 터미널 UI에서 / 키를 눌러 태스크를 검색하고 필터링할 수 있어 대규모 저장소에서 특정 태스크를 빠르게 찾을 수 있다.
React Email 5.0이 다크 모드 스위처, Tailwind 4 지원, Resend 통합, 8개의 새로운 컴포넌트를 추가하며 출시되었다.
새로운 테마 시스템으로 이메일의 다크 모드를 쉽게 구현할 수 있다. 가장 인기 있는 이메일 클라이언트들에서 다크 모드 호환성이 테스트되었다. Tailwind 4를 지원하여 더 간단한 코드와 성능 개선의 기회를 제공한다. React Email은 CSS 호환성을 검사하므로 이메일이 올바르게 렌더링될 것이라는 확신을 가지고 개발할 수 있다.
Resend Templates와의 통합으로 비개발자 팀원들과도 이메일을 협업할 수 있다. React Email 템플릿을 Resend에 업로드하면 전체 팀이 비주얼 에디터에서 실시간으로 협업할 수 있다. 새로운 컴포넌트 갤러리에는 복사 붙여넣기 할 수 있는 이메일 컴포넌트들이 8종 추가되었다. React 19.2와 Next.js 16을 지원한다.
Angular 21이 출시되었다. 개발자 경험 개선과 성능 향상, 그리고 현대적인 개발 패러다임으로의 전환에 초점을 맞춘 메이저 업데이트다.
Signal Forms는 새로운 폼 관리 방식으로, 보일러플레이트 코드를 크게 줄이고 Signal 기반의 반응형 폼 관리를 제공한다. AI를 위한 MCP(Model Context Protocol) 도구가 추가되어 모듈, 컴포넌트, 파이프를 자동으로 생성할 수 있어 개발 생산성이 크게 향상되었다. Angular Aria는 웹 애플리케이션의 접근성을 강화하기 위한 새로운 기능으로, ARIA 표준을 더 쉽게 구현할 수 있도록 지원한다.
Vitest를 기본 테스트 러너로 채택하여 더 빠르고 효율적인 테스트 환경을 제공한다. 가장 주목할 만한 변화는 Zone.js의 폐기다. 기존의 Zone.js를 폐기하고 Signal 기반의 반응형 시스템으로 전환하면서 성능 향상과 유지보수성 개선을 이루었다. 이는 Angular의 미래 방향성을 보여주는 중요한 아키텍처 변화다.
공식 MCP 지원으로 앞서 소개한 "dead framework theory"의 자기 강화 피드백 루프라는 디버프를 피할 수 있을지 귀추가 주목된다.
Antigravity는 Google이 공개한 에이전트 중심의 AI 기반 IDE다. Gemini 3 모델을 기반으로 복잡한 소프트웨어 개발 작업을 자율적으로 계획하고 실행할 수 있는 차세대 IDE 형태를 구현했다.
신뢰, 자율성, 피드백, 자기 개선이라는 네 가지 핵심 원칙 위에 설계되었다. 자연어 코드 명령, 탭 자동완성, 상황 인식형 에이전트를 제공하며, 에디터·터미널·브라우저 간 동기화된 에이전트 제어를 지원한다. Editor와 Manager 두 가지 인터페이스를 제공하는데, Editor는 전통적인 IDE 방식으로 코드 작성과 인라인 명령을 지원하고, Manager는 여러 에이전트를 병렬로 관리하며 비동기적 상호작용을 가능하게 한다.
에이전트의 작업 과정을 투명하게 보여주기 위해 작업 목록, 구현 계획, 단계별 설명, 스크린샷, 브라우저 녹화 등의 산출물을 제공한다. Google Docs 스타일의 주석 시스템으로 직관적인 피드백이 가능하며, 에이전트의 제안을 수락·거부·수정할 수 있다. 현재 MacOS, Linux, Windows에서 무료 공개 Preview로 제공되며, Gemini 3, Claude Sonnet 4.5, GPT-OSS 모델을 선택적으로 활용할 수 있다.
Storybook 10이 출시되었다. ESM 전용으로 전환하여 설치 크기를 29% 줄이고 배포 코드를 비압축 상태로 제공해 디버깅을 쉽게 만들었다. 주요 개선 사항으로 모듈 자동 모킹, React용 타입 안전한 CSF 팩토리 프리뷰, UI 편집 및 공유 최적화, 태그 필터링 제외, Svelte 비동기 컴포넌트 지원 등이 포함된다.
새로운 sb.mock은 vi.mock에서 영감을 받았지만 더 간단하고, Vite와 Webpack 빌더 모두와 호환되며, 개발과 프로덕션 빌드 모두에서 사용할 수 있다. 기존의 Experimental이었던 CSF(Component Story Format)는 이제 Preview 상태로 제공되며, Storybook 11에서 기본값이 될 예정이다. CSF는 향상된 타입 안정성, 자동완성을 통해 더 나은 유저 경험을 제공한다.
UI 개선 사항으로 모바일 접근을 위한 QR 코드, 에디터에서 스토리 열기 버튼 등이 추가되었다. 태그 필터링에 제외 기능과 기본 UI 상태 설정이 추가되어 대규모 Storybook 관리가 쉬워졌다. Svelte 비동기 컴포넌트와 app/state 모킹을 지원하며, Next 16과 Vitest 4를 지원한다. 실험적 기능으로 테스트 신택스와 RSC 컴포넌트 테스트가 제공된다.
Snapchat이 8년간 프로덕션 앱에서 사용해온 크로스 플랫폼 UI 프레임워크가 오픈소스로 공개되었다. Valdi는 선언적 TypeScript로 UI를 한 번 작성하면 iOS, Android, macOS에서 네이티브 뷰로 컴파일된다. 웹뷰나 JavaScript 브릿지 없이 진정한 네이티브 성능을 제공한다.
Valdi는 자동 뷰 재활용, 최적화된 컴포넌트 렌더링, C++ 레이아웃 엔진, 뷰포트 인식 렌더링 등 여러 성능 최적화를 제공한다. 무한 스크롤을 기본적으로 성능 좋게 만들며, 오직 보이는 뷰만 인플레이트한다. 개발자 경험도 뛰어나다. 밀리초 단위의 즉시 핫 리로드, VSCode 디버깅 지원, TypeScript 타입 안정성을 제공한다.
기존 앱에 통합하기 쉬운 유연한 채택 모델을 갖추고 있다. Valdi 컴포넌트를 기존 네이티브 뷰 계층에 삽입하거나, 반대로 네이티브 뷰를 Valdi 레이아웃 내에서 사용할 수 있다. TypeScript와 네이티브 플랫폼 간 타입 안전한 바인딩을 자동 생성하며, Flexbox 레이아웃, 워커 스레드, 네이티브 애니메이션, 제스처 인식, Bazel 통합 등을 지원한다.
Andrej Karpathy가 만든 로컬 웹 애플리케이션으로, 여러 LLM이 서로의 작업을 검토하고 "의장 LLM"이 최종 답변을 종합하는 방식으로 복잡한 질문에 답한다.
3단계 프로세스로 구성되어 있다: (1) 각 LLM이 독립적으로 의견 제시, (2) 다른 LLM의 답변을 검토하고 순위 매김, (3) 의장 LLM이 모든 피드백을 종합해 최종 답변 작성. OpenRouter API를 통해 OpenAI, Google Gemini, Anthropic Claude, xAI Grok 등 다양한 모델을 사용할 수 있다.
COUNCIL_MODELS = [
"openai/gpt-5.1",
"google/gemini-3-pro-preview",
"anthropic/claude-sonnet-4.5",
"x-ai/grok-4",
]
CHAIRMAN_MODEL = "google/gemini-3-pro-preview"Back-end는 Python(FastAPI), Front-end는 React + Vite로 구성되어 있으며, uv와 npm을 통해 간편하게 설정할 수 있다.
Mozilla AI가 개발한 통합 Python 인터페이스로, 다양한 LLM 제공자(OpenAI, Anthropic, Mistral, Ollama 등)와 단일 API로 통신할 수 있도록 한다.
제공자 간 전환이 코드 변경 없이 가능하며, 일관된 API를 통해 개발 복잡성을 크게 줄인다. 추가로 any-llm-gateway라는 FastAPI 기반 프록시 서버를 제공하여, 예산 관리, API 키 관리, 사용량 분석 등 엔터프라이즈 기능을 지원한다.
from any_llm import completion
response = completion(
model="mistral-small-latest",
provider="mistral",
messages=[{"role": "user", "content": "Hello!"}]
)
print(response.choices[0].message.content)통합 인터페이스는 개발자가 LLM 제공자에 종속되지 않고 유연하게 서비스를 선택할 수 있도록 돕는다.
Anthropic의 공식 GitHub Action으로, PR과 이슈에서 Claude를 활용하여 질문에 답하고 코드 변경을 구현할 수 있다.
워크플로 컨텍스트에 따라 실행 모드를 자동으로 선택하며, @claude 멘션, 이슈 할당, 자동화 작업 등에 반응한다. 대화형 코드 어시스턴트, 코드 리뷰, 코드 구현, PR/이슈 통합, 진행 상황 추적, 구조화된 출력 등의 기능을 제공한다.
GitHub 인프라에서 실행되며, Anthropic API, Amazon Bedrock, Google Vertex AI, Microsoft Foundry 등 여러 인증 방법을 지원한다. Claude Code 터미널에서 /install-github-app 명령을 통해 간편하게 설정할 수 있다.
AI 기반 코드 리뷰와 자동화를 GitHub 워크플로에 직접 통합할 수 있어, 개발 생산성을 크게 향상시킬 수 있다.
Mac에서 여러 코딩 에이전트 팀을 실행하고 관리할 수 있는 도구다.
격리된 워크스페이스에서 병렬로 Codex와 Claude Code 에이전트를 생성할 수 있으며, 각 에이전트가 작업 중인 내용을 한눈에 파악하고 변경 사항을 검토 및 병합할 수 있다. 각 Conductor 워크스페이스는 git worktree로 구성되어 있어 안전한 병렬 작업이 가능하다.
Claude Code 인증 방식(API 키 또는 Claude Pro/Max 플랜)을 그대로 사용하며, Conductor 자체도 Conductor를 사용해 개발되었다. 다수의 개발자들이 VSCode보다 우수한 경험을 제공한다고 평가하고 있다.