duck blog
안 쓰고 있다면 진짜 이건 손해입니다: Chrome DevTools MCP

안 쓰고 있다면 진짜 이건 손해입니다: Chrome DevTools MCP

안 쓰고 있다면 진짜 이건 손해입니다

Chrome DevTools MCP 공식 블로그

최근 Chrome에서 공식적으로 제공하는 Chrome DevTools MCP(Model Context Protocol) 를 접하게 되었습니다. 다양한 MCP 를 많이 시도했지만 이정도로 실무에 도움이 되는 MCP 는 없다고 강하게 얘기할 수 있을 정도입니다.

특히 console 로그 기반 디버깅, AI가 문제를 발견하고 자동으로 수정, 그리고 AI가 E2E 시나리오를 자동 생성 하는 기능은 정말 게임 체인저라고 생각합니다.

Chrome DevTools MCP란?

MCP(Model Context Protocol) 는 AI 모델이 외부 도구와 상호작용할 수 있도록 하는 표준 프로토콜입니다. Chrome DevTools MCP는 이 프로토콜을 활용해 Chrome 브라우저를 AI 에이전트가 직접 제어할 수 있게 해주는 도구입니다.

이 글에서는 MCP 자체에 대한 깊은 고찰보다는, Chrome DevTools MCP의 실용적인 활용에만 포커싱하겠습니다.

핵심 특징

  • AI 친화적 설계 : LLM이 이해하기 쉬운 함수 인터페이스 제공
  • 실시간 상호작용 : 브라우저 상태를 실시간으로 읽고 조작
  • Chrome 공식 지원 : Chrome 팀이 직접 개발하고 유지보수
  • 접근성 트리 기반 : 스크린 리더가 사용하는 방식으로 페이지 이해

Puppeteer, Playwright도 MCP가 있는데 왜 Chrome DevTools MCP?

많은 개발자들이 "그냥 Puppeteer MCP 쓰면 되는 거 아니야?"라고 물어봅니다. 맞습니다. Puppeteer와 Playwright도 MCP 서버가 있습니다. 하지만 Chrome DevTools MCP를 써야 하는 이유가 분명히 있습니다.

1. Chrome 공식 지원의 힘

Chrome DevTools MCP는 Chrome 팀이 직접 개발하고 유지보수합니다. 이게 왜 중요할까요?

  • 최신 Chrome 기능 즉시 사용 가능: Performance Insights, Core Web Vitals 측정 등 Chrome DevTools의 최신 기능을 바로 사용할 수 있습니다
  • 안정성 보장: Chrome 업데이트와 함께 MCP도 업데이트되므로 호환성 문제가 거의 없습니다
  • 성능 분석 도구 내장: Puppeteer/Playwright에서는 별도로 구현해야 하는 성능 분석 기능이 기본 제공됩니다
// Chrome DevTools MCP만의 강력한 성능 분석
await mcp.performance_start_trace({ reload: true });
// ... 사용자 시나리오 수행
const trace = await mcp.performance_stop_trace();

// LCP, FID, CLS 등 Core Web Vitals 자동 수집
const insights = await mcp.performance_analyze_insight({
  insightName: 'LCPBreakdown',
});

// Puppeteer/Playwright에서는 이런 기능을 직접 구현해야 합니다

2. Console & Network 모니터링의 편의성

Puppeteer/Playwright MCP에서도 console 로그를 볼 수 있지만, Chrome DevTools MCP는 DevTools와 동일한 인터페이스를 제공합니다.

// Chrome DevTools MCP: DevTools 그대로
const logs = await mcp.list_console_messages({
  types: ['error', 'warn'],
  includePreservedMessages: true, // 이전 페이지 로그도 보존
});

const detail = await mcp.get_console_message({ msgid: log.msgid });
// stackTrace, timestamp, 상세 정보 모두 포함

// 네트워크 요청도 마찬가지
const requests = await mcp.list_network_requests({
  resourceTypes: ['xhr', 'fetch'],
});

const reqDetail = await mcp.get_network_request({ reqid: req.reqid });
// requestHeaders, responseHeaders, responseBody, timing 모두 확인 가능

3. 접근성 트리 기반 스냅샷

Chrome DevTools MCP는 접근성 트리(Accessibility Tree) 를 기반으로 페이지를 이해합니다. 이게 왜 중요할까요?

