<div id="readability-page-1" class="page"><div>
 <div id="SE-b070f469-e28e-4196-a2a3-7bcb5440c70a">
 드디어 마지막 챕터입니다. 1장에서 우리는 React Compiler를 켠 채로 시작했고, 그 뒤로 22개 챕터 내내 useMemo·useCallback·React.memo를 단 한 번도 손으로 쓰지 않았습니다. 다른 React 튜토리얼이라면 한참을 할애했을 그 세 가지를요.
​
이번 챕터는 그 약속을 결산합니다. 컴파일러가 정확히 무엇을 자동화하는지, 왜 우리가 그것들을 안 써도 됐는지, 그리고 컴파일러가 무엇을 여전히 못 하는지. 이걸 이해하면 이 시리즈가 왜 문법보다 멘탈모델을 강조해왔는지도 함께 보입니다.
​
​
옛날의 고통 — 손으로 하던 메모이제이션
컴파일러가 없던 시절, React 앱의 성능을 챙기려면 수동 메모이제이션을 해야 했습니다. 어떤 모습이었는지 봅시다.

 </div> <div id="SE-cc47cf54-c5fa-4b29-ba4a-a4e64cab354e">
 import { useMemo, useCallback, memo } from 'react';

const ExpensiveComponent = memo(function ExpensiveComponent({ data, onClick }: Props) {
 const processedData = useMemo(() =&gt; {
 return expensiveProcessing(data); // 비싼 계산은 useMemo로 캐시
 }, [data]);

 const handleClick = useCallback((item: Item) =&gt; {
 onClick(item.id); // 함수는 useCallback으로 캐시
 }, [onClick]);

 return (
 &lt;div&gt;
 {processedData.map((item) =&gt; (
 &lt;Item key={item.id} onClick={() =&gt; handleClick(item)} /&gt;
 ))}
 &lt;/div&gt;
 );
});
 </div> <div id="SE-58f998b7-2013-4775-a612-df0dda065047">
 memo, useMemo, useCallback이 한 컴포넌트에 다 등장합니다. 문제는 이게 번거롭고, 코드를 어지럽히고, 무엇보다 틀리기 쉽다는 점입니다.
​
위 코드에는 사실 미묘한 버그가 숨어 있습니다. handleClick을 useCallback으로 감쌌는데도, 정작 onClick={() =&gt; handleClick(item)}의 화살표 함수는 매 렌더마다 새로 만들어집니다. 그래서 Item은 매번 새 onClick을 받아 결국 다시 렌더되고, 애써 한 메모이제이션이 깨집니다. 이런 함정은 숙련된 개발자도 자주 빠집니다. 수동 메모이제이션은 "제대로 하기" 자체가 어렵습니다.

 </div> <div id="SE-f77915bf-a876-4089-9e89-6dab293d4cea">
 ​
React Compiler를 켜면, 위와 똑같은 동작을 메모이제이션 없이 이렇게 씁니다.

 </div> <div id="SE-2483f699-6f49-43e2-83be-32ec5706219d">
 // memo·useMemo·useCallback이 전부 사라졌다
function ExpensiveComponent({ data, onClick }: Props) {
 const processedData = expensiveProcessing(data);

 const handleClick = (item: Item) =&gt; {
 onClick(item.id);
 };

 return (
 &lt;div&gt;
 {processedData.map((item) =&gt; (
 &lt;Item key={item.id} onClick={() =&gt; handleClick(item)} /&gt;
 ))}
 &lt;/div&gt;
 );
}
 </div> <div id="SE-59c994b1-e796-4a37-8370-c76beba43a5b">
 코드가 훨씬 깨끗하죠. 그리고 컴파일러는 빌드 시점에 이 코드를 분석해, 필요한 메모이제이션을 자동으로, 그리고 사람이 손으로 한 것보다 더 정확하게 끼워 넣습니다. 앞서 본 "화살표 함수 때문에 깨지던 메모이제이션"도 컴파일러는 올바르게 처리해서, Item은 onClick이 진짜로 바뀔 때만 다시 렌더됩니다.
