[팀프로젝트] 프론트엔드 기술 스택 선정하기

 

 

*취준생 관점에서 작성된 글입니다

 

이번에 새로운 프로젝트에 프론트엔드 개발 담당으로 합류하게 되었다. 그 과정에서 오롯이 내가 기술 스택을 결정해야 하는 일이 생겨서, 필요한 기술 스택 후보를 직접 조사해보고, 선정한 후 결론적으로 왜 해당 기술 스택을 선정했는지를 정리해보고자 한다.

 

 

어떤 범주의 기술 스택이 필요한가?

이번 프로젝트는 크로스플랫폼 앱을 목표로 하며 일부 외부 API 사용이 필수적인 환경에서 개발이 이뤄진다. 또한 가장 중요한 부분인.. 프론트엔드 개발을 주로 담당하게 될 나는, React에 가장 익숙하다. 이러한 조건을 종합적으로 고려해, 전체 앱은 크로스플랫폼 개발 프레임워크를 기반으로 구현하되, 일부 화면은 WebView를 통해 웹 기술로 구축하는 하이브리드 방식을 병행하는 전략을 구상했다.

 

따라서 아래와 같은 기술 스택 범주를 추려냈다.

1. 앱 개발 플랫폼 / 프레임워크 : 크로스 플랫폼 기반으로 앱을 개발할 수 있는 기술
2. 웹 프레임워크(WebView 대응) : WebView에 삽입될 웹 콘텐츠를 제작하기 위한 웹 프론트 기술
3. 언어 : 일관된 코드 작성을 위해 사용될 언어
4. 상태 관리 및 데이터 처리: 클라이언트 상태 및 서버 상태를 효율적으로 관리하고 데이터를 처리할 수 있는 도구
5. UI 컴포넌트 및 스타일링 도구 : 앱 및 웹 환경에서 UI를 일관되게 구성하기 위한 도구
6. 라우팅/내비게이션 시스템 : 앱 및 웹 내 페이지 간 전환을 처리할 수 있는 라우팅 도구
7. 코드 품질 및 일관성 도구 : 코드 스타일을 통일하고 잠재적 오류를 예방하기 위한 정적 분석 도구
8. 테스트 및 문서화 도구 : 기능 테스트와 UI 문서화를 통해 안정성과 유지보수성을 높이는 도구

---

앱 개발 플랫폼 / 프레임워크

크로스 플랫폼 앱 개발을 위해 대표적으로 React Native와 Flutter를 사용할 수 있다. 여전히 둘 중 뭐가 낫냐는 의견이 매우 분분한듯 하다. 실제로도 두 기술은 스택오버플로우의 전문 개발자 대상 조사 결과에서도 근소한 차이의 점유율을 가지고 있기 때문에 여전히 어느 한쪽이 매우 우세하다/유리하다는 결론을 내릴 순 없을 것 같다.

하지만 나는 서론했듯이 React에 익숙하기 때문에 + React Native를 사용해본 경험이 있기 때문에 큰 고민없이 ✅React Native를 선택했다. 당장 프로젝트를 시작해야할 때 접해보지 못한 기술에 도전하고, 조금이라도 더 나은 기술을 선택하는 것도 나쁘지 않겠지만 개발자의 숙련도 또한 가장 중요한 판단 기준이라고 생각한다.

React Native CLI vs Expo

React Native는 크게 React Native CLI와 Expo의 두 가지 방식으로 개발할 수 있다.

• React Native CLI는 모든 네이티브 기능을 직접 구성하고 관리할 수 있어 고도의 커스터 마이징이 가능한 방식이다.
• Expo는 설정 없이 빠르게 앱을 개발할 수 있는 프레임워크다. 다만, Expo의 경우 모든 네이티브 기능을 자유롭게 사용하기엔 제한적일 수 있다.

결론적으로 나는 ✅Expo를 선택했다. 네이티브 기술을 얼마나 사용하게 될 지 아직 잘 몰라서 옛날에 작성된 비교글을 찾아보며 고민이 많았는데, React Native의 공식 문서의 0.74버전에서부터 아예 Expo를 권장하고 있다는 것을 확인하고 고민을 줄일 수 있었다. 또한 향후 복잡한 네이티브 기능이 필요하다면 eject를 고려해볼 여지도 있기 때문에 당장은 Expo를 선택하여 빠르고 효율적으로 개발하는 것이 적합한 선택이라 생각했다.

 

---

웹 프레임워크

WebView에 대응하기 위한 기술로는 React, Next.js, Vue.js(+ Nuxt.js)를 생각해볼 수 있다.

