해커톤 제출 전, 공개 URL을 headed Playwright로 먼저 통과시키는 이유 | DAKER 커뮤니티

오늘 글은 MCP 소식도, 새 모델 발표도 아닙니다. 해커톤이나 데모 제출 직전에 더 자주 놓치는 한 가지를 다룹니다. 제출은 로컬 화면이 아니라 공개 URL로 이뤄지고, 심사위원이 여는 것도 채팅 캡처가 아니라 그 링크입니다.

그래서 오늘 범위는 분명합니다. 제출할 공개 주소를 headed 브라우저로 한 번 직접 통과시키는 일입니다. 코딩 에이전트가 먼저 링크를 열고, 실패를 기록하고, 고치고, 다시 통과할 때까지 확인하는 최소 QA 루프입니다.

배포가 제출입니다. 올린 링크가 제출입니다.

참고 영상은 Claude Code + Playwright Automates Literally Anything.입니다. 오늘 글에서 가져오는 것은 영상 전체가 아니라 첫 사용처입니다. 에이전트가 폼을 만들고, headed Playwright를 돌리고, 버그를 찾고, 고치고, 다시 돌려 통과할 때까지 가는 루프입니다. 명령의 기준은 영상이 아니라 공식 README입니다. 원문은 playwright-cli README이고, 저장소는 microsoft/playwright-cli입니다. MCP 쪽 설명은 microsoft/playwright-mcp에서 볼 수 있습니다. CLI와 MCP를 같은 화면에서 비교한 보조 영상은 이 주소입니다.

보조 영상에 나온 토큰 비율 숫자는 이 글에 적지 않습니다. 공식 문서는 그 비율을 발표하지 않습니다. 이 글은 방송 대본이 아니라, 오늘 해커톤 제출 링크를 올리기 전에 돌릴 최소 QA를 정리한 글입니다.

영상이 실제로 보여 준 것은 QA 루프입니다

영상의 첫 사용처는 QA 루프입니다. 에이전트에게 폼을 만들라고 시킨 뒤, 사람이 손으로 눌러 보는 대신 headed Playwright로 그 흐름을 직접 타게 합니다. 화면이 보이는 상태에서 어디서 막히는지 확인하고, 코드를 고치고, 같은 흐름을 다시 실행해 통과할 때까지 닫힌 루프를 만듭니다.

영상이 잡아 낸 실패는 세 갈래였습니다. textarea에서 Enter를 눌러도 다음 단계로 가지 않았고, 리뷰 페이지가 열리지 않았고, 이전에 남은 오버레이가 버튼을 가렸습니다. 중요한 점은 이 실패들이 채팅 감상으로만 남지 않았다는 데 있습니다. 스크린샷과 코드 수정, 재실행으로 기록됐고, 고친 뒤에는 같은 공개 흐름을 다시 통과시켰습니다.

오늘 DAKER 숙제가 가져올 것은 그 루프뿐입니다.

영상 뒤에 이어지는 다른 장면들은 오늘 범위가 아닙니다. 치과 검색 결과를 긁는 데모도, Skool에서 자동으로 좋아요를 누르는 데모도, 이미 로그인한 Chrome 프로필을 붙잡는 데모도 오늘 숙제가 아닙니다. 우리에게 필요한 것은 우리 공개 URL의 QA입니다. 남의 사이트를 긁는 일도, 남의 세션을 가져오는 일도 여기서 다루지 않습니다.

해커톤에서 자주 생기는 착각도 이 지점과 연결됩니다. 로컬에서 한 번 됐다고 제출이 끝난 것으로 여기기 쉽고, 채팅에 붙인 캡처를 증거처럼 생각하기 쉽습니다. 하지만 심사위원이 여는 것은 로컬 호스트도, 막힌 미리보기 링크도, 로그인 뒤에만 보이는 화면도 아닙니다. 다른 사람 브라우저에서 열리는 공개 URL이 실제 제출물입니다.

공식 문서가 안내하는 첫 시작

