2P by GN⁺ | ★ favorite | 댓글 2개
  • Safari MCP 서버는 코딩 에이전트를 실제 Safari 창에 연결해, 웹 개발·디버깅 중 브라우저에서 보이는 상태를 직접 확인하게 함
  • 에이전트는 DOM, 네트워크 요청, 스크린샷, 콘솔 출력에 접근해 코드만으로는 알기 어려운 렌더링 결과와 사용자 경험을 확인할 수 있음
  • Safari 호환성, 성능, 접근성, 폼·체크아웃 상태 검증처럼 브라우저별 차이가 중요한 작업에서 반복적인 창 전환과 프롬프트 설명 부담을 줄임
  • 탭 제어, URL 이동, JavaScript 실행, 네트워크 요청 조회, 페이지 콘텐츠 추출, DOM 상호작용, 스크린샷, 뷰포트·미디어 에뮬레이션 도구를 제공함
  • 서버는 로컬 머신에서만 실행되고 자체 네트워크 호출을 하지 않지만, 캡처된 페이지 데이터는 사용자가 실행 중인 에이전트로 직접 전달되므로 신뢰할 수 있는 에이전트 사용이 필요함

Safari MCP 서버의 역할

  • Safari Technology Preview 247에 Safari MCP 서버가 추가됨
  • 웹 개발자를 위한 Model Context Protocol 서버로, 에이전트를 Safari 브라우저 창에 연결함
  • 코드가 브라우저에서 실제로 어떻게 렌더링되는지 에이전트가 확인할 수 있어, 코드 분석과 브라우저 상태 확인 사이의 간극을 줄임
  • MCP 호환 클라이언트라면 Safari MCP 서버에 연결 가능함
  • 연결된 에이전트는 사용자가 브라우저에서 보는 상태를 더 가깝게 재현할 수 있음
    • DOM 접근
    • 네트워크 요청 접근
    • 스크린샷 접근
    • 콘솔 출력 접근

디버깅 반복을 줄이는 방식

  • 일반적인 웹 디버깅은 브라우저에서 문제를 보고, 콘솔과 스타일 탭을 확인한 뒤, 다시 코드로 돌아가 수정하는 흐름이 반복됨
  • 에이전트를 쓰더라도 스크린샷을 찍고 문제를 설명한 뒤, 수정이 부족하면 브라우저·프롬프트·에이전트를 다시 오가야 함
  • Safari MCP 서버는 에이전트가 브라우저 상태를 직접 확인하게 해 창 전환과 자세한 프롬프트 작성 부담을 줄임
  • 사용자가 완벽한 프롬프트로 상황을 설명하지 않아도, 에이전트가 Safari에서 확인 가능한 정보를 바탕으로 다음 작업을 이어갈 수 있음

주요 사용 사례

  • Safari에서 웹 개발

    • 에이전트가 코드뿐 아니라 Safari에서의 실제 렌더링 결과까지 확인할 수 있음
  • Safari 호환성 개선

    • 한 브라우저에서만 테스트하면 다른 브라우저의 잠재적 버그를 놓칠 수 있음
    • 에이전트가 Safari에서 사이트를 열고 computed style, 레이아웃, 기대 동작과의 차이를 확인할 수 있음
  • 성능 분석

    • 페이지에서 JavaScript를 평가해 navigation timing, resource load time 같은 성능 지표를 드러낼 수 있음
    • 사이트를 느리게 만드는 부분을 찾으면 수정 대상을 좁히기 쉬움
  • 접근성 점검

    • 누락된 label, 부적절한 ARIA 속성, 낮은 contrast 같은 일반적인 접근성 문제를 확인할 수 있음
  • 사용자 상태 검증

    • 폼 상태 확인, selector로 요소 조회, 특정 상호작용 확인, 체크아웃 흐름의 여러 상태 표시 등을 수행할 수 있음