앱을 React Native 기반으로 개발할 예정이기 때문에, 웹 역시 React 생태계를 따르는 것이 자연스러운 선택이었다. 이에 따라 React 기반의 웹 프레임워크인 Next.js를 도입할 것인지를 고민해봐야 했다. 최근 Next.js를 학습하면서, 파일 기반 라우팅, 정적/동적 혼합 지원, 손쉬운 성능 최적화 등 Next.js가 갖는 다양한 장점을 체감할 수 있었고, 이번 프로젝트에서도 유용하게 적용할 수 있을 것이라 판단했다. 따라서 WebView에 삽입될 웹 콘텐츠는 ✅Next.js로 개발하기로 결정했다.

 

---

언어

언어는 ✅TypeScript를 사용한다. JavaScript로 개발할 때는 런타임에서야 드러나는 예상치 못한 오류가 종종 발생한다. 반면, TypeScript는 컴파일 단계에서 타입 오류를 사전에 확인할 수 있어 안정적인 코드 작성을 도와준다. 특히 이번 프로젝트가 결코 작은 규모는 아니기 때문에 타입스크립트를 사용하는 이점이 더욱 크게 작용할 것이라고 판단했다.

 

---

상태 관리 및 데이터 처리

항상 고민이 많은 영역 중 하나가 바로 상태 관리 라이브러리이다.

Redux, Recoil, Zustand, Jotai, MobX 등등.. 선택지가 꽤나 많고, 회사들의 채용 공고를 봐도 각 회사마다 사용하는 라이브러리가 제각각이라 프로젝트에서도 어떤 걸 선택해야할지 기준을 잡기 어려웠다.

나는 Redux를 처음 접했을 때 느꼈던 복잡한 사용 방식과 높은 러닝 커브를 계기로, 이후 프로젝트에서는 '가볍고 직관적인 사용성'를 기준으로 Zustand를 선택해왔다. 실제로도 이 가벼움과 간편함은 프로젝트 진행 시 꽤 만족스러웠다.

 

이번 프로젝트에서는 좀 더 신중하게 접근해보고자 했고, 그 결과 무거운 redux의 보일러플레이트 문제를 개선한 Redux Toolkit과, zustand를 후보로 올리게 되었다. 다른 라이브러리는 최신 업데이트의 부재나, 학습 리소스 부족 등을 이유로 후보에서 제외했다.

• Redux Toolkit은 Redux 기반의 높은 안정성과 확장성을 보유하고 있고, 복잡한 상태 관리에 적합하며, RTK Query를 사용하여 서버 상태도 간결하게 관리할 수 있다는 점에서 매력적이었다. 하지만 여전히 보일러플레이트 양이 많은 편이고 러닝 커브가 있는 편이었다.
• Zustand는 매우 가벼우며 사용법도 간단하다. 즉, 진입 장벽이 낮다. 하지만 상태 구조가 복잡해질수록 관리가 어려워질 수 있다는 단점이 있었고, 서버 상태 관리에는 적합하지 않기 때문에 추가 도구가 필요하다.

그 밖에도 여러가지 문서나 비교글을 찾아봤지만, 결정적인 우열을 가리기에는 한계가 있었다. 그래서 npm trends에서 두 패키지의 다운로드 수를 비교해보았다. 결과는 놀랍게도.. 작년 중순 이후부터 Zustand가 Redux Toolkit의 다운로드 수를 앞서더니 지금은 격차가 꽤나 벌어진 모습이다. 분명 내가 마지막으로 찾아봤을 땐 여전히 redux-toolkit이 앞서고 있었는데..!

물론 다운로드수가 높다고 '좋은' 라이브러리라거나, 내 프로젝트에 적합한 라이브러리라는 것은 아니다. 하지만 선택에 참고할 수 있는 지표로는 충분히 가치가 있다고 생각한다. 게다가 한쪽이 뒤쳐지다가 앞지른 상황이라면? 그 흐름엔 분명 이유가 있을 것이라 생각했다.

결론적으로, 이번 프로젝트에서는 ✅Zustand를 클라이언트 상태 관리에 사용하고, 서버 상태는 ✅TanStack Query로 분리하여 처리하는 방식으로 결정했다.

 

또한 React Native에서 서버와 비동기 통신을 위해서는 ✅Axios를 사용하며, Next.js에서는 Next.js에서 제공하는 내장 fetch 함수를 그대로 사용할 예정이다.

---

UI 컴포넌트 및 스타일링 도구