// Chrome DevTools MCP
const snapshot = await mcp.take_snapshot();
// AI가 이해하기 쉬운 구조화된 데이터
// "로그인 버튼", "이메일 입력 필드" 같은 의미론적 정보 포함

// Puppeteer/Playwright
// DOM 구조를 직접 파싱해야 함
const html = await page.content();
// AI가 HTML을 파싱하고 이해하는 추가 작업 필요

실제 차이:

  • DOM 구조가 바뀌어도 "로그인 버튼"이라는 의미는 유지되므로 테스트가 깨지지 않습니다
  • AI가 페이지를 이해하는 데 필요한 토큰이 훨씬 적습니다

4. 기존 테스트 코드 그대로 활용 가능

이미 Puppeteer나 Playwright로 작성된 테스트가 있다면? 그대로 사용하면서 Chrome DevTools MCP의 장점만 추가로 활용할 수 있습니다.

// 기존 Playwright 테스트는 그대로 유지
test('로그인 테스트', async ({ page }) => {
  await page.goto('https://example.com');
  await page.click('#login');
  // ... 기존 코드
});

// Chrome DevTools MCP로 추가 분석
// AI에게: "이 테스트 실행 중 console 에러가 있는지 확인해줘"
// AI에게: "이 테스트의 성능 병목 지점을 찾아줘"

셀렉터 방식의 차이

Chrome DevTools MCP의 가장 큰 차별점은 접근성 트리 기반 UID를 사용한다는 것입니다.

도구셀렉터 방식장점단점
Puppeteer MCPCSS/XPath정확한 제어DOM 변경에 취약
Playwright MCPCSS/Text/Role다양한 옵션여전히 DOM 의존적
Chrome DevTools MCPUID (접근성 트리)DOM 변경에 강함, AI 친화적-
// Puppeteer/Playwright MCP
// DOM 구조에 의존
await page.click('.login-form button.primary');
// 클래스명이 바뀌면 테스트 깨짐

// Chrome DevTools MCP
// 접근성 트리의 의미론적 정보 사용
const snapshot = await mcp.take_snapshot();
// AI가 "로그인 버튼"이라는 의미를 이해
await mcp.click({ uid: 'login-button-uid' });
// DOM 구조가 바뀌어도 "로그인 버튼"이라는 의미는 유지

Chrome DevTools MCP가 제공하는 주요 함수들

Chrome DevTools MCP 도구 호출 과정

위 이미지처럼 AI가 자연어 명령을 받으면 자동으로 적절한 MCP 도구들을 호출합니다. 이제 어떤 함수들이 있는지 살펴보겠습니다.

1. 페이지 네비게이션

// 페이지 이동
await mcp.navigate_page({ url: 'https://example.com' });

// 뒤로/앞으로 가기
await mcp.navigate_page_history({ navigate: 'back' });

// 새 탭 열기
await mcp.new_page({ url: 'https://example.com' });

2. 페이지 상태 캡처

// 접근성 트리 기반 스냅샷 (AI가 이해하기 쉬움)
const snapshot = await mcp.take_snapshot({ verbose: false });

// 스크린샷
await mcp.take_screenshot({
  format: 'png',
  fullPage: true,
  filePath: './screenshot.png',
});

3. 사용자 인터랙션

// 클릭
await mcp.click({ uid: 'button-123' });

// 폼 입력
await mcp.fill({ uid: 'input-email', value: 'user@example.com' });

// 여러 폼 한번에 입력
await mcp.fill_form({
  elements: [
    { uid: 'name', value: 'John Doe' },
    { uid: 'email', value: 'john@example.com' },
  ],
});

4. 네트워크 & 콘솔 모니터링

// 네트워크 요청 목록
const requests = await mcp.list_network_requests({
  resourceTypes: ['xhr', 'fetch'],
  pageSize: 50,
});

// 콘솔 메시지 확인
const consoleLogs = await mcp.list_console_messages({
  types: ['error', 'warn'],
});

5. 성능 분석

// 성능 트레이스 시작
await mcp.performance_start_trace({
  reload: true,
  autoStop: false,
});

// 트레이스 중지 및 분석
const performanceData = await mcp.performance_stop_trace();

6. JavaScript 실행

