Aside는 Playwright MCP, 클로드 인 크롬과 뭐가 다를까요?

Aside는 크로미움 엔진을 직접 고쳐 에이전트를 브라우저 안에 넣은 AI 브라우저입니다. CDP(Chrome DevTools Protocol)로 브라우저 바깥에서 연결하는 Playwright MCP와 chrome-devtools-mcp, 크롬 확장 프로그램으로 동작하는 Claude in Chrome과는 붙는 위치가 다릅니다. 붙는 위치가 다르면 접근할 수 있는 범위도 함께 달라집니다.

그러면 이미 쓸 만한 도구가 있는데 브라우저를 통째로 만드는 회사가 왜 필요할까요? 브라우저 밖에서는 바꿀 수 없는 값이 남아 있기 때문입니다. 자동화 여부를 웹페이지에 알리는 값, 화면이 만들어지는 순서, 비밀번호를 다루는 방법이 모두 엔진 안에서 정해집니다.

2026년 8월 말 쓰레드에서 같은 질문이 올라왔고, lilmgenius 계정이 열 편짜리 답변으로 정리한 글이 조회 2만 회를 넘겼습니다.

“

질문의 핵심은 "일반 CDP/Playwright 하네스로는 접근이 안 되고 Aside의 Chromium 수정으로만 가능한 부분이 정확히 뭐냐"였습니다.

쓰레드를 쓴 사람은 마지막 편에 Aside 개발사 공동창업자의 반응을 함께 올렸습니다. Aside 계정은 "저희보다 더욱 Aside가 CDP나 Claude in Chrome 등과 어떻게 다른지 잘 설명해주셨네요"라는 답글을 남겼습니다.

지금부터 그 쓰레드에서 정리된 항목을 출발점으로 삼되, 구글과 앤트로픽, Browserbase의 공식 문서로 확인되는 것과 커뮤니티 주장으로 남아 있는 것을 나눠서 정리하겠습니다. Aside를 직접 설치해 두 가지 작업을 돌려 본 기록은 준이아빠블로그의 Aside 브라우저 사용 후기에 따로 있고, 같은 방향을 택한 제품과의 비교는 클로드 코워크 내장 브라우저 정리에 적어 두었습니다.

브라우저 밖에서 붙는 하네스와 안에서 고친 브라우저

하네스라는 말은 CDP보다 상대적으로 낯설 수 있습니다. 쉽게 말하면 브라우저 바깥에서 제어 통로로 연결해 명령을 보내는 프로그램입니다. 여기서 다루는 네 도구를 한 줄씩 정리하면 이렇습니다.

• Playwright MCP: 마이크로소프트가 만든 하네스로, 웹 테스트 도구인 Playwright를 AI 도구에 연결해 씁니다.
• chrome-devtools-mcp: 구글이 직접 관리하는 하네스로, 크롬 개발자 도구의 기능을 AI 도구에 열어 줍니다.
• Claude in Chrome: 앤트로픽이 만든 크롬 확장 프로그램으로, 옆 패널에서 지금 보고 있는 페이지를 읽고 조작합니다.
• Aside: Aside Computer가 만든 AI 브라우저로, 크로미움 소스를 고쳐 다시 빌드한 별도 앱입니다.

앞의 두 도구가 붙을 때 쓰는 CDP는 크롬 개발자 도구가 브라우저와 주고받는 제어 규약입니다. 유리창 밖에서 집 안을 들여다보며 심부름을 시키듯, 하네스는 브라우저가 내주는 결과를 받아 보고 다시 명령을 넣습니다. 창문 너머로도 웬만한 일은 시킬 수 있지만 집 안에서만 되는 일이 남습니다. 크로미움을 포크한 쪽은 아예 집 안에 들어와 있는 방식이라고 볼 수 있습니다.

세 가지는 우열이 아니라 접근 범위의 차이입니다. 아래에서는 브라우저 밖에서 잘 되지 않는 것부터 항목별로 보겠습니다.

왜 브라우저 밖에서는 같은 경험을 만들기 어려울까요?

매일 쓰는 크롬에 붙는 것부터 막힙니다

구글은 2025년 3월 공지에서 Chrome 136부터 --remote-debugging-port와 --remote-debugging-pipe 스위치의 동작을 바꿨다고 밝혔습니다. 기본 크롬 데이터 디렉터리를 대상으로 하면 이 스위치가 더 이상 적용되지 않고, --user-data-dir로 표준이 아닌 경로를 함께 지정해야 합니다.

