웹 개발에서 파악하지 못하고 있는 것

데이터 엔지니어로서 모바일, 프론트엔드를 위한 데이터 서빙을 담당했었다. 아주 간략히 나누자면 첫 번째로 서비스에 필요한 데이터를 만들기 위한 데이터 파이프라인이 존재한다. 두 번째로 가공한 데이터는 최종적으로 API 형태로 제공한다.

 

나는 컴퓨터 공학이 아닌 조금 다른 지점에서 개발에 흥미를 느끼고 시작하게 된 케이스였고 그러다보니 펀더먼탈이 되는 것들을 깊게 공부하지 않고 비교적 마이너한 부분부터 파고 들어왔다. 일과 공부를 병행 해나가면서 결국 웹을 정확히 모르고서는 앞으로의 성장에 걸림돌이 될 것 같아서 웹 개발의 전반적인 흐름을 파악해야 겠다는 결론을 내리게 되었다. 아마도 순서는 Web에서의 frontend, backend Role을 이해하고 다시 CS 기초를 리뷰하는 흐름이 될 것 같다.

 

먼저 튜토리얼 수준 강의에서는 WAS(Web Application Server)를 사용하여 웹 서버에서 DB에 데이터를 직접 요청하고, 렌더링을 마친 결과를 웹 서버가 클라이언트에 직접 내려준다. 즉 서버에서 데이터 처리를 마친 결과물을 클라이언트에 내려준다. 그런데 여기서부터 혼란스럽기 시작했다. 

 

"나는 항상 API 형태로만 데이터를 제공했는데..? 백엔드는 다른가..?"

 

구글링을 해나가면서 SSR(Server Side Rendering) 그리고 CSR(Client Side Rendering) MPA(Mulit Page Aplication), SPA(Single Page Application) 등의 용어를 접하게 되었다.

 

CSR은 웹 서버에서 html, css, js를 클라이언트에 내려주고 클라이언트가 직접 백엔드 API에 데이터를 요청해서 받은 결과를 직접 렌더링을 하게 된다.

 

여기서 첫 번째 의문점이 생겼다. 클라이언트에서 백엔드 서버에 직접 API call을 날리면 너무 위험하지 않을까? 이때 Nginx가 떠올랐다. 아.. 이걸  위해서 Reverse proxy를 구축하고 백엔드 서버를 숨기는 것 같다.

 

그리고 다음으로 이와 같은 CSR을 사용하게 되면 html, css, js를 내려받았지만 아직 데이터는 요청하지 못한 상태이므로 유저 입장에서는 페이지 로드에 더 많은 시간이 소요되는 것 처럼 느껴질 수 밖에 없다. SSR은 이미 완성된 결과를 내려받지만, CSR은 웹 서버에서 html, css, js를 내려받은 뒤 클라이언트가 다시 백엔드에 데이터를 요청해야 하기 때문이다. 그리고 이 과정에서 SPA가 등장하게 된 이유를 알게 되었다. SPA는 클라이언트가 우선 내려 받은 html, css 파일을 렌더링한다. 그리고 API에서 데이터를 받게 되면 다시 렌더링을 추가적으로 수행한다. 즉 단계적으로 정보가 추가되므로 유저 친화적인 경험을 제공할 수 있게 되는 것이고, 이러한 SPA를 사용하는 js framework가 React다.

 

그렇다면 왜 백엔드와 프론트엔드의 역할이 왜 명확하게 구분이 되기 시작했고, 백엔드는 왜 API만 담당하고, 프론트엔드에서는 왜 클라이언트가 직접 데이터를 요청하는 방식으로 변화하게 되었는가에 대한 궁금증이 생겼다. API를 웹서버와 별도로 운영을 하게 되면 네트워크 오버헤드가 생길 수 밖에 없을텐데 왜 이렇게 분리가 된거지? 서비스 규모가 커짐에 따라서 부하를 줄이기 위해 책임을 나눈걸까?

 

리서치를 진행했을 때 모바일이라는 새로운 클라이언트가 등장하면서 이러한 태동이 시작된 것으로 보인다. 웹과 모바일은 서비스에서 동일한 포인트라도 화면의 크기가 다르므로 요청하는 정보가 다를 수 있다. 또한 모바일은 웹 브라우저 외에도 애플리케이션이 있을 수 있다. 그러므로 기존의 WAS 방식으로는 두 플랫폼을 모두 만족시키기가 어렵다. 다른 이유들이야 더 있겠지만, 모바일과 웹에 모두 유연하게 대응하기 위해 백엔드는 데이터만 처리하여 내려주고 프론트엔드에서는 화면을 구현하고 데이터를 요청하는 방법에 대한 코드를 작성한다. 그리고 클라이언트가 직접 API에 데이터를 요청하면 역할 구분이 명확해짐과 동시에 백엔드에서는 유연한 대응이 가능해진다.

 

이에 대한 글을 찾아보다가 Okky라는 곳에서 도움이 될만한 댓글을 찾았다. 해당 키워드를 가지고 구글링을 해보면 좋을 듯 하다.

https://okky.kr/articles/538253?note=2111760 

OKKY - REST API로 백엔드를 분리한다는 이야기는......!?

 

그리고 여기서 한 단계 더 나아가서, 같은 API를 호출하더라도 웹 프론트와 모바일에서 필요로하는 정보가 조금씩 상이할 수 있다. 하지만 백엔드는 서비스 규모가 커짐에 따라서 1:1 커플링 관계가 아닌 1:N의 관계로 다수의 유저를 상대해야 한다. 그리고 이 과정에서 각 케이스마다 불필요한 데이터를 추가적으로 제공받으므로 오버헤드가 생긴다. 이를 핸들링하기 위해서 프론트에서는 BFF(Backend For Frontend)라는 개념이 등장했다. 간단하게 각 플랫폼이 API를 호출하는 중간 지점에 프론트엔드를 위한 백엔드 서버를 하나 두는 것인데 이 백엔드 서버가 미리 필요한 정보만 가공해서 던져주는 역할을 한다. 그러므로 클라이언트는 필요한 데이터만 받아올 수 있다. 그리고 이러한 BFF는 프론트엔드 Role이 담당하게 된다.

https://fe-developers.kakaoent.com/2022/220310-kakaopage-bff/

카카오페이지는 BFF(Backend For Frontend)를 어떻게 적용했을까?

 

솔직히 궁금해서 하나하나 코드레벨에서 구현을 해보고 싶은데, 경험상 코드 레벨로 구현한다고 하더라도 내 Role이 아닌 이상 시간이 지나면서 까먹는다. 그래서 가장 중요하게 생각하는 것은 왜 이러한 흐름으로 아키텍처가 변화하게 되었는지를 이해하는 것이다.

 

아직 완벽하게 흐름은 이해하지 못하고 파편적인 키워드를 통해서 어림짐작을 하는 수준이다. 프론트엔드 현업을 알면 금방 속시원하게 푸릴 문제일 것 같은데..

 

지금 가장 궁금한 것은 CSR에서 js가 어디로 API콜을 날리지는지 모두 노출이 되는데, 이게 설령 proxy, Lb라고 할지라도 이건 일종의 게이트웨이 역할을 하기 때문에 이 지점이 공격 당하면 굉장히 난처할 것 같은데.. 웹서버가 내려주는 코드에서 js가 API 콜을 어떻게 치고 있는지 알아보자.

 

https://www.youtube.com/watch?v=f4D50VnO_Gw&ab_channel=HackYourFuture 

vanila js에서 API call을 통해 화면에 렌더링하는 내용을 소개하고 있다.