주객이 전도 된 프론트엔드 시장

iPhone의 등장과 React의 등장

태초의 웹은 HTTP 요청으로 웹 문서를 받아 정적인 컨텐츠를 보여주는 디지털 종이와 같았어요.
가끔 동적인 컨텐츠를 제공하는 페이지가 있긴 했는데 이건 마치 흰 종이에 붙여진 스티커와 같았죠.

그러던 도중 iPhone이 등장하고 모바일 앱이라는걸 처음 경험하기 시작합니다.

버튼을 누르면 수려한 애니메이션이 화면을 싹싹 넘기는 모습을 본 사용자들은 생각해요.
’이거 웹에서는 구현 못하나?’

하지만 웹은 앱처럼 만들 수 없는 물리적인 한계가 있었어요.

기본적으로 HTTP는 무상태성이며 한번 페이지를 떠나면 이전 페이지를 기억하지 못하고, 다음 페이지로 이동할 때 HTML을 새로 받아야 하기 때문에 페이지를 스무스하게 탐색하는 경험을 제공할 수 없었어요.

하지만 그걸 구현하고자 여러 시도가 있었고 그렇게 탄생한 도구 중 오늘날까지 쓰이는 도구가 React예요.

번들러의 등장

JavaScript는 원래 모듈을 지원하지 않았어요.

Javascript로 뭔가를 만들어봐야 DOM을 이동하거나 추가하는 등의 간단한 작업만 할 것으로 예상하고 만든 언어라 오늘날의 웹을 예상하지 못했기 때문에 벌어진 일이예요.

그래서 복잡한 Javascript 코드를 구현하려면 파일 하나에 모든 코드를 작성하거나, 순차적으로 <script> 태그를 연결하여 페이지에 Import 하는 방식으로 모듈과 비슷한 코드를 구현하고자 노력했어요.

하지만 오늘날의 웹은 React와 같은 프레임워크로 복잡한 프로그램을 만드는게 매우 흔해져서 여러 조각으로 흩어진 코드를 최종적으로 합쳐주는 도구가 반드시 필요해요.

그래서 만들어진 도구가 Webpack이나 Vite, Rollup과 같은 번들러예요.

상태라는 개념과 도구의 등장

React가 등장하면서 프론트엔드 개발은 컴포넌트 주도 개발이 주류가 되었어요.
이와 같은 방식이 메이저가 되면서 자연스레 상태 관리도 중요해졌죠.

이를 위해 Redux, MobX, Recoil과 같은 상태 관리 도구들이 등장했습니다. 이 도구들은 전역 상태를 쉽게 관리하고 컴포넌트 간의 데이터 흐름을 원활하게 만들어줘요.

데이터 캐싱을 위한 도구의 등장

HTTP 요청은 웹을 느리게 해요.

웹에서 필요로 하는 컨텐츠를 제공하기에 외부 자원 요청은 반드시 필요하지만 이 컨텐츠는 외부에 있기에 웹을 그려내기 까지 긴 시간을 사용해야 하는 병목지점이 되는거죠.

그래서 개발자들은 생각했어요.

어차피 오늘날의 웹은 이전 페이지의 내용도 기억할 수 있으니까 HTTP 요청도 메모리에 넣어놓고 쓰자!

웹 개발자들은 기존에 쓰던 Redux에 HTTP Fetching 코드를 넣어두고 사용하기 시작했어요.

그러다보니 Loading, Error, Success 상태 분기, 캐싱 시스템 구축 등 귀찮은 일이 한 두가지가 아니였고 보일러 플레이트도 증가하기 시작했어요.
그래서 만들어진게 React Query라는 도구예요.

그렇게 만사 해결?

위에서 설명한 도구를 제외하고도 매우 많은 도구가 생성되고 사용되기 시작했어요.
이러한 도구는 개발자가 겪는 여러 문제를 해결해 주었어요.

결과적으로 앱같은 웹을 만들 수 있게 되었고 복잡했던 Redux는 Zustand와 React Query를 결합하여 간단해졌어요.
컴포넌트의 Prop Drilling도 해결한거죠.
너무 잘 된 일이예요.

하지만 너무 무겁고 복잡해졌어요

