본 기사에서는 Claude Code 데스크톱 앱에 추가된 Browser pane이 평소 브라우저 조작에 사용하는 Playwright를 대신할 수 있는지, 공식 설명을 통해 확인하며 실기(実機)로 구동하여 검증해 보았습니다.

TL;DR

• Browser pane은 2026년 7월에 추가된 Claude Code 데스크톱 앱 내장 브라우저입니다.
  기존에 있던 Preview 페인을 개명하고, 외부 사이트 열람에 대응하도록 만든 것이었습니다. - 내부 구성은 Electron 42 / Chromium 148이며, 실기로 구동했을 때
  페이지의 텍스트나 DOM, JavaScript 실행은 모두 문제없이 가져올 수 있었습니다. - 다만 스크린샷의 경우, Browser pane이 화면에 보이지 않으면 30초 만에 타임아웃되었습니다. 보이지 않는 페이지의 렌더링을 Chromium이 중단하기 때문이며,
  별도 창이나 별도 세션을 보면서 작업을 맡기는 방식에서 발생하기 쉽습니다. - Playwright와 비교했을 때 Browser pane이 우세한 점은 로컬 개발 서버의 프리뷰 통합과, 설정 없이 클린한 환경을 열 수 있다는 점이었습니다. 반대로, 이미지를 확실하게 가져오고 싶은 작업이나 로그인된 상태의 조작, 그리고
  화면을 보지 않고 백그라운드에서 계속 돌리고 싶은 작업은 Playwright가 더 적합합니다.

서론

Claude Code 데스크톱 앱을 실행하니 브라우저 기능이 추가되었다는 안내가 나왔습니다. 듣고 보니 작업을 시키는 도중에 Browser pane이라는 브라우저가 열려 있었습니다. 마침 어떤 페이지의 내용과 이미지를 가져오고 싶었기에 그대로 사용해 보았습니다. 하지만 생각만큼 잘 가져와지지 않아 결국 Playwright로 전환하여 일을 마쳤습니다.

이제 막 추가된 기능을 제대로 다루지 못한 것일지도 모릅니다. 그래서 이 Browser pane이 실제로 어떤 기능을 하는지, 어디까지 가능한지를 공식 설명과 실기 모두를 통해 확인했습니다.

결론부터 말씀드리면, Browser pane은 텍스트나 DOM을 읽는 용도로는 충분히 사용할 수 있지만, 이미지나 스크린샷이 포함된 작업에는 현재 구현 단계에서 불안 요소가 남아 있었습니다.

Browser pane이란 무엇인가

먼저 공식 설명을 정리하겠습니다. Browser pane은 Claude Code 데스크톱 앱의 Code 탭 옆에 나란히 있는 페인 중 하나로, 실행 중인 앱 옆에 문서나 issue tracker 등의 사이트를 열 수 있는 탭 형태의 브라우저라고 설명되어 있습니다 (Desktop application). 여는 단축키는 Windows에서 Ctrl+Shift+B, macOS에서 Cmd+Shift+B입니다.

왼쪽 채팅에서 요청하면, 오른쪽 Browser pane에 Sonnet 5의 공식 페이지가 열린다

추가된 시점은 2026년 7월 10일경, 데스크톱 v2.1.206 전후입니다. 다만 무에서 유를 창조한 신기능이 아니라, 기존에 있던 Preview 페인 (실행 중인 앱의 프리뷰)을 개명하고 외부 사이트 열람 기능을 추가한 것입니다. 공식 changelog에도 개명에 앞서 Claude Preview와 Claude Browser라는 이름을 예약한 항목이 남아 있습니다 (changelog).

프로필에 대해서는 공식 측에서 명확하게 구분하여 작성하고 있습니다. Browser pane은 개인 브라우저와는 별개의 클린한 환경이며, 저장된 로그인 정보나 히스토리를 가지고 있지 않습니다. 자신의 로그인 상태 그대로 조작하게 하고 싶을 때는 Claude in Chrome 확장 프로그램을 사용하라는 위치 설정입니다 (Desktop application).

테스트 방법

공식 설명만으로는 실제로 어디까지 가져올 수 있는지 알 수 없습니다. 중립적인 페이지 (example.com 및 영어 Wikipedia)를 열고, Claude Code를 통해 다음 사항을 순차적으로 확인했습니다.

