김신건의 로그 - 위키 / frameworks

Pagefind: 정적 사이트 전문 검색

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

Pagefind 는 정적 사이트 (SSG) 용 클라이언트 사이드 전문 검색 엔진. 빌드 후 정적 인덱스 생성, 브라우저에서 fetch 로 검색.

특징

서버 없음: JS + fragment index 만
다국어 자동 감지
작은 인덱스: 40MB HTML → 300KB index 정도
stemming: Snowball 알고리즘

Astro 통합

npm i -D astro-pagefind

// astro.config.mjs

export default defineConfig({
    integrations: [pagefind()],
});

---

---
<!-- mdx-component: PagefindSearch -->

사용 (직접)

const pagefind = await import('/pagefind/pagefind.js');
const search = await pagefind.search('rails');
for (const r of search.results) {
    const data = await r.data();
    console.log(data.url, data.excerpt);
}

필터링

HTML 에 data-pagefind-filter 속성으로 카테고리 필터:

<article data-pagefind-filter="category:blog">

pagefind.search('rails', { filters: { category: 'blog' } });

참고

[[astro|Astro]]

[Frontend] React 19.x: Actions, Activity, RSC, Foundation

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

React 19 (2024-12-05) 는 Server Components 의 정식화 와 Actions 라는 새 패러다임을 들고 나온 메이저 릴리즈. 이후 19.1 (2025-06), 19.2 (2025-10-01) 까지 minor 릴리즈에서 Activity / Performance Tracks / Partial Pre-rendering 같은 굵직한 기능 이 계속 추가되었다.

2026-06 시점 기준 현재 LTS 줄기는 19.x. React 20 / 19.3 은 아직 공식 발표 전. 이 페이지는 2026-06 의 운영자 시점 에서 정리한 React 19.x 의 작은 백과.

버전 매트릭스

버전	출시	핵심
19.0	2024-12-05	Actions, ref-as-prop, Document Metadata, Asset Loading, `use()`, `useActionState` / `useFormStatus` / `useOptimistic`, Server Components 안정화
19.1	2025-06	점진 안정화 + 버그 픽스 (큰 신 기능 없음)
19.2	2025-10-01	`
`,` useEffectEvent`,` cacheSignal`, Performance Tracks, Partial Pre-rendering, Web Streams for Node,` useId`prefix`r`
19.0.1 / 19.1.2 / 19.2.1	2025-12-03	RSC RCE 보안 패치

Actions: 폼/네트워크 워크플로의 새 표준

폼 제출 같은 비동기 전이 를 useTransition 위에서 정식화 한 것이 Actions. 함수 자체에 async 가 들어가도 isPending 이 자동으로 잡힌다.

function UpdateName() {
  const [name, setName] = useState('');
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  const handleSubmit = () => {
    startTransition(async () => {
      const err = await updateName(name);
      if (err) {
        setError(err);
        return;
      }
      redirect('/path');
    });
  };

  return (
    <div>
      <input value={name} onChange={(e) => setName(e.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>Update</button>
      {error && <p>{error}</p>}
    </div>
  );
}

위 패턴 위에 3 종 hook 이 얹힌다:

Hook	역할
`useActionState(action, initial)`	Action 의 마지막 결과 + `isPending` 보관. 폼 결과 처리의 표준
`useFormStatus()`	`<form>` 의 자손 컴포넌트 에서 부모 폼의 pending 상태 조회 (prop drilling 없이)
`useOptimistic(state, updater)`	낙관적 업데이트 (서버 응답 전 미리 UI 갱신)

<form action={fn}> 형태로 DOM 액션 prop 도 추가. Server Actions ('use server') 와 합쳐지면 클라이언트 → 서버 mutation 의 일등 시민이 된다.

Server Components 정식화

'use client' / 'use server' 디렉티브 기반의 분할. 19 에서 안정 API 로 진입.

디렉티브	의미
`'use client'`	번들러에게 클라이언트 경계 알림. 별도 `<script>` 청크로 묶임
`'use server'`	번들러에게 서버 endpoint 알림. 클라이언트에서 호출하면 POST 가 일어남

번들러 기능 이지 React 의 런타임 기능이 아니다. Next.js, Waku, RedwoodJS 같은 프레임워크 가 묶어서 제공.

ref 가 prop 이 되다

forwardRef 는 더 이상 필요 없다. 함수 컴포넌트가 그냥 ref prop 을 받을 수 있다.

// 19 이전
const Button = forwardRef(function Button(props, ref) {
  return <button ref={ref} {...props} />;
});

// 19+
function Button({ ref, ...props }) {
  return <button ref={ref} {...props} />;
}

forwardRef 자체는 deprecated. 새 코드는 바로 prop 으로 받자.

Document Metadata

<title>, <meta>, <link> 를 컴포넌트 트리 어디에서나 렌더 가능. React 가 자동으로 <head> 로 올린다. React Helmet 같은 라이브러리가 사실상 불필요.

function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <title>{post.title}</title>
      <meta name="author" content="Josh" />
      <link rel="author" href="https://twitter.com/joshcstory/" />
      <meta name="keywords" content={post.keywords} />
    </article>
  );
}

SSR / RSC / CSR 어디서나 같은 방식. 중복 태그는 React 가 알아서 dedupe.

Asset Loading 과 `preload` / `preinit`

스타일시트, 스크립트, 폰트, 이미지의 로딩 라이프사이클 을 Suspense 와 연결. 데이터처럼 준비될 때까지 일관되게 기다림.


// 곧 쓸 자원을 미리 로드 (priority hint)
preload('https://example.com/font.woff2', { as: 'font' });

// 다운로드 + 초기화까지
preinit('https://example.com/script.js', { as: 'script' });

라우터 / 코드 스플리트 시점에 미리 호출해두면 TTI 개선.

`use()` API: Promise / Context 의 일관된 read

use(promise) 는 렌더 중 Promise 결과 를 읽는다. Suspense 가 받아서 fallback 을 띄운다.

use(context) 는 useContext 와 거의 같지만 if 안에서 호출 가능. Rules of Hooks 의 최상위 호출 제약을 조건부 사용 영역에서 풀어준 첫 hook.

function Message({ messagePromise }) {
  const msg = use(messagePromise); // Suspense 가 받음
  return <p>{msg}</p>;
}

19.2 의 큰 4가지

1. `<Activity>`: pre-render + 상태 보존

// 이전
{isVisible && <!-- mdx-component: Page -->}

// 19.2+
<Activity mode={isVisible ? 'visible' : 'hidden'}>
  <!-- mdx-component: Page -->

mode	효과
`visible`	정상 렌더 + effect mount
`hidden`	렌더는 유지 하되 effect 는 unmount, 업데이트는 우선순위 낮춤

다음 페이지로 갈 가능성이 높은 영역을 백그라운드로 미리 그려두기. 뒤로가기 시 입력값/스크롤 등 상태 보존. SPA 라우터의 워킹 디스플레이 패턴.

2. `useEffectEvent`

useEffect 의 의존성으로 들어가야 하는 값 과 그 안에서 단순히 읽기만 하는 값 을 문법적으로 분리. eslint-plugin-react-hooks@latest 가 디펜던시 배열에 자동으로 넣지 않도록 처리한다.

function ChatRoom({ roomId, theme }) {
  // theme 가 바뀌어도 effect 는 재실행 안 됨
  const onConnected = useEffectEvent(() => {
    showNotification('Connected!', theme);
  });

  useEffect(() => {
    const conn = createConnection(serverUrl, roomId);
    conn.on('connected', () => onConnected());
    conn.connect();
    return () => conn.disconnect();
  }, [roomId]); // theme 는 의존성이 *아니다*
}

“이건 이벤트인데 effect 안에서 발생한다” 라는 드문 사례 만 사용. 모든 함수를 wrap 하는 남발 금지.

3. Performance Tracks (Chrome DevTools)

Chrome DevTools 의 custom track 으로 React 의 Scheduler / Components 두 트랙 추가.

Scheduler ⚛: blocking / transition / idle 우선순위별 작업 흐름.
Components ⚛: 컴포넌트 트리의 mount / render / effect 시점.

기존 React DevTools Profiler 보다 브라우저 전체 timing 과 함께 볼 수 있어서 interaction → first paint 까지 일관된 그림. reference/dev-tools/react-performance-tracks 참고.

4. Partial Pre-rendering

정적 부분은 미리 빌드해 CDN 에서, 동적 부분은 런타임에 이어서 렌더.

// 빌드 시
const { prelude, postponed } = await prerender(<!-- mdx-component: App -->, {
  signal: controller.signal,
});
await savePostponedState(postponed);
// prelude 를 CDN 으로

// 런타임
const postponed = await getPostponedState(request);
const resumeStream = await resume(<!-- mdx-component: App -->, postponed);
// 클라이언트로 스트림

Next.js / Vercel 의 Partial Pre-rendering (PPR) 이 같은 의도. React 가 직접 지원 하게 됨.

사라지는 것들

항목	상태
`forwardRef`	deprecated. `ref` prop 사용
`defaultProps` (함수 컴포넌트)	제거
String refs (`<X ref="foo">`)	제거
Module Pattern Factories	제거
`createFactory`	제거
`react-test-renderer/shallow`	제거 (Enzyme 종료 흐름)
Create React App	2025-02-14 sunsetting

CRA 는 공식 종료. 새 프로젝트는 Vite, Next.js, Parcel, RSBuild, Expo 중 선택. 프레임워크 없이 시작 도 공식 가이드가 있다.

보안: 2025-12 RSC 사건

날짜	사건
2025-12-03	RSC 의 unauthenticated RCE 공개. 19.0.1 / 19.1.2 / 19.2.1 으로 즉시 업그레이드 권장
2025-12-11	동일 패치 시도 중 추가 취약점 2건 (DoS, Source Code Exposure) 발견

Server Components 를 프로덕션 에서 쓰는 모든 곳 이 영향. RSC 위에 입력 검증 / 권한 체크 가 반드시 들어가야 한다는 점이 다시 부각되었다.

React Foundation

날짜	사건
2025-10-07	React Foundation 발표. Meta 단독 에서 재단 거버넌스 로
2026-02-24	Linux Foundation 산하 정식 출범. AWS, Amazon, Callstack, Expo, Microsoft, Software Mansion, Vercel 합류