이유도 공지에 함께 적혀 있습니다. 쿠키와 자격 증명 암호화가 강화된 뒤 공격자들이 원격 디버깅으로 쿠키를 빼내는 사례가 늘었기 때문입니다. 구글은 같은 글에서 브라우저 자동화에는 Chrome for Testing을 쓰라고 권합니다.

결과적으로 하네스는 내가 로그인해 둔 크롬 프로필에 그대로 붙지 못하고 별도 프로필로 크롬을 새로 띄우게 됩니다. 그러면 확장 프로그램으로 붙으면 되지 않을까요? 그 방법에도 제약이 따릅니다. 확장의 chrome.debugger 권한으로 붙으면 디버깅 중이라는 알림 막대가 화면에 뜨고, chrome://로 시작하는 내부 페이지에는 붙지 않습니다.

자동화 신호는 엔진 안에서 켜집니다

navigator.webdriver라는 이름은 CDP보다 상대적으로 낯설 수 있습니다. 쉽게 말하면 지금 이 브라우저가 자동화로 움직이는 중인지를 웹페이지에 알려 주는 값입니다. 이 값은 Blink 즉 크로미움의 화면 그리기 엔진 안에서 정해지므로, 밖에서 켜고 끄기 어렵습니다.

Browserbase는 크로미움을 포크한 이유를 설명한 글에서 이 값을 어떻게 고쳤는지 코드 차이까지 공개했습니다. navigator.cc 파일을 수정해 브라우저를 어떤 방식으로 실행하든 항상 false를 반환하게 만들었습니다. 실제 패치는 아래와 같습니다.

같은 글에는 헤드리스 모드에서 HeadlessChrome으로 보고되던 값을 Chrome으로 통일하고, 창이 모두 닫혀도 브라우저 프로세스를 유지하도록 기본값을 바꾼 내용도 함께 실렸습니다. 브라우저가 자기 상태를 어떻게 알리는지는 엔진이 정하므로, 바깥에서는 이 값을 바꿀 방법이 마땅치 않습니다.

그래서 하네스 쪽에는 우회가 남습니다. Playwright를 고쳐 만든 Patchright는 탐지에 걸리는 Runtime.enable 명령을 쓰지 않고 격리된 실행 환경에서 자바스크립트를 돌립니다. 콘솔 API는 통째로 꺼 버리는데, 공식 저장소도 이 방식을 쓰면 콘솔 기능이 동작하지 않는다고 밝혀 두었습니다. 기능 하나를 포기하고 신호를 지우는 방식입니다.

화면을 읽는 시점의 차이

접근성 트리(accessibility tree)는 DOM보다 상대적으로 낯선 개념입니다. 쉽게 말하면 화면에 놓인 요소의 역할과 이름을 담은 목록이고, 브라우저가 화면을 만드는 중간 단계에서 생성됩니다. 그린 결과를 화면에 합치는 과정은 그 뒤에 진행됩니다.

Playwright MCP는 이 트리를 스냅샷으로 받아 씁니다. 픽셀이 아니라 구조를 읽기 때문에 가볍고 결과가 일정하다는 것이 마이크로소프트가 밝힌 설계 의도입니다. 쓰레드에서 정리된 주장은 여기서 한 단계 더 들어갑니다. 브라우저 밖에서는 에이전트가 완성된 결과를 넘겨받지만, 안에서는 화면이 만들어지는 도중에 읽고 같은 처리 단위 안에서 입력까지 보낸다는 이야기입니다.

클릭 직전에 요소를 다시 확인하는 절차도 하네스에서는 페이지에 주입한 자바스크립트가 담당하므로, 확인한 시점과 실제로 누르는 시점이 벌어질 수 있습니다. 같은 쓰레드 답글에는 이 차이가 드러나는 경험이 올라왔습니다. 마우스를 올렸을 때만 나타나는 호버 효과가 두 시점의 차이 때문에 감지되지 않았는데 Aside에서는 감지되었다는 내용이었고, 답글을 쓴 사람도 Aside에서만 되는 것이 아니라 더 잘 되는 쪽이라고 덧붙였습니다. 공식 문서로 확인되는 항목이 아니므로 사용 경험 수준으로 받아들이는 편이 적절해 보입니다.

에이전트 탭이 사람 작업을 방해하는 문제