• navigator.userAgent를 읽어 브라우저의 정체를 특정함
• document.visibilityState와 document.hidden을 읽어 페이지의 표시 상태를 확인함
• 페이지의 텍스트, DOM, 이미지를 가져오는 조작을 각각 시도함
• 스크린샷을 촬영함

환경은 Windows 11, Claude Code 데스크톱의 build 1.20186.1입니다. 페인(Pane)을 전면에 고정하지 않고, 에이전트가 평소 외부 페이지를 다룰 때와 마찬가지로 백그라운드에서 동작하는 상태로 테스트했습니다.

실기 테스트 결과

결과를 먼저 요약하자면, 읽기 관련 작업은 모두 성공했으나 스크린샷만 실패했습니다.

먼저 정체입니다. navigator.userAgent는 다음과 같았습니다.

Claude/1.20186.1 Chrome/148.0.7778.271 Electron/42.5.1 ... MSIX

Browser pane은 Electron 42 기반의 Chromium 148에서 동작하는 독립된 webview입니다. 공식 문서에는 Chromium 기반이라고만 명시되어 있어, 이 버전까지는 실기에서 직접 구동해 보기 전까지 알 수 없었습니다.

읽기 예시로, example.com을 read로 가져오면 다음과 같은 접근성 트리 (Accessibility Tree)가 반환됩니다.

heading "Example Domain" [ref_1]
generic "This domain is for use in documentation examples..." [ref_2]
link "Learn more" [ref_3] href="https://iana.org/domains/example"

요소마다 ref라는 번호가 부여되며, 이 번호를 지칭하여 클릭이나 입력을 할 수 있습니다. Wikipedia 기사에서는 이미지도 DOM으로부터 목록화할 수 있었고, fetch를 통해 첫 번째 이미지를 약 115KB의 바이트 배열 (Byte array)로 가져올 수 있었습니다. 텍스트와 DOM은 기사 본문을 통째로 읽을 수 있을 정도로 충분히 가져왔습니다. 읽기 측면에서는 정적인 페이지라면 부족함을 느끼지 못했습니다.

문제는 스크린샷입니다. 동일한 페이지에서 촬영을 시도하면 30초 만에 타임아웃 (Timeout)이 발생했습니다. 뷰포트 (Viewport) 크기를 다시 설정해 보아도, 3번을 시도해도 결과는 같았습니다. 에러로 거부되는 것이 아니라, 계속 기다리다 타임아웃이 된 것이었습니다.

이미지에 대해 보충하자면, Browser pane에는 이미지를 하나 선택해서 저장하는 식의 단일 조작은 없습니다. 페이지의 외관을 가져오는 정식 방법은 스크린샷이며, 현재 그 부분이 막혀 있습니다. 이미지를 데이터로서 얻고 싶다면 앞서 언급한 것처럼 직접 fetch를 실행하여 바이트 배열을 받는 방법도 있지만, 이는 기능이라기보다는 회피책에 가깝습니다.

스크린샷이 중단되는 이유

원인에 대한 단서는 테스트 과정에서 확인한 표시 상태에 있었습니다. 페이지는 항상 document.hidden = true, 즉 비표시 상태로 판정되었습니다.

여기서부터는 추측을 포함합니다. Chromium은 화면에 보이지 않는 페이지의 렌더링 (Rendering)을 중단합니다. 렌더링되지 않는 페이지에 스크린샷을 요청하면, 들어오지 않는 프레임 (Frame)을 계속 기다리게 됩니다. 에러가 아닌 타임아웃으로 종료된 것도 이로 설명이 가능합니다.

그렇다면 어떤 상황에서 비표시 상태가 되는가? Code 탭에서는 Browser pane이 채팅의 오른쪽에 나란히 배치되므로, 이 세션을 열어 보고 있는 동안에는 페인도 화면에 나타나야 합니다. 그 상태라면 촬영이 가능할 수도 있겠지만, 그 부분은 확실히 검증하지 못했습니다. 중단되는 상황은 다른 창이나 다른 세션을 전면에 띄워 놓아, 이 세션의 페인이 화면에서 벗어나 있을 때입니다. 에이전트에게 작업을 맡기고 사용자가 다른 일을 하는 상황일수록 이 상태에 빠지기 쉽습니다.

