'고성능 웹 앱' 또는 '프런트엔드'란 정확히 무엇인가요?

Internet Explorer 시대가 쇠퇴한 이후 JavaScript 생태계는 점점 더 강력해졌고 "프런트엔드"라는 용어는 고성능 최신 웹 클라이언트와 동의어가 되었습니다. 이 "프론트엔드" 세계의 핵심에는 React가 있습니다. 실제로 프론트엔드 개발에 React를 사용하지 않으면 이상치처럼 보일 때가 많습니다.

그러나 모든 게임이 AAA인 것은 아니듯이 웹 앱을 논의할 때 "고성능"이 무엇을 의미하는지 신중하게 고려해야 합니다. 이러한 구별은 오늘의 주제에 매우 중요합니다.

1. 고성능 웹 앱의 범위

대부분의 경우 "고성능 웹 앱"이라는 용어는 React, Vue 또는 Angular와 같은 JavaScript 기반 프레임워크를 사용하여 구축된 대화형 동적 웹 클라이언트를 의미합니다. 이러한 앱은 일반적으로 빠른 로드 시간과 클라이언트 측 라우팅을 자랑하며, React의 가상 DOM은 렌더링 속도를 향상시키는 데 중요한 역할을 합니다.

그러나 WASM 모듈의 메모리 한도인 4GB를 모두 활용하고 체계적인 메모리 관리를 염두에 두고 구축되었으며 Blender나 3Ds Max와 같은 기본 프로그램과 동등한 성능을 목표로 하는 웹 앱이 있습니다. 이러한 앱은 SEO에 최적화된 기존의 "웹 페이지"보다는 브라우저 탭의 모든 리소스를 활용하는 "프로그램" 개념에 더 부합합니다.

현재 브라우저 환경은 여전히 ​​메모리 제한과 오버헤드로 인해 기본과 유사한 성능을 제공하는 데 어려움을 겪을 수 있지만 이러한 앱의 목표는 근본적으로 다릅니다. 그들은 대규모 데이터 세트를 처리하고 2~4GB의 전체 메모리를 사용하는 동시에 가장 높은 렌더링 속도를 추구하는 것을 목표로 합니다.

이러한 유형의 웹 앱이 직면한 문제가 일반적인 "고성능" 앱이 직면한 문제와 다르기 때문에 그들이 추구하는 방향도 다릅니다.

처음에 언급한 "고성능 웹 앱"과 여기서 설명하는 앱은 근본적으로 그 경로가 다릅니다. 이들을 단일 용어로 묶는 것은 문제가 될 수 있습니다. 이러한 차이점을 반영하려면 다른 용어가 필요합니다.

이것이 바로 후자를 "고성능 웹 앱" 또는 "프런트엔드"라고 언급하는 것을 중단하고 대신 다음 용어를 사용하도록 제안하는 이유입니다.

• 브라우저 기반 고성능 프레임워크 엔지니어링(BBHPFE)
• (브라우저 기반) 고성능 시스템 엔지니어링(HPSE)

저는 이 용어가 프런트엔드와 HPSE 간의 요구 사항 차이를 명확하게 정의한다고 믿습니다. 모든 브라우저 기반 클라이언트가 프런트엔드인 것은 아닙니다. 일부는 HPSE입니다. 이러한 구별이 중요한 이유를 이해하려면 다음 예를 고려하십시오.

[대화 1]

A: "프론트엔드 앱을 개발하고 있지만 React를 사용하고 있지는 않습니다."
B: "React가 없는 프런트엔드 앱? React는 프런트엔드 시장 점유율이 60%가 넘습니다. 왜 사용하지 않겠습니까?"

[대화 2]

A: "HPSE 앱을 개발 중이지만 React를 사용하고 있지 않습니다."
B: "HPSE에는 맞는 말입니다. 게임 회사는 종종 엔진을 광범위하게 사용자 정의하지만 React의 내부 기능과 렌더링 파이프라인은 수정할 수 없습니다. 그런 목적으로 설계된 적이 없습니다."

이제 HPSE가 갖춰야 할 필수 구성요소에 대해 살펴보겠습니다.

2-1. 메모리 관리
메모리를 다루지 않고서는 고성능 프로그램을 논할 수 없습니다. 가비지 수집기를 사용하든 동적으로 할당된 메모리를 수동으로 해제하든 사용되지 않은 메모리는 항상 해제되어야 합니다.

플레이어가 새 지도로 이동하는 브라우저 기반 게임을 생각해 보세요. 게임은 서버에서 비동기식으로 새 지도 데이터를 가져와서 새 메시를 생성하고 이전 메시를 제거해야 합니다. 이전 메시를 생성하는 데 사용된 데이터도 해제해야 합니다.

