Apple은 Safari Technology Preview 247에 공식 Safari MCP 서버를 탑재했으며, 이는 AI 에이전트가 디버깅, 테스트 및 자동화를 위해 브라우저와 상호작용하는 방식에 있어 진정한 변화를 예고합니다.

2026년 7월 초, Safari Technology Preview 247은 디버깅을 위해 AI 에이전트를 사용하는 모든 개발자의 이목을 집중시킨 무언가를 탑재하여 출시되었습니다. Apple은 웹 디버깅 작업을 위해 AI 어시스턴트가 Safari를 제어할 수 있게 해주는 Model Context Protocol (MCP)의 퍼스트 파티 구현체인 공식 Safari MCP 서버를 포함했습니다. 이 MCP 서버는 Safari에 이미 포함된 WebDriver 바이너리인 safaridriver에서 실행되며, URL 열기, DOM 읽기, 요소 클릭, 네트워크 탭 검사, 콘솔 출력 캡처, 스크린샷 찍기 등 핵심 디버깅 루프를 아우르는 17개의 도구를 제공합니다.

이것이 중요한 이유는 AI 에이전트를 위한 브라우저 자동화가 그동안 Chromium 단일 문화(monoculture)였기 때문입니다. Chrome DevTools MCP, Playwright MCP 또는 기타 Puppeteer 래퍼(wrapper)를 포함하여 이 이전의 모든 MCP 브라우저 도구는 Chromium 기반 브라우저를 실행해야 했습니다. Safari를 주력 브라우저로 사용하는 Mac 개발자들에게 이는 AI 에이전트가 버튼을 클릭할 수 있도록 별도의 두 번째 브라우저를 실행해야 함을 의미했습니다. Apple이 Safari 내부에 공식 MCP 서버를 배치한 것은 브라우저 벤더들이 이제 AI 기반 디버깅을 부차적인 실험이 아닌 일급 사례(first-class use case)로 보고 있음을 시사합니다.

Apple이 실제로 출시한 것

Safari MCP 서버는 의도적으로 작게 설계되었습니다. 수백 개가 아닌 17개의 도구를 제공하며, 그 각각은 일반적인 브라우저 자동화보다는 디버깅 워크플로를 목표로 합니다. 이 도구들은 탐색(navigation), DOM 검사, 요소 상호작용, 네트워크 요청 캡처, 콘솔 로그 검색 및 스크린샷 캡처를 다룹니다. 쿠키 조작, 로컬 스토리지 접근, 양식 자동 완성 또는 개인 브라우저 상태에 영향을 미치는 그 어떤 도구도 포함되어 있지 않습니다.

이 서버를 정의하는 설계 선택은 격리(isolation)입니다. Apple의 자체 문서에는 서버가 "Safari의 개인 정보(예: 자동 완성(AutoFill) 또는 기타 브라우저 활동)에 접근할 수 없습니다"라고 명확히 명시되어 있습니다. AI 에이전트가 연결되면, safaridriver는 상단에 "자동화에 의해 제어됨" 배너가 표시되는 새로운 창에서 깨끗한 WebDriver 세션을 실행합니다. 기존의 탭, 로그인 정보, 쿠키 또는 브라우징 기록 중 그 어떤 것도 해당 세션으로 유출되지 않습니다. 디버깅 도구로서 이는 올바른 아키텍처(architecture)입니다. 재현 가능하고, 샌드박스(sandboxed)화되어 있으며, 개인 상태가 테스트 실행을 오염시키지 않습니다. 하지만 이는 또한 AI 에이전트가 분석 대시보드 확인, 관리자 패널에서 데이터 추출, 또는 로그인 장벽 뒤에 있는 기능 테스트와 같이 사용자의 실제 인증된 세션이 필요한 작업에는 도움을 줄 수 없음을 의미합니다.

이 서버는 전적으로 사용자의 기기에서 실행됩니다. 페이지 콘텐츠, 스크린샷, 텔레메트리(telemetry)가 Apple로 전송되지 않습니다. 이는 다른 모든 MCP 서버가 사용하는 것과 동일한 전송 방식인 stdio를 통해 통신하는 로컬 전용(local-only) MCP 서버입니다. 설정에는 MCP 플래그와 함께 safaridriver를 활성화하는 한 줄의 명령어가 필요하며, 현재는 안정적인(stable) Safari 릴리스가 아닌 Safari Technology Preview에서만 사용할 수 있습니다.

