MCP 서버 없이도 충분한 브라우저 DevTools, 이렇게 만들면 끝

요즘 에이전트 개발 이야기만 나오면 MCP 서버가 필수처럼 느껴지죠.
하지만 실제로는, 간단한 Bash와 몇 개의 Node.js 스크립트만으로도 빠르고 효율적인 브라우저 DevTools 환경을 만들 수 있습니다.

이 글에서는 "MCP 없이도 되는 이유"와 "브라우저를 제어하는 최소 도구 세트"를 소개하고, 이를 다른 에이전트들에서도 재사용하는 방법까지 한 번에 정리해보겠습니다.

조금 과장하자면, 이 방식에 익숙해지면 거대한 MCP 서버보다 내가 직접 만든 4~6개의 작은 도구가 훨씬 든든하게 느껴질 겁니다.

왜 MCP 서버가 항상 정답은 아닐까?

에이전트 생태계가 커지면서 MCP 서버는 사실상 표준처럼 취급되고 있습니다.
하지만 실제로 써보면, "멋진 구조"와 "현실적인 효율" 사이에 꽤 큰 간극이 있다는 걸 금방 느끼게 됩니다.

먼저, 인기 있는 MCP 서버들은 너무 많은 기능을 한꺼번에 제공하는 경우가 많습니다.
예를 들어 브라우저 DevTools MCP들은 20개가 넘는 툴을 제공하고, 설명만으로도 수천~수만 토큰이 날아갑니다. 이건 곧 에이전트의 컨텍스트를 매번 크게 잡아먹는다는 뜻이고, 다른 MCP나 시스템 프롬프트와 합쳐지면 금방 혼란이 생깁니다.

또 하나는 확장성 문제입니다.
기능을 조금만 바꾸고 싶어도 기존 MCP 서버 코드를 뜯어보고, 구조를 이해하고, 에이전트가 새 기능을 학습하게 만들어야 합니다. 그 과정에서 디버깅과 재배포까지 해야 하니, "조금 고치자"가 "큰 프로젝트"가 되기 쉽습니다.

가장 치명적인 건 "비합성적"이라는 점입니다.
MCP 응답은 대부분 에이전트의 컨텍스트로만 흐릅니다. 파일로 저장해서 나중에 다시 쓰거나, 다른 코드와 자연스럽게 엮는 게 불편합니다. 반면 Bash와 코드 기반 도구는 파일 시스템, 파이프, 리다이렉션 등 기존 개발자가 익숙한 방식으로 쉽게 조합할 수 있습니다.

정리하자면, 브라우저 제어 같은 단일 용도에는:

툴이 너무 많고 (에이전트 혼란 + 토큰 낭비)
확장과 커스터마이징이 어렵고
출력이 코드/파일과 자연스럽게 섞이지 않는다는 점에서

항상 MCP가 최선이라고 보기는 어렵습니다.

브라우저 작업에 필요한 '진짜 최소 도구 세트'

글쓴이가 실제로 브라우저 작업을 할 때 필요한 건 굉장히 단순합니다.
웹 프론트엔드를 함께 수정하거나, 특정 사이트를 스크레이핑할 때 반복적으로 쓰이는 기능만 딱 추렸습니다.

필요한 건 사실 이 네 가지가 전부입니다.

브라우저 시작

크롬을 원격 디버깅 모드로 실행
필요하면 내 실제 프로필(로그인 정보, 쿠키 포함)을 복사해서 사용

URL 이동

현재 탭으로 이동
혹은 새 탭을 열어서 이동

자바스크립트 실행

활성 탭의 페이지 컨텍스트에서 DOM을 읽거나 수정
에이전트가 DOM API를 직접 활용할 수 있게 해줌

스크린샷 찍기

현재 뷰포트 화면을 PNG로 저장
경로를 돌려줘서, 에이전트가 비전 기능으로 이미지를 "볼" 수 있게 함

이 모든 도구는 단순한 Node.js 스크립트이며, Puppeteer Core로 크롬의 CDP(Chrome DevTools Protocol)에 붙는 구조입니다.

에이전트에게는 README 한 장만 보여주면 됩니다.
예를 들어:

"./start.js --profile 로 크롬을 프로필과 함께 시작"
"./nav.js https://example.com 으로 현재 탭 이동"
"./eval.js 'document.title' 로 DOM 정보 읽기"
"./screenshot.js 로 스크린샷 경로 얻기"

정도만 알려주면, 모델은 이미 Bash와 자바스크립트 사용법을 알고 있기 때문에 나머지는 스스로 잘 해냅니다.

결과적으로, 브라우저 제어를 위해 거대한 MCP 스펙을 먹일 필요 없이, 200여 토큰짜리 README 하나로 끝낼 수 있습니다.

Bash + 코드 조합이 MCP보다 강력한 이유

이 방식의 진짜 장점은 "모델이 이미 알고 있는 것"을 그대로 활용한다는 점입니다.

모델은 Bash를 사용할 줄 압니다.
Node.js 코드도 쓸 줄 알고, DOM API도 이해합니다.
파일을 저장하고 읽는 패턴도 기본적으로 잘 다룹니다.

그래서 도구 설명에 굳이 "세세한 사용 방법"을 장황하게 적을 필요가 없습니다.
간단한 예시만 몇 줄 보여주면, 나머지는 모델이 일반적인 개발 지식으로 추론해 사용합니다.

토큰 측면에서 보면 차이가 극적입니다.

인기 브라우저 MCP: 13k~18k 토큰 (세션마다 고정 비용)
이 글에서 소개한 브라우저 도구 README: 약 225 토큰

게다가 Bash 도구는 합성이 자유롭습니다.
에이전트는 다음과 같은 방식으로 자유롭게 활용할 수 있습니다.

