GN⁺: 리액트가 아니라면, 무엇을 사용할까?

(infrequently.org)

11P by neo 3일전 | favorite | 댓글 11개

"Frameworkism(프레임워크주의)는 더 이상 통하지 않음. 해답은 다른 도구가 아니라 엔지니어링을 할 수 있는 용기"

지난 10년 동안, 데스크톱과 모바일 웹을 위한 다양한 제품과 기술 스택을 통해 100개 이상의 프로젝트를 경험
많은 시간은 웹 API 개선보다 리액트와 같은 프론트엔드 프레임워크가 초래한 성능 및 접근성 문제를 해결하는 데 사용
React는 이미 레거시 기술임에도 불구하고 여전히 신규 프로젝트에서 채택되고 있음
React를 "현대적"이라고 주장하는 사람도 있지만, 이는 과거의 방법을 되풀이하는 것에 불과함

최소한의 클라이언트 측 복잡성 규칙

서버 측 코드는 개발자가 제어 가능하며, 성능과 가용성을 효과적으로 관리할 수 있음
클라이언트 측 코드는 개발자가 제어할 수 없는 다양한 환경에서 실행되어, 안정성과 성능을 보장하기 어려움
최선의 전략은 클라이언트에 보내는 코드 양을 줄이는 것
- HTML과 CSS를 우선 사용해 자바스크립트 의존도를 최소화
- 리액트 및 유사 프레임워크는 불필요한 코드 중복 및 성능 저하 문제를 야기

그렇다면, 대안은 무엇인가?

두 가지 질문으로 나눠지는 논의

좁은 질문: "클라이언트 렌더링이 필요할 경우, 리액트를 대신할 기술은 무엇인가?"
- 현대적인 프레임워크(예: Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil 등)를 고려할 가치가 있음
- 다만, 이들 프레임워크를 사용할 때도 클라이언트 측 페이로드와 복잡성을 엄격히 관리해야 함. 자바스크립트는 HTML/CSS에 비해 최소 3배 이상 비용이 큼
넓은 질문: "리액트에 의존한 기술 스택을 전면적으로 재검토하려면 어떻게 해야 하는가?"
- 단순히 새로운 도구로 대체하는 것이 아니라, 기존 아키텍처의 목적과 한계를 이해하고 재설계해야 함

좁은 질문에 대한 접근법

소규모 PoC(Proof of Concept)를 여러 개 만들어 성능 확장성과 한계를 평가
이러한 객관적인 실험은 팀원들에게 의미 있는 엔지니어링 경험을 제공

넓은 질문을 던지는 팀의 공통적 상황

리액트를 대체하려는 논의에서 혼란스러움을 느끼는 경우가 많음
- 기존 아키텍처를 따라가는 방식으로 결정을 내린 경우가 대부분
- 사용자 경험에 대한 명확한 이해와 데이터 기반의 의사결정 부재

프레임워크주의와 사용자 중심 접근의 차이

프레임워크주의: 프레임워크에 더 많은 기능을 추가하면 모든 문제가 해결될 것이라는 믿음
- 실제로는 사용자 문제를 해결하지 못하는 경우가 많음
- 비정형적인 패턴이나 데이터 중심의 증거를 무시
현실주의: 사용자 경험을 측정하고 실제 데이터에 기반한 결정을 내림
- 사용자의 요구와 제한 조건을 이해하고 이를 기반으로 기술 스택 설계
- 시작점은 항상 사용자 요구

현실주의를 도입하는 방법

RUM 데이터 활용: Core Web Vitals와 같은 사용자 중심 성능 지표를 사용
성능 테스트: WebPageTest(WPT)와 같은 툴을 활용해 주요 사용자 경로(critical user journeys)를 측정
비즈니스 목표와 사용자 경험을 연계: 데이터를 통해 개선 방향과 투자 대비 효과를 평가

데이터 기반 접근의 중요성

프레임워크를 신뢰에 기반해 채택하는 대신, 데이터로 그 효과를 검증
유행에 따른 기술 채택의 실제 비용과 효과를 비교
측정 가능한 지표를 통해 사용자 경험 최적화에 중점을 둔 기술 선택을 장려