Chromium 단일 문화(Monoculture)가 문제였던 이유

맥락을 설명하자면, 이전에 존재했던 모든 MCP 브라우저 자동화 도구는 Chromium에 의존했습니다. Chrome DevTools MCP는 Chrome DevTools Protocol을 기반으로 작동합니다. Playwright MCP는 기본적으로 Chromium에서 실행됩니다. Puppeteer는 Chromium 전용입니다. 만약 AI 에이전트가 웹 페이지와 상호작용해야 한다면, 유일한 옵션은 Chrome을 실행하는 것이었으며, Chrome은 대부분의 개발자 MCP 설정에서 가장 큰 리소스 소모 요인이었습니다.

Apple Silicon Mac에서 MCP 브라우저 도구를 실행하는 개발자들의 실제 측정 결과에 따르면, Chrome은 유휴(idle) 상태에서 815%, 활성 사용 중에는 2540%의 CPU를 소모하며, 브라우저 프로세스 하나만으로도 200~400MB 사이의 메모리를 사용합니다. 이에 비해 Safari는 유휴 상태에서 CPU 사용량이 약 0.1%에 불과합니다. 데이터베이스, 파일 시스템, API를 위해 이미 여러 개의 MCP 서버를 실행 중인 상황에서 Chromium 브라우저 프로세스를 추가하는 것은 시스템에 큰 부담을 줍니다.

이는 단순히 리소스 사용량에 관한 문제만이 아닙니다. Chromium만이 자동화할 가치가 있는 유일한 브라우저라는 생태계 내에 내재된 가정에 관한 문제입니다. Safari는 특히 모바일에서 실제 트래픽의 상당 부분을 차지하고 있으며, WebKit 렌더링의 특이점(quirks)은 Blink의 특이점과 다릅니다. 역사적으로 Safari에서만 나타나는 레이아웃 버그를 디버깅한다는 것은 문제를 수동으로 재현해야 함을 의미했습니다. WebKit에서 네이티브로 실행되는 MCP 서버는 AI 에이전트에게 Safari 특화 디버깅으로 가는 직접적인 경로를 제공합니다.

AI 네이티브 개발 패턴 (AI-native development patterns)을 향한 광범위한 변화는 개발자가 도구를 사용하는 방식을 재편해 왔으며, 브라우저 디버깅은 여전히 단일 엔진에 묶여 있던 마지막 보루 중 하나였습니다.

커뮤니티의 대응: safari-mcp

Apple이 공식 서버를 구축하는 동안, Achiya Cohen이라는 개발자는 이미 2026년 3월에 safari-mcp라는 독립적인 Safari MCP 서버를 출시했습니다. 두 도구는 서로 다른 영역을 차지하고 있으며, 그 차이를 이해하면 각각의 실제 용도가 무엇인지 알 수 있습니다.

커뮤니티 도구는 Technology Preview가 아닌 안정적인(stable) Safari에서 실행됩니다. 이 도구는 이중 엔진 아키텍처를 사용합니다. 대부분의 명령에는 AppleScript 브릿지를 사용하며, 닫힌 Shadow DOM 트리를 관통하거나 엄격한 콘텐츠 보안 정책 (Content Security Policy, CSP) 헤더가 있는 사이트에서 프레임워크 내부 구조에 접근하는 것과 같은 고급 시나리오를 위해 선택적인 Safari 웹 확장 프로그램 (Safari Web Extension)을 사용합니다. Apple의 서버가 17개의 도구를 제공하는 반면, safari-mcp는 96개까지 성장했습니다. 여기에는 네트워크 모킹 (network mocking) 및 스로틀링 (throttling), 전체 쿠키 및 스토리지 접근, IndexedDB 검사, CSS 커버리지 분석, 디바이스 에뮬레이션 프리셋, 그리고 테이블, 메타데이터, 링크, 이미지를 위한 구조화된 데이터 추출 기능이 포함되어 있습니다.

