[번역] 당신이 무시해온 브라우저 DevTools 기능들
Soshy·
원문: The Browser DevTools Features You’ve Been Ignoring (That Would Save You Hours)
얼마 전, 동료와 페어 프로그래밍을 하다가 흥미로운 장면을 목격했습니다. 동료는 지저분한 프로덕션 스타일시트를 뒤지던 중이었는데, 어떤 규칙이 버튼 색상을 덮어쓰고 있는지 찾겠다며 셀렉터를 하나하나 클릭해가며 확인하고 있었습니다. 그 과정에 꼬박 15분이 걸렸습니다.
CSS Overview 패널을 썼다면, 페이지의 모든 색상을 그룹별로 정리된 클릭 가능한 목록으로 10초 만에 볼 수 있었을 텐데 말입니다.
그 동료는 DevTools를 3년째 쓰고 있었지만, 그 패널은 단 한 번도 열어본 적이 없었습니다.
사실 이런 경우는 드문 일이 아닙니다. 대부분의 개발자는 요소 검사(Inspect Element), 콘솔(Console), 네트워크(Network) 탭 정도만 쓰고, 나머지는 없는 것이나 마찬가지로 취급합니다. 하지만 그 나머지 기능들도 버젓이 존재하고, 수년 전부터 그 자리를 지켜왔으며, 일부는 실제로 업무 방식 자체를 바꿔놓을 만큼 강력합니다.
지금부터 놓치고 있던 기능들을 살펴보겠습니다.
CSS Overview: 페이지 스타일 즉석 감사
찾는 방법: Chrome → 도구 더보기(⋮) → CSS Overview. 또는 Cmd/Ctrl+Shift+P를 누르고 "CSS Overview"를 입력
"Capture Overview"를 클릭하면 DevTools가 전체 페이지를 스캔해 상세한 보고서를 만들어냅니다. 사용 중인 모든 색상(배경, 텍스트, fill, border별로 그룹화), 모든 폰트 패밀리와 굵기, 모든 미디어 쿼리, 그리고 사용되지 않는 CSS 선언 목록까지 한눈에 볼 수 있습니다.
특히 유용한 상황은 두 가지입니다. 첫째, 코드베이스를 물려받아 실제로 뭐가 쓰이고 있는지 파악해야 할 때입니다. 한 개발자는 레거시 프로젝트에서 이 기능을 돌려보고 나서 회색 음영이 무려 일곱 가지나 쓰이고 있다는 걸 발견하고, 곧바로 두 가지로 정리했다고 했습니다. 둘째, 접근 권한이 없는 라이브 사이트를 확인할 때입니다. 어떤 브라우저에서든 어떤 페이지에서든 실행해 전체 CSS 현황을 바로 파악할 수 있습니다.
보고서에 표시된 모든 색상은 클릭할 수 있습니다. 클릭하면 그 색상을 쓰는 모든 요소가 강조 표시되고, Elements 패널의 관련 코드로 바로 이동합니다. 빌드 파이프라인의 린팅 도구를 대체하는 건 아니지만, 빠른 확인이 목적이라면, 특히 프로덕션 환경에서라면 이보다 빠른 방법은 없습니다.
이 패널은 요소 수, 셀렉터 유형, 인라인 스타일 수, 외부 스타일시트, 그리고 색상·폰트·미사용 선언의 전체 내역을 보여줍니다. Chrome DevTools 공식 문서에 따르면, 영향을 받는 코드로 직접 링크도 제공되어 일일이 찾아다닐 필요 없이 소스로 바로 넘어갈 수 있습니다.
Local Overrides: 코드베이스 손대지 않고 프로덕션 사이트 편집하기
찾는 방법: Sources 패널 → Overrides 탭 → "Select folder for overrides" → Allow 클릭
이 기능은 프로덕션 이슈를 디버깅하는 방식 자체를 바꿔놓습니다. Local Overrides를 쓰면 사이트의 CSS, JavaScript, HTML을 로컬에서 수정하고, 페이지를 새로고침해도 그 변경 사항이 그대로 유지됩니다. 브라우저가 리소스를 서버에서 받아오는 시점을 가로채 로컬 버전을 대신 내려주는 방식입니다. 다른 사용자에게는 아무런 영향이 없고, 프로덕션 서버도 전혀 건드리지 않습니다.
설정 방법: Sources 패널로 이동해 Overrides 탭을 클릭합니다. 탭이 보이지 않는다면 >> 화살표를 눌러 오버플로 메뉴에서 찾아보세요. 로컬 폴더를 선택하고 Chrome이 권한을 요청하면 Allow를 클릭합니다. 이후 Sources 패널에서 원하는 파일을 우클릭하고 "Save for overrides"를 선택하면 됩니다. 이 시점부터는 변경 사항을 저장(Cmd/Ctrl+S)할 때마다 새로고침 후에도 반영된 상태로 유지됩니다.
오버라이드가 적용된 파일 옆에는 보라색 점 아이콘이 나타나는데, 이게 보이면 오버라이드가 활성화된 것입니다. Network 탭에도 경고 삼각형이 표시되어 오버라이드가 켜져 있다는 걸 계속 상기시켜 줍니다. 변경 사항이 왜 원래대로 안 돌아오는지 의아해하는 상황을 막아주는 장치입니다.
실용적인 활용 사례: 버그가 로컬이 아닌 스테이징에서만 재현될 때, 수정 사항을 스테이징에 푸시해서 확인하는 대신 오버라이드를 설정하고 파일을 직접 수정한 뒤 새로고침하면 2분 안에 검증이 끝납니다. 한 개발자는 자신의 블로그에서 이 기능이 "디버깅부터 배포까지의 수고를 크게 덜어줬다"고 밝혔습니다.
한 가지 중요한 제약이 있습니다. Elements 패널의 DOM 트리에서 직접 수행한 변경은 저장되지 않습니다. CSS가 HTML 파일 안에 있는 경우라면, Styles 창을 통한 편집도 저장되지 않습니다. 이 경우에는 Sources 패널에서 HTML 파일을 직접 열어 편집해야 합니다.
네트워크 요청 차단: 백엔드 없이 에러 상태 테스트하기
찾는 방법: Network 패널 → 요청 우클릭 → "Block request URL" (또는 "Block request domain")
대부분의 개발자는 정상 흐름(happy path)은 끊임없이 테스트합니다. 하지만 에러 경로, 즉 API 호출이 실패했을 때, 서드파티 스크립트가 로드되지 않을 때, fetch가 아무것도 반환하지 않을 때 어떻게 되는지는 훨씬 덜 테스트합니다. 그런 상황을 재현하는 것 자체가 번거롭기 때문입니다. 서버 응답을 직접 수정하거나, 목(mock)을 작성하거나, 아예 네트워크를 끊어야 하는 경우가 많으니까요.
요청 차단 기능은 이를 클릭 두 번으로 해결합니다. Network 패널에서 원하는 요청을 우클릭하고 "Block request URL"을 선택하면 그 URL을 차단하고, "Block request domain"을 선택하면 해당 도메인의 모든 요청을 막습니다. 새로고침하면 그 요청은 네트워크 오류로 실패하고, 앱이 그 상황을 어떻게 처리하는지 그대로 확인할 수 있습니다.
특히 이런 것들을 테스트할 때 유용합니다: 폰트 CDN이 다운됐을 때 앱이 어떻게 보이는지, API 타임아웃 시 에러 UI가 어떻게 그려지는지, 이미지 폴백이 실제로 동작하는지, 서드파티 분석 스크립트 로딩이 실패했을 때 렌더링이 막히는지.
차단된 URL은 네트워크 요청 차단 패널에서 관리할 수 있습니다. 도구 더보기나 커맨드 메뉴("Network request blocking" 입력)로 접근하면 되고, URL 패턴을 직접 추가하거나 와일드카드를 쓰거나, 개별 차단을 켜고 끄거나, 작업이 끝나면 한 번에 전부 지울 수 있습니다.
Rendering 탭: 페인트 플래싱과 레이아웃 시프트 파악하기
찾는 방법: Cmd/Ctrl+Shift+P → "Show Rendering" 입력 → DevTools 하단에 탭이 나타납니다.
Rendering 탭은 Chrome DevTools에서 가장 강력하면서도 가장 덜 쓰이는 패널 중 하나입니다. 평소에는 눈에 잘 띄지 않는 두 가지, 즉 브라우저가 어느 부분을 다시 그리는지와 레이아웃 시프트가 어디서 일어나는지를 시각적으로 드러내줍니다.
페인트 플래싱(Paint flashing) 은 다시 그려지는 영역을 초록색으로 강조합니다. 스크롤하거나, 무언가를 클릭하거나, 애니메이션이 실행될 때, 브라우저가 픽셀을 새로 그려야 하는 곳마다 초록 불빛이 번쩍입니다. 눈여겨볼 지점은 불필요하게 깜빡이는 영역이나, 일부만 바뀌었는데 전체 섹션이 통째로 다시 그려지는 경우입니다. 흔한 원인 중 하나는 transform 대신 top이나 left로 애니메이션을 구현하는 것입니다. 전자는 레이아웃과 리페인트를 모두 유발하지만, 후자는 그렇지 않습니다. 한 개발자는 페인트 플래싱을 켜보고 나서 바로 이 문제로 인해 스크롤할 때마다 전체 상품 목록이 새로 그려지고 있다는 걸 발견했다고 했습니다. transform으로 바꾸자 문제가 해결됐습니다.
레이아웃 시프트 영역(Layout Shift Regions) 은 페이지 로드 중 레이아웃 시프트가 발생하는 곳을 보라색으로 표시합니다. 이는 Google Core Web Vitals 중 하나인 누적 레이아웃 시프트(CLS) 점수와 직결됩니다. 활성화한 뒤 새로고침하면 어떤 요소가 언제, 어디서 튀는지 정확히 볼 수 있습니다. 크기가 명시되지 않은 이미지, 늦게 로드되는 광고, 늦게 적용되는 웹폰트가 주요 원인입니다. 보라색 표시가 어디를 봐야 할지 알려주고, 그 다음은 왜 공간이 미리 확보되지 않았는지 파악하는 것입니다.
Chrome DevTools 공식 렌더링 문서에 따르면, Rendering 탭에는 Frame Rendering Stats(실시간 FPS 및 GPU 사용량 오버레이), 스크롤 성능 이슈(문제 있는 이벤트 리스너 강조), Layer Borders(컴포지팅된 레이어 표시)도 포함되어 있습니다. 모두 유용하지만, 대부분의 개발자라면 페인트 플래싱과 레이아웃 시프트 영역부터 시작하는 게 좋습니다.
Performance 패널: 변경 사항과 사용 모드 이해하기
Performance 패널은 2024년에 대대적으로 개편됐으며, 두 가지 주요 모드의 차이를 알아두면 도움이 됩니다.
기존의 레코딩 모드, 즉 Record를 누르고 작업한 뒤 Stop을 누르는 방식은 JavaScript 실행, 렌더링 이벤트, 스크립팅·렌더링·페인팅·시스템 작업에 소요된 시간 분석이 담긴 플레임 차트를 보여줍니다. 특정 상호작용을 프로파일링할 때, 예를 들어 느린 폼 제출, 버벅이는 애니메이션, 반응이 느린 버튼 클릭 같은 것들을 파고들 때는 여전히 가장 적합한 도구입니다. Chrome의 2024년 개발자 요약에 따르면, 이 패널에는 Core Web Vitals 실시간 모니터링과 레코딩에 주석을 추가하는 기능도 새로 들어왔습니다.
새로운 점은 Performance 패널에 직접 통합된 Insights 사이드바입니다. Lighthouse 스타일의 분석을 트레이스(trace) 안으로 끌어들여, 단순한 타이밍 데이터 대신 문제 원인에 대한 실질적인 제안을 바로 보여줍니다. LCP 요청 탐색 문제, 서드파티 스크립트 영향, 레거시 JavaScript, 중복 리소스 등이 여기에 포함됩니다. DevTools를 벗어나 별도로 Lighthouse 감사를 돌릴 필요가 없습니다. 트레이스 옆에서 바로 이슈를 짚어줍니다.
Live Metrics 화면(Performance 패널 상단에서 접근)은 페이지와 상호작용하는 동안 LCP, INP, CLS가 실시간으로 업데이트되는 걸 보여줍니다. 전체 트레이스를 기록하지 않고도, 방금 수정한 내용이 Core Web Vitals를 개선했는지 악화시켰는지 빠르게 확인할 수 있습니다.
빠른 확인에는 Live Metrics를, 특정 이슈 진단에는 전체 레코딩을, 지표가 나쁜 이유를 파악할 때는 Insights를 쓰면 됩니다.
브라우저별 숨겨진 팁 하나씩
Chrome: 커맨드 메뉴(Cmd/Ctrl+Shift+P)는 DevTools의 어떤 기능이든 가장 빠르게 꺼내 쓰는 방법입니다. "Show Rendering", "CSS Overview", "Network request blocking", "Show Animations" 등 두 단어만 입력하면 바로 나타납니다. 대부분의 개발자는 이 기능을 모른 채 메뉴를 일일이 뒤지고 있습니다.
Firefox: Firefox DevTools의 Inspector에는 탭 전환 없이 HTML, 스타일, 레이아웃 정보를 동시에 볼 수 있는 3분할 뷰가 있습니다. 또한 페이지에서 쓰인 미디어 쿼리를 빠른 이동 링크와 함께 하이라이트해 줘서, 어떤 브레이크포인트가 활성화되어 있는지 확인해야 하는 반응형 디버깅에 유용합니다. Smashing Magazine의 DevTools 심층 분석에 따르면, Firefox는 Chrome이 기본적으로 숨기는 브라우저 기본 스타일도 Inspector에서 작성자 스타일과 나란히 보여줍니다.
Safari: Safari의 Web Inspector는 Chrome처럼 별도의 Rendering 탭으로 이동할 필요 없이, Elements 툴바에 페인트 플래싱 버튼이 바로 달려 있습니다. DevTools Tips에 따르면, 덕분에 Safari에서 렌더링 디버깅을 시작하는 속도가 조금 더 빠릅니다. Web Inspector를 활성화하려면 Safari → 설정 → 고급으로 가서 "웹 개발자용 기능 보기"를 체크하면 됩니다. 그러면 개발자 메뉴가 생기고, 모든 페이지에서 우클릭 → 검사를 쓸 수 있게 됩니다.
이 모든 것의 공통점
여기서 소개한 기능 중 깊숙이 숨겨진 건 하나도 없습니다. CSS Overview는 도구 더보기에, Local Overrides는 Sources 패널에, Rendering 탭은 커맨드 메뉴 한 번이면 닿는 곳에 있습니다. 숨겨진 게 아니라, 대부분의 튜토리얼이 안내하지 않는 곳에 있을 뿐입니다.
대부분의 개발자가 DevTools의 20%만 사용하는 이유는, 대부분의 사람들이 복잡한 도구의 20%만 사용하는 이유와 같습니다. 나머지 기능은 아직 경험해보지 못한 곳을 찾아야 하기 때문입니다. 하지만 이러한 곳들은 충분히 가볼 만한 가치가 있습니다.