실행 엔진과 인터페이스: Playwright, MCP, CLI, 클라우드 브라우저
브라우저 에이전트를 처음 접하면 자주 생기는 혼란이 있다. Playwright도 브라우저를 움직이고, MCP도 브라우저를 움직이고, CLI도 브라우저를 움직이고, Browserbase 같은 서비스도 브라우저를 움직인다. 그러다 보니 전부 비슷한 것처럼 느껴진다.
하지만 이들을 한 상자에 넣어버리면 설계가 흐려진다. 반대로 각자의 자리를 분리해서 보면 아키텍처가 놀랄 만큼 선명해진다. 누가 생각하는지, 누가 클릭하는지, 누가 연결해 주는지, 누가 브라우저를 띄워서 오래 버티게 해주는지만 구분하면 된다.
이 장의 핵심은 간단하다. 추론 레이어와 실행 레이어, 인터페이스 레이어, 인프라 레이어를 분리해서 보라. 그러면 도구 이름이 바뀌어도 구조는 흔들리지 않는다.
브라우저 에이전트 스택을 한눈에 보기
브라우저 에이전트는 보통 아래 네 층으로 생각하면 이해가 쉽다.
추론 레이어: 무엇을 할지 결정한다.
인터페이스 레이어: 그 결정을 도구 호출 형태로 바꾼다.
실행 레이어: 실제 브라우저를 클릭하고 입력한다.
인프라 레이어: 브라우저 세션, 확장성, 원격 실행, 격리를 책임진다.
사람에 비유하면 이렇다. 추론 레이어는 머리이고, 실행 레이어는 손이다. 인터페이스 레이어는 머리와 손 사이의 신경망 비슷한 연결부이고, 인프라 레이어는 작업실과 책상, 전원, 네트워크 같은 환경이다. 손이 아무리 튼튼해도 작업실이 없으면 오래 일하기 어렵고, 머리가 아무리 똑똑해도 손에 명령을 전달할 방법이 없으면 브라우저는 꿈쩍도 하지 않는다.
실행 엔진: Playwright와 Selenium은 무엇을 하는가
Playwright와 Selenium은 실행 엔진이다. 이들은 목표를 스스로 세우지 않는다. 대신 이미 정해진 명령을 정확하게 수행한다. 페이지로 이동하고, 버튼을 클릭하고, 입력창에 값을 넣고, 쿠키를 저장하고, 탭을 전환하는 식이다.
즉, 실행 엔진의 질문은 왜 이 버튼을 눌러야 하지?가 아니라 어떤 버튼을, 어떤 방식으로 눌러야 하지?에 가깝다.
Playwright가 특히 브라우저 에이전트 시대에 잘 맞는 이유는 현대 웹앱을 다루는 능력이 좋고, 여러 브라우저 엔진을 지원하며, 페이지 상태를 더 구조적으로 다룰 수 있기 때문이다. 공식 Playwright MCP 문서도 Playwright가 MCP 서버 뒤에서 실제 브라우저 자동화를 수행하며, LLM은 픽셀이 아니라 접근성 스냅샷을 통해 페이지를 이해한다고 설명한다.1
Selenium도 여전히 중요한 실행 엔진이다. 역사가 길고 생태계가 넓으며, 다양한 언어와 기업 환경에서 많이 쓰인다. 다만 AI 에이전트 문맥에서는 최근 도구 생태계가 Playwright 중심으로 빠르게 발전하고 있어서, 자연어 기반 브라우저 사용이나 MCP 연동 사례는 Playwright 쪽이 더 눈에 띈다.
중요한 점은 이것이다. Playwright나 Selenium은 브라우저를 움직이는 엔진이지, 생각하는 에이전트가 아니다. LLM이 없다면 그냥 매우 성실한 자동화 기사다. 시키는 일은 잘하지만, 일을 왜 하는지는 모른다.
인터페이스 계층: MCP는 엔진이 아니라 연결 방식이다
MCP를 처음 보면 종종 이렇게 오해한다. 아, MCP가 브라우저를 자동화하는구나. 반은 맞고 반은 틀리다.
정확히 말하면 MCP는 AI 클라이언트가 외부 도구를 표준 방식으로 호출하도록 만드는 인터페이스 계층이다. Playwright MCP 서버는 Playwright라는 실행 엔진을 MCP라는 인터페이스 뒤에 놓은 형태다. 그래서 VS Code, Cursor, Claude Desktop 같은 MCP 클라이언트가 브라우저 동작을 도구처럼 호출할 수 있다.1
이 구조를 이해하면 이름이 길어도 겁먹을 필요가 없다.
Playwright MCP = Playwright 엔진 + MCP 인터페이스
여기서 진짜 브라우저를 움직이는 것은 Playwright이고, MCP는 그 기능을 LLM 친화적인 도구 세트로 노출한다. 공식 저장소도 이 패키지를 Playwright에 대한 MCP 인터페이스라고 설명한다.2
이 말은 아주 중요하다. 인터페이스는 바꿀 수 있지만 엔진은 그대로 둘 수 있다. 예를 들어 같은 Playwright 엔진을 두고도 MCP로 연결할 수 있고, CLI로 연결할 수도 있고, 어떤 애플리케이션 내부 SDK로 감쌀 수도 있다.
CLI 계층: 대화형 도구가 아니라 명령형 도구
CLI는 또 다른 인터페이스다. 다만 MCP가 도구 호출에 가깝다면, CLI는 명령 실행에 가깝다.
이 차이는 생각보다 크다. MCP는 대화형 에이전트가 풍부한 상태를 주고받으며 작업하기 좋다. 반면 CLI는 코딩 에이전트나 터미널 중심 워크플로에 잘 맞는다. Microsoft도 공식 저장소에서 코딩 에이전트의 경우 CLI+SKILLS 방식이 더 토큰 효율적일 수 있다고 설명한다. 큰 도구 스키마와 장문의 접근성 트리를 계속 모델 문맥에 넣지 않아도 되기 때문이다. 반대로 MCP는 지속 상태와 풍부한 페이지 구조 관찰이 필요한 에이전트 루프에 여전히 강점이 있다.2
여기서 agent-browser 같은 도구가 등장한다. 이 도구는 브라우저 자동화를 위한 CLI이며, 스냅샷에서 @e2 같은 참조를 얻고 그 참조로 클릭하거나 입력하는 흐름을 제공한다.3 즉, 본질은 브라우저를 다루는 명령줄 인터페이스다. 여전히 뇌는 아니다. 손에 더 가까운 인터페이스다.
Browser Use CLI도 비슷한 점이 있다. 공식 문서는 이 CLI가 직접 브라우저를 열고 상태를 보고, 요소 번호를 얻고, 클릭하고, 입력하고, 심지어 클라우드 브라우저까지 연결할 수 있다고 설명한다. 게다가 백그라운드 데몬이 브라우저를 살아 있게 유지해서 명령 간 지연을 줄인다.4
정리하면 CLI는 브라우저를 조작하는 언어를 자연어 도구 호출 대신 셸 명령 형태로 제공하는 계층이라고 볼 수 있다.
클라우드 브라우저: 브라우저를 어디서 돌릴 것인가
이제 인프라 레이어로 내려가 보자. 여기서 질문은 무엇으로 조작할까?가 아니라 브라우저를 어디에서, 어떤 환경으로, 얼마나 많이 띄울까?다.
이 문제를 해결하는 것이 Browserbase류의 클라우드 브라우저 인프라다. 이런 서비스는 원격 브라우저 세션을 제공하고, 세션 격리와 확장성, 장시간 실행, 관찰 도구, 때로는 프록시나 안티봇 대응까지 맡는다. 브라우저를 직접 내 노트북에서 띄우는 대신, 브라우저를 서비스처럼 빌려 쓰는 셈이다.
Browserbase를 설명한 비교 글을 보면, 개발자는 Browserbase API로 브라우저 세션을 띄우고 Playwright나 Puppeteer의 표준 CDP 방식으로 연결할 수 있다. 즉, 브라우저 자체는 클라우드에 있지만 제어 방식은 익숙한 자동화 도구를 그대로 쓸 수 있다.6
이 계층이 중요한 이유는 세 가지다.
로컬 자원을 덜 쓴다.
병렬 세션을 쉽게 늘릴 수 있다.
세션 격리, 원격 디버깅, 지역 분산 같은 운영 문제를 다루기 쉬워진다.
Google Cloud Run 문서도 비슷한 인프라 관점을 보여 준다. 단순한 헤드리스 브라우저뿐 아니라, 더 복잡한 상호작용이 필요하면 전체 데스크톱 OS까지 컨테이너로 실행해 웹 자동화를 할 수 있다고 설명한다.5 이 말은 곧 브라우저 자동화가 이제 라이브러리 하나의 문제가 아니라 실행 환경 전체의 문제이기도 하다는 뜻이다.
Browserbase류 서비스가 해결하는 진짜 문제
클라우드 브라우저를 처음 보면 아, 브라우저를 대신 호스팅해 주는구나 정도로 이해하기 쉽다. 맞는 말이지만, 그것만으로는 절반밖에 본 것이 아니다.
이들이 실제로 해결하는 문제는 더 운영적이다.
첫째, 세션 관리다. 로그인 상태를 유지할지, 완전히 새 세션으로 시작할지, 여러 탭을 어떤 작업 단위로 격리할지 같은 문제가 생긴다.
둘째, 확장성이다. 실험할 때는 브라우저 하나면 되지만, 운영에서는 열 개, 백 개, 수백 개 세션이 동시에 필요할 수 있다. 이때 노트북 한 대는 금방 울기 시작한다. 팬 소리가 갑자기 철학적으로 변한다.
셋째, 관찰 가능성이다. 실패했을 때 어디서 꼬였는지 알아야 한다. 스크린샷, 비디오, 네트워크 로그, 콘솔 로그, 라이브 뷰는 단순한 사치가 아니라 운영 도구다.
넷째, 네트워크와 지역성이다. 어느 국가에서 접속하느냐, 프록시를 어떻게 쓰느냐, 내부 서비스에 어떻게 연결하느냐가 성공률에 직접 영향을 준다.
그래서 Browserbase류는 실행 엔진의 대체재가 아니라, 실행 엔진이 오래 버티고 많이 일할 수 있게 해 주는 작업장이다.
Browser Use와 agent-browser는 어느 층에 놓아야 할까
여기서 많은 사람이 헷갈린다. Browser Use나 agent-browser는 도대체 엔진인가, 에이전트인가, 인터페이스인가?
정답은 하나가 아니다. 제품은 종종 여러 층을 묶어서 제공한다.
예를 들어 agent-browser는 CLI 중심 인터페이스이지만, 내부적으로는 브라우저 세션을 유지하고 접근성 스냅샷과 ref 기반 상호작용을 제공한다.3 즉, 사용자가 체감하는 표면은 인터페이스지만, 내부에는 실행 제어 로직도 들어 있다.
Browser Use는 더 흥미롭다. 오픈소스 프레임워크로서의 Browser Use는 보통 LLM의 추론 루프 + 브라우저 제어를 함께 다루고, Browser Use CLI는 그중 직접 조작 가능한 명령형 표면을 제공한다. 공식 CLI 문서도 관리형 헤드리스 Chromium, 실제 Chrome 프로필, 클라우드 호스팅 브라우저라는 세 가지 브라우저 모드를 설명한다.4
즉, Browser Use라는 이름 하나만 보고 층을 단정하면 안 된다. 어떤 맥락에서는 에이전트 프레임워크이고, 어떤 맥락에서는 CLI 인터페이스이며, 어떤 맥락에서는 클라우드 브라우저에 연결하는 입구다.
그래서 도구 이름이 아니라 현재 내가 쓰는 기능이 어느 층의 역할을 하는지를 따져야 한다.
추론 레이어는 어디에 있는가
이 장의 핵심 문장을 다시 적어 보자.
LLM이 브라우저를 직접 움직이는 것처럼 보여도, 실제로는 추론 레이어가 다른 레이어를 호출하고 있을 뿐이다.
추론 레이어는 목표를 해석하고, 다음 행동을 계획하고, 실패를 보고 수정한다. 로그인 후 대시보드에서 매출 차트를 찾아 CSV로 저장하라 같은 목표를 페이지 이동 → 로그인 상태 확인 → 버튼 클릭 → 데이터 추출 같은 단계로 바꾸는 곳이 바로 여기다.
이 레이어는 GPT일 수도 있고, Claude일 수도 있고, 로컬 모델일 수도 있다. 심지어 규칙 기반 플래너와 혼합될 수도 있다. 중요한 것은 이 레이어가 바뀌어도 Playwright는 그대로일 수 있고, MCP도 그대로일 수 있으며, Browserbase류 인프라도 그대로일 수 있다는 점이다.
바로 이 분리가 좋은 아키텍처의 출발점이다. 뇌를 교체해도 손과 책상이 그대로 남으면 시스템 전체를 갈아엎지 않아도 된다.
세 가지 대표 아키텍처
실무에서는 대체로 아래 세 형태가 자주 보인다.
로컬 대화형 구조: Claude Desktop나 Cursor 같은 MCP 클라이언트 + Playwright MCP + 로컬 브라우저. 디버깅이 쉽고 눈으로 보기 좋다.코딩 에이전트 구조: Claude Code, Codex, Copilot 같은 환경 + CLI 계층(agent-browser,browser-use, Playwright CLI`) + 로컬 또는 원격 브라우저. 토큰 효율과 스크립트화에 유리하다.운영형 구조: 자체 에이전트 서비스 + Playwright 같은 실행 엔진 + Browserbase류 클라우드 브라우저 + 프록시/세션 저장소/관찰 도구. 대량 실행과 운영 안정성에 유리하다.
셋 중 무엇이 더 고급이라고 보기는 어렵다. 오히려 단계가 다르다. 개인 실험에는 첫 번째가 편하고, 개발 워크플로에는 두 번째가 날렵하며, 제품 운영에는 세 번째가 자연스럽다.
무엇을 고를지 헷갈릴 때 묻는 질문
도구 선택은 이름보다 질문이 더 중요하다.
먼저, 브라우저 상태를 오래 유지해야 하는가를 보자. 로그인 세션과 여러 단계 탐색이 핵심이라면 MCP나 지속 세션 구조가 잘 맞는다.2
다음으로, 토큰 비용과 문맥 길이가 중요한가를 보자. 코딩 에이전트가 파일 시스템과 터미널을 이미 잘 다룬다면 CLI가 더 경제적일 수 있다.2
그다음, 몇 개의 브라우저를 동시에 돌릴 것인가를 보자. 한두 개면 로컬도 충분하지만, 병렬 실행과 장시간 작업이 늘어나면 클라우드 브라우저 인프라가 빛을 발한다.56
마지막으로, 당신이 지금 고르려는 것이 추론 도구인지, 실행 도구인지, 인프라인지를 반드시 확인해야 한다. 이 질문 하나만 해도 구매 실수와 설계 실수가 크게 줄어든다.
아키텍처가 선명해지면 도구 비교도 쉬워진다
이제 처음의 혼란으로 돌아가 보자.
Playwright는 실행 엔진이다. MCP와 CLI는 인터페이스다. Browserbase류는 인프라다. LLM 에이전트는 추론 레이어다.
이 네 문장만 머릿속에 고정해도 도구 비교가 훨씬 쉬워진다. 어떤 서비스가 아무리 멋진 이름을 달고 나와도, 결국 우리는 이렇게 물어볼 수 있다.
이 도구는 생각하는가, 연결하는가, 실행하는가, 아니면 운영을 맡는가?
이 질문에 답할 수 있으면 브라우저 에이전트 스택은 더 이상 안개가 아니다. 그냥 잘 정리된 공구함이다. 그리고 공구함이 잘 정리되면, 다음 장부터 다룰 실제 사용 사례와 운영 이슈도 훨씬 현실적으로 보이기 시작한다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.