37%p 격차, Chrome이 코딩 에이전트에 넣은 웹 상식

AI 요약

• 무슨 일: Chrome 팀이 Modern Web Guidance를 early preview로 공개했습니다.
  • 코딩 에이전트가 최신 Web Platform 기능, Baseline target, fallback 전략을 작업 문맥으로 검색해 쓰는 agent skill입니다.
• 핵심 수치: Google은 초기 평가에서 guidance 적용 시 현대적 best practice 준수가 평균 37%p 높았다고 밝혔습니다.
• 의미: 에이전트 경쟁이 모델 추론만이 아니라 최신 도메인 지식 주입과 평가 하네스로 이동합니다.
• 주의점: Chrome 중심 guidance는 유용하지만, 팀의 실제 브라우저 지원 정책과 보안 기준을 함께 넣어야 합니다.

Google Chrome 팀이 Google I/O 2026에 맞춰 Modern Web Guidance를 early preview로 공개했습니다. 이름만 보면 또 하나의 웹 개발 문서처럼 보일 수 있습니다. 하지만 이 발표의 중심은 사람 개발자가 읽는 튜토리얼이 아니라, 코딩 에이전트가 작업 중 검색하고 회수해 컨텍스트로 넣는 agent skill입니다. Chrome 팀은 에이전트가 오래된 HTML, CSS, 클라이언트 JavaScript 패턴을 반복하는 문제를 겨냥했습니다.

이번 뉴스가 흥미로운 이유는 웹 기술 자체가 새로워서만은 아닙니다. 에이전트가 "무엇을 알고 코드를 쓰는가"라는 더 근본적인 문제를 드러내기 때문입니다. 모델은 수많은 레거시 예제를 학습했습니다. 그래서 모달을 만들 때 <dialog>와 closedby, Popover, Anchor Positioning을 쓰기보다 JavaScript 이벤트와 div 조합으로 돌아가려 할 수 있습니다. 폼 검증에서는 :user-invalid 같은 새 선택자를 놓치고, 복잡한 CSS layout에서는 subgrid나 container query 대신 과한 wrapper와 resize listener를 만들 수 있습니다. 이것은 단순한 취향 문제가 아닙니다. 에이전트가 만든 코드는 그대로 제품 코드가 되고, 낡은 workaround는 번들 크기, 접근성, 성능, 유지보수 비용으로 돌아옵니다.

Modern Web Guidance는 이 문제를 "모델을 다시 학습시킨다"가 아니라 "작업 직전에 좁은 지식을 주입한다"로 풉니다. 공식 문서는 npx modern-web-guidance@latest search "animate a dialog modal backdrop"처럼 prompt에 맞는 use case guide를 찾고, retrieve로 해당 Markdown guide를 가져오는 흐름을 보여줍니다. 설치형 skill은 에이전트에게 이 CLI를 어떻게 호출해야 하는지 알려주고, 에이전트는 필요한 순간에 최신 guide를 컨텍스트로 불러옵니다. 즉, 에이전트의 기억을 영구적으로 고치는 대신, 작업마다 필요한 웹 상식을 꺼내 먹이는 구조입니다.

오래된 패턴은 왜 계속 살아남나

Chrome 문서는 Modern Web Guidance가 필요한 이유를 세 가지로 정리합니다. 첫째, AI 코딩 에이전트는 최신 웹 개발 문제를 해결할 때 오래된 해법으로 돌아가는 경향이 있습니다. 특히 지금은 CSS와 HTML 네이티브 API로 풀 수 있는 문제에도 JavaScript를 많이 쓰는 구현을 생성할 수 있습니다. 둘째, 모델은 최신 Web Platform 기능을 모르거나 잘못 알고 있을 수 있습니다. 셋째, 모델은 프로젝트의 브라우저 지원 조건을 보지 못한 채 one-size-fits-all 답변을 내놓기 쉽습니다.

이 설명은 프론트엔드 개발자가 실제로 자주 보는 실패와 맞닿아 있습니다. 예를 들어 tooltip을 구현하라고 하면 에이전트는 화면 밖으로 삐져나가는 absolute positioning 코드를 만들 수 있습니다. dialog를 만들라고 하면 focus trap, backdrop, escape key, light dismiss를 모두 수동으로 구현하려고 할 수 있습니다. 애니메이션을 추가하라고 하면 prefers-reduced-motion을 놓칠 수 있습니다. 성능 최적화를 요청하면 scheduler.yield나 content-visibility 같은 플랫폼 기능 대신 임의의 debounce와 setTimeout만 붙일 수 있습니다.

