Claude Code를 실제 브라우저 안에서 동작하게 만들고 싶다면 필요한 기능 이름은 Claude in Chrome입니다. 공식 확장을 설치하고 Chrome 창을 보이는 상태로 열어 둔 뒤, claude --chrome 으로 Claude Code를 시작하거나 이미 열린 세션 안에서 /chrome 을 실행하면 됩니다. 이 경로의 핵심 가치는 “Claude가 웹을 클릭할 수 있다”가 아닙니다. Claude Code가 이미 로그인되어 있는 당신의 실제 브라우저 상태를 그대로 쓸 수 있다는 점입니다. 그래서 localhost, 로그인 뒤에만 보이는 대시보드, 실제 화면에서만 드러나는 폼 흐름에 특히 의미가 있습니다.
이 경로는 브라우저 상태 자체가 문제의 핵심일 때 써야 합니다. localhost 테스트, 로그인된 관리자 화면 점검, 반복적인 browser QA, 페이지 관찰과 오류 위치 확인 같은 작업은 잘 맞습니다. 반대로 connector, 로컬 파일, API가 이미 더 깔끔하게 문제를 풀어 준다면 굳이 브라우저까지 올릴 이유가 없습니다. 안전하게 쓰는 가장 좋은 방법도 결국 위험한 동작은 사람 확인 아래에 남기는 것입니다.
“근거 메모: 이 글은 Anthropic의 현재 Claude Code Chrome 문서, Claude in Chrome 시작 가이드, 권한 안내, 안전 가이드를 바탕으로 정리했으며 2026년 4월 7일에 다시 확인했습니다.
먼저 놓치기 쉬운 전제만 짚고 가겠습니다.
- Anthropic의 현재 문서 기준으로 Claude Code
2.0.73+, Claude in Chrome 확장1.0.36+, 그리고 직접 Anthropic 구독 또는 Anthropic API key가 필요합니다. - Claude Code 문서는 현재 Chrome과 Edge를 적고 있지만 help center 설명은 여전히 Chrome 중심입니다. 첫 연결은 Chrome을 기준선으로 잡는 편이 가장 안전합니다.
- 브라우저 창은 보이는 상태로 유지되어야 하며, 로그인, 2FA, CAPTCHA가 나오면 Claude는 멈추고 사람을 기다립니다.
- 확장에는 브라우저 권한이 필요하고 Anthropic의 permissions guide는 일부 high-risk 작업은 덜 자주 묻는 모드에서도 여전히 확인이 필요하다고 말합니다.
이 경로는 정확히 무엇에 쓰는가
어려움의 본체가 브라우저 상태라면 이 경로를 먼저 시도해야 합니다. 중요한 것은 “Claude가 클릭할 수 있다”는 사실이 아닙니다. 중요한 것은 Claude Code가 당신이 이미 신뢰하고 있는 브라우저 세션을 빌려 쓸 수 있다는 점입니다. 이미 로그인된 사이트, 로컬에서 띄워 둔 앱, 실제 렌더링 결과가 진실인 화면, 추상 코드보다 브라우저에서 확인하는 쪽이 빠른 작업이 여기에 해당합니다.
그래서 이 페이지는 더 넓은 computer use 이야기보다 좁아야 합니다. 거기서는 누가 실행 환경을 소유하는지, 언제 더 높은 화면 제어가 필요한지, 데스크톱 수준 위임이 맞는지 같은 문제가 중심입니다. 여기서는 질문이 훨씬 실무적입니다. Claude Code 안에서 브라우저를 어떻게 연결하고 어디까지 믿을 것인가. 확장은 다리일 뿐이고 주제는 아닙니다. 주제는 언제 실제 브라우저가 가장 짧고 안전한 경로가 되는가입니다.
이름 혼란도 한 번만 바로잡으면 됩니다. 많은 사람이 “Claude Chrome”처럼 검색하지만 실제로 원하는 것은 “Claude Code를 브라우저 문맥에 넣고 싶다”는 것입니다. Anthropic의 공식 이름은 Claude in Chrome입니다. 이 이름만 바로잡고 나면 실무는 단순합니다. 확장을 설치하고, Claude Code에서 연결하고, 작은 실제 브라우저 작업으로 먼저 확인한 뒤에 범위를 넓히면 됩니다.
만약 당신에게 정말 필요한 것이 CLI 전체 설치 안내라면 Claude Code 설치 가이드 로 가는 편이 맞습니다. 브라우저 경로와 더 넓은 실행면을 비교하고 싶다면 Claude Computer Use 가이드 가 더 적절합니다. 이 글은 브라우저 경로 자체에 집중해야 합니다.
5분 안에 연결하기
공식 설정은 검색어가 주는 느낌보다 훨씬 단순합니다. 서로 관련 없어 보이는 두 제품을 억지로 묶는 것이 아닙니다. Anthropic의 공식 브라우저 브리지를 켜고 Claude Code에서 그 브리지에 연결하는 것입니다. 첫 실패의 원인은 대개 다섯 가지 안에 들어갑니다. 지원되지 않는 브라우저, 오래된 버전, 잘못된 과금 경로, 빠진 권한, 또는 브라우저를 완전히 headless 대상처럼 숨겨 둘 수 있다고 생각하는 경우입니다.
-
실제로 쓰는 브라우저 프로필에 공식 Claude in Chrome 확장을 설치합니다. Anthropic help center는 Claude in Chrome이 유료 Claude 플랜에서 제공된다고 설명합니다. Claude Code 문서는 여기에 한 가지를 더합니다. CLI 안의 브라우저 통합은 현재 직접 Anthropic 구독 또는 Anthropic API key가 필요합니다. 제3자 provider 경로로 Claude Code를 쓰는 경우 Anthropic은 이 브라우저 경로를 현재 지원된다고 보지 않습니다.
-
연결하기 전에 브라우저와 버전 하한을 확인합니다. 2026년 4월 7일 기준으로 Claude Code 문서는 Google Chrome과 Microsoft Edge를 적고 있지만 help center는 여전히 Chrome-first 톤입니다. Anthropic은 현재 Claude Code
2.0.73+와 확장1.0.36+도 요구합니다. 실무적으로는 첫 시도를 Chrome에서 하는 것이 가장 깔끔합니다. Edge는 문서상 지원되지만 조금 더 조건부인 두 번째 경로로 생각하는 편이 맞습니다. Brave, Arc, WSL은 Anthropic이 현재 지원하지 않는다고 적어 두고 있습니다. -
브라우저를 열어 둔 채 Claude Code에서 연결합니다. 가장 빠른 시작은 다음 둘 중 하나입니다.
bashclaude --chrome
이미 Claude Code 세션 안에 있다면,
text/chrome
Anthropic은 이 통합이 기존 브라우저 상태를 공유한다고 설명합니다. 바로 그 점이 핵심 가치입니다. 동시에 브라우저를 완전히 안 보이는 자동화 타깃처럼 다룰 수 없다는 뜻이기도 합니다. 로그인, 2FA, CAPTCHA가 나오면 Claude는 멈추고 사람이 처리할 때까지 기다립니다.
- 처음에는 작은 검증 작업 하나만 돌립니다. 먼저 경로가 살아 있는지 확인하고, 그다음 더 큰 작업으로 넘어가야 합니다. 첫 확인으로는 다음 같은 지시가 좋습니다.
textOpen http://localhost:3000, click through the signup flow, and tell me where the first validation error appears.
이 한 문장으로 세 가지를 동시에 확인할 수 있습니다. Claude가 브라우저를 실제로 보고 있는지, 브라우저 상태가 usable한지, 그리고 이 경로가 정말 당신의 문제를 해결하고 있는지입니다. localhost나 로그인된 대시보드의 작은 작업조차 제대로 안 된다면, 더 큰 일을 맡기기 전에 설정부터 고쳐야 합니다.
help center에는 또 하나의 실무적인 차이가 있습니다. 확장 쪽에서 보이는 모델 선택지는 플랜에 따라 다릅니다. Pro는 지금 더 제한적이고 Max, Team, Enterprise는 더 넓습니다. 이것이 Claude Code 쪽 연결 절차를 바꾸지는 않지만 브라우저 UI에서 왜 모델 선택이 다르게 보이는지 설명해 줍니다.
Claude Code에서 브라우저를 쓸 때 특히 잘 맞는 작업
브라우저 경로를 써야 하는 시점은 브라우저가 사실상의 시스템 오브 레코드일 때입니다. 많은 개발자에게 가장 흔한 형태는 네 가지입니다.
첫 번째는 localhost 테스트입니다. 버그가 브라우저에서만 보이고, 폼이 실제로 어떻게 반응하는지 봐야 하고, 클릭 흐름의 어디에서 깨지는지 확인해야 하는 상황입니다. Claude Code는 파일을 고치고 테스트를 돌릴 수 있어도 브라우저가 실제로 어떻게 렌더링되는지는 직접 볼 수 없습니다. Claude in Chrome이 그 빈칸을 채웁니다.
두 번째는 로그인된 대시보드나 내부 도구입니다. 문제가 코드 실행이 아니라 인증 상태에 있다면 이 경로는 아주 자연스럽습니다. 로그인 뒤에만 가치가 생기는 페이지에서는 이미 살아 있는 브라우저 세션을 그대로 쓰는 것이 가장 빠른 길입니다.
세 번째는 빠른 browser QA입니다. 반복 클릭, 시각적 spot check, “이 변경이 진짜 기대한 대로 동작했나?” 같은 질문은 실제 페이지에서 하는 편이 빠릅니다. 여기서 경계도 분명합니다. 완전한 end-to-end 자동화 인프라가 필요하다면 그것은 다른 공학 문제입니다. 하지만 지금 코딩 세션 안에서 build, test, verify 루프를 짧게 만들고 싶다면 브라우저 경로는 아주 강합니다.
네 번째는 페이지 관찰과 추출입니다. 일이 꼭 페이지를 조작하는 것은 아닐 수 있습니다. 대시보드 요약, 오류 위치 확인, 렌더링된 DOM 상태 관찰, 화면에 보이는 구조화 정보 추출도 모두 여기에 들어갑니다. 페이지 자체가 진실이라면 그것을 직접 보는 편이 번역 비용이 적습니다.
하지만 이 경로는 웹이 들어간다는 이유만으로 모든 작업의 기본 답이 되면 안 됩니다. Connector가 있으면 connector를 먼저 쓰고, 답이 로컬 파일이나 빌드 산출물에 있으면 그 경로에 머무르는 편이 낫습니다. 이미 API가 있는 시스템이라면 UI 자동화보다 API가 보통 더 좋은 엔지니어링 선택입니다. 브라우저 경로가 강한 이유는 아래 단계에서 지울 수 없는 마찰을 지울 때이지, 더 그럴듯해 보이기 때문이 아닙니다.
권한, 안전 경계, 그리고 언제 사람 손을 유지해야 하는가
민감한 사이트에서 쓰기 전에 확인 경계와 prompt injection 위험을 이해해야 합니다. Anthropic의 permissions guide는 Claude in Chrome이 “매번 물어보고 실행”할 수도 있고 “덜 자주 물으며 진행”할 수도 있지만, 일부 high-risk 작업은 여전히 확인을 요구한다고 설명합니다. 이것이 “agent mode를 켜면 다 맡길 수 있다”는 식의 과장보다 실제에 훨씬 가깝습니다.
Anthropic의 setup과 safety guidance는 사람의 경계도 분명히 합니다. Claude는 당신의 실제 브라우저 세션을 씁니다. 그래서 유용합니다. 동시에 그만큼 브라우저 표면의 위험도 함께 가져옵니다. 로그인, 2FA, CAPTCHA가 나오면 Claude는 멈춥니다. 이것은 버그가 아니라 의도된 제어선입니다.
Anthropic이 가장 강조하는 기술적 위험은 prompt injection 입니다. 페이지 안의 텍스트가 모델을 원래 작업에서 벗어나게 만들 수 있습니다. 브라우저는 제3자 콘텐츠를 그대로 보여 주기 때문에 repo 작업보다 더 조심해야 합니다. Anthropic은 민감한 브라우징에 대해 별도 프로필 사용도 권합니다. 합리적인 조언입니다. 메일, 돈, 관리자 권한, 중요한 승인 같은 authority를 다루는 화면이라면 blast radius가 데모보다 훨씬 크다고 보는 편이 맞습니다.
가장 단순한 안전 규칙은 Anthropic의 더 넓은 제품 논리와도 같습니다. 문제를 해결할 수 있는 가장 낮은 제어 경로를 선택하라 는 것입니다. Connector가 있으면 먼저 connector, 답이 파일에 있으면 repo, 브라우저 상태가 진짜 병목일 때만 브라우저. 거기서 더 넓은 computer use 쪽으로 가고 싶어지는 순간에는 정말 그 제어 수준이 필요한지 한 번 더 생각해야 합니다.
연결이 안 되거나 중간에 멈출 때 먼저 볼 것
대부분의 설정 문제는 겉보기보다 작습니다. 경로 자체가 깨진 것이 아니라 전제 하나가 빠진 경우가 훨씬 많습니다.
/chrome 이 브라우저를 찾지 못하면 가장 먼저 계약 불일치를 의심합니다. 확장이 지금 열린 그 브라우저 프로필에 설치되어 있는지, 창이 보이는지, Claude Code가 2.0.73+ 인지, 확장이 1.0.36+ 인지 확인합니다. WSL, Brave, Arc, 제3자 provider 경로라면 Anthropic의 현재 문서 시점에서 이미 지원 범위 밖입니다.
브라우저는 열리는데 페이지에서 할 수 있는 일이 거의 없다면 먼저 권한을 봅니다. Help center는 nativeMessaging, debugger, 그리고 대상 사이트의 host permissions가 필요하다고 말합니다. 페이지는 보이는데 경로가 “눈이 멀었거나 손이 묶인 것처럼” 느껴진다면, 깊은 버그보다 권한 부족일 확률이 더 큽니다.
로그인, 2FA, CAPTCHA에서 멈추는 것은 예상된 동작입니다. Anthropic 문서는 이 워크플로가 기존 세션을 공유하고 사람이 해야 하는 단계에서 멈춘다고 분명히 말합니다. 그 부분을 직접 처리하고 다시 이어 가면 됩니다.
Edge에서 테스트할 때는 성공의 의미를 조금 더 제한적으로 봐야 합니다. Claude Code docs는 Microsoft Edge를 적고 있지만 help center는 아직 Chrome 중심입니다. 뜻은 간단합니다. 첫 troubleshooting baseline은 Chrome에 두고, Edge 차이는 브라우저 표면 문제로 다루는 편이 맞습니다.
설정 문제인지 계정 자격 문제인지 헷갈리면 질문을 둘로 나눕니다. 확장 자체는 현재 help center 기준 유료 Claude 플랜에서 제공됩니다. 반면 Claude Code 안의 브라우저 통합은 직접 Anthropic billing path도 필요합니다. 확장은 설치된 것 같은데 CLI 쪽에서 계속 거부된다면 브라우저 플래그보다 먼저 계정 경로를 확인하는 편이 낫습니다.
이 확인들을 해도 여전히 답이 안 보인다면, 보통은 이 글 안에서 더 깊게 파기보다 옆 글로 이동하는 쪽이 맞습니다. CLI 전체 setup과 update는 Claude Code 설치 가이드 로, 브라우저가 정말 맞는 실행면인지 더 넓게 보려면 Claude Computer Use 가이드 로 가는 편이 낫습니다.
FAQ
Claude in Chrome이 broad computer use를 대체하나요
아닙니다. Claude Code 안에서 브라우저 경로는 더 좁은 작업면입니다. 가치가 있는 이유도 바로 그 점입니다. 브라우저 상태가 중요할 때만 쓰고, connector, 파일, API가 더 적절하다면 그쪽이 기본 답이어야 합니다.
어떤 플랜과 모델이 필요한가요
Anthropic help center는 Claude in Chrome이 유료 플랜 대상이라고 설명하고, 모델 선택이 플랜에 따라 달라진다고도 적습니다. Claude Code docs는 별도로 CLI 통합에 직접 Anthropic 구독 또는 Anthropic API key가 필요하다고 적고 있습니다. 안전한 짧은 답은 이렇습니다. 확장 쪽은 유료 Anthropic 접근, Claude Code 안의 브라우저 통합은 직접 Anthropic 과금 경로, 브라우저 UI에서 보이는 모델은 플랜 의존입니다.
Microsoft Edge에서도 되나요
현재 Claude Code 문서 기준으로는 됩니다. 다만 help center의 설치 설명은 아직 상당히 Chrome 중심입니다. 그래서 Chrome을 기본 지원 경로로 보고 Edge는 docs-backed이지만 조금 더 조심해서 다뤄야 하는 경로로 보는 편이 안전합니다. 그리고 Edge가 적혀 있다고 해서 Brave나 Arc까지 자동으로 포함된다고 생각하면 안 됩니다. Anthropic의 현재 문서는 그렇지 않습니다.
왜 로그인이나 CAPTCHA에서 멈추나요
이 경로가 당신의 실제 브라우저 세션을 재사용하면서도 사람만 해야 하는 단계는 빼앗지 않도록 설계되어 있기 때문입니다. Anthropic 문서는 로그인, 2FA, CAPTCHA에서 Claude가 멈춘다고 명시합니다. 그 부분을 직접 처리한 뒤 계속하면 됩니다.
민감한 사이트에서 써도 되나요
조심해서 써야 합니다. Anthropic의 안전 가이드는 prompt injection을 가장 큰 기술적 위험으로 보고 민감한 브라우징에 대해 추가 주의와 별도 프로필 사용을 권합니다. 돈, 관리자 권한, 중요한 승인, 고가치 계정을 다루는 작업이라면 사람을 루프 밖으로 빼지 않는 편이 낫습니다.
Claude in Chrome이 가장 유용한 순간은 브라우저가 코드와 현실 사이의 빠진 한 층이 될 때입니다. 강한 워크플로지만 좁게 써야 합니다. 공식 확장을 설치하고, Claude Code에서 연결하고, 먼저 실제 브라우저 작업 하나로 검증한 뒤 localhost, 로그인된 페이지, 브라우저 확인 작업에 집중해서 쓰는 것이 가장 좋습니다. 브라우저가 더 이상 필요하지 않은 순간에는 더 단순한 경로로 기꺼이 내려오는 편이 맞습니다.