“리액트? 써봤지. 근데 SPA 구조가 영 맘에 안 들더라고. 오히려 개발이 더 복잡해지는 느낌이야.”
정말 강력한 광역도발이 아닐 수 없습니다.
최근 대부분의 웹 프론트 개발은 vue, react, svelte 와 같은 라이브러리와 프레임워크들을 사용합니다. 이러한 상황은 이미 5년 가량 지속되어 왔기 때문에, 어떤 신입 개발자들은 순수 HTML / CSS / JS 만으로는 서비스를 아예 만들어본적이 없다고 말하는 경우도 있었습니다.
우리는 왜 특정 기술을 선택하는 걸까요? 트렌드라서? 아니면 정말 필요해서?
리액트를 사용하는건 닭잡는데 소잡는 칼을 사용하는 것일까요?
기술 스택은 결국 도구일 뿐입니다. 필요할 때 쓰고, 필요 없으면 과감히 버릴 줄도 알아야 합니다. 이 글에서는 리액트를 예로 들어, 웹 개발시 어떤 기준들로 기술 선택을 해야할까에 대해 써보려합니다.
1. 컴포넌트 기반 구조: 축복일까, 저주일까?
현대 프론트엔드 개발, React, Vue 이런 것들을 보면 가장 먼저 떠오르는 건 컴포넌트 구조입니다. 컴포넌트를 적극적으로 활용한 개발은 화면의 부분 부분을 독립적으로 관리할 수 있게 해주고, 코드 재사용성을 높여줄 수 있습니다.
UI를 레고 블록처럼 조립할 수 있다는 것입니다.
하지만, 빠르게 조형해야하는 것을 레고블럭 마냥 쪼개고 있는것은 생산적인 일 일까요?
예를 들어서, 작은 카페의 메뉴판 웹사이트를 만든다고 해보겠습니다.
규모 몇개 안되는 메뉴 항목을 컴포넌트로 만들어 재사용성을 높이는 게 좋을까요? 아니면 그냥 마크업 언어로만 빠르게 만드는 게 나을까요? 성능면에서도 작은 규모의 프로젝트일수록 리액트와 같은 Virtual DOM의 성능은 불리해진다는 것도 고려해야합니다.
변경 주기 물론 자주 메뉴가 바뀐다면 컴포넌트기반의 개발이 유리할 수 있습니다. 하지만 매번 메뉴의 형태가 크게 변경된다면 어떨까요?
협업 팀 이번엔 반대로 대규모 이커머스 플랫폼을 개발한다고 해보겠습니다. 수천 개의 상품 카드, 리뷰 섹션, 장바구니 등을 컴포넌트로 관리하면 유지보수가 훨씬 쉬워질 것입니다. 컴포넌트를 적극활용한다면 많은 사람들과 협업하고 특정 피쳐들을 여러 구간에서 재활용 하는데 유리해집니다. 하지만, 1~3명의 개발자팀에서 빠르게 MVP를 개발하고 이후 다시 구조화를 해야하는 경우라면 어떨까요?
물론 빠른 개발에 도움이 될만한 라이브러리를 추가로 활용하는 방법도 있습니다.
최근 tailwind css + shadcn 같은 UI 라이브러리와의 조합이 떠오르는 이유는 tailwind의 많은 사용자풀과 shadcn의 적은(사실상 없는) 의존도와 커스터마이징 빠르고 효율적으로 화면을 구성할 수 있기 때문인데..
참 좋은 도구들이지만, 협업팀에 많은 사람에게 새로운 러닝커브를 요구하거나, 추가 인력을 뽑는데 시간이 걸리는 경우라면 리소스를 줄이기보다는 늘리게 될것입니다.
이처럼 규모, 변경주기, 협업팀과 같은 여러가지 요소들이 기술 선택을 하는데 고려되어야합니다.
‘에잉 라떼는 jquery도 없었는데 ㅉㅉ..’ 부터 ‘나는 대깨 React 다!’ ‘대깨 vue 다!’ 이런 태도는 피하는 것이 좋습니다.
2. Virtual DOM: 성능의 마법, 혹은 과대 광고?
리액트의 또 다른 자랑거리, Virtual DOM. “실제 DOM 조작은 리소스가 많이드니 가상의 DOM을 먼저 조작하고 변경사항만 실제 DOM에 적용하자"는 아이디어입니다.
하지만, 내 서비스의 사용자는 그 차이를 정말 체감할 수 있을까요?
예를 들어, 간단한 블로그 사이트를 만든다고 해보겠습니다.
포스트 목록과 상세 페이지만 있는 정적인 사이트다. 이런 경우 Virtual DOM의 이점을 누리기 위해 리액트를 도입하는 게 과연 현명한 선택일까요? (이 블로그는 react + tailwind css + shadcn 으로 만들었습니다. ^^;)
반면 실시간 주식 / 코인 거래 플랫폼을 개발한다면 어떨까요? 수많은 숫자가 초 단위로 변하는 화면에서는 Virtual DOM의 효율성이 빛을 발할 것입니다.
결국 중요한 건 서비스의 특성과 클라이언트의(혹은 나의) 요구사항 이라는 것입니다. 화면에 실시간으로 업데이트 되는 요소가 많은 서비스라면 Virtual DOM을 사용하는 react나 vue를 선택하는 것은 좋은 선택이 되겠죠.
3. SPA(Single Page Application) vs MPA(Multi Page Application): 사용자 경험의 두 얼굴
React로 개발하면 자연스럽게 SPA(Single Page Application) 구조를 따르게 됩니다. 페이지 전환이 부드럽고, 앱처럼 동작하는 것에 더해 이런 장단점을 갖습니다.
장점:
- 부드러운 페이지 전환으로 사용자 경험 향상
- 서버 부하 감소 (초기 로딩 후에는 필요한 데이터만 요청)
- 오프라인 지원 가능성
단점:
- 초기 로딩 시간이 길어질 수 있음
- SEO에 불리할 수 있음 (검색 엔진 최적화)
- 메모리 사용량 증가
이번엔 뉴스 사이트를 만든다고 해보겠습니다. SEO가 매우 중요하고, 사용자들이 주로 검색엔진을 통해 유입될것을 예상해 볼 수 있죠?
이런 경우 SPA 보다는 전통적인 MPA 구조가 더 적합할 것이라고 어렵지 않게 생각해 볼수있습니다. 반면 사내 백오피스 대시보드를 개발한다면 로그인한 사용자만 접근하고, 빠른 데이터 갱신이 중요하다면 SPA 구조가 훨씬 효율적일 것입니다.
중요한 건 서비스의 목적과 타겟 사용자입니다. 기술을 선택할 때는 항상 우리 서비스에 정말 필요한가를 고민해야합니다.
요약: 기술 선택을 위해 고려되어야 하는 것들
기술 선택은 충분한 고민을 해야하는 프로젝트의 성공을 좌우할 수 있는 중요한 결정입니다.
여기에는 이런 고민들이 해당됩니다.
- 프로젝트의 규모와 복잡성
- 팀의 기술 역량과 학습 곡선
- 개발 기간과 유지보수 계획
- 서비스의 특성과 목표
- 사용자의 요구사항
때로는 최신 기술 대신 검증된 전통적인 방식이 더 적합할 수 있습니다. 때로는 같은 최신 프론트엔드 프레임워크 중에서도 React 보다도 Vue.js나 Svelte 같은 다른 프레임워크가 더 나을 수도 있고, 때로는 찐으로 codepen 같은 웹사이트에서 HTML, CSS, JavaScript로만 끄적여서 S3에 올려 배포해도 충분할 수 있습니다.
현명한 개발자는 트렌드에 큰 관심을 갖기는 하겠지만, 트렌드에 휩쓸려선 안된다고 생각합니다. 유행하는 것들을 다 ‘찍먹’ 해보는건 자유지만, 유행하는 것들을 모두 ‘푹먹’하는 것은 불가능 하기 때문입니다.
대신 프로젝트의 요구사항을 정확히 파악하고, 그에 맞는 최선의 도구를 선택하는데 초점을 맞춰야합니다. 트렌드에 대한 관심은 그에 대한 자유도와 선택지를 늘려줄 것입니다.