브라우저 DevTools 심층 2026 — Chrome / Firefox / Safari / Edge / WebDriver BiDi / CDP / Lighthouse 12 / AI Assistance (Gemini) 심층 가이드

브라우저 DevTools는 프런트엔드 개발자에게 IDE보다 더 자주 켜는 도구다. 2026년 시점에서 DevTools는 단순한 "Inspect Element" 단계를 한참 지났다. AI가 콘솔 에러를 설명해 주고, BiDi 프로토콜이 CDP를 대체해 가며, Lighthouse 12가 INP를 1차 지표로 보고하고, Recorder가 자동화된 워크플로를 만든다. 이 글은 2026년 5월 기준으로 Chrome / Firefox / Safari / Edge 네 진영의 DevTools 현황과, 그것을 둘러싼 CDP·BiDi·Lighthouse·자동화 도구의 생태계를 정리한다.

1. 2026년 브라우저 DevTools 지도 — Chrome / Firefox / Safari / Edge 네 진영

DevTools를 한 줄로 묶기 어려운 이유는, "어느 브라우저에서 디버깅하느냐"가 곧 "어느 프로토콜·어느 UI·어느 한계를 쓰느냐"로 직결되기 때문이다. 2026년 시점에서 시장은 다음 네 진영으로 정리된다.

• Chrome DevTools — Chromium 본가, CDP (Chrome DevTools Protocol)의 사실상 표준
• Firefox DevTools — Quantum 시대의 유산을 잇는 Mozilla의 독자 노선
• Safari Web Inspector — Apple, WebKit 진영의 디버거
• Edge DevTools — Chromium 포크에 3D View / Edge 전용 패널 추가

여기에 표준화 축으로 WebDriver BiDi (W3C) 가 들어온다. 2026년의 Selenium 4.x, Playwright 1.50+, Cypress 14 모두 BiDi를 1차 백엔드로 채택했다. CDP는 여전히 Chrome 전용 슈퍼셋으로 남고, BiDi는 크로스 브라우저 자동화의 공용어가 된다.

2. Chrome DevTools — 가장 풍부, CDP 표준의 본가

Chrome DevTools는 여전히 가장 큰 진영이다. 2026년 5월 기준 Chrome 137 안정 채널에 들어 있는 DevTools는 Sources / Elements / Network / Performance / Memory / Application / Lighthouse / Recorder / Security / Privacy Sandbox / AI Assistance까지 14개 이상의 메인 패널을 가진다.

CDP는 WebSocket 기반의 RPC 프로토콜이다. 외부에서 Chrome을 원격 디버깅하려면 다음과 같이 띄운다.

google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-debug \
  https://example.com

그 다음 http://localhost:9222/json 으로 가면 열린 탭 목록을 JSON으로 받을 수 있다. WebSocket을 잡아서 CDP 메서드를 보내면 Chrome을 코드로 조작할 수 있다.

import WebSocket from 'ws'

const ws = new WebSocket('ws://localhost:9222/devtools/page/ABC123')
ws.on('open', () => {
  ws.send(JSON.stringify({ id: 1, method: 'Page.navigate', params: { url: 'https://www.google.com' } }))
})

Puppeteer, Playwright (Chromium 모드), Lighthouse, Chrome Headless Shell 전부 이 CDP를 사용한다. Chrome DevTools UI 자체도 사실 자기 자신과 CDP로 말하는 웹 앱이다.

2025~2026년의 Chrome DevTools 핵심 변화:

• Performance 패널이 Performance Insights로 통합되어 LCP / INP / CLS 진단을 자동으로 제시
• AI Assistance 패널 (Gemini) 이 정식 GA, Console / Network / Performance에 임베드
• Recorder가 워크플로 단위로 묶이고, JSON / Puppeteer / Cypress / Playwright 코드로 export
• Privacy Sandbox 탭이 Application 아래 신설, Topics / Protected Audience / Storage Access API 디버깅
• CSS Overview가 Elements 옆으로 빠지면서 사용 빈도가 높아짐

