🎧

원문

https://tkdodo.eu/blog/deriving-client-state-from-server-state

휴가에서 막 돌아왔는데, Zustand를 사용할 때 가장 큰 트레이드오프에 대한 Reddit 질문을 보게 되었다.
코드는 대략 이렇다(최신 문법으로 조금 수정하고, 커스텀 훅 안에 넣었다).

Manual-sync

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  // If the selected user gets deleted from the server,
  // Zustand won't automatically clear selectedUserId
  // You have to manually handle this:
  useEffect(() => {
    if (!users?.some((u) => u.id === selectedUserId)) {
      setSelectedUserId(null) // Manual sync required
    }
  }, [users, selectedUserId])

  return [selectedUserId, selectedUserId]
}

물론, useEffect—특히 그 안에서 setState를 호출하는 경우—를 볼 때마다 나는 더 나은 해결책이 없을까 생각하게 된다.
내 경험상, 거의 항상 더 나은 방법이 존재하며, 보통 그 방법을 찾는 것이 가치 있는 일이다.
그러니 한 걸음 물러서서 우리가 먼저 무엇을 달성하고 싶은지를 먼저 살펴보자.

상태 동기화 유지하기 (Keeping State in Sync)

간단히 말하면, 우리는 클라이언트 상태(Client State)인 selectedUserId를 서버 상태(Server State)인 사용자 목록(users)과 동기화하고 싶다.
이것은 당연한 일이다.

예를 들어, useQuery를 통해 백그라운드에서 다시 데이터를 가져왔는데, 사용자가 목록에서 삭제되었음에도 여전히 상태에 저장되어 있다면, 그 선택은 유효하지 않다.

클라이언트 상태(Client State)

이 접근 방식은 Zustand에만 국한된 것이 아니다.
useUserStore()를 단순히 로컬 상태로 바꿔도 똑같이 적용할 수 있다:

const [selectedUserId, setSelectedUserId] = useState()

또는 URL 상태(nuqs 같은)를 사용해도 된다:

const [selectedUserId, setSelectedUserId] = useQueryState('userId')

중요한 건 상태가 어디에 저장되느냐가 아니라,
서버 상태(Server State)가 바뀔 때 업데이트해야 하는 클라이언트 상태(Client State)라는 점이다.

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  const selectedId = users?.some((u) => u.id === selectedUserId)
    ? selectedUserId
    : null

  return [selectedId, setSelectedUserId]
}

이 코드는 매우 간단하다.
스토어 값을 직접 업데이트하는 대신, Selection 자체는 그대로 두고,
서버 상태(Server State)에서 더 이상 해당 id를 찾을 수 없는 경우 커스텀 훅에서 다른 값을 반환하도록 한다.

즉, useSelectedUser()를 호출하는 곳에서는 이전처럼 null을 받게 된다.

그리고 스토어를 건드리지 않기 때문에 추가적인 이점도 있다:

• 사용자가 다시 목록에 추가되면, 선택(selection)이 자동으로 복원된다.
• UX 요구사항이 바뀌어 선택을 제거하고 싶지 않고, 단지 선택이 유효하지 않음을 시각적으로 표시하고 싶을 때도 가능하다.
  → 원래 값을 항상 유지하기 때문에 쉽게 구현할 수 있다.

isSelectionValid

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()
  const isSelectionValid = users?.some((u) => u.id === selectedUserId)

  return [selectedUserId, setSelectedUserId, isSelectionValid]
}

함정은 어디에 있을까요?

"상태 파생 솔루션"의 명백한 단점 중 하나는 사용자 저장소에 저장된 내용을 더 이상 "신뢰"할 수 없다는 것입니다. useUserStore에서 다른 곳의 selectedUserId를 읽어오면 추가 검사를 받지 못하므로 항상 사용자 정의 hook에서 읽어야 합니다.

저는 저장소를 최종 검증된 값의 소스라기보다는 UI에서 실제로 선택된 항목의 기록으로 보기 때문에 이 점에 대해서는 전혀 문제가 없습니다.