가치 있는 것은 하나도 손실되지 않았다

리액트의 확산을 막는 정책의 효과

리액트 및 다른 프레임워크 중심 접근법을 금지하는 것은 비용 절감과 사용자 중심 팀 재조정에 기여
하지만, 프레임워크주의를 완전히 배제하지 않으면 근본적인 성과 개선은 어려움
한 가지 실수를 피하더라도 같은 범주의 다른 실수에 투자한다면 효과는 제한적

넓은 문제에 대한 일반적인 해결책

사용자 중심

의사결정자는 자신들의 엔지니어링 선택 결과에 직접적으로 책임을 져야 함
변명의 여지 없이, 시스템이 사용자(특히 소외된 사용자)에게 잘 작동하지 않는다면 대체 버전을 도입
해결해야 할 문제만 존재하며, 기존 방식을 무조건 고수하는 "성역화"는 배제

증거 기반 접근

경영진과 엔지니어링 간 공유된 현실주의 헌신이 필요
의사결정에서 더 나은 증거가 항상 우위를 가져야 함

보호 장치

프레임워크주의의 환상적 주장을 방지하기 위한 정책 필요
예: 영국 정부 디지털 서비스의 점진적 향상 기술 요구사항
- 조직 상황에 따라 정책을 조정 가능(예: 예외 상황의 에스컬레이션 경로 생성)
- 그러나 중요한 것은 명확한 기준 설정. 증거 기반 정책은 강력한 영향력을 발휘

기술 비교 평가

명확히 정의된 주요 사용자 경로(critical user journeys) 없이 새로운 시스템을 배포하지 말 것
주요 사용자 경로는 시스템에서 사용자들이 가장 자주 수행할 작업을 나타냄
이를 바탕으로 각 기술의 성과를 제한 조건 하에서 테스트하는 비교 평가(bakeoffs) 실시
- 제품 관리자는 실험만 무작정 제안하는 것을 넘어서 제품의 명확한 가설을 정의하고 성공의 기준을 설정해야 함
- 이는 불편한 과정일 수 있지만, 제품 관리자의 핵심 역할
- 자신의 업무와 맞지 않다고 판단하는 PM의 사직은 감내

사례 연구

현실주의와 프레임워크주의의 차이점: 사례를 통해 이해

기술 선택 기준
- 기술 선택은 주요 데이터 업데이트 수와 세션 길이를 기준으로 평가
- 일부 앱 클래스는 긴 세션과 빈번한 데이터 업데이트를 특징으로 함
  - 이 경우, 로컬 데이터 모델이 적합할 수 있음
  - 하지만 이는 드문 예외적인 상황에 해당
짧은 세션의 경우
- 평균 세션 시간이 짧은 사이트는 초기 자바스크립트 로드량을 최소화해야 함
- 대부분의 사이트는 SPA 아키텍처를 요구하지 않음
SPA 아키텍처가 필요한 경우
- SPA 아키텍처는 특정 조건을 충족할 때만 고려해야 함
  - 세션이 길고, 동일 데이터에 대한 여러 번의 업데이트가 필요한 경우
- 이 조건을 충족하지 않는 사이트는 SPA를 채택해서는 안 됨
핵심 질문
- 선택은 자바스크립트 프레임워크 간의 문제가 아님
- 대부분의 경우, SPA 지향 도구 자체를 사용하는 것이 적절한지 여부를 판단하는 것이 핵심
- 대부분의 사이트에서는 명확히 **"아니다"**라는 답이 나옴

정보 제공형 웹사이트 (Informational)

