Go로 재작성된 네이티브 컴파일러를 탑재한 TypeScript 7.0의 릴리스 후보(RC)가 공개되었다. TypeScript 팀은 기존의 타입 체크 로직과 구조를 그대로 유지한 채 Go로 포팅해 네이티브 코드의 속도와 공유 메모리 병렬화의 이점을 얻었다.
TypeScript 7.0은 6.0보다 약 10배 빠르며, Bloomberg, Figma, Google, Slack, Vercel 등 여러 기업의 팀과 협력하여 프리릴리스 빌드를 테스트해왔고, 피드백은 압도적으로 긍정적이었다고 한다. 호환성 측면에서는 6.0에서 정상 컴파일되는 코드가 7.0에서도 동일하게 동작하되, target: es5나 baseUrl 같은 레거시 플래그에는 경고가 표시된다.
RC는 프로덕션 사용에 근접한 안정 단계로, 향후 한 달 내 정식 릴리스될 예정이며 실제 프로젝트의 피드백을 모으고 있다. 대규모 코드베이스에서 타입 체크와 빌드 속도로 고생해 온 팀이라면 미리 검증해 볼 가치가 있다.
Chromium 계열 브라우저의 window.showDirectoryPicker()는 File System Access API의 일부로, 사용자가 로컬 디렉터리에 대한 접근 권한을 부여하면 웹 페이지가 그 안의 파일을 직접 읽고 쓸 수 있게 해 준다. 저자는 이 API가 브라우저 앱과 네이티브 앱의 경계를 허무는 "완전히 새로운 세계"를 연다고 본다.
글은 서버에 파일을 업로드하지 않고 로컬 파일 시스템을 직접 다루는 로컬 우선(local-first) 방식의 가능성에 주목한다. 사용자가 노트 폴더를 직접 관리하는 마크다운 앱이나, 원본을 로컬에 둔 채 편집하는 브라우저 기반 사진 편집 앱처럼, 그동안 네이티브 앱의 영역이던 워크플로를 웹에서 구현할 수 있다는 것이다. 저자 스스로도 이 API를 활용해 사진 뷰어와 이미지 합성 앱 프로토타입을 만들어 본 경험을 공유한다.
다만 이 API는 아직 Chromium 계열에 한정되어 있어 크로스 브라우저 지원은 제한적이다. 그럼에도 클라우드에 데이터를 넘기지 않는 프라이버시 친화적 웹앱, 오프라인 우선 도구 등 새로운 애플리케이션 유형을 실험해 볼 만한 여지를 보여 준다.
E2E 테스트 프레임워크 Playwright의 Fixtures API는 test('...', async ({ page }) => {})처럼 구조 분해 패턴으로 필요한 의존성을 선언하면 스마트하게 주입해 주는 마법 같은 경험을 제공한다. 이 글은 그 마법의 정체를 파헤친다.
핵심은 Function.prototype.toString()이다. Playwright는 테스트 함수를 실행하기 전에 함수를 문자열로 변환한 뒤 정규표현식으로 첫 번째 인자의 구조 분해 패턴에서 fixture 이름을 추출한다. 덕분에 테스트가 실제로 요청한 fixture만 지연 초기화(lazy initialization)되며, page를 요청하지 않으면 브라우저 인스턴스 생성 자체를 건너뛴다. "첫 번째 인자는 반드시 객체 구조 분해 패턴이어야 한다"는 제약이 여기서 비롯된다.
이 설계는 의존성 주입을 await 없이 동기적인 형태로 풀어내 뛰어난 개발자 경험을 만들지만, 내부 동작을 모르면 직관적으로 이해하기 어려워 최소 놀람의 원칙(Principle of Least Astonishment)과는 다소 거리가 있다. 저자는 이 패턴이 테스트 함수라는 특수한 맥락에는 잘 맞지만, 다른 라이브러리에서 그대로 따라 하기는 어렵다고 평가한다.
매년 갱신되는 Robin Wieruch의 React 라이브러리 가이드 2026년 판이다. 프로젝트 시작부터 상태 관리, 데이터 페칭, 라우팅, 스타일링, 폼, 테스트, 인증, 배포까지 28개 카테고리에 걸쳐 현재 추천할 만한 라이브러리를 정리한다.
저자는 React 생태계를 "필요에 따라 라이브러리를 선택적으로 끼워 넣는 유연한 프레임워크"로 바라본다. 매년 변화하는 추천 목록을 통해 React 생태계의 흐름을 한눈에 파악할 수 있어, 신규 프로젝트의 기술 스택을 고민할 때 참고하기 좋은 자료다.
TSRX는 선언적 UI를 위한 TypeScript 언어 확장으로, 마크업 가까이에 JavaScript의 표현력을 유지하면서도 명확한 경계를 두는 템플릿 언어다. 이 글은 초기 설계가 안고 있던 문제를 짚고 방향을 다시 잡는 과정을 다룬다.
기존 설계는 정적 텍스트를 ""나 {''}로 감싸야 했고, if·for·switch 같은 일반 JavaScript 문법이 실제로는 템플릿 의미론으로 동작해 가독성을 해쳤으며 AI 모델이 의도를 파악하기 어려웠다. 새 설계는 JSX로 회귀해 정적 텍스트를 평문으로 작성하고("Static text is JSX text. Dynamic values use expression braces."), 특수 문법에는 @ 접두사를 붙여 @{}, @if, @for, @switch, @try처럼 명시적으로 구분한다.
또한 문장 기반에서 표현식 기반 설계로 전환해 변수 할당과 조합성을 개선했다. 그 결과 템플릿의 특수한 부분과 평범한 JavaScript가 시각적으로 분리되어 가독성, 타입 안정성, 도구 지원이 모두 향상되었다. 언어 설계에서 문법의 명시성이 사람과 도구 양쪽의 이해에 어떤 영향을 미치는지 보여 주는 사례다.
헤드리스 테이블 라이브러리 TanStack Table이 v9에서 v8 대비 메모리 사용량을 최대 90% 절감한 과정을 다룬다. 브라우저 4GB 한계를 기준으로 v8이 약 100만~150만 행까지 처리하던 것을, v9는 1000만~1600만 행까지 끌어올려 성능을 약 10배 개선했다.
v8에서는 수백만 개의 행·셀 객체가 동일한 메서드의 복사본을 저마다 들고 있었고, 화살표 함수마다 따라붙는 클로저(closure) 스코프가 인스턴스별로 유지되며 메모리가 누적되었다. v9는 메서드를 공유 프로토타입(prototype)에 한 번만 정의하고, 각 행 객체는 Object.create()로 그 프로토타입을 참조하도록 바꿨다. 메서드는 this 컨텍스트로 자신이 속한 행을 찾으므로 인스턴스별 클로저도 사라진다.
클래스 대신 수동 프로토타입을 택한 이유는 v9의 API가 기능(feature) 플러그인으로 동적 조합되기 때문이다. 단일 상속만 가능한 클래스로는 조건부 다중 상속에 가까운 이 구조를 표현하기 어색한 반면, 수동 프로토타입은 각 테이블이 등록된 기능의 API만 정확히 포함하도록 해 준다. 다만 const { getValue } = row처럼 메서드를 구조 분해 할당하면 this를 잃어 동작하지 않는 breaking change가 생겼다. (이 때문에 v8에 적용되지 못했다) 평범해 보이는 객체 생성 패턴 하나가 대규모 애플리케이션의 메모리 특성을 크게 좌우할 수 있음을 보여 준다.
프런트엔드와 백엔드처럼 별도로 배포되는 두 시스템에서 "주문을 취소할 수 있는가" 같은 동일한 비즈니스 규칙을 양쪽에 구현해야 할 때 발생하는 코드 중복과 불일치 문제를 다룬다. 저자는 규칙이 API 경계의 양쪽에서 성립해야 한다는 점에 주목한다.
같은 함수를 양쪽에 복사하거나 공유 패키지로 묶는 방식은 버전과 배포 시점의 차이로 불일치가 생기기 쉽다. 글은 세 가지 접근법을 비교하며, 백엔드가 "allowedActions": ["CANCEL"] 같은 결정값을 내려보내거나, 더 나아가 CASL이나 JSON Schema 같은 표준 형식으로 정책 자체를 데이터로 직렬화해 전송하는 방안을 제시한다.
핵심 통찰은 "같은 도메인 규칙이 두 곳에 따로 살게 두지 말고 무언가를 공유하라"는 것이다. 언어나 배포 주기가 다른 환경에서는 규칙을 평가하는 평가자(evaluator)만 공유하고 정책은 데이터로 전송하는 편이 현실적이다. 마이크로서비스나 BFF 구조에서 규칙 일관성을 고민하는 개발자에게 실용적인 관점을 제공한다.
CSS가 점점 더 많은 pseudo-class를 확보하면서, 과거 JavaScript 이벤트로 처리하던 UI 반응을 CSS만으로 표현할 수 있는 영역이 넓어지고 있다. 이 글은 그 흐름을 짚으면서도 "pseudo-class는 이벤트가 아니라 상태(state)를 추적한다"는 근본적인 차이를 명확히 구분한다.
예컨대 :hover는 pointerenter와 pointerleave 사이의 상태를 포착하는 것이지 특정 이벤트에 반응하는 것이 아니다. 저자는 :focus-visible, :checked, :valid/:invalid, 그리고 팝오버·대화상자의 :popover-open·:open처럼 상태를 표현하는 pseudo-class를 정리하고, JavaScript에서 event.target.matches(":focus-visible")처럼 상태와 이벤트를 조합해 쓰는 방법을 보여 준다.
element.addEventListener("focus", (event) => {
if (event.target.matches(":focus-visible")) {
/* 키보드 포커스일 때만 처리 */
}
});마지막으로 아직 브라우저에 구현되지 않은 event-trigger를 소개하는데, 이는 CSS에서 직접 이벤트를 감지해 애니메이션 등을 트리거할 수 있게 해 줄 제안이다. 상태와 이벤트라는 두 모델의 경계를 이해하면 언제 CSS에 맡기고 언제 JavaScript로 처리할지 더 나은 판단을 내릴 수 있다.
Claude Code 팀이 코딩 에이전트에게 프롬프트를 반복 입력하는 대신 "루프를 설계"하는 접근을 정리한 글이다. 루프를 "에이전트가 종료 조건을 만족할 때까지 작업 사이클을 반복하는 것"으로 정의하고, 트리거 방식과 종료 기준에 따라 4가지 유형으로 분류한다.
턴 기반 루프는 사용자 프롬프트로 시작하는 기본 단위로, 검증 절차를 스킬(SKILL.md)로 인코딩해 자가 검증 능력을 높일 수 있다. 목표 기반 루프(/goal)는 "Lighthouse 점수 90 이상"처럼 검증 가능한 완료 기준을 정의하면 평가 모델이 조건 충족 여부를 판단해 반복시킨다. 시간 기반 루프(/loop, /schedule)는 PR 리뷰 대응 같은 반복 작업을 주기적으로 실행하고, 프로액티브 루프는 이들을 조합해 버그 트리아지 같은 장기 작업을 사람 개입 없이 처리한다.
코드 품질 유지를 위해 별도 에이전트를 통한 코드 리뷰와 검증 스킬 작성을 권장하며, 토큰 사용량 관리를 위해 명확한 종료 기준 설정과 대규모 실행 전 파일럿 테스트를 제안한다. 복잡한 루프가 항상 필요한 것은 아니며, 가장 단순한 방법에서 시작해 선택적으로 적용하라고 조언한다.
AI 에이전트가 작성한 React 코드의 품질 문제를 자동으로 잡아내는 도구다. "Your agent writes bad React, this catches it"라는 슬로건처럼, 코드베이스를 스캔해 문제를 진단한다.
상태 관리, 이펙트, 성능, 아키텍처, 보안, 접근성 전반을 검사하며 Next.js, Vite, TanStack, React Native, Expo 등 대부분의 React 환경을 지원한다. Claude Code, Cursor, Codex 같은 AI 에이전트와 연동되고, GitHub Actions를 통한 PR 자동 리뷰도 가능하다. doctor.config.ts로 실행할 규칙을 커스터마이징할 수 있다.
npx react-doctor@latest # 코드베이스 초기 감사
npx react-doctor@latest install # AI 에이전트 연동 설치
npx react-doctor@latest ci install # CI 자동 리뷰 설정AI 코딩 도구가 빠르게 코드를 양산하는 환경에서, 사람이 일일이 잡기 어려운 React 안티패턴을 자동화된 게이트로 걸러 낸다는 점에서 활용도가 높다.
React Router v8이 출시되었다. "지루한 메이저 업그레이드"를 표방하며, v7 이후 40여 차례의 릴리스를 통해 점진적으로 쌓아 온 기능들을 안정화하는 데 초점을 맞췄다.
v7 이후 추가된 미들웨어와 개선된 컨텍스트, 라우트 모듈 분할, 타입 안전한 href, SPA 모드 개선과 사전 렌더링, RSC(React Server Components) 지원 등이 이제 기본값으로 동작한다. 한편 최소 지원 버전이 Node 22, React 19.2, Vite 7로 상향되고 ESM 전용 배포로 전환되었으며, react-router-dom 패키지와 data 파라미터 등이 제거되었다.
마이그레이션은 피어 의존성 업데이트 → future 플래그 적용 → 폐기된 API 제거의 세 단계로 단순하게 정리된다. v8부터는 연간 메이저 릴리스 일정을 채택해 예측 가능성을 높였고, v6와 Remix v2는 지원이 종료된다. 풀스택 프레임워크부터 클라이언트 라우터까지 폭넓은 사용 사례를 안정적으로 지원하려는 방향성이 드러난다.
Deno v2.9.0부터 제공되는 deno desktop은 단일 TypeScript 파일부터 Next.js 앱까지 Deno 프로젝트를 독립 실행형 데스크톱 애플리케이션으로 변환한다.
기본 WebView 백엔드로 바이너리 사이즈를 작게 만들거나 Chromium을 번들할 수 있고, Node.js 완전 호환으로 npm 생태계를 그대로 쓸 수 있다. 프로세스 간 통신(IPC) 대신 인프로세스 바인딩을 사용하며, Next.js·Astro·Fresh·Remix·Nuxt·SvelteKit 등 프레임워크를 자동 감지한다. 단일 머신에서 macOS·Windows·Linux 크로스 컴파일, --hmr 핫 모듈 교체, bsdiff 기반 자동 업데이트와 롤백, 네이티브 OS 대화상자·알림·메뉴 등을 내장했다.
deno desktop main.ts # main.ts를 데스크톱 실행 파일로 컴파일main.ts의 Deno.serve() 핸들러를 WebView에 자동으로 연결해 준다. Electron, Tauri, Electrobun 등과 비교해 작은 바이너리, 완전한 Node 호환성, 프레임워크 자동 감지, 내장 업데이트를 하나로 묶었다는 점이 차별점이다.
Node.js를 대체하는 대신 보강하는 것을 목표로 하는 Rust 기반 CLI 도구다. node, npm run, npx를 하나의 통합 도구로 대체하되 실제 Node 런타임 위에서 동작해, Bun이나 Deno처럼 런타임을 완전히 교체하지 않고 프로덕션 안정성을 유지한다.
빌드 과정 없이 .ts 파일을 직접 실행하고(tsx보다 2.9배 빠름), nub run은 pnpm run보다 24배, nubx는 npx보다 19배 빠르다고 소개한다. 의존성 그래프 기반의 nub watch, pnpm 호환 설치와 lockfile, Node 버전 자동 관리도 지원한다. WHATWG·TC39·Node.js 표준만 사용하고 고유 API가 없어 언제든 제거할 수 있으며, 라이프사이클 스크립트 기본 차단과 24시간 릴리스 대기 등 보안 기능도 갖췄다.
nub index.ts # TypeScript 파일 실행
nub run dev # package.json 스크립트 실행
nub watch src/server.ts # 변경 감지 후 재시작
nubx prisma generate # node_modules/.bin CLI 실행
nub install # 의존성 설치파편화된 Node.js 도구 체인을 하나로 모으면서도 기존 생태계와의 호환성을 해치지 않으려는 접근이 인상적이다.
스키마 검증 라이브러리 Zod의 스키마를 빌드 시점에 오버헤드 없는 검증 함수로 미리 컴파일해 런타임 성능을 끌어올리는 도구다. 기존 Zod 코드를 바꾸지 않고도 2~75배 빠른 검증 속도를 달성하며, 입력이 유효한 경우 메모리 할당이 발생하지 않는다.
두 단계 검증으로 동작한다. 빠른 경로에서는 단일 boolean 체인으로 유효성을 확인하고(할당 없음), 실패했을 때만 느린 경로에서 상세 오류를 수집한다. Vite, webpack, esbuild, Rollup, Bun 등 주요 번들러를 지원하며, 플러그인을 설정하면 순수 Zod 코드로 작성된 스키마를 자동으로 감지·컴파일한다.
// vite.config.ts — 자동 모드(권장)
import zodCompiler from "zod-compiler/vite";
export default defineConfig({
plugins: [zodCompiler()],
});tRPC, Hono, React Hook Form 등과 자동으로 연동되고 재귀 스키마, transform, discriminatedUnion 등 대부분의 기능을 컴파일한다. 개발자 경험을 그대로 유지하면서 프로덕션 검증 성능을 극적으로 개선하려는 프로젝트에 유용하다.
Meta가 8년간 개발하며 내부 13,000개 이상의 앱에서 사용해 온 디자인 시스템을 오픈소스로 공개한 프로젝트로, 사람과 AI 에이전트가 함께 작업할 수 있도록 설계된 점이 특징이다.
150개 이상의 접근성을 갖춘 컴포넌트와 다크 모드를 포함한 브랜드 레벨 테마를 제공하며, neutral, butter, y2k 등 7가지 사전 제작 테마와 즉시 사용 가능한 프로덕션 템플릿을 지원한다. React와 Meta의 CSS-in-JS 라이브러리 StyleX 기반으로 구축됐지만, Tailwind나 CSS Modules, 순수 CSS와도 호환된다. 컴포넌트를 래핑하지 않고 CSS 커스텀 프로퍼티만으로 테마를 커스터마이징할 수 있는 구조도 눈에 띈다.
npm install @astryxdesign/core @astryxdesign/theme-neutral
npm install -D @astryxdesign/cliCLI와 MCP를 통해 프로젝트 스캐폴딩, 템플릿 탐색, 테마 생성, 에이전트용 문서 제공을 지원한다. 현재 베타 단계이며, 동일한 API와 문서를 사람과 AI 에이전트 모두에게 제공한다는 방향성은 AI 협업 시대의 디자인 시스템이 나아갈 방향을 보여준다.
Vercel이 공개한 파일시스템 기반의 지속형(persistent) AI 에이전트 프레임워크다.
에이전트의 구성 요소를 코드가 아닌 디렉터리 구조로 관리하는 것이 핵심이다. 시스템 프롬프트는 instructions.md, 도구는 tools/, 온디맨드 절차는 skills/, HTTP·Slack 연동은 channels/, 반복 작업은 schedules/ 디렉터리에 두는 식으로, 에이전트의 모든 기능이 예측 가능한 위치에 있어 검사와 확장이 쉽다.
// agent/tools/get_weather.ts
import { defineTool } from "eve/tools";
import { z } from "zod";
export default defineTool({
description: "Return mock weather data",
inputSchema: z.object({ city: z.string() }),
async execute({ city }) {
return { city, condition: "Sunny", temperatureF: 72 };
},
});npx eve@latest init my-agent 한 줄로 시작할 수 있으며 현재 공개 베타 단계다. 마크다운과 타입 정의된 함수만으로 에이전트를 구성하는 접근은 코드 중심 프레임워크 대비 낮은 진입 장벽을 제공한다.
API 데이터를 로컬 반응형 상태처럼 쿼리할 수 있게 해주는 클라이언트 상태 관리 라이브러리로, 현재 베타 단계다.
API 데이터를 타입이 지정된 컬렉션(collection)으로 관리하고, 라이브 쿼리를 통해 클라이언트에서 join, filter, 집계를 수행한다. Differential dataflow 기반으로 데이터 변경 시 전체가 아닌 변경된 부분만 재계산하여 성능을 확보하며, 낙관적 트랜잭션(optimistic transaction)으로 서버 응답 전 UI를 즉시 업데이트할 수 있다.
useLiveQuery((q) =>
q.from({ issue: issuesCollection })
.join({ project: projectsCollection }, ({ issue, project }) =>
eq(issue.projectId, project.id))
.orderBy(({ issue }) => issue.updatedAt, "desc"))React, Vue, Solid, Svelte, Vanilla JS를 지원하고 REST, GraphQL, tRPC, TanStack Query, Electric 등 다양한 동기화 엔진과 호환된다. 특정 백엔드에 종속되지 않는 어댑터 구조여서 기존 프로젝트에 점진적으로 도입할 수 있다.