사람 개발자도 최신 기능을 모두 외우기는 어렵습니다. 하지만 사람은 프로젝트의 브라우저 지원 범위, 디자인 시스템, 접근성 기준, 장애 이력, 팀의 코드 리뷰 문화를 알고 있습니다. 에이전트는 그런 배경을 자동으로 갖지 않습니다. 그래서 AGENTS.md, rules, skills, MCP docs retrieval 같은 문맥 공급 장치가 점점 중요해졌습니다. Modern Web Guidance는 그 흐름을 Chrome 팀이 웹 플랫폼 차원에서 공식화한 사례입니다.

100개 이상 use case와 Baseline

공식 문서는 Modern Web Guidance가 100개 이상의 web development use case를 포함한다고 설명합니다. GitHub README에는 102개 modern web features와 128개 real-world developer use cases가 나열되어 있습니다. 범위는 꽤 넓습니다. user experience에는 View Transitions, entry/exit animations, scrollbar styling이 들어갑니다. CSS에는 container queries, subgrid, oklch, text-wrap, line-height trimming이 포함됩니다. performance에는 INP diagnostics, scheduler.yield, background task scheduling, image loading prioritization이 있습니다. forms와 built-in UI components에는 field-sizing: content, :user-invalid, dialogs, Popover, CSS Anchor Positioning이 들어갑니다. accessibility, passkeys, privacy, built-in AI도 별도 영역으로 묶입니다.

여기서 중요한 것은 단순 목록이 아닙니다. Modern Web Guidance는 Baseline과 연결됩니다. Baseline은 주요 브라우저 엔진에서 어떤 웹 기능을 신뢰할 수 있는지 분류하는 Web Platform DX의 기준입니다. 기능은 Limited availability, Newly available, Widely available로 나뉩니다. Chrome 문서는 프로젝트의 AGENTS.md나 CLAUDE.md에 "This project's Baseline target is Baseline 2024."처럼 목표를 적을 수 있다고 설명합니다. target이 없으면 Modern Web Guidance는 Baseline Widely available을 기본값으로 둡니다.

이 설계는 에이전트에게 매우 중요합니다. 최신 API를 무조건 쓰는 것도 위험하고, 가장 오래된 브라우저까지 과도하게 지원하는 것도 비용입니다. 실제 제품은 지원 브라우저, 고객군, 성능 예산, 접근성 기준, 보안 정책이 다릅니다. Baseline target을 문맥에 넣으면 에이전트는 "이 기능을 써도 되는가"와 "fallback이 필요한가"를 더 명확히 판단할 수 있습니다. 에이전트가 코드 스타일만 맞추는 것이 아니라, 웹 플랫폼 지원 정책까지 읽게 되는 셈입니다.

37%p 개선이라는 수치의 의미

이번 발표에서 가장 강한 숫자는 37 percentage point입니다. Chrome 문서는 Modern Web Guidance가 어떻게 accuracy를 보장하는지 설명하면서, 초기 평가에서 guidance를 장착한 에이전트가 modern best practices 준수에서 평균 37 percentage point 개선을 보였다고 밝혔습니다. 단서도 붙였습니다. 프로젝트 요구사항, 모델, prompt, 선호하는 agentic coding tool에 따라 결과는 달라질 수 있습니다.

이 숫자를 제품 성능 보장처럼 읽으면 안 됩니다. "Modern Web Guidance를 설치하면 웹 코드 품질이 37% 좋아진다"는 뜻이 아닙니다. 더 정확한 의미는 따로 있습니다. 도메인별로 잘 쪼갠 guidance와 평가 하네스가 있으면, 최신 모델도 여전히 작업 직전의 좁은 문맥에서 크게 달라질 수 있다는 뜻입니다. 즉, 코딩 에이전트 경쟁의 핵심이 모델 자체에서 점점 "어떤 문맥을 언제 넣는가"로 이동한다는 신호입니다.

평가 방식도 눈여겨볼 만합니다. Chrome 문서는 use case별 guide가 automated QA harness로 보정된다고 설명합니다. Playwright script가 guide의 구현 세부사항을 따랐는지 테스트하고, correct reference demo는 100% pass를 기대하며, deliberately flawed implementation은 0% pass를 기대합니다. 이후 base application에서 unguided control과 guidance를 쓴 experiment를 비교합니다. 모든 use case가 아직 보정된 것은 아니지만, 방향은 분명합니다. "좋은 prompt를 모아둔다"에서 "guide가 실제로 에이전트 행동을 바꾸는지 매일 측정한다"로 가는 것입니다.

