클로드 코드 Playwright MCP로 블로그 62페이지 자동 점검 — 모바일 가로 넘침 찾고 고친 실험
클로드 코드(Claude Code)에 Playwright MCP를 붙여 이 블로그 전체 페이지를 자동으로 점검해 봤다. 시작은 휴대폰으로 글을 보다가 "화면이 좌우로 밀린다"는 걸 알아챈 것이었다. 어느 페이지가, 왜, 얼마나 밀리는지를 사람이 하나씩 열어 보며 찾기는 어렵다. AI에게 브라우저를 쥐여 주고 재 보니, 휴대폰 폭(390px)에서 화면이 최대 1,365px까지 옆으로 늘어나는 페이지들이 나왔다. 원인을 고친 뒤 사이트맵의 62개 페이지를 다시 돌려 넘침 0건을 확인했다. 이 글은 그 과정과, 해 보고 나서 알게 된 'MCP를 잘 쓰는 법'에 대한 기록이다.
Playwright MCP는 마이크로소프트가 만든 MCP 서버다. 저장소 소개는 이렇다. "A Model Context Protocol (MCP) server that provides browser automation capabilities using Playwright."(Playwright 로 브라우저 자동화 기능을 제공하는 MCP 서버.) MCP(Model Context Protocol)는 AI 에이전트가 외부 도구를 같은 방식으로 불러 쓰게 해 주는 연결 규격이다. 이걸 붙이면 AI가 직접 브라우저를 열고, 페이지를 이동하고, 화면 크기를 바꾸고, 페이지 안에서 코드를 실행할 수 있다. 10월 2일 기준 버전은 0.0.83, 라이선스는 Apache-2.0, GitHub 별은 약 3만 7천 개다.
붙이는 법은 한 줄
공식 README에 나온 클로드 코드용 명령은 이것뿐이다.
claude mcp add playwright npx @playwright/mcp@latest
그다음부터는 대화로 시킨다. "휴대폰 폭으로 이 페이지를 열어서 가로로 넘치는 요소가 있는지 봐 줘" 같은 식이다. AI는 browser_resize(창 크기 변경), browser_navigate(이동), browser_evaluate(페이지 안 코드 실행) 같은 도구를 골라 쓴다. 화면 캡처 대신 접근성 트리(페이지 구조를 글자로 표현한 것)를 읽기 때문에, 이미지를 보는 모델이 없어도 된다. README도 "No vision models needed, operates purely on structured data."(비전 모델 없이 구조화된 데이터로만 동작한다)라고 설명한다.
실제로 찾은 것: 출처 줄 하나가 페이지를 밀었다
처음 시킨 일은 단순했다. 주요 페이지 13개를 390px로 열고, 문서 전체 폭(scrollWidth)이 화면 폭보다 큰지, 넘친다면 어떤 요소가 넘치는지 찾는 것이다. 13개 중 6개가 넘쳤다.
| 페이지(일부) | 390px에서 실제 폭 |
|---|---|
| 개인정보 탐지 실험 글 | 1,365px |
| 광명동굴 빛축제 | 1,320px |
| 근로장려금 | 1,137px |
| 에너지바우처 | 961px |
| 인천 연수 크리스마스트리 | 917px |
| Ubuntu 26 러너 | 729px |
넘친 요소는 전부 같았다. 글 맨 아래 '출처' 상자의 링크 묶음이다. 링크와 링크 사이에 줄을 바꿀 자리가 없어서, 출처가 5개를 넘는 글은 한 줄로 길게 이어지며 화면 밖으로 나갔다. 공교롭게도 사실 확인을 꼼꼼히 해서 출처를 많이 단 글일수록 더 심했다.
고친 건 CSS 두 단어다. 링크 묶음에 flex-wrap을 주고 긴 링크에 break-all을 줬다. 그 뒤 사이트맵의 모든 주소를 같은 방식으로 다시 돌렸다. 62개 페이지 모두 390px 안에 들어왔다.
MCP를 잘 쓰는 요령: 한 번에 한 페이지씩 시키지 말 것
처음엔 페이지마다 "열어 봐 → 구조 읽어 봐 → 다음 페이지"를 반복했다. 이렇게 하면 페이지 하나마다 접근성 트리 전체가 AI의 문맥(context)에 들어온다. 수십 페이지면 금방 무거워진다.
재미있게도 Playwright MCP README가 직접 이 점을 짚는다. "CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context"(CLI 호출이 토큰을 덜 쓴다 — 큰 도구 설명과 장황한 접근성 트리를 모델 문맥에 싣지 않기 때문이다). 그래서 방식을 바꿨다. browser_run_code(Playwright 코드 실행) 도구로 반복문 전체를 한 번에 넘기고, AI에게는 요약 결과만 돌려받는다.
async (page) => {
const sitemap = await (await page.request.get('https://postbogi.com/sitemap.xml')).text();
const urls = [...sitemap.matchAll(/<loc>([^<]+)<\/loc>/g)].map(m => m[1]);
await page.setViewportSize({ width: 390, height: 844 });
const bad = [];
for (const u of urls) {
await page.goto(u, { waitUntil: 'domcontentloaded', timeout: 60000 });
const [cw, sw] = await page.evaluate(() =>
[document.documentElement.clientWidth, document.documentElement.scrollWidth]);
if (sw > cw) bad.push(`${u} ${sw}/${cw}`);
}
return `checked ${urls.length}\n` + (bad.join('\n') || 'none overflow');
}
돌아온 답은 checked 62 와 none overflow 두 줄이었다. 페이지가 수십 개여도 AI가 받는 건 이 요약뿐이다. 같은 방식으로 데스크톱 폭(1366·1440·1920px)도 돌렸다. 본문이 어느 폭에서나 768px로 고정돼 있다는 것도 숫자로 확인했다. 이게 데스크톱 레이아웃을 넓히는 작업으로 이어졌다. 레이아웃을 바꾼 뒤에는 "글 페이지에서 '관련 글'과 '같은 카테고리 글'이 둘 다 보이는가"를 폭별로 검사해서, 데스크톱에서 같은 목록이 두 번 나오는 중복도 잡았다.
사람 눈 대신 무엇을 맡길까
해 보니 경계가 비교적 분명했다.
- 맡기기 좋은 것 — 숫자로 판정할 수 있는 검사. 가로 넘침, 요소가 보이는지 숨겨졌는지, 링크·이미지 응답 코드, 화면 폭별 레이아웃 폭. 기준이 명확하면 사이트 전체를 돌리는 데 몇 분이면 된다.
- 같이 봐야 하는 것 — "보기 좋은가". 데스크톱 레이아웃은 스크린샷까지 찍어 사람이 확인했다. 넘침이 0이어도 휑해 보이는 건 숫자로 안 잡힌다.
- MCP 말고 다른 도구가 나은 것 — 제목·메타 설명 중복이나 canonical 태그 누락 같은 HTML 검사. 브라우저를 띄울 필요가 없어서, 이번엔 간단한 파이썬 크롤러로 67페이지를 훑었다. 홈과 소개 같은 고정 페이지 6곳에서 canonical 누락을 찾았다.
개인적으로 가장 쓸모 있었던 건 '배포 전후 비교'다. 같은 검사 코드를 고치기 전에 한 번, 고친 뒤 미리보기 서버에서 한 번, 운영 배포 후 한 번 돌리면 된다. 사람이 손으로 재현하던 확인 작업이 스크립트 하나로 줄어든다. MCP를 붙이는 건 한 줄이지만, 잘 쓰는 건 결국 "무엇을 숫자로 판정할지"를 먼저 정하는 쪽에 달려 있었다.
인용한 문장은 microsoft/playwright-mcp 저장소 README(Apache-2.0)에서 가져왔다. 측정은 2026년 10월 2일, 이 블로그 운영 사이트 기준이다.