MCPSafari: Safari를 AI 에이전트의 네이티브 실행면으로 바꾸는 방법

브라우저 에이전트는 보통 Chrome을 전제로 이야기한다. 그런데 실제 사용자는 늘 Chrome만 쓰는 게 아니다. macOS 환경에서는 Safari가 기본 브라우저이기도 하고, 이미 로그인 세션과 쿠키가 쌓여 있는 경우도 많다.

MCPSafari는 이 지점을 정면으로 건드린다. 이 프로젝트가 하려는 일은 “Safari를 조금 더 자동화하기”가 아니라, Safari를 AI 에이전트가 직접 붙는 네이티브 실행면으로 바꾸는 것에 가깝다.

즉, 브라우저 자동화 도구라기보다 맥에서의 에이전트 제어층이다.

1. 왜 Safari가 따로 의미가 있나

많은 에이전트 도구는 Chrome 중심으로 설계된다. 이유는 단순하다. CDP가 익숙하고, Playwright/Puppeteer 생태계가 크기 때문이다. 하지만 실사용 관점에서는 몇 가지 불편이 남는다.

• 이미 Safari에 로그인되어 있는 세션을 다시 만들어야 한다
• Chrome을 별도로 띄워야 해서 작업 맥락이 분리된다
• macOS 사용자의 실제 기본 브라우저와 괴리가 생긴다
• 브라우저 하나를 더 돌리는 비용이 누적된다

MCPSafari는 여기서 방향을 바꾼다. 기존 Safari를 그대로 활용하면서, 에이전트만 그 위에 얹는다.

이건 작은 차이 같아 보여도 실제 운영에서는 꽤 크다. 세션 유지, 로그인 상태, 반복 작업, 인증 맥락 같은 것들이 에이전트 성공률을 좌우하기 때문이다.

2. 이 프로젝트의 핵심 구조

README와 릴리스 설명을 보면 구조는 꽤 명확하다.

간단히 정리하면 이런 흐름이다.

• MCP client: Claude, Cursor 같은 클라이언트
• Swift MCP server: MCPSafari 바이너리
• Safari extension: 로컬 WebSocket 브리지
• Safari browser: 실제 사용자가 로그인한 브라우저

이 구조의 장점은 브라우저 자동화를 “웹사이트를 조작하는 스크립트”가 아니라 macOS에서 돌아가는 로컬 제어면으로 바꾼다는 점이다.

즉, 에이전트는 페이지를 원격에서 흉내 내는 게 아니라, 사용자 세션이 살아 있는 Safari에 직접 붙는다.

3. 기술적으로 흥미로운 지점

MCPSafari가 흥미로운 이유는 기능 목록보다 설계 선택에 있다.

1) Swift + Safari Extension

이 조합은 이 프로젝트가 임시 해킹이 아니라 macOS 네이티브 제품을 의식하고 있다는 신호다. 브라우저를 억지로 감싸는 대신, Safari 확장과 Swift 서버를 연결해 정석적인 로컬 브리지 형태를 만든다.

2) MCP 표준과의 연결

에이전트 쪽에서는 MCP 클라이언트로 인식된다. 즉, 특정 앱 하나에 종속된 도구가 아니라 MCP 생태계 안에서 재사용 가능한 서버다.

3) 구조가 단순하다

브라우저 자동화는 기능이 많아질수록 복잡해지기 쉽다. 그런데 MCPSafari는 핵심을 다음으로 좁힌다.

• 탭 이동
• 클릭 / 입력 / 폼 작성
• HTML / accessibility tree 읽기
• JavaScript 실행
• 스크린샷 캡처
• 콘솔 / 네트워크 확인

이 정도면 “브라우저를 다루는 데 필요한 최소 핵심”은 꽤 잘 잡은 편이다. 과하게 많은 기능을 늘리기보다, 에이전트가 실제로 필요한 제어점을 깔끔하게 제공한다.

4. Safari를 고른 이유가 있다

이 프로젝트 소개에서 반복해서 보이는 메시지는 사실 기능보다 운영 관점이다.

• Zero Chrome overhead
• Use your existing Safari logins/cookies
• Local & private
• Apple Silicon optimized

이건 단순히 “Safari도 지원합니다” 수준이 아니다. 오히려 다음 메시지에 가깝다.

에이전트 브라우저는 꼭 별도 브라우저일 필요가 없다. 사용자가 이미 쓰는 브라우저를 그대로 도구로 만들 수 있다.

