같은 Chromium 엔진, 다른 자동화 — Playwright / MCP / 브라우저 확장 해부

Claude 같은 에이전트에게 브라우저를 쥐여줄 수 있다는 이야기를 요즘 자주 듣습니다. 그런데 구체적으로 들어가 보면 Playwright, Playwright MCP, Claude-in-Chrome 확장, 그리고 헤드리스 Chromium 이라는 네 가지 선택지가 혼재되어 있고, 이름이 비슷해서 어느 상황에 무엇을 써야 할지 꽤 헷갈렸습니다.

자동화를 직접 만들어 보다가 "분명 같은 엔진을 쓰는데 왜 결과가 다르게 나올까" 하는 질문이 생겼고, 그 답을 찾는 과정에서 이 네 가지를 레이어 관점 으로 구분해서 보면 덜 혼란스럽다는 것을 알게 되었습니다. 이 글은 그 정리입니다.

네 가지가 결국 같은 엔진입니다

먼저 용어부터 정리해 보면, 이렇게 배치할 수 있습니다.

• Chromium — 브라우저 엔진 본체. Chrome 의 오픈소스 기반이며, 나머지 도구들은 결국 이 엔진 위에 올려져 있습니다.

• Playwright — Microsoft 가 만든 브라우저 자동화 라이브러리. Chromium / Firefox / WebKit 를 프로그램적으로 제어할 수 있게 해 줍니다.

• Playwright MCP — Claude Code 가 Playwright 를 MCP (Model Context Protocol) 로 래핑해 LLM 에이전트가 쓸 수 있게 노출한 도구입니다. 내부에서는 여전히 Playwright + Chromium 이 돌아갑니다.

• Claude-in-Chrome 확장 — 사용자가 평소 쓰는 Chrome 에 확장을 설치해 Claude 가 그 세션을 원격 제어하게 하는 방식입니다.

• 사용자 일상 Chrome — 기준점으로서의 "사람이 쓰는 브라우저" 입니다.

즉 네 가지 도구가 같은 엔진을 다른 목적으로 꺼내 쓴 것 이라는 점이 먼저 확인되어야 합니다. 여기서부터 비로소 차이를 이야기할 수 있습니다.

실행 주체와 사용자 개입에 따른 비교

네 가지가 언제 어디서 실행되는지, 사용자가 얼마나 개입해야 하는지에 따라 이렇게 나뉩니다.

이 표만 놓고 보면 "그러면 Playwright MCP 로 다 해결되는 것 아닌가" 싶지만, 실제로 만져 보면 더 미묘한 차이가 드러납니다.

차이를 만드는 건 "쿠키의 수명 주기"

헤드리스 Playwright 스크립트를 짜 보다가, 로그인이 필요한 사이트에서 막힌 적이 있습니다. 사용자가 평소 쓰는 Chrome 에서 로그인한 뒤 쿠키를 추출해 스크립트에 주입했는데, 어떤 요청은 통과하고 어떤 요청은 차단되는 현상이 일어났습니다.

원인을 따라가다 보니, 결국 "쿠키가 어디서 발급되고 어디서 사용되는가" 의 차이라는 것을 알게 되었습니다. 두 가지 수명 주기가 있습니다.

1. 외부 주입형 — 사용자 일상 Chrome 에서 로그인해서 쿠키를 추출하고, 다른 Chromium 인스턴스에 주입.

2. 내부 발급형 — 같은 Chromium 인스턴스 안에서 로그인하고, 그 상태 그대로 자동화를 이어감.

문제는 전자의 경우 쿠키를 잘 주입했어도 그 쿠키를 발급한 브라우저와 지금 쓰는 브라우저가 서로 다르다 는 점입니다. 많은 서비스가 보안을 위해 쿠키를 특정 세션 지문 (fingerprint) 에 묶어 발급하기 때문에, 외부에서 건너온 쿠키는 재검증 단계에서 "이 쿠키의 원래 주인이 아닌 것 같다" 는 판단이 내려지고, 그때부터 추가 확인을 요구하거나 차단이 시작됩니다.

같은 엔진을 써도 쿠키가 자라난 흙 이 다르면 재검증 단계에서 갈라진다는 것이, 네 가지 도구를 가르는 가장 큰 변수였습니다.

브라우저 fingerprint 라는 변수

브라우저 지문은 한 가지 값이 아니라 여러 시그널의 조합입니다. 대표적으로 이런 것들이 있습니다.

