# 13. 브라우저 호환성 가이드

## 0. 먼저 알고 가기 (30초 요약)

- 모든 브라우저를 같은 동작으로 보기보다 `지원 대상`을 먼저 고정하세요.
- 모던 API는 폴리필 정책으로 안전망을 만들고, 위험한 구문은 점진 교체하세요.
- 자동화된 브라우저 테스트를 최소 2개 엔진에서 실행해 회귀를 줄이세요.

## 초심자용 한눈에 보기

브라우저가 다르므로 "기능이 꼭 필요한 곳만" 안정적으로 노출시키는 접근이 중요합니다.

> 일상 비유: 여러 종류의 차에 같은 부품을 끼우는 정비소와 같습니다. 모든 차에 똑같은 부품(최신 API)을 강제하면 일부 차종은 못 굴러갑니다. 차종별(브라우저별)로 사용 가능한 부품을 분류하고, 필요하면 어댑터(polyfill)를 끼우거나 다른 길(fallback)을 안내해야 합니다.

### 핵심 용어 빠르게 정리

| 용어                      | 쉬운 뜻                                           |
| ------------------------- | ------------------------------------------------- |
| `브라우저 호환성`         | 어떤 브라우저에서 동작 보장하는 범위              |
| `feature detection`       | 기능이 있는지 실행 전 확인하는 방식               |
| `polyfill`                | 없는 기능을 보완하는 코드                         |
| `fallback`                | 기능이 안 되면 대체로 보여줄 동작                 |
| `지원 tier`               | 지원을 약속한 브라우저 조합                       |
| `Baseline`                | web.dev 기준 모든 주요 엔진 지원 여부 분류        |
| `progressive enhancement` | 기본 동작은 모두에게, 추가 기능은 지원되는 곳에만 |

### 지원 tier 한눈에 보기

> 왜 중요한가: 모든 브라우저를 똑같이 지원하려 하면 비용이 폭발합니다. 사용자 데이터 기반으로 등급을 나눠야 검증·테스트 자원을 합리적으로 배분할 수 있습니다.

```mermaid
flowchart LR
  T1["Tier 1\n핵심 사용자/매출 영향"] --> A1["모든 핵심 flow 자동/수동 검증"]
  T2["Tier 2\n낮은 비중 but 지원 필요"] --> A2["주요 flow smoke + graceful fallback"]
  U["Unsupported\nEOL/극소수"] --> A3["안내 페이지 또는 기능 제한"]
```

| 분류            | 품질 & 사용자 환경                                                                                                                                             | 상태          | Stable    |
| :-------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------ | :-------- |
| **연관 가이드** | [07. 테스팅](./07_테스팅_가이드.md), [08. 성능](./08_성능_최적화_가이드.md), [11. CI/CD](./11_CICD_파이프라인_표준.md), [19. 접근성](./19_웹_접근성_가이드.md) | **도구 원칙** | 벤더 중립 |
| **핵심 테마**   | 지원 범위, feature detection, polyfill allowlist, progressive enhancement, cross-browser CI                                                                    | **Update**    | 최신 기준 |

---

> 브라우저 호환성 표준은 특정 브라우저 취향이 아니라 **지원 범위, 감지 방식, fallback, 테스트 매트릭스**를 명문화하는 품질 계약입니다.

---

## 추천 항목 (실무 우선순위)

- **시작 추천**: 지원 브라우저 tier를 먼저 고정하고 테스트 매트릭스에 넣습니다.
- **안정 추천**: 기능 탐지 + 폴리필 전략을 레이어별로 정리해 유지 비용을 낮춥니다.
- **운영 추천**: 크로스 브라우저 회귀는 자동화되고 실패 이슈는 PR 템플릿으로 추적하세요.

## 추천 항목 고도화 체크

- `첫 적용` — Baseline, feature detection, polyfill 전략 중 하나를 실제 PR이나 운영 이슈에 붙이고, 변경 전 기준을 먼저 적는다.
- `증거 정리` — browser matrix, smoke run, feature support 링크를 같은 작업 기록에 남긴다.
- `재점검` — unsupported feature 수, polyfill KB, browser-specific bug가 나아졌는지 30일 안에 확인하고 기준을 유지, 수정, 폐기 중 하나로 판정한다.

## 추천 항목 실행 기록 템플릿