3. Firefox DevTools — Quantum의 유산을 잇는 두 번째 진영

Firefox DevTools는 점유율과 별개로 "이건 Firefox가 더 낫다"는 영역을 끝까지 지킨 진영이다. 대표 사례가 CSS Grid 인스펙터다. Chrome도 2020년 이후 따라잡았지만, Firefox의 line numbers 토글, area names overlay, transform overlay는 여전히 한 수 위라는 평가가 많다.

Firefox는 Quantum 엔진 (2017~) 이후 DevTools 전체를 React + Redux 기반으로 다시 썼고, 이 코드베이스는 지금도 mozilla-central 의 devtools/client/ 아래에서 유지된다. 2024~2025년 사이 Mozilla는 다음 두 가지를 밀었다.

• WebDriver BiDi 1차 구현 — Marionette를 BiDi로 점진적 교체
• Firefox Profiler 통합 — Firefox 전용 프로파일러 (profiler.firefox.com) 를 DevTools Performance 탭에서 직접 호출

Firefox의 약점은 시장 점유율 하락 자체보다, 일부 사이트가 Chrome 전용 API에 의존하면서 Firefox에서 디버깅 자체가 불가능해지는 케이스다. 그래서 2026년 시점에서 Firefox DevTools는 "Chrome 외 환경의 호환성 검증" 도구로 자리매김했다.

Firefox 고유의 강점이 살아 있는 영역:

• Storage Inspector — IndexedDB / Cookies / Cache 까지 한 화면에서
• Network Monitor의 HAR export — 가장 깔끔
• Accessibility Inspector — color contrast 시뮬레이션
• about:debugging — Remote Debugging 의 일관된 UI

4. Safari Web Inspector — Apple, WebKit 진영의 디버거

Safari Web Inspector는 macOS Safari · iOS Safari · iPadOS Safari · visionOS Safari · WKWebView 까지 모두 디버깅할 수 있는 유일한 도구다. 2024년 EU DMA 시행 이후 iOS에서 다른 브라우저 엔진 (Blink, Gecko) 이 허용되었지만, 시장의 95% 이상은 여전히 WebKit이므로 모바일 Safari 디버깅은 곧 Web Inspector 디버깅이다.

연결 방식:

1. iPhone / iPad 의 Settings - Safari - Advanced - Web Inspector 활성화
2. 케이블로 macOS에 연결
3. macOS Safari - Develop 메뉴 - 디바이스 이름 - 열린 탭 선택

연결되면 Web Inspector가 데스크톱 Safari의 그것과 동일한 UI로 뜬다. iOS의 메모리 / CPU / 네트워크를 실시간으로 본다.

Web Inspector의 강점:

• iOS Safari 실기 디버깅 — Chrome으로 대체 불가
• Audit 탭 — Lighthouse는 아니지만 자체 규칙 기반 감사
• Timelines / Memory / Canvas / Layers 패널 — WebKit 내부에 가까운 metric
• responsive design mode가 데스크톱 Safari에서도 동일

약점은 Inspector 의 UX 가 보수적이라는 점이다. Chrome DevTools 의 AI Assistance, Recorder, Workflows 같은 신규 기능이 없고, 키보드 단축키도 다르다. 그래서 "iOS Safari 만 깬다" 같은 상황에서만 켜는 사람도 많다.

5. Edge DevTools — Chromium 포크 + 3D View 그리고 Accessibility 트리

Edge DevTools는 Chromium 베이스라 Chrome DevTools와 90% 동일하다. 하지만 Microsoft 가 직접 추가한 차별 패널이 있다.

• 3D View — DOM 트리를 3D로 시각화, z-index / Composited Layer 디버깅에 강점
• Issues 패널의 Microsoft-specific 검사 — Edge for Business 정책, 엔터프라이즈 사이트 호환
• Visual Studio Code Edge DevTools 확장 — VS Code 안에서 DevTools 풀세트
• Application Insights 연동 — Azure 텔레메트리

