Server Side Rendering

 

요즘 웹 서비스 구성들은 프론트엔드, 백엔드 둘로 나뉘어 있고

 

앞단과 뒷단이 나뉘어져 있는 게 당연하게 여겨지는 것 같다.

 

 

 

요즘 서비스 구성은 간략하게 그림과 같이 구성되어 있다.

 

사용자가 도메인에 접속하게 되면 웹 서버는 정적 페이지 (HTML, CSS, JavaScript)를 제공하고

해당 페이지에서 백엔드 서버와 통신을 하면서 비지니스 로직이 처리된다.

 

왜 이런 구조가 거의 표준화 된 듯 사용되는 것일까??

 

그냥 하나의 서버로 모든 요청을 처리하면 효율적이지 않을까??

 

SSR(Server Side Rendering)

하나의 서버로 모든 요청을 처리하는 구조를 서버사이드 렌더링(SSR) 이라고 한다.

말 그대로 서버에서 우리가 보는 페이지를 렌더링 하는 구조이다.

 

위의 구조에서 보면 SSR은 정적 페이지 제공 + 비지니스 로직 처리 까지 담당하게 된다.

 

단순하게 생각하면 그냥 사용자 요청이 많아져서 서버가 견딜 수 없게 되면 단일 서버를 스케일 아웃 하면 된다.

 

단순하게 보기엔 둘로 나누는게 굳이..? 라는 생각이 들 정도로 간단한 구조인데 왜 이 구조를 잘 쓰지 않게 되는 것 일까?

 

단점

우선 '쓰지 않게 됐다' 라는 점은 안 좋은 점이 있어서 쓰지 않게 됐으니 안 좋은 상황들에서 위의 그림에서의 구조와 비교를 해보면 좀 더 명확해진다.

 

비지니스 로직 처리에서 예를 들어서 비지니스 로직을 처리하는 도중 예기치 못 한 상황이 나서 서버가 다운되어야 하는 상황이 생겼다고 하자.

 

그럼 서버가 다운 됐으니 정적 페이지 제공까지도 하지 못 할 것이다. 그러면 사용자는 해당 서비스를 사용하려고 들어왔을 때 페이지조차 보이지 않는다.

 

앞단과 뒷단을 분리하게 된다면 하나의 서버가 다운되더라도 장애가 전파되지 않을 수 있다.

 

생산성 측면에서 보면 프론트엔드 개발자들과 백엔드 개발자들이 하나의 래포를 가지고 이력들이 꼬이는 경우가 있을 수 있고 단순하게 화면에 보이는 위치 수정 정도의 수정 사항을 배포하는 경우에도 백엔드 개발자들은 무슨 배포가 나가는지 신경 쓸 수 밖에 없는 구조가 된다.

 

규모가 커질수록 프론트, 백엔드 각각 추가되는 영역이 많아지고 이를 신경쓸 수 밖에 없게 되는 구조가 된다.

 

코드 관리 측면에서도 프론트엔드 개발자들과 백엔드 개발자들은 따로따로 그들끼리 관리를 하고 히스토리 관리를 할 수 있게 된다.

 

 

장점

외부서비스가 필요해서 사용하게 되었을 때, 예를 들어 이미지 저장소를 직접 구현하는 것 보다 외부 서비스를 사용하는 것이 훨씬 편리해서 해당 서비스를 사용한다고 가정하자.

 

위의 그림에서 CSR(Client Side Rendering)구조에서 만약 클라이언트가 서버로 바로 이미지를 전송하게 되고, 서버는 해당 이미지를 다시 이미지 저장소로 올리게 된다면. 그냥 이미지 저장소를 해당 서비스 개발자들이 구현하는게 되는 것과 다를 게 없다. (디스크에 저장하는 것 만 하면 직접 이미지를 저장하는 것이랑 다를게 없다.)

 

그렇다면 클라이언트쪽에서 바로 이미지 저장소로 저장 요청을 날리게 되는데, 이 과정에서 외부 서비스들은 인증키 같은게 필요하다. (아무나 막 쓸 수는 없으니까)

 

그럼 클라이언트쪽에 해당 인증 키를 심을 수 밖에 없게 되는데 개발자 도구를 들어가서 요청을 확인 해 보면 해당 키는 노출이 된다.

 

물론 1차적인 방어책으로 호스트 주소를 확인하고 그러겠지만.. 그래도 웹개발을 조금만 알아도 충분히 악용 할 수 있는 여지가 있다.

 

SSR에서는 서버에서 해당 인증키를 들고 있어서 이런 부분을 신경 안 써도 된다.

 

또한 작은 서비스의 경우 SSR을 사용하는 것이 생산성이 높을 수 있다.

 

위의 인프라를 구성을 보면 관리해야 하는 포인트가 하나 더 늘어나는 샘이다.

추가로 작은 서비스같은 경우는 추가의 인프라 비용을 사용해야 하는 점이 있다.

 

서비스 하나를 띄우려는데 Nginx같은 Web Server까지 구성 할 줄 알아야 하고... 해당 서버까지 관리해야 하는 번거로움이 있다.

 

그래서 작은 서비스 같은 경우는 SSR을 사용해서 빠른 개발 사이클을 만들고 서비스가 커지면 CSR로 바꾸는 것도 괜찮을 것 같다고 생각한다.

 

 

 

검색하면 나오는 SSR, CSR의 개념보다 실제로 장, 단점이라고 느낀 부분을 풀어서 작성하였다.

다른 사람들은 다르게 느낄 수도 있지만(검색 엔진 최적화 등등.. 그쪽 분야는 못 접해봤다..)

 

적어도 나는 저 부분들이 직접 느낀 장, 단점이라고 생각한다.