세계에는 Unreal Engine, Unity Engine, Godot Engine, Cry Engine 등 많은 게임 엔진이 있습니다.

이 게임 엔진의 공통점은 무엇입니까? 맞춤화 가능. 게임마다 요구 사항이 다르며 목표를 달성하려면 특정 기능이 필요합니다. 단일 프로그램에서 가능한 모든 기능을 제공하는 것은 어렵습니다. 이것이 바로 많은 엔진에서 개발자가 소스 코드를 수정하고 자신만의 사용자 정의 기능을 구축할 수 있도록 허용하는 이유입니다. 사용자 정의는 이러한 엔진의 필수적인 부분입니다.

이제 다시 프런트엔드 개발로 돌아가 보겠습니다. React는 이 분야에서 가장 인기 있는 프레임워크 중 하나입니다. 그런데 게임 개발에서 엔진을 수정하는 것이 흔한 것처럼, 프론트엔드 개발에서도 React의 내부 소스 코드를 수정하는 것이 흔한가요? 이 간단한 질문은 우리가 실제로 추구하는 것이 무엇인지에 대해 많은 것을 보여주며 현대 프론트엔드 개발과 다른 분야 간의 방향 차이를 강조합니다.

React는 수정이 거의 불가능한 프레임워크입니다. React를 있는 그대로 사용하는 것이 권장되며 개발자가 내부 아키텍처나 렌더링 파이프라인을 사용자 정의할 수는 없습니다. 따라서 React를 사용한다는 것은 React 구조의 범위 내에서 모든 요구 사항을 해결해야 함을 의미합니다. 하지만 세상은 다양한 요구사항으로 가득 차 있으며 React 프레임워크 내에서 모든 요구 사항을 해결할 수는 없습니다.

"공짜 점심 같은 것은 없습니다."
"모든 것을 할 수 있는 도구는 없습니다."

React는 하나의 개발 도구일 뿐이며 한계가 있습니다.

개발자가 React를 사용하는 주된 이유는 생산성입니다. React는 "웹 개발에서 DOM 컴포넌트를 어떻게 더 효율적으로 개발할 수 있을까?"라는 질문을 가지고 만들어졌습니다. React 접근 방식의 중심에는 DOM이 있습니다. 자동화된 기능이 일반적으로 사용자 정의의 부족을 의미하는 것처럼, 그들이 말하는 "생산성"은 "가상 DOM을 통해 브라우저와 긴밀하게 결합된 렌더링 루프를 수정할 수 없음"을 의미합니다.

React의 첫 번째 주요 문제는 DOM입니다. 모든 것이 DOM을 중심으로 돌아가는 것은 아니며 모든 프로그램이 DOM을 중심으로만 작동하는 것은 아닙니다. 그러나 React는 DOM을 철학의 핵심으로 두고 있습니다. 각 구성 요소가 "HTML Element Like"를 반환하는 JSX 구문은 이러한 사고 방식을 명확하게 반영합니다.

두 번째 문제는 가상 DOM입니다. 가상 DOM의 작동 방식은 다음과 같습니다.

• DOM은 본질적으로 느립니다.
• 이를 완화하기 위해 React는 더 빠른 내부 로직을 도입합니다.
• 이 로직은 가상 DOM이라고 알려진 실제 DOM 트리의 모양을 복사하는 객체를 생성합니다. 렌더링이 발생할 때마다 React는 이 가상 DOM을 사용하여 변경 사항을 찾아 해당 부분만 업데이트합니다.
• 이 시스템을 구현하려면 DOM 업데이트가 항상 루트 DOM 요소를 거쳐야 합니다.
• 가상 DOM은 React의 내부 작업과 원활하게 작동합니다.

문제는 애초에 HPSE가 그러한 시스템을 채택한 이유가 무엇입니까? 이 렌더링 접근 방식이 다양한 HPSE 요구 사항을 충족할 수 없다는 우려 외에도 더 큰 우려는 이러한 맥락에서 실제 유용성이 부족하다는 점입니다.

HPSE에서는 DOM 구성 요소를 클래스 수준에서 관리할 수 있습니다. 인스턴스가 생성되면 최상위 div DOM 참조가 멤버 변수로 저장됩니다. 인스턴스의 비공개 메서드는 DOM 참조를 직접 조작하거나 querySelector()를 사용하여 DOM 참조에 액세스할 수 있습니다. 대부분의 경우 이는 전체 DOM 트리를 비교하는 것보다 빠릅니다.