Edge DevTools 가 진짜로 빛나는 순간은 VS Code 안에서 디버깅할 때다. Microsoft Edge Tools for VS Code 확장을 설치하면 다음을 한 창에서 처리한다.

• VS Code 디버거로 코드 브레이크포인트
• Edge DevTools 패널이 VS Code 사이드바에 임베드
• CSS Mirror Editing — 인스펙터에서 바꾼 CSS 가 즉시 소스 파일에 반영

엔터프라이즈 환경에서 Windows + VS Code + Edge 조합이라면 Chrome DevTools 보다 통합도가 높다. 단점은 Chrome 본가의 신기능이 Edge 에 들어오기까지 한 메이저 버전 정도의 지연이 있다는 점이다.

6. WebDriver BiDi (W3C) — CDP 후속, 크로스 브라우저 자동화의 공용어

CDP 는 2009년경부터 Chrome 내부 프로토콜로 시작했고, Puppeteer / Playwright 가 사실상 표준처럼 써 왔다. 문제는 Chrome 전용이라는 점이다. Firefox / Safari 는 각자 다른 프로토콜 (Marionette, Inspector Protocol) 을 가지고 있어 크로스 브라우저 자동화 라이브러리는 안에서 분기해 가며 짜야 했다.

이 문제를 풀려고 W3C가 WebDriver BiDi (Bidirectional) 표준화를 시작했다. 기존 WebDriver Classic (Selenium 의 그것) 는 단방향 HTTP 요청-응답 모델이라 실시간 이벤트 (네트워크, 콘솔, DOM mutation) 를 받기 어려웠다. BiDi 는 WebSocket 기반으로 양방향이라 CDP 가 하던 일을 표준 형태로 한다.

2026년 5월 기준 진행 상황:

• Chrome / Edge — BiDi 정식 GA, 일부 도메인은 여전히 CDP 가 우월
• Firefox — BiDi 1차 구현 완료, Marionette 점진적 deprecation
• Safari — BiDi 일부 도메인 (browser, browsingContext, log) 구현, network / script 작업 중
• Selenium 4.20+ — BiDi 명령 API 정식
• Playwright 1.50+ — --use-bidi 플래그로 BiDi 백엔드 선택 가능
• Puppeteer 23+ — Firefox 지원이 BiDi 로 전환

BiDi 의 의미는 자동화 도구가 마침내 "Chrome 도 Firefox 도 Safari 도 같은 코드로" 라는 약속을 지킬 수 있게 된다는 점이다. 다만 2026년 시점에서도 모든 기능 (특히 CDP-only 인 Performance trace 일부) 이 BiDi 에 옮겨진 것은 아니라, Chrome 깊은 곳을 만지는 도구는 한동안 CDP 를 같이 쓴다.

7. Chrome AI Assistance (Gemini, 2024.4) — DevTools 내장 AI

Chrome 124 (2024년 4월) 에서 Console Insights 라는 이름으로 처음 들어왔고, 이후 AI Assistance 라는 우산 아래 Console / Network / Performance / Styles / Sources 까지 확장됐다. 2026년에는 Gemini 1.5 / 2.0 모델이 백엔드로 들어가 다음을 한다.

• Console 에러 메시지 한 줄을 받아서 원인 / 수정 제안
• Network 요청 하나를 받아서 응답 코드 / 헤더 / payload 의 의미 해설
• Performance 트레이스에서 Long Task 의 원인 함수 콜체인 자연어 설명
• Styles 패널에서 "이 요소가 왜 가운데 정렬이 안 되나" 같은 자연어 질문에 CSS 진단
• Sources 패널에서 디버거가 멈춘 지점의 변수 컨텍스트로 설명

활성화는 DevTools 우측 상단 톱니바퀴 - Preferences - Experiments - AI Assistance. Google 계정 로그인이 필요하고, 데이터는 디바운스 후 비식별화되어 Google 서버로 전송된다 (조직 정책으로 비활성화 가능).

