리스트 성능이 운영에서만 나빠질 때

로컬 개발 환경에서는 리스트가 순식간에 로드되는데, 운영 서버에선 3초 이상 걸린다는 보고가 들어왔다. 데이터량이 많아서? 네트워크가 느린 건가?

이런 경우 보통 세 가지 중 하나다. 로컬과 운영의 데이터 규모 차이, 쿼리 최적화 미흡, 또는 네트워크 지연.

로컬과 운영의 데이터량 비교

먼저 각 환경의 실제 데이터 수를 알아본다. 로컬은 수십 개, 운영은 수만 개일 수도 있다.

# 로컬에서 데이터 수 확인
sqlite3 test.db "SELECT COUNT(*) FROM items;"

# 운영 환경 (SSH 접속)
ssh prod-server
psql -d app_prod -c "SELECT COUNT(*) FROM items;"

데이터가 100배 다르면, 성능도 당연히 달라진다.

네트워크와 API 응답 시간

운영 환경에서 같은 요청을 여러 번 보내보고, 응답 시간을 측정한다.

• API 응답 시간: 서버에서 데이터를 가져오고 응답하는 시간
• 페이로드 크기: 한 번에 얼마나 많은 데이터를 보내는가
• 네트워크 지연: 실제 네트워크 왕복 시간

브라우저 개발자 도구의 네트워크 탭에서 실제 시간을 본다. API만 2초 걸린다면, 애플리케이션 코드를 봐도 소용이 없다.

쿼리 최적화 확인

운영 환경에서 실제 실행되는 쿼리를 본다.

# PostgreSQL의 경우
EXPLAIN ANALYZE SELECT * FROM items ORDER BY created_at DESC LIMIT 20;

쿼리가 Full Table Scan을 하는가? 인덱스를 타는가? Sequential vs Index Scan의 차이는 수십 배다.

페이지네이션과 무한 스크롤

한 번에 모든 데이터를 가져오는가, 아니면 페이지 단위로 나눠서 가져오는가?

• 처음부터 다 가져오기: 첫 로드가 오래 걸리지만, 스크롤은 빠름
• 페이지 단위 (페이지네이션): 첫 로드는 빠르지만, 다음 페이지로 넘어갈 때 또 요청
• 무한 스크롤: 스크롤할 때마다 새 데이터를 불러옴, 사용자 환경에선 자연스럽지만 백엔드 부하 증가

운영에서 성능이 나쁘면, 보통 페이지네이션이나 무한 스크롤을 도입해야 한다.

빌드 결과 확인

npm run build
# 프로덕션 번들의 크기와 초기 로드 시간

번들이 너무 크면, 브라우저가 js 파일을 다운로드하고 파싱하는 데 오래 걸린다.

모바일 기기에서 테스트

운영 환경에 실제 모바일 기기로 접속해본다. 아마 데스크톱보다 훨씬 느릴 거다.

• 네트워크: 4G, 5G, Wi-Fi 등에서 모두 테스트
• CPU: 모바일 CPU는 데스크톱보다 훨씬 느림

마지막으로, 성능 문제는 "느리다"는 주관적 판단만으로는 해결할 수 없다. API 응답 시간, 쿼리 성능, 데이터량, 네트워크 지연을 각각 측정해야 한다. 그래야 실제 병목이 어디인지 알 수 있고, 그에 맞는 최적화를 할 수 있다.