[모던 리액트 Deep Dive] 마지막 15장

 

15.1 리액트 프로젝트를 시작할 때 고려해야 할 사항

15.1.1 유지보수 중인 서비스라면 리액트 버전을 최소 16.8.6에서 최대 17.0.2로 올려두자

중요한 대규모 업데이트가 있었전 리액트 16.8버전에 맞춰 라이브러리 등 원활한 지원을 위해 16.8.6이상으로 맞추는 것이 좋다.

또 앞으로 새로운 기능 출시 및 호환성이 깨지는 변경 사항을 최소화하기 위해 17버전으로 가는 것 또한 좋다.

하지만 굳이 클래스 컴포넌트에서 함수 컴포넌트로 변경할 필요는 없다.

 

15.1.2 인터넷 익스플로러 11 지원을 목표한다면 각별히 더 주의를 기한다.

다음은 인터넷 익스플로러 11 을 지원하지 않는 대표적인 라이브러리다.

• 리액트: 리액트는 18버전부터 인터넷 익스플로러 11 을 지원하지 않기로 했다.
• Next.js: Next.js는 13버전부터 공석적으로 인터넷 익스플로러 11 을 지원하지 않기로 했다.
• query-string: 주소의 쿼리 문자열을 다루는 대표적인 라이브러리인 query-string 도 6.x 버전부터 인터넷 익스플로러 11 을 지원하지 않는다.

인터넷 익스플로러 11을 지원히는 애플리케이션은 각별히 라이브러리 설치에 주의 를 기하자. 반드시 사용하고자 하는 라이브러리의 소스코드나 체인지로그， 이슈 등을 살펴보고 문제가 없다고 판단될 때 설치해 사용해야 한다.

 

15.1.3 서버 사이드 렌더링 애플리케이션을 우선적으로 고려한다.

싱글 페이지 애플리케이션에서는 좋은 성능과 최적화 결과를 얻기 어렵다. 대규모 프로젝트 진행 시에는 서버 사이드 렌더링을 고려하는 것이 좋다. Next.js뿐만 아니라 Remix, Shopify에서 만드는 Hydrogen 또한 좋은 대안이 될 수 있다.

 

15.1.4 상태 관리 라이브러리는 꼭 필요할 때만 사용한다.

만약 관리해야 할 상태가 적은, 비교적 정적인 애플리케이션이라면 상태 관리 라이브러리가 굳이 필요하지 않을 수도 있다. 오히려 상태가 적은 애플리케이션에 상태 관리 라이브러리를 추가하는 것은 되려 부자연스러운 프로젝트 구조를 야기할 수 있으며， 쓸데없이 번들링 크기만 키우는 꼴이 될 수 있다.

무작정 상태 관리 라이브러리 하나를 잡고 공부하는 것보다 조금씩 점진적으로 상태와 상태 관리의 필요성을 깨닫는 것이 더 좋다. 이러한 기초적인 이해를 바탕으로 한다면 다른 상태 관리 라이브러리를 쓰더라도 그 핵심 구조를 빠르게 파악하고 더욱 자연스럽게 쓸 수 있게 될 것이다.

 

15.1.5 리액트 의존성 라이브러리 설치를 조심한다.

어떠한 기능 구현을 위해 라이브러리를 설치할 때， 특히 리액트에 의존적인 라이브러리를 설치하려고 히는 경우가 있을 것이다. 이런 라이브러리의 대부분은 react-** 같은 이름을 가지고 있으며， 대부분 다음과 같이 리액트에 대한 의존성을 가지고 있다(react-useportal을 참고했다).

이때 반드시 이 peerDependencies 가 설치하고자 하는 프로젝트의 리액트 버전과 맞는지 확인해야 한다.

 

15.2 언젠가 사라질 수도 있는 리액트

15.2.1 리액트는 그래서 정말 완벽한 라이브러리인가?

 

클래스 컴포넌트에서 함수 컴포넌트로 넘어오면서 느껴지는 혼란

클래스 컴포넌트와 힘수 컴포넌트는 완전히 다른 개념이고， 또한 내부적으로 작동하는 방식도 다르기 때문에 Es6의 클래스에 대한 이해가 부족하다면 이를 완전히 이해하기 어렵다. 리액트에 대한 이해도 부족하고 클래스 컴포넌트와 함수 컴포넌트의 차이도 명확히 모르는 상태에서 하나의 방법론을 선택해야 하는 갈림길에 놓이게 된다. 누군가의 도움으로 요즘은 함수 컴포넌트가 대세니 힘수 컴포넌트와 훅에 대해서만 공부하면 된다고 알게 됐더라도， 왜 이런 변화가 있었는지， 또 클래스 컴포넌트는 알아야 하는 게 아닌지 하는 찝찝함은 남는다.

 

너무 방대한 자유가 주는 혼란

CSS를 적용하는 방식도 다양하고 상태 관리 또한 다양한 옵션이 있다. 뿐만 아니라 데이터를 fetch하는 방법 등 다양한 것들이 파편화돼 있다. 이는 새로운 것을 좋아하는 이들에겐 당기는 요소이지만 새로 배우는 이들에겐 장애물이 될 수도 있다.

프론트엔드 생태계는 빠르고 급진적으로 변화하고 있기 때문에 향후 어떻게 바뀔지 모른다.

 