- `작업` : Baseline, feature detection, polyfill 전략 적용 범위를 어느 화면, 패키지, 문서에 둘지 적는다.
- `증거` : browser matrix, smoke run, feature support 링크 중 실제로 남긴 항목만 링크한다.
- `판정` : 유지/수정/폐기 중 하나와 이유를 한 문장으로 남긴다.
- `다음 점검` : unsupported feature 수, polyfill KB, browser-specific bug를 다시 볼 날짜와 담당자를 지정한다.

## 문서 책임 범위

| 이 문서가 결정하는 것                                          | 단일 출처로 따르는 문서                                                                                                                |
| :------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------- |
| 지원 tier, browserslist, feature detection, polyfill allowlist | [07. 테스팅](./07_테스팅_가이드.md), [11. CI/CD](./11_CICD_파이프라인_표준.md)                                                         |
| cross-browser smoke와 real device evidence 기준                | [08. 성능](./08_성능_최적화_가이드.md), [09. 관측성](./09_장애_대응_및_관측성_표준.md)                                                 |
| 접근성/RTL/motion 호환성 검증                                  | [19. 웹 접근성](./19_웹_접근성_가이드.md), [23. 국제화](./23_국제화_가이드.md), [25. 웹 애니메이션](./25_웹_애니메이션_모션_가이드.md) |
| 디자인 시스템 컴포넌트의 브라우저 지원 기준                    | [20. 디자인 시스템](./20_디자인_시스템_가이드.md)                                                                                      |

---

## 0. 모든 프론트엔드 그룹 공통 Baseline

| 영역                     | 공통 기준                                          | 검증 방법                    |
| :----------------------- | :------------------------------------------------- | :--------------------------- |
| **지원 tier**            | Tier 1, Tier 2, unsupported browser를 명시         | 실제 사용자 분포 + 제품 요구 |
| **browserslist**         | 코드 변환/폴리필/테스트 기준을 repo에 고정         | CI에서 출력 확인             |
| **Feature detection**    | UA sniffing보다 `@supports`, capability check 우선 | fallback test                |
| **Polyfill allowlist**   | 필요한 API만 조건부 로드, 공급망 위험 검토         | bundle audit                 |
| **Cross-browser CI**     | 핵심 flow는 Chromium/Firefox/WebKit 계열에서 smoke | E2E matrix                   |
| **Fallback UX**          | 미지원 기능은 기능 축소, 안내, 대체 flow 제공      | manual QA                    |
| **Real device evidence** | 모바일/터치/저성능 환경 이슈는 실제 기기 증적 확보 | screenshot/trace             |

### 0.0 브라우저 호환성 처리 흐름

```mermaid
flowchart TD
  A[새 기능/스타일 변경] --> B{영향받는 브라우저 tier 분석}
  B -->|미지원 위험 큼| C[Baseline/Limited/Newly/Widely 상태 점검]
  B -->|호환성 리스크 낮음| D[기본 기능 채택]
  C --> E{필수 기능인가?}
  E -->|예| F[Feature detection + fallback 정의]
  E -->|아니오| G[Polyfill allowlist 점검 후 보류]
  F --> H[Cross-browser smoke 계획 수립]
  D --> H
  G --> H
  H --> I{테스트 증적 생성}
  I -->|Pass| J[실제 기기/로그 증적 첨부]
  I -->|Fail| K[지원 tier/UA 정책 재정의]
  J --> L[릴리즈 Gate 승인]
```

### 0.1 교차 검증 매트릭스

| 권고                    | 1차 출처                     | 실행 증거                             | 운영 증거                   | 철회 조건                       |
| :---------------------- | :--------------------------- | :------------------------------------ | :-------------------------- | :------------------------------ |
| Baseline 기반 기능 채택 | web.dev/MDN Baseline 상태    | feature detection test, browser smoke | browser-specific error rate | Tier 1 실패 시 fallback 필수    |
| Polyfill allowlist      | Web API/TC39/W3C 상태        | conditional import test, bundle diff  | long task, load time        | 지원률 상승 시 polyfill 제거    |
| 지원 tier               | 실제 사용자 분석 + 제품 요구 | browserslist output, E2E matrix       | unsupported traffic share   | 사용률/계약 변동 시 tier 재검토 |

### 0.2 운영 게이트

