Chrome Dev Insider: 프레임워크 생태계를 통한 성능 확장

Paul Kinlan

저는 폴 킨란이며 Chrome 개발자 홍보팀을 이끌고 있습니다. 저는 열정적인 웹 지지자로 구성된 팀과 협력하게 되며, 이들은 개발자 만족도 향상을 위한 북극성 측정항목을 통해 실제 개발자의 관점을 제품 및 엔지니어링팀에 전달하는 업무를 담당하고 있습니다.

'만족도'는 추적하고 개선하기 위한 야심차고 주관적인 측정항목이므로, Google은 개발자의 요구사항에 집중하면서 변화를 가져올 방법을 끊임없이 반복하고 있습니다. Google이 파악한 기본 원칙은 '개발자의 현재 수준에 맞추세요'입니다. 최근 Stack Overflow 연구에 따르면 개발자의 75% 가 프레임워크 또는 일종의 추상화를 사용한다고 합니다. 그래서 우리는 이미 기술 스택에 대한 결정을 내렸거나 통제할 수 없는 개발자에게 어떻게 최선의 서비스를 제공할 수 있을지 자문해 왔습니다. 어떻게 하면 오버헤드를 추가하지 않고 생산성을 높일 수 있을까요?

Chrome의 소규모 팀은 프레임워크 및 라이브러리와 같은 웹 플랫폼의 서드 파티 추상화를 사용하는 것을 목표로 Aurora라는 프로젝트를 진행하고 있습니다. 이들의 목표는 웹 개발자인 고객에게 부담을 주지 않고 이러한 추상화를 통해 성능 향상을 직접 이루도록 돕는 것입니다.

Chrome Dev Insider 3호에서는 Project Aurora팀의 애디 오스마니, 카라 에릭슨, 후세인 드지르데와 대화를 나누며 이 프로젝트에 접근해 온 과정과 앞으로 펼쳐질 일에 대해 자세히 알아보았습니다.

소식통: 서드 파티 프레임워크로 작업하기

이 프로젝트의 기원부터 시작하겠습니다. 어떻게 된 건가요?

애디: Aurora는 간단한 아이디어에서 시작했습니다. 즉, 개발자들이 현재 있는 곳에 찾아가서 필요한 곳으로 갈 수 있도록 하는 것입니다. 예를 들어 성능 개선을 위해 개발자가 선택한 인기 기술 스택을 지원하자. 오늘날 많은 앱 개발자가 React, Vue 또는 Angular나 Next.js 및 Nuxt와 같은 메타 프레임워크* 를 사용하여 빌드하고 있습니다. 스벨트, 리트, 프랙트, 아스트로 목록은 계속됩니다!) 이러한 개발자가 성능 면에서 심층적인 전문가가 될 것이라고 기대하는 대신 이러한 스택에 기본적으로 더 많은 권장사항을 추가하여 성공의 허점이 되게 할 수 있습니다. 이렇게 하면 사이트의 품질이 더 우수하다는 것은 단순히 웹만을 위한 사이트를 빌드하는 부작용이 될 수 있습니다.

Aurora는 널리 사용되는 몇 가지 프레임워크와 메타 프레임워크를 파트너로 선택하고 학습한 내용 (예: 좋은 이미지 구성요소를 빌드하는 방법)을 문서화하여 다른 사용자가 Chrome 프레임워크 펀드를 통해 다른 프레임워크와 도구를 통해 빠르게 팔로우하고 다른 프레임워크와 도구를 통해 확장할 수 있도록 합니다. 브라우저를 통해 웹 환경의 품질을 개선할 수 있지만, Google은 이 목표를 (경우에 따라) 프레임워크를 통해서도 달성할 수 있다고 믿습니다. 이번 업데이트가 모두를 위한 더 높은 품질의 웹이라는 Google의 목표를 달성하는 데 도움이 되기를 바랍니다.