에이전트가 쓰는 탭이 사람이 보고 있는 화면을 건드리지 않게 만드는 것도 브라우저 밖에서는 어렵습니다. 백그라운드 탭이 팝업을 띄우면 하네스는 팝업이 뜬 뒤에 되돌리는 정도만 가능합니다.

쓰레드 정리에 따르면 Aside는 포커스와 팝업을 엔진 단계에서 미리 막고 에이전트 탭의 화면 크기를 1440x900으로 고정합니다. CDP에도 화면 크기를 흉내 내는 Emulation 명령이 있지만, 세션이 연결되어 있는 동안에만 유지된다는 점이 다릅니다.

비밀번호와 패스키 처리

패스키(passkey)는 비밀번호보다 상대적으로 낯선 방식입니다. 쉽게 말하면 기기에 저장된 열쇠와 생체 인증으로 비밀번호 없이 로그인하는 방법이고, 브라우저가 그 열쇠를 직접 보관합니다.

Aside 공식 문서는 저장된 비밀번호를 에이전트에게 보여주지 않고 사이트에 입력한다고 설명합니다. 2단계 인증과 패스키, FIDO2, TOTP가 요구되면 화면에 뜬 단계를 사람이 직접 끝내고 작업이 이어집니다. 결제와 게시, 메시지 발송처럼 되돌리기 어려운 작업은 승인을 기다리고, 사이트별 접근 정책은 Always allow, While unlocked, Never 가운데 고릅니다.

열쇠를 창문 밖으로 건네지 않고 집 안 금고가 문을 대신 열어 주는 구조인데, 하네스에서는 만들기 어렵습니다. 임의의 자바스크립트를 실행할 통로가 열려 있는 상태에서 비밀번호만 가려서 입력하려면 엔진에서 막는 방법 외에는 마땅치 않기 때문입니다. CDP에도 WebAuthn 명령이 있지만 테스트용 가상 인증기를 다루는 용도라 실제 사용자의 패스키를 대신 쓰지는 못합니다.

크로미움 포크의 실제 비용

그러면 엔진을 고친 쪽이 언제나 유리할까요? 그렇게 보기는 어렵습니다. 포크에는 유지 비용이 따라오고, 그 비용을 감당하지 못한 제품이 이미 여럿 사라졌습니다.

Browserbase는 크로미움이 약 6주마다 새 버전을 내고 하루에도 수백 건의 커밋이 쌓이므로 버전이 올라갈 때마다 패치를 다시 맞춰야 한다고 밝혔습니다. 일반적인 맥북에서 전체 빌드에 사흘에서 나흘이 걸리고, 전용 빌드 장비를 갖춰야 한 시간 안팎으로 줄어듭니다.

Arc는 2025년 5월에 새 기능 개발을 중단했고, OpenAI의 ChatGPT Atlas는 2026년 8월 9일에 서비스를 끝냈습니다. 출시 292일 만이었습니다. 쓰레드 정리도 5인 팀이 크로미움 새 버전을 얼마나 빨리 따라붙는지를 경쟁 요소로 꼽았는데, 이런 사정과 이어지는 이야기입니다.

Aside, Playwright MCP, chrome-devtools-mcp, Claude in Chrome 비교

2026년 8월 기준으로 네 도구의 공개 자료를 정리하면 다음과 같습니다.

Claude in Chrome은 브라우저 안에서 동작하는데 왜 하네스 쪽에 놓았을까요? 확장 프로그램이 접근할 수 있는 범위는 크롬이 열어 준 만큼으로 정해져 있기 때문입니다. 페이지 내용을 읽고 조작하는 일은 되지만, 엔진 값을 바꾸거나 화면을 만드는 도중에 끼어드는 일은 확장 API의 범위를 벗어납니다.

외부 하네스가 여전히 맞는 경우

엔진을 고친 브라우저가 모든 작업에서 앞선다고 보기는 어렵습니다. 목적이 다른 구간이 분명히 있습니다.

• 디버깅과 성능 점검: chrome-devtools-mcp는 성능 추적과 Lighthouse 감사, 네트워크 요청 검사, 힙 스냅샷을 도구로 제공합니다. 웹사이트를 만드는 사람에게는 이쪽이 본업에 가깝습니다.
• 테스트 자동화: Playwright MCP는 60개가 넘는 도구를 제공하고 네트워크 요청 가로채기와 오프라인 상황 흉내까지 다룹니다. 같은 조건을 반복 재현해야 하는 작업에 맞습니다.
• 브라우저를 바꾸고 싶지 않을 때: Claude in Chrome은 쓰던 크롬에 그대로 붙습니다. 사이트별로 접근을 켜고 끌 수 있고, 게시나 구매처럼 되돌리기 어려운 작업 앞에서는 확인을 요청합니다.
• 운영체제 조건: Aside는 2026년 8월 기준 macOS 중심으로 배포되고 있어서, 윈도우 환경이라면 선택지가 좁아집니다.

