full-page-screenshot

full-page-screenshot skill 개요

full-page-screenshot이 하는 일

full-page-screenshot은 접힌 영역 아래의 콘텐츠까지 포함해 웹 페이지 전체를 하나의 PNG로 캡처하는 Browser Automation skill입니다. 독립 실행형 Node.js 스크립트가 Chrome DevTools Protocol을 통해 Chrome과 통신하는 구조라서, 긴 페이지, 지연 로딩 콘텐츠, 싱글 페이지 앱, 일반 뷰포트 스크린샷으로는 대부분의 내용을 놓치기 쉬운 페이지까지 처리할 수 있습니다.

가장 잘 맞는 사용자와 작업

QA, 시각 검수, 문서화, 디자인 감사, 버그 리포트, 경쟁사 리서치, 로그인된 제품 화면 안내 과정에서 AI agent가 전체 페이지 스크린샷을 안정적으로 만들어야 한다면 이 skill을 설치할 만합니다. 특히 대상 페이지가 이미 Chrome에 열려 있을 때 유용합니다. 열려 있는 탭을 목록으로 확인하고 선택한 탭을 캡처할 수 있어, 사용자에게 로그인 상태를 다시 만들라고 요청하지 않아도 됩니다.

핵심 차별점

full-page-screenshot skill의 가장 큰 가치는 운영 안정성입니다. Chrome DevTools Protocol을 직접 사용하고, Node.js 22+와 Chrome/Chromium 외에는 외부 패키지 의존성이 없으며, 이미 열려 있는 탭 캡처와 URL 기반 캡처를 모두 지원합니다. 특히 기존 탭 워크플로는 인증이 필요한 대시보드, 스테이징 환경, SSO 뒤에 있는 페이지에서 중요한 차별점입니다.

먼저 확인해야 할 도입 조건

설치하기 전에 환경에서 Node.js 22+를 실행할 수 있는지, Chrome remote debugging을 사용할 수 있는지 확인하세요. 이 skill은 호스팅형 스크린샷 API가 아니며 인증, CAPTCHA, 로컬 네트워크 제한, 쿠키 배너, 자동화를 의도적으로 차단하는 페이지를 우회하지 않습니다. 사용자가 Chrome에서 페이지를 정상적으로 열어 둔 뒤 agent가 그 탭을 캡처하는 방식에서 가장 잘 작동합니다.

full-page-screenshot skill 사용 방법

full-page-screenshot 설치와 준비 상태 확인

저장소 경로에서 skill을 설치합니다.

npx skills add alirezarezvani/claude-skills --skill full-page-screenshot

설치 후에는 먼저 SKILL.md를 확인한 다음 scripts/full-page-screenshot.mjs를 살펴보세요. 이 스크립트가 실제 실행 계층이므로, 제한이 많은 환경이나 CI와 유사한 환경에서 사용하기 전에는 읽어 두는 것이 좋습니다.

준비 상태 확인을 실행합니다.

node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --check

Chrome debugging을 사용할 수 없다면 chrome://inspect/#remote-debugging을 열어 해당 브라우저 인스턴스의 remote debugging을 활성화하거나, 로컬 정책에 맞게 debugging port를 지정해 Chrome/Chromium을 실행하세요.

로그인된 페이지에서는 기존 탭 사용

인증된 페이지, 관리자 패널, 현재 브라우저 세션에 의존하는 화면은 기존 탭 워크플로를 사용하세요. 먼저 열려 있는 탭을 목록으로 확인합니다.

node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --list

제목이나 URL로 탭을 찾은 뒤 캡처합니다.

node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" <targetId> /tmp/screenshot.png --width 1200 --dpr 1

이 방식은 세션 쿠키를 잃지 않으므로, 백그라운드에서 새 URL을 여는 것보다 대체로 더 안정적입니다. 검토하려는 디자인 브레이크포인트에 맞는 너비를 사용하세요. 예를 들어 모바일에 가까운 레이아웃은 390, 태블릿은 768, 데스크톱은 1200/1440이 적합합니다.

공개 페이지에서는 URL 사용

공개 페이지, 문서, 마케팅 페이지처럼 로그인이 필요 없는 페이지는 URL 모드를 사용합니다.

node "${SKILL_DIR}/scripts/full-page-screenshot.mjs" --url "https://example.com" /tmp/screenshot.png --width 1200 --dpr 1 --wait 15000

페이지가 지연 렌더링, 클라이언트 사이드 라우팅, analytics-triggered content, lazy-loaded sections에 의존한다면 --wait 값을 늘리세요. 파일 크기와 검토 속도를 고려하면 보통 --dpr 1이 실용적입니다. 픽셀 밀도가 출력 크기보다 더 중요할 때만 더 높은 DPR을 사용하세요.

더 정확한 실행을 위한 프롬프트 패턴

약한 프롬프트는 “이 페이지 스크린샷을 찍어줘.”입니다. 더 좋은 full-page-screenshot 사용 프롬프트에는 URL 또는 탭 맥락, 인증 상태, 뷰포트 너비, 대기 필요성, 출력 경로가 포함됩니다.

