Claude Code와 실제 Chrome을 연결하여 웹 출력을 구현하는 방법

1. list_connected_browsers … 연결된 실제 Chrome을 확인 (deviceId를 얻음)
2. select_browser {deviceId} … 대상 Chrome 선택
3. tabs_context_mcp {createIfEmpty: true} … 작업용 탭 확보

4. navigate {url} … 대상 탭에서 페이지 열기
5. get_page_text … 렌더링된 본문을 일반 텍스트로 가져오기
(구조나 입력란이 필요할 때는 read_page {filter: 

URL만 바꿔 넣는 것이 가볍습니다. 대화가 바뀔 때마다 새 탭을 만들면 탭이 무한정 늘어납니다.
- **에디터 제목 자동 서식 지정은 시킬 수 없습니다.** 이건 실수였습니다. 웹 에디터에서 스타일을 적용하는 작업은 줄 범위 선택(`triple_click` 등)을 동반하며, 좌표가 한 줄이라도 어긋나면 **다른 단락까지 끌어와 본문을 망칩니다**. '한 줄만 틀어져도 파괴적'인 작업은 AI에게 맡기지 않고 사람의 손에 남겨두는 것이 결국 가장 안전했습니다.

## 안전 설계 — 읽기는 즉시, 쓰기는 인간의 승인

실제 Chrome은 자신의 로그인 권한 그 자체로 작동합니다. 그렇기에 작업을 분리했습니다.

- **읽기**: 사용자 확인 없이 실행해도 좋음 -
- **쓰기 확정** (저장/공개/게시/전송): 되돌리기 어렵기 때문에, 내용을 제시하고 **명시적인 승인을 받은 후에만** -
- **로그인/인증/비밀번호 입력**: AI는 하지 않습니다. 끊겼다면 사용자 자신이 로그인해야 합니다 -
- **보여서는 안 되는 탭을 끌어들이지 않음**: 자신에게 보이는 것은 모두 보인다는 의미입니다. 작업용 탭에 닫습니다.

요컨대, '읽기는 AI가, 쓰기 확정은 인간이'. 이 선을 긋는 것만으로도 실제 브라우저 조작의 위험성은 상당히 줄일 수 있습니다.

### 여전히 남는 네 가지 의문점

이 구성을 사람에게 이야기하면 대개 같은 질문들을 받습니다.

'자신의 로그인 권한을 AI에게 사용하게 해도 괜찮은가?'

전제 조건을 4가지 세우고 있습니다. 읽을 수 있는 것은 우리가 제시한 사이트뿐이며, Chrome의 모든 탭을 마음대로 훑어보는 것이 아니라는 점. 브라우저는 눈앞에서 움직이고, 무엇을 하고 있는지 화면에 계속 표시된다는 점. 그리고 접근할 범위는 애초에 자신이 그 권한으로 볼 수 있는 범위를 벗어나지 않는다는 점. 게다가 사용하고 있는 AI 에이전트가 조직의 계약으로서 학습에 사용하지 않음을 보장받고 있다는 점.

그 위에서, 유출 위험과 업무 품질을 저울질했습니다. 얻는 것에 비해 위험은 작다는 판단입니다. 반대로 말하면, 이 4가지 중 어느 하나라도 무너지는 환경에서는 같은 판단을 내리지 않을 것입니다.

'API가 있다면 API를 사용하면 되지 않나?'

API가 있다면 사용합니다. 이 수단이 필요한 경우는 API가 공개되지 않은 서비스를 상대할 때거나, 실제 데이터베이스로 가는 경로가 복잡해서 그 깊이까지 파고드는 비용이 목적에 맞지 않을 때입니다.

원하는 것이 화면에 표시된 텍스트, 예를 들어 지시문이나 조사 결과 그 자체만이라면, 보이는 화면을 읽는 것이 더 빠르고 저렴합니다. 데이터의 정본(正本)이 필요한 작업과, 표시된 정보로 충분한 작업을 나누어 생각하고 있습니다.

'무엇을 했는지 나중에 추적할 수 있는가?'

에이전트 측 지시에, 무엇을 했는지/왜 했는지를 제시하도록 과정을 구성했습니다. 채팅에서 답변의 근거를 되묻는 것과 같은 발상으로, 조작 전후에 확인 게이트를 두는 형태입니다.

브라우저 측 조작 로그에 의존하기보다, 지시 설계로 보장하는 것입니다. 여기는 시스템으로 고정했다기보다는 운영으로 성립시키고 있는 부분입니다.

'확장의 사양이 바뀌면 멈추지 않을까?'

멈추지 않습니다. 이 방법은 사람의 손 대체 범위에 속하기 때문에, 작동을 멈추게 되면 그 작업을 사람이 직접 해야 할 뿐입니다. 업무 자체가 멈추는 것은 아닙니다.

멈추고 싶지 않다면, 스크레이핑 스크립트를 짜서 유지하는 방법도 있습니다. 다만 그것은, 멈출 위험과 유지 비용을 저울질하는 문제가 됩니다. 현재로서는 대체 수단을 가지지 못한 쪽에 무게가 실리고 있습니다.

## 학습

'탑승(相乗り)'은 인증의 벽을 넘는 범용 패턴입니다. 특정 SaaS에 국한되지 않고, 로그인이 필요한 모든 웹 서비스에 응용할 수 있습니다. 인증을 대행시키지 않는 것이 핵심이며, 이를 통해 '인증은 사용자, 조작은 AI'라는 책임 분계가 자연스럽게 결정됩니다.

그리고, **입력보다 출력을 자동화했을 때 효과가 급상승했습니다**. 에이전트의 고속화는 입력 측면(재료 수집)에 시선이 쏠리기 쉽지만, 출력 측면을 같은 세션에 배치하면 지식이 정체되지 않습니다.

한편으로는, 위험한 조작을 의도적으로 사람에게 남겨두는 것이 안전하게 진행하는 비결이라고 생각합니다. 모든 것을 자동화하려 하기보다, '한 줄만 틀어져도 망가지는' 종류의 작업은 경계 밖에 두는 것입니다. 이 경계를 어떻게 일반화할 수 있을지는 아직 언어화하지 못했습니다. 현재로서는 '파괴가 불가역적인지 여부'로 판단하고 있지만, 좀 더 좋은 기준이 있을 것 같습니다.

## 요약

- Claude Code에는 '내장 격리 브라우저'와 '실제 Chrome을 조작하는 확장' 두 계통이 있으며, 로그인 필수 사내 웹에는 후자가 적합합니다.
- 연결은
`list_connected_browsers`
→`select_browser`
→`tabs_context_mcp`
의 3가지로 확인하고, 나머지는 `navigate`

+\`get_page_text\`

/`form_input`

으로 읽고 쓰기한다. - 
`deviceId`

/`tabId`

은 매번 확인하고, 탭은 재사용하며, 제목 형식 지정 등 파괴적인 작업은 사람에게 남긴다. - 읽기는 즉시, 쓰기의 확정은 인간의 승인. 이 경계에서 안전하게 운영할 수 있다.

본 기사는 Stock Tech Blog의 글입니다. 주식회사 Stock은 팀 정보를 가장 쉽게 관리할 수 있는 Stock과, 지식을 키워 기업 잠재력을 개방하는 나레칸(ナレカン)이라는 두 제품을 개발하고 있습니다.

함께 개발할 엔지니어를 찾고 있습니다 → 채용 정보

저자: 타케다 슌이치(@Shunichi-Takeda／주식회사 Stock CTO)

### Discussion

![](https://static.zenn.studio/images/drawing/discussion.png)