앱 개발 프레임워크->웹 프레임워크->웹페이지 렌더링들을 둘러본 이야기

서비스 제작을 위한 앱 개발 수단을 찾아야 했다.

필요 사항은, 빠르게 개발 가능하고, 유지보수의 용이성을 위해 인력이 많은 개발 방식이 필요했다.

 

크로스플랫폼 고려

처음으로 고려한 것은 네이티브 대신 크로스플랫폼 프레임워크를 사용하는 것이었다. 가장 사용률이 높은 Flutter(플러터)와 React native(RN)를 중심적으로 봤었다.

플러터는 구글에서 관리하고, 자체 언어인 Dart언어를 이용한다. RN은 메타에서 관리하고, React와 비슷하게 자바스크립트를 이용한다.

 

크로스플랫폼으로 제작하면, 각 안드로이드 개발자와 IOS개발자로 앱 개발자를 두 분류로 나누어 구할 필요가 없어, 단순히 보았을 때 2배의 생산성을 보여준다. 또한 IOS개발 같은 경우에는 애플 기기가 필요한 등 접근 장벽이 높아 사람도 찾기 어려웠다.

 

크로스플랫폼의 단점

다만 실제 현업에서 사용하는 비율을 확인하기 위하여, 여러 구인 사이트와 기업별 기술 스택 사용 사이트를 통하여 본 결과, 실제로는 네이티브가 크로스플랫폼의 5배 이상의 사용률을 가지고 있는 것으로 보였다.

 

또한 크로스플랫폼 중 플러터와 RN을 봤을 때 구글과 메타에 의존성이 있고, 지원이 부진해질 수 있다는 단점이 있었다.

 

웹뷰

그렇게 네이티브와 크로스플랫폼 중 고민하다 갑자기 웹뷰가 떠올랐다. 원래 웹뷰라 하면 웹인 것이 많이 티가나고, 느린 속도와 어색한 UI 등의 인식을 가지고 있었다. 그러나 최근에 토스 앱도 웹뷰로 개발되었다는 것을 본 기억이 떠올랐고, 다른 웹뷰로 만들어진 앱을 찾아보았더니 네이버의 여러 앱들과 여러 편안한 사용자 경험을 느꼈던 앱들도 웹뷰로 개발된 것을 알게 되고, 웹뷰를 사용해 보자는 결정을 했다.

 

또한 이 과정에서 Progressive web app(PWA)등의 정보도 찾아볼 수 있었다.

 

웹 프레임워크

웹뷰 앱을 만들려면 웹을 만들어야 했다. 처음에 바로 떠오른 것은 React(리엑트)였다.

반사적으로 든 생각이었지만, 실제로 리엑트는 웹뷰앱을 만들기에 나쁜 방법이 아닌 듯했다. 기본적으로 Single Page Application(SPA)이기에 웹에서도 앱 같은 자연스러운 경험을 줄 수 있고(앱에서 버튼을 누를 때마다 새로고침이 되면 이상하다) 사용수도 많은 웹 프레임워크이기도 하다.

이를 찾아보며 cors-js 라이브러리 개발자의 So, what's next? 글을 읽어보게 되었다. 오픈소스 생태계에서 한 사람의 희생적인 기여에 대한 글이다. 본문과 상관은 없지만 여러모로 js의 거대한 생태계와 한 인간으로서의 개발자등에 대해 생각하게 해 주었다.

 

웹사이트 렌더링

오랜만에 다시 프런트엔드 프레임워크를 알아보며, 최근에 읽어보려고 저장했었던 글이 떠올랐다.

https://www.daleseo.com/spa-ssg-ssr/

SPA와 SSG, 그리고 SSR

SPA, SSG 그리고 SSR을 비교하는 글인데, 알고 있는 지식을 다시 확인할 겸 읽어보았다.

https://d2.naver.com/helloworld/7804182

또한 네이버 D2의 SSR에 관해 설명한 글도 읽어보았다.

 

원래 알고 있던 내용을 단순히 복습하고 지식을 체크하며 읽어본 것인데, 읽다 보니 헷갈리는 점이 생겼다. CSR앱들은 우선 접속 시에 단순히 정적웹 배포기등으로 HTML, CSS, JS 몽치를 클라이언트에 던져준다. 이후 클라이언트는 백엔드 서버와 API 등을 통하여 정보를 가져오고 사이트는 완성된다.

SSR앱들은 사실 원래의 대부분의 웹사이트의 방식이라고 생각이 드는데, 웹사이트 요청 시마다 HTML, CSS, JS 몽치를 새로 클라이언트에 보내주는 것이다. 그렇다면 Next.js나 SvelteKit 등은 프론트엔드인가 백엔드인가? 기본적으로 프론트엔드라 할 수 있으나, 실제로 DB 등을 연결하고 백엔드의 역할을 할 수도 있다. 또한 단순 정적웹사이트로 배포가능한 리엑트앱등과 달리 아마도 서버를 유지해야 하는 걸로 알고 있다(정적웹사이트로 배포도 가능한 듯하다). 아무튼 그럼 백엔드라고 하면 Next.js에 추가적으로 백엔드를 연결할 수는 없는 건가? 만약 연결한다면 그건 백백엔드 이런 것이 되는 건가? 머리가 뜨거워졌다.

 

