웹상의 변화를 따라가기 어렵고 이러한 변화가 왜 발생하는지 이해하는 것이 어렵다고 말하는 개발자들이 많습니다. 오늘은 Chrome Dev Insider라는 새로운 시리즈를 시작합니다. (1) 멋지고 중요한 소식, (2) 주요 주제 (예: FLOC 변경)에 대한 Google의 결정 방식 또는 생태계와 관련된 작업에 대한 접근 방식 (예: Interop 2022), (3) 상담사가 알아야 할 상담사 문자열의 정말 중요한 사항 (예: 상담사)을 공유합니다.
Google이 어떤 노력을 기울이고 있는지 공유하며 이는 2022년의 4가지 우선순위인
- 즐거운 사용자 경험 지원: 성능, 트랜잭션, ID, 전환 등 사용자에게 직관적으로 알 수 있는 환경을 제공하세요.
- 웹의 기능 향상: 웹은 콘텐츠 소비 플랫폼부터 다양한 환경을 위한 플랫폼(심층적인 OS 및 하드웨어 수준의 통합이 필요한 환경 포함)까지 진화하는 웹 역할을 지원합니다.
- 웹 개발 간소화: 의사 결정을 더 쉽게 내리고 개발자 생산성을 높일 수 있습니다.
- 웹의 개인 정보 보호 개선: 추적 및 타겟팅에서 개발자의 전문성이 날로 높아지고 있는 가운데, 데이터 개인 정보 보호 기능이 개선되고자 하는 웹 사용자의 기대에 부응합니다.
최신 소식: Interop 2022
Google에서는 로드맵을 계획할 때 무엇보다도 웹 개발자의 가장 큰 고충과 요구사항을 파악하기 위해 개발자 의견을 살펴봅니다. 반복적으로 나타나는 핵심 테마는 브라우저 호환성으로, 여러 브라우저에서 동일한 환경이 작동합니다. 지난 1년간 Google Cloud 생태계와 협력하여 '웹 개발 간소화'라는 최우선 과제의 일환으로 이 주제를 다루었습니다.
지난해 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가지 우선순위 영역에 중점을 둡니다.
최신 소식: 동료 브라우저와 협업하기
Interop 2022를 최우선으로 생각하면서 이러한 대화에 참여한 로버트 니만, 필립 예겐슈테트와 함께 비하인드 스토리를 들어보았습니다. 이 과정을 다룬 편집자 요약은 다음과 같습니다.
이 이니셔티브의 기원은 무엇인가요?
로버트: 이 모든 것은 MDN DNA 2019 설문조사를 진행한 2019년에 시작되었습니다. 호환성 문제는 웹용으로 빌드하는 개발자에게 있어 주요 문제로 명확하게 나타났으며, 2020년 MDN 브라우저 호환성 보고서에서 훨씬 더 자세한 내용을 다루었습니다. 이를 통해 Compat 2021의 노력을 시작하기에 충분한 정보와 실행 가능한 데이터를 확보했으며, 그 결과 Interop 2022를 통해 관련 작업을 계속하고 범위를 확장할 수 있었습니다.
필립: web-platform-tests와 2021년 CSS 현황도 언급하고 싶습니다. 우리는 몇 년 전부터 WPT 사용을 테스트하는 것과 관련하여 다른 브라우저 공급업체와 긴밀하게 협력해 왔으며 이 부분을 적극 활용하고자 했습니다. 이러한 기능의 테스트는 대부분 이미 작성되었으므로, 테스트를 검토하고 누락된 적용 범위를 추가하기만 하면 되었습니다. Google은 wpt.fyi에 많은 투자를 하고 있지만, Mozilla 역시 WPT의 성공에 감사의 마음을 전합니다. Mozilla는 물론 MDN DNA 설문조사에서도 큰 역할을 했습니다. 이 외에도 CSS 2021 현황도 확인할 수 있습니다. Interop 2022와 같은 노력을 기울일 수 있도록 웹 개발자의 요구사항에 대한 새로운 의견이 필요합니다. 따라서 Google은 설문조사 운영자인 Sacha와 협력하여 브라우저 호환성 문제에 관한 몇 가지 새로운 질문을 포함시켰습니다. 이는 Interop 2022 계획 프로세스에 큰 도움이 되었습니다.
Compat 2021에서 얻은 교훈이나 의견이 있나요?
로버트: 각 브라우저 엔진의 작동 상태를 측정하고 점수와 통계를 얻을 수 있어서 정말 유용했습니다. 덕분에 진행 상황을 파악하고 명확하지 않거나 우선순위를 지정해야 하는 문제를 논의하고 해결할 수 있었습니다. 또한 "상호 운용성"이 이 이니셔티브에 더 적합한 이름이라는 것을 빠르게 깨달았습니다. 호환성 및 상호 운용성이라는 용어는 일반적으로 브라우저 공급업체에 따라 구분되며, 여기서 compat은 사이트 호환성을 나타내고 상호 운용성은 동일하게 동작하는 두 개 이상의 브라우저를 의미합니다. 이 용어들에서 이러한 노력은 상호 운용성을 위한 것이며, 이 프로젝트는 상호 운용성과 부합합니다.
Google의 비전은 무엇인가요?
로버트: 웹을 열린 상태로 유지하려면 브라우저와 렌더링 엔진의 다양성이 매우 중요합니다. 안타깝게도 현재 이 기능은 각 엔진의 기능에 대한 다양한 수준의 지원을 따라잡아야 하는 개발자들에게 높은 가격으로 제공되고 있습니다. Google의 비전은 개발자들이 웹 플랫폼을 자신의 필요에 맞는 가장 실행 가능한 옵션과 가장 매력적인 선택으로 여기고, 상호 운용성 문제를 해결하는 데 많은 시간을 들이지 않고도 가능한 한 최고의 환경을 빌드하는 데 집중할 수 있도록 하는 것입니다. 그리고 이러한 목표를 달성하려면 가장 많이 요청되는 기능이 모든 주요 브라우저 엔진에 전달되어야 개발자가 웹 플랫폼에서 성공할 수 있습니다.
때로는 서로 다른 목표를 가진 브라우저가 모일 때 함께 일을 진전시키려면 어떻게 해야 할까요?
필립: Google의 접근 방식은 공통의 관심 영역을 찾고 목표가 이미 대략적으로 도달한 윈윈 협업을 찾는 것이었습니다. 또한 동시에 작업할 제한된 수의 작업에 우선순위를 부여하여 해당 영역에 집중하고 개별 작업을 수행할 때보다 더 빠르게 작업을 진행하고 더 높은 품질을 얻을 수 있습니다. 이것이 바로 그 아이디어입니다.
이 합의에 기반한 접근 방식에는 한계가 있다는 사실을 인식하는 것이 중요하다고 생각합니다. 따라서 다른 방식으로 추진해야 할 때 목표가 충분히 일치되지 않기 때문입니다. 웹 개발자나 사용자 요구사항에 대한 증거를 더 많이 제시하면 도움이 되기도 하지만, 결국 브라우저 공급업체에서 광범위한 합의를 이루지 못한 제품을 제공할 수도 있습니다. 최상의 사례에서는 웹 개발자가 기능을 사용해 보고, 이 기능이 요구를 충족한다는 사실을 확인하고, 모든 브라우저에서 동일한 기능을 요청하는 방식으로 기능의 가치를 입증할 수 있습니다.
하지만 Interop 2022에서는 디자인이 아닌 기능 또는 레이아웃 기능이 언젠가 파이프라인에 도입될 예정인가요?
필립: 맞아요. Interop 2022는 스타일 지정과 레이아웃 기능에 국한되지 않고 CSS에 크게 의존하게 되었습니다. 이는 CSS 2021이 최신 상태가 되었기 때문이기도 하지만 웹 개발자들이 브라우저 간 차이로 인해 가장 큰 어려움을 겪고 있다고 밝혔기 때문입니다. 양식 및 대화상자 요소와 같은 여러 포커스 영역은 CSS를 넘어서며, Google에서는 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" 권한을 부여해야 합니다.
향후 로컬 글꼴에 대한 액세스를 제공하는 다른 API를 사용하기 전에 동일한 "로컬 글꼴" 권한을 부여하도록 요구할 계획입니다.
Cache-control: no-store를 사용하여 BFCache를 작동하도록 만들기
뒤로/앞으로 캐시에서 즉각적인 뒤로/앞으로 탐색을 제공하는 빈도를 개선할 수 있는 중요한 부분이 확인되었습니다. 이를 위해서는 Cache-control: no-store HTTP 헤더로 게재되는 페이지에서 BFCache가 동작하는 방식을 변경해야 합니다. Google에서는 다양한 신호 (예: HTTP 전용 쿠키가 변경될 때마다 BFCache에서 페이지 제거)를 모니터링하여 예상치 못한 상황을 방지하고 고유한 컨텍스트에 대한 조각 (예: Enterprise/Edu 고객의 경우 그룹 정책)을 정리하는 공개 제안서를 마련해 두었습니다. 이는 복잡하지만 흥미로운 기회입니다. 더 자세한 검토와 의견을 보내주시기 바랍니다.
- 타임라인: Chrome 104 (2022년 7월)를 타겟팅하며 큰 차이가 없다고 가정합니다.
- 클릭 유도 문구: 진행 중인 작업을 구현하는 방법, Google의 접근 방식으로 인해 새로운 장애물이 만들어지는 실제 시나리오와 같은 의견을 공유하는 방법 등 자세한 내용은 제안서를 참조하세요.
이 시리즈를 통해 개발자 커뮤니티가 저희 팀과 업무에 더 가까워질 수 있도록 함으로써 개발자 커뮤니티가 집중력과 유대감을 형성할 수 있게 되기를 바랍니다. 계속해서 지켜봐 주세요. 이곳에서 더 많은 업데이트를 확인하세요.
감사합니다.
Chrome Dev Insider 첫 번째 버전에 관해 어떻게 생각하시나요? 의견을 공유해 주세요.