• JavaScript 런타임 속성 (navigator.webdriver, navigator.plugins 등)

• Canvas / WebGL 렌더링 결과 (GPU 드라이버, 폰트 차이로 픽셀 단위 다름)

• 설치된 폰트 목록, 화면 해상도, 시간대, 언어 설정

• TLS 핸드셰이크 패턴 (ClientHello 구성, 확장 순서)

봇 탐지용 기법이라기보다, "이 요청이 방금 전 요청과 동일한 세션인지" 를 판별하는 기준점으로 이해하면 맥락이 잡힙니다. 네 가지 도구를 이 관점에서 다시 보면 이렇게 정리됩니다.

같은 Chromium 엔진이라고 해서 지문까지 같은 것은 아닙니다. 기본 User-Agent 부터 다르고, 자동화 플래그 노출 여부, 확장 설치 여부, 실행 환경이 조합되어 각기 다른 지문을 만듭니다.

그래서 언제 무엇을 쓸 것인가

이 차이가 정리되고 나면 선택이 훨씬 간단해집니다. 세 가지 대표적인 상황을 예로 들어 보겠습니다.

Case A — 로그인이 필요 없는 사이트의 E2E 테스트 / 배치 스크래핑

헤드리스 Playwright (Node) 가 가장 자연스럽습니다. CI 에서 주기적으로 돌리기 적합하고, 재현성이 필요한 자동화에 잘 어울립니다. 로그인 세션이 없으니 쿠키 수명 주기 문제 자체가 생기지 않습니다.

헤드리스 Playwright (Node)
├─ 완전 무인 실행 가능
├─ CI/CD 파이프라인에 통합 쉬움
└─ 공개 페이지 스크래핑 / E2E 테스트 / 스크린샷 비교

Case B — 로그인이 필요한 작업을 에이전트에게 한 번에 시키기

Playwright MCP 가 유용합니다. 사용자가 세션 중에 MCP 가 띄운 브라우저에 로그인만 해 주면, 그 이후로는 같은 Chromium 안에서 에이전트가 이어받아 작업을 처리합니다. 세션이 살아있는 동안만 작동 하므로 무인 배치로는 쓸 수 없지만, "지금 한 번 처리해 달라" 식의 대화형 워크플로우에는 최적입니다.

Playwright MCP
├─ 사용자가 대화 시작 시 로그인 1회
├─ 같은 Chromium 인스턴스 안에서 에이전트가 후속 작업
└─ 세션 종료와 함께 환경도 정리됨

Case C — 사용자 일상 세션을 그대로 이어받기

Claude-in-Chrome 확장이 적합합니다. 사용자가 평소 쓰는 Chrome 에 설치하므로 지문이 사람과 완전히 동일하고, 로그인 상태를 그대로 이용할 수 있습니다. 다만 사용자가 Chrome 을 켜 놓고 있어야 하고, 에이전트의 조작 속도가 사용자의 상호작용과 섞일 수 있다는 점은 감안해야 합니다.

정리 — 레이어를 구분해서 보기

돌이켜 생각해 보면, 처음에 혼란스러웠던 이유는 네 가지 도구를 같은 레이어 에 놓고 비교하려 했기 때문입니다. 사실 이 네 가지는 서로 다른 레이어에 있습니다.

• 엔진 — Chromium

• 엔진을 감싼 자동화 라이브러리 — Playwright

• 그 라이브러리를 LLM 도구로 노출한 프로토콜 — MCP

• 엔진을 사용자 기기에 묶은 실사용 브라우저 — Chrome + 확장

선택은 "엔진을 고르는 것" 이 아니라 "어느 레이어에서 작업을 풀 것인가" 에서 출발해야 덜 헷갈립니다. 무인 반복 작업은 라이브러리 레이어에서, 대화형 협업은 MCP 레이어에서, 사용자 본인의 세션 연장은 확장 레이어에서 풀리는 식입니다.

LLM 에이전트 시대에 브라우저를 쥐여주는 선택지는 앞으로도 늘어날 것 같습니다. 다만 엔진이 같다고 해서 서로 동등한 대체재는 아니라는 것, 그리고 차이를 만드는 핵심 변수는 "쿠키와 지문이 어디서 발급되어 어디에서 쓰이는가" 라는 것을 염두에 두면 선택이 한결 수월해진다는 생각이 들었습니다.