| Gate                | Evidence                                     | Owner          | Rollback                             |
| :------------------ | :------------------------------------------- | :------------- | :----------------------------------- |
| 지원 범위 변경      | browser usage, 제품 요구, browserslist diff  | FE owner       | 기존 tier 유지 또는 fallback 제공    |
| Feature adoption    | feature detection test, unsupported smoke    | Feature owner  | capability check 기반 no-op/fallback |
| Polyfill allowlist  | bundle diff, 공급망 검토, 조건부 로드 테스트 | Platform owner | polyfill 제거 또는 lazy loading 전환 |
| Cross-browser smoke | Chromium/Firefox/WebKit 핵심 flow report     | QA owner       | release 차단 또는 tier별 제한 공지   |

---

### 0.3 Baseline 단계별 채택 기준

> 일상 비유: 새로 출시된 약을 떠올려 보세요. 임상시험 중인 약(Limited)은 제한된 환자에게만, 시판된 지 얼마 안 된 약(Newly)은 부작용을 모니터링하며, 오래 검증된 약(Widely)은 안심하고 처방합니다.

web.dev Baseline은 기능을 `Limited availability`, `Newly available`, `Widely available`로 구분합니다. 이 문서는 그 상태를 그대로 표준화하지 않고, 제품 tier와 fallback 비용을 함께 봅니다.

| Baseline 상태        | 기본 등급                    | production 채택 조건                                           | 테스트/폴리필 기준                              |
| :------------------- | :--------------------------- | :------------------------------------------------------------- | :---------------------------------------------- |
| Limited availability | Experimental Watch           | 핵심 flow가 아니고 capability check와 대체 UX가 있을 때만 허용 | feature flag, Tier 1 smoke, fallback 필수       |
| Newly available      | Conditional 또는 Recommended | Tier 1 사용자가 모두 지원하고, 실패 시 기능 축소가 가능한 경우 | `@supports`/runtime check, WebKit/Firefox smoke |
| Widely available     | Baseline                     | 제품 지원 tier와 browserslist가 모두 만족할 때 기본 사용 가능  | polyfill 제거 후보, regression test 유지        |

새 기능을 채택할 때는 Baseline 상태, MDN/Can I Use 지원표, 실제 사용자 브라우저 분포, 접근성 영향, 번들/INP 비용을 한 PR에 함께 남깁니다.

```mermaid
flowchart LR
  L["Limited\n일부 엔진만"] --> N["Newly\n주요 엔진 모두 최근 지원"]
  N --> W["Widely\n30개월+ 안정 지원"]
  L --> LR["사용 금지 기본, 실험만"]
  N --> NR["조건부 사용 + fallback"]
  W --> WR["기본 사용 가능"]
```

### 0.4 Baseline 라이프사이클 상태도

> 비유: 신메뉴 -> 인기 메뉴 -> 스테디셀러로 옮겨가는 음식점 메뉴판처럼, 기능도 채택 등급이 시간이 지나면서 자연스럽게 이동합니다.

```mermaid
stateDiagram-v2
  [*] --> Experimental: 사양/엔진 도입
  Experimental --> LimitedAvailable: 주요 엔진 일부 지원
  LimitedAvailable --> NewlyAvailable: 모든 주요 엔진 지원
  NewlyAvailable --> WidelyAvailable: 30개월 이상 안정 지원
  WidelyAvailable --> Deprecated: 후속 표준 도입
  Deprecated --> [*]
  Experimental --> Dropped: 표준 폐기/엔진 미채택
  Dropped --> [*]
```

---

## 1. 지원 범위 정의

| Tier            | 기준                                                 | 지원 수준                           |
| :-------------- | :--------------------------------------------------- | :---------------------------------- |
| **Tier 1**      | 핵심 사용자 비중이 높고 매출/업무 영향이 큰 브라우저 | 모든 핵심 flow 자동/수동 검증       |
| **Tier 2**      | 사용자 비중은 낮지만 지원 필요성이 있는 브라우저     | 주요 flow smoke와 graceful fallback |
| **Unsupported** | 보안 업데이트 종료, 사용률 매우 낮음, 기술적 제약 큼 | 안내 페이지 또는 기능 제한          |

지원 범위는 개발팀 선호가 아니라 실제 사용자 데이터, 법적/계약 요구, 제품 전략, 유지보수 비용으로 결정합니다.

---

## 2. Feature Detection

기능 지원 여부는 브라우저 이름보다 실제 capability로 판단합니다.

> **일상 비유**: 우산을 챙길 때 일기예보 사이트 이름(UA)을 보는 것이 아니라 "지금 비가 오는가"(capability)를 직접 묻는 방식입니다. 예보 사이트가 오답을 내도, 실제 날씨를 보면 틀릴 일이 줄어듭니다.

