▲

AI 브라우저 자동화를 위한 "MCP-B 프로토콜"

 (mcp-b.ai)
6P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • MCP-B : 브라우저 네이티브 AI 자동화 프로토콜
  • 기존의 화면 캡처·클릭 방식이 아닌, 웹사이트의 API에 직접 접근하여 AI가 1,000배 빠르고 정확하게 자동화할 수 있도록 지원하는 브라우저 컨텍스트 프로토콜
  • 약 50줄의 코드만 추가하면 별도의 OAuth, API 키, 복잡한 설정 없이 사이트 내 인증 정보로 바로 AI 연동이 가능
  • 브라우저 세션과 기존 인증 시스템을 활용해, 새로운 인증이나 권한 설정 없이 즉시 동작하며, 각 웹 앱의 API 보안 정책을 그대로 존중함
  • 확장 프로그램을 통해 AI 어시스턴트가 여러 탭과 앱을 넘나들며 직접 데이터 조회·작업 수행이 가능, 기존 자동화 대비 성능(수 ms 내 실행)과 신뢰성이 압도적으로 향상됨
  • 구조화된 API 접근이기 때문에 UI 변경, 스크린샷 오류, 복잡한 셀렉터 관리 문제에서 자유로움. 설치와 사용 모두 매우 간단

MCP-B 개요

  • MCP-B(Machine Context Protocol for Browsers) 는 브라우저를 위한 모델 컨텍스트 프로토콜로, AI 기반 터미널 자동화와 유사한 방식으로 브라우저 환경을 제어 및 상호작용하는 표준 제공
  • 본 프로토콜은 브라우저와 AI 엔진 사이의 통신을 명확히 규정해, 다양한 자동화 및 모델 상호작용을 구조화함

기존 방식과의 차별점

  • 전통적 브라우저 자동화: 스크린샷 분석, 요소 클릭, UI 변경에 취약, 느리고 불안정(작업당 10~20초, $4~5 비용)
  • 기존 MCP 방식: API 키와 복잡한 인증 필요, 초기 셋업 진입장벽 높음
  • MCP-B: 브라우저 세션 활용, API 직접 접근, 복잡한 인증·설정 없이 즉시 동작

핵심 원리 및 구조

  • 탭별 MCP 서버: 각 웹앱이 자체적으로 TypeScript 기반 MCP 서버 구동(메모리 내 전송, 기존 쿠키/JWT 인증 재활용)
  • MCP-B 확장 프로그램: 크롬/엣지/파이어폭스 확장(컨텐츠 스크립트가 탭 서버와 postMessage로 통신), 모든 탭의 툴·API를 한곳에서 통합
  • AI 어시스턴트 연동: Native Bridge 및 다양한 클라이언트(Claude Desktop, Cursor IDE 등)에서 MCP-B를 통해 브라우저 자동화 가능

사용 및 배포 방식

  • 개발자: 1) 패키지 설치 2) MCP 서버 코드 추가 3) 배포 완료 → 별도 API 키, OAuth, 복잡 설정 필요 없음
  • 사용자: 확장 프로그램 설치 후 바로 사용, AI 설정만으로 즉시 자동화

실질적 장점

  • 인증: 기존 웹사이트 로그인·세션 정보 그대로 사용, OAuth 2.1/별도 인증 필요 없음
  • 성능: 직접 API 호출로 ms 단위 작업 완료(기존 대비 10,000배 향상)
  • 보안: 애플리케이션 내부에서 동작, 기존 접근 제어 및 권한 정책 그대로 준수
  • 확장성: 여러 웹앱과 탭, AI 도구가 MCP-B를 통해 통합 관리 가능
  • 설정: 약 50줄 코드만으로 자동화 준비 완료

비교 요약

방식 인증 및 설정 동작 방식 성능 및 신뢰성
기존 자동화 복잡한 인증, API 키 화면 스크래핑, 클릭 느리고 불안정 (10~20초)
기존 MCP API 키, OAuth 필요 API 접근 진입장벽 높음
MCP-B 설정 無, 브라우저 세션 사용 직접 API 호출 ms 단위, 매우 빠름/안정적