Meta 의 내부 release process 가 외부 stakeholder 와 공동 운영 으로 전환. Vue 와 비슷한 재단 거버넌스 모델.

React 17/18 에서 19 로

19 Upgrade Guide 의 골자:

모든 변경 이 codemod 로 자동화되어 있다 (@codemod/react-19-codemod 류).
Suspense 안의 사이드 이펙트 가 더 엄격해짐. useEffect 의 클린업 누락 등이 새로 잡힘.
Strict Mode 가 더 강력해짐 (double-invoke 가 effect 까지 확장).
peer dep 으로 react@18 을 요구하는 라이브러리들이 대부분 19 호환 되었다. 안 된 곳만 알림.

김신건의 현장 메모

Asset Loading 은 SSR 페이지에서 FOUC 줄이는 효과가 즉시 보인다. 라우트 진입 직전 preinit('app.css', { as: 'style' }) 한 줄.
Actions 는 <form action={...}> 형태로 progressive enhancement 가 그대로 가능. JS off 인 환경에서도 폼이 동작하는 것이 오랜만에 부활한 정통.
Activity 는 탭 전환이 많은 admin 같은 곳에서 강력. 상태 보존 이 직접 코드보다 깔끔.
Performance Tracks 는 언제 effect 가 늦게 mount 되었는지 가 Chrome 화면 안에서 그대로 보여서 문제 재현 의 grep 가능 영역이 커졌다.

참고

[Frontend] React Compiler 1.0: 자동 memoization 의 새 표준

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

React Compiler 는 React 컴포넌트와 hook 의 불필요한 재계산 을 빌드 타임에 자동으로 잡아주는 optimizing compiler. 손으로 useMemo / useCallback / React.memo 를 박는 대신, 컴파일러가 값과 함수의 변경 여부 를 분석해 자동으로 캐싱한다.

핵심 약속 4가지:

자동 memoization: 손으로 쓰지 않아도 정확하게 박힌다.
조건부 memoization: if/return 이후의 값 까지 memoize 가능 (수동 hook 으로는 불가능했던 영역).
Rules of React 강제: ESLint 와 함께 위반을 조용히 잡아낸다.
점진 도입: 'use memo' 디렉티브 하나로 컴포넌트 단위 부터 켤 수 있다.

v1.0 은 2025년 10월 7일 출시. 거의 10년에 걸친 컴파일러 실험 의 첫 안정 결과물이다.

왜 컴파일러인가?

React 의 멘탈 모델은 “매 렌더마다 새로 계산”. 깔끔하지만, 비싼 계산 이나 자식의 reference equality 가 필요한 곳에서는 다음 같은 코드가 불가피했다:

const filtered = useMemo(
  () => items.filter((it) => it.tag === activeTag),
  [items, activeTag],
);

const handleClick = useCallback(
  (id: string) => onSelect(id),
  [onSelect],
);

const Child = memo(function Child({ data }) {
  // ...
});

문제는 3가지:

디펜던시 배열을 사람이 관리: 빠뜨리면 stale, 너무 많이 넣으면 무의미.
memoize 한 함수도 변하면 자식이 다시 렌더: 한 군데서 끊기면 사슬 전체가 무너진다.
useMemo 자체가 비용: dependency 비교 + 캐시 슬롯 관리. 오히려 무겁다.

자동화는 비용 자체를 줄이는 것이 아니라 사람의 일관성을 보장 하기 위한 것. 컴파일러는 조건부 early-return 이후 의 값까지 memoize 한다.

컴파일러는 어떻게 동작하는가

Babel 이 만든 Abstract Syntax Tree (AST) 를 받아서, 자체 IR (HIR, High-Level Intermediate Representation) 로 lowering. HIR 은 Control Flow Graph (CFG) 기반이라 정확한 data-flow analysis 와 mutability inference 가 가능하다.

Source (JSX/TS)
  ↓ Babel parse
AST
  ↓ React Compiler lowering
HIR (CFG-based)
  ↓ multi-pass
    ├ data-flow analysis
    ├ mutability inference
    ├ scope formation (memoization 단위)
    └ rules-of-react validation
  ↓ codegen
Optimized output (AST)
  ↓ Babel print
JS

이 분리 덕에 다음이 가능:

조건부 분기 이후 memoize: useMemo 의 최상위 위치 제약이 사라진다.
세분화 (granular) scope: 거대한 useMemo 하나가 아니라 필요한 값마다 따로.
lint 가 같은 분석을 재활용: eslint-plugin-react-hooks 의 새 규칙들이 compiler 의 HIR 분석 결과를 그대로 쓴다.

공식 예시 (조건부 return 후의 theme 값까지 memoize):


export default function ThemeProvider(props) {
  if (!props.children) {
    return null;
  }
  // 컴파일러는 conditional return 이후의 값도 memoize 한다
  const theme = mergeTheme(props.theme, use(ThemeContext));
  return (
    <!-- mdx-component: ThemeContext -->

      {props.children}
    
  );
}

수동 useMemo 로는 불가능한 위치. 컴파일러만의 강점.

컴파일 모드와 디렉티브

모드	동작	용도
`infer` (기본)	컴포넌트 / hook 으로 추론 되면 자동 컴파일	새 코드, 전체 도입
`annotation`	`'use memo'` 가 명시된 함수만 컴파일	점진 도입 초기
`all`	모든 함수를 컴파일 시도	보통 권장하지 않음
`syntax`	parse 만 하고 실제 변환은 하지 않음	debugging

함수 단위 디렉티브 (모드와 무관하게 우선):

function StableComponent() {
  'use memo';      // 이 컴포넌트는 *반드시* 컴파일
  // ...
}

function ProblematicComponent() {
  'use no memo';   // 이 컴포넌트는 *반드시* 컴파일에서 제외
  // 보통 Rules of React 위반을 발견한 임시 escape
}

권장 도입 흐름:

compilationMode: 'annotation' 으로 켜고, 잘 검증된 컴포넌트부터 'use memo' 추가.
ESLint 새 규칙으로 위반 코드 식별 + 수정.
compilationMode: 'infer' 로 전환.
문제 발견된 컴포넌트만 'use no memo' 로 임시 격리 + 원인 수정 후 제거.

설정 (`babel.config.js`)

// babel.config.js
module.exports = {
  plugins: [
    [
      'babel-plugin-react-compiler',
      {
        compilationMode: 'annotation',
        target: '18',                  // '17' | '18' | '19' (기본 '19')
        panicThreshold: 'none',        // 'all_errors' | 'critical_errors' | 'none'
        logger: {
          logEvent(filename, event) {
            if (event.kind === 'CompileSuccess') {
              console.log('Compiled:', filename);
            }
          },
        },
        gating: {
          source: 'my-feature-flags',           // 모듈 경로
          importSpecifierName: 'isCompilerEnabled', // 토글 함수
        },
      },
    ],
  ],
};

주요 옵션:

target: '17' | '18': React 19 미만이면 react-compiler-runtime 을 의존성에 추가하고 target 을 명시. v1.0 의 놀라운 약속.
panicThreshold: 일반적으로 'none' 권장. 컴파일에 실패한 함수는 그대로 두고 넘어감.
gating: A/B 테스트나 feature flag 로 환경에 따라 켜고 끄기. Meta 가 내부적으로 쓰던 방식.

빌드 도구 매트릭스