​
컴파일러가 자동화하는 건 크게 두 가지입니다.
​
① 불필요한 리렌더 차단. 
React는 기본적으로 어떤 컴포넌트의 state가 바뀌면 그 자식 전부를 다시 렌더합니다. 바뀐 것과 무관한 자식까지요. 컴파일러는 "이 자식의 결과는 그대로 재사용해도 된다"를 판단해, 바뀐 부분만 다시 렌더되게 만듭니다(이른바 fine-grained reactivity).
​
② 비싼 계산 캐시. 
렌더링 중에 무거운 계산(expensiveProcessing(data) 같은)이 있으면, 입력이 안 바뀐 경우 이전 결과를 재사용합니다. 우리가 useMemo로 하던 바로 그 일이죠.
​
1장에서 컴파일러가 켜졌는지 확인하던 방법, 기억하나요? React DevTools에서 최적화된 컴포넌트 옆에 Memo ✨ 배지가 뜨는 것 말입니다. 그게 바로 컴파일러가 이 메모이제이션을 자동으로 넣었다는 증거입니다.

 </div> <div id="SE-78d601e0-a814-4246-aaf7-9563f7493714">
 ​
컴파일러가 이렇게 마음 놓고 결과를 재사용할 수 있는 근거가 무엇일까요? 바로 컴포넌트가 순수하다는 가정입니다.
​
"같은 입력이면 같은 출력"이 보장되니까, 컴파일러는 "입력이 안 바뀌었으면 출력도 같을 테니 이전 결과를 재사용해도 안전하다"고 판단할 수 있습니다. 만약 컴포넌트가 순수하지 않다면(렌더링 중에 바깥을 바꾼다면), 이 재사용이 틀린 결과를 낳을 수 있죠.
​
비순수 컴포넌트를 다시 떠올려봅시다.

 </div> <div id="SE-97434459-343b-4b85-bd69-775847168611">
 let count = 0;

// 🔴 비순수 — 렌더링 중 외부 변수를 바꾼다
function Counter() {
 count = count + 1; // 부수효과! 호출할 때마다 결과가 달라진다
 return &lt;p&gt;{count}&lt;/p&gt;;
}
 </div> <div id="SE-da3261d1-0cc8-4d8c-8136-aef58aebfd19">
 이 Counter는 "같은 입력이면 같은 출력"이라는 약속을 깹니다. 호출 횟수에 따라 count가 달라지니까요. 컴파일러는 컴포넌트가 순수하다고 가정하고 결과를 재사용하는데, 이렇게 순수하지 않으면 그 재사용이 어긋난 값을 만듭니다. 반대로, 순수하게 짜면 — 예를 들어 값을 props로 받으면 — 컴파일러가 마음 놓고 최적화할 수 있습니다.
 </div> <div id="SE-25955f56-9ac8-4ff6-807e-5c9e38478cda">
 // ✅ 순수 — 입력(props)만으로 계산 → 컴파일러가 안전하게 최적화
function Counter({ count }: { count: number }) {
 return &lt;p&gt;{count}&lt;/p&gt;;
}
 </div> <div id="SE-a9c7d7d8-0593-43a7-b386-f681ea64292d">
 그래서 컴파일러는 규칙(Rules of React)을 어긴 컴포넌트는 최적화를 건너뜁니다. 안전을 위해서요. ESLint 규칙(eslint-plugin-react-hooks)이 "이 컴포넌트는 규칙을 어겨서 최적화할 수 없다"고 정확히 알려줍니다. 나머지 멀쩡한 컴포넌트는 그대로 최적화되고요.
​
여기서 시리즈의 핵심 메시지가 드러납니다. 순수성·불변성은 "컴파일러를 위한 트릭"이 아닙니다. 원래부터 좋은 React 코드의 조건이었고, 컴파일러는 그 좋은 코드에 성능이라는 보상을 자동으로 얹어줄 뿐입니다.

 </div> <div id="SE-0d66ae5a-82d3-4f0f-b608-4590f6c2dcd6">
 ​
