React 프로젝트에서 성능 최적화를 하다 보면 useMemo, useCallback, React.memo가 자연스럽게 늘어납니다. 처음에는 느린 계산을 줄이기 위한 선택이었는데, 어느 순간부터는 “혹시 모르니 감싸두자”에 가까운 코드가 됩니다. 리뷰에서도 실제 병목보다 dependency array가 맞는지, 콜백 참조가 바뀌는지 같은 이야기로 시간이 많이 쓰입니다.React Compiler는 이 흐름을 바꿀 수 있는 도구입니다. React가 컴포넌트와 훅의 코드를 분석해 안전하다고 판단되는 부분을 자동으로 메모이제이션해 주기 때문입니다. 공식 문서에서도 React Compiler는 수동 useMemo, useCallback, React.memo 사용을 줄이는 방향의 자동 최적화 도구로 설명됩니다.하지..

AI 코딩 도구는 프론트엔드 개발에서 꽤 강력합니다. React 컴포넌트를 만들고, TypeScript 타입을 붙이고, CSS를 작성하고, 테스트 초안까지 만들어 줍니다. 특히 반복적인 UI 작업이나 기존 패턴을 따라가는 작업에서는 생산성이 확실히 좋아집니다.하지만 AI가 만든 코드를 그대로 머지해도 되는지는 다른 문제입니다. 겉으로는 동작하는 것처럼 보여도 요구사항을 일부 놓치거나, 상태 관리를 복잡하게 만들거나, 접근성과 테스트가 빠져 있는 경우가 많습니다.이번 글에서는 AI가 만든 프론트엔드 코드를 리뷰할 때 확인하면 좋은 기준을 정리해보겠습니다. React와 TypeScript 프로젝트를 기준으로 설명하지만, Vue나 다른 프레임워크에서도 대부분 비슷하게 적용할 수 있습니다.1. 요구사항을 제대로..

AI 코딩 도구를 사용하면 기능 구현 속도는 확실히 빨라집니다. Cursor, Claude Code, GitHub Copilot, Codex 같은 도구에게 요구사항을 설명하면 컴포넌트, API 호출 코드, 유틸 함수, 테스트 코드까지 빠르게 생성해 줍니다.하지만 실제 프로젝트에 적용해보면 속도만큼이나 불안한 부분도 생깁니다.요구사항을 일부만 이해하고 구현한다.정상 케이스만 처리하고 예외 케이스를 놓친다.기존 코드 컨벤션과 다른 방식으로 작성한다.동작하는 것처럼 보이지만 실제로는 회귀 버그를 만든다.수정 요청을 했더니 관련 없는 파일까지 바꾼다.그래서 AI 코딩을 실무에 안정적으로 적용하려면 “코드를 먼저 만들고 사람이 확인하는 방식”에서 조금 벗어날 필요가 있습니다. 이때 도움이 되는 접근이 테스트 주도..

React 개발자라면 요즘 매일같이 듣는 단어가 있을 겁니다. 바로 'React Server Components(RSC)'죠. "Next.js 13 이후로 그냥 기본으로 쓰는 거 아니야?" 혹은 "기존 SSR(서버 사이드 렌더링)이랑 이름만 다르고 비슷한 거겠지"라고 생각하며 무심코 넘어가셨나요? 만약 여전히 단순한 텍스트나 정적 데이터를 띄우기 위해 수백 KB의 자바스크립트 번들을 통째로 브라우저에 내려보내고 있다면, 여러분은 지금 React 렌더링 패러다임의 가장 거대한 변화를 놓치고 있는지도 모릅니다. '클라이언트'와 '서버'의 경계를 허물고, 번들 사이즈 0(Zero)의 기적을 만들어내는 RSC. 오늘은 매번 헷갈리던 RSC의 진짜 정체와, 왜 이것이 단순한 기능 추가를 넘어 프론트엔드 아키텍처의..

React Query는 React 어플리케이션에서 서버의 상태를 불러오고, 캐싱하며, 지속적으로 동기화 하고 업데이트 하는 작업을 도와 주는 라이브러리 입니다. 장점 * 캐싱 * Boilerplate 코드의 감소 * get 한 데이터에 update 가 발생하면 자동으로 get을 다시 수행한다. * 동일 데이터 여러번 요청시 한번만 요청한다 (옵션에 따라 중복호출 허용 시간 조절 가능) * 데이터가 오래되었다고 판단하면 다시 get (invalidateQueries) * API 요청 수행을 위한 규격화된 방식 제공 사용 npx create-react-app my-app cd my-app yarn add react-query yarn && yarn start 세팅 // src/index.js import R..