웹상의 변화를 따라잡고 이러한 변화가 일어나는 이유를 이해하기 어렵다는 개발자들의 의견이 많습니다. 오늘 Chrome 개발자 인사이더라는 새로운 시리즈를 시작합니다. 이 시리즈에서는 (1) 유용한 정보와 뉴스 가치가 있는 기능, (2) Google이 핵심 주제에 관해 어떻게 결정을 내렸는지(예: FLOC 변경) 생태계와 협력하는 방식(예: Interop 2022) 및 (3) 상담사 변경사항과 관련해 알아야 할 중요한 사항을 공유합니다.
YouTube가 어떤 노력을 기울이고 있는지 알려 드리자면, 2022년에는 다음과 같은 4가지 우선순위에 따라 진행해 나갈 것입니다.
- 즐거운 사용자 환경 지원: 사용자가 직관적으로 이해할 수 있어야 합니다. 실적, 트랜잭션, ID 또는 전환 등 데이터를 추적할 수 있습니다
- 웹 기능 향상: 진화하는 웹의 역할을 콘텐츠 소비 플랫폼에서부터 심층적인 OS 및 하드웨어 수준의 통합이 필요한 경험을 포함한 광범위한 경험을 위한 플랫폼으로 지원합니다.
- 웹 개발 간소화: 의사 결정을 더 쉽게 내리고 개발자 생산성을 개선합니다.
- 웹의 개인 정보 보호 개선: 웹 사용자의 추적 및 타겟팅에 대한 개발자의 정교함이 계속 높아짐에 따라 데이터 개인 정보 보호 기능이 개선될 것이라는 기대를 갖게 되었습니다.
뉴스: Interop 2022
Google은 로드맵을 계획할 때 무엇보다도 웹 개발자의 가장 큰 고충과 요구사항을 파악하기 위해 개발자 의견을 살펴봅니다. 반복적으로 나타나는 핵심 테마는 브라우저 호환성으로, 환경이 브라우저 간에 동일하게 작동합니다. 지난 한 해 동안 Google은 '웹 개발 간소화'라는 우선순위의 일환으로 이 문제를 해결하기 위해 생태계와 협력해 왔습니다.
작년에 Microsoft, Chrome 및 생태계 업체들은 Compat 2021을 발표했으며, 그 결과 인기 브라우저 엔진 (Chromium, Gecko, Webkit)이 모두 한 해에 확인된 5개 중점 영역에서 90% 이상의 점수를 얻었습니다. 무엇보다도 Compat 2021은 CSS 그리드 (사용량 12%, 꾸준히 증가) 및 CSS Flexbox (사용량 77%) 등 강력한 기능을 위한 견고한 기반을 구축했습니다.
지난달, Apple, Bocoup, Google, Igalia, Microsoft, Mozilla가 후원자로서 웹 개발자들이 지적한 주요 브라우저 호환성 문제를 해결하고 공통 벤치마크에 합의했습니다. 그 결과로 Interop 2022는 플랫폼에 보다 동질성을 더하는 것을 목표로 하는 프로젝트입니다. 벤치마크에서는 개발자가 생산성 향상의 핵심으로 정한 15가지 우선순위 영역에 중점을 둡니다.
최신 소식: Google의 다른 브라우저와 협업하기
Interop 2022를 염두에 두고 저는 이러한 대화에 참여한 로버트 니만과 필립 제겐스테트를 만나 내부 스토리를 살펴봤습니다. 편집자 편집 영상은 여기까지입니다.
이 이니셔티브의 기원은 무엇인가요?
로버트: 이 모든 것은 2019년 MDN DNA 2019 설문조사를 진행했을 때 시작되었습니다. 호환성 문제는 웹용으로 빌드하는 개발자에게 주된 문제로 여겨졌으며, Google은 MDN 브라우저 호환성 보고서 2020에 훨씬 더 자세한 내용을 추가했습니다. 이를 통해 Compat 2021 노력을 시작하기에 충분한 정보와 실행 가능한 데이터를 얻었으며, 결과적으로 작업을 계속하고 Interop 2022로 범위를 넓혔습니다.
필립: web-platform-tests 및 State of CSS 2021도 언급하고 싶습니다. 지난 몇 년 간 WPT를 테스트하는 데 있어 다른 브라우저 공급업체와 긴밀한 협력을 진행해 왔으며, 이를 적극 활용하고자 했습니다. 이러한 기능에 대한 테스트는 대부분 이미 작성되었으므로 테스트를 검토하여 누락된 커버리지를 추가하기만 하면 됩니다. Google은 wpt.fyi에 많은 투자를 해왔지만, Mozilla는 또한 WPT가 오늘날과 같은 성공을 이룰 수 있도록 도와준 것에 대해 감사의 말씀을 전합니다. 물론 Mozilla는 MDN DNA 설문조사에도 큰 역할을 했습니다. 이 외에 CSS 2021 현황도 있습니다. Interop 2022와 같은 노력을 하기 위해서는 웹 개발자의 요구에 대한 새로운 의견이 필요하기 때문에 설문조사 관리자 사샤와 협력하여 브라우저 호환성 문제에 관한 몇 가지 새로운 질문을 포함했습니다. 이는 Interop 2022 계획 프로세스에 큰 도움이 되었습니다.
Compat 2021에서 배웠거나 의견이 있나요?
로버트: 각 브라우저 엔진의 성능을 측정하고 점수와 통계를 얻을 수 있었기 때문에 진행 상황을 파악하고 명확하지 않거나 우선순위를 지정해야 하는 문제를 논의하고 해결할 수 있었습니다. 또한 우리는 '상호 운용성'이 이 이니셔티브에 대해 더 적절한 이름이었습니다 호환성 및 상호 운용성이라는 용어는 일반적으로 브라우저 공급업체에서 구별합니다. 여기서 compat은 사이트 compat을 나타내고 interop은 동일하게 동작하는 두 개 이상의 브라우저를 나타냅니다. 이러한 측면에서는 상호 운용성을 위한 노력이 이루어지고 있으므로 프로젝트는 이러한 이름 지정 방식에 부합하게 되었습니다.
Google의 비전은 무엇인가요?
로버트: 웹을 열린 상태로 유지하려면 브라우저와 렌더링 엔진 다양성이 매우 중요합니다. 안타깝게도 이 기능은 현재 각 엔진의 기능에 대해 서로 다른 수준의 지원을 처리해야 하는 개발자들에게 매우 높은 가격을 요구하고 있습니다. Google의 비전은 개발자가 웹 플랫폼을 자신의 니즈에 맞는 가장 실행 가능한 옵션이자 가장 매력적인 선택으로 보고, 상호 운용성 문제를 해결하는 데 많은 시간을 소비하는 대신 가능한 한 최고의 환경을 구축하는 데 집중할 수 있도록 하는 것입니다. 그리고 이러한 목표를 달성하기 위해서는 가장 많이 사용되는 기능을 모든 주요 브라우저 엔진에 적용하여 개발자가 웹 플랫폼에서 성공할 수 있도록 해야 합니다.
(때로는) 서로 다른 목표를 가진 브라우저가 조화를 이룰 때 목표를 어떻게 추진해야 할까요?
필립: DORA의 접근 방식은 공통의 관심사를 추구하여 목표가 이미 대략적으로 일치하는 윈윈 협업을 찾는 것이었습니다. 동시에 작업할 수 있는 작업의 우선순위를 정하여 해당 영역에 집중함으로써 별도로 작업할 때보다 더 빠르게 진행하고 작업 품질을 높일 수 있습니다. 이상입니다.
이러한 합의 기반 접근 방식에는 한계가 있다는 점을 인식하는 것이 중요하다고 생각합니다. 즉, 목표가 충분히 일치하지 않아 다른 방식으로 나아가야 하기 때문입니다. 경우에 따라 웹 개발자 또는 사용자의 요구 사항에 대한 더 많은 증거를 제공하는 것이 도움이 될 수 있지만, 궁극적으로는 브라우저 공급업체가 광범위한 합의를 이루지 못한 제품도 제공할 수 있습니다. 최상의 경우, 이 기능의 가치는 웹 개발자가 해당 기능을 사용해 보고, 해당 기능이 자신의 니즈를 충족하는지 확인한 다음, 모든 브라우저에서 동일한 기능을 요청하는 것입니다.
Interop 2022에서는 디자인 외 또는 레이아웃 기능이 특정 시점에 파이프라인에 도입되는 것을 볼 수 있을까요?
필립: 물론입니다. Interop 2022는 스타일 지정 및 레이아웃 기능에 국한되지 않았으며, 결국 CSS에 크게 의존했습니다. 이는 State of CSS 2021이 최신 상태이기 때문이기도 하지만 웹 개발자들이 브라우저 간 차이점으로 가장 큰 문제가 발생하는 지점이기도 하기 때문입니다. 양식 및 대화상자 요소와 같은 여러 포커스 영역은 CSS를 넘어서는 기능이며, API 및 포인터 및 마우스 이벤트 수정과 관련된 조사 작업도 있습니다. Interop 2023을 위해 웹 전반의 개발자 요구사항에 대한 최신 데이터를 얻고 이러한 기능을 더 많이 포함할 수 있기를 바랍니다.
예정된 주요 변경사항
이 시리즈의 의도 중 하나는 예정된 주요 변경사항을 개발자에게 미리 알려주는 것입니다. 사용자 환경과 플랫폼의 기능을 개선하는 데 중요한 요소입니다.
아래에 언급된 일정은 이러한 변경사항이 적용될 것으로 예상되는 시기입니다. 하지만 기능의 출시 버전이 변경될 수도 있습니다.
사용자 에이전트 축소
User-Agent 헤더 및 연결된 JS 인터페이스는 유용한 브라우저 및 기기 정보를 전송할 뿐만 아니라 계보와 부정확한 정보를 전달합니다. UA 문자열 파싱 버그를 끊임없이 공급할 때보다 모든 탐색 및 하위 리소스 요청에 대해 서버에 소극적으로 전송된다는 점이 더 큰 문제입니다. 이는 사용자가 웹을 탐색할 때 서버에서 안정적인 추적 식별자를 구축하는 데 사용할 수 있는 약 10비트의 엔트로피를 나타냅니다.
현재 계획은 낮은 엔트로피 브라우저 메이저 버전, 플랫폼 이름, 모바일성을 계속 출시하여 높은 엔트로피 정보를 고정하여 기존 UA 문자열을 줄이는 것입니다. 헤더에 포함된 것 이외의 추가 정보가 필요한 사용 사례를 위해 Google은 Chrome 89부터 User-Agent Client Hints API를 제공하고 있습니다.
실험과 의견을 위해 6개월 동안 오리진 트라이얼을 실행했으며, 200명 이상의 참가자가 있음에도 서비스 중단과 관련된 피드백을 받지 못해 만족했습니다.
- 타임라인: Chrome 101에서는 4단계를 진행하여 UA 문자열의
MINOR.BUILD.PATCH정보를0.0.0로 줄입니다. 또한 Google은 5단계 및 그 이후 단계에 대비할 수 있도록 지속적으로 사이트에 알림과 시간을 제공할 것입니다. 또한 Google에서는 이러한 변경사항을 선택 해제할 수 있도록 엔터프라이즈 정책을 만들었으며, 이러한 변경사항에 대비할 수 있도록 사이트에 충분한 시간을 제공하기 위해 Chrome 113까지 지원 중단 기능 트라이얼을 실행할 예정입니다. - 클릭 유도 문구: 사이트를 UA 클라이언트 힌트로 이전하거나 지원 중단 기능 트라이얼에 참여하세요.
로컬 글꼴 액세스 API
Chrome에서 Local Font Access API를 출시합니다. 사이트에서 오래전부터 로컬 글꼴을 사용할 수 있었지만 이 API는 로컬 글꼴 목록을 열거하고 글꼴 데이터 자체에 대한 액세스 권한을 제공합니다. 이 기능을 통해 사용자는 웹 기반 디자인 및 기타 애플리케이션에서 모든 글꼴을 사용할 수 있습니다.
로컬 글꼴은 오랫동안 지문 벡터로 알려져 왔습니다. 이 새로운 API를 사용해도 디지털 지문 수집에 글꼴을 사용하는 기능이 늘어나지는 않지만, Chrome에서 새로운 Local Font Access API를 사용하려면 사용자가 사이트에 새 "local-fonts" 권한을 부여해야 합니다.
향후 동일한 'local-fonts' 로컬 글꼴에 대한 액세스를 제공하는 다른 API를 사용하기 전에 권한을 부여해야 합니다.
BFCache를 Cache-control: no-store와 함께 사용하도록 설정
Google에서는 뒤로/앞으로 캐시가 즉각적인 뒤로-앞으로 탐색을 제공하는 빈도를 개선할 중요한 기회를 발견했습니다. 이렇게 하려면 Cache-control: no-store HTTP 헤더로 제공되는 페이지에서 BFCache가 작동하는 방식을 변경해야 합니다. Google은 다양한 신호 (예: HTTP 전용 쿠키가 변경될 때마다 BFCache에서 페이지 제거)를 모니터링하고 고유한 컨텍스트에 대한 삭제 (예: Enterprise/Edu 고객에 대한 그룹 정책)를 모니터링하여 중대한 예상치 못한 상황을 방지하기 위해 공개 제안서를 제공하고 있습니다. 이번 기회는 복잡하지만 흥미로운 기회입니다. 추가 조사와 의견을 보내주시면 감사하겠습니다.
- 타임라인: 큰 사건이 아니라고 가정하여 Chrome 104 (2022년 7월)를 타겟팅합니다.
- 클릭 유도 문구: 진행 중인 작업을 구현하는 방법, Google의 접근 방식이 새로운 장애물을 만드는 실제 시나리오와 같은 의견을 공유하는 방법 등 자세한 내용은 제안을 참고하세요.
이 시리즈를 통해 개발자 커뮤니티가 저희 팀과 업무에 더 가까이 다가갈 수 있게 함으로써 집중력과 유대감을 형성할 수 있기를 바랍니다. 계속 관심을 갖고 지켜봐 주세요.
감사합니다.
Chrome Dev Insider 첫 번째 호에 대해 어떻게 생각하시나요? 의견을 공유해 주세요.