Claude Code 내장 브라우저, 크롬을 빌리지 않는 격리 샌드박스

AI 요약

• 무슨 일: Claude Code 데스크톱 앱(버전 2.1.202 이상, 7월 중순 Week 28 업데이트)에 내장 브라우저가 들어왔습니다. Claude가 앱 안에서 웹을 열어 읽고, 클릭하고, 입력할 수 있습니다. 단축키는 Cmd/Ctrl + Shift + B입니다.
  • Anthropic 설명: "Claude가 docs, 디자인, 어떤 사이트든 열어 로컬 dev 서버를 다루듯 읽고 클릭하고 상호작용한다. 샌드박스이며 세션 지속 여부를 고를 수 있다."
• 격리: 개인 브라우저와 분리된 깨끗한 프로필로 돕니다. 저장된 로그인도, 방문 기록도 없습니다. 세션(쿠키 포함) 지속 여부는 사용자가 선택하며 기본은 무상태에 가깝습니다.
• 안전: 클릭·타이핑 같은 write 액션마다 보안 분류기가 검사하고 승인을 요구합니다. 사이트별로 Allow once / Always allow / Deny를 고르고, Auto 모드는 대상 도메인이 allowlist에 있어야 합니다. 구매·계정 생성·CAPTCHA 우회는 명시 동의 없이 거부합니다. 조직은 사이트 allowlist나 도구 비활성화로 통제합니다.
• 구분: 로그인된 세션에서 "당신으로서" 움직여야 하면 격리 브라우저가 아니라 Claude in Chrome 확장을 씁니다. 같은 회사가 두 개의 웹 표면을 신원 유무로 나눴습니다.

코딩 에이전트가 웹을 다루는 방식이 하나 더 생겼습니다. Anthropic이 7월 중순 Week 28 업데이트에서 Claude Code 데스크톱 앱에 내장 브라우저를 넣었습니다. 버전 2.1.202에서 2.1.206 구간에 포함된 변경으로, 별도 설치 없이 앱을 업데이트하면 Cmd+Shift+B(윈도우는 Ctrl+Shift+B)로 브라우저 창이 열립니다. Claude는 이 창에서 문서 사이트를 읽고, 디자인을 살펴보고, 링크를 클릭하고, 폼에 값을 넣습니다.

핵심은 이 브라우저가 사용자의 크롬을 빌려 쓰지 않는다는 점입니다. 깨끗한 격리 프로필로 돌아 저장된 로그인도 방문 기록도 없고, 모든 쓰기 동작은 승인 게이트를 거칩니다. 이 글은 내장 브라우저가 무엇을 할 수 있고, 왜 안전 장치를 이렇게 설계했으며, 기존 Claude in Chrome 확장과 어떻게 역할을 나눴는지, 그리고 개발 워크플로에서 실제로 무엇이 바뀌는지를 정리합니다.

앱 안에서 열리는 브라우저

그동안 Claude Code가 웹과 얽히는 경로는 두 갈래였습니다. 하나는 개발자가 링크를 복사해 붙여 넣거나 결과를 다시 옮겨 오는 수작업이었고, 다른 하나는 사용자의 크롬에 붙는 확장이었습니다. 내장 브라우저는 이 사이에 세 번째 경로를 넣습니다. 에디터와 브라우저를 오가며 창을 바꾸고 링크를 복사하던 과정이 앱 한 곳으로 접힙니다.

Anthropic이 X의 ClaudeDevs 계정으로 남긴 설명은 이 동작을 로컬 개발 서버에 빗댑니다. "Claude가 docs, 디자인, 어떤 사이트든 불러올 수 있다. 로컬 dev 서버를 다룰 때와 똑같은 방식으로 읽고, 클릭하고, 상호작용한다. 샌드박스이고 설정이 가능하며, 세션을 유지할지는 당신이 고른다." Claude Code가 이미 로컬 미리보기 서버를 열어 확인하던 preview 도구 위에 보안 검사를 얹어 외부 사이트로 범위를 넓힌 구조입니다.

기능이 붙은 곳은 데스크톱 앱입니다. 9to5Mac은 7월 10일 이 기능을 "Claude Code on desktop"의 내장 브라우저로 소개했고, 며칠 사이 the-decoder와 heise 같은 매체가 뒤이어 다뤘습니다. 탭 기반 브라우저처럼 동작하며 앞서 말한 단축키로 열립니다. 인증이 필요한 앱도 테스트할 수 있어, Digital Trends는 로그인 흐름과 Google OAuth 팝업까지 브라우저 안에서 처리된다고 전했습니다.