최적의 구조: 의미론적 HTML과 필요 시 점진적 향상(Progressive Enhancement)을 활용
정적 사이트 생성기(Hugo, Astro, 11ty, Jekyll)가 적합
빈번히 업데이트되는 콘텐츠는 WordPress와 같은 CMS 도구를 사용
블로그, 마케팅 사이트, 회사 홈페이지, 공공 정보 사이트는 클라이언트 자바스크립트 페이로드를 최대한 줄여야 함
SPA 아키텍처를 위해 설계된 프레임워크를 사용하지 않아야 함
왜 의미론적 마크업과 점진적 향상이 적합한가?
- 짧은 세션과 서버 소유 데이터 모델이 특징
  - 페이지에 표시되는 데이터의 원본은 항상 서버에서 관리
  - 클라이언트 데이터 모델 추상화나 컴포넌트 정의 불필요
- CMS 구성:
  - 저작자를 위한 저트래픽, 고상호작용 편집기
  - 독자를 위한 고트래픽, 저상호작용 뷰어 UI

전자상거래 (E-Commerce)

추천 아키텍처: 서버 생성 의미론적 HTML 및 점진적 향상
아마존 대비 React 기반 경쟁사의 성능 격차가 명확
- Walmart 트래픽의 70% 이상이 모바일에서 발생, SPA 기반의 Next.js는 비즈니스에 부정적 영향
점진적 향상이 적합한 이유
- 전자상거래의 일반적 구조:
  - 현재 제공 중인 제품과 검색 기능을 포함한 랜딩 페이지
  - 필터 및 비교 기능을 지원하는 검색 결과 페이지
  - 제품 상세 페이지: 미디어, 리뷰, 추천 대안 포함
  - 장바구니 관리, 결제, 계정 관리 화면
- 서버 소유 상태:
  - 신선한 콘텐츠(예: 가격) 유지
  - 경량 페이지 최적화를 통해 지연 시간 감소
  - 공격적 캐싱, 이미지 최적화, 페이지 크기 감소 전략 사용

미디어 소비형 웹사이트 (Media)

기본 구조: 점진적 향상을 기반으로 설계
- 필요 시 제품 변화에 따라 복잡성 추가
점진적 향상과 섬(Islands) 구조가 적합한 이유
- 댓글 스레드와 같은 대화형 요소는 독립적 데이터 모델로 구성 가능
- Web Components를 활용하여 정적 페이지 내에 구현 가능
SPA가 적합한 경우
- 미디어 플레이백 지속성:
  - 페이지 탐색 중 미니 플레이어 유지가 필요
  - SPA 기술 사용과 클라이언트 JS 크기 제한 관리
- 오프라인 재생 지원:
  - 로컬 미디어 캐시를 관리하는 로직 필요
  - Zero, Y.js 같은 데이터 동기화 시스템 고려

소셜 미디어 (Social)

하이브리드 모델: 서버 소유 데이터 모델 기반의 적은 상호작용 + 간헐적 미디어 업데이트
점진적 향상이 적합한 이유
- 일반적 상호작용:
  - "좋아요" 클릭, 간헐적 업데이트 등
  - Hotwire 또는 HTMX를 사용한 하이브리드 방식이 적합
SPA가 적합한 경우
- 깊은 상호작용 섬:
  - 드래프트 포스트 저장 등 클라이언트 캐싱 활용
- 오프라인 지원:
  - HTML을 우선 전달하되 Service Worker를 통한 동기화 및 오프라인 로직 구현

생산성 앱 (Productivity)

문서 중심 생산성 앱은 복잡한 요구사항(협업 편집, 오프라인 지원, 경량 보기 모드)을 가짐
로컬 데이터 모델과 SPA 기반 아키텍처가 적합할 수 있음
SPA가 적합한 이유
- 빈번한 데이터 업데이트:
  - 키 입력, 마우스 드래그와 같은 작업에서 클라이언트 로직이 우위를 가짐
- 성능 제약 관리 필요:
  - 초기 번들 크기 관리
  - 지연된 패키지 로딩 전략 적용

기타 애플리케이션 클래스 (Other Application Classes)

특정 요구사항:
- 3D CAD, 프로그래밍 에디터, 게임 스트리밍, 웹 기반 게임, 미디어 편집, 음악 제작 시스템 등
- 각 앱 클래스는 생산성 앱과 동일한 방식으로 신중히 평가 필요
성공 요건:
- 주요 사용자 경로 정의
- 평균 세션 깊이 분석
- 성능 보장 지표 설정
- 핵심 스크립트 및 리소스 제어