이 흐름은 최근 에이전트 도구의 공통 패턴과 맞닿아 있습니다. Claude Code, Codex, Cursor, Gemini CLI, Antigravity 같은 도구는 모두 프로젝트 규칙, skills, MCP, 문서 retrieval을 중요한 실행면으로 끌어올렸습니다. 하지만 대부분의 팀은 아직 "우리 rule이 실제로 좋은 결과를 만드는가"를 감으로 판단합니다. Modern Web Guidance는 웹 플랫폼 영역에서 그 rule을 평가 가능한 자산으로 다루려는 시도입니다.

설치 경로가 말하는 것

Modern Web Guidance의 설치 경로는 이 발표가 특정 IDE 종속 기능이 아니라는 점을 보여줍니다. 공식 문서는 Chrome 팀 CLI인 npx modern-web-guidance@latest install을 권장합니다. 그 밖에도 Antigravity, Antigravity CLI, Gemini CLI, JetBrains WebStorm, GitHub CLI, npx skills, Claude Code, Copilot CLI, Goose 설치 경로를 문서화했습니다. GitHub README도 agent skill과 CLI를 함께 강조합니다.

이 목록은 에이전트 생태계의 현재 상태를 잘 보여줍니다. 개발팀은 이미 여러 코딩 에이전트를 섞어 씁니다. 어떤 사람은 Claude Code를 쓰고, 어떤 사람은 Cursor를 쓰고, 어떤 사람은 Codex나 Gemini CLI를 씁니다. 이때 "우리 팀의 웹 플랫폼 기준"을 특정 에디터 플러그인 안에만 두면 재사용성이 떨어집니다. Modern Web Guidance는 skill과 CLI를 통해 같은 guide library를 여러 도구에 주입하려 합니다.

물론 이것은 곧바로 표준이 된다는 뜻은 아닙니다. 각 도구의 skill 포맷, MCP 지원, 플러그인 생태계, 보안 모델은 아직 빠르게 변합니다. 하지만 방향은 중요합니다. 에이전트가 가져야 할 지식은 모델별 prompt가 아니라, 버전 관리되고 검색되고 평가되는 문서 묶음으로 이동하고 있습니다. 웹 개발에서는 그 묶음이 Baseline, MDN, Chrome docs, framework docs, 사내 browser support matrix를 함께 봐야 합니다.

Chrome의 전략은 문맥과 실행을 나누지 않는다

Modern Web Guidance는 단독 발표로도 의미가 있지만, Google I/O 2026의 다른 Chrome 발표와 함께 보면 더 선명합니다. 같은 주간에 Chrome 팀은 Chrome DevTools for agents, WebMCP, Chrome의 AI assistance 업데이트, modern web capabilities 세션을 함께 밀었습니다. 최근 devlery에서 다룬 Chrome DevTools for agents가 "에이전트가 실제 브라우저를 보고 검증하는 층"이었다면, Modern Web Guidance는 "에이전트가 코드를 쓰기 전에 어떤 구현 지식을 갖는가"를 담당합니다.

둘은 역할이 다릅니다. Modern Web Guidance는 구현 방향을 제시합니다. 예를 들어 에이전트가 dialog animation을 만들 때 ::backdrop, <dialog>, Popover, @starting-style, transition-behavior 같은 기능을 검토하게 합니다. Chrome DevTools for agents는 실행 중인 페이지의 콘솔, 네트워크, 접근성 트리, Lighthouse 결과를 읽고 실제로 잘 작동하는지 확인하게 합니다. 하나는 처방전이고, 다른 하나는 검사 장비에 가깝습니다.

WebMCP까지 포함하면 그림은 더 커집니다. 웹사이트가 브라우저 에이전트에게 구조화된 도구를 노출하고, 에이전트는 Modern Web Guidance로 최신 구현 패턴을 가져오며, Chrome DevTools for agents로 런타임을 검증합니다. Google은 Chrome을 단순 렌더링 엔진이 아니라 에이전트 시대의 개발·실행·검증 표면으로 확장하려 합니다. 이것은 웹 개발자에게 편리한 흐름이지만, 동시에 Chrome 중심의 tooling gravity가 더 커지는 움직임이기도 합니다.

개발팀이 바로 정해야 할 것