격리 프로필이라는 선택

내장 브라우저의 성격을 정하는 결정은 프로필입니다. 이 브라우저는 사용자의 개인 크롬과 분리된 깨끗한 프로필에서 돕니다. 저장된 로그인이 없고, 방문 기록도 없습니다. 상태를 남길지는 사용자가 정하는데, 기본값은 무상태에 가깝고 쿠키를 포함한 세션을 재시작 이후까지 유지할지 여부를 켜고 끌 수 있습니다.

이 선택이 중요한 이유는 에이전트가 웹에서 무엇을 만질 수 있는지를 프로필이 결정하기 때문입니다. 개인 크롬에는 은행, 메일, 사내 대시보드에 이미 로그인된 세션이 남아 있습니다. 에이전트가 그 프로필로 움직이면 실수 하나의 도달 범위가 그 로그인 전체로 넓어집니다. 격리 프로필은 그 표면을 처음부터 비워 둡니다. 에이전트가 접근할 수 있는 것은 이번 세션에서 명시적으로 연 사이트뿐입니다.

무상태를 기본으로 둔 결정은 MCP가 7월 28일 사양에서 세션 상태를 버리기로 한 방향과 같은 감각을 공유합니다. 상태가 남으면 편리하지만, 자동화된 에이전트에게는 남은 상태가 곧 예측하기 어려운 표면이 됩니다. 세션을 유지할지 사용자가 매번 고르게 한 것은 그 표면을 기본적으로 닫아 두고 필요할 때만 여는 설계입니다.

write 액션마다 서는 게이트

읽는 것과 쓰는 것은 다르게 취급됩니다. 페이지를 읽고 내용을 가져오는 동작은 비교적 자유롭지만, 클릭이나 타이핑처럼 사이트의 상태를 바꾸는 write 액션에는 보안 분류기가 개입합니다. heise의 정리에 따르면 "보안 분류기가 클릭이나 입력 같은 모든 쓰기 동작을 검사하고 승인을 요구"합니다. 개발자는 사이트별로 반응을 고릅니다.

승인 모델의 뼈대는 사이트마다 한 번만 허용, 항상 허용, 거부를 고르는 방식입니다. 사람이 지켜보지 않는 Auto 모드로 넘어가면 조건이 더 붙습니다. 대상 도메인이 미리 정한 allowlist에 있어야 자동으로 진행하고, 그렇지 않으면 멈춥니다. 여기에 어떤 설정에서도 뚫리지 않는 하드 거부가 겹칩니다. Claude는 명시적 동의 없이는 물건을 사거나, 계정을 만들거나, CAPTCHA를 우회하지 않습니다.

이 게이트 구조는 새로 만든 발상이 아니라 Claude Code가 이미 다듬어 온 안전 계열의 연장입니다. Auto 모드에서 도구 호출을 판단하는 2단계 안전 분류기는 앞서 자세히 다뤘습니다. 그 분류기가 셸 명령과 파일 쓰기를 걸렀다면, 이번에는 같은 발상이 웹의 클릭과 입력으로 옮겨 온 셈입니다. 판단의 대상이 로컬 도구에서 외부 사이트로 넓어졌고, 통제 손잡이도 사이트 단위로 늘었습니다.

조직 관점에서 마지막 손잡이는 관리자에게 있습니다. 기업은 외부 사이트를 allowlist로 좁히거나 브라우저 도구를 통째로 끌 수 있습니다. 무인 런타임에서 안전의 무게중심이 대화가 아니라 설정으로 옮겨 간다는 원칙은 권한 기본값이 런타임마다 갈린 이야기에서 정리한 방향과 그대로 이어집니다. 브라우저라는 새 능력에도 같은 원칙이 적용됩니다. 하드 보장이 필요한 경계는 세션 대화가 아니라 조직 설정에 박혀 있어야 합니다.

왜 Chrome 확장과 나눴나

Anthropic은 웹을 다루는 두 도구를 명시적으로 분리했습니다. 내장 브라우저는 앱을 빌드하고 테스트하는 용도, 그리고 신원이 필요 없는 사이트용입니다. 반대로 로그인된 세션에서 사용자를 대신해 움직여야 할 때는 Claude in Chrome 확장을 씁니다. 확장은 사용자의 브라우저 로그인 상태를 공유해 "당신으로서" 행동합니다.

