웹 리스트 성능이 안 좋을 때 진단 기준

혼자 개발할수록 확인한 값과 바꾼 값을 따로 남기는 습관이 필요하다. 리스트가 느리거나 팝업이 이상할 때 원인을 빠르게 찾아야 한다.

사용자가 보는 모습 기록

문제의 첫 번째 단서는 사용자 피드백이다:

• "페이지가 느려요" vs "데이터가 안 나타나요" → 다른 원인
• "처음에는 빠른데 나중에 느려져요" → 메모리 누수 가능성
• "특정 브라우저에서만" → 호환성 문제

구체적인 재현 방법을 적어두면 디버깅이 훨씬 쉽다.

개발자 관점에서 신호 읽기

브라우저 개발자 도구로 직접 확인한다.

Performance 탭

npm run build

이후 애플리케이션을 열고:

1. Performance 탭 열기
2. 녹화 시작
3. 리스트 스크롤
4. 녹화 중지

결과에서:

• 초기 로드 시간
• 프레임 드롭 (60fps 목표)
• 렌더링 시간이 오래 걸리는 부분

Network 탭

API 요청 상황을 본다:

• 요청 개수 (한 번에 몇 개씩 로드하는가?)
• 응답 크기 (데이터가 너무 많지는 않은가?)
• 응답 시간

설정과 환경 차이

배포 환경과 로컬의 차이를 찾아본다.

캐싱 설정

# 캐시 비우기
rm -rf .next dist node_modules
npm ci
npm run build

캐시 때문에 이전 버전이 남아 있을 수 있다.

환경 변수

로컬과 배포 환경의 API 엔드포인트가 다를 수 있다:

• 로컬: localhost (빠름)
• 배포: 실제 서버 (네트워크 지연)

네트워크 탭에서 응답 시간을 확인해야 한다.

수정 전 고정할 값

테스트할 때 기준점을 잡아둔다:

// 로그에 타임스탬프 기록
console.time('list-render');
// 렌더링 코드
console.timeEnd('list-render');

// 또는 성능 측정
const start = performance.now();
// 작업
const end = performance.now();
console.log(`걸린 시간: ${end - start}ms`);

사용자 영향 확인

문제가 전체 사용자인지 일부인지 파악한다:

• 특정 데이터셋에서만 느린가?
• 특정 브라우저에서만?
• 특정 시간대에만?

검증 루틴

수정 후 다음을 확인한다:

1. 작은 데이터셋: 10개 아이템으로 테스트
2. 중간 크기: 1,000개 아이템
3. 대규모: 10,000개 이상

각 단계에서 성능이 허용 범위 내인지 확인해야 한다.

운영 메모

배포 후 발생 가능한 성능 문제:

• 데이터가 증가하면서 느려지는 경우
• 브라우저 업데이트 후 렌더링 엔진 변화
• 네트워크 환경에 따른 응답 시간 차이

이런 장기적 문제를 대비하려면 정기적으로 성능을 측정하는 모니터링을 추가하는 것이 좋다.

다음 작업 기준

문제를 해결할 때:

• 현재 값: 현재 성능 수치 (로딩 시간, FPS, 메모리 사용량)
• 목표 값: 목표 성능 수치 (예: 1초 이내 로드)
• 시도한 변경: 어떤 최적화를 했는가
• 개선 결과: 얼마나 개선됐는가

이 정보들을 기록해두면 같은 문제가 반복될 때 훨씬 빠르게 대응할 수 있다.