빌드 도구	지원 상태 (2026-06)
Babel	1차 (`babel-plugin-react-compiler`)
Vite	`@vitejs/plugin-react` 의 Babel 옵션 경유, 또는 `vite-plugin-react-compiler`
Next.js	`next.config.js` 의 `reactCompiler: true`. 15.3.1+ 에서 swc plugin 으로 빌드 속도 크게 개선
swc	experimental. @kdy1dev 가 작업. Next.js 가 먼저 활용
oxc	작업 중 (oxc-project/oxc#10048)
Rsbuild	1차 지원
Expo	SDK 54 부터 기본 enable

새 프로젝트는 create-vite, create-next-app, create-expo-app 모두 컴파일러 enable 옵션 을 제공한다. 새 코드면 거의 무조건 켜는 것이 권장.

ESLint 통합

v1.0 부터 별도 eslint-plugin-react-compiler 는 폐지. eslint-plugin-react-hooks 의 recommended preset 안으로 통합되었다.

// eslint.config.js (Flat Config)


export default defineConfig([
  reactHooks.configs.flat.recommended,
]);

새 규칙 일부:

set-state-in-render: 렌더 중 setState 호출로 인한 무한 루프 패턴.
set-state-in-effect: Effect 안에서 불필요한 state 동기화 를 잡음.
refs: 렌더 중 ref 접근 같은 unsafe 사용을 잡음.

ESLint 만 켜는 것도 유의미: 컴파일러를 실제로 도입하지 않아도, Rules of React 위반을 컴파일러의 IR 수준 분석으로 잡아낼 수 있다.

`useMemo` / `useCallback` / `React.memo` 는 이제 필요 없나?

대부분의 경우 그렇다. 컴파일러는 손으로 쓴 것보다 더 정밀하게 memoize 한다.

다만 다음 세 경우는 escape hatch 로 그대로 둘 가치가 있다:

useEffect 의 dependency 가 정확히 memoize 된 값이어야 할 때: 컴파일러가 언제 reference 가 바뀌는지 의 의도를 표현할 곳이 코드에 명시되어 있어야 안전.
외부 라이브러리에 stable reference 를 넘겨야 할 때: 라이브러리의 hook 내부가 dep array 를 보는 경우.
이미 깔린 기존 useMemo 를 제거: 컴파일 결과가 미세하게 달라질 수 있어, 코드를 건드리지 않고 두는 편이 안전. 새 코드는 안 써도 OK.

프로덕션 결과

Meta 가 자체 앱들에 수년간 적용한 결과 (공식 글):

Meta Quest Store: 초기 로드와 페이지 이동 최대 12% 개선. 일부 인터랙션은 2.5배 이상 빨라짐.
메모리 사용량은 중립: memoize 추가 비용이 그만한 가치 가 있도록 균형.

오픈소스 사례:

Sanity Studio: 거대한 content editor 의 복잡한 트리에서 도입 회고 (discussion #33).
Wakelet: 측정된 수치 와 함께 도입 회고 (discussion #52).

v1.0 까지의 타임라인

시점	이벤트
2017	Meta 의 Prepack 실험. 종료되었지만 Hooks 설계의 토대 가 됨
2021	Xuan Huang 의 첫 prototype 데모
2024-02	React Labs 글, 본격적인 Compiler 작업 상황 공개
2024-05	React Conf 2024 에서 experimental 공개
2024-10	Beta 출시. Meta 사내 사용량 확대
2025-10-07	v1.0 stable, ESLint 통합, 새 프로젝트 기본 enable
2025-10-16	React Conf 2025 에서 리뷰

v1.0 은 시작점. 공식 글이 명시하는 방향:

더 정밀한 memoization (현재보다 세분화 + 예측 가능성).
더 많은 Rules of React 를 정적으로 검증.
swc / oxc 와의 통합 강화 → 빌드 속도.
Library precompilation: 라이브러리 저작자가 미리 컴파일된 결과 를 패키지에 동봉.

참고

[React] Component Composition: Props, Children, Render Prop, HOC, Compound

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Component Composition 은 작은 컴포넌트를 조합 해 큰 UI 를 만드는 React 의 핵심 빌드 블록. 객체지향의 상속 (inheritance) 대신 Composition 이 React 의 정통.

[!IMPORTANT] React 의 공식 입장은 명확하다: “Composition over Inheritance”. 컴포넌트 상속 (extends Modal) 같은 패턴은 처음부터 권장하지 않는다. 모든 재사용은 props / children / Hook / Composition 으로.

Stateless vs Stateful

{}

위 애니메이션은 stateless / stateful 시스템의 일반 직관. React 도 상태 없는 컴포넌트 (presentational) 와 상태 있는 컴포넌트 (container) 의 분리가 대규모 코드 정리의 기본.

// Stateless (presentational)
function Card({ title, body }) {
  return (
    <div className="card">
      <h2>{title}</h2>
      <p>{body}</p>
    </div>
  );
}

// Stateful (container)
function CardWithLike({ id }) {
  const [liked, setLiked] = useState(false);
  return (
    <!-- mdx-component: Card -->

      <button onClick={() => setLiked(!liked)}>Toggle</button>
    
  );
}

패턴 카탈로그

flowchart LR
    Comp[Composition 패턴]
    Comp --> P[Props]
    Comp --> C[Children]
    Comp --> RP[Render Prop]
    Comp --> HOC[HOC]
    Comp --> CC[Compound Component]
    Comp --> Slots[Slots / Portal]
    Comp --> Ctx[Context]
    Comp --> Hook[Custom Hook]

패턴	의도	가장 잘 어울리는 곳
Props	값 전달	가장 기본
Children	임의 JSX 임베드	Card, Layout, Modal
Render Prop	자식 렌더 함수	데이터 + UI 분리 (옛 패턴)
HOC	컴포넌트 감싸기	인증, 권한, 로깅 (옛 패턴)
Compound Component	짝 컴포넌트 (`Tabs.Tab`)	Tabs, Select, Disclosure
Slot	특정 지정 영역 에 임베드	Layout, Drawer
Portal	DOM 트리 밖 으로 렌더	Modal, Tooltip, Toast
Context	트리 전체에 값 공유	Theme, Auth, i18n
Custom Hook	동작 만 추출	API fetch, 폼 상태

1. Props: 가장 기본

function Avatar({ src, size = 'md', alt }) {
  return <img src={src} alt={alt} className={`avatar avatar-${size}`} />;
}

<!-- mdx-component: Avatar -->

[!NOTE] React 19+ 에서는 ref 도 그냥 prop. forwardRef 불필요. 기본 props 의 지위 가 더 강력해졌다.

2. Children: 임의 JSX 임베드

function Card({ title, children }) {
  return (
    <div className="card">
      <h2>{title}</h2>
      <div className="card-body">{children}</div>
    </div>
  );
}

<!-- mdx-component: Card -->

  <p>Anything I want.</p>
  <button>Click me</button>

“내가 디자인한 슬롯에 너가 무엇을 넣을지 결정해”. 컴포지션의 가장 강력한 한 줄.

다중 children: 명명 slot

function Layout({ header, sidebar, children, footer }) {
  return (
    <div className="layout">
      <header>{header}</header>
      <aside>{sidebar}</aside>
      <main>{children}</main>
      <footer>{footer}</footer>
    </div>
  );
}

<!-- mdx-component: Layout -->}
  sidebar={<!-- mdx-component: Sidebar -->}
  footer={<!-- mdx-component: Footer -->}
>
  <!-- mdx-component: Article -->
</Layout>

3. Render Prop (옛 패턴)

자식이 렌더 함수. 부모가 데이터 를 만들고 자식이 UI 를 결정.

<!-- mdx-component: MouseTracker -->

  {({ x, y }) => <div>Mouse at ({x}, {y})</div>}


function MouseTracker({ children }) {
  const [pos, setPos] = useState({ x: 0, y: 0 });
  useEffect(() => {
    const handler = (e) => setPos({ x: e.clientX, y: e.clientY });
    window.addEventListener('mousemove', handler);
    return () => window.removeEventListener('mousemove', handler);
  }, []);
  return children(pos);
}

[!CAUTION] Render Prop 는 Hook 이전 시대의 패턴. 현재는 custom Hook (useMouse) 이 더 깔끔. 새 코드에서는 피하는 게 표준.

// 같은 의도, 현대적 형태
function useMouse() {
  const [pos, setPos] = useState({ x: 0, y: 0 });
  useEffect(() => { /* same */ }, []);
  return pos;
}

function Tracker() {
  const { x, y } = useMouse();
  return <div>Mouse at ({x}, {y})</div>;
}

4. HOC (Higher Order Component) (옛 패턴)

컴포넌트를 함수에 넣고 새 컴포넌트 를 받는다.

function withAuth(Component) {
  return function AuthGuarded(props) {
    const user = useUser();
    if (!user) return <!-- mdx-component: Login -->;
    return <!-- mdx-component: Component -->;
  };
}

const ProtectedPage = withAuth(Page);

[!CAUTION] HOC 도 Hook 이전의 패턴. 현대적 대안:

인증 가드 → Route 레벨 또는 layout 컴포넌트

데이터 주입 → Hook 또는 Context

prop 추가 → Composition + Hook

5. Compound Component: 짝 컴포넌트

부모와 지정된 자식들 이 암묵적 계약. 사용자가 자식의 배치만 결정.

<!-- mdx-component: Tabs -->

  <Tabs.List>
    <Tabs.Trigger value="profile">Profile</Tabs.Trigger>
    <Tabs.Trigger value="settings">Settings</Tabs.Trigger>
  </Tabs.List>
  <Tabs.Panel value="profile"><!-- mdx-component: Profile --></Tabs.Panel>
  <Tabs.Panel value="settings"><!-- mdx-component: Settings --></Tabs.Panel>

// 구현 (Context 로 짝 묶기)
const TabsContext = createContext(null);

function Tabs({ defaultValue, children }) {
  const [active, setActive] = useState(defaultValue);
  return (
    <!-- mdx-component: TabsContext -->

      {children}
    
  );
}

Tabs.List = ({ children }) => <div className="tabs-list">{children}</div>;
Tabs.Trigger = ({ value, children }) => {
  const { active, setActive } = use(TabsContext);
  return (
    <button data-active={active === value} onClick={() => setActive(value)}>
      {children}
    </button>
  );
};
Tabs.Panel = ({ value, children }) => {
  const { active } = use(TabsContext);
  return active === value ? <div>{children}</div> : null;
};

[!TIP] 라이브러리 (Radix, Reach UI, Headless UI, shadcn/ui) 가 모두 이 패턴을 사용. flexible + 타입 안전 + 자기 documentation. 모던 React 의 주력 패턴.

6. Slot / Portal

// 트리 안의 *지정 위치* 에 임베드
function Modal({ children }) {
  return createPortal(
    <div className="modal-backdrop">
      <div className="modal-content">{children}</div>
    </div>,
    document.body          // ← DOM 트리 *밖* 의 <body> 로
  );
}

[!IMPORTANT] Portal 은 DOM 트리는 다르지만 React 트리는 같다. Context 가 portal 자식까지 전파. event bubbling 도 React 트리 따라 흐름.

7. Context: 트리 전체에 값 공유

const ThemeContext = createContext('light');

function App() {
  const [theme, setTheme] = useState('light');
  return (
    <!-- mdx-component: ThemeContext -->
   // ← React 19+ <Context.Provider> 줄임
      <Layout>
        <!-- mdx-component: Article -->
      </Layout>
    
  );
}

function Article() {
  const theme = use(ThemeContext);   // React 19 의 use() API
  return <article className={theme}>...</article>;
}

[!CAUTION] Context 는 상위 값이 바뀌면 Context 를 읽는 모든 자손이 재렌더. 자주 변하는 값 을 Context 에 두면 성능 사고 의 원인. theme / auth 처럼 드물게 변하는 값 에만.

8. Custom Hook: 로직만 추출

UI 가 없는 재사용 가능한 동작. Composition 의 비-시각적 형태.

function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let alive = true;
    fetch(url)
      .then(r => r.json())
      .then(d => alive && setData(d))
      .catch(e => alive && setError(e))
      .finally(() => alive && setLoading(false));
    return () => { alive = false; };
  }, [url]);

  return { data, loading, error };
}

function UserCard({ id }) {
  const { data: user, loading, error } = useFetch(`/api/users/${id}`);
  if (loading) return <!-- mdx-component: Skeleton -->;
  if (error) return <!-- mdx-component: Error -->;
  return <!-- mdx-component: Card -->
{user.name};
}

Custom Hook 의 이름 은 use 로 시작. ESLint 가 Hook 규칙 (최상위 호출, 컴포넌트 내부) 을 강제.

패턴 선택 가이드

