에이전트 브라우저 자동화, MCP 실패 후에만 쓸까

에이전트 브라우저 vs MCP를 고를 때 기본값은 커넥터(MCP) 먼저입니다. 구조화된 도구 호출이 가능하면 DOM 클릭·스크린샷 루프보다 재현·권한이 단순합니다. 브라우저는 MCP가 없거나 실패한 뒤, 또는 화면 검증이 목표일 때만 폴백합니다. Cursor의 Browser도 내부적으로 MCP 도구로 노출되지만, 이 글의 “브라우저”는 navigate·click·type·screenshot 같은 UI 자동화 축을 말합니다.

다루는 것은 세 가지입니다. MCP를 먼저 쓰는 이유 · 브라우저로 넘어갈 신호 · 로그인/2FA 핸드오프. 요금·플랜·토큰 숫자는 다루지 않습니다. 로그인·2FA 우회나 발명한 UI 클릭 경로도 없습니다.

MCP를 먼저 쓰는 이유는?

한 줄 답: MCP(커넥터)는 스키마가 있는 도구로 외부 시스템과 붙습니다. 권한·감사·실패 격리가 UI 자동화보다 명확하고, DOM 스냅샷·스크린샷으로 컨텍스트를 태우지 않습니다.

Cursor 문서 기준으로 MCP는 Tools·Resources·Prompts 등을 노출하고, mcp.json 또는 Customize에서 서버를 켜고 끕니다. 채팅의 Available Tools에 뜨면 관련 작업에 쓰이며, 도구 승인과 Run Mode(예: Auto-review 시 allowlist)를 따릅니다. 서버가 죽거나 타임아웃해도 해당 호출만 실패하고 다른 MCP는 계속 동작합니다.

축	MCP(커넥터)	브라우저 UI 자동화
입력·출력	이름 있는 인자·구조화 응답	DOM/스크린샷·콘솔·네트워크 로그
권한	OAuth·스코프·엔터프라이즈 allowlist	탭·쿠키·origin allowlist(엔터프라이즈)
재현	같은 도구 이름·인자로 반복	레이아웃·카피·A/B에 민감
실패	서버/도구 단위로 고립	한 번의 잘못된 클릭이 세션을 꼬기 쉬움
적합한 일	이슈 조회, Drive 파일, Slack 검색 등 API형	로컬 UI 검증, 접근성, 시각 회귀

커넥터 우선이 맞는 예

공식·팀 MCP가 이미 있다 — Jira·Confluence·Drive·Slack처럼 읽기/쓰기가 도구로 정의된 경우.
감사·최소 권한이 필요하다 — 스코프·도구 allowlist로 “무엇을 호출했는지”를 남기기 쉽습니다.
결과가 데이터다 — 이슈 본문·파일 메타·검색 히트처럼 구조화가 목표인 경우.

브라우저를 맨 앞에 두면, 같은 Slack/Drive 작업을 로그인 화면·메뉴 탐색·셀렉터 추측으로 다시 발명하기 쉽습니다. 커넥터가 있으면 그쪽을 먼저 고칩니다(연결·인증·스코프·멤버십).

에이전트 규칙 한 줄 예시:

Prefer configured MCP/connectors for external systems (issue trackers, Drive, Slack, etc.).
Use browser UI automation only after MCP is missing, unauthorized, or failed — or when the goal is visual/UI verification.
Never invent click-paths to bypass login or 2FA; hand those to a human.

브라우저로 넘어갈 신호는?

한 줄 답: 커넥터가 없거나 호출이 실패했고, 목표가 화면·콘솔·네트워크로만 확인될 때 브라우저로 갑니다. “MCP가 느리다”만으로는 부족합니다. 먼저 로그·인증·도구 이름을 확인합니다.

Cursor Browser는 별도 외부 설치 없이 에이전트가 페이지를 열고, 클릭·입력·스크롤·스크린샷·콘솔·(에이전트 패널) 네트워크를 볼 수 있습니다. 서브에이전트 문서에서도 Browser는 DOM·스크린샷 노이즈가 커서 분리된 경로로 다루는 이유로 설명합니다. 즉 브라우저는 강력하지만 컨텍스트 비용이 큰 도구입니다.