카라: 좀 더 나아가 개발자 환경을 개선하여 웹 성능을 개선하려고 합니다. 실적 권장사항은 자주 바뀌고 기업이 이를 따라가기 어렵기 때문에 실적 권장사항을 홍보하는 것만으로는 충분하지 않습니다. 실적 이전에 있을 가능성이 높은 자체 비즈니스 우선순위가 있습니다.

따라서 개발자가 성능에 전념할 시간이 제한되어 있다면 더 쉽고 빠르게 성능 기준에 맞는 앱을 빌드할 수 있도록 해야 합니다. Google이 인기 있는 웹 프레임워크와 파트너 관계를 맺으면 더 높은 수준의 구성요소, 적합성 경고 등을 통해 개발자 환경을 개선할 수 있는 적합한 추상화 계층에 있습니다. 이러한 인기 도구를 사용하는 사람은 누구나 이러한 이점을 누릴 수 있습니다. 이론적으로 권장되는 조언이 변경되면 내부에서 구성 요소를 업데이트할 수 있으므로 개발자는 최신 상태를 유지하는 것에 대해 걱정할 필요가 없습니다.

후세인: 저는 몇 년 후 소프트웨어 엔지니어링 직무로 전환하기 전에 Developer Advocate로 Google에 합류했습니다. 이전 작업 중에는 웹 개발자에게 훌륭한 사용자 환경을 빌드하는 다양한 방법을 가르치는 일도 많았습니다. 또한 사이트의 성능과 사용성에 영향을 미칠 수 있는 일반적인 문제를 개발자에게 경고하기 위해 동일한 안내를 계속해서 여러 가지 제공하고 있습니다. Aurora 프로젝트에 대해 생각하기 시작하면서 우리는 개발자들에게 해야 할 일을 알려주지 않아도 되는 방향으로 나아갈 수 있을지 자문했습니다. 회사의 도구 모음이 모든 것을 처리해주기 때문입니다.

제가 맞다면, 여러분은 엔지니어 6명으로 이루어진 팀인가요? 가능한 모든 프레임워크나 라이브러리를 사용할 수는 없습니다. 그러면 어떤 파트너와 함께 일할지 어떻게 선택할까요? 그들은 누구인가요?

Addy: 웹은 다양한 면에서 서부의 황야와 같습니다. 원하는 프레임워크, 번들러, 라이브러리, 서드 파티를 원하는 대로 선택할 수 있습니다. 이로 인해 성능 저하 또는 성능 저하에 영향을 미칠 수 있는 여러 복잡성이 야기됩니다. 성능을 향상시키는 가장 좋은 방법 중 하나는 이러한 레이어가 편안함을 느끼고 더 많은 의견을 추가할 수 있도록 하는 것입니다.

예를 들어 웹 프레임워크 (Next.js, Nuxt.js, Angular와 같은)는 수작업으로 구동되는 솔루션보다 더 많은 의견과 기본값으로 베이킹하려고 합니다. 이것이 바로 YouTube가 파트너들과 협력하는 것을 좋아하는 이유 중 하나입니다. 이러한 모델에서는 더 나은 코어 웹 바이탈을 위해 이미지, 글꼴, 스크립트를 로드하는 방법에 대해 더 강력한 기본값을 사용하는 것이 합리적입니다.

또한 최신 권장사항이 적용되는 위치나 재고해야 할 수 있는 부분을 확인할 수 있는 좋은 방법이며, 전체 생태계에 최적화 문제 해결 방법을 알리는 데 도움이 될 수 있습니다.

Kara: 현실적으로 인기도도 고려해야 합니다. 웹에 최대한 큰 영향을 미치고자 하는 경우, 기존의 대규모 개발자 커뮤니티가 있는 프레임워크 및 라이브러리를 사용하는 것이 이상적입니다. 이를 통해 더 많은 개발자와 더 많은 앱에 도달할 수 있습니다. 그러나 인기는 단순한 것만은 아닙니다. 결국에는 인기도, 도서관의 독창성, 사용 가능한 기능 세트가 모두 어우러집니다.

