Next.js는 이미지 처리 과정에서 기본적으로 몇 가지 최적화 기능을 제공한다.

• Lazy Loading
• 포맷 변환 (원본 → WebP / AVIF)
• Responsive Image 생성

마이그레이션 당시에는 이미지가 화면에서 언제 노출되는지를 기준으로 우선순위를 다르게 적용했다.

첫 화면에 바로 보이는 배너 이미지는 priority를 사용해 먼저 요청되도록 했고, 리스트 내부 썸네일은 기본 lazy loading 동작을 유지해 초기 렌더링 비용을 줄이고자 했다.

이번에는 Next.js가 제공하는 이미지 최적화 기능을 하나씩 정리하면서, 어떤 요소가 실제 체감 성능에 가장 큰 영향을 주는지도 함께 확인해보려고 한다.

성능 비교해보기

총 4가지 경우를 두고, 같은 이미지를 렌더링이 어떻게 이뤄지고 있는지 확인해보았다. 앞으로 정리할 테스트는 아래 링크를 통해서 직접 볼 수 있다. https://test-image-improvement.vercel.app/

A. 기본 <img/>

• viewport 포함 여부와 관계없이 모든 이미지 리소스가 초기 렌더링 시점에 동시에 요청된다.
• 이미지의 타입이 jpeg로 원본 이미지 포멧을 따라간다.

B. LazyLoading 적용

A 와 동일한 리소스를 활용하고 대신 img 태그의 loading 속성을 lazy 로 설정하여 Lazy Loading 되도록 설정한 후 다시 확인해보았다.

<img src="image.jpg" alt="..." loading="lazy" />
<iframe src="video-player.html" title="..." loading="lazy"></iframe>

초기에는 렌더링시에 바로 노출되는 이미지들만 로드한다. 이후 스크롤을 내려 하단에 위치한 이미지 리소스가 필요한 경우에 로드되는 것을 확인할 수 있다.

• 초기 리소스 로드, 이후 Lazy Load 되는 리소스가 로드되는 두가지 시점이 타임라인에 찍혀있는 것을 볼 수 있다.

• 타입은 여전히 jpeg 원본을 활용하고 있다.

C. Next.js Image 컴포넌트 기본 활용

• 현재 테스트에서는 viewport 안에 있는 이미지들이 먼저 요청되는 모습을 볼 수 있었다.
• 이미지 타입이 jpeg 원본 이미지 포멧에서 avif 이미지 포멧으로 변경되었다.
• <Image /> 역시 기본적으로 lazy loading이 적용되며, viewport 밖 이미지는 즉시 요청되지 않는다.

Next.js 의 <Image />는 원본 파일 자체를 직접 변경하는 방식이 아니라, 요청 시점에 최적화된 이미지를 별도 endpoint를 통해 전달하는 구조로 동작한다.

실제 Network 탭을 보면 원본 이미지 URL이 그대로 사용되지 않고, _next/image 경로를 통해 다시 요청되는 것을 확인할 수 있다.

w(width), q(quality) 같은 쿼리도 추가되어서 이미지 최적화가 적용된 것을 볼 수 있다.

D. Next.js Image 컴포넌트의 priority 활용

• priority가 적용된 이미지는 lazy loading이 비활성화되고 preload 대상으로 먼저 요청된다.
• 이미지 포맷이나 품질 자체는 달라지지 않지만, 초기 렌더링 시점에 요청되는 리소스가 앞당겨진다. 상단 이미지(C)와 비교했을 때 이미지 사이즈가 커진 것을 볼 수 있었다.
• preload 시점과 선택된 width 후보에 따라 일부 이미지의 초기 전송량이 더 크게 나타날 수 있었고, 실제로는 LCP도 오히려 길어지는 결과가 나타났다.
  

E. Next.js Image 컴포넌트의 size 적용해주기

<Image
  src={...}
  sizes="(max-width: 768px) 100vw, 33vw"
/>

정리

이번 최적화 케이스들을 비교하면서 Next.js 공식 문서도 함께 살펴보았는데, 이번에 확인한 옵션 외에도 이미지 품질, 크기, placeholder 등 다양한 설정이 제공되고 있었다.

가장 먼저 체감되는 차이는 lazy loading 여부에서 나타났고, 가장 큰 전송량 감소는 sizes 설정에서 확인할 수 있었다.

<img> 태그에서도 loading="lazy"만으로 초기 요청 수를 줄일 수 있었지만, <Image />는 여기에 포맷 변환과 _next/image 기반 최적화 경로까지 함께 제공한다는 점에서 차이가 있었다.

반면 priority는 첫 화면에서 반드시 빠르게 보여야 하는 이미지에는 유효했지만, 여러 이미지에 동시에 적용할 경우 기대한 만큼 성능이 개선되지 않을 수도 있었다. 특히 이번 비교에서는 sizes 없이 priority만 적용했을 때 LCP가 오히려 길어지는 결과도 확인할 수 있었다.

결국 <Image />는 단순히 태그를 교체하는 것보다, 어떤 이미지를 어떤 크기로 먼저 보여줄지까지 함께 설계해야 효과가 커지는 기능에 가까웠다. 특히 sizes를 함께 지정했을 때 responsive image 최적화 효과가 가장 분명하게 나타나는 것을 확인할 수 있었다.

무조건 Image 컴포넌트가 좋은가..?

물론 모든 이미지에 <Image />가 필요한 것은 아니다. 이미 충분히 작은 리소스나 SVG처럼 포맷 최적화 이득이 크지 않은 경우에는 기본 <img> 태그가 더 단순한 선택이 될 수 있다. 특히 반복적으로 사용하는 정적 이미지라면, 처음부터 WebP 같은 가벼운 포맷으로 준비해 <img> 태그로 직접 사용하는 편이 오히려 불필요한 최적화 단계를 줄이는 방법이 될 수 있다.

마치며

이번 내용을 정리하면서 lazy loading과 priority를 적용할 때의 판단이 크게 잘못되지 않았다는 점을 다시 확인할 수 있었다 😩

특히 Network 타임라인으로 리소스 요청 시점을 직접 비교해보니, 어떤 최적화가 실제로 먼저 체감되는지 더 직관적으로 이해할 수 있었다.

또한, <Image />를 사용하는 경우뿐 아니라, 기본 <img> 태그를 선택하는 기준도 함께 정리할 수 있었다.

Reference

• Next.js Image Component 공식 문서
• Next.js Image Optimization 가이드 (Vercel Academy)
• MDN Lazy Loading 문서

비슷한 문제를 푸는 SWR이라는 라이브러리가 있다는 건 알고 있었다. 하지만 "TanStack Query가 더 좋다"는 막연한 인식만 있었을 뿐, 실제로 어떻게 다른지, 혹은 SWR이 더 나은 선택이었을 상황이 있었는지는 따져본 적이 없었다.

그래서 두 라이브러리를 여러가지에서 알아보고 앞으로 의식적으로 기술 스택을 선택하기 위한 기준을 마련하기 위해서 정리해보았다.

철학

TanStack Query

• 기존에 서버 데이터를 다루는 방식은 state와 useEffect의 조합이었다. 일반적인 클라이언트 상태를 표현하고 관리하는 데는 효과적이지만, 비동기 상태 즉 서버 상태를 관리하기에는 어색한 부분이 있었다.
• TanStack Query는 이 문제를 해결하기 위해 '서버 상태 라이브러리' 로 정의한다. 서버와 클라이언트 사이의 비동기 작업을 관리하는 역할을 담당하며, Redux나 Zustand 같은 클라이언트 상태 라이브러리와는 명확히 역할을 구분한다.
• 그리고 캐싱, 백그라운드 업데이트, Mutation, DevTools까지 — 비동기 데이터와 관련한 복잡한 상황을 처음부터 고려하여 설계된 라이브러리다.

SWR

• 반면 SWR은 데이터 캐싱에 초점을 맞춘 라이브러리다.
• SWR은 캐시에서 먼저 데이터를 반환하고(stale) 이후 요청을 보내 최신 데이터로 업데이트하는(revalidate) 플로우를 단 하나의 훅으로 단순화한다.
• Vercel에서 만든 라이브러리인 만큼, Next.js와의 궁합이 좋다는 제품적인 특징도 존재한다.

핵심 기능 비교

2.1 캐시 키 설계와 무효화 전략

캐싱은 두 라이브러리 모두 지원하지만, 어떻게 캐시를 식별하고 무효화하는지에서 차이가 난다.

SWR은 캐시 키로 문자열을 사용한다.

보통 fetch URL이 그대로 키가 되기 때문에 직관적이고 간단하다.

// SWR — 문자열 기반 캐시 키
useSWR('/api/todos?status=done', fetcher)
useSWR('/api/todos?status=pending', fetcher)

// todos 관련 캐시 전체 무효화 → 패턴 매칭을 직접 구현해야 함
// 문자열 관련 매칭 로직을 많이 사용
mutate(key => typeof key === 'string' && key.startsWith('/api/todos'), undefined, { revalidate: true })

반면 TanStack Query는 캐시 키로 배열을 사용한다. 배열을 사용하면 계층적인 키를 만들 수 있어 캐시 무효화가 훨씬 강력해진다.

실제 앱에서는 "유저 정보를 수정했으니 유저 관련 캐시를 전부 날려야 하는" 상황이 자주 생긴다. TanStack Query의 계층적 키 설계는 이런 케이스를 훨씬 명확하게 처리할 수 있다.

// TanStack Query — 배열 기반 캐시 키
useQuery({ queryKey: ['todos', { status: 'done' }],    queryFn: fetchTodos })
useQuery({ queryKey: ['todos', { status: 'pending' }], queryFn: fetchTodos })

// todos 관련 캐시 전체 무효화 → prefix 하나로 끝
queryClient.invalidateQueries({ queryKey: ['todos'] })

또한 TanStack Query는 데이터의 신선도를 staleTime과 gcTime 두 개의 개념으로 분리해서 관리한다.

useQuery({
  queryKey: ['user'],
  queryFn: fetchUser,
  staleTime: 1000 * 60 * 5,  // 5분간 fresh → 이 안에선 refetch 안 함
  gcTime:    1000 * 60 * 10, // 10분 후 메모리에서 제거
})

staleTime- 가져온 데이터가 얼마나 오래 "신선한" 상태로 유지되는지를 결정한다. 이 기간 동안에는 컴포넌트가 다시 마운트되거나 refetch가 트리거되더라도 TanStack Query는 네트워크 요청을 보내지 않는다.

gcTime- 비활성 캐시가 메모리에서 제거되기까지의 시간을 제어한다. 반면 SWR은 staleTime이나 조건부 자동 재검증 개념이 없다.

캐싱된 데이터의 refetching 시점을 구체적으로 제어하고 싶다면 TanStack Query가 더 적합하다.

2.2 번들 사이즈

SWR은 gzip 기준 약 4.2KB의 매우 가벼운 라이브러리다.

TanStack Query는 풍부한 기능만큼 11.4KB로 조금 더 무겁다.

하지만 13KB가 엄청난 병목을 일으킬 만큼의 용량이 아니기 때문에 크게 유의미한 비교는 아닌 것 같다.

2.3 Mutation과 Optimistic Update

SWR은 별도의 useMutation 훅이 없다. mutate 함수 하나가 캐시 업데이트와 재검증을 동시에 담당한다. v2부터 useSWRMutation이 추가됐다고 하지만, 뮤테이션 이후 캐시 무효화는 여전히 수동으로 처리해야 한다.

const toggleTodo = async () => {
  mutate(`/api/todos/${id}`, { ...todo, done: !todo.done }, false) // 낙관적 업데이트
  try {
    await updateTodo(id, { done: !todo.done })
    mutate(`/api/todos/${id}`) // 성공 후 재검증
  } catch {
    mutate(`/api/todos/${id}`, todo, false) // 실패 시 수동 롤백
  }
  // mutation 로딩 상태는 useState로 따로 관리해야 함
}

TanStack Query는 useMutation 훅이 명시적으로 분리되어 있고, onMutate / onSuccess / onError / onSettled 라이프사이클 콜백을 제공한다.

const mutation = useMutation({
  mutationFn: (newData) => updateTodo(id, newData),
  onMutate: async (newData) => {
    await queryClient.cancelQueries({ queryKey: ['todos', id] })
    const snapshot = queryClient.getQueryData(['todos', id])
    queryClient.setQueryData(['todos', id], (old) => ({ ...old, ...newData }))
    return { snapshot }
  },
  onError: (err, newData, context) => {
    queryClient.setQueryData(['todos', id], context.snapshot) // 자동 롤백
  },
  onSettled: () => {
    queryClient.invalidateQueries({ queryKey: ['todos', id] })
  },
})

// 로딩·에러 상태가 훅에서 바로 제공됨
const { isPending, isError } = mutation

SWR은 언제 써보면 좋을까?

솔직히 비교하면서도 TanStack Query가 더 좋아 보였던 건 사실이다. 비동기 작업과 관련된 다양한 케이스를 처음부터 고려해 설계된 라이브러리라는 것이 많이 드러났던 것 같다.

그럼에도 SWR을 쓰면 좋은 상황들은 있는 것 같다.

단순한 앱에서의 키 관리가 편리하다. TanStack Query를 쓰다 보면 쿼리키를 어떻게 설계할지 고민하게 되는 순간이 온다. 키가 다른 쿼리의 무효화에도 영향을 줄 수 있기 때문에 쿼리키 팩토리 패턴 같은 것까지 고려해야 하는 상황이 생긴다. 이 복잡도는 정교한 캐시 제어를 위한 필연적인 과정인 것 같다. 반면 SWR은 URL이 곧 캐시 키이기 때문에, 정교한 무효화 전략이 필요 없는 단순한 앱이라면 오히려 이 단순함이 장점이 되는 것 같다.

러닝커브가 상대적으로 낮다. TanStack Query는 useQuery와 useMutation 각각의 사용법과 내부 옵션을 파악해야 한다. SWR은 mutate 하나로 처리하기 때문에 배우는 데 드는 비용이 적다. 다만 이 단순함의 이면에는 mutation 상태(isPending, isError)를 라이브러리가 제공하지 않아 직접 관리해야 한다는 점이 있긴 하다.

결국 두 라이브러리의 선택 기준은 앱의 복잡도에 있는 것 같다.

단순한 read-heavy 앱이라면 SWR의 단순함이 오히려 강점이 되고, mutation이 복잡하거나 정교한 캐시 무효화가 필요하다면 TanStack Query의 구조화된 설계가 필요한 상황이라고 생각한다.

마치며

상당히 닮은 두 라이브러리를 비교해보면서 써보지 않았던 SWR에 대해서 알게되어 새로웠다. 그러면서 tanstack query가 비동기와 관련한 작업을 코드레벨에서 부터 잘 설계한 라이브러리라고 느껴져 새삼 인기가 많은 이유를 알게 된 것 같다. 앞으로 두 라이브러리를 가지고 어떤 것을 사용할지 판단할 때 적합한 판단을 내릴 수 있을 것 같다.

Reference

• TanStack Query 공식 문서 https://tanstack.com/query/latest/docs/framework/react/overview
• TanStack Query 소스 코드 — utils.ts https://github.com/TanStack/query/blob/main/packages/query-core/src/utils.ts
• SWR 공식 문서 https://swr.vercel.app
• LogRocket — SWR vs TanStack Query https://blog.logrocket.com/swr-vs-tanstack-query-react/

수익화를 목적으로 개인 프로젝트로 QR Generator와 Convert Image라는 두 개의 툴 서비스를 운영하면서, 아래와 같은 한계와 문제들이 있었습니다.

• 마케팅 경험의 부재: 유지보수와 개선 방향을 잡기 위해 GA4, GSC 데이터를 세팅했지만, 데이터를 통해 어떤 인사이트를 도출하고 다음 방향성을 정해야 하는지에 대한 경험이 부족했습니다.
• 관리 부담: 두 서비스의 GSC, GA4 데이터를 각각 확인하고 전략을 세우는 데 상당한 시간이 소요되었습니다.
• 의사결정의 모호함: 어떤 프로덕트에 리소스를 더 집중해야 할지 데이터 기반으로 우선순위를 정하기 어려웠습니다.
• 실행의 병목: 리포트에서 "메타 타이틀을 수정하세요"라는 인사이트를 얻더라도, 실제 파일 수정과 PR 생성까지 이어지는 과정이 번거로워 실행이 미뤄지는 문제가 있었습니다.

단순히 데이터를 보여주는 도구가 아니라, 스스로 판단하고 코드를 수정해 PR까지 올리는 에이전트가 필요했습니다.

아래에서는 에이전트를 구성하는 전체 구현 과정보다는, 실제로 설계하면서 중요하게 판단했던 의사결정 지점들을 중심으로 기록해두었습니다.

프로젝트 구조 결정하기: Monorepo vs Multi-Repo

에이전트를 설계할 때 가장 먼저 마주한 고민은 "에이전트가 두 프로젝트를 어떤 방식으로 바라보게 할 것인가?"였습니다. 모노레포를 고려하기도 했지만, 최종적으로는 Multi-Repo 구조를 유지하되 이를 상위 계층에서 통합 관리하는 방식을 선택했습니다.

• 코드의 독립성: 두 프로젝트가 공유하는 코드가 없어 결합도를 높일 이유가 없었고, 모노레포를 도입하려면 기존 프로젝트 구조를 변경해야 했습니다.
• 데이터 중심의 통합: 에이전트에게 필요한 것은 코드 전체가 아니라 각 프로덕트의 데이터와 PR 생성 권한이었습니다.
• 확장성: 이 구조 덕분에 기존 프로젝트 설정을 거의 건드리지 않고도 새로운 프로덕트를 언제든 관리 대상에 추가할 수 있었습니다.

Agent의 단계별 설계

핵심은 분석에서 실행까지 이어지는 파이프라인을 만드는 것이었습니다.

1. Analysis (분석) 에이전트는 먼저 각 프로덕트의 GSC(Search Console), GA4(Analytics) 지표를 수집합니다. 수집된 로우 데이터는 통합 분석 모듈을 통해 가공됩니다. 이 모듈은 단순히 데이터를 나열하는 것이 아니라, 각 서비스의 트래픽, 사용자 참여도, SEO 순위, 수익 데이터를 사전에 정의한 목표 지표와 비교합니다.

   특히 서비스마다 중요도가 다르다는 점을 반영하기 위해 가중치 기반의 Health Score를 계산하도록 했습니다. 이를 통해 어떤 서비스의 성장이 정체되어 있는지, 어디에 리소스를 우선 투입해야 하는지를 보다 객관적으로 판단할 수 있게 했습니다.

   Gemini AI는 이렇게 가공된 지표 분석 결과와 트렌드 데이터를 결합해 아래와 같은 구조화된 마크다운 리포트를 생성합니다.

   • Executive Summary: 전체 프로덕트 상태 요약

   • Health Score: 트래픽, SEO, 수익률을 가중 합산한 건강 지표

   • Action Plan: 하이라이트된 개선 과제 (🔴 긴급, 🟡 중요, 🟢 건의)

     그리고 이 리포트를 기반으로 아래 과정을 따라 실제 기능 개선을 수행합니다.

1. Action Extraction (추출) 마크다운 리포트에서 실행 가능한 액션을 구조화된 데이터로 변환합니다. 이 단계에서는 데이터 파싱 전략으로 성능을 확보하고, 복잡한 문맥만 LLM Fallback으로 처리하는 하이브리드 방식을 채택했습니다.

   기존에는 전체 리포트를 LLM으로만 파싱했는데, 불필요한 토큰 소모가 컸고 특히 파일 경로를 잘못 짚는 환각(Hallucination)이 자주 발생했습니다. Regex-First 방식으로 전환한 뒤에는 약 90%의 전형적인 수정 액션을 거의 즉시 추출할 수 있었고, 비용도 거의 0에 가깝게 줄일 수 있었습니다.

2. Action Validation (검증) AI가 제안한 액션이 안전한지 검증합니다. 사전에 정의된 파일과 태그(Meta Title, Description 등)만 수정할 수 있도록 하는 화이트리스트 방식을 적용해 시스템 안정성을 확보했습니다.

   여기서 화이트리스트(Whitelist) 방식이란, "허용된 것 외에는 모두 금지"하는 보안 원칙입니다. 예를 들어 .env 같은 민감 파일은 접근 자체를 차단하고, layout.tsx 같은 특정 SEO 관련 파일과 update_meta_title 같은 특정 액션 타입만 통과시키도록 제한했습니다. 이 덕분에 rm -rf 같은 파괴적인 명령이나 예상하지 못한 파일 수정은 구조적으로 발생할 수 없도록 설계할 수 있었습니다.

3. Repository Dispatch (실행) 초기 버전에서는 에이전트가 직접 모든 코드를 클론해 수정했지만, 서비스 수가 늘어나면서 속도 문제가 발생했습니다. 이를 해결하기 위해 GitHub Repository Dispatch 이벤트를 활용해 각 프로덕트가 자신의 워크플로우 안에서 파일 수정과 PR 생성을 비동기적으로 처리하도록 구조를 바꿨습니다.

# 프로덕트(Receiver) 측의 GitHub Action 예시
on:
  repository_dispatch:
    types: [seo_update_event]

jobs:
  update_meta:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Apply AI Actions
        run: python update_script.py '${{ github.event.client_payload.actions }}'

Spec 기반으로 코드를 수정하도록 하기

에이전트 개발 과정에서 또 하나 중요하게 본 점은, 코드 수정 과정이 항상 일정한 단계와 형식을 따르도록 만드는 것이었습니다. 그래야 두 프로젝트 간 코드 스타일을 유지할 수 있고, LLM도 더 안정적으로 동작한다고 판단했습니다.

spec.md → plan.mdㅁ → tasks.md 로 이어지는 문서화 과정을 통해 구현 전에 설계를 충분히 정리했습니다.

에이전트에게 내리는 각 단계의 지침(Prompt)은 다음과 같습니다.

• spec.md: "코드를 건드리지 말고, 우리가 해결하려는 도메인 문제와 비즈니스 로직의 정의(What & Why)만 서술하라."
• plan.md: "정의된 스펙을 달성하기 위해 어떤 파일을 어떻게 수정할지 기술적인 설계도(How)를 작성하라. 이때 안전장치를 반드시 포함하라."
• tasks.md: "설계도를 바탕으로 에이전트가 한 번에 하나씩 수행할 수 있는 원자 단위 작업 리스트를 체크리스트 형태로 생성하라."

이 과정을 도입하면서 얻은 효과는 명확했습니다.

• 설계 강제: 무작정 코딩에 들어가는 대신, 도메인 문제와 리스크(Risk & Mitigation)를 먼저 정의할 수 있었습니다.
• 안전장치 내재화: "어떻게 안전하게 수정할 것인가"를 설계 단계에서 LibCST 도입 등으로 미리 결정했기 때문에 실제 구현 과정의 시행착오를 크게 줄일 수 있었습니다.
• 작업의 원자성: 모든 태스크를 todos/ 아래 작은 단위로 나누어 에이전트와의 협업 정확도를 높였습니다.

코드 에이전트별 강점 살리기

이번 프로젝트에서는 Claude Code와 Antigravity 두 개의 코딩 에이전트를 함께 활용했습니다.

개인적으로는 Antigravity를 전반적인 기능 개발에, Claude Code를 세부 리팩토링과 코드 정리에 활용했습니다.

Antigravity는 기능 개발이나 디버깅 과정에서 기본적으로 plan 문서를 생성해주기 때문에 작업 흐름을 파악하기 쉬웠고, Chrome을 통해 실제 화면을 분석하면서 기능과 UI 설명을 잘 이해하는 편이었습니다.