요구 사항은 Node.js 18 이상입니다. 코딩 에이전트는 Claude Code, GitHub Copilot, 그 밖의 에이전트가 될 수 있습니다. 설치 명령은 README에 아래처럼 적혀 있습니다.

npm install -g @playwright/cli@latest
playwright-cli --help
playwright-cli install --skills

글로벌 명령이 없으면 로컬 대체는 npx playwright cli입니다. README는 로컬 버전이 있으면 모든 명령에서 그 로컬 호출을 쓰라고 적습니다. 없으면 공식 글로벌 설치 줄을 다시 실행하면 됩니다. 오늘 재현의 기본은 README의 설치 세 줄입니다.

스킬을 설치하면 Claude Code와 GitHub Copilot 같은 에이전트가 로컬 스킬을 사용할 수 있습니다. 스킬 없이 돌리는 방법도 README에 있습니다. 에이전트에게 도움말을 읽히고 그 명령으로 테스트하라고 시키는 방식입니다. 공식 예시는 TodoMVC 주소에서 add todo 흐름을 시험하는 문장입니다.

공식 데모 주소는 demo.playwright.dev의 todomvc이고, 데모 명령은 아래와 같습니다.

playwright-cli open https://demo.playwright.dev/todomvc/ --headed

기본은 헤드리스입니다. 브라우저를 보려면 open에 headed 플래그를 붙입니다. 오늘 글이 기본값 대신 headed를 강조하는 이유도 여기에 있습니다. 제출 링크를 사람이 보는 장면과 같게 열어야 실패를 재현하고 기록하기 쉽기 때문입니다.

오늘 숙제는 기본값으로 돌리지 않습니다. 제출 링크를 사람이 보는 장면과 같게 열려면 headed가 필요합니다.

세션과 기록은 어떻게 남는가

세션 플래그는 이름 붙은 세션입니다. 환경 변수는 PLAYWRIGHT_CLI_SESSION입니다. 기본 프로필은 메모리이고, 같은 세션 안에서는 쿠키와 저장 상태가 유지됩니다. 브라우저가 닫히면 사라집니다. 디스크에 남기려면 persistent 플래그를 씁니다. README는 프로젝트마다 다른 브라우저 인스턴스를 쓰라고 적고, 에이전트를 특정 세션에 묶으려면 환경 변수를 붙이거나 호출마다 세션 플래그를 붙이라고 설명합니다. 세션 목록은 list, 모두 닫기는 close-all, 강제 종료는 kill-all입니다.

여기서 중요한 선도 분명합니다. 오늘 숙제에서 이미 있는 브라우저 프로필을 가져와 로그인 상태를 재사용하는 일은 하지 않습니다. persistent는 우리 세션을 디스크에 남기는 옵션이지, 다른 사람 프로필을 가져오는 옵션이 아닙니다.

명령을 실행한 뒤에는 스냅샷이 따라옵니다. 페이지 주소와 제목, 요소 참조가 나오고, 필요할 때 playwright-cli snapshot을 다시 찍을 수 있습니다. 특정 요소만 보려면 참조를 붙이고, 깊이를 줄이는 플래그도 사용할 수 있습니다. 큰 스냅샷을 다 읽히지 않으려면 find로 문자열을 찾습니다. 화면 기록은 playwright-cli screenshot입니다. 성공 장면과 실패 장면을 같은 방식으로 남길 수 있습니다.

요소를 누를 때는 스냅샷의 참조를 쓰고, CSS 선택자와 로케이터도 사용할 수 있습니다. 입력은 type과 fill, 키는 press, 이동은 goto, 뒤로 가기는 go-back, 새로고침은 reload입니다. 콘솔과 네트워크 기록 명령도 README Core와 DevTools에 있습니다. 오늘 첫 통과에서는 이 목록을 다 외울 필요는 없습니다. 에이전트에게 도움말을 읽히고, 제출 URL에서 snapshot과 screenshot, 클릭과 입력을 시키면 됩니다.