예를 들어 인기도만 고려하면 React, Vue, Angular가 '3대 주요 플랫폼'입니다. 하지만 우리는 Next.js, Nuxt 및 Angular를 가장 많이 사용합니다. React 및 Vue와 같은 뷰 라이브러리는 대부분 렌더링에 중점을 두므로 원하는 모든 기능을 직접 빌드할 수 없기 때문입니다. 따라서 Google은 이를 기반으로 구축된 독자적인 메타 프레임워크인 Next.js 및 Nuxt와 더 긴밀하게 협력합니다. 이 수준의 추상화에서는 내장 구성요소를 만들 수 있습니다. 또한 서버가 내장되어 있으므로 서버 측 최적화를 포함할 수 있습니다.

Angular가 이러한 긴밀한 파트너십 목록에 포함되어 있지만 메타 프레임워크가 아님을 알 수 있습니다. Angular는 상당히 인기가 있지만 React와 Vue처럼 보완적인 메타 프레임워크가 없기 때문에 다소 특별한 경우에 해당합니다. 따라서 가능한 경우 Angular와 직접 작업하고 CLI를 통해 기능을 제공합니다.

Google은 Gatsby와 같은 다른 프로젝트와도 여러 진행 중인 관계를 맺고 있습니다. 이 프로젝트에서는 설계와 관련하여 어느 정도 정기적으로 동기화하지만 코드에 적극적으로 기여하지는 않습니다.

그렇다면 실생활에서는 어떤 모습일까요? 이 문제를 해결하기 위해 어떤 접근 방식을 사용했나요?

카라: 실제로 YouTube는 긴밀히 협력하는 몇 가지 프레임워크가 있습니다. 잠시 시간을 내어 이 프레임워크를 사용하여 앱을 프로파일링하고 일반적인 성능 문제를 파악해 보겠습니다. 그런 다음 프레임워크팀과 협력하여 이러한 고충을 해결하기 위한 실험적 기능을 설계하고 OSS 저장소에 코드를 직접 제공하여 구현을 진행합니다.

성능에 미치는 영향이 예측한 내용인지 검증하는 것이 매우 중요하므로 외부 회사와 협력하여 프로덕션의 성능 테스트를 수행합니다. 결과가 고무적이면 기능이 '안정화'되도록 설정하고 잠재적으로는 기본값으로 설정할 수 있습니다.

이 모든 것이 말처럼 쉬운 일은 아닙니다. 지금까지 얻은 어려움이나 교훈은 무엇인가요?

Houssein: Google은 최선을 다해 다양한 우선순위로 인기 있는 오픈소스 저장소에 기여하고자 노력하고 있습니다. Google 팀이라고 해서 반드시 기능에 우선순위가 부여되는 것은 아닙니다. 따라서 Google은 상대방에게 끼어들지 않고 새로운 기능을 제안하고 출시하는 일반적인 프로세스에 맞추기 위해 최선을 다하고 있습니다. 우리는 Next.js, Nuxt, Angular 생태계의 수용적인 유지 관리 담당자들과 함께 일하게 되어 매우 운이 좋았습니다. Google은 웹 생태계에 대한 Google의 우려에 열린 자세로 임하고 있으며 다양한 방식으로 Google과 협력할 의향이 있다는 점에 감사드립니다.

우리가 함께 작업하는 많은 프레임워크에서 우리의 전반적인 사명은 동일합니다. 개발자가 어떻게 처음부터 향상된 사용자 환경을 제공하면서 훌륭한 개발자 환경을 누리려면 어떻게 해야 할까요? Google은 수백, 수천 명은 아니더라도 수백 명에 달하는 커뮤니티 참여자와 프레임워크 유지관리자가 서로 교차하는 서로 다른 프로젝트에서 작업하고 있다는 사실을 잘 알고 있으며 존중하고 있습니다.