오늘날에는 React와 Next.js와 같은 프레임워크부터 Redux, Recoil, Zustand와 같은 상태 관리 도구, React Query와 같은 캐싱 라이브러리를 비롯하여 여러 라이브러리를 결합한 형태가 표준처럼 자리잡았어요.

하지만 이런 구조에는 문제가 따라요.
컴포넌트의 응집도와 추상화 수준을 관리해야 하고 이를 위해 널리 알려진 아키텍처를 사용하며 조직 내 유관자에게 교육해야 하죠.

메모리 관리를 위해 데이터마다 적합한 캐싱 만료 시간도 설정해야하고, 타입스크립트를 사용하고 있다면 함수 구현 시 유연한 타입 추론을 위해 Interface도 작성해야 하죠.

사용자가 많이 방문하는 페이지는 따로 통계를 수집해서 적절한 수준으로 Chunk를 나누어 분리해야해요.
FCP를 줄여야하기 때문이죠.

잘 만들어진 홈페이지를 개발하기 위해 컴파일은 물론이고 별도의 라이브러리조차 필요가 없었던 시절이 있었다고 한다면 10년 뒤 웹 개발자들은 아마 놀랄지도 몰라요.

많은 사람들이 놓치는 본질

‘개발자’ 라는 직업은 코드를 우선하는 사람이 아니라 ‘상품을 코드로 만드는 사람’임을 많은 사람들이 망각하고 있다고 생각해요.

다르게 말하자면, 가치 있는 상품을 만들기 위해 가장 자주 쓰이는 수단이 ‘코드’이기 때문에 개발자들이 코드를 짜는데 시간을 상당 부분 할애할 뿐, 문제를 해결할 효율적인 다른 수단이 있다면 굳이 코드가 아니어도 상관이 없다는 것을 기억해야 해요.

주니어 개발자에게 선임 개발자가 내기를 신청했다.

‘누가 먼저 홈페이지를 빠르게 짜는지 내기할래?’

주니어 개발자는 그러자고 했다.

주니어 개발자는 React로 4시간만에 훌륭한 웹사이트를 만들었다.

선임 개발자는 그 때 까지 아무것도 하지 않았다.

주니어의 결과물을 본 선임 개발자는 조용히 노션을 열어 ‘퍼블리싱’ 버튼을 눌렀다.

위 글은 어디선가 읽은 기억이 있는 ‘주니어 개발자와 시니어 개발자의 차이점’에 대한 토픽을 각색한 글이예요.

이 글이 말하고자 하는 바는 ‘진정한 개발자는 수단이 아닌 목적에 집중해야 한다’는 것입니다.

주니어 개발자는 단순히 정적 홈페이지 구축이라는 목적을 이루기 위해 본인에게 익숙한 프로세스를 아무런 의문도 없이 진행한 반면, 시니어 개발자는 ‘정적 홈페이지 구축’이라는 목적에 집중하여 가장 효율적인 솔루션을 찾아내어 문제를 해결한거죠.

적절한 기술을 사용하세요

프론트엔드 업계에서 이러한 흐름은 나쁜건 아니예요.
새로운 기술을 받아들이는 자세가 다른 분야보다 유연하다는 반증이고, 업계가 살아있다는 것을 나타내는 반증이니까요.

하지만 SPA를 개발하기 위해 탄생한 기술 스택이 마치 웹 표준처럼 자리잡아 모든 웹을 SPA처럼 개발해야만 한다는 강박은 가지지 말아야해요.

React를 비롯한 현대의 웹 개발 스택이 가져오는 장점은 공짜가 아니고 이미 가지고 있던 많은 장점을 버려야만 가져올 수 있는 장점을 취한 형태라는 것을 아셔야 해요.

• 검색 엔진 최적화
• 초기 렌더링 속도
• 가벼운 사이즈의 HTML 문서
• 위에서 언급한 모든 문제가 SPA를 개발하기 시작하면서 생겨난 문제

이렇게 복잡해진 웹 생태계에서 개발자로 살아남으려면 최신 기술을 꾸준히 학습하되, 이 기술을 어떤 상황에 써야 하는지 확실하게 이해하고 적절한 상황에 선택하는 기술을 배워야 해요.

내가 기술을 쓰는거지 기술이 나를 쓰게 하지 마세요.