React의 장단점

Composite·2023년 8월 17일

JavaScript React js next.js react.js typescript 리액트 스크립트 자바스크립트 타입스크립트 프론트엔드

오늘 한번 리액트 개발자들을 내가 시험하려 들 것이다.
함수 컴포넌트 기준이다. 틀니 달고 클래스 컴포넌트 쓰고 싶지 않다.

장점

자바스크립트를 최대한 사용

너희들, jsx 쓰면서 마크업에다가 Array.prototype.map 같은 거 많이 쓰는 거 안다. 그게 왜인지는 알고서 하는 거라 믿고 있겠다.
어쨌든, 리액트는 스크립트의 기능을 최대한 활용할 수 있다. 그렇기 때문에, 개발자는 코드에 집중이 가능하기 때문에 구조화가 용이하다 하겠다.
Vue와 Svelte 와는 견줄만 한 장점이라 하겠다. (Solid.js 무시하지 마라)

타입스크립트와 궁합도가 최강인 기술

내 개인적인 견해로 봤을 때, 주요 프론트엔드 기술에서 타입스크립트 궁합은 현재 끝판왕이라도 해도 손색이 없다고 하겠다. 오죽했으면 타입스크립트 자체적으로도 JSX 프로세싱을 고려한 설계를 했을까 싶을 정도로 말이지.

유연한 컴포넌트 정의

뷰와 스벨트는 1파일당 하나의 컴포넌트만 정의가 가능하며(단, Vue도 jsx 방식 쓰면 리액트처럼 쌉가능)
앵귤러는 1파일에 여러 컴포넌트 정의가 가능하지만 module 에 캡슐화 해야 한다.
하지만 리액트는 컴포넌트 정의만 하면 땡이다. 이 얼마나 간편한가.
export 문이 있고 없고로 접근자처럼 지정이 가능하고, 있는 컴포넌트 가지고 마개조까지 가능한 유연함을 제공하고 있다.

엄격하기 때문에 신뢰성이 가는 JSX 특유의 마크업 구조

JSX가 js + xml 구조를 따르기 때문에 당연히 XML 마크업에 용이하지만, 어자피 리액트에서 순수 XML 마크업을 쓸 일은... 리액트 네이티브가 있겠다. 보통이야 HTML 쓰잖아.
즉, 내가 이 리액트로 개발하면서 처음 느낀 점이 바로 XHTML의 부활같은 느낌이었다.
어이 너희 리액트 개발자들, XHTML 표준 준수하면서 마크업 해봤냐? 안해봤으면 말을 말어. 예끼.
어쨌든, 엄격한 구조의 마크업으로 기존 HTML에서 범했던 마크업 실수를 줄일 수 있는 점은 장점으로 작용한다. 왜냐? XML 기반의 마크업 환경이니까.

풍부한 생태계

리액트는 인기를 과시하듯 많은 기반 생태계가 구축되어 있어 웹 앱에 필요한 왠만한 컴포넌트를 갖다 쓸 수 있다.
혹시 뭔가 필요한가? 찾아봐라. 디자인부터 에디터까지. 기존에 바닐라로 제공하던 라이브러리와 프레임워크도 공식이든 커뮤니티든 리액트까지 챙겨주는 이 감격스런 생태계를 보라!

서버 컴포넌트를 통한 미래의 앞선 기술 약속

음... 단점에서 한계를 얘기할 건데, 일단 장점부터 써야 하니 그건 후술하고...
서버 컴포넌트는 앞으로의 미래를 약속하는 기술이라고 내가 감히 자부할 수 있는데,
이런 개발자도 있다. 서버단을 함부로 자바스크립트가 넘보는게 좀 별로라는 의견도 있는데, 자바스크립트가 발랑까진언어인 점을 생각하면 그 생각은 버리도록 하자.
왜 서버 컴포넌트냐,