카라: 또한 Google은 실적에 미치는 영향을 검증하고 데이터를 바탕으로 조치를 취하는 것을 중요하게 여기므로 프로세스에 시간이 조금 더 걸립니다. 아직 미지의 영역이므로, 최적화 범위를 벗어나지 않는 실험을 진행하면서 기능을 완성하지 못할 수도 있습니다. 기능이 실행되지 않더라도 실적을 검사하는 몇 가지 추가 단계에는 시간이 걸리고 일정이 길어집니다.

기능을 테스트할 제작 파트너를 찾기도 쉽지 않습니다. 앞서 언급했듯이 비즈니스는 각자 우선순위를 두고 있기 때문에 먼저 진행되어야 하는 기존 프로젝트와 잘 조율하지 못하면 새로운 이니셔티브에 적응하기가 어려울 수 있습니다. 게다가, 지원에 가장 관심이 많은 회사들은 이미 실적에 투자하고 있는 경향이 있어 실제로 우리의 타겟 고객이 아닙니다. YouTube는 대규모 커뮤니티로부터 실적에 투자할 수 없는 의견을 수집하기 위해 노력 중이지만 문의 가능성이 가장 적은 사용자는 의견을 받습니다.

계속해서 어떤 유형의 최적화에 집중하고 계신가요?

Houssein: 수천 개의 애플리케이션을 분석한 결과, 가장 큰 성능 문제는 일반적으로 프레임워크 자체가 아니라 애플리케이션 코드의 안티패턴 때문에 발생합니다. 불필요하게 큰 이미지를 제공하거나, 맞춤 글꼴을 너무 늦게 로드하거나, 기본 스레드를 차단하는 서드 파티 요청을 너무 많이 가져오며, 비동기식 콘텐츠로 인해 페이지에서 다른 요소가 이동하는 방식을 처리하지 않는 경우가 그 예에 해당합니다. 이 모든 문제는 개발자가 사용하는 도구에 관계없이 발생할 수 있는 문제이므로, 우리는 이러한 문제를 잘 처리하는 몇 가지 기본 최적화를 구현하면서도 프레임워크 도구에 잘 맞는 깔끔한 개발자 환경을 제공할 수 있을지 고민했습니다.

이러한 생각을 바탕으로 Google은 다음과 같은 사항을 발표했습니다.

이러한 노력은 다른 프레임워크와 도구에 영감을 주어 유사한 최적화를 구현했습니다. 정책 위반에는 다음과 같은 예가 해당되지만, 이에 국한되지는 않습니다.

작업에서 얻은 긍정적인 결과를 일부 플레이어와 공유할 수 있나요?

후세인: Google에서 제공한 최적화 덕분에 많은 사이트의 성능이 개선되었습니다. Next.js 이미지 구성요소로 전환한 후 LCP를 2.4초에서 1.7초로 줄인 Leboncoin을 예로 들 수 있습니다. 현재 실험 단계에 있는 많은 단계가 있으며 Google은 계속해서 여기에서 얻은 교훈과 성과를 공유할 예정입니다.

좋습니다. 인기 있는 프레임워크에 집중하고 계시는 것 같습니다. 하지만 사전 작업하지 않은 다른 프레임워크나 라이브러리에서도 선제적으로 도움을 받을 수 있는 방법이 있을까요?

Addy: Aurora가 공동작업한 많은 성능 최적화는 모든 프레임워크에서 동일하게 적용할 수 있습니다. 이미지 또는 스크립트 구성요소를 위한 Google의 노력을 살펴보세요. 기존 권장사항이 코드화되어 있는 경우가 많습니다. Google에서는 이러한 구성요소를 빌드하는 '방법'과 각 프레임워크에서 구성요소가 어떻게 표시되는지 문서화하려고 합니다. 아이디어를 따라 하기 위한 좋은 출발점이 되기를 바랍니다.

우리는 하나의 생태계 (예: React 및 Next.js)에서 얻은 교훈을 얻어 이를 다른 생태계에 적용하는 데 상당한 성공을 거두었습니다. 예를 들어 새로운 Angular 이미지 지침 (Next.js 이미지 구성요소를 빌드하면서 학습한 내용을 토대로 함)이나 Gatsby가 세분화된 JavaScript 청크 분할에 대한 접근 방식을 제공합니다.