제공 도구

  • browser_console_messages: 현재 탭 또는 지정 탭의 버퍼링된 콘솔 로그를 반환함
  • browser_dialogs: 브라우저 dialog 목록을 조회하고 응답을 처리함
    • accept, dismiss, JavaScript prompt 텍스트 입력을 지원함
  • create_tab, close_tab, switch_tab, list_tabs: 브라우저 탭 생성·닫기·전환·목록 조회를 수행함
  • navigate_to_url: URL로 이동하고 로드된 페이지 콘텐츠를 반환함
  • page_info: 현재 페이지의 URL, title, loading state를 확인함
  • evaluate_javascript: 페이지 안에서 JavaScript 코드를 실행하고 결과를 반환함
  • list_network_requests: 현재 탭의 네트워크 요청 요약을 조회함
    • URL, method, status, timing 포함
  • get_network_request: 단일 네트워크 요청의 상세 정보를 조회함
    • headers, body, timing 포함
  • get_page_content: 페이지 텍스트 콘텐츠를 markdown, HTML, JSON 등 여러 형식으로 추출함
  • page_interactions: click, type, scroll, hover, keyPress 같은 DOM 상호작용을 순차 수행함
  • screenshot: 현재 페이지를 PNG 스크린샷으로 캡처함
  • set_emulated_media: responsive-design 테스트를 위해 print 같은 CSS media type을 에뮬레이션함
  • set_viewport_size: 브라우저 viewport 크기를 CSS pixel 단위로 설정함
  • wait_for_navigation: 현재 페이지 로딩 완료를 기다리고 최종 URL과 title을 반환함

시작 방법

  • 먼저 Safari Technology Preview를 설치해야 함
  • 설치 후 Safari 설정에서 다음 항목을 켜야 함
    • Safari Settings > Advanced > Show features for web developers
    • Safari Settings > Developer > Enable remote automation and external agents
  • Claude를 쓰는 경우 터미널에서 다음 명령을 사용할 수 있음
claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp  
  • Codex를 쓰는 경우 다음 명령을 사용할 수 있음
codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp  
  • 다른 에이전트는 mcp.json 또는 config.json에 다음 설정을 넣을 수 있음
"safari-mcp-stp": {  
  "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",  
  "args": ["--mcp"]  
}  
  • 위 예시는 서버 이름을 safari-mcp-stp로 두지만, safari처럼 원하는 이름을 사용할 수 있음

프롬프트와 에이전트 동작

  • 설치 후 다음 같은 간단한 프롬프트로 시작할 수 있음
Find bugs on my site in Safari  
How accessible is my site in Safari?  
See how my website performs in Safari  
  • 에이전트마다 동작 방식은 조금씩 다르지만, Safari MCP 서버를 명시적으로 쓰라고 말하지 않아도 스스로 사용할 수 있음
  • 예시 흐름에서는 사용자가 Safari의 flight page 버그를 물으면, 에이전트가 두 가지 버그를 찾고 Safari 사용자에게 문제를 일으킬 수 있는 항목을 추가로 확인함
  • 초기 요청만으로도 Safari MCP 서버의 도움을 받아 이후 확인과 문제 식별을 이어갈 수 있음

로컬 실행과 데이터 처리

  • Safari MCP 서버는 전적으로 로컬 머신에서 실행됨
  • 자체적으로 네트워크 호출을 하지 않음
  • Safari의 개인 정보에는 접근하지 않음
    • AutoFill
    • 기타 브라우저 활동
  • 페이지 콘텐츠, 스크린샷, 콘솔 로그를 캡처하면 해당 데이터는 Apple이 아니라 사용자가 실행 중인 에이전트로 직접 전달됨
  • 이후 데이터 처리 방식은 사용하는 에이전트와 모델에 따라 달라짐
  • 브라우저 접근 권한을 주는 다른 에이전트와 마찬가지로, 신뢰하는 에이전트만 사용해야 함

WebKit이 기대하는 활용

  • 웹 개발에는 AI를 쓰는 방식과 쓰지 않는 방식이 모두 있음
  • AI가 개발 흐름의 일부라면 Safari MCP 서버가 생산성을 높이는 데 도움이 될 수 있음
  • 에이전트가 Safari 브라우저에서 화면과 동작을 이해하도록 도와, Safari 테스트와 디버깅을 더 쉽게 만드는 것이 목적임
  • 문제가 있으면 WebKit bug report로 이슈를 제출할 수 있음

댓글과 토론

safari mcp라니.. 감회가 새롭네요 ㅎㅎ

