브라우저 작업을 MCP에 맡기면 워크플로가 어떻게 달라지고 코드에서 어떤 부분이 사라질까요? 역할을 나누는 방법, 자주 막히는 네 가지 설정 문제, 문제가 생겼을 때의 점검 순서를 실무 관점에서 정리했습니다.
Claude Code로 브라우저 자동화를 작성하다 보면 가장 먼저 지치는 부분은 글루 코드입니다. 브라우저 실행, 프록시 연결, 환경 생성, 핸들 대기 같은 작업은 비즈니스 로직과 관계가 없지만 계속 반복해서 작성해야 합니다. 브라우저 작업을 MCP를 통해 넘기면 이 부분은 코드에서 거의 사라집니다. 해야 할 일을 설명하면 모델이 어떤 도구를 호출할지 스스로 결정합니다.
역할을 어떻게 나눌까
Claude Code는 명령줄에서 사용하는 코딩 어시스턴트로, 파일을 읽고 쓰고 명령을 실행하며 Git을 다룰 수 있습니다. 강점은 코드와 터미널 쪽 작업입니다. 브라우저를 직접 조작하는 것은 잘하는 영역도 아니고 맡길 필요도 없습니다.
MCP는 바로 이 빈틈을 채웁니다. 브라우저 자동화 환경의 기능을 도구 묶음으로 제공하고, 등록한 뒤에는 모델이 호출할 수 있게 합니다. 환경 목록 조회와 생성, 브라우저 시작과 중지, 스크린샷, 페이지 내용 읽기 등이 여기에 포함됩니다. 한쪽은 코드와 로그를, 다른 쪽은 브라우저와 페이지를 맡습니다. 경계가 분명해지면 문제가 생겼을 때 원인도 찾기 쉬워집니다.
워크플로는 어떻게 달라질까
가장 눈에 띄는 변화는 전체 흐름을 빠르게 구성할 수 있다는 점입니다. 예전에는 프로세스를 한 번 바꾸려면 스크립트를 수정해야 했습니다. 이제는 먼저 자연어로 시험해 볼 수 있습니다. 현재 환경을 나열하고 그중 두 곳에 로그인해 스크린샷을 찍은 뒤 결과를 정리하라고 요청합니다. 제대로 동작하면 그다음에 스크립트로 고정합니다.
실제 프로젝트에서는 보통 세 계층이 함께 작동합니다. MCP는 자연어 지시를 받아 탐색이나 임시 작업에 적합합니다. 로컬 HTTP API는 한 번에 수십 개 환경을 만드는 것 같은 일괄 작업을 맡으며, 안정적이고 재시도하기 쉽습니다. 특정 상태가 나타날 때까지 기다리거나 페이지에서 구조화 데이터를 가져오는 정밀한 상호작용은 CDP로 브라우저에 연결해 처리합니다. 세 방식은 서로 충돌하지 않고 각자 다른 구간을 담당합니다.
환경 계층을 따로 관리해야 한다는 점도 이 단계에서 분명해졌습니다. 환경이 여러 스크립트에 흩어져 있으면 작업이 많아질수록 문제를 추적하기 어렵습니다. 지금은 환경 수준 도구로 생성, 확인, 일괄 회수를 중앙에서 관리하고, 스크립트는 사용할 환경 ID 하나만 받도록 했습니다. 여러 계정을 다루는 상황에서는 PurpleMark 같은 환경 격리 솔루션이 이 계층을 맡아 계정별 환경, 세션, 캐시를 분리하고 실행 계층이 안정적으로 스케줄링할 수 있게 합니다.
자주 막히는 네 가지 지점
첫 번째는 도구가 인식되지 않는 경우입니다. 대부분의 클라이언트는 시작할 때만 설정을 읽기 때문에 등록 후 재시작하지 않으면 적용되지 않습니다. 도구마다 설정 파일 위치가 달라 경로를 잘못 지정하는 일도 흔합니다. 단순하지만 효과적인 방법은 서비스를 수동으로 실행해 보는 것입니다. 실행되면 설정 문제일 가능성이 높고, 실행되지 않으면 환경 문제일 가능성이 높습니다.
두 번째는 인증 실패입니다. 가장 흔한 원인은 자격 증명을 복사할 때 공백이나 줄바꿈이 함께 들어가는 것입니다. 먼저 이것을 확인하고, 다음으로 환경 변수가 어떻게 읽히는지 살펴봅니다. 운영체제와 실행 방식에 따라 결과가 달라질 수 있습니다.
세 번째는 로컬 API가 실행되지 않은 경우입니다. 이런 MCP 서비스는 대체로 클라이언트 자체가 실행 중이어야 합니다. 클라이언트가 꺼져 있으면 서비스가 시작되지 않거나 연결이 시간 초과될 수 있습니다. 포트가 이미 사용 중인지도 확인해야 합니다. 이전 프로세스가 완전히 종료되지 않았다면 포트를 계속 점유할 수 있습니다. 포트 번호는 클라이언트 설정에서 확인할 수 있습니다.
네 번째는 동시 작업끼리 서로 간섭하는 경우입니다. 작업 하나는 잘 돌아가는데 여러 개를 함께 실행하면 데이터가 뒤섞이거나 로그인 상태가 서로 덮어써집니다. 대부분 여러 작업이 같은 환경을 공유한 것이 원인입니다. 이런 문제는 디버깅만으로 해결할 수 없고 제약이 필요합니다. 작업 하나당 환경 하나를 사용하고, 환경 생성과 회수는 일괄 API로 처리하며 스크립트 안에서 임시로 만들지 않습니다.
디버깅할 때의 몇 가지 습관
지시문에는 대기 조건을 분명하게 적습니다. “제출 버튼을 클릭해”라는 말만으로는 정보가 부족합니다. “제출 버튼이 클릭 가능해질 때까지 기다린 뒤 클릭해”라고 하면 성공률이 확실히 달라집니다. 무엇을 할지는 모델이 판단하지만, 언제 기다려야 하는지는 사람이 알려줘야 합니다.
처음에는 읽기 전용 작업으로 연결 경로를 검증합니다. 환경 목록 조회, 스크린샷, 페이지 텍스트 읽기는 부작용이 없지만 인증, 네트워크, 서비스 세 부분을 한 번에 확인할 수 있습니다. 연결이 통하지 않을 때는 부작용이 있는 작업부터 실행하지 않는 것이 좋습니다.
자격 증명은 코드에 넣지 말고 환경 변수나 로컬 설정 파일을 사용하며, 해당 파일은 무시 목록에 추가합니다. 팀 구성원이 바뀌면 자격 증명도 한 번 교체합니다. 로컬 API가 자체 검증을 꺼 둔 경우라도 최소한 로컬 머신에서만 수신하고 외부에서 접근할 수 없게 해야 합니다.
마지막으로 경계를 기억해야 합니다. MCP는 기술적인 연결을 이어 줄 뿐 플랫폼 규칙을 바꾸지 않습니다. 통합이 아무리 매끄러워도 해당 작업에 적용되는 서비스 약관은 그대로 지켜야 합니다.
