지난 글에서 claude-mem을 보다가 자동 메모리 주입은 보류하기로 했다. 이번엔 성격이 다르다 — 지금 이 VPS엔 애초에 모니터도 디스플레이 서버도 없어서, “브라우저로 직접 확인 못 하니 curl 상태코드나 빌드 산출물 grep으로만 확인”해온 게 계속 걸렸다. 그 구멍을 메워줄까 싶어 agent-browser(Vercel Labs)를 리뷰했다.
헤드리스가 정확히 뭘 뜻하는지부터
“헤드”가 화면(디스플레이) 부분을 가리킨다 — 헤드리스는 말 그대로 “화면 없이 돈다”는 뜻이다. 헤드리스 브라우저도 진짜 Chrome 엔진이 그대로 돈다 — HTML 파싱, CSS 계산, JS 실행, DOM 구성까지 내부적으로 다 똑같이 한다. 차이는 그걸 실제 화면에 그려서 보여주는 부분만 뺀다는 것뿐이다. 그래서 사람이 보는 창은 없고, 코드로만 조작한다 — 페이지를 열고, 버튼을 클릭하고, 지금 화면을 스크린샷으로 저장한다(화면에 안 띄울 뿐 이미지는 찍을 수 있다).
VPS에서 이게 중요한 이유는 단순하다. 일반 Chrome을 그냥 실행하면 “그릴 화면이 없다”고 바로 에러난다. 헤드리스 모드는 그 화면이 필요하다는 전제 자체를 빼는 특수 모드라, 디스플레이 서버가 하나도 없는 서버에서도 문제없이 돌아간다.
agent-browser GitHub 지표부터 검증 — 41,724스타
agent-browser는 Vercel Labs가 만든 Rust CLI다.
GitHub API로 직접 확인하니, 현 시점 기준으로 41,724스타·2,778포크,
어제도 커밋될 만큼 활발했고 등록된
보안 어드바이저는 없었다. Chrome DevTools Protocol로 직접 통신해서
Playwright나 Puppeteer 의존성이 없고, agent-browser install로
자체 Chrome을 받거나 이미 있는 Chrome/Brave를 재사용한다.
Vercel 자체 벤치마크로는 “Playwright MCP 대비 컨텍스트 82% 덜 씀”이라는 수치가 있었고, Pulumi 블로그엔 에이전트가 컴포넌트를 만들고 브라우저를 직접 띄워서 자기가 만든 걸 스스로 테스트하는 “Self-Verifying AI Agents” 케이스 스터디도 있었다 — 지금 하고 싶은 것과 정확히 같은 용도였다.
이슈 트래커도 훑어봤다. 크로미움 버전이 설치 시점과 실행 시점에 어긋나는 버그가 반복해서 보고돼 있었고(#107, #244), 기존 Chrome 프로필 재사용이나 iframe 접근 같은 편의 기능은 아직 요청 단계였다. Windows 쪽 설치 버그도 몇 개 있었는데 이건 Linux VPS와는 무관했다.
확인 안 되는 것 하나 — “High Risk” 판정
Mondoo라는 AI 에이전트 스킬 보안 스캐너 사이트가 이 도구를 “High Risk”로 분류해뒀다는 검색 결과가 나왔다. 근거를 보려고 WebFetch로 당겨봤는데 내용을 못 읽었다 — 그 사이트가 Next.js라, 실제 점수는 JS가 다 돌고 난 뒤에야 렌더링되는 구조였다. curl로 상태코드만 찍어보면 200이 나오는데, 이것도 서버가 앱 껍데기만 200으로 주고 그 안에서 클라이언트 쪽 라우터가 “이 페이지 없음”으로 처리하는 소프트 404일 수 있어서 확실치 않았다. (뒤에서 이 도구를 직접 설치하고 나서 다시 확인한 이야기가 나온다.)
실측해보니 — 프로세스 18개, RSS 1.6GB
콜드스타트 자체는 빨랐다 — 완전히 꺼진 상태에서 example.com을 여는
데 0.748초였다. 문제는 그다음이었다. 단순한 페이지 하나 열고 스냅샷
한 번 찍었을 뿐인데, Chrome 관련 프로세스가 18개나 떠 있었다
— zygote, GPU 프로세스, 네트워크/스토리지 유틸리티, 렌더러 여러
개까지. 합산 RSS를 재보니 약 1.6GB였다. “헤드리스니까 가볍겠지”
라고 막연히 짐작했던 것과 완전히 달랐다 — Chrome의 멀티프로세스
구조 자체가 페이지 복잡도와 무관하게 이 정도 오버헤드를 깐다.
VPS 전체 가용 메모리가 4GB 정도인 걸 감안하면, 이건 그 40%를 페이지
하나가 그냥 가져가는 셈이었다. 다행히 agent-browser close로
명시적으로 닫아보니 18개 프로세스가 전부 깨끗하게 사라지고 메모리도
원래대로 돌아왔다 — 좀비로 안 남는다는 것까지는 확인됐다.
그래서 정한 운영 방식 — AGENT_BROWSER_IDLE_TIMEOUT_MS
두 가지를 같이 하기로 했다. 첫째, 확인 작업은 몰아서 하고 끝나면
agent-browser close로 바로 닫는다 — 열어둔 채로 다른 작업을
계속하지 않는다. 둘째, 그래도 닫는 걸 깜빡하거나 명령이 중간에
끊기는 경우를 대비해서 AGENT_BROWSER_IDLE_TIMEOUT_MS=600000(10분)을
안전장치로 걸어뒀다.
이걸 ~/.bashrc에 넣었는데, 여기서 또 하나 걸렸다. Claude Code의
Bash 툴이 쓰는 셸은 매번 새로 뜨는 non-login 셸이라 .bashrc를
안 읽고, 세션 시작 시 만들어진 스냅샷 파일만 source하고 있었다.
그래서 방금 고친 설정이 지금 이 세션에는 반영이 안 됐다 — 다음
세션부터는 자동으로 적용되지만, 이번 세션 동안은 명령마다
AGENT_BROWSER_IDLE_TIMEOUT_MS=600000을 직접 앞에 붙여야 했다.
마지막으로, Mondoo의 소프트 404를 직접 열어봤다
설치가 끝난 김에, 처음에 확인 못 했던 Mondoo 페이지를 agent-browser로 직접 열어서 스냅샷을 찍어봤다. 화면엔 정확히 “404 — The skill or page you are looking for does not exist”가 렌더링돼 있었다. curl로는 못 잡았던 소프트 404를, 실제로 페이지를 렌더링하는 도구로는 바로 확인할 수 있었다 — 이 도구가 채워주기로 한 바로 그 구멍을, 설치하자마자 실제로 겪은 셈이다. 그 “High Risk” 판정은 결국 근거를 확인할 방법이 없는 채로 남았다 — 스캔 레코드가 없어졌거나 애초에 잘못된 링크였던 것으로 보인다.
배운 점
“헤드리스”라는 단어가 주는 인상(가볍다, 화면만 안 그린다)과 실제 리소스 소비는 다른 얘기였다 — 브라우저 엔진 자체의 멀티프로세스 구조는 화면을 안 그려도 그대로 남아 있다. 설치 전 문서만 보고 “가벼울 것”이라고 짐작했다면 그대로 VPS에 여러 개를 동시에 띄우는 실수를 했을 수도 있다. 실측 한 번으로 콜드스타트 시간, 프로세스 개수, RSS, close 이후 정리 여부까지 확인하고 나서야 운영 규칙(몰아서 쓰고 명시적으로 닫기 + idle timeout 안전장치)을 정할 수 있었다.