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