반면 Claude Code는 기존에 활용하던 Skill을 기반으로 코드 리뷰, 컴포넌트 분리, 커밋 단위 정리에 강점이 있었고, 코드가 더 의도에 맞게 정리되는 느낌을 받았습니다.

마치며

현재 unified agent는 다음 역할을 수행할 수 있는 구조까지 구성되어 있습니다.

• 여러 프로젝트의 GSC / GA4 데이터를 통합 분석
• 서비스별 Health Score 기반 우선순위 제안
• 실행 가능한 액션 추출
• 안전 검증 후 repository dispatch 기반 PR 생성

즉 단순히 리포트를 생성하는 도구가 아니라, 어느 프로젝트에 먼저 개입해야 하는지 판단하고 실행까지 이어지는 흐름을 목표로 설계했습니다.

다만 실제 운영 단계에서는 트래픽 규모가 아직 충분하지 않아, 생성된 PR이 지속적으로 유효한 개선으로 이어지는 수준까지는 검증하지 못했습니다.

오히려 이 과정에서 데이터가 부족한 환경에서는 AI가 의미 있는 개선 방향을 제안하기 어렵고, 도메인 맥락과 우선순위를 함께 제공해야 한다는 점을 더 분명히 확인할 수 있었습니다.

특히 "기능을 수행하는 AI"와 "실제로 효과가 있는 AI Product" 사이에는 생각보다 많은 설계가 필요하다는 점을 직접 체감할 수 있었던 작업이었습니다. 🚀

바로 데이터를 언제 어떻게 불러올 것 인가에 대해서 고민을 해야한다.

인턴 기간 중 Nuxt.js 로직을 Next.js로 마이그레이션 하는 과정에서도 고민을했던 영역이다.

Next.js에서 데이터 fetching 방식을 분류해 어떤 특징들이 있는지 알아보고, 그때의 기억을 되살려서 적절하게 의사결정을 했는지 한번 돌아보고자 한다.

Next.js 데이터 Fetching 옵션

1. 서버 컴포넌트에서 fetching하기

    // app/posts/page.tsx
    export default async function PostsPage() {
      const posts = await fetch('/api/posts').then(res => res.json())
      return <PostList posts={posts} />
    }

   • 서버에서 실행, 클라이언트 번들에 포함되지 않는다.
   • 캐싱은 Next.js fetch 옵션으로 제어 (cache, revalidate) 할 수 있다.
   • 인터랙션 없는 정적 데이터에 적합하다.

2. Server Component + Tanstack Query ( Hydration 활용 )

    // lib/getQueryClient.ts
    import { QueryClient } from '@tanstack/react-query'
    import { cache } from 'react'
   
    // React의 cache()로 감싸면 같은 요청 내에서는 동일한 인스턴스 반환
    // 요청이 다르면 새로 생성 → 요청 간 오염 없음
    const getQueryClient = cache(() => new QueryClient())
    export default getQueryClient

    // app/posts/page.tsx
    export default async function PostsPage() {
      const queryClient = getQueryClient() // 같은 요청 내에선 동일 인스턴스
      await queryClient.prefetchQuery(...)
   
      return (
        <HydrationBoundary state={dehydrate(queryClient)}>
          <PostList />
        </HydrationBoundary>
      )
    }

   • 초기 로딩은 SSR, 이후 클라이언트에서 refetch/캐싱 가능하다.
   • 구성이 복잡하지만 두 가지 장점을 다 챙길 수 있다.

3. 클라이언트 컴포넌트 내부에서 Tanstack Query활용하기

    'use client'
    export default function PostList() {
      const { data, isLoading } = useQuery({
        queryKey: ['posts'],
        queryFn: fetchPosts,
      })
    }

   • 사용자 인터랙션에 반응하는 데이터에 적합하다.
   • Tanstack Query에서 제공하는 Caching, Refetching, 낙관적 업데이트 등 클라이언트 상태 관리에 용이하다.

언제 어떤 방식을 쓸까?

레퍼런스를 참고했을 때 대략 아래와 같은 케이스에서 각각의 방식이 적합하다고 볼 수 있다.

Server Component가 적합한 경우

• SEO가 중요한 페이지 (게시글 목록, 상세)
• 로그인 여부와 무관한 공개 데이터
• 실시간 업데이트 불필요
• 번들 사이즈를 줄이고 싶을 때

TanStack Query가 적합한 경우

• 사용자 액션 후 데이터 갱신 (좋아요, 댓글, 필터링)
• 낙관적 업데이트 필요
• 무한 스크롤 / 페이지네이션
• 여러 컴포넌트에서 같은 데이터 공유 (캐싱 활용)
• 폴링(주기적 refetch) 필요

Hydration이 적합한 경우

• SEO와 클라이언트 인터랙션 둘 다 필요한 경우
• 서버에서 prefetch 후 클라이언트에서 실시간 갱신이 필요한 경우

정리하면 아래와 같이 보여줄 수 있다.

Hydration은 SEO와 인터랙션의 장점을 모두 챙길 수 있지만, 구성 복잡도가 높고 번들 사이즈가 증가하는 트레이드오프가 있다. SEO와 클라이언트 인터랙션이 동시에 필요한 경우에만 선택하는 것이 좋다.

마이그레이션 당시 판단 기준

마이그레이션 과정에서 일부 API를 새로 작성해야 하는 경우가 있었고, 일부는 이미 특정 방식으로 구현된 로직을 그대로 활용할 수 있는 상황이었다. 이 두 가지 경우에 따라 데이터 페칭 위치를 어떻게 결정했는지 정리해보았다.

1. API를 새로 작성해야 하는 경우

새로 작성이 필요한 경우, 아래 세 가지 기준을 고려하여 호출 위치를 결정했다.

[ 데이터가 재사용되어야 하는가? ]

TanStack Query가 제공하는 캐싱 기능을 고려한 판단이었다. 동일한 요청이 반복될 가능성이 있는 데이터라면 TanStack Query를 활용하는 것이 더 적합하다고 생각했다.

[ 데이터가 props에 따라 달라지는가? ]

props에 의존하는 데이터는 그만큼 요청 빈도가 높고, 같은 데이터를 다시 조회할 가능성도 높다고 생각했다. 재사용성을 고려한 맥락과 동일하게 TanStack Query가 더 나은 선택이라고 판단했다.

'use client'

import { useInfiniteQuery } from '@tanstack/react-query'

type Item = {
  id: number
  title: string
}

async function fetchItems({ pageParam = 1 }: { pageParam?: number }) {
  const res = await fetch(`/api/items?page=${pageParam}`)
  if (!res.ok) {
    throw new Error('Failed to fetch items')
  }

  return res.json() as Promise<{
    items: Item[]
    nextPage?: number
  }>
}

export default function ItemList() {
  const { data, fetchNextPage, hasNextPage, isFetchingNextPage } =
    useInfiniteQuery({
      queryKey: ['items'],
      queryFn: ({ pageParam }) => fetchItems({ pageParam }),
      initialPageParam: 1,
      getNextPageParam: (lastPage) => lastPage.nextPage,
    })

  const items = data?.pages.flatMap((page) => page.items) ?? []

  return (
    <div>
      <ul>
        {items.map((item) => (
          <li key={item.id}>{item.title}</li>
        ))}
      </ul>

      {hasNextPage && (
        <button onClick={() => fetchNextPage()} disabled={isFetchingNextPage}>
          {isFetchingNextPage ? '불러오는 중...' : '더 보기'}
        </button>
      )}
    </div>
  )
}

페이지네이션이 필요한 데이터도 사용자의 액션에 따라 다음 데이터를 계속 불러와야 했기 때문에 TanStack Query를 활용했다. 특히 무한 스크롤을 적용하려면 “다음 페이지를 불러오는 상태”, “기존 목록 유지”, “추가 요청 제어”가 중요했는데, 이런 점에서 서버 컴포넌트만으로 처리하는 것보다 클라이언트에서 쿼리 상태를 관리하는 편이 더 자연스럽다고 생각했다.

[ 빠른 사용자 피드백이 중요한가? ]

화면 깜빡임 없이 데이터를 최대한 빠르게 보여줘야 하는 경우, 서버 컴포넌트에서 데이터를 페칭해 하위 컴포넌트로 내려주는 방식을 선택했다. 페이지 진입 시점에 데이터가 반드시 존재해야 하고, 이후 클라이언트에서 상태로 관리할 필요가 없는 데이터라면 서버 컴포넌트를 선택했다.

2. 기존 API 로직을 재사용하는 경우

[ 기존 로직이 TanStack Query 훅으로 구현된 경우 ]

훅으로 만들어진 이유가 재사용성을 고려한 것이라고 판단했다. 따라서 해당 훅이 호출되는 시점을 먼저 확인했다. 마이그레이션 대상 페이지 진입 전에 이미 훅이 호출된 적 있다면, 이후에는 캐싱된 데이터를 활용할 가능성이 높기 때문에 훅을 그대로 사용했다. 그렇지 않은 경우에는 처음부터 다시 판단해 적절한 방식을 결정했다.

export default function UserProfile() {
  // 기존 구현된 유저 정보 조회 커스텀 훅을 그대로 활용
  const { data: user, isLoading } = useUserInfo()

  if (isLoading) return <div>로딩 중...</div>

  return (
    <div>
      <p>{user.name}</p>
      <p>{user.email}</p>
    </div>
  )
}

[ 기존 로직이 서버 컴포넌트에서 구현된 경우 ]

데이터의 재사용 가능성이 이미 고려된 시점이라고 봤다. 기존에 서버 컴포넌트로 구현된 이유를 먼저 파악하고, 마이그레이션 이후에도 동일한 방식이 적합한지, 혹은 로직 수정이 필요한지를 함께 검토했다.

마치며

마이그레이션 당시에도 헷갈리기도 했고, 이렇게 기준을 잡아도 되나 싶었던 부분이었는데 이번에 확실히 정리를 하게 되어 다행이라 생각한다.

당시에 하이드레이션할 생각까지는 못했던 것 같아 조금 더 알아보고 작업을 했다면 조금 더 확장된 사고로 의사결정을 할 수 있지 않았을까하는 아쉬움도 남았다.

그리고 각 방식에서 디테일하게 놓치고 있던 부분들도 이번에 확실히 알아가는 것 같아서 정리하길 잘한 것 같다.

Reference

https://nextjs.org/docs/app/getting-started/fetching-data

https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr

https://ko.react.dev/reference/rsc/server-components

그 발표를 계기로 리스트 가상화에 대해서 궁금해졌고, 이게 실제로 어떤 원리로 최적화가 이루어질 수 있는지 알아보자.

리스트 가상화 (List Virtualization)?

리스트 가상화는 동적 리스트를 랜더링할 때 전체 리스트를 랜더링하지 않고 화면에 보이는 콘텐츠만 랜더링하는 방식을 말한다.

리스트 가상화는 어떻게 동작할까?

1. 어떤 아이템을 렌더링할지 계산

1. 각 아이템의 높이를 캐싱 (측정값 또는 예상값)
2. 현재 스크롤 위치(scrollOffset)를 기준으로 이진 탐색
3. 화면에 보이는 범위의 startIndex, endIndex 계산
   • 이진 탐색으로 시작 인덱스를 빠르게 찾음 (O(log n))
4. overscan으로 위아래 버퍼 추가 (깜빡임 방지)

TanStack Virtual 구현:

// packages/virtual-core/src/index.ts
private calculateRange() {
  // 이진 탐색으로 startIndex 찾기
  const startIndex = this.findStartIndex(scrollOffset);

  // 뷰포트 끝까지 endIndex 확장
  const endIndex = this.findEndIndex(startIndex, scrollOffset + outerSize);

  // overscan 적용 (스크롤 시 깜빡임 방지)
  return {
    startIndex: Math.max(0, startIndex - overscan),
    endIndex: Math.min(count - 1, endIndex + overscan)
  };
}

2. 스크롤바 높이 유지

• 실제로는 10개만 렌더링하지만
• 스크롤바는 10,000개처럼 보이게 하는 트릭

TanStack Virtual 구현:

// 전체 리스트의 가상 높이 계산
getTotalSize() {
  const measurements = this.getMeasurements();
  return measurements[measurements.length - 1]?.end ?? 0;
}

3. 동적 높이 처리

• ResizeObserver로 실제 렌더링된 요소 크기 측정
• 측정값을 캐싱해서 다음 계산에 활용

TanStack Virtual 구현:

// 각 아이템의 크기 측정 및 캐싱
measureElement(element: HTMLElement, index: number) {
  const size = element.getBoundingClientRect().height;

  // 캐시에 저장
  this.itemSizeCache.set(index, size);

  // 예상 크기와 다르면 재계산 트리거
  if (this.measurementsCache[index]?.size !== size) {
    this.notify(false); // 3번부터 다시 계산
  }
}

// 측정값 활용
getMeasurements() {
  return this.options.count.map((_, index) => {
    // 캐시에 있으면 사용, 없으면 추정값 사용
    const size = this.itemSizeCache.get(index)
      ?? this.options.estimateSize(index);

    return { start, size, end: start + size };
  });
}

전체 흐름

직접 측정해보기

실제로 리스트 가상화가 어떻게 향상된 사용자 경험을 제공하는지 직접 프로젝트를 통해서 알아봤다.

리스트 가상화 체험해보기 : list-virtualization Repo 주소 : https://github.com/SangWoo9734/list-virtualization.git

성능 측정 로직 설명

1. FPS (Frames Per Second) 측정

let frameCount = 0;
let lastTime = performance.now();

const measureFPS = () => {
  frameCount++;
  const currentTime = performance.now();
  const elapsed = currentTime - lastTime;

  if (elapsed >= 1000) {  // 1초마다
    const fps = Math.round((frameCount * 1000) / elapsed);
    // fps 업데이트
  }
  requestAnimationFrame(measureFPS);
};

• requestAnimationFrame이 호출될 때마다 프레임 카운트 증가
• 1초(1000ms)가 지나면 "1초 동안 몇 프레임이 그려졌는지" 계산

2. DOM 노드 개수 측정

const domNodes = document.getElementsByTagName('*').length;

• 페이지의 모든 HTML 요소 개수를 센다
• Virtualized: 보이는 부분만 렌더링 → 적은 노드 수 (~100-200개)
• Regular List: 전체 아이템 렌더링 → 많은 노드 수 (10,000개 = 수만 개)

3. 메모리 사용량 측정

if ('memory' in performance) {
  const memory = performance.memory;
  const usedMB = memory.usedJSHeapSize / 1048576;
}

• Chrome에서만 지원되는 기능
• JavaScript 힙 메모리 사용량을 MB 단위로 표시
• 많은 DOM 노드 = 더 많은 메모리 사용

결과

리스트 요소 100개

리스트 요소 1000개

리스트 요소 10000개

• 가상화를 적용하지 않은 리스트의 경우 리스트 요소에 비례하게 DOM 노드의 개수가 증가하는 것을 볼 수 있다.
• 가상화가 적용된 리스트의 경우 리스트의 개수가 늘어나더라도 동일한 노드의 개수를 갖는 것을 알 수 있다.
• 그 외 다른 지표들의 경우 리스트 요소 개수에 의해서 크게 영향을 받는 느낌은 아니었다.

이제 여기서 리플로우 / 리페인트를 발생시켜보면 조금 더 체감이 될 것 같다.

10000개를 기준으로 2초마다 반복적으로 스타일을 변경하도록 해서 부하를 추가해서 확인해보았다.

• 가상화 적용(전)

• 가상화 적용(후)

가상화 전에는 스타일 변경이 시작되자마자 스크롤이 되지 않을 정도로 부하가 많이 걸리는 느낌이 확실히 들었다.

반면에 가상화를 적용했을 때는 부하를 주기 전과 거의 동일한 느낌으로 자연스러웠다.

이런 경험 뿐만 아니라 메모리 사용량도 차이가 많이 나는 것을 확인할 수 있었다.

다만 가상화를 적용한 리스트에서 약간 어색했던 부분은 리스트 전체 요소에 스타일이 적용되도록 해 두었는데 가상화 리스트의 경우 리스트 밖의 요소가 리스트에 보일때 랜더링을 하기 때문에 기존에 리스트에 있던 요소와 스타일이 변하는 타이밍이 달라지는 부분이 있었다.

왜 이렇게 성능 차이가 날까?

DOM 노드가 많을수록:

• 브라우저가 관리해야 할 요소 증가 → 메모리 사용량 증가
• 스타일 변경 시 리플로우/리페인트 계산 범위 증가 → FPS 저하
• 이벤트 리스너, 레이아웃 계산 등 모든 작업이 느려짐

가상화는 "DOM 노드 개수를 일정하게 유지"하여 이 문제를 해결

Reference

https://patterns-dev-kr.github.io/performance-patterns/list-virtualization/

https://tanstack.com/virtual/latest

연령, 장애 여부에 관계없이 웹 사이트에서 제공하는 정보에 동등하게 접근하고, 이용할 수 있도록 보장하는 것

웹 접근성 고려사항

• 시각 - 저시력, 실명, 색각 이상 같은 시각 장애를 고려
• 이동성 - 근육 속도 저하, 근육 제어 손실로 인해 손을 쓰기 어렵거나 쓸 수 없는 상태를 고려
• 청각 - 영상, 음성 콘텐츠에 자막, 원고, 수화등의 대체 수단을 고려
• 인지 - 정신 지체 장애, 학습 장애를 고려

웹 접근성에 도움을 주는 브라우저 보조 기술

• 스크린 리더
• 화면 확대 도구
• 음성 인식
• 키보드 오버레이
  

WAI-ARIA?

동적 컨텐츠와 인터페이스 컨트롤을 위한 웹 접근성 표준으로, 보조 기술를 사용해 웹 애플리케이션을 효과적으로 탐색하는데 설계되 있다.

HTML Tag들에 추가적으로 시멘틱을 부여해서 브라우저 보조 기술들이 각 요소의 역할, 상태, 설명 등을 참고 할 수 있도록 한다.

✏️ 간단 적용해보기

1. 시맨틱 HTML과 ARIA 속성 적용

1-1. 모달 다이얼로그 접근성

적용 전:

<div v-if="isOpen" class="form-modal-background" @click.self="handleClose">
  <div class="form-modal">
    <h3>{{ modalTitle }}</h3>
    <!-- 폼 내용 -->
  </div>
</div>

적용 후:

<div
  v-if="isOpen"
  class="form-modal-background"
  @click.self="handleClose"
  role="dialog"
  :aria-modal="isOpen"
  aria-labelledby="modal-title"
>
  <div class="form-modal">
    <h3 id="modal-title">{{ modalTitle }}</h3>
    <!-- 폼 내용 -->
  </div>
</div>

개선 사항:

• role="dialog": 스크린 리더에게 이것이 대화상자임을 알림
• aria-modal="true": 모달이 열려있을 때 배경 컨텐츠를 무시하도록 지시
• aria-labelledby: 모달의 제목을 명시적으로 연결

추가한 접근성 속성은 개발자 도구 Elements → Accessibility 에서 접근성 트리와 각 요소에 적용된 접근성 속성을 확인할 수 있다.

1-2. 폼 입력 필드 접근성

적용 전:

<input
  :value="modelValue"
  :placeholder="placeholder"
  :required="required"
  @input="handleInput"
/>

적용 후:

<input
  :id="props.id"
  :name="props.name"
  :value="modelValue"
  :placeholder="placeholder"
  :required="required"
  @input="handleInput"
  :aria-invalid="props.invalid"
  :aria-describedby="props.invalid ? `${props.id}-error` : undefined"
/>
<p
  v-if="props.invalid && props.message"
  :id="`${props.id}-error`"
  class="error-message"
>
  {{ props.message }}
</p>

개선 사항:

• id와 name: 폼 요소 식별 및 label 연결
• aria-invalid: 입력값이 유효하지 않음을 스크린 리더에게 알림
• aria-describedby: 에러 메시지를 입력 필드와 연결
• 에러 메시지에 고유 id 부여

1-3. Label과 Input 연결

적용 전:

<label class="form-label">
  {{ field.label }}
  <span v-if="field.required">*</span>
</label>
<FormInput :model-value="getFieldValue(field.name)" />

적용 후:

<label class="form-label" :for="field.name">
  {{ field.label }}
  <span v-if="field.required" class="required-mark">*</span>
</label>
<FormInput
  :id="field.name"
  :name="field.name"
  :model-value="getFieldValue(field.name)"
/>

개선 사항:

• <label for="field-name">: label과 input을 명시적으로 연결
• 스크린 리더가 입력 필드에 포커스할 때 레이블을 읽어줌
• 레이블을 클릭하면 해당 입력 필드에 포커스 이동

2. 키보드 접근성

2-1. 버튼 접근성

<button
  :type="type"
  :disabled="disabled"
  :aria-label="ariaLabel"
  class="icon-button"
>
  <slot />
</button>

개선 사항:

• 아이콘만 있는 버튼에 aria-label 추가
• disabled 상태를 명시적으로 관리
• 키보드로 포커스 및 Enter/Space로 실행 가능

탭(Tab) 키 입력시 Todo 버튼에 먼저 포커스가 가는 것을 확인할 수 있다.

2-2. 포커스 스타일 명시

.form-input:focus,
.form-textarea:focus {
  border-color: #3b82f6;
  box-shadow: 0 0 0 3px rgba(59, 130, 246, 0.1);
}

.form-input.form-error:focus {
  border-color: #ef4444;
  box-shadow: 0 0 0 3px rgba(239, 68, 68, 0.1);
}

개선 사항:

• :focus 상태에서 명확한 시각적 피드백 제공
• outline을 제거하는 대신 box-shadow로 포커스 표시
• 에러 상태에서도 구분되는 포커스 스타일

폼 내에서도 동일하게 설정한 속성에 따라 포커스가 이동한다.

3. 반응형 디자인과 접근성

// 모바일에서도 충분한 터치 영역 확보
.icon-button {
  padding: 0.5rem;  // 최소 44x44px 터치 영역
  cursor: pointer;
}

// 가독성을 위한 반응형 폰트 크기
h1 {
  font-size: 1.5rem;

  @media (min-width: 768px) {
    font-size: 2rem;
  }
}

개선 사항:

• WCAG 권장 최소 터치 영역(44x44px) 준수
• 작은 화면에서도 가독성 있는 폰트 크기
• 충분한 색상 대비 (텍스트와 배경)

4. 의미 있는 에러 메시지

적용 전:

if (!value) {
  showToast({ message: '입력해주세요.', variant: 'error' });
}

적용 후:

if (!value || String(value).trim() === '') {
  field.invalid = true;
  field.message = `${field.label}을(를) 입력해주세요.`;
  showToast({ message: '필수 항목을 입력해주세요.', variant: 'error' });
}

개선 사항:

• 어떤 필드에 문제가 있는지 명확히 표시
• Toast와 인라인 에러 메시지를 함께 제공
• 스크린 리더가 aria-describedby를 통해 에러 메시지 읽기

5. 스크린 리더 테스트

실제로 스크린 리더(macOS VoiceOver, Windows Narrator)로 테스트한 결과:

개선 전:

• "버튼" (아이콘 버튼의 역할을 알 수 없음)
• "입력 필드" (어떤 정보를 입력해야 하는지 모름)
• 모달이 열려도 배경 컨텐츠를 계속 읽음

개선 후:

• "Todo 추가 버튼"
• "제목, 필수 항목, 입력 필드"
• "모달 대화상자 - Todo 추가"
• 유효하지 않은 입력: "제목을 입력해주세요"