엔터프라이즈 소프트웨어에 대한 한마디

"기업 비즈니스 앱"은 일반적으로 최악의 성능 문제를 초래
- 대시보드, 워크플로 시스템, 기업용 채팅 앱 등이 대표적
성능이 문화임:
- 초기 로딩 시간과 상호작용 이후 성능 정의 및 측정 실패
- 사용자를 무시하는 개발자 중심 문화가 독이 됨

"하지만…"

React를 포함한 특정 프레임워크에 얽매인 관리자는 종종 이러한 선택을 합리화하기 위해 다양한 논리를 펼침
하지만 이 논의들은 사용자 경험을 중심에 두지 않으며, 이러한 결여는 반복적으로 나타남.

"...우리는 빨리 움직여야 해요"

질문: "그게 얼마나 오래 갈 거라고 보나요?"
빠르게 개발한 NPM 기반 프로젝트는 접근성 문제, 저성능, 복잡성 증가를 초래하며, 결과적으로 속도는 감소.
리메디에이션 비용: JavaScript 문제 해결에 수개월 소요되며, 기능 출시 속도는 더욱 감소.
제품 시장 적합성(Product-Market Fit)을 위해선 접근성과 품질을 우선해야 함.
React를 사용해 "빠르게 움직이자"는 선택은 장기적으로 비용이 더 많이 들며 성장을 방해.

"...페이스북에서 잘 쓰고 있잖아요"

대부분의 기업은 페이스북과 같은 문제를 직면하지 않음.
Facebook도 React 사용으로 인한 성능 문제를 겪음, 하지만 독점적 지위를 통해 문제를 덮음.
일반 기업은 Facebook의 사례를 무작정 따라가면 안 됨.

"...우리 팀이 React를 이미 알고 있어요"

React 개발자는 웹 개발자임. CSS, HTML, JavaScript, DOM 작업은 필수.
React는 기술 스택에서 대체 가능한 가장 단순한 계층.
Preact, Svelte, Lit, FAST 등 더 작고 빠른 프레임워크를 배우는 데 큰 장벽이 없음.

"...채용이 쉬워야 해요"

현재 IT 업계는 우수한 개발자를 채용할 수 있는 절호의 기회.
React 지식은 채용의 기준이 될 수 없음.
React를 아는 개발자는 대부분 웹 표준도 쉽게 학습 가능.
오히려 더 단순한 시스템이 높은 ROI를 제공.

"...모두가 빠른 휴대폰을 쓰잖아요"

모바일 사용이 늘어난 지난 10년간, 클라이언트 리소스가 싸다는 전제는 이미 잘못된 가정.
성능이 낮은 휴대폰 사용자도 제품의 주요 고객일 가능성 큼.
React를 선택함으로써 모든 사용자가 고가의 디바이스를 사용한다고 가정하는 건 위험.

"...React가 업계 표준이에요"

React는 일관된 표준이 아님.
- React 자체의 방식(클래스 컴포넌트 vs 함수형 컴포넌트), 타입스크립트 사용 여부, 상태 관리 도구 선택 등 매 프로젝트마다 달라짐.
React 스택은 항상 변동적이며, "표준"이라는 주장은 편안한 허구에 불과.

"...에코시스템…"

React와만 호환되는 라이브러리가 매우 드물며, 대부분의 도구는 Preact 등에서도 사용 가능.
모든 NPM 패키지는 미래에 대한 기술적 부채로 작용.
CSS-in-JS와 같은 불필요한 의존성은 비용만 증가.

"...Next.js도 충분히 빨라요"

Next.js는 기본적으로 React의 성능 문제를 함께 가져옴.
HTML 우선 도구(예: Astro, 11ty)가 Next.js보다 더 나은 성능을 제공.
VC 지원 스타트업의 API에 락인되는 문제도 존재.

"...React Native!"

