[Spring MVC 1] - HTML, HTTP API, CSR, SSR

정적리소스

• 고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공
• 주로 웹 브라우저

HTML 페이지

• 동적으로 필요한 HTML 파일을 생성해서 전달
• 웹브라우저 : HTML 해석

-> 나의 정보(동적인 정보)가 담긴 HTML을 내려줌

HTTP API

• HTML이 아니라 데이터를 전달
• 주로 JSON 형식 사용 (xml 일 수도 있음)
• 다양한 시스템에서 호출
• 데이터만 주고 받음. UI 필요 시 클라이언트 별도 처리
• 앱 클라이언트 to 서버, 웹 클라이언트 to 서버, 서버 to 서버 (ex. 사용자 서버 -> 계좌 검증 서버)

CSR (Client Side Rendering)
서버에서 index.html 파일을 클라이언트에 보내주면 일반적인 csr프레임워크 (리엑트, 뷰, 앵귤러)는 body안의 id="root"와 어플리케이션에 필요한 js링크만 있다. 그렇게 때문에 최초 html은 비어져있어 처음에는 빈 화면만 보이고 다시 링크된 어플리케이션 js를 서버로부터 다운로드 받는다. 이때의 js에는 어플리케이션에 필요한 로직 뿐만 아니라 어플리케이션을 구동하는 프레임워크 소스코드, 라이브러리가 포함되어 있어 사이즈가 크기 때문에 렌더링이 오래걸린다. 추가로 필요한 데이터는 서버로 요청을 하고 받아서 동적으로 html을 생성해서 사용자에게 최종적인 어플리케이션을 제공한다.

• 사용자가 첫 화면을 보기까지의 시간이 오래 걸린다.
• 검색엔진 최적화에 어렵다 (바디가 비어져있기 때문)

SSR (Server Side Rendering)
웹브라우저 요청시 서버에서는 필요한 데이터를 모두 가져와서 html파일을 만들고, html 파일을 동적으로 제어할 수 있는 소스코드와 함께 클라이언트에게 보내준다. 클라이언트에서는 동적으로 만들어진 html파일을 바로 사용자에게 보여준다.

• csr 사용시보다 첫 화면의 렌더링 시간이 빠르다
• 모든 컨텐츠가 html에 담겨있어 검색엔진에게 효율적이다
• 그러나 페이지 이동할 때마다 정보를 다시 서버에서 요청해서 가져와야하기 때문에 블링킹이슈 (사용자 경험이 좋지않다) 가 있다
• 서버에 과부하가 오기 쉽다

---

내가 해왔던 프로젝트에서는 타임리프를 이용한 ssr 방식으로 구현이 되어있는데 종종 불편함을 경험했다. 그리고 그 불편함을 'ssr 방식 때문이다'라고 단순 결론을 내려버리거나 요즘 주로 쓰이는 csr 방식의 프레임워크(리액트, 뷰,앵귤러)가 막연하게 모든 것을 해결해줄 것 이라는 환상을 가지곤 했다. 그러나 그 환상은 과거의 것을 배제시키고 새로운 것의 등장배경과 과정은 철저히 등한시 된채로 또 다른 지식=공부해야 할 대상의 탄생이었다. 과거를 회고해보면 리액트, 뷰 관련 강의나 서적볼 때도 클라이언트렌더링 관점에서 파생되어 개발된 언어로 접근하기 보다는 '됬고 컴포넌트는 어떻게 생성하는데? 그래서 데이터는 어떻게 가져오고 어떻게 보여줄건데?'에서 벗어나지 못한 태도로 공부한 것 같다. 이와 관련된 것들을 찾아보다 네이버블로그에서는 node.js기반 ssr방식으로 전환을 하고, 리액트는 next.js을 지원하면서 csr과 ssr의 장점을 부각시키려는 각개의 피나는 노력들을 하고 있었다. 이 강의를 보고, 공부를 하면할 수록 개발자로서의 나의 태도를 돌아보며 구현에만 집중하는 편협하고 안일한 내가 부끄러워졌다. ㅠ.ㅠ 흑흑흑... 내가 경험해본 것과 해보지 않은 것을 올바르게 인지하는 것. 정의와 배경을 단단히 다지고 개발자로서의 책임을 다하자. 일정에 쫓겨 구현중심의 사고할 때는 지났다. 내 코드와 선택에 책임감을 심자.....!!!!!!!!!!!!

같이 보면 좋은 글들 https://d2.naver.com/helloworld/7804182

 

@ 스프링 MVC 1편 - 백엔드 웹개발 by 김영한을 참조하고 있습니다.