Hacker News 의견들
  • 2025년 11월부터 Chrome의 공식 MCP DevTools 서버를 쓰고 있음
    https://github.com/ChromeDevTools/chrome-devtools-mcp
    그전에는 Chrome 웹 드라이버를 썼지만, MCP가 더 빠르고 기능도 많았음
    Firefox에서도 동작하는지 확인하려고 LLM에게 Firefox 공식 MCP로 페이지를 테스트하라고 지시함
    https://github.com/mozilla/firefox-devtools-mcp
    이제 Safari도 호환성 테스트에 추가할 예정임

    • 이것들과 Playwright MCP를 Chrome/Firefox 설정으로 쓰는 것 사이에 차이가 있는지 궁금함
    • 가끔은 반대로, LLM이 브라우저를 조작하게 하는 대신 내가 브라우저에서 수동으로 한 작업이 LLM에게 보이길 원할 때가 있음
      그 용도를 커버하려고 MCP를 만들었음
  • Federico Viticci가 MacStories, Mastodon, Connected 팟캐스트 최신 에피소드에서 이게 무엇을 의미하는지 조금 더 자세히 다뤘고, 일반인에게도 더 접근하기 쉬움
    원문에 있는 링크들도 꼭 보는 게 좋음
    https://www.macstories.net/linked/safaris-new-mcp-server-is-...
    https://mastodon.macstories.net/@viticci/116847167023618099
    https://relay.fm/connected/610

  • 테스트뿐 아니라 일상적인 작업에도 특히 기대하고 있음
    내가 로그인해 둔 브라우저에서 에이전트가 대신 브라우저 자동화를 자연스럽게 수행할 수 있으면, 나와 에이전트 사이의 인계가 훨씬 매끄럽게 느껴질 듯함
    Chrome이 배터리를 많이 먹어서 Safari를 주 브라우저로 써왔기 때문이기도 함

    • Hyperia를 만들고 있는데, Electron 기반 웹 패널을 에이전트가 완전히 제어해서 꽤 과격한 작업을 할 수 있음: https://github.com/deepbluedynamics/hyperia
      에이전트 컨테이너 오케스트레이터도 쓰고 있으며, 컨테이너의 포트를 노출하는 MCP 도구가 있어서 작업 결과를 웹 패널에 표시할 수 있음: https://github.com/DeepBlueDynamics/nemesis8
      오늘 n8에 Safari MCP 연결을 추가할 예정이고, 더 많은 기능이 들어간 새 릴리스가 오늘 밤 나올 예정임
    • “Safari의 개인 정보, 예를 들면 자동 완성이나 다른 브라우저 활동에는 접근하지 않는다”는 문구를 보면, 에이전트가 상호작용하는 인스턴스에는 로그인되어 있지 않다는 뜻으로 읽힘
    • “나와 에이전트 사이의 인계가 더 매끄럽다”는 부분이 무서움
      브라우저 반대편의 서비스 입장에서는 누가 무엇을 하는지 알 방법이 없기 때문임
      에이전트를 어떻게 제한하는지, 내가 한 일과 에이전트가 한 일을 어떻게 추적하는지 모르겠음
      뭔가 놓치고 있는 건지, 시대에 뒤처진 건지 궁금함
  • 개인적으로는 Playwright-CLI를 추천함: https://github.com/microsoft/playwright-cli
    내가 써본 MCP 서버들보다 훨씬 빠르게 동작했음

    • 지속적인 브라우저 세션이 필요하면 spel(https://github.com/Blockether/spel)도 있음
      데몬을 통해 Chromium, Firefox, WebKit 엔진을 지원함
    • Playwright는 종단 간 테스트에 훌륭하고 Electron과도 잘 맞음
      다만 나는 Playwright MCP를 쓰고 있음
    • 이 모든 게 나에게는 무겁게 느껴졌음
      전체 브라우저, 디버그 프로토콜, 매번 읽을 때마다 DOM 덤프가 들어가는데, MCP냐 CLI냐보다 그 아래에 무엇이 있는지가 더 중요함
      그래서 시스템 웹뷰를 직접 구동하고 DOM 대신 상태 토큰과 델타를 반환하는 작은 Rust 바이너리를 만들었음
      HN 첫 페이지를 로드해도 에이전트에게 약 50토큰밖에 들지 않음
      MCP와 CLI를 모두 지원하니 에이전트가 선호하는 쪽을 고르면 됨
      https://github.com/frane/vibesurfer
  • Apple이 제공하는 safaridriver는 몇 년 전부터 있었음
    WebDriver W3C를 사용하며 Safari 인스턴스와 상호작용하는 데 쓸 수 있음

  • Apple이 정말 웹 개발자를 신경 쓰는지 모르겠음
    Apple 기기가 없으면 Safari에서 어떻게 테스트하나
    Safari만 들어간 최소한의 가상 머신을 Apple이 만드는 게 그렇게 어려울까

    • Apple 기기 없이 Safari를 어떻게 테스트하냐는 건, PlayStation 없이 PlayStation 게임을 어떻게 테스트하냐는 질문과 비슷함
      하드웨어 없이 하드웨어 펌웨어를 어떻게 테스트하나, 에뮬레이터나 시뮬레이터가 없는데 필요한 하드웨어 없이 프로그램을 어떻게 실행하나와 같은 문제임
      특정 하드웨어에서만 돌아가고 가상화나 에뮬레이션이 없으면, 그 하드웨어 밖에서 테스트할 수 없는 것이고 이는 컴퓨팅 초창기부터 수십 년간 그래왔음
      Apple의 결정은 어렵고 쉬움보다 전략으로 정해지는 경우가 많고, 그들이 벽으로 둘러싼 정원을 만들고 있다는 건 꽤 명확함
      마음에 들지 않으면 나머지 사람들처럼 거기서 놀지 않으면 됨
    • Chrome이 지배적인 상황에서도 Edge 등 여러 브라우저를 놓치고 싶지 않기 때문에 Chromium을 테스트함
      마찬가지로 완벽하진 않지만 WebKit을 테스트할 수 있고, 원하면 Linux나 Windows에서도 가능함:
      https://orionbrowser.com/platforms/linux
      Apple이 Safari 가상 머신 사업을 할 것 같진 않지만, macOS 가상 머신이 필요하다면 클라우드 서비스 제공자를 보면 됨: https://aws.amazon.com/ec2/instance-types/mac/
      많은 곳이 소프트웨어 테스트 오케스트레이션을 미리 연결해 둠
    • Apple이 이 새 도구를 막 출시했으니, 웹 개발자를 신경 쓴다고 볼 수 있음
    • Linux나 OS X에서 IE를 테스트하던 방식과 같음
  • 최근에는 에이전트에게 Chrome을 실행하고 CDP로 직접 통신하라고 시키고 있는데, 꽤 잘 동작함

    • 그 방식도 한번 시도해봐야겠음
      Playwright와 비교하면 어떤지 궁금함
      웹 개발 관점에서는 여러 브라우저에서 쓸 수 있다는 게 Playwright의 장점으로 보임
      브라우저별 도구가 더 빠르거나 토큰 효율이 좋다면 작업 자동화와 Claws에는 그쪽이 더 나은 선택일 듯함
    • 맞음. 이 방식이 MCP 경로보다 훨씬 잘 동작하고 더 빠름
  • “웹을 만드는 방법은 AI를 쓰든 쓰지 않든 많습니다. AI가 작업 흐름의 일부라면 이 도구가 생산성을 높이는 데 도움이 될 것이라고 생각합니다. 아니라면 그것도 괜찮습니다.”
    2026년에 이런 말을 하는 게 묘함
    코드를 직접 쓰고 모든 걸 에이전트에게 위임하지 않으면 어떤 사람들에게는 초보자 취급을 받는 시대이기 때문임

    • 2년 전에는 그 반대가 말도 안 되는 소리 취급을 받았음
      이제는 AI를 쓰는 사람들이 그 사실을 숨기지 않아도 돼서 좋음
    • 어느 부분이 이상한지 모르겠음
      광적인 반AI 진영을 달래려고 이런 면책 문구를 넣어야 했다는 점이 이상한 건가
      이건 명백히 AI 보조 개발을 위한 도구인데, “AI 안 쓰는 분들에게도 위로를 보냅니다” 같은 문장을 붙여야 했다는 게 오히려 매우 이상함
      다만 네가 생각하는 방향과는 다르게 이상함
  • 브라우저 자동화용 MCP가 흥미로운 이유는 Safari의 WebKit 엔진이 대부분의 AI 에이전트가 쉽게 다루기 어려운 쪽이기 때문임
    Playwright와 Puppeteer는 Chromium 중심이라서, Safari용 MCP 서버가 있으면 에이전트 작업 흐름의 교차 브라우저 테스트에서 실제 빈틈을 메울 수 있음