또, Reddit 질문에서 Redux Toolkit이 “이 문제를 해결한다”고 언급했지만, 실제로 크게 다르지 않을 것이다.
보통 API 슬라이스와 사용자 선택 슬라이스를 읽어 두 값을 결합하는 selector를 작성하게 되는데,
이것이 바로 우리가 커스텀 훅에서 하고 있는 방식과 동일하다.

오히려 이 방식은 상태를 파생(derive)하도록 유도하므로, 좋은 접근입니다.

다른 예시

서버 상태(Server State)가 바뀌어도 클라이언트 상태(Client State)를 업데이트하지 않는 개념은 여러 경우에 유용하다.
흔한 예시는 서버에서 가져온 기본값으로 폼을 미리 채울 때(prefilling forms)이다.

default-value-effect

function UserSelection() {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const [selection, setSelection] = useState()

  // use the first value as default selection
  useEffect(() => {
    if (users?.[0]) {
      setSelection(users[0])
    }
  }, [users])

  // return markup
}

이 효과는 장황할 뿐만 아니라, 쿼리에서 새 데이터가 들어올 때 현재 선택 항목을 덮어쓰는 버그도 있습니다. 🐛

이 문제는 다른 검사를 추가하면 쉽게 해결할 수 있지만, 더 나은 해결책은 여전히 ​​상태를 파생하는 것입니다.

derived-default-value

function UserSelection() {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const [selection, setSelection] = useState()

  const derivedSelection = selection ?? users?.[0]

  // return markup
}

지금 우리가 해야 할 일은 selection 대신 derivedSelection을 계속 사용하는 것뿐이며, 그렇게 하면 항상 원하는 값을 얻을 수 있습니다. 🚀

비동기로 멀티 스레드를 구현한다? 많이들 async/await만 쓰면 작업이 “동시에” 돈다고 생각합니다. 하지만 비동기는 하나의 메인 스레드가 일을 잘게 쪼개 순서 없이 처리해 보이는 기법이지, 실제로 여러 스레드가 병렬로 계산하는 건 아닙니다.

UI가 멈추지 않게 하는 데는 비동기로도 충분하지만, 대용량 데이터 처리나 이미지/영상 변환처럼 CPU를 잡아먹는 작업은 결국 메인 스레드를 묶어버립니다.

1. 멀티 스레드가 필요한 이유

자바스크립트는 기본적으로 싱글 스레드 언어입니다. 즉, 한 번에 하나의 작업만 처리할 수 있습니다. 하지만 복잡한 계산, 대규모 데이터 처리, 이미지 변환 같은 작업은 시간이 오래 걸려 UI가 멈출 수도 있습니다. 이런 문제를 해결하기 위해 멀티 스레드 개념을 활용할 수 있는데요.

2. Web Worker로 동시성 구현

Web Worker는 별도의 스레드에서 자바스크립트를 실행할 수 있게 해주는 기능입니다. 메인 스레드(UI)와 독립적으로 동작하므로 무거운 연산을 맡기기 좋습니다.

// worker.js (별도의 파일)
self.onmessage = function(event) {
  let num = event.data;
  let result = 0;
  for (let i = 0; i < num; i++) {
    result += i;
  }
  self.postMessage(result);
};

// main.js
const worker = new Worker("worker.js");
worker.postMessage(1000000); // Worker에게 작업 요청

worker.onmessage = (e) => {
  console.log("결과:", e.data);
};

Web Worker를 사용하면 UI 멈춤 없이 무거운 계산을 처리할 수 있습니다.

3. WebAssembly를 활용한 멀티 스레드

WebAssembly(WASM)는 브라우저에서 동작하는 저수준 이진 코드 포맷입니다. 성능이 중요한 연산을 자바스크립트 대신 C/C++/Rust 같은 언어로 작성한 뒤, WebAssembly로 컴파일해서 실행할 수 있습니다.

// 예시: C 코드 (sum.c)
int sum(int n) {
  int result = 0;
  for (int i = 0; i < n; i++) {
    result += i;
  }
  return result;
}

이 코드를 emscripten 같은 도구로 WebAssembly로 컴파일하면 자바스크립트에서 고성능으로 실행할 수 있습니다.

4. Web Worker vs WebAssembly 비교