모니터링은 playwright-cli show입니다. 에이전트가 뒤에서 브라우저를 돌릴 때 세션을 보고 중간에 손을 넣을 수 있습니다. 다만 오늘 숙제의 필수 줄은 아닙니다. headed로 제출 링크를 연 뒤 스냅샷과 스크린샷이 남으면 최소 기록은 갖춘 셈입니다.

CLI와 MCP를 승패로 읽지 않는 이유

이 글은 Playwright MCP 출시 뉴스가 아닙니다. CLI가 MCP를 죽였다는 식의 이야기로도 읽지 않습니다. README는 둘의 쓰임이 다르다고 적습니다. 코딩 에이전트에 CLI를 쓰는 이유로는 토큰 효율과, 페이지 데이터를 모델 맥락에 강제로 넣지 않는다는 점을 듭니다. 큰 도구 스키마와 긴 접근성 트리를 매번 싣지 않고, 짧고 목적 있는 명령으로 움직이는 쪽이 처리량이 큰 코딩 에이전트에 맞는다는 설명입니다.

그렇다고 MCP가 사라진 것은 아닙니다. 상태가 오래 남아야 하는 루프, 페이지 구조를 반복해 살피는 탐색, 스스로 고치는 테스트, 오래 달리는 자율 작업에는 MCP가 남아 있습니다. 오늘 숙제는 그런 긴 루프가 아니라 제출 URL 하나를 headed로 통과시키는 짧은 루프이므로, CLI와 SKILLS를 먼저 두는 것입니다.

토큰을 얼마나 아끼는지 비율로 단정하지도 않습니다. 보조 영상에 나온 숫자를 사실처럼 옮기지 않습니다. 공식 README가 적는 이유는 토큰 효율과 페이지 데이터를 모델에 강제로 넣지 않는다는 점입니다. 그 문장 이상의 절감률을 이 글에서 만들지 않습니다.

오늘 범위가 아닌 것들

오늘 글은 새 모델 발표가 아닙니다. 에이전트가 브라우저를 만질 수 있게 된 첫날을 다루는 글도 아닙니다. 바뀌는 것은 도구 자체보다 숙제의 대상입니다. 남의 데모 사이트가 아니라 우리가 올리는 공개 주소입니다. 영상 제목의 literally anything을 오늘 범위로 읽지 않습니다. 오늘 범위는 제출 링크 하나입니다.

치과 정보를 긁는 숙제도 아니고, 커뮤니티에 자동 좋아요를 보내는 숙제도 아닙니다. 로컬 브라우저 프로필을 에이전트에 넘겨 로그인 상태를 재사용하는 숙제도 아닙니다. 제출 페이지가 로그인을 요구한다면, 그 페이지는 아직 제출 주소가 아닙니다. 로그인 벽을 우회하는 대신 공개로 열리는 주소를 만드는 것이 먼저입니다.

로컬에서 통과한 캡처가 제출인 것도 아닙니다. 에이전트가 코드를 많이 고쳤다는 로그가 제출인 것도 아닙니다.

유튜브 화면을 이 글에 넣지도 않습니다. 주소만 둡니다. 이 영상이 오늘 필요한 이유는 QA 루프 하나입니다. 폼을 만들고, headed로 실패를 보고, 고치고, 다시 통과하는 그 순서만 가져옵니다.

오늘 할 일: 제출 URL을 headed로 한 번 통과시키기

해커톤 제출은 올린 링크입니다. 오늘 범위는 그 링크를 headed Playwright로 한 번 타 보는 일입니다. 모델 전체를 바꾸거나 스크레이핑 파이프라인을 붙이는 이야기가 아닙니다. 제출 주소의 첫 흐름을 통과와 실패로 나눠 확인하는 일입니다.

먼저 Node.js 18 이상인지 확인하고, README의 설치 세 줄로 시작하면 됩니다. 명령이 없으면 로컬 npx playwright cli 호출을 시도하고, 그래도 없으면 공식 설치 줄을 다시 실행합니다.

