버튼은 잘 눌리고, 화면도 그럴듯합니다. AI가 몇 분 만에 만든 랜딩 페이지나 대시보드는 얼핏 보면 사람이 작성한 코드와 큰 차이가 없어 보입니다.
하지만 키보드의 Tab 키만으로 메뉴를 열 수 없다면 어떨까요? 모달을 닫은 뒤 초점이 원래 버튼으로 돌아오지 않는다면요? 성능이 낮은 모바일 기기에서 클릭 후 화면이 잠시 멈추고, 이미지가 늦게 로드되며 레이아웃이 흔들린다면 그 코드를 정말 잘 만들었다고 할 수 있을까요?
AI가 생성한 프런트엔드 코드의 위험은 대개 화면에 즉시 드러나지 않는 품질 문제에 있습니다.
- 시각적으로는 완성됐지만 스크린 리더가 이해하지 못하는 UI
- 마우스는 지원하지만 키보드 조작은 막힌 메뉴
- 동작은 하지만 긴 JavaScript 작업으로 느려지는 페이지
- 익숙한 라이브러리 코드이지만 최신 브라우저 표준을 활용하지 못한 구현
- 특정 브라우저에서는 정상이어도 다른 환경에서 깨지는 기능
AI coding agent는 “요구한 기능이 동작하는 코드”를 빠르게 만들 수 있습니다. 그러나 Web 개발에서 좋은 코드는 단순히 클릭 가능한 코드가 아닙니다. 다양한 브라우저, 보조기술, 네트워크 환경, 기기 성능에서도 일관되게 사용할 수 있어야 합니다.
예를 들어 AI는 팝업 창을 만들 때 div와 복잡한 이벤트 처리로 직접 구현할 수 있습니다. 이 방식은 겉으로는 충분히 작동합니다. 하지만 focus 이동, Esc 키 닫기, 배경 콘텐츠 접근 차단, prefers-reduced-motion 대응까지 빠짐없이 처리하려면 고려할 요소가 많습니다. 이때 상황에 따라 네이티브 <dialog>나 popover 같은 Web 플랫폼 기능을 선택하는 편이 코드량과 오류 가능성을 함께 줄일 수 있습니다.
이 문제를 겨냥해 Google Chrome은 2026년 11월 10일 Modern Web Guidance 1.0을 공개했습니다. 이는 새로운 브라우저 API가 아니라, AI agent가 최신 Web 표준과 실무 품질 기준을 참고하도록 돕는 오픈소스 지식·검증 계층입니다.
Modern Web Guidance는 AI가 코드를 작성하거나 기존 코드를 현대화할 때 다음과 같은 기준을 함께 고려하도록 유도합니다.
- semantic HTML과 올바른 ARIA 사용
- 키보드 접근성 및 focus 관리
- 성능을 해치는 긴 JavaScript 작업 감소
- 이미지 우선순위와 레이아웃 안정성
- 브라우저별 지원 범위와 Baseline 호환성
- 안전한 HTML 처리, CSP, Passkey 등 보안 원칙
- 오래된 JavaScript 패턴을 네이티브 Web 기능으로 전환하는 방법
핵심은 간단합니다. AI에게 “예쁜 화면을 만들어 달라”고만 요청하는 데서 멈추지 않고, 사용자가 실제로 문제없이 쓸 수 있는 화면을 만들도록 개발 맥락을 제공하는 것입니다.
다만 Guidance가 품질을 자동 보장하는 것은 아닙니다. 가이드는 더 나은 구현 방향을 제시할 뿐, 실제 저사양 기기에서의 반응성이나 브라우저별 동작, 스크린 리더 사용 경험까지 대신 확인해 주지는 않습니다. 따라서 AI가 만든 코드는 여전히 실제 브라우저 테스트와 성능 측정, 접근성 검토를 거쳐야 합니다.
그럼에도 Modern Web Guidance 1.0은 중요한 변화를 보여줍니다. 이제 Web 품질 관리는 AI가 코드를 만든 이후에만 시작되는 일이 아니라, AI가 코드를 만드는 순간부터 설계해야 하는 기준이 되고 있습니다.
Web에서 ‘동작하는 코드’와 ‘좋은 Web 코드’ 사이의 간극
AI가 만든 UI는 화면에서 완벽해 보일 수 있습니다. 버튼은 눌리고, 모달은 열리며, 애니메이션도 자연스럽습니다. 하지만 잘못 붙인 ARIA 속성 하나가 screen reader 사용자에게는 오히려 더 큰 혼란을 만들 수 있습니다. 겉으로 보이는 결과만으로는 좋은 Web 코드인지 판단할 수 없는 이유입니다.
AI coding agent는 대체로 “요구한 기능이 작동하는 코드”를 빠르게 생성합니다. 문제는 Web 플랫폼이 단순히 화면을 그리는 기술이 아니라는 데 있습니다. HTML의 의미 구조, 브라우저 기본 동작, 키보드 탐색, 접근성 트리, 성능, 보안, 브라우저 호환성까지 함께 고려해야 비로소 좋은 Web 경험이 됩니다.
화면이 정상이어도 접근성은 실패할 수 있다
가장 대표적인 사례는 불필요하거나 잘못된 ARIA 사용입니다. 의미가 이미 정해진 네이티브 HTML 요소에 중복된 역할을 덧붙이거나, 실제 동작과 일치하지 않는 상태 정보를 제공하면 보조기술 사용자는 잘못된 안내를 받습니다.
예를 들어 일반 버튼으로 충분한 요소를 div로 만들고 role="button"을 추가했다고 가정해 보겠습니다. 시각적으로는 버튼처럼 보일 수 있습니다. 그러나 개발자가 직접 다음 동작까지 구현해야 합니다.
Enter,Space키 입력 처리- 키보드 focus 이동
- 비활성 상태 전달
- 클릭과 키보드 이벤트의 일관성 유지
- screen reader가 이해할 수 있는 이름과 상태 제공
반면 <button>은 이러한 기본 동작을 브라우저가 이미 제공합니다. 좋은 Web 코드는 필요한 기능을 직접 재구현하는 데서 출발하지 않습니다. 먼저 브라우저가 제공하는 표준 요소와 네이티브 기능으로 해결할 수 있는지 확인하는 데서 시작합니다.
ARIA는 HTML을 대체하는 도구가 아닙니다. 올바른 HTML 의미를 사용할 수 없을 때 보완하는 도구에 가깝습니다.
JavaScript로 만든 기능이 항상 더 유연한 것은 아니다
AI가 생성하는 UI 코드에는 JavaScript로 모든 상호작용을 직접 구현하는 패턴이 자주 등장합니다. tooltip, accordion, modal, popover 같은 기능을 상태값과 이벤트 핸들러로 처음부터 만드는 방식입니다.
물론 복잡한 제품 요구사항에서는 custom 구현이 필요할 수 있습니다. 하지만 단순한 상호작용이라면 네이티브 Web 기능이 더 나은 선택일 때가 많습니다.
| 요구사항 | 우선 검토할 Web 기능 | 직접 구현 시 놓치기 쉬운 부분 |
|---|---|---|
| 모달 창 | <dialog> |
focus 이동·복귀, 배경 접근 제한 |
| 팝오버 | Popover API | 열림 상태, 외부 클릭 처리, 접근성 |
| 접기/펼치기 | <details>와 <summary> |
키보드 조작, 상태 전달 |
| 버튼 | <button> |
Space/Enter 동작, disabled 상태 |
| 입력 검증 | 네이티브 form validation | 오류 메시지 연결, 접근 가능한 안내 |
네이티브 기능을 활용하면 코드량을 줄일 수 있을 뿐 아니라, 브라우저가 제공하는 기본 접근성 동작과 최적화 혜택을 함께 얻을 가능성이 커집니다. 반대로 모든 것을 JavaScript로 구현하면 작은 UI 하나에도 focus 관리, 이벤트 중복, 상태 동기화, 렌더링 비용 같은 문제가 누적됩니다.
좋은 Web 코드는 실행 환경까지 고려한다
“개발 환경에서 동작한다”는 사실은 품질의 출발점일 뿐입니다. 실제 사용자는 서로 다른 브라우저, 운영체제, 네트워크, 입력 장치, 보조기술, 성능 조건에서 서비스를 이용합니다.
따라서 AI가 만든 코드를 검토할 때는 다음 질문이 필요합니다.
- semantic HTML을 우선 사용했는가?
- 키보드만으로 모든 핵심 작업을 완료할 수 있는가?
- focus가 예측 가능한 순서로 이동하고, 모달을 닫으면 원래 위치로 돌아오는가?
prefers-reduced-motion사용자의 설정을 존중하는가?- 이미지와 스크립트가 LCP, INP, CLS에 불리한 영향을 주지 않는가?
- 선택한 API가 지원 대상 브라우저에서 안정적으로 동작하는가?
- 동적 HTML 삽입과 credential 처리가 안전한가?
이 질문들은 AI에게 더 긴 프롬프트를 입력한다고 자동으로 해결되지 않습니다. 최신 표준, Baseline 호환성, 접근성 관행, 성능 원칙을 코드 생성 단계부터 제공해야 합니다.
Modern Web Guidance 1.0이 겨냥하는 지점도 바로 여기입니다. AI가 단지 “작동하는 UI”를 만드는 데서 멈추지 않고, Web 플랫폼이 이미 제공하는 의미와 기본 동작을 우선 선택하도록 돕습니다. 다만 guidance는 방향을 제시할 뿐, 실제 품질을 보장하지는 않습니다. 생성된 결과는 결국 실제 브라우저, 키보드, screen reader, 성능 trace로 검증해야 합니다.
좋은 Web 코드는 더 많은 코드를 작성한 결과가 아닙니다. 브라우저가 잘하는 일을 브라우저에 맡기고, 사람이 실제로 사용하는 환경에서 문제없이 작동하도록 설계한 결과입니다.
Web 가이드 주입부터 코드 현대화까지, 작동 원리를 해부하다
“모달을 만들어줘”라는 요청을 받은 AI agent가 곧바로 div와 JavaScript 이벤트 핸들러부터 작성한다면, 결과물은 겉보기에는 멀쩡할 수 있습니다. 하지만 키보드 사용자는 모달 안에 갇히거나, screen reader 사용자는 배경 콘텐츠까지 계속 탐색할 수 있으며, Esc 키 동작과 focus 복귀도 빠질 수 있습니다.
Modern Web Guidance는 바로 이 지점에서 작동합니다. AI가 코드를 생성한 이전 단계부터 최신 Web 플랫폼의 사용 조건, 접근성 원칙, 브라우저 호환성, 성능 고려사항을 맥락으로 제공합니다. 또한 이미 작성된 코드에서는 낡은 구현 패턴을 찾아 현대화 후보를 제안합니다.
생성 전에 Web 플랫폼 지식을 주입한다
Modern Web Guidance의 첫 번째 역할은 agent가 요구사항을 해석할 때 참고할 수 있는 전문 지식을 제공하는 것입니다. 단순히 “모달 UI를 구현하라”는 명령을 코드로 번역하게 두지 않고, 어떤 Web 기능이 요구사항에 가장 적합한지 먼저 검토하도록 유도합니다.
모달을 예로 들면 agent는 다음 요소를 함께 고려하게 됩니다.
- 네이티브
<dialog>요소를 사용할 수 있는지 - 모달이 열릴 때 focus를 어디로 이동할지
- 닫힌 뒤 사용자의 focus를 원래 트리거로 되돌릴지
- 모달 상태에서 배경 콘텐츠가 보조기술에 노출되지 않도록 처리할지
Escape키로 닫히는 동작이 필요한지- 애니메이션에
prefers-reduced-motion을 반영할지 - 지원 대상 브라우저에서 해당 기능을 안정적으로 쓸 수 있는지
이 과정의 핵심은 “더 많은 코드를 생성하는 것”이 아닙니다. 오히려 이미 브라우저가 제공하는 기능을 활용해 불필요한 JavaScript와 직접 관리해야 할 상태를 줄이는 데 있습니다.
예를 들어 단순한 UI 상호작용이라면 custom JavaScript 구현보다 <dialog>, Popover API, <details>와 <summary>, CSS transition 같은 네이티브 Web 기능이 더 적절할 수 있습니다. 이런 선택은 코드량을 줄일 뿐 아니라 브라우저 기본 동작, 접근성 semantics, 성능 최적화를 함께 활용할 가능성을 높입니다.
호환성 정보까지 포함해 선택을 돕는다
최신 API라고 해서 모든 프로젝트에 바로 적용할 수 있는 것은 아닙니다. 서비스의 지원 브라우저 정책, 기업 고객의 환경, Safari와 모바일 브라우저의 실제 사용 비중에 따라 선택은 달라집니다.
Modern Web Guidance는 가이드에 Baseline과 브라우저 호환성 정보를 포함해, AI agent가 특정 기능을 무조건 최신 방식으로 바꾸기보다 프로젝트 조건에 맞는 대안을 판단하도록 돕습니다.
가령 agent는 다음과 같은 흐름으로 판단할 수 있습니다.
- 요구사항에 적합한 네이티브 Web API를 찾는다.
- 해당 기능의 브라우저 지원 범위를 확인한다.
- 프로젝트의 지원 정책과 비교한다.
- 사용 가능하면 표준 API를 우선 적용한다.
- 지원 범위가 부족하면 점진적 향상 또는 대체 구현을 제안한다.
이 방식은 학습 데이터에 자주 등장하는 오래된 라이브러리 의존 코드나 특정 브라우저 중심의 패턴을 반복할 위험을 낮춥니다.
기존 코드를 스캔해 현대화 기회를 찾는다
1.0에서 추가된 modernization workflow는 새 코드를 잘 작성하게 하는 데서 그치지 않습니다. 기존 HTML, CSS, JavaScript, package.json을 분석해 레거시 구현과 개선 가능성을 찾습니다.
대표적인 대상은 다음과 같습니다.
- JavaScript로 직접 구현한 단순 UI 제어
- 의미 없는
div중심의 마크업 - 불필요하거나 잘못 적용된 ARIA 속성
- 이미지 우선순위와 lazy loading이 누락된 화면
- 성능상 비용이 큰 렌더링 패턴
- 오래된 패키지 또는 브라우저 네이티브 기능으로 대체 가능한 의존성
예를 들어 accordion을 구현하기 위해 클릭 이벤트, 상태 변수, aria-expanded, 높이 계산 애니메이션을 모두 직접 관리하는 코드가 있을 수 있습니다. Guidance는 이 구조를 보고 <details>와 <summary> 또는 더 적절한 표준 패턴으로 단순화할 여지를 제안할 수 있습니다.
설치는 프로젝트 디렉터리에서 시작할 수 있습니다.
npx modern-web-guidance@latest install
이후 agent 환경에서 다음과 같이 현대화 작업을 요청할 수 있습니다.
/modern-web-guidance Modernize the code in this directory
다만 이 기능은 현재 모든 코드의 의도를 완벽히 이해하는 범용 리뷰어는 아닙니다. 제한된 패턴을 중심으로 탐지하는 static analysis 성격이 강합니다. 복잡한 비즈니스 로직, 권한 모델, 서버 상태 동기화, 설계 시스템의 제약까지 자동으로 판단한다고 기대해서는 안 됩니다.
작성 지침과 실행 검증은 역할이 다르다
Modern Web Guidance는 코드를 어떻게 작성해야 하는지 알려주는 계층입니다. 하지만 실제 사용자 환경에서 성능과 동작이 올바른지까지 단독으로 보장하지는 않습니다.
예를 들어 Guidance는 긴 작업을 분할하고 main thread blocking을 줄이는 방법을 제안할 수 있습니다. 그러나 실제 애플리케이션에서 특정 상호작용이 200ms 동안 멈추는지, 메모리가 지속적으로 증가하는지, 실제 기기에서 layout shift가 발생하는지는 런타임 측정이 필요합니다.
따라서 이상적인 workflow는 두 단계로 나뉩니다.
| 단계 | 핵심 역할 |
|---|---|
| Modern Web Guidance | 표준 API, 접근성, 호환성, 보안, 성능 원칙을 반영한 구현 방향 제시 |
| DevTools 및 브라우저 테스트 | 실제 DOM, 렌더링, 성능 trace, 메모리, 키보드 상호작용을 실행 환경에서 검증 |
실무에서는 Guidance로 생성·리팩터링의 방향을 잡고, 이어서 Chrome DevTools, Lighthouse, Playwright 또는 Cypress 테스트, 실제 기기 테스트로 결과를 확인해야 합니다. 특히 모달, 메뉴, form 같은 상호작용 UI는 키보드 전용 사용과 screen reader 시나리오까지 별도로 검증하는 것이 안전합니다.
결국 Modern Web Guidance의 가치는 AI가 “동작하는 코드”를 넘어, Web 플랫폼의 의도에 맞는 코드를 선택하도록 만드는 데 있습니다. 코드 생성과 코드 현대화의 출발점을 바꾸는 도구이지만, 최종 품질의 판단은 여전히 실행 결과와 사람의 검토를 통해 완성됩니다.
Web 숫자는 유망하다—하지만 무엇을 증명하고, 무엇은 증명하지 않을까?
한 공개 실험에서 Modern Web Guidance를 명시적으로 적용한 agent의 현대 Web 검사 통과율은 94.0%에 이르렀습니다. Guidance 없이 작업했을 때의 60.8%와 비교하면 매우 큰 차이입니다. 숫자만 보면 “AI가 만든 프런트엔드 코드의 품질 문제가 거의 해결됐다”고 느낄 수 있습니다.
하지만 이 결과를 그대로 모든 프로젝트에 적용하는 것은 위험합니다. 94.0%는 특정 저장소, 특정 작업, 특정 자동 검사 기준에서 얻은 통과율이지, 모든 사이트의 성능·접근성·보안이 94% 보장된다는 뜻은 아닙니다.
94.0%가 보여주는 것
note inc.가 production Next.js repository clone을 대상으로 진행한 실험에서, 주력 coding agent는 다음과 같은 결과를 보였습니다.
| 조건 | 현대 Web 검사 통과율 |
|---|---|
| Guidance 미사용 | 60.8% |
| 일반적인 Guidance 적용 | 76.5% |
| Guidance를 명시적으로 지시 | 94.0% |
보조 모델 역시 75.8%에서 90.0%로 개선됐습니다. 이 결과가 시사하는 바는 분명합니다.
- AI agent는 최신 Web 표준과 구체적인 검증 기준을 제공받을 때 더 나은 선택을 한다.
- semantic HTML, 이미지 우선순위, 네이티브 UI 요소, 접근성 관련 기본 요구사항에서 반복 오류를 줄일 수 있다.
- 막연하게 “좋은 코드로 작성해 달라”고 요청하는 것보다, 검증된 Web guidance를 작업 맥락에 넣는 편이 효과적이다.
- AI 생성 PR의 초기 품질을 높여 개발자 리뷰와 수동 감사 부담을 줄일 가능성이 있다.
공개 nightly evaluation에서도 Guidance 사용 agent는 자동 검사 약 88%를 통과했고, 미사용 agent는 약 56%를 통과한 것으로 소개됐습니다. 즉, Guidance가 AI의 Web 플랫폼 이해 부족을 보완하는 데 실질적인 효과를 낼 수 있다는 근거는 충분히 유망합니다.
그러나 이 숫자가 증명하지 않는 것
가장 중요한 질문은 “무엇을 통과했는가?”입니다. 공개된 평가는 모든 사용자 경험과 운영 환경을 포괄하는 종합 감사가 아닙니다. 주로 DOM, 스타일, 소스 코드에서 확인 가능한 제한된 자동 검사에 기반합니다.
따라서 높은 통과율은 다음을 자동으로 보장하지 않습니다.
실사용자 Core Web Vitals 개선
LCP, INP, CLS는 실제 네트워크 환경, 기기 성능, 서드파티 스크립트, 서버 응답 시간의 영향을 함께 받습니다. 코드 가이드 통과만으로 현장 성능이 개선됐다고 단정할 수 없습니다.완전한 접근성 준수
자동 검사는 누락된 label, 잘못된 속성, 일부 키보드 문제를 찾는 데 유용합니다. 그러나 screen reader 사용자가 복잡한 결제 과정이나 다단계 폼을 실제로 이해하고 완료할 수 있는지는 별도의 수동 검증이 필요합니다.보안 취약점 제거
sanitization, CSP, Passkey 관리와 같은 가이드는 도움이 되지만, 인증 흐름, 권한 검증, API 보안, 서버 측 데이터 처리까지 보장하지는 않습니다.모든 브라우저에서의 동일한 동작
Baseline과 호환성 정보가 포함돼 있어도, Safari와 모바일 브라우저, 기업 환경의 관리형 브라우저, 특수 입력 장치에서의 실제 동작은 직접 확인해야 합니다.복잡한 비즈니스 로직의 정확성
현재 modernization workflow는 제한된 패턴을 탐지하는 static analysis 중심입니다. 상태 관리, 권한 모델, 결제 규칙, 데이터 정합성처럼 코드 의미를 깊게 이해해야 하는 문제는 별도 리뷰가 필요합니다.
숫자를 올바르게 읽는 방법
이 결과는 “Modern Web Guidance가 품질을 보장한다”는 증거라기보다, AI agent가 검증된 Web 지식을 제공받을 때 기본적인 구현 품질을 크게 높일 수 있다는 증거로 읽는 편이 정확합니다.
특히 다음과 같은 영역에서는 높은 통과율이 실무적 가치를 가질 수 있습니다.
div중심 UI를 semantic HTML로 교체- JavaScript로 직접 구현한 UI를
<dialog>, Popover, native form 기능으로 전환 - 이미지의 loading 및 fetch priority 개선
- 키보드 focus와 reduced-motion 대응 누락 탐지
- 불필요한 ARIA 속성 또는 오래된 Web 패턴 제거
반대로 “검사 통과율이 높다”는 이유만으로 배포 판단을 내려서는 안 됩니다. 자동 검사는 출발점이고, 제품 품질은 실제 실행 환경에서 확인해야 합니다.
가장 현실적인 해석: 생성 품질과 실행 품질은 다르다
Modern Web Guidance는 작성 단계의 품질 기준을 강화합니다. 반면 실제 성능과 사용자 경험은 런타임에서 검증해야 합니다. 따라서 가장 효과적인 접근은 두 도구와 과정을 결합하는 것입니다.
- Guidance로 AI가 생성하거나 리팩터링하는 코드의 방향을 통제합니다.
- PR에서 변경 사항을 사람이 검토합니다.
- Playwright, Cypress 등으로 핵심 사용자 흐름을 브라우저에서 테스트합니다.
- DevTools trace, Lighthouse, field monitoring으로 실제 성능을 측정합니다.
- 키보드 전용 사용과 screen reader 시나리오를 직접 점검합니다.
94.0%라는 숫자는 분명 흥미롭습니다. 다만 이 숫자의 진짜 가치는 “품질 검토가 필요 없어졌다”는 데 있지 않습니다. AI가 만든 Web 코드에서 반복적으로 발생하던 기본 오류를 더 이른 단계에서 줄일 수 있게 됐다는 데 있습니다.
AI 프런트엔드의 새 기본값을 만드는 Web workflow, 마지막 검증은 브라우저에서
Modern Web Guidance가 바꾸려는 것은 브라우저 API 목록이 아닙니다. 더 중요한 변화는 AI가 코드를 작성하는 순간, 어떤 선택을 “기본값”으로 삼게 하느냐입니다.
예를 들어 agent에게 모달, 아코디언, 툴팁을 만들어 달라고 요청했을 때 과거의 기본값은 대개 이렇습니다.
div와 이벤트 핸들러를 조합한다.- 필요한 동작을 JavaScript로 직접 구현한다.
- 나중에 ARIA 속성을 덧붙인다.
- 문제가 생기면 접근성·성능 감사를 별도로 수행한다.
Modern Web Guidance는 이 흐름을 뒤집습니다. 먼저 semantic HTML과 native Web 기능을 검토하고, 브라우저 호환성·키보드 조작·focus 관리·reduced motion을 함께 고려하도록 agent의 출발점을 바꿉니다. 즉, “작동하는 코드”보다 “Web 플랫폼의 기본 동작을 활용하는 코드”를 우선 선택하게 만드는 것입니다.
하지만 여기서 중요한 원칙이 있습니다. 가이드는 구현 방향을 개선하지만, 실행 결과를 보증하지는 않습니다.
<dialog>를 사용했다고 해서 모든 focus 이동이 올바른 것은 아닙니다. 이미지 우선순위를 지정했다고 해서 실제 LCP가 개선되는 것도 아닙니다. CSS 기반 구현으로 바꿨다고 해서 저사양 모바일 기기에서 애니메이션이 매끄럽다는 보장도 없습니다. AI가 제안한 현대화는 반드시 실제 브라우저에서 검증해야 합니다.
가이드와 실행 검증을 분리하는 이유
Modern Web Guidance는 작성 단계의 전문지식 계층입니다. agent가 오래된 JavaScript 패턴을 피하고, 접근 가능한 마크업과 Baseline 호환 기능을 선택하도록 돕습니다. 반면 성능, 렌더링, 메모리, 실제 상호작용 품질은 런타임에서만 확인할 수 있습니다.
따라서 팀은 역할을 명확히 나누는 편이 좋습니다.
| 단계 | 확인할 것 | 적합한 수단 |
|---|---|---|
| 작성 전·중 | semantic HTML, native API, 접근성 패턴, 호환성 | Modern Web Guidance |
| 코드 변경 후 | DOM 구조, 키보드 조작, form 동작, 회귀 여부 | unit test, Playwright/Cypress |
| 브라우저 실행 중 | LCP, INP, CLS, long task, layout shift, 메모리 | Chrome DevTools, Lighthouse, 성능 trace |
| 배포 후 | 실제 사용자 환경의 성능과 오류 | RUM, 오류 모니터링, Web Vitals |
이 구조의 핵심은 간단합니다. Guidance는 더 나은 질문을 하게 만들고, 브라우저 검증은 실제 답을 확인합니다.
작은 변경부터 검증 가능한 단위로 도입하기
처음부터 전체 저장소를 agent에게 현대화하라고 맡기는 방식은 위험합니다. 레거시 UI에는 디자인 시스템, 비즈니스 규칙, 브라우저 지원 정책, 사용자 행동 데이터가 얽혀 있기 때문입니다.
대신 변경 범위를 작게 쪼개고, 각 변경에 명확한 성공 기준을 붙이세요.
- Dialog 개선:
<dialog>적용 후 Escape 닫기, focus 반환, screen reader 안내를 확인합니다. - Form 개선: 네이티브 validation과 오류 메시지를 적용한 뒤 키보드 전용 입력 및 오류 복구 흐름을 테스트합니다.
- 이미지 최적화: LCP 후보 이미지를 식별하고 loading priority 변경 전후의 실측 데이터를 비교합니다.
- 애니메이션 개선:
prefers-reduced-motion대응을 추가하고, 전환 효과가 핵심 정보 전달을 방해하지 않는지 확인합니다. - 레거시 상호작용 제거: JavaScript 기반 UI를 CSS 또는 native 요소로 교체한 뒤 bundle size, long task, 기능 회귀를 함께 점검합니다.
이때 agent가 만든 변경은 자동 병합 대상이 아니라 검토 가능한 PR 초안으로 다루는 것이 바람직합니다. 코드 리뷰에서는 “최신 API를 썼는가”보다 다음 질문이 더 중요합니다.
- 이 변경이 사용자 시나리오를 실제로 개선하는가?
- 지원 대상 브라우저에서 동일하게 동작하는가?
- 키보드와 보조기술 사용자가 막히지 않는가?
- 성능 지표와 번들 크기에 부정적 영향은 없는가?
- 기존 디자인 시스템 및 제품 규칙과 충돌하지 않는가?
AI 생성 코드의 기본값을 팀의 기준으로 바꾸는 법
Modern Web Guidance의 진짜 가치는 한 번의 리팩터링보다 팀의 반복 작업에 있습니다. 여러 개발자가 서로 다른 agent와 도구를 사용하더라도, Web 표준과 접근성 원칙을 공통의 출발점으로 삼게 할 수 있습니다.
도입 초기에는 다음과 같은 운영 방식이 현실적입니다.
npx modern-web-guidance@latest install
설치 후에는 새 기능 개발과 레거시 개선 작업에서 제한적으로 사용합니다. 예를 들어 “이 디렉터리의 form 접근성을 개선하되, 지원 브라우저와 기존 디자인 토큰을 유지하라”처럼 범위와 제약을 함께 지정합니다. 이후 자동 테스트와 실제 브라우저 검증을 통과한 변경만 확장합니다.
특히 금융·커머스·공공 서비스처럼 접근성과 다중 브라우저 지원이 중요한 팀이라면, 다음 항목을 PR 체크리스트에 연결할 수 있습니다.
- semantic HTML을 우선 사용했는가
- 불필요한 ARIA를 추가하지 않았는가
- 키보드 focus와 Escape 동작을 확인했는가
prefers-reduced-motion을 고려했는가- 주요 화면에서 LCP·INP·CLS 영향을 측정했는가
- Chrome뿐 아니라 지원 대상 Firefox, Edge, Safari, 모바일 환경을 확인했는가
결국 목표는 AI에게 모든 판단을 넘기는 일이 아닙니다. AI가 낡은 관행을 자동으로 반복하지 않도록 기본값을 교정하고, 팀이 브라우저에서 결과를 확인하는 습관을 강화하는 일입니다.
Modern Web Guidance는 AI 프런트엔드 개발의 출발점을 더 현대적인 Web으로 옮겨 줍니다. 그러나 제품 품질의 마지막 관문은 여전히 코드가 아니라, 실제 사용자와 실제 브라우저가 만나는 실행 환경입니다.
