빌드 도구를 바꾸면 개발 속도가 빨라질 것이라는 이야기는 매력적입니다. 하지만 이미 사용자가 있는 앱에서는 첫 화면이 뜨는 것만으로 전환을 결정하기 어렵습니다. 로그인한 사람의 화면, 저장 직후 목록, 오래 열어 둔 탭에서도 기존 동작이 유지되어야 합니다.Cloudflare는 2026년 9월 28일 Vinext 1.0을 발표했습니다. Next.js 애플리케이션을 Vite 기반으로 실행하고 배포 환경의 선택지를 넓히려는 프로젝트입니다. 웹 개발을 오래 해 온 제게 흥미로운 지점은 새 도구 자체보다, 익숙한 API의 행동을 다른 기반에서 어디까지 유지하느냐입니다.이 글은 운영 서비스를 Vinext로 이전한 후기가 아닙니다. 10월 11일 확인한 공식 발표에서 현재 범위를 짚고, 실제 앱의 전환 검토에 사용할..

React의 새 기능을 보면 기존 컴포넌트를 모두 바꾸고 싶어집니다. 그러나 화면이 빨라질지, 효과의 생명주기가 더 이해하기 쉬워질지는 코드의 사용 맥락에 따라 다릅니다.React 19.2에서 소개된 Activity와 useEffectEvent는 숨겨진 화면과 효과 이벤트를 다루는 선택지를 넓혀 줍니다. 이 글은 API 사용법을 나열하기보다 어떤 화면에 적용하고 어떤 화면에는 적용하지 않을지에 초점을 둡니다.Activity는 숨겨진 화면의 생명주기를 명시합니다조건부 렌더링은 보이지 않는 화면을 언마운트하는 단순한 방법입니다. Activity의 hidden 모드는 화면을 유지하면서 효과를 중단하고 업데이트를 늦출 수 있어, 다시 돌아올 가능성이 높은 화면의 상태를 보존하는 데 유용할 수 있습니다.하지만 모..

엔드포인트 목록을 열어놓고 하나씩 세어본 적이 있습니다. 화면 하나를 만들려고 라우트 파일을 만들고, 요청 타입을 정의하고, 클라이언트에서 부를 함수를 또 만들고, 응답 타입을 다시 선언하는 일이 반복되고 있었습니다. 실제 로직은 열 줄인데 그걸 감싸는 껍데기가 세 배쯤 됐습니다.Server Actions로 몇 개를 옮겨보기 시작한 건 그 목록을 본 다음이었습니다. 결론부터 말하면 절반쯤 옮겼고 나머지는 그대로 두었습니다. 이 글은 무엇을 옮겼고 무엇을 왜 남겼는지에 대한 기록입니다.옮기면서 실제로 줄어든 것가장 크게 체감한 것은 같은 타입을 두 번 쓰지 않아도 된다는 점이었습니다. 서버 함수를 직접 호출하는 형태가 되니 인자와 반환 타입이 그대로 이어집니다. 필드 이름을 바꿨을 때 컴파일 단계에서 잡히..

프로젝트에서 useMemo와 useCallback이 몇 개나 쓰이고 있는지 세어본 적이 있습니다. 생각보다 많았고, 더 문제는 그중 상당수가 왜 붙였는지 기억나지 않는 것이었습니다. 언젠가 성능이 걱정돼서 붙였고, 그 뒤로 아무도 건드리지 않은 코드였습니다.React Compiler가 자리를 잡으면서 이 코드들을 어떻게 할지 결정해야 하는 시점이 왔습니다. 컴파일러가 알아서 메모이제이션을 해준다면 손으로 붙인 것들은 중복입니다. 다만 전부 지우면 되는 것도 아닙니다. 여전히 손으로 남겨야 하는 자리가 있고, 그 구분을 모르고 일괄 삭제하면 조용히 느려지거나 이상하게 동작합니다.컴파일러가 해주는 일과 해주지 않는 일React Compiler는 컴포넌트와 훅을 분석해서 렌더 사이에 재사용할 수 있는 값을 자..

프론트엔드를 리액트로 만들다 보면 어느 순간 인증 처리를 어디까지 맡겨야 하는지 고민하게 됩니다. 화면을 그리는 일은 리액트가 잘합니다. 상태를 다루고, 컴포넌트를 나누고, 사용자와 빠르게 상호작용하는 것도 리액트의 장점입니다. 하지만 인증은 조금 다릅니다. 토큰을 어디에 저장할지, 쿠키는 어떻게 다룰지, API 호출 권한은 어디서 확인할지, 새로고침 후 세션은 어떻게 유지할지 같은 문제들이 따라옵니다. 처음에는 단순해 보이지만, 실제 서비스를 운영하려고 하면 생각보다 신경 쓸 부분이 많아집니다. 그래서 요즘 다시 관심을 두고 있는 구조가 BFF입니다. Backend for Frontend의 줄임말인데, 이름 그대로 프론트엔드를 위한 백엔드 계층을 하나 두는 방식입니다. 저는 이 구조를 “서버사이드가 프..

