브라우저 개발자도구로 네트워크 병목 찾는 법

웹페이지가 느릴 때 “서버가 느린가?”, “이미지가 큰가?”, “자바스크립트가 문제인가?“를 감으로 판단하면 시간을 많이 잃습니다. 브라우저 개발자도구의 Network 패널은 페이지가 로드되는 동안 어떤 파일과 API가 언제, 얼마나, 어떤 순서로 내려오는지 보여 줍니다. 특별한 유료 도구 없이도 병목의 상당 부분을 찾을 수 있는 가장 현실적인 출발점입니다.

이 글은 Chrome 기준으로 설명하지만 Edge, Brave, Firefox도 비슷한 기능을 제공합니다. 성능 지표 자체가 낯설다면 Core Web Vitals 초보 가이드를 먼저 보고, 구조 선택의 문제라면 정적 사이트 vs SSR을 함께 읽으면 좋습니다.

1. 먼저 재현 조건을 고정한다

성능 측정에서 가장 흔한 실수는 조건을 매번 다르게 두는 것입니다. 집 와이파이, 회사 VPN, 모바일 핫스팟, 로그인 상태, 캐시 상태가 모두 다르면 같은 페이지도 다르게 보입니다. Network 패널을 열기 전에 재현 조건을 정리하세요.

어떤 URL을 측정할 것인가
로그인 상태인가, 비로그인 상태인가
캐시를 켤 것인가, 끌 것인가
모바일 네트워크를 흉내 낼 것인가
확장 프로그램 영향을 줄이기 위해 시크릿 창을 쓸 것인가
측정 지역과 시간대가 중요한가

Chrome에서 개발자도구를 열려면 F12, Ctrl+Shift+I, 또는 우클릭 후 “검사”를 선택합니다. 상단에서 Network 탭을 누르고, 새로고침 버튼을 길게 눌러 “Empty Cache and Hard Reload”를 실행하면 캐시 없는 첫 방문에 가까운 상태를 볼 수 있습니다. 단, 실제 사용자는 캐시가 있는 재방문도 많으니 첫 방문과 재방문을 나눠 봐야 합니다.

2. Network 패널에서 먼저 볼 항목

Network 패널에는 많은 열이 있지만 처음에는 다음 항목만 봐도 충분합니다.

Status: 요청 성공, 리다이렉트, 오류 여부
Type: document, script, stylesheet, image, fetch 등 자원 종류
Size: 전송된 크기와 캐시 여부
Time: 요청 전체에 걸린 시간
Waterfall: 요청이 시작되고 끝나는 순서와 대기 시간
Domain: 어떤 도메인에서 가져왔는지

페이지가 느릴 때는 “가장 큰 파일”과 “가장 오래 걸린 요청”을 구분해야 합니다. 큰 이미지는 다운로드 시간이 문제일 수 있고, 작은 API 요청은 서버 응답 대기 시간이 문제일 수 있습니다. Size와 Time을 각각 정렬해 보면 서로 다른 병목이 드러납니다.

3. Waterfall은 순서를 읽는 도구다

Waterfall은 각 요청이 언제 시작되고 언제 끝났는지 시각적으로 보여 줍니다. 파란색, 초록색, 보라색 같은 색상 자체보다 중요한 것은 “긴 막대가 왜 생겼는가”입니다.

요청을 클릭하고 Timing 탭을 보면 다음 단계를 확인할 수 있습니다.

Queueing: 브라우저 내부 대기 시간
DNS Lookup: 도메인 주소 조회 시간
Initial connection: TCP 연결 시간
SSL: HTTPS 협상 시간
Request sent: 요청 전송 시간
Waiting for server response: 서버가 응답하기까지 기다린 시간
Content Download: 응답 본문 다운로드 시간