AI Assistance 가 진짜 쓸모 있는 순간은 알 수 없는 에러를 만났을 때다. 예를 들어 콘솔의 Uncaught (in promise) DOMException: Failed to execute 'transaction' on 'IDBDatabase' 같은 메시지를 한 줄 클릭만으로 "IndexedDB 트랜잭션이 닫힌 상태에서 호출되었습니다. 원인은 ..." 처럼 풀어서 보여 준다. 검색 → 스택오버플로 → 30분이 → 30초로 줄어든다.

다만 한계도 분명하다. 사내 모노레포 코드베이스 같은 컨텍스트는 모르기 때문에 "왜 우리 코드에서 이 에러가 난다" 까지는 못 간다. 그건 IDE 측 AI (Cursor, Claude Code, GitHub Copilot Chat) 의 몫이다.

8. Performance Insights + Trace + LCP / INP / CLS — 새 워크플로

기존 Performance 패널은 트레이스를 통째로 보여 줬고, LCP / FID / CLS 가 어디서 일어났는지 사용자가 직접 찾아야 했다. 2024년 도입된 Performance Insights 가 이 흐름을 뒤집었다.

워크플로:

1. DevTools - Performance - Record - 시나리오 실행 - Stop
2. 트레이스 위에 LCP / INP / CLS 의 위치가 색상 마커로 표시
3. 사이드 패널 "Insights" 에 검출된 이슈가 카드로 정렬
4. 카드 하나를 클릭하면 원인 함수 / 네트워크 요청 / 레이아웃 시프트가 강조

대표 인사이트:

• Render-blocking request — LCP 전에 차단하는 CSS / JS
• Long Task — 메인 스레드를 50ms 이상 잡은 함수
• Forced Synchronous Layout — JS 가 layout 을 강제로 트리거
• LCP image not eagerly loaded — loading="lazy" 가 잘못 붙은 LCP 이미지
• Document request latency — TTFB 가 너무 큰 케이스

INP (Interaction to Next Paint) 는 2024년 3월 FID 를 대체한 Core Web Vitals 다. Performance Insights 는 인터랙션 별 INP 를 따로 시각화한다. 예를 들어 버튼 클릭 한 번이 250ms 의 INP 를 만들었다면 그 인터랙션의 input delay / processing time / presentation delay 가 막대로 쪼개진다. 어디를 잘라야 INP 를 줄일 수 있는지 한눈에 보인다.

9. Recorder + Workflows — 무코드 E2E 자동화

Recorder 패널은 사용자 동작을 녹화해서 재생 가능한 워크플로로 저장한다. Chrome 97 에서 베타로 시작해 2026년에는 정식 GA 상태다.

기본 흐름:

1. DevTools - Recorder - "Create a new recording"
2. URL 시작점 입력 - 녹화 시작
3. 페이지에서 클릭 / 입력 / 스크롤
4. Stop - 워크플로 저장

저장된 워크플로는 다음으로 활용한다.

• 같은 시나리오 재생 (Replay) — 회귀 확인
• Performance trace 와 묶어서 실행 — 시나리오별 성능 측정
• Export 로 코드 변환 — Puppeteer, Playwright, JSON, Cypress, WebPageTest 스크립트

예: Recorder 워크플로의 Puppeteer export 결과.

import puppeteer from 'puppeteer'

;(async () => {
  const browser = await puppeteer.launch({ headless: false })
  const page = await browser.newPage()
  await page.setViewport({ width: 1280, height: 800 })
  await page.goto('https://shop.example.com/')
  await page.locator('input[name="search"]').fill('headphones')
  await page.keyboard.press('Enter')
  await page.locator('a.product-card >> nth=0').click()
  await page.locator('button.add-to-cart').click()
  await browser.close()
})()

QA 가 직접 만든 시나리오를 개발자가 코드로 받아서 CI 의 E2E 슈트에 끼우는 식으로 워크플로를 분업할 수 있다. Cypress / Playwright 의 record 기능과 비교하면 Recorder 의 강점은 "DevTools 안에서 끝난다" 는 점, 약점은 셀렉터 안정성이 떨어진다는 점이다.