웹 환경에서도 멀티 스레드를 활용할 수 있는 방법은 다양합니다. 간단한 동시성 처리는 Web Worker, 고성능 연산은 WebAssembly를 선택하는 것이 좋습니다. 프로젝트 성격에 맞춰 두 기술을 적절히 조합하면 사용자 경험을 크게 개선할 수 있습니다.

프론트엔드 개발 환경은 지난 몇 년 동안 눈부시게 발전했습니다. 과거에는 단순히 <script> 태그로 JS 파일을 불러오면 되었지만, 규모가 커지고 모듈 단위 개발이 보편화되면서 “모듈 번들러(Module Bundler)”가 필수 도구가 되었습니다. 이번 글에서는 대표적인 모듈 번들러인 Webpack, Rollup.js, 그리고 차세대 번들링 도구로 각광받는 Vite에 대해 비교해 보겠습니다.

1. 모듈 번들러란

모듈 번들러는 여러 개의 JavaScript, CSS, 이미지 등의 파일을 의존성 그래프(Dependency Graph)로 분석해 하나의 파일(또는 최적화된 여러 파일)로 묶어주는 도구입니다.

목적: 브라우저가 효율적으로 로드할 수 있도록 최적화된 번들을 만들어주는 것.

왜 필요한가?

👀속도 개선: 파일이 많으면 브라우저가 하나씩 요청해야 해서 느려요. 번들러가 파일을 합쳐서 요청을 줄여줍니다.
👀최적화: 쓰이지 않는 코드를 제거(트리 쉐이킹)하거나, 코드를 압축해 용량을 줄여줍니다.
👀개발 편의성: 최신 문법(ES6, TypeScript 등)을 구버전 브라우저에서도 쓸 수 있도록 변환해 줍니다.

2. 주요 모듈 번들러

이제 많이 쓰이는 3가지 도구를 비교해볼게요

Webpack

가장 유명하고 오래된 번들러
설정이 강력하지만 복잡하다는 단점이 있다
entry → loader → plugin → output 구조로 동작.

대규모 프로젝트에서 안정적이고 확장성이 높습니다.

예시
React, Vue 같은 프레임워크의 기본 번들러로 많이 쓰였습니다.
복잡한 빌드(이미지, CSS, JS, TS 다 합치기)에 유리.

Rollup.js

라이브러리 제작에 강점.
Webpack보다 단순하고 가볍습니다.
트리 쉐이킹(tree shaking) 기능이 강력해서, 쓰지 않는 코드가 거의 남지 않아요.

예시:
Lodash, D3.js 같은 유명한 JS 라이브러리도 Rollup으로 빌드됩니다.
라이브러리 제작할 때는 Webpack보다 Rollup이 더 선호됩니다.

Vite

차세대 번들러로, 최근 가장 핫합니다.

내부적으로 Rollup을 기반으로 하지만, 개발 서버는 ESBuild(Go 언어로 만든 초고속 번들러)를 사용


🔴장점: 개발 서버 속도가 엄청 빠름 (변경된 부분만 즉시 반영 → HMR)

🔴단점: 아직은 Webpack만큼 플러그인 생태계가 방대하지 않음


예시:
Vue 3, React 최신 템플릿에서 기본 빌드 도구로 채택됨
스타트업이나 개인 프로젝트에서 빠르게 개발할 때 최적

회사에서도 기존에 React + Webpack 기반으로 운영하던 서비스를 Vite로 마이그레이션한 경험이 있습니다. 프로젝트가 무거워지면서 Webpack 환경에서 빌드 속도가 오래걸려 초기 개발 서버를 시작하는데에 10분 정도가 걸리는 아주 힘든 상황이 생겨버린거죠! HMR 속도도 개선하기 위함과 최신 생태계와 호환성을 고려해서 논의 결과 vite로 마이그레이션하기로 결정을 했습니다

그 결과, 개발 서버 구동 속도가 1분 미만으로 단축, HMR속도는 말할 것도 없이 현저히 빨라졌습니다.

결론적으로, Vite는 Webpack 대비 훨씬 가볍고 빠른 개발 경험을 제공했고, 팀의 생산성에도 긍정적인 효과를 줬습니다.