이 그림은 화면 진입 시 capability check를 거쳐 모던 구현, fallback, 비노출로 분기하는 흐름을 보여줍니다.

```mermaid
flowchart TD
  REQ([화면/컴포넌트 진입]) --> CAP{capability check}
  CAP -->|지원| NEW[모던 API 구현 실행]
  CAP -->|미지원| ALT{대체 가능?}
  ALT -->|예| FB[fallback UI/로직 실행]
  ALT -->|아니오| NOOP[기능 비노출 + 사용자 안내]
  NEW --> LOG[성능/오류 계측]
  FB --> LOG
  NOOP --> LOG
  LOG --> END([렌더 완료])
```

```typescript
export function supportsViewTransition(): boolean {
  return typeof document !== 'undefined' && 'startViewTransition' in document
}

export function supportsContainerQuery(): boolean {
  return typeof CSS !== 'undefined' && CSS.supports('container-type', 'inline-size')
}
```

```css
@supports (container-type: inline-size) {
  .card-list {
    container-type: inline-size;
  }
}

@supports not (container-type: inline-size) {
  .card-list {
    display: grid;
  }
}
```

UA sniffing은 분석, 특정 알려진 엔진 버그 우회, 임시 hotfix처럼 제한된 경우에만 사용하고 만료일을 둡니다.

---

## 3. Polyfill 원칙

> 일상 비유: 콘센트 어댑터처럼 꼭 필요한 곳에서만 끼우고, 표준 콘센트가 보급되면 다시 빼야 합니다. 늘 들고 다니면 가방이 무거워집니다(bundle 비용).

| 원칙        | 기준                                                    |
| :---------- | :------------------------------------------------------ |
| 조건부 로드 | 네이티브 지원 시 다운로드하지 않음                      |
| 최소 범위   | 전체 polyfill bundle보다 필요한 API만                   |
| 공급망 검토 | 외부 CDN 임의 로드 금지, lockfile/해시/자체 호스팅 검토 |
| 성능 측정   | polyfill 추가 전후 bundle size와 INP/LCP 확인           |
| 제거 계획   | browserslist 변경 시 더 이상 필요 없는 polyfill 제거    |

### 3.1 polyfill 채택 결정 트리

> 왜 중요한가: 모든 사용자에게 일괄로 polyfill을 넣는 습관은 모던 브라우저 사용자에게도 불필요한 다운로드를 강요합니다.

```mermaid
flowchart TD
  Need[해당 API가 핵심 flow에 필요한가] -->|아니오| Skip[사용 보류 + fallback UX]
  Need -->|예| Tier{Tier 1 사용자가 모두 지원하는가}
  Tier -->|예| Native[그대로 사용]
  Tier -->|아니오| FB[fallback으로 충분한가]
  FB -->|예| Det[feature detection + fallback]
  FB -->|아니오| Q1{공급망 검토 통과}
  Q1 -->|아니오| Reject[채택 보류 + RFC 검토]
  Q1 -->|예| Q2{번들 영향 < 예산}
  Q2 -->|아니오| Lazy[lazy/conditional 로드 시도]
  Q2 -->|예| Add[allowlist 등록 + 만료일]
  Lazy --> Add
```

```typescript
export async function ensureIntlSegmenter(): Promise<void> {
  if ('Segmenter' in Intl) return
  await import('./polyfills/intl-segmenter')
}
```

---

## 4. CSS 호환성 기준

| 기능             | 적용 기준                              |
| :--------------- | :------------------------------------- |
| 최신 layout 기능 | fallback layout을 함께 제공            |
| 애니메이션       | `prefers-reduced-motion` 준수          |
| 색상/테마        | forced-colors, contrast mode 확인      |
| form control     | native behavior와 keyboard 접근성 유지 |
| viewport units   | 모바일 주소창 변화 대응                |

새 CSS 기능은 design system primitive에서 먼저 흡수하고, 제품 화면마다 개별 fallback을 만들지 않습니다.

---

## 5. Cross-Browser 테스트 매트릭스

> 왜 중요한가: 테스트 범위가 좁으면 특정 엔진에서만 깨지는 회귀를 놓치고, 너무 넓으면 CI 시간이 폭발합니다. 빈도와 범위는 다르게 두는 것이 핵심입니다.