결과를 바로 파일로 저장
여러 도구를 한 줄 Bash로 파이프라인 구성
필요할 때만 README를 불러와 참조

또한 출력 형식이 비효율적이라는 생각이 들면, 스크립트 한 줄만 고치면 됩니다.
MCP 서버처럼 구조 전체를 건드릴 필요가 없고, 즉시 반영됩니다.

핵심만 정리하면:

적은 토큰 사용
높은 유연성
파일/코드와의 자연스러운 결합
변경·확장이 매우 쉽다

라는 네 가지가 Bash + 코드 조합의 압도적인 장점입니다.

DOM을 '클릭해서 알려주는' Pick 도구의 매력

스크레이핑을 할 때 가장 귀찮은 부분 중 하나는 "어떤 DOM 요소를 기준으로 데이터를 가져와야 하는지"를 에이전트에게 설명하는 일입니다.

CSS 셀렉터를 글로 설명하다 보면:

"여기 제목 부분 있잖아, 그거 li 태그 아래 a인데…"
"이 버튼이… 그 회색 버튼 말고 옆에 주황색 버튼…"

이런 식으로 사람도 헷갈립니다.

그래서 만든 게 "pick" 도구입니다.

아이디어는 간단합니다.

브라우저에서 내가 직접 DOM 요소를 클릭해 고른다.
스크립트가 선택한 요소의 정보(태그, id, class, 텍스트, 부모 구조 등)를 깔끔하게 정리해 표준 형식으로 출력한다.
에이전트는 그 출력을 보고 적절한 셀렉터, 스크레이퍼 코드를 작성한다.

사용법도 직관적입니다.

"./pick.js '제목이 되는 영역을 선택해 주세요'"처럼 메시지를 주고 실행
마우스로 요소 위에 올리면 하이라이트
클릭하면 선택, Cmd/Ctrl+클릭으로 여러 개 선택
Enter로 선택 완료, ESC로 취소

이렇게 한 번 찍어준 요소 정보만 있으면, 에이전트는:

"이 구조라면 ul > li > a 형태로 반복 요소를 잡으면 되겠네요."
"여기서 텍스트만 추출해서 배열로 만들겠습니다."

같은 식으로 스스로 코드를 설계합니다.

DOM 구조가 나중에 바뀌어도, 다시 pick으로 몇 번 클릭해 새 구조만 알려주면 에이전트가 코드 수정을 도와줍니다.
복잡한 사이트일수록, 이 방식이 사람과 에이전트 협업의 생산성을 크게 올려줍니다.

HTTP-only 쿠키도 1분 만에 도구로 추가하는 방법

스크레이핑을 하다 보면 "로그인된 상태"를 그대로 유지해야 할 때가 많습니다.
이때 문제는, 페이지 안에서 실행되는 자바스크립트는 HTTP-only 쿠키에 접근할 수 없다는 점입니다.

기존 eval 도구는 페이지 컨텍스트에서 돌아가기 때문에, 이런 쿠키를 읽을 수 없습니다.
그렇다고 MCP 서버를 새로 뜯어고칠 필요도 없습니다.

이 글의 접근 방식은 아주 간단합니다.

"쿠키를 가져오는 스크립트가 필요해"라고 에이전트에게 요청
Puppeteer의 CDP 세션이나 쿠키 API를 이용해 HTTP-only 쿠키까지 가져오는 Node.js 스크립트를 생성
README에 사용법 몇 줄 추가
바로 도구 세트에 합류

실제 작업 시간은 1분도 걸리지 않습니다.

이게 가능한 이유는:

도구의 단위가 작고 독립적이며
Node.js + Puppeteer라는 익숙한 스택 위에 있고
README로 인터페이스만 명확히 정의해두었기 때문입니다.

MCP 서버를 수정했다면:

기존 코드베이스를 이해하고
새로운 엔드포인트/툴 정의를 추가하고
구조를 망가뜨리지 않았는지 테스트하고
배포 과정을 다시 거쳐야 합니다.

규모가 큰 시스템에는 MCP가 의미가 있지만, 이렇게 목적이 뚜렷한 도구 몇 개를 빠르게 추가·수정해야 하는 상황에서는 Bash + 스크립트 방식이 압도적으로 생산적입니다.

여러 에이전트에서 재사용 가능한 '개인 도구 세트' 만들기

좋은 도구는 한 번 만들면 여기저기서 쓰고 싶어집니다.
이 구조를 다른 에이전트에도 쉽게 재사용할 수 있도록 정리하는 방법도 깔끔합니다.

대략 이런 식의 구성을 추천합니다.

공통 도구 폴더 만들기

홈 디렉터리에 ~/agent-tools 같은 폴더를 하나 만든 뒤
그 안에 browser-tools, api-tools, file-tools 등 개별 레포를 클론

PATH에만 살짝 올리기

예:
alias cl="PATH=$PATH:$HOME/agent-tools/browser-tools:... && claude --dangerously-skip-permissions"
이렇게 하면 기존 쉘 환경을 더럽히지 않으면서, Claude나 다른 에이전트 세션에서는 모든 스크립트를 전역 명령처럼 호출할 수 있습니다.

파일 이름에 접두사 붙이기

browser-tools-start.js, browser-tools-nav.js 처럼
서로 다른 도구 레포에서 이름이 겹치지 않도록 관리

README 한 줄로 "전역 사용 가능"을 알려주기

"이 폴더의 스크립트는 PATH에 등록되어 있어 어디서든 호출 가능하다"라고 적어두면
에이전트가 굳이 작업 디렉터리를 이동하지 않고도 도구를 쓸 수 있습니다.

에이전트 IDE/코드 환경에 폴더 등록

출처 및 참고 : What if you don't need MCP at all?