10. Workspace — DevTools 안에서 파일 편집, 디스크에 저장

Workspace 는 Sources 패널의 폴더 매핑 기능이다. 로컬 디렉터리를 DevTools 에 연결하면 인스펙터에서 CSS / JS 를 고친 내용이 디스크 파일에 그대로 저장된다. 새로고침 없이 라이브로.

설정:

1. Sources - Filesystem - "Add folder to workspace"
2. 로컬 프로젝트 폴더 선택 - 권한 허용
3. Network 패널에서 서빙되는 파일과 디스크 파일이 매핑됨 (URL 의 도메인 → 폴더)

2024년 말부터 Workspace 가 한층 더 진화한 형태가 들어왔다. 일부 환경에서는 자동 매핑 (DevTools Project 기반) 이 가능해, .devtools 폴더 하나만 두면 DevTools 가 다음 정보를 알아서 읽어 들인다.

• 워크스페이스 루트 경로
• 소스맵 매핑 규칙
• 추천 디바이스 / 네트워크 프로파일
• AI Assistance 컨텍스트 (코드베이스 구조)

CSS 미러 편집 (CSS Mirror Editing) 은 Edge DevTools 가 먼저 밀고 Chrome 이 따라온 기능이다. Styles 패널에서 색상 조정을 하면 그 변경이 SCSS / CSS 파일에 그대로 기록된다. 빌드 도구를 거치지 않아도 된다.

11. Lighthouse 12 + Lighthouse CI + PageSpeed Insights — 점수의 정치학

Lighthouse 는 2018년경부터 Chrome 의 빌트인 감사 도구다. Chrome 122 (2024년 2월) 에 들어온 Lighthouse 11 부터 INP 가 정식 메트릭이 되었고, Lighthouse 12 (2025년 후반) 에서는 Bento (메인 카드 UI) 가 갱신되어 Performance / Accessibility / Best Practices / SEO / PWA 다섯 카테고리가 한 줄로 정리된다.

로컬 Lighthouse 는 두 가지 방식이 있다.

• DevTools 안의 Lighthouse 탭 (가장 간단)
• CLI 의 lighthouse 패키지 (CI 통합용)

npm i -g lighthouse
lighthouse https://example.com --output html --output-path ./report.html

Lighthouse CI 는 GitHub Actions 같은 CI 에서 점수 회귀를 막는 도구다. 설정 예:

name: lighthouse-ci
on: pull_request

jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci && npm run build
      - run: npx @lhci/cli@latest autorun

.lighthouserc.json 에 임계값을 적어 두면 점수가 떨어진 PR 을 막을 수 있다.

{
  "ci": {
    "collect": { "url": ["http://localhost:3000/"], "numberOfRuns": 3 },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.85 }],
        "categories:accessibility": ["error", { "minScore": 0.95 }]
      }
    }
  }
}

PageSpeed Insights 는 같은 Lighthouse 엔진을 Google 서버에서 돌린 결과 + 실제 사용자 (CrUX, Chrome User Experience Report) 의 28일 평균치를 같이 보여 준다. 로컬 Lighthouse 가 "랩 데이터", PSI 의 CrUX 가 "필드 데이터" 라는 차이가 있다.

12. Privacy Sandbox debugger — 쿠키 없는 세상의 디버깅

써드파티 쿠키는 Chrome 에서 점진적 단계로 사라지고 있다. Privacy Sandbox 는 그 빈자리를 메우는 API 묶음 — Topics API (관심사 기반), Protected Audience API (구 FLEDGE, 재마케팅), Storage Access API, Attribution Reporting API, CHIPS (Cookies Having Independent Partitioned State), Federated Credential Management (FedCM) 등이다.