신호	브라우저 폴백?	먼저 할 일
해당 서비스 MCP가 목록에 없음	예(목표에 UI가 필요하면)	Customize/`mcp.json`에 커넥터가 있는지 확인
MCP 도구 실패·타임아웃·needsAuth	조건부	Output → MCP Logs, 재인증, 서버 on/off
로컬 dev 서버 UI 검증	예	포트·이미 떠 있는 서버 재사용(문서의 dev-server 인식)
접근성·시각·콘솔 에러 점검	예	`@browser`로 대비·ARIA·키보드·콘솔
이슈/파일 API로 충분한 읽기	아니오	커넥터 도구만
SSH/원격에서 브라우저 도구가 안 붙음	환경 이슈	로컬 워크스페이스·팀 정책·문서된 제한을 확인. 우회 클릭 경로 발명 금지

폴백 순서(실무)

목표를 한 줄로 — “이슈 본문 읽기” vs “로그인 후 대시보드 스크린샷”.
Available Tools에서 커넥터 검색 — 있으면 MCP만으로 시도.
실패 시 원인 분류 — 미설치 / 인증 / 스코프·멤버십 / 서버 크래시. UI로 우회하지 않고 커넥터를 고칩니다.
그래도 안 되거나 UI가 목표 — Browser(또는 팀 허용 브라우저 MCP)로 전환. 승인 모드를 유지한다(문서 기본: 브라우저 도구는 승인 필요).
성공해도 규칙에 기록 — “이 작업은 브라우저 폴백”을 progress/규칙에 남겨 다음 세션이 커넥터부터 다시 헤매지 않게 합니다.

엔터프라이즈에서는 브라우저 기능·origin allowlist가 MCP Configuration 아래로 묶입니다. 에이전트 자동 browser_navigate는 allowlist origin만, 사람이 수동으로 연 비허용 origin에서는 클릭·입력이 막힐 수 있습니다. 폴백 설계에 정책 경계를 넣습니다.

로그인/2FA는 어떻게?

한 줄 답: 로그인과 2FA는 사람 핸드오프만 합니다. 에이전트에게 비밀번호·OTP 입력 경로를 발명하게 하지 않고, 사람이 인증을 끝낸 뒤 이미 열린·쿠키가 있는 세션에서만 이어가게 합니다.

Cursor Browser는 워크스페이스 단위로 쿠키·localStorage 등이 세션 간에 남을 수 있다고 설명합니다. 도움말에도 “로그인 뒤 페이지는 에이전트에게 어떻게 로그인하는지 알려 주라”는 안내가 있으나, 실무 규칙으로는 자격증명·2FA 코드를 채팅/rules에 넣지 않고, 사람이 브라우저(또는 SSO)에서 인증을 완료하는 쪽을 고정합니다. 우회·캡차 풀기·OTP 자동 입력 절차는 이 글에서 다루지 않습니다.

단계	사람	에이전트
1. 인증 필요 감지	—	“로그인/2FA 화면으로 보임. 중단”만 보고
2. 로그인·2FA	본인 기기·SSO·OTP로 완료	비밀번호·OTP·복구코드 요청·저장 금지
3. 세션 확인	목표 페이지가 보이는지 확인	인증 완료 후 이어서 읽기/클릭(승인 하에)
4. 막히면	정책·origin·세션 만료 점검	새 우회 경로 발명 금지, Blocked로 남김

에이전트에게 적을 문장 예시

If a login, SSO, captcha, or 2FA challenge appears:
1) Stop automated credential entry.
2) Tell the user what screen you see (no secrets).
3) Wait for the human to finish auth in the browser.
4) Resume only on the post-auth page the user confirms.
Never invent UI paths to bypass auth. Never paste passwords, OTP, or recovery codes into chat, rules, or files.

세션이 워크스페이스에 남는다고 해서 공유 머신·녹화·스크린샷에 비밀이 없다는 뜻은 아닙니다. 민감 계정은 수동 승인 모드를 유지하고, 작업이 끝나면 로그아웃·세션 정리를 사람이 결정합니다.

마무리

에이전트 브라우저는 MCP 실패(또는 UI 검증 목적) 후의 폴백으로 두는 편이 안전합니다. 커넥터는 구조화·권한·실패 격리에 강하고, 브라우저는 화면·콘솔·네트워크 확인에 강합니다. 로그인/2FA는 사람만 처리하고, 에이전트는 인증 이후·승인된 동작만 이어갑니다. 요금·발명 클릭 경로·인증 우회는 범위 밖입니다.

에이전트 브라우저 자동화, MCP 실패 후에만 쓸까

MCP를 먼저 쓰는 이유는?

브라우저로 넘어갈 신호는?

로그인/2FA는 어떻게?

마무리

관련 습관