React(Next.js) 기준으로 스타일 라이브러리는 CSS-in-JS 방식의 대표 라이브러리 Styled Component, Emotion와, Atomic CSS 방식의 Tailwind CSS를 고려해볼 수 있다. 아니면 기본적인 방식으로 CSS Modules를 사용하는 것도 하나의 선택지가 될 수 있다.

 

우선 Styled Component는 2025년 3월 18자를 기준으로 더 이상 기능 개발을 하지 않는다고 발표했다. 버그 수정이나 기능 유지 보수는 이어가겠다고 했지만, 굳이 지금 시점에서 Styled Components를 도입할 필요는 없어보인다.(기능개발 중단 글에서도 사용하지 않는게 좋다고 말하고 있다..)

 

최근 내가 프로젝트에 주로 사용한 것은 Tailwind CSS인데, 알려져있다시피 매우 호불호가 갈린다. 나는 미리 정의된 클래스명을 활용해 간단하게 스타일을 입힐 수 있는점, 요소 하나하나에 클래스명을 고민하지 않아도 된다는점, 또 복잡한 CSS 선택자를 사용하지 않아도 된다는 점을 Tailwind CSS의 큰 장점으로 꼽으며, 그 이유로 Tailwind CSS를 선호해왔다.

 

하지만 팀프로젝트에서 만약 팀원들이 내 코드를 수정하거나 함께 개발하게 될 경우, Tailwind CSS에 익숙하지 않다면 그건 그거대로 매우 곤란한 문제가 된다..

위 코드는 최근 내가 개인적으로 개발 중인 프로젝트에서 특정 요소를 TailwindCSS로 스타일링한 부분인데 꽤나 난잡해 보이긴 한다. (참고로 위 코드는 정렬 전 상태이긴 하다)

 

그럼에도 불구하고 이번 프로젝트에 ✅Tailwind CSS를 사용하고자 한다. 앞서 말했듯, Tailwind CSS의 생산성과 확장성을 몸소 겪어보기도 했고, 점점 사용자가 늘어나는 만큼 유용한 도구와 플러그인도 잘 갖춰져 있어 러닝커브도 낮춰줄 수 있다고 생각했기 때문이다.

참고로 최근 Tailwind CSS의 v4 버전이 출시되면서 많은 개선이 있었으나 매우 최근에 일어난 메이저 버전 업데이트이므로 이를 React Native에서 사용할 수 있는 방법이 없어 v3를 사용할 예정이다🤧

 

npm trends에서 emotion과 Tailwind CSS의 최근 2년간 다운로드 추이를 비교해보면 아래와 같다.

 

또한 웹과 모바일 간 스타일링 방식의 일관성을 유지하는 것이 협업과 유지보수 측면에서 중요하다고 판단했다. 따라서 React Native 개발 환경에서도 ✅NativeWind를 사용하여 TailwindCSS 기반 스타일링 방식을 유지하고자 한다.

---

라우팅 / 내비게이션 시스템

Next.js는 v13부터 파일 기반 라우팅 시스템인 App Router를 도입했다. React Native 역시 Expo를 사용하기로 결정한데다, 파일 기반 라우팅 방식을 일관되게 가져가기 위해 별도로 React Navigation 등의 라이브러리를 사용하지 않고, ✅Expo Router를 사용하고자 한다. Expo의 공식 문서에서도 이를 권장하고 있다.

---

기타 도구

그 밖에 코드 품질 및 일관성을 위해 ESLint, Prettier를 사용하고, 가능하다면 Jest, Testing Library, Playwright 등의 테스트 도구 도입을 고려해볼 예정이다.

---

마무리하며

기술 스택을 조사하는 과정에서 프론트엔드의 세계, 아니 개발의 세계는 정말 무궁무진하다는 걸 새삼 느꼈다. 아직 프로젝트의 기획이 구체화되기 전인데다, 나 또한 모든 배경 지식을 충분히 갖춘 것은 아니지만, 그럼에도 불구하고 스스로 판단해 스택을 고르고 환경을 구성해보는 경험 자체가 큰 의미라고 생각한다.

어쨌든 이런 상황이기 때문에 분명 당장 이 기술 스택대로 프로젝트를 세팅하는 것부터 시행착오가 있을 테지만🥲 결국 중요한 건 일단 직접 부딪혀보는 것 아닐까?..라는 생각을 해본다!

 

 

---

참고

https://www.nomtek.com/blog/flutter-vs-react-native

https://lasbe.tistory.com/230

https://yong-nyong.tistory.com/94

https://velog.io/@teo/adorableCSS

https://www.youtube.com/watch?v=2Q7x3LNZPJs&ab_channel=%EC%88%98%EC%BD%94%EB%94%A9

https://ykss.netlify.app/devlog/start_with_RN/