그다음 playwright-cli install --skills를 실행합니다. 쓰는 에이전트가 로컬 스킬을 읽는지 확인하고, 스킬을 안 쓰는 에이전트라면 프롬프트에 playwright-cli --help를 읽고 그 명령으로 제출 URL을 시험하라고 적으면 됩니다.

제출할 공개 URL이 있으면 그 주소를 headed로 엽니다. 명령은 playwright-cli open YOUR_URL --headed입니다. 아직 배포가 없으면 공식 데모 https://demo.playwright.dev/todomvc/를 headed로 열어 도구가 동작하는지 확인할 수 있습니다. 다만 데모 통과는 연습일 뿐이고, 데모 주소를 제출 주소로 올리면 안 됩니다.

페이지가 열리면 playwright-cli snapshot을 찍고 제목과 주소, 주요 버튼이 보이는지 확인합니다. 이어서 시작, 입력, 다음, 제출, 리뷰처럼 팀이 심사위원에게 보여 줄 최소 경로를 탑니다. 이 경로는 팀 제품에 맞게 정하면 됩니다. 없는 경로를 억지로 복사할 필요는 없습니다.

성공 장면과 실패 장면은 playwright-cli screenshot으로 남깁니다. 파일 이름이 필요하면 filename 플래그를 붙입니다. Enter가 먹지 않는 입력, 열리지 않는 리뷰, 남은 오버레이처럼 영상이 보여 준 실패 유형을 우리 화면에서 찾되, 우리 화면에 없는 실패를 지어내지는 않습니다. 있는 실패만 고치면 됩니다.

실패가 있으면 코드를 고치고, 고친 뒤 같은 공개 URL을 headed로 다시 엽니다. 로컬만 고치고 배포를 바꾸지 않으면 제출 링크는 그대로 실패입니다. 고친 결과가 올린 링크에 반영된 뒤 다시 통과시켜야 합니다.

배포가 제출입니다. 고친 결과가 올린 링크에 반영된 뒤에 다시 통과해야 합니다.

통과한 뒤에는 공개 링크를 내리지 않는 것도 중요합니다. 심사 전에 미리보기를 잠그거나, 환경 변수를 끄거나, 로그인 벽을 다시 올리면 제출 링크는 더 이상 제출물이 아니게 됩니다. 올린 링크가 살아 있어야 제출이 유지됩니다.

세션 이름은 팀 제출용으로 고정해 두는 것이 좋습니다. 예시는 -s=submit 또는 PLAYWRIGHT_CLI_SESSION=submit입니다. 기본 메모리 프로필이면 브라우저를 닫을 때 상태가 사라지므로, 흐름을 다시 타야 하면 같은 명령을 다시 실행하면 됩니다. 다른 사람 브라우저 프로필 경로를 넣는 방식은 여기서 다루지 않습니다.

팀으로 내는 대회라면 이 명령을 저장소 README에 함께 두는 것도 좋습니다. 에이전트에게 시킬 문장, headed 명령, 스냅샷 위치, 성공과 실패 스크린샷 이름을 한 파일에 적어 두면 다음 사람이 재현하기 쉽습니다. 채팅에만 남은 순서는 다음 날 바로 사라집니다.

마무리

한 줄로 줄이면 이 글은 MCP 뉴스를 다시 쓰는 글이 아닙니다. 새 모델을 기다리는 글도 아닙니다. 제출할 주소를 headed Playwright로 열고, 스냅샷과 스크린샷으로 통과와 실패를 남기고, 실패를 고친 뒤 같은 주소를 다시 통과시키는 최소 QA 루프를 정리한 글입니다.

그 링크를 브라우저가 먼저 엽니다.

참고 자료

Claude Code + Playwright Automates Literally Anything.
CLI와 MCP 비교 영상
playwright-cli README
microsoft/playwright-cli
microsoft/playwright-mcp

여러분은 제출 직전에 공개 URL을 어떤 방식으로 검증하고 있는지 궁금합니다.