정리

웹 접근성을 적용한 결과:

• ✅ 키보드만으로 모든 기능 사용 가능
• ✅ 스크린 리더로 의미 있는 정보 전달
• ✅ 시각적 피드백이 명확함 (포커스, 에러 상태)
• ✅ 모바일에서도 충분한 터치 영역
• ✅ WCAG 2.1 Level A 기준 충족

그럼 앱에서 접근성을 고려하려면?

모바일 서비스를 이용하는 누구나 불편한 없이 기기를 이용할 수 있게 하는 개념

• 다크모드
• 큰 글씨 모드
• UX 동작 수정 ( 길게 터치 후 끌어다 놓기 → 손이 불편하신 분들은 활용이 어려움)

⇒ 웹 접근성은 특별한 기능이나, 정해진 규칙에 맞추는 것이 아닌 다양한 어려움을 예방하는 UX/UI를 제공하는 것이 핵심

🤨 오? 이거 뭔가 만들 수 있을 것 같은데

🎯 문제 정의

개발자들이 ARIA 속성을 사용할 때 겪는 어려움:

1. ARIA 속성과 값에 대한 이해 부족
   • 어떤 속성에 어떤 값을 넣어야 하는지 헷갈림
   • 예: aria-expanded에 true를 넣어야 할까, "true"를 넣어야 할까?
2. 프로젝트별 맥락 차이
   • 다른 리소스를 참고해도 내 프로젝트에는 다르게 적용해야 하는 경우
   • 예: 같은 토글 버튼이라도 디자인 시스템에 따라 구현이 다름
3. 동적 상태 관리의 어려움 ⭐ (핵심)
   • 상태에 따라 동적으로 변경되어야 하는 ARIA 속성
   • 예: 토글 버튼의 aria-expanded가 항상 "false"로 고정됨

🔧 기존 해결 방식의 한계

기존 도구: eslint-plugin-jsx-a11y

✅ 해결 가능

• ARIA 속성과 값에 대한 이해 부족 → 문법 검증으로 해결
• 프로젝트별 맥락 차이 → 설정 커스터마이징으로 해결

❌ 해결 불가능

• 동적 상태 관리 → 정적 분석의 한계

    // ❌ 이런 오류를 기존 도구는 찾지 못함
    <button onClick={toggle} aria-expanded="false">
      {/* 클릭해도 aria-expanded가 항상 false! */}
    </button>
  

왜 불가능한가?

• 동적 값은 런타임에 결정됨
• 기존 ESLint 플러그인은 빌드 타임 정적 분석만 수행
• 상태(State)와 ARIA 속성의 연결 관계를 추론하지 못함

💡 해결 방식: eslint-plugin-aria-state-validator

핵심 아이디어: AST 분석으로 상태와 ARIA 속성의 연결 관계를 추론

작동 원리

// 1. JSXElement 순회: role 및 aria-* 속성 식별
<button onClick={() => setOpen(!isOpen)} aria-expanded="false">

// 2. 스코프 추적: context.getScope()로 변수 추적
//    → onClick 핸들러에서 'isOpen' 변수 발견

// 3. 상태 추론: useState 훅에서 파생된 상태인지 판단
//    → const [isOpen, setOpen] = useState(false)

// 4. 패턴 검증 & 자동 수정
//    ❌ aria-expanded="false" (정적)
//    ✅ aria-expanded={isOpen ? 'true' : 'false'} (동적)

두 가지 검증 규칙

1. state-dependent-aria-validator (동적 상태 검증)
   • 상태와 ARIA 속성의 바인딩 검증
   • 80% 자동 수정 가능
2. static-aria-validator (정적 ARIA 검증)
   • 기존 도구 보완 (오타, 잘못된 값, 충돌 감지)

⚖️ 트레이드오프

React 생태계로 범위 한정

• useState 훅 또는 Props 통한 상태 전달 추론
• React 외 프레임워크(Vue, Svelte 등)는 미지원

이유:

• 프레임워크마다 상태 관리 패턴이 다름

  • Vue: ref, reactive

  • Svelte: $: reactive statements

  • Solid: createSignal

    // React
    const [isOpen, setOpen] = useState(false)
    
    // Vue (향후 지원 가능)
    const isOpen = ref(false)
    
    // Svelte (향후 지원 가능)
    let isOpen = $state(false)

• React의 useState 패턴이 가장 명확하고 일관적

Reference

한국 접근성 인증 평가원 / 웹 접근성이란? - https://www.wa.or.kr/m1/sub1.asp

토스의 모바일 접근성 - https://toss.im/tossfeed/article/tinyquestions-disability-5

useDeferredValue

useDeferredValue는 UI 업데이트를 지연시키는 역할을 하는 React Hook이고, 용법은 아래와 같다.

const deferedValue = useDeferredValue(value, initialValue);

• value는 지연시키려는 값, 상태를 의미한다.
• initialValue는 옵셔널 값이며, 초기 렌더링에 사용할 값을 의미한다. → initialValue를 설정하지 않은 경우 초기 렌더링 동안에는 값을 지연시키지 않는다.

지연?

계속 '지연'시킨다는 표현을 사용하고 있는데, 정확히 무엇을 지연시키는 걸까?

useDeferredValue는 값의 업데이트를 지연시킨다. 상태가 변경되어도 무거운 컴포넌트에 전달되는 값을 즉시 업데이트하지 않고, React의 우선순위 스케줄링을 통해 나중에 업데이트한다. 이를 통해 사용자 입력과 같은 긴급한 UI 업데이트가 무거운 렌더링에 의해 블로킹되지 않도록 한다.

예시

공식문서의 예시를 가져오면 아래와 같다.

// App.js
import SearchResults from './SearchResults.js';

export default function App() {
  const [query, setQuery] = useState('');
  const deferredQuery = useDeferredValue(query);
  return (
    <>
      <label>
        Search albums:
        <input value={query} onChange={e => setQuery(e.target.value)} />
      </label>
      <Suspense fallback={<h2>Loading...</h2>}>
        <SearchResults query={deferredQuery} />
      </Suspense>
    </>
  );
}

// SearchResult
import {use} from 'react';
import { fetchData } from './data.js';

export default function SearchResults({ query }) {
  if (query === '') {
    return null;
  }
  const albums = use(fetchData(`/search?q=${query}`));
  if (albums.length === 0) {
    return <p>No matches for <i>"{query}"</i></p>;
  }
  return (
    <ul>
      {albums.map(album => (
        <li key={album.id}>
          {album.title} ({album.year})
        </li>
      ))}
    </ul>
  );
}

여기서 쿼리가 변함에 따라 검색 결과가 바뀌게 된다. useDeferredValue를 쓰지 않는다면 유저가 타이핑을 치는 모든 순간에 SearchResult가 리렌더링된다.

useDeferredValue로 인해서 query로 인한 SearchResult의 리렌더링을 상태 업데이트 전에 UI를 임시로 보여줌으로서 매번 리렌더링 되는 것을 막는다.

헷갈리는데…

useDeferredValue를 보면서 헷갈리는 지점이 꽤 있었다.

1. Suspense와 함께 사용하기

Suspense와 useDeferredValue를 함께 사용할 때 어떤 UI가 표시되는지가 가장 헷갈렸다.

처음에는 검색어를 타이핑한 후 Loading 컴포넌트 없이 바로 UI가 리렌더링되는 것을 보고, useDeferredValue로 인해 보이는 이전 UI가 Fallback UI 역할을 하는 것처럼 느껴졌다.

하지만 이는 잘못된 이해였다. Suspense는 하위 컴포넌트에서 Promise를 감지했을 때, 해당 범위 내에 이전에 commit된 컴포넌트가 없으면 Fallback UI를 표시한다.

useDeferredValue와 함께 사용하면, Suspense가 새로운 Promise를 감지하더라도 이미 이전에 commit된 UI(null 포함)가 존재하기 때문에 Fallback UI를 표시하지 않고 기존 UI를 유지한다. 이것이 useDeferredValue와 Suspense를 조합했을 때의 핵심 동작 방식이다.

2. 디바운스? 쓰로틀?

공식 문서 마지막에서 다루는 내용이 바로 이 부분이었다.

평소 스크롤이나 키보드 입력에 debounce를 주로 사용해왔기 때문에, 비슷해 보이는 useDeferredValue라는 Hook이 왜 등장했는지, 어떤 차이가 있는지 궁금했다.

결론적으로 두 방식 모두 최적화를 목적으로 하지만, 최적화 대상이 다르다. Debounce와 throttle은 함수 호출 횟수를 제어한다. Debounce는 일정 시간 내 마지막 함수 호출만 처리하고, throttle은 일정 시간 내 중복 호출을 무시하는 방식으로 최적화한다.

반면 useDeferredValue는 렌더링 최적화에 특화되어 있다. 상태 변경으로 인한 렌더링을 지연시키되, 이전에 commit된 UI를 유지함으로써 무거운 렌더링이 다른 UI 업데이트를 블로킹하지 않도록 한다. 따라서 백그라운드에서 useDeferredValue는 함수 호출 자체를 최적화하지는 않는다.

처음에는 "어느 것이 더 좋은가"의 관점으로 접근했지만, 둘의 목적이 다르다는 것을 이해하고 나니 각각의 사용 시점이 명확해졌다.

마치며

이번 훅을 이해해보면서, 기존에 debouce와 throttle로 해결하던 문제를 React의 렌더링 시스템과 통합하여 효과적으로 해결하려는 의도가 있지 않았나 생각해보았다.

새로운 훅을 보면서 어떤 부분들을 지속적으로 개선하려고하는지 상상해보는 점은 늘 흥미로운 것 같다.

이번 글에서는 필터 컴포넌트 설계하면서 고민했던 과정을 공유하려고 합니다. 단순히 컴포넌트를 나누는 것을 넘어, 어떻게 하면 재사용 가능하면서도 유연한 구조를 만들 수 있을까에 초점을 맞췄습니다.

문제 정의

( *****예시는 실제 프로젝트와 다소 차이가 있습니다. )

프로젝트에는 여러 개의 리스트 페이지가 있었습니다:

• 영화 검색 페이지: 장르, 연도, 평점 필터 + 정렬
• 감독별 영화 페이지: 연도, 평점 필터 + 정렬 (장르 필터 제외)
• 배우별 영화 페이지: 역할, 연도 필터 + 정렬

각 페이지마다 필터 조합이 다르지만, UI 패턴은 유사했습니다:

• 드롭다운 선택 (정렬, 연도)
• 체크박스 다중 선택 (장르, 역할)
• 칩 선택 (평점)
• 필터 초기화 버튼

처음에는 각 페이지마다 필터를 구현했지만, 코드 중복이 심각했고 수정 시 여러 곳을 동시에 고쳐야 하는 문제가 있었습니다.

요구사항 정리

리팩토링을 시작하기 전에 요구사항을 정리했습니다:

1. 재사용성: 같은 UI 패턴(드롭다운, 체크박스)을 여러 곳에서 사용
2. 유연성: 페이지마다 다른 필터 조합을 쉽게 구성
3. 일관성: 모든 필터가 동일한 방식으로 상태를 관리
4. 조건부 표시: 필터가 활성화되었을 때만 초기화 버튼 표시
5. 확장성: 새로운 필터 타입을 쉽게 추가 가능

3단계의 계층 구조

고민 끝에 선택한 구조는 3단계 계층 구조였습니다:

ListOptions/
├── core/           # 재사용 가능한 기본 UI 컴포넌트
│   ├── RadioSelector.tsx
│   ├── CheckboxSelector.tsx
│   └── ChipSelector.tsx
├── tools/          # 비즈니스 로직이 포함된 도구 컴포넌트
│   ├── SortDropdown.tsx
│   ├── GenreCheckbox.tsx
│   └── RatingChip.tsx
└── groups/         # 페이지별 필터 조합
    ├── SearchPageTools.tsx
    └── DirectorPageTools.tsx

Core Layer: 순수 UI 컴포넌트

가장 하위 계층은 비즈니스 로직이 전혀 없는 순수 UI 컴포넌트입니다.

// core/RadioSelector.tsx
export default function RadioSelector({
  options,
  selected,
  paramKey,
  valueMap,
}: {
  options: string[];
  selected?: string;
  paramKey: string;
  valueMap?: Record<string, string>;
}) {
  const { updateSearchParams } = useRouterWithParams();

  const handleSelect = (option: string) => {
    const value = valueMap ? valueMap[option] : option;
    updateSearchParams({ [paramKey]: value });
  };

  return (
    <Modal>
      {options.map((option) => (
        <button onClick={() => handleSelect(option)}>
          {option}
        </button>
      ))}
    </Modal>
  );
}

핵심은 paramKey와 valueMap을 외부에서 주입받는다는 점입니다. 이렇게 하면:

• "추천순" → "recommended" 같은 변환 로직을 외부에서 제어
• 같은 UI를 다른 URL 파라미터에 재사용 가능

Tools Layer: 도메인 로직을 가진 컴포넌트

중간 계층은 특정 필터의 데이터와 로직을 담당합니다.

// tools/SortDropdown.tsx
const SORT_OPTIONS = ["추천순", "최신순", "평점순"];

const SORT_MAP = {
  추천순: "recommended",
  최신순: "latest",
  평점순: "rating",
};

const REVERSE_SORT_MAP = {
  recommended: "추천순",
  latest: "최신순",
  rating: "평점순",
};

export default function SortDropdown() {
  const router = useRouter();
  const currentSort = (router.query.sort as string) || "recommended";

  return (
    <RadioSelector
      options={SORT_OPTIONS}
      selected={REVERSE_SORT_MAP[currentSort]}
      paramKey="sort"
      valueMap={SORT_MAP}
    />
  );
}

여기서 중요한 점:

• 데이터 변환 로직: URL의 "recommended"를 화면의 "추천순"으로 변환
• 기본값 처리: sort가 없을 때 "recommended"를 기본값으로
• Core 컴포넌트 활용: RadioSelector를 재사용

Groups Layer: 페이지별 조합

최상위 계층은 페이지에 필요한 필터를 조합합니다.

// groups/SearchPageTools.tsx
export default function SearchPageTools() {
  const { hasActiveFilters, resetFilterQuery } = useRouterWithParams();
  const excludeKeys = ["query"]; // 검색어는 초기화 대상에서 제외
  const showReset = hasActiveFilters(excludeKeys);

  return (
    <div className="flex gap-4">
      <SortDropdown />
      {showReset && <FilterResetButton onClick={() => resetFilterQuery(excludeKeys)} />}
      <GenreCheckbox />
      <RatingChip />
    </div>
  );
}`

`// groups/DirectorPageTools.tsx
export default function DirectorPageTools() {
  const { hasActiveFilters, resetFilterQuery } = useRouterWithParams();
  const excludeKeys = ["directorId"]; // 감독 ID는 초기화 대상에서 제외
  const showReset = hasActiveFilters(excludeKeys);

  return (
    <div className="flex gap-4">
      <SortDropdown />
      {showReset && <FilterResetButton onClick={() => resetFilterQuery(excludeKeys)} />}
      <RatingChip />
      {/* GenreCheckbox는 제외 */}
    </div>
  );
}

이렇게 하면:

• 검색 페이지는 모든 필터를 표시
• 감독 페이지는 장르 필터를 제외
• 각 페이지의 초기화 로직도 독립적으로 관리

가 가능해집니다.

의사결정: 유연함과 재사용성

유연함과 재사용성을 모두 만족하는 컴포넌트를 만들기 위해, 먼저 각 UI가 어떤 성격을 가지고 있는지를 이해하는 것부터 시작했습니다. 그리고 그 성격 안에서 무엇이 변할 수 있는 지점인지, 또 그 변화를 구현부에서 얼마나 편리하게 다룰 수 있도록 만들 수 있을지라는 흐름으로 고민을 이어갔습니다.

정렬 기능을 예로 들어보면, 정렬은 그 자체로 하나의 비즈니스 요구사항입니다. 동시에 이 요구사항을 해결하는 UI는 드롭다운, 버튼 그룹 등 다양한 형태로 확장될 수 있다고 판단했습니다. 이 시점에서 이미 두 가지 관심사가 분리됩니다.

• 정렬이라는 도메인 로직
• 이를 표현하는 UI

여기에 더해, 정렬 기능을 사용하는 각 페이지마다 어떤 정렬 옵션을 제공할지, 혹은 다른 필터들과 어떻게 함께 사용될지가 모두 달랐습니다. 이 요구사항을 하나의 컴포넌트에서 props나 조건문으로 처리하기보다는, 구현하는 쪽에서 선택적으로 조합할 수 있는 구조가 더 적합하다고 판단했습니다.

그래서 단일 컴포넌트에 모든 책임을 몰아넣는 대신, 조합(Composition) 패턴을 활용해 역할을 분리했습니다. 그 결과, UI만 책임지는 컴포넌트, 도메인 로직을 담은 컴포넌트, 그리고 이를 페이지 단위로 조합하는 컴포넌트까지 총 3단계의 컴포넌트 구조로 정렬 기능을 구현할 수 있었습니다.

이러한 의사결정을 통해, 각 컴포넌트는 더 단순해졌고, 새로운 페이지나 요구사항이 추가되더라도 기존 코드를 크게 수정하지 않고 유연하게 대응할 수 있는 구조를 만들 수 있었습니다

의사결정 : 조건부 필터 초기화

"초기화 버튼을 언제 보여줄까?"가 의외로 복잡한 문제였습니다.

문제점:

• 검색 페이지: 검색어(query)는 유지하고 필터만 초기화
• 감독 페이지: 감독 ID(directorId)는 라우트 파라미터이므로 필터가 아님

처음에는 초기화 버튼이 필터 종류를 직접 알고 있었지만, 이는 페이지마다 필터 구성이 바뀔 때마다 수정이 필요했습니다.

해결책: excludeKeys 패턴

const FILTER_KEYS = ["sort", "genre", "rating"] as const;

function hasActiveFilters(excludeKeys: string[] = []) {
return Object.keys(router.query).some(
(key) =>
FILTER_KEYS.includes(key as typeof FILTER_KEYS[number]) &&
!excludeKeys.includes(key)
);
}

function resetFilterQuery(excludeKeys: string[] = []) {
const query = { ...router.query };

Object.keys(query).forEach((key) => {
if (!excludeKeys.includes(key)) {
delete query[key];
}
});

router.push({ pathname: router.pathname, query }, undefined, {
shallow: true,
});
}`

사용 예시:

`// 검색 페이지: query는 제외
const excludeKeys = ["query"];
const showReset = hasActiveFilters(excludeKeys);

// 감독 페이지: directorId는 제외
const excludeKeys = ["directorId"];
const showReset = hasActiveFilters(excludeKeys);

이 패턴의 장점:

• 유연성: 각 페이지가 제외할 키를 자유롭게 지정
• 명확성: 무엇을 제외하는지 코드에 명시적으로 표현
• 확장성: 새로운 페이지를 추가해도 로직 수정 불필요

컴포넌트 합성의 힘

이 아키텍처의 가장 큰 장점은 레고 블록처럼 조립할 수 있다는 점입니다.

새로운 페이지를 추가한다면?

// groups/ActorPageTools.tsx
export default function ActorPageTools() {
    const { hasActiveFilters, resetFilterQuery } = useRouterWithParams();
    const excludeKeys = ["actorId"];
    const showReset = hasActiveFilters(excludeKeys);

    return (
        <div className="flex gap-4">
            <SortDropdown />
            {showReset && <FilterResetButton onClick={() => resetFilterQuery(excludeKeys)} />}
            <RoleCheckbox />  {/* 새로운 필터 */}
        </div>
    );
}

새로운 필터 타입을 추가한다면?

// tools/RoleCheckbox.tsx
const ROLE_OPTIONS = [
    { value: "lead", label: "주연" },
    { value: "supporting", label: "조연" },
];

export default function RoleCheckbox() {
    const router = useRouter();
    const selected = (router.query.role as string)?.split(",") || [];

    return (
        <CheckboxSelector
            options={ROLE_OPTIONS}
            selected={selected}
            paramKey="role"
            label="역할"
        />
                );
}

Core 컴포넌트(CheckboxSelector)는 전혀 수정할 필요가 없습니다.

배운 점과 트레이드오프

잘된 점

1. 명확한 책임 분리
   • Core: UI 렌더링만
   • Tools: 데이터 변환과 기본값
   • Groups: 조합과 페이지별 로직
2. URL 기반 상태 관리
   • 공유, 새로고침, 히스토리 모두 자연스럽게 해결
   • 디버깅이 쉬움 (URL만 보면 현재 상태 파악)
3. 높은 재사용성
   • RadioSelector는 정렬, 연도, 언어 필터 등에 재사용
   • CheckboxSelector는 장르, 역할, 태그 등에 재사용

아쉬운점

1. 관리 파일의 개수 증가 재사용성과 유연성을 제공하려고 하다보니 자연스럽게 파일의 개수가 늘어났다. 파일의 개수에 따라서 다른 개발자가 이 컴포넌트를 사용했을 때 각 컴포넌트들이 어떤 역할을 하고, 어떤 식으로 사용해야하는지에 대한 가이드를 곧바로 파악하기에는 어려움이 있을 것 같다고 느껴졌다.
2. 상태 관리 방식에 따른 대응 불가 현재 컴포넌트는 URL의 query 기반으로 상태를 관리하고 있다. 하지만 params를 사용하지 않는 경우에 대해서는 유연하게 대처하기가 어렵다.

마치며

AI로 빠른 개발이 가능해지면서 설계에 대한 역량이 더 필요해지는 것 같다. 이번에 설계를 해보면서 단번에 최적의 설계를 찾기에는 어려움이 있는 것 같아서 앞으로 블로그 글을 통해서 정리하는 방식을 주로 활용해려고 한다

1. update 방식을 제한할 수 있다.

// ❌ useState: 어떤 방식으로든 수정 가능
const [state, setState] = useState({ count: 0, user: {} });
setState({ count: 999 });  // 가능
setState({});  // 이것도 가능... 😱

// ✅ useReducer: 정의된 action으로만 수정 가능
const [state, dispatch] = useReducer(reducer, initialState);

dispatch({ type: 'INCREMENT' });  // ✅ 허용된 action
dispatch({ type: 'UPDATE_USER', payload: user });  // ✅ 허용된 action
dispatch({ type: 'RANDOM_ACTION' });  // ❌ reducer에서 처리 안 됨

1. 비슷한 성격의 state를 묶어서 관리할 수 있다.

+) state를 조작하는 Action도 묶어서 관리할 수 있다. reducer 내부에서 관리되기 때문에 응집도가 높다.

// ❌ useState: state가 분산됨
function Form() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  const [age, setAge] = useState(0);
  const [address, setAddress] = useState('');
  const [phoneNumber, setPhoneNumber] = useState('');
  // state가 5개로 분산되어 관리가 어려움
}

// ✅ useReducer: 관련된 state를 하나로 묶음
function formReducer(state, action) {
  switch (action.type) {
    case 'UPDATE_FIELD':
      return { ...state, [action.field]: action.value };
    case 'RESET_FORM':
      return initialFormState;
    default:
      return state;
  }
}

const initialFormState = {
  name: '',
  email: '',
  age: 0,
  address: '',
  phoneNumber: ''
};

function Form() {
  const [formData, dispatch] = useReducer(formReducer, initialFormState);

  // 하나의 state로 관련 데이터 관리
  // 모든 업데이트 로직이 reducer에 집중
  const updateField = (field, value) => 
    dispatch({ type: 'UPDATE_FIELD', field, value });
}