flowchart TD
    Q1{재사용 대상}
    Q1 -->|값 / 데이터 전달| Props[Props]
    Q1 -->|자식 JSX 자유| Children[children]
    Q1 -->|레이아웃 슬롯| NamedSlots[Named props as JSX]
    Q1 -->|로직만| Hook[Custom Hook]
    Q1 -->|UI + 동작 묶음| Q2{관련 컴포넌트 여러개?}
    Q2 -->|예| Compound[Compound Component]
    Q2 -->|아니오| Standalone[일반 컴포넌트]
    Q1 -->|DOM 밖 렌더| Portal[Portal]
    Q1 -->|트리 전체 값 공유| Context[Context]

Inheritance 가 왜 안 좋은가

// 안티패턴
class Modal extends BaseModal {
  // BaseModal 의 protected method 를 호출?
  // 부모-자식의 의미적 결합이 *코드를 강하게 묶음*
}

// 정통: composition
function Modal({ title, children }) {
  return <!-- mdx-component: BaseModal -->
{children};
}

항목	Inheritance	Composition
부모-자식 결합도	강함	약함 (props 만)
테스트 단위	상속 체인 전체	조립 단위 별
재사용 단위	클래스	컴포넌트 + Hook
변경 영향 범위	모든 자식	해당 인스턴스

React 의 모든 공식 문서가 inheritance 를 권장하지 않는다. 예외가 거의 없는 원칙.

컴포넌트 계층의 얕음

flowchart TB
    subgraph Deep[깊은 계층, 안 좋음]
        D1[App] --> D2[Layout]
        D2 --> D3[Section]
        D3 --> D4[CardGroup]
        D4 --> D5[Card]
        D5 --> D6[CardBody]
        D6 --> D7[CardText]
    end
    subgraph Flat[얕은 계층, 좋음]
        F1[App] --> F2[Layout]
        F2 --> F3[Section]
        F3 --> F4[Card]
    end

계층이 깊으면 prop drilling 이 고통. Composition + children + Context 로 얕게 유지.

19+ 의 새 기능들과 composition

React 19+ 기능	composition 에 미친 영향
`ref` as prop	`forwardRef` 의 상속 같은 wrapping 사라짐
Server Components	서버 데이터 + 클라이언트 UI 의 깔끔한 분리
`use()` API	Promise / Context 의 조건부 사용 가능
`<Activity>`	상태 보존 + effect 분리 의 새 컴포지션 단위
Document Metadata	`<title>`, `<meta>` 가 컴포넌트 내부에서 동작

흔한 함정

[!WARNING]

HOC 남용 = 디버깅 hell (트리에 withX(withY(withZ(Component)))).

Render Prop 남용 = nested function 의 무한 들여쓰기. Custom Hook 으로.

Context 의 모든 값을 한 곳 에 = 자주 변하는 값이 모든 자식 재렌더. 분리된 Context 로.

부모가 자식의 내부 state 를 직접 조작 = ref + imperative handle. 피해야 한다. state lift up 또는 event 전달.

Compound Component 의 암묵 계약 = 잘못된 자식이 들어오면 조용히 깨짐. Context 사용 + 자식 검증.

김신certificate의 현장 메모

Compound Component 가 모던 React 의 가장 강력한 무기. Radix / Headless UI 가 모두 이 패턴 → Tailwind + Compound 가 오늘날의 표준 디자인 시스템 빌드 블록.
Custom Hook 의 시그니처 가 컴포넌트보다 더 신중 해야 한다. 반환 모양 (object vs tuple), 의존성 입력 방식, 에러 처리 일관성 이 팀 전체 의 사용성을 결정.
Children 만으로도 거의 모든 합성 이 가능. 팀에 children 으로 끝낼 수 있는 곳에 HOC / render prop 도입 금지 라는 규칙 만 있으면 복잡도 폭증을 막을 수 있다.
Context 의 읽기 / 쓰기 분리 (useTheme / useThemeUpdate) 가 자주 변하는 값의 성능 사고 를 막는 간단한 패턴. 별도 라이브러리 없이 Context 두 개.

참고

공식: Passing Props, Children
레거시 (참고): Composition vs Inheritance
Compound: Kent C. Dodds

[React] Lifecycle: Mount / Update / Unmount, StrictMode, Activity, RSC

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

React Lifecycle 은 컴포넌트의 생성 → 갱신 → 제거 의 흐름. 함수 컴포넌트에서는 클래스의 lifecycle method 가 사라지고 render + effect + cleanup 의 조합으로 대체된다.

[!IMPORTANT] 함수 컴포넌트 시대의 멘탈 모델: **“라이프사이클” 이 아니라 “동기화의 한 사이클”. render (UI 계산) + effect (외부 시스템 동기화) + cleanup (정리). 이 3 단계가 mount / update / unmount 시점마다 다른 조합 으로 일어난다.

일반 라이프사이클의 직관

{}

Spring Bean 의 라이프사이클 직관. React 도 생성 → 의존성/props 주입 → 초기화 콜백 (effect setup) → 사용 → 소멸 콜백 (cleanup) → 제거 의 거의 같은 흐름.

함수 컴포넌트의 3 단계

stateDiagram-v2
    [*] --> Mount
    Mount --> Mounted: render + effect setup
    Mounted --> Updating: state/props 변경
    Updating --> Mounted: render + cleanup (옛 effect) + effect setup
    Mounted --> Unmount: 부모가 제거
    Unmount --> [*]: cleanup (마지막)

1. Mount

1. constructor 같은 *초기 state 설정* (useState, useReducer 초기값)
2. render() = JSX 반환
3. DOM 에 commit
4. useLayoutEffect 실행 (동기)
5. paint
6. useEffect 실행 (비동기)

2. Update

1. state / props 변경 트리거
2. render() = 새 JSX 계산 (Reconciliation)
3. DOM diff 후 commit
4. useLayoutEffect cleanup → 새 useLayoutEffect
5. paint
6. useEffect cleanup → 새 useEffect

3. Unmount

1. 부모 트리에서 제거 결정
2. useEffect cleanup 호출 (마지막)
3. useLayoutEffect cleanup 호출
4. DOM 제거

[!NOTE] Cleanup 은 옛 effect 를 지우고 새 effect 를 시작하기 직전. 언마운트 시점 만의 일이 아니다. 모든 update 시 cleanup + setup 이 짝 으로 일어난다.

클래스 vs 함수 컴포넌트 매핑

클래스 (legacy)	함수 (현재)
`constructor`	`useState`, `useReducer` 초기값
`componentDidMount`	`useEffect(() => {}, [])`
`componentDidUpdate`	`useEffect(() => {}, [deps])`
`componentWillUnmount`	cleanup 함수 `return () => {}`
`shouldComponentUpdate`	`React.memo` 의 비교 함수
`getDerivedStateFromProps`	없음 (props 로부터 유도 = render 중 계산)
`getSnapshotBeforeUpdate`	`useLayoutEffect` cleanup 의 직전 측정
`componentDidCatch`	`ErrorBoundary` (여전히 클래스 필요)

[!CAUTION] ErrorBoundary 는 2026 시점에도 여전히 클래스 컴포넌트 필요. componentDidCatch 와 getDerivedStateFromError 가 함수 API 로 옮겨지지 않았다.

Strict Mode 의 double invoke

React 18+ 의 개발 모드에서 render + effect 가 2 번 실행 된다. cleanup 의 정합성 검증 도구.

sequenceDiagram
    autonumber
    participant SM as StrictMode (dev)
    participant C as Component

    SM->>C: mount
    C->>C: render() (1번)
    C->>C: render() (2번 - 같은 결과 검증)
    C->>C: setup (1번)
    SM->>C: simulated unmount
    C->>C: cleanup (1번)
    C->>C: setup (2번)
    Note over C: 진짜 사용 시작

무엇이 잡히는가

순수하지 않은 render: 두 번 호출에서 다른 결과 가 나오면 Side effect in render 위반.
불완전한 cleanup: setup 에서 전역 카운터 ++, cleanup 에서 — 안 하면 2 가 누적.
stale closure 오용: 첫 render 의 closure 가 두 번째에서 예상과 다르게 동작.

Production 에서는?

<!-- mdx-component: StrictMode -->

  <!-- mdx-component: App -->

→ 개발 모드 only. 프로덕션 번들에서는 single invoke. 즉 개발 시 잡지 못한 버그가 프로덕션에서 발현될 수 있다. Strict Mode 의 모든 경고를 진지하게 받아들이는 게 원칙.

React 19.2 의 `

` 모드

<Activity mode="hidden | visible"> 가 lifecycle 의 4번째 상태 를 추가한다.

stateDiagram-v2
    [*] --> Mounted
    Mounted --> Hidden: Activity mode='hidden'
    Hidden --> Mounted: Activity mode='visible'
    Hidden --> Unmounted: 트리에서 제거
    Mounted --> Unmounted: 트리에서 제거
    Unmounted --> [*]

상태	render	effect	DOM
`Mounted` (visible)	일반	mounted	live
`Hidden`	유지	cleanup (unmount 처럼)	유지 (display:none)
`Unmounted`	없음	cleanup	제거

<Activity mode={isVisible ? 'visible' : 'hidden'}>
  <!-- mdx-component: Page -->

[!TIP] 탭 전환 / 라우터 에서 상태 보존이 필요 하지만 effect 는 멈춰야 할 때. 옛 코드에서는 직접 보관하다가 다시 mount 하는 복잡한 패턴 이 Activity 한 줄 로 대체.

Server Components (RSC) 의 lifecycle

'use server' 가 박힌 서버 컴포넌트는 서버에서 1번 render, 결과만 클라이언트로. 클라이언트에서 effect 없음.

sequenceDiagram
    autonumber
    participant Client
    participant Server
    participant DB

    Client->>Server: HTTP request
    Server->>DB: fetch
    DB-->>Server: data
    Server->>Server: ServerComponent.render() (1번)
    Server-->>Client: RSC payload (직렬화된 트리)
    Client->>Client: 클라이언트 트리에 hydrate
    Note over Client: 클라이언트 컴포넌트 ('use client') 만 effect 실행

CSR / SSR / SSG / RSC 모드 비교

{}

4 가지 렌더링 모드의 시각. 각 모드별 lifecycle 의 위치 가 어떻게 다른지 직관.