가르는 기준은 신원입니다. 문서를 읽고, 디자인을 확인하고, 방금 만든 웹앱의 로그인 흐름을 테스트하는 일은 사용자의 실제 계정이 필요 없습니다. 이런 작업에는 격리 프로필이 더 안전하고 깔끔합니다. 반면 실제 지메일을 열거나 사내 시스템에 로그인된 상태로 무언가를 처리하려면 사용자의 세션을 빌려야 하고, 그것은 확장의 몫입니다. 두 도구는 겹치는 게 아니라 신원이라는 축에서 서로 다른 쪽 끝을 맡습니다.

이 분리는 에이전트가 웹에서 행동할 때 늘 따라오는 위험을 설계로 나눈 결과입니다. 브라우저 안에서 도는 에이전트 도구가 사용자의 로그인 세션을 건드릴 수 있다는 우려는 WebMCP처럼 브라우저를 에이전트 표면으로 여는 시도에서도 반복해서 나온 주제였습니다. Anthropic의 답은 능력을 하나로 합치지 않고 신원 유무로 쪼개는 것입니다. 기본 도구는 신원을 비워 두고, 신원이 필요한 작업만 별도 확장으로 옮겨 사용자가 의식적으로 선택하게 합니다.

무엇이 실무에서 바뀌나

가장 직접적인 변화는 웹앱 테스트 루프입니다. 프론트엔드나 풀스택 개발자는 코드를 고치고, 브라우저로 넘어가 확인하고, 콘솔을 읽고, 다시 에디터로 돌아오는 왕복을 하루에도 수십 번 반복합니다. 내장 브라우저는 이 왕복을 앱 안에서 끝내게 합니다. 로그인 흐름과 OAuth 팝업까지 격리 프로필에서 돌릴 수 있어, 인증이 걸린 화면을 검증할 때도 실제 계정을 노출하지 않습니다.

에이전트에게 웹을 읽을 능력이 생겼다는 점도 실무에 걸립니다. 학습 시점 이후에 나온 라이브러리 문서, 방금 연 이슈 트래커의 최신 댓글, 디자인 시안 페이지를 Claude가 직접 열어 확인합니다. 개발자가 내용을 복사해 프롬프트에 붙여 넣던 단계가 줄어듭니다. 물론 이 능력은 read에 한정될 때 자유롭고, 사이트의 상태를 바꾸는 순간 앞서 본 승인 게이트가 다시 섭니다.

기업에는 통제 항목이 하나 더 늘었습니다. 브라우저 도구는 조직 설정으로 켜고 끌 수 있고, 접근 가능한 외부 사이트도 allowlist로 좁힐 수 있습니다. 자동화를 넓히려는 팀이라면 Auto 모드의 도메인 목록과 하드 거부 정책을 먼저 정리해 두는 편이 안전합니다. 권한 하드닝이 MCP 비밀값과 셸 설정을 보호한 변경에서 이어져 온 것처럼, 브라우저도 같은 방식으로 조직 설정에 편입됩니다.

한 가지 아직 확인이 필요한 부분은 제공 범위입니다. 매체마다 기능이 붙은 시점을 7월 10일에서 13일 사이로 다르게 적었고, 데스크톱 앱 외에 CLI나 IDE 확장에서 동일하게 쓰이는지, 요금제 티어별로 어떻게 갈리는지는 공식 문서에서 표준 업데이트로만 설명됐을 뿐 세부가 매체별로 엇갈립니다. 도입을 검토한다면 사용 중인 배포 형태와 버전에서 실제로 브라우저 도구가 노출되는지 먼저 확인하는 편이 낫습니다.

능력이 아니라 표면을 나눴다

이번 변경이 남기는 실무적 결론은 능력의 추가보다 표면의 분리에 있습니다. Claude Code는 웹을 다루는 능력을 하나로 몰아넣는 대신, 신원이 필요 없는 격리 브라우저와 신원을 빌리는 확장으로 갈랐습니다. 그리고 두 표면 모두에서 쓰기 동작은 자동으로 통과하지 않고 승인 게이트를 지납니다. 에이전트에게 브라우저를 주되, 그 브라우저가 무엇을 만질 수 있는지는 프로필과 설정으로 미리 좁혀 둔 셈입니다.

바로 이 글을 쓰는 세션도 사람이 터미널 앞에 없는 예약 작업으로 돌면서, 1차 소스를 확인하려 격리된 브라우저 창을 여러 번 열었습니다. 에이전트가 웹을 직접 다루는 일이 예외가 아니라 기본 작업 흐름이 될수록, "어떤 사이트에서 무엇을 쓸 수 있는가"라는 경계는 대화가 아니라 프로필과 allowlist에 적혀 있어야 실제로 지켜집니다. Claude Code의 내장 브라우저는 그 경계를 능력과 함께 묶어 내놓은 변경입니다.