촬영 가능한 상태를 유지하려면 페인을 항상 오른쪽에 열어 두어야 하며, 그만큼 화면의 오른쪽 영역을 계속 점유하게 됩니다. 공식 문서에서는 스크린샷을 찍고 DOM을 확인하여 자동으로 검증한다고 설명하지만, 적어도 이번에 페인이 화면에 보이지 않는 조건에서는 그 시각적 기능이 작동하지 않았습니다.

Playwright와의 용도 구분

지금까지의 결과를 평소 브라우저 조작에 사용하는 Playwright와 비교하여 생각해 보겠습니다. Playwright에는 실제 브라우저와 직접 연결되는 모드와, 전용 브라우저를 띄우는 헤드리스 (Headless) 모드가 있습니다.

첫 번째는 로컬 개발 서버 (Local development server)의 프리뷰입니다. Claude Code는 앱을 편집한 후 개발 서버를 실행하고, 그 화면을 Browser pane에 띄워 사용자가 직접 확인하며 수정할 수 있게 합니다. 실행부터 표시까지 하나의 페인 (Pane)으로 연결해 주기 때문에, 프론트엔드 (Frontend) 수정을 보여주며 진행하고 싶을 때 매우 편리합니다.

두 번째는 설정이 필요 없다는 점과 깔끔함(Cleanliness)입니다. 확장 프로그램 연결도, 런타임 준비도 없이 즉시 열 수 있습니다. 로그인을 공유하지 않기 때문에, 로그인되지 않은 상태에서 사이트가 어떻게 보이는지 확인하고 싶을 때나, 자신의 실제 브라우저에 부작용 (Side effect)을 일으키고 싶지 않을 때도 적합합니다. Headless 모드의 Playwright로도 같은 일을 할 수 있지만, Browser pane은 아무런 준비도 필요하지 않습니다.

반대로 Playwright가 우세한 경우는 이미지나 스크린샷 (Screenshot)을 확실하게 찍어야 하는 작업, 로그인된 상태의 조작, 그리고 화면을 보지 않고 백그라운드에서 계속 돌리고 싶은 작업입니다. 이미지는 위에서 본 바와 같고, 로그인은 공식 측에서도 Claude in Chrome 확장 프로그램에 맡기고 있듯이 Browser pane의 클린 프로파일 (Clean profile)에서는 처리할 수 없습니다. 그리고 마지막 점으로, Browser pane은 화면에 띄워 놓지 않으면 스크린샷이 멈추기 때문에, 작업을 맡겨두고 다른 일을 진행하는 방식의 사용이 어렵다는 점이 대조적입니다.

마치며

Browser pane은 텍스트나 DOM을 읽는 용도라면 실제 기기에서도 충분히 사용할 수 있었습니다. 걸림돌이 되는 것은 스크린샷인데, 페인이 화면에 보이지 않으면 멈춘다는 점입니다. 외관 확인까지 맡기려면 페인을 화면에 계속 띄워 두어야 하므로, 백그라운드로 보내고 다른 작업을 하면서 맡기는 방식의 사용이 어렵습니다. 처음에 생각만큼 잘 활용하지 못했던 것도 이 이유라고 생각하면 앞뒤가 맞습니다.

그렇다고 해서 쓸모가 없는 것은 아닙니다. 로컬 개발 서버의 프리뷰를 보면서 수정할 때나, 준비 없이 깔끔하게 사이트를 열고 싶을 때는 화면에 띄워 사용하는 전제하에 간편하게 사용할 수 있습니다. 반대로 이미지를 확실히 찍어야 하거나 로그인된 상태로 조작하고 싶을 때는 Playwright나 Claude in Chrome 확장 프로그램이 적합합니다. 특히 작업을 맡겨두고 백그라운드에서 다른 일을 진행하고 싶다면, 화면을 보지 않고 동작할 수 있는 Headless 모드의 Playwright가 적합합니다. 저는 당분간 Playwright를 주력으로 사용하면서, 이 두 가지 상황에서만 Browser pane을 사용해 볼 생각입니다. 아직 출시된 지 얼마 안 된 기능이므로, 화면에 보이지 않는 상태에서도 스크린샷을 찍을 수 있게 된다면 그 활용 방법도 다시 검토하게 될 것입니다.

(출처: Desktop application / Claude Code changelog / Claude in Chrome / 9to5Mac (2026-07-10). 실제 기기 확인은 Claude Code 데스크톱 build 1.20186.1 시점)

Discussion