서재(書齋)

서비스의 해상도를 결정하는 일은 중요하다고 생각한다.

고객 경험이 좋지 않은 서비스는 아무리 컨텐츠가 뛰어나도 성공할 확률이 낮아진다.

소규모 개발자의 컨텐츠는 더더욱 사용자가 접하는 서비스의 첫 인상과 초기 몇 분 동안의 경험이 고객 확보와 이탈의 기로 사이에서 굉장히 중요한 역할을 한다고 생각하기에, 디자인과 고객 경험은 특히나 더 신중해야 할 부분이다.

UI Framework 선정

UI 프레임워크(라고 해야할지 Kit이라고 해야할지)를 우선 선정한다.

리서치를 통해 비교군은 아래와 같이 잡아보았다.

• Tailwind CSS
  - 단순 CSS 라이브러리
• MUI(Material UI)
  - Material Design(Made by Google)의 React 버전
  - 안드로이드 스타일의 디자인이 쉽고 간편하다
  - 무겁고 커스터마이징이 어렵다
• bootstrap
  - Made by Twitter
  - 트위터 스타일의 디자인이 쉽고 간편하다
• Ant Design
  - Made by Alibaba
  - 가볍다
  - 중국…

나는 Android 사용자이기도 하고, 개인적으로 애플의 폐쇄성이 싫고 구글 스타일의 UI가 나쁘지 않다고 생각하는 사람이다.

또한 내 서비스는 개인 프로젝트에 가까워 무겁다는 것은 단점이 되지 않는다.

커스터마이징 할 시간에 서비스를 구현해야 하기 때문에 커스터마이징도 크게 고려하지 않기로 했다.

따라서 답정너인것 같기는 하지만 MUI(Material UI)를 사용하여 UI를 만들기로 했다.

표준 해상도 결정

운이 좋게도 서비스 및 화면 기획 경험이 있다 보니, 표준 해상도라는 것이 서비스 구현에 있어 얼마나 중요하며 기준을 제대로 잡고 디자인하는 것이 사용자 경험에 얼마나 큰 요소인지를 체감할 수 있었다.

나는 모바일 웹 게임에 가까운 서비스를 만들려고 하고 있으므로, PC 환경에 대한 대응은 크게 신경쓰지 않을 예정이다.

