728x90 반응형 TypeScript34 Next.js 16, next lint 대신 ESLint CLI와 Biome 사이의 현실적인 선택 안녕하세요. J4J입니다. 이번 포스팅은 Next.js 16에서 제거된 next lint 명령어가 실제로 어떤 문제를 일으키는지, 그리고 ESLint CLI와 Biome로 대응하는 방법을 살펴보는 시간을 가져보려고 합니다. next lint가 사라진 이유와 next build 변화 Next.js 15까지 사용하던 next lint 명령어를 16으로 올린 뒤에도 그대로 실행하면, 명령을 찾을 수 없다는 에러와 함께 곧바로 실패하는 경우를 마주치게 됩니다. Next.js 16.0.0부터 next lint 명령어는 점진적으로 줄어드는 것이 아니라 next 패키지에서 완전히 삭제되었습니다. next 패키지 안에는 애초에 lint 서브커맨드를 처리하는 코드 자체가 존재하지 않기 때문에, next lint를 실.. 2026. 8. 17. Next.js 16 Async Request APIs, PageProps로 동기 접근을 걷어내는 방법 안녕하세요. J4J입니다. 이번 포스팅은 Next.js 16에서 완전히 제거된 Async Request APIs의 동기 접근이 실제로 어떤 문제를 일으키는지, 그리고 이를 안전하게 마이그레이션하는 방법을 살펴보는 시간을 가져보려고 합니다. Next.js 16 params, searchParams 동기 접근이 조용히 실패하는 이유 Next.js 15에서 params.id처럼 동기로 접근하던 코드를 16으로 올린 뒤에도 그대로 두었는데, 화면에 값이 비어버리는 경우를 마주치게 됩니다. params, searchParams는 각각 라우트 세그먼트의 동적 값과 URL 쿼리스트링을 담아 컴포넌트에 전달하는 Promise 객체이며, Next.js 15에서 이미 Promise로 바뀌었지만 당시에는 마이그레이션 유.. 2026. 8. 15. Next.js 16 next/image 기본값 변경, quality 75부터 SSRF 방어까지 점검 가이드 안녕하세요. J4J입니다. 이번 포스팅은 Next.js 16으로 업그레이드하면서 next/image의 여러 기본값이 어떻게 조용히 달라졌는지 알아보는 시간을 가져보려고 합니다. next/image quality 기본값 변경, qualities 배열로 제한되는 화질 Next.js 16으로 프로젝트를 올린 뒤에도 quality prop을 예전과 똑같이 쓰고 있는데, 이미지가 이전과 다른 화질로 렌더링되는 경우를 마주치게 됩니다. 이 변화의 원인은 next/image의 images.qualities 설정이 15와 16 사이에 달라졌기 때문입니다. images.qualities는 quality prop으로 지정할 수 있는 값을 제한하는 배열이며, next/image 컴포넌트에서 이 배열에 없는 값을 지정하면.. 2026. 8. 12. Next.js 16 App Router에서 Activity, useEffectEvent, View Transitions 통합하기 안녕하세요. J4J입니다. 이번 포스팅은 React 19.2에서 새로 추가된 Activity, useEffectEvent, View Transitions를 Next.js 16 App Router 환경에 통합해 활용하는 방법을 살펴보는 시간을 가져보려고 합니다. 세 API 각각이 무엇을 해결하는지는 별도로 다루지 않으니, 기본 개념이 궁금하신 분들은 지난 포스팅을 먼저 참고해 주시길 바랍니다. React 19.2: Activity·useEffectEvent 정식 지원, View Transitions 실험 단계안녕하세요. J4J입니다. 이번 포스팅은 React 19.2에서 새롭게 추가된 Activity, useEffectEvent와 함께, 아직 실험 단계에 있는 View Transitions까지 살펴보는 시.. 2026. 8. 11. React 19.2: Activity·useEffectEvent 정식 지원, View Transitions 실험 단계 안녕하세요. J4J입니다. 이번 포스팅은 React 19.2에서 새롭게 추가된 Activity, useEffectEvent와 함께, 아직 실험 단계에 있는 View Transitions까지 살펴보는 시간을 가져보려고 합니다. useEffectEvent로 Effect의 최신 값 참조 문제 해결하기 Effect 안에서 여러 반응형 값을 함께 참조하다 보면, 그중 일부 값이 바뀔 때만 Effect를 다시 실행하고 싶은 상황을 마주치게 됩니다. 일정 간격마다 값을 증가시키는 카운터를 예로 들어보겠습니다. 간격(intervalMs)이 바뀌면 새로운 간격으로 다시 구독해야 하지만, 한 번에 증가시키는 값(step)은 항상 최신 값을 반영하면서도 그 값이 바뀌었다는 이유만으로 다시 구독할 필요는 없습니다. // .. 2026. 8. 9. Next.js 16, Layout Deduplication과 Incremental Prefetching 동작 원리 안녕하세요. J4J입니다. 이번 포스팅은 Next.js 16에서 개편된 프리페치 동작인 Layout Deduplication과 Incremental Prefetching이 실제로 어떻게 동작하는지 살펴보는 시간을 가져보려고 합니다. 기존 프리페치 방식의 한계 React로 App Router의 리스트 화면을 만들다 보면, 링크가 많아질수록 페이지 이동이 오히려 무거워지는 상황을 마주치게 됩니다. Next.js의 Link 컴포넌트는 뷰포트에 들어오거나 hover되면 해당 라우트를 미리 내려받아 두는 프리페치를 자동으로 수행합니다. 이때 프리페치 대상 범위는 loading.js 파일이 있는지에 따라 달라지는데, loading.js가 없으면 페이지 전체를, 있으면 레이아웃부터 첫 loading 경계까지를 미.. 2026. 8. 6. React Compiler와 Next.js 16: useMemo/useCallback이 사라지는 이유 안녕하세요. J4J입니다. 이번 포스팅은 Next.js 16에서 stable로 전환된 React Compiler를 활성화하는 방법과, 기존 useMemo/useCallback/memo로 작성했던 코드를 걷어내는 방법에 대해 알아보는 시간을 가져보려고 합니다. React Compiler란 무엇인가 React로 리스트나 자식 컴포넌트를 다루다 보면 부모 컴포넌트가 리렌더링될 때마다 관련 없는 자식 컴포넌트까지 함께 리렌더링되는 상황을 자주 마주치게 됩니다. 이 문제를 해결하기 위해 그동안은 useMemo로 계산 결과를 캐싱하고, useCallback으로 함수 참조를 고정하고, memo로 컴포넌트 자체를 감싸는 방식을 직접 작성해야 했습니다. 저의 경우 useCallback의 의존성 배열에 값을 하나 빠뜨.. 2026. 8. 2. Turbopack, Next.js 16 기본 번들러 전환과 webpack 커스텀 설정 마이그레이션 안녕하세요. J4J입니다. 이번 포스팅은 Next.js 16에서 Turbopack이 기본 번들러로 자리잡은 배경과, 기존 webpack 커스텀 설정을 Turbopack 설정으로 옮기는 방법에 대해 알아보는 시간을 가져보려고 합니다. Turbopack이 Next.js 16의 기본 번들러가 된 이유 Next.js는 오랫동안 webpack을 기본 번들러로 사용해왔고, 프로젝트 규모가 커질수록 dev 서버의 컴파일 속도와 프로덕션 빌드 시간이 체감될 정도로 느려지는 경우가 많았습니다. 저의 경우 페이지 수가 많은 프로젝트에서 코드 한 줄을 수정하고 Fast Refresh 결과를 확인하기까지 기다리는 시간이 점점 길어지는 것을 체감한 적이 있습니다. 그러면 Next.js 16은 번들러 문제를 어떻게 해결했.. 2026. 8. 1. Next.js 16 proxy.ts, middleware.ts를 대체하는 네트워크 경계 재정의 안녕하세요. J4J입니다. 이번 포스팅은 Next.js 16에서 middleware.ts가 proxy.ts로 바뀐 배경과, 달라진 네트워크 경계를 실제 코드로 확인해보는 시간을 가져보려고 합니다. middleware.ts가 proxy.ts로 바뀐 이유, Next.js 16 네트워크 경계 재정의 Next.js 15까지는 요청이 라우트 핸들러나 페이지에 도달하기 전에 가로채는 진입점으로 middleware.ts 파일을 사용했습니다. 인증 체크, 리다이렉트, 헤더 조작처럼 애플리케이션 앞단에서 처리해야 하는 로직을 이 파일 하나에 모아둘 수 있었습니다. 다만 middleware라는 이름은 Express.js 같은 서버 프레임워크의 middleware 개념과 혼동을 일으키기 쉬웠습니다. Express의 .. 2026. 7. 27. Next.js 16 Cache Components: use cache부터 updateTag까지 캐시 무효화 총정리 안녕하세요. J4J입니다. 이번 포스팅은 Next.js 16에서 바뀐 캐싱 모델인 Cache Components와, use cache 디렉티브부터 revalidateTag, updateTag, refresh까지 캐시를 다루는 방법에 대해 알아보는 시간을 가져보려고 합니다. Next.js 16 캐싱 모델이 바뀐 이유, Cache Components란? Next.js 15까지는 무언가를 캐시하려면 상황에 따라 서로 다른 도구를 조합해야 했습니다. fetch 요청 하나를 캐시하려면 cache나 next.revalidate 옵션을 fetch 호출부에 직접 넘겨야 했고, DB 조회처럼 fetch가 아닌 임의의 함수를 캐시하려면 별도로 unstable_cache로 감싸야 했습니다. 여기에 정적 셸과 동적 콘텐츠.. 2026. 7. 26. onCaughtError, onUncaughtError로 완성하는 React 19 에러 로깅 정리 안녕하세요. J4J입니다. 이번 포스팅은 React 19에 새로 추가된 onCaughtError, onUncaughtError와 기존 onRecoverableError까지 함께 활용해 프로덕션 에러 로깅을 완성하는 방법에 대해 알아보는 시간을 가져보려고 합니다. Error Boundary가 잡은 에러를 놓치지 않으려면 React 18까지는 Error Boundary가 에러를 잡았을 때 그 에러를 컴포넌트 단위로만 처리할 수 있었고, 여러 Error Boundary의 에러를 한 곳에서 일괄적으로 받아 외부 로깅 서비스로 전달할 방법이 없었습니다. Error Boundary는 componentDidCatch 생명주기에서 에러를 받을 수 있었지만, 이는 클래스 컴포넌트 내부에 국한된 처리였고 루트 단위로 .. 2026. 7. 25. React 19 useTransition, Actions로 비동기 pending과 에러 한 번에 처리하기 안녕하세요. J4J입니다. 이번 포스팅은 React 19에서 useTransition에 async 함수를 직접 전달하여 비동기 작업의 pending 상태와 에러를 한 번에 관리하는 방법에 대해 알아보는 시간을 가져보려고 합니다. useTransition에 async 함수를 사용하면 좋은 상황 정렬 변경, 검색, 탭 전환처럼 버튼 클릭 한 번으로 비동기 작업이 시작되는 화면을 만들다 보면 로딩 상태와 에러를 함께 관리해야 하는 상황을 마주치게 됩니다. 지금까지는 이런 화면을 만들 때 로딩 여부와 에러 메시지를 각각 별도의 state로 선언하고, try/catch/finally로 직접 관리해야 했습니다. 제가 처음 이런 화면을 만들 때는 finally에서 로딩 state를 내려주는 코드를 깜빡해서, 요청.. 2026. 7. 20. React 19 ref as prop과 Context 렌더링으로 완성하는 forwardRef 없는 컴포넌트 설계 안녕하세요. J4J입니다. 이번 포스팅은 React 19에 새롭게 추가된 ref as prop과 Context 렌더링 방식을 이용하여 forwardRef 없이 컴포넌트를 작성하는 방법에 대해 알아보는 시간을 가져보려고 합니다. forwardRef 없이 ref를 prop으로 받아야 하는 이유 재사용 가능한 Input, Button 같은 컴포넌트를 만들다 보면 부모 컴포넌트가 DOM 요소에 직접 접근해야 하는 상황을 마주치게 됩니다. 지금까지는 이런 컴포넌트를 만들 때 함수 컴포넌트를 forwardRef로 감싸고, ref를 두 번째 인자로 따로 받아야 했습니다. 제가 처음 컴포넌트 라이브러리를 만들 때 가장 번거롭게 느꼈던 부분은 TypeScript로 forwardRef의 제네릭 타입 두 개를 매번 맞춰.. 2026. 7. 19. React 19 문서 메타데이터와 리소스 프리로드, react-helmet 없이 직접 관리하기 안녕하세요. J4J입니다. 이번 포스팅은 React 19에 새롭게 추가된 문서 메타데이터와 리소스 프리로드 기능을 이용하여 react-helmet 없이 head를 관리하는 방법에 대해 알아보는 시간을 가져보려고 합니다. react-helmet 없이 React 19에서 문서 메타데이터를 다뤄야 하는 이유 Next.js를 사용하지 않는 순수 React 프로젝트에서 페이지마다 title이나 meta 태그를 동적으로 바꾸려면 지금까지는 react-helmet-async 같은 별도 라이브러리를 설치해야 했습니다. react-helmet-async는 Helmet 컴포넌트로 head에 들어갈 태그들을 감싸는 방식으로 동작합니다. // ❌ react-helmet-async로 head를 관리하는 기존 방식import.. 2026. 7. 17. React 19 useOptimistic, Server Action 없이 낙관적 업데이트를 처리하는 방법 안녕하세요. J4J입니다. 이번 포스팅은 React 19에 새롭게 추가된 useOptimistic 훅을 이용하여 낙관적 업데이트를 처리하는 방법에 대해 알아보는 시간을 가져보려고 합니다. useOptimistic을 사용하면 좋은 상황 좋아요 버튼을 누르면 서버 응답이 돌아올 때까지 화면이 잠깐 멈춰 있는 것처럼 느껴지는 경험을 하게 됩니다. 지금까지는 이런 지연을 줄이기 위해 useState로 임시 상태를 직접 만들고, 요청이 실패하면 이전 값으로 되돌리는 로직을 컴포넌트마다 작성해야 했습니다. 저의 경우 이런 롤백 로직을 컴포넌트마다 반복해서 작성하다 보면, 실수로 이전 값을 잘못 저장해 두어 되돌리기가 엉뚱하게 동작하는 경우도 종종 겪었습니다. // ❌ useState로 직접 낙관적 업데이트와 롤.. 2026. 7. 13. React 19 use API, Promise와 Context를 조건부로 읽는 방법 안녕하세요. J4J입니다. 이번 포스팅은 React 19에 새롭게 추가된 use API를 이용하여 Promise와 Context를 다루는 방법에 대해 알아보는 시간을 가져보려고 합니다. use를 사용하면 좋은 상황 지금까지 컴포넌트 안에서 비동기 데이터를 다루려면 useState와 useEffect를 조합하는 방식이 일반적이었습니다. 데이터를 담을 state, 로딩 여부를 담을 state, 에러를 담을 state를 각각 선언하고 useEffect 안에서 fetch를 호출한 뒤 결과에 따라 각 state를 갱신하는 코드를 작성하게 됩니다. 제가 처음 이 패턴을 반복해서 작성할 때 가장 번거롭게 느꼈던 부분은 데이터를 사용하는 컴포넌트마다 동일한 형태의 보일러플레이트가 계속 늘어난다는 것이었습니다. //.. 2026. 7. 12. React Server Action, API Route 없이 서버 함수를 호출하는 방법 안녕하세요. J4J입니다. 이번 포스팅은 React Server Action이 무엇이고, 실무에서 어떻게 활용할 수 있는지에 대해 알아보는 시간을 가져보려고 합니다. Server Action이란? Server Action은 서버에서 실행되는 비동기 함수를 클라이언트에서 직접 호출할 수 있게 해주는 기능입니다. React 19에서 공식 API로 안정화되었으며, Next.js App Router 환경에서 가장 자연스럽게 사용할 수 있습니다. 그러면 Server Action이 왜 필요할까요? 기존에는 클라이언트에서 서버의 데이터를 변경하기 위해 다음과 같은 과정이 필요했습니다. API 엔드포인트(Route Handler) 작성클라이언트에서 fetch로 해당 엔드포인트 호출응답 처리 및 상태 업데이트 Ser.. 2026. 7. 5. 모노레포를 위한 Turborepo 기초 가이드 안녕하세요. J4J입니다. 이번 포스팅은 모노레포를 위한 turborepo 사용하는 방법에 대해 적어보는 시간을 가져보려고 합니다. 모노레포란 ? 모노레포는 하나의 저장소에 애플리케이션 서비스, 라이브러리 패키지 등을 서로 구분하지 않고 여러 개의 프로젝트를 함께 관리하는 방식을 말합니다. 보통 저장소를 관리할 때 가장 많이 접하는 구조는 멀티레포가 될 것입니다. 멀티레포는 1개의 프로젝트마다 1개의 저장소를 소유하고 있는 것으로, 말 그대로 서로 독립적인 방식으로 관리되며 각자의 프로젝트에 관여하지 않는 구조를 말합니다. 간단하게 예시를 들면 멀티레포는 다음과 같은 구조가 나올 수 있습니다. // design-system repo- design-system// application service.. 2026. 1. 27. 이전 1 2 다음 728x90 반응형