??. useEffect는 언제 써야할까?

useEffect는 '부수효과'를 처리하는 로직이다보니 설명이 사이드 이펙트처럼 느껴지기도 했고, 그만큼 디버깅도 어려운 훅이라고 생각이 들어 잘 사용해야하는 훅이라고 생각이 든다.

아래는 공식 문서에서 제공하는 useEffect 사용을 고민해야하는 사례를 설명하고 있는데 그중 몇가지만 소개해보려고 한다. You Might Not Need an Effect – React

사례 1: Props 변경 시 State 초기화하기

function ProfilePage({ userId }) {
  const [comment, setComment] = useState('');

  // 🔴 userId가 변경될 때마다 comment를 초기화하려고 Effect 사용
  useEffect(() => {
    setComment('');
  }, [userId]);

  return (
    <div>
      <h1>User {userId}'s Profile</h1>
      <textarea
        value={comment}
        onChange={e => setComment(e.target.value)}
      />
    </div>
  );
}

문제점:

• Effect가 실행되면서 불필요한 리렌더링 발생
• userId 변경 → 렌더링 → Effect 실행 → 다시 렌더링 (2번 렌더링!)

수정안

function ProfilePage({ userId }) {
  return <Profile userId={userId} key={userId} />;
}

function Profile({ userId }) {
  // ✅ key가 변경되면 React가 자동으로 컴포넌트를 재생성
  // State가 자동으로 초기화됨
  const [comment, setComment] = useState('');

  return (
    <div>
      <h1>User {userId}'s Profile</h1>
      <textarea
        value={comment}
        onChange={e => setComment(e.target.value)}
      />
    </div>
  );
}

장점:

• Effect 없이 자연스럽게 state 초기화
• 1번의 렌더링만 발생
• React의 key 메커니즘 활용

사례 2: 렌더링을 위한 데이터 변환