| 테스트          | 브라우저 범위                | 빈도             |
| :-------------- | :--------------------------- | :--------------- |
| Unit/DOM        | 기본 런타임                  | PR마다           |
| Component smoke | 주요 렌더링 엔진 1개 이상    | PR마다           |
| 핵심 E2E        | Chromium/Firefox/WebKit 계열 | PR 또는 merge 전 |
| 접근성 keyboard | Tier 1 브라우저              | release 전       |
| 실제 기기 QA    | 모바일/터치 주요 조합        | 주요 release 전  |

모든 테스트를 모든 브라우저에서 돌리는 것은 비용이 큽니다. 핵심 flow와 호환성 위험이 높은 영역을 우선합니다.

```mermaid
flowchart LR
  PR["PR 단위"] --> U1["Unit/DOM\n기본 런타임"]
  PR --> U2["Component smoke\n1+ 엔진"]
  Merge["merge 전"] --> E["E2E\nChromium+Firefox+WebKit"]
  Rel["release 전"] --> A["A11y keyboard\nTier 1"]
  Rel --> D["실기기 QA\n모바일/터치"]
```

이 그림은 PR이 머지되어 릴리즈에 이르기까지 cross-browser smoke가 어떤 순서로 실행되고 결과가 누구에게 전달되는지를 보여줍니다.

```mermaid
sequenceDiagram
  participant Dev as 개발자
  participant CI as CI runner
  participant Chr as Chromium 엔진
  participant FF as Firefox 엔진
  participant WK as WebKit 엔진
  participant QA as QA 오너
  Dev->>CI: PR push
  CI->>Chr: 핵심 E2E 실행
  CI->>FF: 핵심 E2E 실행
  CI->>WK: 핵심 E2E 실행
  Chr-->>CI: pass/fail + trace
  FF-->>CI: pass/fail + trace
  WK-->>CI: pass/fail + trace
  alt 모든 엔진 pass
    CI-->>Dev: 머지 가능 표시
    CI->>QA: release 전 a11y/실기기 큐 등록
  else 엔진별 실패
    CI-->>Dev: 실패 엔진/스크린샷/trace 첨부
    Dev->>Dev: fallback 또는 polyfill 결정
  end
```

---

## 6. 호환성 이슈 triage

> 일상 비유: 응급실 환자 분류와 비슷합니다. 증상이 어디서, 누구에게, 얼마나 심각하게 나타나는지를 확인해 우선순위와 처치(폴리필/폴백/RFC)를 결정합니다.

| 질문                                   | 판단                         |
| :------------------------------------- | :--------------------------- |
| 특정 브라우저에서만 실패하는가         | 호환성 또는 엔진 버그 가능성 |
| 동일 브라우저의 특정 버전만 실패하는가 | 버전별 미구현/버그 가능성    |
| polyfill 추가로 해결되는가             | API 미지원 가능성            |
| CSS fallback으로 해결되는가            | progressive enhancement 적용 |
| 제품 핵심 flow를 막는가                | P0/P1로 승격                 |

이슈에는 브라우저 버전, OS, 기기, 스크린샷, trace, 최소 재현 코드, fallback 방안을 함께 남깁니다.

```mermaid
flowchart TD
  Bug[버그 리포트] --> Q1{어디서 발생}
  Q1 -->|모든 브라우저| Q2[제품 로직 버그]
  Q1 -->|특정 엔진만| Q3[엔진 호환성/버그]
  Q1 -->|특정 버전만| Q4[버전별 회귀]
  Q3 --> S1{polyfill로 해결}
  S1 -->|예| P1[조건부 polyfill 추가]
  S1 -->|아니오| S2{CSS/JS fallback 가능}
  S2 -->|예| P2[progressive enhancement]
  S2 -->|아니오| P3[기능 축소 + 안내]
  Q4 --> V[버전 분포 확인 후 우선순위 결정]
  P1 --> Sev{핵심 flow 차단 여부}
  P2 --> Sev
  P3 --> Sev
  Sev -->|차단| Hot[P0/P1 승격]
  Sev -->|차단 없음| Norm[일반 백로그]
```

---

## 7. 체크리스트

- [ ] repo에 browserslist 또는 동등한 지원 범위 정의가 있는가
- [ ] Tier 1/2/unsupported 기준이 사용자 데이터와 연결되어 있는가
- [ ] 최신 Web API 사용 시 feature detection이 있는가
- [ ] Limited/Newly/Widely available 상태에 따라 채택 등급과 fallback을 기록했는가
- [ ] polyfill이 allowlist 방식으로 관리되는가
- [ ] 외부 polyfill CDN을 무검증으로 로드하지 않는가
- [ ] 핵심 flow가 주요 렌더링 엔진에서 자동 검증되는가
- [ ] 미지원 브라우저 사용자에게 fallback 또는 안내가 제공되는가
- [ ] 실제 기기 이슈는 screenshot/trace 증적이 남는가

