2022년, FE Techs
현업에서 내가 느끼는 그러니까 동료 개발자들과 이야기하면서 생각해 본 점들을 정리해보고자 한다. 이 글에는 꽤 많은 주관이 섞여 있는 데, 당연히 동료들과 이야기를 하면서 얻어낸 인사이트이기 때문이다.
React 는 New Standard 다.
예전에 jQuery 가 가졌던 위상을 지금은 React 가 가지고 있다고 해도 딱히 과언은 아닐 거라 생각한다. 실제로 대부분의 통계들이 React 의 중요성에 대해 이야기하고 있으며, React가 어떤 방향을 취하느냐 에 따라 애플리케이션의 설계가 바뀔 정도로 React 는 꽤 중요한 역할을 하고 있다.
무엇보다 React 를 중심으로 한 생태계 (Next, Gatsby 등)는 무시하지 못할 수준으로 거대해지고 있으며, Express 에서는 View Engine 으로 React 를 사용할 수 있게 되는 등 꽤 많은 부분이 발전해나가고 있다. 믿기 힘들겠지만 정말 된다. 확실한 건 라이브러리 전쟁에서 React 는 확고한 위치를 얻었고, 그 결과로 React 를 배워두는 건 적어도 지금 시대에서는 분명히 도움이 될 거라 생각한다.
React 내 에서도 Function Component와 Hooks를 함께 쓰는 게 보편적인 사용 예라 생각되고, React Beta 에서도 이제 Function Component를 더 중점적으로 다루고 있다.
Next
최근 들어 부쩍 Next 를 쓰는 회사가 많아졌다. 당장 내가 일하는 곳뿐만 아니라 꽤 많은 곳이 Next 를 활용하여 웹 사이트를 만드는 것이 눈에 띈다. Next 는 소스 코드 열기를 보았을 때 Root 가 _next 로 되어있어서 눈에 확 띄는 것이 특징이다. CSR, SSR, SSG를 모두 지원하기도 하고, 인터페이스도 단순해서 사용하기 편하다는 점이 장점이라고 생각한다.
Hooks! Hooks! Hooks!
나는 데이터를 불러올 때 SWR이나 React Query 사용을 당연하듯 사용하고 있고, Hooks 를 사용하다가 분리 가능한 Hooks 라 생각되면 Custom Hooks 로 나누어 사용하고 있다. 여러 컴포넌트 사이에서 비즈니스 로직을 공유하는 경우는 많지 않지만, 그런 경우에도 Custom Hooks로 나누어 쓰면 확실히 장점이 크다.
Svelte 의 성장과 Angular, Vue
분명히 Svelte 는 약진하고 있다. 그 속도가 빠르지는 않지만 그래도 조금씩은 성장하는 듯 보이는데, 한국에서는 Svelte 를 사용하는 회사는 아직까지는 접하지는 못했다. 그래도 주변에서 관심을 가지고 도입을 고민해보는 회사들을 몇 군데 보았는데, 아직은 확실한 레퍼런스가 부족해서 그렇다고 생각한다.
얼마 전에 AngularJS 가 지원 중단되면서 Angular 가 지원 중단된 게 아니냐는 걱정을 하는 사람들을 많이 보는데, AngularJS 와 Angular는 완전히 다른 프레임워크이기 때문에 무시해도 괜찮다. 적어도 내가 아는 한도 내에서 Angular를 지원 중단하려면 Google 내부에서만 수없이 많은 프로젝트를 마이그레이션 해야 할 것이다.
사람들이 React 에 너무 익숙해져서 Vue 나 Angular 는 전혀 쓰이지 않는다고 생각할 수 있지만 의외로 두 라이브러리도 국내에서 활발하게 쓰이고 있다. 다만 회사에서 쓰인다고 하였을 때 깊이 있게 공부하는 건 충분히 의미가 있지만, 사전에 미리 Vue 나 Angular를 처음으로 공부할 필요가 있는가? 에 대해서는 잘 모르겠다. 그정도 수준으로 널리 쓰이고 있는 느낌은 아니라고 생각한다.
TypeScript by Default, But how about others?
꽤 많은 회사에서 TypeScript를 거의 기본처럼 사용한다. 그래서 면접에서도 TypeScript 경험을 물어보거나, TypeScript 관련된 질문을 하는 경우도 많이 늘었다고 생각한다.
다만 나는 TypeScript 특유의 불편한 점을 몇 가지 느끼고 있어서 이걸 어떻게 해소할 수 있나 고민하고 있다. ReScript 가 좋아 보이던데 공부해보려고 한다.
jQuery는 어떻게 되어가는가?
내부 아키텍처를 계속 뜯어고치는 것으로 보인다. 일부 라이브러리에서 여전히 jQuery 의존성을 가지고 있기 때문에 jQuery를 완전히 버리기에는 어렵지만, 적어도 내 주변에서는 jQuery를 이제 많이 버렸다고 생각한다.
여러가지 이유가 있지만 버전업이 현재는 유독 느리다. 3.6.0 버전이 2021년 3월 릴리즈 되었는데, 그 이후에 마이너 버전 업데이트도 없이 거의 1년 가까이 지나고 있다. 블로그에 의하면 jQuery UI 나 jQuery Mobile 쪽을 뭔가 최신화하고 있는 듯하다.
Styled Component
UI 개발자와 FE 개발자가 분리되어 있는 조직에서는 여전히 CSS in CSS 를 활용하는 경우도 많아 보이나, 그렇지 않은 조직에서는 CSS in JS 를 더 적극적으로 사용하는 것으로 보인다.
Styled Component, Emotion 등은 꽤 보편적으로 사용하는 테크닉이 되었고, 그로 인해 CSS의 강력한 특성인 상속, 캐스케이딩 등의 활용도는 많이 약해졌지만 컴포넌트 단위로 CSS를 설계하는 게 보편적으로 사용되는 듯 하다.
Micro frontend architecture
은근히 비슷한 컴포넌트를 여러 군데서 사용하거나, 비슷한 유틸을 여러 서비스에서 공용으로 사용하는 경우가 많기 때문에 마이크로 프론트엔드 아키텍처를 통해 공용 로직을 따로 분리하는 패턴을 사용하기도 한다. Yarn 에서는 기본 기능으로 workspace 를 지원하고, Lerna 같은 도구를 활용하여 MFA 를 만들 수도 있다.
이제는 GitHub Acitons 를 활용해 CI / CD 파이프라인도 예전에 비해서는 쉽게 구성할 수 있기 때문에, 구성요소가 바뀌었을 때 여러 서비스를 동시 배포하는 것도 가능하고, 컨테이너 단위로 별도 배포하는 것도 가능하다.
MFA의 정의는 조금 다양한데, 처음 정의된 패턴에서는 페이지 내의 컴포넌트도 서비스 단위로 쪼개서 배포하고, 그걸 하나로 묶어내서 서빙하는 형태를 이야기했었지만, 지금은 한 서비스 내에서 관심사 단위로 따로 배포하는 경우에도 MFA 라 부르는 듯하다.
Backends For Frontend
나는 주로 RESTful API 를 GraphQL 로 바꾸는 영역에서 BFF 레이어를 활용하는 편인데, 백엔드가 여러 마이크로 서비스로 분리되어있을 때 직접 서비스와 통신하여 내가 원하는 API 형태로 내려주기 위해서 BFF 레이어를 활용할 수도 있다.
결국 가장 중요한 건 프론트엔드에 필요한 형태로 데이터를 가공하는 레이어를 클라이언트에 두는 게 아니라 별도 서비스로 두고, 그 서비스와 계속 통신함으로서 클라이언트는 정말 UI 에 초점을 맞출 수 있게 하는 것이다.
기타
트렌드에는 있는 데 아직 제대로 학습하지 못한 것들을 써내려 본다. 대충 어떤 느낌인 지는 알겠으나 내가 알고 있다고 말하기에는 부족하다.
- Vite
- Remix
