느린 페이지 원인 찾기: 1인 개발자를 위한 웹 성능 병목 진단 순서

페이지가 느리면 가장 먼저 캐시를 붙이거나 코드를 크게 고치고 싶어집니다. 하지만 1인 개발자에게 더 중요한 것은 ‘어디가 느린지’와 ‘무엇을 먼저 고칠지’를 빠르게 좁히는 일입니다. 추측으로 여러 부분을 동시에 건드리면 개선 효과를 확인하기 어렵고, 오히려 디버깅 범위만 넓어집니다.

1. 먼저 ‘느리다’의 종류를 나눈다

화면이 늦게 나타나는 경우

첫 화면 자체가 늦게 보인다면 서버 응답, 데이터 페칭, 렌더링 차단 요소를 의심합니다. 브라우저 개발자 도구의 Network 탭에서 문서 요청의 대기 시간과 응답 완료 시점을 확인하고, 서버 로그에서는 요청이 들어온 뒤 어느 단계에서 시간이 걸렸는지 나눠 보세요.

화면은 보이지만 조작이 늦는 경우

버튼 클릭, 입력, 메뉴 열기가 버벅인다면 자바스크립트 실행량이나 큰 렌더링 작업이 원인일 수 있습니다. Performance 도구로 긴 작업이 발생한 시점과 해당 함수의 호출 흐름을 확인합니다. 모바일에서만 느리다면 개발용 컴퓨터의 체감만 믿지 말고 실제 저사양 환경에 가까운 조건에서도 재현해 보세요.

2. 네트워크와 데이터 페칭부터 확인한다

페이지 하나가 여러 API를 순차적으로 호출하면 각 요청의 시간이 누적됩니다. Network 탭에서 요청 개수, 요청 간 시작 시점, 응답 크기를 확인하고 다음 질문에 답해 보세요.

• 서로 의존하지 않는 요청이 순차 실행되고 있지 않은가?
• 화면에 당장 필요하지 않은 데이터까지 한 번에 가져오고 있지 않은가?
• 같은 데이터를 컴포넌트 여러 곳에서 반복 요청하지 않는가?
• 서버 응답에 사용하지 않는 필드가 과하게 포함되지 않았는가?

가능하다면 독립적인 요청은 함께 실행하고, 첫 화면에 필요한 데이터와 이후에 불러올 데이터를 분리합니다. API 경계를 다시 정리할 때는 REST vs GraphQL vs RPC: 작은 프로젝트의 API 스타일 선택과 실전 설계 팁도 함께 참고할 만합니다.

3. DB 병목과 N+1 쿼리를 찾는다

쿼리 횟수보다 호출 구조를 본다

목록을 가져온 뒤 각 항목마다 상세 정보를 다시 조회하는 구조는 대표적인 N+1 패턴입니다. 코드에서 반복문 안에 DB 호출이 있는지 찾고, 개발 환경의 쿼리 로그로 실제 호출 횟수를 확인하세요. 항목 수가 적을 때는 드러나지 않다가 데이터가 늘면서 급격히 느려지는 경우가 많습니다.

가장 먼저 줄일 것

필요한 컬럼만 선택하고, 여러 번 조회하는 데이터를 한 번의 조인·집계·배치 조회로 바꿀 수 있는지 검토합니다. 다만 무작정 복잡한 쿼리로 합치기보다 실행 계획과 결과를 함께 확인해야 합니다. 인덱스를 추가할 때도 실제 필터와 정렬 조건을 기준으로 판단하세요. 운영 DB 구조를 건드리는 작업이라면 DB 스키마 마이그레이션 안전하게 하기의 점검 흐름을 적용하면 실수를 줄일 수 있습니다.

4. 번들, 자바스크립트, 이미지를 분리해서 측정한다

서버와 DB가 빠른데도 첫 화면이 늦다면 정적 자산을 확인할 차례입니다. 번들 분석 도구로 큰 라이브러리와 사용하지 않는 코드가 포함됐는지 보고, 모든 기능을 첫 로드에 넣고 있지는 않은지 점검합니다. 화면 아래쪽 기능이나 특정 메뉴에서만 필요한 코드는 지연 로딩 후보입니다.

이미지는 원본 크기, 포맷, 표시 크기를 함께 봅니다. 작은 카드에 거대한 원본을 내려주거나, 보이지 않는 이미지까지 동시에 로드하면 네트워크와 디코딩 비용이 커집니다. 이미지 자체를 줄이는 것과 함께 화면에 들어오는 시점에 맞춰 로드하는 방법을 검토하세요.

5. 개선 순서는 ‘효과 × 확실성’으로 정한다

한 번에 하나만 바꾼다

진단 결과를 다음 표처럼 기록하면 우선순위가 선명해집니다.

가장 효과가 크고 원인이 명확한 항목 하나를 고친 뒤 같은 조건에서 다시 측정합니다. 측정값이 좋아졌는지뿐 아니라 기능 오류, 캐시 영향, 다른 화면의 부작용도 확인해야 합니다. 문제가 여러 개 섞여 있다면 버그를 Codex로 디버깅하는 법처럼 증상·재현 조건·관찰 결과를 분리해 기록하면 AI에게 분석을 맡길 때도 훨씬 정확해집니다.

성능 작업의 목표는 가장 빠른 코드를 만드는 것이 아니라 사용자가 기다리는 구간을 줄이는 것입니다. 요청 하나, 쿼리 하나, 자산 하나씩 근거를 남기며 고치면 혼자 운영하는 서비스에서도 성능 개선을 반복 가능한 작업으로 만들 수 있습니다.