'왜 아직도 느리지?' React 개발자라면 한 번쯤 겪어봤을 그 순간이 있다. React.memo를 컴포넌트마다 붙이고, useCallback으로 함수를 전부 감쌌는데도 앱은 여전히 버벅인다. dev.to에 올라온 React 성능 최적화 실전 가이드가 짚는 핵심은 바로 이 지점이다. 최적화 도구를 먼저 꺼내는 것 자체가 문제라는 것.
가장 먼저 점검해야 할 것은 상태(state)의 위치다. 루트 컴포넌트에 color 상태 하나가 올라가 있으면, 색상 피커를 건드릴 때마다 HeavyChartComponent와 ComplexTable 전체가 다시 렌더링된다. 해법은 React.memo가 아니다. 상태를 실제로 그것을 필요로 하는 컴포넌트 안으로 내려보내는 것—State Colocation이다. ColorPicker라는 독립 컴포넌트로 분리하면 차트와 테이블은 아예 리렌더링 대상에서 빠진다. 메모이제이션을 쓰기 전에 컴포넌트 트리 설계를 먼저 손봐야 하는 이유다.
상태를 내릴 수 없는 상황이라면 children 합성 패턴이 다음 카드다. 스크롤 위치를 추적하는 ScrollContainer가 있어도, HeavyContent를 children prop으로 전달하면 React는 부모 상태가 바뀌어도 children을 재렌더링하지 않는다. children은 App에서 이미 만들어진 prop이기 때문이다. 이 두 가지—상태 내리기와 children 합성—만 제대로 적용해도 React.memo 없이 체감 성능이 달라지는 경우가 많다.
목록 렌더링은 다른 차원의 문제다. 5,000개 DOM 노드를 한 번에 그리면 메인 스레드가 잠긴다. @tanstack/react-virtual의 DOM 가상화는 뷰포트 안에 보이는 항목만 실제로 렌더링하고, 나머지는 CSS transform으로 위치만 잡아둔다. 번들 크기 문제는 React.lazy와 Suspense로 라우트 단위 코드 스플리팅을 적용해 해결한다. 로그인 페이지에서 대시보드 번들까지 미리 내려받을 이유가 없다. 그리고 실시간 검색 필터처럼 입력과 렌더링이 경합하는 상황엔 useTransition으로 무거운 업데이트를 비긴급(non-urgent) 으로 분류하면, 타이핑 자체는 즉각 반응하면서 결과 목록은 백그라운드에서 업데이트된다.
이 최적화 흐름을 AI 에이전트와 연결해서 보면 흥미로운 구조가 보인다. 같은 주 Dev Signal 뉴스레터는 Claude Opus 5의 아키텍처 변화를 이렇게 정리했다. 이전 모델들은 멀티파일 리팩터링을 위해 오케스트레이션 스캐폴딩이 필요했다. 부분 출력을 체이닝하는 레이어를 직접 짜야 했다는 뜻이다. Opus 5는 이 단계를 모델 내부로 흡수했다. 완성된 구현을 직접 뱉어내고, reasoning이 기본 활성화되며, 장기 태스크를 별도 조율 없이 처리한다.
이게 프론트엔드 성능 최적화와 어떻게 연결되느냐. 에이전트에게 '이 컴포넌트 트리에서 불필요한 리렌더링 경로를 찾아서 상태 배치를 재설계해줘'라고 요청할 때, 이전 모델은 파일 하나씩 분석하고 부분 제안을 내놓는 방식이었다면, Opus 5는 컴포넌트 간 의존 관계를 추론하고 실제로 리팩터링된 전체 구조를 돌려준다. 성능 병목 분석→상태 설계 재조정→코드 적용까지의 루프를 에이전트 한 번으로 돌릴 수 있게 된 것이다. 단, 보안 감사 패턴 일부는 안전 분류기에 걸릴 수 있으니 AI Gateway의 폴백 체인(Claude Sonnet 5 또는 4.8)을 미리 설정해두는 것이 실무 팁이다.
그 반대편에 완전히 다른 철학이 하나 있다. 단일 HTML 파일로 만든 CD 계산기 사례는 '프레임워크가 없을 때 진짜 UI 설계가 무엇인지'를 역설적으로 보여준다. 490줄 CSS, 460줄 JS, 라이브러리 없음. 상태는 DOM 입력값이 곧 단일 진실 소스다. 요구사항이 변하지 않는다면, 컴포넌트 경계도 상태 관리 라이브러리도 번들러도 순수 오버헤드다. 이 관점은 성능 최적화의 핵심 질문을 다시 상기시킨다. 이 추상화가 지금 이 문제에 실제로 필요한가?
특히 이 프로젝트의 UI 결정이 인상적이다. 처음엔 카드와 드롭섀도로 구성된 '일반적인 앱 UI'를 만들었지만, 금융 도구에 어울리지 않는다는 직관이 들었다. 여러 번 수정 끝에 도달한 결론은 '영수증 느낌'이었다. 크림색 배경, 세리프 서체 두 가지(헤딩용 Cormorant Garamond, 본문용 Newsreader), 숫자 정렬을 위한 JetBrains Mono, 그리고 4% 불투명도의 SVG 노이즈 텍스처. 사용자가 돈을 다루는 맥락에서 첫 반응은 감탄이 아니라 의심이라는 것을 UI가 먼저 이해해야 한다는 것.
세 흐름을 하나의 설계 원칙으로 묶으면 이렇게 된다. 도구를 먼저 꺼내지 말 것. React 성능 문제의 1순위 해법은 memo가 아니라 상태 위치의 재검토다. AI 에이전트 성능의 1순위 조건은 모델 스펙이 아니라 에이전트에게 넘길 태스크의 범위 설계다. UI 품질의 1순위 판단 기준은 미학이 아니라 사용자가 그 맥락에서 실제로 느끼는 감정이다. 세 영역 모두 추상화나 도구를 쌓기 전에 문제 자체를 정확히 정의하는 것이 먼저라는 같은 원칙을 가리키고 있다.
Claude Opus 5가 멀티파일 리팩터링을 단일 패스로 처리하게 된 지금, 프론트엔드 개발자가 에이전트에게 위임할 수 있는 범위는 분명히 넓어졌다. 그러나 에이전트가 아무리 강해져도, 잘못된 위치의 상태를 memo로 덮으라는 지시를 받으면 그대로 실행한다. 더 강한 모델을 더 잘 쓰려면 더 좋은 질문이 필요하다. '이 컴포넌트를 최적화해줘'가 아니라 '이 렌더링 경로에서 상태 배치가 잘못된 지점을 찾아서 구조부터 다시 설계해줘'—이 차이가 에이전트 시대의 프론트엔드 개발자 역량 차이가 될 것이다.