Chrome DevTools MCP 써보기

평화로운 어느 날 아침...

종근님께서 무언가를 보내주셨다

 

https://duck-blog.vercel.app/blog/web/chrome-devtools-mcp-game-changer

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

 

일단 제목부터 레전드 어그로 (이목을 끈다는 뜻, positive)

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

 

 

넵 (뼈 부러져서 순살치킨 됨)

---

 

Chrome DevTools 시작하기

 

의외로 간단함!

 

cursor에서 쓰는 경우

 

1. 우상단 설정 버튼을 누른다

 

2. 좌측 메뉴에서 Tools&Integrations 클릭 > New MCP Server 클릭

 

3. mcp.json에 추가해준다

{
  "mcpServers": {
	// 그 외 다른 mcp 툴들 코드
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

 

4. cursor 창에 'chrome devtools mcp를 사용해줘'라는 프롬프트로 대화를 시작한다

이렇게 테스트용 크롬 브라우저가 하나 켜짐

이제 이 브라우저를 cursor가 직접 제어하면서 dom 요소를 읽거나, 콘솔 로그를 읽으면서 스스로 디버깅할 수 있음

 

#페이지 관리
list_pages - 열린 페이지 목록 확인
new_page - 새 페이지 열기
navigate_page - URL로 이동
select_page - 페이지 선택

#페이지 분석
take_snapshot - 페이지의 텍스트/구조 스냅샷
take_screenshot - 스크린샷 촬영
list_network_requests - 네트워크 요청 분석
list_console_messages - 콘솔 로그 확인

#페이지 조작
click - 요소 클릭
fill - 입력 필드 채우기
evaluate_script - JavaScript 실행
hover, drag - 마우스 인터랙션

#성능 분석
performance_start_trace - 성능 측정 시작
performance_stop_trace - 성능 측정 종료
emulate - CPU/네트워크 제한 에뮬레이션

 

cursor는 이런 작업들을 해볼 수 있다고 응답함

호오 그럼 LCP 측정도 간단히 해볼 수 있겠구만

 

일단 claude code에서 사용하는 방법도 마저 적어두겠음

 

claude code에서 쓰는 경우

 

1. terminal에서 claude를 입력해 claude code를 실행시킨다

2. 아래 명령어를 입력한다

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest

 

얘가 훨씬 간단하군

 

그냥 본인이 cursor랑 claude 중 무엇을 더 간편하게 느끼는지에 따라 다를 듯

 

그 외 다른 방법들

http://github.com/ChromeDevTools/chrome-devtools-mcp/?tab=readme-ov-file#chrome-devtools-mcp

GitHub - ChromeDevTools/chrome-devtools-mcp: Chrome DevTools for coding agents

공식 문서에 더 다양한 방법들이 나와있음

MCP Client Configuration 참고!

 

---

Chrome DevTools MCP 써보기

 

실무 예제: '이 요소가 가장 위로 올라올 때까지 디버깅하면서 고쳐봐'

 

구현 목표

1. 검은색 영역과 주황색 영역은 서로 붙어있음

2. 검은색 영역 안에 하늘색 요소가 존재함

3. 하늘색 요소 위에 핑크색 요소를 얹어야 함

4. 핑크색 요소는 가장 상위로 올라와야 함 (검은색, 하늘색, 주황색 요소보다 위에 있어야 함)

 

문제 상황

1. 검은색 요소는 overflow-y-hidden

2. 하늘색 요소 위에 핑크색 요소를 얹을 수 있으나, 검은색 영역을 벗어난 부분은 안보임

3. div가 너무 겹겹이 쌓여있어서 어떤 속성이 어디까지 영향 주는지 파악이 어려움

4. ai에게 프롬프트로 '핑크색 요소가 가장 위로 올라오게 해줘'라고 해도 ai는 ui를 직접 인식하지 못함

 

나의 시도

-> 핑크색 요소가 가장 위로 올라올 때가지 dev tools, 콘솔 로그 등 chrome에서 확인 가능한 모든 것을 사용해서 고쳐봐

 

Chrome DevTools MCP의 시도

1. dev tools에서 dom 요소를 직접 읽어서 구조를 파악함

- 이게 굉장히 놀랐던 부분.

- 종종 필요하면 프롬프트 입력할 때 dev tools 열어서 elements 좀 복사해서 붙여넣고 했었는데, 워낙 방대하니 한계가 있었음

- 근데 얘는 그냥 필요한 Dom을 알아서 추출해서 읽더니 막 분석함

 

2. 레포지토리 구조와 dom 구조를 동시에 분석함

- cursor나 claude code는 기존에 레포지토리 전체를 읽을 수 있었음

- 그런데 chrome 창을 연결해 dom을 같이 분석하니, 좀 더 넓은 시야로 분석을 시도하는 느낌을 받았음

 

결론

1. 결국 해결하진 못했음;

2. 기반 구조 전체를 다 건드리기에 이 기능의 임팩트는 미미했음

3. 디자이너님과 합의해 검은색 영역을 벗어나지 않는 스펙으로 변경

4. 하지만, 이 기능을 구현하려고 시도한 덕분에 새로운 툴을 써봤음! 유익했다

5. 잘 쓰면 정말 시너지가 엄청날 것 같음

 

실무 예제: '내가 로컬에서 14MB의 파일을 삭제했는데, 실제로 성능적으로 유의미한지 궁금해'

 

목표

최근에 큰 맘 먹고 사이버 노가다 해서 31MB 파일을 날렸다 (거의 파일 250개 이상)

안쓰는 파일 날리고, 서버에 업로드하고 등등

 

이게 진짜 유의미한지 궁금해짐

performance_start_trace 명령어로 분석 시켜봄

 

결과

LCP 측정은 진심 뚝~딱 해줌

그리고, LCP 개선을 위해 적용 가능한 방법도 소개해줌

 

근데 로컬 파일 날리는건 LCP에는 크게 영향이 없었다;

 

교훈

그래도, 새로운 시도를 해볼 수 있었는데,

브랜치를 오가면서 성능 분석을 시킬 때 정말 편리했다

 

1. 브랜치 1: 내가 파일을 날리지 않은 브랜치

2. 브랜치 2: 내가 파일을 날린 브랜치

 

나는 브랜치1과 브랜치2를 왔다갔다 하면서 성능을 측정해보고 싶었다

원래라면 내가 직접 브랜치를 이동하면서 측정했을 듯?

 

근데, Chrom DevTools MCP에게는 이렇게 한 마디로 시킬 수 있다.

'브랜치1과 브랜치2에는 31MB 에셋 용량만큼 차이가 있어, 난 이게 실제로 퍼포먼스에도 영향이 있는지 궁금해.'

 

굉장한 시간 절약이 가능했다!

응용해서 다른 작업들도 해봐야지

 

---

아직은 이만큼만 써봤는데, 무궁무진한 가능성이 있어보임!

실무에 더 적용해보고 후속글을 가져오겠습니다

 

종근님이 말씀해주신 '너가 직접 콘솔 로그 찍어보면서 될 때까지 구현해줘'라던가...

기능 개발하면서 더 시도해보고 싶음!

 

좋은 인사이트 주신 종근님께 감사드립니다 🙇‍♀️

종버지 그저 갓.

 

---

여담으로, 올 여름에 토스 메이커스 컨퍼런스 들었던 e2e 테스트 세션이 생각났음

 

🔽 토스 메이커스 컨퍼런스 후기 글

https://developer-dreamer.tistory.com/188

[토스 컨퍼런스] TOSS MAKERS CONFERENCE 25 후기

 

 

그때 말씀하셨던 Chrome Devtools Protocol을 최대로 활용한게

이 Chrome Devtools MCP 아닌가 싶은...?(아닐수도 있음)

 

아무튼 갑자기 그 강연이 퍼뜩 떠올라서 뭔가 머릿속에서 지식 퍼즐 조각이 합쳐지는 느낌이 들었고 재밌었다

이게 나옴으로서 연사분이 원하시던 구현을 좀 더 쉽게 할 수 있지 않을까 싶음

(당시에 Chrome Devtools에 대한 레퍼런스가 많이 않아서 좀 힘들었다고 하셨던 기억이 어렴풋이...)

---

종근님께서 이걸 알려주신 날짜 2025.11.13.

내가 이걸 써본 날짜 2025.11.26.

이 글을 쓴 날짜 2025.11.29.

 

좀 더 빨리 써봤어야 했다... 반성합니다

 

그럼 이제 진짜 끝!

이만.