결정적인 차이점은 세션 처리 (session handling)입니다. Apple의 서버는 AI 에이전트에게 살균된 빈 방을 제공합니다. 반면 커뮤니티 도구는 에이전트가 당신이 이미 앉아 있는 방, 즉 당신의 실제 Gmail 로그인, GitHub 세션, 그리고 인증된 대시보드 탭이 있는 방으로 걸어 들어갈 수 있게 해줍니다. AI 에이전트가 Google Search Console 순위를 확인하거나, 분석 도구에서 데이터를 가져오거나, 인증 뒤에 숨겨진 기능을 테스트하기를 원하는 개발자들에게 이 커뮤니티 도구는 재인증 단계를 완전히 제거해 줍니다. 트레이드오프 (tradeoff)는 AI 에이전트에게 당신의 실제 브라우저 상태에 대한 접근 권한을 부여한다는 점이며, 이는 각 개발자가 자신의 보안 편의 수준에 따라 신중히 고려해야 할 결정입니다.

Apple이 공식 서버를 출시했을 때, Cohen은 당황하지 않았습니다. 그는 17개의 도구를 모두 읽고 비교 글을 작성했으며, 두 도구 모두 존재해야 한다는 결론을 내렸습니다. Apple은 클린룸 디버거 (clean-room debugger)를 만들었습니다. 그는 당신이 매일 사용하는 브라우저를 구동하기 위한 도구를 만들었습니다. 포지셔닝은 명확하며 어느 쪽도 서로를 대체하지 않습니다.

개발자 워크플로(Workflow)의 변화

Safari MCP 서버와 커뮤니티 대안이 결합됨으로써, Safari는 더 이상 에이전트형 AI (agentic AI) 생태계에서 빠져 있지 않게 되었습니다. 이제 Mac 사용자 개발자들은 Chrome을 설치하거나, Playwright 브라우저 바이너리를 다운로드하거나, 디버그 포트(debug ports)를 설정할 필요 없이 AI 에이전트에게 WebKit에 대한 직접적인 접근 권한을 부여할 수 있습니다. MCP 설정은 다른 모든 MCP 서버가 사용하는 것과 동일한 세 줄의 JSON 블록이며, 동일한 설정 파일에 배치됩니다.

디버깅 워크플로(Workflow) 측면에서 이는 몇 가지 구체적인 패턴을 제시합니다. AI 에이전트는 MCP 도구 인터페이스를 벗어나지 않고도 Safari에서 페이지를 열고, WebKit이 보는 방식 그대로 렌더링된 DOM을 읽으며, 엔진 간의 레이아웃 차이를 확인하고, WebKit 전용 경고를 위해 콘솔을 캡처하며, 결과물을 스크린샷으로 찍을 수 있습니다. 여러 브라우저에 걸쳐 테스트를 수행하는 팀의 경우, 이는 별도의 수동 단계 없이 CI 파이프라인이나 로컬 개발 루프(local dev loop)에 Safari 체크를 포함할 수 있음을 의미합니다.

리소스(resource) 측면의 이점 또한 실질적입니다. Safari MCP는 Node.js 프로세스를 위해 약 30MB의 메모리를 사용하며, 그 외에는 이미 열려 있는 탭을 위해 Safari가 사용 중인 메모리만큼만 사용합니다. 별도의 두 번째 브라우저 프로세스나 중복된 렌더링 엔진, 디버그 포트 오버헤드가 없습니다. 배터리로 작업하는 개발자들에게 Safari MCP와 Chrome DevTools MCP의 차이는 전체 업무 시간 동안 CPU 발열과 배터리 잔량 모두에서 측정 가능한 수준으로 나타납니다.

알아두어야 할 한계점

공식 Safari MCP 서버에는 개발자가 도입하기 전에 이해해야 할 명확한 공백이 있습니다. 이 서버는 macOS에 포함된 안정화 버전(stable release)이 아닌 Safari Technology Preview를 요구합니다. 2026년 7월 기준으로, 안정화된 Safari 버전의 safaridriver에는 MCP 플래그가 존재하지 않습니다. 또한 macOS 전용인데, 이는 Safari 도구로서 예상 가능한 부분이지만 크로스 플랫폼(cross-platform) 워크플로를 가진 팀에게는 언급할 가치가 있습니다. Safari는 항상 실제 눈에 보이는 브라우저로 작동하기 때문에 헤드리스(headless) 모드가 없으며, 따라서 가상 디스플레이를 구성하지 않는 한 CI 서버에서의 사용 사례는 제한적입니다.

