포스트

Chrome DevTools MCP에 로그인 브라우저를 연결해도 될까: DOM, Network, Cookie 노출

Chrome DevTools MCP에는 평소 쓰는 로그인 브라우저가 아니라 더미 계정과 테스트 데이터만 있는 격리 프로필을 연결해야 합니다.

AI가 보는 것은 화면보다 훨씬 많다

chrome-devtools-mcp는 LLM을 MCP 클라이언트, MCP 서버, Puppeteer, Chrome DevTools Protocol(CDP) 순서로 브라우저에 연결합니다. 이 경로를 통해 에이전트는 DOM을 읽고 요소를 조작하는 것뿐 아니라 Console 오류, Network 요청과 응답, 성능 데이터까지 조사할 수 있습니다.

이 범위가 디버깅에는 강점이지만 보안에는 그대로 위험이 됩니다. Network 응답에는 개인정보가, 저장소와 쿠키에는 세션 정보가, 사내 페이지에는 외부로 보내면 안 되는 데이터가 들어 있을 수 있습니다. “로컬에서 실행한다”는 사실만으로 LLM에 전달되는 컨텍스트까지 로컬에 남는 것은 아닙니다.

Playwright와 역할도 구분해야 합니다. 미리 작성한 시나리오를 반복 검증하려면 결정적인 E2E 테스트가 맞습니다. 오류를 보고 다음에 어느 탭과 요청을 살필지 그때그때 정해야 하는 탐색적 진단에는 MCP 연결이 유용합니다. 둘은 대체 관계가 아니라 재현 전후의 역할이 다릅니다.

설정 예시는 설치 완료 절차가 아니다

원문에 나온 설정은 MCP 서버를 등록하는 스냅샷입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--headless",
        "--no-performance-crux"
      ],
      "env": {
        "PUPPETEER_SKIP_CHROMIUM_DOWNLOAD": "true",
        "CHROME_PATH": "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
      }
    }
  }
}

이 조각은 @latest를 사용하므로 실행 시점에 결과가 달라질 수 있고, CHROME_PATH는 macOS의 한 경로 예시입니다. Node와 Chrome 호환 버전, MCP 클라이언트별 설정 위치, 별도 사용자 데이터 디렉터리, 접근 가능한 주소와 권한 정책은 포함하지 않습니다. 운영 팀에서는 버전을 고정하고 테스트 프로필을 명시한 뒤 도구별 읽기, 쓰기 권한을 따로 확인해야 합니다.

특히 기존 Chrome 실행 파일을 지정하는 것과 기존 로그인 프로필을 공유하는 것은 다른 결정입니다. 실제 계정의 쿠키와 로컬 스토리지가 필요한 편의보다 유출 범위가 훨씬 커질 수 있습니다.

좋은 요청은 증상과 중단 조건을 함께 준다

메모리 누수를 찾을 때는 “페이지를 알아서 고쳐라”보다 재현 행동, 측정 전후, 관찰 대상을 좁히는 편이 낫습니다. 예를 들어 특정 상호작용 전후의 힙 스냅샷을 비교하고 Detached DOM 노드가 계속 늘어나는지만 먼저 확인합니다. 원인 후보가 나오면 코드 변경은 별도 단계로 넘깁니다.

HTTP 500 오류도 같은 방식으로 쪼갤 수 있습니다.

  1. 오류를 만드는 사용자 동작을 한 번만 재현합니다.
  2. 실패한 요청의 URL이 아니라 메서드, 상태, payload와 응답을 확인합니다.
  3. Console 오류와 같은 시점인지 맞춥니다.
  4. 민감한 필드는 가린 뒤 원인 후보를 정리합니다.
  5. 수정 후에는 동일 동작을 정해진 E2E 테스트로 고정합니다.

클릭 횟수, 탐색 시간, 허용 도메인 같은 중단 조건이 없으면 Shadow DOM이나 동적으로 바뀌는 요소에서 행동 루프가 생길 수 있습니다. Canvas 중심 UI처럼 의미 있는 DOM이 부족한 화면에서도 에이전트가 볼 수 있는 단서가 급격히 줄어듭니다.

디버깅 권한은 최소 단위로 열어야 한다

