어제 Apple은 제가 safari-mcp를 오픈 소스로 공개한 이후 어느 정도 예상해 왔던 일을 실행했습니다. 바로 그들 자체의 Safari MCP 서버를 출시한 것입니다.

이 기능은 WebKit 팀이 구축한 Safari Technology Preview 247 (2026년 7월 1일)에 포함되었습니다. 이제 Claude, Cursor 등 MCP 호환 에이전트(Agent)라면 무엇이든 Safari 창에 직접 연결하여 DOM을 검사하고, 콘솔을 읽고, 네트워크 요청을 캡처하며, 스크린샷을 찍을 수 있습니다.

저는 정확히 이와 동일한 기능을 수행하는 도구를 유지 관리하고 있습니다. 그래서 당연한 일을 했습니다. 릴리스 노트를 전부 읽고, 약 17개의 모든 도구를 살펴본 뒤, 가장 중요한 단 하나의 질문을 던졌습니다 — 내가 무언가를 바꿔야 할까?

솔직한 답변을 드리겠습니다.

Apple이 실제로 출시한 것

공정하게 평가하자면, 설계가 깔끔하고 개인정보 보호 측면이 매우 뛰어납니다:

• Safari의 내장 WebDriver 바이너리인 safaridriver에서 실행됩니다. STP에서 _"원격 자동화 및 외부 에이전트(remote automation and external agents)"_를 활성화하고 명령 하나로 연결할 수 있습니다.
• 전적으로 로컬에서 실행됩니다. Apple로의 네트워크 호출이 없습니다. 페이지 콘텐츠, 스크린샷, 콘솔 로그는 Apple의 서버가 아닌 사용자의 에이전트로 직접 전달됩니다.
• 약 17개의 도구는 실제 디버깅 루프를 다룹니다: navigate_to_url, get_page_content, evaluate_javascript, page_interactions (클릭/타이핑/스크롤/호버), screenshot, list_network_requests, browser_console_messages, browser_dialogs, 탭 관리, set_viewport_size, set_emulated_media.

만약 당신의 업무가 "에이전트가 WebKit에서 페이지가 렌더링되는 방식을 디버깅하게 하는 것"이라면, 이것은 이를 수행하기 위한 퍼스트 파티(First-party)의 잘 만들어진 방식입니다. 또한 이는 제가 구축해 온 카테고리가 실재한다는 가장 강력한 검증이기도 합니다.

모든 것을 결정짓는 한 문장

Apple의 공식 문서에 따르면 다음과 같습니다:

"Safari MCP 서버는 Safari에 있는 사용자의 개인 정보(예: 자동 완성(AutoFill) 또는 기타 브라우저 활동)에 접근할 수 없습니다."

그 문장이 전부입니다. safaridriver는 **격리된 WebDriver 자동화 세션 (isolated WebDriver automation session)**을 구동합니다. 즉, "자동화에 의해 제어됨"이라는 배너가 표시되는 클린룸(clean-room) 창입니다. 여러분이 이미 사용 중인 탭과 로그인 정보가 담긴 그 Safari가 아닙니다.

그리고 이것은 버그가 아닙니다. 디버깅 도구로서 격리된 세션은 올바른 설계입니다. 재현 가능하고, 개인 상태(personal-state) 유출이 없으며, 표준 기반입니다.

하지만 이는 제가 만든 것과는 정반대입니다.

safari-mcp는 나머지 95%를 위해 만들어졌습니다

저는 렌더링을 디버깅하기 위해 safari-mcp를 만든 것이 아닙니다. 에이전트가 네이티브 AppleScript와 Safari 확장 프로그램을 사용하여, 포커스를 뺏지 않고 백그라운드에서, 모든 Mac의 안정적인 Safari 상에서, 제가 이미 로그인해 있는 브라우저(Gmail, GitHub, Ahrefs, 은행 등)를 직접 제어할 수 있도록 만들기 위해 제작했습니다.