더욱 중요한 점은, 공식 서버에 성능 감사(performance auditing) 도구가 부족하다는 것입니다. Lighthouse와 유사한 기능, 성능 추적(performance trace) 캡처, CPU 프로파일링(CPU profiling), 그리고 메모리 스냅샷(memory snapshot) 기능이 없습니다. 이러한 기능들은 여전히 Chrome DevTools MCP의 영역으로 남아 있습니다. 전체 성능 디버깅 스위트(debugging suite)가 필요한 개발자들에게 가장 실용적인 설정은 아마도 두 서버를 병행하여 사용하는 것일 것입니다. WebKit 렌더링 확인 및 일상적인 자동화를 위해서는 Safari MCP를, Lighthouse나 성능 추적이 구체적으로 필요한 5%의 작업을 위해서는 Chrome DevTools MCP를 사용하는 방식입니다.

커뮤니티의 safari-mcp 도구는 이러한 격차 중 일부, 특히 세션 처리(session handling)와 도구의 폭(tool breadth) 측면을 보완하지만, 그 나름의 트레이드오프(tradeoffs)가 존재합니다. AppleScript 백엔드는 macOS 업데이트로 인해 시스템 API가 변경될 때 작동이 중단될 수 있으며, 이는 macOS 26에서 실제로 발생했습니다. 선택 사항인 Safari 확장 프로그램(Safari Extension)은 일회성 Xcode 빌드가 필요하며, 이 도구는 브라우저 제조사가 아닌 단일 개발자에 의해 유지 관리됩니다.

향후 전망

Apple이 Safari 내부에 공식 MCP 서버를 탑재하여 출시하는 것은 이번 특정 릴리스 이상의 의미를 지닌 신호입니다. 브라우저를 만드는 회사가 AI 에이전트의 접근을 사후 고려 사항이 아닌 내장 기능으로 취급할 때, 해당 패턴은 표준화됩니다. 향후 예상되는 단계는 MCP 플래그가 안정화된(stable) Safari에 도달하고, 도구의 수가 17개를 넘어 성장하며, 다른 브라우저 제조사들이 자체적인 퍼스트 파티(first-party) MCP 서버로 대응하는 것입니다. geckodriver에 자체적인 WebDriver 구현을 갖춘 Firefox가 자연스러운 후보가 될 것입니다.

개발자 경험 (Developer Experience)에 미치는 영향은 상당합니다. 모든 주요 브라우저가 MCP 서버를 탑재하게 되면, 교차 브라우저 디버깅 (cross-browser debugging)을 위한 개발자 워크플로(workflow)는 "각 브라우저를 열어 수동으로 확인하기"에서 "에이전트에게 여러 엔진을 통해 확인하도록 요청하기"로 전환됩니다. 에이전트는 Safari, Chrome, Firefox MCP 서버에서 동일한 URL을 동시에 열고, 렌더링된 결과물을 비교하며, 차이점을 찾아낼 수 있습니다. 그러한 워크플로는 현재 존재하지 않지만, 그 구성 요소들이 하나씩 갖춰지고 있습니다.

현재로서는 Mac 개발자들을 위한 실질적인 시사점이 명확합니다. 만약 AI 에이전트가 WebKit에서 페이지가 어떻게 렌더링되는지 검사할 수 있도록 샌드박스화된 퍼스트 파티 (first-party) 방식을 원한다면, Technology Preview 247에 포함된 Safari MCP 서버를 바로 사용할 수 있습니다. 만약 에이전트가 17개가 아닌 96개의 도구를 사용하여 실제 사용 중인 세션이 포함된 실제 Safari를 제어하기를 원한다면, 커뮤니티의 safari-mcp 도구를 오늘 바로 npm에서 사용할 수 있습니다. 두 방식 모두 오픈 소스이며, 로컬에서 실행되고, 3개월 전에는 없었던 Safari의 MCP 참여 기회를 제공합니다.

추가 읽을거리: Model Context Protocol 명세 (specification), WebKit.org의 Safari MCP 서버 발표, 그리고 GitHub의 커뮤니티 safari-mcp 프로젝트.