이 API 들은 디버깅이 어렵다. 데이터가 비식별화되어 있고, 일부는 일정 시간 후에야 발화하며, 결과를 직접 확인하기도 힘들다. 그래서 Chrome DevTools 의 Application 탭에 Privacy Sandbox 섹션이 생겼다.

확인 가능한 항목:

• Topics — 현재 사용자에게 추론된 관심사 토픽 목록
• Protected Audience — 등록된 interest group, 진행 중 / 종료된 auction
• Storage Access — iframe 별 storage 접근 권한
• Attribution Reporting — pending source / trigger 이벤트와 리포트 큐
• CHIPS — Partitioned cookie 상태
• FedCM — Identity Provider, RP 설정

테스트 환경에서는 Chrome 플래그 (chrome://flags) 로 각 API 를 강제로 켜거나 끌 수 있다.

google-chrome \
  --enable-features=BrowsingTopics,InterestGroupStorage,FledgeBiddingAndAuctionServer

광고 / 마케팅 백엔드를 만진다면 2026년 시점에서 Privacy Sandbox debugger 사용 빈도가 가장 높다.

13. Animation Inspector + Memory + JS profiler — 깊은 진단의 세 도구

Animation Inspector 는 페이지에서 발생한 CSS / Web Animations API 애니메이션을 타임라인으로 묶어 보여 준다. 활용 시점:

• transition 이 끊겨 보이는 이유 — easing 곡선, duration 충돌
• transform 이 paint 가 아니라 composite 단계에 올라갔는지
• requestAnimationFrame 루프와 CSS animation 의 동기화

Memory 패널은 두 개의 큰 도구를 갖는다.

• Heap snapshot — 특정 시점의 객체 트리를 통째로 캡처
• Allocation timeline — 시간에 따른 할당량 변화

메모리 누수 디버깅의 정석은 "Snapshot 3회 (3 snapshots) 기법" 이다. (1) 베이스라인 스냅샷 → (2) 누수 시나리오 실행 → (3) 두 번째 스냅샷 → (4) 같은 시나리오 한 번 더 → (5) 세 번째 스냅샷. 1→2→3 사이에 일관되게 늘어난 객체가 누수의 후보다. Detached DOM Tree 항목이 가장 자주 누수의 신호다.

JS Profiler (Performance 패널의 main thread 트레이스) 는 함수별 self time / total time 을 보여 준다. 2024년 이후 V8 의 sampling profiler 가 정밀해져서, 200ms 이상 잡힌 함수는 거의 확실히 잡힌다. Flame chart 의 가로 폭이 곧 시간이다.

14. Coverage tab — 사용되지 않은 코드 찾기

Coverage 탭은 페이지 로딩 / 인터랙션 동안 실제로 실행된 JS / CSS 의 비율을 보여 준다. 사용법:

1. DevTools - Coverage 탭 활성화 (Cmd/Ctrl+Shift+P → "Show Coverage")
2. Reload - 시나리오 실행
3. 각 파일별 used / unused bytes 가 표로 정렬

unused 비율이 높은 파일은 트리쉐이킹이나 code splitting 의 1차 후보다. 특히 큰 SaaS 앱에서 vendor 번들의 unused 비율은 60~80%가 흔한데, 이걸 보면서 dynamic import 로 쪼개 나간다.

주의 — Coverage 는 "이 페이지 / 이 시나리오에서 사용되지 않았다" 는 의미지, "절대 사용되지 않는다" 는 뜻이 아니다. 라우트별로 unused 한 코드를 모은 다음, 종합해서 dead code 후보를 잡는 게 정석이다.

15. Network throttling + Device emulation + CSS Overview — 환경 시뮬레이션 트로이카

Network throttling 은 Network 패널 상단의 드롭다운에서 No throttling / Slow 4G / Fast 4G / Offline 등을 고른다. 2026년에는 Custom profile 에 RTT / 다운로드 / 업로드 / packet loss 까지 지정 가능하다.

Device emulation 은 Toggle Device Toolbar (Cmd/Ctrl+Shift+M) 로 켠다. iPhone 15 Pro, Galaxy S24, iPad mini 등 프리셋이 있고, custom viewport 도 가능하다. CSS 미디어 쿼리, viewport meta, touch event 시뮬레이션, geolocation override 까지 한 화면에서.

CSS Overview 는 페이지의 CSS 통계를 페이지 1장으로 묶어 준다.

• 사용 중인 폰트, font-size, line-height 분포
• 색상 팔레트 (실제 사용된 모든 색상)
• 미디어 쿼리 목록
• 사용되지 않은 selector 후보
• contrast ratio 가 낮은 텍스트 (Accessibility 힌트)

디자인 시스템 일관성을 잡을 때 가장 빠른 도구다. 색상이 100개로 발산하고 있다면 즉시 보인다.

16. Source maps + Long task analyzer — 번들 디버깅과 INP

Source maps 는 번들된 / 압축된 / 트랜스파일된 코드를 원본 (.ts, .tsx, .jsx, .vue 등) 으로 되돌려 주는 매핑이다. 2026년의 모든 빌드 도구 (Vite, Webpack, Rspack, Turbopack, esbuild, swc) 는 source map 을 기본 생성한다.

DevTools 의 Source maps 사용 팁:

• Sources 패널에서 우클릭 - "Add source map" 으로 외부 source map 수동 지정
• Settings - Preferences - "Enable JavaScript source maps" 가 켜져 있는지 확인
• Network 패널 - Initiator 컬럼에서 source map 으로 매핑된 경로 확인
• 프로덕션 에러 보고 (Sentry 등) 도 source map 업로드를 하면 stack trace 가 원본으로

Long task analyzer 는 Performance 패널의 "Long Tasks" 트랙이다. 50ms 이상 메인 스레드를 잡은 작업이 가로 막대로 표시된다. INP 디버깅의 1차 도구다.

INP 가 나쁠 때 점검 순서:

1. Performance 녹화 - 문제 인터랙션 발생
2. 해당 인터랙션의 Long Task 가 어디서 시작했는지 확인
3. Flame chart 에서 가로로 가장 긴 함수 / 가장 깊은 콜체인 추적
4. Forced reflow 가 있는지 확인 (보라색 경고)
5. requestIdleCallback / scheduler.yield 로 양보할 수 있는지 검토

2025년 추가된 scheduler.yield() 는 INP 디버깅에서 가장 큰 변화다. 긴 작업을 명시적으로 양보하면 INP 가 즉시 떨어진다. DevTools 에서 그 효과를 trace 로 검증한다.

17. Puppeteer + Playwright + Cypress + chrome://inspect — DevTools 와 자동화의 다리

Puppeteer, Playwright, Cypress 는 모두 DevTools 의 동생 / 사촌이다. 셋 다 CDP 또는 BiDi 를 백엔드로 쓴다.

비교:

원격 디버깅의 두 시나리오:

(1) 같은 머신 — --remote-debugging-port=9222 띄우고 http://localhost:9222 접속

(2) 다른 머신 / 모바일 — chrome://inspect 사용

Android 실기 디버깅 :

1. PC 의 Chrome 에서 chrome://inspect/#devices
2. Android 폰의 개발자 옵션 - USB 디버깅 활성화
3. USB 케이블 연결
4. 폰의 Chrome 에서 사이트 열면 PC 의 chrome://inspect 에 탭이 뜸
5. "inspect" 클릭하면 PC DevTools 가 폰의 페이지에 붙음

iOS Safari 는 chrome://inspect 가 안 된다. macOS Safari + USB 케이블 + Web Inspector 만 가능하다.

18. 한국 / 일본 — 토스 perf, NAVER D2, 메르카리, Cybozu DevTools 블로그

DevTools 활용은 결국 "조직이 얼마나 깊게 성능을 챙기느냐" 와 직결된다. 한·일 사례를 보면 글로벌 흐름과 거의 동기화되어 있다.

한국:

• 토스 — toss.tech 의 Frontend 카테고리에 Lighthouse CI, INP 디버깅, Long task 분석 사례 다수. 특히 "INP를 100ms 미만으로 끌어내린 과정" 류 글이 검색 1순위로 잡힌다.
• NAVER D2 — d2.naver.com 의 프런트엔드 글. Chrome DevTools Performance / Memory snapshot 의 한글 해설은 D2 가 거의 표준 레퍼런스다.
• 카카오 if(kakao) 컨퍼런스 — 매년 DevTools 성능 사례 세션 한두 개. 발표 영상이 YouTube 에 공개.
• 우아한형제들 (배민) — woowahan.com/tech 의 프런트엔드 성능 사례. CrUX 와 RUM 을 함께 다룬다.

일본:

• メルカリ engineering — engineering.mercari.com 의 Web Performance 시리즈. Lighthouse, INP, Core Web Vitals 사례.
• Cybozu Frontend — blog.cybozu.io 에 Chrome DevTools 와 Playwright 통합 글이 정기적으로 올라온다.
• LINE Yahoo techblog — techblog.lycorp.co.jp. JP 도메인의 RUM 데이터를 바탕으로 한 디버깅 사례 다수.
• DeNA testblog — testblog.dena.com. 자동화 / E2E 측면에서 Cypress / Playwright 의 BiDi 전환 사례 공유.

영문권의 web.dev 와는 결이 다르다. 모바일 환경 (한국의 3사 통신망, 일본의 docomo / au / softbank) 의 실제 4G / 5G RTT 데이터를 들고 와서 Network throttling 프로파일을 만드는 식의 글이 많다.

19. 누가 무엇을 깊게 배워야 하나 — 풀스택 / 프론트엔드 / 모바일 웹

DevTools 는 광범위하다. 역할별 우선순위를 정리해 본다.

추천 학습 순서 (프런트엔드 신입 기준):

1. Elements + Styles + Network + Console — 1주
2. Sources (브레이크포인트, conditional, logpoint) — 1주
3. Performance + Performance Insights — 2주
4. Memory + Coverage — 1주
5. Lighthouse 로컬 + CI — 1주
6. Recorder + Workspace — 1주
7. AI Assistance — 그때부터 모든 단계의 보조

여기까지 7~8주면 DevTools 의 80%를 쓰는 사람이 된다. 나머지 20%는 케이스별로 마주칠 때마다 익히면 된다.

20. 참고 / References

• Chrome DevTools 공식 — https://developer.chrome.com/docs/devtools
• Chrome DevTools Protocol — https://chromedevtools.github.io/devtools-protocol/
• WebDriver BiDi (W3C 초안) — https://w3c.github.io/webdriver-bidi/
• Firefox DevTools — https://firefox-source-docs.mozilla.org/devtools-user/
• Safari Web Inspector — https://webkit.org/web-inspector/
• Edge DevTools — https://learn.microsoft.com/microsoft-edge/devtools-guide-chromium/
• Lighthouse — https://developer.chrome.com/docs/lighthouse
• Lighthouse CI — https://github.com/GoogleChrome/lighthouse-ci
• PageSpeed Insights — https://pagespeed.web.dev/
• Core Web Vitals — https://web.dev/articles/vitals
• INP 가이드 — https://web.dev/articles/inp
• Privacy Sandbox — https://privacysandbox.com/
• Chrome AI Assistance — https://developer.chrome.com/docs/devtools/ai-assistance
• Recorder — https://developer.chrome.com/docs/devtools/recorder
• Workspace — https://developer.chrome.com/docs/devtools/workspaces
• Puppeteer — https://pptr.dev/
• Playwright — https://playwright.dev/
• Cypress — https://www.cypress.io/
• 토스 Frontend — https://toss.tech/tech/categories/frontend
• NAVER D2 — https://d2.naver.com/
• 메르카리 engineering — https://engineering.mercari.com/
• Cybozu Frontend — https://blog.cybozu.io/
• web.dev — https://web.dev/