Hydration: 서버 HTML 과 클라이언트의 합체

sequenceDiagram
    autonumber
    participant SSR as Server-Side Render
    participant Browser
    participant Client as Client React

    SSR->>SSR: render() → HTML
    SSR-->>Browser: HTML (정적, no interactivity)
    Browser->>Browser: HTML 파싱 + 보여줌 (interactive 0)
    Browser->>Client: JS 번들 load
    Client->>Client: hydrate(root, <!-- mdx-component: App -->)
    Client->>Client: DOM 트리와 React tree 매칭
    Client->>Client: event listener 부착
    Note over Browser: 이제 interactive
    Client->>Client: useEffect 실행 (mount)

Hydration mismatch

서버 render 결과와 클라이언트 첫 render 결과가 다르면 에러:

// ❌ 서버와 클라이언트가 다른 시간
function Now() {
  return <div>{new Date().toISOString()}</div>;
}

// ✅ 서버 render 결과 그대로 사용, 클라이언트만 갱신
function Now() {
  const [now, setNow] = useState(null);
  useEffect(() => setNow(new Date()), []);
  return <div>{now?.toISOString() ?? '...'}</div>;
}

Browser 렌더링 vs React 렌더링

{}

브라우저 자체의 DOM → Layout → Paint → Composite 흐름. React 의 render → commit → effect 가 어디에 끼는지 의 큰 그림.

흔한 함정

[!WARNING]

render 에서 사이드 이펙트 = useEffect 로 옮기거나 이벤트 핸들러 로. render 는 순수해야 한다 (StrictMode 가 강제로 검증).

setState 가 즉시 반영되지 않음 = 같은 render 사이클 안에서는 옛 값. batched update.

Concurrent rendering 의 interrupted render = render 가 중간에 버려질 수 있다. render 안에서 외부 state 변경 금지.

Strict Mode 의 double invoke 를 production 으로 오해 = 개발 도구. 프로덕션에서는 일어나지 않는다. 그러나 그 경고를 무시하면 다른 버그.

함수 컴포넌트의 호출 횟수 헷갈림

flowchart LR
    Mount[mount] -->|"render() 1번"| Render1[render]
    Render1 -->|Strict Mode dev| Render2[render 2번]
    Render1 -->|commit + effect| Effect1[setup]
    Update1[state change] -->|"render() 1번"| Render3[render]
    Render3 -->|commit| Cleanup1[cleanup]
    Cleanup1 --> Effect2[setup]

시점	render 호출	effect setup	effect cleanup
첫 mount (prod)	1번	1번	0
첫 mount (StrictMode dev)	2번	2번 (1번 + 시뮬레이션 cleanup + 1번)	1번
상태 변경	1번	1번 (deps 변경 시)	1번 (deps 변경 시)
unmount	0	0	1번 (마지막)

컴포넌트 수명 추적

function Component() {
  const mountCount = useRef(0);
  const renderCount = useRef(0);

  renderCount.current += 1;

  useEffect(() => {
    mountCount.current += 1;
    console.log(`mounted: ${mountCount.current} times`);
    return () => console.log('unmounted');
  }, []);

  console.log(`rendered: ${renderCount.current} times`);
}

개발 시 얼마나 자주 mount / re-render 되는지 측정. prop 변경 → re-render 와 key 변경 → unmount + mount 의 큰 차이 를 직관으로.

Key prop 의 lifecycle 영향

// 같은 위치, key 같음 → React 가 *재사용* (update)
<!-- mdx-component: Component -->
<!-- mdx-component: Component -->

// 같은 위치, key 다름 → *unmount + remount* (state 리셋)
<!-- mdx-component: Component -->

[!IMPORTANT] key 가 바뀌면 React 는 완전히 새 컴포넌트 로 본다. state 가 모두 리셋. prop 변경 시 state reset 패턴은 useEffect 보다 key 가 정석.

19.2 Activity + Strict Mode + RSC: 정리

도구	도입	목적
Strict Mode	16.3	cleanup 검증 (double invoke 18+)
Server Components	18 / 19 정식	서버에서만 render (effect 없음)
Concurrent Rendering	18	render 중단/재시작
Activity	19.2	hidden / visible 의 4번째 상태
useEffectEvent	19.2	effect dep 분리

김신건의 현장 메모

함수 컴포넌트 시대에 componentDidMount 라는 표현을 팀에서 쓰지 않도록 정리한 게 멘탈 모델 교체에 도움. “mount effect” / “update effect” / “cleanup” 의 함수 시대 어휘 로.
Strict Mode 켠 직후 가장 자주 본 버그: 전역 store 구독 의 cleanup 누락. 두 번 setup → 구독 2 개 → 알림 2 번. Strict Mode 가 없었으면 프로덕션에서 알 수 없는 중복.
Activity 가 도입된 뒤 탭 전환의 state 보존 이 완전히 다른 패턴. 옛 별도 store 에 입력값 복제 같은 모종의 패턴 이 Activity 한 줄 로 대체.
Hydration mismatch 의 가장 자주 본 원인 은 Math.random() 또는 Date.now(). SSR 와 클라이언트 첫 render 사이의 시간차. 시간 의존 값은 effect 안 에서.

참고

공식: useEffect, Strict Mode, Activity
Class legacy: Component

[React] useEffect: 동기화의 본질, dep array, cleanup, useEffectEvent

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

useEffect(setup, deps?) 는 컴포넌트의 렌더 결과 와 외부 시스템 을 동기화 하는 hook.

외부 시스템: 브라우저 DOM, WebSocket, 구독, 타이머, 외부 라이브러리 (D3, Mapbox 등), 외부 store.
동기화: “렌더가 끝났을 때 외부 상태도 이 컴포넌트 상태와 맞아야 한다” 라는 규칙 적용.

[!IMPORTANT] useEffect 의 공식 멘탈 모델은 “동기화”. 생명주기 이벤트 가 아니다. 왜 이 effect 가 살아 있어야 하는지 를 외부 시스템 관점 에서 설명할 수 있어야 한다.

라이프사이클의 직관

{}

위 애니메이션은 Spring Bean 의 라이프사이클이지만 컴포넌트 라이프사이클의 일반 직관 을 정확히 보여준다. 생성 → 의존성 주입 → init 콜백 → 사용 → destroy. React 도 mount → effect → re-render (deps 변경시) → cleanup → unmount 의 유사 흐름.

가장 단순한 형태

useEffect(() => {
  // setup: 렌더 후 동작
  const conn = createConnection(url);
  conn.connect();
  return () => {
    // cleanup: 다음 effect 전에, 그리고 unmount 시
    conn.disconnect();
  };
}, [url]);   // dep: 이 값들이 변하면 cleanup + setup 다시

4가지 패턴

flowchart LR
    Q{deps?}
    Q -->|"deps 없음"| EveryRender["매 렌더마다 실행"]
    Q -->|"[] 빈 배열"| Once["mount 시 1회 + unmount 시 cleanup"]
    Q -->|"[dep1, dep2]"| OnChange["mount + dep 변경 시"]
    Q -->|"[state, props]"| Sync["state/props 의존 동기화"]

deps	의미	흔한 사용
`useEffect(fn)`	매 렌더	거의 피해야 한다
`useEffect(fn, [])`	mount 1회	구독, 초기 fetch, 외부 라이브러리 init
`useEffect(fn, [a, b])`	a, b 변경 시	검색 query 변경 → 새 fetch
`useEffect(fn, [state])`	state 동기화	라우터, 외부 store

Cleanup: 왜 이렇게 동작하는가

sequenceDiagram
    autonumber
    participant Render as Render
    participant Effect as Effect setup
    participant Cleanup as Effect cleanup

    Note over Render: 첫 mount
    Render->>Effect: setup() 실행
    Note over Render: prop 변경 → re-render
    Render->>Cleanup: cleanup() (옛 effect)
    Render->>Effect: setup() (새 effect)
    Note over Render: unmount
    Render->>Cleanup: cleanup() (마지막)

[!IMPORTANT] Cleanup 은 setup 의 거울. setup 에서 시작한 모든 것 을 cleanup 이 멈춰야 한다. 그래야 다음 setup 이 깨끗한 상태 에서 시작.

Cleanup 시각화

{}

위는 AbortController 의 동작 직관. effect 의 cleanup 에서 진행 중인 비동기 를 abort 하는 표준 패턴.

useEffect(() => {
  const ac = new AbortController();
  fetch(`/api/users/${id}`, { signal: ac.signal })
    .then(r => r.json())
    .then(setUser)
    .catch(err => {
      if (err.name !== 'AbortError') throw err;
    });
  return () => ac.abort();   // 새 id 로 바뀌면 옛 요청 취소
}, [id]);

Strict Mode 의 double invoke

React 18+ 의 development 모드에서 effect 가 2 번 실행 된다. cleanup 을 제대로 짰는지 강제로 검사하는 도구.

sequenceDiagram
    participant SM as StrictMode (dev)
    participant Component
    SM->>Component: mount
    Component->>Component: setup()
    SM->>Component: unmount (시뮬레이션)
    Component->>Component: cleanup()
    SM->>Component: remount
    Component->>Component: setup() (2번째)
    Note over Component: 진짜 mount

[!CAUTION] cleanup 이 비대칭이면 두 번째 setup 후 불일치 상태. 예: setup 에서 전역 카운터 ++, cleanup 에서 — 안 하면 2 가 남는다. StrictMode 의 의도가 정확히 이런 버그를 잡는 것.

”Effect 가 필요 없는” 패턴

You Might Not Need an Effect 의 핵심:

1. 다른 state 로부터 유도된 값 → useMemo (또는 그냥 계산)

// ❌ Effect
const [fullName, setFullName] = useState('');
useEffect(() => {
  setFullName(firstName + ' ' + lastName);
}, [firstName, lastName]);

// ✅ 렌더 중 계산
const fullName = firstName + ' ' + lastName;

2. event 응답 로직 → event handler

// ❌ Effect
useEffect(() => {
  if (submitted) {
    post('/api/cart', cart);
    setSubmitted(false);
  }
}, [submitted]);

// ✅ handler
function handleSubmit() {
  post('/api/cart', cart);
}

