AI 에이전트는 지금 무엇이 부족한가
코드를 생성하는 것과 코드가 실제로 동작하는지 확인하는 것은 전혀 다른 문제다. 지금까지 AI 코딩 도구는 전자에는 뛰어났지만 후자에는 손이 닿지 않았다. 코드를 작성하고, 사람이 직접 실행하고, 결과를 눈으로 확인한 뒤 다시 AI에게 피드백을 전달하는—이 반복 루프가 생산성의 병목이었다.
MCP(Model Context Protocol)는 바로 이 간극을 메운다. AI 에이전트가 외부 시스템과 표준화된 방식으로 연결되는 일종의 '감각 인터페이스'다. 최근 프론트엔드 개발 생태계에서 MCP의 구체적인 활용 사례가 빠르게 축적되고 있는데, Vercel MCP 서버와 Chrome DevTools MCP는 그 실용성을 가장 선명하게 보여주는 두 사례다.
Vercel MCP: 에디터 안에서 인프라를 만지다
Vercel이 공식 MCP 서버(https://mcp.vercel.com)를 출시했다. OAuth 인증을 통해 Cursor, Claude Code, VS Code Copilot 같은 AI 클라이언트가 Vercel 계정에 직접 접근할 수 있는 구조다. 단순히 "Vercel CLI를 wrapping한 것"이 아니라, AI 에이전트가 맥락을 이해하고 도구를 연쇄적으로 호출할 수 있도록 설계된 서버다.
실제로 개발 중 마주치는 시나리오를 생각해보면 이 도구의 가치가 선명해진다. 프리뷰 배포가 빨간불로 떨어졌을 때, 기존 방식이라면 Vercel 대시보드를 열고, 빌드 로그를 찾고, 에러를 복사해 AI에 붙여넣는 과정이 필요했다. Vercel MCP를 연결한 에이전트는 list_deployments로 실패한 배포를 찾고, get_deployment_build_logs로 로그를 직접 가져와 원인을 진단한다. 컨텍스트 스위칭 없이, 에디터 안에서.
get_runtime_logs는 특히 주목할 만하다. 환경(production/preview), 로그 레벨, HTTP 상태 코드, 소스 타입, 시간 범위, 전문 검색, 요청 ID까지—이 필터 조합은 프로덕션 500 에러를 추적할 때 정확히 필요한 것들이다. AI가 이 필터를 스스로 조합해 로그를 추려낸다면, 디버깅의 초기 탐색 비용은 극적으로 줄어든다.
한 가지 강조하고 싶은 것은 보안 모델이다. Vercel은 배포나 도메인 구매 같은 되돌리기 어려운 작업에 대해 반드시 사람의 확인을 거칠 것을 권고한다. MCP가 에이전트에게 '손'을 달아줄수록, 어디까지 자율로 두고 어디서 인간이 개입할지를 설계하는 것이 더 중요해진다. 이건 기술 문제가 아니라 워크플로우 설계 문제다.
Chrome DevTools MCP: AI가 브라우저를 직접 본다
Chrome 익스텐션 개발, 특히 서드파티 웹앱을 대상으로 하는 확장 프로그램을 만들 때의 고통은 독특하다. DOM 구조는 불투명하고, 클래스명은 난독화되어 있으며, 배포마다 바뀐다. 공식 API도 없다. 결국 DevTools를 열어 수동으로 DOM을 탐색하고, 셀렉터를 작성하고, 익스텐션을 리로드하고, 동작 여부를 눈으로 확인하는 느린 루프를 반복하게 된다.
dev.to에 소개된 WXT + Chrome DevTools MCP 스택은 이 루프를 근본적으로 바꾼다. WXT는 --remote-debugging-port=9222 옵션으로 Chrome을 실행하고, Chrome DevTools MCP 서버는 이 포트에 연결해 AI 에이전트에게 Chrome DevTools Protocol을 노출한다. Cursor에서 .cursor/mcp.json에 설정 몇 줄을 추가하면, 에이전트가 브라우저 상태를 직접 읽고 쓸 수 있게 된다.
이 패턴의 핵심은 자기 검증(self-verification) 이다. 기존 AI 보조 코딩에서는 에이전트가 코드를 작성하고 나서 "이 변경 사항을 확인해주세요"라고 요청한다. Chrome DevTools MCP를 활용하면 에이전트 스스로 evaluate_script를 호출해 DOM 상태를 확인한다. #my-panel 엘리먼트가 존재하는지, 자식 노드가 몇 개인지, 스타일이 올바르게 적용됐는지를 코드 작성 직후 에이전트가 직접 검증한다.
이건 '빠른 프로토타이핑 → 검증 → 고도화' 흐름을 사람의 개입 없이 에이전트 내부에서 순환시키는 구조다. 특히 주목할 팁은 스크린샷보다 텍스트 기반 DOM 검증을 우선하라는 것이다. 더 빠르고, 토큰 비용이 적으며, 정확하다. 시각적 레이아웃 확인이 꼭 필요할 때만 take_screenshot()을 쓴다.
Cursor vs Claude Code: 아키텍처가 철학을 드러낸다
MCP 이야기와 함께 곱씹을 만한 아키텍처 비교가 있다. Cursor가 로컬에 쌓는 8GB 스토리지 구조와 Claude Code의 ~/.claude/projects/*.jsonl 방식의 차이다.
Cursor는 여러 위치에 걸쳐 SQLite 데이터베이스, 트랜스크립트 파일, 글로벌 상태 DB를 분산 저장한다. VS Code 계보를 이은 레이어드 아키텍처의 결과다. Claude Code는 반대다. 프로젝트마다 JSONL 파일 하나. 어디에 무엇이 있는지 명확하고, 삭제도 간단하며, 파이프라인 연결도 쉽다.
이 차이는 단순한 스토리지 효율 문제가 아니다. 개발자 제어권에 관한 철학 차이다. JSONL 구조는 자동화 스크립트를 붙이기 쉽고, 세션 히스토리를 분석 도구로 파이핑하는 것도 SQL 쿼리 없이 가능하다. MCP처럼 AI 에이전트의 실행 환경을 확장하려 할수록, 에이전트가 접근하는 데이터의 구조와 위치가 투명한 것이 중요해진다. 자동화를 설계할 때 '예측 가능한 단순함'이 '기능이 풍부한 복잡함'보다 더 강력한 이유다.
시사점: MCP는 도구가 아니라 패러다임이다
세 사례를 관통하는 공통 구조가 있다. AI 에이전트가 외부 시스템의 상태를 읽고(perceive), 행동하고(act), 결과를 검증(verify) 하는 루프다. Vercel MCP는 인프라 레이어에서 이 루프를 실현하고, Chrome DevTools MCP는 브라우저 레이어에서 실현한다.
프론트엔드 개발자 관점에서 이 흐름이 중요한 이유는, 우리가 다루는 문제의 본질이 '코드를 생성하는 것'이 아니라 '사용자가 경험하는 결과물을 올바르게 만드는 것'이기 때문이다. DOM이 의도대로 렌더링됐는지, 배포가 정상적으로 올라갔는지, 런타임에 에러가 없는지—이 검증 루프를 AI가 스스로 닫을 수 있게 되면, 개발자는 더 높은 수준의 의사결정에 집중할 수 있다.
다만 이 확장은 무조건적인 자율화를 의미하지 않는다. Vercel이 권고하듯, 되돌릴 수 없는 작업의 경계를 설계하는 것은 여전히 사람의 몫이다. MCP가 AI에게 더 많은 감각을 줄수록, 어디서 에이전트를 멈추게 할지를 정의하는 워크플로우 설계의 중요성도 함께 높아진다.
전망: 감각이 늘어날수록 설계가 중요해진다
앞으로 MCP 서버는 지금보다 훨씬 다양한 레이어—데이터베이스, 디자인 도구, 테스트 러너, 모니터링 시스템—에 연결될 것이다. AI 에이전트의 감각기관이 늘어날수록, 에이전트가 어떤 정보를 바탕으로 어떤 행동을 할 수 있는지를 명확하게 설계하는 역량이 프론트엔드 개발자의 핵심 역량 중 하나가 된다.
코드를 잘 짜는 것만큼, 에이전트가 잘 볼 수 있는 환경을 잘 만드는 것—그것이 다음 단계의 개발자 경험 설계다.