15.2.2 오픈소스 생태계의 명과 암

 

페이스북 라이선스 이슈

MIT 라이선스는 흔히 볼 수 있는 오픈소스에 많이 쓰이고 있으며, 오픈소스 소프트웨어를 상업적으로 이용하거나, 배포하거나, 개인적으로 이용하는 등 어떠한 제약 없이 소프트웨어를 취급할 수 있는 매우 자유로운 라이선스 중 하나다.

그러나 페이스북은 자사의 오픈소스인 React, Immutable, Jest 등에 이 MIT 라이선스 대신에 BSD+Patents 라이선스를 시용하고 있었다. 이 라이선스는 다른 라이선스와는 다르게 ‘이 라이선스를 적용한 소프트웨어에 대해서 특정한 사건이 발생한다면 라이선스가 통지 없이 종료될 수 있다. ’ 라는 한 가지 눈에 띄는 조항이 있었다.

2017 년 7월， 오픈소스 소프트웨어 프로젝트를 운영한는 아파치 재단에서 BSD+Patents 라이선스를 사용하는 것을 금지한다고 밝혔다. 그리고 이 조항을 사용하고 있는 페이스북에 많은 이목이 쏠리기 시작했다. 그러나 페이스북은 이 조항을 철회할 의사가 없다고 밝혔고 이는 곧 많은 커뮤니티의 찬반 논란을 가져왔다. 이에 전 세계 웹사이트의 25%를 이루고 있는 워드프레스 진영에서 라이선스를 바꾸지 않으면 더 이상 자사 소프트웨어에서 리액트를 사용하지 않을 것이라고 밝혔다. 이러한 격론 끝에 결국 페이스북은 해당 특허권을 삭제하고 MIT 라이선스로 넘어갔다. 아파치 재단과 워드프레스 그리고 많은 개발자들의 관심 덕분에 이 페이스북 라이선스는 한바탕 소동으로 끝났지만 개발지들에게는 자신이 오픈소스로 만든 소프트웨어에 대한 권리를 한순간에 잃어버릴 수도 있다는 경각심을 갖게 하는계기가 됐다.

 

오픈소스는 무료로 계속 제공될 수 있는가? colors.js, faker.js, 그리고 바벨

바벨은 자바스크립트 컴파일러로， 자바스크립트 최신 문법을 지원하지 않는 브라우저에서도 최신 문법을 사용할 수 있도록 자바스크립트를 컴파일해 주는 도구다. 이 바벨을 사용하기 위해 돈을 낸 적은 없다. 2021 년 5 월 재정난을 겪고 있다는 글이 올라왔으며 연간 330 ， 000 달러가 필요하며， 이를 위한 모금을 계속하고 있다고 밝혔다.

colors.js는 1.4.0 버전에서 1.4.1 로 패치 업데이트가 이뤄졌는데， 유의적 버전에 따라 패치 버전은 단순히 버그 수준에 그쳤어야 했지만 고의로 무한루프를 삽입한코드를 커밋해 1.4.1 을 배포해 버렸다.

 

오픈소스 덕분에 손쉽게 개발하고 있음을 알아야 하고, 오픈소스가 무슨 일을 하고 있는지 알 필요가 있다. 해서 지속 가능하고 오래 유지될 수 있는 안정적인 웹서비스를 만들기 위해 노력해야 한다.

 

15.2.3 제이쿼리, Angular JS, 리액트, 그리고 다음은 무엇인가?

 

 

 

 

수많은 프레임워크가 등장하는 가운데 리액트는 그중 가장 많이 쓰이고 있는 도구 중 하나지만, 다양한 옵션에 대한 피로감, 훅에 대한 거부감과 어려움 등으로 부정적인 의견이 점차 늘고 있다. 이를 틈타 Svelte에 대한 관심이 떠오르는 추세다. 이렇게 미래를 예측할 수 없으므로 개발자는 유연한 자세를 지녀야 한다.

 

15.2.4 웹개발자로서 가져야 할 유연한 자세

HTML, CSS, 자바스크립트가 웹을 구성할 것이라는 사실에는 변함이 없을 것이다. 하지만 최근 느린 자바스크립트를 대신할 하나의 방안으로 웹어셈블리(WebAssembly)가 떠오르고 있다. 웹어셈블리는 C, C++, 러스트 같은 시스템 프로그래밍 언어로 작성된 프로그램을 웹에서 사용할 수 있게 해준다. 자바스크립트보다 훨씬 더 빠른 언어로 작성돼 있기 때문에 일반적으로 웹에서 자바스크립트 기반으로 처리하기 어려운 작업을 웹어셈블리를 활용해 처리할 수 있다. 그러나 웹어셈블리는 자바스크립트의 대체제가 아닌 함께 상호 보완적으로 실행되는 도구라 보는 것이 적절하다.

라이브러리와 프레임워크는 그저 도구일 뿐 자바스크립트가 토대라는 사실에는 변함이 없다. 리액트 내부에서 어떻게 자바스크립트를 활용하는 지 살펴보기도 하고 자바스크립트부터 다시 공부해 보는 것도 좋다. 리액트에 의존적이지 않은 유연한 개발자가 되어야 한다.