3. 상위 prop 변경 시 state reset → key prop

// ❌ Effect
useEffect(() => {
  setComment('');
}, [userId]);

// ✅ key reset
<!-- mdx-component: Profile -->

4. 외부 store 구독 → useSyncExternalStore

// ❌ Effect + 직접 구독
useEffect(() => {
  const unsubscribe = store.subscribe(setData);
  return unsubscribe;
}, []);

// ✅ useSyncExternalStore
const data = useSyncExternalStore(store.subscribe, store.getSnapshot);

진짜 Effect 가 필요한 경우

flowchart TD
    Q{외부 시스템과<br/>동기화?}
    Q -->|예| Yes[Effect 사용]
    Q -->|아니오| Q2{event 응답?}
    Q2 -->|예| Handler[Event Handler]
    Q2 -->|아니오| Q3{유도된 값?}
    Q3 -->|예| Memo[렌더 중 계산]
    Q3 -->|아니오| Q4{key reset?}
    Q4 -->|예| Key[key prop]
    Q4 -->|아니오| Q5{외부 구독?}
    Q5 -->|예| Sync[useSyncExternalStore]
    Q5 -->|아니오| Rare[정말 드물게 Effect]

진짜 Effect 사용처:

WebSocket / SSE 연결
외부 라이브러리 (D3, Mapbox, Chart.js) instance 의 attach/detach
브라우저 이벤트 listener (window.scroll, resize)
타이머 (setInterval, setTimeout)
document.title 같은 외부 mutation (단, React 19 의 Document Metadata 도 고려)

`useEffectEvent` (React 19.2)

Effect 안에서 최신 prop/state 를 의존성 없이 읽고 싶을 때.

문제:

function ChatRoom({ roomId, theme }) {
  useEffect(() => {
    const conn = createConnection(serverUrl, roomId);
    conn.on('connected', () => {
      showNotification('Connected!', theme);   // ❌ theme 가 dep 에 없으면 stale
    });
    conn.connect();
    return () => conn.disconnect();
  }, [roomId, theme]);   // theme 도 넣으면 *theme 바뀔 때마다 재연결*
}

해결 (React 19.2+):

function ChatRoom({ roomId, theme }) {
  const onConnected = useEffectEvent(() => {
    // 항상 *최신 theme* 사용. dep array 에 들어가지 *않는다*.
    showNotification('Connected!', theme);
  });

  useEffect(() => {
    const conn = createConnection(serverUrl, roomId);
    conn.on('connected', () => onConnected());
    conn.connect();
    return () => conn.disconnect();
  }, [roomId]);   // ✅ theme 는 dep 가 아니다
}

[!TIP] useEffectEvent 는 남용하면 안 된다. “이건 이벤트인데 effect 안에서 발생한다” 라는 드문 케이스 만. 일반 함수를 dep 에서 빼려고 wrap 하는 건 반패턴.

Effect 의 타이밍

sequenceDiagram
    participant React
    participant DOM
    participant Browser

    React->>React: render() (Virtual DOM 계산)
    React->>DOM: commit (실제 DOM 갱신)
    DOM->>Browser: paint (화면 그림)
    React->>React: useEffect setup (paint 후, 비동기)

`useEffect` vs `useLayoutEffect` vs `useInsertionEffect`

Hook	타이밍	사용
`useEffect`	paint 후	대부분의 동기화
`useLayoutEffect`	DOM mutation 후, paint 전 (동기)	측정 + 즉시 mutation (예: tooltip 위치)
`useInsertionEffect`	DOM mutation 전	CSS-in-JS 라이브러리 전용

gantt
    title 렌더 사이클의 effect 타이밍
    dateFormat ms
    axisFormat %S.%L

    section React
    render             :r1, 000, 5ms
    useInsertionEffect :i1, after r1, 1ms
    commit (DOM)       :c1, after i1, 3ms
    useLayoutEffect    :le, after c1, 2ms
    section Browser
    paint              :p1, after le, 8ms
    section React
    useEffect          :e1, after p1, 1ms

[!CAUTION] useLayoutEffect 는 동기적으로 paint 를 막는다. 비싼 작업 (큰 DOM 측정 등) 을 넣으면 애니메이션 끊김. 반드시 필요한 경우 (FOUC 방지, 즉시 위치 조정) 만 사용.

흔한 함정

1. Race condition (오래된 응답이 새 응답 덮음)

// ❌ id 가 빠르게 변하면 옛 응답이 마지막에 도착
useEffect(() => {
  fetch(`/api/users/${id}`).then(r => r.json()).then(setUser);
}, [id]);

// ✅ cleanup 플래그 또는 AbortController
useEffect(() => {
  let alive = true;
  fetch(`/api/users/${id}`).then(r => r.json()).then(u => {
    if (alive) setUser(u);
  });
  return () => { alive = false; };
}, [id]);

2. 무한 루프 (effect 안에서 setState)

// ❌ 무한 루프
useEffect(() => {
  setUser({ ...user, lastSeen: Date.now() });
}, [user]);   // user 가 deps 에 있고 effect 가 user 변경

→ 유도된 값이면 렌더 중 계산. 외부 시스템 동기화 라면 어떤 조건 으로 막을지 명시.

3. Stale closure

useEffect(() => {
  const id = setInterval(() => {
    console.log(count);   // 처음 mount 시점의 count 만 영원히
  }, 1000);
  return () => clearInterval(id);
}, []);

→ deps 에 count 추가, 또는 useEffectEvent / setState 함수형 갱신 으로.

4. 의존성을 수동으로 빠뜨림

useEffect(() => {
  fetchPosts(query);
  // eslint-disable-next-line   ❌
}, []);

→ 해결의 시작이 아니라 끝 이다. 의존성이 진짜 필요 없음 을 증명하거나, useEffectEvent 또는 useRef 로 의도 명시.

Event Loop 와의 관계

{}

{}

useEffect 는 paint 후 마이크로태스크 큐 에서 실행. 위 두 애니메이션은 언제 어떤 작업이 실행되는지 의 일반 직관. effect cleanup 과 setup 의 순서 가 왜 그렇게 정해졌는지 의 배경.

React 19.2 의 변화

기능	의미
`useEffectEvent` 정식	dep array 분리
`<Activity>` 의 `hidden` 모드	effect unmount 시뮬레이션 (배경 렌더)
ESLint 새 규칙	`set-state-in-effect`, `refs` 등 effect 안의 흔한 버그 자동 검출
React Compiler 1.0	effect 안의 reference 자동 memoize → dep array stable

김신건의 현장 메모

Effect 의 80% 는 필요 없는 경우. 첫 코드 리뷰 라운드에서 “이거 진짜 외부 시스템과 동기화 인가?” 를 물어보면 거의 반 이상 이 제거됨.
AbortController 가 fetch + effect 의 기본 패턴. 옛 axios.cancel 같은 라이브러리별 API 보다 web 표준 이 깔끔.
useEffectEvent 는 알림 전송 / 로깅 같은 side effect 하나만 분리할 때 가장 빛난다. 비즈니스 로직 을 wrap 하는 용도로 남용하면 추후 디버깅이 더 어렵다.
React Compiler 1.0 이 잡힌 뒤 useEffect 의 의존성 누락 버그 가 컴파일 타임에 잡힘. 런타임 버그가 빌드 에러로 옮겨감.

참고

공식: useEffect
멘탈 모델: Synchronizing with Effects
안 쓰는 패턴: You Might Not Need an Effect

[React] useMemo / useCallback / memo: 자동 시대의 수동 도구

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

세 가지 도구는 동일한 목표 (불필요한 재계산 / 재생성 / 재렌더 방지) 를 서로 다른 위치 에서 잡는다.

useMemo(fn, deps): 값 의 메모이제이션. deps 가 같으면 같은 값 반환.
useCallback(fn, deps): 함수 의 메모이제이션. deps 가 같으면 같은 함수 reference.
React.memo(Component): 컴포넌트 의 메모이제이션. props 의 얕은 비교 가 같으면 재렌더 skip.

[!IMPORTANT] React Compiler 1.0 (2025-10-07) 이후로 대부분의 새 코드 는 이 세 가지를 수동으로 쓰지 않는다. 컴파일러가 자동으로 최적 memoization 을 박는다. 이 페이지는 왜 / 언제 / 어떻게 수동으로 쓰는지 와 Compiler 시대의 escape hatch 를 정리.

자동 시대 (React Compiler 1.0+)

기본 사고는 “손 안 댄다”. 컴파일러가 조건부 return 이후 까지 memoize 가능. 사람이 직접 작성한 조잡한 useMemo 보다 정밀.

// React Compiler 가 켜진 환경
function UserList({ users, query }) {
  // 컴파일러가 자동으로 filter 결과를 memoize
  const filtered = users.filter(u => u.name.includes(query));

  // 컴파일러가 자동으로 onClick 을 stable reference 로
  const onClick = (id) => navigate(`/users/${id}`);

  return filtered.map(u => <!-- mdx-component: Item -->);
}

자세한 컴파일러 동작은 [[React Compiler]] 참고.

그래도 수동이 필요한 4 경우

1. Effect 의 dep 로 stable reference 보장

// 외부 라이브러리에 객체를 넘기는데, 매 렌더 새 객체면 effect 재실행
const config = useMemo(() => ({ url, headers }), [url, headers]);

useEffect(() => {
  client.subscribe(config);
  return () => client.unsubscribe(config);
}, [config]);

React Compiler 도 값이 effect dep 에 쓰이면 알아서 stable 화. 하지만 명시적 의도 가 필요할 때.

2. 외부 라이브러리에 동일 reference 약속

// 어떤 라이브러리가 "callback 이 바뀌면 재구독" 하는 경우
const onMessage = useCallback((msg) => {
  console.log(msg, user.name);
}, [user.name]);

useExternalSubscription(onMessage);   // 라이브러리가 reference 비교

3. 매우 비싼 계산의 명시적 캐시

// O(n²) 알고리즘 같은 비싼 계산
const layout = useMemo(() => {
  return expensiveLayoutCompute(items);   // 100ms+
}, [items]);

컴파일러도 자동 memoize 하지만, 의도 (이건 비싸니까 절대 다시 안 하길 바람) 를 코드로 표현.