Waiting for server response가 길다면 서버, 데이터베이스, API 처리 시간이 문제일 가능성이 큽니다. Content Download가 길다면 파일 크기나 네트워크 속도가 문제일 수 있습니다. DNS, SSL, Initial connection이 여러 도메인에서 반복된다면 외부 스크립트와 CDN 도메인이 너무 많은지 확인해야 합니다.

4. 요청 수가 많으면 느려질 수 있다

HTTP/2와 HTTP/3에서는 과거보다 여러 요청을 병렬로 처리하기 좋아졌지만, 요청 수가 무한히 많아도 괜찮다는 뜻은 아닙니다. 작은 아이콘, 폰트, 상업성 광고 스크립트, 분석 스크립트, 위젯, API 호출이 쌓이면 브라우저와 네트워크가 바빠집니다.

Network 패널 하단에는 요청 수, 전송량, 로드 시간이 표시됩니다. 처음 보는 페이지가 수백 개 요청을 만들고 있다면 다음을 점검하세요.

사용하지 않는 외부 스크립트가 남아 있는가
같은 폰트 굵기를 너무 많이 불러오는가
이미지 썸네일을 원본 크기로 내려받는가
상업성 광고·분석 태그가 중복 설치되어 있는가
API를 컴포넌트마다 따로 호출해 같은 데이터를 반복 요청하는가
아이콘을 개별 SVG 파일로 과도하게 요청하는가

요청 수 최적화는 “무조건 합치기”가 아닙니다. 필요한 요청만 남기고, 캐시 가능한 정적 파일은 오래 캐시하며, 중요하지 않은 스크립트는 지연 로드하는 방향이 좋습니다.

5. 이미지 병목 찾기

느린 페이지에서 가장 흔한 원인은 이미지입니다. Network 패널에서 Img 필터를 누르고 Size 기준으로 정렬해 보세요. 모바일 화면에 400픽셀로 보이는 이미지가 3000픽셀 원본으로 내려오고 있다면 개선 여지가 큽니다.

이미지 점검 체크리스트는 다음과 같습니다.

실제 표시 크기에 맞는 리사이즈 이미지를 제공하는가
WebP, AVIF 같은 최신 포맷을 사용할 수 있는가
화면 아래 이미지는 lazy loading을 적용했는가
hero 이미지는 너무 늦게 요청되지 않는가
썸네일 목록에서 원본 이미지를 반복 사용하지 않는가
이미지 CDN의 변환 옵션을 활용하고 있는가

특히 LCP에 해당하는 큰 hero 이미지는 중요합니다. 너무 늦게 발견되거나, CSS 배경 이미지로 숨어 있거나, 다른 스크립트가 끝난 뒤 로드되면 첫 화면 체감 속도가 나빠집니다.

6. 캐시가 제대로 먹는지 확인한다

Network 패널의 Size 열에 (memory cache), (disk cache), 304가 보이면 캐시가 작동하고 있다는 뜻입니다. 하지만 모든 파일이 매번 새로 다운로드된다면 캐시 헤더를 확인해야 합니다.

요청을 클릭하고 Headers 탭에서 다음 헤더를 봅니다.

cache-control
etag
last-modified
expires
content-encoding

정적 자산에는 긴 캐시를 적용할 수 있습니다. 파일 이름에 해시가 들어간 app.abc123.js 같은 자산은 내용이 바뀌면 파일명이 바뀌므로 오래 캐시해도 안전합니다. 반면 HTML 문서는 최신 콘텐츠가 중요하므로 너무 오래 캐시하면 배포 후 변경이 늦게 반영될 수 있습니다.

정적 사이트를 CDN이나 Workers에 올린다면 캐시 정책이 성능과 비용에 직접 영향을 줍니다. 배포 구조가 궁금하다면 Cloudflare Workers로 정적 사이트 배포하기를 참고하세요.

7. API 요청 병목 분석

Fetch/XHR 필터를 누르면 API 요청만 볼 수 있습니다. API가 느릴 때는 단순히 Time만 보지 말고 응답 크기와 상태 코드를 같이 봅니다.