그러나 Google은 모든 프레임워크가 기여자가 유사한 성능 기능을 구축하거나 사용자에게 중요하다고 여기는 다른 최적화에 투자할 수 있는 대역폭이나 자금을 확보하지 못한다는 점도 잘 알고 있습니다. Chrome 웹 프레임워크 펀드는 JavaScript 생태계의 성능 관련 작업을 후원하여 프로젝트가 기여자에게 지불하고 성능 작업을 생태계에서 더 확장할 수 있도록 하는 방법입니다.

팀에서 계획된 로드맵은 무엇인가요?

카라: 곧 흥미로운 프로젝트가 많이 진행될 것 같네요. 주요 개편 사항:

  • 글꼴 관련 CLS 줄이기: 웹 글꼴이 로드되어 대체 글꼴을 대체할 때 레이아웃이 변경되는 것이 일반적입니다. Next.js에서 기본적으로 글꼴 관련 CLS를 줄이기 위해 글꼴 측정항목 재정의와 'size-adjust' 속성을 사용하는 방법을 모색하고 있습니다. 또한 이 문제에 대해 Nuxt 팀과 상의해 왔으며 내년에 더 많은 프레임워크로 이 아이디어를 확장할 계획입니다.
  • INP 디버깅: 이제 다음 페인트에 대한 상호작용 (INP) 측정항목이 출시되었으므로 Google에서는 프레임워크와 협력하여 커뮤니티의 INP 문제의 가장 일반적인 근본 원인을 조사하고 수정사항을 제안하고 있습니다. 저희는 이와 관련하여 Angular와 긴밀히 협력해 왔으며, 곧 몇 가지 결과를 공유할 수 있기를 바랍니다!
  • 일반적인 서드 파티 스크립트 최적화: 서드 파티 스크립트를 잘못된 시점에 로드하면 실적에 상당한 부정적인 영향을 미칠 수 있습니다. 매우 일반적인 3P가 몇 가지 있으므로 이러한 래퍼가 프레임워크로 최적으로 로드되고 기본 스레드를 차단하지 않도록 하는 래퍼를 제공할 수 있는지 조사하고 있습니다. 이 조사의 출발점으로 빌드한 Next.js 스크립트 구성요소를 사용하고 있습니다.

개발자는 이 사이트에서 Google의 진행 상황을 확인할 수 있습니다.

뉴스 속 장소

마무리하기 전에 Google에서 일어나는 다양한 프레임워크 관련 흥미로운 업데이트를 몇 가지 알려드리고자 합니다.

지난 7월, Chrome팀에서는 웹의 성능, 사용자 환경, 개발자 환경을 개선하기 위한 프로젝트에 집중하는 프레임워크 및 도구 기금을 위한 최근 자금 50만 달러를 발표했습니다. 향후 자금 지원에서는 새 프로젝트를 심사하므로 요청을 제출하는 것을 잊지 마세요.

물론 커뮤니티에서도 엄청난 일들이 벌어지고 있습니다. 이 생태계는 Deno's Fresh와 같은 새로운 프레임워크와 브라우저 내 데모일 뿐만 아니라 Web Container API를 사용하여 브라우저에서 기본적으로 Node.js를 실행하는 Svelte의 온보딩 튜토리얼과 같은 멋진 환경으로 잘 성숙했습니다. 정말 좋은 내용이네요.

생태계가 함께 이루어지면서 브라우저의 가능성을 높이고 개발자가 누구나 사용할 수 있는 제품을 빌드할 수 있도록 돕는 것을 보면 정말 설레는 일입니다. 웹 개발자가 되는 것은 흥미진진한 시기입니다.

그럼 바로 다음 인사이더님.

이번 Chrome Dev Insider 버전에 관해 어떻게 생각하시나요? 의견을 공유해 주세요.