오늘은 2020년도에 배워볼만한 프레임워크와 라이브러리들에 대해 이야기 해보도록 하겠습니다. 10년정도 전만 하여도 프론트엔드의 영역은 현재처럼 복잡하지 않았습니다. 지금처럼 수많은 사이즈의 스크린을 서포트 할 필요도 없었고, SPA 따윈 존재하지도 않았으며 UI/UX 편의성에 대한 유저들의 기대치가 현대처럼 높지도 않았습니다. 하지만 아이폰의 출시와 함께 프론트 엔드 개발자들의 지옥이 시작되었고 언어 매년 성장이 가장 빠른 언어중 하나인 Javascript를 사용하여 셀수없이 많은 라이브러리와 프레임워크들이 매년 쏟아지며 프론트엔드는 어떤 라이브러리/프레임워크를 사용해야할지 결정조차 못하겠는 영역이 되었습니다. 이번 강의는 제가 사용해본 결과 배울만 하다 생각되는 프론트 엔드 라이브러리/프레임워크를 설명하는 시간을 갖어보도록 하겠습니다.
HTML/CSS/JS/JQuery
일반적으로 많은 프론트엔드 개발자 분들이 가장 먼저 접하는 영역은 웹 영역입니다. 가장 많이 처음으로 접하고 많은 분들이 개발을 포기하는 부분이기도 하죠. 읿반적으로 프론트엔드 개발자로서 프로그래밍 첫걸음을 떼면 HTML/JS/CSS로 시작하게됩니다. HTML로 화면에 컴포넌트를 배치하고 CSS로 해당 컴포넌트를 꾸미며 JS로 서버와 통신 또는 동적인 UI를 구성하게 되죠. 여기에 jQuery를 첨가하게되면 조금더 Javascript를 손쉽게 사용할 수 있게 됩니다. 옛날이였으면 여기까지 배웠으면 기본기는 다 갖췄다고 볼 수 있었죠. 하지만 SPA (Single Page Application)이 나오게 되면서 프론트엔드의 생태계는 지옥으로 치닫게됩니다.
SPA
SPA는 Single Page Application의 약자로 말 그대로 한 페이지에서 모든 컴포넌트들을 렌더링 하는겁니다. 물론 프로그래머의 관점에서 봤을때 한 페이지고 유저의 입장에서는 여러 페이지가 모두 공존하는 것같은 착각을 한 페이지에서 만들어내죠. 페이스북에서 React를 만들었고 구글에서 Angular 그리고 개발 커뮤니티가 Vue를 만들었습니다. 현재 전 세계적으로 제일 인기 있는건 React 지만 Vue가 빠르게 쫓아오고 있습니다. 제 경험상 React가 가장 직관적이고 사용하기가 편했지만 Vue는 기존 전통적인 HTML/JS/CSS에 너무 적응되어있고 러닝커브가 너무 높은걸 배우고 싶지 않은 분들에게 추천할 만 하다고 생각합니다. 요즘은 세 라이브러리 모두 너무 잘 구현되어 있어서 기본 튜토리얼과 가장 보편적인 상태관리 툴들을 사용하면서 어떤 라이브러리를 먼저 배워볼지 선택하시면 좋을 것 같습니다. 요즘은 채용공고에 SPA 세가지중 하나는 꼭 필수사항으로 있을만큼 SPA가 많이 보편화가 되었기 때문에 프론트엔드 개발자가 되고 싶다면 꼭 배워야하는 기술중 하나입니다.
State Management
State Management 는 한국어로는 일반적으로 상태관리라고 하는데 쉽게 말하면 SPA에서 지속되야 하는 변수들의 값을 어떻게 글로벌하게 관리하냐에 대한 답변을 들고있는 친구들이 State Management 라이브러리들이라고 보면 됩니다. SPA는 설명 들였다싶이 프로그램적으로는 페이지가 하나이기 때문에 유저가 고의적으로 페이지를 벗어나지 않는 이상 여러 라우트에서 생긴 유저의 액션들을 한번에 관리할 수 있습니다. 예를들어서 물건을 리스팅 해놓는 페이지에 필터링 기능이 있다면 일반적으로 서버에서 페이지를 렌더링 해주는 프론트엔드의 경우 해당 페이지를 벗어났다 돌아왔을때 어떤 필터가 적용이 되었었는지 기억하는 기능의 구현이 비교적 복잡하지만 SPA에서는 State Management 라이브러리를 사용해서 손쉽게 구현할 수 있습니다. State Management 라이브러리들은 상당한 장점을 갖고 있지만 그만큼 프로그램을 복잡하게 만들기 때문에 꼭 필요할 경우가 아니면 사용하는걸 추천하진 않습니다.
Redux
Redux는 일반적으로 React를 사용하는 사람들이 가장 쉽게 접하는 상태관리 라이브러리입니다. 제가 알기론 상태관리 라이브러리중 가장 오래되었고 React 에서 Context 라이브러리가 기본적으로 탑재되기 전까지는 업계 표준이었던 라이브러리입니다. 엔드포인트 하나를 추가할때마다 작성해줘야하는 코드가 너무 많다는게 단점입니다. 그래도 React에 처음 입문하셨다면 일반적인 상태관리 개념을 깨우치기 위해 Redux를 꼭 배워보시길 바랍니다.
Mobx
Mobx도 React의 상태관리 라이브러리중 하나인데 Mobx의경우 OOP개념을 아주 효율적으로 활용한 라이브러리라고 볼 수 있습니다. 저도 항상 Redux만 사용하다 이제는 Mobx만 사용하는데 Mobx가 Redux보다 훨씬 더 간결하고 서버 엔지니어링을 많이 하다가 오신분들은 Mobx가 Redux보다 훨씬 더 친숙하실 수 있습니다. 개인적으로 State Management 라이브러리 중에는 꼭 배워보길 추천해드리는 라이브러리입니다.
RxJS
RxJS는 Stream을 최대한으로 활용한 진정한 Async State Management 라이브러리라고 볼 수 있을 것 같습니다. Stream을 사용하다보니 훨씬 더 자유롭게 상태 관리가 가능하고 State를 상당히 복잡한(?) 방법으로 변형시킬 수 있습니다. Flutter 에서는 RxDart가 기본적인 상태관리 방법인데 RxJS가 거의 비슷하다고 보시면 될 것 같습니다. 다만 제 개인적으로는 Flutter 만큼 React에 완벽히 스며드는 것 같은 느낌은 아니고 어느정도 이질감이 있다고 생각이 되고 저는 프로젝트가 커질수록 상태관리 복잡도가 상당히 높아지는 경험을 했습니다. Rx라이브러리에 관심이 있다면 한번쯤 사용 해볼만한 라이브러리입니다.
UI Libraries
처음 SPA를 접하게 되면 기존 HTML/JS/CSS를 사용하실 때는 그냥 Bootstrap 사용하면 됐었는데 SPA로 넘어오면서 도대체 어떤 UI 라이브러리를 사용해야할지 하루 종일 고민하는 자신을 발견하게 될겁니다. Bootstrap은 jQuery 기반이기 때문에 SPA에, 특히 React에 완벽히 어울린다 볼 수 없으며 실제로 가장 인기있는 UI라이브러리가 아닙니다. 구글에서 내세우는 디자인 프린시플인 Material UI와 중국 기업들이 사용하는 Ant Design이 가장 활발하게 개발되고 있는 라이브러리들이라고 볼 수 있습니다. Material UI는 약간 투박한 느낌이 있으나 스폰도 탄탄하고 GitHub 별도 무려 6만개를 넘는 탄탄한 라이브러리입니다. 저는 개인적으로 Material UI라이브러리를 기반으로 UI 커스터마이징을 진행하는데 구현하기 귀찮은 기능과 애니메이션들이 기본적으로 탑재되어 있기 때문입니다. Ant Design은 중국에서 많이 쓰는 라이브러리인데 Material UI에 비해 컴포넌트들이 아기자기하고 주관적이긴 하지만 기본 디자인이 조금 더 이쁘다는 장점이 있습니다. 다만 아직 영어로 완전히 번역되지 않은 페이지들이 좀 있다는 단점이 있습니다. 개인적으로 구경만 하고 아직 사용은 해보지 못해서 편의성에 대해서는 코멘트 하지 못할 것 같습니다.
Native Mobile
네이티브 모바일은 일반적인 iOS와 Android 개발을 이야기합니다. iOS의 경우 Objective C 또는 Swift를 사용해서 개발하게 되고 Android는 Java 또는 Kotlin을 사용해서 개발하게 됩니다. 저는 옛날에 Android 개발을 조금 한 적이 있었는데 현재 바뀌었는지는 모르겠지만 당시에는 XML로 모든 UI를 구성해야하는게 상당히 불편했던 기억이 있습니다. iOS 네이티브 개발은 해보지 않아서 할 이야기가 많지 않지만 App Store 등록 절차는 정말 토나온다는…
React Native / Flutter
React Native와 Flutter는 iOS와 Android 개발을 하나의 소스코드로 크로스 플랫폼 개발을 할 수 있는 프레임워크들입니다. React Native는 이름에서 알 수 있다싶이 React로 앱 개발을 할 수 있는 프레임워크입니다. React 생태계에 구축되어 있는 거의 모든 라이브러리들을 사용할 수 있고 혹시 회사에 React 개발자가 많다면 러닝커브가 거의 없다는 장점이 있습니다. 저도 React Native로 앱을 몇개 출시 해봤는데 Native 앱으로 개발하는 것보다는 훨씬 편리하다는 인상을 받긴 했습니다. 다만 React Native의 경우 iOS와 Android에 존재하는 컴포넌트들을 최대한 묶어놓은 형태라 코드는 하나일지언정 iOS와 Android에서 결국 따로 디버깅을 모두 해봐야한다는 단점이 있었고 실제로 이 과정이 실제 개발 과정보다 오래 걸리는 경우가 많습니다. 한쪽에서 고치면 다른쪽에서 고장이 나는 크로스 플랫폼 특유의 단점이 있기 때문에… Flutter는 React Native보다 한국에서는 덜 알려진 크로스플랫폼 앱 제작 플랫폼입니다. Flutter를 접하기 전까지는 React Native가 그래도 참 편리하다는 생각을 갖었는데 Flutter를 접한 후에는 React Native는 버그 투성이에 개발 덜된 라이브러리 같은 느낌이 들정도로 UI를 크로스 플랫폼으로 개발하는데 상당한 장점을 갖고 있습니다. Flutter 같은경우 iOS와 Android에서 제공해주는 UI를 공유하는 방식이 아닌 직접 화면에 컴포넌트를 그려버리는 형태로 개발을 하기 때문에 플랫폼별로 따로 디버깅을 해야하는 경우가 거의 없고 Android에서 개발한 후 iOS에서 실행하면 거의 문제 없이 한번에 돌아가는 경우가 대부분일 정도로 완벽에 가까운 크로스플랫폼 앱 개발 플랫폼이라 볼 수 있습니다. 다만 아직은 지원 안되는 기능들이 꽤 있기 때문에 특수한 기능이 필요 하시다면 해당 기능이 구현이 가능한지 확인 후 Flutter를 채택하시기 바랍니다. 더 나아가 Flutter는 모바일 뿐만 아니라 데스크톱, 웹까지 한번에 원 소스코드로 개발 할 수 있도록 진화하고 있기에 앞으로 더욱 기대되는 프레임워크입니다.
Electron
.NET이나 Java로 데스크톱 앱을 만들어 보셨다면 웹 개발 라이브러리 및 툴들을 사용해서 쉽고 이쁘게 프론트 엔드를 구성할 수 있으면 얼마나 좋을까 하는 생각을 한번쯤 해보셨을 겁니다. 이런 상상을 실제로 가능하게 해주는게 Electron 입니다. Electron은 React 기반으로 데스크톱 앱을 제작할 수 있도록 해주는 프레임워크고 React Native와 마찬가지로 React의 라이브러리들을 대부분 그대로 사용할 수 있습니다. Slack 및 VSCode가 Electron으로 제작된 대표적인 프로그램들이며 웹에서 구현할 수 있는 복잡하고 아름다운 UI를 손쉽게 데스크톱에서 구현할 수 있게 해주는 편리한 프레임워크라고 생각하시면 될것 같습니다. 데스크톱 앱을 구현하고 싶으시다면 한번 배워볼걸 추천드립니다.
Apollo
Apollo는 React또는 Vue에서 GraphQL을 효율적으로 사용할 수 있도록 해주는 라이브러리입니다. State Management도 기본적으로 되고 React의 Hook과 완벽 호환되는 상당히 편리한 라이브러리입니다. Flutter 에서도 GraphQL을 종종 사용했었는데 GraphQL을 사용하려면 제 생각에는 React Apollo 만한 라이브러리가 없다고 생각됩니다. GraphQL에 관심이 있으시다면 React의 Apollo로 시작해보시는 걸 추천드립니다.
SSR
SPA 초창기에는 CSR (Client Side Rendering)만이 가능했었습니다. CSR은 렌더링이 빠르다는 장점이 있지만 SEO에 취약하다는 단점이 있습니다. CSR은 서버에서 빈 HTML 페이지를 요청해서 가져온다음 관련된 Javascript를 따로 호출해서 페이지를 렌더링 하는 시스템인데 이렇게 될 경우 구글이나 네이버같은 검색엔진에서 크롤러들이 웹사이트를 빈 페이지로 인식하게 됩니다. 그래서 개발된게 SSR (Server Side Rendering)인데 SSR의경우 개발은 SPA로 하지만 페이지를 요청하게 되면 서버에서 해당 페이지의 모든 컨텐츠를 렌더링 해서 클라이언트로 전송을 해주게 됩니다. 이렇게 이론적으론 전통적인 프론트엔드 개발과 SPA의 장점들만 묶어놓은 것 같지만 실제로 SSR을 구현하려면 배보다 배꼽이 클 정도로 개발이 복잡해지는 기능들이 가끔 있습니다. 이런 문제들을 해결하기 위해서 NextJS나 Gatsby같은 프레임워크가 있으나 CSR에 비해 퍼포먼스적인 부분이 많이 차이가 나기 때문에 충분한 테스트를 거친 후 결정을 하시기 바랍니다 (CSR을 사용하고 Prerender.io같은 툴을 사용해서 SEO문제를 해결할 수도 있습니다.)