위에 넣은 구글과 Browserbase 화면 캡처도 준이아빠블로그에서 Playwright MCP로 두 페이지를 열어 받은 것입니다. 공개된 문서를 읽고 캡처하는 작업이라면 하네스만으로 충분하다는 예로 볼 수 있습니다.

보안 쪽도 함께 봐야 합니다. 앤트로픽은 Claude in Chrome을 공개하면서 프롬프트 인젝션 실험 결과를 함께 밝혔습니다. 완화 조치를 넣기 전 공격 성공률이 23.6%였고 조치 뒤 11.2%로 내려갔으며, 브라우저에서만 성립하는 네 가지 공격은 35.7%에서 0%가 되었습니다. 웹페이지에 숨겨 둔 지시문에 에이전트가 끌려갈 여지는 엔진을 고친 쪽에도 남아 있으므로, 어느 도구를 쓰든 승인 단계를 켜 두는 편이 안전합니다.

지금까지 정리한 항목 가운데 화면을 읽는 시점과 포커스 차단, 화면 크기 고정은 쓰레드에 올라온 설명이고 Aside가 공식 문서로 밝힌 내용이 아닙니다. 엔진 안쪽을 무엇부터 어디까지 고쳤는지는 소스가 공개되기 전까지 단정하기 어렵습니다.

자주 묻는 질문

Playwright MCP만으로는 Aside가 하는 일을 못 하나요?

못 하는 것은 아니고 조건이 달라집니다. 사이트를 열고 읽고 클릭하는 작업은 Playwright MCP로도 진행됩니다. 다만 매일 쓰는 크롬 프로필에 붙지 못하고, 자동화 신호를 지우려면 Patchright 같은 우회를 더해야 하며, 비밀번호를 모델에 숨긴 채 입력하는 구조는 만들기 어렵습니다.

Claude in Chrome은 브라우저 안에서 동작하는데 왜 하네스와 함께 묶어 보나요?

확장 프로그램은 크롬이 확장에 허용한 범위 안에서만 동작하기 때문입니다. 페이지 내용을 읽고 조작하는 일은 되지만, navigator.webdriver 같은 엔진 값을 바꾸거나 화면을 만드는 도중에 끼어드는 일은 확장 API의 범위를 벗어납니다. 붙는 위치로 보면 엔진 수정보다 하네스 쪽에 가깝습니다.

크로미움을 고치면 봇 차단을 확실히 피할 수 있나요?

확실하다고 보기는 어렵습니다. Browserbase가 공개한 것은 navigator.webdriver와 헤드리스 표기 같은 알려진 신호를 지운 패치이고, 탐지 방식은 계속 바뀝니다. 자동화 탐지를 피하는 것과 웹사이트 이용약관을 지키는 것은 별개의 문제이므로, 로그인이 걸린 서비스를 다룰 때는 약관과 계정 정책을 먼저 확인하는 편이 안전합니다.

3줄 요약

• Aside는 크로미움 엔진을 직접 고쳐 에이전트를 브라우저 안에 넣은 AI 브라우저이고, CDP와 Playwright MCP, Claude in Chrome은 브라우저 밖이나 확장 범위에서 붙습니다.
• Chrome 136부터 원격 디버깅 스위치가 기본 데이터 디렉터리에서 무시되므로, 외부 하네스는 매일 쓰는 크롬 프로필이 아니라 별도 프로필을 띄워야 합니다.
• 자동화 탐지 신호와 화면을 읽는 시점, 비밀번호를 모델에 넘기지 않는 자동 입력은 엔진을 고쳐야 풀리는 문제라 하네스로는 대체하기 어렵습니다.

참고 자료

• Changes to remote debugging switches to improve security (Chrome for Developers)
• Why we forked Chromium (Browserbase)
• Playwright MCP 공식 저장소
• chrome-devtools-mcp 공식 저장소
• Claude for Chrome 공식 발표 (Anthropic)
• Aside 패스워드 매니저 공식 문서