도입 전에는 전용 브라우저 프로필, 더미 계정, 테스트 환경, 허용할 도메인을 먼저 준비합니다. 결제, 삭제, 발송처럼 되돌리기 어려운 동작은 자동 실행 대상에서 제외하고, 요청과 응답을 LLM으로 보낼 수 있는지 데이터 등급별로 확인해야 합니다.

또한 브라우저 실행과 상태 직렬화, LLM 왕복에는 지연과 메모리가 듭니다. 단순 재현 테스트까지 모두 에이전트에 맡기면 기존 Playwright 테스트보다 느리고 불안정할 수 있습니다. 가장 현실적인 경계는 MCP로 낯선 증상을 탐색하고, 사람이 가설과 변경 diff를 검토하며, 확인된 재현은 테스트 코드로 옮기는 것입니다.

Chrome DevTools MCP는 프론트엔드 디버깅을 끝내는 도구가 아닙니다. 복사, 붙여넣기로 잃던 브라우저 맥락을 에이전트에 제공하는 대신, 그 맥락에 포함된 비밀까지 함께 노출될 수 있음을 관리하는 도구입니다.

브라우저 위협 모델은 무엇부터 그려야 하는가?

전용 프로필을 만들 때 기존 프로필 디렉터리를 복사하지 말고 빈 사용자 데이터 디렉터리에서 시작합니다. 테스트 계정에는 필요한 애플리케이션과 테넌트만 허용하고 결제, 관리자, 실사용자 데이터 권한을 제거합니다. 허용 도메인은 애플리케이션, 로컬 개발 서버와 필요한 테스트 API로 제한하고 임의 인터넷 탐색은 막습니다.

브라우저에서 에이전트가 읽을 수 있는 데이터 흐름을 표로 만드세요. DOM 텍스트, Console 로그, request header, body, response, cookie, localStorage, IndexedDB, 화면 캡처와 성능 trace마다 개인정보와 비밀이 들어갈 가능성, LLM으로 전송해도 되는지, 보존 기간을 정합니다. ‘Network 탭 읽기’ 하나의 권한 안에도 Authorization 헤더와 공개 자산 URL은 민감도가 전혀 다릅니다.

웹 페이지 자체도 신뢰할 수 없는 입력입니다. DOM이나 API 응답에 ‘이 지시를 따르라’는 텍스트가 있어도 도구 범위와 디버깅 목표를 바꿀 수 없게 합니다. 링크 클릭, 파일 다운로드, clipboard, 권한 요청과 새 창 이동은 별도 정책으로 제한하세요. 테스트 대상이 외부 콘텐츠를 렌더링한다면 프롬프트 주입 시나리오도 평가에 넣습니다.

읽기 전용 진단은 어떤 단계로 진행할까?

첫 단계에서는 URL, 재현 행동과 예상 결과를 고정하고 DOM, Console, Network를 관찰만 합니다. 에이전트가 문제를 재현하지 못하면 무작위 클릭을 늘리지 말고 누락된 환경, 계정 상태와 feature flag를 질문합니다. 재현 시각, 브라우저, 앱 버전, request ID를 남겨 서버 로그와 맞출 수 있어야 합니다.

두 번째 단계는 가설별 최소 증거를 수집합니다. 화면 렌더 오류라면 관련 요소의 상태와 Console stack, API 실패라면 메서드, 상태, 민감 값을 제거한 payload와 응답, 성능 문제라면 명시한 구간의 trace를 봅니다. 전체 페이지와 모든 네트워크 응답을 무조건 문맥에 넣으면 비밀 노출과 분석 잡음이 함께 늘어납니다.

세 번째 단계에서만 코드 후보와 예상 diff를 만듭니다. 브라우저 세션을 계속 조작하는 대신 저장소의 관련 파일과 테스트를 연결하고, 사람이 원인 가설을 승인한 뒤 수정합니다. 수정 후 같은 행동으로 증상이 사라지는지 확인하되 캐시나 세션 상태가 결과를 가리지 않도록 새 프로필 또는 초기화 절차를 사용합니다.

민감한 Network 데이터는 어떻게 줄이는가?

MCP 서버나 중간 계층에서 header와 body 필드를 allowlist 방식으로 선택하는 편이 좋습니다. Authorization, Cookie, Set-Cookie, API key와 개인 식별자는 모델 문맥에 들어가기 전에 제거하거나 안정된 placeholder로 바꿉니다. 마스킹 뒤에도 payload 구조와 오류 코드를 분석할 수 있도록 필드 존재와 데이터 유형은 남길 수 있습니다.

