SK-hynix MAPS: 23만 rows 조회 지연 5초 → 1초로 줄이기

SK-hynix에서 MAPS(Manufacturing Advanced Planning System) 프로젝트를 4개월간 진행했다. 그 중 가장 기억에 남는 작업이 이 성능 개선이었다.

문제 상황

특정 조회 화면에서 데이터를 불러올 때 사용자 체감 로딩 시간이 5초가 넘었다. 데이터 건수가 최대 23만 개였고, 조회할 때마다 눈에 띄게 느렸다.

처음엔 "데이터가 많으니까 느린 거 아냐?" 하고 넘어갈 뻔했는데 직접 파고들어보기로 했다.

원인 분석

1. API 응답 구조 문제

서버에서 내려오는 응답이 화면에서 필요한 것보다 훨씬 많은 필드를 포함하고 있었다. 23만 rows 각각에 불필요한 컬럼이 수십 개씩 붙어오니까 네트워크 페이로드 자체가 컸다.

2. 불필요한 렌더링

데이터가 들어올 때마다 컴포넌트 전체가 리렌더링되고 있었다. 부모 state가 바뀌면 자식들이 줄줄이 다시 렌더링되는 구조였다.

3. 전체 데이터 일괄 조회

페이지네이션이나 가상화 없이 전체 데이터를 한 번에 불러오고 있었다.

개선 작업

API 응답 최적화 — 화면에서 실제로 쓰는 필드만 내려오도록 API 응답을 수정했다. 이것만으로 페이로드 크기가 크게 줄었다.

렌더링 구조 개선 — 불필요하게 리렌더링되던 컴포넌트를 React.memo와 useMemo로 최적화했다.

// 전: 매 렌더링마다 새로 계산
const processedData = data.map(item => transform(item));

// 후: 데이터 바뀔 때만 계산
const processedData = useMemo(() => data.map(item => transform(item)), [data]);

결과

지표	개선 전	개선 후
조회 로딩 시간	~5초	~1초
사용자 체감	답답함	자연스러움

배운 것

성능 문제는 "느리다"는 현상만 보면 원인을 못 찾는다. 네트워크 탭, React DevTools Profiler를 같이 봐야 어디서 시간이 가장 많이 소비되는지 알 수 있다.

23만 개 데이터를 프론트에서 다 받는 구조 자체가 근본적으로 맞지 않는다. API 레벨에서 필터링과 페이지네이션을 먼저 적용하는 게 맞는 방향이다.