이 관점이 중요한 이유는, 브라우저 에이전트의 병목이 종종 모델 성능이 아니라 상태 관리이기 때문이다. 로그인, 2FA, 세션 유지, 권한 상태, 기기 신뢰 같은 것들이 실제 성공률을 결정한다.

Safari를 그대로 쓰면 이 상태를 재활용할 수 있다.

5. 어떤 사람에게 잘 맞나

이 프로젝트는 범용 만능툴은 아니다. 대신 특정 사용자층에는 꽤 맞는다.

• macOS 중심으로 일하는 사람
• Safari 로그인 세션을 자주 활용하는 사람
• 브라우저 기반 QA / 리서치 / 운영 작업이 많은 사람
• Claude Code, Cursor 같은 MCP 클라이언트를 이미 쓰는 사람
• Chrome을 또 하나 띄우기 싫은 사람

반대로 이런 경우엔 덜 맞을 수 있다.

• Windows 중심 환경
• Playwright / Puppeteer 기반의 범용 브라우저 테스트가 더 중요한 경우
• 완전한 cross-browser 자동화가 필요한 경우
• 로컬 파일/터미널 자동화가 더 중심인 경우

즉, MCPSafari는 “브라우저 자동화의 최강자”라기보다 macOS 사용자에게 가장 자연스러운 브라우저 제어면에 가깝다.

6. 다른 도구와 비교해보면

비슷한 계열의 프로젝트는 많다. 예를 들면 agent-browser 같은 범용 브라우저 CLI, 또는 Safari 중심이지만 AppleScript/Extension 전략을 쓰는 다른 도구들이 있다.

그런데 MCPSafari의 포지션은 조금 다르다.

여기서 핵심은 “Safari가 더 낫다”가 아니다. 사용자 환경과 자동화 도구의 경계가 맞아떨어질 때 생산성이 크게 올라간다는 점이다.

MCPSafari는 그 경계를 Safari 쪽으로 밀어 붙인다.

7. 지금 시점에서 읽히는 신호

이 저장소는 아직 초기 릴리스대지만, 릴리스가 빠르게 쌓이고 있다. 최신 버전은 v0.2.5이고, 설치 흐름도 Homebrew cask를 중심으로 정리되어 있다.

이건 두 가지 의미가 있다.

1. 데모보다 실제 배포를 염두에 둔 프로젝트다
2. 사용자가 직접 설치해서 쓰는 쪽으로 빨리 가고 있다

특히 Homebrew 설치 경로가 있다는 건 작지 않다. 브라우저 자동화 도구는 대부분 설정이 번거로운데, 설치가 쉬워지면 실제 채택 가능성이 확 올라간다.

8. 내 해석: 이건 브라우저 자동화보다 운영면의 변화다

MCPSafari의 핵심은 결국 이 문장으로 정리된다.

브라우저를 더 똑똑하게 만드는 게 아니라, 에이전트의 시작점을 Safari와 macOS 안으로 가져온다.

이 차이는 크다.

• 브라우저 탭 하나를 조작하는 도구가 아니라
• 이미 로그인된 내 세션을 재사용하고
• macOS 네이티브 환경에 붙고
• MCP 클라이언트에서 바로 호출되는 도구

이 되기 때문이다.

그래서 이 프로젝트는 단순한 기능 추가가 아니라, 에이전트가 실제 사용자 환경에 더 가까워지는 방향으로 읽힌다.

마치며

MCPSafari는 화려한 신기능을 잔뜩 넣은 프로젝트는 아니다. 대신 방향이 분명하다.

• Safari를 그대로 쓴다
• 로그인 상태를 재활용한다
• MCP로 연결한다
• macOS 네이티브로 붙인다

이런 조합은 특히 맥 사용자에게 설득력이 있다. 브라우저 에이전트가 점점 많아지는 지금, 중요한 건 “더 많은 브라우저를 지원하느냐”보다 내가 실제로 쓰는 브라우저를 얼마나 자연스럽게 제어하느냐다.

그 점에서 MCPSafari는 꽤 좋은 후보다.

🔗 관련 정보

• GitHub: https://github.com/Epistates/MCPSafari
• Releases: https://github.com/Epistates/MCPSafari/releases
• Homebrew cask: brew install --cask epistates/tap/mcp-safari
• MCP SDK: https://github.com/modelcontextprotocol/swift-sdk