서버사이드 렌더링에서 클라이언트 렌더링으로 바꾸고 다시 돌아온 이유는?

두 달이 지났다. 요즘처럼 프론트엔드 프레임워크가 많은 시기에 SPA(Single Page Application)을 만들고 싶은건 어찌보면 당연하다... 하지만 그 동안 쉽게 결정을 내리지 못했으니 그 이유는 모두 seo.. 검색엔진최적화에 대한 의문이다.

이 의문은 아직도 가지고 있지만 실제로 클라이언트 렌더링으로 모두 바꾸고 두 달 동안 느끼고 경험했던 것들을 적어볼까한다. 결론부터 말하면 난 다시 돌아왔다; 서버렌더링으로 바꾸는데도 꽤 많은 시간이 들었다;;

  "클라이언트 렌더링 vs 서버사이드 렌더링"  

SEO만 따지고 본다면 당연히 서버사이드보다는 클라이언트 렌더링이 우수하다고 쉽게 결론을 내리기 쉽다. 하지만 구글링의 정점에서 난 클라이언트가 우세하다는 의견을 너무 많이 봐버렸다... 고민할 필요도 없이 Webisfree의 싱글페이지로 변신을 시작했다.


# 클라이언트 렌더링시 고민할 점
난 AngularJS를 사용했다. 이 역시 MVC 패턴을 사용하는 프론트언어로 대부분의 사람들이 선호하는 언어 중 하나이다. 어쨌든 열심히 탈바꿈 과정에서 어려움에 봉착했으니 바로 API가 하나도 없다는 것이다; 사실 다 서버렌더링으로 만들어져 있었으니 REST API를 만드는 것도 여간 어려운 일이 아니다... 하지만 API는 한번 만들어두면 비슷한 HTTP 메소드들은 가져다 쓰면 되므로(물론 데이터베이스는 간단한 인덱스 정도만 작업하고;) 열심히 뚝딱하다보니 어느새 새로운 웹어플리케이션으로 탈바꿈 ㅎㅎ

개발과정에서 아래와 일부 코드는 서버 렌더링을 유지했다...

• head 내부의 메타관련 정보들 
• 인증에 관련된 세션 및 쿠키 코드들

메타데이터는 사실 seo의 핵심이다. 이 부분은 가급적 서버렌더링을 남겨두었는데 아무래도 크롤러, 봇이 지연시간에 따른 크롤링에 조금이라도 손해가 생길 것 같은 미심쩍은 부분이었다.

# 클라이언트 렌더링의 장점 및 고민할 점

클라이언트 렌더링 방식이 서버렌더링 방식보다 좋은 이유는 무엇일까 내생각으로는...

• 1. 빠른 페이지 로딩 속도
• 2. 부분 콘텐츠 로딩으로 빠른 트래픽 처리
• 3. 클라이언트에게 더 빠른 경험을 제공
• 4. 구글과 같은 검색엔진에서 쿨라이언트 렌더링을 높이 평가
  

사실 페이지 로딩 속도는 생각보다 중요하다. 여기서 눈에 띄는 4번은 무시할 수 없는 이유인데 사실 자바스크립트의 끝은 ajax 그리고 클라이언트측 처리에서 꽃을 피웠다 말할 수 있다. 그 중심에 angulrjs 역시 한 몫했다... 물론 지금은 뭐가 좋다고 판단할 수 없지만(각자 장단점이 있으므로...) 말이다.

이런 장점도 있지만 고민되는 부분은 무엇일까?

1. 해쉬뱅 방식 등의 클라이언트 검색엔진 최적화 작업이 필요
: 꽤 어렵고 귀찮은 작업이다. 이는 크롤러에게 실제 콘텐츠 정보가 담긴 페이지를 알려주는 클라이언트 렌더링 seo의 가장 핵심이나 그 범위를 어디부터 어디까지 제공해야 하는지의 생각할 고민이 많다.

2. 많은 검색엔진
; 트래픽의 전부가 하나의 검색엔진이라면 모르겠지만 seo에 영향을 미치는 요소로 다른 페이지 또는 따른 검색엔진의 인덱싱 여부 및 쿠기이다. 이를 고려하자면 사실 내가 먼저 앞서서 고생할 필요는 없다; 냉정하게 남이 보완하고 보수공사를 마친 안전한 곳을 가는 것이 더 현명할 수 있다.


약 두 달간의 클라이언트 렌더링은 비록 실패했지만 좋은 경험이었다. 지금은 모든 것을 서버 렌더링으로 바꾼 것이 아닌 이 전에 만들어둔 클라리언트 코드와 API를 활용하고 있다. 초기 로딩 이후부터 클라이언트 렌더링 방식을 사용하여 비동기식 방식을 적용하는 것이 많아졌고 방문자들은 더 나은 경험을 가지게 되었다 생각한다.

좀 더 시기가 지나고 좀 더 배우고 분석하여 클라이언트 렌더링 검색엔진최적화에 만족할 수 있는 수준에 다다르면 다시 또 도전을 해보려한다. SPA는 현재 어드민, cms에 많이 사용되는 한정적인 모습을 보이지만 지금의 속도라면 더 많은 레퍼런스를 얻고 쌓을 수 있게될 것 같다.