결론: 차세대 브라우저 기반 AI 자동화

  • MCP-B는 브라우저 환경에 최적화된 AI 자동화 프로토콜로, 인증/보안/확장성/성능 모든 면에서 혁신적
  • 추가 인증이나 복잡한 설정 없이, 브라우저 기반의 API 직접 호출만으로 대규모 AI 자동화 구현 가능
  • MIT 라이선스, 커뮤니티 중심, 모든 주요 브라우저 지원
▲
shindalsoo 2시간전  [-]

MCP-B 기술의 핵심 비전은 다음과 같다고 볼 수 있습니다.
"크롬 확장 프로그램(Extension)이라는 신뢰할 수 있는 매개체를 통해, 브라우저가 이미 안전하게 관리하고 있는 사용자 정보(쿠키, 세션, 인증 등)를 활용하여,
웹페이지에 개발자가 미리 정의해 둔 '도구(Tools)'들을 AI 채팅창에서 자연어 명령으로 호출하고 제어하겠다."

하지만 저는 "확대될 여지가 없어 보인다"고 느끼며, 그 이유는 다음과 같다고 생각합니다.

  1. 사용자 저항감: 가장 큰 허들입니다. 사용자들은 자신의 브라우저 정보에 접근하는 확장 프로그램을 설치하는 것에 대해 본능적인 거부감과 보안 우려를 가지고
    있습니다. 이 기술이 제공하는 편리함이 그 우려를 넘어설 만큼 압도적이지 않다면, 사용자들은 설치를 주저할 것입니다.
  2. 웹 개발자의 부담: 웹사이트 개발자들은 기존의 API를 만드는 것 외에도, MCP-B를 위한 '도구(Tools)'를 별도로 정의하고 관리해야 하는 추가적인 부담을 갖게
    됩니다. 이 기술이 널리 채택되어 얻는 이득이 크지 않다면, 개발자들은 굳이 이중의 노력을 들이려 하지 않을 것입니다.
  3. 보안 문제의 책임 소지: 만약 이 기술을 통해 보안 사고가 발생했을 때, 책임이 웹사이트 개발자에게 있는지, 확장 프로그램 개발자에게 있는지, 아니면 AI 모델
    제공자에게 있는지 불분명해질 수 있습니다. 이런 복잡성은 기업들이 기술을 도입하는 것을 꺼리게 만듭니다.
  4. 중앙화된 플랫폼의 부재: 현재로서는 "어떤 웹사이트가 어떤 도구들을 제공하는지" 알려주는 표준화된 디렉토리나 플랫폼이 없습니다. 사용자는 웹사이트에 방문하기전까지는 어떤 AI 기능을 사용할 수 있는지 알기 어렵습니다.

결론적으로,
MCP-B의 아이디어 자체는 기술적으로 매우 흥미롭고 혁신적이지만, 사용자와 개발자 모두에게 "왜 굳이 이 방식을 써야 하는가?"라는 근본적인 질문에 대한 명확한 답을 주지 못할 것 같습니다. 기존의 API 방식에 비해 얻는 이점은 불분명한 반면, 보안 우려와 개발 복잡성이라는 단점은 명확하기 때문입니다.

