React 컴포넌트를 쓰다 보면 이런 코드를 한 번쯤 마주치게 되는데요. 로딩, 에러, 목록, 빈 상태를 구분하는 평범한 요구사항인데 정작 코드는 괄호를 세 겹 열고 삼항 연산자를 두 번 중첩합니다. 자바스크립트에는 if도 있고 for도 있는데, JSX 안에서는 이 문법들을 쓸 수 없어서 전부 표현식으로 바꿔 끼워 넣어야 하기 때문입니다. 😅 TSRX는 바로 이 지점을 건드리는 프로젝트입니다. 이번 포스팅에서는 TSRX가 어떤 문법을 제공하고, 왜 이런 문법이 지금 나왔는지 살펴보겠습니다. TSRX는 무엇인가요? TSRX는 Typ
2026년 8월 20일에 Bun 1.4가 출시되었습니다. 저는 릴리스 노트를 열어보고 잠깐 스크롤을 멈췄는데요. 보통 이런 글은 새 API 목록으로 시작하는데, 이번에는 첫 문단부터 "Bun을 Zig에서 Rust로 다시 썼다"는 문장이 나오더라고요 🤯 런타임의 구현 언어를 통째로 바꾼다는 건 자동차가 달리는 중에 엔진을 갈아 끼우는 일에 가깝습니다. 그런데 이번 릴리스는 그 소식 말고도 볼 게 많습니다. Node.js 호환성 테스트가 1,517개 늘었고, 이미지 처리와 크론, 마크다운 파서가 표준 라이브러리로 들어왔으며, bun
공들여 쓴 글에 제목을 달고 모바일에서 열어봤는데, 마지막 줄에 짧은 단어 하나만 덩그러니 남아 있는 걸 보신 적 있으신가요? 😅 글꼴도 크기도 잘 골랐는데 제목이 어딘가 엉성해 보이는데요. 한국어라면 여기에 더해 "브라우저"가 "브라" / "우저"로 뚝 잘리는 일까지 생깁니다. 이런 문제는 글꼴이나 여백을 아무리 만져도 해결되지 않습니다. 줄을 어디서 나눌지는 브라우저의 줄바꿈 알고리즘이 정하는 영역이기 때문인데요. 우리가 개입하려면 그 알고리즘에 직접 말을 걸어야 합니다. 이번 포스팅에서는 word-break 속성과 text-
문서 사이트를 만들다 보면 이상한 순간이 옵니다. 정작 보여주려는 건 글자 몇 천 개인데, 그걸 그리려고 내려받는 자바스크립트가 1MB를 넘어가는 거죠. 😅 TanStack 팀이 딱 이 상황이었습니다. tanstack.com의 문서 페이지 하나가 스크립트만 약 1.1MiB를 전송하고 있었는데, 그중 358KiB 정도가 오직 코드 구문 강조에 쓰이고 있었어요. 이걸 React Server Components로 감추는 대신, 팀은 도구 자체를 작게 만드는 쪽을 택했습니다. 그렇게 나온 게 TanStack Markdown과 TanSta
관리자 화면에 버튼 하나를 추가하려는데 디자인부터 다시 잡아야 했던 적이 있나요? 버튼만 끝나면 다행이지만 입력창, 대화 상자, 탭, 드롭다운까지 필요해지면 이야기가 달라집니다. 직접 만들자니 접근성과 키보드 조작이 걱정되고, 익숙한 UI 프레임워크를 쓰자니 특정 JavaScript 프레임워크에 프로젝트 전체가 묶일 수 있죠. Web Awesome은 이 사이를 파고드는 UI 컴포넌트 라이브러리입니다. React나 Vue 전용 컴포넌트 대신 브라우저 표준인 웹 컴포넌트(Web Components)로 만들어졌는데요. 일반 HTML 페이
봇 개발을 하다 보면 결국 마주치는 통로가 **게이트웨이(Gateway)**입니다. 슬래시 커맨드를 만들 때 client.login() 한 줄로 봇을 온라인으로 띄웠는데, 그 순간 봇은 바로 이 게이트웨이로 디스코드와 연결을 맺은 거였어요. 이번 글에서는 그 통로의 안쪽을 들여다보며, 봇이 어떻게 서버의 모든 일을 실시간으로 지켜보는지, 그리고 그렇게 만든 봇을 어떻게 24시간 운영하는지까지 살펴봅니다. 게이트웨이는 항상 열려 있는 WebSocket REST API가 "내가 물어보면 답해주는" 요청-응답 방식이었다면, 게이트웨이는
ChatGPT에게 질문을 던지면 답변이 한 글자씩 타이핑되듯 흘러나오는 모습, 다들 익숙하시죠? 증권 앱의 시세가 새로고침 없이 실시간으로 바뀌거나, 웹 대시보드에 알림이 띵 하고 도착하는 것도 마찬가지인데요. 이런 화면들의 공통점은 서버에서 새로운 데이터가 생길 때마다 클라이언트가 곧바로 받아본다는 것입니다. 실시간 양방향 통신을 위한 웹소켓(WebSocket) 글에서 우리는 HTTP의 한계와 이를 극복하는 웹소켓을 살펴봤는데요. 그런데 위 예시를 가만히 보면 한 가지 공통점이 더 있습니다. 데이터가 서버에서 클라이언트로 한 방향
블로그나 문서 사이트를 운영하다 보면 빌드 시간이 슬금슬금 늘어나는 순간이 옵니다. 글이 수백 개를 넘어가면 마크다운 파싱과 변환에만 수십 초가 쓰이고, 거기에 remark/rehype 플러그인을 몇 개 더 끼우면 1분을 훌쩍 넘기는 경우도 흔하죠. 저도 이 블로그를 운영하면서 빌드 로그를 보다가 "마크다운 처리에 이만큼 시간을 쓴다고?"라는 생각을 한두 번 해본 게 아닌데요 😅 최근 Astro 6.4에서 markdown.processor API가 새로 등장하면서, unified 생태계가 아닌 다른 마크다운 처리기로 갈아탈 수 있
Void 라우팅에서 데이터를 읽어 오는 로더는 자세히 봤는데요. 정작 데이터를 바꾸는 쪽은 "로더 대신 action을 내보낸다"는 한 줄로 넘어갔습니다. 사실 폼을 다루는 일은 읽기보다 손이 많이 가죠. 입력값을 검증하고, 에러를 화면에 표시하고, 제출 중에는 버튼을 막고, 성공하면 목록을 새로고침하고… 이번 글에서는 Void가 이 과정을 useForm 하나로 어떻게 묶어주는지 살펴보겠습니다. 액션으로 데이터 바꾸기 데이터를 읽을 때 로더를 썼다면, 바꿀 때는 액션을 씁니다. 페이지의 .server.ts에서 action을 내보내면
코딩 에이전트와 함께 React 코드를 짜다 보면 묘한 위화감이 들 때가 있습니다. 코드는 분명히 동작하고 타입도 맞는데, useEffect 안에서 상태를 폭포처럼 줄줄이 갱신하거나 dangerouslySetInnerHTML을 별 고민 없이 넣어두는 식이죠. 에이전트 입장에서는 "요구사항을 만족시키는 코드"를 짠 것이지만, 우리 입장에서는 "리뷰 코멘트가 쏟아질 코드"입니다. 이 간극을 메우는 도구가 Million.co에서 만든 React Doctor입니다. 한 줄짜리 명령으로 React 프로젝트를 진단해서 0~100 사이의 건강
자바스크립트로 무언가를 만들다 보면 의외로 자주 마주치는 순간이 있습니다. 세션 토큰을 만들거나, 비밀번호를 해시하거나, 파일 무결성을 검증하거나, 쿠키에 서명을 넣어야 할 때인데요. 예전 같으면 별도의 라이브러리를 깔아야 했지만, 요즘은 브라우저와 서버 런타임 모두 이런 일을 표준 API로 해낼 수 있습니다. 바로 Web Crypto API입니다. 이 글에서 Web Crypto API의 사용법을 먼저 다루지만, 그 뒤에 깔린 대칭키와 비대칭키 암호화의 원리가 궁금하다면 별도 글에서 따로 풀어 두었습니다. 이름만 들으면 브라우저 전
Rollup은 이미 잘 만들어진 번들러인데, 왜 갑자기 이름이 비슷한 Rolldown이라는 도구가 등장했을까요? 🤔 게다가 Vite는 8 버전부터 오랫동안 써 온 Rollup을 두고 이 Rolldown을 기본 번들러로 채택했습니다. 멀쩡히 돌아가던 도구를 갈아엎은 데는 그만한 이유가 있겠죠. 최근 JavaScript 도구들이 하나둘 Rust로 다시 작성되는 흐름 위에 Rolldown도 놓여 있습니다. SWC가 Babel을, Oxc가 ESLint를 겨냥했다면, Rolldown은 Rollup의 자리를 노립니다. 이번 글에서는 Roll
AI 기능을 웹 앱에 붙이는 일이 요즘 정말 흔해졌습니다. 채팅 인터페이스를 만들거나, LLM에게 도구를 쥐여주거나, 스트리밍 응답을 화면에 뿌리거나. 그런데 막상 시작하면 고민이 생깁니다. OpenAI를 쓸지 Anthropic을 쓸지, React인지 Vue인지, Next.js인지 다른 프레임워크인지에 따라 코드가 전부 달라지거든요. TanStack Query와 TanStack Router로 유명한 TanStack 생태계에서 이 문제를 해결하려고 나온 게 바로 TanStack AI입니다. 스스로를 "AI 도구의 스위스"라고 소개할
Vite+가 로컬 개발 도구를 하나로 통합했다면, 이번에는 배포까지 먹으러 왔습니다. VoidZero가 내놓은 Void는 Vite 앱에 플러그인 하나를 추가하고 void deploy 한 방이면 데이터베이스, 인증, KV 스토리지, 큐까지 갖춘 풀스택 애플리케이션이 Cloudflare Workers 위에 올라가는 배포 플랫폼입니다. "자바스크립트에 드디어 Rails 순간이 온 건가, 아니면 그냥 Cloudflare 종속에 리본을 달아놓은 건가?" 궁금해서 Void가 뭘 하는 건지 직접 파헤쳐봤습니다. Vite+와 Void의 관계 먼저
AI 코딩 에이전트에게 UI를 만들어달라고 하면 종종 난감한 결과물이 나옵니다. 프로젝트에 이미 잘 만들어둔 Button, Card, Modal 같은 컴포넌트가 있는데 에이전트는 그 존재를 모르니까 비슷한 걸 또 만들어버리는 거죠. 디자인 시스템을 열심히 구축해놨는데 AI가 인라인 스타일로 대충 때운 컴포넌트를 내놓으면 정말 답답합니다 😅 이 문제의 원인은 간단합니다. AI 에이전트에게 우리 프로젝트의 UI 컴포넌트에 대한 맥락이 없기 때문인데요. Storybook이 MCP(Model Context Protocol)를 통해 이 문
React로 풀스택 앱을 만들 때 어떤 프레임워크를 쓰시나요? 아마 Next.js를 먼저 떠올리실 텐데요. Next.js가 사실상 표준처럼 자리 잡긴 했지만 쓰다 보면 아쉬운 점도 있습니다. 타입 안전성이 중간중간 끊긴다거나, 캐싱 동작이 예상과 다르게 돌아간다거나, 배포할 때 특정 플랫폼에 묶이는 느낌이 든다거나요. 그런 분들에게 TanStack Start가 반가울 겁니다. TanStack Query와 TanStack Table로 유명한 TanStack 생태계에서 나온 풀스택 React 프레임워크인데요. "엔드투엔드 타입 안전성"
웹 프론트엔드 프로젝트 하나를 제대로 셋업하려면 도구가 정말 많이 필요하죠. 번들러는 Vite, 테스트 러너는 Vitest, 린터는 ESLint, 포맷터는 Prettier... 거기에 Node.js 버전 관리자랑 패키지 매니저까지 더하면 package.json의 devDependencies가 금세 길어지고 설정 파일도 여기저기 흩어집니다. 2026년 3월, Vite의 창시자 Evan You가 이끄는 VoidZero가 이 문제에 대한 답을 내놓았는데요. Vite+ — Vite, Vitest, Oxlint, Oxfmt, Rolldown
자바스크립트 프로젝트를 하나 세팅하려면 설치해야 할 도구가 한두 개가 아닙니다. 코드 린팅에는 ESLint, 포맷팅에는 Prettier, 트랜스파일링에는 Babel이나 SWC, 번들링에는 Webpack이나 Vite... 각각 다른 팀이 다른 언어로 만든 도구들을 조합해서 쓰다 보니 설정 파일만 여러 개, 플러그인 간 버전 충돌에 빌드 속도는 답답하고. 😩 이 파편화된 자바스크립트 도구 생태계를 하나로 통합하겠다는 프로젝트가 있는데요, 바로 Oxc입니다. 이번 포스팅에서는 Oxc가 무엇이고, 어떤 도구들로 구성되어 있으며, 실제 프
예전에 RedwoodJS로 풀스택 웹 앱 만들기라는 글에서 RedwoodJS를 소개해드린 적이 있는데요. React, GraphQL, Prisma를 하나로 묶어서 풀스택 앱을 빠르게 만들 수 있게 해주는 프레임워크였죠. 그 글 마지막에 잠깐 언급했던 RedwoodSDK가 2025년 3월 드디어 v1.0으로 정식 출시되었습니다. RedwoodSDK는 기존 RedwoodJS의 후속작이라기보다는 완전히 새로운 프레임워크에 가깝습니다. GraphQL과 Prisma 중심이었던 기존 접근 방식을 버리고, React Server Componen
웹 서비스를 운영하다 보면 이미지를 다뤄야 하는 일이 참 많은데요. 사용자가 올린 프로필 사진을 썸네일로 줄이거나, 상품 이미지를 WebP로 변환하거나, 여러 이미지를 하나로 합쳐야 할 때가 있죠. 이런 작업을 브라우저가 아닌 서버 쪽에서 처리하려면 어떻게 해야 할까요? Sharp는 Node.js에서 가장 널리 쓰이는 이미지 처리 라이브러리입니다. 내부적으로 C 기반의 libvips 엔진을 사용하기 때문에 ImageMagick보다 4~5배 빠르고, 메모리 사용량도 적습니다. JPEG, PNG, WebP, AVIF, GIF, TIFF