// 커스텀 스크립트 실행
const result = await mcp.evaluate_script({
  function: `() => {
    return {
      title: document.title,
      url: window.location.href
    };
  }`,
});

실무 활용 사례

1. Console 로그 기반 실시간 디버깅

가장 강력한 기능 중 하나는 실시간 console 로그 모니터링 입니다. 프로덕션 환경에서 재현하기 어려운 버그를 추적할 때 특히 유용합니다.

사용 방법

나 → AI: "example.com에서 발생하는 모든 에러를 찾아줘"

AI가 자동으로 MCP 함수 호출:
1. mcp.navigate_page() - 페이지 접속
2. mcp.list_console_messages() - Console 에러/경고 수집
3. mcp.get_console_message() - 각 에러의 상세 정보 (stackTrace, timestamp) 분석
4. 결과 리포트

실전 활용 사례 : 프로덕션에서 특정 상품 상세 페이지가 간헐적으로 빈 화면으로 렌더링되는 이슈가 발생했습니다. 재현이 어려워서 원인을 찾기 힘들었는데, AI에게 디버깅을 요청하니 바로 원인을 찾았습니다.

나 → AI

"shop.example.com/product/12345 페이지에서 빈 화면이 나오는데,
console 에러를 찾아서 원인을 분석해줘"

AI → 나 (분석 결과)

다음 에러를 발견했습니다:

❌ SyntaxError: Unexpected token in JSON at position 1234
   at ProductDetail.tsx:45

네트워크 요청을 확인한 결과, API 응답에 문제가 있습니다:

{
  "productId": 12345,
  "price": "1,000원",  // ❌ 숫자여야 하는데 문자열
  "stock": 10
}

price 필드가 "1,000원" (문자열)로 오고 있어서
JSON.parse() 시 에러가 발생하고,
이로 인해 컴포넌트 렌더링이 실패하고 있습니다.

백엔드 API에서 price를 숫자 1000으로 보내도록 수정이 필요합니다.

실제 경험 : 이 문제를 찾는 데 기존에는 로그를 일일이 확인하고 재현하느라 오래 걸렸는데, AI에게 한 줄로 요청하니 5분 만에 원인을 특정했습니다.

AI가 내부적으로 사용한 MCP 함수들:

1. mcp.navigate_page() - 페이지 접속
2. mcp.list_console_messages() - Console 에러 수집
3. mcp.get_console_message() - 에러 상세 정보 확인
4. mcp.list_network_requests() - 네트워크 요청 목록
5. mcp.get_network_request() - API 응답 데이터 확인
6. mcp.take_screenshot() - 현재 화면 캡처

MCP 없이는 개발자가 직접:

  1. 브라우저 DevTools 열기
  2. Console 탭에서 에러 찾기
  3. Network 탭에서 API 요청 찾기
  4. 응답 데이터 일일이 확인
  5. 에러와 API 응답 연결해서 분석

이 모든 과정을 AI가 자동으로 해주니, 개발자는 문제 해결에만 집중할 수 있습니다.

2. AI가 문제를 발견하고 자동으로 수정

이게 진짜 게임 체인저입니다. AI가 브라우저에서 직접 문제를 확인하고 코드를 수정합니다.

실제 사례: 잘못된 Fallback으로 인한 UI 깨짐

프로덕션에서 사용자 프로필 이미지가 로드 실패 시 깨진 이미지 아이콘이 표시되는 문제가 발생했습니다. Fallback 이미지 경로가 잘못되어 있었습니다.

나 → AI:
"localhost:3000/profile 페이지에서 프로필 이미지가 깨져 보이는데,
원인을 찾아서 수정해줘"

AI가 MCP 함수로 자동 분석 및 수정:
1. mcp.navigate_page() - /profile 페이지 접속
2. mcp.take_screenshot() - 현재 상태 캡처 (깨진 이미지 확인)
3. mcp.list_console_messages() - Console 에러 확인
   → "Failed to load resource: /images/default-avatar.png 404"
4. mcp.list_network_requests() - 네트워크 요청 분석
   → GET /images/default-avatar.png → 404 Not Found
5. (파일 시스템 도구로) 코드 분석
   → ProfileImage.tsx에서 fallback 경로 발견
6. (파일 시스템 도구로) 코드 수정
   → fallback="/images/default-avatar.png"
   → fallback="/assets/default-avatar.png" (올바른 경로)