Modern Web Guidance를 무조건 설치해야 한다는 결론은 성급합니다. 더 중요한 것은 팀이 에이전트에게 줄 웹 정책을 명확히 갖고 있는지입니다. 첫째, AGENTS.md나 동등한 규칙 파일에 Baseline target과 지원 브라우저를 적어야 합니다. "최신 Chrome만 지원"하는 내부 도구와 "Safari, Firefox, Chromium 계열을 모두 지원"하는 고객용 제품은 같은 지침을 쓸 수 없습니다.

둘째, 에이전트가 최신 API를 쓸 때 fallback 정책을 정해야 합니다. 공식 문서는 feature가 Widely available이 아닐 때 progressive enhancement와 조건부 polyfill을 안내한다고 설명합니다. 하지만 실제 정책은 팀마다 다릅니다. 어떤 기능은 지원하지 않는 브라우저에서 graceful degradation이면 충분하고, 어떤 기능은 결제나 인증처럼 대체 구현이 필요합니다. 이 차이를 에이전트가 알지 못하면 "현대적이지만 제품 기준에는 맞지 않는 코드"가 나옵니다.

셋째, guidance를 테스트와 연결해야 합니다. Modern Web Guidance 자체는 Playwright 기반 calibration을 강조하지만, 팀의 제품 코드에는 별도 검증이 필요합니다. 에이전트가 <dialog>를 썼다고 해서 접근성이 자동으로 보장되지는 않습니다. focus 이동, keyboard navigation, screen reader announcement, reduced motion, viewport별 layout, 실제 브라우저 호환성을 테스트해야 합니다. 이 지점에서 Chrome DevTools for agents나 기존 Playwright/Cypress suite와의 조합이 중요해집니다.

넷째, Chrome 중심 guidance를 보완해야 합니다. Modern Web Guidance는 Chrome 팀, Microsoft Edge 팀, 웹 개발 커뮤니티의 지원을 받는다고 README가 설명합니다. 그래도 제품이 Firefox와 Safari를 중요하게 지원한다면 MDN browser compatibility data, WebKit release note, caniuse, 자체 analytics 기반 browser matrix를 함께 봐야 합니다. Baseline은 좋은 공통 언어지만, 모든 제품의 위험 허용치를 대신하지는 않습니다.

에이전트 시대의 문서가 바뀐다

이번 발표의 더 큰 의미는 문서의 소비자가 바뀐다는 점입니다. 과거의 개발 문서는 사람이 검색하고 읽었습니다. 지금의 에이전트 워크플로에서는 문서가 검색 가능한 skill, CLI, MCP resource, AGENTS.md 규칙으로 바뀝니다. 사람이 "이 API가 최신인가"를 판단하는 대신, 에이전트가 작업 중 필요한 guide를 찾아 컨텍스트에 넣고, 코드를 만든 뒤 테스트를 돌립니다.

이 변화는 문서 작성 방식도 바꿉니다. 긴 설명보다 use case별로 좁고 실행 가능한 guide가 중요해집니다. browser support, fallback, accessibility, performance caveat, security note가 구조화되어야 합니다. 그리고 guide가 실제로 에이전트 행동을 개선하는지 평가해야 합니다. Modern Web Guidance가 Playwright calibration을 전면에 둔 이유가 여기에 있습니다.

개발자에게 남는 질문은 단순합니다. 앞으로 코딩 에이전트에게 "최신 웹으로 만들어줘"라고 말하는 것만으로 충분할까요. 아마 아닙니다. 에이전트는 최신 API 이름을 알아도, 그 API를 언제 써야 하는지, 어떤 브라우저에서 fallback이 필요한지, 접근성 기준을 어떻게 맞춰야 하는지, 성능 예산과 제품 정책이 무엇인지는 모릅니다. Modern Web Guidance는 그 빈칸을 채우는 한 가지 방식입니다.

그래서 이 뉴스는 웹 개발 가이드 출시가 아니라 에이전트 인프라 뉴스에 가깝습니다. 모델이 코드를 잘 쓰는 시대에도, 좋은 코드를 만들려면 좋은 문맥과 좋은 평가가 필요합니다. Chrome 팀은 웹 플랫폼의 최신 지식을 에이전트가 먹을 수 있는 형태로 포장하기 시작했습니다. 37%p라는 초기 수치는 그 시도가 적어도 측정 가능한 차이를 만들 수 있음을 보여줍니다. 이제 남은 경쟁은 누가 더 큰 모델을 내놓는가만이 아닙니다. 누가 더 신뢰할 수 있고, 최신이며, 제품 정책에 맞는 문맥을 에이전트에게 제때 공급하는가입니다.