React Native는 모바일 앱을 느리게 만들고 유지 관리에 많은 비용을 요구.
PWA 및 Capacitor/Cordova를 사용하는 것이 더 나은 선택.
페이스북도 React Native에서 벗어나고 있음.

▲

wildmental 1일전 [-]

글이 너무 길어서 주제의식이 흐려져있음

글쓴이는 리액트를 쓰자는 의견을 무조건 프레임워크 주의에서 비롯된 것처럼 생각하는 것으로 보임

프레임워크주의를 벗어나서 케이스별로 접근하자는 말을 하고나서 모든 종류의 엔지니어링 니즈에 대해서 레시피를 만들려고 하고 있음

모든 예상반론에 대해서 다 대답하려는 과도한 대화 점유 시도가 돋보임. 반론에 대한 재반론이 너무 편협함.

즉, 특정 케이스 이상을 넘어서 일반론을 다루는 토론을 수행하기에는 글쓴이가 갖춘 토론 태도와 기술이 매우 부족해보임

그 결과 나는 리액트 사용을 좋아하지 않음에도 글쓴이의 일방적인 태도만으로 리액트 사용을 주장하는 사람들의 생각을 조금 더 들어보고 싶게 되었음

답변달기

▲

savvykang 1일전 [-]

일단 개인적으로 현재는 리액트가 최선이라고 생각해서 의견 드립니다

웹개발 입문은 php jquery시절부터, 지금 일하는 회사에서 앵귤러JS, 앵귤러, 클래스 스타일 리액트, 훅 스타일 리액트 경험해본 입장으로는 먼저 써본 사람들의 시행착오와 라이브러리들이 갖춰진 다음에 기술스택을 바꾸는 것이 덜 머리가 아픕니다. 시맨틱 버전으로 따지면 최신버전 보다 하나 아래의 메이저버전을 사용하는 셈이죠. 요구사항과 고수준 기능은 변하지 않으니 문제가 없는데 기반기술에 대한 참고자료가 없으면 생산성이 나오지 않더군요. 또한 저희 회사 프로젝트 특성상 saas 서비스와 다르게 제품 사이클이 길고 메인터넌스만 하는 기간이 존재해서 더더욱이 최신기술을 적용하기가 어려웠습니다

아마 리액트가 Next.js로 방향을 전환해서 SPA 지원을 종료하고 아키텍처 변경을 강제하는 시점에는 기술 전환을 다시 한번 고민해야 할 듯 합니다. Vue가 좀더 많이 보급되어 있으면 후보군에 당연히 올릴거구요. 안 쓸 이유가 없습니다

답변달기

▲

alucard 2일전 [-]

잘 쓰고 있는데 억까 느낌이 없지 않아 있네요..이렇게 장황하게 적어놓으니 뭔가 큰 문제를 직면하게 한 것처럼 느껴라라는 느낌..

답변달기

▲

dalinaum 1일전 [-]

모바일 앱을 RN이 느리게 만든다면서 왜 캐피시티왜 코도바를 추천하죠? Ui라도 네이티브로 보여주는 건 하이브리드 웹 보다 훨씬 성능적으로는 나은 접근이라 봅니다.

답변달기

▲

dalinaum 1일전 [-]

슬프게도 한국 채용시장에서 "프레임워크 주의가 통하지 않는다."면 면접 광탈할 가능성이 매우 높을 겁니다. 많은 면접에서 프레임워크를 많이 써봐야만 아는 질문을 합니다.

답변달기

▲

savvykang 2일전 [-]

새로운 것에 호소하는 사람들이 있는 한 이런 문제는 반복될텐데요. 이미 리액트로 된 시스템이 있기 때문에 채용 문제를 간과해서는 현실이 바뀌지 않을겁니다. 페이스북이 리액트를 밀던 이유와 10년이 지나서 일반 기업에서 리액트를 선택하는 이유에는 차이가 있습니다

아키텍처와 패러다임을 바꾸고자 하는 논의는 이것보단 신중하고 가능한 한 많은 사람을 설득해야 한다고 생각합니다

