커뮤니티와 Chrome의 새로운 소식을 전해드리는 Chrome Dev Insider 2번째 버전에 오신 것을 환영합니다. Google의 업무 접근 방식에 관한 내부자 이야기와 주목해야 할 가장 중요한 업데이트를 간략하게 살펴볼 수 있는 새로운 에피소드입니다.
저는 Chrome 개발자 관계팀의 콘텐츠 리드인 레이첼 앤드류입니다. web.dev와 developer.chrome.com을 담당하고 있습니다. 20년 넘게 웹에서 일해 왔으며, 개방형 웹 표준과 CSS에 중점을 두고 있습니다. CSS 워킹 그룹의 일원이기도 합니다.
두 달 전, Google은 Google I/O에서 사용자의 정보를 안전하고 비공개로 유지하면서 개발자가 웹을 더 빠르고 강력하게 만들 수 있도록 지원하는 방법에 관한 가장 중요한 업데이트를 공유했습니다.
눈에 띄는 점 중 하나는 웹에서 더 많은 CSS 및 UI 기능을 지원하기 위해 팀이 수행하는 엄청난 양의 작업입니다 (커뮤니티에서 이를 알아주어 기쁩니다). 이번 Chrome Dev Insider에서는 이 작업을 담당하는 사람, CSS 및 UI 개발자를 지원하기 위해 노력하는 방식, 앞으로의 계획을 자세히 살펴봅니다. 그래서 이번 Insider를 진행하게 되어 기쁩니다.
뉴스 속 장소
첫 번째 Chrome Dev Insider에서는 브라우저 공급업체와 생태계 참여자가 모든 브라우저에서 지원되는 더 많은 기능을 웹에 제공하기 위해 파트너십을 맺은 Compat 2021 및 Interop 2022 이니셔티브에 관한 업데이트를 공유했습니다. 이 이니셔티브는 CSS에 중점을 두고 있습니다. 브라우저 비호환성이 CSS 개발자에게 가장 큰 문제 중 하나이기 때문입니다.
대부분의 사용자에게는 새로운 소식이 아닐 수 있지만, 브라우저 전반에서 이미 상당한 진전이 있었다는 점은 고무적입니다.
지난달 초 Safari는 컨테이너 쿼리, 하위 그리드, 플렉스박스 인스펙터와 같은 흥미로운 기능이 포함된 Safari 16.0 베타를 통해 대규모 출시를 발표했습니다. 최근 Firefox와 Chrome 출시에는 다양한 흥미로운 기능과 수정사항이 포함되어 있습니다. 매달 새로운 웹 플랫폼 시리즈 게시물에서 안정화 버전 및 베타 브라우저의 주요 사항을 다루고 있습니다.
내부 소식: CSS 및 UI 개발자 지원
2022년은 CSS 기능에 있어 흥미로운 한 해였으므로, 이번 기회에 그 뒷이야기를 들려드리고자 합니다. 웹 UI 및 Devtools의 DevRel 리드인 Una Kravets와 CSS 및 HTML API에 중점을 두는 웹 UI 제품 관리자인 Nicole Sullivan과 함께 UI 개발자를 지원하기 위한 Chrome의 여정에 관해 이야기를 나눴습니다.
두 분부터 시작해 보겠습니다. 본인에 관해 좀 더 자세히 알려주세요.
니콜: Chrome의 웹 UI 제품 관리자입니다. 새로운 CSS 및 HTML API와 UI를 빌드하는 개발자 및 디자이너에 중점을 둡니다. 컨테이너 쿼리, 범위, 세로 리듬과 같은 매우 중요한 API가 출시되는 흥미로운 공간입니다.
Una: 웹 UI 및 DevTools DevRel 팀을 이끌고 있습니다. Google은 웹 플랫폼의 UI 엔지니어를 지원하는 데 중점을 두고 있으며, UI 엔지니어가 성공하는 데 필요한 도구를 제공합니다. 여기에는 활성 변경사항과 의견을 확인할 수 있는 DevTools 기능과 함께 CSS API 및 HTML 구성요소가 포함됩니다.
Chrome의 UI 개발자 지원은 지난 몇 년간 속도를 높여 왔습니다. 여기까지 오는 데 왜 이렇게 오래 걸렸다고 생각하시나요? 가장 큰 어려움은 무엇이었나요?
Una: 이 작업이 얼마나 중요한지, 왜 우선순위가 되어야 하는지 보여주기 위해 몇 가지 작업을 해야 했습니다. 2019년 MDN DNA 설문조사에서 UI가 플랫폼의 주요 문제점으로 파악되었습니다. 그 이후로 Google은 MDN과 자체 내부 개발자 만족도 설문조사를 통해 데이터를 계속해서 활용해 왔습니다. 그 결과, 리더십의 지지를 더 많이 얻을 수 있었고 호환성 2021 및 상호 운용성 2022와 같은 이니셔티브의 주요 초점이기도 한 UI 공간에서 가장 많이 요청된 개발자 기능을 중심으로 엔지니어링 작업을 우선순위로 지정할 수 있었습니다.
니콜: 리더십의 동의를 얻는 것 외에도 이러한 API를 개발자에게 제공하는 올바른 방법을 찾아야 했습니다. Chrome에 처음 입사했을 때 계층화된 API (줄여서 LAPIs)라는 프로젝트에서 이 부분을 잘못 처리했습니다. LAPI는 개발자에게 드롭인 구성요소 환경을 제공하는 것을 목표로 했습니다. 여전히 좋은 결과라고 생각하지만 실수가 많았습니다. 가장 먼저 토스트 알림과 가상 목록에 초점을 맞췄습니다. 토스트는 접근성을 확보하기가 거의 불가능하며 가상 목록은 올바르게 구현하기 가장 어려운 구성요소 중 하나입니다. 의도는 좋았지만 개발자에게 도움이 되지 않아 프로젝트를 종료했습니다. 어려운 방법으로 배우는 것은 어렵지만 모든 실수가 지금 일어나고 있는 CSS와 HTML의 부흥을 촉진하고 있습니다.
LAPI에 대해 좀 더 자세히 알아보겠습니다. 무슨 일이 있었나요?
니콜: LAPI의 경우 웹에 기본 UI를 빌드하는 데 더 가까운 드롭인 구성요소 개발자 환경이 필요하다는 것을 알고 있었습니다. 그리고 바퀴를 재발명하는 것이 개발자를 방해한다는 것이 분명했습니다. 지금까지 만든 탭의 수를 셀 수 없을 정도입니다. 하지만 브라우저와 함께 JavaScript를 제공하여 이 문제를 해결하려고 했지만 매우 어려웠습니다. 이전에는 브라우저에 JavaScript를 제공한 적이 없었으며 브라우저의 렌더링 엔진을 지원하는 C++ 코드와 어떻게 상호작용해야 하는지 명확하지 않았습니다. Google은 다른 브라우저 공급업체 (Mozilla에 감사드립니다)의 의견을 수렴하여 해당 접근 방식을 철회했으며, 그 결과 Open UI를 통해 훨씬 더 나은 방법을 찾을 수 있었습니다. HTML과 CSS를 활용하면 유연한 선언적 솔루션을 얻을 수 있습니다. 선언적이기 때문에 JavaScript로는 쉽지 않았을 방식으로 접근성을 내장할 수 있습니다. 앞으로 어떻게 될지 정말 기대됩니다. 정말 필수적인 UI 디자인 패턴인 selectmenu, popup, tooltip, nav, accordion, tabs, carousel, toggle을 지원하기 위해 노력하고 있습니다.
그래서 많은 것을 배웠습니다. CSS Houdini와 같은 다른 이니셔티브도 있었던 것으로 알고 있습니다. 무슨 이야기인가요?
Una: 네, CSS Houdini도 커뮤니티에서 배운 또 다른 사례입니다. 유용한 Houdini 기능이 많이 있지만, 많은 기능이 너무 하위 수준이라 널리 채택되고 지원받지 못했습니다. 로우레벨 API를 구현한다고 해서 개발자의 불편이 반드시 줄어드는 것은 아니라는 것을 깨달았습니다. 대신 높은 수준의 솔루션과 요구사항에 집중하면 교차 브라우저 지원과 생태계에서 변화를 일으키는 데 필요한 착륙을 확보할 수 있습니다. 현재 https://ishoudinireadyyet.com에서 진행 상황을 추적하고 있습니다.
크로스 브라우저 지원에 관해 말하자면 Interop 2022 및 Open UI와 같은 이니셔티브가 커뮤니티에 상당한 긍정적인 결과를 제공하는 것으로 보입니다. 개발자로부터 어떤 의견을 듣고 있나요?
우나: 개발자가 가장 많이 겪는 고충 중 하나는 '브라우저 간에 디자인이 동일하게 작동하도록 하는 것'입니다. Google에서는 다른 브라우저 공급업체와 협력하여 가장 많이 요청된 개발자 기능의 우선순위를 정하고 이를 구현하여 이 문제를 해결했습니다. 커뮤니티에서 받은 의견도 압도적으로 긍정적이었습니다. 또한 RenderingNG라는 대규모 리아키텍처 작업을 통해 이러한 기능을 훨씬 더 성능이 우수하게 구현할 수 있게 되었습니다. 개발자들은 수년 동안 요청해 온 오랫동안 기다려 온 기능이 드디어 작업되고 크로스 브라우저로 제공된다는 점에 흥분하고 있습니다.
니콜: 커뮤니티의 흥분이 느껴집니다. Twitter에서 확인할 수 있습니다. :)
생태계와의 협력은 개발자의 삶을 더 쉽게 만드는 데 있어 매우 중요합니다. 귀사에서 많은 노력을 기울인 것으로 알고 있습니다. 자세한 내용을 공유해 주시겠어요?
니콜: 우선 개발자가 웹에서 빌드하는 프로젝트에 항상 감탄합니다. 가장 작은 라이브러리부터 완전한 프레임워크까지 개발자들은 놀라운 것들을 만들고 있습니다. 제작자 커뮤니티가 정말 멋집니다. Chrome은 이러한 프로젝트와 더 긴밀하게 연결하기 위해 다양한 조치를 취하고 있습니다.
예를 들어 몇 년 전부터 React, Angular와 같은 JavaScript 프레임워크를 사용하기 시작했습니다. 메타 프레임워크(예: Next, Nuxt, Gatsby) 작년부터는 Sass, Bootstrap, Material과 같은 UI 도구 및 프레임워크에도 동일한 작업을 적용하기 시작했습니다. 내년에는 GreenSock 및 개발자의 삶을 더 쉽게 만들어 주는 다른 도구와 협업할 수 있기를 바랍니다. Smashing Conference에서 GreenSock의 Cassie Evans가 발표하는 것을 봤는데, 애니메이션 분야의 사람들과 함께 일하는 것에 정말 큰 흥미를 느꼈습니다.
그렇다면 웹 UI 생태계에서 가장 큰 기회는 어디에 있을까요?
Una: 큰 기회 측면에서 맞춤설정 가능한 웹 환경의 가능성은 아직 극히 일부에 불과하다고 생각합니다. 컨테이너 쿼리 및 CSS 사용자 환경설정 미디어 기능과 같은 새로운 API는 개발자가 반응형 디자인을 보는 방식을 재정의하고 있습니다. 또한 개발자와 디자이너가 웹사이트를 방문하는 사용자와 함께 작업할 수 있도록 지원하는 공동 디자인 환경도 기대됩니다.
니콜, 팀의 다음 로드맵은 무엇인가요?
니콜: 모든 탐색이 출시 가능한 제품으로 이어지는 것은 아니지만 현재 정말 기대되는 부분이 많습니다.
Una가 첫 번째 사항을 언급했듯이 반응형 구성요소 기반 디자인을 지원합니다. 디자이너가 어두운 모드와 같은 사용자 환경설정에 대응할 수 있도록 색상 시스템을 설계하는 도구가 포함되어 있습니다. 예를 들어 OKLCH 색상 공간은 색조 전반에서 밝기를 일관되게 유지합니다. 디자이너는 색상을 선택하는 것에서 색상 간의 관계를 디자인하는 것으로 이동할 수 있으며, 흐릿한 팔레트가 나오지 않습니다.
또한 컨테이너 쿼리, 캐스케이드 레이어, 상위 선택기 (:has), 범위가 지정된 스타일, 중첩과 같이 가장 많이 요청된 API도 개발 중입니다. 개발자는 재사용 가능한 구성요소로 가득한 유연한 디자인 시스템을 빌드할 수 있어야 합니다.
연결된 애니메이션 스크롤도 재미있는 영역입니다. 스티브 가드너의 데모가 정말 마음에 듭니다. 부드러운 스크롤과 스크롤 시 트리거되는 멋진 비행기 애니메이션이 있습니다. 이러한 기능은 재미있지만, 특히 접근성을 고려할 때는 올바르게 구현하기가 까다로울 수 있습니다. 따라서 현재 기능의 접근성에 대한 사용자 테스트를 진행하고 있습니다.
개인적으로 가장 기대되는 기능은 내장 웹 UI 컨트롤입니다. 개발자가 동일한 탭 세트를 계속해서 빌드하고 있으므로 브라우저가 도움이 될 수 있다고 생각합니다. Open UI에서는 selectmenu, popup, tooltip, tabs, nav, accordion, toggle과 같은 구성요소를 작업하고 있습니다. Google은 웹이 시간이 지남에 따라 기본적으로 접근 가능해지도록 이러한 브라우저 기본 요소에 접근성을 통합하는 방법을 모색하고 있습니다. 그러면 개발자는 더 복잡하고 미묘한 문제에 집중할 수 있고 탭이 탭되는 방식과 같은 기본 사항은 브라우저에서 지원할 수 있습니다. 이 내용은 별도의 게시물이 필요할 것 같으니 일단 여기까지만 설명하겠습니다.
마지막으로 브라우저 간 상호 운용성에 계속 투자할 것입니다. WebKit 및 Gecko의 여러 사용자와 협력하여 개발자 환경의 일관성을 유지할 수 있어 좋았습니다. 개발자들은 이 기능을 원한다고 명확하게 의견을 보내왔습니다.
아직 확인하지 않았다면 원활한 웹팀의 공유 요소 전환 API가 웹 디자인 방식을 바꿀 것입니다. 디자이너가 물리적 공간에서 디자인을 방향을 지정할 수 있는 미묘한 전환이 가능할 뿐만 아니라 쉬워질 것입니다. 제이크 아치볼드에게 훌륭한 데모가 있습니다.
표준이 잘 진행된다면 올해 세로 리듬을 살펴볼 수도 있습니다. LayoutNG를 기반으로 빌드할 수 있어 다양한 기능을 사용할 수 있습니다.
두 분 모두 감사합니다. 저희와 마찬가지로 커뮤니티 전체가 웹 UI에 적용되는 개선사항과 기능의 속도가 빨라진 데 대해 기뻐하고 있을 것이라고 생각합니다. 아직 이해해야 할 부분이 많으므로 어디서부터 여정을 시작해야 할까요?
Una: I/O의 웹 플랫폼의 새로운 기능 세션에서는 올해 출시되는 여러 기능의 주요 내용을 다룹니다. Adam Argyle도 새롭고 곧 출시될 CSS 기능에 관한 훌륭한 도움말을 작성했습니다. 지금은 안정적인 버전에 집중하고 파이프라인에 있는 다른 작업에 대해서는 인지하고 있는 것이 좋습니다. 웹 플랫폼 신규 사용자 시리즈를 참고하면 됩니다. web.dev 뉴스레터를 구독하면 개발자의 받은편지함으로도 이 콘텐츠가 전송됩니다. 이 모든 작업에 참여하고 지원하려는 개발자에게는 Open UI에 참여하는 것이 이 작업을 지원하는 가장 좋은 방법 중 하나입니다.
주요 예정 업데이트
웹 환경을 구축할 때 유의해야 할 예정된 변경사항을 미리 알려드리는 전통을 이어가고 있습니다.
쿠키의 max-age를 400일로 제한
- 업데이트: 명시적
Expires/Max-Age속성으로 쿠키가 설정되면 이제 값이 미래의 400일 이하로 제한됩니다. 이전에는 제한이 없었으며 쿠키가 수천 년 후에 만료될 수 있었습니다. 이 한도의 목표는 일반적인 사용 패턴과 사용자 개인 정보 보호 간의 균형을 맞추는 것입니다. 400일보다 자주 방문하는 사이트는 서비스 연속성을 보장하기 위해 쿠키를 새로고침할 수 있으며, 사용자는 쿠키가 수천 년 동안 사용되지 않고 브라우저에 남아 있지 않다는 것을 안심할 수 있습니다. - 예상 일정: Chrome 104 (2022년 8월 2일 안정화 버전)에서 제공됩니다.
- 개발자 CTA: 사용자가 웹사이트를 방문할 때 개발자가 이전보다 더 자주 쿠키를 적극적으로 새로고침해야 할 수 있습니다. 그렇지 않으면 쿠키가 처음 설정된 후 400일이 지나면 사용자가 로그아웃될 수 있습니다.
이번 Chrome Dev Insider가 도움이 되었기를 바랍니다. 놓치셨다면 첫 번째를 확인하세요. 다음 분기에 더 많은 소식을 전해드릴 수 있도록 노력하겠습니다.
그때까지 이번 Chrome Dev Insider에 대한 의견과 개선할 점을 알려주세요.
이번 Chrome Dev Insider에 관해 어떻게 생각하시나요? 의견 공유하기