따라서 현재로서는 이 기술이 일부 매니아나 특정 목적을 가진 개발자들 사이에서 실험적으로 사용될 수는 있겠지만, 웹 생태계 전반으로 확대되기에는 많은 어려움이 있어 보입니다.

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 예상: RSS와 같은 길을 걷게 될 것. 기업들은 사용자가 데이터 활용 방식을 스스로 통제하는 걸 꺼리는 경향이 있음

    • REST API도 마찬가지로, 한때는 'API-first' 설계 바람과 함께 서비스 자동화·연동의 미래가 될 거라 기대됨. 그런데 비즈니스들이 이런 역량을 제공하면 자신의 수익 구조에 위협이 된다는 걸 빨리 자각해서 금방 방향이 꺾였음. 결국 모든 돈줄이 이런 권한을 사용자가 갖지 못하게 하는 데 있다는 점을 다시 깨달음

    • RSS는 실패한 것이 아니라 오히려 엄청난 성공을 거뒀다고 생각함. Google Reader가 사라진 뒤 다른 리더로 옮겨도 20년 넘게 RSS 피드가 문제없이 잘 동작하고 있음. RSS를 지원하지 않는 사이트는 거의 만나본 적이 없음

    • 대부분의 웹사이트가 RSS를 여전히 지원하고 있고, 일부는 페이지에 표시하지 않아도 기본적으로 피드가 존재함. 일부만 본문 전체를 공개하지 않는다 하더라도 업데이트 알림이나 자동화 트리거로 여전히 가치가 큼. RSS는 여전히 매우 유용하게 살아있는데, 마치 전자레인지처럼 당연히 존재하는 느낌임

    • 시장 구조에서 변화가 일어나서 이제는 대형 기업들이 콘텐츠 그 자체보다 '인텔리전스 레이어'에 집중하고 있음. 콘텐츠는 점점 상품화됨. Google은 사용자의 눈과 관심, 그리고 그들을 사로잡는 스마트 기술을 손에 넣어야 광고를 계속 팔 수 있음. Google이 RSS를 원하지 않았던 이유는 RSS가 Google Search를 우회할 수 있었기 때문임

    • AI가 곧 사람처럼 클릭하고 스크롤하는 능력을 갖게 되면, 또 한 번의 무한 경쟁이 벌어질 것임

  • Github 프로젝트의 기여 내역이 매우 흥미로움 (직접 링크 인용). MiguelsPizza가 3회, Claude가 2회 커밋했는데, Claude의 코드 변경량이 거의 압도적임

    • 일시적으로 확장 기능을 비공개 처리하면서 git 히스토리를 조정해서 실제 내역과 약간 차이가 있음. 그래도 Claude 코드가 전체의 약 85%를 작성한 건 사실임

    • 앞으로 이런 패턴(거대한 AI 기반 코드 기여)이 점점 더 많아질 것 같음

    • Claude의 커밋 그래프가 매우 독특함. Claude Code가 직접적으로 커밋하는 듯 보이긴 하지만 실제로는 거의 없음. claude 프로필도 참고

    • 실제 커밋 목록을 보면 전부 MiguelsPizza / Alex Nahas 명의로 되어 있음 (링크). 뭔가 이상해 보임

  • 블로그에서 발췌한 부분을 언급하며, MCP의 인증 문제에 대해 다룸. OAuth2.1은 장기적으로 봐도 괜찮지만, 사용자를 대신해 동작하는 에이전트에 맞춘 인증을 새로 재발명해야 하는 상황임. 다중 테넌트 앱 내에서 데이터 유출 위험이 아직 해결되지 않음

    • 모델의 피해 범위와 접근 데이터를 제한하는 것이 MCP의 큰 장점일 수 있음. 다중 테넌트 앱의 클라이언트 측 API는 이미 유저 범위로 제한되어 있을 것이라 기대되므로, 모델에 그것만 제공한다면 피해가 크지 않을 것임. Amazon 내부 인증 시스템과 OAuth2.1의 호환성 문제도 언급됨(Amazon에서는 인증이 다름)

    • OAuth2.1의 일부 기능이 이미 RFC 8693의 위임과 사칭에서 다뤄지는지 궁금함

    • 모델이 접근할 수 있는 범위는 결국 유저와 동일하므로 확실한 보안 구현은 웹사이트 관리자의 책임임

    • Oauth가 제대로 적용되지 않은 Amazon의 예시가 핵심 이슈는 아니라고 생각함. 사용자 권한 범위를 넘는 백도어 식 접근은 매우 위험함. MCP 앱의 모든 행동이 유저 액세스와 같은 범주로 기록된다면 컴플라이언스 이슈가 많아질 수 있음. 이런 관점에서 매우 흥미롭지만, 보안 측면에서는 우회로서 문제 소지가 클 것 같음

  • Swagger(OpenAPI) 명세를 공개하고 범용 swagger mcp 클라이언트만 있어도 이 모든 구현이 거의 대체 가능하지 않냐는 아이디어를 제시함. 사용자 스스로 인증 세션을 수동으로 열게 하면 될 듯함. Claude가 프롬프트/설정에서 API 키를 잘 파악해서 swagger 기반 API 클라이언트를 사용하면 같지 않겠냐고 제안함

    • MCP 등장 당시 모두가 가장 먼저 떠올린 방식임. 하지만 실제로는 너무 많은 툴이 존재해서 잘 작동되지 않는다는 점이 드러남. 그래도 이 분야에서 재미있는 시도들이 지속됨

    • API 키를 프롬프트에 넣지 말라는 주의 당부도 있음

    • Claude Code가 CLAUDE.md에 swagger.json 링크만 줘도 API 테스트가 정말 편리해짐

    • 직접 해보라고 격려함

  • 누가 타겟 유저인지 잘 모르겠음. 프런트엔드 테스트에서는 UI가 크게 바뀌면 테스트가 깨지는 게 오히려 유용함. 그 외 자동화 목적이라면 실제 API를 제공하는 편이 낫다고 생각함

    • 크롤러들과 본인이 VLM으로 우유 사는 작업 등이 실제 사용자에 해당함

  • "Home Depot에서 테이블을 만들려고 하면 오히려 더 힘들 것"이란 비유에, Home Depot에도 목재가 가득하다는 점을 들어 의문을 제기함

    • Home Depot에서는 이미 완성된 테이블도 판매함

    • Home Depot에는 더 좋은 정밀 공구는 물론, 전문가도 있어서 오히려 작업이 더 쉬워질 수 있음

    • '목재는 네가 상상해서 만들어내야 한다'는 뉘앙스로 농담함

    • 지적 사항을 반영해서 문구를 수정했다고 밝힘

  • MCP를 직접 사용해 보진 않았지만, 장애를 가진 사람 입장에서는 MCP가 브라우저·스마트폰 자동화에 있어 접근성(Accessibility) 관련 활용처가 크게 보임. 다만 이런 기술이 악의적 사용자에게 남용될 수 있어 실제로 메이저 웹/앱에서 도입할지는 의문임. 혹시 실제로 접근성 개선에 쓰고 있는 사례가 있는지 궁금함

    • 접근성 도구가 어떻게 악용될 수 있는지 더 구체적으로 궁금해함

  • MCP-B 오픈소스로 풀린 점이 고마움을 느낌. 대부분의 브라우저에서 일이 일어나지만, MCP는 AI 클라이언트가 작업한다는 전제가 조금 다름. 근본적으로 MCP-B가 웹 앱의 JS API를 LLM 서버와 바로 연동해 사용함과 어떻게 다른지 궁금함. 결국 똑같은 건지, 아니면 더 큰 그림이 있는지 질문함

    • 답변에서, MCP-B는 웹사이트 주인장이 별도의 AI 챗 기능을 직접 구현하거나 관리할 필요 없이, 표준 프로토콜로 사용자가 원하는 모델을 사이트의 여러 도구와 연동해 쓸 수 있다는 점이 근본적인 차이임을 설명함

  • 홈페이지 내용만 봐서는 잘 이해가 안 되고 Selenium의 브라우저 버전 느낌이라 여겨 질문함

    • 유사하지만 완전히 다름. Playwright나 Selenium은 브라우저 자동화 프레임워크이고, Playwright-MCP 서버에서 에이전트가 Playwright를 자동화에 활용할 수 있음. 반면 MCP-B는 웹사이트 내부에 MCP 서버를 두고, 브라우저 확장이나 JS 삽입으로 MCP-B 클라이언트를 실행함. Playwright는 화면을 직접 파싱하고, MCP-B는 표준화된 함수 호출 방식임. 블로그 코드 예시를 참고하라고 안내함

  • 무료 LLM 사용자를 대상으로 MCP로 브라우저 자동화가 시작되면 무료 모델도 캡차(Captcha)를 요구하는 세상이 올 것이라고 예상함. 문제는 캡차가 LLM에 그다지 효과적이지 않아서 결국 LLM들이 자동화 LLM의 접근을 막기 위해 서로 싸우는 이상한 로봇 전쟁 시대가 열릴 수도 있음

    • 이런 이야기에서는 결국 로봇들이 서로 같은 목표를 가지고 있다는 걸 알고 협력하게 된다는 결말로 흘러감
답변달기