들어가면서

트위터에서 Kent C.Dodds 트윗을 한 번씩 보게 되는데 그 중 재밌게 읽었던 글을 가져와봤습니다.

저도 React를 좋아하긴 하는데 왜냐고 물어보면 바로 답하기는 어렵습니다.

이번 글을 보면서 저도 React를 좋아하는 이유를 다시 한 번 생각해보고 싶었습니다.

It's simple

React에 강력하게 끌리게 된 이유가 무엇이었을까요? 솔직히 몇 가지 이유가 있겠지만 한가지로 요약한다면 바로 이것입니다:

React는 단순합니다.

"쉽다"고 말하지 않았습니다. 왜냐하면 모든 사람에게 쉬운 것은 아니기 떄문입니다.("쉬움"은 개인마다 다릅니다) 하지만 React는 단순합니다. 이전 일반적인 도구들보다 더 단순했기에 React에 끌렸습니다.

"단순함"과 "쉬움"의 차이에 대한 자세한 내용은 Rich Hickey가 발표한 Simplicity Matters 를 참조하세요.

무엇이 React를 단순하게 만드는가?

명시적인 상태 업데이트

React는 상태 변경 API를 통해 상태 mutation을 피합니다. 대신 상태 업데이트는 명시적인 함수 호출로 이루어집니다. 이는 엄청난 큰 개선점이었습니다. 상태가 잘못 변경되는 원인을 찾는데 얼마나 많은 시간을 소비했는지 모릅니다. 저의 소프트웨어는 상태 업데이트의 "쉬움"에 의해 복잡해졌습니다.

Controlled input을 연결하는데 필요한 것이 Angular.js나 Vue처럼 "양방향 데이터 바인딩"(two-way data binding) 와 React를 비교한다면 Angular.js의 코드가 더 적다는 것을 알 수 있습니다. 그리고 그 데모도 놀랍도록 잘 보여줍니다. 하지만 "데모"가 잘 보여준다는 것과 실제 시나리오에서 유지 관리가 가능한 것이 항상 상관관계가 있는 것은 아니라는 것을 알게 되었습니다. "단방향 데이터 바인딩"(one-way data binding)를 선태갛 React의 선택은 좋은 선택이었습니다. 간단하고, 합리적이며, 유연하고, 강력합니다. 저는 코드를 얼마나 많이 작성해야 하는지는 별로 신경쓰지 않습니다. 저나 동료들이 나중에 버그 없이 코드를 변경하는 데 얼마나 많은 작업이 필요한지가 중요합니다.

JSX

문자열 템플릿 대신 JSX 구문(aka React.createElement의 syntax sugar)을 사용하면 템플릿 구문을 배우고 제한을 받거나 Angular.js 디렉티브의 전역 네임스페이스/레지스트리로 고생하는 대신 JavaScript 언어 기능에 대한 지식을 그대로 활용(및 개선) 할 수 있습니다. 템플릿 구문 사용시에는 무엇이 잘못됐는지 파악하는데 많은 시간을 보낼 수 있습니다. 엄청나게 복잡성을 가진 DLS(Domain Specific Language)이니까요.

게다가 그 구문을 배우기 위해 투자한 모든 시간이 낭비됩니다. 다른 작업에서는 전혀 적용이 불가능합니다.(React가 아니라 Angular2로 넘어갔더라도 말이죠) 하지만 JSX를 사용하고 syntax sugar을 이해하면 React가 아닌 코드에서도 항상 유용하게 사용할 수 있는 기능을 배우게 됩니다.

Hooks

React Hook은 확실히 React를 "단순"하게 만드는 또 다른 요소입니다:

• useState: 상태 관리해야 할 때
• useEffect: React 외부의 무언가를 앱의 상태와 동기화해야 할 때

Hook에 대해 익숙해져야 할 것이 분명히 있고 다양한 사례에 사용되는 다른 많은 Hook이 있지만, 개념적으로 "단순"합니다.(다시 말하지만 반드시 "쉬운" 것은 아닙니다)

Hook에서 가장 좋아하는 부분은 간단한 방식으로 코드를 공유하는 것이 비교적 쉽다는 점입니다. 컴포넌트 간에 Hook 로직을 공유하려면 기존 코드를 만드는 것처럼 함수를 만들고 로직을 사용하고자 하는 곳에서 그냥 호출하면 됩니다.

