지금까지 웹 개발자는 버그를 발견하면 콘솔을 열고, 스크린샷을 찍고, 그 내용을 다시 에이전트에게 설명해야 했습니다. 사파리가 이 왕복을 없애는 MCP 서버를 내놨습니다.

애플의 WebKit 팀이 Safari Technology Preview 247에 웹 개발자용 MCP(Model Context Protocol) 서버를 추가했습니다. MCP로 연결된 코딩 에이전트가 사파리 브라우저 창에 직접 접속해서, DOM 구조와 네트워크 요청, 콘솔 로그, 스크린샷까지 실시간으로 들여다볼 수 있게 됐습니다.

출처: Introducing the Safari MCP server for web developers – WebKit

브라우저, 프롬프트, 에이전트를 오가던 반복

웹 개발자라면 익숙한 흐름이 있습니다. 브라우저에서 뭔가 이상한 걸 발견하면 콘솔을 열어 원인을 찾고, 스타일 탭을 뒤지고, 코드로 돌아가 고칩니다. 아니면 스크린샷을 찍어 에이전트에게 상황을 설명하고 수정을 맡기기도 합니다. 문제는 한 번에 안 고쳐질 때입니다. 브라우저를 보고, 프롬프트를 쓰고, 에이전트가 답하고, 다시 브라우저를 확인하는 과정을 버그가 잡힐 때까지 반복해야 합니다. Safari MCP 서버는 에이전트가 이 확인 작업을 직접 하도록 만들어서, 창을 오가는 횟수 자체를 줄이는 방향을 택했습니다.

코드가 아니라 화면을 보는 에이전트

이 서버가 여는 건 몇 가지 구체적인 작업입니다. 에이전트가 사파리에서 사이트를 직접 열어 실제 렌더링 결과와 계산된 스타일, 레이아웃을 비교해 크로스 브라우저 호환성 문제를 잡아낼 수 있고, 페이지의 자바스크립트를 실행해 내비게이션 타이밍이나 리소스 로드 시간 같은 성능 지표도 확인할 수 있습니다. 레이블 누락이나 잘못된 ARIA 속성, 낮은 대비 같은 접근성 문제도 점검 대상입니다. 폼 상태를 확인하거나 특정 셀렉터로 요소를 조회하는 식으로, 체크아웃 흐름 같은 사용자 상태를 검증하는 데도 쓸 수 있습니다. 핵심은 에이전트가 코드만 읽고 추측하는 게 아니라, 실제로 브라우저에 렌더링된 결과를 보고 판단한다는 점입니다.

로컬에서만 도는 서버

Safari MCP 서버는 사용자 컴퓨터 안에서만 동작하고, 자체적으로 네트워크 호출을 하지 않습니다. 오토필처럼 사파리에 저장된 개인정보에도 접근하지 않습니다. 서버가 캡처하는 화면 내용이나 스크린샷, 콘솔 로그는 애플이 아니라 사용자가 쓰고 있는 에이전트로 바로 전달됩니다. 이후 그 데이터를 어떻게 다루는지는 각 에이전트와 모델의 정책에 달려 있어서, WebKit 팀도 신뢰하는 에이전트에만 브라우저 접근 권한을 주라고 당부하고 있습니다.

에이전트가 코드 작성을 넘어 실제 화면 상태까지 확인하게 되면서, 디버깅에서 사람이 맡던 “확인” 역할의 비중이 조금씩 줄어드는 셈입니다. 다른 브라우저용 MCP 서버들도 비슷한 방향으로 나오고 있는데, 애플이 자사 브라우저 엔진에 이 기능을 직접 얹었다는 점에서 사파리 호환성 문제를 다루는 개발자에게는 특히 눈여겨볼 변화입니다.