이전 데이터에 대한 참조가 제대로 해제되지 않으면 맵이 전환될 때마다 메모리 사용량이 계속 증가합니다. 약 2GB에 도달하면 "메모리 부족" 오류가 발생할 수 있으며 브라우저가 충돌합니다.

JavaScript가 낮은 수준의 메모리 제어를 위해 설계되지 않은 것은 사실입니다. 언어나 개발자의 철학 모두 이를 우선시하지 않습니다. 메모리 관리가 항상 중요하다는 말은 아니지만, "공짜 점심 같은 건 없다"는 말이 있습니다. 메모리 관리가 필요하다면 반드시 해줘야 합니다.

2-2. 요구 사항 충족의 유연성
누군가가 "주니어 개발자에서 중급 개발자로 이동할 때쯤에는 요청하는 모든 것을 구축할 수 있을 것입니다."라고 말하는 것을 들은 적이 있습니다.

JavaScript는 이미 고유한 제한(메모리 제한 제외)이 거의 없는 인상적인 언어입니다. 무언가를 만들고 싶다면 아마도 이루어질 수 있을 것입니다.

진짜 질문은 현재 프로젝트가 실제로 다양한 요구 사항을 수용할 수 있는지 여부입니다.

공장의 기계가 계속 작동하다 고장이 나듯이, 고성능, 맞춤형 기능을 추구하다 보면 예상치 못한 난제에 부딪힐 수밖에 없습니다. 이런 일이 발생하면 고유한 요구 사항을 충족할 수 있는 유연성과 능력이 필수적입니다.

예를 들어, 로스트아크가 언리얼 엔진 3를 기반으로 제작됐다는 소식을 들어보신 적이 있나요? 언리얼 엔진 5가 출시되었지만 그들은 여전히 ​​2004년에 제작된 언리얼 엔진 3를 사용하고 있습니다. 지금까지 프로젝트를 유지하려면 엔진을 대대적으로 수정해야 했습니다. 사실상 완전한 점검이 필요했습니다. 게임의 특성으로 인해 성능 및 미적 요구 사항을 충족하기 위해 지연 렌더링, 인스턴싱, 컬링 및 화면 공간 반사와 같은 기술을 사용하여 렌더링 파이프라인과 루프를 지속적으로 맞춤화해야 했습니다.

엔진의 소스 코드를 수정하는 기능이 매우 중요했습니다. 엔진이 닫혀 있거나 개조가 불가능할 정도로 너무 단단하게 결합되어 있었다면 로스트아크는 결코 개발되지 않았을 수도 있습니다.

HPSE도 마찬가지입니다. 환경은 브라우저 기반으로 바뀌었지만, 맞춤형 기능과 유연한 수정에 대한 필요성은 그대로입니다. 따라서 HPSE에 사용되는 라이브러리와 외부 모듈은 수정 가능해야 하며, 브라우저의 렌더링 파이프라인이나 내부 모듈 결합이 너무 경직되어 이러한 변경을 허용할 수 없는 경우 심각한 문제가 됩니다.

2-3. 필연적인 객체지향 접근 방식
대규모 프로그램을 다룰 때 피할 수 없는 한 가지가 바로 객체지향 프로그래밍(OOP)입니다.

자바스크립트는 다중 패러다임 언어이며, 함수형 프로그래밍(FP)이 널리 사용됩니다. 그러나 FP는 웹 클라이언트에 적합하지만 FP의 인스턴스에는 내부 상태가 부족하기 때문에 여러 객체가 복잡한 방식으로 상호 작용하는 대규모 프로그램에서는 거의 사용되지 않습니다.

React는 전역 상태 관리 및 useEffect로 이를 보완하지만, 각 인스턴스가 자체 상태를 유지하고 공개 메서드를 통해 메서드 호출을 제어하는 ​​것만큼 직관적이지는 않습니다.

OOP가 항상 최선의 선택은 아니지만 HPSE의 고도로 맞춤화된 개발 요구 사항을 고려할 때 더 나은 대안을 생각하기는 어렵습니다. 운영 체제 및 게임을 포함한 많은 대규모 프로그램은 OOP 원칙을 사용하여 구축됩니다. 가장 널리 사용되는 엔진 소스도 객체 지향적이며 방법론이 약간 다릅니다.

대규모 프로젝트에 참여한 개발자라면 OOP에 익숙할 것입니다. 이는 OOP 기반 개발이 협업에 도움이 되도록 만듭니다.

그렇다고 해서 JavaScript의 장점을 버릴 필요는 없습니다. JavaScript는 함수와 const 선언을 지원하므로 인스턴스가 필요하지 않은 간단한 모듈 함수는 const 또는 함수를 사용하여 객체 리터럴로 정의할 수 있습니다. 이를 통해 생산성을 높이고 JavaScript의 다양성을 활용할 수 있습니다.

결론적으로, 객체지향 원칙을 통합한 다중 패러다임 접근 방식이 HPSE에 이상적이라고 생각합니다.