가상 DOM을 사용하는 것은 변경 사항을 식별하는 방법일 뿐이지만 이미 인스턴스 내부에 변경 사항이 저장되어 있는 경우 이를 다시 검색하는 것은 중복됩니다. DOM 요소가 업데이트되면 브라우저는 계속 ReFlow 및 RePaint를 트리거하므로 이후 성능에는 차이가 없습니다.

궁극적인 문제는 React의 '내부 운영'에 있습니다. 이러한 내부 작업은 정확히 무엇입니까? 자세한 문서나 정보가 부족하고 대부분의 프런트엔드 개발자도 이를 완전히 이해하지 못합니다. 브라우저 클라이언트는 이미 브라우저 자체의 추상화 계층 내에서 작동하므로 다양한 문제에 취약합니다. React의 불투명하고 수정 불가능한 내부 프로세스는 이 취약점을 더욱 악화시킬 뿐입니다.

React의 구성 요소 변경은 가상 DOM을 거쳐야 하며 가상 DOM은 특정 우선 순위 규칙을 따르는 Fiber 아키텍처에 의해 관리됩니다. 그러나 HPSE의 실시간 성능 또는 정밀 타이밍 요구 사항을 충족하기 위해 React의 내부 기능을 사용자 정의하는 방법에 대한 문서는 거의 없습니다. 마치 커스터마이징이 불가능한 엔진으로 AAA 게임을 개발하는 기분입니다.

'왜 귀찮게 하나요?'

계속 올라오는 질문이네요.

React는 내부적으로 너무 밀접하게 결합되어 있어 수정하고 싶어도 수정할 수 없습니다. 결코 그런 목적을 염두에 두고 설계되지 않았습니다. 게다가 렌더링과 상태 업데이트의 강력한 결합으로 인해 React는 데이터나 3D 요소와 같은 비시각적 구성 요소를 DOM 요소와 함께 관리해야 하는 HPSE 프로젝트에 적합하지 않습니다.

HPSE에서는 이벤트 호출 및 메모리 마운트 해제 시점이 개별 구성 요소에 묶여 있지 않을 수 있지만 React는 이러한 구성 요소 기반 구조를 시행하므로 이러한 요구 사항을 처리하기가 어렵습니다. 구성 요소의 상태 변경이 전체 렌더링 트리에 영향을 미칠 수 있는 React의 설계는 그러한 영향을 최소화하거나 제어해야 하는 HPSE의 요구 사항과도 충돌합니다.

R3F(React Three Fiber)와 같은 라이브러리를 사용하면 "HTML Element Like" 구문을 사용하여 Mesh 또는 Scene과 같은 인스턴스를 생성할 수 있지만 이는 단순히 React의 구조에 적용된 Three.js일 뿐입니다. React 내의 높은 수준의 결합은 수정 불가능한 내부 문제를 악화시킬 뿐입니다.

React의 이벤트 처리 접근 방식에도 문제가 있습니다. React는 이벤트 처리의 브라우저 호환성과 일관성을 보장하기 위해 합성 이벤트 시스템을 사용합니다. 그러나 이벤트 처리에 추상화 계층을 추가함으로써 이 시스템은 HPSE에 필요한 이벤트 루프 및 타이밍에 대한 세밀한 제어를 제한하여 필수 최적화 구현을 어렵게 만듭니다.

이러한 문제는 React의 디자인 철학이 HPSE의 목표와 근본적으로 다르기 때문에 발생합니다. React는 HPSE를 염두에 두고 구축되지 않았습니다. 이는 표준 웹 클라이언트의 개발을 최적화하도록 설계되었습니다. 만약 React가 HPSE와 비슷한 방향을 추구했다면 그 기능은 엄청나게 달랐을 것이고, 이를 HPSE 개발에 채택한 사례도 있었을 것입니다. 하지만 두 사람의 목표가 너무 다르기 때문에 필연적으로 헤어지게 됩니다.

라우팅이나 useEffect와 같은 React의 모든 것이 나쁘다는 말은 아닙니다. 실제로 이러한 기능의 대부분은 독립형 JavaScript 모듈이나 코드를 사용하여 구현할 수 있습니다. React와 달리 일반 JavaScript 모듈은 프로젝트에 특정 파이프라인이나 규칙을 적용하지 않습니다. 또한 오픈 소스인 경우 필요에 맞게 내부를 수정할 수 있습니다.