4. 기존 코드의 변경 위험 최소화

기존 useMemo 가 박혀 있고 광범위한 영향 이 의심되면 제거하지 말고 유지. 컴파일러 출력이 미세하게 달라질 수 있음.

[!CAUTION] 기존 코드의 useMemo 를 컴파일러 도입했다고 일괄 제거 하면 동작 변경 가능. 새 코드에서만 안 쓰는 게 안전.

직관: closure 와 메모이제이션

useCallback 이 잡는 closure 의 동작 직관:

{}

{}

Closure 는 함수가 자기 외부 변수 reference 를 잡고 살아남게 한다. useCallback 이 같은 reference 를 유지한다는 건 closure 안에 잡힌 변수가 stale 일 수 있다는 의미. dep 가 정확히 필요.

referential equality

React 가 재렌더가 필요한지 판단하는 기준:

Object.is(prevProp, nextProp)   // 얕은 비교, 객체는 reference 비교

function Parent() {
  return <!-- mdx-component: Child -->;
  // 매 렌더 새 객체 → memo 컴포넌트도 매번 재렌더
}

function Parent() {
  const config = useMemo(() => ({ theme: 'dark' }), []);
  return <!-- mdx-component: Child -->;
  // 같은 reference → memo 컴포넌트는 skip
}

[!NOTE] Object.is(a, b) 는 === 와 거의 같지만 NaN === NaN (false) / 0 === -0 (true) 의 두 가지 경계 다르다. React 의 의도는 “의미적 동등” 에 가까움.

React.memo 의 메커니즘

sequenceDiagram
    autonumber
    participant Parent
    participant MemoChild

    Parent->>Parent: re-render
    Note over Parent: 새 props 계산
    Parent->>MemoChild: props (new reference)
    MemoChild->>MemoChild: 얕은 비교 (Object.is)
    alt props 같음
        MemoChild->>MemoChild: skip render
        MemoChild-->>Parent: 옛 결과 재사용
    else props 다름
        MemoChild->>MemoChild: re-render
    end

함정: function prop

function Parent() {
  return <MemoChild onClick={() => doX()} />;
  // 매 렌더 *새 함수* → MemoChild 매번 재렌더
}

function Parent() {
  const onClick = useCallback(() => doX(), []);
  return <!-- mdx-component: MemoChild -->;
  // ✅ stable reference
}

React.memo + 함수 prop 은 useCallback 짝 이 거의 필수. 짝 없이 memo 만 박으면 효과 없음 + 비교 비용만 추가.

진짜 효과가 있는가? (렌더 횟수 직관)

같은 컴포넌트 트리, memoize 사용 여부 별 재렌더 횟수 의 직관:

[!TIP] “React.memo 만 박았는데 왜 효과 없냐” 의 가장 흔한 원인이 함수 prop 의 매번 새 reference. memo + useCallback 짝이 동작 조건.

비용 분석

flowchart LR
    A["useMemo / useCallback<br/>오버헤드"] --> B["dep 비교 + 캐시 슬롯"]
    A --> C["closure 유지"]
    D["효과"] --> E["재계산 skip"]
    D --> F["하위 컴포넌트<br/>재렌더 skip"]
    B & C --> Cost
    E & F --> Benefit
    Cost{비용 < 효과?} -->|예| Use[유지]
    Cost -->|아니오| Remove[제거]

상황	효과
매우 간단한 계산 (3 줄)	오버헤드가 더 큼. 제거.
가벼운 함수 + memo 없는 자식	효과 없음. 제거.
비싼 계산 + memo 있는 자식	효과 큼. 유지.
effect dep 의 stable 보장	효과 명확. 유지.
React Compiler on	거의 모든 경우 자동. 새 코드에서 생략.

의존성 배열의 흔한 함정

1. 객체 / 배열 리터럴을 deps 안에

// ❌ 매 렌더 새 객체 → useMemo 가 매 렌더 다시
const result = useMemo(() => compute(opts), [{ a, b }]);

// ✅ 평탄화
const result = useMemo(() => compute(opts), [a, b]);

2. 함수 자체 를 dep 로

function Parent({ onSelect }) {
  // onSelect 가 매번 새 reference 라면 무의미
  const handler = useCallback(() => onSelect(id), [onSelect, id]);
}

→ 부모가 useCallback 으로 stable 보장 필요. 또는 useEffectEvent 로 분리.

3. 모든 것을 dep 에 넣기

const handler = useCallback(() => {
  doX(a, b, c, d, e, f);
}, [a, b, c, d, e, f]);

→ deps 가 매번 변하면 useCallback 효과 없음. 그냥 일반 함수 와 동일. 진짜 stable 한 일부 만 dep 에 두거나, useEffectEvent 로 분리.

React Compiler 와의 협업

Compiler 가 잡는 것:

모든 값 / 함수 의 자동 memoization
조건부 return 이후 까지 cover
조잡한 useMemo 보다 정밀

Compiler 가 못 잡는 것 (수동 도구 필요):

외부 라이브러리 가 dep 로 받는 객체
effect 의 dep 명시 stability (자주 잡지만 항상 은 아님)
극도로 비싼 계산 의 명시적 캐시 의도

[!IMPORTANT] Compiler 시대에 useMemo / useCallback 는 없어지는 게 아니라 escape hatch 가 된다. 기본 도구가 컴파일러, 세밀 제어가 수동.

새 코드 / 기존 코드 가이드

flowchart TD
    Q1{새 코드?}
    Q1 -->|예| Q2{Compiler 켜짐?}
    Q2 -->|예| New1[기본은 *수동 없이*<br/>+ escape hatch 만]
    Q2 -->|아니오| New2[수동 memo 필요시 사용]
    Q1 -->|아니오| Q3{Compiler 도입?}
    Q3 -->|예| Keep[기존 수동 memo *유지*<br/>제거하지 말 것]
    Q3 -->|아니오| Maintain[수동 memo 유지 + 개선]

깊이: dep 비교 알고리즘

React 의 useMemo / useCallback dep 비교:

// 의사 코드
function depsAreEqual(prev, next) {
  if (prev.length !== next.length) return false;
  for (let i = 0; i < prev.length; i++) {
    if (!Object.is(prev[i], next[i])) return false;
  }
  return true;
}

얕은 비교. 객체 안의 내용 비교가 아니다. reference 만. 그래서 dep 에 객체 면 매번 다르다고 인식.

흔한 함정

[!WARNING]

항상 모든 곳에 useMemo = 오버헤드만 추가, 이득 없음. 측정 후 결정.

useMemo 의 사이드 이펙트 = 안에 setState, console.log 등 순수 함수가 아니면 StrictMode 에서 두 번 호출 시 문제 발생.

React.memo 만 박고 함수 prop useCallback 없음 = 효과 없음.

useMemo 의 추적 누락 = 컴파일러는 eslint-plugin-react-hooks 로 dep 누락 잡는다. eslint 출력 무시 금지.

김신건의 현장 메모

기존 수동 memoization 이 깔린 코드베이스 에 React Compiler 도입 시: 기존 코드는 그대로 두고 새 코드에서만 수동 생략. 동작이 다를 수 있는 영역을 최소화.
useMemo 가 정말 필요한지 측정 의 가장 빠른 방법: React DevTools Profiler 에서 해당 컴포넌트의 commit 횟수 를 보고 memo 추가 전후 비교. 눈에 보이지 않는 효과 를 수치로 결정.
useCallback + 외부 라이브러리 조합에서 가장 자주 부딪힌 함정: 라이브러리가 내부적으로 deps 비교 안 하면 useCallback 의 의미가 전혀 없다. 라이브러리 코드를 확인.
서버 컴포넌트 (RSC) 에서는 useMemo / useCallback 자체가 불가. 클라이언트 컴포넌트 ('use client') 안에서만 유효.

참고

공식: useMemo, useCallback, memo
React Compiler: 블로그

[비교] JPA EAGER vs Rails eager_load

koa (김신건) — Tue, 23 Jun 2026 00:00:00 GMT

정의

JPA 와 Rails 는 둘 다 “eager” 라는 용어를 ORM 의 연관 로딩 전략에 사용한다. 이름은 비슷하지만 의미는 정반대.

JPA FetchType.EAGER: 매핑 선언 시점에 영구 설정. 그 entity 를 조회할 때마다 항상 자동으로 함께 로드. 끄는 게 권장.
Rails eager_load: 쿼리 시점에 옵트인. 그 쿼리에서만 JOIN 으로 함께 로드. 권장 패턴.

이름이 같아 혼동하기 쉬워 별도 페이지로 정리한다.

1줄 비교

측면	JPA `EAGER`	Rails `eager_load`
선언 위치	Entity 매핑 (`@ManyToOne(fetch=EAGER)`)	Query 호출 (`.eager_load(:assoc)`)
적용 범위	그 entity 의 모든 조회	그 쿼리만
변경 가능성	코드 수정 + 재배포	쿼리마다
권장 사용	거의 항상 비권장	권장 (또는 includes)
기본값	`@ManyToOne` 은 EAGER (위험)	명시 안 함 (lazy)
실행 방식	즉시 SELECT (별도 또는 JOIN)	LEFT OUTER JOIN 단일 쿼리

JPA EAGER 의 의미

@Entity
class Post {
    @ManyToOne(fetch = FetchType.EAGER)   // ← 기본값 (위험)
    @JoinColumn(name = "author_id")
    User author;
}

List<Post> posts = em.createQuery("SELECT p FROM Post p", Post.class).getResultList();
// → posts SELECT 1번 + 각 post 의 author SELECT N번 = N+1
// 또는 Hibernate 의 batch fetch 가 켜있으면 IN 절로 일부 묶임

“Post 가 어디서 조회되든 author 도 함께 로드”. 매핑이 영구. 끄려면 코드 수정.

위험:

N+1 폭탄
깊은 그래프 (Post → Comment → User → Profile) 가 의도치 않게 전부 로드
끌 수 없음 (LAZY 로 매핑 변경 후 재배포 필요)

규칙: 모든 연관 LAZY 선언, 쿼리마다 필요한 것만 fetch join / EntityGraph / @BatchSize 로 명시. [[spring-jpa-fetch-type]] 참고.