7. mcp.navigate_page() - 페이지 새로고침
8. mcp.take_screenshot() - 수정 후 상태 캡처
9. mcp.list_console_messages() - 에러 해결 확인

AI → 나:
"✅ 문제를 찾아서 수정했습니다.

원인: ProfileImage.tsx의 fallback 경로가 잘못되어 있었습니다.
- 기존: /images/default-avatar.png (404 에러)
- 수정: /assets/default-avatar.png (정상 로드)

[before.png] [after.png] 첨부
Console 에러도 모두 해결되었습니다."

실제 경험 : 이런 문제를 찾는 데 기존에는:

  1. 브라우저 DevTools 열기
  2. Console에서 404 에러 찾기
  3. Network 탭에서 실패한 요청 확인
  4. 코드에서 해당 경로 검색
  5. 올바른 경로 찾기
  6. 코드 수정
  7. 빌드 후 확인

이 과정이 10-15분 걸렸는데, AI에게 한 줄로 요청하니 2분 만에 자동으로 해결했습니다. AI가 문제 발견 → 원인 분석 → 코드 수정 → 검증까지 모두 자동으로 처리했기 때문입니다.

3. AI가 E2E 테스트 시나리오를 자동 생성

기존 E2E 테스트의 가장 큰 문제는 시나리오를 일일이 작성해야 한다 는 것입니다. MCP는 이걸 완전히 바꿔놓습니다.

// 기존 방식: 개발자가 모든 시나리오를 수동 작성
describe('결제 플로우', () => {
  it('정상 결제', async () => { /* 50줄의 코드 */ });
  it('카드 오류', async () => { /* 50줄의 코드 */ });
  it('재고 부족', async () => { /* 50줄의 코드 */ });
  // ... 수십 개의 케이스
});

// MCP 방식: AI에게 자연어로 요청
"우리 쇼핑몰의 결제 플로우를 테스트할 수 있는
모든 시나리오를 만들고 실행해줘"

AI가 자동으로 생성하는 시나리오 :

나 → AI:
"우리 쇼핑몰의 결제 플로우를 테스트하는 시나리오를 만들고 실행해줘"

AI가 자동으로:
1. mcp.navigate_page() - 페이지 접속
2. mcp.take_snapshot() - 페이지 구조 분석
3. 가능한 시나리오 도출:
   - 정상 결제 플로우
   - 빈 장바구니 결제 시도
   - 잘못된 카드 정보
   - 재고 부족 상품 구매
   - 쿠폰 적용 후 결제
   - ... (20-30개 시나리오)
4. 각 시나리오 자동 실행 (mcp.click, mcp.fill, mcp.take_screenshot)
5. 결과 리포트

AI → 나:
"총 27개 시나리오 테스트 완료
✅ 성공: 24개
❌ 실패: 3개

실패한 케이스:
1. '쿠폰 중복 적용' - 에러 메시지 미표시 [screenshot]
2. '배송지 미입력' - 결제 진행됨 (버그) [screenshot]
3. '재고 0인 상품' - 장바구니 추가 가능 (버그) [screenshot]"

실제 경험 : 새로운 기능을 배포하기 전에 QA 팀이 수동으로 테스트 케이스를 작성하고 실행하는 데 2-3일이 걸렸습니다. MCP를 도입한 후, AI에게 "이 기능의 모든 엣지 케이스를 테스트해줘"라고 요청하면 30분 안에 50개 이상의 시나리오를 생성하고 실행합니다.

특히 놀라웠던 건, AI가 우리가 생각하지 못한 엣지 케이스까지 찾아낸다는 것입니다. 예를 들어 "이메일 입력 필드에 공백만 입력했을 때", "브라우저 뒤로가기 버튼을 연속으로 눌렀을 때" 같은 시나리오를 자동으로 생성했습니다.

4. 네트워크 요청 디버깅

API 호출 문제를 추적할 때 엄청 유용합니다.

나 → AI:
"이 페이지에서 실패하는 API 요청을 찾고 원인을 분석해줘"

AI가 MCP 함수로 자동 분석:
1. mcp.navigate_page() - 페이지 접속
2. mcp.click() - 사용자 액션 수행
3. mcp.list_network_requests() - 모든 네트워크 요청 수집
4. mcp.get_network_request() - 실패한 요청 상세 분석