Use the full-page-screenshot skill to capture the already-open Chrome tab for staging.example.com/dashboard. I am logged in. Use desktop width 1440, DPR 1, wait long enough for lazy charts to render, and save the PNG to /tmp/dashboard-full-page.png. If multiple matching tabs exist, list them first and ask me which target ID to use.

이렇게 요청하면 agent가 추측하지 않고 --list, 기존 탭 캡처, --url 모드 중 무엇을 써야 할지 판단할 수 있습니다.

full-page-screenshot skill FAQ

full-page-screenshot은 일반 스크린샷 프롬프트보다 나은가요?

전체 페이지 캡처가 필요하다면 그렇습니다. 일반적인 프롬프트는 실행 환경이 제공하는 스크린샷 기능에 의존할 수 있고, 그 결과 현재 화면에 보이는 영역만 저장되는 경우가 많습니다. full-page-screenshot skill은 agent에게 CDP 기반의 구체적인 워크플로, 명령 구조, 이미 열려 있는 탭을 위한 대체 경로를 제공합니다.

초보자도 이 skill을 사용할 수 있나요?

가능합니다. 다만 skill을 설치할 수 있고 Chrome에서 remote debugging을 활성화해 실행할 수 있어야 합니다. 명령 자체는 단순하지만, 설정은 브라우저 확장 프로그램보다 기술적인 편입니다. 초보자는 먼저 --check를 실행하고, 그다음 --list로 탭을 확인한 뒤, URL 모드를 시도하기 전에 기존 탭 캡처부터 해보는 것이 좋습니다.

이 skill을 쓰지 않는 편이 좋은 경우는 언제인가요?

예약된 스크린샷 모니터링, 브라우저 간 렌더링 비교, 스크린샷 diff, OCR, PDF 내보내기, 대규모 클라우드 실행이 필요하다면 이 skill은 적합하지 않습니다. 이 skill은 Chrome/Chromium에서 PNG 스크린샷을 캡처합니다. Playwright 테스트 스위트, 시각적 회귀 테스트 플랫폼, 호스팅형 스크린샷 API를 대체하지 않습니다.

Browser Automation 워크플로에 사용할 수 있나요?

네. full-page-screenshot for Browser Automation은 agent가 이동, 로그인, 필터 적용, UI 상태 대기 후 결정적인 캡처 단계를 수행해야 할 때 잘 맞습니다. 자체적으로 완전한 탐색 또는 테스트 프레임워크라기보다는, 더 큰 브라우저 워크플로의 마지막 캡처 도구로 사용할 때 가장 유용합니다.

full-page-screenshot skill 개선 방법

full-page-screenshot 입력값 개선하기

입력값이 구체적일수록 더 좋은 스크린샷을 얻을 수 있습니다. 페이지 주소만 전달하지 말고, 로그인된 계정, 선택된 필터, 모달 상태, 뷰포트 너비, 로드되어야 하는 요소, 출력 파일명을 함께 지정하세요. 동적인 페이지라면 캡처 전에 반드시 보여야 하는 요소나 섹션을 명시해 agent가 더 긴 대기나 수동 확인이 필요한지 판단할 수 있게 하세요.

흔한 캡처 실패 줄이기

가장 흔한 장애 요인은 Chrome remote debugging이 활성화되어 있지 않은 경우, 로그인이 필요한 페이지에 URL 모드를 사용하는 경우, lazy content가 로드되기 전에 캡처하는 경우, 잘못된 뷰포트 너비를 사용하는 경우입니다. 이를 줄이려면 --check를 실행하고, 인증 페이지에는 기존 탭 모드를 우선 사용하며, 공개 SPA에는 --wait를 늘리고, 실제로 확인하려는 레이아웃에 맞게 --width를 지정하세요.

첫 PNG 이후 반복 조정하기

첫 결과물을 보고 하단 콘텐츠 누락, sticky headers가 섹션을 가리는 문제, 쿠키 배너, 로드되지 않은 이미지, 예상과 다른 반응형 레이아웃이 있는지 확인하세요. 그런 다음 다른 너비, 더 긴 대기 시간, 또는 미리 준비해 둔 탭으로 다시 실행합니다. 쿠키 배너나 모달이 나타난다면 Chrome에서 먼저 닫은 뒤, 새로운 백그라운드 URL에 의존하지 말고 기존 탭을 캡처하세요.

확장하기 전에 스크립트 읽기

skill을 커스터마이즈하려면 프롬프트를 수정하기 전에 scripts/full-page-screenshot.mjs를 읽어 보세요. 이 스크립트가 탭 검색, 뷰포트 너비, DPR, 대기 동작, CDP 캡처를 제어합니다. 유용한 개선 방향으로는 더 명확한 오류 메시지, 추가 대기 전략, 출력 파일명 규칙, 또는 워크플로에서 허용되는 경우 sticky overlays를 숨기기 위한 선택적 CSS 처리 등이 있습니다.