200이지만 느린가: 서버 처리나 DB 쿼리가 느릴 수 있습니다.
304가 많은가: 캐시 검증은 되고 있지만 여전히 왕복 요청이 있습니다.
401 또는 403이 반복되는가: 인증 갱신 로직이 꼬였을 수 있습니다.
404가 많은가: 잘못된 URL을 계속 요청하고 있을 수 있습니다.
429가 보이는가: API 사용량 제한에 걸렸을 수 있습니다.
500대 오류가 보이는가: 서버 로그 확인이 필요합니다.

API 응답 본문이 너무 크다면 필요한 필드만 내려주도록 바꾸는 것이 좋습니다. 목록 화면에서 상세 페이지에 필요한 모든 데이터를 내려보내는 구조는 처음에는 편하지만, 데이터가 쌓이면 느려집니다.

8. 외부 스크립트와 폰트도 병목이 된다

분석 도구, 채팅 위젯, 상업성 광고 스크립트, A/B 테스트 도구, 폰트 CDN은 모두 외부 도메인 요청을 만듭니다. 하나하나는 작아 보여도 DNS, TLS, 실행 비용이 쌓입니다. Network 패널에서 Domain 기준으로 보면 어느 외부 서비스가 많은 요청을 만드는지 알 수 있습니다.

운영 중인 사이트라면 다음 질문을 해 보세요.

이 스크립트는 현재도 실제로 쓰고 있는가
관리자만 필요한 도구가 모든 방문자에게 로드되고 있지 않은가
페이지 하단 위젯이 첫 화면 렌더링을 막고 있지 않은가
폰트 굵기와 문자 범위를 줄일 수 있는가
타사 스크립트 장애가 우리 페이지를 멈추게 만들 수 있는가

외부 스크립트는 성능뿐 아니라 개인정보 처리와도 관련됩니다. 어떤 데이터를 수집하고 어디로 전송하는지 파악해 개인정보처리방침에도 반영해야 합니다.

9. 개선 우선순위 정하기

Network 패널에서 문제를 찾았다고 바로 모든 것을 고치려 하면 일정이 늘어집니다. 영향도와 난이도로 우선순위를 정하세요.

오류 요청 제거: 404, 500, 인증 반복은 먼저 고칩니다.
큰 이미지 최적화: 체감 개선이 빠릅니다.
LCP 관련 자원 개선: 첫 화면 핵심 요소를 먼저 로드합니다.
사용하지 않는 외부 스크립트 제거: 요청 수와 실행 비용을 줄입니다.
캐시 헤더 정리: 재방문 속도와 트래픽 비용을 줄입니다.
느린 API 개선: 서버 로그와 DB 쿼리까지 함께 봅니다.

개선 전후에는 같은 조건으로 다시 측정해야 합니다. 캐시를 켰는지, 네트워크 제한을 걸었는지, 로그인 상태인지가 달라지면 비교가 의미 없어집니다.

마무리 체크리스트

Network 패널을 열고 캐시 없는 첫 방문과 캐시 있는 재방문을 모두 확인했는가
Size 기준으로 큰 이미지와 자산을 찾았는가
Time 기준으로 오래 걸리는 API와 외부 요청을 찾았는가
Waterfall에서 대기 시간이 긴 원인을 Timing 탭으로 확인했는가
404, 500, 429 같은 오류 상태 코드를 제거했는가
캐시 헤더와 압축 헤더가 적절한지 확인했는가
개선 후 같은 조건으로 다시 측정했는가

브라우저 개발자도구는 성능 문제의 최종 답을 주지는 않지만, 어디를 더 깊게 봐야 하는지 알려 줍니다. 감으로 “서버가 느린 것 같다”고 말하기 전에 Network 패널을 열고 요청, 크기, 순서, 캐시를 확인하세요. 그 습관만으로도 실무에서 낭비되는 디버깅 시간을 크게 줄일 수 있습니다.