크롬 144와 MCP: 끊긴 연결을 복구하고 AI 에이전트의 한계를 돌파하는 법

앤스로픽이 제시한 Model Context Protocol(MCP)은 AI 에이전트가 브라우저와 대화하는 방식을 완전히 뒤바꿨습니다. 하지만 현장의 엔지니어들은 축배를 들 틈도 없이 벽에 부딪혔습니다. 크롬 144 버전이 보안을 이유로 자동화의 핵심 경로를 차단했기 때문입니다.

단순한 연결 오류를 넘어 기업용 AI 에이전트가 마주한 진짜 과제는 보안과 성능의 균형입니다. 작동만 하는 코드가 아니라, 비즈니스 현장에서 견딜 수 있는 아키텍처가 필요합니다.

---

보안이 가로막은 자동화: 크롬 144의 변화

가장 먼저 해결할 문제는 사라진 API입니다. 크롬 144는 기존 자동화 도구들이 브라우저 인스턴스를 찾을 때 사용하던 HTTP 발견 API(/json/version)를 제거했습니다. 에이전트가 404 오류를 뱉으며 멈추는 이유가 바로 이것입니다.

이제는 구걸하듯 경로를 찾을 게 아니라 직접 웹소켓(WebSocket) URL을 구성해야 합니다. DevToolsActivePort 파일을 읽어 포트를 강제로 지정하는 수동 연결 방식이 유일한 해법입니다. 또한, 구글은 MCP 서버 연결 시마다 사용자 승인 팝업을 강제하고 있습니다. 무인 자동화를 꿈꾸는 팀이라면 이 권한 설계를 처음부터 다시 짜야 합니다.

---

세션 탈취를 막는 기기 귀속 자격 증명(DBSC)

AI 에이전트가 사용자의 쿠키와 인증 세션을 그대로 상속받는 것은 보안팀에게는 악몽입니다. 에이전트의 취약점이 곧 전사적 데이터 유출로 이어질 수 있습니다.

진짜 해결책은 기기 귀속 세션 자격 증명(DBSC) 기술에 있습니다. 크롬 145(Windows)와 147(macOS)부터 본격 도입되는 이 기술은 세션 쿠키를 특정 하드웨어에 물리적으로 묶어버립니다. 설령 AI가 쿠키를 유출당해도 다른 기기에서는 무용지물입니다.

실전 격리 전략:

• 물리적 프로필 분리: --user-data-dir 플래그를 통해 에이전트마다 독립적인 데이터 저장소를 할당하십시오.
• 세션 레지스트리 구축: chromectl 같은 도구를 활용해 세션별 포트를 중앙에서 관리하면 인증 상태 간섭을 원천 차단할 수 있습니다.

---

성능 벤치마크: 왜 Playwright MCP인가

대규모 배포 환경에서 MCP 서버의 리소스 점유율은 비용과 직결됩니다. 안티그래비티(Antigravity) IDE 사례를 보면, 워크스페이스마다 독립 프로세스를 생성할 경우 유휴 상태에서도 수십 개의 프로세스가 기가바이트 단위의 RAM을 잡아먹는 프로세스 폭발 현상이 발생합니다.

도구 선택	기술 기반	토큰 소모 효율 (200k 기준)	추천 용도
Playwright MCP	접근성 트리(Accessibility Tree)	~6.8% 소모	비용 최적화 및 고속 자동화
Chrome DevTools MCP	CDP 전체 프로토콜	~9.5% 소모	심층 디버깅 및 UI 테스트

Playwright MCP가 압도적으로 효율적인 이유는 명확합니다. 지저분한 DOM 전체를 읽는 대신 스크린 리더가 인식하는 핵심 정보만 추출하기 때문입니다. 비용을 줄이고 싶다면 이 접근성 트리 기반의 에이전트를 선택하십시오.

---

자가 치유(Self-healing) 로직의 도입

웹페이지는 생물과 같습니다. 버튼 ID 하나만 바뀌어도 전통적인 스크립트는 죽어버립니다. 에이전트에게 3단계 계층적 복구 프레임워크를 학습시켜야 합니다.

1. 기본 로케이터 시도: 기존 CSS나 XPath로 먼저 접근합니다.
2. 휴리스틱 검색: 실패 시 LLM을 쓰지 않고 텍스트 유사도나 부모-자식 관계를 추측해 비용 없이 요소를 찾습니다.
3. AI 기반 재식별: 마지막 단계에서만 DOM 스냅샷을 Gemini에 전달해 의도에 맞는 요소를 찾고 코드를 자동 업데이트하는 힐링 리포트를 생성합니다.

흔히 하는 실수는 사용자 데이터 디렉토리를 무분별하게 재사용하는 것입니다. 캐시가 수십 GB로 불어나기 전에 --disk-cache-size=104857600 플래그로 100MB 제한을 걸고, 세션 종료 시마다 추적 데이터를 삭제하는 스크립트를 반드시 병행해야 합니다.

---

엔터프라이즈 배포를 위한 최종 체크리스트

조직 내에서 MCP를 안전하게 운영하려면 권한 최소화 원칙을 고수해야 합니다. 모든 도메인을 허용하는 대신 mcp_config.json에서 화이트리스트를 관리하십시오.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--allowed-origins=https://*.internal.com"
      ]
    }
  }
}

로컬 인프라의 한계를 넘고 싶다면 Browser-as-a-Service(BaaS)가 정답입니다. Firecrawl이나 Browserbase 같은 서비스는 일회용 컨테이너에서 세션을 실행하고 작업 즉시 파기합니다. 보안성을 극대화하면서 수백 개의 병렬 세션을 실시간으로 감시할 수 있는 유일한 방법입니다.

크롬 144 이후의 MCP 활용은 단순한 연결 구현이 아닙니다. 세션 격리 아키텍처를 설계하고, 리소스 효율을 벤치마킹하며, 자가 치유 로직으로 견고함을 확보하는 고도의 엔지니어링 과정입니다. 데이터 유출 방지(DLP)와 프롬프트 주입 방어라는 산을 넘어야만 에이전틱 브라우저 시대의 진정한 승자가 될 수 있습니다.