Rails eager_load 의 의미

class Post < ApplicationRecord
  belongs_to :author, class_name: 'User'
end

# 기본 (lazy)
posts = Post.all
posts.each { |p| puts p.author.name }   # N+1

# eager_load 옵트인
posts = Post.eager_load(:author)
# → 1쿼리: SELECT p.*, u.* FROM posts LEFT OUTER JOIN users ON ...
posts.each { |p| puts p.author.name }   # 추가 쿼리 없음

“이 쿼리 한 번만 author 도 함께”. 쿼리 시점 결정. 다음 쿼리는 lazy.

권장 패턴: 연관은 lazy by default, 필요할 때만 includes/preload/eager_load 명시. [[rails-query-optimization]] 참고.

정확한 매핑

JPA 와 Rails 의 개념적 대응:

Rails 메서드	해당 JPA 패턴	발생 쿼리
`preload(:assoc)`	`@BatchSize` 또는 `JOIN FETCH` 안 쓰는 explicit 2-쿼리	2 쿼리 (부모 + 자식 IN)
`eager_load(:assoc)`	`JOIN FETCH p.assoc` JPQL	1 쿼리 (LEFT OUTER JOIN)
`includes(:assoc)`	(없음)	preload 또는 eager_load 자동
`references(:assoc)`	(없음, JPQL 의 JOIN FETCH 와 유사)	eager_load 강제

JPA 의 FetchType.EAGER 는 Rails 에 직접적 대응 없음. 굳이 비유하면 association 정의에 eager_load(:assoc) 를 default scope 로 박아두는 것 (안티패턴).

Rails 의 “EAGER” 라는 단어

Rails 문서 / 커뮤니티에서 “eager loading” 은 일반적으로 includes / preload / eager_load 셋을 통칭. “eager 로 가져온다” = “lazy 안 하고 미리 가져온다” 의미.

JPA 의 EAGER 는 fetch type = 영구 매핑 속성. 다른 개념.

권장 패턴 비교

// JPA: lazy + 쿼리마다 명시
@Entity
class Post {
    @ManyToOne(fetch = FetchType.LAZY)
    User author;
}

@Query("SELECT p FROM Post p JOIN FETCH p.author")
List<Post> findAllWithAuthor();

# Rails: 기본 lazy + 쿼리마다 명시
class Post < ApplicationRecord
  belongs_to :author, class_name: 'User'
end

def self.with_author
  includes(:author)
end

두 ORM 모두 lazy by default + 쿼리 시점에 fetch 선택 이 best practice. JPA 가 기본을 EAGER 로 잘못 정한 게 함정.

N+1 디버깅 도구

항목	JPA / Hibernate	Rails
로그	`org.hibernate.SQL=DEBUG`	`ActiveRecord::Base.logger`
정적 분석	Hypersistence Utils	bullet gem
자동 감지	(수동)	`strict_loading` (Rails 6.1+)
Profiler	p6spy, datasource-proxy	rack-mini-profiler
인덱스 검사	Hibernate Statistics	EXPLAIN ANALYZE

bullet gem 처럼 자동 N+1 알림 도구가 JPA 진영엔 약함. 직접 통합 테스트에서 Statement count 측정.

함정 비교

JPA 함정

@ManyToOne 기본 EAGER: 명시적으로 LAZY 안 하면 위험
@OneToOne 양방향 LAZY 안 됨 (proxy 못 만듦): bytecode enhancement 또는 optional=false
컬렉션 fetch join + Pageable = in-memory paging: OOM 위험
OSIV (Open Session In View) 가 LAZY 함정 가림: 운영에선 끄기 권장 spring.jpa.open-in-view=false

Rails 함정

find_by + includes 일부 버전에서 includes 무시: .where().first 패턴 권장
uniq/distinct + includes 의 row count 미묘함
select 시 FK 누락: select(:name).includes(:school) 깨짐
polymorphic 은 JOIN 불가, preload 강제

작은 결과 / 큰 결과의 전략

결과 크기	JPA 권장	Rails 권장
부모 < 10	JOIN FETCH	eager_load
부모 < 1000, 자식 비대	2 쿼리 (`@BatchSize`)	preload
Pageable	EntityGraph + slice (collection 제외)	includes + paging
깊은 nested	단계별 explicit fetch	preload 단계 분리

정리

질문	답
JPA EAGER 와 Rails eager_load 가 같은 뜻인가?	아니다. 이름만 같다.
JPA EAGER 사용 권장하나?	아니다. 모든 연관 LAZY.
Rails eager_load 사용 권장하나?	그렇다. lazy default + 쿼리마다 명시.
둘 다 N+1 해결책인가?	Rails eager_load 는 명백한 해결책. JPA EAGER 는 종종 N+1 의 원인.

이름이 미묘하게 같아서 “EAGER 면 빠른 것” 으로 단순화하지 말 것. 두 ORM 의 정반대 권장 사항을 기억.

Astro

koa (김신건) — Sat, 23 May 2026 00:00:00 GMT

개요

Astro 는 콘텐츠 중심 사이트를 위한 정적 사이트 생성기다. Islands Architecture로 필요한 부분만 hydration 하기 때문에 기본 페이지 로드가 빠르다.

이 블로그에서의 역할

마크다운 / MDX 콘텐츠 렌더링
자체 remark 플러그인으로 위키링크 자동 변환 ([[BrainDB]] 참고)
[[D3]] 기반 그래프 페이지의 React Island 호스팅
GitHub Actions를 통한 정적 빌드 → GitHub Pages 배포

참고

공식 문서: https://docs.astro.build
Content Collections: https://docs.astro.build/en/guides/content-collections/

BrainDB

koa (김신건) — Sat, 23 May 2026 00:00:00 GMT

개요

BrainDB 는 마크다운 콘텐츠를 데이터베이스처럼 다룰 수 있게 해주는 [[Astro]] 통합 라이브러리다.

제공하는 것

위키링크 자동 처리 (@braindb/remark-wiki-link)
backlink 추출
콘텐츠 그래프 데이터 (이 블로그의 그래프 페이지 기반)
깨진 링크 감지

이 블로그에서의 사용

원래 BrainDB 를 astro.config.mjs 의 integrations 에 추가해서 쓰려고 했으나, 의존 패키지인 better-sqlite3 가 Node.js 26 과 호환되지 않아 빌드가 깨졌다. 그래서 결국 작은 커스텀 remark 플러그인(src/plugins/remark-wikilink.mjs)으로 위키링크 처리, backlink, 그래프 데이터를 직접 구현했다.

BrainDB 가 제공하던 핵심 기능만 추려 보면 그 양이 많지 않아서, 직접 작성하는 편이 의존성도 가볍고 디버깅도 쉬웠다.

D3

koa (김신건) — Sat, 23 May 2026 00:00:00 GMT

개요

D3.js 는 데이터 기반의 SVG / Canvas 시각화 라이브러리다. 이 블로그의 그래프 페이지는 D3 의 forceSimulation 으로 노드를 배치한다.

사용한 force

forceLink, 노드 사이의 연결 거리
forceManyBody, 노드 간 반발력 (음수 strength)
forceCenter, 전체를 화면 중앙으로 끌어당김
forceCollide, 노드끼리 겹치지 않게

김신건의 로그 - 위키 / frameworks

Pagefind: 정적 사이트 전문 검색

정의

특징

Astro 통합

사용 (직접)

필터링

참고

[Frontend] React 19.x: Actions, Activity, RSC, Foundation

정의

버전 매트릭스

Actions: 폼/네트워크 워크플로의 새 표준

Server Components 정식화

ref 가 prop 이 되다

Document Metadata

Asset Loading 과 preload / preinit

use() API: Promise / Context 의 일관된 read

19.2 의 큰 4가지

1. <Activity>: pre-render + 상태 보존

2. useEffectEvent

3. Performance Tracks (Chrome DevTools)

4. Partial Pre-rendering

사라지는 것들

보안: 2025-12 RSC 사건

React Foundation

React 17/18 에서 19 로

김신건의 현장 메모

관련 위키

참고

[Frontend] React Compiler 1.0: 자동 memoization 의 새 표준

정의

왜 컴파일러인가?

컴파일러는 어떻게 동작하는가

컴파일 모드와 디렉티브

설정 (babel.config.js)

빌드 도구 매트릭스

ESLint 통합

useMemo / useCallback / React.memo 는 이제 필요 없나?

프로덕션 결과

v1.0 까지의 타임라인

다음

관련 위키

참고

[React] Component Composition: Props, Children, Render Prop, HOC, Compound

정의

Stateless vs Stateful

패턴 카탈로그

1. Props: 가장 기본

2. Children: 임의 JSX 임베드

다중 children: 명명 slot

3. Render Prop (옛 패턴)

4. HOC (Higher Order Component) (옛 패턴)

5. Compound Component: 짝 컴포넌트

6. Slot / Portal

7. Context: 트리 전체에 값 공유

8. Custom Hook: 로직만 추출

패턴 선택 가이드

Inheritance 가 왜 안 좋은가

컴포넌트 계층의 얕음

19+ 의 새 기능들과 composition

흔한 함정

김신certificate의 현장 메모

관련 위키

참고

[React] Lifecycle: Mount / Update / Unmount, StrictMode, Activity, RSC

정의

일반 라이프사이클의 직관

함수 컴포넌트의 3 단계

1. Mount

2. Update

3. Unmount

클래스 vs 함수 컴포넌트 매핑

Strict Mode 의 double invoke

무엇이 잡히는가

Production 에서는?

React 19.2 의 `

Server Components (RSC) 의 lifecycle

CSR / SSR / SSG / RSC 모드 비교

Hydration: 서버 HTML 과 클라이언트의 합체

Hydration mismatch

Asset Loading 과 `preload` / `preinit`

`use()` API: Promise / Context 의 일관된 read

1. `<Activity>`: pre-render + 상태 보존

2. `useEffectEvent`

설정 (`babel.config.js`)

`useMemo` / `useCallback` / `React.memo` 는 이제 필요 없나?

`useEffectEvent` (React 19.2)

`useEffect` vs `useLayoutEffect` vs `useInsertionEffect`