공개하면 안되는 정보를 통한 통신이 용이해진다. 특히 API를 사용할 때, 공개하면 안되는 보안 키를 사용해야 하는 API를 사용하여 컴포넌트를 바로 렌더링할 수 있게 된다.
여태까지 우리가 주로 사용했던 프론트엔드를 넘어, 다른 유형의 정보 교환(꼭 XML이 아니더라도)이 가능해진다. 렌더링 결과물은 서버 컴포넌트가 이미 변환한 뒤의 결과를 뿌리기 때문에, 클라이언트 입장에서는 결과물을 받을 때에 대한 이질감이 전혀 없다.
서버 컴포넌트는 현재 stateless 를 지향하고 있기 때문에, 비동기 구문을 아무렇지도 않게 사용할 수 있는 장점을 가지고 있지만 useId 외 훅을 사용할 수 없는 리액트스럽지 않은(?) 단점을 가지고 있다. 여기에 리액트가 열심히 안정화하고 있는 use 함수가 공식 채택된다면, 이 원시적인 훅 함수는 useId 와 같이 서버단 컴포넌트에서도 사용 가능하며, 비동기를 직접적으로도 지원하기 때문에, 클라이언트에서도, 서버단에서도 더 강력한 컴포넌트 관리를 기대할 수 있다.

유난히 길지? 내가 리액트를 쓰는 가장 큰 이유다.

단점

스타일링의 어려움

리액트의 대표적으로 꼽는 단점이기도 하며,
리액트 입문을 좌절하게 만드는 초보 개발자들의 고충 남바완.
리액트에서 스타일링을 하는 방법은 여러가지가 있는데, 대충 나열하도록 하겠다.

style 객체 사용 (공식에서도 커뮤니티에서도 추천하지 않는 방법)
module css 사용 (React 공식 지원)
아싸리 공통 css 사용 (React 공식 지원, 디자인 및 퍼블리시에 인기)
emotion, styled 같은 모듈화된 스타일 사용 (전통적인 개발자 인기)
tailwindcss 같은 유틸리티 스타일 사용 (서버 컴포넌트 등장으로 인기 상승 중)

어자피 마크업 한계와 보안 등 여러 요소들을 챙겨야 하는 리액트 특성에 의한 "의도한 한계"이기도 하기에, 디자이너나 퍼블려서 입장에서 리액트 접근이 어려운 큰 요소로 작용하고 있다.

하지만 이 관문을 타파하면, 리액트만의 컴포넌트 매력에 푹 빠진 개발자 자신을 발견할 것이다.

이에 빈해, 뷰와 스벨트는 스타일링을 자체적으로 마크업 상에서 지원하는 점이 접근성이 쉬워진 주요 요인인데, 대신 독자적인 포멧 구축으로 도구에 플러그인이 없을 때 매으 불편하다.

뚝심 없는 컴포넌트, 그 원흉인 훅

redux 같은 전역 상태관리를 쓰거나, zustand 같이 context 없어도 가능한 좀 더 유연한 상태 관리 프레임워크를 쓰는 이유를 알고 있다면 이미 넌 그 단점에 대해 인지를 하고 있는 개발자라 말하고 싶었다.
기본적으로 함수 컴포넌트는 상태가 바뀌었다 싶으면 함수를 갈아엎는다. 일단 이 특성으로 개발자들은 자바스크립트 문법을 자유롭게 작성하는 혜택을 주었지만, 불변성은 이미 개나 줘버린 며느리도 모르는 컴포넌트라 하겠다.
그리고, 훅은 컴포넌트 내에서만 쓸 수 있으며, if 문에서도 사용할 수 없는 여러 까탈스러움이 묻어나는 핵심 기능이다.
훅은 생각보다 비용이 매우 비싸다. 훅의 남용은, 성능과 상태관리의 정확도까지 떨어뜨리는 중구난방 컴포넌트를 불러 일으킨다.
리액트로 개발하다 보면 엉뚱한 렌더링 결과 때문에 고생한 적이 없는 개발자는 아마 없을 것이다.
훅 자체적으로는 비동기로 동작하지만, 비동기를 지원하지 않는 이기적인 놈이 훅이다.
물론 비동기라는 불확실성보다는 낫겠지만, 만약 use 함수 RFC를 본 적이 있다면, 의문을 품을 수밖에 없을 것이다. 대체 리액트는 자바스크립트로 만들었으면서 자바스크립트를 신뢰하지 않는 게 아닌가 하는 의구심이 말이지.
이게 은근 큰 문제라 Preact 와 Solid 가 태어나게 한 원흉으로 지목받고 있으며, 자세한 기술적인 내용은 Preact와 Solid 개발자가 쓴 글을 번역한 고마운 분이 있으니 보도록 하라.

안드로메다급 웹 컴포넌트 표준 호환성

