AI 브라우저 제어에서 주로 쓰이는 protocol은 두 가지입니다. CDP(Chrome DevTools Protocol)와 MCP(Model Context Protocol)입니다. 서로 다른 레이어에서 서로 다른 문제를 해결하지만, browser agent를 구축하는 개발자들은 둘을 혼동하거나 용도에 맞지 않는 쪽을 선택하곤 합니다. 이 가이드는 각 protocol의 역할, 사용 시점, 그리고 프로덕션 agent 스택에서 함께 쓰는 방법을 설명합니다.
요약: CDP는 WebSocket 연결을 통해 browser를 직접, 저수준으로 제어합니다. MCP는 표준화된 tool-use 인터페이스를 통해 LLM에 고수준 browser tools를 제공합니다. CDP는 엔진이고, MCP는 핸들입니다. 대부분의 프로덕션 AI 에이전트에는 둘 다 필요합니다. MCP로 LLM이 action을 결정하고, CDP가 아래에서 browser를 실제로 동작시킵니다. Clawbrowser는 두 protocol을 모두 네이티브로 지원합니다.
참고: 이 글에서 "CDP"는 Chrome DevTools Protocol(브라우저 제어 표준)을 뜻합니다.
CDP와 MCP의 정체
CDP: Chrome DevTools Protocol
CDP는 WebSocket 기반 protocol로 Chromium browser를 프로그래밍 방식으로 제어합니다. Google이 Chrome DevTools(F12로 여는 inspector) 용도로 만들었지만 browser 자동화 표준이 되었습니다. Playwright, Puppeteer, 모든 주요 자동화 라이브러리가 내부에서 CDP를 사용합니다.
Playwright에서 page.goto()를 호출하면 WebSocket을 통해 CDP 명령이 browser로 전송됩니다. CDP는 세밀한 제어를 제공합니다. 페이지 이동, JavaScript 실행, network request intercept, cookie 조작, screenshot 캡처가 가능합니다.
# CDP: your code controls the browser directly
from playwright.async_api import async_playwright
async with async_playwright() as p:
browser = await p.chromium.connect_over_cdp("http://127.0.0.1:9222")CDP에 대한 자세한 내용은 CDP Browser for AI Agents 개발자 가이드를 참고하세요.
MCP: Model Context Protocol
MCP는 LLM이 외부 도구에 연결하는 방식을 표준화하는 protocol입니다. 각 도구마다 커스텀 function-call 정의를 작성하는 대신, LLM이 MCP 서버를 통해 사용 가능한 도구를 발견하고 표준 인터페이스로 호출합니다.
browser 제어의 경우 MCP 서버가 navigate, click, type, screenshot, extract 같은 action을 LLM이 호출할 수 있는 도구로 공개합니다. LLM이 task에 따라 어떤 도구를 호출할지 결정합니다. Playwright 코드도, CSS 셀렉터도, agent에 커스텀 도구 정의도 필요 없습니다.
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]이 설정을 Claude Code, Cursor, Gemini CLI 또는 MCP 호환 agent에 추가하면 LLM이 즉시 browser tools를 사용할 수 있습니다.
왜 혼동되는가
두 protocol 모두 AI 에이전트를 browser에 연결합니다. 둘 다 "protocol"이라는 단어를 포함합니다. AI 에이전트 인프라 관련 대화에 동시에 등장합니다. 하지만 동작하는 레이어가 다릅니다.
- CDP는 browser 레벨 protocol입니다. Chromium과 통신합니다.
- MCP는 application 레벨 protocol입니다. LLM과 통신합니다.
MCP browser 서버는 내부에서 CDP를 사용해 browser를 제어합니다. 둘은 대안이 아닙니다. 같은 스택의 서로 다른 레이어입니다.
나란히 비교
| CDP (Chrome DevTools Protocol) | MCP (Model Context Protocol) | |
|---|---|---|
| 만든 곳 | Google (Chrome 팀) | Anthropic |
| Protocol 유형 | 브라우저 제어 (WebSocket) | 도구 사용 (stdio/SSE) |
| 호출 주체 | 코드 (Playwright, Puppeteer, raw WebSocket) | LLM (Claude, GPT, Gemini) |
| 제어 수준 | 저수준: DOM, network, JavaScript 실행, cookies | 고수준: navigate, click, type, screenshot, extract |
| 설정 | browser의 debugging port에 연결 | agent에 MCP 서버 구성 |
| 유연성 | 완전: browser가 할 수 있는 모든 것 | 서버가 공개하는 도구로 제한 |
| 액션 속도 | 밀리초 (inference 없음) | 0.5~3초 (LLM이 매 단계 판단) |
| 에러 처리 | 코드에서 에러 처리 | LLM이 에러를 추론 |
| Anti-detection | 미제공 (browser에 의존) | 미제공 (browser에 의존) |
| 적합한 용도 | 스크립트 자동화, 세밀한 제어, framework 개발 | LLM 기반 브라우징, 열린 작업, 빠른 프로토타이핑 |
어떤 protocol도 anti-detection을 제공하지 않습니다. 이것은 protocol 문제가 아니라 browser 레벨 문제입니다. 기본 Chrome instance는 CDP 경유든 MCP 서버 경유든 같은 자동화 신호를 노출합니다. anti-detection에는 Clawbrowser 같은 engine 레벨 솔루션이 필요합니다. 20가지 이상의 surface에 걸친 managed fingerprints, 내장 proxy routing, Chromium 소스 레벨 CDP signal 억제를 제공합니다.
CDP를 써야 할 때
browser를 정밀하게, 프로그래밍 방식으로 제어해야 하고 실행 단계가 미리 정해진 경우 CDP를 사용합니다.
CDP가 적합한 시나리오:
- 구조화된 스크레이핑. 대상 셀렉터, 추출할 데이터, 페이지네이션 처리법을 알고 있다. 코드가 매번 같은 단계를 실행한다.
- Network intercept. 리소스 차단, request 헤더 수정, API response 캡처, 페이지 로드 전 JavaScript 주입이 필요하다.
- 복잡한 대기 조건. 특정 DOM 요소, network idle 상태, JavaScript 변수 변화를 기다려야 한다.
- 성능이 중요한 자동화. CDP 명령은 밀리초 만에 실행된다. action마다 LLM inference 지연이 없다. CDP로 수 초 걸리는 50단계 스크레이핑 작업이 LLM 추론을 거치면 수 분 걸린다.
- Framework 개발. agent framework, 테스트 하네스, 다른 사람이 쓸 자동화 라이브러리를 만들고 있다.
# CDP: full control, full responsibility
await page.wait_for_selector("#login-form")
await page.fill("#email", "[email protected]")
await page.fill("#password", credentials)
await page.click("#submit")트레이드오프: browser 접착 코드를 전부 직접 작성하고 유지해야 합니다. 모든 셀렉터, 모든 대기 조건, 모든 에러 핸들러를 포함합니다. 대상 페이지 구조가 바뀌면 코드가 깨집니다.
MCP를 써야 할 때
페이지에 보이는 내용을 바탕으로 LLM이 다음 행동을 결정해야 할 때 MCP를 사용합니다.
MCP가 적합한 시나리오:
- 열린 브라우징. "요금 페이지를 찾아서 플랜 세부사항을 추출해줘." agent가 페이지를 읽고, 하드코딩된 셀렉터 없이 클릭 대상을 판단한다.
- 판단이 필요한 다단계 워크플로. "로그인하고, 새 청구서가 있는지 확인하고, 금액이 500달러 이상이면 다운로드해줘." LLM이 각 단계에서 페이지 내용을 읽고 조건 분기를 처리한다.
- 빠른 프로토타이핑. Playwright 코드 없이 5분 안에 browser agent를 띄우고 싶다. MCP 설정을 추가하고 task를 기술하면 끝이다.
- 비개발자 사용자. agent 운용자가 자연어로 task를 기술한다. 코드가 필요 없다.
- Agent-native 환경. Claude Code, Cursor, Gemini CLI는 이미 MCP를 지원한다. browser 추가는 설정 블록 하나로 끝난다.
# MCP: the LLM decides what to do
User prompt: "Go to example.com and tell me the page title"
LLM calls: navigate(url="https://example.com")
LLM calls: screenshot()트레이드오프: 정밀도가 떨어집니다. LLM이 잘못된 요소를 클릭하거나, 불필요한 단계를 밟거나, 페이지 내용을 잘못 읽을 수 있습니다. 각 action에 LLM inference 지연이 발생합니다. 표준 MCP browser tools로는 network request intercept나 JavaScript 주입이 불가합니다.
둘 다 함께 쓸 때
대부분의 프로덕션 AI 에이전트가 결국 도달하는 구성입니다. MCP가 LLM-to-agent 인터페이스를 맡고, CDP가 agent-to-browser 인터페이스를 맡습니다. MCP 서버가 중간에서 고수준 tool calls를 저수준 browser 명령으로 변환합니다.
LLM ← MCP → MCP Server ← CDP → Browser
(clawctl) (Clawbrowser)LLM이 MCP tool calls를 보냅니다("이 URL로 이동", "로그인 버튼 클릭"). MCP 서버가 이를 CDP 명령으로 변환해 browser에 보냅니다. 결과는 체인을 역순으로 올라옵니다.
browser 레이어가 중요한 이유
대부분의 MCP browser 서버는 CDP를 통해 기본 Chrome instance에 연결합니다. 해당 browser에는 fingerprint 관리, proxy routing, anti-detection이 없습니다. agent가 데모 사이트에서는 작동하지만 Cloudflare, DataDome, Akamai 뒤의 프로덕션 웹사이트에서는 차단됩니다.
Clawbrowser의 내장 MCP 서버는 자체 Chromium engine에 연결합니다. LLM이 navigate를 호출하면 MCP 서버는 managed fingerprints, geo-aligned proxy routing, engine 레벨 CDP signal 억제를 갖춘 browser에 CDP 명령을 보냅니다. stealth plugin, proxy middleware, fingerprint rotation 코드가 필요 없습니다.
MCP 경로 (LLM 기반, 접착 코드 없음):
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]CDP 경로 (스크립트, 완전 제어):
browser = await playwright.chromium.connect_over_cdp(
"http://127.0.0.1:9222"
)두 경로 모두 같은 Clawbrowser instance에 연결되며 같은 fingerprints, proxy routing, anti-detection을 사용합니다. 용도에 맞는 인터페이스를 선택하세요. 같은 프로젝트에서 워크플로의 다른 부분에 다른 수준의 제어가 필요하면 둘 다 사용할 수 있습니다.
두 protocol로 agent를 구축하는 단계별 튜토리얼은 웹을 탐색하는 AI 에이전트 구축 방법을 참고하세요.
판단 프레임워크
| 질문 | CDP | MCP |
|---|---|---|
| 실행 단계를 미리 알고 있는가? | 예 | CDP를 쓴다 |
| LLM이 클릭 대상을 결정해야 하는가? | MCP를 쓴다 | 예 |
| Network intercept가 필요한가? | 예 | 사용 불가 |
| 서브 초 단위 action 속도가 필요한가? | 예 | 아니오 (LLM 지연) |
| 비개발자 대상인가? | 아니오 | 예 |
| Claude Code 또는 Cursor를 쓰는가? | 사용 가능 | 네이티브 통합 |
| browser 코드를 없애고 싶은가? | 아니오 | 예 |
양쪽 모두에 "예"가 있다면 둘 다 사용합니다. LLM 기반 부분에는 MCP, 정밀 제어 부분에는 CDP를 씁니다. Clawbrowser가 어떤 protocol이든 browser 레이어를 담당합니다.
FAQ
browser를 바꾸지 않고 CDP와 MCP를 전환할 수 있나요?
예. browser가 둘 다 지원하면 가능합니다. Clawbrowser는 모든 profile에 CDP endpoint를 공개하고 내장 MCP 서버도 제공합니다. 스크립트 자동화에는 Playwright를 CDP endpoint에 연결하고, LLM 기반 브라우징에는 MCP 서버를 사용합니다. 같은 browser profile에서 같은 fingerprints와 sessions를 씁니다. 두 연결 방식의 안내는 Cursor를 CDP로 실제 브라우저에 연결하는 방법을 보세요.
어떤 protocol이 더 빠른가요?
CDP입니다. LLM inference가 없어 명령이 밀리초 만에 실행됩니다. MCP는 LLM이 호출할 도구를 정하고 결과를 해석해야 하므로 action당 0.5~3초가 걸립니다. 50단계 스크레이핑 작업은 CDP로 수 초, MCP로는 수 분이 걸립니다. 단계가 정해진 대량 자동화에는 CDP를, 각 단계에서 판단이 필요한 작업에는 MCP를 사용하세요.
WebDriver BiDi는 어떤가요?
WebDriver BiDi는 W3C 표준으로, WebDriver(Selenium이 사용)와 CDP 일부를 browser 비의존적 protocol로 대체하려 합니다. 아직 성숙 중입니다. Playwright와 Puppeteer는 여전히 내부에서 CDP를 씁니다. WebDriver BiDi가 완전히 채택되면 browser 제어 레이어에서 CDP와 경쟁하겠지만, tool-use 레이어의 MCP와는 경쟁하지 않습니다. 이 글의 CDP vs MCP 판단 프레임워크는 저수준 browser protocol이 무엇이든 적용됩니다.
어떤 protocol이든 anti-detect browser가 필요한가요?
예. agent가 anti-bot 보호가 있는 사이트를 자동화한다면 필요합니다. CDP에도 MCP에도 anti-detection은 포함되지 않습니다. 이들은 browser에 명령을 보내는 protocol입니다. browser가 자동화 신호(navigator.webdriver, headless User-Agent, 일반 canvas hash)를 노출하면 어떤 protocol을 쓰든 사이트가 차단합니다. 전체 탐지 모델은 브라우저 자동화에서 차단당하지 않는 법을 참고하세요.
빌드 시작
clawbrowser.ai에서 설치 프롬프트를 AI 에이전트에 붙여넣어 Clawbrowser를 설치합니다.
MCP 경로 (LLM 기반): agent에 Clawbrowser MCP 서버 설정을 추가하고 자연어로 브라우징을 시작합니다.
CDP 경로 (스크립트): Playwright 또는 Puppeteer를 CDP endpoint에 연결하고 자동화 코드를 작성합니다.
둘 다: LLM이 무엇을 할지 추론하는 부분에는 MCP를, 정밀하고 빠르며 결정적인 제어가 필요한 부분에는 CDP를 사용합니다. 같은 browser, 같은 fingerprints, 같은 sessions입니다.
CDP 심화는 CDP Browser for AI Agents 개발자 가이드를 읽으세요. 전체 빌드 튜토리얼은 웹을 탐색하는 AI 에이전트 구축 방법을 읽으세요.
Continue exploring
Ask AI how Clawbrowser helps
계속 읽기
