JavaScript 프레임워크 생태계에서의 적합성
소개 블로그 게시물에서는 프레임워크와 도구를 빌드하고 사용하여 Google 검색, 지도, 포토 등의 대규모 웹 애플리케이션을 개발하고 유지하는 과정에서 많은 것을 배웠습니다. 사용자 환경에 부정적인 영향을 미칠 수 있는 코드 작성으로부터 개발자를 보호함으로써 프레임워크가 성능과 애플리케이션 품질의 결과를 바꾸는 데 핵심적인 역할을 할 수 있음을 입증했습니다.
Google 내부에서는 이 방법론을 설명하기 위해 '적합성'이라는 용어를 사용했으며, 이 문서에서는 이 개념을 JavaScript 프레임워크 생태계에 오픈소스로 제공할 방법을 다룹니다.
적합성이란 무엇인가요?
Google에서 적합성은 진화의 원동력이 되었습니다. 팀은 광범위한 코드 검토를 수행하여 정확성 문제를 넘어 앱 품질과 유지관리에 훨씬 영향을 미친 요소를 신고하는 고도로 숙련된 소수의 유지관리 담당자에 의존했습니다. 성장하는 앱 개발자 팀으로 이를 확장하기 위해 자동화되고 실행 가능한 방식으로 권장사항을 코드화하는 적합성 시스템이 개발되었습니다. 이를 통해 코드 기여자 수에 관계없이 앱 품질과 코드베이스 유지관리성 측면에서 일관되게 높은 기준을 유지할 수 있었습니다.
적합성은 개발자가 적절한 길을 나설 수 있도록 해주는 시스템이며, 자신감을 쌓고 예측 가능한 결과를 보장합니다. 팀이 성장하고 더 많은 기능이 동시에 개발됨에 따라 팀의 생산성이 높아지며 확장에 있어 핵심적인 역할을 합니다. 이를 통해 개발자는 성능, 접근성, 보안과 같은 다양한 영역의 사소함과 변화하는 환경에서 벗어나 제품 기능을 빌드하는 데 집중할 수 있습니다. 누구나 언제든지 적합성을 선택 해제할 수 있으며 팀이 약정할 사항을 시행할 수 있는 옵션까지 맞춤설정이 가능해야 합니다.
적합성은 강력한 기본값을 기반으로 하며 작성 시 적용할 수 있는 실행 가능한 규칙을 제공합니다. 이는 다음과 같은 3가지 원칙으로 나눌 수 있습니다.
1. 강력한 기본값
적합성의 기본적인 측면은 개발자가 사용하는 도구에 강력한 기본값이 적용되도록 하는 것입니다. 즉, 솔루션이 프레임워크에 기본 제공될 뿐만 아니라 프레임워크 디자인 패턴을 사용하면 올바른 작업을 하기가 쉽고 안티패턴을 따르기 어렵습니다. 이 프레임워크는 애플리케이션 설계 및 코드 구조로 개발자를 지원합니다.
로드 성능을 위해서는 모든 리소스 (글꼴, CSS, JavaScript, 이미지 등)를 최적화해야 합니다. 이는 바이트 자르기, 왕복 횟수 감소, 첫 번째 렌더링, 시각적 준비, 사용자 상호작용에 필요한 항목 분리와 관련된 복잡한 과제입니다. 예를 들어 중요한 CSS를 추출하고 중요한 이미지에 우선순위를 설정합니다.
2. 실행 가능한 규칙
기본적인 최적화가 이뤄졌다고 해도 개발자는 여전히 선택을 해야 합니다. 필요한 개발자 입력의 양과 관련하여 최적화의 가능성은 무궁무진합니다.
- 중요한 CSS 인라인 처리와 같이 개발자의 입력이 필요 없는 기본값
- 개발자의 선택이 필요합니다. 예를 들어 프레임워크에서 제공하는 이미지 구성요소를 사용하여 이미지의 크기를 조정하고 조정합니다.
- 개발자의 선택 및 맞춤설정이 필요합니다. 예를 들어 조기에 로드되도록 중요한 이미지를 태그할 수 있습니다.
- 특정 기능은 아니지만 개발자의 결정이 필요한 항목입니다. 예를 들어 조기 렌더링을 지연시키는 글꼴이나 동기 스크립트를 사용하지 않습니다.
개발자의 결정이 필요한 최적화는 애플리케이션 성능에 위험을 야기합니다. 기능이 추가되고 팀이 확장됨에 따라 숙련된 개발자라도 끊임없이 변화하는 권장사항을 따라잡을 수 없으며 시간을 최대한 활용하지 못합니다. 적합성을 위해서는 개발자가 계속 변경하는 경우에도 애플리케이션이 특정 표준을 계속 충족할 수 있도록 강력한 기본값만큼 실행 가능한 적절한 규칙이 중요합니다.
3. 작성 시간
개발 수명 주기 초기에 성능 문제를 포착하여 포기하는 것이 중요합니다. 코드가 커밋되기 전 작성 시간이 문제를 포착하고 해결하는 데 가장 적합합니다. 개발 수명 주기에서 문제가 나중에 발견되면 이를 해결하는 것이 더 어렵고 비용이 더 많이 듭니다. 이는 정확성 문제에 적용되지만 성능 문제에도 적용됩니다. 이러한 문제의 대부분은 코드베이스에 커밋된 후 소급적으로 해결되지 않기 때문입니다.
오늘날 대부분의 성능 피드백은 문서, 일회성 감사를 통해 대역 외이거나 프로덕션에 배포한 후 측정항목 회귀를 통해 너무 늦게 표시됩니다. 이를 작성 시간에 반영하려고 합니다.
프레임워크 적합성
로드 성능과 관련하여 높은 수준의 사용자 환경을 유지하려면 다음 질문에 답해야 합니다.
- 최적의 로드를 구성하는 요소는 무엇이며, 로드에 부정적인 영향을 미칠 수 있는 일반적인 문제는 무엇인가요?
- 개발자의 입력이 필요 없는 내장형 솔루션은 무엇인가요?
- 개발자가 이러한 솔루션을 사용하고 최적의 방식으로 활용하도록 하려면 어떻게 해야 할까요?
- 로드 성능에 영향을 미치기 위해 개발자가 선택할 수 있는 다른 사항은 무엇입니까?
- 작성 초기에 이러한 선택 사항(위의 3번 및 4번)을 알 수 있는 코드 패턴은 무엇인가요?
- 이러한 코드 패턴을 평가하기 위해 어떤 규칙을 만들 수 있을까요? 워크플로에 원활하게 통합되면서 작성 시 개발자에게 어떻게 표시될 수 있을까요?
Google 내부에서 보유한 적합성 모델을 오픈소스 프레임워크에 도입하기 위해 Google팀은 Next.js에 대한 많은 실험을 거쳤으며, 세분화된 비전과 계획을 공유할 수 있게 되었습니다. 코드 패턴을 평가할 수 있는 최상의 규칙 세트는 정적 코드 분석과 동적 검사를 조합해야 한다는 사실을 알게 되었습니다. 이러한 규칙은 다음을 포함한 여러 표시 경로에 적용될 수 있습니다.
- ESLint
- TypeScript
- 사용자 개발 서버에서 동적 확인 (DOM 생성 후)
- 모듈 번들러 (webpack)
- CSS 도구 (여전히 탐색 단계)
다양한 도구를 통해 규칙을 제공함으로써 규칙을 일관되게 유지할 수 있을 뿐만 아니라 로드 성능에 직접 영향을 미치는 사용자 환경 문제도 수용할 수 있습니다. 또한 이러한 규칙은 서로 다른 시점에 개발자에게 표시될 수도 있습니다.
- 개발 서버에서 로컬 개발 중에 브라우저 및 사용자의 IDE는 경고를 표시하여 개발자에게 약간의 코드를 변경하라는 메시지를 표시합니다.
- 빌드 시 해결되지 않은 문제가 사용자의 터미널에 다시 표시됩니다.
간단히 말해, 팀은 코어 웹 바이탈 또는 로드 성능과 같이 중요하게 생각하는 결과를 선택하고 모든 코드 기여자가 따라야 하는 관련 규칙 세트를 사용 설정할 수 있습니다.
새 프로젝트에는 이 방법이 효과적이지만, 전체 규칙 세트를 준수하기 위해 대규모 코드베이스를 업그레이드하는 것은 쉽지 않습니다. Google에는 개별 소스 코드 줄, 전체 디렉터리, 기존 코드베이스 또는 개발 중이 아닌 앱 부분과 같이 다양한 수준에서 선택 해제할 수 있는 광범위한 시스템이 있습니다. Google은 오픈소스 프레임워크를 사용하여 팀에 이를 제공할 수 있는 효과적인 전략을 적극적으로 모색하고 있습니다.
Next.js의 적합성
ESLint는 JavaScript 개발자 사이에서 널리 사용되며 Next.js 애플리케이션의 50% 이상이 빌드 워크플로의 일부에서 ESLint를 사용합니다. Next.js v11에는 맞춤 플러그인과 공유 가능한 구성이 포함된 즉시 사용 가능한 ESLint 지원이 도입되어 개발 중 및 빌드 시간에 일반적인 프레임워크 관련 문제를 더 쉽게 포착할 수 있습니다. 이를 통해 개발자는 작성 시 중요한 문제를 해결할 수 있습니다. 페이지에 HTML 링크 없음처럼 특정 구성요소가 성능 저하를 일으킬 수 있는 방식으로 사용되거나 사용되지 않는 경우를 예로 들 수 있습니다. 또는 특정 글꼴, 스타일시트 또는 스크립트가 페이지의 리소스 로드에 부정적인 영향을 미칠 수 있습니다. (예: 동기식 스크립트 없음)
ESLint 외에도 개발과 프로덕션의 통합 유형 검사가 TypeScript가 지원되는 v9부터 Next.js에서 지원되었습니다. 프레임워크에서 제공하는 여러 구성요소 (이미지, 스크립트, 링크)는 HTML 요소 (<img>, <script>, <a>)의 확장 프로그램으로 빌드되어 개발자에게 웹페이지에 콘텐츠를 추가하는 데 효율적인 접근 방식을 제공합니다. 유형 확인은 할당된 속성과 옵션이 지원되는 값 및 유형의 허용 가능한 범위 내에 있는지 확인하여 이러한 기능의 적절한 사용을 지원합니다. 예시는 필요한 이미지 너비 및 높이를 참고하세요.
토스트 메시지 및 오버레이로 오류 표시
앞서 언급했듯이 적합성 규칙은 여러 영역에 표시될 수 있습니다. 현재 토스트 메시지 및 오버레이는 사용자의 로컬 개발 환경 내에서 브라우저에 직접 오류를 표시하는 방법으로 탐색되고 있습니다.
개발자가 활용하는 많은 오류 검사 및 감사 도구 (Lighthouse, Chrome DevTools 문제 탭)는 수동적이며 정보를 검색하려면 일정한 형태의 사용자 상호작용이 필요합니다. 개발자는 기존 도구에서 오류가 직접 드러나고 문제 해결을 위해 취해야 할 구체적이고 구체적인 조치를 제공할 때 조치를 취할 가능성이 높습니다.
다른 프레임워크에서의 적합성
다른 프레임워크(Nuxt, Angular 등)로 확장하기 위해 Next.js에서 먼저 적합성을 살펴보고 있습니다. ESLint 및 TypeScript는 이미 많은 프레임워크에서 다양한 방식으로 사용되고 있지만, 일관된 브라우저 수준 런타임 시스템의 개념이 활발하게 탐색되고 있습니다.
결론
적합성은 권장사항을 간단한 코드 패턴으로 개발자가 실행할 수 있는 규칙 세트로 코드화합니다. Aurora팀은 로드 성능에 중점을 두었지만 접근성 및 보안과 같은 다른 권장사항도 마찬가지로 적용할 수 있습니다.
적합성 규칙을 따르면 결과를 예측할 수 있으며 사용자 경험에 대한 높은 기준을 달성하면 기술 스택을 구축하는 부작용이 될 수 있습니다. 적합성은 팀의 생산성을 높여주며, 시간이 지남에 따라 팀과 코드베이스가 증가하더라도 애플리케이션의 높은 품질 기준을 보장합니다.