요약 / 핵심 포인트
React가 가장 큰 지지자를 잃은 날
수년 동안 웹 개발자들은 오픈 웹 플랫폼의 논쟁의 여지가 없는 바이블로서 MDN Web Docs Web Docs에 의존해 왔습니다. 이곳은 단순한 문서 사이트를 넘어, 모범 사례를 지시하고, 표준을 정의하며, 업계 전반에 걸쳐 수많은 아키텍처 결정을 안내하는 결정적인 권위자입니다. 따라서 이곳의 기술적 선택은 비할 데 없는 무게로 울려 퍼지며, 인터넷을 위한 구축 방식의 근본적인 변화를 알립니다.
그러한 영향력으로 인해 이 발표는 지진과 같은 사건이었습니다. MDN Web Docs Web Docs가 공식적으로 React를 포기했습니다. 이것은 조용한 사용 중단이나 사소한 리팩토링이 아니었습니다. 이는 전체 프런트엔드인 Yari를 구동했던 프레임워크에 대한 전면적인 거부였습니다. Yari는 'crazy webpack config'로 Create React App에서 이젝트되었고 심지어 `dangerouslySetInnerHTML`에 의존하는 React SPA였습니다. 이 움직임은 주요 클라우드 제공업체가 갑자기 주력 데이터베이스 지원을 중단하는 것과 유사하게 개발자 커뮤니티에 충격을 주었습니다.
이 결정은 단순한 회사 재구축을 넘어섭니다. 이는 웹 플랫폼 자체의 미래 방향에 대한 심오한 진술입니다. HTML, CSS, JavaScript를 문서화하는 바로 그 주체인 MDN Web Docs Web Docs는 이제 이러한 내재된 기술로 구축하는 것을 옹호합니다. 그들은 이전의 React 기반 Single Page Application과는 극명한 대조를 이루며, Lit와 사용자 지정 서버 컴포넌트를 사용하여 Web Components를 수용하며 전체 프런트엔드를 처음부터 다시 구축했습니다.
MDN Web Docs Web Docs는 만능 SPA 트렌드에서 벗어나 대담하고 의도적인 움직임을 보였습니다. 그들의 새로운 아키텍처는 사용자 지정 요소를 콘텐츠에 직접 통합하여 래퍼의 필요성을 없애고 사용되지 않는 JavaScript를 줄입니다. 이러한 간결하고 표준에 부합하는 개발에 대한 헌신은 메인 사이트 드롭다운과 같은 기능에서 분명히 드러납니다. 이 드롭다운은 이제 JavaScript가 로드되기 전에 전적으로 CSS로 실행된 다음 점진적으로 향상됩니다. 개발 환경 시작 시간은 2분에서 2초로 급감하여, 그들의 새롭고 성능 지향적인 접근 방식의 실질적인 이점을 보여줍니다.
Yari 내부: MDN이 없애야 했던 '미친' 스택
MDN Web Docs Web Docs는 한때 프런트엔드 역할을 했던 React 기반 Single Page Application(SPA)인 Yari에 의존했습니다. 이것은 단순한 React 구현이 아니었습니다. 팀은 Create React App에서 Yari를 이젝트하여 사용자 지정의 매우 복잡한 구성에 깊이 파고들었음을 알렸습니다. 이젝트는 세밀한 제어를 위해 Create React App의 관리되는 단순성을 포기하는 것을 의미했으며, 이는 시간이 지남에 따라 상당한 유지보수 부담으로 이어지는 선택입니다.
Yari의 증가하는 기술 부채의 핵심은 'crazy webpack config'였습니다. 수년간의 사용자 지정, 패치 및 해결 방법의 증거인 이 복잡한 설정은 개발자 속도와 빌드 효율성을 심각하게 저해했습니다. 방대한 구성은 디버깅 및 업데이트를 악몽으로 만들었고, 느리고 취약한 개발 경험을 초래했습니다. 개발자들은 고통스러울 정도로 긴 기다림에 직면했으며, 개발 환경 시작 시간은 고통스러운 2분으로 늘어났습니다. 이는 진화하는 웹 표준의 빠른 반복과 포괄적인 문서화에 중점을 둔 프로젝트에는 상당한 부담이었습니다.
복잡성을 더하고 스택의 본질적인 어색함을 보여주듯이, Yari는 콘텐츠를 렌더링하기 위해 `dangerouslySetInnerHTML`을 자주 사용했습니다. 신뢰할 수 있는 정보를 안전하게 제공하는 것이 주된 목표인 문서 사이트의 경우, 이러한 관행은 상당한 보안 위험을 수반하여 교차 사이트 스크립팅(XSS) 취약점의 길을 열었습니다. 또한 수동 콘텐츠 정화와 React의 선언적 렌더링 모델 우회를 필요로 하여 본질적으로 투박하게 느껴졌으며, 이는 팀이 감수해야 했던 어려운 타협의 명확한 지표였습니다.
궁극적으로 Yari는 근본적으로 잘못 적용된 강력한 도구였습니다. 복잡한 상태 관리를 통해 고도로 상호작용적이고 동적인 애플리케이션을 위해 설계된 무거운 SPA는 MDN Web Docs의 핵심 임무인 주로 정적이고 표준에 부합하는 문서를 제공하는 데 적합하지 않다는 것이 입증되었습니다. 이 스택은 모든 페이지 로드에 상당한 양의 사용되지 않는 JavaScript를 전송하여 페이지 렌더링 속도를 늦추고 비효율적인 사용자 경험을 유발했습니다. 이러한 아키텍처는 MDN Web Docs 자체가 옹호하는 웹 성능 원칙과 직접적으로 모순되었으며, 이는 팀을 급진적인 개편으로 이끈 중대한 불일치였습니다.
네이티브 브라우저 기술에 대한 급진적인 베팅
MDN Web Docs의 프런트엔드 재구축은 급진적인 철학에 기반을 두었습니다. 즉, 플랫폼 위에 단순히 구축하는 것이 아니라 *플랫폼과 함께* 구축하는 것입니다. 그들은 전통적인 프레임워크의 추상화 계층을 의식적으로 거부하고 네이티브 브라우저 기능을 직접 수용했습니다. 이는 Web Components로의 완전한 전환을 의미했으며, 특히 구현을 위해 Lit을 활용했습니다.
Web Components는 사용자 정의, 재사용 가능하며 캡슐화된 HTML 태그를 생성하기 위한 강력한 웹 표준 모음을 제공합니다. 그 이점은 심오합니다. Shadow DOM을 통한 진정한 캡슐화는 스타일 또는 스크립트 충돌을 방지하고, 프레임워크에 구애받지 않는 재사용성을 제공하며, 다양한 프런트엔드 환경에서 원활한 상호 운용성을 보장합니다. 이 접근 방식은 구성 요소가 콘텐츠 내에 직접 존재하도록 허용하여 래퍼 복잡성을 제거하고 사용되지 않는 JavaScript 전송을 없앱니다.
이러한 전략적 전환은 문서 사이트의 미래 보장을 우선시합니다. Custom Elements, Shadow DOM, HTML Templates와 같은 기본적인 웹 표준에 의존함으로써 MDN Web Docs는 단일 JavaScript 프레임워크를 훨씬 능가하는 수명을 가진 기술에 투자했습니다. 표준은 느리고 예측 가능하게 발전하여 장기적인 안정성을 보장하고 노후화 위험을 줄입니다.
이를 프레임워크 중심 세계에서 만연한 빠른 변화와 생태계 종속과 극명하게 대조해 보십시오. 프레임워크는 종종 개발 패턴을 지시하고, 빈번한 파괴적 변경 사항을 도입하며, 지속적인 리팩터링 및 종속성 업데이트를 강요합니다. MDN Web Docs는 이러한 주기를 명시적으로 피하고 일시적인 트렌드보다 안정성을 선택했습니다.
Lit으로 구축된 Web Components와 사용자 정의 서버 구성 요소를 특징으로 하는 새로운 스택은 실질적인 성능 향상을 제공합니다. 개발 환경 시작 시간이 고통스러운 2분에서 단 2초로 급감했습니다. 이 간결한 아키텍처는 페이지에 필요한 정확한 CSS 및 JavaScript만 로드되도록 보장하여 전송되는 코드를 극적으로 줄이고 초기 페이지 로드 시간을 향상시킵니다. 이 변환의 기술적 세부 사항에 대해 더 자세히 알아보려면 독자는 Under the hood of MDN Web Docs's new frontend - MDN Web Docs를 참조할 수 있습니다.
Lit을 만나보세요: 안티-프레임워크 강자
React를 버린다는 것은 MDN Web Docs Web Docs가 플랫폼 위에서만 구축하는 것이 아니라 플랫폼과 함께 구축하는 철학을 받아들였음을 의미했습니다. 이러한 급진적인 변화는 빠르고 가벼운 web components를 구축하기 위한 간단한 라이브러리인 Lit에서 이상적인 파트너를 찾았습니다. Lit은 거대한 framework가 아니라 집중된 도구로, 전체 애플리케이션 아키텍처를 지시하지 않으면서도 네이티브 Web Components를 즐겁게 작업할 수 있도록 충분한 추상화를 제공합니다.
Lit의 매력은 종종 킬로바이트 단위로 측정되는 최소한의 footprint와 탁월한 runtime performance에 있습니다. 이는 네이티브 browser APIs의 거친 부분을 우아하게 다듬어주는 개발자 친화적인 API를 제공하며, 직관적인 decorators와 declarative rendering을 통해 reactive templating 및 state management를 단순화합니다. 이러한 접근 방식은 components가 놀랍도록 간결하고 빠르며 본질적으로 web standards에 부합하도록 보장합니다.
결정적으로, Lit은 사용자 정의 elements가 HTML 내부에 직접 존재할 수 있도록 하여 번거로운 wrapper components나 복잡한 rendering trees의 필요성을 없앱니다. 이는 boilerplate code를 크게 줄이고 components가 진정으로 네이티브이며 표준 HTML elements와 완벽하게 공존하도록 보장합니다. MDN Web Docs Web Docs의 이전 React SPA인 Yari(ejected Create React App)는 종종 콘텐츠를 주입하기 위해 "crazy webpack config"와 심지어 `dangerouslySetInnerHTML`에 의존했으며, 이는 복잡한 구조 내에서 동적 elements를 통합하는 데 상당한 마찰이 있었음을 보여줍니다.
Lit은 MDN Web Docs Web Docs에게 실용적인 중간 지점을 제공하여, 순수한 browser APIs와 완전한 framework 사이의 균형을 맞췄습니다. 이는 vanilla JavaScript보다 훨씬 더 많은 구조와 유지보수성을 제공하면서도 React의 오버헤드와 독단적인 부분은 극히 일부에 불과했습니다. 이를 통해 팀은 크고 복잡한 dependency tree의 부담 없이 최신 web standards의 힘을 활용할 수 있었습니다. 그 결과는 성능이 뛰어날 뿐만 아니라(개발 환경 시작 시간을 2분에서 단 2초로 단축) 미래 개발에도 놀랍도록 직관적인 frontend stack이며, open web platform을 문서화하고 구현하려는 그들의 사명과 완벽하게 일치합니다.
MDN의 비밀 병기: 자체 개발 Server Components
MDN Web Docs Web Docs는 server components를 자체적으로 설계했는데, 이는 React Server Components가 널리 주목받기 훨씬 전부터 서버 중심 UI로의 업계 변화를 예측한 선견지명 있는 움직임이었습니다. 이 독점적인 아키텍처는 극도의 효율성을 목표로 하며, 모든 페이지가 매우 빠른 사용자 경험을 위해 필수적인 code만을 전달하도록 보장합니다. 팀은 이전 Create React App 기반 Yari frontend와 관련된 bloat에 대한 직접적인 대응으로 client-side overhead를 최소화하는 것을 우선시했습니다.
이러한 사용자 정의 server components는 Lit components를 server에서 HTML로 직접 렌더링하며, 이는 client의 작업 부하를 크게 줄이는 과정입니다. NodeJS를 활용하여 MDN Web Docs Web Docs의 backend는 Lit code를 처리하고, 대화형 web components를 browser에 도달하기 전에 정적 HTML strings으로 변환합니다. 이 강력한 pre-rendering 기능은 client-side rendering 지연을 없애고, 완전히 형성된 콘텐츠를 즉시 전달하며, 기존 client-side SPA의 복잡성을 우회합니다.
결정적으로, MDN Web Docs Web Docs는 아직 더 넓은 채택을 얻고 있는 강력한 web platform 기능인 Declarative Shadow DOM을 활용합니다. 이 기술은 JavaScript에 의존하여 로드 후 구성하는 대신, component의 shadow DOM과 관련 styles를 초기 HTML payload 내에 직접 포함합니다. Declarative Shadow DOM을 지원하는 browsers는 HTML이 도착하는 순간 component의 캡슐화된 구조와 styling을 즉시 렌더링할 수 있으며, 단 한 줄의 JavaScript도 파싱하거나 실행될 때까지 기다릴 필요가 없습니다. 이는 중요한 시각적 향상을 제공합니다.
이 혁신적인 접근 방식은 HTML이 도착하는 즉시 사용자가 완전히 스타일링되고 기능적인 컴포넌트를 볼 수 있음을 의미하며, 인지된 성능을 크게 향상시키고 누적 레이아웃 이동을 줄입니다. 페이지에 *실제로 존재하는* 컴포넌트를 하이드레이션하고 상호작용성을 추가하는 데 필요한 JavaScript만 다운로드됩니다. 특정 페이지에 없는 컴포넌트의 사용되지 않는 JavaScript는 클라이언트에 전혀 도달하지 않으며, 이는 모든 경로에 잠재적으로 불필요한 코드의 대규모 번들을 제공했던 이전 Yari SPA와는 극명한 대조를 이룹니다.
MDN Web Docs의 서버 컴포넌트는 엄청나게 가볍고 최적화된 페이로드를 제공하여 방대한 문서 라이브러리의 초기 로드 시간과 대역폭 소비를 크게 줄입니다. 서버 측 렌더링에 대한 이러한 전략적 투자와 네이티브 브라우저 기능의 결합은 플랫폼 위에 구축하는 것을 넘어 플랫폼과 함께 구축하려는 깊은 의지를 보여줍니다. 그 결과는 웹 표준을 설명할 뿐만 아니라 MDN Web Docs가 옹호하는 성능 및 효율성 표준 자체를 예시하며 매력적인 대안을 제공하는 문서 사이트입니다.
2분에서 2초로: 실제 영향
MDN Web Docs의 프런트엔드 아키텍처 변화는 개발자 생산성에서 가장 극적인 영향을 미쳤습니다. 엔지니어들이 한때 로컬 개발 환경이 시작되기를 2분 이상 기다렸던 반면, 새로운 스택은 이제 단 2초 만에 부팅됩니다. 이러한 놀라운 98%의 시작 시간 단축은 개발 워크플로를 근본적으로 재편하여 컴파일 대기열 대신 기능 작업 및 버그 수정에 셀 수 없이 많은 시간을 할애할 수 있게 합니다.
새롭게 발견된 이러한 효율성은 내부 개발 주기를 훨씬 넘어 문서에 액세스하는 모든 사용자에게 직접적인 이점을 제공합니다. 방문자는 이제 훨씬 빠른 페이지 로드를 경험하고, 더 적은 데이터를 소비하며, 전반적으로 훨씬 더 빠릿빠릿한 사용자 경험을 즐깁니다. 이 아키텍처는 성능을 우선시하여 MDN Web Docs가 느린 네트워크 연결이나 리소스가 제한된 장치에서도 접근 가능하고 반응성을 유지하도록 보장하며, 포괄적인 웹을 구현합니다.
이 성능 우선 철학의 대표적인 예인 메인 사이트 드롭다운 메뉴를 고려해 보세요. 이제 어떤 JavaScript도 로드되기 전에 전적으로 CSS로 작동하며, 필요한 스크립트를 사용할 수 있게 되면 점진적으로 향상됩니다. 이 네이티브 우선 접근 방식은 즉각적인 상호작용성과 반응성을 제공하며, 무거운 프레임워크를 위에 겹쳐 쌓는 대신 웹 플랫폼으로 구축하는 것의 힘을 보여줍니다.
이러한 놀라운 성과는 JavaScript 페이로드를 대폭 줄이고 브라우저 네이티브 기능을 완전히 수용하려는 아키텍처 결정에서 직접 비롯됩니다. 무거운 React Single Page Application (SPA) 오버헤드를 제거하고 Web Components의 전략적 사용을 결합하여 불필요한 복잡성을 제거했습니다. Lit와 같은 라이브러리는 이러한 컴포넌트를 위한 가벼운 기반을 제공하며, MDN Web Docs의 자체 개발 서버 컴포넌트는 페이지에 필요한 정확한 CSS와 JavaScript만 클라이언트에 도달하도록 보장합니다.
궁극적으로, 이러한 변화는 MDN Web Docs가 문서화하는 바로 그 웹 표준에 대한 깊은 의지를 나타냅니다. 복잡하고 이젝트된 Create React App에서 네이티브 브라우저 기능으로 구축된 간소화된 스택으로 전환함으로써 성능을 크게 향상시켰을 뿐만 아니라, 영향력 있는 웹 플랫폼이 어떻게 작동할 수 있는지에 대한 새로운 기준을 제시하며, 적은 JavaScript가 종종 더 많은 속도를 의미한다는 것을 증명합니다.
점진적 향상: JavaScript가 선택 사항일 때
MDN Web Docs의 새로운 스택은 모든 사용자에게 견고하고 기능적인 기본을 우선시하는 근본적인 원칙인 점진적 향상(Progressive Enhancement)을 수용합니다. 이 접근 방식은 강력한 HTML과 CSS를 통해 핵심 콘텐츠와 기능을 제공하는 것으로 시작하며, JavaScript는 선택적 향상으로만 추가됩니다. 스크립트가 실패하거나, 차단되거나, 아직 로드되지 않은 경우에도 사이트는 완전히 사용 가능합니다.
사이트의 주요 내비게이션 드롭다운을 고려해 보세요. 이는 중요한 인터페이스 요소입니다. 단 한 줄의 JavaScript 없이 CSS만을 사용하여 사용자 상호작용에 반응하며 완벽하게 작동합니다. 필요한 JavaScript가 로드된 후에야 향상된 키보드 내비게이션이나 동적 상태 관리와 같은 추가적인 개선 사항을 받습니다. 이는 다양한 네트워크 조건에서 즉각적인 사용성과 일관된 경험을 보장합니다.
이러한 아키텍처 선택은 상당한 이점을 제공합니다: 향상된 탄력성(resilience), 광범위한 접근성, 그리고 현저히 빠른 인지 성능(perceived performance)입니다. 느린 연결이나 구형 장치를 사용하는 사용자도 여전히 완전히 기능하는 사이트에 접속하며, 깨진 인터페이스를 결코 만나지 않습니다. 핵심 콘텐츠와 내비게이션은 항상 사용 가능하며, 견고한 기반을 제공합니다.
이러한 전략은 많은 최신 Single Page Application (SPA) 아키텍처와 극명한 대조를 이룹니다. 종종 SPA는 거의 빈 페이지를 제공하며, 콘텐츠가 표시되거나 상호작용하기 전에 대규모 JavaScript 번들을 다운로드, 파싱 및 실행해야 합니다. 이는 사용자에게 치명적인 실패 지점과 상당한 지연을 초래합니다.
MDN Web Docs의 Progressive Enhancement에 대한 헌신은 그들의 철학을 강조합니다: 플랫폼 위에만 구축하는 것이 아니라 플랫폼과 함께 구축하는 것입니다. 네이티브 브라우저 기능을 먼저 활용함으로써, 팀은 웹 표준의 결정적인 소스에 접근하는 모든 사람에게 본질적으로 더 견고하고, 접근 가능하며, 성능이 뛰어난 웹 경험을 제공했습니다.
코드 그 이상: 전면적인 UI 개편
심오한 아키텍처 변화를 넘어, MDN Web Docs는 극적인 사용자 인터페이스 개편도 공개했습니다. 이것은 단순히 백엔드 코드 재작성이 아니었습니다. 개발자들이 웹의 가장 중요한 문서와 상호작용하는 방식을 완전히 재구상한 것을 의미했습니다. 새로운 프런트엔드는 현대 웹 표준과 사용자 우선 접근 방식에 대한 근본적인 헌신을 직접적으로 반영하는 세련되고 직관적인 경험을 제공했습니다.
방문객들은 플랫폼 전체에 걸쳐 더 깔끔하고 일관된 미학을 즉시 알아차렸습니다. 팀은 타이포그래피를 세심하게 다듬어, 산문과 코드 예제 모두에 신중하게 선택된 글꼴로 가독성을 높여 장문의 기사가 덜 피로하게 만들었습니다. 새롭고 전용인 코드 글꼴(code font)은 구문의 가독성을 획기적으로 향상시켰는데, 이는 프로그래밍과 기술적 정확성에 중점을 둔 사이트에서 매우 중요한 세부 사항입니다.
특정 UI 요소들은 상당한 주목을 받아 일상적인 상호작용을 변화시켰습니다. MDN Web Docs는 선명한 Lucide 아이콘으로 전환하여, 오래된 자산을 시각적 명확성을 향상시키는 확장 가능하고 일관된 세트로 교체했습니다. 검색 경험은 강력한 재설계를 거쳐, 사용자에게 종종 첫 번째 상호작용 지점인 문서 발견을 간소화하는 더 직관적이고 기능이 풍부한 모달을 도입했습니다. 심지어 상단 내비게이션도 포괄적인 새로고침을 통해 필수 콘텐츠로의 더 명확한 경로를 제공했습니다.
무엇보다도, Lit으로 구축된 새로운 컴포넌트 기반 아키텍처는 이러한 시각적 개선을 직접적으로 가능하게 했습니다. Lit의 경량 웹 컴포넌트를 채택함으로써, MDN Web Docs는 응집력 있는 디자인 시스템을 구축하여 수십만 페이지에 걸쳐 일관성을 유지하는 것을 훨씬 쉽게 만들고 빠른 개발 주기를 보장했습니다. 이 모듈식 접근 방식은 UI 요소가 재사용 가능하고, 성능이 뛰어나며, 일관된 스타일을 갖추도록 보장하여 전체 사용자 경험을 기본 기술력에 맞춰 향상시켰습니다.
이것이 SPA 시대의 종말을 알리는 신호일까요?
MDN Web Docs의 급진적인 전환은 개발자들 사이에서 필연적으로 한 가지 질문을 불러일으킵니다: 이것이 React의 지배력, 또는 심지어 단일 페이지 애플리케이션(SPA) 시대 자체의 종말을 알리는 신호일까요? 답은 미묘하며, 구식화에 대한 단정적인 선언이 아닙니다. React는 풍부한 클라이언트 측 상태 관리가 가장 중요한 고도로 상호작용적이고 복잡한 애플리케이션에 필수적인 강력한 도구로 남아 있습니다.
하지만 MDN Web Docs는 근본적으로 콘텐츠 전달 플랫폼으로 작동합니다. 주요 기능은 문서를 효율적으로 제공하는 것이지, 전체 SPA를 필요로 하는 복잡한 사용자 상호작용을 관리하는 것이 아닙니다. 이전 Yari 스택인 이젝트된 Create React App은 '과잉' 솔루션이 되었으며, '복잡한 webpack config'에 시달리고 콘텐츠 통합을 위해 `dangerouslySetInnerHTML`까지 필요로 했습니다. MDN Web Docs는 전통적인 SPA에 내재된 무거운 JavaScript 번들이나 클라이언트 측 라우팅 오버헤드가 단순히 필요하지 않았습니다.
MDN Web Docs의 이러한 움직임은 '기본 SPA' 사고방식에서 벗어나려는 더 광범위하고 가속화되는 산업 트렌드를 반영합니다. 개발자들은 특정 사용 사례에 맞춰진 더욱 미묘한 아키텍처 솔루션을 점점 더 많이 찾고 있습니다. 예시로는 다음과 같은 프레임워크 및 라이브러리가 있습니다: - Astro - Qwik - 최신 서버 측 렌더링(SSR) 프레임워크
이러한 새로운 솔루션은 부분 하이드레이션 및 아일랜드 아키텍처와 같은 개념을 옹호하며, 상호작용하는 컴포넌트에 필요한 JavaScript만 제공합니다. 이들은 초기 페이지 로드 성능을 우선시하고 서버 측 렌더링을 활용하여 빠르고 콘텐츠가 풍부한 기준선을 제공합니다. 이러한 철학은 Lit을 웹 컴포넌트에 사용하고 사용자 정의 서버 컴포넌트를 사용하여 페이지에 필요한 정확한 CSS 및 JavaScript만 로드하는 MDN Web Docs의 새로운 스택과 완벽하게 일치합니다.
프런트엔드 개발은 보편적인 프레임워크에서 벗어나 목표 지향적인 효율성으로 초점을 옮기며 새로운 성숙 단계에 접어들었습니다. 모든 프로젝트에 최신 유행하는 프레임워크를 맹목적으로 채택하던 시대는 저물고 있습니다. 대신, 이제 생태계는 실제 성능 지표와 적합성에 기반한 실용적인 선택을 중요하게 여기며, 도구 사용에 대한 보다 신중한 접근 방식을 요구합니다.
MDN Web Docs의 극적인 성과 — 개발 환경 시작 시간이 2분 이상에서 단 2초로 급감한 것 —는 이러한 변화를 강조합니다. 그들의 결정은 플랫폼으로 구축하고, 효율성을 우선시하며, 점진적 개선을 수용하는 것이 콘텐츠 우선 경험을 위한 거대한 클라이언트 측 프레임워크를 능가하는 미래를 입증합니다. 이것은 React의 종말이 아니라, 더 사려 깊고 성능이 뛰어난 프런트엔드 환경을 위한 분명한 신호입니다.
MDN의 승부수가 당신의 다음 프로젝트에 의미하는 것
MDN Web Docs가 React에서 극적으로 전환한 것은 다음 웹 프로젝트를 계획하는 모든 팀에게 마스터클래스 역할을 합니다. 개발자와 기술 리더는 이제 프런트엔드 아키텍처에 대한 오래된 가정을 비판적으로 재평가해야 합니다. 이것은 단지 MDN Web Docs의 이야기가 아닙니다. 불필요한 복잡성 없이 효율적이고 탄력적인 웹 경험을 구축하기 위한 강력한 청사진입니다.
먼저, 전체 사이트에 걸쳐 완전한 클라이언트 측 프레임워크가 실제로 필요한지 면밀히 검토하십시오. MDN Web Docs의 이전 Yari 스택(ejected Create React App)은 복잡한 webpack 구성의 부담이 되었고, 콘텐츠를 렌더링하기 위해 `dangerouslySetInnerHTML`까지 필요했습니다. 이러한 수준의 프레임워크 오버헤드는 콘텐츠 중심 사이트에서 종종 수익 감소를 가져오며, 상당한 개발자 시간을 소모하고 사용되지 않는 JavaScript를 메가바이트 단위로 배포합니다. 모든 페이지에 완전한 SPA가 정말로 필수적인지 평가하십시오.
둘째, Web Components를 간과하지 마십시오. 이들은 JavaScript 프레임워크의 끊임없는 변화에서 벗어날 수 있는 강력한 길을 제공하는 성숙하고 강력한 플랫폼 프리미티브입니다. MDN Web Docs는 Lit를 채택하여 콘텐츠 내에 직접 존재하는 사용자 정의 요소를 구축함으로써 래퍼 컴포넌트의 필요성을 없애고 배포되는 코드량을 획기적으로 줄였습니다. 이 접근 방식은 지속적인 안정성, 탁월한 성능, 그리고 웹 표준에 직접 기반을 둔 미래 지향적인 토대를 제공합니다.
셋째, 견고하고 빠른 웹 경험을 구축하기 위한 기본 원칙으로 점진적 향상(progressive enhancement)을 다시 받아들이십시오. MDN Web Docs의 새로운 스택은 이를 잘 보여줍니다. 메인 사이트 드롭다운과 같은 핵심 UI 요소는 JavaScript가 로드되기 전에 CSS만으로 순수하게 작동합니다. 향상을 계층화하면 네트워크 조건이나 브라우저 기능에 관계없이 모든 사용자에게 견고하고 접근 가능한 기준선을 보장하여 JavaScript를 종속성이 아닌 선택적 계층으로 만듭니다.
다음 프로젝트의 아키텍처를 결정할 때 애플리케이션의 특성을 고려하십시오. 복잡한 상태 관리와 빈번한 클라이언트 측 업데이트가 필요한 고도로 상호작용적이고 데이터 집약적인 웹 애플리케이션(대시보드 또는 실시간 편집기 등)의 경우, React와 같은 완전한 SPA는 여전히 강력한 이점을 제공합니다. 그러나 대부분의 콘텐츠 중심 웹사이트, 문서 포털 또는 마케팅 사이트의 경우 MDN Web Docs는 서버 렌더링 HTML과 타겟팅된 JavaScript를 사용하는 더 가볍고 컴포넌트 기반 접근 방식의 심오한 이점을 보여줍니다. 이 전략은 불필요한 클라이언트 측 복잡성보다 초기 페이지 로드 속도, 복원력 및 장기적인 유지보수성을 우선시합니다. 개발 환경 시작 시간이 2분 이상에서 단 2초로 급감한 것은 이러한 영향을 강조합니다.
자주 묻는 질문
MDN은 왜 React 프런트엔드를 교체했나요?
MDN은 기술 부채를 없애고 성능을 개선하며, 문서화하는 웹 표준에 자체 사이트를 맞추기 위해 Yari라는 이름의 React SPA를 교체했습니다. 이전 스택은 복잡한 구성을 가지고 있었고 콘텐츠 중심 사이트에 불필요한 JavaScript를 배포했습니다.
MDN의 새로운 기술 스택은 무엇인가요?
MDN의 새로운 스택은 Lit 라이브러리를 사용하는 네이티브 Web Components를 기반으로 구축되었습니다. 또한 사용자 정의 서버 컴포넌트를 특징으로 하며 점진적 향상을 강조하여, JavaScript가 로드되기 전에 핵심 기능이 CSS만으로 작동하도록 합니다.
Lit은 무엇이며 MDN은 왜 이를 선택했나요?
Lit은 빠른 Web Components를 구축하기 위한 경량 라이브러리입니다. MDN은 Lit이 간단하고, 매우 성능이 뛰어나며, 브라우저 네이티브 기술을 활용하여 더 큰 프런트엔드 프레임워크의 오버헤드와 종속성을 피할 수 있기 때문에 선택했습니다.
새로운 스택은 MDN의 성능을 어떻게 개선했나요?
새로운 아키텍처는 페이지에 필요한 정확한 CSS와 JavaScript만 로드함으로써 성능을 크게 향상시켰습니다. 또한 개발 환경 시작 시간을 2분 이상에서 단 2초로 단축하여 개발자 경험을 개선했습니다.