AI → 나:
"3개의 실패한 API 요청을 발견했습니다:

1. GET /api/products/12345 - 404 Not Found
   - 요청 시간: 150ms
   - 원인: 상품 ID가 존재하지 않음

2. POST /api/cart/add - 500 Internal Server Error
   - 요청 시간: 3.2s
   - Request Body: { productId: null, quantity: 1 }
   - 원인: productId가 null로 전송됨

3. GET /api/user/profile - 401 Unauthorized
   - 요청 시간: 200ms
   - 원인: Authorization 헤더 누락"

실제 경험 : 프로덕션에서 간헐적으로 발생하는 API 타임아웃 문제가 있었습니다. 로컬에서는 재현이 안 됐는데, AI에게 "Slow 3G 환경에서 테스트해줘"라고 요청하니 바로 재현됐습니다. AI가 mcp.emulate_network()로 네트워크를 느리게 설정하고, 특정 API가 30초 이상 걸리는 것을 확인했습니다. 해당 API에 타임아웃 설정과 로딩 상태 처리를 추가해서 문제를 해결했습니다.

5. 성능 병목 지점 자동 발견

나 → AI:
"이 페이지의 성능 문제를 찾고 개선 방법을 제안해줘"

AI가 MCP 함수로 자동 분석:
1. mcp.performance_start_trace() - 성능 트레이스 시작
2. mcp.navigate_page() - 페이지 로드
3. mcp.performance_stop_trace() - 트레이스 중지
4. mcp.performance_analyze_insight() - 병목 지점 분석

AI → 나:
"성능 분석 결과:

📊 Core Web Vitals
- LCP: 4.2s (개선 필요)
- FID: 120ms (양호)
- CLS: 0.15 (개선 필요)

🔍 병목 지점:
1. 메인 이미지 로드 (2.8s) - 최적화 필요
2. 외부 스크립트 (Google Analytics) - 지연 로딩 권장
3. 렌더링 블로킹 CSS (800ms)

💡 개선 방안:
1. 이미지를 WebP로 변환하고 lazy loading 적용
2. 스크립트에 defer 속성 추가
3. Critical CSS 인라인 처리"

시작하기

실전에서 발견한 주의사항

Context 사용량 관리

Chrome DevTools MCP는 강력하지만, 모든 콘솔 로그와 네트워크 요청을 가져오면 AI Context를 엄청나게 소비합니다.

❌ 비효율적인 사용:
"이 페이지의 모든 console 로그와 모든 네트워크 요청을 분석해줘"
→ 수백 개의 로그/요청이 Context에 포함되어 토큰 낭비

✅ 효율적인 사용:
"이 페이지에서 에러 레벨의 console 로그만 찾아줘"
"실패한 API 요청(4xx, 5xx)만 분석해줘"
→ 필요한 정보만 필터링하여 Context 절약

권장 사항:

  • list_console_messages()는 항상 types 필터 사용 (['error', 'warn'])
  • list_network_requests()는 resourceTypes 필터 사용 (['xhr', 'fetch'])
  • 전체 분석이 필요하면 단계별로 나눠서 요청

마치며

디버깅이나 특정 구현에 있어 진짜 많은 시간을 단축시킨 MCP라고 생각합니다. 실제로 Puppeteer MCP, Playwright MCP도 사용해봤지만, Chrome DevTools MCP가 확실히 AI 친화적이며 강력하다고 느꼈습니다. (물론 브라우저를 변경하거나 크로스 브라우저 테스트는 Puppeteer, Playwright의 장점도 분명히 존재합니다.)

이미 저와 함께 일하는 프론트엔드 동료들은 실무에서 잘 활용하여 분석하고 디버깅하고 있습니다.

백엔드 개발자분들에게도 추천합니다. 네트워크 관련 테스트할 때 클라이언트 지식이 없어도 쉽게 분석이 가능합니다. 예전에는 개발자 도구를 직접 열어서 어떤 이벤트가 발생했을 때 어떤 네트워크 통신이 일어났고, 이때 어떤 콘솔 에러가 발생했는지 일일이 분석하는 데 시간이 너무 많이 소요되었는데, 이제는 AI에게 물어보면 됩니다.

여러분도 손해 보지 마시고 사용하십시오.

참고 자료