React로 화면을 만들다 보면 생각보다 많은 시간이 API 데이터를 다루는 데 쓰입니다. 데이터를 불러오고, 로딩 상태를 표시하고, 실패했을 때의 처리를 만들고, 다시 새로고침해야 하는 시점을 고민합니다. 처음에는 단순한 fetch 코드로 충분해 보이지만, 화면이 늘어나면 이 흐름이 금방 복잡해집니다. TanStack Query, 예전 이름으로 React Query는 이 문제를 꽤 잘 정리해주는 도구입니다. React 애플리케이션에서 비동기 데이터, 특히 서버에서 가져오는 데이터를 가져오고, 캐싱하고, 동기화하고, 업데이트하는 일을 도와줍니다. 클라이언트 상태와 서버 상태는 다릅니다 React에서 상태라고 하면 보통 useState나 Zustand 같은 상태 관리 도구를 떠올립니다. 하지만 서버에서 가..

프론트엔드 기술을 고를 때마다 React와 Vue는 자주 비교 대상에 올라옵니다. 둘 다 오래 사용되어 왔고, 생태계도 충분히 성숙했습니다. 그래서 이제는 어느 쪽이 더 뛰어난지보다, 지금 만들고 있는 서비스의 성격에 어느 쪽이 더 잘 맞는지를 보는 편이 더 현실적이라고 느낍니다. 2026년 6월 기준으로 React는 19.2 계열, Vue는 3.5 계열을 기준으로 보면 됩니다. 버전 숫자만 보면 둘 다 이미 안정적인 단계에 들어와 있습니다. 새로운 프로젝트에서 선택할 때는 최신 기능 자체보다, 팀이나 개인이 얼마나 오래 유지보수할 수 있는지가 더 중요해졌습니다. React는 생태계와 유연성이 강점입니다 React는 라이브러리에 가깝습니다. 화면을 구성하는 핵심 방식은 제공하지만, 라우팅, 상태 관리, ..

메리톡톡을 리팩토링하면서, 예전에 많이 썼던 아토믹 디자인 패턴이 떠올랐습니다. 한때는 React 컴포넌트를 atom, molecule, organism으로 나누는 것이 무척 체계적으로 느껴졌는데, 지금은 이 패턴에 대해 더 이상 이야기하는 사람을 만나기 어렵습니다. 왜 그럴까 하는 생각이 들어, 이번 기회에 정리해보기로 했습니다. 유행하던 시절 아토믹 디자인은 UI를 가장 작은 단위(atom)로 쪼개고, 이를 조합해 molecule, organism, template, page 순으로 구성하는 방법론입니다. 재사용성을 높이고, 디자인 시스템과 개발 컴포넌트를 일치시키는 데 강점이 있었습니다. 한동안 React 생태계에서 널리 참고되었고, 저도 몇몇 프로젝트에 적용해보면서 그 장점을 체감했습니다. 실무에..

저는 21년째 닷넷 개발자로 일하고 있습니다. 오래 전에 Next.js를 사용하다가 문득 최근의 Next.js는 어떻게 변했을지 궁금해졌습니다. 공식 문서가 워낙 잘 되어 있지만, 오래전에 접하고 잊고 있었던 제 눈에는 생소한 부분이 많았습니다. 이 글은 그냥 시작해보고 정리한 기록입니다. 완벽한 튜토리얼이 아니라, 개발자가 React 생태계의 최신 도구를 접했을 때 느낀 점과 선택한 방식을 공유하려고 합니다. 왜 지금 Next.js인가 제가 손놓기 직전 Next.js는 App Router를 기본으로 채택하면서 구조가 크게 바뀌었습니다. Pages Router에서 App Router로의 전환은 단순한 업데이트가 아니라, 파일 시스템 기반 라우팅과 서버 컴포넌트를 기본으로 삼는 패러다임 변화였습니다. 저는..

React / TypeScript 프로젝트 코딩 규칙 가이드 본 문서는 프로젝트의 일관된 아키텍처와 유지보수성 향상을 위한 작업 규칙 정의서입니다. 새로운 기능을 추가할 때는 아래 구조와 규칙을 반드시 준수하며, 기존 파일의 지역 관례를 최우선으로 적용합니다. 1. 프로젝트 구조 (Directory Architecture) 역할 중심의 디렉터리 분리를 통해 스파게티 코드를 방지하고, 특정 도메인 로직과 UI 컴포넌트의 결합도를 낮춥니다. 경로 (Path) 역할 및 준수 사항 src/main.tsx 애플리케이션의 진입점입니다. 전역 CSS, i18n, 인증 Provider, React Query Provider 등 시스템 전역에 영향을 주는 컨텍스트 및 환경 설정만 배치합니다. src/App.tsx 전체 ..