Skip to content
게으른 엔지니어의 기술 블로그
Go back

agent-browser를 설치하면서 — 1편에서 이미 검토했던 도구라는 걸 까먹고 있었다

MCP 서버랑 스킬 리뷰 · 8/8편

지난 글에서 agent-browser를 설치했다. 며칠 뒤 이 시리즈를 처음부터 다시 읽다가 이상한 기시감이 들었다 — 1편에서 이미 똑같은 문제를 다룬 적이 있었다.

1편을 다시 읽다가 걸렸다

1편에서 Playwright MCP를 검토하면서 이렇게 적어뒀다. “지금 쓰는 WebFetch는 정적 페이지는 잘 처리하지만 실제 렌더링 확인(레이아웃, 라이브 URL이 정말 404 없이 뜨는지)은 못 한다.” 그리고 7편에서 agent-browser를 설치한 이유도 정확히 같은 문장으로 설명할 수 있다 — “VPS라 브라우저로 직접 확인 못 하니 curl 상태코드나 빌드 산출물 grep으로만 확인해온 게 계속 걸렸다.”

같은 문제를 두 번 짚었는데, 7편 어디에도 1편이나 Playwright MCP를 다시 검토했다는 흔적이 없었다. 다른 사람이 언급하는 걸 보고 괜찮아 보여서 agent-browser를 물어본 건데, 그때 1편에서 이미 비슷한 도구를 검토했었다는 사실 자체를 까먹고 있었던 거다.

실제로 몰랐던 건지, Honcho 대화 로그로 확인했다

기억에 의존하는 대신, Claude Code 세션마다 매 턴 저장되는 Honcho 대화 기록을 직접 뒤져봤다. agent-browser를 처음 물어본 시점을 찾으려고 최근 700개 메시지를 시간순으로 정렬해서 “agent-browser”가 등장하는 지점을 찾았다.

2026-09-02 11:11에 이런 질문으로 시작하고 있었다.

“Agent-browsers 라는 스킬에 대한 분석을 해줄래? 지금 너가 도는 VPS 처럼 GUI가 없는데도 도움이 될까?”

이 질문과 그에 이어지는 답변 어디에도 1편이나 Playwright MCP 얘기는 없었다. “진작 있었으면 좋았을 도구다”라는 결론까지 내렸는데, 그 “진작”이 정확히 1편에서 이미 검토했던 시점을 가리킨다는 연결은 그 자리에서 전혀 이뤄지지 않았다. 완전히 독립적으로 새로 시작된 질문이었다는 게 로그로 확인됐다.

그런데 “이미 있었다”는 것도 Hermes 한정이었다

여기서 확인할 게 하나 더 있었다 — 1편에서 말한 “이미 활성화돼 있었다”는 Playwright MCP가, 정말 이번에도 그냥 쓸 수 있었던 건지였다.

~/.claude/settings.json과 이 환경의 MCP 설정을 뒤져보니, Playwright MCP는 Claude Code 쪽에는 애초에 연결된 적이 없었다. 1편에서 확인한 “이미 기본 활성화”는 hermes tools list로 본 것 — Hermes 자체 툴셋 얘기였지, Claude Code하고는 무관했다. Claude Code에서 쓰려면 MCP 서버로 새로 연결하고 Playwright 자체 Chromium도 따로 받아야 하는 건 agent-browser 설치와 마찬가지였다.

즉 “예전에 공짜로 있던 걸 놔두고 또 설치했다”는 깔끔한 이야기는 아니었다. Claude Code 관점에서는 둘 다 어차피 새로 셋업해야 하는 도구였다. 다만 1편에서 이미 “이런 문제가 있고, 이런 도구로 풀 수 있다”는 조사 자체는 끝나 있었는데, 그 조사가 몇 주 뒤 같은 문제를 다시 마주쳤을 때 전혀 떠오르지 않았다는 것까지는 사실이다.

그럼 기능은 얼마나 겹치나

Playwright MCPagent-browser
통합 방식MCP 서버(Claude Code에 붙이려면 별도 설정 필요)Bash로 직접 호출하는 CLI 스킬
조작 방식접근성 트리 스냅샷 기반스크린샷 기반 + axe-core 접근성 감사
브라우저Playwright 번들 ChromiumChrome DevTools Protocol로 직접 통신, 기존 Chrome/Brave 재사용 가능
리소스 실측안 해봄(미설치 상태로 남아있어서)프로세스 18개, RSS 1.6GB로 직접 측정
토큰 사용(agent-browser 쪽 주장상 기준점)Vercel 자체 벤치마크로 “Playwright MCP 대비 82% 덜 씀”

리소스가 무거운 원인은 Chrome 엔진 자체의 멀티프로세스 구조라서, Playwright MCP를 실제로 붙였어도 비슷하게 무거웠을 가능성이 높다. 다만 이건 실측을 안 해봤으니 확신할 수 있는 얘기는 아니다.

남는 생각

“예전에 검토한 도구를 까먹고 비슷한 걸 또 설치했다”고 단정하고 넘어갔으면 틀린 이야기가 될 뻔했다 — 실제로는 “이미 있었다”는 전제 자체가 Hermes와 Claude Code라는 서로 다른 컨텍스트 사이에서는 성립하지 않았다. 기억으로 “아마 그랬을 거다”라고 짐작하는 대신 Honcho에 저장된 실제 대화 로그를 직접 뒤져서 확인했기 때문에, 이 미묘한 차이를 놓치지 않을 수 있었다.

그래도 남는 사실은 있다 — 1편에서 이미 “VPS에서 렌더링을 직접 확인 못 한다”는 문제 자체는 정확히 짚어놨는데, 몇 주 뒤 같은 문제를 다시 마주쳤을 때 그 기록이 전혀 떠오르지 않았다는 것. 조사해둔 걸 다시 찾아 쓰는 것도, 결국 그 조사가 있었다는 걸 기억하고 있어야 가능한 일이었다.


Share this post:

MCP 서버랑 스킬 리뷰

  1. 1. MCP 서버랑 스킬 7개를 리뷰한 하루 — 설치한 건 하나뿐이었다
  2. 2. ponytail을 리뷰하다가 — redundant하다는 판단은 틀렸다
  3. 3. Superpowers를 써보니 — 기능 하나 만드는데 대화·스펙·플랜·서브에이전트를 거쳤다
  4. 4. Codebase Memory MCP·Graphify를 리뷰하려다가 — 문제는 모델이 아니라 도구였다
  5. 5. Headroom과 OmniRoute를 리뷰하다가 — 검색 요약만으로는 둘 다 판단할 수 없었다
  6. 6. claude-mem을 리뷰하다가 — Honcho에서 이미 꺼둔 기능과 같은 걸 다시 켜는 셈이었다
  7. 7. agent-browser를 리뷰하다가 — 헤드리스라 가벼울 줄 알았는데 아니었다
  8. 8. agent-browser를 설치하면서 — 1편에서 이미 검토했던 도구라는 걸 까먹고 있었다