리액트가 지금은 MIT지만, 페이스북은 리액트를 상품화하려는 시도를 했었다. 독자적 생태계와 환경으로 일단은 오픈으로 풀어 새로운 패러다임을 마음껏 즐겨서 언젠가는 통수칠 기회를... 븅신들이 오픈소스 참여자가 바보들인 줄 아나... 이건 다행이라 하겠다.
이런 합리적 의심(??)이 들게 할 정도로 웹 컴포넌트 표준과는 거리가 안드로메다라 하겠다.
게다가 웹 컴포넌트 중심의 라이브러리나 프레임워크를 리액트에서 바로 갖다 쓰는건 불가능하기 때문에 이걸 또 리액트에 맞춰서 배포해야 한다. 물론 반대로도 안 되고.
오히려 뷰와 스벨트, 그리고 Lit 등의 몇몇 프론트엔드는 웹 컴포넌트 호환성과의 배려를 해준 대표적인 프론트엔드 기술이다.
못믿겠으면 공식 문서 봐라 - Vue와 웹 컴포넌트
다행히도 리액트 팀은 이미 인지를 하고 있었고, 웹 컴포넌트와의 호환성을 챙기려 노력하고 있으며, 지금은 실험적 단계지만 이 문서를 보고 기대를 해도 좋을 것 같긴 하다 - Custom HTML elements

무겁고 느린 실행환경

확실히 리액트의 생태계는 풍부하지만, 필요한 생태계를 최소한으로 담을 만한 환경은 아니다. 가뜩이나 리액트 자체부터가 무거운데, 여기에 개발에 필요한 스타일링, 부가적인 상태관리, 그리고 필요한 이것저것 컴포넌트를 설치하다 보면 무슨 일렉트론 급의 빌드 산출물이 나온다.
무겁다? 곧 느리다. 초기화도 느린데, SSR은 상호검증 과정까지 더해지니 새로고침급의 페이지 이동은 천하의 next.js 라도 페이지 불러오는 과정에서 비명을 지른다.
따라서 컨텐츠 중심의 웹 앱을 리액트로 만든다먼, 나는 당장 말리고 뷰보단 스벨트를 추천하고 싶어진다. 렌더링 빈도가 적은 웹 앱에 리액트는 사치다.

이글을 쓴 이유

자바를 찬양하는 개발자 보는것도 소름돋는데 리액트 찬양하는 개발자도 점점 눈에 띄니까 더욱 소름돋는다.
어쨌든 특정 기술을 찬양하는 개발자는 믿고 거르는 개발자라 하겠다.
어떤 기술이든 혜택과 한계를 알고 가는 개발자들은 그 기술을 더 가지고 놀 줄 안다.
왜냐, 되기 때문에 향상시킬 수 있으며, 안되기 때문에 보완할 수 있으니까.
하지만 맹목적으로 찬양하는 개발자 치고 해당 기술을 우수하게 활용한 사례는... 내 경험상 본 적이 없었다. 특히 자바 개발자들. 특히나.

첨언하여. 사실 비동기 지원에 대해서도 너무 불친절해서 단점으로 넣고 싶긴 했었다.
하지만 이 단점이 애매한게, 데이터 등록을 위한(Mutation) 비동기 처리에 대해서는 그다지 불편한 건 없다.
그냥 이벤트 함수나 useEffect 콜백에다가 넣어도 되니까.
문제는 데이터를 가져올 때인데, 에휴... 니네들 react-query 왜 쓰고, react-query 에서 애꿏은 키가 왜 필요한지...
swr 또한 마찬가지고, 아직도 <Suspense> 지원이 실험적 단계인지... 대체 왜인지...
이 점에서 Next.js 의 서버 컴포넌트 도입은 신의 한수긴 하다. 하지만 앱라우터 함부로 접근하면 큰 코다친다.
그 이유는 시간 나면 나중에 따로 설명하기도 전에 이미 뭐 앱라우터 삽질기 검색 해도 좌르륵 나오네. 이놈의 인기란...

끗.

Composite

지옥에서 온 개발자

이전 포스트

"저같은 초짜가 기술블로그 작성해도 되나요?"

다음 포스트

React 상태관리의 구세주, Poimandres 모임.

2개의 댓글

happy

2023년 8월 17일

유익한 글이었습니다.

답글 달기

shenbo

2024년 9월 12일

답글 달기