---

## 8. 제외한 벤더 종속 항목

공통 개발 가이드에는 특정 브라우저 테스트 SaaS, 특정 디바이스 클라우드, 특정 브라우저 벤더의 콘솔 절차, 특정 상용 호환성 리포트 사용법을 표준으로 포함하지 않습니다. 이 문서는 어떤 테스트 인프라를 쓰더라도 유지되어야 하는 지원 범위, feature detection, polyfill, fallback, 테스트 매트릭스 기준만 남깁니다.

---

## 실무 적용 가이드

### 언제 이 문서를 펼칠까

- 새 Web API를 쓰고 싶지만 일부 브라우저 지원이 불확실할 때
- polyfill이 bundle size를 크게 늘릴 때
- 특정 브라우저에서만 핵심 flow가 깨질 때

### 적용 순서

1. 지원 browser tier와 사용자 비중을 정한다.
2. Baseline, MDN, 공식 문서로 API 상태를 확인한다.
3. feature detection과 fallback을 먼저 구현한다.
4. polyfill은 allowlist와 bundle budget 안에서만 추가한다.
5. Playwright matrix 또는 실제 기기 smoke 결과를 남긴다.

### 함께 두는 파일

- feature detection helper는 사용 feature 가까이에 둔다.
- 공통 browser capability util은 테스트와 함께 shared로 둔다.
- fallback UI와 E2E는 기능 폴더에 둔다.

### 흔한 실수

- UA sniffing만으로 분기한다.
- 지원하지 않는 브라우저에서 기능이 조용히 실패한다.
- polyfill 비용을 route별로 보지 않는다.
- 접근성 보조기술 조합을 브라우저 테스트에서 제외한다.

### PR 완료 기준

- [ ] 지원 tier가 명시되어 있다.
- [ ] feature detection/fallback 테스트가 있다.
- [ ] polyfill bundle diff가 확인되었다.
- [ ] 핵심 flow cross-browser smoke가 있다.

## 추천 항목 실행 우선순위 매핑

- `P1(7일 내)` — Baseline, feature detection, polyfill 전략 중 하나를 작은 변경 1건에 적용하고 증거(browser matrix)를 남긴다.
- `P2(30일 내)` — 브라우저 호환성 기준을 팀 템플릿, 체크리스트, CI 중 한 곳에 고정한다.
- `P3(90일 내)` — unsupported feature 수, polyfill KB, browser-specific bug 추이를 보고 기준을 유지할지 조정할지 결정한다.
- `완료 기준` — 호환성 오너가 증거와 철회 조건을 확인했다는 기록을 남긴다.

## 추천 항목 실행 체크리스트

- [ ] `1단계(7일)` : Baseline, feature detection, polyfill 전략 적용 대상을 1개로 좁힌다.
- [ ] `2단계(30일)` : 증거(browser matrix, smoke run, feature support 링크)를 PR, ADR, 회고 중 한 곳에 연결한다.
- [ ] `3단계(60일)` : unsupported feature 수, polyfill KB, browser-specific bug가 기준 안에 들어왔는지 확인한다.
- [ ] `문제 대응` : 미달성 사유와 다음 조치, 중단 여부를 같은 기록에 남긴다.

## 추천 항목 실행 운영 규칙

- `실행 게이트` : Limited availability 기능은 fallback과 측정 범위를 먼저 둔다.
- `승인 체계` : 호환성 오너가 영향 범위와 rollback 담당자를 적용 전에 확인한다.
- `재개 조건` : 지원 브라우저 smoke가 통과하면 기능 사용 범위를 넓힌다.
- `정지 조건` : feature detection 없이 UA 분기만 늘어나면 적용을 멈춘다.
- `리스크 점수` : 사용자 브라우저 비중, polyfill 무게, fallback 품질로 산정한다.
- `리더 승인자` : 프론트엔드 플랫폼 리드가 최종 승인 책임을 맡는다.
- `승인 역할` : 브라우저 호환성 작성자, 검토자, 운영 확인자를 분리해 기록한다.
- `재평가 주기` : 분기마다 Baseline 상태와 지원 matrix를 갱신한다.