답변달기

▲

huiya 2일전 [-]

그치만 preact도 react-like고 react 벗어나면 라이브러리 숫자가.....
쓸만한 라이브러리처럼 보이면 다 react 전용인 vue 개발자는 웁니다

답변달기

▲

clastneo 2일전 [-]

RN개발자 광광 우러요

답변달기

▲

clastneo 2일전 [-]

뭐 진지하게 달자면 RN은 js번들로 네이티브 컴포넌트 핸들하게 해주는데에 의미가 있는거라 pwa랑은 유즈케이스가 완전 다르죠.

웹뷰로도 핸들하기 어려운 부분이 있는데 pwa? 장기적으로는 해당 방향으로 이어질거라고는 보지만 지금은 시기상조입니다. 애당초 의미없는 비교를 하고 있단 느낌이네요.

답변달기

▲

bbulbum 14시간전 [-]

맞아요. 본문은 거의 native 앱이 필요없다는 수준의 의견이네요.

답변달기

▲

neo 3일전 [-]

Hacker News 의견

React 사용을 반대하는 이유가 대부분 잘못된 문제를 해결하려는 것이라고 생각함. 성능 문제는 실제로 큰 문제가 아님. 대부분의 경우 백엔드 개선이 더 효과적임
- React가 구식 이벤트 시스템을 사용한다고 비판하지만, 이는 사용자에게 문제를 일으키지 않음. React를 완전히 버릴 이유는 아님
- React 대신 사용할 대안을 제시하지 않아서 논의가 부족함. 대안이 React보다 나쁘다고 생각함
React와 jQuery가 인기를 얻은 이유는 코드가 깔끔하게 보이기 때문임. AngularJS 초기 코드 샘플은 보기 좋지 않음
- React는 jQuery처럼 더 나은 대안이 나오면 대체될 것임. 코드 샘플이 예쁘게 보이는 것이 중요함
React의 핵심은 O(n) UI 상태를 함수형으로 렌더링할 수 있게 해주는 것임. 과거에는 O(n^2) 상태 전환을 관리하는 것이 복잡했음
- React는 이러한 복잡성을 줄여주는 첫 번째 주류 도구였으며, 성공할 만한 가치가 있음
React를 계속 사용하는 이유는 Java처럼 안정적이고 성숙한 기술이기 때문임. 커뮤니티와 리소스가 풍부함
Alex의 글은 반복되는 논쟁에 대한 좌절감을 보여줌. 많은 사람들이 글을 끝까지 읽지 않음
- 웹 성능에 대한 진실을 보지만 아무도 믿지 않는 Cassandra와 같음
React 개발자가 웹 개발자라는 말이 점점 맞지 않게 느껴짐. SPA React와 스타일링 프레임워크에만 익숙한 개발자가 많아짐
- React를 사용하는 이유는 Facebook 때문이며, 많은 사람들이 이를 의심하지 않음
대부분의 사이트는 SPA가 필요하지 않음. 하지만 많은 데이터가 필요한 비즈니스는 SPA가 유리함
- NPM 패키지에 대한 비판이 많지만, 그 이유를 이해하려는 노력이 부족함
- React는 프레임워크가 아닌 뷰 라이브러리임
React를 좋아하지 않음. 주로 백엔드 개발자로서 서버 생성 HTML과 약간의 JavaScript를 선호함
- 새로운 프로젝트에서는 Elixir/Phoenix/LiveView와 HTMX를 고려 중임
프론트엔드 개발이 JavaScript 프레임워크로 이동하는 이유는 유지보수 비용 때문임
- 프론트엔드 빌드가 이미 프로세스에 포함되어 있으면 비용을 절감할 수 있음
- SPA 패턴은 프론트엔드 빌드와 가장 잘 맞음
React에 대한 잘못된 비판이 많음. React 개발자는 새로운 템플릿 언어를 만들지 않고도 작업을 완료함
- 웹사이트가 느린 이유는 React 때문이 아니라 개발자나 예산 부족 때문임

답변달기