다음 세대 웹 개발의 질문은 “코드를 어떻게 빨리 쓰나”가 아니라
“사람 UI와 에이전트 인터페이스를 어떻게 함께 설계하나”로 바뀐다.
요즘 WebMCP와 DevTools MCP 이야기를 듣다 보면 둘 중 하나로 흐르기 쉽다.
- “신기한 데모다”
- “아직 먼 미래다”
둘 다 반쯤만 맞다.
실제로는 이미 시작됐고, 지금은 도입 여부보다 어떤 경계부터 설계할지가 더 중요하다.
TL;DR
- 브라우저 MCP는 웹을 “읽는 대상”에서 “호출 가능한 도구 집합”으로 바꾼다.
- DevTools MCP는 디버깅을 수동 클릭에서 자동 검증 루프로 옮긴다.
- FE 역할은 컴포넌트 구현에서 인터페이스 경계 설계로 확장된다.
- 팀 경쟁력은 코드 생성 속도보다, 안전한 호출/검증/복구 설계에서 갈린다.
지금 실제 나온 인터페이스 (2026-05 기준)
| 항목 | 상태 | 인터페이스/형태 | FE가 지금 할 일 |
|---|---|---|---|
| Chrome DevTools for agents | Stable | MCP server, CLI, agent skills | CI에 자동 검증 1개 연결 |
| WebMCP | Origin Trial (Chrome 149) | 구조화된 도구 노출(JS 함수/폼) | 호출 경계(Action Boundary) PoC |
| Modern Web Guidance | Early Preview | 베스트프랙티스 스킬셋 + Baseline 연계 | 팀 코드 기준을 가이드로 명시 |
| Soft Navigations API | Final OT (Chrome 147~149) | SPA 내비게이션 단위 CWV 측정 | RUM 수집/리셋 로직 실험 |
| HTML-in-Canvas | Origin Trial | Canvas 내부 DOM 결합 | 접근성 요구가 낮은 영역에서 제한 실험 |
| Universal Cart/UCP/AP2 | Rollout/Expansion | 멀티서페이스 카트/체크아웃 프로토콜 | 정합성/승인/감사 UX 설계 |
핵심은 “아직 멀다”가 아니라,
이미 안정화된 것과 실험 가능한 것을 분리해 운영 계획을 짜는 것이다.
1) 지금 바뀌는 것: 개발 루프 자체
기존 루프:
- 개발자가 코드 작성
- 브라우저에서 수동 확인
- 이슈 발견 후 재수정
MCP 결합 루프:
- 에이전트가 코드 초안 작성
- DevTools MCP로 콘솔/네트워크/접근성/성능 자동 확인
- 실패 원인 기록 + 재시도
- 사람은 경계와 우선순위 판단
포인트는 “자동화됐다”가 아니다.
검증과 수정이 같은 루프 안에서 닫힌다는 점이다.
2) 브라우저 MCP 시대에 생기는 제품 패턴 3가지
패턴 A) Agent-ready Action
버튼/폼을 그대로 긁어 쓰게 두는 대신,
조회, 선택, 적용, 확정 같은 동작 단위를 도구로 명시한다.
필수 조건:
- 동작별 권한
- 입력 검증
- 취소/재시도 규칙
- 감사 가능한 실행 로그
패턴 B) Self-checking UI
릴리즈 전에 사람이 하나씩 확인하는 것이 아니라,
에이전트가 핵심 시나리오를 실행하고 DevTools MCP로 증거를 남긴다.
필수 조건:
- 실패 유형 분류 (사용자/시스템/정합성)
- 재현 가능한 최소 시나리오
- PR/CI에 붙는 자동 리포트
패턴 C) Recovery-first UX
실패를 “오류 토스트”로 덮는 대신,
항목 단위 복구 동선을 먼저 설계한다.
필수 조건:
- 부분 실패 상태 모델
- 복구 CTA 분리
- 롤백 가능한 상태 전이
이번 주에 해볼 실천 시나리오 3개
시나리오 A) DevTools MCP + CI 회귀 검증 자동화
상황:
- PR마다 “장바구니 총액 불일치”, “버튼 비활성 상태 누락” 같은 회귀가 반복
- 리뷰어가 수동 확인할 때마다 기준이 달라져 누락 발생
적용:
- 에이전트가 PR 기준 핵심 시나리오 실행
- DevTools MCP로 콘솔 에러/네트워크 실패/접근성 경고 수집
- 실패 항목을 PR 코멘트 템플릿으로 자동 정리
측정:
- PR당 수동 검증 시간
- 배포 후 회귀 이슈 건수
시나리오 B) WebMCP Action Boundary로 승인 UX 분리
상황:
- 에이전트가 주문 관련 플로우를 자동 실행할 때 허용 범위가 모호
- 팀마다 “자동 실행 가능 범위” 해석이 달라 사고 리스크 증가
적용:
조회/선택/적용은 자동 허용최종 확정/결제는 사용자 승인 필수- 승인 전 화면에 “자동 실행 내역 요약 + 취소”를 고정 노출
측정:
- 승인 단계에서 중단된 위험 동작 건수
- 자동 실행 후 수동 되돌리기 건수
시나리오 C) Recovery-first UX로 실패 이탈 줄이기
상황:
- 실패 시
오류가 발생했습니다토스트 한 줄로 끝나 복구 동선이 없음 - 사용자 이탈 후 재진입률이 낮음
적용:
- 실패를 항목 단위(재고/가격/옵션)로 분리 표시
- 항목별 복구 CTA 제공 (
대체 상품,옵션 재선택,변경 항목만 확인) - 복구 성공/실패를 이벤트로 분리 로깅
측정:
- 실패 후 이탈률
- 실패 후 복구 완료율
- 복구까지 걸린 평균 시간
3) FE가 새로 갖게 되는 책임
예전엔 주로 화면 품질이 핵심이었다면,
이제는 아래 네 가지를 동시에 책임지게 된다.
- Action Contract: 에이전트가 호출할 행동 단위의 계약 정의
- Safety Boundary: 위험 동작의 승인/제한/취소 설계
- Observability: 호출 경로별 로그/지표/감사 추적
- Trust UX: 사용자에게 자동 실행 내역과 복구 경로를 설명
결국 FE는 UI 구현자에서,
사람과 에이전트 사이의 인터페이스 설계자로 이동한다.
4) 현실적인 도입 순서: Now / Next / Later
Now (이번 분기)
- 핵심 플로우 1개를 action 단위로 분해
- DevTools MCP 기반 자동 검증 1개를 CI에 연결
- 실패 유형 대시보드(정합성/성능/접근성) 최소 버전 도입
Next (6~12개월)
- 브라우저 MCP 호출 경계를 API/권한 모델과 통합
- 사용자 승인 UX(확정 전 요약/취소) 표준화
- 운영/QA/개발 공통의 실행 로그 포맷 확립
Later (구조 전환)
- 사람 UI + 에이전트 호출 인터페이스 동시 설계가 기본값
- 디버깅은 “사람이 찾아내는 작업”에서 “자동 검증 파이프라인” 중심으로 이동
5) 팀에서 바로 시작할 5문장
새 기능 착수 전에 아래 문장을 못 채우면, 에이전트 자동화도 보류한다.
- 이 기능에서 에이전트가 호출 가능한 동작은
___다. - 호출 불가 동작(사람 승인 필수)은
___다. - 실패 시 자동 복구 경로는
___다. - 감사 로그에서 추적할 필드는
___다. - 배포 전 통과해야 할 자동 검증은
___다.
이 다섯 줄이 있으면 MCP는 가속기가 되고,
없으면 장애 전파기가 된다.
이 글이 기대가 아닌 이유: 내가 이미 해본 운영 기록
아래 글들은 “미래 예측”이 아니라, 실제 운영 과정에서 얻은 기준들이다.
- AI 스킬은 코드다 — 쓰면서 고쳐야 산다
→ 실행-오차-수정 루프를 실제 사례로 정리 - MCP 메인스트림 주간
→ 연결보다 런타임/안전 운영이 핵심이라는 관찰 - my-cursor 설계/운영 회고
→ 명령/리뷰/복구 레이어를 나눠 운영한 기록 - Heart API 마이그레이션 + /cb 스킬
→ 실제 마이그레이션 작업에서 스킬 운영 방식 검증 - Cursor 가이드
→ 팀이 바로 따라 할 수 있는 기본 운영선
그래서 이 글의 요지는 “언젠가 올 미래”가 아니라,
이미 시작된 변화를 팀 운영으로 옮기는 방법이다.
참고 레퍼런스
마치며
브라우저 MCP가 오면 웹 개발이 완전히 자동화되는가?
아니다. 오히려 설계 책임은 더 선명해진다.
사람이 해야 할 일은 줄지 않는다.
다만 더 가치가 높은 일로 이동한다.
한 줄 결: 브라우저 MCP 시대의 승부처는 코드 양이 아니라, 호출 경계와 복구 설계다.