response body가 크면 전체를 보내지 말고 실패한 레코드, schema 차이와 관련 구간만 추출합니다. 이미지, 문서 다운로드는 기본 거부하고 필요할 때 파일 크기, 유형을 검사한 격리 저장소에서 처리합니다. 로그에는 원본 비밀 대신 request ID, 마스킹 정책 버전과 추출된 필드 목록을 남깁니다.

데이터가 모델 공급자 경계 밖으로 나갈 수 없는 환경이라면 로컬 실행 여부만 확인해서는 안 됩니다. MCP 클라이언트가 어떤 모델과 기록 저장소를 쓰는지, trace와 스크린샷이 어디에 보존되는지까지 확인해야 합니다. 허용할 수 없다면 민감 값을 제거한 재현 환경이나 합성 fixture를 먼저 만듭니다.

탐색 결과를 결정적 테스트로 옮기는 방법은?

에이전트가 찾은 재현 행동을 고정 selector, 준비 데이터와 assertion이 있는 E2E 테스트로 바꿉니다. DOM 위치나 자연어 설명만 의존하면 화면 변화 때 흔들리므로 제품이 제공하는 안정된 테스트 ID와 사용자에게 보이는 결과를 사용합니다. Network 오류의 경우 mock만 쓰지 말고 가능한 범위에서 실제 계약 테스트도 둡니다.

메모리 누수는 한 번의 heap 숫자보다 같은 행동을 여러 번 반복했을 때 retained object와 Detached DOM이 계속 증가하는지 봅니다. 성능 테스트에는 하드웨어와 브라우저 조건의 변동이 크므로 절대값뿐 아니라 기준 버전 대비 회귀와 여러 번의 분포를 사용합니다. 탐색 중 발견한 우연한 관찰을 바로 CI 임계값으로 만들지 않습니다.

테스트가 만들어지면 일반 회귀 검증은 Playwright 같은 자동화가 맡고 MCP는 새로운 실패를 조사할 때 다시 사용합니다. 이렇게 해야 매 빌드마다 LLM이 브라우저를 자유 탐색하는 비용과 불확실성을 피할 수 있습니다. 테스트 실패 시 저장할 trace와 마스킹된 로그도 미리 정합니다.

파일럿에서 무엇을 중단 조건으로 볼까?

대표적인 Console 오류, API 500, 렌더 불일치와 느린 상호작용을 고르고 기존 수동 진단과 비교합니다. 첫 유효 가설까지의 시간, 확인을 위해 연 탭과 요청 수, 모델로 전달한 데이터량, 잘못된 클릭, 사람이 수정한 가설과 최종 재현 테스트 성공을 기록하세요.

허용 도메인 밖으로 이동하거나 민감 header가 문맥에 들어가고, 결제, 삭제 같은 금지 동작을 시도하면 파일럿을 중단합니다. 탐색 시간이 상한을 넘거나 같은 행동이 반복되면 추가 클릭 대신 현재 증거와 막힌 이유를 반환하게 합니다. 빠르게 원인을 맞히는 것보다 피해 없이 멈추고 사람이 이어 갈 수 있는지가 운영 준비의 기준입니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

자주 묻는 질문

Chrome DevTools MCP에 평소 쓰는 Chrome 프로필을 연결해도 되나요?

권장하지 않습니다. 로그인 쿠키, 로컬 저장소, 방문 페이지와 네트워크 응답이 노출될 수 있으므로 더미 계정과 테스트 데이터만 있는 별도 프로필을 사용하세요.

MCP 디버깅이 Playwright 테스트를 대체하나요?

아닙니다. MCP는 낯선 증상을 탐색하는 데 유용하고 Playwright는 확인된 재현을 반복 검증하는 데 적합합니다. 탐색 결과를 결정적 테스트로 옮겨야 합니다.

에이전트에게 페이지 수정까지 바로 맡겨도 되나요?

먼저 읽기 전용 관찰로 증상과 근거를 수집하고 코드 변경은 별도 승인 단계로 두는 편이 안전합니다. 결제, 삭제, 발송 동작은 자동 실행에서 제외하세요.

참고 자료

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1 —

←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    13개 장 20 분읽는 시간