그래서 제가 README에 솔직하게 적어둔 비교표는 다음과 같습니다:

	safari-mcp	Apple safaridriver --mcp
실제 로그인 / 쿠키	✅ 실제 Safari 사용	⚠️ 격리된 자동화 세션
...

이 글을 쓰기 전 제 컴퓨터에서 직접 확인했기에, 솔직하게 말씀드리고 싶은 두 가지 사실이 있습니다:

1. safaridriver --mcp는 STP 247에만 존재합니다. Safari 26.5와 함께 제공되는 안정적인 safaridriver에는 --port, --bidi, --enable, --diagnose는 있지만 --mcp는 없습니다. 따라서 현재 Apple의 서버를 사용하려면 Technology Preview를 설치해야 합니다.
2. 격리된 세션은 로그인이 불가능함을 의미합니다. 이것이 바로 제가 safari-mcp를 통해 극복하고자 했던 장벽입니다.

그렇다면 제가 무엇을 바꾸고 있나요? 네, 세 가지입니다. 하지만 그 중 어느 것도 "전환(switch)"은 아닙니다.

1. 코드가 아닌 포지셔닝(Positioning). Apple이 safari-mcp를 쓸모없게 만든 것이 아니라, 그것이 _무엇을 위한 것인지_를 명확히 해준 것입니다. Apple의 서버는 클린룸 디버거입니다. 저의 도구는 "이미 신뢰하고 있는 브라우저를 제어하는" 도구입니다. 역할이 다릅니다. 저는 이 점을 명시하기 위해 README를 업데이트했습니다.

2. 선택적 safaridriver 백엔드 — 나중에, 지금은 아닙니다. 저의 아키텍처는 이미 듀얼 엔진(extension + AppleScript) 구조입니다. 표준 기반의 깨끗한 세션(clean session)을 특별히 원하는 사람들을 위해 세 번째 선택적 WebDriver 백엔드를 추가하는 것은 재작성이 아닌 자연스러운 확장입니다. 이는 STP가 안정화되는 것에 따라 결정될 예정이므로, 일단 기다리고 있습니다.

3. 그들이 더 잘하는 단 한 가지를 가져오기. WebDriver 입력은 이벤트를 합성(synthesize)하는 매우 견고하고 공식적으로 지원되는 방식입니다. 저의 네이티브 입력(native-input) 경로는 CGEvent에 의존하는데, 이는 macOS 버전이 바뀔 때마다 취약해질 수 있습니다. safaridriver는 더 안정적인 입력 폴백(fallback)을 위한 좋은 모델입니다. 이것은 제가 사용자들에게 제공해야 할 진정한 개선 사항입니다.

요점 (The takeaway)

플랫폼 벤더가 여러분의 오픈 소스 도구에 대한 공식 버전을 출시하면, 본능적으로 패닉에 빠지게 됩니다. 하지만 "공식(official)"과 "대체(replacement)"는 서로 다른 단어입니다. 반응하기 전에 전체 내용을 읽어보세요. 열에 아홉은 여러분의 도구와는 약간 다른 작업을 위해 만들어졌을 것입니다. 그리고 정직한 비교는 그 어떤 출시 포스트보다 더 나은 마케팅이 됩니다.

Apple은 클린룸 디버거(clean-room debugger)를 만들었습니다. 저는 여러분이 이미 로그인해 있는 브라우저를 구동하는 도구를 만들었습니다. 둘 다 존재해야 합니다.

safari-mcp는 오픈 소스 (MIT)입니다 — github.com/achiya-automation/safari-mcp. 이는 AI 에이전트를 위한 네이티브 macOS Safari 자동화 도구입니다: 96개의 도구, npx safari-mcp, Chrome 미사용. 제가 만드는 것에 대한 더 자세한 내용은 achiya-automation.com에서 확인하세요.

실제 로그인된 브라우저 대신 격리된 디버깅 세션을 선택하게 만드는 요인, 혹은 그 반대의 경우는 무엇인가요? 진심으로 알고 싶습니다.