이는 약간의 용어 혼재의 문제가 있는 듯했다. 기존의 백엔드 서버를 API서버라고 한다면 될 것 같다. 그렇다면 Next.js에 API서버를 연결해서 사용한다면 이는 어떤 방식으로 사용하는 걸까? Next.js로 SSR 해서 만든 사이트에 JS로 클라이언트에서 API 통신을 하여 CSR를 추가하는 방식? 아니면 Next.js의 뒤에서 API서버와 연결하여 요청을 받을 때마다 API서버에서 정보를 가져와서 SSR를 해주는 방식? 언제나 그렇듯이 두 가지 방법이 모두 가능했다. 단지 Next.js가 SSR이라고 하여 따로 API서버를 두는 것이 불가능한 건 아니라는 것만 확인한 느낌이다. 명확한 하나의 가장 아름다운 답을 찾으려 했는데 단지 많은 방법이 있다는 것만 알게 되었다.

 

네이버 블로그 서비스

이런 의문들이 줄줄이 이어졌던 건 위의 네이버 D2의 글을 읽어보면서였다. 네이버 블로그 서비스는 기존에 고전 SSR?로 운용되던 서비스에 Angular를 이용하여 SPA를 구축했다. 이때 기존의 JSP로 만들어져서 프론트-백이 통합되어 있던 환경을 분리했다. 완전히 분리된 것은 아니고 CSR 페이지는 프론트로 분류하여 개발하고, SSR페이지는 여전히 백엔드로 남겨 개발하던 상황인 것 같다. 여러모로 혼재된 상황이다.

 

이후 Node기반 SSR을 도입하여 웹페이지 생성 부분은 모두 프론트로 넘어가게 되었고, 백엔드는 API서버를 맡게 되었다.

 

아무튼 이 글에서 의문이 생겼던 것은 다음 문장이었다.

 

둘째, SSR을 사용하면 프런트엔드 영역과 백엔드 영역을 완전히 분리함으로써 생산성을 높일 수 있다.

내가 기존에 생각했던 건 SSR을 하려면 Django나 JSP 이런 것들을 사용할 텐데, 그러면 프론트와 백엔드가 하나로 합쳐지는 것이 아닌가?라는 것이었다. 이런 생각을 했던 건 바로 사이트를 생성해 주는 서버가 백엔드 서버가 아닌가,라는 생각을 했기 때문인데, 프론트엔드의 범위는 SPA등에서 정적웹사이트뿐만 아니라, SSR을 도입했을 때의 사이트를 생성해 주는 서버까지가 프론트엔드로 묶는 게 깔끔하다는 것을 알았다.

이것과 별개로 정보를 가져오는 API서버를 백엔드라고 하는 것이 프론트와 백의 구분 기준이 맞는 것 같았다.

 

지금 다시 생각해 보면 당연한 것인데, 기존 지식이 제대로 되어있지 않아서 혼란스러웠던 부분이었다. 그리고 너무 모든 것에 확실한 하나의 답을 찾고 모든 것을 분류하려고 해서 그런 것 같기도 하다.

 

실제 웹 서비스에서는 처음에는 SSR로 받아오고 최대한 빠르게 웹사이트를 보여준 후에 계속 데이터를 받아서 SPA로 이용하는 경우도 있지 않을까? 아마 이게 가장 효율적인 방법 같고 분명 있을 거다...

SSR 사이트에서 API로 무언가를 받아오면 그건 SSR 사이트인가 CSR 사이트인가?

이러한 분류들은 다 어느 정도의 예시를 위한 것이고 결국 너무 집착할 필요가 없는 것 같다.

 

별개로 보안적 관점에서 생각을 해보며 SSR의 장점 중 하나를 떠올렸는데, API서버를 SSR사이트 뒤로 숨긴다면 API서버에 임의 접근이 불가능해진다는 것이다. 만약 SPA에서 API서버를 열어놓고 계속 그곳에서 정보를 받아오는 식으로 통신을 한다면, 사용자가 정상적인 웹을 이용한 사용자인지, 아니면 어떤 툴을 이용하여 정상적으로 웹을 사용하는척하고 API통신을 이용하는 사용자인지 구분이 어려운데, SSR을 이용한다면 아예 API서버의 접근을 SSR로 제작된 웹을 통해서만 가능하기에 이를 막을 수 있다. 사실 이것도 실제 SPA가 이런 느낌으로 돌아가는 건지 확실치 않아서 맞는지 모르겠다.

 

아무튼 앱 스택 선정부터 시작하여서 정말 멀리 온 하루였다.

 

추가적으로 읽어볼만한 글들

https://medium.com/hcleedev/web-서버-사이드-랜더링-ssr-알아보기-c0b8075dd661

Web: 서버 사이드 랜더링(SSR) 알아보기

https://web.dev/rendering-on-the-web/

Rendering on the Web

윗글의 번역 https://shlrur.github.io/develog/2019/02/14/rendering-on-the-web/

Web에서의 Rendering