따라서 스탯 카운터(https://gs.statcounter.com/) 사이트를 참고하여 현재 모바일 기기별 해상도 점유율을 살펴보고, 이에 따라 표준 해상도를 결정하기로 했다.

아래는 해당 사이트에서 살펴본 대한민국의 최근 1년(23. 03. 26. 기준)간 모바일 해상도 점유율이다.

1위는 10.25%의 390x844, 2위는 9.47%의 412x915 해상도임을 알 수 있다.

검색을 해 보니, 390x844 해상도는 iPhone 13 Pro & iPhone 14의 해상도로, 412x915 해상도는 Galaxy S20 Ultra 기종의 해상도다.

처음에는 Worldwide로 필터를 설정하여 검색했으나, 아직까지 예전 안드로이드 핸드폰을 사용중인 전 세계인들의 영향인지 아래와 같이 예전 안드로이드 표준 해상도인 360x800의 점유율이 압도적인 1위로 나타난다.

갤럭시 S21 이하 휴대폰의 해상도가 360x800, 또는 360x760이 많으므로 완전 구형 핸드폰이라고는 할 수 없지만, 나는 K-서비스를 만들 예정이므로 전 세계인의 기준이 아닌 내수 기준을 따르고 이 기준을 전 세계로 확산시키겠다.

결론은, 한국 기준으로 안드로이드 점유율 1위 해상도인 412x915를 기준으로 서비스를 개발하기로 했다.

디자인 툴은 Adobe XD를 사용할 예정이다.

끝.

어떻게 보면 가장 문외한이라 할 수 있는 FE 영역을 공부하려 하는데, 자꾸만 프레임웤(이 아니라 사실 React는 라이브러리라고 하지만 혼용된 의미로 사용되는 것 같다. 일단은 사전 제공되는 규모의 차이니 둘 다 프레임워크라 하기로...) 선택에 시간이 소요되고 있다.

많은 영상을 참고해 보면 둘 다 배우라는 이야기가 많지만, 나는 BE 뿐 아니라 DB도 신경써야 하고 서비스 자체를 기획해야 하는 입장에서 컨텐츠/디자인 영역에 소요될 시간이 더 많을 것 같아서 둘 중 하나를 선택해서 배워야 하는 입장이다.

혼자 끙끙 앓으며 고민하기보다는 두 기술에 대해 잘 설명되어 있는 유튜브 영상을 참고하여 프론트에 대한 이해도 할 겸, 선택에 대한 근거를 좀 쌓아두려고 한다.

참고한 자료는 아래 '큰돌의터전'님 유튜브 영상이다.

전반적인 특징

프로그래밍 패러다임

Vue.js(이하 Vue라 한다)의 경우, 반응형 프로그래밍으로 특정 요소에 값을 입력하면 watch하고 있다가 특정 변수에 값을 자동으로 입력해 준다고 한다. (Input -> Value)

예를 들어, 텍스트박스에 값을 입력하면 입력된 값을 별도의 할당 함수 없이도 변수가 해당 값을 인지하고 가지고 있을 수 있다.

위와 같은 특성을 가진 라이브러리를 다뤄본 적이 없어서 정확히 어떤 식으로 작동되는지는 알 수 없으나, 영상 내의 예시를 보니 대충 이해가 되었다.

React.js(이하 React라 한다)의 경우, 함수형 프로그래밍으로 setState등의 함수를 활용해 특정 요소에 입력된 값을 이용해 변수의 값을 변경 가능하다. (Input -> function -> Value)

데이터 바인딩

다 까먹어서 가장 이해가 취약한 부분인데... 현재 수준에서 적어보려 한다.

모델과 뷰 간의 데이터 동기화 방식에 대한 차이를 의미하는 것으로, 다른 분이 정리해 주신 내용을 참고하여 이해했다.

(출처 - adjh54님의 Tistory https://adjh54.tistory.com/49)

React가 사용하는 단방향 데이터 바인딩의 경우, 아래 그림과 같이 로직이 존재하는 Model에서 화면을 로딩하는 시점에 View 영역으로 데이터를 제공하고 이를 이용하여 초기값 등을 셋팅한다.

이후 사용자가 View 영역에서 값을 수정하면, onClick 등의 이벤트 함수를 생성하여 이를 다시 Model로 보내준 뒤 각종 로직을 처리하고 DB에 저장 등을 수행하게 된다.

(MVC(Model - View - Controller) 패턴)

Vue가 사용하는(단방향 또한 지원한다) 양방향 데이터 바인딩의 경우, ViewModel 이라는 컴포넌트가 존재하여 View와 Model 컴포넌트의 데이터 변화를 감지하다가, 어느 한 쪽에서 값의 변화가 일어나는 경우 자동으로 다른 컴포넌트에 변화된 값을 동기화해 준다.

(MVVM(Model - View - ViewModel) 패턴)

자유도

자유도의 경우 React가 조금 더 높다고 한다.

타 플러그인 의존도

Vue보다는 React가 타 플러그인 의존도가 높으며, React는 많은 라이브러리를 import 하므로 빌드 시 생성되는 파일의 수도 상대적으로 많다.

Document

공식적으로 제공되는 도큐먼트의 경우 Vue가 조금 더 이해하기 쉽다.

Learning Curve

배우기에는 Vue가 React보다는 조금 더 쉽다고 한다.

성능

성능의 경우 둘 다 준수한 성능을 나타내나, 상대적으로 Vue가 조금 더 우수하다.

각종 프레임워크의 성능을 비교해 놓은 GitHub 링크가 있어 이를 참고하여 설명해 주셨다.

(https://krausest.github.io/js-framework-benchmark/2022/table_chrome_104_windows.html)

기타

커뮤니티의 경우 React가 좀 더 활성화되어 있다.

아무래도 Facebook 진영에서 공식적으로 지원하는 라이브러리이다 보니, 버그 수정도 빠르고 뒷배가 더 든든해서 커밋 수, 포크 수, 기여자 수 등에서 React가 조금 더 앞선 모습을 볼 수 있다.

모바일로서의 확장성의 경우 React는 React-Native라는 너무나 강력한 지원군이 존재하여 NativeScript 등이 존재하는 Vue 진영에 비해 우위에 있다고 할 수 있다.

결론...?

다른 부분은 큰 차이가 없다고 가정하면, 세 가지 포인트 정도가 주된 의사결정 요소가 될 것 같다.

(표에는 없는) 시장 선호도, 러닝커브, (역시 표에는 안 쓴...) 모바일 확장성이다.

시장 선호도는 WorldWide 기준 여전히 React가 높고, 러닝 커브는 Vue가 낮으며, 모바일 확장성은 React가 우위에 있다.

이렇게만 놓고 보면 2대 1로 React의 승리인데... 리액트가 얼마나 배우기 어려운지를 잘 모르겠다...

조금만 더... 고민해보기로 하자...

끝.