컴파일러를 만능으로 오해하면 안 됩니다. 컴파일러는 올바르게 짠 코드를 더 빠르게 만들 뿐, 설계 자체를 고쳐주지는 않습니다. 이 시리즈가 다룬 문제들과 연결해보면 경계가 분명해집니다.
​
<ul><li>잘못된 상태 설계는 못 고친다. 파생 상태(계산 가능한 값을 state로 둠), 불필요한 useEffect(파생 상태를 이펙트로 동기화) 같은 구조적 문제는 컴파일러의 영역 밖입니다. 컴파일러는 메모이제이션을 넣을 뿐, "이 state를 없애라"라고 코드를 다시 짜주지는 않습니다. 불필요한 렌더 캐스케이드와 stale 프레임은 그대로 남습니다.
</li><li>렌더링 우선순위는 못 정한다. "이 갱신이 저 갱신보다 급한가"는 사용자 경험에 대한 의도라서 컴파일러가 알 수 없습니다. useTransition·useDeferredValue는 여전히 우리 손에 있습니다.
</li><li>비순수 컴포넌트는 고치지 않고 건너뛴다. 규칙을 어긴 코드는 최적화 대상에서 빠질 뿐, 컴파일러가 순수하게 바꿔주지 않습니다.
</li><li>React 컴포넌트·훅만 최적화한다. 일반 유틸 함수는 대상이 아니고, 메모이제이션이 여러 컴포넌트 사이에 공유되지도 않습니다. 정말 무거운 순수 함수를 여러 곳에서 쓴다면, React 바깥에서 따로 캐싱하는 게 나을 수 있습니다.
</li></ul>​
한마디로, 컴파일러는 "성능"이라는 한 가지 부담만 덜어줍니다. 상태 설계, 데이터 흐름, 순수성 — 코드의 "올바름"은 여전히 사람의 몫입니다. 그래서 이 시리즈가 문법 암기보다 멘탈모델에 무게를 둔 겁니다.

 </div> <div id="SE-df8ce8b6-7d3e-4769-9e8b-0ccdc75bef8e">
 "그래도 useMemo를 써야 하지 않나요?"
 </div> <div id="SE-5eaeedc4-e6a4-42d3-989f-16f0aa01c91e">
 ​
가장 많이 나오는 불안입니다. 결론부터 말하면, 새 코드에서는 컴파일러에 맡기고, 손으로 메모이제이션하지 마세요. 컴파일러의 메모이제이션은 대개 사람이 한 것만큼, 혹은 더 정확합니다.
​
다만 useMemo·useCallback이 사라진 건 아닙니다. "정밀한 제어가 필요한 탈출구"로 남아 있습니다. 대표적인 실제 사례 하나는, 메모이즈한 값을 useEffect의 의존성으로 쓸 때입니다. 그 값의 참조가 안정적이어야 이펙트가 불필요하게 다시 실행되지 않으니까요. 이런 특정한 이유가 있을 때만 꺼내 쓰면 됩니다.
​
멘탈모델의 전환: 예전엔 "성능을 위해 일단 memo로 감싸고 보자"가 기본값이었습니다. 이제는 "기본적으로 안 쓰고, 분명한 이유가 있을 때만 쓴다"가 기본값입니다. 옛 코드의 메모이제이션을 무리해서 걷어낼 필요는 없지만(걷어내면 컴파일 결과가 달라질 수 있어 테스트가 필요합니다), 새로 짤 때는 컴파일러를 믿으세요.
​
문제가 의심되는 컴포넌트는 "use no memo" 지시어로 잠시 최적화에서 제외해 디버깅할 수도 있습니다. 하지만 이건 임시방편이고, 근본 원인(대개 규칙 위반)을 고친 뒤 지시어를 제거하는 게 맞습니다.

 </div> <div id="SE-c846b7ae-0de2-4143-8e0c-84ab90f955c4">
 ​
<ul><li>React Compiler — Introduction — React 공식 문서 (확인: 2026-06-14)
</li><li>React Compiler v1.0 — React 공식 블로그, 2025-10-07
</li><li>Rules of React — React 공식 문서 (확인: 2026-06-14)
</li></ul>
 </div> </div></div>

개발하는 기획자. 기획하는 개발자.

드디어 마지막 챕터입니다. 1장에서 우리는 React Compiler를 켠 채로 시작했고, 그 뒤로 22개 챕터 내내 useMemo·useCallback·React.memo를 단 한 번도 손으로 쓰지 않았습니다. 다른 React 튜토리얼이라면 한참을 할애했을 그 세 가지를요. 이번 챕터는 그 약속을 결산합니다. 컴파일러가 정확히 무엇을 자동화하는지, 왜 우리가 그것들을 안 써도 됐는지, 그리고 컴파일러가 무엇을 여전히 못 하는지. 이걸 이해하면 이 시리즈가 왜 문법보다 멘탈모델을 강조해왔는지도 함께 보입니다. 옛날의 고통 — 손으로 하던 메모이제이션 컴파일러가 없던 시절, React 앱의 성능을 챙기려면 수동 메모이제이션을 해야 했습니다. 어떤 모습이었는지 봅.......

React Compiler 제대로 이해하기 — 우리가 useMemo를 안 쓴 이유

댓글