function TodoList({ todos, filter }) {
  const [visibleTodos, setVisibleTodos] = useState([]);

  // 🔴 todos나 filter가 변경될 때마다 Effect로 필터링
  useEffect(() => {
    setVisibleTodos(getFilteredTodos(todos, filter));
  }, [todos, filter]);

  return (
    <ul>
      {visibleTodos.map(todo => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

문제점:

• 불필요한 state와 Effect
• todos/filter 변경 → 렌더링 → Effect 실행 → 다시 렌더링 (2번 렌더링!)
• 메모리 낭비 (state를 별도로 저장)

수정안

function TodoList({ todos, filter }) {
  // ✅ 렌더링 중에 직접 계산
  const visibleTodos = getFilteredTodos(todos, filter);

  return (
    <ul>
      {visibleTodos.map(todo => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

function getFilteredTodos(todos, filter) {
  if (filter === 'active') {
    return todos.filter(todo => !todo.completed);
  }
  if (filter === 'completed') {
    return todos.filter(todo => todo.completed);
  }
  return todos;
}

장점:

• Effect 없이 간단하고 명확
• 1번의 렌더링만 발생
• 추가 state 불필요

오히려 이때는 useMemo 를 사용하는게 효과적

function TodoList({ todos, filter }) {
  // ✅ 비용이 큰 계산은 useMemo로 캐싱
  const visibleTodos = useMemo(() => {
    return getFilteredTodos(todos, filter);
  }, [todos, filter]);

  return (
    <ul>
      {visibleTodos.map(todo => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

사례 3: 이벤트 핸들러에서 처리해야 할 로직

function ProductPage({ product, addToCart }) {
  // 🔴 product가 변경될 때마다 알림을 보내려고 Effect 사용
  useEffect(() => {
    if (product.isInCart) {
      showNotification(`${product.name}이(가) 장바구니에 추가되었습니다!`);
    }
  }, [product]);

  function handleBuyClick() {
    addToCart(product);
  }

  return (
    <button onClick={handleBuyClick}>
      구매하기
    </button>
  );
}

문제점:

• 사용자가 구매 버튼을 누르지 않아도 알림이 뜰 수 있음
• 페이지 새로고침 시에도 알림이 뜸
• "특정 상호작용"에 대한 반응이 아니라 "상태 변화"에 반응

function ProductPage({ product, addToCart }) {
  function handleBuyClick() {
    // ✅ 사용자가 구매 버튼을 눌렀을 때만 실행
    addToCart(product);
    showNotification(`${product.name}이(가) 장바구니에 추가되었습니다!`);
  }

  return (
    <button onClick={handleBuyClick}>
      구매하기
    </button>
  );
}

장점:

• 사용자의 특정 행동에 정확히 반응
• 의도가 명확함
• 예상치 못한 시점에 실행되지 않음

그래서, Effect는 언제 사용하나?

// ✅ 외부 시스템과 동기화할 때만 사용
useEffect(() => {
  // 브라우저 API
  const connection = createConnection(serverUrl, roomId);
  connection.connect();

  return () => {
    connection.disconnect();
  };
}, [serverUrl, roomId]);

외부 시스템의 예:

• 네트워크 요청
• 브라우저 API (localStorage, geolocation 등)
• 타사 라이브러리 (D3, jQuery 등)
• 타이머 (setTimeout, setInterval)

관련 ESlint Plugin

ESLint - React - You Might Not Need An Effect

??.useRef는 왜 current를 가지고 있을까? 무슨 의도를 갖고 있는 걸까?

useRef는 기본적으로 렌더링에 필요하지 않을 값을 관리하려는 의도를 가지고 있는 훅이다.

만약 useRef내부가 일반 변수들 처럼 primitive하게 관리되었다면 매번 호출에 있어 초기화될 것이다. (불변성 유지 X)

// ❌ primitive로 관리했다면?
function Component() {
  let count = 0;  // 매 렌더마다 0으로 초기화

  const increment = () => {
    count += 1;
    console.log(count);  // 1, 2, 3...
  };

  return <button onClick={increment}>Click</button>;
  // 리렌더링 시 count는 다시 0이 됨
}

반대로 useState 처럼 관리된다면 useRef의 의도와 멀어지게 된다. ( 랜더링 발생 )

// ❌ useState로 관리했다면?
function Component() {
  const [count, setCount] = useState(0);

  const increment = () => {
    setCount(count + 1);  // 값은 유지되지만 리렌더링 발생!
  };

  return <button onClick={increment}>Click</button>;
}

위 두 문제 상황으로 접근해보면 useRef는 상태 변화에 있어서 리랜더링이 발생하면 안되고, 불변성이 유지되어야한다.

따라서 값은 바뀌어야하는데, 그 대상은 불변해야한다라는 모순적인 요구사항이 생기게 된다.

그래서 객체를 통해 이를 만족시키고자 한 것 같다.

// ✅ useRef의 실제 구조
const ref = useRef(0);

// ref 객체 자체는 불변 (같은 참조 유지)
console.log(ref);  // { current: 0 }

// current만 변경 가능
ref.current = 5;
ref.current = 10;

// 리렌더링 후에도
console.log(ref === 이전_렌더의_ref);  // true (같은 객체!)

객체를 선언한 대상으로 불변성을 유지하고, 내부의 값(current)를 통해서 값은 지속적으로 바뀔 수 있도록 의도했다.

뿐만 아니라 React 내부에서 선언된 상태는 ReactFiber를 통해 사용되는 컴포넌트로 전달된다. 이때는 JS가 값을 주고받는 원리와 연결되어 있는데

// JavaScript 값 전달 특성

// Primitive: 값 복사
let a = 5;
let b = a;  // 새로운 메모리에 5를 복사
a = 10;
console.log(b);  // 5 (변경 안됨)

// Object: 참조 전달
let obj1 = { value: 5 };
let obj2 = obj1;  // 같은 객체를 참조
obj1.value = 10;
console.log(obj2.value);  // 10 (같은 객체를 가리킴)

primvitive한 값인 경우에는 동일한 값을 복사하지만, 객체는 원본 객체를 참조하는 값을 전달하기 때문에 React Fiber 작업내에서도 불변성을 유지할 수 있는 점 때문에 객체를 채택한 것 같다.

current라는 필드 명은 네이밍 적인 요인으로 ‘현재 저장된 값’으로 생각하면 납득이 될 것 같다.

페이스북이 임의로 만든 언어로서 다양한 속성을 가진 트리 구조를 토큰화해 ECMA Script로 변환하는데 초점을 두고 있다.

→ 표현하기 까다로웠던 XML 스타일의 트리 구분을 작성하는 데 많은 도움을 주는 새로운 문법

2.1.1 JSX의 정의

JSXElement

JSX를 구성하는 기본 요소로 HTML의 요소와 비슷한 역할을 한다.

• JSXOpeningElement - <JSXElement JSXAttributes(optional)>
• JSXClosingElement - </JSXElement>
• JSXSelfClosingElement - <JSXElement JSXAttributes(optional) />
• JSXFragment - <>JSXChildren(optional)</>

JSXElementName

JSXIdentifier

function Valid1() {
    return <_></_>
}

JSX 내부에서 사용할 수 있는 식별자. 함수명, 변수명과 같이 JSXElement 사이에 구분할 수 있는 이름을 말한다. 숫자 또는 $ 와 _ 이외에 다른 특수문자로 시작할 수 없다.

JSXNameSpacedName

function Valid() {
    return <foo:bar></foo:bar>
}

JSXIdentifier:JSXIdentifier 의 조합을 의미하며, : 로 묶을 수 있는 것은 한 번 뿐이다.

JSXMemberExpression

function Valid() {
    return <foo.bar></foo.bar>
}

JSXIdentifier.JSXIdentifier의 조합을 의미하며, . 여러 개를 활용하여 묶을 수 있다. 대신 JSXNameSpacedName와 혼합하여 사용하는 것은 불가능하다.

JSXAttributes

JSXSpreadAttributes

{…AssignmentExpression} : 객체 뿐만 아니라 AssignmentExpression에서 취급할 수 있는 모든 표현식이 존재할 수 있다.

JSXAttribute

속성을 나타내는 키(JSXAttributeName)와 값(JSXAttributeValue)의 짝으로 표현한다.

• JSXAttributeName - 속성의 키 값을 의미, JSXIdentifier(<$></$>)와 JSXNamespacedName(foo:bar) 를 통해 키를 나타낼 수 있다.
• JSXAttributeValue - 속성의 키에 할당하는 값
  • "" (큰 따옴표로 구성된 문자열)
  • '' (작은 따옴표로 구성된 문자열)
  • { AssignmentExpression }
  • JSXElement
  • JSXFragment ( 별도의 속성을 갖지 않는 형태의 JSX, <></> )

JSXChildren

JSXElement의 자식 값을 나타낸다. JSX가 트리 구조를 효과적으로 보여주기 위한 목적이 있기 때문에 JSX로 부모/자식에 대한 표현이 가능하고 이 자식을 JSXChildren이라고 한다.

JSXChild

→ JSXChildren을 구성하는 기본 단위 JSXChildren은 0개 이상의 JSXChild가 필요하다. 0개 이상의 의미처럼 JSXElement는 JSXChildren은 JSXChild가 필요하다.

• JSXText - { , < , > , } 를 제외한 문자열
• JSXElement
• JSXFragment
• { JSXChildExpression (optional) } - JSXAttributes의 AssignmentExpression을 의미.

JSXString

HTML에서 사용 가능한 문자열을 JSXStrings에서 사용 가능하다. 여기서의 문자열은 '큰 따옴표', '작은 따옴표' 또는 JSXText를 의미한다.

JSX String Characters 관련 최근 논의

JSX 스펙에서 문자열 처리와 관련해서 최근에는 논의가 있었는지 궁금해서 타임라인과 함께 간단히 정리해봤습니다.

현재 JSX의 문자 처리 방식

JSX는 HTML4의 252개 문자 엔티티( , & 등)만 지원하고, HTML5의 2,231개 확장 문자는 의도적으로 제외하고 있습니다. HTML과의 복사-붙여넣기 호환성을 위해서죠.

주요 논의 내용

HTML Entities vs JavaScript Escaping (2014~)

• HTML entities를 제거하고 JavaScript 이스케이프(\u1234)를 사용하자는 제안
• JSX가 HTML이 아닌 ECMAScript 기능이므로 JS 문법이 더 적절하다는 의견
• 하지만 HTML 복사-붙여넣기 편의성 때문에 채택되지 않음

JSX 2.0 제안 무산 (2016)

• 여러 breaking changes를 모아 한번에 처리하려 했으나 실패
• 203개 찬성에도 불구하고 생태계 안정성을 위해 보류

보안 이슈 (2022)

• � 같은 특수 문자 참조의 동작 논의
• HTML 스펙상 보안을 위해 특정 문자는 U+FFFD로 대체되는데, JSX 스펙과의 불일치 문제 제기

Babel 8 변경사항

• JSX 텍스트에서 }, > 문자 금지 예정
• 마이그레이션: {'}'}와 {'>'}로 대체

현재 상황

JSX는 안정성을 최우선으로 하여 의도적으로 변경을 최소화하고 있습니다. 향후 TC39 제안으로 진행될 가능성이 언급되고 있지만, 2022년 이후로는 활발한 논의가 없는 상태입니다.

참고

• JSX 스펙 - String Characters
• GitHub Issue #146 - Unicode Entities
• GitHub Issue #65 - JSX 2.0

2.1.3 JSX는 어떻게 자바스크립트에서 변환될까?

아래 JSX 코드는

const ComponentA = <A required={true}>Hello World</A>
const ComponentB = <>Hello World</>

const ComponentC = (
    <div>
        <span>hello world</span>
    </div>
)

@babel/plugin-transform-react-jsx 로 변환하면 아래와 같이 바뀐다.

'use strict'
var ComponentA = React.createElement(
    A,
    {
        required: true,
    },
    'Hello World',
)
var ComponentB = React.createElement(
    React.Fragment,
    null,
    'Hello World',
)
var ComponentC = React.createElement(
    'div',
    null,
    React.createElement('span', null, 'hello world')
)

JSXElement(A, React.Fragment, 'div')가 먼저 인자로 들어가고 이후 옵셔널 요소인 JSXChildren( React.createElement('span', null, 'hello world'), JSXAttributes({ required: true }), JSXStrings('Hello World') 들이 다음 인자들로 들어간다.

💡 A 는 저대로 두는건가..? A는 중첩된 컴포넌트일텐데 변환될 때도 중첩된 구조로 바뀌는 건가?

1. Babel은 JSX 문법만 변환합니다
   • <A> → React.createElement(A, ...)
     • A 자체는 건드리지 않음
2. 런타임에 실행됩니다
   • React.createElement(A, ...)가 호출되면
     • React가 A 함수를 실행하고
     • 그 안의 JSX도 이미 변환된 상태
3. 중첩 구조는 함수 호출로 해결
   • A 컴포넌트 내부의 JSX는 A 함수 안에서 변환됨
   • 각 컴포넌트는 독립적으로 변환됨

위 코드를 트랜스파일하면 아래와 같이 결과가 나온다.

'use strict'

var _jsxRuntime = require('custom-jsx-library/jsx-runtime')

var ComponentA = (0, _jsxRuntime.jsx)(A, {
    required: true,
    children: 'Hello World',
})

var ComponentB = (0, _jsxRuntime.jsx)(_jsxElement.Fragment, {
    children: 'Hello World',
});

var ComponentC = (0, _jsxRuntime.jsx)( 'div', {
    children: (0, _jsxRuntime.jsx)( 'span', {
        children: 'Hello World',
    }),
})

그래서 동일한 props를 갖지만 children 요소만 달라지는 경우, 두 개의 컴포넌트를 만들고 삼항연산자를 할 필요 없고, 아래와 같이 createElement의 옵션을 통해서 간결하게 처리할 수 있다.

function TextOrHeading({ 
    isHeading,
    children
}: PropsWithChildren<{isHeading: boolean}>) {
 return isHeading ? <h1 {...args}>{children}</h1> : <span {...args}>{children}</span>
}

function TextOrHeading({ 
    isHeading,
    children
}: PropsWithChildren<{isHeading: boolean}>) {
 return React.createElement(
     isHeading ? 'h1' : 'span',
     { className: 'text' },
     children,
 )
}

2.2 가상 DOM과 리액트 파이버

DOM과 렌더링 과정

DOM: 웹 페이지에 대한 인터페이스로 브라우저가 웹페이지의 콘텐츠와 구조를 어떻게 보여줄지에 대한 정보를 담고 있다.

렌더링 과정

1. 요청한 주소에 대한 HTML 파일을 다운로드
2. 브라우저 렌더링 엔진이 HTML을 파싱해서 DOM 트리를 구성
3. CSS 파일을 만나면 CSS 파일 다운로드
4. 브라우저 렌더링 엔진이 CSS를 파싱해 CSSOM 트리를 구성
5. DOM을 순회하면서 트리를 분석한다. 이때 display: none 같이 화면에 보이지 않는 요소에 대해서는 작업하지 않는다. (렌더 트리 생성)

❓ display:none 말고 렌더 트리 형성에 영향을 주는 옵션은 어떤 것이 있을까.

렌더 트리에서 완전히 제외되는 속성

• display: none

  • DOM 트리에는 존재하지만 렌더 트리에서 완전히 제외
  • 레이아웃 계산 및 페인팅 과정에서 제외

• <head>, <script>, <meta> 등

  • 시각적으로 표시되지 않는 요소들

렌더 트리에는 포함되지만 특별하게 처리되는 속성

• visibility: hidden

  • 렌더 트리에 포함됨 (display: none과 다름)
  • 레이아웃 공간은 차지하지만 화면에 그려지지 않음
  • 자식 요소가 visibility: visible이면 보임

• opacity: 0

  • 렌더 트리에 포함됨
  • 레이아웃 공간 차지, 투명하게 렌더링
    • 이벤트는 여전히 받을 수 있음

• position: absolute/fixed + left: -9999px

  • 렌더 트리에는 포함
  • 화면 밖으로 이동시킴

• clip-path, transform: scale(0)

  • 렌더 트리에 포함
  • 시각적으로만 숨김

6. 눈에 보이는 노드에 대해서는 해당 노드에 대한 CSSOM 정보를 찾고 노드에 적용한다.
   • 레이아웃(layout, reflow): 브라우저 화면 어디에 나타나야하는지 계산하는 과정, 레이아웃 과정을 거치면 페인팅 과정을 반드시 수행
   • 페인팅(painting): 레이아웃 단계 이후에 색과 같은 실제 유효한 모습을 그리는 과정

가상 DOM 등장 배경

브라우저의 관점

추가 렌더링 과정은 SPA에서 많이 발생하게 된다. SPA는 페이지 전환시 새롭게 HTML 파일을 다운로드 받는 것이 아니라 하나의 HTML 파일 내부에서 리플로우, 리페인트 과정을 반복하면서 새로운 요소들을 보여주는 방식이다. 요소를 삭제, 삽입, 위치 계산 등의 작업이 반복되니 사용자 경험상으로는 뛰어나지만 DOM을 관리하는 비용이 커지고 있었다.

개발자의 관점

하나의 인터렉션을 통해서 내부 DOM의 수많은 요소가 변경이 일어난다. 개발자는 DOM 요소 하나하나의 변경점을 아는 것보다, 결과적으로 만들어지는 DOM 결과물에 더 포커싱이 되어있다. 그래서 인터렉션의 최종 결과물 DOM을 간편하게 제공하는 것은 개발자에게도 유용한 방법이다.

가상 DOM과 리액트 파이버

가상 DOM의 역할

가상 DOM은 실제 브라우저 DOM이 아닌 리액트가 관리하는 가상의 DOM을 의미한다. 상태나 props가 변경될 때마다 새로운 가상 DOM이 생성되고, 그 변화가 기존 가상 DOM과 비교(diff)된다. DOM 계산을 브라우저가 아닌 메모리에서 수행함으로써 실제 DOM의 렌더링 과정을 최소화할 수 있다.

리액트 파이버의 역할

리액트 파이버는 재조정자(reconciler)가 관리하며, 가상 DOM과 실제 DOM을 비교해서 변경사항을 수집한다. 파이버가 가지고 있는 둘 사이 차이점에 대해서 화면에 렌더링을 요청하는 역할을 한다.

여기서 재조정(reconciliation)은 가상 DOM을 활용한 렌더링 과정을 최적화하는데 도와주는 리액트의 아키텍처 또는 알고리즘을 말한다.

리액트 파이버가 하는 일

• 작업을 작은 단위로 분할하고 쪼갠 다음, 우선순위를 매긴다.
• 이러한 작업을 일시 중지하고 나중에 다시 시작할 수 있다.
• 이전에 했던 작업을 다시 재사용하거나 필요하지 않은 경우에는 폐기할 수 있다.

⇒ 이런 과정이 비동기적으로 일어난다.

리액트 파이버가 작업을 수행하는 단계

파이버의 작업은 크게 두 단계로 나뉜다.

렌더 단계(Render Phase)

사용자에게 노출되지 않는 모든 비동기 작업을 수행한다. 이 단계에서 앞서 언급한 파이버의 작업, 즉 우선순위를 지정하거나 중지시키거나 버리는 등의 작업이 이루어진다.

이 단계의 특징:

• 비동기적으로 실행
• 작업을 중단하고 재개할 수 있음
• 우선순위가 높은 작업이 들어오면 현재 작업을 중단하고 새로운 작업을 먼저 처리
• beginWork(), completeWork() 등이 실행됨

커밋 단계(Commit Phase)

DOM에 실제 변경 사항을 반영하기 위한 작업으로, commitWork()가 실행된다. 이 과정은 동기적으로 수행되며 중단될 수도 없다.

이 단계의 특징:

• 동기적으로 실행
• 중단 불가능
• 실제 DOM 업데이트, 라이프사이클 메서드 실행 등이 발생
• 사용자에게 보이는 변경사항이 이 단계에서 반영됨

💡 왜 커밋 단계는 동기적일까?

렌더 단계에서는 여러 번 작업을 중단하고 재개해도 사용자에게 보이지 않기 때문에 문제가 없다. 하지만 커밋 단계에서 DOM 업데이트를 중단하면 사용자는 절반만 그려진 화면을 보게 되므로, 이 단계는 한 번에 동기적으로 완료되어야 한다.

리액트 파이버 구현체

리액트 파이버는 실제로 어떻게 구현되어 있을까?

자바스크립트 객체로 관리

리액트 파이버는 하나의 자바스크립트 객체로 관리된다. 각 파이버는 리액트 엘리먼트에 1:1로 대응되며, 해당 컴포넌트에 대한 정보를 문자열, 숫자, 배열과 같은 값으로 저장한다.

관계 정의를 통한 트리 구조

파이버는 child, sibling, return 과 같은 속성을 통해 다른 파이버와의 관계를 정의하고 있다.

• child: 첫 번째 자식 파이버를 가리킴
• sibling: 다음 형제 파이버를 가리킴
• return: 부모 파이버를 가리킴 (작업 완료 후 돌아갈 곳)

이러한 구조를 통해 부모는 하나의 자식만 참조하고, sibling을 통해 형제들을 연결함으로써 1대다 관계를 효율적으로 표현한다.

// 파이버 객체의 간소화된 예시
const fiber = {
  type: 'div',              // 컴포넌트 타입
  key: null,
  props: { className: 'container' },

  // 트리 구조를 위한 포인터
  child: childFiber,        // 첫 번째 자식
  sibling: siblingFiber,    // 다음 형제
  return: parentFiber,      // 부모

  // 작업 관련
  alternate: currentFiber,  // current ↔ workInProgress
  effectTag: 'UPDATE',      // 어떤 작업을 해야 하는지
  // ...
}

이렇게 링크드 리스트 형태로 구현함으로써 재귀 없이 트리를 순회할 수 있고, 작업을 언제든 중단하고 재개할 수 있는 유연성을 확보했다.

가상 DOM과 파이버의 협력

1. 상태나 props가 변경되면 새로운 가상 DOM이 생성되고, 기존 가상 DOM과 비교(diff)된다.
2. React Fiber는 가상 DOM의 변경 사항을 렌더 단계에서 관리하며, 우선순위를 계산하고 중요한 작업부터 처리할 수 있도록 한다.
3. 여러 변경 사항이 모이면, Fiber는 커밋 단계에서 그 변경 사항을 최종적으로 실제 DOM에 일괄적으로 반영한다. 이를 통해 불필요한 DOM 조작을 줄이고 성능을 최적화한다.

따라서 가상 DOM은 매번 모든 변경 사항을 저장하는 것이 아니라, 변경이 일어날 때마다 새롭게 생성되고, 이 변경 사항들을 React Fiber가 추적하고 관리하여, 최적화된 방식으로 실제 DOM에 업데이트하는 것이다.

리액트 파이버 트리

리액트 내에는 두 개의 파이버 트리가 존재한다.

• 현재 모습을 담고 있는 파이버 트리 (current)
• 작업 중인 상태를 나타내는 workInProgress 트리

리액트는 파이버의 작업이 완료되고 나면, 커밋 단계에서 workInProgress 트리의 포인터를 변경해 current 트리로 바꾼다. 이를 더블 버퍼링이라고 한다.

더블 버퍼링 - 주로 컴퓨터 그래픽에서 사용되는 용어로, 내부 버퍼에서 그림을 지웠다가 그리는 과정을 수행한 다음에 외부 버퍼로 보내 화면이 부드럽게 보이도록 하는 방법이다.

파이버의 작업 순서

1. 리액트는 beginWork() 함수를 실행해서 파이버 작업을 수행한다. 더 이상 자식이 없는 파이버를 만날 때까지 트리 형식으로 시작한다.
2. 1번 작업이 끝나면 completeWork()를 실행해 파이버 작업을 완료한다.
3. 형제가 있으면 형제로 넘어간다.
4. 앞선 작업이 모두 완료되면 return을 통해 부모로 돌아가며, 2~4번을 반복한다.

파이버의 트리 순회 방식

React Fiber는 재귀 대신 Singly Linked List를 사용한 Parent-first, Depth-first traversal을 수행한다.

Fiber 구조체 내에서 자식, 형제, 부모에 대한 정보를 구조체로 관리하고 있다.

// packages/react-reconciler/src/ReactInternalTypes.js
export type Fiber = {
  return: Fiber | null,    // 부모
  child: Fiber | null,     // 첫 자식
  sibling: Fiber | null,   // 형제
  alternate: Fiber | null, // current ↔ workInProgress
  // ...
};

리액트 내부의 performUnitOfWork에서는 재귀보다 Linked List로 순회하는 방식을 활용한다.

function performUnitOfWork(unitOfWork: Fiber): void {
  const current = unitOfWork.alternate;

  const next = beginWork(current, unitOfWork, renderLanes);

  unitOfWork.memoizedProps = unitOfWork.pendingProps;

  if (next === null) {
    // 자식이 없으면 complete 단계로
    completeUnitOfWork(unitOfWork);
  } else {
    // 자식이 있으면 자식을 다음 작업으로
    workInProgress = next;
  }
}

과거 Stack Reconciler에서는 재귀 방식으로 동기적으로 업데이트를 수행했기 때문에 중단할 수 없었다. 현재는 Linked List 기반 DFS로 개선하여 작업을 중단/재개할 수 있고, 작업 단위와 우선순위를 정할 수 있게 되었다.

업데이트 처리

새롭게 업데이트가 생기면 workInProgress 트리를 다시 빌드한다. 최초 렌더링 시에는 모든 파이버를 새롭게 만들어야 했지만, 이후에는 파이버가 이미 존재하므로 되도록 새로 생성하지 않고 기존 파이버에 업데이트된 props를 받아 파이버 내부에서 처리한다. 파이버 객체를 계속 생성하는 것은 리소스 낭비이므로, 기존의 파이버 객체를 재사용해서 내부 속성값만 초기화하고 변경하여 트리를 업데이트한다.

파이버와 가상 DOM

• 파이버는 리액트 컴포넌트의 정보를 1:1로 가지고 있으며, 파이버의 작업(재조정)은 리액트 아키텍처 내에서 비동기적으로 작동한다. 단, 실제 DOM으로 반영되는 커밋 단계는 동기적으로 수행된다.
• 가상 DOM은 웹 애플리케이션에 대해서만 통용되는 개념이다. 리액트 네이티브에서도 파이버를 통한 재조정은 일어나지만 렌더링 엔진이 다르기 때문에, 가상 DOM은 브라우저 환경에 특화된 개념이라는 점을 알아둘 필요가 있다.

메인 페이지에서 CPU 성능을 낮춰 테스트를 해봤을 때 LCP 지표가 3.35s로 개선이 필요한 상태로 측정이 돠었다. 그래서 메인 페이지 컴포넌트 로직 수정을 통해 개선을 기획하게 되었다.

LCP는 페이지에서 가장 큰 영역을 차지하는 컨텐츠가 로드 되었을 때의 시점을 표기하는 Core Web Vital 지표이다.

현재 모멘티아 프로젝트의 메인 화면에서 보이는 케로셀의 이미지들이 효과적으로 랜더링 되지 않기 때문에 나쁘게 지표가 나오고 있는 것 같다.

🎯 개선 목표 및 방향

SSR 적용

    import LatestArtworkSection from '@/components/MainPage/LatestArtworkSection';
    import MonthlyBestArtistSection from '@/components/MainPage/MonthlyBestArtistSection';
    import MonthlyPopularArtworkSection from '@/components/MainPage/MonthlyPopularArtworkSection';

    const Home = () => {
      return (
        <div className='max-w-[1960px] w-full mx-auto my-[126px] flex flex-col gap-[126px] px-[32px] tablet:px-[140px]'>
          <MonthlyPopularArtworkSection />
          <LatestArtworkSection />
          <MonthlyBestArtistSection />
        </div>
      );
    };

    export default Home;

→ 메인 페이지는 크게 3개의 영역으로 구성되어 있다. 각 영역의 경우 현재 CSR로 랜더링 되어있는 상태이다. 현재 페이지는 메인 페이지로서 유저의 상호작용 보다 컨텐츠를 보여주는 역할이 더 큰 페이지이라고 생각한다.

→ LCP는 페이지 요청된 시점에서 가장 큰 컨텐츠 요소가 랜더링 될 때까지 걸리는 시간을 말한다. 따라서 중간에 데이터 요청을 기다리는 시간이 필요한 CSR에 비해 SSR은 서버에서 랜더링 된 화면을 바로 보여주면 되기 때문에 CSR → SSR로 개선하는 과정은 효과적인 방향이라는 생각이 들었다.

Next.js의 Image 태그의 priority 옵션 선택적 적용

    const ArtworkCard = ({
      mode = 'artwork-popular',
      rank,
      artworkInfo,
    }: ArtworkCardProps) => {
      ...

      return (
        <CardLayout onClick={clickArtworkCard} classname={modeClasses[mode]}>
          <Image
            src={postImage || '/images/defaultArtworkImage.png'}
            alt={postImage ? `artwork-${postId}` : 'default_image'}
            fill={true}
            sizes={modeClasses[mode] || '402px'}
            className={'object-cover'}
            priority
          />

          ...
        </CardLayout>
      );
    };

    export default ArtworkCard;

→ 현재 메인페이지에서 사용되는 ArtworkCard, ArtistProfileCard 컴포넌트에는 <Image/> 태그가 사용되는데 모두 priority 옵션이 적용되고 있다. priority 옵션을 사용하는 경우 이미지 리소스가 우선적으로 로드되는데 많은 이미지에 해당 옵션이 적용되고 있다보니 그만큼 랜더링에 필요한 다른 리소스들의 우선순위가 낮아져 LCP 지표에 영향을 주고 있다는 추측을 했다.

→ 케로셀 특성상 특정 순위 아래에 있는 이미지들은 빠르게 로드할 필요가 없기 때문에 특정 순위 이상인 경우 priority 옵션을 적용 하도록 수정할 계획이다.

✅ 리팩토링 결과 (After)

CSR → SSR

const MonthlyBestArtistSection = () => {
  const { cardsInfo, isLoading } = useGetMonthlyPopularArtists();

  if (isLoading) return <div>로딩중</div>;

  return (
    <div className='flex flex-col gap-[90px]'>
      <div className='flex flex-col gap-[30px]'>
        <p className='title-l'>이달의 예술가 TOP10</p>
        <p className='subtitle1'>
          지난 한 달간 가장 많은 작품 좋아요를 받은 작가들이에요.
        </p>
      </div>
      <ControlledCarousel
        slides={cardsInfo}
        renderSlide={(info: ArtistInfoType, index: number) => (
          <ArtistProfileCard artistInfo={{ ...info }} rank={index + 1} />
        )}
      />
    </div>
  );
};

export default MonthlyBestArtistSection;

→ 기존 코드의 경우 Tanstack Query를 통해 데이터를 요청하고, 데이터를 통해 반복적으로 컴포넌트를 랜더링하는 단순한 로직이었다.Tanstack Query를 사용하는 커스텀 훅을 활용하기 때문에 use client 옵션을 적용하게 되었다.

const MonthlyBestArtistSection = async () => {
  const users: ArtistInfoType[] = await getMonthlyPopularArtists();

  const slides = users.map((info: ArtistInfoType, index: number) => (
    <ArtistProfileCard
      artistInfo={{ ...info }}
      rank={index + 1}
      isPriority={index < 4}
    />
  ));

  return (
    <div className='flex flex-col gap-[90px]'>
      <div className='flex flex-col gap-[30px]'>
        <p className='title-l'>이달의 예술가 TOP10</p>
        <p className='subtitle1'>
          지난 한 달간 가장 많은 작품 좋아요를 받은 작가들이에요.
        </p>
      </div>
      <ControlledCarousel slides={slides} />
    </div>
  );
};

export default MonthlyBestArtistSection;

→ 개선 후에는 서버에서 활용하지 않는 Tanstack Query 관련한 로직들을 제거하여 데이터 fetching 하는 로직만 남겨두었다.

priority 옵션

    const MonthlyBestArtistSection = async () => {
        ...

      const slides = users.map((info: ArtistInfoType, index: number) => (
        <ArtistProfileCard
          artistInfo={{ ...info }}
          rank={index + 1}
          isPriority={index < 4}
        />
      ));

      return (
        <div className='flex flex-col gap-[90px]'>
          <div className='flex flex-col gap-[30px]'>
            <p className='title-l'>이달의 예술가 TOP10</p>
            <p className='subtitle1'>
              지난 한 달간 가장 많은 작품 좋아요를 받은 작가들이에요.
            </p>
          </div>
          <ControlledCarousel slides={slides} />
        </div>
      );
    };

    export default MonthlyBestArtistSection;

    const ArtworkCard = ({
      mode = 'artwork-popular',
      rank,
      artworkInfo,
      isPriority = false,
    }: ArtworkCardProps) => {
      ...

      return (
        <CardLayout onClick={clickArtworkCard} classname={modeClasses[mode]}>
          <Image
            src={postImage || '/images/defaultArtworkImage.png'}
            alt={postImage ? `artwork-${postId}` : 'default_image'}
            fill={true}
            sizes={modeClasses[mode] || '402px'}
            className={'object-cover'}
            priority={isPriority}
          />

          ...
        </CardLayout>
      );
    };

    export default ArtworkCard;

→ ArtistProfileCard , ArtworkCard 컴포넌트의 Props에 isPriority라는 props를 추가적으로 넘겨주고 받는 컴포넌트에서 해당 값을 활용하여 선택적으로 priority 옵션이 적용되도록 수정했다.

📈 리팩토링 효과

• SSR 적용 후

• priority 옵션 선택적 적용 후

→ 전반적으로 SSR을 적용했을 떄, priority 옵션을 적용했을 때 순차적으로 LCP 지표가 개선되는 것을 확인할 수 있었다.

💬 회고 및 배운 점

• 이번 개선 작업에서 지표 측정을 lighthouse를 통해서 진행했었는데, 몇 회정도는 너무 지표가 좋게 나오거나 반대로 너무 나쁘게 지표가 나오는 경우가 있었다. 성능 측정 기준을 어떻게 잡아야 해당 지표를 신뢰할 수 있을지 고민이 되었다.
• 두 개선 방안 모두 어쩌면 구현 단계에서 적용해 볼 수 있는 선택지들이었다는 생각도 들었다. 이런 부분들도 설계 과정에 포함하는 것과 이번처럼 구현 후 성능 개선을 하는 방향 중에 어떤 것이 더 효과적이고 잘한 방법인지도 고민이 되었다.

🧩 참고 자료

• https://web.dev/articles/lcp?hl=ko

그 전에! 업데이트 내용 옆에 alpha, beta 이런 식으로 키워드가 달려있는데 이것부터 정확하게 하고...

• Alpha (알파): 초기 테스트 단계로, 소프트웨어가 불완전하고 불안정하며 버그를 포함할 수 있지만, 핵심 기능은 포함된 단계
• Beta (베타): 다음 단계로, 알파보다는 안정적이지만, 여전히 버그가 있을 수 있으며 사용자 피드백에 따라 변경될 수 있는 단계
• Stable (안정 버전): 최종적으로 공식 릴리스된 버전으로, 완전히 테스트되었으며 신뢰할 수 있고 일반 사용자가 사용할 준비가 된 단계

1. Turbopack (Stable) - 이제 기본 번들러

• 성능 개선
  • 프로덕션 빌드: 2-5배 빠름
  • Fast Refresh: 최대 10배 빠름
• Next.js 15.3+ 기준으로 개발 세션의 50%, 프로덕션 빌드의 20%가 이미 Turbopack 사용 중
• 모든 새 프로젝트에 자동으로 적용
• next dev --webpack 플래그로 계속 사용 가능

파일시스템 캐싱 (Beta)

→ turbopack에서의 Beta 기능 / webpack에는 이미 있음

→ 컴파일 결과물을 디스크에 저장

const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForDev: true,
  },
};

• 컴파일 아티팩트를 디스크에 저장하여 재시작 시 훨씬 빠른 컴파일 가능

2. React Compiler 지원 (Stable)

• 컴포넌트를 자동으로 메모이제이션하여 불필요한 리렌더링 감소
• 수동 최적화 코드 작성 불필요
• Babel 의존성 때문에 빌드 시간이 증가할 수 있음

const nextConfig = {
  reactCompiler: true, // 이제 stable!
};

• 예시

  React Compiler는 빌드시 메모이제이션을 추가해준다!

    function ProductList({ products, onSelect }) {
      return (
        <div>
          {products.map(product => (
            <ProductCard 
              key={product.id}
              product={product}
              onClick={() => onSelect(product)}
            />
          ))}
        </div>
      );
    }

    function ProductList({ products, onSelect }) {
      // React Compiler가 자동으로 추가한 메모이제이션
      const memoizedProducts = useMemo(() => products, [products]);
      const memoizedOnSelect = useCallback(onSelect, [onSelect]);
  
      const memoizedMap = useMemo(() => 
        memoizedProducts.map(product => ({
          key: product.id,
          product,
          onClick: () => memoizedOnSelect(product)
        }))
      , [memoizedProducts, memoizedOnSelect]);
  
      return (
        <div>
          {memoizedMap.map(item => (
            <ProductCard {...item} />
          ))}
        </div>
      );
    }

💡 React Compiler 업데이트가 왜 Next.js에?

React Compiler가 최신 React 19 버전으로 올라가면서 나오게 되어서, React에서 기본적으로 제공하는 기능을 Next.js에서 제한적으로 제공했었나? 라는 생각을 했었는데, 그건 오해였고, React Compiler는 기본적으로 플러그인처럼 제공되어서, React에서도 기본적으로 설정이 필요했다. 이번 Next.js에서는 React Compiler를 사용하기 쉽도록 설정값을 추가해준 업데이트인 것이었다. 😥

3. 향상된 라우팅 & 내비게이션

Layout Deduplication (레이아웃 중복 제거)

• 문제: 50개의 제품 링크가 있는 페이지에서 공유 레이아웃이 50번 다운로드됨
• 해결: 공유 레이아웃(layout.tsx)은 한 번만 다운로드하고, 각 링크별로 차이나는 부분만 다운로드
• 결과: 네트워크 전송 크기 대폭 감소

Incremental Prefetching (증분 프리페칭)

• prefetching을 청크 단위로 구분

  → 이미 캐시된 부분은 건너뛰고 필요한 부분만 프리페칭

• 링크가 뷰포트를 벗어나면 요청 취소

• 호버 시 우선순위 높여서 프리페칭

• 데이터 무효화 시 자동으로 재프리페칭

트레이드오프: 개별 요청 수는 증가(청크)하지만, 전체 전송 크기는 크게 감소(캐싱)

4. 개선된 캐싱 API

• Caching API → Next.js에서 제공하는 캐싱 제어 유틸

revalidateTag() 변경 ⚠️

→ 기본동작 : 캐싱된 데이터를 반환하고, 새 데이터를 fetch 한 후에 캐시 값 갱신

// ✅ 새로운 방식 (필수)
revalidateTag('blog-posts', 'max');  // 대부분의 경우 'max' 권장
revalidateTag('news-feed', 'hours');
revalidateTag('analytics', 'days');
revalidateTag('products', { revalidate: 3600 }); // 인라인 설정

// ❌ 기존 방식 (deprecated)
revalidateTag('blog-posts');

• 두 번째 인자 필수: cacheLife 프로필 지정
• SWR 동작: 사용자는 캐시된 데이터를 즉시 받고, 백그라운드에서 재검증

updateTag() (신규) 🆕

→ 기본 동작 : 기존 캐시를 만료 시키고, 새 값을 fetch해서 반환 후 캐시 갱신

'use server';
import { updateTag } from 'next/cache';

export async function updateUserProfile(userId, profile) {
  await db.users.update(userId, profile);
  updateTag(`user-${userId}`); // 즉시 캐시 만료 및 갱신
}

• Server Actions 전용
• Read-your-writes: 사용자가 변경한 내용을 즉시 확인 가능
• 용도: 폼, 사용자 설정 등 즉각적인 피드백이 필요한 경우

refresh() (신규) 🆕

'use server';
import { refresh } from 'next/cache';

export async function markNotificationAsRead(notificationId) {
  await db.notifications.markAsRead(notificationId);
  refresh(); // 캐시되지 않은 데이터만 갱신
}

• Server Actions 전용
• 캐시 건드리지 않음: 알림 카운트, 실시간 메트릭 등 캐시되지 않은 데이터만 갱신

6. 주요 Breaking Changes

필수 요구사항

• Node.js: 20.9+ (18 지원 종료)
• TypeScript: 5.1.0+
• 브라우저: Chrome/Edge/Firefox 111+, Safari 16.4+

비동기로 변경 필수 ⚠️

→ 내부 동작 자체가 비동기로 마이그레이션됨 → 성능 최적화

// ❌ 기존 방식
const params = props.params;
const searchParams = props.searchParams;
const cookieStore = cookies();

// ✅ 새로운 방식
const params = await props.params;
const searchParams = await props.searchParams;
const cookieStore = await cookies();

next/image 변경사항

• images.minimumCacheTTL: 60초 → 4시간 (14400초)
• images.imageSizes: 16 제거 (사용률 4.2%에 불과)
• images.qualities: [1..100] → [75]로 단순화
• images.maximumRedirects: 무제한 → 3으로 제한
• 보안: images.dangerouslyAllowLocalIP 기본값 false

Middleware 파일명

• middleware.ts → proxy.ts로 변경 권장 (deprecated)

⚛️ React 19.2 주요 업데이트

1. <Activity /> 컴포넌트 🆕

애플리케이션을 "활동" 단위로 나누어 제어 가능

// 기존 방식
{isVisible && <Page />}

// 새로운 방식
<Activity mode={isVisible ? 'visible' : 'hidden'}>
  <Page />
</Activity>

모드

• visible: 자식 표시, 이펙트 마운트, 업데이트 정상 처리
• hidden: 자식 숨김 (display: none), 이펙트 언마운트, 업데이트를 가장 낮은 우선순위로 지연

사용 사례

• 사용자가 다음에 탐색할 가능성이 높은 부분을 미리 렌더링 (백그라운드에서 데이터, CSS, 이미지 로딩)
• 뒤로 가기 시 입력 필드 등의 상태 유지

💡 기존 방식이랑 코드 작성법만 바뀐거 아니에요?! 🤬(억지)

Activity를 사용하면 아래와 같이 동작하게된다. 컴포넌트는 마운트와 백그라운드 랜더링, 데이터 또는 이미지 Fetching, 상태 유지가 가능하다. 하지만 useEffect는 동작하지 않는다. 컴포넌트는 마운트되어 있고 State도 유지되지만, 모든 Effect(부수효과)가 클린업되어 실행되지 않는 대기 상태로 유지된다. 기존 방식에 비해서 해당 컴포넌트가 화면에 보일 수 있게 사전 작업을 미리 해둘 수 있어 UX적으로도 뛰어난 업데이트라고 볼 수 있다.

2. useEffectEvent() 🆕

Effect에서 상태 갱신으로 인한 side effect와 로직을 분리하는 패턴 → Effect 내부에서 사용되는 값이 의존성 배열에 포함되면서 Effect가 지속적으로 재실행되는 현상을 개선 → 최신 값을 사용해야 하지만, 그 값의 변경으로 인한 Effect 재실행(부수 효과)을 방지하고 싶을 때 사용

문제 상황

function ChatRoom({ roomId, theme }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.on('connected', () => {
      showNotification('Connected!', theme); // theme 사용
    });
    connection.connect();
    return () => connection.disconnect();
  }, [roomId, theme]); // theme 변경 시 재연결 발생 🤦
}
// -> 채팅 룸 상태가 theme에 의존함

해결 방법

function ChatRoom({ roomId, theme }) {
  const onConnected = useEffectEvent(() => {
    showNotification('Connected!', theme); // 항상 최신 theme 참조
  });

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.on('connected', () => {
      onConnected();
    });
    connection.connect();
    return () => connection.disconnect();
  }, [roomId]); // ✅ roomId만 의존성 배열에 남김
}

특징

• Effect Event는 항상 최신 props/state를 "봄"
• 의존성 배열에 포함하지 않음
• eslint-plugin-react-hooks@6.1.0 업그레이드 필요

3. cacheSignal() 🆕

💡 React cache()

• 렌더링 사이클 동안 동일한 데이터 요청의 중복을 제거하는 함수
• 여러 중첩된 Server Component가 같은 데이터를 요청할 때, 실제 fetch는 1번만 수행
• 일반 캐싱과의 차이
  • 일반 캐싱: 시간 기반 저장 (예: 1시간), 재방문 시 재사용
  • React cache(): 렌더링 기반 저장, 렌더링 끝나면 즉시 삭제

cache() 라이프타임이 끝날 때를 알 수 있는 신호

import { cache, cacheSignal } from 'react';

const dedupedFetch = cache(fetch);

async function Component() {
  await dedupedFetch(url, { signal: cacheSignal() });
}

정리 시점

• 렌더링이 성공적으로 완료됨
• 렌더링이 중단됨
• 렌더링이 실패함

그래서 이걸 어따씀..?

• 여러 데이터를 조회하는 과정에서 빠르게 페이지를 넘어갈 때 현재 요청을 중단하고 리소스를 정리할 때.

• 예시

    async function ProductPage({ id }) {
      const product = await fetchProduct(id);      // 요청 1
      const reviews = await fetchReviews(id);      // 요청 2
      const related = await fetchRelated(id);      // 요청 3
  
      return <div>...</div>;
    }
  
    const fetchProduct = cache(async (id) => {
      return fetch(`/api/products/${id}`, { signal: cacheSignal() });
    });
  
    const fetchReviews = cache(async (id) => {
      return fetch(`/api/reviews/${id}`, { signal: cacheSignal() });
    });
  
    const fetchRelated = cache(async (id) => {
      return fetch(`/api/related/${id}`, { signal: cacheSignal() });
    });

  케이스 1: 렌더링 정상 완료

    렌더링 시작
      ↓
    fetchProduct 완료 (1초)
      ↓
    fetchReviews 완료 (1초)
      ↓
    fetchRelated 완료 (1초)
      ↓
    렌더링 완료
      ↓
    cacheSignal 발동
      → 모든 fetch 이미 완료됨
      → 아무 일도 안 일어남 ✅

  ---

  케이스 2: 렌더링 중간에 중단 (페이지 이동)

    렌더링 시작
      ↓
    fetchProduct 시작 (3초 소요 예상)
    fetchReviews 시작 (3초 소요 예상)
    fetchRelated 시작 (3초 소요 예상)
      ↓
    1초 후 사용자가 다른 페이지로 이동!
      ↓
    렌더링 중단!
      ↓
    cacheSignal 발동
      → fetchProduct의 fetch 취소 ✅
      → fetchReviews의 fetch 취소 ✅
      → fetchRelated의 fetch 취소 ✅

  이 경우 3개 모두 취소되는 이유:

  • 3개 모두 같은 렌더링 사이클에 속함

  • 렌더링 중단 = 모든 cache() 정리

  • 각자의 cacheSignal이 각자의 fetch 취소

    케이스 3: 일부만 완료된 경우

    렌더링 시작
    ↓
    fetchProduct 완료 (0.5초) ✅
    ↓
    fetchReviews 시작 (3초 소요 예상) 🔄
    fetchRelated 시작 (3초 소요 예상) 🔄
    ↓
    1초 후 사용자가 페이지 이동
    ↓
    렌더링 중단!
    ↓
    cacheSignal 발동
    → fetchProduct: 이미 완료, 취소할 게 없음
    → fetchReviews: 진행 중이던 fetch 취소 ✅
    → fetchRelated: 진행 중이던 fetch 취소 ✅

    "각 fetch의 cacheSignal은 자기 자신의 요청만 취소한다. 단, 같은 렌더링 사이클에 속한 모든 cache()가 정리될 때 각자의 fetch가 각자 취소된다."

4. Performance Tracks 🆕

Chrome DevTools에 React 전용 성능 트랙 추가

Scheduler ⚛ Track

• React가 다양한 우선순위로 작업하는 내용 표시
• "blocking" (사용자 인터랙션) vs "transition" (startTransition 내부)
• 업데이트를 스케줄한 이벤트 타입
• 어떤 우선순위가 다른 우선순위를 기다리는지

Components ⚛ Track

• React가 작업 중인 컴포넌트 트리 표시
• "Mount", "Blocked" 등의 라벨
• 컴포넌트가 렌더링되거나 이펙트를 실행하는 시점과 소요 시간

5. Partial Pre-rendering (PPR)

• 앱의 일부를 정적 컨텐츠로 빌드 시 미리 생성(SSG) CDN에서 제공.
• 동적 영역에 대해서는 SSR로 스트리밍하여 나머지 컨텐츠 제공

→ SSG(Static Site Generation)는 빠르지만 동적 컨텐츠를 제공하지 못한다는 특징과, SSR(Server Side Rendering)은 동적 컨텐츠를 제공할 수 는 있지만 서버를 거쳐 컨텐츠를 생성해야한다는 점을 상호 보완한 하이브리드 랜더링 방식

→ ISR(Incremental Static Regeneration)은 정적 데이터를 주기적으로 생성해서 새로운 데이터를 보여주는 방식이라 PPR과의 랜더링 방식에는 차이가 있음

// 1. 사전 렌더링
const { prelude, postponed } = await prerender(<App />, {
  signal: controller.signal,
});
await savePostponedState(postponed);
// prelude를 클라이언트나 CDN으로 전송

// 2. 나중에 재개 (SSR 스트림)
const postponed = await getPostponedState(request);
const resumeStream = await resume(<App />, postponed);

// 또는 SSG를 위한 정적 HTML
const { prelude } = await resumeAndPrerender(<App />, postponedState);

6. 그 외 주요 변경사항

Suspense Boundary Batching (SSR)

• 이전: 스트리밍 SSR 중 Suspense 콘텐츠가 준비되는 즉시 fallback 교체
• 19.2: 짧은 시간 동안 배치하여 더 많은 콘텐츠를 함께 표시
• 장점: <ViewTransition> 지원 준비, 애니메이션을 더 큰 배치로 실행

Node.js에서 Web Streams 지원

• renderToReadableStream Node.js에서 사용 가능
• prerender Node.js에서 사용 가능
• resume, resumeAndPrerender API 추가

eslint-plugin-react-hooks v6

• Flat config가 기본값 (ESLint v10 준비)
• React Compiler 기반 규칙 opt-in 가능
• 레거시 설정: recommended-legacy 사용

useId 기본 prefix 변경

• _r_ 로 변경 (이전: :r: 또는 «r»)
• 이유: View Transitions 지원을 위해 view-transition-name과 XML 1.0 이름에 유효한 ID 필요

📚 참고 자료

• Next.js 16 Beta 공식 블로그
• React 19.2 공식 발표

실시간과 관련해서는 거의 경험이 없다시피 했고, 대충 WebSocket 개념 정도..? 만 알고있었다.

언제가되든 실시간과 관련된 기능을 꼭 한 번 경험해볼 날이 올 것 같아 다양한 방식들을 알아보는 시간을 가졌다..!

Polling

Polling은 특정 장치가 다른 장치의 상태를 주기적으로 검사하고, 일정 조건을 만족할때 송수신 자료처리를 하는 방식을 말한다. 웹에서 실시간 통신을 폴링 방식으로 구현할 경우, 클라이언트는 일정 주기로 서버에 요청을 보내어 상태를 확인한다.

폴링 방식은 구현 방식이 가장 간단하지만, 서버로 보내는 요청이 길어질 수 록 서버 리소스 낭비가 심해지고, 이벤트가 발생하는 시점과, 서버가 요청에 대한 응답을 보내는 시점이 정확하게 일치하지 않기 때문에 실시간 성에서 단점을 가진다.

Long Polling

Long Polling은 Polling과 반복적으로 서버에 요청을 보내는 측면에서는 같지만 다음과 같은 특징을 가진다.

• Polling과는 달리 서버에 요청을 보내고 서버에서 곧바로 응답을 보내는 것이 아니라 이벤트가 발생하기 까지 일정시간 대기 했다가 이벤트가 발생하면 응답을 내려주는 방식이다.
• 이벤트가 발생하면 즉시 응답하고, 일정 시간이 지나면 타임아웃 처리 후 다시 요청한다.

Long Polling은 이벤트 발생 빈도가 매우 높다면, 일반 Polling과 차이가 줄어들지만, 그렇지 않은 경우에는 서버 부하를 줄이는 데 더 효과적이다.

Server-Sent Event (SSE)

SSE(Server-Sent Events)는 서버 → 클라이언트 단방향 통신을 형성하여, 클라이언트가 별도의 요청을 보내지 않아도 서버가 지속적으로 이벤트를 푸시할 수 있는 방식을 말한다.

초기에 클라이언트가 연결 요청(Request Connect)을 보내고, 서버가 OK 응답을 반환하면 단방향 통신이 유지되면서 서버에서 여러 이벤트를 보낸다.

연결을 종료할 때는 클라이언트가 명시적으로 연결 해제 요청(Request Disconnect)을 보내거나,서버에서 특정 조건(예: 타임아웃, 리소스 제한 등)에 의해 연결을 종료할 수도 있다.

SSE는 서버에서 이벤트가 발생했을 때 클라이언트로 메세지를 보내기 때문에 실시간 성이 뛰어나지만 HTTP/HTTPS 프로토콜에 따라 도메인에 연결할 수 있는 요청 개수가 한계가 있다.

HTTP의 경우 6개, HTTPS의 경우 100개 정도이기 때문에 대규모 서비스에서 SSE를 활용하는 것에는 어려움이 있을 수 있다.

또한, 양방향 연결이 아닌 서버에서 클라이언트로 연결되는 단방향 연결이기 때문에 클라이언트와 서버의 양방향 통신이 필요한 경우에는 적절하지 않은 방식이다.

Web Socket

Web Socket은 웹 브라우저에서 소켓 통신을 가능하게 설계된 방식으로 양 끝단의 컴퓨터가 서로 자유롭게 데이터를 주고받을 수 있다는 점이 특징이다.

기존 소켓 통신을 브라우저에서 활용할 수 있도록 최적화 된 방식이기 때문에 아래와 같은 소켓 연결 / 해제 과정을 따른다.

1. connect()
   • 클라이언트가 서버로 WebSocket 연결 요청을 보냄. ( HTTP / HTTPS )
   • HTTP 요청의 헤더로 Upgrade : websocket 을 함께 보내 연결된 이후 WebSocket 프로토콜로 전환하여 요청/응답을 처리
2. read() / write()
   • WebSocket 연결이 완료된 상태에서 서버/클라이언트 순서에 관계없이 데이터를 주고 받을 수 있음
   • HTTP/HTTPS 프로토콜 대신 WS/WSS 프로토콜을 활용한다.
3. close()
   • 클라이언트의 close()을 보내 소켓 통신을 중단한다.

🧐 Why HTTP → WS?

그냥 두 프로토콜의 목적이 다르기 때문이다.

• WebSocket 프로토콜은 전이중 통신을 지원하는 프로토콜이고, 연결된 이후 클라이언트와 서버 간 연결을 지속하며 동시에 데이터를 주고 받을 수 있다.
• HTTP의 경우 요청-응답 프로토콜이며 WebSocket과 다르게 요청을 보내는 경우에만 응답을 받을 수있고, 응답을 받으면 연결을 종료한다.

그 외

여러 통신 방식을 찾아보면서 추가로 언급된 방식들이다. 짧게 읽어본 내용들이라 디테일하게 파악하진 못했지만 주로 멀티미디어와 관련된 실시간 통신 방식인 것으로 보였다. 이번 실시간 통신 방식들을 주로 서버로부터 메세지를 받거나 서버의 이벤트를 감지하기 위한 목적의 실시간 통신을 비교해보고 있었기 때문에 해당 방식들은 조금만 알아보았다..ㅎ

Web Real Time Communication (WebRTC)

웹 브라우저간 외부 플러그인의 도움 없이 P2P 통신이 가능하도록 설계된 API. 음성 통화, 화상 통화, 파일 공유 등에 활용한다.

https://webrtc.org/?hl=ko

HTTP Live Streaming (HLS)

HTTP 기반 적응형 비트레이트 스트리밍 통신 프로토콜을 의미하며, 여러 미디어 플레이어에서 HTTP 기반 파일을 작은 단위로 다운로드하여 잠재적으로 무한한 전송 스트림을 적재하며 동작하는 방식.

https://ko.wikipedia.org/wiki/HTTP_라이브_스트리밍

Fin.

우연한 기회로 실시간 통신들의 여러가지 방식을 알아보게 되었다.

어떤 곳에 어떤 방식을 적용하는 것이 좋을지 생각도 해밨다. 각 바식을 이해하면서 각 방식의 장단점이 명확하다는 생각이 들었고, 어느 한가지만 사용한다기 보다 서로 단점을 보완할 수 있게 여러가지 방식을 함께 활용하고 있을 수 도 있겠다는 생각도 들었다.

예를 들어 SSE의 경우 도메인에 연결할 수 있는 인스턴스의 수가 적기 때문에 모든 개체를 무한정 연결해두었을 때 나중에 연결조차 하지 못하는 경우가 발생할 수 있다.

이 경우에는 특정 이벤트가 발생하는 시점을 대략 예측할 수 있다는 가정하에 롱 폴링과 SSE를 섞어 사용해볼 수도 있을 것 같다.

특정 이벤트 처리를 위해 9분이 걸린다고 하면 7 ~ 8분 쯤에는 롱 폴링으로 실시간 통신을 시도하고, 이벤트 발생 확률이 높은 9분 대에는 SSE를 적용하여 실시간성을 최대한 높이면서 짧은시간 연결을 유지하도록해서 현재 연결상태에 있는 인스턴스의 개수를 최소한으로 유지할 수 있을 것 같다.

이런 생각들이 옳은 방향으로 생각하고 있는 것인진 모르겠지만, 이런 식으로 여러가지 생각을 많이 해볼 수 있었던 주제였던 것 같다.

Reference

https://sendbird.com/ko/developer/tutorials/websocket-vs-http-communication-protocols

https://ko.wikipedia.org/wiki/폴링_(컴퓨터_과학) https://developer.mozilla.org/ko/docs/Web/API/Server-sent_events/Using_server-sent_events

https://velog.io/@charmull/실시간-통신-기술

이전에는요…

const useToggleFollow = ({
  initFollowState,
}: {
  initFollowState: boolean | null;
}) => {
  ...

  const mutation = useMutation<
    void,
    Error,
    { userId: number; following: boolean }
  >({
    mutationFn: async ({ userId, following }) => {
      following ? await deleteFollow(userId) : await postFollow(userId);
    },

    onSuccess: (_, { following }) => {
      const currentUserId = TokenHandler.getUserIdFromToken();

      if (currentUserId) {
        [
          ARTWORK.followedArtists,
          USER.followerList(currentUserId),
          USER.followingList(currentUserId),
        ].forEach((queryKey) => {
          queryClient.invalidateQueries({ queryKey: [queryKey] });
        });
      }

      setIsFollowing(!following); // 성공 시 데이터 변경
    },

    onError: (error) => {
      console.error('팔로우 상태 변경 에러: ', error.message);
    },
  });

    ...

  return { isFollowing, toggleFollow };
};

export default useToggleFollow;

기존 로직의 개선점

• useMutation의 동작에 따라 onSuccess는 mutateFn이 정상적으로 마쳐야 동작. 따라서 follow 상태를 변경하는 로직은 api 로직이 모두 끝난 다음에야 동작.

→ UI 갱신이 follow/unfollow의 로직 처리 시간에 영향을 받음.

• 에러가 발생했을 때, 함수 자체가 미실행 된 것인지, 버튼 이벤트가 실패한 것인지에 대한 피드백이 없음 (다른 UI 장치가 없다고 가정.)

낙관적 업데이트

사용자 경험(UX)를 증진시키기 위해 적용하는 개념으로, 상태, 데이터 업데이트와 관련해서 우선 데이터 변경이 정상적으로 이루어진 다는 것을 가정하여 요청이 마무리 되기전에 상태를 변경하고, 추후 실패 상태에 대해서는 다시 원래 상태로 복구 시켜 에러 이벤트에 대한 피드백을 전달하는 방식

낙관적 업데이트는 언제 활용해야할까.

낙관적 업데이트를 적용하는 기준에 대해서 프로젝트 데모 발표 때에도 받았었다. 개인적으로, 이번에 적용한 팔로우, 좋아요 버튼과 같이 사용자가 api 요청에 대한 결과를 사용하지 않아 사용자 액션에 영향을 주지 않는 UI의 UX를 개선하기 위해 사용하려고 했다.

반면에 갱신된 서버 데이터로 인해서 이후 다른 인터렉션에 영향이 미치는 경우나 중요한 비즈니스 로직의 경우 빠른 반응보다 정확한 처리가 더 중요하기 때문에 이런 경우에는 지양하는 것이 좋겠다라는 생각을 했다.

낙관적 업데이트 적용하기

1. setState로 적용하기

단순히 ‘상태를 미리 갱신한다.’는 점에서 setState를 통해서 구현이 가능하다.

mutateFn 내에서 api 요청을 실행하기 전에 state를 수정하고, 성공 시에 상태는 그대로 두고, 에러 발생 시 mutateFn의 인자로 전달받은 값을 통해 이전 값으로 갱신한다.

```jsx
const useToggleFollow = ({
  initFollowState,
}: {
  initFollowState: boolean | null;
}) => {
    ...

  const mutation = useMutation<
    void,
    Error,
    TogglePropsType,
    MutationContextType
  >({
    mutationFn: async ({ userId, following }) => {
        // 상태 먼저 갱신
      setState(!following);
      following ? await deleteFollow(userId) : await postFollow(userId);
    },

    onSuccess: () => {
      const currentUserId = TokenHandler.getUserIdFromToken();

      if (currentUserId) {
        [
          ARTWORK.followedArtists,
          USER.followerList(currentUserId),
          USER.followingList(currentUserId),
        ].forEach((queryKey) => {
          queryClient.invalidateQueries({ queryKey: [queryKey] });
        });
      }

      // 성공시 변경된 상태 그대로 유지
    },

    onError: (error, { following }) => {
        // 에러 발생시 상태 롤백
        setState(following);
      console.error('팔로우 상태 변경 에러: ', error.message);
    },
  });

    ...
};
```

이것도 충분히 잘 작동한다.

2. useMutate로 적용하기

tanstack query에서는 낙관적 업데이트를 위한 useMutation의 onMutate 옵션을 제공하고 있다. 공식 문서에서는 다음과 같이 onMutate에 대해서 설명하고 있다.

• 이함수는 mutation 함수가 실행되기 이전에 실행된다. 그리고 mutation 함수가 받아 하는 변수와 동일한 변수를 전달 받는다.
• mutation이 성공했을 때에 대한 낙관적 업데이트에 활용할 수 있다.
• mutation이 실패한 경우, 이 함수로 부터 return된 값은 onError와 onSettled로 전달 된다. 그리고 낙관적업데이트를 롤백하는 데 유용하다.

onMutate를 활용하여 다음과 같이 적용해볼 수 있다.

const useToggleFollow = ({
    initFollowState,
  }: {
      initFollowState: boolean | null;
  }) => {
    ...

    const mutation = useMutation<
      void,
      Error,
        TogglePropsType,
        MutationContextType
    >({
        mutationFn: async ({ userId, following }) => {
          following ? await deleteFollow(userId) : await postFollow(userId);
        },

        onMutate: async ({ following }) => {
          await queryClient.cancelQueries();

          // 에러 케이스를 대비하여 기존 상태 값 저장
          const prevFollowStatus = isFollowing;

          // 일단 상태 변경
          setIsFollowing(!following);

          return { prevFollowStatus };
        },

        onSuccess: () => {
          const currentUserId = TokenHandler.getUserIdFromToken();

          if (currentUserId) {
            [
              ARTWORK.followedArtists,
              USER.followerList(currentUserId),
              USER.followingList(currentUserId),
            ].forEach((queryKey) => {
              queryClient.invalidateQueries({ queryKey: [queryKey] });
            });
          }

          // 성공시 변경된 상태 그대로 유지
        },

        onError: (error, _, context) => {
          console.error('팔로우 상태 변경 에러: ', error.message);

          // 에러가 발생한 경우 원래 상태로 롤백
          if (context?.prevFollowStatus !== undefined) {
              setIsFollowing(context.prevFollowStatus);
        }
      },
    });

  ...

};

왜 setState 방식으로도 할 수 있는데, onMutate라는 옵션을 제공할까.

내 생각 )

낙관적 업데이트가 필요한 경우는 대부분 서버 상태 갱신을 위해 로직을 처리하는 과정에서 딜레이가 발생하기 때문이다. setState로 낙관적 업데이트를 구현하게 되면 상태를 업데이트하는 과정이 마치 클라이언트 상태 갱신과 같이 동작하게 된다.

따라서, tanstack query는 서버 상태 관리를 위한 라이브러리로서 낙관적 업데이트 관련한 onMutate 옵션을 제공함으로서 보다 서버 상태와 클라이언트 상태를 명확하게 구분하기 위함이 아닐까..? 🧐

GPT )

낙관적 업데이트가 필요한 이유는 대부분 서버 상태 갱신 과정에서의 딜레이 때문입니다.

setState로 낙관적 업데이트를 구현할 수도 있지만, 이는 클라이언트 상태를 관리하는 방식과 동일하게 동작하게 됩니다.

하지만 TanStack Query는 서버 상태 관리 라이브러리이므로, 클라이언트 상태와 서버 상태를 명확하게 구분하기 위해 useMutation을 제공합니다.

또한 useMutation은 단순히 상태를 변경하는 것을 넘어서, 낙관적 업데이트, 캐싱, 에러 핸들링, 롤백 기능까지 포함하여 서버 상태를 더욱 안정적으로 관리할 수 있도록 도와줍니다.

따라서, 서버 상태를 보다 효과적으로 관리하기 위해 setState 대신 useMutation을 사용하는 것이 더 적절합니다. ✅

→ 내가 적은 생각에 보완한 느낌이라 유사한 점이 많다. 캐싱과 에러 핸들링 부분을 추가로 말해주면서 보다 서버 / 클라이언트 상태 갱신을 분리한다는 점에 더해 편리함에 있어서도 이점을 가진다고 말해주고 있다.

Reference

https://tecoble.techcourse.co.kr/post/2023-08-15-how-to-improve-ux-with-optimistic-update/ https://tanstack.com/query/v4/docs/framework/react/guides/optimistic-updates https://tanstack.com/query/v4/docs/framework/react/reference/useMutation

두 가지 경험을 하면서 공통적으로 나왔던 용어가 있었는데 바로 Service Worker 다.

Service Worker라는 개념이 여러번 나오다보니 조금 더 알고 있으면 좋을 것 같아 정리하게 되었다.

먼저, 우리 어디서 봤더라..

먼저 MSW의 공식문서를 살펴 봤다. MSW의 철학에 대한 문서 중간에 아래 이미지에서 볼 수 있듯이, 브라우저 네트워크 수준에서 요청을 가로채기 위한 목적 때문에 Service Worker를 채택하여 사용한다.

다음은 PWA에 관한 MDN 문서인데, PWA에서는 캐싱을 활용해서 로딩 시간을 줄이기 위해 사용한다고 한다.

같은 도구를 활용했는데 서로 다른 목적을 가지고 있는 것을 알 수 있었고, 당연한 소리지만 Service Woker가 다양한 기능을 제공하는 것을 짐작할 수 있었다. ( 예리한 척. 🧐 )

Service Worker

Service Worker는 출처와 경로에 페이지를 제어하는 스크립트이며, 이벤트 기반의 워커로 JS 파일을 말한다.

연관된 웹 페이지/사이트를 통제해서 리소스 요청을 가로채 수신하여 수정할 수 있고, 다시 페이지로 돌려보낼 수 있습니다. 또한 서비스의 리소스를 세부적으로 캐싱할 수 있다.

그리고 브라우저와 별도의 Worker Context를 가지기 때문에 DOM에 접근할 수 없고, 웹/앱을 구동하는 JS 스레드와 다른 스레드에서 동작하기 때문에 웹/앱을 구동하는 JS 스레드 입장에서 연산을 가로막지 않는 (Non-blocking) 특징이 있다.

또한, 보안 상의 이유로 HTTPS에서만 동작한다. 네트워크를 가로채 수정한다는 점에서 중간자 공격에 취약할 수 있기 때문이다.

Service Worker 기본 흐름

1. 서비스 워커 로드 ( Download )

   브라우저가 웹 페이지를 열면 리소스(HTML, JS, CSS)를 로드되는데, 이때 JS를 통해서 ServiceWorker 파일가 로드 됩니다. 브라우저가 새로고침 되었을때, 변경 여부를 다시 확인하는데, 파일이 변경되었다면 다시 Service Worker를 다운로드 한다.

2. 설치(Install) / 캐싱 (Caching)

   다운로드 이후에 설치(Install) 이벤트가 발생한다. 이때 필요한 리소스를 캐싱한다. 해당 리소스들을 추후에 오프라인에서도 활용할 수 있다.

3. 활성화 (Activate)

   설치가 완료된 이후 활성화(Activate) 이벤트가 발생하고, Service Worker가 활성화된다. 이때 오래된 캐시를 삭제하거나 앱 초기화 작업을 수행할 수 있다.

   이 시점 부터 Service Woker는 네트워크 요청을 가로챌 수 있다.

4. 가로채기 (Fetch)

   페이지 요청을 가로채서 Service Worker의 fetch 이벤트를 통해서 요청을 핸들링할 수 있다(Proxy). 캐싱된 값을 전달하거나, 네트워크로 보내거나, 응답을 임의로 설정할 수 있다.

위 과정들은 아래 MDN에서 제공하는 이미지를 통해 더 쉽게 이해할 수 있다..!

궁금한 점

1. 캐싱되는 장소는 어디인가?

Service Worker가 설치되는 시점에 초기 리소스를 캐싱하게 된다. 이 캐싱 데이터가 실제 저장된 위치는 어디일까?

추측컨데 Service Worker는 앞서 웹/앱과 다른 스레드에서 실행된다고 했다. 그렇다면 스레드 메모리 구조에서 Stack에 저장되는 게 아닐까하는 생각이 들었다.

→ 땡 ❌. 바보 같게도 오프라인에서도 유지되어야 하는데 스레드의 스택에 저장되면 브라우저 내 지속성을 유지하기 어렵다…

캐싱된 리소스들은 브라우저 내에 cache storage에 저장된다.

이전 프로젝트에서 PWA를 찍먹 했을 때 코드를 활용해서 실제 리소스가 캐싱된 위치를 찾아가보았다.

    self.addEventListener('install', function () {
      self.waitUntil(
        caches.open('v1').then((cache) => {
          return cache.addAll(['/index.html']);
        }),
      );
    });

service worker가 install 될때 /index.html을 캐싱하도록 지정해주었고, 브라우저 개발자 도구에서 Application > Cache Strage 내에 지정한대로 캐싱이 이루어지고 있는 것을 확인할 수 있었다.

추가) Service Worker 확인하기

• chrome://serviceworker-internals/ 접속

로컬에 연결된 모든 서비스 워커를 확인할 수 있다.

• 개발자 도구 활용 브라우저의 개발자 도구에서 Application > Service workers 탭에서 현재 도메인에 설치된 Service Worker에 대한 정보를 확인할 수 있다.

  

2. JS Proxy API vs Service Worker

지금까지 알아봤던 Service Worker는 Proxy의 역할을 가지고 있다. 단순히 요청을 가로채서 원하는 값만 주는 것을 원하면 JS Proxy API와 같이 다른 방식도 있을 텐데 굳이 Service Worker를 사용한 이유에 대해서도 생각해 보았다.

우선 JS Proxy API는 객체 대한 작업을 가로채서 재정의 할 수 있게 해준다. 만약 JS Proxy API로 Mocking하는 API를 만든다면 아래와 같이 만들 수도 있다. ( Thanks to GPT… )

import axios from 'axios';

// Axios 인스턴스 생성
const apiClient = axios.create({
    baseURL: 'https://api.example.com',
    timeout: 5000,
});

// Proxy를 활용해 요청을 가로채기
const proxiedApiClient = new Proxy(apiClient, {
    get(target, propKey) {
    // propKey: 'get', 'post' 등 Axios의 HTTP 메서드

    // 원래 메서드 가져오기 (예: axios.get)
    const originalMethod = target[propKey];

    // 요청 가로채기
    return async (...args) => {
         const [url] = args;

        // 특정 엔드포인트 모킹
        if (url.includes('/mock-endpoint')) {
          console.log('Mocking response for:', url);

          return Promise.resolve({
            data: { mock: 'This is mock data!' },
            status: 200,
          });
        }

        // 나머지는 실제 네트워크 요청
        return originalMethod.apply(target, args);
      };
    },
  });

단순히 코드와 API 모킹에 대한 봤을 때는 가능한 이야기지만 JS Proxy의 경우 단순히 코드 레벨에서 기존 메서드의 동작과 다르게 동작 시키는 것이었고, Service Worker를 사용한다면 실제 브라우저에서 보낸 네트워크 요청을 가로채서 API 모킹을 하게 된다.

Service Worer를 사용하는 것이 보다 백엔드 서버에 요청 / 응답을 보내는 실제 동작에 더 유사한 가로채기? 방식이기 때문에 내가 비교했던 Proxy보다 Service Worker를 활용하는 쪽이 더 적합한 방식이다.

끝내며…

PWA의 오프라인 환경에서의 앱 실행과 MSW의 Mocking 전략에 대해서 이해할 수 있었다. 결국 두 방식 모두 요청을 주고 받을 대상이 없는 상태에서 Service Worker를 통해서 마치 실제 앱이 네트워크를 통해 데이터를 요청/응답하는 것 처럼 보이게 하기 위해서 Service Worker를 활용하는 것이다.

이번에 Service Worker가 무엇인지, 어떤 흐름을 통해서 동작하는지를 보다 잘 알게 된 것 같다. 동시에 내 프로젝트에 만들어뒀던 service worker 파일이 얼마나 엉망인지도 알게 되었다… ㅎ…

해당 글과는 살짝 관계 없는 내용이지만,

매번 새로운 개념을 공부하면서 수동적으로 인터넷에 있는 글들을 받아들이지 않기 위해서, 내가 기존에 알고있는 개념을 비교해보거나, 왜?라는 질문을 달기 위해서 노력하려고 한다.

하지만 고민해서 낸 질문에 비해서 생각보다 어렵지 않게 질문에 대한 답을 찾는 것 같아서 뭔가 생각하는 방향이 잘못된건지, 억지로 질문을 짜내려고해서 그런건지, 문득 잘못 공부하고 있나? 하는 생각이 들었다.

다른 개발자 분들은 블로그나 GPT를 통한 정보를 어떻게 비판적으로 수용하는지 궁금해졌다.

Reference

https://developer.mozilla.org/ko/docs/Web/API/Service_Worker_API

https://fe-developers.kakaoent.com/2022/221208-service-worker/

간단한 구현이라고 생각했는데 그 과정에서 알게된 부분들이 몇가지 있어 구현 과정을 정리해보았다.

ref 여러개 관리하기

위 이미지 처럼 소개 페이지 내부 영역이 여러 개이고 각 컴포넌트의 DOM 객체를 모두 관리해야하는데, 여러 DOM 객체를 배열로 관리해도 되는지에 대해서 헷갈리는 부분이 있었다. useRef내에서 배열로 관리할지, 아니면 useRef를 N 개 만큼 생성해서 관리할지 고민을 했었다.

우선 소개 영역이 거의 변하진 않겠지만 가능하다면 수정 가능성을 열어두고 개발한다면 임의로 N개의 useRef를 직접 만드는 것은 적절하지 않다고 판단했고, useRef 내부에서 배열로 관리하는 방향으로 방법을 찾아보았다.

그래서 ref 타입을

const refs = useRef<(HTMLDivElement | null)[]>([]);

로 선언해서 활용했다. 이렇게 활용하면 index를 통해 각 DOM 객체에 직접 접근할 수 있다.

이제 ref 내 요소를 넣는 방식이 떠오르지 않았는데 기존에 ref에 DOM 객체를 할당하는 방식은

...
<div ref={ref}> ... </div>
...

위 코드처럼 ref 객체를 props로 넘겨주는 방식이었는데 기본적인 사용 방식을 기반으로

...
{
    someArray.map((_, index) => {
        return <div key={index} ref={refs[index]}> ... </div>;
    })
}
...

작성해보았는데 refs가 가지고 있는 값이 배열이지 refs 자체는 배열이 아니기 때문에 index를 활용할 수 없었다.

...
{
    someArray.map((_, index) => {
        return <div key={index} ref={refs.current[index]}> ... </div>;
    })
}
...

이런 식으로도 해볼까 했지만 props 타입이 RefObject가 넘어가야하는데, HTMLElement 객체 값이 직접 넘어가기 때문에 이 방식도 적절하지 않다.

그래서 ref를 활용할때 ref 객체 대신 콜백 함수를 넘겨줄 수 있다는 점을 활용해서

...
{
    someArray.map((_, index) => {
        return <div 
            key={index}
            ref={ref={(element: HTMLDivElement) => {
          refs.current[index] = element;  // 각 요소를 배열의 해당 인덱스에 저장
        }}
            > ... </div>;
    })
}
...

이렇게 작성하면 된다고 한다.

일반적으로 ref를 props로 넘겨주는 방식은 내부적으로 React가 랜더링이 완료되고, DOM 요소를 생성한 직후에 해당 DOM 요소를 ref.current에 저장하는데, 콜백함수를 활용하게 되면 이 동작 자체를 직접 정의할 수 있다. 콜백 함수의 인자로 DOM 요소를 받게 되고, 마찬가지로 React가 랜더링이 완료되고, DOM 요소를 생성한 시점에 콜백 함수를 실행한다.

위 코드에서는 refs.current의 특정 위치(Index)에 DOM 정보를 저장하도록 하고 있다.

특정 DOM 위치로 스크롤 이동 시키기

이 부분에 대한 요구사항을 봤을 때 DOM 객체에 현재 페이지에 위치에 대한 정보나 스크롤에 대한 정보가 있어서 그걸 활용해야하나 추측했었다.

이부분은 생각보다 수월했던 것이 이런 요구사항을 위해 .scrollIntoView() 라는 내장 API를 활용하면 되는 것을 알았다.

 const moveContent = (index: number) => {
    if (contentRefs.current[index]) {
      contentRefs.current[index]?.scrollIntoView({
        behavior: 'smooth',
        block: 'center',
      });
    }
  };

그래서 아까 저장한 refs 내 DOM 정보에 .scrollIntoView() 를 적용시키고, .scrollIntoView() 의 인자로 스크롤 이동시 부드럽게 이동시키기 위해 behavior 속성과, DOM이 뷰포트 내 위치를 지정하기 위해 block 속성을 각각 지정해주었다.

React 19에서 ref를 props로 받기

프로젝트내 React 버전이 19 버전으로 되어있어 최근 정식으로 업그레이드 된 19버전에 따라 Ref를 props로 받는 방법이 달라졌다.

기존 18버전 까지는 React.fowardRef 를 활용해서 ref를 다른 props들과 구별하여 전달받아 활용했는데, 19버전으로 올라가면서 forwardRef를 사용하지 않고 다른 props와 동일하게 ref를 넘겨주도록 수정되었다.

그래서 컴포넌트 내에 props 타입을 정의할 때로 Ref를 포함하여 정의했다.

interface IntroBlockProps {
  title: string;
  describe: ReactNode;
  content: ReactNode;
  ref: Ref<HTMLDivElement | null>;
}

끝내며…

ref를 element 속성에 직접 넘겨주고 ref.current를 활용하는 단순하고 반복적으로 활용하다보니 더 디테일하게 사용하는 방식이나 ref에 언제 DOM 정보가 저장되는지에 대한 내부적인 구현까지 파악하지 못하고 있었던 것 같다. ref를 더 잘 사용할 수 있게 된 것 같다.

Reference

https://ko.react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback

https://developer.mozilla.org/ko/docs/Web/API/Element/scrollIntoView

앞서 시작한 프로젝트에서 icon을 관리하고 호출하는 방식을 이후 시작한 프로젝트에 적용해보면서 더 나은 방식이 있을 것이라는 생각이 들어 개선 과정을 정리하게 되었다.

이전 프로젝트에서는 어떻게 사용하고 있나.

우선 모든 svg 아이콘을 개별 컴포넌트( 또는 svg 파일 )로 관리하고 있다.

그리고 icon 컴포넌트 리스트를 통해 어떤 활용할 수 있는 이미지들을 관리하고, 활용하는 컴포넌트 또는 페이지에서 Icon 컴포넌트를 호출하고 컴포넌트 이름을 props로 넘겨주어, Icon 컴포넌트 내부에서 해당 Icon을 특정하여 활용하고 있다.

이 방식은 다른 프로젝트에서도 비슷하게 활용하고 있어 크게 어색한 방식이라는 생각이 들진 않았지만, 초기 세팅과정에 번거로움 있고, 아이콘을 등록하는 과정에서 2 ~ 3개의 파일을 거쳐야한다는 점이 불편하게 느껴졌다.

그래서 개선할 수 있는 방법을 찾다가 svg sprite이라는 기법을 발견하게 되었다.

svg sprite?

svg sprite은 여러 개의 svg 파일을 하나의 svg 파일로 합쳐서 관리하고 <use> 태그를 통해서 특정 아이콘만 활용하는 방식을 말한다.

svg sprite를 활용하면 우선 파일 크기를 줄일 수 있고, 기존의 각각 icon 파일을 요청하는 방식에 비해 1개의 파일만 요청하여 활용하기 때문에 네트워크 부하가 줄어들며, 뿐만 아니라 다운로드 받은 1개의 파일에 대해서 브라우저 캐싱이 가능하기 때문에 더 빠르게 로딩이 가능하다.

사용해보자

방법은 간단하다. 모든 svg 파일에 있는

그리고 이후 컴포넌트에서 사용할 아이콘을 지정하기 위해 각 symbol 태그의 id 속성에 icon의 이름을 지정해둔다.

svg-sprite 코드 설명

• <defs> 태그 : svg 내부에서 재사용할 요소들을 그룹화 하는 컨테이너 역할
• <symbol> 태그 : 재사용할 그래픽 요소 (svg Icon)를 구분/정의하는 역할, 이때 <symbol> 태그 내부에 있는 요소들은 랜더링 되지 않고, 이후 <use> 태그를 통해 사용해야 한다.

그 다음 svg-sprite 기법으로 만든 하나의 파일을 통해 icon을 랜더링할 Icon 컴포넌트를 만든다 ( React / Next.js 기준 )

interface IconProps {
  id: string;
  size?: 'md' | 'lg';
  className?: string;
}

const sizeValue = {
  md: 20,
  lg: 24,
};

const Icon = ({ id, size = 'lg', className }: IconProps) => {
  return (
    <svg
      width={sizeValue[size]}
      height={sizeValue[size]}
      className={className}
      fill='none'
    >
      <use href={`/images/svg-sprite.svg#${id}`} />
    </svg>
  );
};

export default Icon;

컴포넌트 내부에서 태그를 통해서 원하는 Icon 컴포넌트를 지정하여 랜더링 할 수 있다.

<use> 태그 내 href 속성에 {svg sprite 파일 경로 }#{ svg icon id } 값을 넘겨주어 Icon을 특정할 수 있다.

사용해보니…

일단 눈에 띄게 개선되었다라고 느껴진 부분은 프로젝트 폴더 내 icon 파일들이 사라졌다는 점과 새로운 아이콘을 등록할 때 svg-sprite.svg 파일만 수정하면 된다는 점이었다.

그리고 모든 icon을 프로젝트 디렉토리에서 관리하는 방식과 svg-sprite.svg 단일로 관리하는 방식의 물리적인 용량 차이를 비교해봤을 때도 생각보다 큰 차이가 느껴졌다.

초기 단계라 11개의 아이콘만 관리하고 있음에도, 8KB → 2KB로 6KB( 약 75% ) 정도 용량 차이가 있었다. 더 많은 파일을 관리하게 되면 그만큼 더 큰 개선이 이루어질 것이라고 생각되어 개선 방향이 긍정적이지 않았나 하는 생각이 들었다.

svg-sprite는 무적?

모든 기술에는 장단점이 있듯 svg-sprite를 활용하는 것에도 한계가 있을 수 있다.

먼저, svg-sprite는 모든 아이콘을 불러온다.

앞서 모든 Icon을 개별 파일로 저장하는 경우, 총 용량이 더 클 수는 있지만 Icon을 활용할 떄 마다 불러오기 때문에 Icon 활용을 적게 하는 경우에서는 svg-sprite를 활용하는 것이 더 많은 리소스를 사용하게 될 수 도 있다.

오히려 복잡한 관리 방식

svg-sprite 방식을 활용하면 단일 파일로 모든 이미지 정보를 관리하고, svg 파일 내부 코드들은 벡터 기반 그래픽들의 정보들이라 읽기가 힘들어 많은 아이콘들을 관리하게 되면 그만큼 파일 내부가 복잡해지기 때문에 오히려 여러 개의 파일로 관리하는 것보다 관리가 어려울 수 있다.

이외에도 여러 단점이 있을 수 있지만, 현재 진행하고 있는 우리 프로젝트에서는 svg-sprite를 활용하는 것이 더 나은 선택이라고 생각했다.

사이드 프로젝트 규모에서 활용하는 Icon 개수가 그렇게 많지 않고, MVP 기준으로 최소 기능을 구현하기 때문에 대부분의 Icon을 활용하게 되어 적은 용량으로 관리하는 것이 더 나은 방식인 것 같다.

아마 규모가 더 커지거나, 이후 실무에서 이런 방식을 적용하는 경우에는 부분적으로 주요한 비즈니스 로직에 있는 icon 들만 최적화 한다거나, 트래픽을 통해 자주 방문하는 페이지의 icon들에 대해서만 svg-sprite를 활용한다면 svg-sprite의 장점을 더욱 극대화 시킬 수 있지 않을까 생각한다.

Reference

https://velog.io/@sasha1107/SVG-스프라이트-기법으로-사이트-성능-향상시키기리액트에서-스프라이트-SVG-사용하기

https://velog.io/@sumi-0011/react-icon-manage

https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use

https://developer.mozilla.org/en-US/docs/Web/SVG/Element/symbol

// EmailInput.tsx

const EmailInput = ({ mode }: EmailInputProps) => {
  const [validationMessage, setValidationMessage] = useState('');
  const [validationMessageColor, setValidationMessageColor] = useState('');
  const {
    register,
    resetField,
    watch,
    formState: { errors },
  } = useFormContext();

  const email = watch('email');

  const { isValid, message, isLoading } = useGetValidateEmail(email, mode);

  const isEmailInvalid = () => !EMAIL_REGEX.test(email);

  const clearEmailField = () => resetField('email');

  const validateEmail = () => {
    if (isLoading) {
      setValidationMessage('이메일 검증 중...');
      setValidationMessageColor('text-gray-400');
    } else if (!isValid) {
      setValidationMessage(message || '이미 가입된 이메일입니다.');
      setValidationMessageColor('text-system-error');
    } else {
      setValidationMessage('가입되어 있지 않은 이메일입니다.');
      setValidationMessageColor('text-system-error');
    }
  };

  useEffect(() => {
    if (mode !== 'sign-up') return;

    if (email === '') {
      setValidationMessage('');
      setValidationMessageColor('');
    } else if (isEmailInvalid()) {
      setValidationMessage('올바른 이메일 형식으로 입력해주세요.');
      setValidationMessageColor('text-system-error');
    } else if (email) {
      validateEmail();
    } else {
      setValidationMessage('');
    }
  }, [email]);

  useEffect(() => {
    if (errors.email) {
      setValidationMessage(errors.email?.message as string);
      setValidationMessageColor('text-system-error');
    }
  }, [errors]);

  return (
    <div>
      <Input
        {...register('email', { required: true, pattern: EMAIL_REGEX })}
        type='email'
        label='이메일'
        labelPlacement='outside'
        placeholder='이메일을 입력해주세요.'
        isInvalid={false}
        classNames={{
          label: 'custom-label text-gray-400',
          input: 'placeholder:text-gray-700',
          inputWrapper: ['bg-gray-900', 'rounded-md'],
        }}
        onClear={clearEmailField}
      />
        ...
    </div>
  );
};

export default EmailInput;

처음 작성했던 이메일 Input 컴포넌트인데 보기에도 상당히 복잡해보인다. 폼 자체에 대해서는 폼을 관리하는 페이지에서 React Hook Form을 통해서 폼 데이터를 효율적으로 관리하고 있지만, 각 필드에서 유효성 검사, 에러 메세지 같이 생각보다 많은 상태들을 관리하고 있다.

그리고 이메일 입력값에 대한 유효성 검증 로직이 복잡하게 얽혀있는데, 필드 내부에 입력 컴포넌트가 사용되는 폼을 직접 관리하기 때문에 상당히 복잡한 것을 볼 수 있다.

그래서 이번 리팩토링의 목적을

1. 각 필드 내 사용되는 상태 줄이기
2. 입력 값에 대한 유효성 검증 로직 개선하기

로 잡고 리팩토링을 수행했다.

상태 줄이기

우선 기존 컴포넌트 내부에서는 에러 메세지와 검증 결과를 표시할 문자의 색상 값을 상태로 관리하고 있었다. 이 상태들은 상태 갱신이 되는 시점이 동일하기 때문에 굳이 별개의 useState로 정의할 필요가 없다고 생각해서 객체 상태로 정의하여 한번에 관리하였다.

그리고 기존에 두 개의 유효성 검증 조건 문은 로그인/ 회원가입에 활용될 수 있게 조건의 순서를 조절하여 하나의 조건문으로 검증 가능하도록 수정하였다.

const NicknameInput = () => {
  const [validateStatus, setValidateStatus] = useState({
    type: '',
    message: '',
    messageColor: '',
  });

  const { register, watch } = useFormContext();

  const nickname = watch('nickname');

  const { isValid, message, isLoading } = useGetValidateNickName(nickname);

  const isNicknameInvalid =
    (nickname !== '' && !NICKNAME_REGEX.test(nickname)) ||
    nickname.length > MAX_NICKNAME_LENGTH;

  const validateNickname = () => {
    if (nickname === '') {
      return { type: '', message: '', messageColor: '' };
    }

    if (isNicknameInvalid) {
      return {
        type: 'error',
        message: '사용할 수 없는 문자 또는 길이를 초과했습니다.',
        messageColor: 'text-system-error',
      };
    }

    if (isLoading) {
      return {
        type: 'loading',
        message: '닉네임 검증 중...',
        messageColor: 'text-gray-400',
      };
    }

    if (!isValid) {
      return {
        type: 'error',
        message: message || '중복된 닉네임이 존재합니다.',
        messageColor: 'text-system-error',
      };
    }

    return {
      type: 'success',
      message: '사용 가능한 닉네임입니다.',
      messageColor: 'text-system-success',
    };
  };

  useEffect(() => {
    const nicknameValidateResult = validateNickname();

    setValidateStatus(nicknameValidateResult);
  }, [nickname, isLoading, isValid, message]);

  const currentNicknameLength = nickname.length;
  const nicknameLengthColor =
    nickname.length === 0
      ? 'text-gray-700'
      : currentNicknameLength > MAX_NICKNAME_LENGTH
        ? 'text-system-error'
        : 'text-white';

  return (
    <div>
      ...
    </div>
  );
};

export default NicknameInput;

하지만 여전히 효과적으로 리팩토링을 했다는 생각이 들지 않았다.

우선 먼저 react hook form을 사용하면서 제출 버튼이 폼의 유효성 검증이 통과하는 경우에 활성화되도록 되어있는데, 이때 각 필드의 유효성 검증은 Input 태그 내에서 포함된 register의 속성에 정의되어있어야 한다. 그래서 어색하게 동일한 유효성 검증이 에러 메세지를 위해서, 폼 제출 여부 판단을 위해서 두 번 쓰이고 있다.

이를 개선 하기 위해 아래와 같은 두번의 시행 착오를 거쳤다.

1. 모든 유효성 검증을 register 속성 내부로 이전

    <Input
      {...register('nickname', {
        required: '닉네임이 입력되지 않았습니다.',
        max: {
          value: 10,
          message: '최대 닉네임 길이를 초과했습니다.',
        },
        pattern: {
          value: NICKNAME_REGEX,
          message: '닉네임에 허용되지 않는 문자가 포함되어 있습니다.',
        },
        validate: {
          duplicatedNickname: async (nickname) => {
            const isDuplicated = await getValidateNickname(nickname);
            return isDuplicated && '이미 사용 중인 닉네임입니다.';
          },
        },
      })}
      type='text'
      label='닉네임'
      labelPlacement='outside'
      placeholder='닉네임을 입력해주세요.'
      maxLength={MAX_NICKNAME_LENGTH}
      classNames={{
        label: 'custom-label',
        input: 'placeholder:text-gray-700',
        inputWrapper: ['bg-gray-900', 'rounded-md'],
      }}
      endContent={
        <div className='flex items-center'>
          <span className={`placeholder ${nicknameLengthColor}`}>
            {currentNicknameLength}
          </span>
          <span className='placeholder text-gray-700'>
            /{MAX_NICKNAME_LENGTH}
          </span>
        </div>
      }
    />

   → 하지만 이렇게 작성하는 경우 로그인 폼 / 회원 가입 폼에 필요한 검증 방식이 다른데 폼 종류에 관계없이 모두 같은 로직을 사용해야하기 때문에 해당 방식을 활용할 수 없었다.

2. 모든 유효성 검증을 외부 로직으로 분리

   반대로 외부로직으로 모든 유효성 검증 로직을 분리하고, 대신 폼과 유효성 결과를 동기화 시키기 위해 React Hook Form에서 제공하는 setError, formState를 활용하여 기존 setState를 대신하는 방식을 사용해보았다.

   → 수정이 필요했던 부분들을 모두 반영할 수 있었지만, React Hook Form에서 다시 유효성 검증 로직을 실행하기 이전에 Error 객체를 초기화하기 때문에 입력 필드의 onChange 이벤트가 발생할 때 마다 메세지가 사라졌다가, 다시 새로운 메세지가 나와 메세지가 깜빡깜빡 거리는 현상이 생겼다.

그래서 현재 단계에서 보완이 필요한 점은

1. React Hook Form의 폼에서 관리하는 유효성 로직을 현재 각 필드의 에러 메세지 UI와 동기화 되어야함
2. 현재 필드를 사용하려고하는 폼에 따라 서로다른 유효성 검증 로직이 적용되어야함.

이 두가지를 목표로 다른 방식을 찾아보면서 zod라는 라이브러리를 React Hook Form에서 활용할 수 있다는 것을 알게 되었다.

Zod

Zod는 ‘스키마’라는 개념을 통해서 객체 정의가 가능하고, 동시에 객체에 대한 유효성 검사도 가능하게 하는 라이브러리이다.

import { z } from "zod";

// 스키마 선언
const userSchema = z.object({
  name: z.string(),
  age: z.number(),
  email: z.string().email(),
});

// 타입 추출
type UserType = z.infer<typeof userSchema>;

React Hook Form에서는 useForm을 선언할 때, resolver라는 옵션을 사용할 수 있는데, 이 옵션을 사용하면 각 필드에서 작성했던 유효성 검사를 중앙에서 관리할 수 있게 해준다. resolver의 옵션으로 zodResolver라는 함수와 함께 zod로 선언한 객체의 스키마를 넘겨주면 객체 정의에 따라 유효성 검사가 가능해진다.

Zod로 유효성 검사 로직 분리하기

회원 가입 폼에 대한 스키마를 다음과 같이 정의하여 활용하였다.

const signUpValidationSchema = object({
  email: string()
    .min(1, '이메일은 필수입니다.')
    .email('유효하지 않은 이메일 형식입니다.')
    .refine(async (email) => {
      const isDuplicated = await getValidateEmail(email);
      return isDuplicated;
    }, '이미 가입된 이메일입니다.'),
  password: string()
    .min(1, '비밀번호는 필수입니다.')
    .regex(
      PASSWORD_REGEX,
      '영문, 숫자, 특수문자를 포함해 9자 이상 입력해주세요.',
    ),
  nickname: string()
    .min(1, '닉네임은 필수입니다.')
    .max(MAX_NICKNAME_LENGTH, '최대 닉네임 길이를 초과했습니다.')
    .regex(NICKNAME_REGEX, '한글, 영어, 숫자로 구성된 닉네임을 입력해주세요.')
    .refine(async (nickname) => {
      const isDuplicated = await getValidateNickname(nickname);
      return isDuplicated;
    }, '이미 사용중인 닉네임입니다.'),
});

그리고 스키마로 인해서 자연스럽게 각 필드에 있던 유효성 로직이 필요없어졌기 때문에 관련 코드를 이전보다 깔끔하게 정리할 수 있었다.

const EmailInput = ({ mode }: EmailInputProps) => {
  const [isEmailValidating, setIsEmailValidating] = useState(false);

  const {
    register,
    resetField,
    watch,
    setValue,
    trigger,
    formState: { errors },
  } = useFormContext();

  const email = watch('email');

  const clearEmailField = () => resetField('email');

  return (
    <div>
      <Input
        {...register('email')}
        type='email'
        label='이메일'
        labelPlacement='outside'
        placeholder='이메일을 입력해주세요.'
        isInvalid={false}
        classNames={{
          label: 'custom-label',
          input: 'placeholder:text-gray-700',
          inputWrapper: ['bg-gray-900', 'rounded-md'],
        }}
        onClear={clearEmailField}
      />

      ...
        </div>
  );
};

export default EmailInput;

추가 개선 사항

1. .superRefine()으로 유효성 검사 커스텀 하기

   비동기 검증 로직을 활용하면서 true/false를 반환하여 현재 이메일을 사용할 수 있는지, 사용할 수 없는지만 검증하였지만, 내부적으로 정확히 어떤 이유에서 이메일을 사용할 수 없는지 에러 메세지를 통해 전달할 필요가 있었다.

   기존의 .refine()은 내부 콜백함수가 true/false를 반환해서 검증 여부만 판단하기 때문에 각 에러 케이스에 따른 에러 메세지를 설정하기 어렵다고 판단했다.

   그래서 .refine의 고급 커스텀이 가능한 .superRefine()을 활용하여 아래와 같이 경우에 따른 적절한 에러 메세지를 전달할 수 있도록 개선했다.

    const signUpValidationSchema = object({
      email: string()
        ...
        .superRefine(async (email, ctx) => {
          const status = await getValidateEmail(email);
   
          if (status === 400) {
            ctx.addIssue({
              code: ZodIssueCode.custom,
              message: SIGNIN_ERROR_MESSAGE.INVALID_EMAIL,
            });
          }
   
          if (status === 409) {
            ctx.addIssue({
              code: ZodIssueCode.custom,
              message: SIGNIN_ERROR_MESSAGE.DUPLICATE_EMAIL,
            });
          }
        }),
      ...
      nickname: string()
          ...
        .superRefine(async (nickname, ctx) => {
          const status = await getValidateNickname(nickname);
   
          if (status === 400) {
            ctx.addIssue({
              code: ZodIssueCode.custom,
              message: NICKNAME_VALIDATE_ERROR_MESSAGE.INVALID_NICKNAME,
            });
          }
   
          if (status === 409) {
            ctx.addIssue({
              code: ZodIssueCode.custom,
              message: NICKNAME_VALIDATE_ERROR_MESSAGE.DUPLICATE_NICKNAME,
            });
          }
        }),
    });

2. debounce 적용하기

   이전에 onChange마다 유효성 검사가 실행되기 때문에 에러 메세지가 깜빡거리는 현상이 있었다.

   이 부분이 상당히 사용자 입장에서 좋아보이는 UI가 아니기도 했고, 유효성 검증 로직 중에 현재 입력 값이 이미 가입된 이메일인지 확인하는 요청을 보내야하는데 이것이 입력될 때 마다 요청을 주고 받는 부분에 대해서 최적화의 필요성을 느꼈다.

   lodash의 debounce를 통해서 onChange 이벤트가 끝난 시점에서 특정 시간동안 입력이 없으면 검증 로직이 실행될 수 있도록 최적화 하였다.

    import { debounce } from 'lodash';
   
    ...
   
    const handleEmailInputOnChange = debounce(async (e) => {
        setValue('email', e.target.value);
   
        setIsEmailValidating(true);
        await trigger('email');
        setIsEmailValidating(false);
      }, 300);

리팩토링 후기

누군가 zod 꼭 쓰세요 라고 했던 걸 본적이 있었는데 이번 기회에 zod를 사용해보게 되어서 상당히 의미있는 시간이었던 것 같다. 그리고 React Hook Form을 사용해서 필요한 상태를 줄일 수 있다는 점에 대해서는 상당히 공감하며 사용하고 있었지만 그 외 제공해주는 다양한 기능들에 대해서는 잘 몰랐었다.

이번 기회에 공식 문서도 조금 더 파볼 수 있었고, form 데이터 관리를 좀 더 체계적으로 해볼 수 있는 경험이었던 것 같다.

RC? Release Candidate의 약자로, 소프트웨어 개발 주기에서 최종 출시 전에 공개되는 버전을 말한다. 안정성과 기능이 최종 버전에 가깝지만 사용자로부터 피드백을 받고 버그를 수정할 가능성이 있는 상태를 의미한다.

React 19의 새로운 기능

Actions

React App들의 일반적인 사용 케이스는 데이터를 변형하고 그 응답에 따라 상태를 업데이트하는 것입니다. 예를 들어, 사용자가 이름을 변경하여 폼을 제출할 때, API 요청을 생성한 다음, 응답을 처리합니다. 과거에는 Pending 상태, 에러, 낙관적 업데이트, 그리고 순차적인 요청을 수동적으로 처리해야 했습니다.

예를 useState를 통해 Pending과 Error 상태를 다룰 수 있었습니다.

// Before Actions
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, setIsPending] = useState(false);

  const handleSubmit = async () => {
    setIsPending(true);
    const error = await updateName(name);
    setIsPending(false);
    if (error) {
      setError(error);
      return;
    } 
    redirect("/path");
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

React 19에서는 Pending 상태, Error, 폼, 낙관적 업데이트를 자동으로 처리하기 위해 transition에서 비동기 함수를 통해 지원하는 방식을 추가하였습니다.

예를 들어, pending state를 다루기 위해 useTransition 훅을 아래와 같이 사용할 수 있습니다.

// Using pending state from Actions
function UpdateName({}) {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  const handleSubmit = () => {
    startTransition(async () => {
      const error = await updateName(name);
      if (error) {
        setError(error);
        return;
      } 
      redirect("/path");
    })
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}

비동기 트랜지선은 isPending상태를 즉시 true로 바꾸고, 트랜지션이 끝난 후에 비동기 요청를 만들고, isPending을 False로 바꿉니다. 이것을 통해서 데이터가 바뀌는 동안 현재 UI를 반응성있고, 상호작용적으로 유지할 수 있습니다.

Actions를 기반으로, React 19에서는 낙관적 업데이트를 관리하는 useOptimistic 과 Actions의 일반적인 케이스를 다루는 React.useActionState 라는 새로운 훅을 소개합니다.

react-dom 에서는 form을 자동으로 관리하는 <form>Actions와 form에서의 Actions의 일반적인 케이스를 지원하는 useFormStatus를 추가했습니다.

React 19에서는 위 예시를 다음과 같이 단순화 할 수 있습니다.

 // Using <form> Actions and useActionState
  function ChangeName({ name, setName }) {
    const [error, submitAction, isPending] = useActionState(
      async (previousState, formData) => {
        const error = await updateName(formData.get("name"));
        if (error) {
          return error;
        }
        redirect("/path");
        return null;
      },
      null,
    );

    return (
      <form action={submitAction}>
        <input type="text" name="name" />
        <button type="submit" disabled={isPending}>Update</button>
        {error && <p>{error}</p>}
      </form>
    );
  }

다음 섹션에서는 React 19의 새로운 Action의 기능들을 하나씩 알아봅니다.

새 훅 : useActionState

Actions의 일반적인 케이스를 쉽게 하기 위해 useActionState라고 불리는 새로운 훅을 추가하였습니다.

const [error, submitAction, isPending] = useActionState(
  async (previousState, newName) => {
    const error = await updateName(newName);
    if (error) {
      // You can return any result of the action.
      // Here, we return only the error.
      return error;
    }

    // handle success
    return null;
  },
  null,
);

useActionState는 함수를 받아서, 호출할 wrapping된 Action을 반환합니다. Actions가 구성되기 때문에 이것은 동작합니다. 래핑된 Action이 호출될 때, useActionState는 Action의 마지막 결과를 data 로 반환하고 Actions의 pending 상태를 pending으로 반환합니다.

더 많은 정보를 알고 싶으면 useActionState의 문서를 확인하세요.

React DOM : <form> Actions

Actions는 또한 React 19에서 <form>의 새로운 기능과도 통합되었습니다. Actions을 통해 자동으로 폼을 제출하기 위해 <form>, <input>, <button> 엘리먼트의 formAction props로 함수를 전달하는 기능을 추가했습니다.

<form action={actionFunction} />

<form> 액션이 성공되었을 때, 리액트는 제어되지 않은 컴포넌트에 대해서 폼을 초기화 하게 됩니다. 만약 <form>의 초기화를 수동으로 해야한다면 새로운 React DOM API의 requestFormReset을호출할 수 있습니다.

더 자세한 내용은 react-dom의 <form>, <input>, <button> 문서를 참조하세요.

React Dom : 새 훅: useFormStatus

디자인 시스템에서, 컴포넌트까지 props를 drilling하지 않고, 컴포넌트에 대한 정보에 접근하는 디자인 컴포넌트를 만드는 것이 일반적입니다. 이것을 Context를 통해서 가능하지만 더 쉽게 만들기 위해서 useFormStatus라는 새로운 훅을 추가하였습니다.

import {useFormStatus} from 'react-dom';

function DesignButton() {
  const {pending} = useFormStatus();
  return <button type="submit" disabled={pending} />
}

useFormStatus는

이 Context Provider 인 것 처럼, 부모의 상태를 읽을 수 있게 해줍니다.

자세한 내용은 react-dom 의 useFormStatus문서를 참조하세요 .

새 훅 : useOptimistic

데이터 변형(Mutation)을 수행할때 또 다른 일반적인 패턴은 비동기 요청이 수행되는 동안에 낙관적으로 최종 상태를 보여주는 것입니다. React 19에서는 useOptimistic이라고 불리는 새로운 훅을 호출하여 더욱 쉽게 했습니다.

function ChangeName({currentName, onUpdateName}) {
  const [optimisticName, setOptimisticName] = useOptimistic(currentName);

  const submitAction = async formData => {
    const newName = formData.get("name");
    setOptimisticName(newName);
    const updatedName = await updateName(newName);
    onUpdateName(updatedName);
  };

  return (
    <form action={submitAction}>
      <p>Your name is: {optimisticName}</p>
      <p>
        <label>Change Name:</label>
        <input
          type="text"
          name="name"
          disabled={currentName !== optimisticName}
        />
      </p>
    </form>
  );
}

updateName 요청이 진행되는 동안에, useOptimistic 훅은 즉시 optimisticName을 랜더할 것입니다. 업데이트가 완료 되거나, 에러가 발생하면 리액트는 자동으로 currentName 값으로 바꾸게 됩니다.

자세한 내용은 useOptimistic 문서를 참조하세요.

새 API : use

React 19에서 render 에서 리소스를 읽는 새로운 API인 use를 소개합니다.

예를 들어 use를 통해 promise를 읽을 수 있고, 그 동안 React는 promise가 완료될 때 까지 중단합니다.

import {use} from 'react';

function Comments({commentsPromise}) {
  // `use` will suspend until the promise resolves.
  const comments = use(commentsPromise);
  return comments.map(comment => <p key={comment.id}>{comment}</p>);
}

function Page({commentsPromise}) {
  // When `use` suspends in Comments,
  // this Suspense boundary will be shown.
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Comments commentsPromise={commentsPromise} />
    </Suspense>
  )
}

use 를 활용하여 Context를 읽을 수 있으며, early return 후와 같이 context를 조건부로 읽을 수 있습니다.

import {use} from 'react';
import ThemeContext from './ThemeContext'

function Heading({children}) {
  if (children == null) {
    return null;
  }

  // This would not work with useContext
  // because of the early return.
  const theme = use(ThemeContext);
  return (
    <h1 style={{color: theme.color}}>
      {children}
    </h1>
  );
}

use API는 훅과 비슷하게 render 에서 부를 수 있습니다. 훅과는 다르게 use API는 조건부로 호출이 가능합니다. 미래에는 use 를 활용하여 리소스를 활용하는 더 많은 방식을 지원할 계획에 있습니다.

자세한 내용은 use 문서를 참조하세요.

React Server Component

Server Component

서버 컴포넌트는 번들링하기 이전에 클라이언트 애플리케이션이나 SSR 서버와 별도의 환경에서 구성 요소를 미리 랜더링할 수 있는 방식이다. 이 분리된 환경은 “React Server Component”의 ‘서버’입니다. 서버 컴포넌트는 CI 서버에서 빌드 시간에 한 번 실행되거나 웹 서버를 사용해서 각 요청에 대해 실행될 수 있습니다.

React 19에는 Canary 채널에서 포함된 모든 React Server Component의 기능이 포함되어 있습니다. 즉, Server Component와 함께 제공되는 라이브러리는 이제 Full-Stack React Architecture를 지원하기위한 프레임워크를 사용할 때 React 19를 react-server export 조건과 함께 피어 종속성으로 타겟으로 할 수 있습니다.

자세한 내용은 React Server Components 문서를 참조하세요.

Server Actions

Server Actions는 클라이언트 컴ㅍ노너트가 서버에서 실행되는 비동기 함수를 호출할 수 있게 해줍니다.

Server Actions가 use server 로 직접 정의되어 있을 때, 당신의 프레임워키에서는 자동으로 서버 함수의 참조를 생성하고 클라이언트 컴포넌트에게 참조를 전달합니다. 함수가 클라이언트에서 호출되었을 때, React는 함수를 실행하고 결과를 반환하기 위해서 서버에 요청을 보냅니다.

서버 액션은 서버 컴포넌트에서 생성되어 클라이언트 컴포넌트에 Props로 전달될 수 도 있고, 클라이언트 컴포넌트에서 import해서 사용할 수 도 있습니다.

자세한 내용은 React Server Actions 문서를 참조하세요.

React 19의 개선 사항

prop으로서 ref

React 19를 시작하면서 함수형 컴포넌트에서 prop으로 ref에 접근할 수 있습니다.

function MyInput({placeholder, ref}) {
  return <input placeholder={placeholder} ref={ref} />
}

//...
<MyInput ref={ref} />

새로운 함수형 컴포넌트는 더이상 forwardRef가 필요하지 않습니다. 그리고 새로운 ref prop을 사용하여 자동으로 당신의 컴포넌트를 업데이트하는 codemod도 배포할 예정힙니다. 미래의 버전에서는 forwardRef를 deprecate하고 삭제할 예정입니다.

Diff for hydration errors

우리는 또한 react-dom에서 hrdration error를 보고하는 에러 보고를 개선하였습니다. 예를 들어 DEV에서 불일치에 대한 어떠한 정보도 없이 기록하는 대신

이제 불일치의 diff에 대한 메세지를 포함하여 기록합니다.

as Provider

React 19에서 Context.Provider 대신 를 Provider로 활용할 수 있습니다.

const ThemeContext = createContext('');

function App({children}) {
  return (
    <ThemeContext value="dark">
      {children}
    </ThemeContext>
  );  
}

새로운 Context Provider는 <Context> 를 활용할 수 있으며, 기존 Provider를 변환하기 위한 codemod를 게시할 예정입니다. 향후 버전에서는 <Context.Provider>을 사용하지 않을 예정입니다.

Cleanup functions for refs

이제 ref의 콜백에서 정리 함수를 반환하는 기능을 지원합니다.

<input
  ref={(ref) => {
    // ref created

    // NEW: return a cleanup function to reset
    // the ref when element is removed from DOM.
    return () => {
      // ref cleanup
    };
  }}
/>

컴포넌트가 언마운트 되었을 때, 리액트는 ref 콜백함수로부터 반환되는 cleanup 함수를 호출합니다. 이것은 DOM refs, 클래스 컴포넌트의 refs, useImperativeHandle에 유효합니다.

ref 정리함수가 도입되었기 때문에 ref 콜백함수에서 다른 것을 반환하는 것은 이제 TS에서 거부됩니다. 아래와 같이 return을 사용하지 않음으로서 문제를 해결할 수 있습니다.

- <div ref={current => (instance = current)} />
+ <div ref={current => {instance = current}} />

원래 코드는 HTMLDivElement의 인스턴스를 반환했고, TypeScript는 이것이 cleanup 함수인지 cleanup 함수를 반환하고 싶지 않아하는지 알 수 없었습니다.

당신은 no-implicit-ref-callback-return 을 통해서 해당 패턴을 codemod 할 수 있습니다.

useDeferredValue inital Value

우리는 useDeferredValue 에 initial Option을 추가하였습니다.

function Search({deferredValue}) {
  // On initial render the value is ''.
  // Then a re-render is scheduled with the deferredValue.
  const value = useDeferredValue(deferredValue, '');

  return (
    <Results query={value} />
  );
}

initialValue가 제공되면, useDeferedValue는 이것을 컴포넌트의 초기 랜더 값으로서 반환합니다. 그리고 반환되는 defferedValue와 함께 백그라운드에서 리랜더를 예약합니다.

더 많은 내용은 useDefferedValue 를 참조하세요.

Support for Document Metadata

HTML에서 https://velog.io/@tkddn_dev8430/Warning-Received-false-for-a-non-boolean-attribute-mode https://velog.io/@tkddn_dev8430/Warning-Received-false-for-a-non-boolean-attribute-mode Thu, 31 Oct 2024 10:00:14 GMT

오래된 사이드 프로젝트 에러들을 잡는 과정에서 다음과 같은 경고 문구가 나왔다.

찾아보니 styled-component를 위해 넘겨준 props가 걸러지지 않고 DOM Element의 attribute에 넘겨졌고, DOM Element에서는 props에 해당하는 attribute가 존재하지 않기 때문에 발생하는 문제였다.

공식문서를 참조하여 문제를 해결할 수 있었다. 현재 프로젝트에서 사용하는 styled-component 버전이 5.1 이상이라 props의 이름 앞에 $ 표기를 추가하는 transient props를 통해 에러를 해결해주었다.

transient props를 활용하면 styled-component에서만 활용될 props들이 Reat 노드와 DOM Element에 전달되는 것을 방지해줄 수 있고, 추가로 시각적으로도 일반 props들과 styled-component props들을 구분할 수 있다.

function Toggle() {
    ...

  return (
        ...
      <S.ToggleCircle $mode={mode}></S.ToggleCircle>
    ...
  );
}

export default Toggle;

Reference

https://styled-components.com/docs/api#transient-props

]]>