게다가 모든 것이 함수이기 때문에 다른 것들과 함께 구성할 수 있습니다. 이는 Hook을 다른 사용자 커스텀 Hook으로 만들고 또 다른 사용자 커스텀 Hook으로 만들고 또 다른 사용자 커스텀 Hook으로 만들고... 놀랍도록 강력하면서도 여전히 "간단"합니다. 이와 관련하여 좀 더 알고자 한다면 Tanner Linsley가 발표한 Custom Hooks in React: The Ultimate UI Abstraction Layer 를 참고하세요.

모두를 위한 React

React의 또 다른 장점은 규모와 상관없이 문제를 잘 처리한다는 점입니다. 특별한 도구가 필요하지 않고 빠르고 강력한 개발 경험을 제공합니다.

게다가 React는 UI가 있는 거의 모든 플랫폼을 지원합니다. (React Native, React VR 등등) React의 단순한 컴포넌트 기반 모델과 Hook의 힘은 어디든 도달할 수 있습니다. 크거나 작은 프로젝트에 상관없이.

React를 배우면 어디서든 UI를 만들 수 있습니다.

Community

프레임워크 단순함 외에도 React를 좋아하는 또 다른 이유는 모든 지표에서 전 세계에서 프론트엔드 애플리케이션 구축에 가장 인기 있고 널리 사용되는 도구라는 점입니다.

엄청난 차이로요.

실제 지표를 구하기는 어렵지만, 상대적인 인기도를 파악할 수 있는 가장 좋은 지표는 개발자 도구 브라우저 확장 프로그램의 사용자 수 입니다. React devtools 사용자 수는 4백만명 사용자를 넘어섰습니다. 그 다음 인기 있는 프레임워크의 개발자 도구의 2배 이상입니다.(Vue devtools는 2백만명입니다.)

npm 트렌드에서도 많이 느낄 수 있습니다.

어떻게 보던 React는 매우 인기 있는 프레임워크입니다. 그리고 이는 매우 좋은 부작용을 낳기도 합니다. 세계에서 가장 똑똑한 엔지니어들이 React를 개발하고 있을 뿐만 아니라, 커뮤니티 규모가 크다는 것은 세계에서 가장 똑똑한 엔지니어들이 라이브러리와 도구 등 생태계를 만들고 기여하는데 참여하고 있다는 것을 의미합니다.

다른 프레임워크에 이런 기능이 없다는 뜻은 아니지만(물론 있습니다), React의 압도적인 규모와 인기를 통해 이미 문제를 경험하고 해결하는 사람의 수가 많다는 것을 의미합니다. 그리고 우리가 직면하는 모든 문제가 이미 커뮤니티의 누군가에 의해 해결되었을 가능성이 높다는 것을 의미합니다.

마무리하며

React를 좋아하는데 말로 설명하기에는 어려웠었는데 이번 Kent C.Dodds 글을 읽고 나서 정리가 되었던 것 같습니다.

저 또한 React를 좋아하는 이유는 단순함이 가장 큰 이유라고 생각합니다.

저의 React를 좋아하는 많은 이유의 본질은 단순함이라고 생각합니다. 코드의 크기가 늘어나도 코드의 복잡성이 늘어나지 않는다는 것이 저에게는 매우 중요한 부분입니다.

애플리케이션, 시스템, 서비스는 복잡합니다. 크기가 커질수록 복잡성은 더욱 커집니다. 그러나 React는 이러한 복잡성을 다루는데 매우 효과적이라고 생각합니다.

코드가 영원히 살아가지는 않습니다. 결국에는 다른 사람이 이 코드를 이해하고 유지보수해야 합니다. 그리고 이러한 과정에서 코드의 복잡성은 더욱 더 중요해집니다. 지금 이 코드를 작성하는 사람이 아닌 다른 사람(또는 가까운 미래의 내가)이 이 코드를 이해하고 유지보수할 수 있어야 합니다. 이러한 관점에서 제 철학은 현재의 코드의 복잡성을 최소화하는 것입니다. 제가 React를 좋아했던 이유가 바로 여기에 있었던 것 같습니다.

여러분의 생각은 어떠신가요? React를 좋아하시나요? 그러면 좋아하는 이유가 무엇인가요?

reference

• https://epicreact.dev/why-i-love-react/
• https://twitter.com/kentcdodds/status/1782458532123881528